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

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

Документація

1 - Документація Kubernetes

Kubernetes — рушій оркестрування контейнерів, створений для автоматичного розгортання, масштабування і управління контейнеризованими застосунками, є проєктом з відкритим вихідним кодом. Цей проєкт знаходиться під егідою Cloud Native Computing Foundation.

1.1 - Доступні версії документації

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

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

2 - Початок роботи

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

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

Деякі компоненти Kubernetes, такі як kube-apiserver або kube-proxy, також можуть бути розгорнуті у вигляді образів контейнерів всередині кластера.

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

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

Навчальне середовище

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

Операційне середовище

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

Для кластера, яким ви керуєте самостійно, офіційно підтримуваним інструментом для розгортання Kubernetes є kubeadm.

Що далі

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

2.1 - Навчальне середовище

2.2 - Операційне середовище

Створіть кластер Kubernetes виробничої якості

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

Аспекти промислової експлуатації

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

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

  • Доступність: Одномашинне навчальне середовище Kubernetes має одну точку відмови. Створення високодоступного кластера передбачає:

    • Відділення панелі управління від робочих вузлів.
    • Реплікації компонентів панелі управління на кілька вузлів.
    • Балансування трафіку до API-сервера кластера.
    • Наявність достатньої кількості робочих вузлів або можливість їх швидкого введення в експлуатацію залежно від змін в робочому навантажені.
  • Масштабування: Якщо ви очікуєте, що ваше операційне середовище Kubernetes отримає стабільний обсяг запитів, ви, можливо, зможете налаштувати потрібну потужність і на цьому зупинитись. Однак, якщо ви очікуєте, що попит зростатиме з часом або раптово змінюватиметься на основі таких чинників, як сезонність чи спеціальні події, вам потрібно розробити план щодо масштабування для обробки зростаючого навантаження від збільшення запитів до панелі управління та робочих вузлів або масштабування вниз для зменшення простою ресурсів, які більше не потрібні.

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

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

  • Serverless: Просто виконуйте робочі завдання на обладнанні сторонніх постачальників без управління кластером взагалі. Вам доведеться платити за такі речі, як використання процесора, памʼяті та дискові запити.
  • Керування панеллю управління: Дозвольте постачальнику управляти масштабуванням та доступністю панелі управління кластера, а також розвʼязувати питання щодо застосування латок та встановлення оновлень.
  • Керування робочими вузлами: Налаштуйте пули вузлів для задоволення ваших потреб, а потім постачальник забезпечить наявність цих вузлів та готовність виконувати оновлення за необхідності.
  • Інтеграція: Є постачальники, які інтегрують Kubernetes з іншими сервісами, які вам можуть знадобитися, такими як сховища, реєстри контейнерів, методи автентифікаційні та інструменти розробки.

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

Налаштування промислового кластера

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

Панель управління промислового кластера

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

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

  • Оберіть інструменти розгортання: Ви можете розгорнути панель управління використовуючи інструменти, такі як: kubeadm, kops, kubespray. Перегляньте Встановлення Kubernetes за допомогою інструментів розгортання, щоб дізнатись порад щодо розгортання промислового кластера за допомогою цих методів. Різні середовища виконання контейнерів доступні для використання у вашому розгортанні.
  • Керування сертифікатами: Безпечний звʼязок між компонентами панелі управління реалізується за допомогою сертифікатів. Сертифікати автоматично генеруються під час розгортання, або ви можете генерувати їх за допомогою власного центру сертифікації. Дивіться Вимоги та сертифікати PKI.
  • Налаштування балансування навантаженням apiserverʼа: Налаштуйте балансувальник навантаження, щоб розподілити зовнішні запити до екземплярів apiserver, що працюють на різних вузлах. Дивіться Створення зовнішнього балансувальника навантаження.
  • Відділіть та робіть резервні копії служби etcd: Служба etcd може або працювати на тій же машині, що і панель управління, або працювати на окремих вузлах, для підвищення захищеності та доступності. Оскільки etcd зберігає дані конфігурації кластера, важливо робити резервні копії цих даних регулярно, щоб переконатись, що вони можуть бути відновлені в разі потреби. Дивіться ЧаПи etcd щодо налаштування та використання etcd. Дивіться Керування кластерами etcd Kubernetes та Налаштування високої доступності кластера etcd з kubeadm.
  • Створення системи з кількома панелями управління: Для забезпечення високої доступності панелі управління, необхідно відмовитися від обмеження щодо її знаходження на одні машині. Якщо служби панелі управління запускаються службою init (такої як systemd), кожна служба повинна працювати як мінімум на трьох машинах. Однак запуск служб панелі управління як Podʼів в Kubernetes гарантує, що реплікована кількість служб, яку ви вказуєте, завжди буде доступною. Планувальник повинен бути стійким до помилок, але не високодоступним. Деякі засоби розгортання налаштовують алгоритм консенсусу Raft для вибору лідера служб Kubernetes. Якщо основна служба зазнає збою, інша служба обирає себе лідером і перебирає контроль на себе.
  • Використовуйте кілька зон: Якщо важливо, щоб ваш кластер був доступним у будь-який час, розгляньте можливість створення кластера, який працює у кількох центрах обробки даних, відомих як зони в хмарних середовищах. Групи зон називаються регіонами. Розподіливши кластер по кількох зонах в одному регіоні, ви можете покращити ймовірність того, що ваш кластер продовжуватиме працювати, навіть якщо одна зона стане недоступною. Дивіться Робота у кількох зонах.
  • Керуйте тривалими функціями: Якщо ви плануєте тримати свій кластер протягом тривалого часу, є завдання, які вам потрібно виконати для забезпечення його самовідновлення та безпеки. Наприклад, якщо ви встановили кластер за допомогою kubeadm, є інструкції, які допоможуть вам з керуванням сертифікатами та оновленням кластерів kubeadm. Дивіться Адміністрування кластера для отримання більш докладного списку адміністративних завдань Kubernetes.

Щоб дізнатися про доступні опції при запуску служб панелі управління, дивіться сторінки компонентів kube-apiserver, kube-controller-manager та kube-scheduler. Для прикладів конфігурації високої доступності панелі управління дивіться Варіанти високодоступної топології, Створення високодоступних кластерів за допомогою kubeadm та Експлуатація кластерів etcd для Kubernetes. Для інформації щодо плану створення резервних копій etcd дивіться Резервне копіювання кластера etcd.

Робочі вузли промислового кластера

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

  • Налаштування вузлів: Вузли можуть бути фізичними або віртуальними машинами. Якщо ви хочете створювати та управляти власними вузлами, ви можете встановити підтримувану операційну систему, додати та запустити відповідні Служби вузлів. Розгляньте такі питання:
    • Вимоги вашого робочого навантаження при налаштуванні вузлів, маючи відповідну кількість памʼяті, процесора та швидкості дискових операцій та обʼєму сховища.
    • Чи підійдуть загальні компʼютерні системи, чи у вас є завдання, які потребують процесорів GPU, вузлів з операційною системою Windows або ізоляції віртуальних машин.
  • Перевірка вузлів: Дивіться Правильне налаштування вузлів для інформації про те, як переконатися, що вузол відповідає вимогам для приєднання до кластера Kubernetes.
  • Додавання вузлів до кластера: Якщо ви керуєте своїм власним кластером, ви можете додавати вузли, налаштовуючи свої власні машини та додаючи їх вручну або реєструючи їх в службі apiserver кластера. Дивіться розділ Вузли для інформації щодо того, як налаштувати Kubernetes для додавання вузлів цими способами.
  • Масштабування вузлів: Майте план розширення потужності вашого кластера на майбутнє. Дивіться Рекомендації для великих кластерів, щоб визначити, скільки вузлів вам потрібно, виходячи з кількості podʼів і контейнерів, які вам потрібно запустити. Якщо ви керуєте вузлами самостійно, це може означати придбання та встановлення власного фізичного обладнання.
  • Автомасштабування вузлів: Ознайомтесь з Автомасштабуванням кластера, щоб дізнатись про інструменти доступні для автоматизованого керування вашими вузлами та ресурсами, які вони надають.
  • Налаштування перевірок справності вузлів: Для важливих завдань важливо переконатися, що Nodeʼи та Podʼи, які працюють на цих вузлах, є працездатними. За допомогою демона Node Problem Detector ви можете забезпечити працездатність своїх вузлів.

Доступ користувачів до промислового кластера

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

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

  • Автентифікація: apiserver може автентифікувати користувачів за допомогою клієнтських сертифікатів, токенів доступу, проксі автентифікації або базової HTTP-автентифікації. Ви можете вибрати методи автентифікації, які ви хочете використовувати. За допомогою втулків apiserver може використовувати наявні методи автентифікації вашої організації, такі як LDAP або Kerberos. Див. Автентифікація для опису різних методів автентифікації користувачів Kubernetes.

  • Авторизація: Коли ви починаєте авторизовувати звичайних користувачів, ви, ймовірно, вибиратимете між авторизацією RBAC та ABAC. Див. Огляд авторизації для ознайомлення з різними режимами авторизації облікових записів користувачів (а також доступу службових облікових записів до вашого кластера):

    • Контроль доступу на основі ролей (RBAC): Дозволяє вам призначати доступ до вашого кластера, виставляючи конкретні набори дозволів автентифікованим користувачам. Дозволи можуть бути призначені для конкретного простору імен (Role) або по всьому кластеру (ClusterRole). Потім, використовуючи RoleBindings та ClusterRoleBindings, ці дозволи можна призначити певним користувачам.
    • Контроль доступу на основі атрибутів (ABAC): Дозволяє вам створювати політики на основі атрибутів ресурсів у кластері та дозволяти чи відмовляти у доступі на основі цих атрибутів. Кожен рядок файлу політики ідентифікує властивості версії (apiVersion та kind) та вказує у властивостях spec збіг з субʼєктом (користувачем або групою), властивістю ресурсу, властивості не-ресурсу (/version або /apis) або readonly. Дивіться Приклади для отримання деталей.

Якщо ви налаштовуєте автентифікацію та авторизацію на своєму промисловому кластері Kubernetes, ось кілька речей, які варто врахувати:

  • Встановлення режиму авторизації: Коли сервер API Kubernetes (kube-apiserver) запускається, підтримувані режими автентифікації повинні бути встановлені за допомогою прапорця --authorization-mode. Наприклад, цей прапорець у файлі kube-adminserver.yaml/etc/kubernetes/manifests) може бути встановлений у значення Node, RBAC. Це дозволить авторизацію Node та RBAC для автентифікованих запитів.
  • Створення сертифікатів користувача та привʼязка ролей (RBAC): Якщо ви використовуєте авторизацію RBAC, користувачі можуть створювати CertificateSigningRequest (CSR), які можуть бути підписати CA кластера. Потім ви можете привʼязувати Roles та ClusterRoles до кожного користувача. Дивіться Запити на підпис сертифікатів для отримання деталей.
  • Створення політик, що комбінують атрибути (ABAC): Якщо ви використовуєте авторизацію ABAC, ви можете призначати комбінації атрибутів для формування політик для авторизації обраних користувачів або груп для доступу до певних ресурсів (наприклад, Podʼів), просторів імен або apiGroup. Докладніше дивіться Приклади.
  • Використання контролерів вхідних даних: Додаткові форми авторизації для запитів, які можуть надходити через сервер API, включають Автентифікацію токенів за допомогою вебхуків. Вебхуки та інші спеціальні типи авторизації повинні бути увімкнені додаванням Контролерів допуску (Admission Controllers) до сервера API.

Встановлення лімітів для робочих навантажень

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

  • Встановіть обмеження простору імен: Встановіть квоти в кожному просторі імен для речей, таких як памʼять та ЦП. Дивіться Керування памʼяттю, ЦП та ресурсами API для отримання деталей. Ви також можете встановити Ієрархічні простори імен для успадкування обмежень.
  • Підготуйтесь до вимог DNS: Якщо ви очікуєте, що робочі навантаження масштабуються, ваша служба DNS повинна бути готовою масштабуватися також. Дивіться Масштабування служби DNS в кластері.
  • Створюйте додаткові службові облікові записи: Облікові записи користувачів визначають, що користувачі можуть робити в кластері, тоді як службовий обліковий запис визначає доступ до Podʼів у межах певного простору імен. Стандартно Pod приймає стандартний службовий обліковий запис у своєму просторі імен. Дивіться Управління службовими обліковими записами для інформації про створення нового службового облікового запису. Наприклад, ви можете:

Що далі

2.2.1 - Середовище виконання контейнерів

Для того, щоб запускати Podʼи на кожному вузлі кластера, потрібно встановити container runtime. Ця сторінка надає огляд того, які компоненти беруть в цьому участь, та описує повʼязані завдання для налаштування вузлів.

Kubernetes 1.31 вимагає використання runtime, який відповідає специфікації Container Runtime Interface (CRI).

Дивіться Підтримка версій CRI для отримання додаткової інформації.

Ця сторінка містить огляд того, як використовувати кілька поширених середовищ виконання контейнерів з Kubernetes.

Встановлення та налаштування передумов

Конфігурація мережі

Стандартно ядро Linux не дозволяє маршрутизувати пакети IPv4 між інтерфейсами. Більшість реалізацій мережі кластера Kubernetes змінить це налаштування (якщо це потрібно), але деякі можуть очікувати, що адміністратор зробить це за них. (Деякі також можуть очікувати встановлення інших параметрів sysctl, завантаження модулів ядра тощо; перевірте документацію для вашої конкретної мережної реалізації.)

Увімкнення маршрутизації IPv4 пакетів

Для увімкнення вручну маршрутизації IPv4 пакетів:

# параметри sysctl, необхідні для налаштування, параметри зберігаються після перезавантаження
cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.ipv4.ip_forward = 1
EOF

# Застосувати параметри sysctl без перезавантаження
sudo sysctl --system

Перевірте, що net.ipv4.ip_forward встановлено на 1 за допомогою:

sysctl net.ipv4.ip_forward

Драйвери cgroup

У Linux використовуються control groups для обмеження ресурсів, які виділяються процесам.

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

Існують два доступні драйвери cgroup:

Драйвер cgroupfs

Драйвер cgroupfs є стандартним драйвером cgroup в kubelet. Коли використовується драйвер cgroupfs, kubelet та середовище виконання контейнерів безпосередньо взаємодіють з файловою системою cgroup для їх налаштування.

Драйвер cgroupfs не рекомендується використовувати, коли systemd є системою ініціалізації, оскільки systemd очікує наявності єдиного менеджера cgroup в системі. Крім того, якщо використовуєте cgroup v2, використовуйте драйвер systemd cgroup замість cgroupfs.

Драйвер cgroup системи systemd

Коли systemd вибрано як систему ініціалізації в дистрибутиві Linux, процес ініціалізації створює і використовує кореневу групу cgroup (cgroup) та діє як менеджер cgroup.

systemd тісно інтегрований з cgroup та розміщує по одній cgroup на кожному юніті systemd. В результаті, якщо ви використовуєте systemd як систему ініціалізації з драйвером cgroupfs, система отримує два різних менеджери cgroup.

Наявність двох менеджерів cgroup призводить до двох видів доступних та використаних ресурсів в системі. У деяких випадках вузли, які налаштовані на використання cgroupfs для kubelet та середовище виконання контейнерів, але використовують systemd для інших процесів, стають нестійкими при зростанні тиску на ресурси.

Підхід до помʼякшення цієї нестійкості — використовувати systemd як драйвер cgroup для kubelet та середовище виконання контейнерів, коли systemd вибрано системою ініціалізації.

Щоб встановити systemd як драйвер cgroup, відредагуйте в KubeletConfiguration опцію cgroupDriver та встановіть її в systemd. Наприклад:

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
...
cgroupDriver: systemd

Якщо ви конфігуруєте systemd як драйвер cgroup для kubelet, вам також слід налаштувати systemd як драйвер cgroup для середовища виконання контейнерів. Дивіться документацію для вашого середовища виконання контейнерів для отримання докладних інструкцій. Наприклад:

У Kubernetes 1.31, з увімкненою функціональною можливістю KubeletCgroupDriverFromCRI і середовищем виконання контейнерів, яке підтримує RuntimeConfig CRI RPC, kubelet автоматично визначає відповідний драйвер cgroup з runtime, та ігнорує налаштування cgroupDriver у конфігурації kubelet.

Міграція на драйвер systemd в кластерах, що керуються kubeadm

Якщо ви хочете мігрувати на драйвер systemd cgroup в кластерах, що керуються kubeadm, дотримуйтеся рекомендацій налаштування драйвера cgroup.

Підтримка версій CRI

Ваше середовище виконання контейнерів повинне підтримувати принаймні версію v1alpha2 інтерфейсу контейнера.

Kubernetes починаючи з v1.26 працює тільки з v1 CRI API. Попередні версії типово використовують версію v1, проте, якщо середовище виконання контейнерів не підтримує v1 API, kubelet перемкнеться на використання (застарілої) версії API v1alpha2.

Середовища виконання контейнерів

containerd

У цьому розділі описані необхідні кроки для використання containerd як середовища виконання контейнерів (CRI).

Щоб встановити containerd на вашу систему, дотримуйтеся інструкцій з Початок роботи з containerd. Поверніться до цього кроку, якщо ви створили файл конфігурації config.toml.

Ви можете знайти цей файл тут: /etc/containerd/config.toml.

Ви можете знайти цей файл тут: C:\Program Files\containerd\config.toml.

У Linux, типовий CRI-socket для containerd — /run/containerd/containerd.sock. У Windows, типова CRI-точка доступу — npipe://./pipe/containerd-containerd.

Налаштування драйвера cgroup systemd

Щоб використовувати драйвер cgroup systemd в /etc/containerd/config.toml з runc, встановіть

[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
  ...
  [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
   

 SystemdCgroup = true

Драйвер cgroup systemd є рекомендованим, якщо ви використовуєте cgroup v2.

Після внесення змін в перезавантажте containerd.

sudo systemctl restart containerd

Використовуючи kubeadm, вручну налаштуйте cgroup драйвер для kubelet.

У Kubernetes v1.28 ви можете увімкнути alpha-функцію автоматичного виявлення драйвера cgroup. Дивіться systemd cgroup driver для отримання додаткової інформації.

Перевизначення образу пісочниці (pause)

У вашій конфігурації containerd ви можете перевизначити образ, встановивши наступну конфігурацію:

[plugins."io.containerd.grpc.v1.cri"]
  sandbox_image = "registry.k8s.io/pause:3.2"

Можливо, вам доведеться також перезапустити containerd, якщо ви оновили файл конфігурації: systemctl restart containerd.

CRI-O

У цьому розділі наведено необхідні кроки для встановлення CRI-O як середовища виконання контейнерів.

Для встановлення CRI-O слід дотримуватися Інструкцій з встановлення CRI-O.

Драйвер cgroup

CRI-O використовує стандартний драйвер cgroup, який ймовірно буде працювати добре для вас. Для перемикання на драйвер cgroupfs, відредагуйте /etc/crio/crio.conf або розмістіть конфігурацію у вигляді окремого файлу в /etc/crio/crio.conf.d/02-cgroup-manager.conf, наприклад:

[crio.runtime]
conmon_cgroup = "pod"
cgroup_manager = "cgroupfs"

Важливо відзначити змінений conmon_cgroup, який повинен бути встановлений в значення pod при використанні CRI-O з cgroupfs. Зазвичай необхідно синхронізувати конфігурацію драйвера cgroup kubelet (зазвичай встановлюється за допомогою kubeadm) та CRI-O.

У Kubernetes v1.28 можна ввімкнути автоматичне виявлення драйвера cgroup як альфа-функцію. Див. драйвер cgroup systemd докладніше.

Для CRI-O типовий сокет CRI — /var/run/crio/crio.sock.

Перевизначення образу пісочниці (pause)

У вашій конфігурації CRI-O ви можете встановити наступне значення конфігурації:

[crio.image]
pause_image="registry.k8s.io/pause:3.6"

Цей параметр конфігурації підтримує перезавантаження конфігурації в реальному часі для застосування цих змін: systemctl reload crio або відсилання сигналу SIGHUP процесу crio.

Docker Engine

  1. На кожному з ваших вузлів встановіть Docker для вашого дистрибутиву Linux; дивіться Інсталяція Docker Engine.

  2. Встановіть cri-dockerd, дотримуючись інструкцій у репозиторій з вихідним кодом.

Для cri-dockerd типовий сокет CRI — /run/cri-dockerd.sock.

Mirantis Container Runtime

Mirantis Container Runtime (MCR) є комерційно доступною реалізацією середовища виконання контейнерів, яка була раніше відома як Docker Enterprise Edition.

Ви можете використовувати Mirantis Container Runtime з Kubernetes за допомогою відкритої реалізації компонента cri-dockerd, який входить до складу MCR.

Для отримання докладнішої інформації щодо встановлення Mirantis Container Runtime дивіться посібник з розгортання MCR.

Перевірте юніт systemd із назвою cri-docker.socket, щоб дізнатися шлях до сокета CRI.

Перевизначення образу пісочниці (pause)

Адаптер cri-dockerd приймає аргумент командного рядка для зазначення образу контейнера, який слід використовувати як інфраструктурний контейнер для Podʼа («pause image»). Аргумент командного рядка, який слід використовувати — --pod-infra-container-image.

Що далі

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

2.2.2 - Встановлення Kubernetes за допомогою інструментів розгортання

Існує багато методів та інструментів для встановлення власного промислового кластера Kubernetes. Наприклад:

  • kubeadm
  • Cluster API: Підпроект Kubernetes зосереджений на наданні декларативних API та інструментарію для спрощення створення, оновлення та експлуатації кількох кластерів Kubernetes.
  • kops: автоматизований інструмент для розгортання кластера. За навчальними матеріалами, найкращими практиками, параметрами конфігурації та інформацією про спільноту звертайтесь до вебсайту kOps.
  • kubespray: набір плейбуків Ansible, інвентарю, інструментів керування та знання про загальні завдання з конфігурації OS/Kubernetes. Ви можете звертатися до спільноти на каналі Slack #kubespray.

2.2.2.1 - Запуск кластерів з kubeadm

2.2.2.1.1 - Встановлення kubeadm

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

installation guide стосується Kubernetes v1.31. Якщо ви хочете використовувати іншу версію Kubernetes, перегляньте натомість такі сторінки:

Перш ніж ви розпочнете

  • Сумісний хост на основі Linux. Проєкт Kubernetes надає загальні інструкції для дистрибутивів Linux, зокрема на базі Debian та Red Hat, а також для дистрибутивів без менеджера пакетів.
  • 2 ГБ або більше оперативної памʼяті на кожній машині (менше може залишити мало місця для ваших застосунків).
  • 2 процесори або більше для машин панелі управління.
  • Повноцінне мережеве зʼєднання між усіма машинами в кластері (публічна чи приватна мережа підходить).
  • Унікальні імена хостів, MAC-адреси та product_uuid для кожного вузла. Див. тут для отримання докладнішої інформації.
  • Відкриті певні порти на ваших машинах. Див. тут для отримання докладнішої інформації.

Перевірка унікальності MAC-адрес та product_uuid для кожного вузла

  • Ви можете отримати MAC-адресу мережевих інтерфейсів за допомогою команди ip link або ifconfig -a.
  • product_uuid можна перевірити за допомогою команди sudo cat /sys/class/dmi/id/product_uuid.

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

Перевірка мережевих адаптерів

Якщо у вас є більше одного мережевого адаптера і компоненти Kubernetes недоступні за стандартним маршрутом, ми рекомендуємо додати IP-маршрут(и), щоб адреси кластера Kubernetes відповідали конкретному адаптеру.

Перевірка необхідних портів

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

nc 127.0.0.1 6443 -v

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

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

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

  • Щоб дозволити swap, додайте failSwapOn: false до конфігурації kubelet або як аргумент командного рядка. Примітка: навіть якщо вказано failSwapOn: false, робочі навантаження не матимуть стандартно доступу до swap. Це можна змінити, встановивши параметр swapBehavior, знову ж таки в конфігураційному файлі kubelet. Для використання swap, встановіть значення swapBehavior інше ніж стандартне налаштування NoSwap. Докладніше дивіться у розділі Управління памʼяттю swap.
  • Щоб вимкнути swap, можна використовувати команду sudo swapoff -a для тимчасового відключення swap. Щоб зробити цю зміну постійною після перезавантаження, переконайтеся, що swap вимкнено у конфігураційних файлах, таких як /etc/fstab, systemd.swap, залежно від того, як це налаштовано у вашій системі.

Встановлення середовища виконання контейнерів

Для запуску контейнерів у Pod, Kubernetes використовує середовище виконання контейнерів.

Стандартно Kubernetes використовує Container Runtime Interface (CRI), щоб взаємодіяти з обраним середовищем.

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

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

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

Наведені нижче таблиці містять відомі точки доступу для підтримуваних операційних систем:

Linux container runtimes
Середовище виконанняШлях до Unix socket
containerdunix:///var/run/containerd/containerd.sock
CRI-Ounix:///var/run/crio/crio.sock
Docker Engine (з cri-dockerd)unix:///var/run/cri-dockerd.sock

Windows container runtimes
Середовище виконанняШлях до іменованого pipe Windows
containerdnpipe:////./pipe/containerd-containerd
Docker Engine (з cri-dockerd)npipe:////./pipe/cri-dockerd

Встановлення kubeadm, kubelet та kubectl

Ви повинні встановити ці пакунки на всіх своїх машинах:

  • kubeadm: команда для ініціалізації кластера.

  • kubelet: компонент, який працює на всіх машинах у вашому кластері та виконує такі дії, як запуск підсистем та контейнерів.

  • kubectl: утиліта командного рядка для взаємодії з вашим кластером.

kubeadm не буде встановлювати або керувати kubelet або kubectl за вас, тому вам потрібно забезпечити відповідність їх версії панелі управління Kubernetes, яку ви хочете, щоб kubeadm встановив для вас. Якщо цього не зробити, існує ризик змішування версій, що може призвести до непередбачуваної та неправильної роботи. Однак одина невелика розбіжність між kubelet та панеллю управління підтримується, але версія kubelet ніколи не повинна перевищувати версію API сервера. Наприклад, kubelet версії 1.7.0 буде повністю сумісний з API-сервером версії 1.8.0, але не навпаки.

Щодо інформації про встановлення kubectl, див. Встановлення та налаштування kubectl.

Докладніше про відмінності версій:

Ці інструкції для Kubernetes v1.31.

  1. Оновіть індекс пакунків apt та встановіть пакунки, необхідні для використання репозитарію Kubernetes apt:

    sudo apt-get update
    # apt-transport-https може бути фіктивним пакунком; якщо це так, ви можете пропустити цей крок
    sudo apt-get install -y apt-transport-https ca-certificates curl gpg
    
  2. Завантажте публічний ключ підпису для репозиторіїв пакунків Kubernetes. Той самий ключ підпису використовується для всіх репозитаріїв, тому ви можете ігнорувати версію в URL:

    # Якщо каталог `/etc/apt/keyrings` не існує, його слід створити до команди curl, прочитайте нижче наведене примітку.
    # sudo mkdir -p -m 755 /etc/apt/keyrings
    curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.31/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg
    
  1. Додайте відповідний репозиторій Kubernetes apt. Зверніть увагу, що цей репозиторій містить пакунки лише для Kubernetes 1.31; для інших мінорних версій Kubernetes вам потрібно змінити мінорну версію Kubernetes в URL так, щоб вона відповідала вашій бажаній мінорній версії (також перевірте, чи ви ознайомились з документацією для версії Kubernetes, яку ви плануєте встановити).

    # Це перезаписує будь-яку наявну конфігурацію в /etc/apt/sources.list.d/kubernetes.list
    echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.31/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list
    
  2. Оновіть індекс пакунків apt, встановіть kubelet, kubeadm та kubectl, та зафіксуйте їх версію:

    sudo apt-get update
    sudo apt-get install -y kubelet kubeadm kubectl
    sudo apt-mark hold kubelet kubeadm kubectl
    
  3. (Опціонально) Увімкніть kublet перед запуском kubeadm:

    sudo systemctl enable --now kubelet
    

  1. Встановіть SELinux у режим permissive:

    Ці інструкції для Kubernetes 1.31.

    # Встановити SELinux у режим `permissive` (фактично відключити його)
    sudo setenforce 0
    sudo sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config
    
  1. Додайте репозиторій Kubernetes yum. Параметр exclude в визначенні репозиторію забезпечує, що пакунки, повʼязані з Kubernetes, не оновлюються при виконанні yum update, оскільки є спеціальна процедура, якої слід дотримуватися для оновлення Kubernetes. Зверніть увагу, що цей репозиторій має пакунки лише для Kubernetes v1.31; для інших мінорних версій Kubernetes вам потрібно змінити мінорну версію Kubernetes в URL так, щоб вона відповідала вашій бажаній мінорній версії (також перевірте, чи ви ознайомились з документацією для версії Kubernetes, яку ви плануєте встановити).

    # Це перезаписує будь-яку існуючу конфігурацію в /etc/yum.repos.d/kubernetes.repo
    cat <<EOF | sudo tee /etc/yum.repos.d/kubernetes.repo
    [kubernetes]
    name=Kubernetes
    baseurl=https://pkgs.k8s.io/core:/stable:/v1.31/rpm/
       enabled=1
       gpgcheck=1
       gpgkey=<https://pkgs.k8s.io/core:/stable:/v1.31/rpm/repodata/repomd.xml.key
       exclude=kubelet kubeadm kubectl cri-tools kubernetes-cni
       EOF
    
  2. Встановіть kubelet, kubeadm та kubectl, та активуйте kubelet:

    sudo yum install -y kubelet kubeadm kubectl --disableexcludes=kubernetes
    
  3. (Опціонально) Увімкніть kubelet перед запуском kubeadm:

    sudo systemctl enable --now kubelet
    

Встановіть втулки CNI (необхідно для більшості мережевих підсистем):

CNI_PLUGINS_VERSION="v1.3.0"
ARCH="amd64"
DEST="/opt/cni/bin"
sudo mkdir -p "$DEST"
curl -L "https://github.com/containernetworking/plugins/releases/download/${CNI_PLUGINS_VERSION}/cni-plugins-linux-${ARCH}-${CNI_PLUGINS_VERSION}.tgz" | sudo tar -C "$DEST" -xz

Визначте теку для завантаження файлів команд:

DOWNLOAD_DIR="/usr/local/bin"
sudo mkdir -p "$DOWNLOAD_DIR"

Встановіть crictl (необхідно для взаємодії з Container Runtime Interface (CRI), необовʼязково для kubeadm):

CRICTL_VERSION="v1.31.0"
ARCH="amd64"
curl -L "https://github.com/kubernetes-sigs/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-${ARCH}.tar.gz" | sudo tar -C $DOWNLOAD_DIR -xz

Встановіть kubeadm, kubelet та додайте службу kubelet systemd:

RELEASE="$(curl -sSL https://dl.k8s.io/release/stable.txt)"
ARCH="amd64"
cd $DOWNLOAD_DIR
sudo curl -L --remote-name-all https://dl.k8s.io/release/${RELEASE}/bin/linux/${ARCH}/{kubeadm,kubelet}
sudo chmod +x {kubeadm,kubelet}

RELEASE_VERSION="v0.16.2"
curl -sSL "https://raw.githubusercontent.com/kubernetes/release/${RELEASE_VERSION}/cmd/krel/templates/latest/kubelet/kubelet.service" | sed "s:/usr/bin:${DOWNLOAD_DIR}:g" | sudo tee /usr/lib/systemd/system/kubelet.service
sudo mkdir -p /usr/lib/systemd/system/kubelet.service.d
curl -sSL "https://raw.githubusercontent.com/kubernetes/release/${RELEASE_VERSION}/cmd/krel/templates/latest/kubeadm/10-kubeadm.conf" | sed "s:/usr/bin:${DOWNLOAD_DIR}:g" | sudo tee /usr/lib/systemd/system/kubelet.service.d/10-kubeadm.conf

Встановіть kubectl, відповідно до інструкцій на сторінці Встановлення інструментів.

Опціонально, увімкніть службу kubelet перед запуском kubeadm:

sudo systemctl enable --now kubelet

Kubelet тепер перезавантажується кожні кілька секунд, чекаючи в циклі crashloop на вказівки від kubeadm.

Налаштування драйвера cgroup

Як середовище виконання контейнерів, так і kubelet мають властивість, відому як "cgroup driver", яка є важливою для управління cgroup на машинах з операційною системою Linux.

Розвʼязання проблем

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

Що далі

2.2.2.1.2 - Розвʼязання проблем kubeadm

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

Якщо вашої проблеми немає в переліку нижче, будь ласка, скористайтесь настпуним:

  • Ви вважаєте, що це помилка в kubeadm:

  • Ви не впевнені, що це проблема в роботі kubeadm, ви можете запитати в Slack в каналі #kubeadm, або поставити питання на Stack Overflow. Будь ласка, додайте теґи #kubeadm та #kubernetes.

Неможливо приєднати вузол v1.18 до кластера v1.17 через відсутність RBAC

У версії v1.18 kubeadm додав запобігання приєднання вузла до кластера, якщо вузол з таким самим імʼям вже існує. Це вимагало додавання RBAC для користувача bootstrap-token для можливості виконання операції GET обʼєкта Node.

Однак це викликає проблему, коли kubeadm join з v1.18 не може приєднатися до кластера, створеного за допомогою kubeadm v1.17.

Для того, щоб оминути цю проблему у вас є два варіанти:

Виконайте kubeadm init phase bootstrap-token на вузлі панелі управління за допомогою kubeadm v1.18. Зауважте, що це дозволяє інші дозволи bootstrap-token.

або

Застосуйте наступний RBAC вручну за допомогою kubectl apply -f ...:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: kubeadm:get-nodes
rules:
  - apiGroups:
      - ""
    resources:
      - nodes
    verbs:
      - get
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: kubeadm:get-nodes
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: kubeadm:get-nodes
subjects:
  - apiGroup: rbac.authorization.k8s.io
    kind: Group
    name: system:bootstrappers:kubeadm:default-node-token

ebtables або подібний виконавчий файл не знайдений під час встановлення

Якщо ви бачите наступні попередження під час виконання kubeadm init:

[preflight] WARNING: ebtables not found in system path
[preflight] WARNING: ethtool not found in system path

Тоді вам може бракувати ebtables, ethtool або подібного виконавчого файлу на вашому вузлі. Ви можете встановити їх за допомогою наступних команд:

  • Для користувачів Ubuntu/Debian виконайте apt install ebtables ethtool.
  • Для користувачів CentOS/Fedora виконайте yum install ebtables ethtool.

kubeadm блокується під час очікування на панель управління під час встановлення

Якщо ви помічаєте, що kubeadm init зупиняється після виведення наступного рядка:

[apiclient] Created API client, waiting for the control plane to become ready

Це може бути спричинено кількома проблемами. Найбільш поширеними є:

  • проблеми з мережевим підключенням. Перш ніж продовжувати, перевірте, чи ваша машина має повне підключення до мережі.
  • драйвер cgroup контейнера відрізняється від драйвера kubelet cgroup. Щоб зрозуміти, як правильно налаштувати це, див. Налаштування драйвера cgroup.
  • контейнери панелі управління впадають в цикл або зупиняються. Ви можете перевірити це, використовуючи docker ps та вивчаючи кожен контейнер за допомогою docker logs. Для інших середовищ виконання контейнерів, див. Налагодження вузлів Kubernetes за допомогою crictl.

kubeadm блокується під час видалення керованих контейнерів

Наступне може трапитися, якщо середовище виконання контейнерів зупиняється і не видаляє жодних керованих контейнерів Kubernetes:

sudo kubeadm reset
[preflight] Running pre-flight checks
[reset] Stopping the kubelet service
[reset] Unmounting mounted directories in "/var/lib/kubelet"
[reset] Removing kubernetes-managed containers
(block)

Можливий варіант вирішення — перезапустити середовище виконання контейнерів, а потім знову запустити kubeadm reset. Ви також можете використовувати crictl для налагодження стану середовища виконання контейнерів. Див. Налагодження вузлів Kubernetes за допомогою crictl.

Podʼи у стані RunContainerError, CrashLoopBackOff або Error

Відразу після виконання kubeadm init не повинно бути жодних контейнерів у таких станах.

  • Якщо є контейнери в одному з цих станів відразу після kubeadm init, будь ласка, створіть тікет в репозиторії kubeadm. coredns (або kube-dns) повинен перебувати у стані Pending до моменту розгортання додатка для мережі.
  • Якщо ви бачите контейнери у стані RunContainerError, CrashLoopBackOff або Error після розгортання додатка для мережі та нічого не відбувається з coredns (або kube-dns), дуже ймовірно, що додаток Pod Network, який ви встановили, є пошкодженим. Можливо, вам потрібно надати йому більше привілеїв RBAC або використовувати новішу версію. Будь ласка, створіть тікет в системі відстеження проблем постачальника Pod Network та очікуйте розвʼязання проблеми там.

coredns застрягає у стані Pending

Це очікувано і є частиною дизайну. kubeadm є агностичним до мережі, тому адміністратор повинен встановити вибраний додаток для мережі за власним вибором. Вам потрібно встановити Pod Network, перш ніж coredns може бути повністю розгорнутим. Таким чином, стан Pending перед налаштуванням мережі є нормальним.

Сервіси HostPort не працюють

Функціональність HostPort та HostIP доступна залежно від вашого провайдера Pod Network. Будь ласка, звʼяжіться з автором додатка Pod Network, щоб дізнатися, чи функціональність HostPort та HostIP доступна.

Перевірено, що Calico, Canal та Flannel CNI підтримують HostPort.

Для отримання додаткової інформації перегляньте документацію CNI portmap.

Якщо ваш постачальник мережі не підтримує втулок CNI portmap, можливо, вам доведеться використовувати функцію NodePort для сервісів або використовуйте HostNetwork=true.

До Podʼів неможливо отримати доступ за їх Service IP

  • Багато додатків для мережі ще не увімкнули режим hairpin, який дозволяє Podʼам звертатися до себе за їх Service IP. Це повʼязано з CNI. Будь ласка, звʼяжіться з постачальником додатка для мережі, щоб дізнатися про останній статус підтримки режиму hairpin.

  • Якщо ви використовуєте VirtualBox (безпосередньо, або через Vagrant), вам слід переконатися, що hostname -i повертає маршрутизовану IP-адресу. Типово перший інтерфейс підключений до немаршрутизованої мережі тільки для хосту. Як тимчасовий варіант, ви можете змінити /etc/hosts, подивіться цей Vagrantfile для прикладу.

Помилки сертифіката TLS

Наступна помилка вказує на можливу несумісність сертифікатів.

# kubectl get pods
Unable to connect to the server: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "kubernetes")
  • Перевірте, що файл $HOME/.kube/config містить дійсний сертифікат, та перегенеруйте сертифікат за необхідності. Сертифікати у файлі конфігурації kubeconfig закодовані у форматі base64. Команда base64 --decode може бути використана для декодування сертифіката, а openssl x509 -text -noout може бути використано для перегляду інформації про сертифікат.

  • Скасуйте змінну середовища KUBECONFIG за допомогою:

    unset KUBECONFIG
    

    Або встановіть його в типове розташування KUBECONFIG:

    export KUBECONFIG=/etc/kubernetes/admin.conf
    
  • Іншим обхідним методом є перезапис наявного kubeconfig для користувача "admin":

    mv $HOME/.kube $HOME/.kube.bak
    mkdir $HOME/.kube
    sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
    sudo chown $(id -u):$(id -g) $HOME/.kube/config
    

Помилка ротації сертифіката клієнта Kubelet

Стандартно kubeadm налаштовує kubelet на автоматичну ротацію сертифікатів клієнта за допомогою символічного посилання /var/lib/kubelet/pki/kubelet-client-current.pem, вказаного в /etc/kubernetes/kubelet.conf. Якщо цей процес ротації завершиться невдачею, ви можете побачити помилки, такі як x509: certificate has expired or is not yet valid в журналах kube-apiserver. Щоб виправити цю проблему, слід виконати наступні кроки:

  1. Зробіть резервну копію та видаліть файли /etc/kubernetes/kubelet.conf та /var/lib/kubelet/pki/kubelet-client* з несправного вузла.

  2. З робочого вузла контрольної площини кластера, де є /etc/kubernetes/pki/ca.key, виконайте kubeadm kubeconfig user --org system:nodes --client-name system:node:$NODE > kubelet.conf. $NODE повинно бути встановлено на імʼя наявного несправного вузла в кластері. Вручну змініть отриманий kubelet.conf, щоб відкоригувати імʼя та endpoint сервера, або передайте kubeconfig user --config (див. see Створення файлів kubeconfig для додаткових користувачів). Якщо в у вашому кластері немає ca.key, ви повинні вручну підписати вбудовані сертифікати в kubelet.conf.

  3. Скопіюйте цей отриманий kubelet.conf в /etc/kubernetes/kubelet.conf на несправному вузлі.

  4. Перезапустіть kubelet (systemctl restart kubelet) на несправному вузлі та зачекайте, доки /var/lib/kubelet/pki/kubelet-client-current.pem буде відновлено.

  5. Вручну відредагуйте kubelet.conf, щоб вказати на обертані сертифікати клієнта kubelet, замінивши client-certificate-data та client-key-data на:

    client-certificate: /var/lib/kubelet/pki/kubelet-client-current.pem
    client-key: /var/lib/kubelet/pki/kubelet-client-current.pem
    
  6. Перезапустіть kubelet.

  7. Переконайтеся, що вузол стає Ready.

Типовий мережевий інтерфейс NIC при використанні Flannel як мережі для Podʼів у Vagrant

Наступна помилка може свідчити про те, що щось пішло не так у мережі Podʼів:

Error from server (NotFound): the server could not find the requested resource
  • Якщо ви використовуєте Flannel як мережу для Podʼів у Vagrant, тоді вам доведеться вказати типове імʼя інтерфейсу для Flannel.

    Зазвичай Vagrant призначає два інтерфейси всім віртуальним машинам. Перший, для якого всі хости мають IP-адресу 10.0.2.15, призначено для зовнішнього трафіку, який проходить через NAT.

    Це може призвести до проблем із Flannel, яка стандартно він обирає перший інтерфейс на хості. Це призводить до того, що всі хости вважають, що у них однакова публічна IP-адреса. Щоб цього уникнути, передайте прапорець --iface eth1 для Flannel, щоб обрати другий інтерфейс.

Непублічні IP-адреси для контейнерів

У деяких ситуаціях команди kubectl logs та kubectl run можуть повертати помилки на функціональному кластері:

Error from server: Get https://10.19.0.41:10250/containerLogs/default/mysql-ddc65b868-glc5m/mysql: dial tcp 10.19.0.41:10250: getsockopt: no route to host
  • Це може бути викликано використанням Kubernetes IP-адреси, яка не може взаємодіяти з іншими IP-адресами на одній підмережі, можливо, через політику провайдера машин.

  • DigitalOcean призначає публічний IP для eth0, а також приватний IP для внутрішнього використання як анкера для їхньої функції змінного IP. Однак, kubelet вибере останній як InternalIP вузла замість першого.

    Використовуйте ip addr show для перевірки цього сценарію, а не ifconfig, оскільки ifconfig не показує обрану адресу IP для аліаса. Альтернативно, API-точка, специфічна для DigitalOcean, дозволяє запитувати анкер IP-адресу з машини:

    curl http://169.254.169.254/metadata/v1/interfaces/public/0/anchor_ipv4/address
    

    Обхідним рішенням є повідомлення kubelet, яку IP використовувати за допомогою --node-ip. Коли використовується DigitalOcean, це може бути публічний IP (призначений eth0) або приватний IP (призначений eth1), якщо ви хочете використовувати додаткову приватну мережу. Розділ kubeletExtraArgs структури kubeadm NodeRegistrationOptions може бути використаний для цього.

    Потім перезапустіть kubelet:

    systemctl daemon-reload
    systemctl restart kubelet
    

Podʼи coredns перебувають у стані CrashLoopBackOff або Error

Якщо у вас є вузли, які працюють із SELinux та старішою версією Docker, ви можете стикнутися зі сценарієм, де Podʼи coredns не запускаються. Щоб вирішити це, ви можете спробувати один з наступних варіантів:

kubectl -n kube-system get deployment coredns -o yaml | \
  sed 's/allowPrivilegeEscalation: false/allowPrivilegeEscalation: true/g' | \
  kubectl apply -f -

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

Podʼі etcd постійно перезапускаються

Якщо ви стикаєтеся з такою помилкою:

rpc error: code = 2 desc = oci runtime error: exec failed: container_linux.go:247: starting container process caused "process_linux.go:110: decoding init error from pipe caused \"read parent: connection reset by peer\""

Ця проблема виникає, якщо ви використовуєте CentOS 7 з Docker 1.13.1.84. Ця версія Docker може завадити kubelet виконуватися в контейнері etcd.

Для усунення цієї проблеми виберіть один з наступних варіантів:

  • Поверніться до попередньої версії Docker, наприклад, 1.13.1-75

    yum downgrade docker-1.13.1-75.git8633870.el7.centos.x86_64 docker-client-1.13.1-75.git8633870.el7.centos.x86_64 docker-common-1.13.1-75.git8633870.el7.centos.x86_64
    
  • Встановіть одну з новіших рекомендованих версій, наприклад 18.06:

    sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
    yum install docker-ce-18.06.1.ce-3.el7.x86_64
    

Неможливо передати розділений комою список значень аргументів під прапорцем --component-extra-args

Прапорці kubeadm init, такі як --component-extra-args, дозволяють передавати власні аргументи компоненту панелі управління, наприклад, kube-apiserver. Однак цей механізм обмежений через тип, який використовується для розбору значень (mapStringString).

Якщо ви вирішите передати аргумент, який підтримує кілька значень, розділених комами, такий як --apiserver-extra-args "enable-admission-plugins=LimitRanger,NamespaceExists", цей прапорець видасть помилку flag: malformed pair, expect string=string. Це відбувається через те, що список аргументів для --apiserver-extra-args очікує пари key=value, і в цьому випадку NamespacesExists розглядається як ключ, якому не вистачає значення.

У іншому випадку ви можете спробувати розділити пари key=value так: --apiserver-extra-args "enable-admission-plugins=LimitRanger,enable-admission-plugins=NamespaceExists", але це призведе до того, що ключ enable-admission-plugins матиме лише значення NamespaceExists.

Відомий обхід цього — використання файлу конфігурації kubeadm.

kube-proxy плануєтья до того, як вузол ініціалізовано cloud-controller-manager

У сценаріях хмарних провайдерів kube-proxy може виявитися запланованим на нових робочих вузлах до того, як cloud-controller-manager ініціалізує адреси вузла. Це призводить до того, що kube-proxy не може належним чином отримати IP-адресу вузла, і це має негативний вплив на функцію проксі, що керує балансуванням навантаження.

У kube-proxy Pods можна побачити наступну помилку:

server.go:610] Failed to retrieve node IP: host IP unknown; known addresses: []
proxier.go:340] invalid nodeIP, initializing kube-proxy with 127.0.0.1 as nodeIP

Відомий варіант рішення — виправлення DaemonSet kube-proxy, щоб дозволити його планування на вузлах панелі управління незалежно від їхніх умов, утримуючи його подальше від інших вузлів, доки їхні початкові умови зберігаються:

kubectl -n kube-system patch ds kube-proxy -p='{
  "spec": {
    "template": {
      "spec": {
        "tolerations": [
          {
            "key": "CriticalAddonsOnly",
            "operator": "Exists"
          },
          {
            "effect": "NoSchedule",
            "key": "node-role.kubernetes.io/control-plane"
          }
        ]
      }
    }
  }
}'

Тікет, що відстежує цю проблему, розташовано тут.

/usr монтується тільки для читання на вузлах

У дистрибутивах Linux, таких як Fedora CoreOS або Flatcar Container Linux, тека /usr монтується як файлова система тільки для читання. Для підтримки flex-volume компоненти Kubernetes, такі як kubelet і kube-controller-manager, використовують типовий шлях /usr/libexec/kubernetes/kubelet-plugins/volume/exec/, проте тека flex-volume має бути доступною для запису, щоб ця функція працювала.

Для усунення цієї проблеми ви можете налаштувати теку flex-volume, використовуючи файл конфігурації kubeadm.

На основному вузлі панелі управління (створеному за допомогою kubeadm init) передайте наступний файл, використовуючи параметр --config:

apiVersion: kubeadm.k8s.io/v1beta4
kind: InitConfiguration
nodeRegistration:
  kubeletExtraArgs:
  - name: "volume-plugin-dir"
    value: "/opt/libexec/kubernetes/kubelet-plugins/volume/exec/"
---
apiVersion: kubeadm.k8s.io/v1beta4
kind: ClusterConfiguration
controllerManager:
  extraArgs:
  - name: "flex-volume-plugin-dir"
    value: "/opt/libexec/kubernetes/kubelet-plugins/volume/exec/"

При долученні вузлів:

apiVersion: kubeadm.k8s.io/v1beta4
kind: JoinConfiguration
nodeRegistration:
  kubeletExtraArgs:
  - name: "volume-plugin-dir"
    value: "/opt/libexec/kubernetes/kubelet-plugins/volume/exec/"

Альтернативно ви можете змінити файл /etc/fstab, щоб зробити монтування /usr доступним для запису, проте будьте обізнані, що це змінює принцип дизайну дистрибутиву Linux.

kubeadm upgrade plan виводить повідомлення про помилку context deadline exceeded

Це повідомлення про помилку виводиться при оновленні кластера Kubernetes за допомогою kubeadm у випадку використання зовнішнього etcd. Це не критична помилка і виникає через те, що старі версії kubeadm виконують перевірку версії зовнішнього кластера etcd. Ви можете продовжити з kubeadm upgrade apply ....

Цю проблему виправлено у версії 1.19.

kubeadm reset відмонтовує /var/lib/kubelet

Якщо /var/lib/kubelet має точку монтування, виконання kubeadm reset фактично відмонтує його.

Для уникнення цієї проблеми повторно замонтуйте каталог /var/lib/kubelet після виконання операції kubeadm reset.

Це вдосконалення було введено в kubeadm 1.15. Проблема виправлена в 1.20.

Неможливо безпечно використовувати metrics-server в кластері kubeadm

У кластері kubeadm metrics-server може бути використаний в небезпечний спосіб, передаючи йому параметр --kubelet-insecure-tls. Це не рекомендується для промислових кластерів.

Якщо ви хочете використовувати TLS між metrics-server та kubelet, виникає проблема, оскільки kubeadm розгортає самопідписний службовий сертифікат для kubelet. Це може призвести до наступних помилок з боку metrics-server:

x509: certificate signed by unknown authority
x509: certificate is valid for IP-foo not IP-bar

Дивіться Увімкнення підписаних службових сертифікатів kubelet, щоб зрозуміти, як налаштувати kubelet в кластері kubeadm для отримання належно підписаних службових сертифікатів.

Також перегляньте Як запустити metrics-server безпечно.

Оновлення не вдається через незмінність хешу etcd

Це стосується лише оновлення вузла панелі управління за допомогою бінарного файлу kubeadm v1.28.3 або пізніше, при умові, що вузол в цей час керується версіями kubeadm v1.28.0, v1.28.1 або v1.28.2.

Ось повідомлення про помилку, яке може виникнути:

[upgrade/etcd] Failed to upgrade etcd: couldn't upgrade control plane. kubeadm has tried to recover everything into the earlier state. Errors faced: static Pod hash for component etcd on Node kinder-upgrade-control-plane-1 did not change after 5m0s: timed out waiting for the condition
[upgrade/etcd] Waiting for previous etcd to become available
I0907 10:10:09.109104    3704 etcd.go:588] [etcd] attempting to see if all cluster endpoints ([https://172.17.0.6:2379/ https://172.17.0.4:2379/ https://172.17.0.3:2379/]) are available 1/10
[upgrade/etcd] Etcd was rolled back and is now available
static Pod hash for component etcd on Node kinder-upgrade-control-plane-1 did not change after 5m0s: timed out waiting for the condition
couldn't upgrade control plane. kubeadm has tried to recover everything into the earlier state. Errors faced
k8s.io/kubernetes/cmd/kubeadm/app/phases/upgrade.rollbackOldManifests
	cmd/kubeadm/app/phases/upgrade/staticpods.go:525
k8s.io/kubernetes/cmd/kubeadm/app/phases/upgrade.upgradeComponent
	cmd/kubeadm/app/phases/upgrade/staticpods.go:254
k8s.io/kubernetes/cmd/kubeadm/app/phases/upgrade.performEtcdStaticPodUpgrade
	cmd/kubeadm/app/phases/upgrade/staticpods.go:338
...

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

Є два способи обійти цю проблему, якщо ви бачите її у своєму кластері:

  • Оновлення etcd може бути пропущено між пошкодженими версіями та v1.28.3 (або пізніше) за допомогою:

    kubeadm upgrade {apply|node} [version] --etcd-upgrade=false
    

    Це не рекомендується у випадку, якщо пізніше патч-версії v1.28 вводять нову версію etcd.

  • Перед оновленням виправте маніфест для статичного Pod etcd, щоб видалити стандартні проблемні атрибути:

    diff --git a/etc/kubernetes/manifests/etcd_defaults.yaml b/etc/kubernetes/manifests/etcd_origin.yaml
    index d807ccbe0aa..46b35f00e15 100644
    --- a/etc/kubernetes/manifests/etcd_defaults.yaml
    +++ b/etc/kubernetes/manifests/etcd_origin.yaml
    @@ -43,7 +43,6 @@ spec:
           scheme: HTTP
         initialDelaySeconds: 10
         periodSeconds: 10
    -      successThreshold: 1
         timeoutSeconds: 15
       name: etcd
       resources:
    @@ -59,26 +58,18 @@ spec:
           scheme: HTTP
         initialDelaySeconds: 10
         periodSeconds: 10
    -      successThreshold: 1
         timeoutSeconds: 15
    -    terminationMessagePath: /dev/termination-log
    -    terminationMessagePolicy: File
       volumeMounts:
       - mountPath: /var/lib/etcd
         name: etcd-data
       - mountPath: /etc/kubernetes/pki/etcd
         name: etcd-certs
    -  dnsPolicy: ClusterFirst
    -  enableServiceLinks: true
     hostNetwork: true
     priority: 2000001000
     priorityClassName: system-node-critical
    -  restartPolicy: Always
    -  schedulerName: default-scheduler
     securityContext:
       seccompProfile:
         type: RuntimeDefault
    -  terminationGracePeriodSeconds: 30
     volumes:
     - hostPath:
         path: /etc/kubernetes/pki/etcd
    

Більше інформації можна знайти в тікеті для цієї помилки.

2.2.2.1.3 - Створення кластера за допомогою kubeadm

За допомогою kubeadm ви можете створити мінімальний кластер Kubernetes, який відповідає найкращим практикам. Фактично, ви можете використовувати kubeadm для налаштування кластерf, який успішно пройде тести відповідності Kubernetes. kubeadm також підтримує інші функції життєвого циклу кластера, такі як bootstrap-токени nf оновлення кластера.

Інструмент kubeadm корисний у випадках, коли вам потрібен:

  • Простий спосіб спробувати Kubernetes, можливо, вперше.
  • Спосіб для поточних користувачів автоматизувати налаштування кластера та протестувати свій застосунок.
  • Компонент в інших екосистемах та/або інсталяторах із більшим функціоналом.

Ви можете встановлювати та використовувати kubeadm на різних машинах: на вашому ноутбуці, хмарних серверах, Raspberry Pi та інших. Незалежно від того, чи ви розгортаєте у хмарі, чи на власних серверах, ви можете інтегрувати kubeadm у системи постачання, такі як Ansible або Terraform.

Перш ніж ви розпочнете

Для виконання цього керівництва вам потрібно мати:

  • Одну чи кілька машин з операційною системою, сумісною з deb/rpm, наприклад: Ubuntu чи CentOS.
  • 2 ГБ або більше оперативної памʼяті на кожній машині — менше може призвести до обмежень для вашого застосунку.
  • Принаймні 2 процесори на машині, яку ви використовуєте як вузол панелі управління.
  • Повну мережеву доступність між усіма машинами в кластері. Ви можете використовувати як публічні, так і приватні мережі.

Також вам потрібно використовувати версію kubeadm, яка може розгортати ту версію Kubernetes, яку ви хочете використовувати у своєму новому кластері.

Політика підтримки версій та їх розбіжностей в Kubernetes розповсюджується на kubeadm так само як і на Kubernetes в цілому. Перевірте цю політику, щоб дізнатися, які версії Kubernetes та kubeadm підтримуються. Ця сторінка написана для Kubernetes v1.31.

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

Мета

  • Встановити Kubernetes з одною панеллю управління
  • Встановити мережу для Podʼів в кластері, так щоб вони могли спілкуватися один з одним

Інструкції

Підготовка хостів

Встановлення компонентів

Встановіть середовище виконання контейнерів та kubeadm на всіх хостах. За докладними інструкціями та іншими вимогами звертайтесь до Встановлення kubeadm.

Налаштування мережі

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

Щоб дізнатися, яка це IP-адреса на Linux-хості, ви можете використовувати:

ip route show # Перегляньте рядок, який починається з "default via"

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

Для налаштування IP-адреси оголошення API-сервера для вузлів панелі управління, створених із init та join, можна використовувати прапорець --apiserver-advertise-address. Переважно, варто встановлювати цю опцію в API-інтерфейсі kubeadm як InitConfiguration.localAPIEndpoint та JoinConfiguration.controlPlane.localAPIEndpoint.

Для kubelet на всіх вузлах опцію --node-ip можна передати в .nodeRegistration.kubeletExtraArgs всередині конфігураційного файлу kubeadm (InitConfiguration або JoinConfiguration).

Для роботи з двома стеками дивіться Підтримка двох стеків із kubeadm.

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

Підготовка необхідних образів контейнерів

Цей крок є необовʼязковим і застосовується тільки у випадку, якщо ви бажаєте, щоб kubeadm init та kubeadm join не завантажували типові образи контейнерів, які розміщені на registry.k8s.io.

Kubeadm має команди, які можуть допомогти вам попередньо витягти необхідні образи при створенні кластера без Інтернет-зʼєднання на його вузлах. Дивіться Запуск kubeadm без Інтернет-зʼєднання для отримання докладнішої інформації.

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

Ініціалізація вузла панелі управління

Вузол панелі управління — це машина, де працюють компоненти панелі управління, включаючи etcd (база даних кластера) та API Server (з яким взаємодіє інструмент командного рядка kubectl).

  1. (Рекомендовано) Якщо у вас є плани оновлення цього кластера з одною панеллю управління за допомогою kubeadm до рівня високої доступності, ви повинні вказати --control-plane-endpoint, щоб встановити загальний endpoint для всіх вузлів панелі управління. Такий endpoint може бути іменем DNS або IP-адресою балансувальника навантаження.
  2. Виберіть надбудову мережі Pod та перевірте, чи для його налаштування потрібно передати будь-які аргументи в kubeadm init. Залежно від того, якого постачальника вибрано, вам може бути потрібно встановити значення --pod-network-cidr в значення, специфічне для постачальника. Дивіться Встановлення надбудови мережі Podʼів.
  3. (Необовʼязково) kubeadm намагається визначити середовище виконання контейнерів, використовуючи список відомих точок входу. Щоб використовувати інше середовище виконання контейнерів або якщо встановлено більше одного на наданому вузлі, вкажіть аргумент --cri-socket для kubeadm. Дивіться Встановлення середовища виконання.

Щоб ініціалізувати вузол панелі управління, виконайте:

kubeadm init <args>

Міркування щодо apiserver-advertise-address та ControlPlaneEndpoint

Хоча --apiserver-advertise-address може бути використано для встановлення оголошення адреси для API-сервера цього конкретного вузла панелі управління, --control-plane-endpoint може бути використано для встановлення загальної endpoint для всіх вузлів управління.

--control-plane-endpoint дозволяє використовувати як IP-адреси, так і DNS-імена, які можуть транслюватись у IP-адреси. Будь ласка, зверніться до вашого адміністратора мережі, щоб оцінити можливі рішення щодо такого перетворення.

Ось приклад:

192.168.0.102 cluster-endpoint

Де 192.168.0.102 — це IP-адреса цього вузла, а cluster-endpoint — це власне DNS-імʼя, яке повʼязується з цим IP. Це дозволить вам передавати --control-plane-endpoint=cluster-endpoint у kubeadm init і передавати те ж саме DNS-імʼя до kubeadm join. Пізніше ви можете змінити cluster-endpoint, щоб вказати адресу вашого балансувальника навантаження в сценарії високої доступності.

Перетворення кластера з одною панеллю управлінням, створеного без --control-plane-endpoint, у високодоступний кластер не підтримується kubeadm.

Додаткова інформація

Для отримання додаткової інформації щодо аргументів kubeadm init, див. посібник kubeadm.

Щоб налаштувати kubeadm init за допомогою файлу конфігурації, див. Використання kubeadm init з файлом конфігурації.

Для налаштування компонентів панелі управління, включаючи необовʼязкове призначення IPv6 для перевірки наявності для компонентів панелі управління та сервера etcd, надайте додаткові аргументи кожному компоненту, як описано на сторінці про додаткові аргументи.

Щоб переналаштувати кластер, який вже був створений, див. Переконфігурування кластера kubeadm.

Щоб знову виконати kubeadm init, спершу вам потрібно розібрати кластер.

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

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

Your Kubernetes control-plane has initialized successfully!

To start using your cluster, you need to run the following as a regular user:

  mkdir -p $HOME/.kube
  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
  sudo chown $(id -u):$(id -g) $HOME/.kube/config

You should now deploy a Pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
  /docs/concepts/cluster-administration/addons/

You can now join any number of machines by running the following on each node
as root:

  kubeadm join <control-plane-host>:<control-plane-port> --token <token> --discovery-token-ca-cert-hash sha256:<hash>

Щоб кubectl працював для вашого користувача без прав root, виконайте ці команди, які є також частиною виводу kubeadm init:

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

Або, якщо ви є користувачем root, ви можете виконати:

export KUBECONFIG=/etc/kubernetes/admin.conf

Запишіть команду kubeadm join, яку виводить kubeadm init. Вам потрібна ця команда для приєднання вузлів до вашого кластера.

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

Встановлення надбудови для мережі Pod

Кілька зовнішніх проєктів надають мережі Pod Kubernetes за допомогою CNI, деякі з яких також підтримують Network Policy.

Див. список надбудов, які реалізують Модель мережі Kubernetes.

Будь ласка, звертайтеся до сторінки Встановлення надбудов для списку мережевих надбудов (може бути неповним), які підтримуються в Kubernetes. Ви можете встановити надбудову мережі Pod за допомогою наступної команди на вузлі панелі управління або вузлі, на якому є облікові дані kubeconfig:

kubectl apply -f <add-on.yaml>

Ви можете встановити лише одну мережу Pod на кластер.

Як тільки мережу Pod буде створено, ви можете підтвердити, що вона працює, перевіривши, що Pod CoreDNS у стані Running у виводі kubectl get pods --all-namespaces. І як тільки Pod CoreDNS запущено і він працює, ви можете продовжити приєднувати ваші вузли.

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

Керовані мітки вузлів

Типово kubeadm вмикає контролер доступу NodeRestriction, що обмежує, які мітки можуть бути самостійно застосовані kubelet під час реєстрації вузла. Документація контролера доступу описує, які мітки можна використовувати з параметром kubelet --node-labels. Мітка node-role.kubernetes.io/control-plane є такою обмеженою міткою, і kubeadm вручну застосовує її, використовуючи привілейований клієнт після створення вузла. Щоб зробити це вручну, ви можете використовувати kubectl label та переконатися, що використовується привілейований kubeconfig, такий як керований kubeadm /etc/kubernetes/admin.conf.

Ізоляція вузла панелі управління

Типово у вашому кластері не буде планувати розміщення Podʼів на вузлі панелі управління з міркувань безпеки. Якщо ви хочете мати можливість планувати Podʼи на вузлах панелі управління, наприклад, для кластера Kubernetes на одній машині, виконайте команду:

kubectl taint nodes --all node-role.kubernetes.io/control-plane-

Вивід буде схожим на:

node "test-01" untainted
...

Це видалить позначку node-role.kubernetes.io/control-plane:NoSchedule з будь-яких вузлів, які мають її, включаючи вузли панелі управління, що означає, що планувальник зможе розміщувати Podʼи всюди.

Додатково ви можете виконати наступну команду, щоб видалити мітку node.kubernetes.io/exclude-from-external-load-balancers з вузла панелі управління, що виключає його зі списку бекенд-серверів:

kubectl label nodes --all node.kubernetes.io/exclude-from-external-load-balancers-

Додавання додаткових вузлів панелі управління

Дивіться Створення кластерів з високою доступністю за допомогою kubeadm для інструкцій щодо створення кластеру з високою доступністю за допомогою kubeadm шляхом додавання додаткових вузлів панелі управління.

Додавання робочих вузлів

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

Наступні сторінки показують, як додати Linux та Windows робочі вузли до кластеру за допомогою команди kubeadm join:

(Необовʼязково) Керування кластером з інших машин, крім вузла панелі управління

Щоб отримати доступ до кластера з іншого компʼютера (наприклад, з ноутбука), вам потрібно скопіювати файл kubeconfig з вузла панелі управління на ваш робочий компʼютер так:

scp root@<control-plane-host>:/etc/kubernetes/admin.conf .
kubectl --kubeconfig ./admin.conf get nodes

(Необовʼязково) Проксі-доступ до API Server на localhost

Якщо ви хочете підʼєднатися до API Server ззовні кластера, ви можете використовувати kubectl proxy:

scp root@<control-plane-host>:/etc/kubernetes/admin.conf .
kubectl --kubeconfig ./admin.conf proxy

Тепер ви можете отримати доступ до API Server локально за адресою http://localhost:8001/api/v1.

Очищення

Якщо ви використовували тимчасові сервери для свого кластера для тестування, ви можете вимкнути їх і не проводити додаткового очищення. Ви можете використовувати kubectl config delete-cluster, щоб видалити ваші локальні посилання на кластер.

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

Видалення вузла

Зверніться до вузла панелі управління використовуючи відповідний обліковий запис та виконайте:

kubectl drain <імʼя вузла> --delete-emptydir-data --force --ignore-daemonsets

Перед видаленням вузла скиньте стан, встановлений за допомогою kubeadm:

kubeadm reset

Процес скидання не відновлює або не очищає правила iptables чи таблиці IPVS. Якщо ви хочете скинути iptables, вам слід це зробити вручну:

iptables -F && iptables -t nat -F && iptables -t mangle -F && iptables -X

Якщо ви хочете скинути таблиці IPVS, вам слід виконати наступну команду:

ipvsadm -C

Тепер видаліть вузол:

kubectl delete node <імʼя вузла>

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

Очищення панелі управління

Ви можете використовувати kubeadm reset на хості панелі управління для виконання очищення.

Дивіться довідкову документацію для kubeadm reset для отримання додаткової інформації щодо цієї підкоманди та її параметрів.

Політика розбіжності версій

Хоча kubeadm дозволяє розбіжність версій для деяких компонентів, якими він керує, рекомендується вирівнювати версію kubeadm із версіями компонентів панелі управління, kube-proxy та kubelet.

Відхилення версії kubeadm від версії Kubernetes

kubeadm можна використовувати із компонентами Kubernetes, які мають таку саму версію, як і kubeadm, або на одну версію застаріше. Версію Kubernetes можна вказати для kubeadm, використовуючи прапорець --kubernetes-version команди kubeadm init або поле ClusterConfiguration.kubernetesVersion при використанні --config. Ця опція буде контролювати версії kube-apiserver, kube-controller-manager, kube-scheduler та kube-proxy.

Приклад:

  • kubeadm має версію 1.31
  • kubernetesVersion повинна бути 1.31 або 1.30

Відхилення версії kubeadm від версії kubelet

Аналогічно до версії Kubernetes, kubeadm можна використовувати з версією kubelet, яка є такою ж самою версією, що й kubeadm, або на три версії старішою.

Приклад:

  • kubeadm має версію 1.31
  • kubelet на хості повинен мати версію 1.31, 1.30, 1.29 або 1.28

Відхилення версії kubeadm від kubeadm

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

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

Приклад для kubeadm join:

  • версія kubeadm 1.31 використовувалася для створення кластера за допомогою kubeadm init
  • Приєднувані вузли повинні використовувати бінарний файл kubeadm версії 1.31

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

Приклад для kubeadm upgrade:

  • версія kubeadm 1.30 використовувалася для створення або оновлення вузла
  • Версія kubeadm, використана для оновлення вузла, повинна бути на 1.30 або 1.31

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

Обмеження

Витривалість кластера

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

Обхідні шляхи:

Платформна сумісність

Пакунки та бінарники kubeadm для deb/rpm будуються для amd64, arm (32-біт), arm64, ppc64le та s390x, відповідабть пропозиції щодо багатоплатформовості.

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

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

Усунення несправностей

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

Що далі

Зворотній звʼязок

2.2.2.1.4 - Налаштування компонентів за допомогою kubeadm API

Ця сторінка охоплює способи налаштування компонентів, які розгортаються за допомогою kubeadm. Для компонентів панелі управління можна використовувати прапорці у структурі ClusterConfiguration або патчі на рівні вузла. Для kubelet і kube-proxy ви можете використовувати KubeletConfiguration та KubeProxyConfiguration, відповідно.

Всі ці опції можливі за допомогою конфігураційного API kubeadm. Докладніше про кожне поле в конфігурації ви можете дізнатися на наших довідкових сторінках API.

Налаштовування панелі управління за допомогою прапорців у ClusterConfiguration

Обʼєкт конфігурації панелі управління kubeadm надає можливість користувачам перевизначати типові прапорці, що передаються компонентам панелі управління, таким як APIServer, ControllerManager, Scheduler та Etcd. Компоненти визначаються за допомогою наступних структур:

  • apiServer
  • controllerManager
  • scheduler
  • etcd

Ці структури містять спільне поле extraArgs, яке складається з пар name / value. Щоб перевизначити прапорець для компонента панелі управління:

  1. Додайте відповідні extraArgs до вашої конфігурації.
  2. Додайте прапорці до поля extraArgs.
  3. Запустіть kubeadm init з --config <ВАШ КОНФІГ YAML>.

Прапорці APIServer

Докладну інформацію див. у довідковій документації для kube-apiserver.

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

apiVersion: kubeadm.k8s.io/v1beta4
kind: ClusterConfiguration
kubernetesVersion: v1.16.0
apiServer:
  extraArgs:
  - name: "enable-admission-plugins"
    value: "AlwaysPullImages,DefaultStorageClass"
  - name: "audit-log-path"
    value: "/home/johndoe/audit.log"

Прапорці ControllerManager

Докладну інформацію див. у довідковій документації для kube-controller-manager.

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

apiVersion: kubeadm.k8s.io/v1beta4
kind: ClusterConfiguration
kubernetesVersion: v1.16.0
controllerManager:
  extraArgs:
  - name: "cluster-signing-key-file"
    value: "/home/johndoe/keys/ca.key"
  - name: "deployment-controller-sync-period"
    value: "50"

Прапорці планувальника

Докладну інформацію див. у довідковій документації для kube-scheduler.

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

apiVersion: kubeadm.k8s.io/v1beta4
kind: ClusterConfiguration
kubernetesVersion: v1.16.0
scheduler:
  extraArgs:
  - name: "config"
    value: "/etc/kubernetes/scheduler-config.yaml"
  extraVolumes:
    - name: schedulerconfig
      hostPath: /home/johndoe/schedconfig.yaml
      mountPath: /etc/kubernetes/scheduler-config.yaml
      readOnly: true
      pathType: "File"

Прапорці etcd

Докладну інформацію див. у документації сервера etcd.

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

apiVersion: kubeadm.k8s.io/v1beta4
kind: ClusterConfiguration
etcd:
  local:
    extraArgs:
    - name: "election-timeout"
      value: 1000

Налаштування за допомогою патчів

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

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

Ви можете передати цей файл в kubeadm init за допомогою --config <ВАШ КОНФІГ YAML>:

apiVersion: kubeadm.k8s.io/v1beta4
kind: InitConfiguration
patches:
  directory: /home/user/somedir

Ви можете передати цей файл в kubeadm join за допомогою --config <ВАШ КОНФІГ YAML>:

apiVersion: kubeadm.k8s.io/v1beta4
kind: JoinConfiguration
patches:
  directory: /home/user/somedir

Тека має містити файли з назвами target[suffix][+patchtype].extension. Наприклад, kube-apiserver0+merge.yaml або просто etcd.json.

  • target може бути одним із kube-apiserver, kube-controller-manager, kube-scheduler, etcd та kubeletconfiguration.
  • suffix — це необовʼязковий рядок, який можна використовувати для визначення порядку застосування патчів за алфавітною послідовністю.
  • patchtype може бути одним із strategic, merge або json і вони повинні відповідати форматам патчів, підтримуваним kubectl. Типово patchtype — strategic.
  • extension повинен бути або json, або yaml.

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

Щоб налаштувати kubelet, ви можете додати KubeletConfiguration поруч із ClusterConfiguration або InitConfiguration, розділеними --- у тому самому файлі конфігурації. Цей файл потім можна передати до kubeadm init, і kubeadm застосує ту ж саму базову KubeletConfiguration для всіх вузлів у кластері.

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

Також ви можете використовувати прапорці kubelet як перевизначення, передаючи їх у поле nodeRegistration.kubeletExtraArgs, яке підтримується як InitConfiguration, так і JoinConfiguration. Деякі прапорці kubelet є застарілими, тому перевірте їх статус у довідковій документації kubelet, перш ніж їх використовувати.

Додаткові деталі дивіться в розділі Налаштування кожного kubelet у вашому кластері за допомогою kubeadm

Налаштування kube-proxy

Щоб налаштувати kube-proxy, ви можете передати KubeProxyConfiguration поруч з ClusterConfiguration або InitConfiguration до kubeadm init, розділені ---.

Для отримання докладнішої інформації ви можете перейти на наші сторінки API-посилань.

2.2.2.1.5 - Варіанти топології високої доступності (HA)

Ця сторінка пояснює два варіанти конфігурації топології ваших високо доступних (HA) кластерів Kubernetes.

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

  • З вузлами панелі управління, де вузли etcd розташовані разом із вузлами панелі управління.
  • З зовнішніми вузлами etcd, де etcd працює на окремих вузлах від вузлів панелі управління.

Перед налаштуванням стійкого кластера слід ретельно розглянути переваги та недоліки кожної топології.

Топологія etcd зі спільним розміщенням

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

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

Кожен вузол панелі управління створює локального члена etcd, і цей член etcd спілкується лише з kube-apiserver цього вузла. Те ж саме стосується локальних екземплярів kube-controller-manager та kube-scheduler.

Ця топологія зʼєднує вузли панелі управління з членами etcd на тих самих вузлах. Вона є простішою для налаштування, ніж кластер зі зовнішніми вузлами etcd, і простішою для управління реплікацією.

Проте такий кластер має ризик втрати зʼєднання. Якщо один вузол вийде з ладу, втратиться як член etcd, так і екземпляр панелі управління, і резервні можливості будуть скомпрометовані. Цей ризик можна зменшити, додавши більше вузлів панелі управління.

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

Це типова топологія в kubeadm. Локальний член etcd створюється автоматично на вузлах панелі управління при використанні kubeadm init та kubeadm join --control-plane.

Топологія etcd зі стековим розміщенням

Топологія зовнішнього розміщення etcd

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

Подібно до топології зі стековими etcd, кожен вузол панелі управління в топології зі зовнішньою etcd запускає екземпляр kube-apiserver, kube-scheduler та kube-controller-manager. І kube-apiserver доступний для робочих вузлів за допомогою балансувальника навантаження. Однак члени etcd працюють на окремих хостах, і кожен хост etcd спілкується з kube-apiserver кожного вузла панелі управління.

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

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

Топологія зовнішнього розташування etcd

Що далі

2.2.2.1.6 - Створення високодоступних кластерів за допомогою kubeadm

На цій сторінці пояснюється два різних підходи до налаштування високодоступного кластера Kubernetes з використанням інструменту kubeadm:

  • Зі стековими вузлами панелі управління. Цей підхід вимагає менше інфраструктури. Члени etcd та вузли панелі управління розташовані разом.
  • Зовнішній кластер etcd. Цей підхід вимагає більше інфраструктури. Вузли панелі управління та члени etcd розділені.

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

У випадку виникнення проблем з налаштуванням HA-кластера, будь ласка, повідомте про це в системі відстеження проблем kubeadm.

Також дивіться документацію з оновлення.

Перш ніж ви розпочнете

Передумови залежать від топології, яку ви обрали для панелі управління кластера:

Вам потрібно:

  • Три або більше машин, які відповідають мінімальним вимогам kubeadm для вузлів панелі управління. Наявність непарної кількості вузлів панелі управління може бути корисною при виборі лідера в разі відмови машини чи зони,
  • Три або більше машин, які відповідають мінімальним вимогам kubeadm для робочих вузлів,
    • включаючи середовище виконання контейнерів, яке вже налаштоване та працює.
  • Повноцінне мережеве зʼєднання між усіма машинами в кластері (публічна чи приватна мережа).
  • Привілеї суперкористувача на всіх машинах за допомогою sudo.
    • Ви можете використовувати інший інструмент; цей посібник використовує sudo у прикладах.
  • SSH-доступ з одного пристрою до всіх вузлів системи.
  • kubeadm та kubelet вже встановлені на всіх машинах.

Дивіться Топологія стекового etcd для контексту.

Вам потрібно:

  • Три або більше машин, які відповідають мінімальним вимогам kubeadm для вузлів панелі управління. Наявність непарної кількості вузлів панелі управління може бути корисною при виборі лідера в разі відмови машини чи зони,
  • Три або більше машин, які відповідають мінімальним вимогам kubeadm для робочих вузлів,
    • включаючи середовище виконання контейнерів контейнера, яке вже налаштоване та працює.
  • Повноцінне мережеве зʼєднання між усіма машинами в кластері (публічна чи приватна мережа).
  • Привілеї суперкористувача на всіх машинах за допомогою sudo.
    • Ви можете використовувати інший інструмент; цей посібник використовує sudo у прикладах.
  • SSH-доступ з одного пристрою до всіх вузлів системи.
  • kubeadm та kubelet вже встановлені на всіх машинах.

І вам також потрібно:

  • Три або більше додаткових машин, які стануть членами кластера etcd. Наявність непарної кількості членів у кластері etcd — це вимога для досягнення оптимального кворуму під час голосування.
    • Ці машини також повинні мати встановлені kubeadm та kubelet.
    • На цих машинах також потрібно мати середовище виконання контейнерів, яке вже налаштоване та працює.

Дивіться Топологія зовнішнього etcd для контексту.

Образи контейнерів

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

Інтерфейс командного рядка

Для управління Kubernetes після налаштування кластера, вам слід встановити kubectl на вашому компʼютері. Також корисно встановити інструмент kubectl на кожному вузлі панелі управління, оскільки це може бути корисним для усунення несправностей.

Перші кроки для обох методів

Створення балансувальника навантаження для kube-apiserver

  1. Створіть балансувальник навантаження kube-apiserver з імʼям, яке розпізнається DNS.

    • У хмарному середовищі ви повинні розмістити вузли панелі управління за TCP балансувальником навантаження, який виконує переспрямовування трафіку. Цей балансувальник розподіляє трафік до всіх справних вузлів панелі управління у своєму списку цілей. Перевірка доступності apiserver — це перевірка TCP порту, на якому слухає kube-apiserver (типове значення порту :6443).

    • Не рекомендується використовувати IP-адресу безпосередньо у хмарному середовищі.

    • Балансувальник навантаження повинен мати можливість взаємодіяти з усіма вузлами панелі управління на порті apiserver. Також він повинен дозволяти вхідний трафік на його порту прослуховування.

    • Переконайтеся, що адреса балансувальника завжди відповідає адресі ControlPlaneEndpoint kubeadm.

    • Прочитайте Параметри для програмного балансування навантаження для отримання додаткових відомостей.

  2. Додайте перший вузол панелі управління до балансувальника та перевірте зʼєднання:

    nc -v <LOAD_BALANCER_IP> <PORT>
    

    Помилка "connection refused" є очікуваною, оскільки API-сервер ще не запущено. Проте тайм-аут означає, що балансувальник не може взаємодіяти з вузлом панелі управління. Якщо виникає тайм-аут, повторно налаштуйте балансувальник для взаємодії з вузлом панелі управління.

  3. Додайте решту вузлів панелі управління до цільової групи балансувальника.

Панель управління та вузли etcd зі стековою архітектурою

Кроки для першого вузла панелі управління

  1. Ініціалізуйте панель управління:

    sudo kubeadm init --control-plane-endpoint "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT" --upload-certs
    
    • Ви можете використовувати прапорець --kubernetes-version, щоб встановити версію Kubernetes, яку слід використовувати. Рекомендується, щоб версії kubeadm, kubelet, kubectl та Kubernetes відповідали одна одній.

    • Прапорець --control-plane-endpoint повинен бути встановлений на адресу або DNS та порт балансувальника.

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

    Вивід виглядатиме десь так:

    ...
    You can now join any number of control-plane node by running the following command on each as a root:
        kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 --control-plane --certificate-key f8902e114ef118304e561c3ecd4d0b543adc226b7a07f675f56564185ffe0c07
    
    Please note that the certificate-key gives access to cluster sensitive data, keep it secret!
    As a safeguard, uploaded-certs will be deleted in two hours; If necessary, you can use kubeadm init phase upload-certs to reload certs afterward.
    
    Then you can join any number of worker nodes by running the following on each as root:
        kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866
    
    • Скопіюйте цей вивід у текстовий файл. Ви будете потребувати його пізніше для приєднання вузлів панелі управління та робочих вузлів до кластера.

    • Коли використовується --upload-certs з kubeadm init, сертифікати основної панелі управління шифруються та завантажуються у kubeadm-certs Secret.

    • Щоб знову завантажити сертифікати та згенерувати новий ключ розшифрування, використовуйте наступну команду на вузлі панелі управління який вже приєднаний до кластера:

      sudo kubeadm init phase upload-certs --upload-certs
      
    • Ви також можете вказати власний --certificate-key під час init, який пізніше може бути використаний з join. Щоб згенерувати такий ключ, використовуйте наступну команду:

      kubeadm certs certificate-key
      

    Ключ сертифіката — це рядок, закодований у шістнадцятковій формі, який є ключем AES розміром 32 байти.

  2. Застосуйте обраний вами мережеву втулок CNI: Дотримуйтеся цих інструкцій для встановлення постачальника CNI. Переконайтеся, що конфігурація відповідає CIDR IP для Podʼа, вказаному в файлі конфігурації kubeadm (якщо застосовується).

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

    kubectl get pod -n kube-system -w
    

Кроки для інших вузлів панелі управління

Для кожного додаткового вузла панелі управління:

  1. Виконайте команду приєднання, яка вам була надана раніше виводом kubeadm init на першому вузлі. Вона повинна виглядати приблизно так:

    sudo kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 --control-plane --certificate-key f8902e114ef118304e561c3ecd4d0b543adc226b7a07f675f56564185ffe0c07
    
    • Прапорець --control-plane повідомляє kubeadm join створити новий вузол панелі управління.
    • Прапорець --certificate-key ... призведе до того, що сертифікати вузлів панелі управління будуть завантажені з секрету kubeadm-certs в кластері та розшифровані за допомогою вказаного ключа.

Ви можете приєднувати кілька вузлів панелі управління паралельно.

Зовнішні вузли etcd

Налаштування кластера з зовнішніми вузлами etcd подібно до процедури, використовуваної для стекових вузлів etcd, з винятком того, що ви повинні налаштувати etcd спочатку, і ви повинні передавати інформацію про etcd у конфігураційному файлі kubeadm.

Налаштуйте кластер etcd

  1. Слідуйте цим інструкціям для налаштування кластера etcd.

  2. Налаштуйте SSH, як описано тут.

  3. Скопіюйте наступні файли з будь-якого вузла etcd в кластері на перший вузол панелі управління:

    export CONTROL_PLANE="ubuntu@10.0.0.7"
    scp /etc/kubernetes/pki/etcd/ca.crt "${CONTROL_PLANE}":
    scp /etc/kubernetes/pki/apiserver-etcd-client.crt "${CONTROL_PLANE}":
    scp /etc/kubernetes/pki/apiserver-etcd-client.key "${CONTROL_PLANE}":
    
    • Замініть значення CONTROL_PLANE на user@host першого вузла панелі управління.

Налаштуйте перший вузол панелі управління

  1. Створіть файл із назвою kubeadm-config.yaml із наступним змістом:

    ---
    apiVersion: kubeadm.k8s.io/v1beta4
    kind: ClusterConfiguration
    kubernetesVersion: stable
    controlPlaneEndpoint: "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT" # змініть це (див. нижче)
    etcd:
      external:
        endpoints:
          - https://ETCD_0_IP:2379 # змініть ETCD_0_IP відповідно
          - https://ETCD_1_IP:2379 # змініть ETCD_1_IP відповідно
          - https://ETCD_2_IP:2379 # змініть ETCD_2_IP відповідно
        caFile: /etc/kubernetes/pki/etcd/ca.crt
        certFile: /etc/kubernetes/pki/apiserver-etcd-client.crt
        keyFile: /etc/kubernetes/pki/apiserver-etcd-client.key
    
    • Замініть наступні змінні в шаблоні конфігурації на відповідні значення для вашого кластера:

      • LOAD_BALANCER_DNS
      • LOAD_BALANCER_PORT
      • ETCD_0_IP
      • ETCD_1_IP
      • ETCD_2_IP

Наступні кроки схожі на налаштування stacked etcd:

  1. Виконайте команду sudo kubeadm init --config kubeadm-config.yaml --upload-certs на цьому вузлі.

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

  3. Застосуйте обраний вами втулок CNI.

Кроки для інших вузлів панелі управління

Кроки аналогічні налаштуванню для stacked etcd:

  • Переконайтеся, що перший вузол панелі управління повністю ініціалізований.
  • Приєднайте кожен вузол панелі управління за допомогою команди приєднання, яку ви зберегли в текстовий файл. Рекомендується приєднувати вузли панелі управління по одному.
  • Не забудьте, що ключ розшифрування з параметром --certificate-key діє дві години.

Загальні завдання після налаштування панелі управління

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

Робочі вузли можна приєднати до кластера за допомогою команди, яку ви зберегли раніше як вивід з команди kubeadm init:

sudo kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866

Ручне поширення сертифікатів

Якщо ви вирішили не використовувати kubeadm init з параметром --upload-certs, це означає, що вам доведеться вручну скопіювати сертифікати з первинного вузла панелі управління до приєднуваних вузлів панелі.

Є багато способів це зробити. У наступному прикладі використовуються ssh та scp:

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

  1. Активуйте ssh-agent на своєму основному пристрої, який має доступ до всіх інших вузлів в системі:

    eval $(ssh-agent)
    
  2. Додайте свій SSH-ідентифікатор до сеансу:

    ssh-add ~/.ssh/path_to_private_key
    
  3. Перемикайтесь між вузлами, щоб перевірити, чи зʼєднання правильно працює.

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

      ssh -A 10.0.0.7
      
    • Коли використовуєте sudo на будь-якому вузлі, обовʼязково зберігайте середовище, щоб SSH forwarding працював:

      sudo -E -s
      
  4. Після налаштування SSH на всіх вузлах ви повинні запустити наступний скрипт на першому вузлі панелі управління після запуску kubeadm init. Цей скрипт скопіює сертифікати з першого вузла панелі управління на інші вузли панелі:

    У наступному прикладі замініть CONTROL_PLANE_IPS на IP-адреси інших вузлів панелі управління.

    USER=ubuntu # налаштовується
    CONTROL_PLANE_IPS="10.0.0.7 10.0.0.8"
    for host in ${CONTROL_PLANE_IPS}; do
        scp /etc/kubernetes/pki/ca.crt "${USER}"@$host:
        scp /etc/kubernetes/pki/ca.key "${USER}"@$host:
        scp /etc/kubernetes/pki/sa.key "${USER}"@$host:
        scp /etc/kubernetes/pki/sa.pub "${USER}"@$host:
        scp /etc/kubernetes/pki/front-proxy-ca.crt "${USER}"@$host:
        scp /etc/kubernetes/pki/front-proxy-ca.key "${USER}"@$host:
        scp /etc/kubernetes/pki/etcd/ca.crt "${USER}"@$host:etcd-ca.crt
        # Пропустіть наступний рядок, якщо використовуєте зовнішній etcd
        scp /etc/kubernetes/pki/etcd/ca.key "${USER}"@$host:etcd-ca.key
    done
    
  5. Потім на кожному приєднуваному вузлі панелі управління вам слід виконати наступний скрипт перед виконанням kubeadm join. Цей скрипт перемістить раніше скопійовані сертифікати з домашньої теки в /etc/kubernetes/pki:

    USER=ubuntu # налаштовується
    mkdir -p /etc/kubernetes/pki/etcd
    mv /home/${USER}/ca.crt /etc/kubernetes/pki/
    mv /home/${USER}/ca.key /etc/kubernetes/pki/
    mv /home/${USER}/sa.pub /etc/kubernetes/pki/
    mv /home/${USER}/sa.key /etc/kubernetes/pki/
    mv /home/${USER}/front-proxy-ca.crt /etc/kubernetes/pki/
    mv /home/${USER}/front-proxy-ca.key /etc/kubernetes/pki/
    mv /home/${USER}/etcd-ca.crt /etc/kubernetes/pki/etcd/ca.crt
    # Пропустіть наступний рядок, якщо використовуєте зовнішній etcd
    mv /home/${USER}/etcd-ca.key /etc/kubernetes/pki/etcd/ca.key
    

2.2.2.1.7 - Налаштування високодоступного кластера etcd за допомогою kubeadm

Типово kubeadm запускає локальний екземпляр etcd на кожному вузлі панелі управління Також можливо розглядати кластер etcd як зовнішній та розгортати екземпляри etcd на окремих хостах. Відмінності між цими підходами описано на сторінці Варіанти топології високої доступності.

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

Перш ніж ви розпочнете

  • Три хости, які можуть взаємодіяти між собою через TCP-порти 2379 та 2380. Цей документ вважає, що це стандартні порти. Однак їх можна налаштувати через файл конфігурації kubeadm.
  • На кожному хості повинен бути встановлений systemd та сумісна з bash оболонка.
  • На кожному хості повинно бути встановлене середовище виконання контейнерів, kubelet та kubeadm.
  • Кожен хост повинен мати доступ до реєстру образів контейнерів Kubernetes (registry.k8s.io) або ви можете отримати перелік та/або витягти необхідний образ etcd, використовуючи kubeadm config images list/pull. У цьому посібнику екземпляри etcd налаштовані як статичні Podʼи, керовані kubelet.
  • Є якась інфраструктура для копіювання файлів між хостами. Наприклад, ssh та scp можуть відповідати цьому вимогу.

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

Загальний підхід — генерувати всі сертифікати на одному вузлі та розповсюджувати лише необхідні файли на інші вузли.

  1. Налаштуйте kubelet як менеджер служб для etcd.

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

    cat << EOF > /etc/systemd/system/kubelet.service.d/kubelet.conf
    # Замініть "systemd" на драйвер cgroup вашого середовища виконання контейнерів. Стандартне значення в kubelet - "cgroupfs".
    # Замініть значення "containerRuntimeEndpoint" на інше середовище виконання контейнерів за потреби.
    #
    apiVersion: kubelet.config.k8s.io/v1beta1
    kind: KubeletConfiguration
    authentication:
      anonymous:
        enabled: false
      webhook:
        enabled: false
    authorization:
      mode: AlwaysAllow
    cgroupDriver: systemd
    address: 127.0.0.1
    containerRuntimeEndpoint: unix:///var/run/containerd/containerd.sock
    staticPodPath: /etc/kubernetes/manifests
    EOF
    
    cat << EOF > /etc/systemd/system/kubelet.service.d/20-etcd-service-manager.conf
    [Service]
    ExecStart=
    ExecStart=/usr/bin/kubelet --config=/etc/systemd/system/kubelet.service.d/kubelet.conf
    Restart=always
    EOF
    
    systemctl daemon-reload
    systemctl restart kubelet
    

    Перевірте статус kubelet, щоб переконатися, що він працює.

    systemctl status kubelet
    
  2. Створіть конфігураційні файли для kubeadm.

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

    # Оновіть HOST0, HOST1 та HOST2 IP ваших хостів
    export HOST0=10.0.0.6
    export HOST1=10.0.0.7
    export HOST2=10.0.0.8
    
    # Оновіть NAME0, NAME1 та NAME2 іменами хостів
    export NAME0="infra0"
    export NAME1="infra1"
    export NAME2="infra2"
    
    # Створіть тимчасові теки для зберігання файлів, які потраплять на інші хости
    mkdir -p /tmp/${HOST0}/ /tmp/${HOST1}/ /tmp/${HOST2}/
    
    HOSTS=(${HOST0} ${HOST1} ${HOST2})
    NAMES=(${NAME0} ${NAME1} ${NAME2})
    
    for i in "${!HOSTS[@]}"; do
    HOST=${HOSTS[$i]}
    NAME=${NAMES[$i]}
    cat << EOF > /tmp/${HOST}/kubeadmcfg.yaml
    ---
    apiVersion: "kubeadm.k8s.io/v1beta4"
    kind: InitConfiguration
    nodeRegistration:
        name: ${NAME}
    localAPIEndpoint:
        advertiseAddress: ${HOST}
    ---
    apiVersion: "kubeadm.k8s.io/v1beta4"
    kind: ClusterConfiguration
    etcd:
        local:
            serverCertSANs:
            - "${HOST}"
            peerCertSANs:
            - "${HOST}"
            extraArgs:
            - name: initial-cluster
              value: ${NAMES[0]}=https://${HOSTS[0]}:2380,${NAMES[1]}=https://${HOSTS[1]}:2380,${NAMES[2]}=https://${HOSTS[2]}:2380
            - name: initial-cluster-state
              value: new
            - name: name
              value: ${NAME}
            - name: listen-peer-urls
              value: https://${HOST}:2380
            - name: listen-client-urls
              value: https://${HOST}:2379
            - name: advertise-client-urls
              value: https://${HOST}:2379
            - name: initial-advertise-peer-urls
              value: https://${HOST}:2380
    EOF
    done
    
  3. Згенеруйте центр сертифікації.

    Якщо у вас вже є ЦС, то єдине що треба зробити — скопіювати файли crt та key ЦС у /etc/kubernetes/pki/etcd/ca.crt та /etc/kubernetes/pki/etcd/ca.key. Після копіювання цих файлів перейдіть до наступного кроку — "Створення сертифікатів для кожного учасника".

    Якщо у вас ще немає ЦС, то виконайте цю команду на $HOST0 (де ви згенерували файли конфігурації для kubeadm).

    kubeadm init phase certs etcd-ca
    

    Це створює два файли:

    • /etc/kubernetes/pki/etcd/ca.crt
    • /etc/kubernetes/pki/etcd/ca.key
  4. Створення сертифікатів для кожного учасника.

    kubeadm init phase certs etcd-server --config=/tmp/${HOST2}/kubeadmcfg.yaml
    kubeadm init phase certs etcd-peer --config=/tmp/${HOST2}/kubeadmcfg.yaml
    kubeadm init phase certs etcd-healthcheck-client --config=/tmp/${HOST2}/kubeadmcfg.yaml
    kubeadm init phase certs apiserver-etcd-client --config=/tmp/${HOST2}/kubeadmcfg.yaml
    cp -R /etc/kubernetes/pki /tmp/${HOST2}/
    # очистити одноразові сертифікати
    find /etc/kubernetes/pki -not -name ca.crt -not -name ca.key -type f -delete
    
    kubeadm init phase certs etcd-server --config=/tmp/${HOST1}/kubeadmcfg.yaml
    kubeadm init phase certs etcd-peer --config=/tmp/${HOST1}/kubeadmcfg.yaml
    kubeadm init phase certs etcd-healthcheck-client --config=/tmp/${HOST1}/kubeadmcfg.yaml
    kubeadm init phase certs apiserver-etcd-client --config=/tmp/${HOST1}/kubeadmcfg.yaml
    cp -R /etc/kubernetes/pki /tmp/${HOST1}/
    find /etc/kubernetes/pki -not -name ca.crt -not -name ca.key -type f -delete
    
    kubeadm init phase certs etcd-server --config=/tmp/${HOST0}/kubeadmcfg.yaml
    kubeadm init phase certs etcd-peer --config=/tmp/${HOST0}/kubeadmcfg.yaml
    kubeadm init phase certs etcd-healthcheck-client --config=/tmp/${HOST0}/kubeadmcfg.yaml
    kubeadm init phase certs apiserver-etcd-client --config=/tmp/${HOST0}/kubeadmcfg.yaml
    # Немає потреби переміщувати сертифікати, оскільки вони призначені для HOST0
    
    # приберемо сертифікати, які не повинні бути скопійовані з цього хоста
    find /tmp/${HOST2} -name ca.key -type f -delete
    find /tmp/${HOST1} -name ca.key -type f -delete
    
  5. Скопіюйте сертифікати та конфігурації kubeadm.

    Сертифікати вже були згенеровані, і тепер їх потрібно перемістити на відповідні хости.

    USER=ubuntu
    HOST=${HOST1}
    scp -r /tmp/${HOST}/* ${USER}@${HOST}:
    ssh ${USER}@${HOST}
    USER@HOST $ sudo -Es
    root@HOST $ chown -R root:root pki
    root@HOST $ mv pki /etc/kubernetes/
    
  6. Переконайтеся, що всі очікувані файли існують.

    Повний перелік обовʼязкових файлів на $HOST0:

    /tmp/${HOST0}
    └── kubeadmcfg.yaml
    ---
    /etc/kubernetes/pki
    ├── apiserver-etcd-client.crt
    ├── apiserver-etcd-client.key
    └── etcd
        ├── ca.crt
        ├── ca.key
        ├── healthcheck-client.crt
        ├── healthcheck-client.key
        ├── peer.crt
        ├── peer.key
        ├── server.crt
        └── server.key
    

    На $HOST1:

    $HOME
    └── kubeadmcfg.yaml
    ---
    /etc/kubernetes/pki
    ├── apiserver-etcd-client.crt
    ├── apiserver-etcd-client.key
    └── etcd
        ├── ca.crt
        ├── healthcheck-client.crt
        ├── healthcheck-client.key
        ├── peer.crt
        ├── peer.key
        ├── server.crt
        └── server.key
    

    На $HOST2:

    $HOME
    └── kubeadmcfg.yaml
    ---
    /etc/kubernetes/pki
    ├── apiserver-etcd-client.crt
    ├── apiserver-etcd-client.key
    └── etcd
        ├── ca.crt
        ├── healthcheck-client.crt
        ├── healthcheck-client.key
        ├── peer.crt
        ├── peer.key
        ├── server.crt
        └── server.key
    
  7. Створіть маніфести статичних Podʼів.

    Тепер, коли сертифікати та конфігурації на місці, прийшов час створити маніфести для etcd. На кожному хості виконайте команду kubeadm для генерації статичного маніфесту для etcd.

    root@HOST0 $ kubeadm init phase etcd local --config=/tmp/${HOST0}/kubeadmcfg.yaml
    root@HOST1 $ kubeadm init phase etcd local --config=$HOME/kubeadmcfg.yaml
    root@HOST2 $ kubeadm init phase etcd local --config=$HOME/kubeadmcfg.yaml
    
  8. Опціонально: Перевірте стан кластера.

    Якщо etcdctl недоступний, ви можете запустити цей інструмент в середовищі контейнера. Ви можете це зробити безпосередньо з вашим середовищем виконання контейнерів за допомогою такого інструменту, як crictl run, а не через Kubernetes

    ETCDCTL_API=3 etcdctl \
    --cert /etc/kubernetes/pki/etcd/peer.crt \
    --key /etc/kubernetes/pki/etcd/peer.key \
    --cacert /etc/kubernetes/pki/etcd/ca.crt \
    --endpoints https://${HOST0}:2379 endpoint health
    ...
    https://[HOST0 IP]:2379 is healthy: successfully committed proposal: took = 16.283339ms
    https://[HOST1 IP]:2379 is healthy: successfully committed proposal: took = 19.44402ms
    https://[HOST2 IP]:2379 is healthy: successfully committed proposal: took = 35.926451ms
    
    • Встановіть ${HOST0}на IP-адресу хосту, який ви тестуєте.

Що далі

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

2.2.2.1.8 - Налаштування кожного kubelet у кластері за допомогою kubeadm

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

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

Оскільки kubelet — це демон, його потрібно обслуговувати за допомогою якоїсь системи ініціалізації або менеджера служб. Коли kubelet встановлено за допомогою DEB або RPM-пакунків, systemd налаштовується для управління kubelet. Ви можете використовувати інший менеджер служб, але його потрібно налаштувати вручну.

Деякі деталі конфігурації kubelet повинні бути однакові для всіх kubelet, які беруть участь в кластері, тоді як інші аспекти конфігурації повинні бути встановлені для кожного kubelet окремо, щоб врахувати різні характеристики кожної машини (такі як ОС, сховище та мережа). Ви можете керувати конфігурацією kubelet вручну, але тепер kubeadm надає API-тип KubeletConfiguration дляцентралізованого управління конфігураціями kubelet.

Шаблони конфігурації kubelet

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

Поширення конфігурації на рівні кластера для кожного kubelet

Ви можете надати kubelet стандартне значення для використання команд kubeadm init та kubeadm join. Цікаві приклади охоплюють використання іншого середовища виконання контейнерів або встановлення типової підмережі, яку використовують служби.

Якщо ви хочете, щоб ваші служби використовували мережу 10.96.0.0/12, ви можете передати параметр --service-cidr в kubeadm:

kubeadm init --service-cidr 10.96.0.0/12

Віртуальні IP-адреси для служб тепер виділяються з цієї підмережі. Вам також потрібно встановити адресу DNS, яку використовує kubelet, за допомогою прапорця --cluster-dns. Це налаштування мають бути однаковим для кожного kubelet на кожному вузлі управління та вузлі в кластері. Kubelet надає структурований, версійований обʼєкт API, який може налаштовувати більшість параметрів в kubelet та розсилати цю конфігурацію кожному працюючому kubelet в кластері. Цей обʼєкт називається KubeletConfiguration. KubeletConfiguration дозволяє користувачу вказувати прапорці, такі як IP-адреси DNS кластера, у вигляді списку значень для camelCased ключа, як показано в наступному прикладі:

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
clusterDNS:
- 10.96.0.10

Докладніше про KubeletConfiguration можна знайти у цьому розділі.

Надання конфігурації, специфічної для екземпляра

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

  • Шлях до файлу розвʼязання DNS, як вказано прапорцем конфігурації kubelet --resolv-conf, може відрізнятися залежно від операційної системи або від того, чи використовується systemd-resolved. Якщо цей шлях вказано неправильно, розвʼязування DNS буде невдалим на вузлі, конфігурація kubelet якого налаштована неправильно.

  • Обʼєкт API вузла .metadata.name типово вказує імʼя хосту машини, якщо ви не використовуєте хмарного постачальника. Ви можете використовувати прапорець --hostname-override, щоб змінити типову поведінку, якщо вам потрібно вказати імʼя вузла, відмінне від імені хосту машини.

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

  • Щоб вказати середовище виконання контейнерів, вам потрібно встановити його endpoint за допомогою прапорця --container-runtime-endpoint=<шлях>.

Рекомендований спосіб застосування такої конфігурації, специфічної для екземпляра, — використовувати патчі для KubeletConfiguration.

Налаштування kubelet за допомогою kubeadm

Можливо налаштувати kubelet, який запустить kubeadm, якщо вказано власний обʼєкт API KubeletConfiguration з конфігураційним файлом таким чином kubeadm ... --config some-config-file.yaml.

Викликаючи kubeadm config print init-defaults --component-configs KubeletConfiguration, ви можете переглянути всі типові значення для цієї структури.

Також можливо застосувати специфічні для екземпляра патчі до базового KubeletConfiguration. Див. Налаштування kubelet для отримання докладнішої інформації.

Послідовність дій при використанні kubeadm init

Коли ви викликаєте kubeadm init, конфігурація kubelet записується на диск в /var/lib/kubelet/config.yaml і також завантажується в ConfigMap kubelet-config в просторі імен kube-system кластера. Файл конфігурації kubelet також записується у /etc/kubernetes/kubelet.conf із базовою конфігурацією кластера для всіх kubelet в кластері. Цей файл конфігурації вказує на клієнтські сертифікати, які дозволяють kubelet взаємодіяти з сервером API. Це вирішує необхідність поширення конфігурації на рівні кластера для кожного kubelet.

Щоб вирішити другий шаблон надання конфігурації, специфічної для екземпляра, kubeadm записує файл середовища у /var/lib/kubelet/kubeadm-flags.env, який містить список прапорців, які слід передати kubelet при запуску. Прапорці виглядають у файлі наступним чином:

KUBELET_KUBEADM_ARGS="--flag1=value1 --flag2=value2 ..."

Крім прапорців, використовуваних при запуску kubelet, файл також містить динамічні параметри, такі як драйвер cgroup та використання іншого сокету контейнерного середовища (--cri-socket).

Після того як ці два файли конвертуються на диск, kubeadm намагається виконати дві команди, якщо ви використовуєте systemd:

systemctl daemon-reload && systemctl restart kubelet

Якщо перезавантаження та перезапуск вдалися, продовжується звичайний робочий процес kubeadm init.

Послідовність при використанні kubeadm join

Коли ви викликаєте kubeadm join, kubeadm використовує облікові дані Bootstrap Token, щоб виконати запуск TLS, який отримує необхідні облікові дані для завантаження kubelet-config ConfigMap та записує його в /var/lib/kubelet/config.yaml. Файл середовища генерується точно так само, як і при kubeadm init.

Далі kubeadm виконує дві команди для завантаження нової конфігурації в kubelet:

systemctl daemon-reload && systemctl restart kubelet

Після завантаження нової конфігурації kubelet, kubeadm записує /etc/kubernetes/bootstrap-kubelet.conf файл конфігурації KubeConfig, який містить сертифікат CA та Bootstrap Token. Ці дані використовуються kubelet для виконання TLS Bootstrap та отримання унікальних облікових даних, які зберігається в /etc/kubernetes/kubelet.conf.

Коли файл /etc/kubernetes/kubelet.conf записаний, kubelet завершує виконання TLS Bootstrap. Kubeadm видаляє файл /etc/kubernetes/bootstrap-kubelet.conf після завершення TLS Bootstrap.

Файл kubelet drop-in для systemd

kubeadm постачається з конфігурацією systemd для запуску kubelet. Зверніть увагу, що команда kubeadm CLI ніколи не торкається цього drop-in файлу.

Цей файл конфігурації, встановлений за допомогою пакунку kubeadm, записується в /usr/lib/systemd/system/kubelet.service.d/10-kubeadm.conf та використовується systemd. Він доповнює основний kubelet.service.

Якщо ви хочете внести зміні, ви можете створити теку /etc/systemd/system/kubelet.service.d/ (зверніть увагу, не /usr/lib/systemd/system/kubelet.service.d/) та внести власні налаштування у файл там. Наприклад, ви можете додати новий локальний файл /etc/systemd/system/kubelet.service.d/local-overrides.conf для того, щоб перевизначити налаштування елементів в kubeadm.

Ось що ви, імовірно, знайдете в /usr/lib/systemd/system/kubelet.service.d/10-kubeadm.conf:

[Service]
Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf"
Environment="KUBELET_CONFIG_ARGS=--config=/var/lib/kubelet/config.yaml"
# Це файл, який "kubeadm init" та "kubeadm join" генерують в режимі виконання, заповнюючи
# змінну KUBELET_KUBEADM_ARGS динамічно
EnvironmentFile=-/var/lib/kubelet/kubeadm-flags.env
# Це файл, який користувач може використовувати для заміщення аргументів kubelet як останній захист. В ідеалі,
# користувач повинен використовувати обʼєкт .NodeRegistration.KubeletExtraArgs в файлах конфігурації.
# KUBELET_EXTRA_ARGS повинен бути джерелом цього файлу.
EnvironmentFile=-/etc/default/kubelet
ExecStart=
ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS $KUBELET_KUBEADM_ARGS $KUBELET_EXTRA_ARGS

Цей файл вказує на типове знаходження для всіх файлів, які керуються kubeadm для kubelet.

  • Файл KubeConfig для TLS Bootstrap — /etc/kubernetes/bootstrap-kubelet.conf, але він використовується тільки у випадку, якщо /etc/kubernetes/kubelet.conf не існує.
  • Файл KubeConfig з унікальними ідентифікаційними даними kubelet — /etc/kubernetes/kubelet.conf.
  • Файл, що містить ComponentConfig kubelet — /var/lib/kubelet/config.yaml.
  • Динамічний файл середовища, що містить KUBELET_KUBEADM_ARGS, взятий з /var/lib/kubelet/kubeadm-flags.env.
  • Файл, що може містити перевизначення прапорців, вказаних користувачем за допомогою KUBELET_EXTRA_ARGS, береться з /etc/default/kubelet (для DEB) або /etc/sysconfig/kubelet (для RPM). KUBELET_EXTRA_ARGS останній в ланцюжку прапорців та має найвищий пріоритет у випадку конфлікту налаштувань.

Бінарні файли Kubernetes та вміст пакунків

DEB та RPM-пакети, які постачаються з випусками Kubernetes:

Назва пакункаОпис
kubeadmВстановлює інструмент командного рядка /usr/bin/kubeadm та файл drop-in для kubelet для kubelet.
kubeletВстановлює виконавчий файл /usr/bin/kubelet.
kubectlВстановлює виконавчий файл /usr/bin/kubectl.
cri-toolsВстановлює виконавчий файл /usr/bin/crictl з репозиторію git cri-tools.
kubernetes-cniВстановлює бінарні файли /opt/cni/bin з репозиторію git plugins.

2.2.2.1.9 - Підтримка подвійного стека за допомогою kubeadm

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

Ваш кластер Kubernetes має мережу з підтримкою подвійного стека, що означає, що у кластері мережева взаємодія може використовувати обидві адресні родини. У кластері панель управління може призначити як IPv4-адреси, так і IPv6-адреси Podʼу чи Service.

Перш ніж ви розпочнете

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

Для кожного сервера, який ви хочете використовувати як вузол, переконайтеся, що на ньому увімкнено переспрямовування IPv6 трафіку (IPv6 forwarding). На Linux це можна зробити, виконавши sysctl -w net.ipv6.conf.all.forwarding=1 з правами користувача root на кожному сервері.

Вам потрібні діапазони адрес IPv4 та IPv6. Оператори кластера, як правило, використовують приватні діапазони адрес для IPv4. Щодо IPv6, оператор кластера, як правило, обирає глобальний унікальний блок адрес з області 2000::/3, використовуючи діапазон, який виділений оператору. Вам не потрібно робити маршрутизацію IP-діапазонів кластера в Інтернет.

Розмір діапазону IP-адрес повинен бути достатнім для тієї кількості Podʼів та Serviceʼів, які ви плануєте запускати.

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

Для створення кластера з подвійним стеком за допомогою kubeadm init ви можете передати аргументи командного рядка аналогічно наступному прикладу:

# Це діапазони адрес для прикладу
kubeadm init --pod-network-cidr=10.244.0.0/16,2001:db8:42:0::/56 --service-cidr=10.96.0.0/16,2001:db8:42:1::/112

Щоб зробити це більш зрозумілим, ось приклад конфігураційного файлу kubeadm kubeadm-config.yaml для основного вузла панелі управління з подвійним стеком.

---
apiVersion: kubeadm.k8s.io/v1beta4
kind: ClusterConfiguration
networking:
  podSubnet: 10.244.0.0/16,2001:db8:42:0::/56
  serviceSubnet: 10.96.0.0/16,2001:db8:42:1::/112
---
apiVersion: kubeadm.k8s.io/v1beta4
kind: InitConfiguration
localAPIEndpoint:
  advertiseAddress: "10.100.0.1"
  bindPort: 6443
nodeRegistration:
  kubeletExtraArgs:
  - name: "node-ip"
    value: "10.100.0.2,fd00:1:2:3::2"

advertiseAddress в InitConfiguration вказує IP-адресу, яку API Server оголошує як адресу, на якій він очікує трафік. Значення advertiseAddress дорівнює значенню прапорця --apiserver-advertise-address команди kubeadm init.

Використовуйте kubeadm для ініціалізації панелі управління на вузлі з подвійним стеком:

kubeadm init --config=kubeadm-config.yaml

Прапори kube-controller-manager --node-cidr-mask-size-ipv4|--node-cidr-mask-size-ipv6 встановлені у стандартні значення. Див. налаштування подвійного стека IPv4/IPv6.

Приєднання вузла до кластера з подвійним стеком

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

Ось приклад конфігураційного файлу kubeadm kubeadm-config.yaml для приєднання робочого вузла до кластера.

apiVersion: kubeadm.k8s.io/v1beta4
kind: JoinConfiguration
discovery:
  bootstrapToken:
    apiServerEndpoint: 10.100.0.1:6443
    token: "clvldh.vjjwg16ucnhp94qr"
    caCertHashes:
    - "sha256:a4863cde706cfc580a439f842cc65d5ef112b7b2be31628513a9881cf0d9fe0e"
    # змініть інформацію про автентифікацію вище, щоб відповідати фактичному токену та хешу сертифіката CA для вашого кластера
nodeRegistration:
  kubeletExtraArgs:
  - name: "node-ip"
    value: "10.100.0.2,fd00:1:2:3::3"

Також ось приклад конфігураційного файлу kubeadm kubeadm-config.yaml для приєднання іншого вузла панелі управління до кластера.

apiVersion: kubeadm.k8s.io/v1beta4
kind: JoinConfiguration
controlPlane:
  localAPIEndpoint:
    advertiseAddress: "10.100.0.2"
    bindPort: 6443
discovery:
  bootstrapToken:
    apiServerEndpoint: 10.100.0.1:6443
    token: "clvldh.vjjwg16ucnhp94qr"
    caCertHashes:
    - "sha256:a4863cde706cfc580a439f842cc65d5ef112b7b2be31628513a9881cf0d9fe0e"
    # змініть інформацію про автентифікацію вище, щоб відповідати фактичному токену та хешу сертифіката CA для вашого кластера
nodeRegistration:
  kubeletExtraArgs:
  - name: "node-ip"
    value: "10.100.0.2,fd00:1:2:3::4"

advertiseAddress в JoinConfiguration.controlPlane вказує IP-адресу, яку API Server оголошує як адресу, на якій він слухає. Значення advertiseAddress дорівнює прапорцю --apiserver-advertise-address команди kubeadm join.

kubeadm join --config=kubeadm-config.yaml

Створення кластера з одним стеком

Щоб зробити речі більш зрозумілими, конфігураційного файлу kubeadm kubeadm-config.yaml для панелі управління з одним стеком.

apiVersion: kubeadm.k8s.io/v1beta4
kind: ClusterConfiguration
networking:
  podSubnet: 10.244.0.0/16
  serviceSubnet: 10.96.0.0/16

Що далі

2.2.3 - Хмарні рішення під ключ

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

2.3 - Найкращі практики

2.3.1 - Міркування щодо великих кластерів

Кластер — це набір вузлів (фізичних або віртуальних машин), на яких працюють агенти Kubernetes, керовані через панель управління. Kubernetes v1.31 підтримує кластери розміром до 5,000 вузлів. Зокрема, Kubernetes розроблений для роботи з конфігураціями, які відповідають всім наступним критеріям:

  • Не більше 110 Podʼів на вузол
  • Не більше 5,000 вузлів
  • Не більше 150,000 Podʼів загалом
  • Не більше 300,000 контейнерів загалом

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

Обмеження ресурсів у хмарних постачальників

Щоб уникнути проблем із квотами хмарного постачальника при створенні кластера із багатьма вузлами, розгляньте наступне:

  • Запит на збільшення квоти ресурсів хмари, таких як:
    • Кількість компʼютерів
    • Центральні процесори (CPU)
    • Томи зберігання
    • Використані IP-адреси
    • Набори правил фільтрації пакетів
    • Кількість балансерів навантаження
    • Підмережі
    • Потоки логів
  • Керування діями масштабування кластера для введення нових вузлів партіями, з паузою між партіями, оскільки деякі хмарні постачальники обмежують швидкість створення нових екземплярів.

Компоненти панелі управління

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

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

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

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

Сховище etcd

Для покращення продуктивності великих кластерів ви можете зберігати обʼєкти подій в окремому відділеному екземплярі etcd.

При створенні кластера ви можете (за допомогою власних інструментів):

  • запускати та налаштовувати додаткові екземплярти etcd
  • налаштовувати API сервер для використання його для зберігання подій

Деталі з налаштування та управління etcd для великого кластера наведено в розділах Управління кластерами etcd для Kubernetes та Налаштування високодоступного кластера etcd за допомогою kubeadm.

Ресурси надбудов

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

Наприклад, ви можете встановити обмеження CPU та памʼяті для компонента логування:

  ...
  containers:
  - name: fluentd-cloud-logging
    image: fluent/fluentd-kubernetes-daemonset:v1
    resources:
      limits:
        cpu: 100m
        memory: 200Mi

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

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

  • Деякі надбудови масштабуються вертикально — є одна репліка надбудови для кластера чи обслуговування всієї зони відмов. Для таких надбудов збільшуйте запити та обмеження при масштабуванні вашого кластера.
  • Багато надбудов масштабуються горизонтально — ви додаєте можливості, запускаючи більше Podʼів, але з дуже великим кластером вам може також знадобитися трошки збільшити обмеження CPU чи памʼяті. Vertical Pod Autoscaler може працювати в режимі recommender, щоб надати запропоновані цифри для запитів та обмежень.
  • Деякі надбудови працюють як одна копія на вузол, керована DaemonSet: наприклад, агрегатор логів рівня вузла. Так само як і у випадку горизонтально масштабованих надбудов, вам може також знадобитися трошки збільшити обмеження CPU чи памʼяті.

Що далі

  • VerticalPodAutoscaler — це власний ресурс, який ви можете розгортати у свій кластер, щоб допомогти управляти запитами та обмеженнями ресурсів для Podʼів. Дізнайтеся більше про Vertical Pod Autoscaler та як ви можете використовувати його для масштабування компонентів кластера, включаючи критичні для кластера надбудови.

  • Автомасштабування кластера

  • Надбудова Resizer допомагає автоматично змінювати розміри надбудов при зміні масштабу вашого кластера.

2.3.2 - Запуск у кількох зонах

Ця сторінка описує запуск Kubernetes у кількох зонах.

Контекст

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

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

Поведінка панелі управління

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

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

Поведінка вузла

Kubernetes автоматично розподіляє Podʼи для робочих ресурсів (таких як Deployment чи StatefulSet) по різних вузлах кластера. Це розподілення допомагає зменшити вплив відмов.

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

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

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

Розподіл вузлів по зонах

Ядро Kubernetes не створює вузли за вас; вам потрібно це зробити самостійно, або використовувати інструмент, такий як Cluster API, щоб керувати вузлами від вашого імені.

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

Ручне призначення зон для Podʼів

Ви можете застосовувати обмеження селектора вузла до Podʼів, які ви створюєте, а також до шаблонів Podʼів в робочих ресурсах таких як Deployment, StatefulSet або Job.

Доступ до ресурсів зберігання для зон

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

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

Ви можете вказати StorageClass для PersistentVolumeClaims, який вказує домени відмов (зони), які може використовувати сховище в цьому класі. Щоб дізнатися, як налаштувати StorageClass, який опікується доменами відмов або зонами, див. Дозволені топології.

Мережа

Сам по собі Kubernetes не містить мережі, які знається на зонах. Ви можете використовувати мережевий втулок для налаштування мережі кластера, і це мережеве рішення може мати елементи, специфічні для зони. Наприклад, якщо ваш постачальник хмари підтримує служби з type=LoadBalancer, балансир може відправляти трафік лише до Podʼів, які працюють в тій же зоні, що й елемент балансування навантаження, який обробляє ці зʼєднання. Перевірте документацію вашого постачальника хмари для отримання деталей.

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

Відновлення після відмов

При налаштуванні кластера можливо вам також доведеться розглядати можливість та способи відновлення обслуговування, якщо всі зони відмов у регіоні вийдуть з ладу одночасно. Наприклад, чи ви покладаєтесь на те, що принаймні один вузол може виконувати Podʼи в зоні? Переконайтеся, що будь-які роботи з ремонту, критичні для кластера, не покладаються на те, що у вашому кластері є принаймні один справний вузол. Наприклад: якщо всі вузли несправні, вам може знадобитися запустити роботу з ремонту з особливим Toleration, щоб ремонт міг завершити роботу, щоб принаймні один вузол був в робочому стані.

Kubernetes не має відповіді на це виклик; однак це щось, що варто враховувати.

Що далі

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

2.3.3 - Перевірка налаштувань вузла

Тест відповідності вузла

Тест відповідності вузла — це контейнеризований тестовий фреймворк, який надає системну перевірку та тестування функціональності для вузла. Тест перевіряє, чи вузол відповідає мінімальним вимогам Kubernetes; вузол, який успішно проходить тест, має відповідати вимогам для приєднання до кластера Kubernetes.

Передумови вузла

Для запуску тесту відповідності вузла вузол повинен відповідати тим же передумовам, що й стандартний вузол Kubernetes. Принаймні, на вузлі повинні бути встановлені наступні служби:

  • Сумісні з CRI середовища виконання контейнерів, такі як Docker, Containerd та CRI-O
  • Kubelet

Запуск тесту відповідності вузла

Для запуску тесту відповідності вузла виконайте наступні кроки:

  1. Визначте значення параметра --kubeconfig для kubelet, наприклад: --kubeconfig=/var/lib/kubelet/config.yaml. Оскільки тестовий фреймворк запускає локальну панель управління для тестування kubelet, використовуйте http://localhost:8080 як URL API-сервера. Є ще деякі інші параметри командного рядка kubelet, які можна використовувати:

    • --cloud-provider: Якщо ви використовуєте --cloud-provider=gce, ви повинні видалити прапорець для запуску тесту.
  2. Запустіть тест відповідності вузла за допомогою команди:

# $CONFIG_DIR — це шлях до файлу маніфеста под вашого Kubelet.
# $LOG_DIR — це шлях для виведення результатів тесту.
sudo docker run -it --rm --privileged --net=host \
  -v /:/rootfs -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \
  registry.k8s.io/node-test:0.2

Запуск тесту відповідності вузла для інших архітектур

Kubernetes також надає образи Docker для тестування відповідності вузлів для інших архітектур:

АрхітектураОбрази
amd64node-test-amd64
armnode-test-arm
arm64node-test-arm64

Запуск конкретних тестів

Щоб запустити конкретні тести, перезапишіть змінну середовища FOCUS регулярним виразом тестів, які ви хочете запустити.

sudo docker run -it --rm --privileged --net=host \
  -v /:/rootfs:ro -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \
  -e FOCUS=MirrorPod \ # Запустити тільки тест MirrorPod
  registry.k8s.io/node-test:0.2

Щоб пропустити певні тести, перезапишіть змінну середовища SKIP регулярним виразом тестів, які ви хочете пропустити.

sudo docker run -it --rm --privileged --net=host \
  -v /:/rootfs:ro -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \
  -e SKIP=MirrorPod \

 # Запустити всі тести відповідності, але пропустити тест MirrorPod
  registry.k8s.io/node-test:0.2

Тест відповідності вузла — це контейнеризована версія e2e тесту вузла. Стандартно запускаються всі тести відповідності.

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

Обмеження

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

2.3.4 - Запровадження стандартів безпеки для Podʼів

Ця сторінка надає огляд найкращих практик щодо впровадження стандартів безпеки для Podʼів.

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

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

Контролер допуску безпеки Podʼів має на меті замінити застарілі політики безпеки Podʼів (PodSecurityPolicies).

Налаштування для всіх просторів імен кластера

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

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

Принципу найменшого доступу

У ідеальному світі кожен Pod в кожному просторі імен повинен відповідати вимогам політики restricted. Однак це або не можливо, або не практично, оскільки деякі робочі навантаження будуть вимагати підняття привілеїв з певних причин.

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

Використання стратегії мультимодальності

Режими audit та warn контролера впровадження стандартів безпеки Podʼів дозволяють легко збирати важливі відомості щодо безпеки ваших Podʼів без порушення поточних робочих навантажень.

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

Коли режим enforce встановлено як бажаний рівень, ці режими все ще можуть бути корисними декількома різними способами:

  • Встановивши warn на той самий рівень, що й enforce, клієнти отримають попередження при спробі створення Podʼів (або ресурсів, які мають шаблони Podʼів), які не проходять валідацію. Це допоможе їм оновити ці ресурси, щоб вони стали сумісними.
  • В просторах імен, які закріплюють enforce за конкретною не-останньою версією, встановлення режимів audit та warn на той самий рівень, що й enforce, але на latest версію, надає видимість налаштувань, які були дозволені попередніми версіями, але не дозволяються за поточними найкращими практиками.

Альтернативи від сторонніх постачальників

В екосистемі Kubernetes розробляються інші альтернативи для впровадження профілів безпеки:

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

2.3.5 - Сертифікати PKI та вимоги

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

Як кластер використовує сертифікати

Kubernetes вимагає PKI для виконання таких операцій:

Сертифікати сервера

  • Сертифікат сервера для точки доступу API сервера
  • Сертифікат сервера для сервера etcd
  • Сертифікати сервера для кожного kubelet (кожен вузол запускає kubelet)
  • Опціональний сертифікат сервера для front-proxy

Сертифікати клієнта

  • Сертифікати клієнта для кожного kubelet, які використовуються для автентифікації в API сервері як клієнта Kubernetes API
  • Сертифікат клієнта для кожного API сервера, який використовується для автентифікації в etcd
  • Сертифікат клієнта для менеджера контролерів для безпечного звʼязку з API сервером
  • Сертифікат клієнта для планувальника для безпечного звʼязку з API сервером
  • Сертифікати клієнтів для кожного вузла, які використовуються kube-proxy для автентифікації в API сервері
  • Опціональні сертифікати клієнтів для адміністраторів кластера для автентифікації в API сервері
  • Опціональний сертифікат клієнта для front-proxy

Серверні та клієнтські сертифікати Kubelet

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

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

  • Спільні сертифікати: kube-apiserver може використовувати ту ж саму пару сертифікатів та ключів, яку використовує для автентифікації своїх клієнтів. Це означає, що наявні сертифікати, такі як apiserver.crt та apiserver.key, можуть використовуватися для звʼязку з серверами kubelet.

  • Окремі сертифікати: Альтернативно, kube-apiserver може згенерувати новий сертифікат клієнта та пару ключів для автентифікації звʼязку з серверами kubelet. У цьому випадку створюється окремий сертифікат з назвою kubelet-client.crt та відповідний приватний ключ, kubelet-client.key.

etcd також реалізує взаємну аутентифікацію TLS для автентифікації клієнтів.

Де зберігаються сертифікати

Якщо ви встановлюєте Kubernetes за допомогою kubeadm, більшість сертифікатів зберігається в /etc/kubernetes/pki. Усі шляхи в цьому документі стосуються цієї теки, за винятком сертифікатів облікових записів користувачів, які kubeadm розміщує в /etc/kubernetes.

Налаштування сертифікатів вручну

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

Один кореневий ЦС

Ви можете створити один кореневий ЦС, яким керує адміністратор. Цей кореневий ЦС може створювати кілька проміжних ЦС та делегувати весь подальший процес створення Kubernetes.

Необхідні ЦС:

шляхТиповий CNопис
ca.crt,keykubernetes-caЗагальний ЦС Kubernetes
etcd/ca.crt,keyetcd-caДля всіх функцій, повʼязаних з etcd
front-proxy-ca.crt,keykubernetes-front-proxy-caДля проксі-сервера

На додачу до цих ЦС також необхідно отримати пару ключ/сертифікат для управління обліковими записами служби, sa.key та sa.pub. Наведений нижче приклад ілюструє файли ключа та сертифіката ЦС, показані в попередній таблиці:

/etc/kubernetes/pki/ca.crt
/etc/kubernetes/pki/ca.key
/etc/kubernetes/pki/etcd/ca.crt
/etc/kubernetes/pki/etcd/ca.key
/etc/kubernetes/pki/front-proxy-ca.crt
/etc/kubernetes/pki/front-proxy-ca.key

Усі сертифікати

Якщо ви не хочете копіювати приватні ключі ЦС до свого кластера, ви можете створити всі сертифікати самостійно.

Необхідні сертифікати:

Типовий CNБатьківський ЦСO (в обʼєкті)видhosts (SAN)
kube-etcdetcd-caserver, client<hostname>, <Host_IP>, localhost, 127.0.0.1
kube-etcd-peeretcd-caserver, client<hostname>, <Host_IP>, localhost, 127.0.0.1
kube-etcd-healthcheck-clientetcd-caclient
kube-apiserver-etcd-clientetcd-caclient
kube-apiserverkubernetes-caserver<hostname>, <Host_IP>, <advertise_IP>, [1]
kube-apiserver-kubelet-clientkubernetes-casystem:mastersclient
front-proxy-clientkubernetes-front-proxy-caclient

[1]: будь-яка інша IP-адреса чи DNS-імʼя, за яким ви звертаєтеся до свого кластера (що використовується kubeadm для стабільної IP-адреси або DNS-імені балансування навантаження, kubernetes, kubernetes.default, kubernetes.default.svc, kubernetes.default.svc.cluster, kubernetes.default.svc.cluster.local)

де kind посилається на один або кілька ключів x509, які також документовані в .spec.usages типу CertificateSigningRequest:

kindВикористання ключа
serverцифровий підпис, шифрування ключа, автентифікація сервера
clientцифровий підпис, шифрування ключа, автентифікація клієнта

Шляхи до сертифікатів

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

Типовий CNрекомендований шлях до ключарекомендований шлях до сертифікатакомандааргумент ключааргумент сертифіката
etcd-caetcd/ca.keyetcd/ca.crtkube-apiserver--etcd-cafile
kube-apiserver-etcd-clientapiserver-etcd-client.keyapiserver-etcd-client.crtkube-apiserver--etcd-keyfile--etcd-certfile
kubernetes-caca.keyca.crtkube-apiserver--client-ca-file
kubernetes-caca.keyca.crtkube-controller-manager--cluster-signing-key-file--client-ca-file, --root-ca-file, --cluster-signing-cert-file
kube-apiserverapiserver.keyapiserver.crtkube-apiserver--tls-private-key-file--tls-cert-file
kube-apiserver-kubelet-clientapiserver-kubelet-client.keyapiserver-kubelet-client.crtkube-apiserver--kubelet-client-key--kubelet-client-certificate
front-proxy-cafront-proxy-ca.keyfront-proxy-ca.crtkube-apiserver--requestheader-client-ca-file
front-proxy-cafront-proxy-ca.keyfront-proxy-ca.crtkube-controller-manager--requestheader-client-ca-file
front-proxy-clientfront-proxy-client.keyfront-proxy-client.crtkube-apiserver--proxy-client-key-file--proxy-client-cert-file
etcd-caetcd/ca.keyetcd/ca.crtetcd--trusted-ca-file, --peer-trusted-ca-file
kube-etcdetcd/server.keyetcd/server.crtetcd--key-file--cert-file
kube-etcd-peeretcd/peer.keyetcd/peer.crtetcd--peer-key-file--peer-cert-file
etcd-caetcd/ca.crtetcdctl--cacert
kube-etcd-healthcheck-clientetcd/healthcheck-client.keyetcd/healthcheck-client.crtetcdctl--key--cert

Ті ж самі вимоги стосуються пари ключів облікових записів служби:

Шлях приватного ключаШлях публічного ключакомандааргумент
sa.keykube-controller-manager--service-account-private-key-file
sa.pubkube-apiserver--service-account-key-file

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

/etc/kubernetes/pki/etcd/ca.key
/etc/kubernetes/pki/etcd/ca.crt
/etc/kubernetes/pki/apiserver-etcd-client.key
/etc/kubernetes/pki/apiserver-etcd-client.crt
/etc/kubernetes/pki/ca.key
/etc/kubernetes/pki/ca.crt
/etc/kubernetes/pki/apiserver.key
/etc/kubernetes/pki/apiserver.crt
/etc/kubernetes/pki/apiserver-kubelet-client.key
/etc/kubernetes/pki/apiserver-kubelet-client.crt
/etc/kubernetes/pki/front-proxy-ca.key
/etc/kubernetes/pki/front-proxy-ca.crt
/etc/kubernetes/pki/front-proxy-client.key
/etc/kubernetes/pki/front-proxy-client.crt
/etc/kubernetes/pki/etcd/server.key
/etc/kubernetes/pki/etcd/server.crt
/etc/kubernetes/pki/etcd/peer.key
/etc/kubernetes/pki/etcd/peer.crt
/etc/kubernetes/pki/etcd/healthcheck-client.key
/etc/kubernetes/pki/etcd/healthcheck-client.crt
/etc/kubernetes/pki/sa.key
/etc/kubernetes/pki/sa.pub

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

Ви повинні вручну налаштувати ці облікові записи адміністратора та службові облікові записи:

імʼя файлуімʼя облікового записуТиповий CNO (в обʼєкті)
admin.confdefault-adminkubernetes-admin<admin-group>
super-admin.confdefault-super-adminkubernetes-super-adminsystem:masters
kubelet.confdefault-authsystem:node:<nodeName> (див. примітку)system:nodes
controller-manager.confdefault-controller-managersystem:kube-controller-manager
scheduler.confdefault-schedulersystem:kube-scheduler
  1. Для кожної конфігурації створіть пару ключ/сертифікат x509 із зазначеними CN та O.

  2. Виконайте команду kubectl для кожної конфігурації наступним чином:

KUBECONFIG=<filename> kubectl config set-cluster default-cluster --server=https://<host ip>:6443 --certificate-authority <path-to-kubernetes-ca> --embed-certs
KUBECONFIG=<filename> kubectl config set-credentials <credential-name> --client-key <path-to-key>.pem --client-certificate <path-to-cert>.pem --embed-certs
KUBECONFIG=<filename> kubectl config set-context default-system --cluster default-cluster --user <credential-name>
KUBECONFIG=<filename> kubectl config use-context default-system

Ці файли використовуються наступним чином:

Імʼя файлуКомандаКоментар
admin.confkubectlНалаштовує користувача-адміністратора для кластера
super-admin.confkubectlНалаштовує користувача-суперадміністратора для кластера
kubelet.confkubeletОдин обовʼязковий для кожного вузла в кластері
controller-manager.confkube-controller-managerМає бути доданий до manifests/kube-controller-manager.yaml
scheduler.confkube-schedulerМає бути доданий до manifests/kube-scheduler.yaml

Наведені нижче файли ілюструють повні шляхи до файлів, перерахованих у попередній таблиці:

/etc/kubernetes/admin.conf
/etc/kubernetes/super-admin.conf
/etc/kubernetes/kubelet.conf
/etc/kubernetes/controller-manager.conf
/etc/kubernetes/scheduler.conf

3 - Концепції

Розділ "Концепції" допоможе вам дізнатися про складові системи Kubernetes та абстракції, які використовує Kubernetes для представлення вашого кластера, і допоможе вам краще зрозуміти, як працює Kubernetes.

3.1 - Огляд

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

Ця сторінка надає огляд основних концепцій Kubernetes.

Назва Kubernetes (/ˌk(j)uːbərˈnɛtɪs, Кубернетіс) походить від грецького слова, що означає особу, що керує кораблем. K8s — це скорочення Kubernetes, яке складається з першої літери «K», потім восьми літер і, нарешті, літери «s». Google зробив Kubernetes проєктом з відкритим кодом у 2014 році. Kubernetes поєднує понад 15 років досвіду Google у роботі з контейнеризованими навантаженнями з найкращими ідеями та практиками спільноти.

Чому вам потрібен Kubernetes та що він може робити?

Контейнери — це гарний спосіб обʼєднати та запустити ваші застосунки. У промисловому середовищі вам потрібно керувати контейнерами, які запускають застосунки, і гарантувати відсутність простоїв. Наприклад, якщо контейнер падає, повинен запуститися інший контейнер. Чи не було б легше, якби такою поведінкою займалася система?

Ось саме тут Kubernetes приходить на допомогу! Kubernetes надає вам фреймворк для надійного запуску розподілених систем. Він піклується про масштабування та відмовостійкість для ваших застосунків, забезпечує шаблони розгортання тощо. Наприклад: Kubernetes може легко керувати розгортанням канарки (canary deployment) для вашої системи.

Kubernetes надає вам:

  • Виявлення сервісів та балансування Kubernetes може надати доступ до контейнерів застосунків за допомогою внутрішньої IP-адреси та імені DNS. Якщо навантаження на контейнер зростає, Kubernetes може балансувати навантаження та розподіляти мережевий трафік, що робить роботу розгортання стабільною.
  • Оркестрування зберіганням Kubernetes дозволяє автоматично монтувати системи зберігання, такі як локальні пристрої, хмарні ресурси тощо.
  • Автоматизоване розгортання та згортання Ви можете описати бажаний стан вашого розгорнутого контейнера використовуючи Kubernetes, а він може змінювати стан вашого контейнера, щоб відповідати бажаному стану з певним рівнем відповідності. Наприклад, ви можете налаштувати Kubernetes так, щоб він автоматично створював контейнери з вашими застосунками для вашого розгортання, вилучав контейнери, які не використовуються та використовував їх ресурси для нових контейнерів.
  • Автоматичне пакування Ви надаєте Kubernetes кластер вузлів, які він може використовувати для виконання контейнеризованих завдань. Ви вказуєте Kubernetes, скільки процесорних потужностей та памʼяті (ОЗП) потрібно кожному контейнеру. Kubernetes може помістити контейнери на ваші вузли, щоб найкращим чином використовувати ресурси.
  • Самовідновлення Kubernetes перезапускає контейнери, які впали, заміняє контейнери, припиняє роботу контейнерів, які не відповідають визначеному користувачем стану під час перевірки, очікує готовності їх до роботи перш ніж пропонувати їх клієнтам.
  • Секрети та керування конфігураціями Kubernetes дозволяє зберігати та керувати чутливими даними, такими як паролі, OAuth-токени та SSH-ключі. Ви можете розгортати та оновлювати конфігурацію та секрети без перезбирання образу вашого контейнера, без розголошення секретів у вашому стеку конфігурації.
  • Пакетне виконання На додачу до сервісів, Kubernetes може керувати пакетним виконанням процесів та CI завдань, заміщаючи контейнери, що зазнали збою, за потреби.
  • Горизонтальне масштабування Масштабуйте ваші застосунки, збільшуючи чи зменшуючи кількість робочих навантажень, просто командами, за допомогою UI або автоматично залежно від використання ЦП або інших ресурсів.
  • Подвійний стек IPv4/IPv6 Виділення адрес IPv4 та IPv6 для Podʼів та Serviceʼів.
  • Запланована розширюваність Додавайте нові функції до Kubernetes без зміни основного коду Kubernetes.

Чим не є Kubernetes?

Kubernetes не є традиційною, все-в-одному PaaS-платформою (Platform as a Service). Оскільки Kubernetes працює на рівні контейнерів, а не апаратному рівні, він надає деякі загально прийняті функції PaaS, такі як розгортання, масштабування, балансування навантаження та дозволяє користувачам інтегрувати власні рішення для моніторингу, журналювання тощо. Однак, Kubernetes не є монолітом і ці рішення є підʼєднуваними та необовʼязковими. Kubernetes надає вам будівельні блоки, які можна зʼєднати для створення платформи для розробки, але залишає вами вибір та гнучкість саме там де вам це потрібно.

Kubernetes:

  • Не обмежує типи підтримуваних застосунків. Kubernetes прагне підтримувати надзвичайно різноманітні робочі навантаження, включаючи робочі навантаження stateless, stateful та робочі навантаження з обробки даних. Якщо застосунок може працювати в контейнері, він повинен чудово працювати на Kubernetes.
  • Не розгортає код і не збирає ваш застосунок. Робочі процеси безперервної інтеграції, доставки та розгортання (CI/CD) визначаються культурою та уподобаннями організації, а також технічними вимогами.
  • Не надає служби на рівні застосунків, такі як middleware, проміжне програмне забезпечення (наприклад, шини повідомлень), фреймворки обробки даних (наприклад, Spark), бази даних (наприклад, MySQL), кеші або кластерні системи зберігання (наприклад, Ceph) як вбудовані служби. Такі компоненти можуть працювати на Kubernetes та/або бути доступними застосункам, що працюють в Kubernetes, за допомогою механізмів перенесення, таких як Open Service Broker.
  • Не диктує рішення для логування, моніторингу або оповіщення. Він забезпечує деякі інтеграції як доказ концепції та механізми збору та експорту метрик.
  • Не надає та не ставить вимог щодо мови/системної конфігурації (наприклад, Jsonnet). Він надає декларативний API, який може використовуватись довільними формами декларативних специфікацій.
  • Не забезпечує і не приймає будь-які комплексні системи конфігурації машини, обслуговування, управління або самовідновлення.
  • Крім того, Kubernetes — це не просто система оркестрування. Насправді вона усуває необхідність оркестрування. Технічним визначенням оркестрування є виконання визначеного робочого процесу: спочатку зробіть A, потім B, потім C. На відміну від цього, Kubernetes має в собі набір незалежних частин процесів управління, які безперервно рухають поточний стан до вказаного бажаного стану. Не має значення, як ви перейдете від А до С. Централізоване управління також не потрібне. Це призводить до того, що система простіша у використанні та потужніша, надійна, стійка та розширювана.

Назад у минуле

Погляньмо на те, чому Kubernetes настільки корисний, повернувшись в минуле.

Deployment evplution

Ера традиційного розгортання:

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

Ера віртуалізованого розгортання:

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

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

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

Ера контейнеризації:

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

Контейнери набули популярності, оскільки вони надають додаткові вигоди, такі як:

  • Гнучке створення та розгортання застосунків: підвищено простоту та ефективність створення образу контейнера порівняно з використанням образу віртуальної машини.
  • Безперервна розробка, інтеграція та розгортання: забезпечує надійне та часте створення та розгортання образу контейнера зі швидким та ефективним відкатом (через незмінність образу).
  • Розділення Dev та Ops: створення образів контейнерів застосунків під час створення/випуску, а не під час розгортання, тим самим застосунки відокремлюються від інфраструктури.
  • Спостережуваність: не тільки відображає інформацію та метрики на рівні ОС, але й стан застосунків та інші сигнали.
  • Узгодженість оточення розробки, тестування та експлуатації: все працює так само на ноутбуці, як і в хмарі.
  • Переносимість між хмарами та ОС: працює на Ubuntu, RHEL, CoreOS, у приватних хмарах, основних публічних хмарах — всюди.
  • Управління, орієнтоване на застосунки: підвищує рівень абстракції від запуску ОС на віртуальному обладнанні до запуску застосунків в ОС з використанням логічних ресурсів.
  • Вільно повʼязані, розподілені, еластичні, звільнені мікросервіси: застосунки розбиваються на менші, незалежні частини та можуть бути розгорнуті та керовані динамічно — на відміну від монолітного стека, що працює на одній великій спеціально призначеній для цього машині.
  • Ізоляція ресурсів: передбачувана продуктивність застосунків.
  • Використання ресурсів: висока ефективність та щільність.

Що далі

3.1.1 - Компоненти Kubernetes

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

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

Компоненти Kubernetes

Компоненти кластера Kubernetes

Основні компоненти

Кластер Kubernetes складається з панелі управління та одного або декількох робочих вузлів. Ось короткий огляд основних компонентів:

Компоненти панелі управління

Керують загальним станом кластера:

kube-apiserver
Сервер основних компонентів, який надає Kubernetes HTTP API
etcd
Узгоджене та високодоступне сховище значень ключів для всіх даних сервера API
kube-scheduler
Шукає ще не прикріплені до вузла Podʼи та призначає кожен Pod до відповідного вузла.
kube-controller-manager
Запускає контролери для впровадження поведінки API Kubernetes.
cloud-controller-manager (необовʼязково)
Інтегрується з інфраструктурою хмарного постачальника.

Компоненти вузлів

Запускаються на кожному вузлі, підтримуючи запущені Podʼи та надаючи середовище виконання Kubernetes:

kubelet
Забезпечує роботу Podʼів, включно з їхніми контейнерами.
kube-proxy
Підтримує мережеві правила на вузлах для реалізації Services.
Рушій виконання контейнерів
Програмне забезпечення для запуску контейнерів. Дивіться Середовище виконання контейнерів, щоб дізнатись більше.

Надбудови

Надбудови розширюють функціональність Kubernetes. Ось кілька важливих прикладів:

DNS
Для перетворення адрес на назви на рівні всього кластера.
Wеb UI (Dashboard)
Вебінтерфейс для керування кластером Kubernetes.
Container Resource Monitoring
Збирає логи контейнерів в централізоване сховище логів.

Гнучкість архітектури

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

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

3.1.2 - Обʼєкти в Kubernetes

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

Ця сторінка пояснює, як обʼєкти Kubernetes подаються в API Kubernetes, та як ви можете описати їх у форматі .yaml.

Розуміння обʼєктів Kubernetes

Обʼєкти Kubernetes є постійними сутностями в системі Kubernetes. Kubernetes використовує ці сутності для подання стану вашого кластера. Зокрема, вони можуть описувати:

  • Які контейнеризовані застосунки працюють (і на яких вузлах)
  • Ресурси, доступні для цих застосунків
  • Політики щодо того, як ці застосунки поводяться, такі як політики перезапуску, оновлення та стійкості до відмов

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

Для роботи з обʼєктами Kubernetes — чи то для створення, зміни чи видалення — вам потрібно використовувати API Kubernetes. Наприклад, коли ви використовуєте інтерфейс командного рядка kubectl, CLI виконує необхідні виклики API Kubernetes за вас. Ви також можете використовувати API Kubernetes безпосередньо у ваших власних програмах за допомогою однієї з Клієнтських бібліотек.

Специфікація та стан обʼєкта

Майже кожен обʼєкт Kubernetes містить два вкладених поля обʼєкта, які керують конфігурацією обʼєкта: spec та status обʼєкта. Для обʼєктів, які мають spec, вам потрібно встановити його при створенні обʼєкта, надаючи опис характеристик, які ви хочете, щоб ресурс мав: його бажаний стан.

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

Наприклад: в Kubernetes, Deployment є обʼєктом, який може представляти застосунок, який працює на вашому кластері. При створенні Deployment ви можете встановити spec Deployment, щоб вказати, що ви хочете, щоб працювало три репліки застосунку. Система Kubernetes читає spec Deployment та запускає три екземпляри вашого застосунку — оновлюючи status Deployment, щоб віддзеркалювати поточний стан розгорнення. Якщо один цих екземплярів зазнає збою (зміни стану), Kubernetes відреагує на відмінність між spec та status, створивши новий екземпляр, щоб забезпечити, щоб status відповідав spec.

З докладнішою інформацією про spec, status та metadata обʼєктів Kubernetes звертайтесь до Kubernetes API Conventions.

Опис обʼєктів Kubernetes

Коли ви створюєте обʼєкт Kubernetes, ви повинні визначити spec обʼєкта, який описує бажаний стан обʼєкта, а також інші відомості про обʼєкт, наприклад його назву (name). Коли ви використовуєте API Kubernetes для створення обʼєкта, чи безпосередньо, чи за допомогою kubectl, цей запит до API має містити ці відомості у вигляді JSON в тілі запиту. Найчастіше інформація про обʼєкт подається kubectl у вигляді файлу, який називається маніфестом. За домовленістю, маніфести обʼєктів Kubernetes подаються у форматі YAML (ви також можете використовувати JSON). Інструменти, такі як kubectl, перетворюють інформацію з маніфесту у JSON або інший підтримуваний формат серіалізації надсилаючи HTTP-запити до API.

Ось приклад маніфесту, який містить обовʼязкові поля обʼєкта та його spec для Kubernetes Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2 # вказує Deployment запустити 2 Podʼи, що відповідають шаблону
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

Один зі способів створення Deployment за допомогою маніфесту, подібного до показаного вище, — використання команди kubectl apply в інтерфейсі командного рядка kubectl, передаючи файл .yaml як аргумент. Ось так:

kubectl apply -f https://k8s.io/examples/application/deployment.yaml

Вивід буде схожий на цей:

deployment.apps/nginx-deployment created

Обовʼязкові поля

В маніфесті (файл YAML або JSON) обʼєкта Kubernetes, який ви хочете створити, ви повинні вказати значення для наступних обовʼязкових полів:

  • apiVersion — версія API Kubernetes, яку ви використовуєте для створення обʼєкта
  • kind — тип обʼєкта, який ви хочете створити
  • metadata — відомості про обʼєкт, які дозволяють ідентифікувати обʼєкт, включаючи рядок name, який вказує назву обʼєкта, UID, та, необовʼязково, namespace
  • spec — опис бажаного стану обʼєкта

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

Наприклад, подивіться на поле spec для обʼєкта Pod. Для кожного Pod, поле .spec вказує на Pod та його бажаний стан (наприклад, назву образу контейнера для кожного контейнера всередині цього Pod). Інший приклад специфікації обʼєкта — поле spec для обʼєкта StatefulSet. Для StatefulSet, поле .spec вказує на StatefulSet та його бажаний стан. У .spec StatefulSet є template для обʼєктів Pod. Цей шаблон описує Pod, які контролер StatefulSet створить, щоб задовольнити специфікацію StatefulSet. Різні типи обʼєктів Kubernetes можуть мати різні .status; дивіться Kubernetes API Reference для отримання відомостей структуру поля .status та його вміст для кожного типу обʼєкта.

Перевірка полів на стороні сервера

Починаючи з Kubernetes v1.25, API сервера Kubernetes може виконувати перевірку полів на стороні сервера, що дозволяє виявляти невідомі та задвоєні поля в описі обʼєктів. Це надає функціонал kubectl --validate на стороні сервера.

kubectl використовує прапорець --validate для встановлення рівня перевірки полів маніфесту. Його значенням може бути ignore, warn та strict, також можна вказати true (еквівалент strict) та false (еквівалент ignore). Типове значення перевірки для kubectl — --validate=true.

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

Якщо kubectl не може підʼєднатися до API сервера, він використовує локальну перевірку, яка виконується на стороні клієнта. Kubernetes v1.27 та пізніші версії завжди пропонуватимуть перевірку полів; версії до v1.27, скоріш за все — ні. Якщо версія Kubernetes на вашому кластері старіша за v1.27, звіртесь з документацією до вашої версії Kubernetes.

Що далі

Якщо ви тільки починаєте свій шлях з Kubernetes, дізнайтесь більше про:

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

Щоб дізнатись про API Kubernetes, зверніться до:

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

3.1.2.1 - Управління обʼєктами Kubernetes

Інструмент командного рядка kubectl підтримує кілька різних способів створення та управління обʼєктами Kubernetes. Цей документ надає огляд різних підходів. Для отримання деталей щодо управління обʼєктами за допомогою Kubectl читайте Книгу Kubectl.

Техніки управління

Техніка управлінняДіє наРекомендоване середовищеПідтримувані інструментиКрива навчання
Імперативні командиЖиві обʼєктиПроєкти розробки1+Налегша
Імперативна конфігурація обʼєктівОкремі файлиПродуктові проєкти1Середня
Декларативна конфігурація обʼєктівТеки файлівПродуктові проєкти1+Найскладніша

Імперативні команди

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

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

Приклади

Запустіть екземпляр контейнера nginx, створивши обʼєкт розгортання (Deployment):

kubectl create deployment nginx --image nginx

Компроміси

Переваги порівняно із конфігуруванням обʼєктів:

  • Команди виражені як одне слово дії.
  • Команди вимагають лише одного кроку для внесення змін до кластера.

Недоліки порівняно із конфігуруванням обʼєктів:

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

Імперативне конфігурування обʼєктів

У імперативній конфігурації обʼєктів команда kubectl вказує операцію (створити, замінити інше), необовʼязкові прапорці та принаймні одне імʼя файлу. Зазначений файл повинен містити повне визначення обʼєкта у форматі YAML або JSON.

Див. API-довідник для отримання докладніших відомостей щодо визначення обʼєктів.

Приклади

Створити обʼєкти, визначені у файлі конфігурації:

kubectl create -f nginx.yaml

Видалити обʼєкти, визначені у двох файлах конфігурації:

kubectl delete -f nginx.yaml -f redis.yaml

Оновити обʼєкти, визначені у файлі конфігурації, перезаписавши живу конфігурацію:

kubectl replace -f nginx.yaml

Компроміси

Переваги порівняно з імперативними командами:

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

Недоліки порівняно з імперативними командами:

  • Конфігурація обʼєктів потребує базового розуміння схеми обʼєкта.
  • Конфігурація обʼєктів потребує додаткового кроку у вигляді написання файлу YAML.

Переваги порівняно із декларативною конфігурацією обʼєктів:

  • Поведінка імперативної конфігурації обʼєктів простіша та її легше зрозуміти.
  • З версії Kubernetes 1.5 імперативна конфігурація обʼєктів більш зріла.

Недоліки порівняно із декларативною конфігурацією обʼєктів:

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

Декларативна конфігурація обʼєктів

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

Приклади

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

kubectl diff -f configs/
kubectl apply -f configs/

Рекурсивно обробити теки:

kubectl diff -R -f configs/
kubectl apply -R -f configs/

Компроміси

Переваги порівняно з імперативною конфігурацією обʼєктів:

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

Недоліки порівняно з імперативною конфігурацією обʼєктів:

  • Декларативна конфігурація обʼєктів важко налагоджувати, і результати її роботи важко зрозуміти, коли вони несподівані.
  • Часткові оновлення за допомогою відміток створюють складні операції злиття та накладання патчів.

Що далі

3.1.2.2 - Назви та Ідентифікатори Обʼєктів

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

Наприклад, ви можете мати лише один обʼєкт Pod із назвою myapp-1234 в просторі імен з такою ж назвою, а також ви можете мати один обʼєкт Pod та один Deployment із назвами myapp-1234 кожен.

Для неунікальних атрибутів, наданих користувачем, Kubernetes надає мітки (labels) та анотації (annotations).

Назви

Наданий клієнтом рядок, який посилається на обʼєкт в URL ресурсу, наприклад /api/v1/pods/some-name.

Тільки один обʼєкт вказаного виду (kind) може мати вказану назву одночасно. Проте, якщо ви видаляєте обʼєкт, ви можете створити новий обʼєкт з такою ж назвою.

Назви повинні бути унікальними між усіма версіями API того ж самого ресурсу. Ресурси API відрізняються своєю API-групою, типом ресурсу, простором імен (для ресурсів із просторами імен) та назвою. Іншими словами, версія API не має значення в цьому контексті.

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

Назви DNS-піддоменів

Більшість типів ресурсів потребують назви, яку можна використовувати як DNS-піддомен згідно з RFC 1123. Це означає, що назва повинна:

  • містити не більше 253 символів
  • містити лише буквено-цифрові символи, '-' чи '.' в нижньому регістрі
  • починатися буквено-цифровим символом
  • закінчуватися буквено-цифровим символом

Назви міток RFC 1123

Деякі типи ресурсів вимагають, щоб їх назви відповідали стандарту DNS як визначено в RFC 1123. Це означає, що назва повинна:

  • містити не більше 63 символів
  • містити лише буквено-цифрові символи чи '-' в нижньому регістрі
  • починатися буквено-цифровим символом
  • закінчуватися буквено-цифровим символом

Назви міток RFC 1035

Деякі типи ресурсів вимагають, щоб їх назви відповідали стандарту DNS як визначено в RFC 1035. Це означає, що назва повинна:

  • містити не більше 63 символів
  • містити лише буквено-цифрові символи чи '-' в нижньому регістрі
  • починатися алфавітним символом
  • закінчуватися буквено-цифровим символом

Назви сегментів шляху

Деякі типи ресурсів вимагають, щоб їх назви можна було безпечно кодувати як сегмент шляху. Іншими словами, назва не може бути "." або "..", і вона не може містити "/" або "%".

Ось приклад маніфесту для Pod із назвою nginx-demo.

apiVersion: v1
kind: Pod
metadata:
  name: nginx-demo
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80

UID

Рядок, створений системами Kubernetes для унікальної ідентифікації обʼєктів.

Кожен обʼєкт, створений протягом усього життя кластера Kubernetes, має відмінний UID. Він призначений для відмінності між історичними випадками схожих сутностей.

UID Kubernetes — це унікальні ідентифікатори, також відомі як UUID (узгоджені універсальні ідентифікатори). UUID стандартизовані згідно з ISO/IEC 9834-8 та ITU-T X.667.

Що далі

3.1.2.3 - Мітки та Селектори

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

"metadata": {
  "labels": {
    "key1" : "value1",
    "key2" : "value2"
  }
}

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

Мотивація

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

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

Приклади міток:

  • "release" : "stable", "release" : "canary"
  • "environment" : "dev", "environment" : "qa", "environment" : "production"
  • "tier" : "frontend", "tier" : "backend", "tier" : "cache"
  • "partition" : "customerA", "partition" : "customerB"
  • "track" : "daily", "track" : "weekly"

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

Синтаксис та набір символів

Мітки — це пари ключ/значення. Дійсні ключі міток мають два сегменти: необовʼязковий префікс та назву, розділені слешем (/). Сегмент назви є обовʼязковим і має бути не більше 63 символів, починатися та закінчуватися буквено-цифровим символом ([a-z0-9A-Z]) з дефісами (-), підкресленнями (_), крапками (.), та буквено-цифровими символами між ними. Префікс є необовʼязковим. Якщо вказаний, префікс повинен бути піддоменом DNS: серією DNS-міток, розділених крапками (.), не довше 253 символів загалом, за яким слідує слеш (/).

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

Префікси kubernetes.io/ та k8s.io/ є зарезервованими для основних компонентів Kubernetes.

Дійсне значення мітки:

  • повинно бути не більше 63 символів (може бути порожнім),
  • крім порожнього значення, повинно починатися та закінчуватися буквено-цифровим символом ([a-z0-9A-Z]),
  • може містити дефіси (-), підкреслення (_), крапки (.), та буквено-цифрові символи між ними.

Наприклад, ось маніфест для Pod із двома мітками environment: production та app: nginx:

apiVersion: v1
kind: Pod
metadata:
  name: label-demo
  labels:
    environment: production
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80

Селектори міток

На відміну від назв та UID, мітки не забезпечують унікальності. Загалом, ми очікуємо, що багато обʼєктів матимуть ті ж самі мітки.

За допомогою селектора міток користувач може ідентифікувати набір обʼєктів. Селектор міток є основним примітивом гуртування в Kubernetes.

На цей момент API підтримує два типи селекторів: equality-based та set-based. Селектор міток може складатися з кількох вимог, які розділені комами. У випадку кількох вимог всі повинні бути задоволені, таким чином кома виступає логічним оператором AND (&&).

Equality-based вимоги

Вимоги Equality- чи inequality-based дозволяють фільтрувати обʼєкти за ключами та значеннями міток. Відповідні обʼєкти повинні задовольняти всі вказані обмеження міток, хоча вони можуть мати додаткові мітки також. Допускаються три види операторів: =, ==, !=. Перший та другий представляють рівність (equality) і є синонімами, тоді як останній представляє нерівність (inequality). Наприклад:

environment = production
tier != frontend

Перший вибирає всі ресурси з ключем environment та значенням production. Другий вибирає всі ресурси з ключем tier та значеннями відмінним від frontend, та всі ресурси без міток з ключем tier. Можна використовувати оператор коми для фільтрації ресурсів у production, іншими словами, environment=production,tier!=frontend.

Один зі сценаріїв використання вимог на основі рівності використовується для Podʼів, які вказують критерії вибору вузлів. Наприклад, зразок Podʼа нижче вибирає вузли з міткою accelerator зі значенням "accelerator=nvidia-tesla-p100".

apiVersion: v1
kind: Pod
metadata:
  name: cuda-test
spec:
  containers:
    - name: cuda-test
      image: "registry.k8s.io/cuda-vector-add:v0.1"
      resources:
        limits:
          nvidia.com/gpu: 1
  nodeSelector:
    accelerator: nvidia-tesla-p100

Set-based вимоги

Вимоги на основі множини дозволяють фільтрувати ключі за набором значень. Підтримуються три види операторів: in, notin та exists (тільки ідентифікатор ключа). Наприклад:

environment in (production, qa)
tier notin (frontend, backend)
partition
!partition
  • Перший приклад вибирає всі ресурси з ключем, рівним environment та значенням рівним production або qa.
  • Другий приклад вибирає всі ресурси з ключем, рівним tier та значеннями іншими ніж frontend та backend, та всі ресурси без міток з ключем tier.
  • Третій приклад вибирає всі ресурси, включаючи мітку з ключем partition; значення не перевіряються.
  • Четвертий приклад вибирає всі ресурси без мітки з ключем partition; значення не перевіряються.

Так само розділювач коми діє як AND оператор. Таким чином, фільтрування ресурсів з ключем partition (без значення) та з environment відмінним від qa може бути досягнуто за допомогою partition,environment notin (qa). Вимоги на основі множини є загальною формою вимог на основі рівності, оскільки environment=production еквівалентно environment in (production); так само для != та notin.

Вимоги на основі множини можна комбінувати з вимогами на основі рівності. Наприклад: partition in (customerA, customerB),environment!=qa.

API

Фільтрація LIST та WATCH

Для операцій list і watch ви можете вказати селектори міток для фільтрації наборів обʼєктів що повертаються; фільтр задається за допомогою параметра запиту. (Щоб дізнатися докладніше про watch у Kubernetes, прочитайте ефективне виявлення змін). Обидві вимоги дозволені (тут подано так, як вони з'являться у рядку URL-запиту):

  • вимоги на основі рівності: ?labelSelector=environment%3Dproduction,tier%3Dfrontend
  • вимоги на основі множини: ?labelSelector=environment+in+%28production%2Cqa%29%2Ctier+in+%28frontend%29

Обидва стилі селекторів міток можуть бути використані для переліку чи перегляду ресурсів через клієнта REST. Наприклад, спрямовуючись до apiserver за допомогою kubectl та використовуючи вимогу на основі рівності, можна написати:

kubectl get pods -l environment=production,tier=frontend

чи використовуючи вимогу на основі множини:

kubectl get pods -l 'environment in (production),tier in (frontend)'

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

kubectl get pods -l 'environment in (production, qa)'

чи обмежувати відʼємний збіг за допомогою оператора notin:

kubectl get pods -l 'environment,environment notin (frontend)'

Посилання в API-обʼєктах

Деякі обʼєкти Kubernetes, такі як services та replicationcontrollers, також використовують селектори міток для вказівки наборів інших ресурсів, таких як Podʼи.

Service та ReplicationController

Множина Podʼів, яку service вибирає, визначається селектором міток. Так само, популяція Podʼів, якою replicationcontroller повинен керувати, також визначається селектором міток.

Селектори міток для обох обʼєктів визначаються в файлах json або yaml за допомогою звʼязування та підтримуються лише equality-based селектори:

"selector": {
    "component" : "redis",
}

або

selector:
  component: redis

Цей селектор (відповідно у форматі json або yaml) еквівалентний component=redis або component in (redis).

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

Нові ресурси, такі як Job, Deployment, ReplicaSet, та DaemonSet, також підтримують вимоги на основі множин.

selector:
  matchLabels:
    component: redis
  matchExpressions:
    - { key: tier, operator: In, values: [cache] }
    - { key: environment, operator: NotIn, values: [dev] }

matchLabels — це звʼязування з парами {key,value}. Одна пара {key,value} у звʼязці matchLabels еквівалентна елементу matchExpressions, де поле key — це "key", оператор — "In", а масив values містить лише "value". matchExpressions - це список вимог селектора для вибору Podʼів. Допустимі оператори включають In, NotIn, Exists, та DoesNotExist. Масив values повинен бути непорожнім у випадку In та NotIn. Всі вимоги, як з matchLabels, так і з matchExpressions, йдуть разом з логічною операцією AND — всі вони повинні бути задоволені для збігу.

Вибір множини вузлів

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

Ефективне використання міток

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

Наприклад, різні застосунки можуть використовувати різні значення для мітки app, але багаторівневий застосунок, такий як приклад гостьової книги, додатково повинен відрізняти кожний рівень. Фронтенд може мати наступні мітки:

labels:
  app: guestbook
  tier: frontend

тоді як Redis master та replica можуть мати різні мітки tier, і, можливо, навіть додаткову мітку role:

labels:
  app: guestbook
  tier: backend
  role: master

та

labels:
  app: guestbook
  tier: backend
  role: replica

Мітки дозволяють розрізняти ресурси по будь-якому виміру, зазначеному міткою:

kubectl apply -f examples/guestbook/all-in-one/guestbook-all-in-one.yaml
kubectl get pods -Lapp -Ltier -Lrole
NAME                           READY  STATUS    RESTARTS   AGE   APP         TIER       ROLE
guestbook-fe-4nlpb             1/1    Running   0          1m    guestbook   frontend   <none>
guestbook-fe-ght6d             1/1    Running   0          1m    guestbook   frontend   <none>
guestbook-fe-jpy62             1/1    Running   0          1m    guestbook   frontend   <none>
guestbook-redis-master-5pg3b   1/1    Running   0          1m    guestbook   backend    master
guestbook-redis-replica-2q2yf  1/1    Running   0          1m    guestbook   backend    replica
guestbook-redis-replica-qgazl  1/1    Running   0          1m    guestbook   backend    replica
my-nginx-divi2                 1/1    Running   0          29m   nginx       <none>     <none>
my-nginx-o0ef1                 1/1    Running   0          29m   nginx       <none>     <none>
kubectl get pods -lapp=guestbook,role=replica
NAME                           READY  STATUS   RESTARTS  AGE
guestbook-redis-replica-2q2yf  1/1    Running  0         3m
guestbook-redis-replica-qgazl  1/1    Running  0         3m

Оновлення міток

Іноді вам може знадобитися переозначити наявні Podʼи та інші ресурси перед створенням нових ресурсів. Це можна зробити за допомогою kubectl label. Наприклад, якщо ви хочете позначити всі свої NGINX Podʼи як рівень фронтенду, виконайте:

kubectl label pods -l app=nginx tier=fe
pod/my-nginx-2035384211-j5fhi labeled
pod/my-nginx-2035384211-u2c7e labeled
pod/my-nginx-2035384211-u3t6x labeled

Спочатку фільтруються всі Podʼи з міткою "app=nginx", а потім вони позначаються як "tier=fe". Щоб переглянути Podʼи, які ви позначили, виконайте:

kubectl get pods -l app=nginx -L tier
NAME                        READY     STATUS    RESTARTS   AGE       TIER
my-nginx-2035384211-j5fhi   1/1       Running   0          23m       fe
my-nginx-2035384211-u2c7e   1/1       Running   0          23m       fe
my-nginx-2035384211-u3t6x   1/1       Running   0          23m       fe

Це виводить всі Podʼи "app=nginx", з додатковим стовпчиком міток рівня Podʼів (вказаним за допомогою -L або --label-columns).

Для отримання додаткової інформації, будь ласка, див. kubectl label.

Що далі

3.1.2.4 - Простори імен

В Kubernetes простори імен (namespaces) забезпечують механізм для ізоляції груп ресурсів в межах одного кластера. Імена ресурсів повинні бути унікальними в межах простору імен, але не між просторами імен. Засноване на просторах імен обмеження застосовується лише до обʼєктів, які входять до простору імен (наприклад, Deployments, Services тощо), а не до обʼєктів, що поширюються на весь кластер (наприклад, StorageClass, Вузли, PersistentVolumes тощо).

Коли використовувати кілька просторів імен

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

Простори імен визначають область імен. Назви ресурсів повинні бути унікальними в межах простору імен, але не між просторами імен. Простори імен не можуть бути вкладені один в одного, і кожен ресурс Kubernetes може бути лише в одному просторі імен.

Простори імен — це спосіб розділити ресурси кластера між кількома користувачами (за допомогою квот ресурсів).

Не обовʼязково використовувати кілька просторів імен для відокремлення трохи відмінних ресурсів, таких як різні версії одного й того ж програмного забезпечення: використовуйте мітки для розрізнення ресурсів в межах одного простору імен.

Початкові простори імен

Після запуску в Kubernetes є чотирьох початкових простори імен:

default
Kubernetes включає цей простір імен, щоб ви могли почати використовувати новий кластер без попереднього створення простору імен.
kube-node-lease
Цей простір імен містить обʼєкти Оренди, повʼязані з кожним вузлом. Обʼєкти оренди дозволяють kubelet відправляти імпульси, щоб панель управління могла виявити відмову вузла.
kube-public
Цей простір імен може бути прочитаний усіма клієнтами (включаючи тих, які не автентифіковані). Цей простір імен в основному призначений для внутрішнього використання кластером, у випадку, коли деякі ресурси повинні бути видимими та доступними публічно по всьому кластеру. Публічний аспект цього простору імен — це лише домовленість, яка не є обовʼязковою.
kube-system
Простір імен для обʼєктів, створених системою Kubernetes.

Робота з просторами імен

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

Перегляд просторів імен

Ви можете переглянути поточні простори імен у кластері за допомогою:

kubectl get namespace
NAME              STATUS   AGE
default           Active   1d
kube-node-lease   Active   1d
kube-public       Active   1d
kube-system       Active   1d

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

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

Наприклад:

kubectl run nginx --image=nginx --namespace=<insert-namespace-name-here>
kubectl get pods --namespace=<insert-namespace-name-here>

Встановлення обраного простору імен

Ви можете постійно зберігати простір імен для всіх подальших команд kubectl в даному контексті.

kubectl config set-context --current --namespace=<insert-namespace-name-here>
# Перевірте його
kubectl config view --minify | grep namespace:

Простори імен та DNS

При створенні Service, створюється відповідний DNS запис. Цей запис має форму <service-name>.<namespace-name>.svc.cluster.local, що означає, що якщо контейнер використовує тільки <service-name>, він буде звертатись до сервісу, який є локальним для простору імен. Це корисно для використання одного і того ж конфігураційного файлу в кількох просторах імен, таких як Development, Staging та Production. Якщо вам потрібно досягти обʼєкта в іншому просторі імен, вам слід використовувати повне кваліфіковане доменне імʼя (FQDN).

Отже, всі імена просторів імен повинні бути дійсними DNS-мітками згідно RFC 1123.

Не всі обʼєкти мають простори імен

Більшість ресурсів Kubernetes (наприклад, pods, services, replication controllers та інші) є в деяких просторах імен. Однак ресурси простору імен самі не перебувають в просторі імен. І ресурси низького рівня, такі як nodes та persistentVolumes, не перебувають в жодному просторі імен.

Щоб переглянути, які ресурси Kubernetes є в просторі імен, а які — ні:

# В просторі імен
kubectl api-resources --namespaced=true

# Не в просторі імен
kubectl api-resources --namespaced=false

Автоматичне маркування

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

Панель управління Kubernetes встановлює незмінювану мітку kubernetes.io/metadata.name для всіх просторів імен. Значення мітки — це назва простору імен.

Що далі

3.1.2.5 - Анотації

Ви можете використовувати анотації Kubernetes, щоб додати довільні невизначені метадані до обʼєктів. Клієнти, такі як інструменти та бібліотеки, можуть отримувати ці метадані.

Додавання метаданих до обʼєктів

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

Анотації, подібно до міток, є парами ключ/значення:

"metadata": {
  "annotations": {
    "key1" : "value1",
    "key2" : "value2"
  }
}

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

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

  • Інформація про збірку, реліз чи образ, така як часові мітки, ідентифікатори релізу, гілка git, номера PR, хеші образу та адреса реєстру.

  • Вказівники на репозиторії логування, моніторингу, аналітики чи аудиту.

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

  • Інформація про походження користувача чи інструменту/системи, така як URL-адреси повʼязаних обʼєктів з інших компонентів екосистеми.

  • Метадані інструменту легкого розгортання: наприклад, конфігурація чи контрольні точки.

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

  • Директиви від кінцевого користувача до реалізації щодо зміни поведінки чи використання нестандартних функцій.

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

Синтаксис та набір символів

Анотації — це пари ключ/значення. Допустимі ключі анотацій мають два сегменти: необовʼязковий префікс і назва, розділені косою рискою (/). Назва є обовʼязковою та має містити не більше 63 символів, починаючи та закінчуючись буквено-цифровим символом ([a-z0-9A-Z]), тире (-), підкресленням (_), крапкою (.) та буквено-цифровими символами між ними. Префікс є необовʼязковим. Якщо вказано, префікс повинен бути піддоменом DNS: серією DNS-міток, розділених крапками (.), загальною довжиною не більше 253 символів, за якою слідує коса риска (/).

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

Префікси kubernetes.io/ та k8s.io/ зарезервовані для основних компонентів Kubernetes.

Наприклад, ось маніфест для Pod, який має анотацію imageregistry: https://hub.docker.com/:

apiVersion: v1
kind: Pod
metadata:
  name: annotations-demo
  annotations:
    imageregistry: "https://hub.docker.com/"
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80

Що далі

3.1.2.6 - Селектори полів

Селектори полів дозволяють вам вибирати обʼєкти Kubernetes на основі значень одного або кількох полів ресурсу. Ось кілька прикладів запитань для селекторів полів:

  • metadata.name=my-service
  • metadata.namespace!=default
  • status.phase=Pending

Ця команда kubectl вибирає всі Podʼи, для яких значення поля status.phase дорівнює Running:

kubectl get pods --field-selector status.phase=Running

Підтримувані поля

Підтримувані селектори полів варіюються залежно від типу ресурсу Kubernetes. Усі типи ресурсів підтримують поля metadata.name та metadata.namespace. Використання селекторів до полів, що їх не підтримують, призводить до помилки. Наприклад:

kubectl get ingress --field-selector foo.bar=baz
Error from server  (BadRequest): Unable to find "ingresses" that match label selector "", field selector "foo.bar=baz": "foo.bar" is not a known field selector: only "metadata.name", "metadata.namespace"

Список підтримуваних полів

ВидПоля
Podspec.nodeName
spec.restartPolicy
spec.schedulerName
spec.serviceAccountName
spec.hostNetwork
status.phase
status.podIP
status.nominatedNodeName
EventinvolvedObject.kind
involvedObject.namespace
involvedObject.name
involvedObject.uid
involvedObject.apiVersion
involvedObject.resourceVersion
involvedObject.fieldPath
reason
reportingComponent
source
type
Secrettype
Namespacestatus.phase
ReplicaSetstatus.replicas
ReplicationControllerstatus.replicas
Jobstatus.successful
Nodespec.unschedulable
CertificateSigningRequestspec.signerName

Підтримувані оператори

Ви можете використовувати оператори =, == та != з селекторами полів (= та == означають те саме). Наприклад, ця команда kubectl вибирає всі сервіси Kubernetes, які не знаходяться в просторі імен default:

kubectl get services  --all-namespaces --field-selector metadata.namespace!=default

Ланцюжки селекторів

Як і з мітками та іншими селекторами, селектори полів можна складати у список, розділений комами. Ця команда kubectl вибирає всі Podʼи, для яких значення status.phase не дорівнює Running, а поле spec.restartPolicy дорівнює Always:

kubectl get pods --field-selector=status.phase!=Running,spec.restartPolicy=Always

Кілька типів ресурсів

Ви можете використовувати селектори полів для кількох типів ресурсів. Ця команда kubectl вибирає всі Statefulsets та Services, які не знаходяться в просторі імен default:

kubectl get statefulsets,services --all-namespaces --field-selector metadata.namespace!=default

3.1.2.7 - Завершувачі

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

Коли ви наказуєте Kubernetes видалити обʼєкт, для якого є завершувачі, API Kubernetes позначає обʼєкт для видалення, заповнюючи поле .metadata.deletionTimestamp, і повертає статус-код 202 (HTTP "Accepted"). Цільовий обʼєкт залишається в стані завершення, поки панель управління чи інші компоненти виконують дії, визначені завершувачами. Після завершення цих дій контролер видаляє відповідні завершувачі з цільового обʼєкта. Коли поле metadata.finalizers порожнє, Kubernetes вважає видалення завершеним і видаляє обʼєкт.

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

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

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

Як працюють завершувачі

При створенні ресурсу за допомогою файлу маніфесту ви можете вказати завершувачі у полі metadata.finalizers. Коли ви намагаєтеся видалити ресурс, сервер API, що обробляє запит на видалення, помічає значення у полі finalizers і робить наступне:

  • Модифікує обʼєкт, додаючи поле metadata.deletionTimestamp з часом, коли ви почали видалення.
  • Запобігає видаленню обʼєкта, поки всі елементи не будуть видалені з його поля metadata.finalizers.
  • Повертає код статусу 202 (HTTP "Accepted")

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

Розповсюджений приклад завершувача — kubernetes.io/pv-protection, який запобігає випадковому видаленню обʼєктів PersistentVolume. Коли обʼєкт PersistentVolume використовується у Podʼі, Kubernetes додає завершувач pv-protection. Якщо ви намагаєтеся видалити PersistentVolume, він потрапляє в стан Terminating, але контролер не може видалити його через наявність завершувача. Коли Pod перестає використовувати PersistentVolume, Kubernetes очищує завершувач pv-protection, і контролер видаляє обʼєкт.

Власники, мітки та завершувачі

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

Контролер Завдання також додає посилання на власника до цих Podʼів, посилаючись на Завдання, яке створило Podʼи. Якщо ви видаляєте Завдання, поки ці Podʼи працюють, Kubernetes використовує посилання на власника (а не мітки), щоб визначити, які Podʼи в кластері потрібно прибрати.

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

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

Що далі

3.1.2.8 - Власники та Залежності

В Kubernetes деякі обʼєкти є власниками інших обʼєктів. Наприклад, ReplicaSet є власником групи Podʼів. Ці обʼєкти, якими володіють, є залежними від свого власника.

Власність відрізняється від механізму міток та селекторів, який також використовують деякі ресурси. Наприклад, розгляньте Service, який створює обʼєкти EndpointSlice. Service використовує мітки щоби панель управління могла визначити, які обʼєкти EndpointSlice використовуються для цього Service. Крім того, до міток, кожен EndpointSlice, який керується від імені Service, має посилання на власника. Посилання на власника допомагають різним частинам Kubernetes уникати втручання в обʼєкти, якими вони не керують.

Посилання на власника в специфікаціях обʼєктів

Залежні обʼєкти мають поле metadata.ownerReferences, яке містить посилання на їх власника. Дійсне посилання на власника складається з назви обʼєкта та UID в межах того ж простору імен, що й залежний обʼєкт. Kubernetes автоматично встановлює значення цього поля для обʼєктів, які є залежностями інших обʼєктів, таких як ReplicaSets, DaemonSets, Deployments, Jobs and CronJobs, та ReplicationControllers. Ви також можете налаштувати ці звʼязки вручну, змінивши значення цього поля. Однак зазвичай цього не потрібно робити, і можна дозволити Kubernetes автоматично керувати цими звʼязками.

Залежні обʼєкти також мають поле ownerReferences.blockOwnerDeletion, яке має булеве значення і контролює, чи можуть певні залежні обʼєкти блокувати збір сміття, що видаляє їх власника. Kubernetes автоматично встановлює це поле в true, якщо контролер (наприклад, контролер Deployment) встановлює значення поля metadata.ownerReferences. Ви також можете встановити значення поля blockOwnerDeletion вручну, щоб контролювати, які залежні обʼєкти блокують збір сміття.

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

Власність та завершувачі

Коли ви наказуєте Kubernetes видалити ресурс, сервер API дозволяє керуючому контролеру обробити будь-які правила завершувача для ресурсу. Завершувачі запобігають випадковому видаленню ресурсів, які вашому кластеру можуть ще бути потрібні для коректної роботи. Наприклад, якщо ви намагаєтеся видалити PersistentVolume, який все ще використовується Podʼом, видалення не відбувається негайно, оскільки PersistentVolume має завершувач kubernetes.io/pv-protection. Замість цього том залишається в стані Terminating до тих пір, поки Kubernetes не очистить завершувач, що відбувається тільки після того, як PersistentVolume більше не привʼязаний до Podʼа.

Kubernetes також додає завершувачів до ресурсу-власника, коли ви використовуєте або переднє або інше каскадне видалення. При передньому видаленні додається завершувач foreground, так що контролер повинен видалити залежні ресурси, які також мають ownerReferences.blockOwnerDeletion=true, перш ніж він видалить власника. Якщо ви вказуєте політику видалення покинутих ресурсів (сиріт), Kubernetes додає завершувач orphan, так що контролер ігнорує залежні ресурси після того, як він видаляє обʼєкт-власника.

Що далі

3.1.2.9 - Рекомендовані Мітки

Ви можете візуалізувати та керувати обʼєктами Kubernetes за допомогою інших інструментів, ніж kubectl та панель інструментів (dashboard). Загальний набір міток дозволяє інструментам працювати між собою, описуючи обʼєкти спільним чином, який можуть розуміти всі інструменти.

Крім підтримки інструментів, рекомендовані мітки описують застосунки так, що до них можна звертатись.

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

Спільні мітки та анотації мають спільний префікс: app.kubernetes.io. Мітки без префіксу є приватними для користувачів. Спільний префікс забезпечує, що спільні мітки не втручаються у власні мітки користувача.

Мітки

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

КлючОписПрикладТип
app.kubernetes.io/nameНазва застосункуmysqlрядок
app.kubernetes.io/instanceУнікальна назва, що ідентифікує екземпляр застосункуmysql-abcxyzрядок
app.kubernetes.io/versionПоточна версія застосунку (наприклад, SemVer 1.0, хеш ревізії і т.д.)5.7.21рядок
app.kubernetes.io/componentКомпонент всередині архітектуриdatabaseрядок
app.kubernetes.io/part-ofНазва вищого рівня застосунку, частину якого складає цейwordpressрядок
app.kubernetes.io/managed-byІнструмент, який використовується для управління операцією застосункуHelmрядок

Щоб проілюструвати ці мітки в дії, розгляньте наступний обʼєкт StatefulSet:

# Це уривок
apiVersion: apps/v1
kind: StatefulSet
metadata:
  labels:
    app.kubernetes.io/name: mysql
    app.kubernetes.io/instance: mysql-abcxyz
    app.kubernetes.io/version: "5.7.21"
    app.kubernetes.io/component: database
    app.kubernetes.io/part-of: wordpress
    app.kubernetes.io/managed-by: Helm

Застосунки та екземпляри застосунків

Застосунок можна встановити один або декілька разів в кластер Kubernetes і, у деяких випадках, в тому ж просторі імен. Наприклад, WordPress можна встановити більше одного разу, де різні вебсайти є різними екземплярами WordPress.

Назва застосунку та назва екземпляра записуються окремо. Наприклад, у WordPress є app.kubernetes.io/name — wordpress, тоді як назва екземпляра представлена як app.kubernetes.io/instance зі значенням wordpress-abcxyz. Це дозволяє ідентифікувати застосунок та його екземпляр. Кожен екземпляр застосунку повинен мати унікальну назву.

Приклади

Щоб проілюструвати різні способи використання цих міток, наведено різні приклади складності.

Простий Stateless Service

Розгляньте випадок простого Stateless Serviceʼу, розгорнутого за допомогою обʼєктів Deployment та Service. Наведені нижче два уривки представляють, як можуть бути використані мітки у їх найпростішій формі.

Deployment використовується для нагляду за Podʼами, які виконують сам застосунок.

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app.kubernetes.io/name: myservice
    app.kubernetes.io/instance: myservice-abcxyz
...

Service використовується для відкриття доступу до застосунку.

apiVersion: v1
kind: Service
metadata:
  labels:
    app.kubernetes.io/name: myservice
    app.kubernetes.io/instance: myservice-abcxyz
...

Вебзастосунок із базою даних

Розгляньмо трохи складніший застосунок: вебзастосунок (WordPress) із базою даних (MySQL), встановлений за допомогою Helm. Наведені нижче уривки ілюструють початок обʼєктів, які використовуються для розгортання цього застосунку.

Початок цього Deployment використовується для WordPress:

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app.kubernetes.io/name: wordpress
    app.kubernetes.io/instance: wordpress-abcxyz
    app.kubernetes.io/version: "4.9.4"
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/component: server
    app.kubernetes.io/part-of: wordpress
...

Service використовується для відкриття доступу до WordPress:

apiVersion: v1
kind: Service
metadata:
  labels:
    app.kubernetes.io/name: wordpress
    app.kubernetes.io/instance: wordpress-abcxyz
    app.kubernetes.io/version: "4.9.4"
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/component: server
    app.kubernetes.io/part-of: wordpress
...

MySQL представлено як StatefulSet з метаданими як для нього, так і для застосунку, до якого він належить:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  labels:
    app.kubernetes.io/name: mysql
    app.kubernetes.io/instance: mysql-abcxyz
    app.kubernetes.io/version: "5.7.21"
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/component: database
    app.kubernetes.io/part-of: wordpress
...

Service використовується для відкриття доступу до MySQL як частини WordPress:

apiVersion: v1
kind: Service
metadata:
  labels:
    app.kubernetes.io/name: mysql
    app.kubernetes.io/instance: mysql-abcxyz
    app.kubernetes.io/version: "5.7.21"
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/component: database
    app.kubernetes.io/part-of: wordpress
...

З MySQL StatefulSet та Service ви побачите, що включена інформація як про MySQL, так і про WordPress.

3.1.3 - API Kubernetes

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

Основа Kubernetes — це панель управління з API server. Сервер API використовує API HTTP, яке дозволяє кінцевим користувачам, різним частинам вашого кластера та зовнішнім компонентам спілкуватися один з одним.

API Kubernetes дозволяє вам отримувати та маніпулювати станом обʼєктів API в Kubernetes (наприклад: Pod, Namespace, ConfigMap та Event).

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

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

  • Discovery API надає інформацію про API Kubernetes: назви API, ресурси, версії, та операції, які підтримуються. Цей термін є специфічним для Kubernetes, що відділяє API від Kubernetes OpenAPI. Він має на меті надавати опис доступних ресурсів, однак він не надає детальну специфікацію кожного ресурсу. Щоб отримати докладні відомості про схеми ресурсів звертайтесь до документації OpenAPI.
  • Документація Kubernetes OpenAPI надає детальну специфікацію схем OpenAPI v2.0 та v3.0 для всіх точок доступу API Kubernetes. OpenAPI v3.0 є бажаним методом для доступу до OpenAPI, оскільки він надає більш докладну та повну специфікацію API. Цей варіант містить всі можливі API-шляхи, так само як і всі ресурси, що використовуються та створюються для кожної операції на кожній точці доступу. Тут також є розширювані компоненти, які підтримуються кластером. Дані містять повну специфікацію та значно перевищують за обсягом те, що надає Discovery API.

Discovery API

Kubernetes публікує перелік всіх груп версій та ресурсів які підтримуються через Discovery API, що включає для кожного ресурсу наступне:

  • Назва
  • Обсяг досяжності (Namespace або Cluster)
  • URL Endpoint та підтримувані дії
  • Альтернативні назви
  • Group, version, kind

API доступний як в агрегованому, так і в не агрегованому вигляді. Агреговане виявлення обслуговує дві точки доступу (endpoint), тоді як не агреговане — окрему точку доступу для кожної групи версії.

Агреговане виявлення

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

Kubernetes надає підтримку агрегованого виявлення, публікуючи всі ресурси, які підтримує кластер, через дві точки доступу (/api та /apis) порівняно з одним для кожної групи версій. Надсилання запиту до цієї точки доступу різко зменшує кількість надісланих запитів для отримання даних про кластер Kubernetes. Ви можете отримати доступ до даних надсилаючи запити до відповідних точок доступу з заголовком Accept, що є агрегованим виявленням ресурсів: Accept: application/json;v=v2;g=apidiscovery.k8s.io;as=APIGroupDiscoveryList.

Без зазначення типу ресурсів використання заголовка Accept стандартна відповідь для /api та /apis буде не агрегованим виявленням ресурсів.

Документ виявлення для вбудованих ресурсів можна знайти в репозиторій Kubernetes GitHub. Цей документ Github можна використовувати як довідник базового набору доступних ресурсів, якщо кластер Kubernetes недоступний для запитів.

Точка доступу також підтримує кодування ETag і protobuf.

Не агреговане виявлення

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

Список усіх версій груп, підтримуваних кластером, публікується в точках доступу /api та /apis. Наприклад:

{
  "kind": "APIGroupList",
  "apiVersion": "v1",
  "groups": [
    {
      "name": "apiregistration.k8s.io",
      "versions": [
        {
          "groupVersion": "apiregistration.k8s.io/v1",
          "version": "v1"
        }
      ],
      "preferredVersion": {
        "groupVersion": "apiregistration.k8s.io/v1",
        "version": "v1"
      }
    },
    {
      "name": "apps",
      "versions": [
        {
          "groupVersion": "apps/v1",
          "version": "v1"
        }
      ],
      "preferredVersion": {
        "groupVersion": "apps/v1",
        "version": "v1"
      }
    },
    ...
  ]
}

Для отримання документа виявлення для кожної версії групи за адресою /apis/<group>/<version> (наприклад, /apis/rbac.authorization.k8s.io/v1alpha1) потрібні додаткові запити. Ці точки доступу оголошують список ресурсів, що обслуговуються певною версією групи. Ці точки доступу використовуються командою kubectl для отримання списку ресурсів, підтримуваних кластером.

Інтерфейс OpenAPI

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

Kubernetes працює як з OpenAPI v2.0, так і з OpenAPI v3.0. OpenAPI v3 є кращим методом доступу до OpenAPI, оскільки він пропонує повніше (без втрат) представлення ресурсів Kubernetes. Через обмеження OpenAPI версії 2 певні поля видалено з опублікованого OpenAPI, включаючи, але не обмежуючись, default, nullable, oneOf.

OpenAPI V2

Сервер API Kubernetes надає агреговану специфікацію OpenAPI v2 через точку доступу /openapi/v2. Ви можете запросити формат відповіді, використовуючи заголовки запиту наступним чином:

Дійсні значення заголовків запиту для запитів OpenAPI v2
ЗаголовокМожливі значенняПримітки
Accept-Encodinggzipне надання цього заголовка також допустиме
Acceptapplication/com.github.proto-openapi.spec.v2@v1.0+protobufголовним чином для внутрішньокластерного використання
application/jsonтипово
*обслуговує application/json

OpenAPI V3

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

Kubernetes підтримує публікацію опису своїх API у форматі OpenAPI v3.

Надається точка доступу /openapi/v3 для перегляду списку всіх доступних груп/версій. Ця точка повертає лише JSON. Ці групи/версії вказані у наступному форматі:

{
    "paths": {
        ...,
        "api/v1": {
            "serverRelativeURL": "/openapi/v3/api/v1?hash=CC0E9BFD992D8C59AEC98A1E2336F899E8318D3CF4C68944C3DEC640AF5AB52D864AC50DAA8D145B3494F75FA3CFF939FCBDDA431DAD3CA79738B297795818CF"
        },
        "apis/admissionregistration.k8s.io/v1": {
            "serverRelativeURL": "/openapi/v3/apis/admissionregistration.k8s.io/v1?hash=E19CC93A116982CE5422FC42B590A8AFAD92CDE9AE4D59B5CAAD568F083AD07946E6CB5817531680BCE6E215C16973CD39003B0425F3477CFD854E89A9DB6597"
        },
        ....
    }
}

Відносні URL вказують на незмінний опис OpenAPI для поліпшення кешування на стороні клієнта. Також API-сервер встановлює відповідні заголовки кешування HTTP (Expires на 1 рік вперед та Cache-Control на immutable). При використанні застарілого URL API-сервер повертає перенаправлення на новий URL.

API-сервер Kubernetes публікує специфікацію OpenAPI v3 для кожної групи версій Kubernetes через точку доступу /openapi/v3/apis/<group>/<version>?hash=<hash>.

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

Дійсні значення заголовків запиту для запитів OpenAPI v3
ЗаголовокМожливі значенняПримітки
Accept-Encodinggzipне надання цього заголовка також допустиме
Acceptapplication/com.github.proto-openapi.spec.v3@v1.0+protobufголовним чином для внутрішньокластерного використання
application/jsonстанадартно/em>
*обслуговує application/json

Реалізація Golang для отримання OpenAPI V3 надається в пакунку k8s.io/client-go/openapi3.

Kubernetes 1.31 публікує OpenAPI v2.0 та v3.0; найближчим часом підтримка 3.1 не планується.

Серіалізація Protobuf

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

Постійність

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

Групи API та версіювання

Щоб полегшити вилучення полів або перебудову представлень ресурсів, Kubernetes підтримує кілька версій API, кожна з різним API-шляхом, таким як /api/v1 або /apis/rbac.authorization.k8s.io/v1alpha1.

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

Щоб полегшити еволюцію та розширення свого API, Kubernetes реалізує API groups, які можна увімкнути або вимкнути.

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

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

Зміни в API

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

Загалом можна часто та періодично додавати нові ресурси API та нові поля ресурсів. Усунення ресурсів чи полів вимагає дотримання політики застарівання API.

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

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

Дивіться довідник по версіях API для отримання докладнішої інформації про визначення рівня API.

Розширення API

API Kubernetes можна розширити одним з двох способів:

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

Що далі

3.2 - Архітектура кластера

Архітектурні концепції в основі Kubernetes.

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

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

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

Панель управління (kube-apiserver, etcd, kube-controller-manager, kube-scheduler) та кілька вузлів. Кожен вузол запускає kubelet та kube-proxy.

Компоненти кластера Kubernetes

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

Компоненти панелі управління

Компоненти панелі управління приймають глобальні рішення щодо кластера (наприклад, планування), а також виявляють та реагують на події в кластері (наприклад, запуск нового Podʼа, коли умова поля replicas в Deployment не виконується).

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

kube-apiserver

Сервер API є компонентом панелі управління Kubernetes, який надає доступ до API Kubernetes. Сервер API є фронтендом для панелі управління Kubernetes.

Основна реалізація сервера API Kubernetes — kube-apiserver. kube-apiserver спроєктований для горизонтального масштабування, тобто масштабується за допомогою розгортання додаткових екземплярів. Ви можете запустити кілька екземплярів kube-apiserver та балансувати трафік між ними.

etcd

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

Якщо ваш кластер Kubernetes використовує etcd як сховище для резервування, переконайтеся, що у вас є план резервного копіювання даних.

Ви можете знайти докладну інформацію про etcd в офіційній документації.

kube-scheduler

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

При виборі вузла враховуються наступні фактори: індивідуальна і колективна потреба у ресурсах, обмеження за апаратним/програмним забезпеченням і політиками, характеристики affinity та anti-affinity, локальність даних, сумісність робочих навантажень і граничні терміни виконання.

kube-controller-manager

Компонент панелі управління, який запускає процеси контролера.

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

Існує багато різних типів контролерів. Деякі приклади:

  • Контролер вузлів: відповідає за виявлення та реагування, коли вузли виходять з ладу.
  • Контролер завдань: відстежує обʼєкти Job, що представляють одноразові завдання, а потім створює Podʼи для виконання цих завдань, які існують до їх завершення.
  • Контролер EndpointSlice: заповнює обʼєкти EndpointSlice (для забезпечення звʼязку між Serviceʼами та Podʼами).
  • Контролер службових облікових записів: створює стандартні ServiceAccounts для нових просторів імен.

Наведений вище список не є вичерпним.

cloud-controller-manager

Компонент панелі управління Kubernetes, що інтегрує управління логікою певної хмари. Cloud controller manager дозволяє звʼязувати ваш кластер з API хмарного провайдера та відокремлює компоненти, що взаємодіють з хмарною платформою від компонентів, які взаємодіють тільки в кластері.

cloud-controller-manager запускає лише ті контролери, які специфічні для вашого хмарного провайдера. Якщо ви використовуєте Kubernetes у себе на підприємстві або в навчальному середовищі всередині вашого ПК, кластер не матиме cloud-controller-manager.

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

Наступні контролери можуть мати залежності від хмарного провайдера:

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

Компоненти вузлів

Компоненти вузлів працюють на кожному вузлі, підтримуючи роботу Podʼів та забезпечуючи середовище виконання Kubernetes.

kubelet

Агент, запущений на кожному вузлі кластера. Забезпечує запуск і роботу контейнерів в Podʼах.

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

kube-proxy (опційно)

kube-proxy є мережевим проксі, що запущений на кожному вузлі кластера і реалізує частину концепції Kubernetes Service.

kube-proxy забезпечує підтримання мережевих правил на вузлах. Ці правила обумовлюють підключення мережею до ваших Podʼів всередині чи поза межами кластера.

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

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

Рушій виконання контейнерів

Основний компонент, який дозволяє Kubernetes ефективно запускати контейнери. Він відповідає за керування виконанням і життєвим циклом контейнерів у середовищі Kubernetes.

Kubernetes підтримує середовища виконання контейнерів, такі як containerd, CRI-O, та будь-яку іншу реалізацію Kubernetes CRI (інтерфейс виконання контейнерів).

Надбудови

Надбудови використовують ресурси Kubernetes (DaemonSet, Deployment тощо) для реалізації функцій кластера. Оскільки вони надають функції на рівні кластера, ресурси, що належать надбудовам, розміщуються в просторі імен kube-system.

Вибрані застосунки описані нижче; для розширеного списку доступних надбудов дивіться Надбудови.

DNS

Хоча інші надбудови не є строго необхідними, всі кластери Kubernetes повинні мати кластерний DNS, оскільки багато прикладів залежать від нього.

Кластерний DNS — це DNS-сервер, який доповнює інші DNS-сервери у вашому середовищі та обслуговує DNS-записи для сервісів Kubernetes.

Контейнери, запущені за допомогою Kubernetes, автоматично включають цей DNS-сервер у свої DNS-запити.

Вебінтерфейс (Dashboard)

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

Моніторинг ресурсів контейнерів

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

Логування на рівні кластера

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

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

Мережеві втулки — це програмні компоненти, які реалізують специфікацію інтерфейсу мережі контейнерів (CNI). Вони відповідають за виділення IP-адрес Podʼам та забезпечення їх звʼязку між собою у кластері.

Варіації архітектури

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

Варіанти розгортання панелі управління

Компоненти панелі управління можна розгортати кількома способами:

Традиційне розгортання:
Компоненти панелі управління працюють безпосередньо на виділених машинах або віртуальних машинах, часто керованих як служби systemd.
Статичні Podʼи:
Компоненти панелі управління розгортаються як статичні Podʼи, керовані kubelet на певних вузлах. Це поширений підхід, який використовують такі інструменти, як kubeadm.
Самообслуговування:
Панель управління працює як Podʼи у самому кластері Kubernetes, яким керують Deployments та StatefulSets або інші примітиви Kubernetes.
Керовані сервіси Kubernetes:
Хмарні провайдери часто абстрагують панель управління, керуючи її компонентами як частиною послуги, яку вони надають.

Розміщення робочих навантажень

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

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

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

Такі інструменти, як kubeadm, kops та Kubespray, пропонують різні підходи до розгортання та управління кластерами, кожен з яких має свій метод розташування та управління компонентами.

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

Налаштування та розширюваність

Архітектура Kubernetes дозволяє значну кастомізацію:

  • Власні планувальники можна розгортати паралельно зі стандартним планувальником Kubernetes або замінювати його повністю.
  • API-сервери можна розширювати за допомогою CustomResourceDefinitions та API Aggregation.
  • Хмарні провайдери можуть глибоко інтегруватися з Kubernetes за допомогою cloud-controller-manager.

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

Що далі

Дізнайтеся більше про:

3.2.1 - Вузли

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

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

Компоненти на вузлі включають kubelet, середовище виконання контейнерів та kube-proxy.

Управління

Є два основних способи додавання Вузлів до API-сервера:

  1. kubelet на вузлі самостійно реєструється в панелі управління.
  2. Ви (або інший користувач) вручну додаєте обʼєкт Node.

Після створення обʼєкта Node, або якщо kubelet на вузлі самостійно реєструється, панель управління перевіряє, чи новий обʼєкт Node є дійсним. Наприклад, якщо ви спробуєте створити Вузол з наступним JSON-маніфестом:

{
  "kind": "Node",
  "apiVersion": "v1",
  "metadata": {
    "name": "10.240.79.157",
    "labels": {
      "name": "my-first-k8s-node"
    }
  }
}

Kubernetes внутрішньо створює обʼєкт Node. Kubernetes перевіряє чи kubelet зареєструвався в API-сервері, що відповідає полю metadata.name Node. Якщо вузол є справним (тобто всі необхідні служби працюють), то він може запускати Podʼи. В іншому випадку цей вузол ігнорується для будь-якої діяльності кластера доки він не стане справним.

Назва обʼєкта Node повинно бути дійсним імʼям DNS-піддомену.

Унікальність назв Вузлів

Назва ідентифікує Node. Два Вузли не можуть мати однакову назву одночасно. Kubernetes також припускає, що ресурс з такою ж назвою — це той самий обʼєкт. У випадку Вузла припускається неявно, що екземпляр, який використовує ту ж назву, матиме той самий стан (наприклад, мережеві налаштування, вміст кореневого диска) та атрибути, такі як мітки вузла. Це може призвести до невідповідностей, якщо екземпляр був змінений без зміни його назви. Якщо Вузол потрібно замінити або значно оновити, наявний обʼєкт Node повинен бути видалений з API-сервера спочатку і знову доданий після оновлення.

Самореєстрація Вузлів

Коли прапорець kubelet --register-node є true (типово), kubelet спробує зареєструвати себе в API-сервері. Цей підхід використовується більшістю дистрибутивів.

Для самореєстрації kubelet запускається з наступними параметрами:

  • --kubeconfig — Шлях до облікових даних для автентифікації на API-сервері.

  • --cloud-provider — Як взаємодіяти з хмарним постачальником для отримання метаданих про себе.

  • --register-node — Автоматична реєстрація в API-сервері.

  • --register-with-taints — Реєстрація вузла з заданим списком позначок (розділених комами <ключ>=<значення>:<ефект>).

    Нічого не відбувається, якщо register-node є false.

  • --node-ip — Необовʼязковий розділений комами список IP-адрес вузла. Можна вказати лише одну адресу для кожного роду адрес. Наприклад, у кластері з одним стеком IPv4 ви встановлюєте це значення як IPv4-адресу, яку повинен використовувати kubelet для вузла. Див. налаштування подвійного стека IPv4/IPv6 для отримання відомостей з запуску кластера з подвійним стеком.

    Якщо ви не вказали цей аргумент, kubelet використовує стандартну IPv4-адресу вузла, якщо є; якщо у вузла немає адреси IPv4, тоді kubelet використовує стандартну IPv6-адресу вузла.

  • --node-labels - Мітки для додавання при реєстрації вузла в кластері (див. обмеження міток, що накладаються втулком доступу NodeRestriction).

  • --node-status-update-frequency — Вказує, як часто kubelet публікує свій статус вузла на API-сервері.

Коли увімкнено режим авторизації Вузла та втулок доступу NodeRestriction, kubelets мають право створювати/змінювати лише свій власний ресурс Node.

Ручне адміністрування Вузлів

Ви можете створювати та змінювати обʼєкти Node за допомогою kubectl.

Коли ви хочете створювати обʼєкти Node вручну, встановіть прапорець kubelet --register-node=false.

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

Ви можете використовувати мітки на Вузлах разом із селекторами вузлів на Podʼах для управління плануванням. Наприклад, ви можете обмежити Pod лише можливістю запуску на підмножині доступних вузлів.

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

Щоб позначити Вузол як незапланований, виконайте:

kubectl cordon $NODENAME

Див. Безпечне очищення вузла для деталей.

Статус Вузла

Статус Вузла містить наступну інформацію:

Ви можете використовувати kubectl, щоб переглядати статус Вузла та інші деталі:

kubectl describe node <вставте-назву-вузла-тут>

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

Сигнали Вузлів

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

Для вузлів існують дві форми сигналів:

  • Оновлення в .status Вузла.
  • Обʼєкти Оренди (Lease) у просторі імен kube-node-lease. Кожен Вузол має асоційований обʼєкт Lease.

Контролер вузлів

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

У контролера вузла є кілька ролей у житті вузла. По-перше, він призначає блок CIDR вузлу при його реєстрації (якщо призначення CIDR увімкнено).

По-друге, він підтримує актуальність внутрішнього списку вузлів контролера зі списком доступних машин хмарного провайдера. У разі, якщо вузол несправний, контролер вузла перевіряє у хмарному провайдері, чи ще доступний віртуальний компʼютер (VM) для цього вузла. Якщо ні, контролер вузла видаляє вузол зі свого списку вузлів.

По-третє, контролер відповідає за моніторинг стану вузлів і:

  • У випадку, якщо вузол стає недоступним, оновлення умови Ready у полі .status Вузла. У цьому випадку контролер вузла встановлює умову Ready в Unknown.
  • Якщо вузол залишається недоступним: запускає виселення ініційоване API для всіх Podʼів на недосяжному вузлі. Типово контролер вузла чекає 5 хвилин між позначенням вузла як Unknown та поданням першого запиту на виселення.

Стандартно контролер вузла перевіряє стан кожного вузла кожні 5 секунд. Цей період можна налаштувати за допомогою прапорця --node-monitor-period у компоненті kube-controller-manager.

Обмеження швидкості виселення

У більшості випадків контролер вузла обмежує швидкість виселення на --node-eviction-rate (типово 0,1) в секунду, що означає, що він не буде виводити Podʼи з більше, ніж 1 вузла кожні 10 секунд.

Поведінка виселення вузла змінюється, коли вузол в певній доступності стає несправним. Контролер вузла перевіряє, яка частина вузлів в зоні є несправною (умова Ready — Unknown або False) у той самий час:

  • Якщо частка несправних вузлів становить принаймні --unhealthy-zone-threshold (типово 0,55), тоді швидкість виселення зменшується.
  • Якщо кластер малий (тобто має менше або дорівнює --large-cluster-size-threshold вузлів — типово 50), тоді виселення припиняється.
  • У іншому випадку швидкість виселення зменшується до --secondary-node-eviction-rate (типово 0,01) в секунду.

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

Однією з ключових причин розподілу вузлів за зонами доступності є можливість переміщення навантаження в справні зони, коли одна ціла зона виходить з ладу. Таким чином, якщо всі вузли в зоні несправні, контролер вузла виводить навантаження зі звичайною швидкістю --node-eviction-rate. Крайній випадок — коли всі зони повністю несправні (жоден вузол в кластері не є справним). У такому випадку контролер вузла припускає, що існує якась проблема зі зʼєднанням між панеллю управління та вузлами, і не виконує жодних виселень. (Якщо стався збій і деякі вузли відновились, контролер вузла виводить Podʼи з решти вузлів, які є несправними або недосяжними).

Контролер вузла також відповідає за виселення Podʼів, що працюють на вузлах із позначками NoExecute, якщо ці Podʼи дозволяють таке. Контролер вузла також додає taint, відповідні проблемам вузла, таким як недосяжність вузла або неготовність вузла. Це означає, що планувальник не розміщуватиме Podʼи на несправних вузлах.

Відстеження місткості ресурсів

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

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

Топологія вузла

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

Якщо ви увімкнули функціональну можливість ресурсу TopologyManager, то kubelet може використовувати підказки топології при прийнятті рішень щодо призначення ресурсів. Див. Керування політиками топології на вузлі для отримання додаткової інформації.

Керування swapʼом

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

Щоб увімкнути swap на вузлі, feature gate NodeSwap повинен бути активований у kubelet (типово так), і прапорець командного рядка --fail-swap-on або параметр конфігурації failSwapOn повинен бути встановлений в значення false. Для того, щоб дозволити Podʼам використовувати swap, swapBehavior не повинен мати значення NoSwap (яке є стандартним) у конфігурації kubelet.

Користувач також може налаштувати memorySwap.swapBehavior, щоб вказати, як вузол буде використовувати swap. Наприклад,

memorySwap:
  swapBehavior: LimitedSwap
  • NoSwap (стандартно): Робочі навантаження Kubernetes не використовуватимуть swap.
  • LimitedSwap: Використання робочими навантаженнями Kubernetes swap обмежено. Тільки Podʼи Burstable QoS мають право використовувати swap.

Якщо конфігурація для memorySwap не вказана, і feature gate увімкнено, типово kubelet застосовує ту ж саму поведінку, що й налаштування NoSwap.

З LimitedSwap, Podʼам, які не відносяться до класифікації Burstable QoS (тобто Podʼи QoS BestEffort/Guaranteed), заборонено використовувати swap. Для забезпечення гарантій безпеки і справності вузла цим Podʼам заборонено використовувати swap при включеному LimitedSwap.

Перед тим як розглядати обчислення ліміту swap, необхідно визначити наступне:

  • nodeTotalMemory: Загальна кількість фізичної памʼяті, доступної на вузлі.
  • totalPodsSwapAvailable: Загальний обсяг swap на вузлі, доступний для використання Podʼами (деякий swap може бути зарезервовано для системного використання).
  • containerMemoryRequest: Запит на памʼять для контейнера.

Ліміт swap налаштовується так: (containerMemoryRequest / nodeTotalMemory) * totalPodsSwapAvailable.

Важливо враховувати, що для контейнерів у Podʼах Burstable QoS можна відмовитися від використання swap, вказавши запити на памʼять, рівні лімітам памʼяті. Контейнери, налаштовані таким чином, не матимуть доступу до swap.

Swap підтримується тільки з cgroup v2, cgroup v1 не підтримується.

Для отримання додаткової інформації, а також для допомоги у тестуванні та надання зворотного звʼязку, будь ласка, перегляньте блог-пост Kubernetes 1.28: NodeSwap виходить у Beta1, KEP-2400 та його проєкт концепції.

Що далі

Дізнайтеся більше про наступне:

3.2.2 - Звʼязок між Вузлами та Панеллю управління

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

Звʼязок Вузла з Панеллю управління

У Kubernetes існує шаблон API "hub-and-spoke". Всі використання API вузлів (або Podʼів, які вони виконують) завершуються на API-сервері. Інші компоненти панелі управління не призначені для експонування віддалених служб. API-сервер налаштований для прослуховування віддалених підключень на захищеному порту HTTPS (зазвичай 443) з однією або декількома формами автентифікації клієнта. Рекомендується включити одну чи кілька форм авторизації, особливо якщо анонімні запити або токени облікового запису служби дозволені.

Вузли повинні бути забезпечені загальним кореневим сертифікатом для кластера, щоб вони могли безпечно підключатися до API-сервера разом з дійсними обліковими даними клієнта. Добрим підходом є те, що облікові дані клієнта, які надаються kubelet, мають форму сертифіката клієнта. Див. завантаження TLS kubelet для автоматичного забезпечення облікових даних клієнта kubelet.

Podʼи, які бажають підʼєднатися до API-сервера, можуть це зробити безпечно, використовуючи службовий обліковий запис (service account), так що Kubernetes автоматично вставлятиме загальний кореневий сертифікат та дійсний токен власника у Pod, коли він буде ініціалізований. Служба kubernetes (в просторі імен default) налаштована з віртуальною IP-адресою, яка перенаправляється (через kube-proxy) на точку доступу HTTPS на API-сервері.

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

В результаті, типовий режим роботи для зʼєднань від вузлів та Podʼів, що працюють на вузлах, до панелі управління є захищеним і може працювати через ненадійні та/або публічні мережі.

Звʼязок Панелі управління з Вузлом

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

Звʼязок API-сервер з kubelet

Зʼєднання від API-сервера до kubelet використовуються для:

  • Отримання логів для Podʼів.
  • Приєднання (зазвичай через kubectl) до запущених Podʼів.
  • Забезпечення функціональності перенаправлення портів kubelet.

Ці зʼєднання завершуються на точці доступу HTTPS kubelet. Стандартно API-сервер не перевіряє сертифікат обслуговування kubelet, що робить зʼєднання вразливими до атаки "особа-посередині" і небезпечними для використання через ненадійні та/або публічні мережі.

Щоб перевірити це зʼєднання, використовуйте прапорець --kubelet-certificate-authority, щоб надати API серверу пакет кореневих сертифікатів для перевірки сертифіката обслуговування kubelet.

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

Нарешті, автентифікацію та/або авторизацію Kubelet потрібно ввімкнути, щоб захистити API kubelet.

Звʼязок API-сервера з вузлами, Podʼам та Service

Зʼєднання від API-сервера до вузла, Podʼа чи Service типово використовують прості HTTP-зʼєднання і, отже, не автентифікуються або не шифруються. Їх можна використовувати через захищене зʼєднання HTTPS, підставивши https: перед назвою вузла, Podʼа чи Service в URL API, але вони не будуть перевіряти сертифікат, наданий точкою доступу HTTPS, та не надаватимуть облікові дані клієнта. Таким чином, хоча зʼєднання буде зашифрованим, воно не гарантує цілісності. Ці зʼєднання поки не є безпечними для використання через ненадійні або публічні мережі.

Тунелі SSH

Kubernetes підтримує тунелі SSH, щоб захистити канали звʼязку від панелі управління до вузлів. У цій конфігурації API-сервер ініціює тунель SSH до кожного вузла в кластері (підключаючись до SSH-сервера, який прослуховує порт 22) і передає весь трафік, призначений для kubelet, вузла, Podʼа чи Service через тунель. Цей тунель гарантує, що трафік не виходить за межі мережі, в якій працюють вузли.

Служба Konnectivity

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

Як заміна тунелям SSH, служба Konnectivity надає проксі на рівні TCP для звʼязку панелі управління з кластером. Служба Konnectivity складається з двох частин: сервера Konnectivity в мережі панелі управління та агентів Konnectivity в мережі вузлів. Агенти Konnectivity ініціюють зʼєднання з сервером Konnectivity та утримують мережеві підключення. Після ввімкнення служби Konnectivity весь трафік від панелі управління до вузлів прокладається через ці зʼєднання.

Для налаштування служби Konnectivity у своєму кластері ознайомтесь із завданням служби Konnectivity.

Що далі

3.2.3 - Контролери

У робототехніці та автоматизації control loop (цикл керування) — це необмежений цикл, який регулює стан системи.

Ось один приклад control loop — термостат у кімнаті.

Коли ви встановлюєте температуру, це означає, що ви повідомляєте термостату про бажаний стан. Фактична температура в кімнаті — це поточний стан. Термостат діє так, щоб наблизити поточний стан до бажаного стану, вмикаючи чи вимикаючи відповідне обладнання.

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

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

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

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

Управління через API-сервер

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

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

(Після процесу планування, обʼєкти Pod стають частиною бажаного стану для kubelet).

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

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

Контролери також оновлюють обʼєкти, які їх конфігурують. Наприклад, якщо робота виконана для завдання, контролер Job оновлює обʼєкт Job, щоб позначити його як Finished.

(Це трошки схоже на те, як деякі термостати вимикають світловий індикатор, щоб сповістити, що ваша кімната тепер має температуру, яку ви встановили).

Безпосереднє управління

На відміну від Job, деякі контролери повинні вносити зміни в речі за межами вашого кластера.

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

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

(Фактично є контролер що горизонтально масштабує вузли у вашому кластері).

Важливим тут є те, що контролер вносить певні зміни, щоб досягти вашого бажаного стану, а потім повідомляє поточний стан назад на API-сервер вашого кластера. Інші control loop можуть спостерігати за цим звітами та виконувати вже свої дії.

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

Бажаний стан порівняно з поточним

Kubernetes має хмарний вигляд систем і здатний обробляти постійні зміни.

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

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

Дизайн

Як принцип дизайну, Kubernetes використовує багато контролерів, кожен з яких керує певним аспектом стану кластера. Найчастіше, певний цикл управління (контролер) використовує один вид ресурсу як свій бажаний стан, і має різні види ресурсу, якими він управляє, щоб задовольнити цей бажаний стан. Наприклад, контролер для ресурсу Job відстежує обʼєкти Job (для виявлення нової роботи) та обʼєкти Pod (для запуску робіт і потім визначення, коли робота закінчена). У цьому випадку щось інше створює роботи, тоді як контролер Job створює Podʼи.

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

Способи використання контролерів

Kubernetes постачається з набором вбудованих контролерів, які працюють всередині kube-controller-manager. Ці вбудовані контролери забезпечують важливі основні функції.

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

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

Що далі

3.2.4 - Лізинг

Часто в розподілених системах є потреба в лізингу, яка забезпечує механізм блокування спільних ресурсів та координації дій між членами групи. В Kubernetes концепцію лізингу представлено обʼєктами Lease в API Group coordination.k8s.io, які використовуються для критичних для системи можливостей, таких як час роботи вузлів та вибір лідера на рівні компонентів.

Час роботи вузлів

Kubernetes використовує API Lease для звʼязку з пульсом kubelet вузла з API сервером Kubernetes. Для кожного Node існує обʼєкт Lease з відповідним імʼям в просторі імен kube-node-lease. Під капотом кожен сигнал пульсу kubelet — це запит на оновлення цього обʼєкта Lease, який оновлює поле spec.renewTime для оренди. Панель управління Kubernetes використовує відмітку часу цього поля для визначення доступності цього вузла.

Дивіться Обʼєкти Lease вузлів для отримання додаткових деталей.

Вибір лідера

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

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

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

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

Починаючи з Kubernetes v1.26, кожен kube-apiserver використовує API Lease для публікації своєї ідентичності для решти системи. Хоча це само по собі не є особливо корисним, це забезпечує механізм для клієнтів для визначення кількості екземплярів kube-apiserver, які керують панеллю управління Kubernetes. Наявність лізингів kube-apiserver дозволяє майбутнім можливостям, які можуть потребувати координації між кожним kube-apiserver.

Ви можете перевірити лізинги, якими володіє кожен kube-apiserver, перевіривши обʼєкти лізингу в просторі імен kube-system з іменем kube-apiserver-<sha256-hash>. Або ви можете використовувати селектор міток apiserver.kubernetes.io/identity=kube-apiserver:

kubectl -n kube-system get lease -l apiserver.kubernetes.io/identity=kube-apiserver
NAME                                        HOLDER                                                                           AGE
apiserver-07a5ea9b9b072c4a5f3d1c3702        apiserver-07a5ea9b9b072c4a5f3d1c3702_0c8914f7-0f35-440e-8676-7844977d3a05        5m33s
apiserver-7be9e061c59d368b3ddaf1376e        apiserver-7be9e061c59d368b3ddaf1376e_84f2a85d-37c1-4b14-b6b9-603e62e4896f        4m23s
apiserver-1dfef752bcb36637d2763d1868        apiserver-1dfef752bcb36637d2763d1868_c5ffa286-8a9a-45d4-91e7-61118ed58d2e        4m43s

Хеш SHA256, який використовується в назвах лізингу, базується на імені ОС, які бачить цей API сервер. Кожен kube-apiserver повинен бути налаштований на використання унікального імені в межах кластера. Нові екземпляри kube-apiserver, які використовують те саме імʼя хоста, захоплюють наявні лізинги за допомогою нового ідентифікатора власника, замість того щоб створювати нові обʼєкти лізингу. Ви можете перевірити імʼя хоста, використовуючи kube-apisever, перевіривши значення мітки kubernetes.io/hostname:

kubectl -n kube-system get lease apiserver-07a5ea9b9b072c4a5f3d1c3702 -o yaml
apiVersion: coordination.k8s.io/v1
kind: Lease
metadata:
  creationTimestamp: "2023-07-02T13:16:48Z"
  labels:
    apiserver.kubernetes.io/identity: kube-apiserver
    kubernetes.io/hostname: master-1
  name: apiserver-07a5ea9b9b072c4a5f3d1c3702
  namespace: kube-system
  resourceVersion: "334899"
  uid: 90870ab5-1ba9-4523-b215-e4d4e662acb1
spec:
  holderIdentity: apiserver-07a5ea9b9b072c4a5f3d1c3702_0c8914f7-0f35-440e-8676-7844977d3a05
  leaseDurationSeconds: 3600
  renewTime: "2023-07-04T21:58:48.065888Z"

Прострочені лізинги від kube-apiservers, які вже не існують, прибираються новими kube-apiservers через 1 годину.

Ви можете вимкнути лізинги ідентичності API сервера, вимкнувши функціональну можливість APIServerIdentity.

Робочі навантаження

Ваші власні робочі навантаження можуть визначити своє власне використання лізингів. Наприклад, ви можете запускати власний контролер, де первинний член чи лідер виконує операції, які його партнери не виконують. Ви визначаєте лізинг так, щоб репліки контролера могли вибирати чи обирати лідера, використовуючи API Kubernetes для координації. Якщо ви використовуєте лізинг, це гарна практика визначати імʼя лізингу, яке очевидно повʼязано з продуктом чи компонентом. Наприклад, якщо у вас є компонент з іменем Example Foo, використовуйте лізинг з іменем example-foo.

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

Ви можете використовувати інший підхід, поки він досягає того самого результату: відсутність конфліктів між різними програмними продуктами.

3.2.5 - Cloud Controller Manager

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

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

Сloud-controller-manager це компонент панелі управління Kubernetes, що інтегрує управління логікою певної хмари. Cloud controller manager дозволяє звʼязувати ваш кластер з API хмарного провайдера та відокремлює компоненти, що взаємодіють з хмарною платформою від компонентів, які взаємодіють тільки в кластері.

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

Cloud-controller-manager структурується з допомогою механізму втулків, який дозволяє різним постачальникам хмар інтегрувати свої платформи з Kubernetes.

Дизайн

Компоненти Kubernetes

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

Функції менеджера контролера хмар

Контролери всередині менеджера контролера хмар складаються з:

Контролер Node

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

  1. Оновлення обʼєкта Node відповідним унікальним ідентифікатором сервера, отриманим з API постачальника хмари.
  2. Анотація та маркування обʼєкта Node хмароспецифічною інформацією, такою як регіон, в якому розгорнуто вузол, та ресурси (CPU, памʼять і т. д.), якими він володіє.
  3. Отримання імені хосту та мережевих адрес.
  4. Перевірка стану вузла. У випадку, якщо вузол стає непридатним для відповіді, цей контролер перевіряє за допомогою API вашого постачальника хмари, чи сервер був деактивований / видалений / завершений. Якщо вузол був видалений з хмари, контролер видаляє обʼєкт Node з вашого кластера Kubernetes.

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

Контролер Route

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

Залежно від постачальника хмари, контролер Route може також виділяти блоки IP-адрес для мережі Podʼа.

Контролер Service

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

Авторизація

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

Контролер Node

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

v1/Node:

  • get
  • list
  • create
  • update
  • patch
  • watch
  • delete

Контролер Route

Контролер Route відстежує створення обʼєктів Node та налаштовує маршрути відповідним чином. Він вимагає доступу Get до обʼєктів Node.

v1/Node:

  • get

Контролер Service

Контролер Service відстежує події create, update та delete обʼєктів та після цього налаштовує Endpoints для цих Service відповідним чином (для EndpointSlices менеджер kube-controller-manager керує ними за запитом).

Для доступу до Service потрібні доступи list та watch. Для оновлення Service потрібен доступ patch та update.

Для налаштування ресурсів Endpoints для Service потрібен доступ до create, list, get, watch та update.

v1/Service:

  • list
  • get
  • watch
  • patch
  • update

Інші

Реалізація основи менеджера контролера хмар потребує доступу до створення Event та для забезпечення безпечної роботи він потребує доступу до створення ServiceAccounts.

v1/Event:

  • create
  • patch
  • update

v1/ServiceAccount:

  • create

RBAC ClusterRole для менеджера контролера хмар виглядає наступним чином:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cloud-controller-manager
rules:
- apiGroups:
  - ""
  resources:
  - events
  verbs:
  - create
  - patch
  - update
- apiGroups:
  - ""
  resources:
  - nodes
  verbs:
  - '*'
- apiGroups:
  - ""
  resources:
  - nodes/status
  verbs:
  - patch
- apiGroups:
  - ""
  resources:
  - services
  verbs:
  - list
  - patch
  - update
  - watch
- apiGroups:
  - ""
  resources:
  - serviceaccounts
  verbs:
  - create
- apiGroups:
  - ""
  resources:
  - persistentvolumes
  verbs:
  - get
  - list
  - update
  - watch
- apiGroups:
  - ""
  resources:
  - endpoints
  verbs:
  - create
  - get
  - list
  - watch
  - update

Що далі

  • Адміністрування менеджера контролера хмар містить інструкції щодо запуску та управління менеджером контролера хмар.

  • Щодо оновлення панелі управління з розділеною доступністю для використання менеджера контролера хмар, див. Міграція реплікованої панелі управління для використання менеджера контролера хмар.

  • Хочете знати, як реалізувати свій власний менеджер контролера хмар або розширити поточний проєкт?

    • Менеджер контролера хмар використовує інтерфейси Go, зокрема, інтерфейс CloudProvider, визначений у cloud.go з kubernetes/cloud-provider, щоб дозволити використовувати імплементації з будь-якої хмари.
    • Реалізація загальних контролерів, виділених у цьому документі (Node, Route та Service), разом із загальним інтерфейсом хмарного постачальника, є частиною ядра Kubernetes. Реалізації, специфічні для постачальників хмари, знаходяться поза ядром Kubernetes і реалізують інтерфейс CloudProvider.
    • Для отримання додаткової інформації щодо розробки втулків, див. Розробка менеджера контролера хмар.

3.2.6 - Про cgroup v2

У Linux control groups обмежують ресурси, які виділяються процесам.

kubelet та середовище виконання контейнерів повинні співпрацювати з cgroups для забезпечення управління ресурсами для Podʼів та контейнерів, що включає запити та обмеження на CPU/памʼяті для контейнеризованих навантажень.

Є дві версії cgroups у Linux: cgroup v1 і cgroup v2. cgroup v2 — це нове покоління API cgroup в Linux.

Що таке cgroup v2?

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

cgroup v2 — це наступне покоління API Linux cgroup. cgroup v2 надає єдину систему управління з розширеними можливостями управління ресурсами.

cgroup v2 пропонує кілька поліпшень порівняно з cgroup v1, таких як:

  • Один уніфікований дизайн ієрархії в API
  • Безпечне делегування піддерева контейнерам
  • Нові можливості, такі як Pressure Stall Information
  • Розширене управління розподілом ресурсів та ізоляція між різними ресурсами
    • Обʼєднаний облік різних типів виділення памʼяті (мережева памʼять, памʼять ядра і т. д.)
    • Облік негайних змін ресурсів, таких як запис кешу сторінок

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

Використання cgroup v2

Рекомендованим способом використання cgroup v2 є використання дистрибутиву Linux, який типово має та використовує cgroup v2.

Щоб перевірити, чи ваш дистрибутив використовує cgroup v2, див. Визначення версії cgroup на вузлах Linux.

Вимоги

cgroup v2 має наступні вимоги:

  • Дистрибутив ОС включає cgroup v2
  • Версія ядра Linux — 5.8 або пізніше
  • Середовище виконання контейнерів підтримує cgroup v2. Наприклад:
  • kubelet та середовище виконання контейнерів налаштовані на використання cgroup-драйвера systemd

Підтримка cgroup v2 дистрибутивами Linux

Для ознайомлення зі списком дистрибутивів Linux, які використовують cgroup v2, див. документацію cgroup v2

  • Container Optimized OS (з версії M97)
  • Ubuntu (з версії 21.10, рекомендовано 22.04+)
  • Debian GNU/Linux (з Debian 11 bullseye)
  • Fedora (з версії 31)
  • Arch Linux (з квітня 2021)
  • RHEL та схожі дистрибутиви (з версії 9)

Щоб перевірити, чи ваш дистрибутив використовує cgroup v2, див. документацію вашого дистрибутиву або скористайтеся інструкціями в Визначенні версії cgroup на вузлах Linux.

Також можна включити cgroup v2 вручну у вашому дистрибутиві Linux, змінивши аргументи завантаження ядра. Якщо ваш дистрибутив використовує GRUB, systemd.unified_cgroup_hierarchy=1 повинно бути додано в GRUB_CMDLINE_LINUX в /etc/default/grub, а потім виконайте sudo update-grub. Однак рекомендованим підходом є використання дистрибутиву, який вже стандартно має cgroup v2.

Міграція на cgroup v2

Щоб перейти на cgroup v2, переконайтеся, що ваша система відповідаєте вимогам, а потім оновіть її до версії ядра, яка стандартно має cgroup v2.

Kubelet автоматично виявляє, що ОС працює з cgroup v2 і виконує відповідно без додаткової конфігурації.

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

cgroup v2 використовує інший API, ніж cgroup v1, тому, якщо є застосунки, які безпосередньо отримують доступ до файлової системи cgroup, вони повинні бути оновлені до новіших версій, які підтримують cgroup v2. Наприклад:

  • Деякі сторонні агенти моніторингу та безпеки можуть залежати від файлової системи cgroup. Оновіть ці агенти до версій, які підтримують cgroup v2.
  • Якщо ви використовуєте cAdvisor як окремий DaemonSet для моніторингу Podʼів та контейнерів, оновіть його до v0.43.0 чи новіше.
  • Якщо ви розгортаєте Java-застосунки, віддайте перевагу використанню версій, які повністю підтримують cgroup v2:
  • Якщо ви використовуєте пакунок uber-go/automaxprocs, переконайтеся, що ви використовуєте версію v1.5.1 чи вище.

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

Версія cgroup залежить від використаного дистрибутиву Linux та версії cgroup, налаштованої в ОС. Щоб перевірити, яка версія cgroup використовується вашим дистрибутивом, виконайте команду stat -fc %T /sys/fs/cgroup/ на вузлі:

stat -fc %T /sys/fs/cgroup/

Для cgroup v2 вивід — cgroup2fs.

Для cgroup v1 вивід — tmpfs.

Що далі

3.2.7 - Інтерфейс середовища виконання контейнерів (CRI)

CRI — це інтерфейс втулка, який дозволяє kubelet використовувати різноманітні середовища виконання контейнерів, не маючи потреби перекомпілювати компоненти кластера.

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

Інтерфейс середовища виконання контейнерів (CRI) — основний протокол для взаємодії між kubelet та середовищем виконання контейнерів.

Інтерфейс середовища виконання контейнерів Kubernetes (CRI) визначає основний протокол gRPC для взаємодії між компонентами вузла kubelet та середовищем виконання контейнерів.

API

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

Kubelet діє як клієнт при підключенні до середовища виконання контейнерів через gRPC. Endpointʼи служби виконання та образів повинні бути доступні в середовищі виконання контейнерів, це може бути налаштовано окремо в kubelet за допомогою прапорців командного рядка --image-service-endpoint command line flags.

Для Kubernetes v1.31, kubelet вибирає CRI v1. Якщо середовище виконання контейнерів не підтримує v1 CRI, то kubelet намагається домовитися про будь-яку підтримувану старішу версію. Kubelet v1.31 також може домовитися про CRI v1alpha2, але ця версія вважається застарілою. Якщо kubelet не може домовитися про підтримувану версію CRI, то kubelet припиняє спроби та не реєструє вузол.

Оновлення

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

Що далі

3.2.8 - Збір сміття

Збирання сміття — це загальний термін для різних механізмів, які Kubernetes використовує для очищення ресурсів кластера. Це дозволяє очищати ресурси, такі як:

Власники та залежності

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

Власність відрізняється від механізму міток та селекторів, які також використовують деякі ресурси. Наприклад, розгляньте Service, який створює обʼєкти EndpointSlice. Сервіс використовує мітки, щоб дозволити панелі управління визначити, які обʼєкти EndpointSlice використовуються для цього Сервісу. Кожен обʼєкт EndpointSlice, який керується Сервісом, має власників. Посилання на власника допомагають різним частинам Kubernetes уникати втручання в обʼєкти, якими вони не керують.

Каскадне видалення

Kubernetes перевіряє та видаляє обʼєкти, які більше не мають власників, наприклад, Podʼи, які залишилися після видалення ReplicaSet. Коли ви видаляєте обʼєкт, ви можете контролювати, чи автоматично видаляє Kubernetes залежні обʼєкти, у процесі, що називається каскадним видаленням. Існують два типи каскадного видалення:

  • Каскадне видалення на передньому плані
  • Каскадне видалення у фоні

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

Каскадне видалення на передньому плані

У каскадному видаленні на передньому плані обʼєкт власника, який видаляється, спочатку потрапляє в стан deletion in progress. У цьому стані стається наступне для обʼєкта власника:

  • Сервер API Kubernetes встановлює поле metadata.deletionTimestamp обʼєкта на час, коли обʼєкт був позначений на видалення.
  • Сервер API Kubernetes також встановлює поле metadata.finalizers в foregroundDeletion.
  • Обʼєкт залишається видимим через API Kubernetes, поки не буде завершений процес видалення.

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

Під час каскадного видалення на передньому плані тільки ті залежні обʼєкти, які мають поле ownerReference.blockOwnerDeletion=true, блокують видалення власника. Дивіться Використання каскадного видалення на передньому плані, щоб дізнатися більше.

Каскадне видалення у фоні

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

Дивіться Використання каскадного видалення у фоні, щоб дізнатися більше.

Залишені залежності

Коли Kubernetes видаляє обʼєкт власника, залишені залежні обʼєкти називаються залишеними обʼєктами. Типово Kubernetes видаляє залежні обʼєкти. Щоб дізнатися, як перевизначити цю поведінку, дивіться Видалення власників та залишені залежності.

Збір сміття невикористаних контейнерів та образів

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

Щоб налаштувати параметри для збору сміття невикористаних контейнерів та образів, налаштуйте kubelet за допомогою файлу конфігурації та змініть параметри, повʼязані зі збором сміття, використовуючи ресурс типу KubeletConfiguration.

Життєвий цикл образу контейнера

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

  • HighThresholdPercent
  • LowThresholdPercent

Використання дискового простору вище встановленого значення HighThresholdPercent викликає збір сміття, який видаляє образи в порядку їх останнього використання, починаючи з найстаріших. Kubelet видаляє образи до тих пір, поки використання дискового простору не досягне значення LowThresholdPercent.

Збір сміття для невикористаних контейнерних образів

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

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

Щоб налаштувати параметр встановіть значення поля imageMaximumGCAge в файлі конфігурації kubelet.

Значення вказується як duration Kubernetes; Допустимі одиниці часу для поля imageMaximumGCAge у файлі конфігурації kubelet:

  • «ns» для наносекунд
  • «us» або «µs» для мікросекунд
  • «ms» для мілісекунд
  • «s» для секунд
  • «m» для хвилин
  • «h» для годин

Наприклад, ви можете встановити значення поля конфігурації 12h45m, що означає 12 годин 45 хвилин.

Збір сміття контейнерів

Kubelet збирає сміття невикористаних контейнерів на основі наступних змінних, які ви можете визначити:

  • MinAge: мінімальний вік, при якому kubelet може видаляти контейнер. Вимкніть, встановивши на значення 0.
  • MaxPerPodContainer: максимальна кількість мертвих контейнерів які кожен Pod може мати. Вимкніть, встановивши менше 0.
  • MaxContainers: максимальна кількість мертвих контейнерів у кластері. Вимкніть, встановивши менше 0.

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

MaxPerPodContainer та MaxContainers можуть потенційно конфліктувати одне з одним в ситуаціях, де збереження максимальної кількості контейнерів на кожен Pod (MaxPerPodContainer) вийде за допустиму загальну кількість глобальних мертвих контейнерів (MaxContainers). У цій ситуації kubelet коригує MaxPerPodContainer для вирішення конфлікту. У найгіршому випадку може бути знижений MaxPerPodContainer до 1 та видалені найдавніші контейнери. Крім того, контейнери, які належать Podʼам, які були видалені, видаляються, якщо вони старше MinAge.

Налаштування збору сміття

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

Що далі

3.2.9 - Mixed Version Proxy

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

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

Це дозволяє адміністраторам кластерів налаштовувати високодоступні кластери, які можна модернізувати більш безпечно, направляючи запити на ресурси (зроблені під час оновлення) на правильний kube-apiserver. Цей проксі заважає користувачам бачити несподівані помилки 404 Not Found, які випливають з процесу оновлення.

Цей механізм називається Mixed Version Proxy.

Активація Mixed Version Proxy

Переконайтеся, що функціональну можливість UnknownVersionInteroperabilityProxy увімкнено, коли ви запускаєте API Server:

kube-apiserver \
--feature-gates=UnknownVersionInteroperabilityProxy=true \
# обовʼязкові аргументи командного рядка для цієї функції
--peer-ca-file=<шлях до сертифіката CA kube-apiserver>
--proxy-client-cert-file=<шлях до сертифіката агрегатора проксі>,
--proxy-client-key-file=<шлях до ключа агрегатора проксі>,
--requestheader-client-ca-file=<шлях до сертифіката CA агрегатора>,
# requestheader-allowed-names може бути встановлено як порожнє значення, щоб дозволити будь-яке Загальне Імʼя
--requestheader-allowed-names=<дійсні Загальні Імена для перевірки сертифікату клієнта проксі>,

# необовʼязкові прапорці для цієї функції
--peer-advertise-ip=`IP цього kube-apiserver, яке повинно використовуватися рівноправними для проксі-запитів`
--peer-advertise-port=`порт цього kube-apiserver, який повинен використовуватися рівноправними для проксі-запитів`

# …і інші прапорці як зазвичай

Транспорт та автентифікація проксі між API-серверами

  • Вихідний kube-apiserver повторно використовує наявні прапорці автентифікації клієнта API-сервера --proxy-client-cert-file та --proxy-client-key-file для представлення своєї ідентичності, яку перевіряє його рівноправний (цільовий kube-apiserver). Цей останній підтверджує підключення рівноправного на основі конфігурації, яку ви вказуєте за допомогою аргументу командного рядка --requestheader-client-ca-file.

  • Для автентифікації сертифікатів серверів призначення вам слід налаштувати пакет сертифіката організації, вказавши аргумент командного рядка --peer-ca-file вихідному API-серверу.

Налаштування для зʼєднання з рівноправним API-сервером

Для встановлення мережевого розташування kube-apiserver, яке партнери будуть використовувати для проксі-запитів, використовуйте аргументи командного рядка --peer-advertise-ip та --peer-advertise-port для kube-apiserver або вказуйте ці поля в конфігураційному файлі API-сервера. Якщо ці прапорці не вказані, партнери будуть використовувати значення з аргументів командного рядка --advertise-address або --bind-address для kube-apiserver. Якщо ці прапорці теж не встановлені, використовується типовий інтерфейс хосту.

Mixed version proxying

При активації Mixed version proxying шар агрегації завантажує спеціальний фільтр, який виконує такі дії:

  • Коли запит ресурсу надходить до API-сервера, який не може обслуговувати цей API (чи то тому, що він є версією, що передує введенню API, чи тому, що API вимкнено на API-сервері), API-сервер намагається надіслати запит до рівноправного API-сервера, який може обслуговувати затребуваний API. Це відбувається шляхом ідентифікації груп API / версій / ресурсів, які місцевий сервер не визнає, і спроби проксійовати ці запити до рівноправного API-сервера, який може обробити запит.
  • Якщо рівноправний API-сервер не відповідає, то source API-сервер відповідає помилкою 503 ("Сервіс недоступний").

Як це працює під капотом

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

  • Якщо ресурс відомий API-серверу, що отримав запит (наприклад, GET /api/v1/pods/some-pod), запит обробляється локально.

  • Якщо для запитаного ресурсу не знайдено внутрішнього обʼєкта StorageVersion (наприклад, GET /my-api/v1/my-resource) і налаштовано APIService на проксі до API-сервера розширення, цей проксі відбувається за звичайного процесу для розширених API.

  • Якщо знайдено дійсний внутрішній обʼєкт StorageVersion для запитаного ресурсу (наприклад, GET /batch/v1/jobs) і API-сервер, який намагається обробити запит (API-сервер обробників), має вимкнений API batch, тоді API-сервер, який обробляє запит, витягує рівноправні API-сервери, які обслуговують відповідну групу / версію / ресурс (api/v1/batch у цьому випадку) за інформацією у витягнутому обʼєкті StorageVersion. API-сервер, який обробляє запит, потім проксіює запит до одного з вибраних рівноправних kube-apiservers які обізнані з запитаним ресурсом.

    • Якщо немає партнера, відомого для тієї групи API / версії / ресурсу, API-сервер обробників передає запит своєму власному ланцюжку обробки, який, врешті-решт, повинен повернути відповідь 404 ("Не знайдено").

    • Якщо API-сервер обробників ідентифікував і вибрав рівноправний API-сервер, але цей останній не відповідає (з причин, таких як проблеми з мережевим зʼєднанням або data race між отриманням запиту та реєстрацією інформації партнера в панелі управління), то API-сервер обробників відповідає помилкою 503 ("Сервіс недоступний").

3.3 - Контейнери

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

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

Контейнери відокремлюють застосунки від базової інфраструктури хоста Це полегшує розгортання в різних хмарних або ОС-середовищах.

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

Образи контейнерів

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

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

Середовище виконання контейнерів

Основний компонент, який дозволяє Kubernetes ефективно запускати контейнери. Він відповідає за керування виконанням і життєвим циклом контейнерів у середовищі Kubernetes.

Kubernetes підтримує середовища виконання контейнерів, такі як containerd, CRI-O, та будь-яку іншу реалізацію Kubernetes CRI (інтерфейс виконання контейнерів).

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

Ви також можете використовувати RuntimeClass для запуску різних Podʼів з однаковим контейнером, але з різними налаштуваннями.

3.3.1 - Образ контейнера

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

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

Ця сторінка надає огляд концепції образів контейнерів.

Назви образів

Образам контейнерів зазвичай дається назва, така як pause, example/mycontainer або kube-apiserver. Образ також може містити імʼя хосту реєстру; наприклад: fictional.registry.example/imagename, а також, можливо, номер порту; наприклад: fictional.registry.example:10443/imagename.

Якщо ви не вказуєте імʼя хосту реєстру, Kubernetes вважає, що ви маєте на увазі публічний реєстр образів Docker. Ви можете змінити цю поведінку, вказавши стандартний реєстр образів у налаштуваннях середовища виконання контейнерів.

Після частини назви образу ви можете додати теґ або даджест (так само, якщо ви використовуєте команди типу docker чи podman). Теґи дозволяють ідентифікувати різні версії одного ряду образів. Даджест — унікальний ідентифікатор конкретної версії образу. Даджести є хешами, які визначаються вмістом образу, і вони не змінюються. Теґи можна змініювати, так щоб вони вказували на різні версії образу, даджйести залишаються незмінними.

Теґи образів складаються з малих і великих літер, цифр, підкреслень (_), крапок (.) та тире (-). Довжина теґу може бути до 128 символів. Теґ має відповідати наступному шаблону: [a-zA-Z0-9_][a-zA-Z0-9._-]{0,127}. Дізнатись більше та знайти інші регулярні вирази для перевірки можна в OCI Distribution Specification. Якщо ви не вказуєте теґ, Kubernetes вважає, що ви маєте на увазі теґ latest.

Хеш-сума образу складається з назви алгоритму хешу (наприклад, sha256) і значення хешу. Наприклад: sha256:1ff6c18fbef2045af6b9c16bf034cc421a29027b800e4f9b68ae9b1cb3e9ae07 Додаткову інформацію про формат хешів можна знайти в OCI Image Specification.

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

  • busybox — Тільки назва образу, без теґу або хеша. Kubernetes використовує загальний реєстр Docker і теґ latest. (Те саме, що і docker.io/library/busybox:latest)
  • busybox:1.32.0 — назва образу з теґом. Kubernetes використовує загальний реєстр Docker. (Те саме, що і docker.io/library/busybox:1.32.0)
  • registry.k8s.io/pause:latest — назва образу з власного реєстру і теґом latest.
  • registry.k8s.io/pause:3.5 — назва образу з власного реєстру і теґом, який не є останнім.
  • registry.k8s.io/pause@sha256:1ff6c18fbef2045af6b9c16bf034cc421a29027b800e4f9b68ae9b1cb3e9ae07 — назва образу з хешем.
  • registry.k8s.io/pause:3.5@sha256:1ff6c18fbef2045af6b9c16bf034cc421a29027b800e4f9b68ae9b1cb3e9ae07 — назва образу з теґом і хешем. Тільки хеш буде використаний для завантаження.

Оновлення образів

При першому створенні Deployment, StatefulSet, Pod чи іншого обʼєкта, що включає шаблон Pod, стандартна політика завантаження всіх контейнерів у цьому Pod буде встановлена в IfNotPresent, якщо вона не вказана явно. Ця політика призводить до того, що kubelet пропускає завантаження образів, якщо вони вже існують.

Політика завантаження образів

imagePullPolicy для контейнера та теґ образу впливають на те, коли kubelet намагається завантажити (стягнути) вказаний образ.

Ось список значень, які можна встановити для imagePullPolicy та їхні ефекти:

IfNotPresent
образ завантажується лише тоді, коли він ще не присутній локально.
Always
кожен раз, коли kubelet запускає контейнер, kubelet зверетається до реєстру образів для пошуку відповідності між назвою та образом (digest). Якщо у kubelet є образ контейнера з цим точним хешем в кеші локально, kubelet використовує свій кеш образів; в іншому випадку kubelet завантажує образ зі знайденим хешем та використовує його для запуску контейнера.
Never
kubelet не намагається отримати образ. Якщо образ вже присутній локально, kubelet намагається запустити контейнер; в іншому випадку запуск закінчується невдачею. Див. попередньо завантажені образи для отримання деталей.

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

Щоб переконатися, що Pod завжди використовує ту саму версію образів контейнерів, ви можете вказати хеш образів; замініть <image-name>:<tag> на <image-name>@<digest> (наприклад, image@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2).

При використанні теґів образів, якщо реєстр образів змінив код, який представляє теґ вашого образу, ви могли б отримати суміш Podʼів, що запускають старий і новий код. Дайджест образу унікально ідентифікує конкретну версію образу, тому Kubernetes запускає один і той же код кожного разу, коли він запускає контейнер із вказаним імʼям образу та дайджестом. зазначення образу за допомогою дайджесту виправляє код, який ви запускаєте, так що зміна в реєстрі не може призвести до такого змішаного використання версій.

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

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

Коли ви (чи контролер) подаєте новий Pod серверу API, ваш кластер встановлює поле imagePullPolicy при виконанні певних умов:

  • якщо ви опускаєте поле imagePullPolicy та вказуєте хеш для образів контейнерів, imagePullPolicy автоматично встановлюється в IfNotPresent.
  • якщо ви опускаєте поле imagePullPolicy та теґ для образів контейнерів є :latest, imagePullPolicy автоматично встановлюється в Always;
  • якщо ви опускаєте поле imagePullPolicy та не вказуєте теґ для образів контейнерів, imagePullPolicy автоматично встановлюється в Always;
  • якщо ви опускаєте поле imagePullPolicy та вказуєте теґ для образів контейнерів, який не є :latest, imagePullPolicy автоматично встановлюється в IfNotPresent.

Обовʼязкове завантаження образів

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

  • Встановіть imagePullPolicy контейнера в Always.
  • Опустіть imagePullPolicy і використовуйте :latest як теґ для образів; Kubernetes встановить політику в Always при подачі Pod.
  • Опустіть imagePullPolicy та теґ для використання образів; Kubernetes встановить політику в Always при подачі Pod.
  • Увімкніть контролер допуску AlwaysPullImages.

ImagePullBackOff

Коли kubelet починає створювати контейнери для Pod за допомогою середовища виконання контейнерів, можливо, контейнер перебуває у стані Waiting з причини ImagePullBackOff.

Статус ImagePullBackOff означає, що контейнер не може запуститися через те, що Kubernetes не може завантажити образ контейнера (з причин, таких як невірне імʼя образу або спроба завантаження з приватного реєстру без imagePullSecret). Частина BackOff вказує на те, що Kubernetes буде продовжувати пробувати завантажити образ зі збільшенням інтервалів між спробами.

Kubernetes збільшує інтервал між кожною спробою до тих пір, поки не досягне вбудованого обмеження, яке становить 300 секунд (5 хвилин).

Завантаження образу відповідно до класу середовища виконання

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.29 [alpha]
У Kubernetes є альфа-підтримка для виконання завантаження образів на основі класу середовища виконання контейнерів Pod.

Якщо ви увімкнете функціональну можливість RuntimeClassInImageCriApi, kubelet вказує образи контейнерів кортежем (назва образу, обробник), а не лише назва чи хешем образу. Ваше середовище виконання контейнерів може адаптувати свою поведінку залежно від обраного обробника. Завантаження образів на основі класу середовища виконання буде корисним для контейнерів, що використовують віртуальні машини, таких як контейнери Windows Hyper-V.

Послідовне та паралельне завантаження образів

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

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

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

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

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

Максимальна кількість паралельних завантажень образів

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

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

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

Ви можете встановити maxParallelImagePulls на позитивне число, яке більше або рівне 1. Якщо ви встановите maxParallelImagePulls більше або рівне 2, ви повинні встановити serializeImagePulls в значення false. Kubelet не буде запущено з недійсними налаштуваннями maxParallelImagePulls.

Мультиархітектурні образи з індексами образів

Окрім надання бінарних образів, реєстр контейнерів також може обслуговувати індекс образу контейнера. Індекс образу може посилатися на кілька маніфестів образу для версій контейнера, специфічних для архітектури. Ідея полягає в тому, що ви можете мати імʼя для образу (наприклад: pause, example/mycontainer, kube-apiserver) та дозволити різним системам отримувати правильний бінарний образ для використання на їхній архітектурі машини.

Сам Kubernetes зазвичай називає образи контейнерів із суфіксом -$(ARCH). З метою забезпечення сумісності з попередніми версіями, будь ласка, генеруйте старіші образи із суфіксами. Ідея полягає в тому, щоб створити, наприклад, образ pause, який має маніфест для всіх архітектур, та скажімо pause-amd64, який є сумісним з попередніми конфігураціями або файлами YAML, які можуть містити жорстко закодовані образи із суфіксами.

Використання приватних реєстрів

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

  • Налаштування вузлів для автентифікації в приватному реєстрі
    • всі Podʼи можуть читати будь-які налаштовані приватні реєстри
    • вимагає конфігурації вузла адміністратором кластера
  • Постачальник облікових даних Kubelet для динамічного отримання облікових даних для приватних реєстрів
    • kubelet може бути налаштований для використання втулка від постачальника облікових даних для відповідного приватного реєстру.
  • Попередньо завантажені образи
    • всі Podʼи можуть використовувати будь-які образи, кешовані на вузлі
    • вимагає доступу до кореня на всіх вузлах для налаштування
  • Вказання ImagePullSecrets на Pod
    • лише Podʼи, які надають власні ключі, можуть отримувати доступ до приватного реєстру
  • Постачальник специфічний для вендора або локальні розширення
    • якщо ви використовуєте власну конфігурацію вузла, ви (або ваш постачальник хмари) можете реалізувати власний механізм автентифікації вузла в реєстрі контейнерів.

Ці варіанти пояснюються докладніше нижче.

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

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

Для прикладу конфігурування приватного реєстру образів контейнерів дивіться завдання Завантаження образу з приватного реєстру. У цьому прикладі використовується приватний реєстр в Docker Hub.

Постачальник облікових даних Kubelet для витягування автентифікованих образів

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

Докладніше дивіться Налаштування постачальника облікових даних образу kubelet.

Тлумачення файлу config.json

Тлумачення config.json відрізняється між оригінальною реалізацією Docker та тлумаченням Kubernetes. У Docker ключі auths можуть вказувати тільки кореневі URL-адреси, тоді як Kubernetes дозволяє використовувати глобальні URL-адреси, а також шляхи, які відповідають префіксу. Єдиним обмеженням є те, що глобальні шаблони (*) повинні включати крапку (.) для кожного піддомену. Кількість піддоменів, що мають збіг, повинна дорівнювати кількості глобальних шаблонів (*.), наприклад:

  • *.kubernetes.io не збігатиметься з kubernetes.io, але збігатиметься з abc.kubernetes.io
  • *.*.kubernetes.io не збігатиметься з abc.kubernetes.io, але збігатиметься з abc.def.kubernetes.io
  • prefix.*.io збігатиметься з prefix.kubernetes.io
  • *-good.kubernetes.io збігатиметься з prefix-good.kubernetes.io

Це означає, що файл config.json, подібний до цього, є дійсним:

{
    "auths": {
        "my-registry.io/images": { "auth": "…" },
        "*.my-registry.io/images": { "auth": "…" }
    }
}

Операції отримання образів тепер будуть передавати облікові дані CRI контейнеру для кожного дійсного шаблону. Наприклад, образи контейнера, вказані нижче, успішно збігатимуться:

  • my-registry.io/images
  • my-registry.io/images/my-image
  • my-registry.io/images/another-image
  • sub.my-registry.io/images/my-image

Але не:

  • a.sub.my-registry.io/images/my-image
  • a.b.sub.my-registry.io/images/my-image

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

{
    "auths": {
        "my-registry.io/images": {
            "auth": "…"
        },
        "my-registry.io/images/subpath": {
            "auth": "…"
        }
    }
}

Тепер, якщо контейнер вказує образ my-registry.io/images/subpath/my-image, то kubelet спробує завантажити його з обох джерел автентифікації, якщо завантеження з одного з них виявиться невдалим.

Попередньо завантажені образи

Типово kubelet намагається отримати кожен образ з вказаного реєстру. Однак якщо властивість imagePullPolicy контейнера встановлена на IfNotPresent або Never, то використовується локальний образ (переважно або виключно, відповідно).

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

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

Всі Podʼи матимуть доступ на читання до будь-яких попередньо завантажених образів.

Вказання ImagePullSecrets для Pod

Kubernetes підтримує вказання ключів реєстру образів контейнерів для Pod. imagePullSecrets повинні бути всі в тому ж просторі імен, що й Pod. Зазначені Secrets повинні бути типу kubernetes.io/dockercfg або kubernetes.io/dockerconfigjson.

Створення Secret з Docker-конфігом

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

kubectl create secret docker-registry <name> \
  --docker-server=DOCKER_REGISTRY_SERVER \
  --docker-username=DOCKER_USER \
  --docker-password=DOCKER_PASSWORD \
  --docker-email=DOCKER_EMAIL

Якщо у вас вже є файл облікових даних Docker, ніж використовувати вищезазначену команду, ви можете імпортувати файл облікових даних як Secrets Kubernetes. Створення Secret на основі наявних облікових даних Docker пояснює, як це зробити.

Це особливо корисно, якщо ви використовуєте кілька приватних реєстрів контейнерів, оскільки kubectl create secret docker-registry створює Secret, який працює лише з одним приватним реєстром.

Посилання на imagePullSecrets для Pod

Тепер ви можете створювати Podʼи, які посилаються на цей secret, додавши розділ imagePullSecrets до визначення Pod. Кожен елемент у масиві imagePullSecrets може посилатися тільки на Secret у тому ж просторі імен.

Наприклад:

cat <<EOF > pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: foo
  namespace: awesomeapps
spec:
  containers:
    - name: foo
      image: janedoe/awesomeapp:v1
  imagePullSecrets:
    - name: myregistrykey
EOF

cat <<EOF >> ./kustomization.yaml
resources:
- pod.yaml
EOF

Це слід робити для кожного Podʼа, який використовує приватний реєстр.

Однак налаштування цього поля можна автоматизувати, встановивши imagePullSecrets в ресурс ServiceAccount.

Перевірте Додавання ImagePullSecrets до облікового запису служби для докладних інструкцій.

Ви можете використовувати це разом із .docker/config.json на рівні вузла. Облікові дані обʼєднанні.

Сценарії використання

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

  1. Кластер, в якому використовуються лише непроприєтарні (наприклад, відкриті) образи. Немає потреби приховувати образи.
    • Використовуйте відкриті образи з відкритого реєстру.
      • Конфігурація не потрібна.
      • Деякі постачальники хмари автоматично кешують або дзеркалюють відкриті образи, що підвищує доступність та скорочує час їх отримання.
  2. Кластер, в якому використовуються деякі проприєтарні образи, які повинні бути невидимими для інших компаній, але доступними для всіх користувачів кластера.
    • Використовуйте приватний реєстр.
      • Можлива ручна конфігурація на вузлах, які повинні мати доступ до приватного реєстру.
    • Або запустіть внутрішній приватний реєстр за вашим фаєрволом з відкритим доступом на читання.
      • Не потрібна конфігурація Kubernetes.
    • Використовуйте сервіс реєстрації образів контейнерів, який контролює доступ до образів.
      • Він працюватиме краще з автомасштабуванням кластера, ніж ручна конфігурація вузла.
    • Або на кластері, де зміна конфігурації вузла незручна, використовуйте imagePullSecrets.
  3. Кластер із проприєтарними образами, кілька з яких вимагають строгого контролю доступу.
    • Переконайтеся, що контролер доступу AlwaysPullImages активний. У противному випадку всі Podʼи потенційно мають доступ до всіх образів.
    • Перемістіть конфіденційні дані в ресурс "Secret", а не додавайте їх в образ.
  4. Багатокористувацький кластер, де кожен орендар потребує власного приватного реєстру.
    • Переконайтеся, що контролер доступу AlwaysPullImages активний. У противному випадку всі Podʼи всіх орендарів потенційно мають доступ до всіх образів.
    • Запустіть приватний реєстр з обовʼязковою авторизацією.
    • Створіть обліковий запис реєстру для кожного орендара, розмістіть його в Secret та внесіть Secret в кожний простір імен орендаря.
    • Орендар додає цей Secret до imagePullSecrets кожного простору імен.

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

Застарілий вбудований постачальник облікових даних kubelet

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

Існувало три вбудовані реалізації інтеграції облікових записів kubelet: ACR (Azure Container Registry), ECR (Elastic Container Registry) та GCR (Google Container Registry).

Докладніше про застарілий механізм можна прочитати в документації версії Kubernetes, яку ви використовуєте. У версіях Kubernetes від v1.26 до v1.31 він відсутній, тому вам потрібно або:

  • налаштувати постачальника облікових записів kubelet на кожному вузлі
  • вказати облікові дані для отримання образів, використовуючи imagePullSecrets та принаймні один Secret

Що далі

3.3.2 - Середовище контейнера

Ця сторінка описує ресурси, доступні контейнерам в середовищі контейнера.

Середовище контейнера

Середовище контейнера Kubernetes надає кілька важливих ресурсів контейнерам:

  • Файлову систему, яка є комбінацією образу та одного чи декількох томів.
  • Інформацію про сам контейнер.
  • Інформацію про інші обʼєкти в кластері.

Інформація про контейнер

hostname контейнера є імʼям Pod, в якому він працює. Воно доступне через команду hostname або виклик функції gethostname у бібліотеці libc.

Імʼя та простір імен Pod доступні як змінні середовища через downward API.

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

Інформація про кластер

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

Для служби з імʼям foo, яка повʼязана з контейнером із імʼям bar, визначаються наступні змінні:

FOO_SERVICE_HOST=<хост, на якому працює служба>
FOO_SERVICE_PORT=<порт, на якому працює служба>

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

Що далі

3.3.3 - Клас виконання

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

Ця сторінка описує ресурс RuntimeClass та механізм вибору середовища виконання.

RuntimeClass — це функція для вибору конфігурації середовища виконання контейнерів. Конфігурація середовища виконання контейнерів використовується для запуску контейнерів у Pod.

Мотивація

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

Ви також можете використовувати RuntimeClass для запуску різних Pod з однаковим середовищем виконання, але з різними налаштуваннями.

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

  1. Налаштуйте впровадження CRI на вузлах (залежить від середовища виконання).
  2. Створіть відповідні ресурси RuntimeClass.

1. Налаштуйте впровадження CRI на вузлах

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

Кожна конфігурація має відповідний handler, на який посилається RuntimeClass. Handler повинен бути дійсним імʼям DNS-мітки.

2. Створіть відповідні ресурси RuntimeClass

Кожна конфігурація, налаштована на кроці 1, повинна мати асоційованій handler, який ідентифікує конфігурацію. Для кожного handler створіть обʼєкт RuntimeClass.

Ресурс RuntimeClass наразі має всього 2 значущі поля: імʼя RuntimeClass (metadata.name) та handler (handler). Визначення обʼєкта виглядає наступним чином:

# RuntimeClass визначений у групі API node.k8s.io
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  # Імʼя, за яким буде викликано RuntimeClass.
  # RuntimeClass - ресурс без простору імен.
  name: myclass 
# Імʼя відповідної конфігурації CRI
handler: myconfiguration 

Імʼя обʼєкта RuntimeClass повинно бути дійсним імʼям DNS-піддомену.

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

Після налаштування RuntimeClass для кластера, ви можете вказати runtimeClassName в специфікації Pod, щоб використовувати його. Наприклад:

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  runtimeClassName: myclass
  # ...

Це доручить kubelet використовувати названий RuntimeClass для запуску цього Podʼа. Якщо зазначений RuntimeClass не існує або CRI не може виконати відповідний handler, Pod увійде в термінальну фазу Failed. Шукайте відповідну подію для отримання повідомлення про помилку.

Якщо runtimeClassName не вказано, буде використовуватися стандартний обробник, що еквівалентно поведінці при вимкненні функції RuntimeClass.

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

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

containerd

Обробники Runtime налаштовуються через конфігурацію containerd за шляхом /etc/containerd/config.toml. Дійсні обробники налаштовуються в розділі runtimes:

[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.${HANDLER_NAME}]

Докладніше див. у документації з конфігурації containerd:

CRI-O

Обробники Runtime налаштовуються через конфігурацію CRI-O за шляхом /etc/crio/crio.conf. Дійсні обробники налаштовуються в таблиці crio.runtime:

[crio.runtime.runtimes.${HANDLER_NAME}]
  runtime_path = "${PATH_TO_BINARY}"

Докладніше див. у документації з конфігурації CRI-O.

Планування

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

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

Щоб гарантувати, що Podʼи потрапляють на вузли, які підтримують конкретний RuntimeClass, цей набір вузлів повинен мати спільні мітки, які потім обираються полем runtimeclass.scheduling.nodeSelector. NodeSelector RuntimeClass обʼєднується з nodeSelector Pod під час допуску, фактично беручи перетин множини вузлів, обраних кожним.

Якщо підтримувані вузли позначені, щоб завадити запуску інших Podʼів з іншим RuntimeClass на вузлі, ви можете додати tolerations до RuntimeClass. Як із nodeSelector, tolerations обʼєднуються з tolerations Pod у доступі, фактично беручи обʼєднання множини вузлів, які влаштовують всіх.

Щоб дізнатися більше про налаштування селектора вузла і tolerations, див. Призначення Podʼів вузлам.

Надмірність Pod

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

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

Надмірність Podʼа визначається через поле overhead в RuntimeClass. За допомогою цього поля ви можете вказати надмірність запуску Podʼів, що використовують цей RuntimeClass, та забезпечити облік цих надмірностей в Kubernetes.

Що далі

3.3.4 - Хуки життєвого циклу контейнера

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

Огляд

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

Хуки контейнера

До контейнерів виносяться два хуки:

PostStart

Цей хук виконується негайно після створення контейнера. Однак немає гарантії, що хук виконається до ENTRYPOINT контейнера. До обробника не передаються параметри.

PreStop

Цей хук викликається негайно перед тим, як контейнер буде завершено через запит API або подію управління, таку як невдача проби на живучість/запуску, передумови, конфлікт ресурсів та інші. Звернення до хука PreStop не вдасться, якщо контейнер вже перебуває у стані завершення або виконання, і хук повинен завершити виконання до того, як може бути відправлений сигнал TERM для зупинки контейнера. Відлік пільгового періоду припинення Pod починається до виконання хуку PreStop, тому, незалежно від результату обробника, контейнер врешті-решт закінчиться протягом пільгового періоду припинення Pod. Жодні параметри не передаються обробнику.

Докладний опис поведінки припинення роботи Podʼів можна знайти в Припинення роботи Podʼа.

Реалізації обробника хуків

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

  • Exec — Виконує конкретну команду, таку як pre-stop.sh, всередині cgroups та namespaces контейнера. Ресурси, спожиті командою, зараховуються на рахунок контейнера.
  • HTTP — Виконує HTTP-запит до конкретного endpoint в контейнері.
  • Sleep — Призупиняє контейнер на вказаний час. Обробник "Sleep" є функцією бета-рівня типово увімкненою через функціональну можливість PodLifecycleSleepAction.

Виконання обробника хука

Коли викликається хук управління життєвим циклом контейнера, система управління Kubernetes виконує обробник відповідно до дії хука, httpGet, tcpSocket та sleep виконуються процесом kubelet, а exec виконується в контейнері.

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

Хуки PreStop не викликаються асинхронно від сигналу зупинки контейнера; хук повинен завершити своє виконання до того, як може бути відправлений сигнал TERM. Якщо хук PreStop затримується під час виконання, фаза Pod буде Terminating, і залишиться такою, поки Pod не буде вбито після закінчення його terminationGracePeriodSeconds. Цей період припинення роботи застосовується до загального часу, необхідного як для виконання хука PreStop, так і для зупинки контейнера. Якщо, наприклад, terminationGracePeriodSeconds дорівнює 60, і хук займає 55 секунд для завершення, а контейнер зупиняється нормально через 10 секунд після отримання сигналу, то контейнер буде вбитий перш, ніж він зможе завершити роботу, оскільки terminationGracePeriodSeconds менше, ніж загальний час (55+10), необхідний для цих двох подій.

Якщо хук PostStart або PreStop не вдасться, він вбиває контейнер.

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

Гарантії доставки хуків

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

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

Налагодження обробників хуків

Логи обробника хука не відображаються в подіях Pod. Якщо обробник відмовляється з будь-якої причини, він розсилає подію. Для PostStart це подія FailedPostStartHook, а для PreStop це подія FailedPreStopHook. Щоб згенерувати подію FailedPostStartHook, змініть lifecycle-events.yaml файл, щоб змінити команду postStart на "badcommand" та застосуйте його. Ось приклад виводу події, який ви побачите після виконання kubectl describe pod lifecycle-demo:

Events:
  Type     Reason               Age              From               Message
  ----     ------               ----             ----               -------
  Normal   Scheduled            7s               default-scheduler  Successfully assigned default/lifecycle-demo to ip-XXX-XXX-XX-XX.us-east-2...
  Normal   Pulled               6s               kubelet            Successfully pulled image "nginx" in 229.604315ms
  Normal   Pulling              4s (x2 over 6s)  kubelet            Pulling image "nginx"
 

 Normal   Created              4s (x2 over 5s)  kubelet            Created container lifecycle-demo-container
  Normal   Started              4s (x2 over 5s)  kubelet            Started container lifecycle-demo-container
  Warning  FailedPostStartHook  4s (x2 over 5s)  kubelet            Exec lifecycle hook ([badcommand]) for Container "lifecycle-demo-container" in Pod "lifecycle-demo_default(30229739-9651-4e5a-9a32-a8f1688862db)" failed - error: command 'badcommand' exited with 126: , message: "OCI runtime exec failed: exec failed: container_linux.go:380: starting container process caused: exec: \"badcommand\": executable file not found in $PATH: unknown\r\n"
  Normal   Killing              4s (x2 over 5s)  kubelet            FailedPostStartHook
  Normal   Pulled               4s               kubelet            Successfully pulled image "nginx" in 215.66395ms
  Warning  BackOff              2s (x2 over 3s)  kubelet            Back-off restarting failed container

Що далі

3.4 - Робочі навантаження

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

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

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

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

Kubernetes надає кілька вбудованих ресурсів робочого навантаження:

  • Deployment та ReplicaSet (що є заміною застарілого типу ресурсу ReplicationController). Deployment є хорошим вибором для керування робочим навантаженням, яке не зберігає стану, де будь-який Pod у Deployment може бути замінений, якщо це потрібно.
  • StatefulSet дозволяє вам запускати один або кілька повʼязаних Podʼів, які відстежують стан певним чином. Наприклад, якщо ваше робоче навантаження постійно записує дані, ви можете запустити StatefulSet, який поєднує кожен Pod з PersistentVolume. Ваш код, який працює в Pod для цього StatefulSet, може реплікувати дані на інші Podʼи в цьому StatefulSet, щоб покращити загальну надійність.
  • DaemonSet визначає Podʼи які надають можливості, що локальними для вузлів. Кожного разу, коли ви додаєте вузол до свого кластера, який відповідає специфікації в DaemonSet, панель управління планує Pod для цього DaemonSet на новому вузлі. Кожен Pod в DaemonSet виконує роботу, схожу на роботу системного демона у класичному Unix/POSIX сервері. DaemonSet може бути фундаментальним для роботи вашого кластера, як, наприклад, втулок мережі кластера, він може допомогти вам керувати вузлом, або надати додаткову поведінку, яка розширює платформу контейнерів, яку ви використовуєте.
  • Job та CronJob надають різні способи визначення завдань, які виконуються до завершення та зупиняються. Ви можете використовувати Job для визначення завдання, яке виконується до завершення, тільки один раз. Ви можете використовувати CronJob для запуску того ж Job кілька разів згідно з розкладом.

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

Що далі

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

Щоб дізнатись про механізми Kubernetes для відокремлення коду від конфігурації, відвідайте сторінку Конфігурація.

Існують два концепти, які надають фонову інформацію про те, як Kubernetes керує Podʼами для застосунків:

  • Збір сміття приводить до ладу обʼєкти у вашому кластері після того, як їх власний ресурс був видалений.
  • Контролер time-to-live after finished видаляє Jobʼи після того, як визначений час пройшов після їх завершення.

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

3.4.1 - Podʼи

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

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

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

Що таке Pod?

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

Pod схожий на набір контейнерів із спільними просторами імен та спільними ресурсами файлових систем.

Podʼи в кластері Kubernetes використовуються двома основними способами:

  • Podʼи, що керують одним контейнером. Модель "один контейнер на Pod" є найпоширенішим використанням в Kubernetes. У цьому випадку Pod можна розглядати як обгортку навколо одного контейнера; Kubernetes керує Podʼами, а не контейнерами безпосередньо.
  • Podʼи, що керують кількома контейнерами, які мають працювати разом. Pod може інкапсулювати застосунок, який складається з кількох розміщених разом контейнерів, які тісно повʼязані та мають спільні ресурси. Такі контейнери утворюють єдиний обʼєкт.

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

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

Використання Podʼів

Нижче наведено приклад Pod, який складається з контейнера, який запускає образ nginx:1.14.2.

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80

Для створення Podʼа, показаного вище, виконайте наступну команду:

kubectl apply -f https://k8s.io/examples/pods/simple-pod.yaml

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

Ресурси навантаження для керування Podʼами

Зазвичай у вас немає потреби у створенні окремих Pod напряму в Kubernetes, навіть одиничних Podʼів. Натомість створюйте їх за допомогою ресурсів робочих навантажень, таких як Deployment або Job. Якщо ваші Podʼи потребують відстеження стану, розгляньте використання ресурсу StatefulSet.

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

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

Podʼи можуть надавати два види спільних ресурсів для своїх підпорядкованих контейнерів: мережу та зберігання.

Робота з Podʼами

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

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

Операційна система Podʼа

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

Ви маєте вказати значення поля .spec.os.name як linux або windows, щоб вказати ОС, на якій ви хочете запустити Pod. Ці дві ОС підтримуються Kubernetes. У майбутньому цей список може бути розширений.

У Kubernetes v1.31, значення .spec.os.name не впливає на те, як kube-scheduler вибирає вузол для запуску Podʼа. У будь-якому кластері, де існує більше однієї операційної системи для запуску вузлів, ви повинні правильно встановити мітку kubernetes.io/os на кожному вузлі та визначити Podʼи з використанням nodeSelector на основі мітки операційної системи. Kube-scheduler призначає вашому Podʼа вузол на основі інших критеріїв і може або не може вдало вибрати відповідне розміщення вузлів, де операційна система вузла відповідає контейнерам в такому Podʼі. Стандарти безпеки Pod також використовують це поле, щоб уникнути застосування політик, які не є відповідними для цієї операційної системи.

Podʼи та контролери

Ви можете використовувати ресурси робочих навантажень для створення та керування Podʼами. Контролери ресурсів опікуються реплікацією та розгортанням Podʼів, а також автоматичним відновленням роботи застосунку в разі відмови. Наприклад, якщо Node впав, контролер помітить, що Pod на цьому вузлі перестав працювати, він створить заміну Podʼа. Планувальник поміщає Pod заміну до нового працездатного вузла.

Ось кілька прикладів ресурсів робочих навантажень, які керують одним чи більше Podʼами:

Pod templates

Контролери ресурсів робочих навантажень створюють Pod з pod template та керують цими Podʼом від вашого імені.

PodTemplate — це специфікація для створення Pod, і вона включена в ресурси робочих навантажень, такі як Deployment, Job та DaemonSet.

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

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

Приклад нижче — це маніфест простого Job з template, який запускає один контейнер. Контейнер в цьому Podʼі виводить повідомлення, а потім призупиняється.

apiVersion: batch/v1
kind: Job
metadata:
  name: hello
spec:
  template:
    # Це шаблон Podʼа
    spec:
      containers:
      - name: hello
        image: busybox:1.28
        command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600']
      restartPolicy: OnFailure
    # Кінець щаблону Podʼа

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

Наприклад, контролер StatefulSet переконується, що запущені Pod відповідають поточному template для кожного обʼєкта StatefulSet. Якщо ви редагуєте StatefulSet, щоб змінити його template, StatefulSet починає створювати нові Pod на основі оновленого template. З часом всі старі Pod замінюються новими і оновлення завершується.

Кожен ресурс робочого навантаження реалізує власні правила для обробки змін у template Podʼа. Якщо ви хочете дізнатися більше про StatefulSet, прочитайте Стратегія оновлення в посібнику StatefulSet Basics.

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

Оновлення та заміна Podʼів

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

Kubernetes не забороняє вам керувати Pod напряму. Ви можете оновлювати деякі поля запущеного Pod, на місці. Однак операції оновлення Pod, такі як patch та replace, мають деякі обмеження:

  • Більшість метаданих про Pod є незмінними. Наприклад, ви не можете змінити поля namespace, name, uid або creationTimestamp; поле generation є унікальним. Воно приймає лише оновлення, які збільшують поточне значення поля.
  • Якщо metadata.deletionTimestamp встановлено, новий запис не може бути доданий до списку metadata.finalizers.
  • Оновлення Pod може не змінювати поля, крім spec.containers[*].image, spec.initContainers[*].image, spec.activeDeadlineSeconds або spec.tolerations. Для spec.tolerations ви можете додавати лише нові записи.
  • Коли ви оновлюєте spec.activeDeadlineSeconds, дозволені два типи оновлень:
    1. встановлення непризначеному полю позитивного числа;
    2. оновлення поля з позитивного числа на менше, невідʼємне число.

Спільні ресурси та комунікація

Podʼи дозволяють контейнерам спільно використовувати ресурси та спілкуватися один з одним.

Збереження в Podʼах

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

Мережі та Pod

Кожен Pod отримує власну унікальну IP-адресу для кожного сімейства адрес. Кожен контейнер в Pod використовує спільний простір імен мережі, включаючи IP-адресу та мережеві порти. В межах Pod (і тільки там) контейнери, які належать до Pod, можуть спілкуватися один з одним, використовуючи localhost. Коли контейнери в Pod спілкуються з іншими обʼєктами по за Podʼом, вони повинні координуватись, як вони використовують спільні мережеві ресурси (такі як порти). В межах Pod контейнери спільно використовують IP-адресу та порти, і можуть знаходити один одного через localhost. Контейнери в різних Podʼах мають власні IP-адреси та не можуть спілкуватися за допомогою міжпроцесового звʼязку ОС без спеціальної конфігурації. Контейнери, які хочуть взаємодіяти з контейнером, що працює в іншому Pod, можуть використовувати IP-мережу для комунікації.

Контейнери в Pod бачать системне імʼя хоста таким самим, як і вказане name для Pod. Більше про це ви можете прочитати в розділі мережі.

Налаштування безпеки Podʼів

Для встановлення обмежень безпеки на Podʼи та контейнери використовуйте поле securityContext у специфікації Podʼа. Це поле дозволяє вам здійснювати докладний контроль над тим, що може робити Pod або окремі контейнери. Наприклад:

  • Відкидайте конкретні можливості Linux, щоб уникнути впливу CVE.
  • Примусово запускайте всі процеси в Podʼі як користувач не-root або як певний користувач або ідентифікатор групи.
  • Встановлюйте конкретний профіль seccomp.
  • Встановлюйте параметри безпеки Windows, такі як те, чи працюють контейнери як HostProcess.

Статичні Podʼи

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

Static Pods керуються безпосередньо демоном kubelet на конкретному вузлі, без спостереження з боку сервера API. У той час як більшість Podʼів керуються панеллю управління (наприклад, Deployment), для статичних Podʼів kubelet безпосередньо наглядає за кожним статичним Pod (та перезапускає його, якщо він падає).

Статичні Podʼи завжди привʼязані до одного Kubeletʼу на конкретному вузлі. Основне використання статичних Podʼів — це запуск самостійної панелі управління: іншими словами, використання kubelet для нагляду за окремими компонентами панелі управління.

Kublet автоматично намагається створити mirror Pod на сервері API Kubernetes для кожного статичного Pod. Це означає, що Pod, які працюють на вузлі, видно на сервері API, але ними не можна керувати звідти. Дивіться Створення статичних Podʼів для отримання додаткової інформації.

Як Podʼи керують кількома контейнерами

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

Podʼи в Kubernetes можуть керувати одним або кількома контейнерами двома способами:

  • Podʼи, що керують одним контейнером. Модель "один контейнер на Pod" є найпоширенішим використанням в Kubernetes. У цьому випадку Pod можна розглядати як обгортку навколо одного контейнера; Kubernetes керує Podʼами, а не контейнерами безпосередньо.
  • Podʼи, що керують кількома контейнерами, які мають працювати разом. Pod може інкапсулювати застосунок, який складається з кількох розміщених разом контейнерів, які тісно повʼязані та мають спільні ресурси. Ці спільно розташовані контейнери утворюють єдину цілісну службу — наприклад, один контейнер обслуговує дані, збережені в спільному томі, для загального доступу, тоді як окремий контейнер sidecar оновлює ці файли. Pod обгортає ці контейнери, ресурси сховища та тимчасову мережеву ідентичність разом як єдину одиницю.

Наприклад, у вас може бути контейнер, який виконує функції вебсервера для файлів у спільному томі, та окремий "sidecar" контейнер, який оновлює ці файли з віддаленого джерела, як показано на наступній діаграмі:

Діаграма створення Podʼа

Деякі Podʼи мають контейнери ініціалізації та контейнери застосунку. Типово, контейнери ініціалізації запускаються та завершують роботу перед тим, як почнуть працювати контейнери застосунку.

У вас також може бути "sidecar" контейнер, який виконує додаткові функції для контейнера застосунку, наприклад, реалізує service mesh.

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

Типово увімкнена функціональна можливість SidecarContainers дозволяє вам вказати restartPolicy: Always для контейнерів ініціалізації. Встановлення політики перезапуску Always гарантує, що контейнери, там де ви встановили, будуть вважатися як sidecar та працювати протягом усього життєвого циклу Pod. Контейнери, які явно визначені як sidecar контейнери, стартують до запуску основного застосунку Podʼа та працюють допоки Pod не завершить роботу.

Перевірки контейнерів

Probe — це діагностика, яку періодично виконує kubelet на контейнері. Для виконання діагностики kubelet може використовувати різні дії:

  • ExecAction (виконується за допомогою процесу виконання контейнера)
  • TCPSocketAction (перевіряється безпосередньо the kubelet)
  • HTTPGetAction (перевіряється безпосередньо kubelet)

Ви можете дізнатися більше про перевірки в документації про життєвий цикл Podʼів

Що далі

Для розуміння контексту того, чому Kubernetes обгортає загальний API Pod іншими ресурсами (такими як StatefulSets або Deployments), ви можете прочитати про попередні роботи, включаючи:

3.4.1.1 - Життєвий цикл Pod

Ця сторінка описує життєвий цикл Pod. Podʼи слідують визначеному життєвому циклу, починаючи з фази Pending, переходячи до фази Running, якщо принаймні один з його основних контейнерів запускається добре, а потім до фаз Succeeded або Failed, залежно від того, чи завершився будь-який контейнер у Pod з помилкою.

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

Тривалість життя Pod

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

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

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

Ви можете використати Готовність до планування подів щоб затримати планування для Pod, доки не буде видалено всі його scheduling gates. Наприклад, ви можете визначити набір Podʼів, але запустити планування лише після того, як всі Podʼи будуть створені.

Pods та усунення несправностей

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

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

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

У Kubernetes використовується абстракція вищого рівня, яка називається контролео, яка відповідає за роботу керуванням відносно одноразовими екземплярами Pod.

Даний Pod (визначений UID) ніколи не "переплановується" на інший вузол; замість цього, цей Pod може бути замінений новим, майже ідентичним Podʼом. Якщо ви створюєте новий Pod, він може навіть мати ту саму назву (як у .metadata.name), що й старий Pod, але заміна буде мати інший .metadata.uid, ніж старий Pod.

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

Повʼязані терміни служби

Коли говорять, що щось має такий самий термін життя, як і Pod, наприклад volume, це означає, що ця річ існує стільки часу, скільки існує цей конкретний Pod (з таким самим UID). Якщо цей Pod буде видалений з будь-якої причини, і навіть якщо буде створений ідентичний замінник, повʼязана річ (у цьому прикладі — том) також буде знищена і створена знову.

Багатоконтейнерний Pod, який містить механізм отримання файлів sidecar і веб-сервер. Pod використовує ефемерний том emptyDir для спільного зберігання між контейнерами.

Малюнок 1.

Багатоконтейнерний Pod, який містить механізм отримання файлів sidecar і веб-сервер. Pod використовує ефемерний том emptyDir для спільного зберігання між контейнерами.

Фази Pod

Поле status обʼєкта PodStatus Podʼа містить поле phase.

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

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

Ось можливі значення для phase:

ЗначенняОпис
PendingPod прийнятий кластером Kubernetes, але один чи кілька контейнерів ще не було налаштовано та готові до запуску. Це включає час, який Pod витрачає на очікування планування, а також час, який витрачається на завантаження образів контейнерів з мережі.
RunningPod привʼязаний до вузла, і всі контейнери створені. Принаймні один контейнер все ще працює або перебуває у процесі запуску чи перезапуску.
SucceededВсі контейнери в Podʼі завершили роботу успішно і не будуть перезапущені.
FailedВсі контейнери в Podʼі завершили роботу, і принаймні один контейнер завершився з помилкою. Іншими словами, контейнер вийшов зі статусом, відмінним від нуля, або його завершила система, і контейнер не налаштований на автоматичний перезапуск.
UnknownЗ якоїсь причини не вдалося отримати стан Podʼа. Ця фаза, як правило, виникає через помилку в комунікації з вузлом, де повинен виконуватися Pod.

Починаючи з Kubernetes 1.27, kubelet переводить видалені Podʼи, крім статичних Podʼів та примусово видалених Podʼів без завершувача, в термінальну фазу (Failed або Succeeded залежно від статусів exit контейнерів Podʼа) перед їх видаленням із сервера API.

Якщо вузол вмирає або відключається від іншої частини кластера, Kubernetes застосовує політику встановлення phase всіх Podʼів на втраченому вузлі у Failed.

Стани контейнера

Окрім фаз Podʼа загалом Kubernetes відстежує стан кожного контейнера всередині Podʼа. Ви можете використовувати хуки життєвого циклу контейнера, щоб запускати події на певних етапах життєвого циклу контейнера.

Як тільки планувальник призначає Pod вузлу, kubelet починає створювати контейнери для цього Podʼа, використовуючи середовище виконання контейнерів. Існує три можливі стани контейнера: Waiting (Очікування), Running (Виконання) та Terminated (Завершено).

Щоб перевірити стан контейнерів Podʼа, ви можете використовувати kubectl describe pod <імʼя-пода>. Вивід показує стан для кожного контейнера в межах цього Podʼа.

Кожен стан має конкретне значення:

Waiting

Якщо контейнер не перебуває в стані або Running, або Terminated, то він знаходиться в стані Waiting (Очікування). Контейнер в стані Waiting все ще виконує операції, які він потребує для завершення запуску: наприклад, витягує образ контейнера із реєстру образів контейнерів або застосовує Secret. Коли ви використовуєте kubectl для опитування Podʼа із контейнером, який перебуває в стані Waiting, ви також бачите поле Reason, щоб узагальнити причину, чому контейнер знаходиться в цьому стані.

Running

Статус Running вказує на те, що виконання контейнера відбувається без проблем. Якщо існує налаштований хук postStart — його роботу завершено. Коли ви використовуєте kubectl для опитування Podʼа із контейнером, який перебуває в стані Running, ви також бачите інформацію про те, коли контейнер увійшов в стан Running.

Terminated

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

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

Як Podʼи вирішують проблеми з контейнерами

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

  1. Початковий збій: Kubernetes намагається негайно перезапустити контейнер на основі політики перезапуску Podʼа.
  2. Повторні збої: Після початкового збою Kubernetes застосовує експоненційну затримку для наступних перезапусків, описане в restartPolicy. Це запобігає швидким, повторним спробам перезапуску, що може перенавантажити систему.
  3. Стан CrashLoopBackOff: Це означає, що механізм затримки працює для певного контейнера, який знаходиться в циклі збоїв, невдач і постійного перезапуску.
  4. Скидання затримки: Якщо контейнер успішно працює протягом певного часу (наприклад, 10 хвилин), Kubernetes скидає затримку, розглядаючи будь-який новий збій як перший.

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

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

CrashLoopBackOff може бути спричинений проблемами, такими як:

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

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

  1. Перевірити логи: Використовуйте kubectl logs <name-of-pod>, щоб перевірити логи контейнера. Це часто є безпосереднім способом діагностики проблеми, що викликає збої.
  2. Перевірити події: Використовуйте kubectl describe pod <name-of-pod> для перегляду подій для Podʼа, які можуть надати підказки про проблеми конфігурації або ресурсів.
  3. Перевірити конфігурацію: Переконайтеся, що конфігурація Podʼа, включаючи змінні середовища та змонтовані томи, є правильною і що всі необхідні зовнішні ресурси доступні.
  4. Перевірити обмеження ресурсів: Переконайтеся, що контейнер має достатньо CPU та памʼяті. Іноді збільшення ресурсів у визначенні Podʼа може вирішити проблему.
  5. Перевірити застосунок: Можуть існувати помилки або неправильні конфігурації в коді застосунку. Запуск цього образу контейнера локально або в середовищі розробки може допомогти діагностувати проблеми, специфічні для застосунку.

Політика перезапуску контейнера

У полі spec Podʼа є поле restartPolicy із можливими значеннями Always, OnFailure та Never. Стандартне значення — Always.

restartPolicy для Podʼа застосовується до контейнер застосунків в Podʼі та до звичайних контейнерів ініціалізації. Контейнери Sidecar не звертають уваги на поле restartPolicy на рівні Podʼа: в Kubernetes, sidecar визначається як запис всередині initContainers, який має свою політику перезапуску контейнера на рівні контейнера, встановлену на Always. Для контейнерів ініціалізації, які завершують роботу із помилкою, kubelet виконує їх перезапуск, якщо політика перезапуску Podʼа встановлена як OnFailure або Always:

  • Always: автоматично перезапускає контейнер після його завершення, незалежно від статусу завершення.
  • OnFailure: перезапускає контейнер тільки після його завершення з помилкою (код виходу відмінний від нуля).
  • Never: ніколи автоматично не перезапускає контейнер, що завершив роботу.

Коли kubelet обробляє перезапуск контейнера згідно з налаштованою політикою перезапуску, це стосується лише перезапусків, які призводять до заміни контейнерів всередині того ж Podʼа та на тому ж вузлі. Після завершення контейнерів у Podʼі, kubelet перезапускає їх із затримкою, що зростає експоненційно (10 с, 20 с, 40 с, …), і обмеженою пʼятьма хвилинами (300 секунд). Якщо контейнер виконується протягом 10 хвилин без проблем, kubelet скидає таймер затримки перезапуску для цього контейнера. Контейнери Sidecar та життєвий цикл Podʼа пояснює поведінку контейнерів ініціалізації при вказанні поля restartpolicy для нього.

Стани Podʼа

У Podʼа є статус, який містить масив PodConditions, через які Pod проходить чи не проходить. Kubelet управляє наступними PodConditions:

  • PodScheduled: Pod був запланований на вузол.
  • PodReadyToStartContainers: (бета-функція; типово увімкнено) Pod sandbox був успішно створений, і була налаштована мережа.
  • ContainersReady: всі контейнери в Pod готові.
  • Initialized: всі контейнери ініціалізації успішно завершили виконання.
  • Ready: Pod може обслуговувати запити і його слід додати до балансування навантаження всіх відповідних Services.
Назва поляОпис
typeІмʼя цього стану Podʼа.
statusВказує, чи застосовується цей стан, з можливими значеннями "True", "False" або "Unknown".
lastProbeTimeВідмітка часу останнього запиту стану Podʼа.
lastTransitionTimeВідмітка часу для останнього переходу Podʼа з одного статусу в інший.
reasonМашиночитаний текст у форматі UpperCamelCase, який вказує причину останньої зміни стану.
messageПовідомлення, яке вказує подробиці щодо останнього переходу стану, яке може розібрати людина.

Готовність Podʼа

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

Ваш застосунок може внести додатковий зворотний звʼязок або сигнали в PodStatus: готовність Podʼа. Щоб використовувати це, встановіть readinessGates в spec Podʼа, щоб вказати список додаткових станів, які kubelet оцінює для готовності Podʼа.

Стани готовності визначаються поточним станом полів status.condition для Podʼа. Якщо Kubernetes не може знайти такий стан в полі status.conditions Podʼа, стан подається як "False".

Наприклад:

kind: Pod
...
spec:
  readinessGates:
    - conditionType: "www.example.com/feature-1"
status:
  conditions:
    - type: Ready                              # вбудований стан Podʼа
      status: "False"
      lastProbeTime: null
      lastTransitionTime: 2018-01-01T00:00:00Z
    - type: "www.example.com/feature-1"        # додатковий стан Podʼа
      status: "False"
      lastProbeTime: null
      lastTransitionTime: 2018-01-01T00:00:00Z
  containerStatuses:
    - containerID: docker://abcd...
      ready: true
...

Стани Podʼа, які ви додаєте, повинні мати імена, які відповідають формату ключа міток Kubernetes.

Стан для готовності Podʼа

Команда kubectl patch не підтримує зміну статусу обʼєкта накладанням патчів. Щоб встановити ці status.conditions для Podʼа, застосунки та оператори повинні використовувати дію PATCH. Ви можете використовувати бібліотеку клієнтів Kubernetes для написання коду, який встановлює власні стани Podʼа для готовності Podʼа.

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

  • Всі контейнери в Pod готові.
  • Всі стани, вказані в readinessGates, рівні True.

Коли контейнери Podʼа готові, але принаймні один власний стан відсутній або False, kubelet встановлює стан Podʼа ContainersReady в True.

Готовність мережі Podʼа

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

Після того, як Pod отримує призначення на вузол, йому потрібно бути допущеним до kubelet та мати встановлені всі необхідні томи зберігання. Як тільки ці фази завершаться, kubelet співпрацює з середовищем виконання контейнерів (використовуючи Інтерфейс середовища виконання контейнера (CRI)), щоб налаштувати ізольоване середовище виконання та налаштувати мережу для Podʼа. Якщо функціональну можливість PodReadyToStartContainersCondition увімкнено (є типово увімкненою для Kubernetes 1.31), стан PodReadyToStartContainers буде додано до поля status.conditions Podʼа.

Стан PodReadyToStartContainers встановлюється в False Kubelet, коли він виявляє, що у Podʼа немає ізольованого середовища виконання із налаштованою мережею. Це трапляється в наступних випадках:

  • На початковому етапі життєвого циклу Podʼа, коли kubelet ще не почав налаштовувати середовище виконання для Podʼа за допомогою середовища виконання контейнерів.
  • Пізніше в життєвому циклі Podʼа, коли sandbox Podʼа був знищений через:
    • перезавантаження вузла без вилучення Podʼа
    • для середовищ виконання контейнерів, які використовують віртуальні машини для ізоляції, Pod sandbox віртуальної машини перезавантажується, що потім вимагає створення нового sandbox та свіжої конфігурації мережі контейнера.

Стан PodReadyToStartContainers встановлюється в True kubelet після успішного завершення створення і налаштування ізольованого середовища виконання для Podʼа за допомогою втулка виконання. Kubelet може почати витягувати образ контейнера та створювати контейнери після встановлення стану PodReadyToStartContainers в True.

Для Podʼа з контейнерами ініціалізації kubelet встановлює стан Initialized в True після успішного завершення контейнерів ініціалізації (що відбувається після успішного створення sandbox та налаштування мережі контейнером втулка виконання). Для Podʼа без контейнерів ініціалізації kubelet встановлює стан Initialized в True перед початком створення sandbox та налаштування мережі.

Діагностика контейнера

Проба (probe) — це діагностика, яку періодично виконує kubelet для контейнера. Для виконання діагностики kubelet або виконує код всередині контейнера, або виконує мережевий запит.

Механізми перевірки

Існує чотири різних способи перевірки контейнера за допомогою проб. Кожна проба повинна визначати один з чотирьох цих механізмів:

exec
Виконує вказану команду всередині контейнера. Діагностика вважається успішною, якщо команда виходить з кодом стану 0.
grpc
Виконує віддалений виклик процедури gRPC. Цільовий обʼєкт повинен мати підтримку gRPC health checks. Діагностика вважається успішною, якщо status відповіді рівний SERVING.
httpGet
Виконує HTTP-запит GET до IP-адреси Podʼа з вказаним портом та шляхом. Діагностика вважається успішною, якщо код стану відповіді більший або рівний 200 і менше ніж 400.
tcpSocket
Виконує перевірку TCP до IP-адреси Podʼа за вказаним портом. Діагностика вважається успішною, якщо порт відкритий. Якщо віддалена система (контейнер) відразу закриває зʼєднання після відкриття, це вважається нормальним.

Результат проби

Кожна проба має один із трьох результатів:

Success
Контейнер пройшов діагностику.
Failure
Контейнер не пройшов діагностику.
Unknown
Діагностика не пройшла (не потрібно вживати жодних заходів, і kubelet буде робити подальші перевірки).

Типи проб

Kubelet може опціонально виконувати та реагувати на три типи проб для робочих контейнерів:

livenessProbe
Вказує, чи контейнер працює. Якщо ця проба не проходить, kubelet припиняє роботу контейнера, і він підлягає перезапуску відповідно до своєї політики перезапуску. Якщо контейнер не надає пробу життєздатності, стандартний стан — Success.
readinessProbe
Вказує, чи готовий контейнер відповідати на запити. Якщо проба готовності завершиться невдачею, контролер endpoint видаляє IP-адресу Podʼа з endpoint усіх служб, які відповідають Podʼа. Стандартний стан готовності перед початковою затримкою — Failure. Якщо контейнер не надає пробу готовності, стандартний стан — Success.
startupProbe
Вказує, чи запущено застосунок всередині контейнера. Усі інші проби вимкнено, якщо надана проба запуску, поки вона не стане успішною. Якщо проба запуску завершиться невдачею, kubelet вбиває контейнер, і він підлягає перезапуску відповідно до політики перезапуску. Якщо контейнер не надає пробу запуску, стандартний стан — Success.

Для отримання докладнішої інформації щодо налаштування проб життєздатності, готовності або запуску дивіться Налаштування проб життєздатності, готовності та запуску.

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

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

Якщо ви хочете, щоб роботу вашого контейнера було припинено та він був перезапущений у разі невдачі проби, то вказуйте пробу життєздатності та встановлюйте restartPolicy на Always або OnFailure.

Коли слід використовувати пробу готовності?

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

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

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

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

Коли слід використовувати пробу запуску?

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

Якщо ваш контейнер зазвичай запускається довше, ніж initialDelaySeconds + failureThreshold × periodSeconds, вам слід вказати пробу запуску, яка перевіряє той самий endpoint, що й проба життєздатності. Типово для periodSeconds — 10 секунд. Потім ви повинні встановити його failureThreshold настільки великим, щоб дозволити контейнеру запускатися, не змінюючи стандартних значень проби життєздатності. Це допомагає захистити від блокування роботи.

Завершення роботи Podʼів

Оскільки Podʼи представляють процеси, які виконуються на вузлах кластера, важливо дозволити цим процесам завершувати роботу відповідним чином, коли вони більше не потрібні (замість раптового зупинення за допомогою сигналу KILL і відсутності можливості завершити роботу).

Дизайн спрямований на можливість запитування видалення та знання про те, коли процеси завершують роботу, а також можливість забезпечення завершення видалень у настанні строки. Коли ви запитуєте видалення Podʼа, кластер реєструє та відстежує призначений строк належного припинення роботи перед тим, як дозволити примусове закінчення роботи Podʼа. З цим відстеженням примусового завершення, kubelet намагається виконати належне завершення роботи Podʼа.

Зазвичай, з цим належним завершенням роботи, kubelet робить запити до середовища виконання контейнера з метою спроби зупинити контейнери у Podʼі, спочатку надсилаючи сигнал TERM (також відомий як SIGTERM) основному процесу в кожному контейнері з таймаутом для належного завершення. Запити на зупинку контейнерів обробляються середовищем виконання контейнера асинхронно. Немає гарантії щодо порядку обробки цих запитів. Багато середовищ виконання контейнерів враховують значення STOPSIGNAL, визначене в образі контейнера і, якщо воно відрізняється, надсилають значення STOPSIGNAL, визначене в образі контейнера, замість TERM. Після закінчення строку належного завершення роботи сигнал KILL надсилається до будь-яких залишкових процесів, а потім Pod видаляється з API Server. Якщо kubelet або служба управління середовищем виконання перезапускається під час очікування завершення процесів, кластер повторює спробу спочатку, включаючи повний початковий строк належного завершення роботи.

Приклад припинення роботи Podʼа проілюстровано у наступному прикладі:

  1. Ви використовуєте інструмент kubectl, щоб вручну видалити певний Pod, з типовим значення строку належного припинення роботи (30 секунд).

  2. В Podʼі в API-сервері оновлюється час, поза яким Pod вважається "мертвим", разом із строком належного припинення роботи. Якщо ви використовуєте kubectl describe для перевірки Podʼа, який ви видаляєте, цей Pod показується як "Terminating". На вузлі, на якому виконується Pod: як тільки kubelet бачить, що Pod був позначений як такий, що закінчує роботу (встановлений строк для належного вимкнення), kubelet розпочинає локальний процес вимкнення Podʼа.

    1. Якщо один із контейнерів Podʼа визначає preStop хук, і terminationGracePeriodSeconds в специфікації Podʼа не встановлено на 0, kubelet виконує цей хук всередині контейнера. Стандартно terminationGracePeriodSeconds встановлено на 30 секунд.

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

    2. Kubelet робить виклик до середовища виконання контейнера для надсилання сигналу TERM процесу 1 всередині кожного контейнера.

      Є спеціальний порядок, якщо в Pod визначено будь-які контейнери sidecar. В іншому випадку контейнери в Pod отримують сигнал TERM у різний час і в довільному порядку. Якщо порядок завершення роботи має значення, розгляньте можливість використання хука preStop для синхронізації (або перейдіть на використання контейнерів sidecar).

  3. У той же час, коли kubelet розпочинає належне вимкнення Podʼа, панель управління оцінює, чи слід вилучити цей Pod з обʼєктів EndpointSlice (та Endpoints), де ці обʼєкти представляють Service із налаштованим selector. ReplicaSets та інші ресурси робочого навантаження більше не розглядають такий Pod як дійсний.

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

    Будь-які endpoint, які представляють Podʼи, що закінчують свою роботу, не вилучаються негайно з EndpointSlices, а статус, який вказує на стан завершення, викладається з EndpointSlice API (та застарілого API Endpoints). Endpointʼи, які завершуть роботу, завжди мають статус ready як false (для сумісності з версіями до 1.26), тому балансувальники навантаження не будуть використовувати його для звичайного трафіку.

    Якщо трафік на завершуючомуся Podʼі ще потрібний, фактичну готовність можна перевірити як стан serving. Детальніше про те, як реалізувати очищення зʼєднань, можна знайти в розділі Порядок завершення роботи Podʼів та Endpointʼів

  4. kubelet забезпечує завершення та вимкнення Pod

    1. Коли період очікування закінчується, якщо у Pod все ще працює якийсь контейнер, kubelet ініціює примусове завершення роботи. Середовище виконання контейнера надсилає SIGKILL всім процесам, які ще працюють у будь-якому контейнері в Pod. kubelet також очищає прихований контейнер pause, якщо цей контейнер використовується.
    2. kubelet переводить Pod у термінальну фазу (Failed або Succeeded залежно від кінцевого стану його контейнерів).
    3. kubelet ініціює примусове видалення обʼєкта Pod з API-сервера, встановлюючи період очікування на 0 (негайне видалення).
    4. API-сервер видаляє обʼєкт API Pod, який потім більше не доступний для жодного клієнта.

Примусове завершення Podʼів

Типово всі видалення є належними протягом 30 секунд. Команда kubectl delete підтримує опцію --grace-period=<seconds>, яка дозволяє вам перевизначити типове значення своїм.

Встановлення належного завершення роботи в 0 примусово та негайно видаляє Pod з API сервера. Якщо Pod все ще працює на вузлі, це примусове видалення спричинює початок негайного прибирання kubelet.

Використовуючи kubectl, ви повинні вказати додатковий прапорець --force разом із --grace-period=0, щоб виконати примусове видалення.

Під час примусового видалення API-сервер не чекає підтвердження від kubelet, що Pod завершено на вузлі, на якому він працював. Він негайно видаляє Pod в API, щоб можна було створити новий pod з тим самим імʼям. На вузлі Podʼи, які мають бути видалені негайно, все ще отримують невеликий строк для завершення роботи перед примусовим вимиканням.

Якщо вам потрібно примусово видалити Podʼи, які є частиною StatefulSet, дивіться документацію для видалення Podʼів з StatefulSet.

Завершення роботи Pod і контейнери sidecar

Якщо ваш Pod містить один або більше контейнерів sidecar (init-контейнерів з політикою перезапуску Always), kubelet затримає надсилання сигналу TERM цим контейнерам sidecar, доки останній основний контейнер повністю не завершить роботу. Контейнери sidecar будуть завершені у зворотному порядку, в якому вони визначені в специфікації Pod. Це забезпечує продовження обслуговування контейнерами sidecar інших контейнерів у Pod, доки вони не стануть непотрібними.

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

Аналогічно, якщо Pod має хук preStop, який перевищує період очікування завершення, може статися аварійне завершення. Загалом, якщо ви використовували хуки preStop для керування порядком завершення без контейнерів sidecar, тепер ви можете видалити їх і дозволити kubelet автоматично керувати завершенням роботи контейнерів sidecar.

Збір сміття Podʼів

Для несправних Podʼів обʼєкти API залишаються в API кластера, поки людина чи контролер явно їх не видалять.

Збірник сміття Podʼів (PodGC), який є контролером панелі управління, прибирає завершені Podʼів (із фазою Succeeded або Failed), коли кількість Podʼів перевищує налаштований поріг (визначений параметром terminated-pod-gc-threshold в kube-controller-manager). Це запобігає витоку ресурсів при створенні та завершенні Podʼів з часом.

Крім того, PodGC очищує будь-які Podʼи, які відповідають одній з наступних умов:

  1. є осиротілими Podʼів — привʼязаними до вузла, якого вже не існує,
  2. є незапланованими Podʼами у стані завершення,
  3. є Podʼів у стані завершення, привʼязаними до непрацюючого вузла з позначкою node.kubernetes.io/out-of-service, коли ввімкнено функціонал NodeOutOfServiceVolumeDetach.

Разом із прибиранням Podʼів, PodGC також позначає їх як несправнені, якщо вони перебувають в незавершеній фазі. Крім того, PodGC додає стан руйнування Podʼа під час очищення осиротілого Podʼа. Див. стани руйнування Podʼів для отримання докладніших відомостей.

Що далі

3.4.1.2 - Контейнери ініціалізації

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

Ви можете вказати контейнери ініціалізації в специфікації Podʼа разом із масивом containers (який описує контейнери застосунку).

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

Контейнери ініціалізації

У Pod може бути кілька контейнерів, які виконують застосунки всередині нього, але також може бути один чи кілька контейнерів ініціалізації, які виконуються до того, як стартують контейнери застосунків.

Контейнери ініціалізації абсолютно такі ж, як і звичайні контейнери, окрім того:

  • Контейнери ініціалізації завжди завершуються після виконання завдань ініціалізації.
  • Кожен контейнер ініціалізації повинен успішно завершити свою роботу, перш ніж почнуть свою роботу наступні.

Якщо контейнер init Pod виходить з ладу, kubelet неодноразово перезапускає цей контейнер, поки він не досягне успіху. Однак якщо у Pod встановлено restartPolicy рівне Never, і контейнер ініціалізації виходить з ладу під час запуску Pod, Kubernetes розглядає весь Pod як неуспішний.

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

Стан контейнерів внвціалізації повертається у полі .status.initContainerStatuses у вигляді масиву станів контейнерів (аналогічно полю .status.containerStatuses).

Відмінності від звичайних контейнерів

Контейнери ініціалізації підтримують всі поля та можливості контейнерів застосунків, включаючи обмеження ресурсів, томи та налаштування безпеки. Однак запити та обмеження ресурсів для контейнера ініціалізації обробляються по-іншому, як описано в розділі Спільне використання ресурсів в межах контейнерів.

Звичайні контейнери ініціалізації (іншими словами, виключаючи контейнери sidecar) не підтримують поля lifecycle, livenessProbe, readinessProbe чи startupProbe. Контейнери ініціалізації повинні успішно завершити свою роботу перед тим, як Pod може бути готовий; контейнери sidecar продовжують працювати протягом життєвого циклу Podʼа і підтримують деякі проби. Дивіться контейнер sidecar для отримання додаткової інформації про nfrs контейнери.

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

Відмінності від контейнерів sidecar

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

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

Контейнери ініціалізації не підтримують lifecycle, livenessProbe, readinessProbe чи startupProbe, у той час, як контейнери sidecar підтримують всі ці проби, щоб керувати своїм життєвим циклом.

Контейнери ініціалізації використовують ті ж ресурси (CPU, памʼять, мережу) що й основні контейнери застосунків, але не взаємодіють з ними напряму. Однак вони можуть використовувати спільні томи для обміну даними.

Використання контейнерів ініціалізації

Оскільки контейнери ініціалізації мають окремі образи від контейнерів застосунків, вони мають кілька переваг для коду, повʼязаного із запуском:

  • Контейнери ініціалізації можуть містити утиліти або власний код для налаштування, які відсутні в образі застосунку. Наприклад, немає потреби створювати образ FROM іншого образу лише для використання інструменту, такого як sed, awk, python чи dig під час налаштування.
  • Ролі створення та розгортання образу застосунку можуть працювати незалежно одна від одної без необхідності спільного створення єдиного образу застосунку.
  • Контейнери ініціалізації можуть працювати з різними видами файлових систем порівняно з контейнерами застосунків у тому ж Podʼі. Вони, отже, можуть мати доступ до Secret, до яких контейнери застосунків не можуть отримати доступ.
  • Оскільки контейнери ініціалізації завершують свою роботу, перш ніж будь-які контейнери застосунків розпочнуть свою роботу, вони пропонують механізм блокування або затримки запуску контейнера застосунку до виконання певних умов. Після того, як умови виконані, всі контейнери застосунків у Pod можуть стартувати паралельно.
  • Контейнери ініціалізації можуть безпечно виконувати утиліти або власний код, який інакше зробив би образ контейнера застосунку менш безпечним. Відокремлюючи непотрібні інструменти, ви можете обмежити область атак для вашого образу контейнера застосунку.

Приклади

Ось кілька ідей, як використовувати контейнери ініціалізації:

  • Очікування на створення Service, використовуючи команду оболонки у вигляді одного рядка, наприклад:

    for i in {1..100}; do sleep 1; if nslookup myservice; then exit 0; fi; done; exit 1
    
  • Реєстрація Podʼа у віддаленому сервері зі значеннями, отриманими з Downward API за допомогою команди, подібної цій:

    curl -X POST http://$MANAGEMENT_SERVICE_HOST:$MANAGEMENT_SERVICE_PORT/register -d 'instance=$(<POD_NAME>)&ip=$(<POD_IP>)'
    
  • Очікування певного часу перед запуском контейнера застосунку за допомогою команди, подібної цій:

    sleep 60
    
  • Клонування репозиторію Git в Том

  • Додавання значень у файл конфігурації та виклик інструменту шаблонування для динамічного створення файлу конфігурації для основного контейнера застосунку. Наприклад, додайте значення POD_IP у конфігурації та створюйте основний файл конфігурації застосунку, що використовує Jinja.

Використання контейнерів ініціалізації

У цьому прикладі визначається простий Pod, який має два контейнери ініціалізації. Перший чекає на myservice, а другий — на mydb. Як тільки обидва контейнери ініціалізації завершаться, Pod запускає контейнер застосунку зі свого розділу spec.

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app.kubernetes.io/name: MyApp
spec:
  containers:
  - name: myapp-container
    image: busybox:1.28
    command: ['sh', '-c', 'echo The app is running! && sleep 3600']
  initContainers:
  - name: init-myservice
    image: busybox:1.28
    command: ['sh', '-c', "until nslookup myservice.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for myservice; sleep 2; done"]
  - name: init-mydb
    image: busybox:1.28
    command: ['sh', '-c', "until nslookup mydb.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for mydb; sleep 2; done"]

Ви можете запустити цей Pod, використовуючи:

kubectl apply -f myapp.yaml

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

pod/myapp-pod created

І перевірте його статус за допомогою:

kubectl get -f myapp.yaml

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

NAME        READY     STATUS     RESTARTS   AGE
myapp-pod   0/1       Init:0/2   0          6m

або для отримання більше деталей:

kubectl describe -f myapp.yaml

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

Name:          myapp-pod
Namespace:     default
[...]
Labels:        app.kubernetes.io/name=MyApp
Status:        Pending
[...]
Init Containers:
  init-myservice:
[...]
    State:         Running
[...]
  init-mydb:
[...]
    State:         Waiting
      Reason:      PodInitializing
    Ready:         False
[...]
Containers:
  myapp-container:
[...]
    State:         Waiting
      Reason:      PodInitializing
    Ready:         False
[...]
Events:
  FirstSeen    LastSeen    Count    From                      SubObjectPath                           Type          Reason        Message
  ---------    --------    -----    ----                      -------------                           --------      ------        -------
  16s          16s         1        {default-scheduler }                                              Normal        Scheduled     Successfully assigned myapp-pod to 172.17.4.201
  16s          16s         1        {kubelet 172.17.4.201}    spec.initContainers{init-myservice}     Normal        Pulling       pulling image "busybox"
  13s          13s         1        {kubelet 172.17.4.201}    spec.initContainers{init-myservice}     Normal        Pulled        Successfully pulled image "busybox"
  13s          13s         1        {kubelet 172.17.4.201}    spec.initContainers{init-myservice}     Normal        Created       Created container init-myservice
  13s          13s         1        {kubelet 172.17.4.201}    spec.initContainers{init-myservice}     Normal        Started       Started container init-myservice

Щоб переглянути логи контейнерів ініціалізації у цьому Podʼі, виконайте:

kubectl logs myapp-pod -c init-myservice # Огляд першого контейнера ініціалізації
kubectl logs myapp-pod -c init-mydb      # Огляд другого контейнера ініціалізації

На цей момент ці контейнери ініціалізації будуть чекати виявлення Сервісів з іменами mydb та myservice.

Ось конфігурація, яку ви можете використовувати для того, щоб ці Services зʼявилися:

---
apiVersion: v1
kind: Service
metadata:
  name: myservice
spec:
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9376
---
apiVersion: v1
kind: Service
metadata:
  name: mydb
spec:
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9377

Щоб створити Services mydb та myservice:

kubectl apply -f services.yaml

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

service/myservice created
service/mydb created

Потім ви побачите, що ці контейнери ініціалізації завершаться, і Pod myapp-pod переходить у стан Running:

kubectl get -f myapp.yaml

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

NAME        READY     STATUS    RESTARTS   AGE
myapp-pod   1/1       Running   0          9m

Цей простий приклад повинен дати вам натхнення для створення ваших власних контейнерів ініціалізації. У розділі Що далі є посилання на більш детальний приклад.

Докладний опис поведінки

Під час запуску Pod kubelet затримує виконання контейнерів ініціалізації (init containers), доки мережеве зʼєднання та сховище не будуть готові. Після цього kubelet виконує контейнери ініціалізації Podʼа в порядку, в якому вони зазначені в специфікації Pod.

Кожен контейнер ініціалізації має успішно завершитися перед тим, як буде запущений наступний контейнер. Якщо контейнер не вдалося запустити через помилку середовища виконання або він завершується з помилкою, його перезапускають згідно з політикою перезапуску Podʼів (restartPolicy). Однак, якщо політика перезапуску Podʼа (restartPolicy) встановлена на Always, контейнери ініціалізації використовують політику перезапуску OnFailure.

Pod не може бути Ready, поки всі контейнери ініціалізації не завершаться успішно. Порти контейнерів ініціалізації не агрегуються в Service. Pod, що ініціалізується, перебуває в стані Pending, але повинен мати умову Initialized, встановлену на false.

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

Зміни в специфікації контейнерів ініціалізації обмежуються полем образу контейнера. Зміна поля образу контейнера ініціалізації еквівалентна перезапуску Podʼа.

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

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

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

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

Спільне використання ресурсів між контейнерами

З урахуванням порядку виконання контейнерів ініціалізації, обслуговування та застосунків застосовуються наступні правила використання ресурсів:

  • Найвищий запит чи обмеження будь-якого конкретного ресурсу, визначеного у всіх контейнерах ініціалізації, вважається ефективним запитом/обмеженням ініціалізації. Якщо для будь-якого ресурсу не вказано обмеження, це вважається найвищим обмеженням.
  • Ефективний запит/обмеження Podʼа для ресурсу — більше з:
    • сума всіх запитів/обмежень контейнерів застосунків для ресурсу
    • ефективний запит/обмеження для ініціалізації для ресурсу
  • Планування виконується на основі ефективних запитів/обмежень, що означає, що контейнери ініціалізації можуть резервувати ресурси для ініціалізації, які не використовуються протягом життя Podʼа.
  • Рівень якості обслуговування (QoS), рівень QoS Podʼа — є рівнем QoS як для контейнерів ініціалізації, так і для контейнерів застосунків.

Обмеження та ліміти застосовуються на основі ефективного запиту та ліміту Podʼа.

Контейнери ініціалізація та cgroups Linux

У Linux, розподіл ресурсів для контрольних груп рівня Podʼів (cgroups) ґрунтується на ефективному запиті та ліміті рівня Podʼа, так само як і для планувальника.

Причини перезапуску Pod

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

  • Перезапускається контейнер інфраструктури Podʼа. Це рідкісне явище і його має виконати тільки той, хто має root-доступ до вузлів.
  • Всі контейнери в Podʼі завершуються, коли restartPolicy встановлено в Always, що примушує до перезапуску, а запис про завершення контейнера ініціалізації був втрачено через збирання сміття.

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

Що далі

Дізнайтеся більше про наступне:

3.4.1.3 - Контейнери sidecar

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

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

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

Контейнери sidecar в Kubernetes

Kubernetes впроваджує контейнери sidecar як особливий випадок контейнерів ініціалізації; контейнери sidecar залишаються запущеними після запуску Podʼа. У цьому документі термін звичайні контейнери ініціалізації використовується для чіткого посилання на контейнери, які працюють лише під час запуску Podʼа.

Припускаючи, що у вашому кластері увімкнено функціональну можливість SidecarContainers, (активна починаючи з Kubernetes v1.29), ви можете вказати restartPolicy для контейнерів, вказаних у полі initContainers Podʼа. Ці контейнери sidecar, які перезапускаються, є незалежними від інших контейнерів ініціалізації та від основних контейнерів застосунку у тому ж Podʼі, і можуть бути запущені, зупинені або перезапущені без впливу на основний контейнер застосунку та інші контейнери ініціалізації.

Ви також можете запустити Pod із декількома контейнерами, які не позначені як контейнери ініціалізації або sidecar. Це доцільно, якщо контейнери в межах Podʼа необхідні для його роботи в цілому, але вам не потрібно керувати тим, які контейнери спочатку запускаються або зупиняються. Ви також можете це зробити, якщо вам потрібно підтримувати старі версії Kubernetes, які не підтримують поле restartPolicy на рівні контейнера.

Приклад застосунку

Нижче наведено приклад Deployment з двома контейнерами, один з яких є sidecar:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
  labels:
    app: myapp
spec:
  replicas: 1
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
        - name: myapp
          image: alpine:latest
          command: ['sh', '-c', 'while true; do echo "logging" >> /opt/logs.txt; sleep 1; done']
          volumeMounts:
            - name: data
              mountPath: /opt
      initContainers:
        - name: logshipper
          image: alpine:latest
          restartPolicy: Always
          command: ['sh', '-c', 'tail -F /opt/logs.txt']
          volumeMounts:
            - name: data
              mountPath: /opt
      volumes:
        - name: data
          emptyDir: {}

Контейнери sidecar та життєвий цикл Podʼа

Якщо контейнер ініціалізації створено з параметром restartPolicy, встановленим на Always, він розпочне роботу і залишиться запущеним протягом усього життя Podʼа. Це може бути корисно для запуску служб підтримки, відокремлених від основних контейнерів застосунку.

Якщо для цього контейнера ініціалізації вказано readinessProbe, результат буде використовуватися для визначення стану ready Podʼа.

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

В порівнянні зі звичайними контейнерами ініціалізації, контейнери, визначені в initContainers, продовжують роботу після їх запуску. Це важливо, коли в .spec.initContainers для Podʼа є більше одного запису. Після запуску контейнера ініціалізації типу sidecar (kubelet встановлює статус started для цього контейнера в true), kubelet запускає наступний контейнер ініціалізації з упорядкованого списку .spec.initContainers. Цей статус стає true через те, що в контейнері працює процес і немає визначеного startupProbe, або внаслідок успішного виконання startupProbe.

Завдання з контейнерами sidecar

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

Ось приклад Job із двома контейнерами, один з яких — це контейнер sidecar:

apiVersion: batch/v1
kind: Job
metadata:
  name: myjob
spec:
  template:
    spec:
      containers:
        - name: myjob
          image: alpine:latest
          command: ['sh', '-c', 'echo "logging" > /opt/logs.txt']
          volumeMounts:
            - name: data
              mountPath: /opt
      initContainers:
        - name: logshipper
          image: alpine:latest
          restartPolicy: Always
          command: ['sh', '-c', 'tail -F /opt/logs.txt']
          volumeMounts:
            - name: data
              mountPath: /opt
      restartPolicy: Never
      volumes:
        - name: data
          emptyDir: {}

Відмінності від контейнерів застосунків

Контейнери sidecar працюють поруч з контейнерами застосунку в одному Podʼі. Однак вони не виконують основну логіку застосунку; замість цього вони надають додатковий функціонал основному застосунку.

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

Контейнери sidecar ділять той самий простір імен мережі та сховища з основним контейнером. Це спільне розташування дозволяє їм тісно взаємодіяти та спільно використовувати ресурси.

Відмінності від контейнерів ініціалізації

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

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

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

Контейнери ініціалізації зупиняються до того, як основний контейнер застосунку розпочне роботу, тож контейнер ініціалізації не може обмінюватись повідомленнями з контейнером застосунку в Podʼі. Будь-які дані передаються лише в один бік (наприклад, контейнер ініціалізації може залишити інформацію у томі emptyDir).

Спільне використання ресурсів всередині контейнерів

З урахуванням порядку виконання контейнерів ініціалізації, обслуговування та застосунків застосовуються наступні правила використання ресурсів:

  • Найвищий запит чи обмеження будь-якого конкретного ресурсу, визначеного у всіх контейнерах ініціалізації, вважається ефективним запитом/обмеженням ініціалізації. Якщо для будь-якого ресурсу не вказано обмеження, це вважається найвищим обмеженням.
  • Ефективний запит/обмеження Podʼа для ресурсу — більше з:
    • сума всіх запитів/обмежень контейнерів застосунків для ресурсу
    • ефективний запит/обмеження для ініціалізації для ресурсу
  • Планування виконується на основі ефективних запитів/обмежень, що означає, що контейнери ініціалізації можуть резервувати ресурси для ініціалізації, які не використовуються протягом життя Podʼа.
  • Рівень якості обслуговування (QoS), рівень QoS Podʼа — є рівнем QoS як для контейнерів ініціалізації, так і для контейнерів застосунків.

Обмеження та ліміти застосовуються на основі ефективного запиту та ліміту Podʼа.

Контейнери sidecar та cgroups Linux

У Linux, розподіл ресурсів для контрольних груп рівня Podʼів (cgroups) ґрунтується на ефективному запиті та ліміті рівня Podʼа, так само як і для планувальника.

Що далі

3.4.1.4 - Ефемерні контейнери

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

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

Розуміння ефемерних контейнерів

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

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

Що таке ефемерний контейнер?

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

  • У ефемерних контейнерів не може бути портів, тому такі поля, як ports, livenessProbe, readinessProbe, заборонені.
  • Виділення ресурсів для Podʼа незмінне, тому встановлення resources заборонене.
  • Для повного списку дозволених полів дивіться документацію по ефемерним контейнерам (EphemeralContainer).

Ефемерні контейнери створюються за допомогою спеціального обробника ephemeralcontainers в API замість того, щоб додавати їх безпосередньо до pod.spec, тому не можна додавати ефемерний контейнер за допомогою kubectl edit.

Використання ефемерних контейнерів

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

Зокрема образи distroless дозволяють вам розгортати мінімальні образи контейнерів, які зменшують площу атаки та вразливість. Оскільки образи distroless не включають оболонку або будь-які засоби налагодження, складно налагоджувати образи distroless, використовуючи лише kubectl exec.

При використанні ефемерних контейнерів корисно включити спільний простір імен процесу (process namespace sharing), щоб ви могли переглядати процеси в інших контейнерах.

Що далі

3.4.1.5 - Розлади

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

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

Добровільні та невідворотні розлади

Podʼи не зникають, поки хтось (людина або контролер) не знищить їх, або не трапиться невідворотна помилка обладнання чи системного програмного забезпечення.

Ми називаємо ці невідворотні випадки невідворотними розладами застосунку. Приклади:

  • відмова обладнання фізичної машини, яка підтримує вузол
  • адміністратор кластера видаляє віртуальну машину (екземпляр) помилково
  • відмова хмарного провайдера або гіпервізора призводить до зникнення віртуальної машини
  • kernel panic
  • вузол зникає з кластера через поділ мережі кластера
  • виселення Podʼа через вичерпання ресурсів вузла.

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

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

  • видалення розгортання або іншого контролера, який управляє Podʼом
  • оновлення шаблону розгортання Podʼа, що призводить до перезапуску
  • безпосереднє видалення Podʼа (наприклад, випадково)

Дії адміністратора кластера включають:

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

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

Управління розладами

Ось кілька способів помʼякшення невідворотних розладів:

Частота добровільних розладів різниться. На базовому кластері Kubernetes немає автоматизованих добровільних розладів (тільки ті, які ініціює користувач). Однак адміністратор кластера або постачальник хостингу може запускати деякі додаткові служби, які призводять до добровільних розладів. Наприклад, розгортання оновлень програмного забезпечення вузла може призвести до добровільних розладів. Також деякі реалізації автомасштабування кластера (вузла) можуть призводити до добровільних розладів для дефрагментації та ущільнення вузлів. Адміністратор кластера або постачальник хостингу повинні документувати, на якому рівні добровільних розладів, якщо такі є, можна розраховувати. Деякі параметри конфігурації, такі як використання PriorityClasses у вашій специфікації Podʼа, також можуть призводити до добровільних (і невідворотних) розладів.

Бюджет розладів Podʼів

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

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

Як власник застосунку, ви можете створити Бюджет розладів Podʼів (PodDisruptionBudget або PDB) для кожного застосунку. PDB обмежує кількість Podʼів, які можуть бути одночасно вимкнені через добровільні розлади для реплікованого застосунку. Наприклад, застосунок, який працює на основі кворуму, хоче забезпечити, що кількість реплік ніколи не знизиться нижче необхідної для кворуму. Вебінтерфейс, наприклад, може бажати забезпечити, що кількість реплік, які обслуговують навантаження, ніколи не падатиме нижче певного відсотка від загальної кількості.

Менеджери кластерів та постачальники хостингу повинні використовувати інструменти, які дотримуються бюджетів розладів Podʼів, викликаючи Eviction API замість прямого видалення Podʼа або Deployment.

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

PDB визначає кількість реплік, які застосунок може терпіти, порівняно з тим, скільки він має намір мати. Наприклад, Deployment, який має .spec.replicas: 5, повинен мати 5 Podʼів в будь-який момент часу. Якщо PDB дозволяє бути 4 Podʼам одночасно, то Eviction API дозволить добровільне відключення одного (але не двох) Podʼів одночасно.

Група Podʼів, з яких складається застосунок, визначається за допомогою селектора міток, такого самого, як і той, який використовується контролером застосунку (deployment, stateful-set і т. д.).

"Очікувана" кількість Podʼів обчислюється з .spec.replicas ресурсу робочого навантаження (Workload), який управляє цими Podʼами. Панель управління визначає ресурс робочого навантаження, оглядаючи .metadata.ownerReferences Podʼа.

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

Podʼи, які видаляються або недоступні через поетапне оновлення застосунку, дійсно враховуються в бюджеті розладів, але ресурси робочого навантаження (такі як Deployment і StatefulSet) не обмежуються PDB під час поетапного оновлення. Замість цього обробка невдач під час оновлення застосунку конфігурується в специфікації конкретного ресурсу робочого навантаження.

Рекомендується встановлювати політику виселення несправних Podʼів AlwaysAllow у ваших PodDisruptionBudgets для підтримки виселення неправильно працюючих застосунків під час виведення вузла. Стандартна поведінка полягає в тому, що очікується, коли Podʼи застосунку стануть справними перед тим, як виведення може продовжитися.

Коли Pod виводиться за допомогою API виселення, він завершується відповідним чином, з урахуванням налаштувань terminationGracePeriodSeconds його PodSpec.

Приклад бюджету розладів поди

Припустимо, що у кластері є 3 вузли: node-1 до node-3. Кластер виконує кілька застосунків. Один з них має 3 репліки, які спочатку називаються pod-a, pod-b і pod-c. Інший, неповʼязаний з ними Pod без PDB, називається pod-x. Спочатку Podʼи розташовані наступним чином:

node-1node-2node-3
pod-a доступнийpod-b доступнийpod-c доступний
pod-x доступний

Усі 3 Podʼи є частиною Deployment, і вони разом мають PDB, який вимагає, щоб одночасно було доступними принаймні 2 з 3 Podʼів.

Наприклад, припустимо, що адміністратор кластера хоче запровадити нову версію ядра ОС, щоб виправити помилку в ядрі. Адміністратор кластера спочатку намагається вивести з експлуатації node-1 за допомогою команди kubectl drain. Цей інструмент намагається витіснити pod-a і pod-x. Це відбувається миттєво. Обидві Podʼа одночасно переходять в стан terminating. Це переводить кластер у стан:

node-1 drainingnode-2node-3
pod-a terminatingpod-b availablepod-c available
pod-x terminating

Deployment помічає, що один з Podʼів виводиться, тому він створює заміну під назвою pod-d. Оскільки node-1 закритий, він опиняється на іншому вузлі. Також, щось створило pod-y як заміну для pod-x.

(Примітка: для StatefulSet, pod-a, який міг би мати назву щось на зразок pod-0, повинен був би повністю завершити свою роботу, перш ніж його заміна, яка також має назву pod-0, але має інший UID, може бути створений. В іншому випадку приклад застосовується і до StatefulSet.)

Тепер кластер перебуває у такому стані:

node-1 drainingnode-2node-3
pod-a terminatingpod-b availablepod-c available
pod-x terminatingpod-d startingpod-y

У якийсь момент Podʼи завершують свою роботу, і кластер виглядає так:

node-1 drainednode-2node-3
pod-b availablepod-c available
pod-d startingpod-y

На цьому етапі, якщо нетерплячий адміністратор кластера намагається вивести з експлуатації node-2 або node-3, команда виведення буде блокуватися, оскільки доступно тільки 2 Podʼи для Deployment, і його PDB вимагає принаймні 2. Після того, як пройде певний час, pod-d стає доступним.

Тепер стан кластера виглядає так:

node-1 drainednode-2node-3
pod-b availablepod-c available
pod-d availablepod-y

Тепер адміністратор кластера намагається вивести з експлуатації node-2. Команда drain спробує виселити два Podʼи у деякому порядку, скажімо, спочатку pod-b, а потім pod-d. Їй вдасться витіснити pod-b. Але, коли вона спробує витіснити pod-d, отримає відмову через те, що це залишить тільки один доступний Pod для Deployment.

Deployment створює заміну для pod-b з назвою pod-e. Оскільки в кластері недостатньо ресурсів для планування pod-e, виведення знову буде заблоковано. Кластер може опинитися в такому стані:

node-1 drainednode-2node-3no node
pod-b terminatingpod-c availablepod-e pending
pod-d availablepod-y

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

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

  • скільки реплік потрібно для застосунку
  • скільки часу потрібно для відповідного вимикання екземпляра
  • скільки часу потрібно для запуску нового екземпляра
  • типу контролера
  • ресурсів кластера

Умови розладу поду

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

Спеціальна умова DisruptionTarget додається до Podʼа, що вказує, що Pod має бути видалений через розлад. Поле reason умови додатково вказує на одну з наступних причин завершення роботи Podʼа:

PreemptionByScheduler
Pod має бути випереджений планувальником для надання місця новому Podʼа з вищим пріоритетом. Докладніше дивіться Випередження за пріоритетом Podʼа.
DeletionByTaintManager
Pod має бути видалений Менеджером Taint (який є частиною контролера життєвого циклу вузла в kube-controller-manager) через NoExecute taint, який Pod не толерує; див. виселення на основі taint.
EvictionByEvictionAPI
Pod був позначений для виселення за допомогою Kubernetes API.
DeletionByPodGC
Pod, який повʼязаний із вузлом, якого вже не існує, має бути видалений за допомогою збирання сміття Podʼів.
TerminationByKubelet
Pod був примусово завершений kubelet, через виселення через тиск вузла, відповідне вимикання вузла або пріоритет для системно критичних Podʼів.

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

Разом із видаленням Podʼів, збирач сміття Podʼів (PodGC) також відзначатиме їх як неуспішні, якщо вони не знаходяться в фазі завершення роботи (див. також Збирання сміття Podʼів).

При використанні Job (або CronJob) вам може знадобитися використовувати ці умови розладу Podʼа як частину політики невдачі вашого Job Політики невдачі Podʼа.

Розділення ролей власника кластера та власника застосунку

Часто корисно розглядати Менеджера кластера і Власника застосунку як окремі ролі з обмеженим знанням одне про одного. Це розділення обовʼязків може мати сенс у таких сценаріях:

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

Бюджети розладу Podʼів підтримують це розділення ролей, надаючи інтерфейс між цими ролями.

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

Як виконати дії з розладу у вашому кластері

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

  • Примиритись з періодом простою під час оновлення.
  • Перемикнутися на іншу повну репліку кластера.
    • Відсутність простою, але може бути дорогою як для дубльованих вузлів, так і для зусиль людей для оркестрування перемикання.
  • Розробляти застосунки, що терплять розлади, і використовувати бюджети розладу Podʼів.
    • Відсутність простою.
    • Мінімальне дублювання ресурсів.
    • Дозволяє більше автоматизації адміністрування кластера.
    • Написання застосунків, що терплять розлади, складне, але робота з підтримкою добровільних розладів в основному збігається з роботою з підтримкою автомасштабування і толеруючи інші типи рощладів розлади.

Що далі

3.4.1.6 - Класи якості обслуговування (Quality of Service) Podʼів

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

Класи обслуговування (QoS)

Kubernetes класифікує Podʼи, які ви запускаєте, і розподіляє кожен Pod в певний клас обслуговування (Quality of Service, QoS). Kubernetes використовує цю класифікацію для впливу на те, як різні Podʼи обробляються. Kubernetes робить цю класифікацію на основі резервів ресурсів контейнерів у цьому Podʼі, а також того, як ці резерви стосуються обмежень ресурсів. Це відомо як клас обслуговування (Quality of Service, QoS). Kubernetes присвоює кожному Podʼу клас QoS на основі запитів та лімітів ресурсів його складових контейнерів. Класи QoS використовуються Kubernetes для вирішення того, які Podʼи виводити з вузла, який переживає високий тиск на вузол. Можливі класи QoS: Guaranteed, Burstable та BestEffort.

Guaranteed

Podʼи, які мають клас Guaranteed, мають найстрогіші обмеження ресурсів і найменшу ймовірність бути виселеними. Гарантується, що їх не буде примусово завершено, доки вони не перевищать свої ліміти або доки не буде інших Podʼів з меншим пріоритетом, які можна витіснити з вузла. Вони можуть не отримувати ресурси поза вказаними лімітами. Ці Podʼи також можуть використовувати виключно власні CPU, використовуючи політику управління CPU типу static.

Критерії

Щоб Pod отримав клас QoS Guaranteed:

  • У кожному контейнері Podʼа повинен бути ліміт та запит на памʼять.
  • Для кожного контейнера у Podʼі ліміт памʼяті повинен дорівнювати запиту памʼяті.
  • У кожному контейнері Podʼа повинен бути ліміт та запит на CPU.
  • Для кожного контейнера у Podʼі ліміт CPU повинен дорівнювати запиту CPU.

Burstable

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

Критерії

Pod отримує клас QoS Burstable, якщо:

  • Pod не відповідає критеріям класу QoS Guaranteed.
  • Принаймні один контейнер у Podʼі має запит або ліміт пам\яті або CPU.

BestEffort

Podʼи в класі BestEffort можуть використовувати ресурси вузла, які не призначені спеціально для Podʼів інших класів QoS. Наприклад, якщо у вузлі є 16 ядер CPU, і ви призначили 4 ядра CPU під Pod із класом Guaranteed, тоді Pod з класом BestEffort може намагатися використовувати будь-яку кількість решти з 12 ядер CPU.

Kubelet віддає перевагу виселенню Podʼів з класом BestEffort, якщо вузол потрапляє в стан тиску на ресурси.

Критерії

Pod має клас QoS BestEffort, якщо він не відповідає критеріям ані Guaranteed, ані Burstable. Іншими словами, Pod має клас BestEffort лише в тому випадку, якщо жоден з контейнерів у Podʼі не має ліміту або запиту памʼяті, і жоден з контейнерів у Podʼі не має ліміту або запиту CPU. Контейнери в Podʼі можуть запитувати інші ресурси (не CPU чи памʼять) і все одно класифікуватися як BestEffort.

QoS памʼяті з cgroup v2

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

QoS памʼяті використовує контролер памʼяті cgroup v2 для гарантування ресурсів памʼяті в Kubernetes. Запити та ліміти памʼяті контейнерів у Podʼі використовуються для встановлення конкретних інтерфейсів memory.min та memory.high, які надає контролер памʼяті. Коли memory.min встановлено на запити памʼяті, ресурси памʼяті резервуються і ніколи не звільняються ядром; саме так QoS памʼяті забезпечує наявність памʼяті для Podʼів Kubernetes. Якщо в контейнері встановлено ліміти памʼяті, це означає, що системі потрібно обмежити використання памʼяті контейнера; QoS памʼяті використовує memory.high для обмеження роботи навантаження, що наближається до свого ліміту памʼяті, забезпечуючи, що систему не перевантажено миттєвим виділенням памʼяті.

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

Деяка поведінка незалежна від класу QoS

Деяка поведінка є незалежною від класу QoS, який визначає Kubernetes. Наприклад:

  • Будь-який контейнер, що перевищує ліміт ресурсів, буде завершено та перезапущено kubelet без впливу на інші контейнери в цьому Podʼі.

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

  • Запит ресурсів Podʼа дорівнює сумі запитів ресурсів його компонентних контейнерів, а ліміт Podʼа дорівнює сумі лімітів ресурсів його контейнерів.

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

Що далі

3.4.1.7 - Простори імен користувачів

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

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

Процес, який працює як root в контейнері, може працювати як інший (не-root) користувач на хості; іншими словами, процес має повні привілеї для операцій всередині простору користувача, але не має привілеїв для операцій за його межами.

Ви можете використовувати цю функцію, щоб зменшити можливий збиток, який може заподіяти скомпрометований контейнер хосту або іншим Podʼам на тому ж вузлі. Є кілька вразливостей безпеки, які оцінено як ВИСОКІ або КРИТИЧНІ, і які не можна було б використати при активних просторах користувачів. Передбачається, що простір користувачів також буде запобігати деяким майбутнім вразливостям.

Перш ніж ви розпочнете

Це функція, доступна лише для Linux, і потребує підтримки в Linux для монтування idmap на використовуваних файлових системах. Це означає:

  • На вузлі файлова система, яку ви використовуєте для /var/lib/kubelet/pods/, або спеціальна тека, яку ви конфігуруєте для цього, повинна підтримувати монтування idmap.
  • Всі файлові системи, які використовуються в томах Podʼа, повинні підтримувати монтування idmap.

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

Деякі популярні файлові системи, які підтримують монтування idmap в Linux 6.3, — це: btrfs, ext4, xfs, fat, tmpfs, overlayfs.

Крім того, середовище виконання контейнерів та його базове середовище OCI повинні підтримувати простори користувачів. Підтримку надають наступні середовища OCI:

  • crun версії 1.9 або вище (рекомендована версія 1.13+).

Для використання просторів користувачів з Kubernetes також потрібно використовувати CRI середовища виконання контейнерів, щоб мати можливість використовувати цю функцію з Podʼами Kubernetes:

  • CRI-O: версія 1.25 (і пізніше) підтримує простори користувачів для контейнерів.

containerd v1.7 несумісний із підтримкою userns в Kubernetes v1.27 по v1.31. Kubernetes v1.25 і v1.26 використовували попередню реалізацію, яка є сумісною з containerd v1.7 з точки зору підтримки userns. Якщо ви використовуєте версію Kubernetes, відмінну від 1.31, перевірте документацію для цієї версії Kubernetes для найбільш актуальної інформації. Якщо є новіша версія containerd, ніж v1.7, яка доступна для використання, також перевірте документацію containerd щодо інформації про сумісність.

Стан підтримки просторів користувачів в cri-dockerd відстежується у тікеті на GitHub.

Вступ

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

Pod може обрати використовувати простори користувачів, встановивши поле pod.spec.hostUsers в false.

Kubelet вибере host UID/GID, до якого зіставлено Pod, і зробить це так, щоб гарантувати, що жоден з Podʼів на одному вузлі не використовує те саме зіставлення.

Поля runAsUser, runAsGroup, fsGroup тощо в pod.spec завжди звертаються до користувача всередині контейнера.

Дійсні UID/GID, коли ця функція активована, є у діапазоні 0-65535. Це стосується файлів та процесів (runAsUser, runAsGroup і т. д.).

Файли з UID/GID за межами цього діапазону будуть вважатися належними переповненню ID, яке зазвичай дорівнює 65534 (налаштовано в /proc/sys/kernel/overflowuid та /proc/sys/kernel/overflowgid). Однак їх неможливо змінити, навіть якщо запущено як user/group 65534.

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

Розуміння просторів користувачів для Podʼів

Кілька середовищ виконання контейнерів із їхньою типовою конфігурацією (таких як Docker Engine, containerd, CRI-O) використовують простори імен Linux для ізоляції. Існують інші технології, які також можна використовувати з цими середовищами (наприклад, Kata Containers використовує віртуальні машини замість просторів імен Linux). Ця стосується середовищ виконання контейнерів, які використовують простори імен Linux для ізоляції.

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

Це означає, що контейнери можуть працювати як root та зіставлятись з не-root користувачами на хості. Всередині контейнера процес буде вважати себе root (і, отже, інструменти типу apt, yum, ін. працюватимуть нормально), тоді як насправді процес не має привілеїв на хості. Ви можете перевірити це, наприклад, якщо ви перевірите, як користувач запущений у контейнері, виконавши ps aux з хосту. Користувач, якого показує ps, не той самий, що і користувач, якого ви бачите, якщо ви виконаєте команду id всередині контейнера.

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

Крім того, оскільки користувачі в кожному Podʼі будуть зіставлені з різними користувачами на хості, обмежено те, що вони можуть зробити з іншими Podʼами.

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

  • CAP_SYS_MODULE не має жодного ефекту, якщо зіставлено в Podʼі з використанням просторів користувачів, Pod не може завантажити модулі ядра.
  • CAP_SYS_ADMIN обмежений простором користувача Podʼа та є недійсним поза його межами.

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

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

Налаштування вузла для підтримки просторів користувачів

Типово kubelet призначає UID/GID Podʼам вище діапазону 0-65535, ґрунтуючись на припущенні, що файли та процеси хоста використовують UID/GID у цьому діапазоні, що є стандартним для більшості дистрибутивів Linux. Цей підхід запобігає будь-якому перекриттю між UID/GID хостом та UID/GID Podʼів.

Уникнення перекриття є важливим для помʼякшення впливу вразливостей, таких як CVE-2021-25741, де потенційно Pod може читати довільні файли на хості. Якщо UID/GID Podʼа та хосту не перекриваються, те що може робити Pod обмежено: UID/GID Podʼа не буде відповідати власнику/групі файлів хосту.

kubelet може використовувати власний діапазон для ідентифікаторів користувачів та груп для Podʼів. Для налаштування власного діапазону, вузол повинен мати:

  • Користувача kubelet в системі (ви не можете використовувати інше імʼя користувача тут)
  • Встановлений бінарний файл getsubids (частина shadow-utils) та PATH для бінарного файлу kubelet.
  • Конфігурацію допоміжних UID/GID для користувача kubelet (див. man 5 subuid та man 5 subgid).

Цей параметр лише збирає конфігурацію діапазону UID/GID та не змінює користувача, який виконує kubelet.

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

  • Допоміжний ідентифікатор користувача, який визначає початок діапазону UID для Podʼів, має бути кратним 65536 і також повинен бути більшим або рівним 65536. Іншими словами, ви не можете використовувати жодний ідентифікатор з діапазону 0-65535 для Podʼів; kubelet накладає це обмеження, щоб ускладнити створення ненавмисно незахищеної конфігурації.

  • Кількість допоміжних ID повинна бути кратною 65536.

  • Кількість допоміжних ID повинна бути щонайменше 65536 x <maxPods>, де <maxPods> — максимальна кількість Podʼів, які можуть запускатися на вузлі.

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

  • Жоден з призначених діапазонів не повинен перекриватися з будь-яким іншим призначенням.

  • Конфігурація допоміжних ID повинна бути лише одним рядком. Іншими словами, ви не можете мати кілька діапазонів.

Наприклад, ви можете визначити /etc/subuid та /etc/subgid, щоб обидва мати такі записи для користувача kubelet:

# Формат такий
#   імʼя:першийID:кількість ідентифікаторів
# де
# - першийID - 65536 (мінімально можливt значення)
# - кількість ідентифікаторів - 110 (стандартний ліміт кількості) * 65536
kubelet:65536:7208960

Інтеграція з перевірками безпеки доступу в Podʼи

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

Для Podʼів Linux, які увімкнули простори користувачів, Kubernetes послаблює застосування Стандартів безпеки Podʼа контрольованим способом. Цю поведінку можна контролювати за допомогою функціональної можливості UserNamespacesPodSecurityStandards, що дозволяє раннє включення для кінцевих користувачів. Адміністраторам слід забезпечити увімкнення просторів користувачів на всіх вузлах в межах кластера при використанні feature gate.

Якщо ви увімкнете відповідний feature gate та створите Pod, який використовує простори користувачів, yfcnegys поля не будуть обмежені навіть в контекстах, які застосовують Baseline чи Restricted Podʼа. Це не становить проблему безпеки, оскільки root всередині Podʼа з просторами користувачів фактично посилається на користувача всередині контейнера, який ніколи не зіставляється з привілейованим користувачем на хості. Ось список полів, які не перевіряються для Podʼів в цих обставинах:

  • spec.securityContext.runAsNonRoot
  • spec.containers[*].securityContext.runAsNonRoot
  • spec.initContainers[*].securityContext.runAsNonRoot
  • spec.ephemeralContainers[*].securityContext.runAsNonRoot
  • spec.securityContext.runAsUser
  • spec.containers[*].securityContext.runAsUser
  • spec.initContainers[*].securityContext.runAsUser
  • spec.ephemeralContainers[*].securityContext.runAsUser

Обмеження

При використанні просторів користувачів для Podʼа заборонено використовувати інші простори імен хосту. Зокрема, якщо ви встановите hostUsers: false, ви не маєте права встановлювати будь-яке з наступного:

  • hostNetwork: true
  • hostIPC: true
  • hostPID: true

Що далі

3.4.1.8 - Downward API

Є два способи використання полів обʼєкта Pod та контейнера у працюючому контейнері: як змінні середовища та як файли, які заповнюються спеціальним типом тома. Разом ці два способи використання полів обʼєкта Pod та контейнера називають Downward API.

Іноді корисно, щоб контейнер мав інформацію про себе, не будучи занадто повʼязаним із Kubernetes. downward API дозволяє контейнерам використовувати інформацію про себе чи кластер, не використовуючи клієнт Kubernetes або API-сервер.

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

В Kubernetes існують два способи використання полів обʼєкта Pod та контейнера:

Разом ці два способи використання полів обʼєкта Pod та контейнера називають downward API.

Доступні поля

Через downward API доступні не всі поля обʼєкта Kubernetes API. У цьому розділі перераховано доступні поля.

Ви можете передавати інформацію з доступних полів рівня Pod, використовуючи fieldRef. На рівні API spec для Pod завжди визначає принаймні один Контейнер. Ви можете передавати інформацію з доступних полів рівня Container, використовуючи resourceFieldRef.

Інформація, доступна за допомогою fieldRef

Для деяких полів рівня Pod ви можете передати їх контейнеру як змінні середовища або використовуючи том downwardAPI. Поля, доступні через обидва механізми, наступні:

metadata.name
імʼя Pod
metadata.namespace
namespace Pod
metadata.uid
унікальний ідентифікатор Pod
metadata.annotations['<KEY>']
значення аннотації Pod з іменем <KEY> (наприклад, metadata.annotations['myannotation'])
metadata.labels['<KEY>']
текстове значення мітки Pod з іменем <KEY> (наприклад, metadata.labels['mylabel'])

Наступна інформація доступна через змінні середовища, але не як поле fieldRef тома downwardAPI:

spec.serviceAccountName
імʼя service account Pod
spec.nodeName
імʼя вузла, на якому виконується Pod
status.hostIP
основна IP-адреса вузла, до якого призначено Pod
status.hostIPs
IP-адреси — це версія подвійного стека status.hostIP, перша завжди така сама, як і status.hostIP.
status.podIP
основна IP-адреса Pod (зазвичай, його IPv4-адреса)
status.podIPs
IP-адреси — це версія подвійного стека status.podIP, перша завжди така сама, як і status.podIP

Наступна інформація доступна через том downwardAPI fieldRef, але не як змінні середовища:

metadata.labels
всі мітки Pod, в форматі label-key="escaped-label-value" з однією міткою на рядок
metadata.annotations
всі аннотації поду, у форматі annotation-key="escaped-annotation-value" з однією аннотацією на рядок

Інформація, доступна за допомогою resourceFieldRef

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

resource: limits.cpu
Обмеження CPU контейнера
resource: requests.cpu
Вимога CPU контейнера
resource: limits.memory
Обмеження памʼяті контейнера
resource: requests.memory
Вимога памʼяті контейнера
resource: limits.hugepages-*
Обмеження hugepages контейнера
resource: requests.hugepages-*
Вимога hugepages контейнера
resource: limits.ephemeral-storage
Обмеження ефемерних сховищ контейнера
resource: requests.ephemeral-storage
Вимога ефемерних сховищ контейнера

Резервні інформаційні обмеження для ресурсів

Якщо ліміти CPU та памʼяті не вказані для контейнера, і ви використовуєте downward API для спроби викриття цієї інформації, тоді kubelet типово використовує значення для CPU та памʼяті на основі розрахунку розподілених вузлів.

Що далі

Ви можете прочитати про томи downwardAPI.

Ви можете спробувати використовувати downward API для поширення інформації на рівні контейнера чи Pod:

3.4.2 - Керування навантаженням

Kubernetes надає кілька вбудованих API для декларативного керування вашими робочими навантаженнями та їх компонентами.

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

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

Вбудовані API для керування робочими навантаженнями:

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

StatefulSet дозволяє вам керувати одним або кількома Pod, які виконують один і той же код застосунку, де Pod мають унікальну ідентичність. Це відрізняється від Deployment, де очікується, що Pod будуть взаємозамінними. Найпоширеніше використання StatefulSet полягає в тому, щоб забезпечити звʼязок між Pod та їх постійним сховищем. Наприклад, ви можете запустити StatefulSet, який асоціює кожен Pod з PersistentVolume. Якщо один з Pod у StatefulSet зазнає збою, Kubernetes створює новий Pod, який підключений до того ж PersistentVolume.

DemonSet визначає Podʼи, які надають можливості, що є локальними для конкретного вузла; наприклад, драйвер, який дозволяє контейнерам на цьому вузлі отримувати доступ до системи сховища. Ви використовуєте DemonSet, коли драйвер або інша служба рівня вузла має працювати на вузлі, де вона корисна. Кожен Pod в DemonSet виконує роль, схожу на системний демон на класичному сервері Unix/POSIX. DemonSet може бути фундаментальним для роботи вашого кластера, наприклад, як втулок мережі кластера, він може допомогти вам керувати вузлом, або надати додаткову поведінку, яка розширює платформу контейнерів, яку ви використовуєте. Ви можете запускати DemonSet (і їх Podʼи) на кожному вузлі вашого кластера, або лише на підмножині (наприклад, встановити драйвер прискорювача GPU лише на вузлах, де встановлено GPU).

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

Інші теми в цьому розділі:

3.4.2.1 - Deployment

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

Розгортання (Deployment) забезпечує декларативні оновлення для Podʼів та ReplicaSets.

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

Сценарії використання

Наступні сценарії є типовими для Deployment:

Створення Deployment

Розглянемо приклад Deployment. Він створює ReplicaSet для запуску трьох Podʼів nginx:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

В цьому прикладі:

  • Створюється Deployment з назвоюnginx-deployment, назва вказується в полі .metadata.name. Ця назва буде основою для ReplicaSets та Podʼів які буде створено потім. Дивіться Написання Deployment Spec для отримання додаткових відомостей.

  • Deployment створює ReplicaSet, який створює три реплікованих Podʼи, кількість зазначено у полі .spec.replicas.

  • Поле .spec.selector визначає як створений ReplicaSet відшукує Podʼи для керування. В цьому випадку вибирається мітка, яка визначена в шаблоні Pod, app: nginx. Однак можливі складніші правила вибору, якщо шаблон Pod задовольняє це правило.

  • Поле template має наступні вкладені поля:

    • Podʼи позначаються міткою app: nginx з поля .metadata.labels.
    • Шаблон специфікації Podʼа, поле .template.spec, вказує на те, що Podʼи використовують один контейнер, nginx, який використовує образ nginx з Docker Hub версія якого – 1.14.2.
    • Створюється один контейнер, який отримує назву nginx, яка вказана в полі .spec.template.spec.containers[0].name.

Перед тим, як почати, переконайтеся, що ваш кластер Kubernetes працює. Дотримуйтесь наведених нижче кроків для створення Deployment:

  1. Створіть Deployment скориставшись командою:

    kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
    
  2. Виконайте kubectl get deployments для перевірки створення Deployment.

    Якщо Deployment все ще створюється, ви побачите вивід подібний цьому:

    NAME               READY   UP-TO-DATE   AVAILABLE   AGE
    nginx-deployment   0/3     0            0           1s
    

    Коли ви досліджуєте Deploymentʼи у вашому кластері, показуються наступні поля:

    • NAME — містить назву Deploymentʼів у просторі імен.
    • READY — показує скільки реплік застосунку доступно користувачам. Значення відповідає шаблону наявно/бажано.
    • UP-TO-DATE — показує кількість реплік, які були оновлені для досягнення бажаного стану.
    • AVAILABLE — показує скільки реплік доступно користувачам.
    • AGE — показує час впродовж якого застосунок працює.

    Notice how the number of desired replicas is 3 according to .spec.replicas field.

  3. Для перевірки стану розгортання Deployment, виконайте kubectl rollout status deployment/nginx-deployment.

    Має бути подібний вивід:

    Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
    deployment "nginx-deployment" successfully rolled out
    
  4. Запустіть kubectl get deployments знов через кілька секунд. Має бути подібний вивід:

    NAME               READY   UP-TO-DATE   AVAILABLE   AGE
    nginx-deployment   3/3     3            3           18s
    

    Бачите, що Deployment створив три репліки, і всі репліки актуальні (вони містять останній шаблон Pod) та доступні.

  5. Для перевірки ReplicaSet (rs), створених Deployment, виконайте kubectl get rs. Має бути подібний вивід:

    NAME                          DESIRED   CURRENT   READY   AGE
    nginx-deployment-75675f5897   3         3         3       18s
    

    Вивід ReplicaSet має наступні поля:

    • NAME — перелік назв ReplicaSets в просторі імен.
    • DESIRED — показує бажану кількість реплік застосунку, яку ви вказали при створенні Deployment. Це — бажаний стан.
    • CURRENT — показує поточну кількість реплік, що працюють на поточний момент.
    • READY — показує скільки реплік застосунку доступно користувачам.
    • AGE — показує час впродовж якого застосунок працює.

    Зверніть увагу, що назва ReplicaSet завжди складається як [DEPLOYMENT-NAME]-[HASH]. Ця назва буде основою для назв Podʼів, які буде створено потім.

    Рядок HASH є відповідником мітки pod-template-hash в ReplicaSet.

  6. Для ознайомлення з мітками, які було створено для кожного Pod, виконайте kubectl get pods --show-labels. Вивід буде схожим на це:

    NAME                                READY     STATUS    RESTARTS   AGE       LABELS
    nginx-deployment-75675f5897-7ci7o   1/1       Running   0          18s       app=nginx,pod-template-hash=75675f5897
    nginx-deployment-75675f5897-kzszj   1/1       Running   0          18s       app=nginx,pod-template-hash=75675f5897
    nginx-deployment-75675f5897-qqcnn   1/1       Running   0          18s       app=nginx,pod-template-hash=75675f5897
    

    Створений ReplicaSet таким чином переконується, що в наявності є три Podʼи nginx.

Мітка pod-template-hash

Мітка pod-template-hash додається контролером Deployment до кожного ReplicaSet, який створює або бере під нагляд Deployment.

Ця мітка забезпечує унікальність дочірніх ReplicaSets Deploymentʼа. Вона генерується шляхом хешування PodTemplate ReplicaSet, і отриманий хеш використовується як значення мітки, яке додається до селектора ReplicaSet, міток шаблону Podʼа, а також до всіх наявних Podʼів, які можуть бути у ReplicaSet.

Оновлення Deployment

Дотримуйтеся поданих нижче кроків для оновлення вашого Deployment:

  1. Оновіть Podʼи nginx, щоб використовувати образ nginx:1.16.1 замість nginx:1.14.2.

    kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1
    

    або використовуйте наступну команду:

    kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1
    

    де deployment/nginx-deployment вказує на Deployment, nginx — на контейнер, який буде оновлено, і nginx:1.16.1 — на новий образ та його теґ.

    Вивід буде схожий на:

    deployment.apps/nginx-deployment image updated
    

    Альтернативно, ви можете відредагувати розгортання і змінити .spec.template.spec.containers[0].image з nginx:1.14.2 на nginx:1.16.1:

    kubectl edit deployment/nginx-deployment
    

    Вивід буде схожий на:

    deployment.apps/nginx-deployment edited
    
  2. Щоб перевірити статус розгортання, виконайте:

    kubectl rollout status deployment/nginx-deployment
    

    Вивід буде схожий на це:

    Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
    

    або

    deployment "nginx-deployment" successfully rolled out
    

Отримайте більше деталей про ваш оновлений Deployment:

  • Після успішного розгортання можна переглянути Deployment за допомогою kubectl get deployments. Вивід буде схожий на це:

    NAME               READY   UP-TO-DATE   AVAILABLE   AGE
    nginx-deployment   3/3     3            3           36s
    
  • Виконайте kubectl get rs, щоб перевірити, що Deployment оновив Podʼи, створивши новий ReplicaSet та масштабував його до 3 реплік, а також зменшивши розмір старого ReplicaSet до 0 реплік.

    kubectl get rs
    

    Вивід схожий на це:

    NAME                          DESIRED   CURRENT   READY   AGE
    nginx-deployment-1564180365   3         3         3       6s
    nginx-deployment-2035384211   0         0         0       36s
    
  • Виклик get pods повинен тепер показати лише нові Podʼи:

    kubectl get pods
    

    Вивід буде схожий на це:

    NAME                                READY     STATUS    RESTARTS   AGE
    nginx-deployment-1564180365-khku8   1/1       Running   0          14s
    nginx-deployment-1564180365-nacti   1/1       Running   0          14s
    nginx-deployment-1564180365-z9gth   1/1       Running   0          14s
    

    Наступного разу, коли вам потрібно буде оновити ці Podʼи, вам достатньо буде знову оновити шаблон Podʼа в Deployment.

    Deployment забезпечує, що тільки певна кількість Podʼів буде відключена під час оновлення. Типово це забезпечує, що принаймні 75% відомої кількості Podʼів будуть активними (максимум недоступних 25%).

    Deployment також забезпечує, що тільки певна кількість Podʼів буде створена поверх відомої кількості Podʼів. Типово це забезпечує, що як максимум буде активно 125% відомої кількості Podʼів (25% максимального збільшення).

    Наприклад, якщо ви ретельно досліджуєте Deployment вище, ви побачите, що спочатку було створено новий Pod, потім видалено старий Pod і створено ще один новий. Старі Podʼи не прибираються допоки не зʼявиться достатня кількість нових, і не створюються нові Podʼи допоки не буде прибрано достатню кількість старих. Deployment переконується, що принаймні 3 Podʼи доступні, і що вони не перевищують 4 Podʼа. У випадку розгортання з 4 репліками кількість Podʼів буде між 3 і 5.

  • Отримайте деталі вашого розгортання:

    kubectl describe deployments
    

    Вивід буде схожий на це:

    Name:                   nginx-deployment
    Namespace:              default
    CreationTimestamp:      Thu, 30 Nov 2017 10:56:25 +0000
    Labels:                 app=nginx
    Annotations:            deployment.kubernetes.io/revision=2
    Selector:               app=nginx
    Replicas:               3 desired | 3 updated | 3 total | 3 available | 0 unavailable
    StrategyType:           RollingUpdate
    MinReadySeconds:        0
    RollingUpdateStrategy:  25% max unavailable, 25% max surge
    Pod Template:
      Labels:  app=nginx
       Containers:
        nginx:
          Image:        nginx:1.16.1
          Port:         80/TCP
          Environment:  <none>
          Mounts:       <none>
        Volumes:        <none>
      Conditions:
        Type           Status  Reason
        ----           ------  ------
        Available      True    MinimumReplicasAvailable
        Progressing    True    NewReplicaSetAvailable
      OldReplicaSets:  <none>
      NewReplicaSet:   nginx-deployment-1564180365 (3/3 replicas created)
      Events:
        Type    Reason             Age   From                   Message
        ----    ------             ----  ----                   -------
        Normal  ScalingReplicaSet  2m    deployment-controller  Scaled up replica set nginx-deployment-2035384211 to 3
        Normal  ScalingReplicaSet  24s   deployment-controller  Scaled up replica set nginx-deployment-1564180365 to 1
        Normal  ScalingReplicaSet  22s   deployment-controller  Scaled down replica set nginx-deployment-2035384211 to 2
        Normal  ScalingReplicaSet  22s   deployment-controller  Scaled up replica set nginx-deployment-1564180365 to 2
        Normal  ScalingReplicaSet  19s   deployment-controller  Scaled down replica set nginx-deployment-2035384211 to 1
        Normal  ScalingReplicaSet  19s   deployment-controller  Scaled up replica set nginx-deployment-1564180365 to 3
        Normal  ScalingReplicaSet  14s   deployment-controller  Scaled down replica set nginx-deployment-2035384211 to 0
    

    Тут ви бачите, що при створенні Deployment спочатку було створено ReplicaSet (nginx-deployment-2035384211) та масштабовано його до 3 реплік безпосередньо. Коли ви оновили Deployment, було створено новий ReplicaSet (nginx-deployment-1564180365) та масштабовано його до 1, потім Deployment дочекався, коли він запуститься. Потім було зменшено розмір старого ReplicaSet до 2 і масштабовано новий ReplicaSet до 2, таким чином, щоб принаймні 3 Podʼа були доступні, і не більше 4 Podʼів в будь-який момент. Потім було продовжено масштабування нового та старого ReplicaSet, з однаковою стратегією поетапного оновлення. У кінці вас буде 3 доступні репліки в новому ReplicaSet, і старий ReplicaSet зменшений до 0.

Rollover (або кілька одночасних оновлень)

Кожного разу, коли новий Deployment спостерігається контролером Deployment, ReplicaSet створюється для запуску необхідних Podʼів. Якщо Deployment оновлюється, поточний ReplicaSet, Podʼи якого збігаються з міткам з .spec.selector, але не збігаються з .spec.template, зменшується. Зрештою, новий ReplicaSet масштабується до .spec.replicas, і всі старі ReplicaSets масштабуються в 0.

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

Наприклад, припустимо, ви створюєте Deployment для створення 5 реплік nginx:1.14.2, але потім оновлюєте Deployment для створення 5 реплік nginx:1.16.1, коли вже створено тільки 3 репліки nginx:1.14.2. У цьому випадку Deployment негайно починає знищувати 3 Podʼи nginx:1.14.2, які вже створено, і починає створювати Podʼи nginx:1.16.1. Deployment не чекає, доки буде створено 5 реплік nginx:1.14.2, перш ніж змінити напрямок.

Оновлення селектора міток

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

  • Додавання селектора вимагає оновлення міток шаблону Podʼа в специфікації Deployment новою міткою, інакше буде повернуто помилку перевірки. Ця зміна не є такою, що перетинається з наявними мітками, що означає, що новий селектор не вибирає ReplicaSets та Podʼи, створені за допомогою старого селектора, що призводить до залишення всіх старих ReplicaSets та створення нового ReplicaSet.
  • Оновлення селектора змінює поточне значення ключа селектора — призводить до такого ж результату, як і додавання.
  • Вилучення селектора вилучає наявний ключ з селектора Deployment — не вимагає будь-яких змін у мітках шаблону Podʼа. Наявні ReplicaSets не залишаються сиротами, і новий ReplicaSet не створюється, але слід зауважити, що вилучена мітка все ще існує в будь-яких наявних Podʼах і ReplicaSets.

Відкат Deployment

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

  • Припустимо, ви припустилися помилки при оновленні Deployment, вказавши назву образу як nginx:1.161 замість nginx:1.16.1:

    kubectl set image deployment/nginx-deployment nginx=nginx:1.161
    

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

    deployment.apps/nginx-deployment image updated
    
  • Розгортання застрягає. Ви можете перевірити це, перевіривши стан розгортання:

    kubectl rollout status deployment/nginx-deployment
    

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

    Waiting for rollout to finish: 1 out of 3 new replicas have been updated...
    
  • Натисніть Ctrl-C, щоб зупинити спостереження за станом розгортання. Щодо деталей розгортання, що застрягло, читайте тут.

  • Ви бачите, що кількість старих реплік (додаючи кількість реплік від nginx-deployment-1564180365 та nginx-deployment-2035384211) — 3, а кількість нових реплік (від nginx-deployment-3066724191) — 1.

    kubectl get rs
    

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

    NAME                          DESIRED   CURRENT   READY   AGE
    nginx-deployment-1564180365   3         3         3       25s
    nginx-deployment-2035384211   0         0         0       36s
    nginx-deployment-3066724191   1         1         0       6s
    
  • При перегляді створених Podʼів ви бачите, що 1 Pod, створений новим ReplicaSet, застряг у циклі завантаження образу.

    kubectl get pods
    

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

    NAME                                READY     STATUS             RESTARTS   AGE
    nginx-deployment-1564180365-70iae   1/1       Running            0          25s
    nginx-deployment-1564180365-jbqqo   1/1       Running            0          25s
    nginx-deployment-1564180365-hysrc   1/1       Running            0          25s
    nginx-deployment-3066724191-08mng   0/1       ImagePullBackOff   0          6s
    
  • Отримання опису розгортання:

    kubectl describe deployment
    

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

    Name:           nginx-deployment
    Namespace:      default
    CreationTimestamp:  Tue, 15 Mar 2016 14:48:04 -0700
    Labels:         app=nginx
    Selector:       app=nginx
    Replicas:       3 desired | 1 updated | 4 total | 3 available | 1 unavailable
    StrategyType:       RollingUpdate
    MinReadySeconds:    0
    RollingUpdateStrategy:  25% max unavailable, 25% max surge
    Pod Template:
      Labels:  app=nginx
      Containers:
       nginx:
        Image:        nginx:1.161
        Port:         80/TCP
        Host Port:    0/TCP
        Environment:  <none>
        Mounts:       <none>
      Volumes:        <none>
    Conditions:
      Type           Status  Reason
      ----           ------  ------
      Available      True    MinimumReplicasAvailable
      Progressing    True    ReplicaSetUpdated
    OldReplicaSets:     nginx-deployment-1564180365 (3/3 replicas created)
    NewReplicaSet:      nginx-deployment-3066724191 (1/1 replicas created)
    Events:
      FirstSeen LastSeen    Count   From                    SubObjectPath   Type        Reason              Message
      --------- --------    -----   ----                    -------------   --------    ------              -------
      1m        1m          1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-2035384211 to 3
      22s       22s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-1564180365 to 1
      22s       22s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled down replica set nginx-deployment-2035384211 to 2
      22s       22s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-1564180365 to 2
      21s       21s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled down replica set nginx-deployment-2035384211 to 1
      21s       21s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-1564180365 to 3
      13s       13s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled down replica set nginx-deployment-2035384211 to 0
      13s       13s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-3066724191 to 1
    

    Для виправлення цього вам потрібно відкотитиcm до попередньої ревізії Deployment, яка є стабільною.

Перевірка історії розгортання Deployment

Виконайте наведені нижче кроки, щоб перевірити історію розгортань:

  1. По-перше, перевірте ревізії цього Deployment:

    kubectl rollout history deployment/nginx-deployment
    

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

    deployments "nginx-deployment"
    REVISION    CHANGE-CAUSE
    1           kubectl apply --filename=https://k8s.io/examples/controllers/nginx-deployment.yaml
    2           kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1
    3           kubectl set image deployment/nginx-deployment nginx=nginx:1.161
    

    CHANGE-CAUSE копіюється з анотації Deployment kubernetes.io/change-cause до його ревізій при створенні. Ви можете вказати повідомлення CHANGE-CAUSE:

    • Анотуючи Deployment командою kubectl annotate deployment/nginx-deployment kubernetes.io/change-cause="image updated to 1.16.1"
    • Ручним редагуванням маніфесту ресурсу.
  2. Щоб переглянути деталі кожної ревізії, виконайте:

    kubectl rollout history deployment/nginx-deployment --revision=2
    

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

    deployments "nginx-deployment" revision 2
      Labels:       app=nginx
              pod-template-hash=1159050644
      Annotations:  kubernetes.io/change-cause=kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1
      Containers:
       nginx:
        Image:      nginx:1.16.1
        Port:       80/TCP
         QoS Tier:
            cpu:      BestEffort
            memory:   BestEffort
        Environment Variables:      <none>
      No volumes.
    

Відкат до попередньої ревізії

Виконайте наведені нижче кроки, щоб відкотити Deployment з поточної версії на попередню версію, яка є версією 2.

  1. Тепер ви вирішили скасувати поточне розгортання та повернутися до попередньої ревізії:

    kubectl rollout undo deployment/nginx-deployment
    

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

    deployment.apps/nginx-deployment rolled back
    

    Замість цього ви можете виконати відкат до певної ревізії, вказавши її параметром --to-revision:

    kubectl rollout undo deployment/nginx-deployment --to-revision=2
    

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

    deployment.apps/nginx-deployment rolled back
    

    Для отримання додаткових відомостей про команди, повʼязані з розгортаннями, читайте kubectl rollout.

    Deployment тепер повернуто до попередньої стабільної ревізії. Як ви можете бачити, контролер розгортань генерує подію DeploymentRollback щодо відкату до ревізії 2.

  2. Перевірте, чи відкат був успішним і Deployment працює як очікується, виконавши:

    kubectl get deployment nginx-deployment
    

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

    NAME               READY   UP-TO-DATE   AVAILABLE   AGE
    nginx-deployment   3/3     3            3           30m
    
  3. Отримайте опис розгортання:

    kubectl describe deployment nginx-deployment
    

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

    Name:                   nginx-deployment
    Namespace:              default
    CreationTimestamp:      Sun, 02 Sep 2018 18:17:55 -0500
    Labels:                 app=nginx
    Annotations:            deployment.kubernetes.io/revision=4
                            kubernetes.io/change-cause=kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1
    Selector:               app=nginx
    Replicas:               3 desired | 3 updated | 3 total | 3 available | 0 unavailable
    StrategyType:           RollingUpdate
    MinReadySeconds:        0
    RollingUpdateStrategy:  25% max unavailable, 25% max surge
    Pod Template:
      Labels:  app=nginx
      Containers:
       nginx:
        Image:        nginx:1.16.1
        Port:         80/TCP
        Host Port:    0/TCP
        Environment:  <none>
        Mounts:       <none>
      Volumes:        <none>
    Conditions:
      Type           Status  Reason
      ----           ------  ------
      Available      True    MinimumReplicasAvailable
      Progressing    True    NewReplicaSetAvailable
    OldReplicaSets:  <none>
    NewReplicaSet:   nginx-deployment-c4747d96c (3/3 replicas created)
    Events:
      Type    Reason              Age   From                   Message
      ----    ------              ----  ----                   -------
      Normal  ScalingReplicaSet   12m   deployment-controller  Scaled up replica set nginx-deployment-75675f5897 to 3
      Normal  ScalingReplicaSet   11m   deployment-controller  Scaled up replica set nginx-deployment-c4747d96c to 1
      Normal  ScalingReplicaSet   11m   deployment-controller  Scaled down replica set nginx-deployment-75675f5897 to 2
      Normal  ScalingReplicaSet   11m   deployment-controller  Scaled up replica set nginx-deployment-c4747d96c to 2
      Normal  ScalingReplicaSet   11m   deployment-controller  Scaled down replica set nginx-deployment-75675f5897 to 1
      Normal  ScalingReplicaSet   11m   deployment-controller  Scaled up replica set nginx-deployment-c4747d96c to 3
      Normal  ScalingReplicaSet   11m   deployment-controller  Scaled down replica set nginx-deployment-75675f5897 to 0
      Normal  ScalingReplicaSet   11m   deployment-controller  Scaled up replica set nginx-deployment-595696685f to 1
      Normal  DeploymentRollback  15s   deployment-controller  Rolled back deployment "nginx-deployment" to revision 2
      Normal  ScalingReplicaSet   15s   deployment-controller  Scaled down replica set nginx-deployment-595696685f to 0
    

Масштабування Deployment

Ви можете масштабувати Deployment за допомогою наступної команди:

kubectl scale deployment/nginx-deployment --replicas=10

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

deployment.apps/nginx-deployment scaled

Припускаючи, що горизонтальне автомасштабування Pod увімкнено у вашому кластері, ви можете налаштувати автомасштабування для вашого Deployment і вибрати мінімальну та максимальну кількість Podʼів, які ви хочете запустити на основі використання ЦП вашими поточними Podʼами.

kubectl autoscale deployment/nginx-deployment --min=10 --max=15 --cpu-percent=80

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

deployment.apps/nginx-deployment scaled

Пропорційне масштабування

Deployment RollingUpdate підтримує виконання кількох версій застосунку одночасно. Коли ви або автомасштабування масштабуєте Deployment RollingUpdate, яке знаходиться в процесі розгортання (будь-то в процесі або призупинено), контролер Deployment балансує додаткові репліки в наявних активних ReplicaSets (ReplicaSets з Podʼами), щоб помʼякшити ризик. Це називається пропорційним масштабуванням.

Наприклад, ви використовуєте Deployment з 10 репліками, maxSurge=3 та maxUnavailable=2.

  • Переконайтеся, що в вашому Deployment працює 10 реплік.

    kubectl get deploy
    

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

    NAME                 DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
    nginx-deployment     10        10        10           10          50s
    
  • Ви оновлюєте образ, який, як виявляється, неможливо знайти в межах кластера.

    kubectl set image deployment/nginx-deployment nginx=nginx:sometag
    

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

    deployment.apps/nginx-deployment image updated
    
  • Оновлення образу розпочинає новий rollout з ReplicaSet nginx-deployment-1989198191, але воно блокується через вимогу maxUnavailable, яку ви вказали вище. Перевірте стан rollout:

    kubectl get rs
    

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

    NAME                          DESIRED   CURRENT   READY     AGE
    nginx-deployment-1989198191   5         5         0         9s
    nginx-deployment-618515232    8         8         8         1m
    
  • Потім надходить новий запит на масштабування для Deployment. Автомасштабування збільшує репліки Deployment до 15. Контролер Deployment повинен вирішити, куди додати цих нових 5 реплік. Якби ви не використовували пропорційне масштабування, всі 5 реплік були б додані в новий ReplicaSet. З пропорційним масштабуванням ви розподіляєте додаткові репліки між всіма ReplicaSets. Більші частки йдуть в ReplicaSets з найбільшою кількістю реплік, а менші частки йдуть в ReplicaSets з меншою кількістю реплік. Залишки додаються до ReplicaSet з найбільшою кількістю реплік. ReplicaSets з нульовою кількістю реплік не масштабуються.

У нашому прикладі вище 3 репліки додаються до старого ReplicaSet, а 2 репліки — до нових ReplicaSet. Процес розгортання повинен остаточно перемістити всі репліки в новий ReplicaSet, за умови, що нові репліки стають справними. Для підтвердження цього виконайте:

kubectl get deploy

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

NAME                 DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment     15        18        7            8           7m

Статус rollout підтверджує, як репліки були додані до кожного ReplicaSet.

kubectl get rs

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

NAME                          DESIRED   CURRENT   READY     AGE
nginx-deployment-1989198191   7         7         0         7m
nginx-deployment-618515232    11        11        11        7m

Призупинення та відновлення розгортання Deployment

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

  • Наприклад, з Deployment, яке було створено:

    Отримайте деталі Deployment:

    kubectl get deploy
    

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

    NAME      DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
    nginx     3         3         3            3           1m
    

    Отримайте стан розгортання:

    kubectl get rs
    

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

    NAME               DESIRED   CURRENT   READY     AGE
    nginx-2142116321   3         3         3         1m
    
  • Зробіть паузу за допомогою наступної команди:

    kubectl rollout pause deployment/nginx-deployment
    

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

    deployment.apps/nginx-deployment paused
    
  • Потім оновіть образ в Deployment:

    kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1
    

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

    deployment.apps/nginx-deployment image updated
    
  • Зверніть увагу, що новий rollout не розпочався:

    kubectl rollout history deployment/nginx-deployment
    

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

    deployments "nginx"
    REVISION  CHANGE-CAUSE
    1   <none>
    
  • Отримайте стан розгортання, щоб перевірити, що існуючий ReplicaSet не змінився:

    kubectl get rs
    

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

    NAME               DESIRED   CURRENT   READY     AGE
    nginx-2142116321   3         3         3         2m
    
  • Ви можете робити стільки оновлень, скільки вам потрібно, наприклад, оновіть ресурси, які будуть використовуватися:

    kubectl set resources deployment/nginx-deployment -c=nginx --limits=cpu=200m,memory=512Mi
    

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

    deployment.apps/nginx-deployment resource requirements updated
    

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

  • У кінці відновіть розгортання Deployment і спостерігайте, як новий ReplicaSet зʼявляється з усіма новими оновленнями:

    kubectl rollout resume deployment/nginx-deployment
    

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

    deployment.apps/nginx-deployment resumed
    
  • Спостерігайте за статусом розгортання, доки воно не завершиться.

    kubectl get rs --watch
    

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

    NAME               DESIRED   CURRENT   READY     AGE
    nginx-2142116321   2         2         2         2m
    nginx-3926361531   2         2         0         6s
    nginx-3926361531   2         2         1         18s
    nginx-2142116321   1         2         2         2m
    nginx-2142116321   1         2         2         2m
    nginx-3926361531   3         2         1         18s
    nginx-3926361531   3         2         1         18s
    nginx-2142116321   1         1         1         2m
    nginx-3926361531   3         3         1         18s
    nginx-3926361531   3         3         2         19s
    nginx-2142116321   0         1         1         2m
    nginx-2142116321   0         1         1         2m
    nginx-2142116321   0         0         0         2m
    nginx-3926361531   3         3         3         20s
    
  • Отримайте статус останнього розгортання:

    kubectl get rs
    

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

    NAME               DESIRED   CURRENT   READY     AGE
    nginx-2142116321   0         0         0         2m
    nginx-3926361531   3         3         3         28s
    

Статус Deployment

Deployment переходить через різні стани протягом свого життєвого циклу. Він може бути d процесі, коли виконується розгортання нового ReplicaSet, може бути завершеним або невдалим.

Deployment в процесі

Kubernetes позначає Deployment як в процесі (progressing), коли виконується одне з наступних завдань:

  • Deployment створює новий ReplicaSet.
  • Deployment масштабує вгору свій новий ReplicaSet.
  • Deployment масштабує вниз свої старі ReplicaSet(s).
  • Нові Podʼи стають готовими або доступними (готові принаймні MinReadySeconds).

Коли розгортання стає "в процесі" (progressing), контролер Deployment додає умову із наступними атрибутами до .status.conditions Deployment:

  • type: Progressing
  • status: "True"
  • reason: NewReplicaSetCreated | reason: FoundNewReplicaSet | reason: ReplicaSetUpdated

Ви можете відстежувати хід розгортання за допомогою kubectl rollout status.

Завершений Deployment

Kubernetes позначає Deployment як завершений (complete), коли він має наступні характеристики:

  • Всі репліки, повʼязані з Deployment, були оновлені до останньої версії, яку ви вказали. Це означає, що всі запитані вами оновлення були завершені.
  • Всі репліки, повʼязані з Deployment, доступні.
  • Не працюють жодні старі репліки для Deployment.

Коли розгортання стає "завершеним" (complete), контролер Deployment встановлює умову із наступними атрибутами до .status.conditions Deployment:

  • type: Progressing
  • status: "True"
  • reason: NewReplicaSetAvailable

Ця умова Progressing буде зберігати значення статусу "True" до тих пір, поки не буде запущено нове розгортання. Умова залишається незмінною навіть тоді, коли змінюється доступність реплік (це не впливає на умову Available).

Ви можете перевірити, чи завершено Deployment, використовуючи kubectl rollout status. Якщо Deployment завершився успішно, kubectl rollout status повертає код виходу нуль (успіх).

kubectl rollout status deployment/nginx-deployment

Вивід буде схожий на наступний:

Waiting for rollout to finish: 2 of 3 updated replicas are available...
deployment "nginx-deployment" successfully rolled out

і код виходу з kubectl rollout дорівнює 0 (успіх):

echo $?
0

Невдалий Deployment

Ваш Deployment може застрягти під час намагання розгорнути свій новий ReplicaSet і ніколи не завершитися. Це може статися через наступне:

  • Недостатні квоти
  • Збій проб readiness
  • Помилки підтягування образів
  • Недостатні дозволи
  • Обмеження лімітів
  • Неправильна конфігурація середовища виконання застосунку

Один із способів виявлення цього стану — це вказати параметр граничного терміну в специфікації вашого розгортання: (.spec.progressDeadlineSeconds). .spec.progressDeadlineSeconds вказує кількість секунд, протягом яких контролер Deployment чекатиме, перш ніж вказати (в статусі Deployment), що прогрес розгортання зупинився.

Наступна команда kubectl встановлює специфікацію з progressDeadlineSeconds, щоб змусити контролер повідомляти про відсутність прогресу розгортання для Deployment після 10 хвилин:

kubectl patch deployment/nginx-deployment -p '{"spec":{"progressDeadlineSeconds":600}}'

Вивід буде схожий на наступний:

deployment.apps/nginx-deployment patched

Після того як граничний термін закінчився, контролер Deployment додає DeploymentCondition з наступними атрибутами до .status.conditions Deployment:

  • type: Progressing
  • status: "False"
  • reason: ProgressDeadlineExceeded

Ця умова також може зазнати невдачі на ранніх етапах, і тоді вона встановлюється в значення статусу "False" з причинами, такими як ReplicaSetCreateError. Крім того, термін не враховується більше після завершення розгортання.

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

Ви можете зіткнутися з тимчасовими помилками у Deployment, або через низький таймаут, який ви встановили, або через будь-який інший вид помилок, який можна розглядати як тимчасовий. Наприклад, допустімо, що у вас недостатні квоти. Якщо ви опишете Deployment, ви помітите наступний розділ:

kubectl describe deployment nginx-deployment

Вивід буде схожий на наступний:

<...>
Conditions:
  Type            Status  Reason
  ----            ------  ------
  Available       True    MinimumReplicasAvailable
  Progressing     True    ReplicaSetUpdated
  ReplicaFailure  True    FailedCreate
<...>

Якщо ви виконаєте kubectl get deployment nginx-deployment -o yaml, статус Deployment схожий на це:

status:
  availableReplicas: 2
  conditions:
  - lastTransitionTime: 2016-10-04T12:25:39Z
    lastUpdateTime: 2016-10-04T12:25:39Z
    message: Replica set "nginx-deployment-4262182780" is progressing.
    reason: ReplicaSetUpdated
    status: "True"
    type: Progressing
  - lastTransitionTime: 2016-10-04T12:25:42Z
    lastUpdateTime: 2016-10-04T12:25:42Z
    message: Deployment has minimum availability.
    reason: MinimumReplicasAvailable
    status: "True"
    type: Available
  - lastTransitionTime: 2016-10-04T12:25:39Z
    last

UpdateTime: 2016-10-04T12:25:39Z
    message: 'Error creating: pods "nginx-deployment-4262182780-" is forbidden: exceeded quota:
      object-counts, requested: pods=1, used: pods=3, limited: pods=2'
    reason: FailedCreate
    status: "True"
    type: ReplicaFailure
  observedGeneration: 3
  replicas: 2
  unavailableReplicas: 2

В решті решт, коли граничний термін прогресу Deployment буде перевищений, Kubernetes оновить статус і причину умови Progressing:

Conditions:
  Type            Status  Reason
  ----            ------  ------
  Available       True    MinimumReplicasAvailable
  Progressing     False   ProgressDeadlineExceeded
  ReplicaFailure  True    FailedCreate

Ви можете вирішити проблему недостатньої квоти, зменшивши масштаб вашого Deployment, зменшивши масштаб інших контролерів, які ви можете виконувати, або збільшивши квоту у вашому просторі імен. Якщо ви задовольните умови квоти і контролер Deployment завершить розгортання, ви побачите, що статус Deployment оновлюється успішною умовою (status: "True" та reason: NewReplicaSetAvailable).

Conditions:
  Type          Status  Reason
  ----          ------  ------
  Available     True    MinimumReplicasAvailable
  Progressing   True    NewReplicaSetAvailable

type: Available з status: "True" означає, що у вас є мінімальна доступність Deployment. Мінімальна доступність визначається параметрами, вказаними в стратегії розгортання. type: Progressing з status: "True" означає, що ваш Deployment або знаходиться в середині розгортання і прогресує, або він успішно завершив свій прогрес, і доступна мінімально необхідна нова кількість реплік (див. причину умови для конкретики — у нашому випадку reason: NewReplicaSetAvailable означає, що Deployment завершено).

Ви можете перевірити, чи Deployment не вдався за допомогою kubectl rollout status. kubectl rollout status повертає код виходу, відмінний від нуля, якщо Deployment перевищив граничний термін виконання.

kubectl rollout status deployment/nginx-deployment

Вивід буде схожий на наступний:

Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
error: deployment "nginx" exceeded its progress deadline

і код виходу з kubectl rollout дорівнює 1 (позначає помилку):

echo $?
1

Операції з невдалим Deployment

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

Політика очищення

Ви можете встановити поле .spec.revisionHistoryLimit у Deployment, щоб вказати, скільки старих ReplicaSets для цього Deployment ви хочете зберегти. Решта буде видалена як сміття в фоновому режимі. Типове значення становить 10.

Canary Deployment

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

Написання специфікації Deployment

Як і з усіма іншими конфігураціями Kubernetes, у Deployment потрібні поля .apiVersion, .kind і .metadata. Для загальної інформації щодо роботи з файлами конфігурацій дивіться документи розгортання застосунків, налаштування контейнерів та використання kubectl для управління ресурсами.

Коли панель управління створює нові Podʼи для Deployment, .metadata.name Deployment є частиною основи для найменування цих Podʼів. Назва Deployment повинна бути дійсним значенням DNS-піддомену, але це може призводити до неочікуваних результатів для імен хостів Podʼів. Для найкращої сумісності імʼя повинно відповідати більш обмеженим правилам DNS-мітки.

Deployment також потребує розділу .spec.

Шаблон Pod

.spec.template та .spec.selector — єдині обовʼязкові поля .spec.

.spec.template — це шаблон Pod. Він має точно таку ж схему, як і Pod, за винятком того, що він вкладений і не має apiVersion або kind.

Крім обовʼязкових полів для Pod, шаблон Pod в Deployment повинен вказати відповідні мітки та відповідну політику перезапуску. Щодо міток, переконайтеся, що вони не перекриваються з іншими контролерами. Дивіться селектор.

Дозволяється лише .spec.template.spec.restartPolicy, рівне Always, що є стандартним значенням, якщо не вказано інше.

Репліки

.spec.replicas — це необовʼязкове поле, яке вказує кількість бажаних Podʼів. Стандартно встановлено значення 1.

Якщо ви вручну масштабуєте Deployment, наприклад, через kubectl scale deployment deployment --replicas=X, а потім ви оновлюєте цей Deployment на основі маніфесту (наприклад: виконуючи kubectl apply -f deployment.yaml), то застосування цього маніфесту перезаписує ручне масштабування, яке ви раніше вказали.

Якщо HorizontalPodAutoscaler (або будь-який аналогічний API для горизонтального масштабування) відповідає за масштабування Deployment, не встановлюйте значення в .spec.replicas.

Замість цього дозвольте панелі управління Kubernetes автоматично керувати полем .spec.replicas.

Селектор

.spec.selector — обовʼязкове поле, яке вказує селектор міток для Podʼів, які створює цей Deployment.

.spec.selector повинно відповідати .spec.template.metadata.labels, або воно буде відхилено API.

В API-версії apps/v1 .spec.selector та .metadata.labels не встановлюють стандартні значення на основі .spec.template.metadata.labels, якщо вони не встановлені. Таким чином, їх слід встановлювати явно. Також слід зазначити, що .spec.selector неможливо змінити після створення Deployment в apps/v1.

Deployment може примусово завершити Podʼи, мітки яких відповідають селектору, якщо їх шаблон відмінний від .spec.template або якщо загальна кількість таких Podʼів перевищує .spec.replicas. Запускає нові Podʼи з .spec.template, якщо кількість Podʼів менше, ніж бажана кількість.

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

Стратегія

.spec.strategy визначає стратегію, якою замінюються старі Podʼи новими. .spec.strategy.type може бути "Recreate" або "RollingUpdate". Типовим значенням є "RollingUpdate".

Перестворення Deployment

Всі поточні Podʼи примусово зупиняються та вилучаються, перш ніж створюються нові, коли .spec.strategy.type==Recreate.

Оновлення Deployment

Deployment оновлює Podʼи в режимі поетапного оновлення, коли .spec.strategy.type==RollingUpdate. Ви можете вказати maxUnavailable та maxSurge, щоб контролювати процес поетапного оновлення.

Максимально недоступний

.spec.strategy.rollingUpdate.maxUnavailable — це необовʼязкове поле, яке вказує максимальну кількість Podʼів, які можуть бути недоступні під час процесу оновлення. Значення може бути абсолютним числом (наприклад, 5) або відсотком від бажаної кількості Podʼів (наприклад, 10%). Абсолютне число обчислюється з відсотком, округленим вниз. Значення не може бути 0, якщо MaxSurge дорівнює 0. Станадартне значення — 25%.

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

Максимальний наплив

.spec.strategy.rollingUpdate.maxSurge — це необовʼязкове поле, яке вказує максимальну кількість Podʼів, які можуть бути створені понад бажану кількість Podʼів. Значення може бути абсолютним числом (наприклад, 5) або відсотком від бажаної кількості Podʼів (наприклад, 10%). Абсолютне число обчислюється з відсотком, округленим вгору. Значення не може бути 0, якщо MaxUnavailable дорівнює 0. Станадартне значення - 25%.

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

Ось кілька прикладів оновлення Deployment за допомогою maxUnavailable та maxSurge:

apiVersion: apps/v1
kind: Deployment
metadata:
 name: nginx-deployment
 labels:
   app: nginx
spec:
 replicas: 3
 selector:
   matchLabels:
     app: nginx
 template:
   metadata:
     labels:
       app: nginx
   spec:
     containers:
     - name: nginx
       image: nginx:1.14.2
       ports:
       - containerPort: 80
 strategy:
   type: RollingUpdate
   rollingUpdate:
     maxUnavailable: 1

apiVersion: apps/v1
kind: Deployment
metadata:
 name: nginx-deployment
 labels:
   app: nginx
spec:
 replicas: 3
 selector:
   matchLabels:
     app: nginx
 template:
   metadata:
     labels:
       app: nginx
   spec:
     containers:
     - name: nginx
       image: nginx:1.14.2
       ports:
       - containerPort: 80
 strategy:
   type: RollingUpdate
   rollingUpdate:
     maxSurge: 1

apiVersion: apps/v1
kind: Deployment
metadata:
 name: nginx-deployment
 labels:
   app: nginx
spec:
 replicas: 3
 selector:
   matchLabels:
     app: nginx
 template:
   metadata:
     labels:
       app: nginx
   spec:
     containers:
     - name: nginx
       image: nginx:1.14.2
       ports:
       - containerPort: 80
 strategy:
   type: RollingUpdate
   rollingUpdate:
     maxSurge: 1
     maxUnavailable: 1

Час Progress Deadline

.spec.progressDeadlineSeconds — це необовʼязкове поле, яке вказує кількість секунд, протягом яких ви хочете чекати, поки ваш Deployment продовжиться, перш ніж система повідомить, що Deployment має помилку — відображається як умова з type: Progressing, status: "False" та reason: ProgressDeadlineExceeded в статусі ресурсу. Контролер Deployment буде продовжувати повторювати спроби Deployment. Станадартно це значення становить 600. У майбутньому, коли буде реалізовано автоматичний відкат, контролер Deployment відкотить Deployment, як тільки він виявить таку умову.

Якщо вказано це поле, воно повинно бути більше, ніж значення .spec.minReadySeconds.

Час Min Ready

.spec.minReadySeconds — це необовʼязкове поле, яке вказує мінімальну кількість секунд, протягом яких новий створений Pod повинен бути готовим, і жоден з його контейнерів не повинен виходити з ладу, щоб його вважалим доступним. Стандартно це значення становить 0 (Pod буде вважатися доступним, як тільки він буде готовий). Щоб дізнатися більше про те, коли Pod вважається готовим, див. Проби контейнерів.

Ліміт історії ревізій

Історія ревізій Deployment зберігається в ReplicaSets, якими він керує.

.spec.revisionHistoryLimit — це необовʼязкове поле, яке вказує кількість старих ReplicaSets, які слід зберігати для можливості відкату. Ці старі ReplicaSets витрачають ресурси в etcd та заважають виводу kubectl get rs. Конфігурація кожного ревізії Deployment зберігається в його ReplicaSets; отже, після видалення старого ReplicaSet ви втрачаєте можливість відкотитися до цієї ревізії Deployment. Стандартно буде збережено 10 старих ReplicaSets, але ідеальне значення залежить від частоти та стабільності нових Deployment.

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

Пауза

.spec.paused — це необовʼязкове булеве поле для призупинення та відновлення Deployment. Єдиний відмінок між призупиненим Deployment і тим, який не призупинений, полягає в тому, що будь-які зміни в PodTemplateSpec призупиненого Deployment не викличуть нових розгортань, поки він призупинений. Deployment типово не призупинений при створенні.

Що далі

3.4.2.2 - ReplicaSet

Призначення ReplicaSet полягає в забезпеченні стабільного набору реплік Podʼів, які працюють у будь-який момент часу. Зазвичай ви визначаєте Deployment та дозволяєте цьому Deployment автоматично керувати ReplicaSets.

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

Як працює ReplicaSet

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

ReplicaSet повʼязаний зі своїми Podʼами через поле metadata.ownerReferences Podʼа, яке вказує, яким ресурсом є власник поточного обʼєкта. Усі Podʼи, які отримав ReplicaSet, мають інформацію про ідентифікацію їхнього власного ReplicaSet у полі ownerReferences. Завдяки цим посиланням ReplicaSet знає про стан Podʼів, які він підтримує, і планує дії відповідно.

ReplicaSet визначає нові Podʼи для отримання за допомогою свого селектора. Якщо існує Pod, який не має OwnerReference або OwnerReference не є контролером, і він відповідає селектору ReplicaSet, його негайно отримає вказаний ReplicaSet.

Коли використовувати ReplicaSet

ReplicaSet забезпечує наявність вказаної кількості реплік Podʼів у будь-який момент часу. Проте Deployment є концепцією вищого рівня, яка управляє ReplicaSets і надає декларативні оновлення для Podʼів, разом із багатьма іншими корисними можливостями. Тому ми рекомендуємо використовувати Deployments замість безпосереднього використання ReplicaSets, якщо вам необхідне настроювання оркестрування оновлень або взагалі не потрібні оновлення.

Це означає, що вам можливо навіть не доведеться працювати з обʼєктами ReplicaSet: використовуйте Deployment та визначайте ваш застосунок у розділі spec.

Приклад

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: frontend
  labels:
    app: guestbook
    tier: frontend
spec:
  # змініть кількість реплік відповідно до ваших потреб
  replicas: 3
  selector:
    matchLabels:
      tier: frontend
  template:
    metadata:
      labels:
        tier: frontend
    spec:
      containers:
      - name: php-redis
        image: us-docker.pkg.dev/google-samples/containers/gke/gb-frontend:v5

Зберігаючи цей маніфест у файл frontend.yaml та застосовуючи його до кластера Kubernetes ви створите визначений обʼєкт ReplicaSet та Podʼи, якими він керує.

kubectl apply -f https://kubernetes.io/examples/controllers/frontend.yaml

Ви можете переглянути створений ReplicaSet за допомогою команди:

kubectl get rs

І побачите що створено frontend:

NAME       DESIRED   CURRENT   READY   AGE
frontend   3         3         3       6s

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

kubectl describe rs/frontend

Ви побачите вивід подібний до цього:

Name:         frontend
Namespace:    default
Selector:     tier=frontend
Labels:       app=guestbook
              tier=frontend
Annotations:  <none>
Replicas:     3 current / 3 desired
Pods Status:  3 Running / 0 Waiting / 0 Succeeded / 0 Failed
Pod Template:
  Labels:  tier=frontend
  Containers:
   php-redis:
    Image:        us-docker.pkg.dev/google-samples/containers/gke/gb-frontend:v5
    Port:         <none>
    Host Port:    <none>
    Environment:  <none>
    Mounts:       <none>
  Volumes:        <none>
Events:
  Type    Reason            Age   From                   Message
  ----    ------            ----  ----                   -------
  Normal  SuccessfulCreate  13s   replicaset-controller  Created pod: frontend-gbgfx
  Normal  SuccessfulCreate  13s   replicaset-controller  Created pod: frontend-rwz57
  Normal  SuccessfulCreate  13s   replicaset-controller  Created pod: frontend-wkl7w

І нарешті, ви можете перевірити, що Podʼи створені:

kubectl get pods

І побачите щось подібне до цього:

NAME             READY   STATUS    RESTARTS   AGE
frontend-gbgfx   1/1     Running   0          10m
frontend-rwz57   1/1     Running   0          10m
frontend-wkl7w   1/1     Running   0          10m

Ви можете також перевірити, що посилання на власника цих Podʼів вказує на ReplicaSet. Для цього отримайте деталі одного з Pod в форматі YAML:

kubectl get pods frontend-gbgfx -o yaml

Вихід буде схожий на цей, з інформацією ReplicaSet, встановленою в полі ownerReferences метаданих:

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: "2024-02-28T22:30:44Z"
  generateName: frontend-
  labels:
    tier: frontend
  name: frontend-gbgfx
  namespace: default
  ownerReferences:
  - apiVersion: apps/v1
    blockOwnerDeletion: true
    controller: true
    kind: ReplicaSet
    name: frontend
    uid: e129deca-f864-481b-bb16-b27abfd92292
...

Володіння Podʼами без шаблону

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

Візьмемо приклад попереднього ReplicaSet для фронтенду та Podʼів, визначених у наступному маніфесті:

apiVersion: v1
kind: Pod
metadata:
  name: pod1
  labels:
    tier: frontend
spec:
  containers:
  - name: hello1
    image: gcr.io/google-samples/hello-app:2.0

---

apiVersion: v1
kind: Pod
metadata:
  name: pod2
  labels:
    tier: frontend
spec:
  containers:
  - name: hello2
    image: gcr.io/google-samples/hello-app:1.0

Оскільки ці Podʼи не мають контролера (або будь-якого обʼєкта) як власника та відповідають селектору ReplicaSet для фронтенду, вони одразу перейдуть у його володіння.

Припустимо, ви створюєте Podʼи після того, як ReplicaSet для фронтенду буде розгорнуто та встановлено свої початкові репліки Podʼів для виконання вимог до кількості реплік:

kubectl apply -f https://kubernetes.io/examples/pods/pod-rs.yaml

Нові Podʼи будуть отримані ReplicaSet та негайно завершені, оскільки ReplicaSet буде мати більше, ніж його бажана кількість.

Отримання Podʼів:

kubectl get pods

Вивід покаже, що нові Podʼи або вже завершено, або в процесі завершення:

NAME             READY   STATUS        RESTARTS   AGE
frontend-b2zdv   1/1     Running       0          10m
frontend-vcmts   1/1     Running       0          10m
frontend-wtsmm   1/1     Running       0          10m
pod1             0/1     Terminating   0          1s
pod2             0/1     Terminating   0          1s

Якщо ви створите Podʼи спочатку:

kubectl apply -f https://kubernetes.io/examples/pods/pod-rs.yaml

А потім створите ReplicaSet таким чином:

kubectl apply -f https://kubernetes.io/examples/controllers/frontend.yaml

Ви побачите, що ReplicaSet отримав Podʼи та створив нові лише відповідно до свого опису, доки кількість його нових Podʼів та оригінальних не відповідала його бажаній кількості. Якщо отримати Podʼи:

kubectl get pods

Вивід покаже, що:

NAME             READY   STATUS    RESTARTS   AGE
frontend-hmmj2   1/1     Running   0          9s
pod1             1/1     Running   0          36s
pod2             1/1     Running   0          36s

Таким чином, ReplicaSet може володіти неоднорідним набором Podʼів.

Написання маніфесту ReplicaSet

Як і усі інші обʼєкти API Kubernetes, ReplicaSet потребує полів apiVersion, kind та metadata. Для ReplicaSet kind завжди є ReplicaSet.

Коли панель управління створює нові Podʼи для ReplicaSet, .metadata.name ReplicaSet є частиною основи для найменування цих Podʼів. Назва ReplicaSet повинна бути дійсним значенням DNS-піддомену, але це може призвести до неочікуваних результатів для імен хостів Podʼа. Для найкращої сумісності назва має відповідати більш обмеженим правилам для DNS-мітки.

ReplicaSet також потребує розділу .spec.

Шаблон Podʼа

.spec.template — це шаблон Podʼа, який також повинен мати встановлені мітки. У нашому прикладі frontend.yaml ми мали одну мітку: tier: frontend. Будьте обережні, щоб селектори не перекривалися з селекторами інших контролерів, інакше вони можуть намагатися взяти контроль над Podʼом.

Для політики перезапуску шаблону restart policy, .spec.template.spec.restartPolicy, є допустимим тільки значення Always, яке є стандартним значенням.

Селектор Podʼа

Поле .spec.selector є селектором міток. Як обговорювалося раніше, це мітки, які використовуються для ідентифікації потенційних Podʼів для володіння. У нашому прикладі frontend.yaml селектор був:

matchLabels:
  tier: frontend

У ReplicaSet .spec.template.metadata.labels має відповідати spec.selector, інакше він буде відхилений API.

Репліки

Ви можете вказати, скільки Podʼів мають виконуватись одночасно, встановивши значення .spec.replicas. ReplicaSet буде створювати/видаляти свої Podʼи щоб кількість Podʼів відповідала цьому числу. Якщо ви не вказали .spec.Podʼа, то типово значення дорівнює 1.

Робота з ReplicaSets

Видалення ReplicaSet та його Podʼів

Щоб видалити ReplicaSet і всі його Podʼи, використовуйте kubectl delete. Збирач сміття Garbage collector автоматично видаляє всі залежні Podʼи.

При використанні REST API або бібліотеки client-go, вам потрібно встановити propagationPolicy в Background або Foreground в опції -d. Наприклад:

kubectl proxy --port=8080
curl -X DELETE  'localhost:8080/apis/apps/v1/namespaces/default/replicasets/frontend' \
  -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}' \
  -H "Content-Type: application/json"

Видалення лише ReplicaSet

Ви можете видалити ReplicaSet, не впливаючи на його Podʼи за допомогою kubectl delete з опцією --cascade=orphan. При використанні REST API або бібліотеки client-go, вам потрібно встановити propagationPolicy в Orphan. Наприклад:

kubectl proxy --port=8080
curl -X DELETE  'localhost:8080/apis/apps/v1/namespaces/default/replicasets/frontend' \
  -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Orphan"}' \
  -H "Content-Type: application/json"

Після видалення оригіналу ви можете створити новий ReplicaSet для заміни. До тих пір поки старий та новий .spec.selector однакові, новий прийме старі Podʼи. Однак він не буде намагатися повʼязувати наявні Podʼи з новим, відмінним шаблоном Podʼа. Для оновлення Podʼів до нової специфікації у контрольований спосіб використовуйте Deployment, оскільки ReplicaSets безпосередньо не підтримують rolling update.

Ізолювання Podʼів від ReplicaSet

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

Масштабування ReplicaSet

ReplicaSet можна легко масштабувати вгору або вниз, просто оновивши поле .spec.replicas. Контролер ReplicaSet забезпечує, що бажана кількість Podʼів з відповідним селектором міток доступна та працює.

При зменшенні масштабу ReplicaSet контролер ReplicaSet вибирає Podʼи для видалення, сортуючи доступні Podʼи, щоб визначити, які Podʼи видаляти в першу чергу, використовуючи наступний загальний алгоритм:

  1. Перш за все прибираються Podʼи, що перебувають в очікуванні.
  2. Якщо встановлено анотацію controller.kubernetes.io/pod-deletion-cost, то Pod із меншою вартістю буде видалено першим.
  3. Podʼи на вузлах з більшою кількістю реплік йдуть перед Podʼами на вузлах з меншою кількістю реплік.
  4. Якщо часи створення Podʼів відрізняються, то Pod, створений недавно, йде перед старішим Podʼом (часи створення розділені на цілочисельний логарифмічний масштаб)

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

Вартість видалення Podʼа

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

За допомогою анотації controller.kubernetes.io/pod-deletion-cost користувачі можуть встановити вподобання щодо порядку видалення Podʼів під час зменшення масштабу ReplicaSet.

Анотація повинна бути встановлена на Podʼі, діапазон — [-2147483648, 2147483647]. Вона представляє вартість видалення Podʼа порівняно з іншими Podʼами, які належать тому ж ReplicaSet. Podʼи з меншою вартістю видалення видаляються першими на відміну Podʼами з більшою вартістю видалення.

Неявне значення для цієї анотації для Podʼів, які його не мають, — 0; допустимі відʼємні значення. Неприпустимі значення будуть відхилені API-сервером.

Ця функція є бета-версією та увімкнена типово. Ви можете вимкнути її, використовуючи функціональну можливість PodDeletionCost як в kube-apiserver, так і в kube-controller-manager.

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

Різні Podʼи застосунку можуть мати різний рівень використання. При зменшенні масштабу застосунок може віддавати перевагу видаленню Podʼів з меншим використанням. Щоб уникнути частого оновлення Podʼів, застосунок повинен оновити controller.kubernetes.io/pod-deletion-cost один раз перед зменшенням масштабу (встановлення анотації в значення, пропорційне рівню використання Podʼа). Це працює, якщо сам застосунок контролює масштабування вниз; наприклад, драйвер розгортання Spark.

ReplicaSet як ціль горизонтального автомасштабування Podʼа

ReplicaSet також може бути ціллю для Горизонтального Автомасштабування Podʼа (HPA). Іншими словами, ReplicaSet може автоматично масштабуватися за допомогою HPA. Ось приклад HPA, який застосовується до ReplicaSet, створеному у попередньому прикладі.

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: frontend-scaler
spec:
  scaleTargetRef:
    kind: ReplicaSet
    name: frontend
  minReplicas: 3
  maxReplicas: 10
  targetCPUUtilizationPercentage: 50

Збереження цього маніфесту в hpa-rs.yaml та його застосування до кластера Kubernetes повинно створити визначене HPA, яке автоматично змінює масштаб цільового ReplicaSet залежно від використання ЦП реплікованими Podʼами.

kubectl apply -f https://k8s.io/examples/controllers/hpa-rs.yaml

Або ви можете використовувати команду kubectl autoscale для досягнення того ж самого (і це простіше!)

kubectl autoscale rs frontend --max=10 --min=3 --cpu-percent=50

Альтернативи ReplicaSet

Deployment — це обʼєкт, який може володіти ReplicaSets і оновлювати їх та їхні Podʼи через декларативні оновлення на стороні сервера. Хоча ReplicaSets можуть використовуватися незалежно, на сьогодні вони головним чином використовуються Deployments як механізм для оркестрування створення, видалення та оновлення Podʼів. Коли ви використовуєте Deployments, вам не потрібно турбуватися про керування ReplicaSets, які вони створюють. Deployments володіють і керують своїми ReplicaSets. Таким чином, рекомендується використовувати Deployments, коли вам потрібні ReplicaSets.

Чисті Podʼи

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

Job

Використовуйте Job замість ReplicaSet для Podʼів, які повинні завершитися самостійно (тобто пакетні завдання).

DaemonSet

Використовуйте DaemonSet замість ReplicaSet для Podʼів, які надають функції на рівні машини, такі як моніторинг стану машини або реєстрація машини. Ці Podʼи мають термін служби, який повʼязаний з терміном служби машини: Pod повинен працювати на машині перед тим, як інші Podʼи почнуть роботу, і можуть бути безпечно завершені, коли машина готова до перезавантаження/вимкнення.

ReplicationController

ReplicaSets — є наступниками ReplicationControllers. Обидва служать тому ж самому призначенню та поводяться схоже, за винятком того, що ReplicationController не підтримує вимоги вибору на основі множини, як описано в посібнику про мітки. Таким чином, ReplicaSets має перевагу над ReplicationControllers.

Що далі

  • Дізнайтеся про Podʼи.
  • Дізнайтеся про Deploуments.
  • Запустіть Stateless Application за допомогою Deployment, що ґрунтується на роботі ReplicaSets.
  • ReplicaSet — це ресурс верхнього рівня у Kubernetes REST API. Прочитайте визначення обʼєкта ReplicaSet, щоб розуміти API для реплік.
  • Дізнайтеся про PodDisruptionBudget та як ви можете використовувати його для управління доступністю застосунку під час перебоїв.

3.4.2.3 - StatefulSets

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

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

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

Схожий на Deployment, StatefulSet керує Podʼами, які базуються на ідентичній специфікації контейнерів. На відміну від Deployment, StatefulSet зберігає постійну ідентичність для кожного свого Podʼа. Ці Podʼи створюються за однаковою специфікацією, але не є взаємозамінними: у кожного є постійний ідентифікатор, який він утримує при переплануванні.

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

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

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

  • Стабільних, унікальних мережевих ідентифікаторів.
  • Стабільного, постійного сховища.
  • Упорядкованого, відповідного розгортання та масштабування.
  • Упорядкованих, автоматизованих поступових (rolling) оновлень.

У випадку відсутності потреби в стабільних ідентифікаторах або упорядкованому розгортанні, видаленні чи масштабуванні, вам слід розгортати свою програму за допомогою робочого обʼєкта, який забезпечує набір реплік без збереження стану (stateless). Deployment або ReplicaSet можуть бути більш придатними для ваших потреб.

Обмеження

  • Місце для зберігання для певного Podʼа повинно буде виділене чи вже виділено PersistentVolume Provisioner на основі запиту storage class, або виділено адміністратором наперед.
  • Видалення та/або масштабування StatefulSet вниз не призведе до видалення томів, повʼязаних з StatefulSet. Це зроблено для забезпечення безпеки даних, яка загалом є важливішою, ніж автоматичне очищення всіх повʼязаних ресурсів StatefulSet.
  • Наразі для StatefulSets обовʼязково потрібний Headless Service щоб відповідати за мережевий ідентифікатор Podʼів. Вам слід створити цей Сервіс самостійно.
  • StatefulSets не надають жодних гарантій щодо припинення роботи Podʼів при видаленні StatefulSet. Для досягнення упорядкованого та відповідного завершення роботи Podʼів у StatefulSet можливо зменшити масштаб StatefulSet до 0 перед видаленням.
  • При використанні Поступових Оновлень використовуючи стандартну Політику Керування Podʼів (OrderedReady), можливе потрапляння в стан, що вимагає ручного втручання для виправлення.

Компоненти

Наведений нижче приклад демонструє компоненти StatefulSet.

apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  selector:
    matchLabels:
      app: nginx # повинно відповідати .spec.template.metadata.labels
  serviceName: "nginx"
  replicas: 3 # типово 1
  minReadySeconds: 10 # типово 0
  template:
    metadata:
      labels:
        app: nginx # повинно відповідати .spec.selector.matchLabels
    spec:
      terminationGracePeriodSeconds: 10
      containers:
      - name: nginx
        image: registry.k8s.io/nginx-slim:0.24
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: "my-storage-class"
      resources:
        requests:
          storage: 1Gi

У вищенаведеному прикладі:

  • Використовується Headless Service, з назвою nginx, для управління мережевим доменом.
  • StatefulSet, названий web, має Spec, який вказує на те, що буде запущено 3 репліки контейнера nginx в унікальних Podʼах.
  • volumeClaimTemplates буде забезпечувати стійке зберігання за допомогою PersistentVolumes, виділених PersistentVolume Provisioner.

Назва обʼєкта StatefulSet повинна бути дійсною DNS міткою.

Селектор Podʼів

Вам слід встановити поле .spec.selector StatefulSet, яке збігається з міткам його .spec.template.metadata.labels. Нездатність вказати відповідний селектор Pod призведе до помилки перевірки під час створення StatefulSet.

Шаблони заявок на місце для зберігання

Ви можете встановити поле .spec.volumeClaimTemplates, щоб створити PersistentVolumeClaim. Це забезпечить стійке зберігання для StatefulSet, якщо:

  • Для заявки на том встановлено StorageClass, який налаштований на використання динамічного виділення, або
  • Кластер вже містить PersistentVolume з правильним StorageClass та достатньою кількістю доступного місця для зберігання.

Мінімальний час готовності

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

.spec.minReadySeconds є необовʼязковим полем, яке вказує мінімальну кількість секунд, протягом яких новий створений Pod повинен працювати та бути готовим, без виходу будь-яких його контейнерів з ладу, щоб вважатися доступним. Це використовується для перевірки прогресу розгортання при використанні стратегії Поступового Оновлення. Це поле станлартно дорівнює 0 (Pod вважатиметься доступним одразу після готовності). Дізнайтеся більше про те, коли Pod вважається готовим, див. Проби Контейнера.

Ідентичність Podʼа

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

Порядковий індекс

Для StatefulSet з N реплік кожному Podʼу в StatefulSet буде призначено ціле число, яке є унікальним у наборі. Стандартно Podʼам буде призначено порядкові номери від 0 до N-1. Контролер StatefulSet також додасть мітку Podʼа з цим індексом: apps.kubernetes.io/pod-index.

Початковий порядковий номер

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

.spec.ordinals — це необовʼязкове поле, яке дозволяє налаштувати цілочисельні порядкові номери, призначені кожному Pod. Стандартно воно встановлено в nil. В межах цього поля ви можете налаштувати наступні параметри:

  • .spec.ordinals.start: Якщо встановлено поле .spec.ordinals.start, Podʼам будуть призначені порядкові номери від .spec.ordinals.start до .spec.ordinals.start + .spec.replicas - 1.

Стабільний мережевий ідентифікатор

Кожен Pod в StatefulSet виводить назву свого хосту з імені StatefulSet та порядкового номера Podʼа. Шаблон для створеного імені хосту має вигляд $(імʼя statefulset)-$(порядковий номер). У вищезазначеному прикладі буде створено три Podʼа з іменами web-0,web-1,web-2. StatefulSet може використовувати Headless Service для управління доменом своїх Podʼів. Домен, яким управляє цей сервіс, має вигляд: $(імʼя сервісу).$(простір імен).svc.cluster.local, де "cluster.local" — це кластерний домен. При створенні кожного Podʼа він отримує відповідний DNS-піддомен, який має вигляд: $(імʼя Podʼа).$(головний домен сервісу), де головний сервіс визначається полем serviceName в StatefulSet.

Залежно від того, як налаштований DNS у вашому кластері, ви можливо не зможете одразу знаходити DNS-імʼя для нового Podʼа. Це можливо, коли інші клієнти в кластері вже відправили запити на імʼя хосту Podʼа до його створення. Негативне кешування (зазвичай для DNS) означає, що результати попередніх невдалих пошуків запамʼятовуються та використовуються, навіть після того, як Pod вже працює, принаймні кілька секунд.

Якщо вам потрібно виявити Podʼи негайно після їх створення, у вас є кілька варіантів:

  • Запитуйте API Kubernetes безпосередньо (наприклад, використовуючи режим спостереження), а не покладаючись на DNS-запити.
  • Зменште час кешування в вашому постачальнику DNS Kubernetes (зазвичай це означає редагування ConfigMap для CoreDNS, який зараз кешує протягом 30 секунд).

Як зазначено в розділі Обмеження, ви відповідаєте за створення Headless Service, відповідального за мережевий ідентифікатор Podʼів.

Ось деякі приклади варіантів вибору кластерного домену, імені сервісу, імені StatefulSet та того, як це впливає на DNS-імена Podʼів StatefulSet.

Кластерний доменСервіс (ns/імʼя)StatefulSet (ns/імʼя)Домен StatefulSetDNS PodʼаІмʼя хоста Podʼа
cluster.localdefault/nginxdefault/webnginx.default.svc.cluster.localweb-{0..N-1}.nginx.default.svc.cluster.localweb-{0..N-1}
cluster.localfoo/nginxfoo/webnginx.foo.svc.cluster.localweb-{0..N-1}.nginx.foo.svc.cluster.localweb-{0..N-1}
kube.localfoo/nginxfoo/webnginx.foo.svc.kube.localweb-{0..N-1}.nginx.foo.svc.kube.localweb-{0..N-1}

Стійке сховище

Для кожного вхідного запису volumeClaimTemplates, визначеного в StatefulSet, кожен Pod отримує один PersistentVolumeClaim. У прикладі з nginx кожен Pod отримує один PersistentVolume з StorageClass my-storage-class та 1 ГБ зарезервованого сховища. Якщо не вказано StorageClass, то використовуватиметься стандартний розмір сховища. Коли Pod переплановується на вузлі, його volumeMounts монтує PersistentVolumes, повʼязані із його PersistentVolume Claims. Зазначте, що PersistentVolumes, повʼязані із PersistentVolume Claims Podʼів, не видаляються при видаленні Podʼів чи StatefulSet. Це слід робити вручну.

Мітка імені Podʼа

Коли StatefulSet контролер створює Pod, він додає мітку statefulset.kubernetes.io/pod-name, яка дорівнює назві Podʼа. Ця мітка дозволяє прикріплювати Service до конкретного Podʼа в StatefulSet.

Мітка індексу Podʼа

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

Коли StatefulSet контролер створює Pod, новий Pod має мітку apps.kubernetes.io/pod-index. Значення цієї мітки — це порядковий індекс Podʼа. Ця мітка дозволяє маршрутизувати трафік до певного індексу Podʼа, фільтрувати логи/метрики за допомогою мітки індексу Podʼа та інше. Зауважте, що feature gate PodIndexLabel повинен бути увімкнений для цієї функції, і стандартно він увімкнений.

Гарантії розгортання та масштабування

  • Для StatefulSet із N реплік, при розгортанні Podʼи створюються послідовно, у порядку від {0..N-1}.
  • При видаленні Podʼів вони закінчуються у зворотньому порядку, від {N-1..0}.
  • Перед тим як застосувати масштабування до Podʼа, всі його попередники повинні бути запущені та готові.
  • Перед тим як Pod буде припинено, всі його наступники повинні бути повністю зупинені.

StatefulSet не повинен вказувати pod.Spec.TerminationGracePeriodSeconds рівним 0. Це практика небезпечна і настійно не рекомендується. Для отримання додаткової інформації, зверніться до примусового видалення Podʼів StatefulSet.

Коли створюється приклад nginx вище, три Podʼа будуть розгорнуті в порядку web-0, web-1, web-2. web-1 не буде розгорнуто, поки web-0 не буде запущений і готовий, і web-2 не буде розгорнуто, поки web-1 не буде запущений і готовий. Якщо web-0 виявиться несправним, після того, як web-1 стане запущеним і готовим, але до запуску web-2, web-2 не буде запущено, поки web-0 успішно перезапуститься і стане запущеним і готовим.

Якщо користувач масштабує розгорнутий приклад, застосовуючи патчи до StatefulSet так, так щоб replicas=1, спочатку буде припинено web-2. web-1 не буде припинено, поки web-2 повністю не завершить свою роботу та буде видалено. Якщо web-0 виявиться невдалим після того, як web-2 вже був припинений і повністю завершено, але перед видаленням web-1, web-1 не буде припинено, поки web-0 не стане запущеним і готовим.

Політики управління Podʼами

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

Політика управління Podʼами "OrderedReady"

OrderedReady є типовим значенням політики управління Podʼами для StatefulSet. Вона реалізує поведінку, описану вище.

Політика управління Podʼами "Parallel"

"Parallel" вказує контролеру StatefulSet запускати або припиняти всі Podʼи паралельно, і не чекати, поки Podʼи стануть запущеними та готовими або повністю припиняться перед запуском або видаленням іншого Podʼа. Ця опція впливає лише на поведінку операцій масштабування. Оновлення не підпадають під вплив.

Стратегії оновлення

Поле .spec.updateStrategy обʼєкта StatefulSet дозволяє налаштовувати та вимикати автоматизовані поетапні оновлення для контейнерів, міток, ресурсів (запити/обмеження) та анотацій для Podʼів у StatefulSet. Є два можливих значення:

OnDelete
Коли поле .spec.updateStrategy.type StatefulSet встановлено в OnDelete, контролер StatefulSet не буде автоматично оновлювати Podʼи в StatefulSet. Користувачам необхідно вручну видаляти Podʼи, щоб спричинити створення контролером нових Podʼів, які відображають зміни, внесені в .spec.template StatefulSet.
RollingUpdate
Стратегія оновлення RollingUpdate реалізує автоматизовані, поточні оновлення для Podʼів у StatefulSet. Це значення є стандартною стратегією оновлення.

Поточні оновлення

Коли поле .spec.updateStrategy.type StatefulSet встановлено на RollingUpdate, контролер StatefulSet буде видаляти та знову створювати кожен Pod у StatefulSet. Він буде продовжувати в тому ж порядку, як Podʼи завершують роботу (від найбільшого індексу до найменшого), оновлюючи кожен Pod по одному.

Панель управління Kubernetes чекає, доки оновлений Pod буде переведений в стан Running та Ready, перш ніж оновити його попередника. Якщо ви встановили .spec.minReadySeconds (див. Мінімальна кількість секунд готовності), панель управління також чекає вказану кількість секунд після того, як Pod стане готовим, перш ніж перейти далі.

Поточні оновлення частинами

Стратегію оновлення RollingUpdate можна поділити на розділи, вказавши .spec.updateStrategy.rollingUpdate.partition. Якщо вказано розділ, всі Podʼи з індексом, який більший або рівний розділу, будуть оновлені при оновленні .spec.template StatefulSet. Усі Podʼи з індексом, який менший за розділ, не будуть оновлені та, навіть якщо вони будуть видалені, вони будуть відновлені на попередню версію. Якщо .spec.updateStrategy.rollingUpdate.partition StatefulSet більше, ніж .spec.replicas, оновлення .spec.template не буде розповсюджуватися на його Podʼи. У більшості випадків вам не знадобиться використовувати розподіл, але вони корисні, якщо ви хочете розгортати оновлення, робити канаркові оновлення або виконати поетапне оновлення.

Максимальна кількість недоступних Podʼів

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

Ви можете контролювати максимальну кількість Podʼів, які можуть бути недоступні під час оновлення, вказавши поле .spec.updateStrategy.rollingUpdate.maxUnavailable. Значення може бути абсолютним числом (наприклад, 5) або відсотком від бажаних Podʼів (наприклад, 10%). Абсолютне число обчислюється з відсоткового значення заокругленням вгору. Це поле не може бути 0. Стандартне значення — 1.

Це поле застосовується до всіх Podʼів у діапазоні від 0 до replicas - 1. Якщо є будь-який недоступний Pod у діапазоні від 0 до replicas - 1, він буде враховуватися в maxUnavailable.

Примусовий відкат

При використанні поступових оновлень зі стандартною політикою управління Podʼами (OrderedReady), існує можливість потрапити в становище, яке вимагає ручного втручання для виправлення.

Якщо ви оновлюєте шаблон Podʼа до конфігурації, яка ніколи не стає в стан Running and Ready (наприклад, через поганий бінарний файл або помилку конфігурації на рівні застосунку), StatefulSet припинить розгортання і залишиться у стані очікування.

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

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

Збереження PersistentVolumeClaim

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

Необовʼязкове поле .spec.persistentVolumeClaimRetentionPolicy контролює, чи і як видаляються PVC під час життєвого циклу StatefulSet. Вам потрібно увімкнути функціональну можливість StatefulSetAutoDeletePVC на сервері API та менеджері контролера, щоб використовувати це поле. Після активації ви можете налаштувати дві політики для кожного StatefulSet:

whenDeleted
налаштовує поведінку зберігання тому, яке застосовується при видаленні StatefulSet
whenScaled
налаштовує поведінку зберігання тому, яке застосовується при зменшенні кількості реплік у StatefulSet, наприклад, при масштабуванні вниз.

Для кожної політики, яку ви можете налаштувати, ви можете встановити значення Delete або Retain.

Delete
PVC, створені за допомогою volumeClaimTemplate StatefulSet, видаляються для кожного Podʼа, який впливає на політику. З політикою whenDeleted всі PVC від volumeClaimTemplate видаляються після того, як їх Podʼи були видалені. З політикоюю whenScaled, лише PVC, що відповідають реплікам Podʼа, які зменшуються видаляються після того, як їх Podʼи були видалені.
Retain (стандартно)
PVC від volumeClaimTemplate не змінюються, коли їх Pod видаляється. Це поведінка до цієї нової функції.

Звертайте увагу, що ці політики застосовуються лише при вилученні Podʼів через видалення або масштабування StatefulSet. Наприклад, якщо Pod, повʼязаний із StatefulSet, зазнає відмови через відмову вузла, і панель управління створює замінний Pod, StatefulSet зберігає поточний PVC. Поточний том не піддається впливу, і кластер прикріплює його до вузла, де має запуститися новий Pod.

Станадртно для політик встановлено Retain, відповідно до поведінки StatefulSet до цієї нової функції.

Ось приклад політики.

apiVersion: apps/v1
kind: StatefulSet
...
spec:
  persistentVolumeClaimRetentionPolicy:
    whenDeleted: Retain
    whenScaled: Delete
...

Контролер StatefulSet додає посилання на власника до своїх PVC, які потім видаляються збирачем сміття після завершення Podʼа. Це дозволяє Podʼу чисто демонтувати всі томи перед видаленням PVC (і перед видаленням PV та обсягу, залежно від політики збереження). Коли ви встановлюєте whenDeleted політику Delete, посилання власника на екземпляр StatefulSet поміщається на всі PVC, повʼязані із цим StatefulSet.

Політика whenScaled повинна видаляти PVC тільки при зменшенні розміру Podʼа, а не при видаленні Podʼа з іншої причини. Під час узгодження контролер StatefulSet порівнює очікувану кількість реплік із фактичними Podʼами, що присутні на кластері. Будь-який Pod StatefulSet, ідентифікатор якого більший за кількість реплік, засуджується та позначається для видалення. Якщо політика whenScaled є Delete, засуджені Podʼи спочатку встановлюються власниками для відповідних PVC зразків StatefulSet, перед видаленням Podʼа. Це призводить до того, що PVC видаляються збирачем сміття тільки після видалення таких Podʼів.

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

Репліки

.spec.replicas — це необовʼязкове поле, яке вказує кількість бажаних Podʼів. Стандартно воно дорівнює 1.

Якщо ви масштабуєте Deployment вручну, наприклад, через kubectl scale statefulset statefulset --replicas=X, а потім оновлюєте цей StatefulSet на основі маніфесту (наприклад, за допомогою kubectl apply -f statefulset.yaml), то застосування цього маніфесту перезапише попереднє ручне масштабування.

Якщо HorizontalPodAutoscaler (або будь-який подібний API для горизонтального масштабування) керує масштабуванням StatefulSet, не встановлюйте .spec.replicas. Замість цього дозвольте панелі управління Kubernetes автоматично керувати полем .spec.replicas.

Що далі

3.4.2.4 - DaemonSet

DaemonSet визначає Podʼи, які забезпечують локальноі засоби вузла. Це може бути фундаментально важливим для роботи вашого кластера, таким як інструмент-помічник мережі, або бути частиною застосунку.

DaemonSet переконується, що всі (або деякі) вузли запускають копію Podʼа. При додаванні вузлів до кластера, на них додаються Podʼи. При видаленні вузлів з кластера ці Podʼи видаляються. Видалення DaemonSet призведе до очищення створених ним Podʼів.

Деякі типові використання DaemonSet включають:

  • запуск демона кластерного сховища на кожному вузлі
  • запуск демона збору логів на кожному вузлі
  • запуск демона моніторингу вузла на кожному вузлі

У простому випадку один DaemonSet, який охоплює всі вузли, може використовуватися для кожного типу демона. Складніше налаштування може використовувати кілька DaemonSet для одного типу демона, але з різними прапорцями, або різними запитами памʼяті та CPU для різних типів обладнання.

Створення специфікації DaemonSet

Створення DaemonSet

Ви можете описати DaemonSet у файлі YAML. Наприклад, файл daemonset.yaml нижче описує DaemonSet, який запускає Docker-образ fluentd-elasticsearch:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd-elasticsearch
  namespace: kube-system
  labels:
    k8s-app: fluentd-logging
spec:
  selector:
    matchLabels:
      name: fluentd-elasticsearch
  template:
    metadata:
      labels:
        name: fluentd-elasticsearch
    spec:
      tolerations:
      # ці tolerations дозволяють запускати DaemonSet на вузлах панелі управління
      # видаліть їх, якщо ваші вузли панелі управління не повинні запускати Podʼи
      - key: node-role.kubernetes.io/control-plane
        operator: Exists
        effect: NoSchedule
      - key: node-role.kubernetes.io/master
        operator: Exists
        effect: NoSchedule
      containers:
      - name: fluentd-elasticsearch
        image: quay.io/fluentd_elasticsearch/fluentd:v2.5.2
        resources:
          limits:
            memory: 200Mi
          requests:
            cpu: 100m
            memory: 200Mi
        volumeMounts:
        - name: varlog
          mountPath: /var/log
      # можливо, бажано встановити високий пріоритетний клас, щоб забезпечити, що Podʼи DaemonSetʼу
      # витіснятимуть Podʼи, що виконуються
      # priorityClassName: important
      terminationGracePeriodSeconds: 30
      volumes:
      - name: varlog
        hostPath:
          path: /var/log

Створіть DaemonSet на основі файлу YAML:

kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml

Обовʼязкові поля

Як і з будь-якою іншою конфігурацією Kubernetes, DaemonSet потребує полів apiVersion, kind та metadata. Для загальної інформації щодо роботи з файлами конфігурації, див. запуск stateless застосунків та управління обʼєктами за допомогою kubectl.

Назва обʼєкта DaemonSet повинна бути дійсним імʼям DNS-піддомену.

DaemonSet також потребує .spec розділу.

Шаблон Podʼа

.spec.template — одне з обовʼязкових полів в .spec.

.spec.template — це шаблон Podʼа. Він має ту саму схему, що і Pod, за винятком того, що він вкладений і не має apiVersion або kind.

Окрім обовʼязкових полів для Podʼа, шаблон Podʼа в DaemonSet повинен вказати відповідні мітки (див. вибір Podʼа).

Шаблон Pod в DaemonSet повинен мати RestartPolicy рівну Always або бути не вказаною, що типово рівнозначно Always.

Селектор Podʼа

.spec.selector — обовʼязкове поле в .spec.

Поле .spec.selector — це селектор Podʼа. Воно працює так само як і .spec.selector в Job.

Ви повинні вказати селектор Podʼа, який відповідає міткам .spec.template. Крім того, після створення DaemonSet, його .spec.selector не може бути змінено. Зміна вибору Podʼа може призвести до навмисного залишення Podʼів сиротами, і це буде плутати користувачів.

.spec.selector — це обʼєкт, що складається з двох полів:

  • matchLabels - працює так само як і .spec.selector у ReplicationController.
  • matchExpressions - дозволяє будувати складніші селектори, вказуючи ключ, список значень та оператор, який повʼязує ключ і значення.

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

.spec.selector повинен відповідати .spec.template.metadata.labels. Конфігурація з цими двома несумісними буде відхилена API.

Запуск Podʼів на вибраних вузлах

Якщо ви вказуєте .spec.template.spec.nodeSelector, тоді контролер DaemonSet буде створювати Podʼи на вузлах, які відповідають селектору вузла. Так само, якщо ви вказуєте .spec.template.spec.affinity, тоді контролер DaemonSet буде створювати Podʼи на вузлах, які відповідають цій спорідненості вузла. Якщо ви не вказали жодного з них, контролер DaemonSet буде створювати Podʼи на всіх вузлах.

Як заплановані Daemon Podʼи

DaemonSet може бути використаний для того, щоб забезпечити, щоб всі придатні вузли запускали копію Podʼа. Контролер DaemonSet створює Pod для кожного придатного вузла та додає поле spec.affinity.nodeAffinity Podʼа для відповідності цільовому хосту. Після створення Podʼа, зазвичай вступає в дію типовий планувальник і привʼязує Pod до цільового хосту, встановлюючи поле .spec.nodeName. Якщо новий Pod не може поміститися на вузлі, типовий планувальник може здійснити перерозподіл (виселення) деяких наявних Podʼів на основі пріоритету нового Podʼа.

Користувач може вказати інший планувальник для Podʼів DaemonSet, встановивши поле .spec.template.spec.schedulerName DaemonSet.

Оригінальна спорідненість вузла, вказана в полі .spec.template.spec.affinity.nodeAffinity (якщо вказано), береться до уваги контролером DaemonSet при оцінці придатних вузлів, але замінюється на спорідненість вузла, що відповідає імені придатного вузла, на створеному Podʼі.

nodeAffinity:
  requiredDuringSchedulingIgnoredDuringExecution:
    nodeSelectorTerms:
    - matchFields:
      - key: metadata.name
        operator: In
        values:
        - target-host-name

Taint та toleration

Контролер DaemonSet автоматично додає набір toleration до Podʼів DaemonSet:

Toleration для Podʼів DaemonSet
Ключ толерантностіЕфектДеталі
node.kubernetes.io/not-readyNoExecutePodʼи DaemonSet можуть бути заплановані на вузли, які не є справними або готовими приймати Podʼи. Будь-які Podʼи DaemonSet, які працюють на таких вузлах, не будуть виселені.
node.kubernetes.io/unreachableNoExecutePodʼи DaemonSet можуть бути заплановані на вузли, які недоступні з контролера вузла. Будь-які Podʼи DaemonSet, які працюють на таких вузлах, не будуть виселені.
node.kubernetes.io/disk-pressureNoSchedulePodʼи DaemonSet можуть бути заплановані на вузли із проблемами дискового тиску.
node.kubernetes.io/memory-pressureNoSchedulePodʼи DaemonSet можуть бути заплановані на вузли із проблемами памʼяті.
node.kubernetes.io/pid-pressureNoSchedulePodʼи DaemonSet можуть бути заплановані на вузли з проблемами процесів.
node.kubernetes.io/unschedulableNoSchedulePodʼи DaemonSet можуть бути заплановані на вузли, які не можна планувати.
node.kubernetes.io/network-unavailableNoScheduleДодається лише для Podʼів DaemonSet, які запитують мережу вузла, тобто Podʼи з spec.hostNetwork: true. Такі Podʼи DaemonSet можуть бути заплановані на вузли із недоступною мережею.

Ви можете додавати свої толерантності до Podʼів DaemonSet, визначивши їх в шаблоні Podʼа DaemonSet.

Оскільки контролер DaemonSet автоматично встановлює толерантність node.kubernetes.io/unschedulable:NoSchedule, Kubernetes може запускати Podʼи DaemonSet на вузлах, які відзначені як unschedulable.

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

Взаємодія з Daemon Podʼами

Деякі можливі шаблони для взаємодії з Podʼами у DaemonSet:

  • Push: Podʼи в DaemonSet налаштовані надсилати оновлення до іншого сервісу, такого як база статистики. У них немає клієнтів.
  • NodeIP та відомий порт: Podʼи в DaemonSet можуть використовувати hostPort, щоб їх можна було знайти за IP-адресою вузла. Клієнти певним чином знають стандартний список IP-адрес вузлів і порти.
  • DNS: Створіть headless сервіс за таким же вибором Podʼа, а потім виявіть DaemonSet, використовуючи ресурс endpoints або отримайте кілька записів A з DNS.
  • Сервіс: Створіть сервіс із тим самим вибором Podʼа та використовуйте сервіс для зʼєднання з демоном на випадковому вузлі. (Немає способу зʼєднатися напряму з конкретним Podʼом.)

Оновлення DaemonSet

Якщо мітки вузлів змінюються, DaemonSet негайно додає Podʼи на нові відповідні вузли та видаляє Podʼи на нових не відповідних вузлах.

Ви можете змінювати Podʼи, які створює DaemonSet. Проте Podʼи не дозволяють оновлювати всі поля. Крім того, контролер DaemonSet буде використовувати початковий шаблон при наступному створенні вузла (навіть з тим самим імʼям).

Ви можете видалити DaemonSet. Якщо ви вказали --cascade=orphan з kubectl, тоді Podʼи залишаться на вузлах. Якщо ви потім створите новий DaemonSet з тим самим селектором, новий DaemonSet прийме наявні Podʼи. Якщо потрібно замінити які-небудь Podʼи, DaemonSet їх замінює згідно з його updateStrategy.

Ви можете виконати поетапне оновлення DaemonSet.

Альтернативи DaemonSet

Скрипти ініціалізації

Звичайно, можливо запускати процеси демонів, безпосередньо стартуючи їх на вузлі (наприклад, за допомогою init, upstartd або systemd). Це абсолютно прийнятно. Однак існують кілька переваг запуску таких процесів через DaemonSet:

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

Тільки Podʼи

Можливо створити Podʼи безпосередньо, вказуючи певний вузол для запуску. Проте DaemonSet замінює Podʼи, які видаляються або завершуються з будь-якої причини, такої як збій вузла або руйнівне обслуговування вузла, наприклад, оновлення ядра. З цієї причини слід використовувати DaemonSet замість створення тільки Podʼів.

Статичні Podʼи

Можливо створити Podʼи, записавши файл у певну теку, що спостерігається Kubelet. Їх називають статичними Podʼами. На відміну від DaemonSet, статичними Podʼами не можна управляти за допомогою kubectl або інших клієнтів API Kubernetes. Статичні Podʼи не залежать від apiserver, що робить їх корисними в разі початкового налаштування кластера. Однак, статичні Podʼи можуть бути застарілими у майбутньому.

Deployments

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

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

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

Що далі

3.4.2.5 - Job

Job – є одноразовим завданням, що виконується до моменту його завершення.

Завдання (Job) створює один або кілька Podʼів і буде продовжувати повторювати виконання Podʼів, доки не буде досягнуто вказану кількість успішних завершень. При успішному завершенні Podʼів завдання відстежує ці успішні завершення. Коли досягнута вказана кількість успішних завершень, завдання (тобто Job) завершується. Видалення завдання буде видаляти Podʼи, які воно створило. При призупиненні завдання буде видаляти активні Podʼи, доки завдання знову не буде відновлене.

У простому випадку можна створити один обʼєкт Job для надійного запуску одного Podʼа до завершення. Обʼєкт Job буде запускати новий Pod, якщо перший Pod зазнає невдачі або видаляється (наприклад, через відмову апаратного забезпечення вузла або перезавантаження вузла).

Також можна використовувати Job для запуску кількох Podʼів паралельно.

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

Запуск прикладу Job

Ось конфігурація прикладу Job. Тут обчислюється число π з точністю до 2000 знаків і виконується його вивід. Виконання зазвичай займає близько 10 секунд.

apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  template:
    spec:
      containers:
      - name: pi
        image: perl:5.34.0
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never
  backoffLimit: 4

Ви можете запустити цей приклад за допомогою наступної команди:

kubectl apply -f https://kubernetes.io/examples/controllers/job.yaml

Вивід буде схожим на це:

job.batch/pi created

Перевірте статус Job за допомогою kubectl:


Name:           pi
Namespace:      default
Selector:       batch.kubernetes.io/controller-uid=c9948307-e56d-4b5d-8302-ae2d7b7da67c
Labels:         batch.kubernetes.io/controller-uid=c9948307-e56d-4b5d-8302-ae2d7b7da67c
                batch.kubernetes.io/job-name=pi
                ...
Annotations:    batch.kubernetes.io/job-tracking: ""
Parallelism:    1
Completions:    1
Start Time:     Mon, 02 Dec 2019 15:20:11 +0200
Completed At:   Mon, 02 Dec 2019 15:21:16 +0200
Duration:       65s
Pods Statuses:  0 Running / 1 Succeeded / 0 Failed
Pod Template:
  Labels:  batch.kubernetes.io/controller-uid=c9948307-e56d-4b5d-8302-ae2d7b7da67c
           batch.kubernetes.io/job-name=pi
  Containers:
   pi:
    Image:      perl:5.34.0
    Port:       <none>
    Host Port:  <none>
    Command:
      perl
      -Mbignum=bpi
      -wle
      print bpi(2000)
    Environment:  <none>
    Mounts:       <none>
  Volumes:        <none>
Events:
  Type    Reason            Age   From            Message
  ----    ------            ----  ----            -------
  Normal  SuccessfulCreate  21s   job-controller  Created pod: pi-xf9p4
  Normal  Completed         18s   job-controller  Job completed


apiVersion: batch/v1
kind: Job
metadata:
  annotations: batch.kubernetes.io/job-tracking: ""
             ...  
  creationTimestamp: "2022-11-10T17:53:53Z"
  generation: 1
  labels:
    batch.kubernetes.io/controller-uid: 863452e6-270d-420e-9b94-53a54146c223
    batch.kubernetes.io/job-name: pi
  name: pi
  namespace: default
  resourceVersion: "4751"
  uid: 204fb678-040b-497f-9266-35ffa8716d14
spec:
  backoffLimit: 4
  completionMode: NonIndexed
  completions: 1
  parallelism: 1
  selector:
    matchLabels:
      batch.kubernetes.io/controller-uid: 863452e6-270d-420e-9b94-53a54146c223
  suspend: false
  template:
    metadata:
      creationTimestamp: null
      labels:
        batch.kubernetes.io/controller-uid: 863452e6-270d-420e-9b94-53a54146c223
        batch.kubernetes.io/job-name: pi
    spec:
      containers:
      - command:
        - perl
        - -Mbignum=bpi
        - -wle
        - print bpi(2000)
        image: perl:5.34.0
        imagePullPolicy: IfNotPresent
        name: pi
        resources: {}
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
      dnsPolicy: ClusterFirst
      restartPolicy: Never
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30
status:
  active: 1
  ready: 0
  startTime: "2022-11-10T17:53:57Z"
  uncountedTerminatedPods: {}

Щоб переглянути завершені Podʼи Job, використовуйте kubectl get pods.

Щоб вивести всі Podʼи, які належать Job у машинночитаній формі, ви можете використовувати таку команду:

pods=$(kubectl get pods --selector=batch.kubernetes.io/job-name=pi --output=jsonpath='{.items[*].metadata.name}')
echo $pods

Вивід буде схожим на це:

pi-5rwd7

Тут, селектор збігається з селектором, який використовується в Job. Параметр --output=jsonpath зазначає вираз з назвою з кожного Pod зі списку.

kubectl logs $pods

Іншим варіантом є використання kubectl logs для виводу логів з кожного Pod.

kubectl logs job/pi

Вивід буде схожим на це:

3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679821480865132823066470938446095505822317253594081284811174502841027019385211055596446229489549303819644288109756659334461284756482337867831652712019091456485669234603486104543266482133936072602491412737245870066063155881748815209209628292540917153643678925903600113305305488204665213841469519415116094330572703657595919530921861173819326117931051185480744623799627495673518857527248912279381830119491298336733624406566430860213949463952247371907021798609437027705392171762931767523846748184676694051320005681271452635608277857713427577896091736371787214684409012249534301465495853710507922796892589235420199561121290219608640344181598136297747713099605187072113499999983729780499510597317328160963185950244594553469083026425223082533446850352619311881710100031378387528865875332083814206171776691473035982534904287554687311595628638823537875937519577818577805321712268066130019278766111959092164201989380952572010654858632788659361533818279682303019520353018529689957736225994138912497217752834791315155748572424541506959508295331168617278558890750983817546374649393192550604009277016711390098488240128583616035637076601047101819429555961989467678374494482553797747268471040475346462080466842590694912933136770289891521047521620569660240580381501935112533824300355876402474964732639141992726042699227967823547816360093417216412199245863150302861829745557067498385054945885869269956909272107975093029553211653449872027559602364806654991198818347977535663698074265425278625518184175746728909777727938000816470600161452491921732172147723501414419735685481613611573525521334757418494684385233239073941433345477624168625189835694855620992192221842725502542568876717904946016534668049886272327917860857843838279679766814541009538837863609506800642251252051173929848960841284886269456042419652850222106611863067442786220391949450471237137869609563643719172874677646575739624138908658326459958133904780275901

Створення опису Job

Як і з будь-якою іншою конфігурацією Kubernetes, у Job мають бути вказані поля apiVersion, kind та metadata.

При створенні панеллю управління нових Podʼів для Job, поле .metadata.name Job є частиною основи для надання імен цим Podʼам. Імʼя Job повинно бути дійсним значенням DNS-піддомену, але це може призводити до неочікуваних результатів для імен хостів Podʼів. Для найкращої сумісності імʼя повинно відповідати більш обмеженим правилам для DNS-мітки. Навіть якщо імʼя є DNS-піддоменом, імʼя повинно бути не довше 63 символів.

Також у Job повинен бути розділ .spec.

Мітки для Job

Мітки Job повинні мати префікс batch.kubernetes.io/ для job-name та controller-uid.

Шаблон Podʼа

.spec.template — єдине обовʼязкове поле .spec.

.spec.template — це шаблон Podʼа. Він має точно таку ж схему, як Pod, окрім того, що він вкладений і не має apiVersion чи kind.

Окрім обовʼязкових полів для Podʼа , шаблон Podʼа в Job повинен вказати відповідні мітки (див. селектор Podʼа) та відповідну політику перезапуску.

Дозволяється лише RestartPolicy, рівний Never або OnFailure.

Селектор Podʼа

Поле .spec.selector є необовʼязковим. У майже всіх випадках ви не повинні його вказувати. Дивіться розділ вказування вашого власного селектора Podʼа.

Паралельне виконання для Jobs

Існують три основних типи завдань, які підходять для виконання в якості Job:

  1. Непаралельні Jobs

    • зазвичай запускається лише один Pod, якщо Pod не вдається.
    • Job завершується, як тільки його Pod завершується успішно.
  2. Паралельні Jobs із фіксованою кількістю завершень

    • вкажіть ненульове позитивне значення для .spec.completions.
    • Job являє собою загальне завдання і завершується, коли є .spec.completions успішних Podʼів.
    • при використанні .spec.completionMode="Indexed", кожен Pod отримує різний індекс у діапазоні від 0 до .spec.completions-1.
  3. Паралельні Jobs із чергою завдань

    • не вказуйте .spec.completions, типово встановлюється .spec.parallelism.
    • Podʼи повинні координувати серед себе або зовнішній сервіс для визначення над чим кожен з них має працювати. Наприклад, Pod може отримати набір з N елементів з черги завдань.
    • кожен Pod може незалежно визначити, чи завершилися всі його партнери, і, таким чином, що весь Job завершений.
    • коли будь-який Pod з Job завершується успішно, нові Podʼи не створюються.
    • як тільки хоча б один Pod завершився успішно і всі Podʼи завершені, тоді Job завершується успішно.
    • як тільки будь-який Pod завершився успішно, жоден інший Pod не повинен виконувати роботу для цього завдання чи записувати будь-який вивід. Вони всі мають бути в процесі завершення.

Для непаралельного Job ви можете залишити як .spec.completions, так і .spec.parallelism не встановленими. Коли обидва не встановлені, обидва типово встановлюються на 1.

Для Job із фіксованою кількістю завершень вам слід встановити .spec.completions на кількість необхідних завершень. Ви можете встановити .spec.parallelism чи залишити його не встановленим, і він буде встановлено типово на 1.

Для Job із чергою завдань ви повинні залишити .spec.completions не встановленим і встановити .spec.parallelism на не відʼємне ціле число.

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

Контроль паралелізму

Запитаний паралелізм (.spec.parallelism) може бути встановлений на будь-яке не відʼємне значення. Якщо значення не вказано, стандартно воно дорівнює 1. Якщо вказано як 0, то Job ефективно призупинено до тих пір, поки воно не буде збільшене.

Фактична паралельність (кількість Podʼів, які працюють в будь-який момент) може бути більше чи менше, ніж запитаний паралелізм, з різних причин:

  • Для Job із фіксованою кількістю завершень, фактична кількість Podʼів, які працюють паралельно, не буде перевищувати кількість залишених завершень. Значення .spec.parallelism більше чи менше ігнорується.
  • Для Job із чергою завдань, жоден новий Pod не запускається після успішного завершення будь-якого Podʼа — залишені Podʼи мають право завершити роботу.
  • Якщо у контролера Job не було часу відреагувати.
  • Якщо контролер Job не зміг створити Podʼи з будь-якої причини (нестача ResourceQuota, відсутність дозволу і т.д.), тоді може бути менше Podʼів, ніж запитано.
  • Контролер Job може обмежувати створення нових Podʼів через ексцесивні попередні відмови Podʼів у цьому ж Job.
  • Коли Pod завершується відповідним чином, на його зупинку потрібен час.

Режим завершення

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

Для завдань з фіксованою кількістю завершень — тобто завдань, які мають не нульове .spec.completions — може бути встановлено режим завершення, який вказується в .spec.completionMode:

  • NonIndexed (стандартно): завдання вважається завершеним, коли є .spec.completions успішно завершених Podʼів. Іншими словами, завершення кожного Podʼа гомологічне одне одному. Зверніть увагу, що завдання, у яких .spec.completions дорівнює null, неявно є NonIndexed.

  • Indexed: Podʼи завдання отримують асоційований індекс завершення від 0 до .spec.completions-1. Індекс доступний через чотири механізми:

    • Анотація Podʼа batch.kubernetes.io/job-completion-index.
    • Мітка Podʼа batch.kubernetes.io/job-completion-index (для v1.28 і новіших). Зверніть увагу, що для використання цієї мітки механізм feature gate PodIndexLabel повинен бути увімкнений, і він є типово увімкненим.
    • Як частина імені хоста Podʼа, за шаблоном $(job-name)-$(index). Коли ви використовуєте Індексоване Завдання у поєднанні з Service, Podʼи всередині завдання можуть використовувати детерміністичні імена хостів для адресації одне одного через DNS. Докладні відомості щодо того, як налаштувати це, див. Завдання з комунікацією від Podʼа до Podʼа.
    • З контейнера завдання, в змінній середовища JOB_COMPLETION_INDEX.

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

Обробка відмов Podʼа та контейнера

Контейнер у Podʼі може вийти з ладу з ряду причин, таких як завершення процесу з ненульовим кодом виходу або примусове припинення роботи контейнера через перевищення ліміту памʼяті та таке інше. Якщо це стається і .spec.template.spec.restartPolicy = "OnFailure", тоді Pod залишається на вузлі, але контейнер перезапускається. Отже, ваш застосунок повинен обробляти випадок, коли він перезапускається локально, або вказувати .spec.template.spec.restartPolicy = "Never". Докладні відомості про restartPolicy див. в розділі життєвий цикл Podʼа.

Весь Pod також може вийти з ладу з ряду причин, таких як коли Pod видаляється з вузла (вузол оновлюється, перезавантажується, видаляється тощо), або якщо контейнер Podʼа виходить з ладу і .spec.template.spec.restartPolicy = "Never". Коли Pod виходить з ладу, контролер завдання запускає новий Pod. Це означає, що ваш застосунок повинен обробляти випадок, коли він перезапускається у новому Podʼі. Зокрема, він повинен обробляти тимчасові файли, блокування, неповний вивід та інше, викликане попередніми запусками.

Типово кожна відмова Podʼа враховується в ліміті .spec.backoffLimit, див. політика відмови Podʼа. Однак ви можете налаштовувати обробку відмов Podʼа, встановлюючи [політику відмови Podʼа] (#pod-failure-policy) для завдання.

Додатково ви можете вирішити враховувати відмови Podʼа незалежно для кожного індексу в Індексованому Завданні, встановлюючи поле .spec.backoffLimitPerIndex (докладні відомості див. ліміт затримки на індекс).

Зверніть увагу, що навіть якщо ви вказали .spec.parallelism = 1 і .spec.completions = 1 і .spec.template.spec.restartPolicy = "Never", той самий програмний код може іноді бути запущений двічі.

Якщо ви вказали як .spec.parallelism, так і .spec.completions більше ніж 1, то може бути запущено кілька Podʼів одночасно. Таким чином, ваші Podʼи також повинні бути стійкими до конкурентності.

Якщо ви вказуєте поле .spec.podFailurePolicy, контролер Job не вважає Pod, який перебуває у стані завершення (Pod з встановленим полем .metadata.deletionTimestamp), за помилку до того, як Pod стане термінальним (його .status.phase є Failed або Succeeded). Однак контролер Job створює замінний Pod, як тільки стає очевидним, що Pod перебуває в процесі завершення. Після того як Pod завершиться, контролер Job оцінює .backoffLimit і .podFailurePolicy для відповідного Job, враховуючи тепер уже завершений Pod.

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

Політика backoff відмови Podʼа

Є ситуації, коли ви хочете щоб завдання зазнало збою після певної кількості спроб через логічну помилку в конфігурації тощо. Для цього встановіть .spec.backoffLimit, щоб вказати кількість спроб перед тим, як вважати завдання таким, що не вдалось. Ліміт затримки стандартно встановлено на рівні 6. Помилкові Podʼи, повʼязані з завданням, відновлюються контролером завдань з експоненційною затримкою (10 с, 20 с, 40 с …) з верхнім обмеженням у шість хвилин.

Кількість спроб обчислюється двома способами:

  • Кількість Podʼів з .status.phase = "Failed".
  • При використанні restartPolicy = "OnFailure" кількість спроб у всіх контейнерах Podʼів з .status.phase, що дорівнює Pending або Running.

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

Ліміт затримки для кожного індексу

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

Коли ви запускаєте індексоване Завдання, ви можете вибрати обробку спроб для відмов Podʼа незалежно для кожного індексу. Для цього встановіть .spec.backoffLimitPerIndex, щоб вказати максимальну кількість невдалих спроб Podʼа для кожного індексу.

Коли ліміт затримки для кожного індексу перевищується для певного індексу, Kubernetes вважає цей індекс невдалим і додає його до поля .status.failedIndexes. Індекси, які виконались успішно, реєструються в полі .status.completedIndexes, незалежно від того, чи ви встановили поле backoffLimitPerIndex.

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

Ви також можете обмежити максимальну кількість позначених невдалих індексів, встановивши поле .spec.maxFailedIndexes. Коли кількість невдалих індексів перевищує значення поля maxFailedIndexes, контролер завдань запускає завершення всіх залишаються запущеними Podʼами для цього завдання. Щойно всі Podʼи будуть завершені, контролер завдань позначає все Завдання як невдале, встановлюючи умову Failed в статусі Завдання.

Ось приклад маніфесту для завдання, яке визначає backoffLimitPerIndex:

apiVersion: batch/v1
kind: Job
metadata:
  name: job-backoff-limit-per-index-example
spec:
  completions: 10
  parallelism: 3
  completionMode: Indexed  # обов'язково для функціоналу
  backoffLimitPerIndex: 1  # максимальна кількість невдач на один індекс
  maxFailedIndexes: 5      # максимальна кількість невдалих індексів перед припиненням виконання Job
  template:
    spec:
      restartPolicy: Never # обов'язково для функціоналу
      containers:
      - name: example
        image: python
        command:           # Робота завершується невдачею, оскільки є принаймні один невдалий індекс
                           # (всі парні індекси невдаються), але всі індекси виконуються,
                           # оскільки не перевищено максимальну кількість невдалих індексів.
        - python3
        - -c
        - |
          import os, sys
          print("Привіт, світ")
          if int(os.environ.get("JOB_COMPLETION_INDEX")) % 2 == 0:
            sys.exit(1)          

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

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

kubectl get -o yaml job job-backoff-limit-per-index-example
  status:
    completedIndexes: 1,3,5,7,9
    failedIndexes: 0,2,4,6,8
    succeeded: 5          # 1 succeeded pod for each of 5 succeeded indexes
    failed: 10            # 2 failed pods (1 retry) for each of 5 failed indexes
    conditions:
    - message: Job has failed indexes
      reason: FailedIndexes
      status: "True"
      type: FailureTarget
    - message: Job has failed indexes
      reason: FailedIndexes
      status: "True"
      type: Failed

Контролер Job додає умову FailureTarget до Job для запуску завершення та очищення Job. Коли всі Podʼи Job завершуються, контролер Job додає умову Failed з тими ж значеннями для reason і message, що й у умови FailureTarget. Для деталей дивіться Завершення Podʼів завдання.

Додатково ви можете використовувати ліміт затримки для кожного індексу разом з політикою збоїв Podʼа. Коли використовується ліміт затримки для кожного індексу, доступний новій дії FailIndex, який дозволяє вам уникати непотрібних повторів всередині індексу.

Політика збою Podʼа

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

Політика збою Podʼа, визначена за допомогою поля .spec.podFailurePolicy, дозволяє вашому кластеру обробляти відмови Podʼа на основі кодів виходу контейнера та умов Podʼа.

У деяких ситуаціях вам може знадобитися кращий контроль обробки відмов Podʼа, ніж контроль, який надає політика відмови Podʼа за допомогою затримки збою Podʼа, яка базується на .spec.backoffLimit завдання. Ось деякі приклади використання:

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

Ви можете налаштувати політику збою Podʼа в полі .spec.podFailurePolicy, щоб відповідати вищенаведеним використанням. Ця політика може обробляти відмови Podʼа на основі кодів виходу контейнера та умов Podʼа.

Ось маніфест для завдання, яке визначає podFailurePolicy:

apiVersion: batch/v1
kind: Job
metadata:
  name: job-pod-failure-policy-example
spec:
  completions: 12
  parallelism: 3
  template:
    spec:
      restartPolicy: Never
      containers:
      - name: main
        image: docker.io/library/bash:5
        command: ["bash"]        # приклад команди, що емулює помилку, яка запускає дію FailJob
        args:
        - -c
        - echo "Hello world!" && sleep 5 && exit 42
  backoffLimit: 6
  podFailurePolicy:
    rules:
    - action: FailJob
      onExitCodes:
        containerName: main      # опціонально
        operator: In             # одне з: In, NotIn
        values: [42]
    - action: Ignore             # одне з: Ignore, FailJob, Count
      onPodConditions:
      - type: DisruptionTarget   # вказує на порушення роботи Podʼу

У вищенаведеному прикладі перше правило політики збою Podʼа вказує, що завдання слід позначити як невдале, якщо контейнер main завершиться кодом виходу 42. Наступні правила стосуються саме контейнера main:

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

Друге правило політики збою Podʼа, що вказує дію Ignore для невдалих Podʼів з умовою DisruptionTarget, виключає Podʼи, які взяли участь в розладах, з хунок ліміту спроб .spec.backoffLimit.

Ось деякі вимоги та семантика API:

  • якщо ви хочете використовувати поле .spec.podFailurePolicy для завдання Job, вам також слід визначити шаблон Podʼа цього завдання з .spec.restartPolicy, встановленим на Never.
  • правила політики збою Podʼа, які ви визначаєте у spec.podFailurePolicy.rules, оцінюються послідовно. Якщо одне з правил відповідає збою Podʼа, інші правила ігноруються. Якщо жодне правило не відповідає збою Podʼа, застосовується типова обробка.
  • ви можете бажати обмежити правило певним контейнером, вказавши його імʼя у spec.podFailurePolicy.rules[*].onExitCodes.containerName. Якщо не вказано, правило застосовується до всіх контейнерів. Якщо вказано, воно повинно відповідати імені одного з контейнерів або initContainer у шаблоні Podʼа.
  • ви можете вказати дію, вживану при відповідності політиці збою Podʼа, у spec.podFailurePolicy.rules[*].action. Можливі значення:
    • FailJob: використовуйте це, щоб вказати, що завдання Podʼа має бути позначено як Failed та всі запущені Podʼи повинні бути завершені.
    • Ignore: використовуйте це, щоб вказати, що лічильник до .spec.backoffLimit не повинен збільшуватися, і повинен бути створений замінюючий Pod.
    • Count: використовуйте це, щоб вказати, що Pod повинен бути оброблений типовим способом. Лічильник до .spec.backoffLimit повинен збільшитися.
    • FailIndex: використовуйте цю дію разом із лімітом затримки на кожен індекс для уникнення непотрібних повторних спроб в межах індексу невдалого Podʼа.

Коли ви використовуєте podFailurePolicy, і Job зазнає невдачі через Pod, що відповідає правилу з дією FailJob, контролер Job запускає процес завершення Job, додаючи умову FailureTarget. Для деталей дивіться Завершення та очищення Job.

Політика успіху

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

При створенні Індексованого Завдання ви можете визначити, коли завдання може бути визнане успішним за допомогою .spec.successPolicy, на основі успішних Podʼів.

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

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

Ви можете налаштувати політику успіху у полі .spec.successPolicy, щоб задовольнити вищезазначені випадки використання. Ця політика може керувати успіхом завдання на основі успішних Podʼів. Після того, як завдання відповідає політиці успіху, контролер завдань завершує залишкові Podʼи. Політика успіху визначається правилами. Кожне правило може мати одну з наступних форм:

  • Коли ви вказуєте лише succeededIndexes, одразу після успішного завершення всіх індексів, вказаних у succeededIndexes, контролер завдань позначає завдання як успішне. succeededIndexes повинен бути списком інтервалів між 0 і .spec.completions-1.
  • Коли ви вказуєте лише succeededCount, як тільки кількість успішних індексів досягне succeededCount, контролер завдань позначає завдання як успішне.
  • Коли ви вказуєте як succeededIndexes, так і succeededCount, як тільки кількість успішних індексів з підмножини індексів, вказаних у succeededIndexes, досягне succeededCount, контролер завдань позначає завдання як успішне.

Зверніть увагу, що коли ви вказуєте кілька правил у .spec.successPolicy.rules, контролер завдань оцінює правила послідовно. Після того, як завдання задовольняє правило, контролер завдань ігнорує решту правил.

Ось приклад маніфеста для завдання із successPolicy:

apiVersion: batch/v1
kind: Job
metadata:
  name: job-success
spec:
  parallelism: 10
  completions: 10
  completionMode: Indexed # Обовʼязково для іспішної політики
  successPolicy:
    rules:
      - succeededIndexes: 0,2-3
        succeededCount: 1
  template:
    spec:
      containers:
      - name: main
        image: python
        command:          # З урахуванням того, що принаймні один із Podʼів з індексами 0, 2 та 3 успішно завершився,
                          # загальна задача вважатиметься успішною.
          - python3
          - -c
          - |
            import os, sys
            if os.environ.get("JOB_COMPLETION_INDEX") == "2":
              sys.exit(0)
            else:
              sys.exit(1)            
      restartPolicy: Never

У вищенаведеному прикладі були вказані як succeededIndexes, так і succeededCount. Тому контролер завдань позначить завдання як успішне і завершить залишкові Podʼи після успіху будь-яких зазначених індексів, 0, 2 або 3. Завдання, яке відповідає політиці успіху, отримує умову SuccessCriteriaMet з причиною SuccessPolicy. Після видалення залишкових Podʼів, завдання отримує стан Complete.

Зверніть увагу, що succeededIndexes представлено як інтервали, розділені дефісом. Номери перераховані у вигляді першого та останнього елементів серії, розділених дефісом.

Завершення завдання та очищення

Коли завдання завершується, Podʼи більше не створюються, але Podʼи зазвичай також не видаляються. Тримання їх допомагає переглядати логи завершених Podʼів для перевірки наявності помилок, попереджень чи іншого діагностичного виводу. Обʼєкт завдання також залишається після завершення, щоб ви могли переглядати його статус. Користувачу слід видаляти старі завдання після перегляду їх статусу. Видаліть завдання за допомогою kubectl (наприклад, kubectl delete jobs/pi або kubectl delete -f ./job.yaml). Коли ви видаляєте завдання за допомогою kubectl, всі його створені Podʼи також видаляються.

Стандартно завдання буде виконуватися без перерви, поки Pod не вийде з ладу (restartPolicy=Never) або контейнер не вийде з ладу з помилкою (restartPolicy=OnFailure), після чого завдання дотримується .spec.backoffLimit, описаного вище. Як тільки досягнуто .spec.backoffLimit, завдання буде позначене як невдале, і будь-які запущені Podʼи будуть завершені.

Іншим способом завершити завдання є встановлення граничного терміну виконання. Це робиться шляхом встановлення поля .spec.activeDeadlineSeconds завдання кількості секунд. activeDeadlineSeconds застосовується до тривалості завдання, незалежно від кількості створених Podʼів. Як тільки Job досягає activeDeadlineSeconds, всі його запущені Podʼи завершуються, і статус завдання стане type: Failed з reason: DeadlineExceeded.

Зауважте, що .spec.activeDeadlineSeconds Job має пріоритет перед його .spec.backoffLimit. Отже, завдання, яке повторює один або кілька невдал х Podʼів, не розпочне розгортання додаткових Podʼів, якщо activeDeadlineSeconds вже досягнуто, навіть якщо backoffLimit не досягнуто. Приклад:

apiVersion: batch/v1 kind: Job
metadata:
  name: pi-with-timeout
Стандартноimit: 5
  activeDeadlineSeconds: 100
  template:
    spec:
      containers:
      - name: pi
        image: perl:5.34.0
        command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never

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

Памʼятайте, що restartPolicy застосовується до Podʼа, а не до самого завдання: автоматичного перезапуску завдання не відбудеться, якщо статус завдання type: Failed. Іншими словами, механізми завершення завдання, активовані за допомогою .spec.activeDeadlineSeconds і .spec.backoffLimit, призводять до постійної невдачі завдання, що вимагає ручного втручання для вирішення.

Умови термінального завдання

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

  • Успішне виконання: умова завдання Complete
  • Невдача: умова завдання Failed

Завдання зазнають невдачі з наступних причин:

  • Кількість невдач Podʼа перевищила вказане .spec.backoffLimit у специфікації завдання. Для деталей див. Політика відмови Podʼа.
  • Час виконання завдання перевищив вказане .spec.activeDeadlineSeconds.
  • Індексуєме завдання, яке використовує .spec.backoffLimitPerIndex, має невдалі індекси. Для деталей див. Ліміт затримки на індекс.
  • Кількість невдалих індексів у завданні перевищила вказане spec.maxFailedIndexes. Для деталей див. Ліміт затримки на індекс.
  • Невдалий Pod відповідає правилу у .spec.podFailurePolicy, яке має дію FailJob. Для деталей про те, як правила політики невдач Podʼа можуть вплинути на оцінку невдачі, див. Політика невдач Podʼа.

Завдання успішні з наступних причин:

  • Кількість успішних Podʼів досягла вказаного .spec.completions.
  • Виконані критерії, зазначені у .spec.successPolicy. Для деталей див. Політика успіху.

У Kubernetes v1.31 та пізніших версіях контролер завдань затримує додавання термінальних умов, Failed або Complete, поки всі Podʼи завдання не будуть завершені.

У Kubernetes v1.30 та раніших версіях контролер завдань додавав термінальні умови Complete або Failed відразу після того, як був запущений процес завершення завдання та всі завершувачі Podʼа були видалені. Однак деякі Podʼи все ще могли працювати або завершуватися в момент додавання термінальної умови.

У Kubernetes v1.31 та пізніших версіях контролер додає термінальні умови завдання лише після завершення всіх Podʼів. Ви можете увімкнути цю поведінку, використовуючи функціональні можливості JobManagedBy або JobPodReplacementPolicy (стандартно увімкнено).

Завершення Podʼів завдання

Контролер Job додає умову FailureTarget або умову SuccessCriteriaMet до завдання, щоб запустити завершення Pod після того, як завдання відповідає критеріям успіху або невдачі.

Фактори, такі як terminationGracePeriodSeconds, можуть збільшити час від моменту додавання контролером завдання умови FailureTarget або умови SuccessCriteriaMet до моменту, коли всі Pod завдання завершаться і контролер Job додасть термінальну умову (Failed або Complete).

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

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

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

Автоматичне очищення завершених завдань

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

Механізм TTL для завершених завдань

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

Ще один спосіб автоматично очищати завершені завдання (якщо вони Complete або Failed) — це використовувати механізм TTL, наданий контролером TTL для завершених ресурсів, вказуючи поле .spec.ttlSecondsAfterFinished у Job.

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

Наприклад:

apiVersion: batch/v1
kind: Job
metadata:
  name: pi-with-ttl
spec:
  ttlSecondsAfterFinished: 100
  template:
    spec:
      containers:
      - name: pi
        image: perl:5.34.0
        command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never

Job pi-with-ttl буде призначено для автоматичного видалення через 100 секунд після завершення.

Якщо поле встановлено в 0, Job буде призначено для автоматичного видалення негайно після завершення. Якщо поле не вказане, це Job не буде очищено контролером TTL після завершення.

Патерни використання завдань (Job)

Обʼєкт завдання (Job) може використовуватися для обробки набору незалежних, але повʼязаних робочих одиниць. Це можуть бути електронні листи для надсилання, кадри для відтворення, файли для транскодування, діапазони ключів у базі даних NoSQL для сканування і так далі.

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

Існує кілька різних патернів для паралельних обчислень, кожен з власними перевагами та недоліками. Компроміси:

  • Один обʼєкт Job для кожної робочої одиниці або один обʼєкт Job для всіх робочих одиниць. Один Job на кожну робочу одиницю створює деяку накладну роботу для користувача та системи при управлінні великою кількістю обʼєктів Job. Один Job для всіх робочих одиниць підходить краще для великої кількості одиниць.
  • Кількість створених Podʼів дорівнює кількості робочих одиниць або кожен Pod може обробляти кілька робочих одиниць. Коли кількість Podʼів дорівнює кількості робочих одиниць, Podʼи зазвичай вимагають менше змін у наявному коді та контейнерах. Кожен Pod, що обробляє кілька робочих одиниць, підходить краще для великої кількості одиниць.
  • Декілька підходів використовують робочу чергу. Це вимагає запуску служби черги та модифікацій існуючої програми чи контейнера, щоб зробити його сумісним із чергою роботи. Інші підходи легше адаптувати до наявного контейнеризованого застосунку.
  • Коли Job повʼязаний із headless Service, ви можете дозволити Podʼам у межах Job спілкуватися один з одним для спільної обчислень.

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

ПатернОдин обʼєкт JobКількість Pods менше за робочі одиниці?Використовувати застосунок без модифікацій?
Черга з Pod на робочу одиницюіноді
Черга змінної кількості Pod
Індексоване Завдання із статичним призначенням роботи
Завдання із спілкуванням від Pod до Podінодііноді
Розширення шаблону Job

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

Ця таблиця показує обовʼязкові налаштування для .spec.parallelism та .spec.completions для кожного з патернів. Тут W — це кількість робочих одиниць.

Патерн.spec.completions.spec.parallelism
Черга з Pod на робочу одиницюWбудь-яка
Черга змінної кількості Podnullбудь-яка
Індексоване Завдання із статичним призначенням роботиWбудь-яка
Завдання із спілкуванням від Pod до PodWW
Розширення шаблону Job1повинно бути 1

Розширене використання завдань (Job)

Відкладення завдання

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

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

Щоб призупинити Job, ви можете оновити поле .spec.suspend Job на значення true; пізніше, коли ви захочете відновити його, оновіть його на значення false. Створення Job з .spec.suspend встановленим в true створить його в призупиненому стані.

При відновленні Job з призупинення йому буде встановлено час початку .status.startTime в поточний час. Це означає, що таймер .spec.activeDeadlineSeconds буде зупинений і перезапущений, коли Job буде призупинено та відновлено.

Коли ви призупиняєте Job, будь-які запущені Podʼи, які не мають статусу Completed, будуть завершені з сигналом SIGTERM. Буде дотримано період відповідного завершення ваших Podʼів, і вашим Podʼам слід обробити цей сигнал протягом цього періоду. Це може включати в себе збереження прогресу для майбутнього або скасування змін. Podʼи, завершені цим чином, не враховуватимуться при підрахунку completions Job.

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

kubectl get job myjob -o yaml
apiVersion: batch/v1
kind: Job
metadata:
  name: myjob
spec:
  suspend: true
  parallelism: 1
  completions: 5
  template:
    spec:
      ...

Ви також можете перемикати призупинення Job, використовуючи командний рядок.

Призупиніть активний Job:

kubectl patch job/myjob --type=strategic --patch '{"spec":{"suspend":true}}'

Відновіть призупинений Job:

kubectl patch job/myjob --type=strategic --patch '{"spec":{"suspend":false}}'

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

kubectl get jobs/myjob -o yaml
apiVersion: batch/v1
kind: Job
# .metadata and .spec пропущено
status:
  conditions:
  - lastProbeTime: "2021-02-05T13:14:33Z"
    lastTransitionTime: "2021-02-05T13:14:33Z"
    status: "True"
    type: Suspended
  startTime: "2021-02-05T13:13:48Z"

Умова Job типу "Suspended" зі статусом "True" означає, що Job призупинено; поле lastTransitionTime може бути використане для визначення того, як довго Job було призупинено. Якщо статус цієї умови є "False", то Job було раніше призупинено і зараз працює. Якщо такої умови не існує в статусі Job, то Job ніколи не був зупинений.

Також створюються події, коли Job призупинено та відновлено:

kubectl describe jobs/myjob
Name:           myjob
...
Events:
  Type    Reason            Age   From            Message
  ----    ------            ----  ----            -------
  Normal  SuccessfulCreate  12m   job-controller  Created pod: myjob-hlrpl
  Normal  SuccessfulDelete  11m   job-controller  Deleted pod: myjob-hlrpl
  Normal  Suspended         11m   job-controller  Job suspended
  Normal  SuccessfulCreate  3s    job-controller  Created pod: myjob-jvb44
  Normal  Resumed           3s    job-controller  Job resumed

Останні чотири події, зокрема події "Suspended" та "Resumed", є прямим наслідком перемикання поля .spec.suspend. Протягом цього часу ми бачимо, що жоден Pods не був створений, але створення Pod розпочалося знову, як тільки Job було відновлено.

Змінні директиви планування

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

У більшості випадків, паралелльні завдання вимагатимуть щоб їхні Podʼи запускались з певними обмеженнями, типу "всі в одній зоні" або "всі на GPU моделі x або y", але не комбінація обох.

Поле призупинення є першим кроком для досягнення цих семантик. Призупинення дозволяє власному контролеру черги вирішити, коли повинне початися завдання; Однак після того, як завдання престає бути призупиненим, власний контролер черги не впливає на те, де насправді буде розташований Pod завдання.

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

Поля в шаблоні Podʼа Job, які можна оновити, це приналежність до вузла, селектор вузла, толерантності, мітки, анотації та вікно планування.

Вказування власного селектора Podʼа

Зазвичай, коли ви створюєте обʼєкт Job, ви не вказуєте .spec.selector. Логіка системного визначення типових значень додає це поле під час створення Завдання. Вона обирає значення селектора, яке не буде перекриватися з будь-яким іншим завданням.

Однак у деяких випадках вам може знадобитися перевизначити цей автоматично встановлений селектор. Для цього ви можете вказати .spec.selector Job.

Будьте дуже уважні при цьому. Якщо ви вказуєте селектор міток, який не є унікальним для Podʼів цього Завдання, і який відповідає неповʼязаним Podʼам, то Podʼи з неповʼязаним Завданням можуть бути видалені, або це Завдання може вважати інші Podʼи завершеними, або одне чи обидва Завдання можуть відмовитися від створення Podʼів або виконуватись до завершення роботи. Якщо вибираєте неунікальний селектор, то інші контролери (наприклад, ReplicationController) та їхні Podʼи можуть проявляти непередбачувану поведінку також. Kubernetes не зупинить вас від того, що ви можете зробити помилку при зазначені .spec.selector.

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

Скажімо, Завдання old вже запущене. Ви хочете, щоб наявні Podʼи продовжували працювати, але ви хочете, щоб решта Podʼів, які воно створює, використовували інший шаблон Pod і щоб у Завдання було нове імʼя. Ви не можете оновити Завдання, оскільки ці поля не можна оновлювати. Отже, ви видаляєте Завдання old, але залишаєте її Podʼи запущеними, використовуючи kubectl delete jobs/old --cascade=orphan. Перед видаленням ви робите помітку, який селектор використовувати:

kubectl get job old -o yaml

Виввід схожий на цей:

kind: Job
metadata:
  name: old
  ...
spec:
  selector:
    matchLabels:
      batch.kubernetes.io/controller-uid: a8f3d00d-c6d2-11e5-9f87-42010af00002
  ...

Потім ви створюєте нове Завдання з імʼям new і явно вказуєте той самий селектор. Оскільки існуючі Podʼи мають мітку batch.kubernetes.io/controller-uid=a8f3d00d-c6d2-11e5-9f87-42010af00002, вони також контролюються Завданням new.

Вам потрібно вказати manualSelector: true в новому Завданні, оскільки ви не використовуєте селектор, який система зазвичай генерує автоматично.

kind: Job
metadata:
  name: new
  ...
spec:
  manualSelector: true
  selector:
    matchLabels:
      batch.kubernetes.io/controller-uid: a8f3d00d-c6d2-11e5-9f87-42010af00002
  ...

Саме нове Завдання матиме інший uid від a8f3d00d-c6d2-11e5-9f87-42010af00002. Встановлення manualSelector: true говорить системі, що ви розумієте, що робите, і дозволяє це неспівпадіння.

Відстеження Завдання за допомогою завершувачів

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

Панель управління стежить за Podʼами, які належать будь-якого Завдання, і виявляє, чи Pod був видалений з сервера API. Для цього контролер Job створює Podʼи з завершувачем batch.kubernetes.io/job-tracking. Контролер видаляє завершувач тільки після того, як Pod був врахований в стані Завдання, що дозволяє видалити Pod іншими контролерами або користувачами.

Еластичні Індексовані Завдання

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

Ви можете масштабувати Indexed Job вгору або вниз, змінюючи як .spec.parallelism, так і .spec.completions разом, так щоб .spec.parallelism == .spec.completions. При масштабуванні вниз Kubernetes видаляє Podʼи з вищими індексами.

Сценарії використання для еластичних Індексованих Завдань включають пакетні робочі навантаження, які вимагають масштабування Індексованого Завдання, такі як MPI, Horovod, Ray, та PyTorch.

Відкладене створення замінних Podʼів

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

Типово контролер Job створює Podʼи якнайшвидше, якщо вони або зазнають невдачі, або знаходяться в стані завершення (мають відмітку видалення). Це означає, що в певний момент часу, коли деякі з Podʼів знаходяться в стані завершення, кількість робочих Podʼів для Завдання може бути більшою, ніж parallelism або більше, ніж один Pod на індекс (якщо ви використовуєте Індексоване Завданя).

Ви можете вибрати створення замінних Podʼів лише тоді, коли Podʼи, які знаходиться в стані завершення, повністю завершені (мають status.phase: Failed). Для цього встановіть .spec.podReplacementPolicy: Failed. Типова політика заміщення залежить від того, чи Завдання має встановлену політику відмови Podʼів. Якщо для Завдання не визначено політику відмови Podʼів, відсутність поля podReplacementPolicy вибирає політику заміщення TerminatingOrFailed: панель управління створює Podʼи заміни негайно після видалення Podʼів (як тільки панель управління бачить, що Pod для цього Завдання має встановлене значення deletionTimestamp). Для Завдань із встановленою політикою відмови Podʼів стандартне значення podReplacementPolicy — це Failed, інших значень не передбачено. Докладніше про політики відмови Podʼів для Завдань можна дізнатися у розділі Політика відмови Podʼів.

kind: Job
metadata:
  name: new
  ...
spec:
  podReplacementPolicy: Failed
  ...

При увімкненому feature gate у вашому кластері ви можете перевірити поле .status.terminating Завдання. Значення цього поля — це кількість Podʼів, якими володіє Завдання, які зараз перебувають у стані завершення.

kubectl get jobs/myjob -o yaml
apiVersion: batch/v1
kind: Job
# .metadata and .spec omitted
status:
  terminating: 3 # три Podʼи, які перебувають у стані завершення і ще не досягли стану Failed

Делегування управління обʼєктом Job зовнішньому контролеру

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

Ця функція дозволяє вам вимкнути вбудований контролер Job для конкретного Завдання і делегувати узгодження цього Завдання зовнішньому контролеру.

Ви вказуєте контролер, який узгоджує Завдання, встановлюючи власне значення для поля spec.managedBy — будь-яке значення окрім kubernetes.io/job-controller. Значення поля є незмінним.

Альтернативи

Тільки Podʼи

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

Контролер реплікації

Завдання є компліментарними до контролера реплікації. Контролер реплікації керує Podʼами, які не повинні завершуватися (наприклад, вебсервери), а Завдання керує Podʼами, які очікують завершення (наприклад, пакетні задачі).

Якщо врахувати життєвий цикл Podʼа, Job лише придатний для Podʼів з RestartPolicy, рівним OnFailure або Never. (Примітка: Якщо RestartPolicy не встановлено, стандартне значення — Always.)

Один Job запускає контролер Podʼів

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

Один приклад такого підходу — це Завдання, яке створює Podʼи, яка виконує сценарій, який з свого боку запускає контролер Spark master (див. приклад Spark), запускає драйвер Spark, а потім робить очищення.

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

Що далі

3.4.2.6 - Автоматичне очищення завершених задач

Механізм визначення часу життя для автоматичного очищення старих задач, які завершили виконання.
СТАН ФУНКЦІОНАЛУ: Kubernetes v1.23 [stable]

Коли ваша задача завершилася, корисно залишити цю задачу в API (і не видаляти її відразу), щоб ви могли визначити, чи вдалося, чи не вдалося завдання.

Контролер Kubernetes часу життя після завершення забезпечує механізм TTL (time to live), щоб обмежити термін життя обʼєктів задачі, які завершили виконання.

Очищення завершених задач

Контролер часу життя після завершення підтримується лише для задач. Ви можете використовувати цей механізм для автоматичного очищення завершених завдань (як Complete, так і Failed), автоматично вказавши поле .spec.ttlSecondsAfterFinished задачі, як у цьому прикладі.

Контролер часу життя після завершення передбачає, що задачу можна очистити через TTL секунд після завершення роботи. Відлік починається, коли умова статусу задачі змінюється, щоб показати, що задача є або Complete, або Failed; як тільки TTL закінчився, ця задача стає придатною для каскадного видалення. Коли контролер часу життя після завершення очищає задачу, він видалить її каскадно, іншими словами, він видалить її залежні обʼєкти разом з нею.

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

Ви можете встановити TTL секунд у будь-який момент. Ось деякі приклади встановлення поля .spec.ttlSecondsAfterFinished задачі:

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

Обмеження

Оновлення TTL для завершених задач

Ви можете змінювати період TTL, наприклад, поле .spec.ttlSecondsAfterFinished для задач, після створення або завершення задачі. Якщо ви збільшуєте період TTL після закінчення поточного періоду ttlSecondsAfterFinished, Kubernetes не гарантує збереження цієї задачі, навіть якщо оновлення для збільшення TTL повертає успішну API відповідь.

Зсув часу

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

Годинники не завжди вірні, але різниця повинна бути дуже мала. Будь ласка, будьте уважні при встановленні ненульового TTL.

Що далі

3.4.2.7 - CronJob

Обʼєкт CronJob запускає Job за повторюваним графіком.
СТАН ФУНКЦІОНАЛУ: Kubernetes v1.21 [stable]

CronJob створює Jobs за повторюваним графіком.

CronJob призначений для виконання регулярних запланованих дій, таких як резервне копіювання, генерація звітів та інше. Один обʼєкт CronJob подібний до одного рядка файлу crontab (таблиця cron) на системі Unix. Він запускає Job періодично за заданим графіком, записаним у форматі Cron.

У CronJob є обмеження та особливості. Наприклад, в певних обставинах один CronJob може створювати кілька одночасних Jobs. Див. обмеження нижче.

Коли планувальник створює нові Jobs і (відповідно) Podʼи для CronJob, .metadata.name CronJob є частиною основи для імені цих Podʼів. Назва CronJob повинна бути дійсним значенням DNS-піддомену, але це може призводити до неочікуваних результатів для імен хостів Podʼів. Для найкращої сумісності назва повинна відповідати більш обмеженим правилам DNS-мітки. Навіть коли імʼя є DNS-піддоменом, імʼя не повинно бути довше 52 символів. Це тому, що контролер CronJob автоматично додає 11 символів до наданого вами імені, і існує обмеження на довжину імені Job, яке не повинно перевищувати 63 символи.

Приклад

У цьому прикладі маніфест CronJob виводить поточний час та вітання кожну хвилину:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "* * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox:1.28
            imagePullPolicy: IfNotPresent
            command:
            - /bin/sh
            - -c
            - date; echo Hello from the Kubernetes cluster
          restartPolicy: OnFailure

(Виконання автоматизованих завдань за допомогою CronJob докладніше описує цей приклад).

Написання специфікації CronJob

Синтаксис розкладу

Поле .spec.schedule є обовʼязковим. Значення цього поля відповідає синтаксису Cron:

# ┌───────────── хвилина (0 - 59)
# │ ┌───────────── година (0 - 23)
# │ │ ┌───────────── день місяця (1 - 31)
# │ │ │ ┌───────────── місяць (1 - 12)
# │ │ │ │ ┌───────────── день тижня (0 - 6) (Неділя - Субота)
# │ │ │ │ │                                   АБО неділя, понеділок, вівторок, середа, четвер, пʼятниця, субота
# │ │ │ │ │ 
# │ │ │ │ │
# * * * * *

Наприклад, 0 3 * * 1 означає, що це завдання планується запускати щотижня в понеділок о 3 ранку.

Формат також включає розширені значення кроків "Vixie cron". Як пояснено в документації FreeBSD:

Значення кроків можна використовувати разом із діапазонами. Після діапазону з / <number> вказує пропуски значення числа через діапазон. Наприклад, 0-23/2 можна використовувати в годинах для вказівки виконання команди кожну другу годину (альтернативою в стандарті V7 є 0,2,4,6,8,10,12,14,16,18,20,22). Після зірочки також допускаються кроки, тому, якщо ви хочете сказати "кожні дві години", просто використовуйте */2.

Окрім стандартного синтаксису, також можна використовувати деякі макроси, такі як @monthly:

ЗаписОписЕквівалентно
@yearly (або @annually)Виконувати один раз на рік о півночі 1 січня0 0 1 1 *
@monthlyВиконувати один раз на місяць о півночі першого дня місяця0 0 1 * *
@weeklyВиконувати один раз на тиждень о півночі в неділю0 0 * * 0
@daily (або @midnight)Виконувати один раз на день о півночі0 0 * * *
@hourlyВиконувати один раз на годину на початку години0 * * * *

Для генерації виразів розкладу CronJob можна також використовувати вебінструменти, наприклад crontab.guru.

Шаблон завдання

Поле .spec.jobTemplate визначає шаблон для завдань, які створює CronJob, і воно обовʼязкове. Воно має точно таку ж схему, як Job, за винятком того, що воно вкладене і не має apiVersion або kind. Ви можете вказати загальні метадані для завдань, створених за шаблоном, такі як labels або annotations. Щодо інформації щодо написання .spec завдання, дивіться Написання специфікації завдання.

Термін відстрочення для відкладеного запуску завдання

Поле .spec.startingDeadlineSeconds є необовʼязковим. Це поле визначає термін (в повних секундах) для запуску завдання, якщо це завдання пропускає свій запланований час з будь-якої причини.

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

Для завдань, які пропускають свій термін, налаштований час відстрочення, Kubernetes вважає їх завданнями, що не вдалися. Якщо ви не вказали startingDeadlineSeconds для CronJob, екземпляри завдань не мають терміну.

Якщо поле .spec.startingDeadlineSeconds встановлено (не є нульовим), контролер CronJob вимірює час між тим, коли очікується створення завдання, і зараз. Якщо різниця вище за цей ліміт, він пропускає це виконання.

Наприклад, якщо воно встановлене на 200, це дозволяє створити завдання протягом 200 секунд після фактичного часу.

Політика паралелізму

Також необовʼязкове поле .spec.concurrencyPolicy. Воно визначає, як обробляти паралельні виконання завдання, яке створюється цим CronJob. Специфікація може вказувати лише одну з наступних політик паралельності:

  • Allow (станадартно): CronJob дозволяє паралельні запуски завдань
  • Forbid: CronJob не дозволяє паралельні запуски; якщо настав час для нового запуску завдання і попередній запуск завдання ще не завершився, CronJob пропускає новий запуск завдання. Також слід зауважити, що коли попередній запуск завдання завершиться, враховується .spec.startingDeadlineSeconds і може призвести до нового запуску завдання.
  • Replace: Якщо час для нового запуску завдання і попередній запуск завдання ще не завершився, CronJob замінює поточний запуск завдання новим запуском завдання.

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

Призупинення розкладу

Ви можете призупинити виконання завдань для CronJob, встановивши необовʼязкове поле .spec.suspend в значення true. Стандартно поле має значення false.

Це налаштування не впливає на завдання, які CronJob вже розпочав.

Якщо ви встановите це поле в значення true, всі наступні виконання будуть призупинені (вони залишаються запланованими, але контролер CronJob не запускає завдання для виконання завдань), поки ви не призупините CronJob.

Обмеження історії завдань

Поля .spec.successfulJobsHistoryLimit та .spec.failedJobsHistoryLimit вказують, скільки завершених успішних та невдалих завдань потрібно зберігати. Обидва поля є необовʼязковими.

  • .spec.successfulJobsHistoryLimit: Це поле вказує кількість успішно завершених завдань, які слід зберігати. Стандартне значення — 3. Встановлення цього поля на 0 не буде зберігати жодних успішних завдань.

  • .spec.failedJobsHistoryLimit: Це поле вказує кількість невдало завершених завдань, які слід зберігати. Стандартне значення — 1. Встановлення цього поля на 0 не буде зберігати жодних невдало завершених завдань.

Для іншого способу автоматичного прибирання завершених Завдань, дивіться Автоматичне прибирання завершених завдань.

Часові пояси

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

Для CronJob без вказаного часового поясу kube-controller-manager інтерпретує розклад відносно свого локального часового поясу.

Ви можете вказати часовий пояс для CronJob, встановивши .spec.timeZone на назву дійсного часового поясу. Наприклад, встановлення .spec.timeZone: "Etc/UTC" вказує Kubernetes інтерпретувати графік відносно Координованого універсального часу.

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

Обмеження CronJob

Непідтримувані специфікації часових поясів

Зазначення часового поясу за допомогою змінних CRON_TZ або TZ всередині .spec.schedule офіційно не підтримується (і ніколи не підтримувалася).

Починаючи з Kubernetes 1.29, якщо ви намагаєтеся встановити розклад, який включає вказівку часового поясу TZ або CRON_TZ, Kubernetes не зможе створити ресурс і сповістить про помилку. Оновлення CronJobs, які вже використовують TZ або CRON_TZ, продовжать повідомляти клієнта про попередження.

Зміна параметрів CronJob

За концепцією, у CronJob є шаблоном для нових Jobs. Якщо ви модифікуєте наявний CronJob, зміни застосовуватимуться до нових Job, які почнуть виконуватися після завершення вашої модифікації. Job (і їх Podʼи), які вже почали виконуватися, продовжують працювати без змін. Іншими словами, CronJob не оновлює поточні Job, навіть якщо вони ще продовжують виконуватися.

Створення Job

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

Для кожного CronJob контролер CronJob Контролер перевіряє, скільки розкладів він пропустив протягом часу від його останнього запланованого часу до теперішнього часу. Якщо пропущено понад 100 розкладів, то Job не запускається, і виводиться помилка в лог.

Cannot determine if job needs to be started. Too many missed start time (> 100). Set or decrease .spec.startingDeadlineSeconds or check clock skew.

Важливо відзначити, що якщо поле startingDeadlineSeconds встановлено (не є nil), контролер враховує, скільки пропущених Job сталося від значення startingDeadlineSeconds до теперішнього часу, а не від останнього запланованого часу до теперішнього часу. Наприклад, якщо startingDeadlineSeconds дорівнює 200, контролер враховує, скільки Job було пропущено за останні 200 секунд.

CronJob вважається пропущеним, якщо не вдалося створити Job в запланований час. Наприклад, якщо concurrencyPolicy встановлено на Forbid і CronJob було спробовано запланувати, коли попередній Job все ще працював, то це буде враховуватися як пропущено.

Наприклад, припустимо, що CronJob встановлено для запуску нового Job кожну хвилину, починаючи з 08:30:00, і його поле startingDeadlineSeconds не встановлено. Якщо контролер CronJob випадково був вимкнений з 08:29:00 по 10:21:00, Job не буде запущено, оскільки кількість пропущених Jobs, які пропустили свій розклад, понад 100.

Для того, щоб краще проілюструвати цей концепт, припустимо, що CronJob встановлено для запуску нового Job кожну хвилину, починаючи з 08:30:00, і його поле startingDeadlineSeconds встановлено на 200 секунд. Якщо контролер CronJob випадково був вимкнений протягом того ж періоду, що й у попередньому прикладі (08:29:00 до 10:21:00) Job все одно запуститься о 10:22:00. Це трапляється тому, що тепер контролер перевіряє, скільки пропущених розкладів сталося за останні 200 секунд (тобто 3 пропущені розклади), а не від останнього запланованого часу до теперішнього часу.

CronJob відповідає лише за створення Job, які відповідають його розкладу, а Job, зs свого боку, відповідає за управління Podʼами, які він представляє.

Що далі

  • Дізнайтесь про Podʼи та Job, два поняття, які використовуються в CronJobs.
  • Дізнайтеся більше про формат поля .spec.schedule в CronJob.
  • Щодо інструкцій зі створення та роботи з CronJobs, а також для прикладу маніфесту CronJob, дивіться Виконання автоматизованих завдань за допомогою CronJobs.
  • CronJob є частиною Kubernetes REST API. Читайте CronJob API посилання для отримання докладних деталей.

3.4.2.8 - ReplicationController

Застаріле API для управління навантаженням, яке може горизонтально масштабуватися. Замінено API Deployment та ReplicaSet.

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

Як працює ReplicationController

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

ReplicationController часто скорочується до "rc" в обговореннях та як скорочення в командах kubectl.

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

Запуск прикладу ReplicationController

Цей приклад конфігурації ReplicationController запускає три копії вебсервера nginx.

kubectl apply -f https://k8s.io/examples/controllers/replication.yaml

Вивід подібний до такого:

replicationcontroller/nginx created

Перевірте стан ReplicationController за допомогою цієї команди:

kubectl describe replicationcontrollers/nginx

Вивід подібний до такого:

Name:        nginx
Namespace:   default
Selector:    app=nginx
Labels:      app=nginx
Annotations:    <none>
Replicas:    3 current / 3 desired
Pods Status: 0 Running / 3 Waiting / 0 Succeeded / 0 Failed
Pod Template:
  Labels:       app=nginx
  Containers:
   nginx:
    Image:              nginx
    Port:               80/TCP
    Environment:        <none>
    Mounts:             <none>
  Volumes:              <none>
Events:
  FirstSeen       LastSeen     Count    From                        SubobjectPath    Type      Reason              Message
  ---------       --------     -----    ----                        -------------    ----      ------              -------
  20s             20s          1        {replication-controller }                    Normal    SuccessfulCreate    Created pod: nginx-qrm3m
  20s             20s          1        {replication-controller }                    Normal    SuccessfulCreate    Created pod: nginx-3ntk0
  20s             20s          1        {replication-controller }                    Normal    SuccessfulCreate    Created pod: nginx-4ok8v

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

Pods Status:    3 Running / 0 Waiting / 0 Succeeded / 0 Failed

Щоб перелічити всі Podʼи, які належать ReplicationController у формі, придатній для машинного читання, можна використовувати команду на зразок:

pods=$(kubectl get pods --selector=app=nginx --output=jsonpath={.items..metadata.name})
echo $pods

Вивід подібний до такого:

nginx-3ntk0 nginx-4ok8v nginx-qrm3m

Тут селектор такий самий, як і селектор для ReplicationController (бачимо у виводі kubectl describe), і в іншій формі у replication.yaml. Опція --output=jsonpath вказує вираз з іменем кожного Podʼа в отриманому списку.

Створення маніфесту ReplicationController

Як і з усіма іншими конфігураціями Kubernetes, для ReplicationController потрібні поля apiVersion, kind і metadata.

Коли панель управління створює нові Podʼи для ReplicationController, .metadata.name ReplicationController є частиною основи для найменування цих Podʼів. Назва ReplicationController повинна бути дійсним значенням DNS-піддомену, але це може призводити до неочікуваних результатів для імен хостів Podʼів. Для забезпечення найкращої сумісності імʼя повинно відповідати більш обмеженим правилам для DNS-мітки.

Для загальної інформації про роботу з файлами конфігурації дивіться управління обʼєктами.

ReplicationController також потребує розділу .spec.

Шаблон Pod

.spec.template — єдине обовʼязкове поле в розділі .spec.

.spec.template — це шаблон pod. Він має точно таку ж схему, як і Pod, за винятком того, що він вкладений і не має apiVersion або kind.

Окрім обовʼязкових полів для Pod, шаблон pod в ReplicationController повинен вказати відповідні мітки та відповідну політику перезапуску. Щодо міток, переконайтеся, що вони не перекриваються з іншими контролерами. Див. селектор pod.

Дозволяється лише .spec.template.spec.restartPolicy, рівна Always, якщо не вказано інше, що є стандартним значенням.

Для локальних перезапусків контейнерів ReplicationControllers делегують агентові на вузлі, наприклад, Kubelet.

Мітки на ReplicationController

ReplicationController може мати власні мітки (.metadata.labels). Зазвичай ви встановлюєте їх так само, як і .spec.template.metadata.labels; якщо .metadata.labels не вказано, то вони cnfylfhnyj встановлюються як .spec.template.metadata.labels. Однак вони можуть бути різними, і .metadata.labels не впливають на поведінку ReplicationController.

Селектор Pod

Поле .spec.selector є селектором міток. ReplicationController керує всіма Podʼами з мітками, які відповідають селектору. Він не робить різниці між Podʼами, які він створив чи видалив, і Podʼами, які створив чи видалив інший процес чи особа. Це дозволяє замінити ReplicationController без впливу на робочі Podʼи.

Якщо вказано, то .spec.template.metadata.labels повинні бути рівні .spec.selector, або вони буде відхилені API. Якщо .spec.selector не вказано, він буде встановлений типово як .spec.template.metadata.labels.

Також, як правило, ви не повинні створювати жодних Podʼів, мітки яких відповідають цьому селектору, безпосередньо, з іншим ReplicationController або з іншим контролером, таким як Job. Якщо ви це зробите, то ReplicationController вважатиме, що він створив інші Podʼами. Kubernetes не забороняє вам це робити.

Якщо у вас все-таки виникає кілька контролерів з однаковими селекторами, вам доведеться керувати видаленням самостійно (див. нижче).

Декілька Реплік

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

Якщо ви не вказали .spec.replicas, то типово встановлюється 1.

Робота з ReplicationControllers

Видалення ReplicationController та його Podʼів

Щоб видалити ReplicationController та всі його Podʼи, використовуйте команду kubectl delete. Kubectl масштабує ReplicationController до нуля і чекає, доки кожний Pod буде видалено, перед видаленням самого ReplicationController. Якщо цю команду kubectl перервати, її можна перезапустити.

При використанні REST API або бібліотеки клієнта, вам потрібно виконати кроки явно (масштабування реплік до 0, очікування видалення Podʼів, а потім видалення самого ReplicationController).

Видалення лише ReplicationController

Ви можете видалити ReplicationController, не впливаючи на його Podʼи.

При використанні kubectl вкажіть опцію --cascade=orphan команді kubectl delete.

При використанні REST API або бібліотеки клієнта ви можете видалити обʼєкт ReplicationController.

Після видалення оригіналу ви можете створити новий ReplicationController, щоб замінити його. Поки старий та новий .spec.selector однакові, то новий прийме старі Podʼи. Однак він не буде вживати жодних зусиль, щоб наявні Podʼи відповідали новому, відмінному від оригінального, шаблону Podʼа. Щоб оновити Podʼи за новою специфікацією у керований спосіб, використовуйте кероване оновлення.

Ізолювання Podʼів від ReplicationController

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

Загальні патерни використання

Перепланування

Як було зазначено вище, чи у вас є 1 Pod, який вам потрібно тримати в роботі, чи 1000, ReplicationController гарантує, що зазначена кількість Podʼів існує, навіть у випадку відмови вузла або завершення Podʼа (наприклад, через дію іншого агента управління).

Масштабування

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

Поступові оновлення

ReplicationController призначений для полегшення поступового оновлення служби за допомогою заміни Podʼів один за одним.

Як пояснено в #1353, рекомендований підхід — створити новий ReplicationController з 1 реплікою, масштабувати нові (+1) та старі (-1) контролери по одному, а потім видалити старий контролер після досягнення 0 реплік. Це передбачувано оновлює набір Podʼів незалежно від неочікуваних відмов.

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

Два ReplicationController повинні створювати Podʼи із принаймні однією відмінною міткою, такою як теґ образу основного контейнера Podʼа, оскільки це зазвичай оновлення образу, що мотивує поступові оновлення.

Кілька треків випуску

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

Наприклад, служба може охоплювати всі Podʼи з tier in (frontend), environment in (prod). Тепер скажімо, у вас є 10 реплікованих Podʼів, які складають цей рівень. Але ви хочете мати можливість 'канаркову' нову версію цього компонента. Ви можете налаштувати ReplicationController із replicas, встановленим на 9 для більшості реплік, з мітками tier=frontend, environment=prod, track=stable, та інший ReplicationController із replicas, встановленим на 1 для канарки, з мітками tier=frontend, environment=prod, track=canary. Тепер служба охоплює як канаркові, так і не канаркові Podʼи. Але ви можете окремо взаємодіяти з ReplicationControllers, щоб тестувати речі, відстежувати результати і т.д.

Використання ReplicationControllers з Service

Декілька ReplicationControllers можуть бути розміщені поза одним Service, так що, наприклад, частина трафіку іде до старої версії, а частина до нової.

ReplicationController ніколи не завершиться самостійно, але не очікується, що він буде таким тривалим, як Service. Service можуть складатися з Podʼів, які контролюються кількома ReplicationControllers, і передбачається, що протягом життя Service (наприклад, для виконання оновлення Podʼів, які виконують Service) буде створено і знищено багато ReplicationControllers. Як самі Service, так і їх клієнти повинні залишатися осторонь від ReplicationControllers, які утримують Podʼи Service.

Написання програм для Replication

Створені ReplicationController'ом Podʼи призначені бути взаємозамінними та семантично ідентичними, хоча їх конфігурації можуть ставати різноманітними з часом. Це очевидний вибір для реплікованих stateless серверів, але ReplicationControllers також можна використовувати для забезпечення доступності застосунків, які вибирають майстра, або мають розподілені, або пул робочих задач. Такі застосунки повинні використовувати механізми динамічного призначення роботи, такі як черги роботи RabbitMQ, на відміну від статичної / одноразової настроюваної конфігурації кожного Podʼа, що вважається анти-патерном. Будь-яке настроювання Podʼа, таке як вертикальне автоматичне масштабування ресурсів (наприклад, процесора чи памʼяті), повинно виконуватися іншим процесом контролю в режимі реального часу, подібним до самого ReplicationController.

Обовʼязки ReplicationController

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

ReplicationController завжди обмежується цією вузькою відповідальністю. Він самостійно не буде виконувати перевірки готовності або тестів на життєздатність. Замість автоматичного масштабування він призначений для управління зовнішнім автомасштабувальником (як обговорюється в #492), який буде змінювати його поле replicas. Ми не будемо додавати політик планування (наприклад, розподілення) до ReplicationController. Він також не повинен перевіряти, чи відповідають контрольовані Podʼи поточному зазначеному шаблону, оскільки це може заважати автоматичному зміщенню розміру та іншим автоматизованим процесам. Також термінові строки виконання, залежності від порядку, розширення конфігурації та інші функції належать іншим місцям. Навіть планується виділити механізм масового створення Podʼів (#170).

ReplicationController призначений бути базовим примітивом для побудови композиційних структур. Ми очікуємо, що на його основі та інших взаємодіючих примітивів у майбутньому буде побудовано високорівневі API та / або інструменти для зручності користувачів. "Макро" операції, які наразі підтримуються kubectl (run, scale), є прикладами концепції. Наприклад, можемо уявити щось на зразок Asgard, що управляє ReplicationControllers, автомасштабувальниками, сервісами, політиками планування, канарковими розгортаннями та іншими аспектами.

Обʼєкт API

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

Альтернативи ReplicationController

ReplicaSet

ReplicaSet — це ReplicationController нового покоління, який підтримує нові вимоги щодо вибору міток на основі множин. Він використовується головним чином Deployment як механізм для оркестрування створення, видалення та оновлення Podʼів. Зауважте, що ми рекомендуємо використовувати Deployments замість безпосереднього використання Replica Sets, якщо вам потрібна власне оркестрування оновлення або взагалі не потрібні оновлення.

Deployment — це обʼєкт API вищого рівня, який оновлює свої базові Replica Sets та їхні Podʼи. Deployments рекомендуються, якщо вам потрібна функціональність плавного оновлення, оскільки вони є декларативними, виконуються на сервері та мають додаткові функції.

Тільки Podʼи

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

Job

Використовуйте Job замість ReplicationController для Podʼів, які мають завершуватись самі по собі (іншими словами, пакетні завдання).

DaemonSet

Використовуйте DaemonSet замість ReplicationController для Podʼів, які забезпечують функцію рівня машини, таку як моніторинг машини або ведення логу машини. Ці Podʼи мають термін служби, який повʼязаний із терміном служби машини: Pod повинty працювати на машині перед тим, як інші Podʼи почнуть працювати, і може бути безпечно завершений, коли машина готова до перезавантаження або вимкнення.

Що далі

  • Більше про Podʼи.
  • Дізнайтеся більше про Deployment, альтернативу ReplicationController.
  • ReplicationController — це частина Kubernetes REST API. Ознайомтесь з визначенням обʼєкта ReplicationController, щоб зрозуміти API для контролерів реплікації.

3.4.3 - Автомасштабування робочих навантажень

З автомасштабуванням ви можете автоматично оновлювати ваші робочі навантаження різними способами. Це дозволяє вашому кластеру еластичніше та ефективніше реагувати на зміни витрат ресурсів.

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

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

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

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

Ручне масштабування робочих навантажень

Kubernetes підтримує ручне масштабування робочих навантажень. Горизонтальне масштабування можна виконати за допомогою інтерфейсу командного рядка kubectl. Для вертикального масштабування вам потрібно змінити визначення ресурсів вашого робочого навантаження.

Дивіться нижче приклади обох стратегій.

Автоматичне масштабування робочих навантажень

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

Концепція Автомасштабування в Kubernetes стосується можливості автоматичного оновлення обʼєкта, який керує набором Podʼів (наприклад, Deployment).

Горизонтальне масштабування робочих навантажень

У Kubernetes ви можете автоматично масштабувати робоче навантаження горизонтально за допомогою HorizontalPodAutoscaler (HPA).

Він реалізований як ресурс Kubernetes API та controller і періодично налаштовує кількість реплік в робочому навантаженні, щоб відповідати спостереженню за використанням ресурсів, такими як використання CPU чи памʼяті.

Є посібник з інструкціями з налаштування HorizontalPodAutoscaler для Deployment.

Вертикальне масштабування робочих навантажень

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

Ви можете автоматично масштабувати робоче навантаження вертикально за допомогою VerticalPodAutoscaler (VPA). На відміну від HPA, VPA не поставляється стандартно в Kubernetes, але є окремим проєктом, який можна знайти на GitHub.

Після встановлення він дозволяє створювати CustomResourceDefinitions (CRDs) для ваших робочих навантажень, які визначають як і коли масштабувати ресурси керованих реплік.

На цей час VPA може працювати в чотирьох різних режимах:

Різні режими VPA
РежимОпис
AutoНаразі Recreate, може змінитися на оновлення на місці у майбутньому
RecreateVPA встановлює ресурсні запити при створенні підпорядкованих контейнерів і оновлює їх на наявних контейнерах, витісняючи їх, коли запитані ресурси відрізняються від нової рекомендації
InitialVPA встановлює ресурсні запити лише при створенні підпорядкованих контейнерів і ніколи не змінює їх пізніше.
OffVPA автоматично не змінює вимоги до ресурсів підпорядкованих контейнерів. Рекомендації обчислюються і можуть бути перевірені в обʼєкті VPA.

Вимоги для масштабування на місці

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

Масштабування робочого навантаження на місці без перезапуску підпорядкованих контейнерів чи їх контейнерів вимагає версії Kubernetes 1.27 чи пізніше. Додатково потрібно ввімкнути властивість InPlaceVerticalScaling.

InPlacePodVerticalScaling: Дозволяє вертикальне масштабування Podʼів на місці.

Автомасштабування на основі розміру кластера

Для робочих навантажень, які потрібно масштабувати залежно від розміру кластера (наприклад, cluster-dns чи інші системні компоненти), ви можете використовувати Cluster Proportional Autoscaler. Так само як і VPA, він не є частиною основного функціонала Kubernetes, але розміщений як окремий проєкт на GitHub.

Cluster Proportional Autoscaler відстежує кількість вузлів які готові приймати Podʼи та ядра та масштабує кількість реплік цільового робочого навантаження відповідно.

Якщо кількість реплік має залишитися незмінною, ви можете масштабувати свої робочі навантаження вертикально залежно від розміру кластера, використовуючи Cluster Proportional Vertical Autoscaler. Проєкт знаходиться наразі у бета-версії та доступний на GitHub.

В той час як Cluster Proportional Autoscaler масштабує кількість реплік робочого навантаження, Cluster Proportional Vertical Autoscaler налаштовує вимоги до ресурсів для робочого навантаження (наприклад, Deployment або DaemonSet) залежно від кількості вузлів та/або ядер у кластері.

Автомасштабування, на підставі подій

Також існує можливість масштабування робочих навантажень на основі подій, наприклад, використовуючи Kubernetes Event Driven Autoscaler (KEDA).

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

Автомасштабування на основі розкладу

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

Схоже на автомасштабування, спровоковане подіями, таку поведінку можна досягти за допомогою KEDA спільно з його Cron scaler. Scaler Cron дозволяє вам визначати розклади (і часові пояси) для масштабування ваших робочих навантажень вгору чи вниз.

Масштабування інфраструктури кластера

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

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

Що далі

3.4.4 - Управління робочими навантаженнями

Ви розгорнули ваш застосунок та експонували його через Service. Що далі? Kubernetes надає ряд інструментів для допомоги в управлінні розгортанням вашого застосунку, включаючи масштабування та оновлення.

Організація конфігурацій ресурсів

Багато застосунків потребують створення кількох ресурсів, таких як Deployment разом із Service. Управління кількома ресурсами можна спростити, обʼєднавши їх в одному файлі (розділеному --- у YAML). Наприклад:

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

Кілька ресурсів можна створити так само як і один ресурс:

kubectl apply -f https://k8s.io/examples/application/nginx-app.yaml
service/my-nginx-svc created
deployment.apps/my-nginx created

Ресурси будуть створені в порядку, в якому вони зʼявляються в маніфесті. Тому краще спочатку вказати Service, оскільки це забезпечить, що планувальник зможе розподілити повʼязані з Service podʼи в процесі їх створення контролером(ами), таким як Deployment.

kubectl apply також приймає кілька аргументів -f:

kubectl apply -f https://k8s.io/examples/application/nginx/nginx-svc.yaml \
  -f https://k8s.io/examples/application/nginx/nginx-deployment.yaml

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

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

kubectl apply -f https://k8s.io/examples/application/nginx/nginx-deployment.yaml
deployment.apps/my-nginx created

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

Зовнішні інструменти

У цьому розділі перераховані лише найпоширеніші інструменти, які використовуються для керування навантаженнями в Kubernetes. Щоб переглянути більше інструментів, подивіться Application definition and image build в CNCF Landscape.

Helm

Helm — це інструмент для управління пакетами попередньо налаштованих ресурсів Kubernetes. Ці пакети відомі як Helm чарти.

Kustomize

Kustomize проходить по маніфестах Kubernetes, щоб додати, видалити або оновити конфігураційні опції. Він доступний як окремий бінарний файл і як вбудована функція kubectl.

Пакетні операції в kubectl

Створення ресурсів — не єдина операція, яку kubectl може виконувати в пакетному режимі. Він також може витягувати імена ресурсів з конфігураційних файлів для виконання інших операцій, зокрема для видалення тих же ресурсів, які ви створили:

kubectl delete -f https://k8s.io/examples/application/nginx-app.yaml
deployment.apps "my-nginx" deleted
service "my-nginx-svc" deleted

У випадку з двома ресурсами ви можете вказати обидва ресурси в командному рядку, використовуючи синтаксис resource/name:

kubectl delete deployments/my-nginx services/my-nginx-svc

Для більшої кількості ресурсів буде зручніше вказати селектор (запит на мітку), використовуючи -l або --selector, щоб відфільтрувати ресурси за їхніми мітками:

kubectl delete deployment,services -l app=nginx
deployment.apps "my-nginx" deleted
service "my-nginx-svc" deleted

Ланцюги та фільтрація

Оскільки kubectl виводить імена ресурсів у тому ж синтаксисі, який він приймає, ви можете робити ланцюги операції, використовуючи $() або xargs:

kubectl get $(kubectl create -f docs/concepts/cluster-administration/nginx/ -o name | grep service/ )
kubectl create -f docs/concepts/cluster-administration/nginx/ -o name | grep service/ | xargs -i kubectl get '{}'

Вивід може бути подібний до:

NAME           TYPE           CLUSTER-IP   EXTERNAL-IP   PORT(S)      AGE
my-nginx-svc   LoadBalancer   10.0.0.208   <pending>     80/TCP       0s

Використовуючи вище наведенні команди, спочатку ви створюєте ресурси в examples/application/nginx/ і виводите створені ресурси у форматі виводу -o name (виводите кожен ресурс як resource/name). Потім ви виконуєте grep для вибору Service, а потім виводите його за допомогою kubectl get.

Рекурсивні операції з локальними файлами

Якщо ви організували ваші ресурси в кількох підтеках всередині певної теки, ви можете рекурсивно виконувати операції з ними, вказавши --recursive або -R разом з аргументом --filename/-f.

Наприклад, припустимо, є тека project/k8s/development, яка містить усі маніфести необхідні для середовища розробки, організовані за типом ресурсу:

project/k8s/development
├── configmap
│   └── my-configmap.yaml
├── deployment
│   └── my-deployment.yaml
└── pvc
    └── my-pvc.yaml

Стандартно, виконання пакетної операції для project/k8s/development зупиниться на першому рівні теки, не обробляючи жодних вкладених тек. Якщо ви спробували б створити ресурси з цієї теки, використовуючи наступну команду, ви б отримали помилку:

kubectl apply -f project/k8s/development
error: you must provide one or more resources by argument or filename (.json|.yaml|.yml|stdin)

Замість цього, вкажіть аргумент командного рядка --recursive або -R разом з аргументом --filename/-f:

kubectl apply -f project/k8s/development --recursive
configmap/my-config created
deployment.apps/my-deployment created
persistentvolumeclaim/my-pvc created

Аргумент --recursive працює з будь-якою операцією, яка приймає аргумент --filename/-f, такою як: kubectl create, kubectl get, kubectl delete, kubectl describe, або навіть kubectl rollout.

Аргумент --recursive також працює, коли вказані кілька аргументів -f:

kubectl apply -f project/k8s/namespaces -f project/k8s/development --recursive
namespace/development created
namespace/staging created
configmap/my-config created
deployment.apps/my-deployment created
persistentvolumeclaim/my-pvc created

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

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

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

Ви можете запускати кілька копій вашого застосунку і використовувати rollout для поступового перенаправлення трафіку до нових справних Podʼів. З часом всі запущені Podʼи отримають нове програмне забезпечення.

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

Припустимо, ви запускали версію 1.14.2 nginx:

kubectl create deployment my-nginx --image=nginx:1.14.2
deployment.apps/my-nginx created

Переконайтеся, що є 1 репліка:

kubectl scale --replicas 1 deployments/my-nginx --subresource='scale' --type='merge' -p '{"spec":{"replicas": 1}}'
deployment.apps/my-nginx scaled

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

kubectl patch --type='merge' -p '{"spec":{"strategy":{"rollingUpdate":{"maxSurge": "100%" }}}}'
deployment.apps/my-nginx patched

Щоб оновитись до версії 1.16.1, змініть .spec.template.spec.containers[0].image з nginx:1.14.2 на nginx:1.16.1, використовуючи kubectl edit:

kubectl edit deployment/my-nginx
# Змініть маніфест на використання новішого образу контейнера, потім збережіть зміни

Ось і все! Deployment оновить розгорнутий застосунок з nginx прогресивно за лаштунками. Він забезпечує, що лише певна кількість старих реплік може бути недоступною під час оновлення, і лише певна кількість нових реплік може бути створена понад бажану кількість podʼів. Щоб дізнатися більше деталей про те, як це відбувається, відвідайте Deployment.

Ви можете використовувати rollouts з DaemonSets, Deployments або StatefulSets.

Управління Rollouts

Ви можете використовувати kubectl rollout для управління прогресивним оновленням поточного застосунку.

Наприклад:

kubectl apply -f my-deployment.yaml

# дочекайтеся завершення rollout
kubectl rollout status deployment/my-deployment --timeout 10m # тайм-аут 10 хвилин

або

kubectl apply -f backing-stateful-component.yaml

# не чекайте завершення rollout, просто перевірте статус
kubectl rollout status statefulsets/backing-stateful-component --watch=false

Ви також можете призупиняти, відновлювати або скасовувати rollout. Відвідайте kubectl rollout для отримання додаткової інформації.

Canary Deployment

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

Наприклад, можна використовувати мітку track для розрізнення різних версій.

Основна, стабільна версія буде мати мітку track зі значенням stable:

name: frontend
replicas: 3
...
labels:
   app: guestbook
   tier: frontend
   track: stable
...
image: gb-frontend:v3

А потім ви можете створити нову версію фронтенду для guestbook, яка має мітку track з іншим значенням (тобто canary), так що два набори podʼів не перетинатимуться:

name: frontend-canary
replicas: 1
...
labels:
   app: guestbook
   tier: frontend
   track: canary
...
image: gb-frontend:v4

Сервіс фронтенду охоплюватиме обидва набори реплік, вибираючи загальну підмножину їх міток (тобто пропускаючи мітку track), так що трафік буде перенаправлено на обидва застосунки:

selector:
   app: guestbook
   tier: frontend

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

Оновлення анотацій

Іноді ви захочете додати анотації до ресурсів. Анотації є довільними метаданими, що не є ідентифікаційними, для отримання API клієнтами, такими як інструменти або бібліотеки. Це можна зробити за допомогою kubectl annotate. Наприклад:

kubectl annotate pods my-nginx-v4-9gw19 description='my frontend running nginx'
kubectl get pods my-nginx-v4-9gw19 -o yaml
apiVersion: v1
kind: pod
metadata:
  annotations:
    description: my frontend running nginx
...

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

Масштабування вашого застосунку

Коли навантаження на ваш застосунок зростає або зменшується, використовуйте kubectl, щоб масштабувати ваш застосунок. Наприклад, щоб зменшити кількість реплік nginx з 3 до 1, виконайте:

kubectl scale deployment/my-nginx --replicas=1
deployment.apps/my-nginx scaled

Тепер у вас буде тільки один pod, яким управляє deployment.

kubectl get pods -l app=nginx
NAME                        READY     STATUS    RESTARTS   AGE
my-nginx-2035384211-j5fhi   1/1       Running   0          30m

Щоб система автоматично вибирала кількість реплік nginx в межах від 1 до 3, виконайте:

# Це вимагає існуючого джерела метрик контейнера і Pod
kubectl autoscale deployment/my-nginx --min=1 --max=3
horizontalpodautoscaler.autoscaling/my-nginx autoscaled

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

Для отримання додаткової інформації перегляньте kubectl scale, kubectl autoscale і horizontal pod autoscaler.

Оновлення ресурсів на місці

Іноді необхідно вносити вузькі оновлення до ресурсів які ви створили, не порушуючи роботи.

kubectl apply

Рекомендується підтримувати набір конфігураційних файлів у системі контролю версій (див. конфігурація як код), щоб їх можна було підтримувати та версіонувати разом з кодом для ресурсів, які вони конфігурують. Тоді ви можете використовувати kubectl apply для того, щоб надіслати зміни конфігурації в кластер.

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

kubectl apply -f https://k8s.io/examples/application/nginx/nginx-deployment.yaml
deployment.apps/my-nginx configured

Щоб дізнатися більше про механізм, що лежить в основі, прочитайте server-side apply.

kubectl edit

Альтернативно, ви також можете оновлювати ресурси за допомогою kubectl edit:

kubectl edit deployment/my-nginx

Це еквівалентно спочатку отриманню get ресурсу, редагуванню його в текстовому редакторі, а потім apply ресурсу з оновленою версією:

kubectl get deployment my-nginx -o yaml > /tmp/nginx.yaml
vi /tmp/nginx.yaml
# зробіть деякі редагування, а потім збережіть файл

kubectl apply -f /tmp/nginx.yaml
deployment.apps/my-nginx configured

rm /tmp/nginx.yaml

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

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

kubectl patch

Ви можете використовувати kubectl patch для оновлення API обʼєктів на місці. Ця підкоманда підтримує JSON patch, JSON merge patch і стратегічний merge patch.

Дивіться Оновлення API обʼєктів на місці за допомогою kubectl patch для отримання додаткових деталей.

Оновлення, що порушують стабільність

В деяких випадках може знадобитися оновити поля ресурсу, які не можна оновити після його ініціалізації, або може знадобитися зробити рекурсивну зміну негайно, наприклад, щоб виправити пошкоджені podʼи, створені Deployment. Для зміни таких полів використовуйте replace --force, що видаляє і перезапускає ресурс. У цьому випадку ви можете змінити ваш оригінальний конфігураційний файл:

kubectl replace -f https://k8s.io/examples/application/nginx/nginx-deployment.yaml --force
deployment.apps/my-nginx deleted
deployment.apps/my-nginx replaced

Що далі

3.5 - Service, балансування навантаження та мережа

Концепції та ресурси, що лежать в основі роботи в мережі в Kubernetes.

Мережева модель Kubernetes

Мережева модель Kubernetes складається з кількох частин:

  • Кожен pod у кластері отримує власну унікальну кластерну IP-адресу.

    • Pod має власний приватний мережевий простір імен, який спільно використовують всі контейнери всередині podʼа. Процеси, що працюють у різних контейнерах в одному podʼі, можуть спілкуватися між собою через localhost.
  • Мережа podʼів (також називається кластерною мережею) керує комунікацією між podʼами. Вона забезпечує, що (за відсутності навмисної сегментації мережі):

Модель мережі Kubernetes складається з кількох компонентів:

  • Кожен pod у кластері отримує свою унікальну кластерну IP-адресу.

    • Pod має власний приватний мережевий простір імен, який спільно використовують усі контейнери в pod. Процеси, що працюють у різних контейнерах в одному pod, можуть спілкуватися між собою через localhost.
  • Мережа pod (також називається кластерною мережею) керує комунікацією між podʼами. Вона забезпечує, що (за відсутності навмисної сегментації мережі):

    • Усі podʼи можуть спілкуватися з усіма іншими podʼами, незалежно від того, чи знаходяться вони на одному вузлі, чи на різних. Podʼи можуть спілкуватися безпосередньо, без використання проксі-серверів чи трансляції адрес (NAT).

      У Windows це правило не застосовується до podʼів з мережею вузла.

    • Агенти на вузлі (такі як системні демони чи kubelet) можуть спілкуватися з усіма podʼами на цьому вузлі.

  • API Service дозволяє надати стабільну (довготривалу) IP-адресу або імʼя хосту для сервісу, реалізованого одним або кількома podʼами, при цьому окремі podʼи, що складають сервіс, можуть змінюватися з часом.

    • Kubernetes автоматично керує обʼєктами EndpointSlice, які надають інформацію про podʼи, що підтримують сервіс.

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

  • API Gateway (або його попередник Ingress) дозволяє зробити сервіси доступними для клієнтів поза кластером.

  • NetworkPolicy — це вбудований API Kubernetes, який дозволяє контролювати трафік між podʼами або між podʼами та зовнішнім світом.

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

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

  • Налаштування простору імен мережі pod виконується системним програмним забезпеченням, яке реалізує Container Runtime Interface.

  • Мережею pod керує реалізація мережі pod. На Linux більшість середовищ виконання контейнерів використовують Container Networking Interface (CNI), щоб взаємодіяти з реалізацією мережі pod, тому ці реалізації часто називаються _CNI втулками.

  • Kubernetes надає стандартну реалізацію для проксі сервісів, яка називається kube-proxy, але деякі реалізації мережі pod використовують власний сервісний проксі, який тісніше інтегрований з іншими компонентами.

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

  • Існує багато реалізацій Gateway API, деякі з яких специфічні для певних хмарних середовищ, інші більше орієнтовані на середовища "bare metal", а інші є більш універсальними.

Що далі

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

Стаття Мережа кластера пояснює, як налаштувати мережу для вашого кластера, а також надає огляд задіяних технологій.

3.5.1 - Service

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

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

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

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

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

Це призводить до проблеми: якщо певний набір Podʼів (назвемо їх "backend") надає функціонал іншим Podʼам (назвемо їх "frontend") всередині вашого кластера, як фронтенд дізнається та відстежує, яку IP-адресу підключати, щоб він міг використовувати частину робочого навантаження?

Познайомтесь з Service.

Service в Kubernetes

API Service, що є частиною Kubernetes, є абстракцією, яка допомагає вам давати групі Podʼів доступ в мережі. Кожен обʼєкт Service визначає логічний набір endpoint (зазвичай endpoint — Pod) разом із політикою того, як робити ці Podʼи доступними.

Наприклад, розгляньте stateless бекенд для обробки зображень, який працює з 3 репліками. Ці репліки замінюються одна одною — фронтендам не важливо, який бекенд вони використовують. Хоча конкретні Podʼи, що складають бекенд, можуть змінюватися, клієнти фронтенду не мають на це звертати уваги, і вони не повинні вести облік набору елементів бекендів самі.

Абстракція Service дозволяє таке відокремлення.

Набір Podʼів, яким призначається Service, зазвичай визначається селектором, який ви визначаєте. Щоб дізнатися про інші способи визначення endpointʼів сервісу, дивіться Сервіси без селекторів.

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

API Gateway для Kubernetes надає додаткові можливості, які виходять за межі Ingress і Service. Ви можете додати Gateway до вашого кластера — це родина розширених API, реалізованих за допомогою CustomResourceDefinitions — і потім використовувати їх для налаштування доступу до мережевих сервісів, що працюють у вашому кластері.

Хмарно-нативне виявлення сервісів

Якщо ви можете використовувати API Kubernetes для виявлення сервісів у вашому застосунку, ви можете звертатись до сервера API по відповідні EndpointSlices. Kubernetes оновлює EndpointSlices для сервісу кожного разу, коли набір Podʼів у сервісі змінюється.

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

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

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

Service — це обʼєкт (так само як Pod чи ConfigMap є обʼєктами). Ви можете створювати, переглядати або змінювати визначення Service, використовуючи API Kubernetes. Зазвичай для цього ви використовуєте інструмент, такий як kubectl, який звертається до API.

Наприклад, припустимо, у вас є набір Podʼів, які слухають TCP-порт 9376 і мають мітку app.kubernetes.io/name=MyApp. Ви можете визначити Сервіс, щоб опублікувати цього TCP-слухача:

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app.kubernetes.io/name: MyApp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376

Застосування цього маніфесту створює новий Сервіс з назвою "my-service" зі стандартним типом служби ClusterIP. Сервіс обслуговує TCP-порт 9376 на будь-якому Podʼі з міткою app.kubernetes.io/name: MyApp.

Kubernetes призначає цьому Сервісу IP-адресу (так званий кластерний IP), що використовується механізмом віртуалізації IP-адрес. Для отримання докладнішої інформації про цей механізм, читайте Віртуальні IP та Проксі-сервіси.

Контролер для цього Сервісу постійно сканує Podʼи, які відповідають його селектору, а потім вносить будь-які необхідні оновлення до набору EndpointSlices для Сервісу.

Назва обʼєкта Сервісу повинна бути дійсним іменем мітки за стандартом RFC 1035.

Визначення портів

Визначення портів в Podʼах мають назви, і ви можете посилатися на ці назви в атрибуті targetPort Сервісу. Наприклад, ми можемо привʼязати targetPort Сервісу до порту Podʼа таким чином:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    app.kubernetes.io/name: proxy
spec:
  containers:
  - name: nginx
    image: nginx:stable
    ports:
      - containerPort: 80
        name: http-web-svc

---
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app.kubernetes.io/name: proxy
  ports:
  - name: name-of-service-port
    protocol: TCP
    port: 80
    targetPort: http-web-svc

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

Станадртним протоколом для Service є TCP; ви також можете використовувати будь-який інший підтримуваний протокол.

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

Сервіси без селекторів

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

Наприклад:

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

У будь-якому з цих сценаріїв ви можете визначити Сервіс без вказівки селектора для відповідності Podʼам. Наприклад:

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  ports:
    - name: http
      protocol: TCP
      port: 80
      targetPort: 9376

Оскільки у цього Сервісу немає селектора, відповідні обʼєкти EndpointSlice (та застарілі Endpoints) не створюються автоматично. Ви можете повʼязувати Сервіс з мережевою адресою та портом, де він працює, додавши обʼєкт EndpointSlice вручну. Наприклад:

apiVersion: discovery.k8s.io/v1
kind: EndpointSlice
metadata:
  name: my-service-1 # за звичай, використовуйте назву Сервісу
                     # як префікс для назви EndpointSlice
  labels:
    # Ви повинні встановити мітку "kubernetes.io/service-name".
    # Встановіть її значення, щоб відповідати назві Сервісу
    kubernetes.io/service-name: my-service
addressType: IPv4
ports:
  - name: http # Має збігатись з іменем порту у визначенні Service 
               # визначеному вище
    appProtocol: http
    protocol: TCP
    port: 9376
endpoints:
  - addresses:
      - "10.4.5.6"
  - addresses:
      - "10.1.2.3"

Власні EndpointSlices

Коли ви створюєте обʼєкт EndpointSlice для Сервісу, ви можете використовувати будь-яку назву для EndpointSlice. Кожен EndpointSlice в просторі імен повинен мати унікальну назву. Ви поєднуєте EndpointSlice із Сервісом, встановлюючи label kubernetes.io/service-name на цьому EndpointSlice.

Для EndpointSlice, який ви створюєте самостійно або у своєму власному коді, вам також слід вибрати значення для мітки endpointslice.kubernetes.io/managed-by. Якщо ви створюєте свій власний код контролера для управління EndpointSlice, розгляньте можливість використання значення, схожого на "my-domain.example/name-of-controller". Якщо ви використовуєте інструмент від стороннього постачальника, використовуйте назву інструменту в нижньому регістрі та замініть пробіли та інші знаки пунктуації на дефіси (-). Якщо ви безпосередньо використовуєте інструмент, такий як kubectl, для управління EndpointSlice, використовуйте назву, яка описує це ручне управління, таку як "staff" або "cluster-admins". Ви повинні уникати використання захищеного значення "controller", яке ідентифікує EndpointSlices, які керуються власною панеллю управління Kubernetes.

Доступ до Сервісу без селектора

Доступ до Сервісу без селектора працює так само, якби він мав селектор. У прикладі Сервісу без селектора, трафік маршрутизується до одного з двох endpoint, визначених у маніфесті EndpointSlice: TCP-зʼєднання до 10.1.2.3 або 10.4.5.6, на порт 9376.

ExternalName Сервіс — це особливий випадок Сервісу, який не має селекторів і використовує DNS-імена замість них. Для отримання доклдадної інформації, див. розділ ExternalName.

EndpointSlices

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

EndpointSlices — це обʼєкти, які представляють підмножину (зріз) мережевих endpoint, які підтримують Сервіс.

Ваш кластер Kubernetes відстежує кількість endpointʼів, які представляє кожен EndpointSlice. Якщо для Сервісу є настільки багато endpointʼів, що досягається порогове значення, тоді Kubernetes додає ще один порожній EndpointSlice і зберігає там нову інформацію про endpoint. Типово Kubernetes створює новий EndpointSlice, як тільки наявні EndpointSlice всі містять принаймні 100 endpoint. Kubernetes не створює новий EndpointSlice, поки не буде потрібно додати додатковий endpoint.

Див. EndpointSlices для отримання додаткової інформації про цей API.

Endpoint

В API Kubernetes, Endpoints (тип ресурсу у множині) визначають список мережевих endpointʼів, зазвичай використовується Сервісом для визначення того, до яких Podʼів можна направляти трафік.

API EndpointSlice — це рекомендована заміна для Endpoints.

Endpoints з перевищеним обсягом

Kubernetes обмежує кількість endpointʼів, які можуть поміститися в один обʼєкт Endpoints. Коли є понад 1000 endpointʼів, які підтримують Сервіс, Kubernetes розмішує дані в обʼєкті Endpoints. Оскільки Сервіс може бути повʼязаним з більше ніж одним EndpointSlice, обмеження в 1000 endpointʼів впливає лише на застарілий API Endpoints.

У цьому випадку Kubernetes вибирає не більше 1000 можливих endpointʼів, які слід зберегти в обʼєкті Endpoints, і встановлює анотацію на Endpoints: endpoints.kubernetes.io/over-capacity: truncated. Панель управління також видаляє цю анотацію, якщо кількість бекенд-Podʼів впадає нижче 1000.

Трафік все ще відсилається на бекенди, але будь-який механізм балансування навантаження, який покладається на застарілий API Endpoints, відсилає трафік не більше, ніж до 1000 доступних бекенд-endpointʼів.

Той самий ліміт API означає, що ви не можете вручну оновлювати Endpoints так, щоб у них було понад 1000 endpointʼів.

Протокол застосунку

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

Поле appProtocol надає можливість вказати протокол застосунку для кожного порту Сервісу. Це використовується як підказка для реалізацій для надання розширеної поведінки для протоколів, які вони розуміють. Значення цього поля відображається відповідними обʼєктами Endpoints та EndpointSlice.

Це поле відповідає стандартному синтаксису міток Kubernetes. Дійсні значення — це одне з:

  • стандартні назви служб IANA.

  • Імплементаційно-визначені префіксовані імена, такі як mycompany.com/my-custom-protocol.

  • Імена з префіксом, визначені Kubernetes:

ПротоколОпис
kubernetes.io/h2cHTTP/2 поверх чіткого тексту, як описано в RFC 7540
kubernetes.io/wsWebSocket через текст, як описано у RFC 6455
kubernetes.io/wssWebSocket через TLS, як описано у RFC 6455

Сервіси з кількома портами

Для деяких Сервісів вам може знадобитися використовувати більше одного порту. Kubernetes дозволяє конфігурувати кілька визначень портів в обʼєкті Service. При використанні кількох портів для Сервісу, вам слід надавати всім портам імена, щоб вони були однозначними. Наприклад:

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app.kubernetes.io/name: MyApp
  ports:
    - name: http
      protocol: TCP
      port: 80
      targetPort: 9376
    - name: https
      protocol: TCP
      port: 443
      targetPort: 9377

Тип Сервісу

Для деяких частин вашого застосунку (наприклад, фронтенду) ви можете знадобитись звʼязати Сервіс з зовнішньою IP-адресою, доступну з-поза вашого кластера.

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

Доступні значення type та їхні поведінки:

ClusterIP
Повʼязує Сервіс з внутрішньою IP-адресою кластера. Вибір цього значення робить Сервіс доступним лише зсередини кластера. Це значення використовується стандартно, якщо ви не вказали явно type для Сервісу. Ви можете дати Сервісу доступ в Інтернет за допомогою Ingress або Gateway.
NodePort
Повʼязує Сервіс на кожному IP-адресі вузла зі статичним портом (NodePort). Щоб зробити порт вузла доступним, Kubernetes налаштовує IP-адресу кластера, так само якби ви запросили Сервіс з type: ClusterIP.
LoadBalancer
Повʼязує Сервіс із зовнішніми споживачами за допомогою зовнішнього балансувальника навантаження. Kubernetes не надає безпосередньо компонент балансування навантаження; вам слід надати його, або ви можете інтегрувати свій кластер Kubernetes з постачальником хмарних послуг.
ExternalName
Повʼязує Сервіс зі змістом поля externalName (наприклад, на імʼя хоста api.foo.bar.example). Це конфігурує сервер DNS вашого кластера повертати запис CNAME з вказаною зовнішньою назвою хосту. Ніякого проксінгу не налаштовується.

Поле type в API Сервісу розроблене як вкладена функціональність — кожен рівень додається до попереднього. Однак існує виняток з цього вкладеного дизайну. Ви можете визначити Сервіс LoadBalancer, відключивши використання порту вузла для балансування навантаження.

type: ClusterIP

Цей тип Сервісу типово призначає IP-адресу з пулу IP-адрес, який ваш кластер зарезервував для цієї мети.

Кілька інших типів Сервісу базуються на типі ClusterIP.

Якщо ви визначаєте Сервіс, у якому .spec.clusterIP встановлено в "None", тоді Kubernetes не призначає IP-адресу. Див. сервіси headless для отримання додаткової інформації.

Вибір власної IP-адреси

Ви можете вказати власну IP-адресу кластера як частину запиту на створення Service. Для цього встановіть поле .spec.clusterIP. Наприклад, якщо у вас вже є наявний запис DNS, який ви хочете повторно використовувати, або старі системи, які налаштовані на певну IP-адресу і важко переналаштовуються.

IP-адреса, яку ви вибираєте, повинна бути дійсною IPv4 або IPv6 адресою з діапазону CIDR, який налаштований для сервера API за допомогою service-cluster-ip-range. Якщо ви намагаєтеся створити Сервіс із недійсною IP-адресою clusterIP, сервер API поверне HTTP-відповідь зі статус-кодом 422 для позначення проблеми.

Читайте уникнення конфліктів, щоб дізнатися, як Kubernetes допомагає зменшити ризик та вплив двох різних Сервісів, що намагаються використовувати однакову IP-адресу.

type: NodePort

Якщо ви встановлюєте поле type в NodePort, панель управління Kubernetes виділяє порт з діапазону, вказаного прапорцем --service-node-port-range (типово: 30000-32767). Кожен вузол проксіює цей порт (той самий номер порту на кожному вузлі) у ваш Сервіс. Ваш Сервіс повідомляє виділений порт у полі .spec.ports[*].nodePort.

Використання NodePort дає вам свободу налаштувати власне рішення з балансування навантаження, конфігурувати середовища, які не повністю підтримуються Kubernetes, або навіть експонувати один або кілька IP-адрес вузлів безпосередньо.

Для Сервісу з портом вузла Kubernetes додатково виділяє порт (TCP, UDP або SCTP для відповідності протоколу Сервісу). Кожен вузол у кластері конфігурується на прослуховування цього призначеного порту і пересилання трафіку на одну з готових точок доступу, повʼязаних із цим Сервісом. Ви зможете звертатися до Сервісу з type: NodePort, ззовні кластера, підключаючись до будь-якого вузла за відповідним протоколом (наприклад: TCP) та відповідним портом (який призначено цьому Сервісу).

Вибір власного порту

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

Ось приклад маніфесту для Сервісу з type: NodePort, який вказує значення NodePort (30007 у цьому прикладі):

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  type: NodePort
  selector:
    app.kubernetes.io/name: MyApp
  ports:
    - port: 80
      # Стандартно та для зручності, `targetPort` встановлено
      # в те ж значення, що й поле `port`.
      targetPort: 80
      # Необовʼязкове поле
      # Стандартно та для зручності, панель управління Kubernetes
      # виділить порт з діапазону (станадртно: 30000-32767)
      nodePort: 30007

Резервування діапазонів NodePort для уникнення конфліктів

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

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

Налаштування власної IP-адреси для Сервісів type: NodePort

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

Якщо ви хочете вказати певні IP-адреси для проксі-порта, ви можете встановити прапорець --nodeport-addresses для kube-proxy або еквівалентне поле nodePortAddresses у файлі конфігурації kube-proxy на конкретні блоки IP.

Цей прапорець приймає список IP-блоків через кому (наприклад, 10.0.0.0/8, 192.0.2.0/25) для вказівки діапазонів IP-адрес, які kube-proxy повинен вважати локальними для цього вузла.

Наприклад, якщо ви запускаєте kube-proxy з прапорцем --nodeport-addresses=127.0.0.0/8, kube-proxy вибирає лише інтерфейс loopback для NodePort-сервісів. Типово для --nodeport-addresses є порожній список. Це означає, що kube-proxy повинен вважати всі доступні мережеві інтерфейси локальними для NodePort. (Це також сумісно з раніше випущеними версіями Kubernetes.)

type: LoadBalancer

У хмарних постачальників, які підтримують зовнішні балансувальники навантаження, встановлення поле type в LoadBalancer надає балансувальник навантаження для вашого Сервісу. Створення балансувальника навантаження відбувається асинхронно, і інформація про створений балансувальник публікується у поле .status.loadBalancer Сервісу. Наприклад:

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app.kubernetes.io/name: MyApp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376
  clusterIP: 10.0.171.239
  type: LoadBalancer
status:
  loadBalancer:
    ingress:
    - ip: 192.0.2.127

Трафік від зовнішнього балансувальника навантаження направляється на бекенд-Podʼи. Хмарний постачальник вирішує, як він балансує навантаження.

Для реалізації Сервісу з type: LoadBalancer, Kubernetes зазвичай починає з того, що вносить зміни, які еквівалентні вашим запитам на Сервіс type: NodePort. Компонент cloud-controller-manager потім налаштовує зовнішній балансувальник для пересилання трафіку на цей призначений порт вузла.

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

Деякі постачальники хмар дозволяють вам вказати loadBalancerIP. У цих випадках балансувальник створюється з вказаною користувачем loadBalancerIP. Якщо поле loadBalancerIP не вказано, то балансувальник налаштовується з ефемерною IP-адресою. Якщо ви вказали loadBalancerIP, але ваш постачальник хмари не підтримує цю функцію, то вказане вами поле loadbalancerIP ігнорується.

Вплив життєздатності вузла на трафік балансувальника навантаження

Перевірки стану балансувальника навантаження є критичними для сучасних застосунків. Вони використовуються для визначення того, на який сервер (віртуальна машина або IP-адреса) повинен бути направлений трафік балансувальника навантаження. API Kubernetes не визначає, як мають бути реалізовані перевірки стану для керованих Kubernetes балансувальників навантаження; замість цього це роблять хмарні постачальники (і люди, які створюють код інтеграції), які визначають поведінку. Перевірки стану балансувальника навантаження широко використовуються в контексті підтримки поля externalTrafficPolicy для Service.

Балансувальники з мішаними типами протоколів

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

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

Feature gate MixedProtocolLBService (стандартно увімкнено для kube-apiserver з версії v1.24) дозволяє використовувати різні протоколи для Сервісів типу LoadBalancer, коли визначено більше одного порту.

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

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

Ви можете вимкнути виділення порту вузла для Сервісу з type: LoadBalancer, встановивши поле spec.allocateLoadBalancerNodePorts в false. Це слід використовувати тільки для реалізацій балансувальників, які маршрутизують трафік безпосередньо до Podʼів, а не використовують порти вузла. Стандартно spec.allocateLoadBalancerNodePorts дорівнює true, і Сервіси типу LoadBalancer будуть продовжувати виділяти порти вузла. Якщо spec.allocateLoadBalancerNodePorts встановлено в false для існуючого Сервісу з виділеними портами вузла, ці порти вузла не будуть автоматично видалятися. Вам слід явно видалити запис nodePorts в кожному порту Сервісу для деалокації цих портів вузла.

Вказання класу реалізації балансувальника

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

Для Сервісу з type встановленим на LoadBalancer, поле .spec.loadBalancerClass дозволяє вам використовувати реалізацію балансувальника, відмінну від тієї, яку типово встановлено постачальником хмари.

Типово .spec.loadBalancerClass не встановлено, і Сервіс з LoadBalancer використовує реалізацію балансувальника що постачається в хмарі, якщо кластер налаштовано постачальником хмари за допомогою прапорця компоненту --cloud-provider. Якщо ви вказуєте .spec.loadBalancerClass, вважається, що реалізація балансувальника, яка відповідає вказаному класу, відстежує Сервіси. Будь-яка стандартн реалізація балансувальника (наприклад, та, яку надає постачальник хмари), ігнорує Сервіси, у яких встановлено це поле. spec.loadBalancerClass може бути встановлено тільки для Сервісу типу LoadBalancer. Після встановлення його не можна змінити. Значення spec.loadBalancerClass повинно бути ідентифікатором у формі мітки, з необовʼязковим префіксом, таким як "internal-vip" або "example.com/internal-vip". Безпрефіксні імена зарезервовані для кінцевих користувачів.

Вказання IPMode для стану балансувальника

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

Як бета-функція в Kubernetes 1.30, функціональна можливість з іменем LoadBalancerIPMode дозволяє встановлювати значення .status.loadBalancer.ingress.ipMode для Сервісу з type встановленим у LoadBalancer. .status.loadBalancer.ingress.ipMode вказує, як веде себе IP-адреса балансувальника. Воно може бути вказано лише тоді, коли вказано поле .status.loadBalancer.ingress.ip.

Є два можливі значення для .status.loadBalancer.ingress.ipMode: "VIP" та "Proxy".Типово встановлене значення "VIP", що означає, що трафік подається на вузол з призначенням, встановленим на IP та порт балансувальника. Є два випадки, коли встановлено значення "Proxy", залежно від того, як постачальник хмари балансує трафік:

  • Якщо трафік подається на вузол, а потім перенаправляється до Podʼа, призначення буде встановлено на IP та порт вузла;
  • Якщо трафік подається безпосередньо до Podʼа, призначення буде встановлено на IP та порт Podʼа.

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

Внутрішній балансувальник

У змішаному середовищі іноді необхідно направляти трафік від Сервісів всередині того ж (віртуального) мережевого блоку.

У середовищі DNS із подвійним горизонтом вам може знадобитися два Сервіси для маршрутизації зовнішнього і внутрішнього трафіку до ваших ендпоінтів.

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

Виберіть одну з вкладок.

metadata:
  name: my-service
  annotations:
    networking.gke.io/load-balancer-type: "Internal"

metadata:
  name: my-service
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-internal: "true"

metadata:
  name: my-service
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-internal: "true"

metadata:
  name: my-service
  annotations:
    service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "private"

metadata:
  name: my-service
  annotations:
    service.beta.kubernetes.io/openstack-internal-load-balancer: "true"

metadata:
  name: my-service
  annotations:
    service.beta.kubernetes.io/cce-load-balancer-internal-vpc: "true"

metadata:
  annotations:
    service.kubernetes.io/qcloud-loadbalancer-internal-subnetid: subnet-xxxxx

metadata:
  annotations:
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: "intranet"

metadata:
  name: my-service
  annotations:
    service.beta.kubernetes.io/oci-load-balancer-internal: true

type: ExternalName

Сервіси типу ExternalName звʼязують Сервіс з DNS-іменем, а не на типовим селектором, таким як my-service або cassandra. Ви вказуєте ці Сервіси параметром spec.externalName.

Наприклад, це визначення Сервісу звʼязує Сервіс my-service в просторі імен prod з my.database.example.com:

apiVersion: v1
kind: Service
metadata:
  name: my-service
  namespace: prod
spec:
  type: ExternalName
  externalName: my.database.example.com

При пошуку хоста my-service.prod.svc.cluster.local, DNS-сервіс кластера повертає запис CNAME із значенням my.database.example.com. Доступ до my-service працює так само, як і для інших Сервісів, але з важливою різницею в тому, що перенаправлення відбувається на рівні DNS, а не через проксі або переадресацію. Якщо ви пізніше вирішите перемістити свою базу даних в кластер, ви можете запустити його Podʼи, додати відповідні селектори чи endpointʼи та змінити тип Сервісу.

Headless Services

Іноді вам не потрібен балансувальник навантаження та одна IP-адреса Сервісу. У цьому випадку ви можете створити так звані headless Services, якщо явно вказати "None" для IP-адреси кластера (.spec.clusterIP).

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

Для headless Сервісів кластерна IP-адреса не видається, kube-proxy не обслуговує ці Сервіси, і для них платформа не виконує балансування навантаження чи проксіюваня.

Headless Сервіси дозволяють клієнту приєднуватись до будь-якого Pod безпосередньо. Ці Сервіси не встановлюють маршрути та перенаправлення пакетів з використанням віртуальних IP-адрес та проксі; натомість вони повідомляють про IP-адреси точок доступу окремих Podʼів через внутрішні записи DNS, які обслуговуються службою DNS кластера. Для визначення headless Сервіса вам потрібно створити Service з .spec.type встановленим на ClusterIP (що також є типовим значенням) та .spec.clusterIP встановленим у None.

Рядкове значення None є спеціальним випадком та не є тотожноми тому, якщо поле .spec.clusterIP не вказане.

Те, як автоматично налаштовано DNS, залежить від того, чи визначені селектори Сервісу:

З селекторами

Для headless Сервісів, які визначають селектори, контролер endpointʼів створює обʼєкти EndpointSlice в Kubernetes API та змінює конфігурацію DNS так, щоб повертати записи A або AAAA (IPv4 або IPv6 адреси), які напрямую вказують на Podʼи, які підтримують Сервіс.

Без селекторів

Для headless Сервісів, які не визначають селектори, панель управління не створює обʼєкти EndpointSlice. Проте система DNS шукає та налаштовує або:

  • DNS-записи CNAME для Сервісів з type: ExternalName.
  • DNS-записи A / AAAA для всіх IP-адрес Сервісу з готовими endpointʼами, для всіх типів Сервісів, крім ExternalName.
    • Для IPv4 endpointʼів система DNS створює A-записи.
    • Для IPv6 endpointʼів система DNS створює AAAA-записи.

Коли ви визначаєте headless Сервіс без селектора, поле port повинно відповідати полю targetPort.

Виявлення сервісів

Для клієнтів, що працюють всередині вашого кластера, Kubernetes підтримує два основних способи виявлення Сервісу: змінні середовища та DNS.

Змінні середовища

Коли Pod запускається на вузлі, kubelet додає набір змінних середовища для кожного активного Сервісу. Додаються змінні середовища {SVCNAME}_SERVICE_HOST та {SVCNAME}_SERVICE_PORT, де імʼя Сервісу перетворюється у верхній регістр, а тире конвертуються у підкреслення.

Наприклад, Сервіс redis-primary, який використовує TCP-порт 6379 та має присвоєну IP-адресу кластера 10.0.0.11, створює наступні змінні середовища:

REDIS_PRIMARY_SERVICE_HOST=10.0.0.11
REDIS_PRIMARY_SERVICE_PORT=6379
REDIS_PRIMARY_PORT=tcp://10.0.0.11:6379
REDIS_PRIMARY_PORT_6379_TCP=tcp://10.0.0.11:6379
REDIS_PRIMARY_PORT_6379_TCP_PROTO=tcp
REDIS_PRIMARY_PORT_6379_TCP_PORT=6379
REDIS_PRIMARY_PORT_6379_TCP_ADDR=10.0.0.11

Kubernetes також підтримує та надає змінні, які сумісні з "legacy container links" Docker Engine. Ви можете переглянути makeLinkVariables щоб побачити, як це реалізовано в Kubernetes.

DNS

Ви можете (і майже завжди повинні) налаштувати службу DNS для вашого кластера Kubernetes, використовуючи надбудову.

Сервер DNS, знається на кластерах, такий як CoreDNS, стежить за Kubernetes API для виявлення нових Сервісів і створює набір DNS-записів для кожного з них. Якщо DNS увімкнено в усьому кластері, то всі Podʼи повинні автоматично мати можливість знаходити Сервіси за їхнім DNS-імʼям.

Наприклад, якщо у вас є Сервіс з назвою my-service в просторі імен Kubernetes my-ns, то разом панель управління та служба DNS створюють DNS-запис для my-service.my-ns. Podʼи в просторі імен my-ns повинні мати можливість знаходити Сервіс, роблячи запит за іменем my-service (my-service.my-ns також працюватиме).

Podʼи в інших просторах імен повинні вказати імʼя як my-service.my-ns. Ці імена будуть розповсюджуватись на призначений кластером IP для Сервісу.

Kubernetes також підтримує DNS SRV (Service) записи для іменованих портів. Якщо Сервіс my-service.my-ns має порт з іменем http і протоколом, встановленим в TCP, ви можете виконати DNS SRV-запит для _http._tcp.my-service.my-ns, щоб дізнатися номер порту для http, а також IP-адресу.

Сервер DNS Kubernetes — єдиний спосіб доступу до Сервісів ExternalName. Ви можете знайти більше інформації про вирішення ExternalName в DNS для Сервісів та Podʼів.

Механізм віртуальних IP-адрес

Прочитайте Віртуальні IP-адреси та сервісні проксі, що пояснює механізм, який Kubernetes надає для експозиції Сервісу з віртуальною IP-адресою.

Політики трафіку

Ви можете встановити поля .spec.internalTrafficPolicy та .spec.externalTrafficPolicy, щоб контролювати, як Kubernetes маршрутизує трафік до справних ("готових") бекендів.

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

Розподіл трафіку

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

Поле .spec.trafficDistribution надає ще один спосіб впливу на маршрутизацію трафіку в межах Сервісу Kubernetes. Хоча політика трафіку зосереджується на строгих семантичних гарантіях, розподіл трафіку дозволяє виражати уподобання (наприклад, маршрутизацію до топологічно ближчих точок доступу). Це може допомогти оптимізувати продуктивність, вартість або надійність. Це необовʼязкове поле можна використовувати, якщо ви ввімкнули функціональну можливість ServiceTrafficDistribution для вашого кластера та всіх його вузлів. У Kubernetes 1.31, підтримується таке значення поля:

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

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

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

Збереження сесії

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

Зовнішні IP

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

При визначенні Сервісу ви можете вказати externalIPs для будь-якого типу сервісу. У наведеному нижче прикладі Сервіс з іменем "my-service" може отримати доступ від клієнтів за допомогою TCP за адресою "198.51.100.32:80" (розраховано із .spec.externalIPs[] та .spec.ports[].port).

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app.kubernetes.io/name: MyApp
  ports:
    - name: http
      protocol: TCP
      port: 80
      targetPort: 49152
  externalIPs:
    - 198.51.100.32

API Обʼєкт

Сервіс — це ресурс верхнього рівня в Kubernetes REST API. Ви можете знайти більше деталей про обʼєкт API Service.

Що далі

Дізнайтеся більше про Сервіси та те, як вони вписуються в Kubernetes:

  • Дізнайтесь про Підключення застосунків за допомогою Service уроку.
  • Прочитайте про Ingress, який експонує маршрути HTTP та HTTPS ззовні кластера до Сервісів всередині вашого кластера.
  • Прочитайте про Gateway, розширення для Kubernetes, яке надає більше гнучкості, ніж Ingress.

Для отримання додаткового контексту прочитайте наступне:

3.5.2 - Ingress

Робить вашу мережеву службу HTTP (або HTTPS) доступною за допомогою конфігурації, яка розуміє протокол та враховує вебконцепції, такі як URI, імена хостів, шляхи та інше. Концепція Ingress дозволяє вам направляти трафік на різні бекенди на основі правил, які ви визначаєте через API Kubernetes.

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

Обʼєкт API, який управляє зовнішнім доступом до служб в кластері, зазвичай HTTP.

Ingress може надавати балансування навантаження, розшифровування SSL-трафіку та віртуальний хостинг на основі імен.

Термінологія

Для ясності цей посібник визначає наступні терміни:

  • Вузол: Робоча машина в Kubernetes, що є частиною кластера.
  • Кластер: Набір вузлів, на яких виконуються контейнеризовані застосунки, керовані Kubernetes. У прикладі та в більшості типових розгортань Kubernetes вузли кластера не є частиною відкритої мережі Інтернет.
  • Edge маршрутизатор: Маршрутизатор, який застосовує політику брандмауера для вашого кластера. Це може бути шлюз, керований хмарним постачальником, або фізичний пристрій.
  • Кластерна мережа: Набір зʼєднань, логічних або фізичних, які сприяють комунікації в межах кластера згідно з мережевою моделлю Kubernetes.
  • Service: Service Kubernetes, що ідентифікує набір Podʼів за допомогою селекторів label. Якщо не вказано інше, припускається, що служби мають віртуальні IP-адреси, які можна маршрутизувати лише в межах кластерної мережі.

Що таке Ingress?

Ingress відкриває маршрути HTTP та HTTPS із зовні кластера до Services всередині кластера. Маршрутизацію трафіку контролюють правила, визначені в ресурсі Ingress.

Ось простий приклад, де Ingress спрямовує весь свій трафік на один Service:

graph LR; client([клієнт])-. Балансувальник навантаження
яким керує Ingress .->ingress[Ingress]; ingress-->|правила
маршрутизації|service[Service]; subgraph cluster["Кластер"] ingress; service-->pod1[Pod]; service-->pod2[Pod]; end classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000; classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5; class ingress,service,pod1,pod2 k8s; class client plain; class cluster cluster;
Схема. Ingress

Ingress може бути налаштований таким чином, щоб надавати Service зовнішньодоступні URL, балансувати трафік, термінувати SSL/TLS та пропонувати іменований віртуальний хостинг. Контролер Ingress відповідає за виконання Ingress, зазвичай з допомогою балансувальника навантаження, хоча він також може конфігурувати ваш edge маршрутизатор або додаткові фронтенди для допомоги в обробці трафіку.

Ingress не відкриває довільні порти або протоколи. Для експозиції служб, відмінних від HTTP та HTTPS, в Інтернет зазвичай використовується служба типу Service.Type=NodePort або Service.Type=LoadBalancer.

Передумови

Вам потрібно мати контролер Ingress, щоб виконувати Ingress. Лише створення ресурсу Ingress не має ефекту.

Можливо, вам доведеться розгорнути контролер Ingress, такий як ingress-nginx. Ви можете вибрати з-поміж контролерів Ingress.

В ідеалі, всі контролери Ingress повинні відповідати вказаній специфікації. На практиці різні контролери Ingress працюють трошки по-різному.

Ресурс Ingress

Мінімальний приклад ресурсу Ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: minimal-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx-example
  rules:
  - http:
      paths:
      - path: /testpath
        pathType: Prefix
        backend:
          service:
            name: test
            port:
              number: 80

Для Ingress необхідні поля apiVersion, kind, metadata та spec. Назва обʼєкта Ingress повинна бути дійсним DNS-піддоменом. Для загальної інформації щодо роботи з файлами конфігурації дивіться розгортання застосунків, налаштування контейнерів, управління ресурсами. Ingress часто використовує анотації для налаштування деяких параметрів залежно від контролера Ingress, прикладом чого є анотація для перезапису. Різні контролери Ingress підтримують різні анотації. Ознайомтеся з документацією контролера Ingress, який ви вибрали, щоб дізнатися, які анотації підтримуються.

У специфікації Ingress міститься вся інформація, необхідна для налаштування балансувальника навантаження чи проксі-сервера. Важливою є наявність списку правил, які порівнюються з усіма вхідними запитами. Ресурс Ingress підтримує правила тільки для направлення трафіку HTTP(S).

Якщо ingressClassName відсутній, має бути визначений типовий клас Ingress.

Є контролери Ingress, які працюють без визначення типового IngressClass. Наприклад, контролер Ingress-NGINX може бути налаштований за допомогою прапора --watch-ingress-without-class. З усім тим, рекомендується вказати типовий IngressClass, як показано нижче.

Правила Ingress

Кожне правило HTTP містить наступну інформацію:

  • Необовʼязковий хост. У цьому прикладі хост не вказаний, тому правило застосовується до всього вхідного HTTP-трафіку через вказану IP-адресу. Якщо вказано хост (наприклад, foo.bar.com), правила застосовуються до цього хосту.
  • Список шляхів (наприклад, /testpath), кожен з яких має повʼязаний бекенд, визначений імʼям service.name та service.port.name або service.port.number. Як хост, так і шлях повинні відповідати вмісту вхідного запиту, перш ніж балансувальник навантаження направить трафік до зазначеного Service.
  • Бекенд — це комбінація імені Service та порту, як описано в документації Service або ресурсом бекенду користувача за допомогою CRD. HTTP (та HTTPS) запити до Ingress, які відповідають хосту та шляху правила, надсилаються до вказаного бекенду.

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

DefaultBackend

Ingress без правил спрямовує весь трафік до єдиного стандартного бекенду, і .spec.defaultBackend — це бекенд, який повинен обробляти запити в цьому випадку. Зазвичай defaultBackend — це опція конфігурації контролера Ingress і не вказується в ресурсах вашого Ingress. Якщо не вказано .spec.rules, то повинен бути вказаний .spec.defaultBackend. Якщо defaultBackend не встановлено, обробка запитів, які не відповідають жодному з правил, буде покладена на контролер ingress (звертайтеся до документації свого контролера Ingress, щоб дізнатися, як він обробляє цей випадок).

Якщо жоден із хостів або шляхів не відповідає HTTP-запиту в обʼєктах Ingress, трафік направляється до вашого стандартного бекенду.

Бекенд Resource

Бекенд Resource — це ObjectRef на інший ресурс Kubernetes всередині того ж простору імен, що й обʼєкт Ingress. Resource — є несумісним з Service, перевірка налаштувань виявить помилку, якщо вказані обидва. Звичайне використання для бекенду Resource — це направлення даних в обʼєкт зберігання зі статичними ресурсами.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-resource-backend
spec:
  defaultBackend:
    resource:
      apiGroup: k8s.example.com
      kind: StorageBucket
      name: static-assets
  rules:
    - http:
        paths:
          - path: /icons
            pathType: ImplementationSpecific
            backend:
              resource:
                apiGroup: k8s.example.com
                kind: StorageBucket
                name: icon-assets

Після створення Ingress вище, ви можете переглянути його за допомогою наступної команди:

kubectl describe ingress ingress-resource-backend
Name:             ingress-resource-backend
Namespace:        default
Address:
Default backend:  APIGroup: k8s.example.com, Kind: StorageBucket, Name: static-assets
Rules:
  Host        Path  Backends
  ----        ----  --------
  *
              /icons   APIGroup: k8s.example.com, Kind: StorageBucket, Name: icon-assets
Annotations:  <none>
Events:       <none>

Типи шляхів

Для кожного шляху в Ingress обовʼязково повинен бути відповідний тип шляху. Шляхи, які не включають явний pathType, не пройдуть валідацію. Існує три типи шляхів, що підтримуються:

  • ImplementationSpecific: З цим типом шляху визначення відповідності залежить від IngressClass. Реалізації можуть розглядати це як окремий pathType або обробляти його так само як типи шляхів Prefix або Exact.

  • Exact: Відповідає URL-шляху точно і з урахуванням регістрів.

  • Prefix: Відповідає на основі префіксу URL-шляху, розділеному /. Відповідність визначається з урахуванням регістру і виконується поелементно за кожним елементом шляху. Елемент шляху вказує на список міток у шляху, розділених роздільником /. Запит відповідає шляху p, якщо кожен p є префіксом елемента p запиту.

Приклади

ТипШлях(и)Шлях запитуВідповідає?
Префікс/(всі шляхи)Так
Точний/foo/fooТак
Точний/foo/barНі
Точний/foo/foo/Ні
Точний/foo//fooНі
Префікс/foo/foo, /foo/Так
Префікс/foo//foo, /foo/Так
Префікс/aaa/bb/aaa/bbbНі
Префікс/aaa/bbb/aaa/bbbТак
Префікс/aaa/bbb//aaa/bbbТак, ігнорує кінцевий слеш
Префікс/aaa/bbb/aaa/bbb/Так, співпадає з кінцевим слешем
Префікс/aaa/bbb/aaa/bbb/cccТак, співпадає з підшляхом
Префікс/aaa/bbb/aaa/bbbxyzНі, не співпадає з префіксом рядка
Префікс/, /aaa/aaa/cccТак, співпадає з префіксом /aaa
Префікс/, /aaa, /aaa/bbb/aaa/bbbТак, співпадає з префіксом /aaa/bbb
Префікс/, /aaa, /aaa/bbb/cccТак, співпадає з префіксом /
Префікс/aaa/cccНі, використовується типовий backend
Змішаний/foo (Префікс), /foo (Точний)/fooТак, віддає перевагу Точному

Декілька збігів

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

Шаблони імен хостів

Хости можуть бути точними збігами (наприклад, "foo.bar.com") або містити шаблони (наприклад, "*.foo.com"). Точні збіги вимагають, щоб заголовок HTTP host відповідав полю host. Шаблони вимагають, щоб заголовок HTTP host був рівним суфіксу правила з символами підстановки.

ХостЗаголовок хостаЗбіг?
*.foo.combar.foo.comЗбіг на основі спільного суфіксу
*.foo.combaz.bar.foo.comНемає збігу, символ підстановки охоплює лише одну DNS-мітку
*.foo.comfoo.comНемає збігу, символ підстановки охоплює лише одну DNS-мітку
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-wildcard-host
spec:
  rules:
  - host: "foo.bar.com"
    http:
      paths:
      - pathType: Prefix
        path: "/bar"
        backend:
          service:
            name: service1
            port:
              number: 80
  - host: "*.foo.com"
    http:
      paths:
      - pathType: Prefix
        path: "/foo"
        backend:
          service:
            name: service2
            port:
              number: 80

Клас Ingress

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

apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: external-lb
spec:
  controller: example.com/ingress-controller
  parameters:
    apiGroup: k8s.example.com
    kind: IngressParameters
    name: external-lb

Поле .spec.parameters класу IngressClass дозволяє посилатися на інший ресурс, який надає конфігурацію, повʼязану з цим класом IngressClass.

Конкретний тип параметрів для використання залежить від контролера Ingress, який ви вказуєте в полі .spec.controller IngressClass.

Область застосування IngressClass

Залежно від вашого контролера Ingress, ви можете використовувати параметри, які ви встановлюєте на рівні кластера, або лише для одного простору імен.

Стандартна область застосування параметрів IngressClass — це весь кластер.

Якщо ви встановлюєте поле .spec.parameters і не встановлюєте .spec.parameters.scope, або ви встановлюєте .spec.parameters.scope на Cluster, тоді IngressClass посилається на ресурс, який є на рівні кластера. kind (в поєднанні з apiGroup) параметрів вказує на API на рівні кластера (можливо, власний ресурс), і name параметрів ідентифікує конкретний ресурс на рівні кластера для цього API.

Наприклад:

---
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: external-lb-1
spec:
  controller: example.com/ingress-controller
  parameters:
    # Параметри для цього IngressClass вказані в ClusterIngressParameter
    # (API group k8s.example.net) імені "external-config-1".
    # Це визначення вказує Kubernetes шукати ресурс параметрів на рівні кластера.
    scope: Cluster
    apiGroup: k8s.example.net
    kind: ClusterIngressParameter
    name: external-config-1

<div class="feature-state-notice feature-stable">
  <span class="feature-state-name">СТАН ФУНКЦІОНАЛУ:</span> 
  <code>Kubernetes v1.23 [stable]</code>
</div>

Якщо ви встановлюєте поле .spec.parameters і встановлюєте .spec.parameters.scope на Namespace, тоді IngressClass посилається на ресурс на рівні простору імен. Ви також повинні встановити поле namespace в межах .spec.parameters на простір імен, який містить параметри, які ви хочете використовувати.

kind (в поєднанні з apiGroup) параметрів вказує на API на рівні простору імен (наприклад: ConfigMap), і name параметрів ідентифікує конкретний ресурс у просторі імен, який ви вказали в namespace.

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

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

Сам API IngressClass завжди має область застосування на рівні кластера.

Ось приклад IngressClass, який посилається на параметри на рівні простору імен:

---
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: external-lb-2
spec:
  controller: example.com/ingress-controller
  parameters:
    # Параметри для цього IngressClass вказані в IngressParameter
    # (API group k8s.example.com) імені "external-config",
    # що знаходиться в просторі імен "external-configuration".
    scope: Namespace
    apiGroup: k8s.example.com
    kind: IngressParameter
    namespace: external-configuration
    name: external-config

Застарілі анотації

Перед тим, як в Kubernetes 1.18 були додані ресурс IngressClass та поле ingressClassName, класи Ingress вказувалися за допомогою анотації kubernetes.io/ingress.class в Ingress. Ця анотація ніколи не була формально визначена, але отримала широку підтримку контролерами Ingress.

Нове поле ingressClassName в Ingress — це заміна для цієї анотації, але не є прямим еквівалентом. Хоча анотація, як правило, використовувалася для посилання на імʼя контролера Ingress, який повинен реалізувати Ingress, поле є посиланням на ресурс IngressClass, який містить додаткову конфігурацію Ingress, включаючи імʼя контролера Ingress.

Стандартний IngressClass

Ви можете визначити певний IngressClass як стандартний для вашого кластера. Встановлення анотації ingressclass.kubernetes.io/is-default-class зі значенням true на ресурсі IngressClass забезпечить те, що новим Ingress буде призначений цей типовий IngressClass, якщо в них не вказано поле ingressClassName.

Є контролери Ingress, які працюють без визначення типового IngressClass. Наприклад, контролер Ingress-NGINX може бути налаштований з прапорцем --watch-ingress-without-class. Однак рекомендується визначати типовий IngressClass явно:

apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  labels:
    app.kubernetes.io/component: controller
  name: nginx-example
  annotations:
    ingressclass.kubernetes.io/is-default-class: "true"
spec:
  controller: k8s.io/ingress-nginx

Типи Ingress

Ingress з підтримкою одного Service

Існують концепції в Kubernetes, що дозволяють вам використовувати один Service (див. альтернативи). Ви також можете зробити це за допомогою Ingress, вказавши стандартний бекенд без правил.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: test-ingress
spec:
  defaultBackend:
    service:
      name: test
      port:
        number: 80

Якщо ви створите його за допомогою kubectl apply -f, ви повинні мати можливість переглядати стан доданого Ingress:

kubectl get ingress test-ingress
NAME           CLASS         HOSTS   ADDRESS         PORTS   AGE
test-ingress   external-lb   *       203.0.113.123   80      59s

Де 203.0.113.123 — це IP-адреса, яку надав контролер Ingress для виконання цього Ingress.

Простий розподіл

Конфігурація розподілу дозволяє маршрутизувати трафік з одної IP-адреси до більше ніж одного сервісу, виходячи з HTTP URI, що запитується. Ingress дозволяє зберігати кількість балансувальників на мінімальному рівні. Наприклад, налаштування як:

graph LR; client([клієнт])-. Балансувальник навантаження
яким керує Ingress .->ingress[Ingress, 178.91.123.132]; ingress-->|/foo|service1[Service service1:4200]; ingress-->|/bar|service2[Service service2:8080]; subgraph cluster["Кластер"] ingress; service1-->pod1[Pod]; service1-->pod2[Pod]; service2-->pod3[Pod]; service2-->pod4[Pod]; end classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000; classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5; class ingress,service1,service2,pod1,pod2,pod3,pod4 k8s; class client plain; class cluster cluster;
Схема. Ingress Fan Out

Для цього потрібно мати Ingress, наприклад:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: simple-fanout-example
spec:
  rules:
  - host: foo.bar.com
    http:
      paths:
      - path: /foo
        pathType: Prefix
        backend:
          service:
            name: service1
            port:
              number: 4200
      - path: /bar
        pathType: Prefix
        backend:
          service:
            name: service2
            port:
              number: 8080

Коли ви створюєте Ingress за допомогою kubectl apply -f:

kubectl describe ingress simple-fanout-example
Name:             simple-fanout-example
Namespace:        default
Address:          178.91.123.132
Default backend:  default-http-backend:80 (10.8.2.3:8080)
Rules:
  Host         Path  Backends
  ----         ----  --------
  foo.bar.com
               /foo   service1:4200 (10.8.0.90:4200)
               /bar   service2:8080 (10.8.0.91:8080)
Events:
  Type     Reason  Age                From                     Message
  ----     ------  ----               ----                     -------
  Normal   ADD     22s                loadbalancer-controller  default/test

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

Віртуальний хостинг на основі імен

Віртуальні хости на основі імен підтримують маршрутизацію HTTP-трафіку до кількох імен хостів за однією IP-адресою.

graph LR; client([клієнт])-. Балансувальник навантаження
яким керує Ingress .->ingress[Ingress, 178.91.123.132]; ingress-->|Host: foo.bar.com|service1[Service service1:80]; ingress-->|Host: bar.foo.com|service2[Service service2:80]; subgraph cluster["Кластер"] ingress; service1-->pod1[Pod]; service1-->pod2[Pod]; service2-->pod3[Pod]; service2-->pod4[Pod]; end classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000; classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5; class ingress,service1,service2,pod1,pod2,pod3,pod4 k8s; class client plain; class cluster cluster;
Схема. Ingress віртуального хостингу на основі імен

Наступний Ingress вказує балансувальнику направляти запити на основі заголовка Host.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: name-virtual-host-ingress
spec:
  rules:
  - host: foo.bar.com
    http:
      paths:
      - pathType: Prefix
        path: "/"
        backend:
          service:
            name: service1
            port:
              number: 80
  - host: bar.foo.com
    http:
      paths:
      - pathType: Prefix
        path: "/"
        backend:
          service:
            name: service2
            port:
              number: 80

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

Наприклад, наступний Ingress маршрутизує трафік спрямований для first.bar.com до service1, second.bar.com до service2, і будь-який трафік, який має заголовок запиту хоста, який не відповідає first.bar.com і second.bar.com до service3.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: name-virtual-host-ingress-no-third-host
spec:
  rules:
  - host: first.bar.com
    http:
      paths:
      - pathType: Prefix
        path: "/"
        backend:
          service:
            name: service1
            port:
              number: 80
  - host: second.bar.com
    http:
      paths:
      - pathType: Prefix
        path: "/"
        backend:
          service:
            name: service2
            port:
              number: 80
  - http:
      paths:
      - pathType: Prefix
        path: "/"
        backend:
          service:
            name: service3
            port:
              number: 80

TLS

Ви можете захистити Ingress, вказавши Secret, що містить приватний ключ TLS та сертифікат. Ресурс Ingress підтримує лише один TLS-порт, 443, та передбачає термінування TLS на точці входу (трафік до Service та його Podʼів передається у вигляді звичайного тексту). Якщо розділ конфігурації TLS в Ingress вказує різні хости, вони мультиплексуються на одному порту відповідно до імені хоста, вказаного через розширення TLS з SNI (за умови, що контролер Ingress підтримує SNI). TLS-секрет повинен містити ключі з іменами tls.crt та tls.key, які містять сертифікат та приватний ключ для використання TLS. Наприклад:

apiVersion: v1
kind: Secret
metadata:
  name: testsecret-tls
  namespace: default
data:
  tls.crt: base64 encoded cert
  tls.key: base64 encoded key
type: kubernetes.io/tls

Посилання на цей секрет в Ingress дозволяє контролеру Ingress захистити канал, що йде від клієнта до балансувальника навантаження за допомогою TLS. Вам потрібно переконатися, що TLS-секрет, який ви створили, містить сертифікат, який містить Common Name (CN), також Fully Qualified Domain Name (FQDN) для https-example.foo.com.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: tls-example-ingress
spec:
  tls:
  - hosts:
      - https-example.foo.com
    secretName: testsecret-tls
  rules:
  - host: https-example.foo.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: service1
            port:
              number: 80

Балансування навантаження

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

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

Оновлення Ingress

Щоб оновити існуючий Ingress і додати новий хост, ви можете відредагувати ресурс таким чином:

kubectl describe ingress test
Name:             test
Namespace:        default
Address:          178.91.123.132
Default backend:  default-http-backend:80 (10.8.2.3:8080)
Rules:
  Host         Path  Backends
  ----         ----  --------
  foo.bar.com
               /foo   service1:80 (10.8.0.90:80)
Annotations:
  nginx.ingress.kubernetes.io/rewrite-target:  /
Events:
  Type     Reason  Age                From                     Message
  ----     ------  ----               ----                     -------
  Normal   ADD     35s                loadbalancer-controller  default/test
kubectl edit ingress test

Це відкриє редактор з поточною конфігурацією у форматі YAML. Змініть її, щоб додати новий хост:

spec:
  rules:
  - host: foo.bar.com
    http:
      paths:
      - backend:
          service:
            name: service1
            port:
              number: 80
        path: /foo
        pathType: Prefix
  - host: bar.baz.com
    http:
      paths:
      - backend:
          service:
            name: service2
            port:
              number: 80
        path: /foo
        pathType: Prefix
..

Після збереження змін, kubectl оновлює ресурс у API-сервері, що повідомляє Ingress-контролеру переконфігурувати балансувальник.

Перевірте це:

kubectl describe ingress test
Name:             test
Namespace:        default
Address:          178.91.123.132
Default backend:  default-http-backend:80 (10.8.2.3:8080)
Rules:
  Host         Path  Backends
  ----         ----  --------
  foo.bar.com
               /foo   service1:80 (10.8.0.90:80)
  bar.baz.com
               /foo   service2:80 (10.8.0.91:80)
Annotations:
  nginx.ingress.kubernetes.io/rewrite-target:  /
Events:
  Type     Reason  Age                From                     Message
  ----     ------  ----               ----                     -------
  Normal   ADD     45s                loadbalancer-controller  default/test

Ви можете досягти того самого результату, викликавши kubectl replace -f із зміненим файлом YAML для Ingress.

Збій у різних зонах доступності

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

Альтернативи

Ви можете використовувати різні способи надання доступу до Service, які безпосередньо не стосуються ресурсу Ingress:

Що далі

3.5.3 - Контролери Ingress

Для того, щоб ресурс Ingress працював у вашому кластері, повинен бути запущений контролер Ingress. Вам потрібно вибрати принаймні один контролер Ingress та переконатися, що він налаштований у вашому кластері. На цій сторінці перелічені поширені контролери Ingress, які ви можете встановити.

Для того, щоб ресурс Ingress працював, у кластері повинен бути запущений контролер Ingress.

На відміну від інших типів контролерів, які працюють як частина бінарного файлу kube-controller-manager, контролери Ingress не запускаються автоматично разом з кластером. Використовуйте цю сторінку, щоб вибрати реалізацію контролера Ingress, яка найкраще підходить для вашого кластера.

Проєкт Kubernetes підтримує контролери Ingress для AWS, GCE та nginx.

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

  • AKS Application Gateway Ingress Controller — це контролер Ingress, який налаштовує Azure Application Gateway.
  • Alibaba Cloud MSE Ingress — це контролер Ingress, який налаштовує Alibaba Cloud Native Gateway, який також є комерційною версією Higress.
  • Apache APISIX Ingress Controller — це контролер Ingress, заснований на Apache APISIX.
  • Avi Kubernetes Operator забезпечує балансування навантаження рівня 4-7, використовуючи VMware NSX Advanced Load Balancer.
  • BFE Ingress Controller — це контролер Ingress, заснований на BFE.
  • Cilium Ingress Controller — це контролер Ingress, який працює на основі Cilium.
  • Контролер Ingress Citrix співпрацює з контролером доставки програм Citrix.
  • Contour — це контролер Ingress на основі Envoy.
  • Emissary-Ingress API Gateway — це контролер Ingress на основі Envoy.
  • EnRoute — це шлюз API на основі Envoy, який може працювати як контролер Ingress.
  • Easegress IngressController — це шлюз API на основі Easegress, який може працювати як контролер Ingress.
  • F5 BIG-IP Container Ingress Services for Kubernetes дозволяє використовувати Ingress для конфігурації віртуальних серверів F5 BIG-IP.
  • FortiADC Ingress Controller підтримує ресурси Kubernetes Ingress та дозволяє керувати обʼєктами FortiADC з Kubernetes
  • Gloo — це відкритий контролер Ingress на основі Envoy, який пропонує функціональність воріт API.
  • HAProxy Ingress — це контролер Ingress для HAProxy.
  • Higress — це шлюз API на основі Envoy, який може працювати як контролер Ingress.
  • Контролер Ingress HAProxy для Kubernetes також є контролером Ingress для HAProxy.
  • Istio Ingress — це контролер Ingress на основі Istio.
  • Контролер Ingress Kong для Kubernetes — це контролер Ingress, який керує Kong Gateway.
  • Kusk Gateway — це контролер Ingress, орієнтований на OpenAPI, на основі Envoy.
  • Контролер Ingress NGINX для Kubernetes працює з вебсервером NGINX (як проксі).
  • ngrok Kubernetes Ingress Controller — це контролер Ingress з відкритим кодом для надання безпечного публічного доступу до ваших служб K8s за допомогою платформи ngrok.
  • Контролер Ingress OCI Native — це контролер Ingress для Oracle Cloud Infrastructure, який дозволяє керувати OCI Load Balancer.
  • OpenNJet Ingress Controller є ingress-контролером на основі OpenNJet.
  • Контролер Ingress Pomerium — це контролер Ingress на основі Pomerium, який пропонує політику доступу з урахуванням контексту.
  • Skipper — це HTTP-маршрутизатор та зворотний проксі для композиції служб, включаючи випадки використання, такі як Kubernetes Ingress, розроблений як бібліотека для побудови вашого власного проксі.
  • Контролер Ingress Traefik Kubernetes provider — це контролер Ingress для проксі Traefik.
  • Tyk Operator розширює Ingress за допомогою власних ресурсів для надання можливостей управління API Ingress. Tyk Operator працює з відкритими шлюзами Tyk та хмарною системою управління Tyk.
  • Voyager — це контролер Ingress для HAProxy.
  • Контролер Ingress Wallarm — це контролер Ingress, який надає можливості WAAP (WAF) та захисту API.

Використання кількох контролерів Ingress

Ви можете розгортати будь-яку кількість контролерів Ingress за допомогою класу Ingress у межах кластера. Зверніть увагу на значення .metadata.name вашого ресурсу класу Ingress. При створенні Ingress вам слід вказати це імʼя для визначення поля ingressClassName в обʼєкті Ingress (див. специфікацію IngressSpec v1). ingressClassName є заміною застарілого методу анотації.

Якщо ви не вказуєте IngressClass для Ingress, і у вашому кластері рівно один IngressClass відзначений як типовий, тоді Kubernetes застосовує типовий IngressClass кластера до Ingress. Ви вказуєте IngressClass як типовий, встановлюючи анотацію ingressclass.kubernetes.io/is-default-class для цього IngressClass, зі значенням "true".

В ідеалі, всі контролери Ingress повинні відповідати цій специфікації, але різні контролери Ingress працюють трошки по-різному.

Що далі

3.5.4 - Gateway API

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

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

Принципи дизайну

Наведені нижче принципи визначили дизайн та архітектуру Gateway API:

  • Орієнтований на ролі: Види Gateway API моделюються за організаційними ролями, які відповідають за управління мережевою службою Kubernetes:

    • Постачальник інфраструктури: Управляє інфраструктурою, яка дозволяє кільком ізольованим кластерам обслуговувати кілька орендарів, наприклад, хмарний постачальник.
    • Оператор кластера: Управляє кластерами та зазвичай цікавиться політиками, мережевим доступом, дозволами застосунків тощо.
    • Розробник застосунків: Управляє застосунком, який працює в кластері та, як правило, цікавиться конфігурацією рівня застосунку та складом Service.
  • Переносний: Специфікації Gateway API визначаються як власні ресурси та підтримуються багатьма реалізаціями.

  • Експресивний: Види Gateway API підтримують функціональність для загальних випадків маршрутизації трафіку, таких як відповідність на основі заголовків, визначенні пріоритету трафіку та інших, які були можливі тільки в Ingress за допомогою власних анотацій.

  • Розширюваний: Gateway дозволяє повʼязувати власні ресурси на різних рівнях API. Це робить можливим докладне налаштування на відповідних рівнях структури API.

Модель ресурсів

Gateway API має три стабільні види API:

  • GatewayClass: Визначає набір шлюзів зі спільною конфігурацією та керується контролером, який реалізує цей клас.

  • Gateway: Визначає екземпляр інфраструктури обробки трафіку, такої як хмарний балансувальник.

  • HTTPRoute: Визначає правила, специфічні для HTTP, для передачі трафіку з Gateway listener на мережеві точки доступу бекенду. Ці точки доступу часто представлені як Service.

Gateway API організовано за різними видами API, які мають взаємозалежні відносини для підтримки організаційно орієнтованої природи організацій. Обʼєкт Gateway повʼязаний із саме одним GatewayClass; GatewayClass описує контролер шлюзу, відповідального за керування шлюзами цього класу. Один чи кілька видів маршрутів, таких як HTTPRoute, потім повʼязуються з Gateways. Gateway може фільтрувати маршрути, які можуть бути прикріплені до його слухачів, утворюючи двоспрямовану довірчу модель з маршрутами.

Наступна схема ілюструє звʼязок між трьома стабільними видами Gateway API:

graph LR; subgraph cluster["Кластер"] direction LR HTTPRoute --> Gateway; Gateway --> GatewayClass; end classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000; classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5; class HTTPRoute,Gateway,GatewayClass k8s; class cluster cluster;

GatewayClass

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

Мінімальний приклад GatewayClass:

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: example-class
spec:
  controllerName: example.com/gateway-controller

У цьому прикладі контролер, який реалізував Gateway API, налаштований для управління GatewayClasses з іменем контролера example.com/gateway-controller. Шлюзи цього класу будуть керуватися контролером реалізації.

Дивіться специфікацію GatewayClass для повного визначення цього виду API.

Gateway

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

Мінімальний приклад ресурсу Gateway:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: example-gateway
spec:
  gatewayClassName: example-class
  listeners:
  - name: http
    protocol: HTTP
    port: 80

У цьому прикладі екземпляр інфраструктури обробки трафіку програмується на прослуховування HTTP-трафіку на порту 80. Оскільки поле addresses не вказано, адреса чи імʼя хосту надається Gateway контролером реалізації. Ця адреса використовується як мережева точка доступу для обробки трафіку бекенду, визначеного в маршрутах.

Дивіться специфікацію Gateway для повного визначення цього виду API.

HTTPRoute

Вид HTTPRoute визначає поведінку маршрутизації HTTP-запитів від слухача Gateway до бекенду мережевих точок доступу. Для бекенду Service реалізація може представляти мережеву точку доступу як IP-адресу Service чи поточні Endpointʼи Service. HTTPRoute представляє конфігурацію, яка застосовується до внутрішньої реалізації Gateway. Наприклад, визначення нового HTTPRoute може призвести до налаштування додаткових маршрутів трафіку в хмарному балансувальнику або внутрішньому проксі-сервері.

Мінімальний приклад HTTPRoute:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: example-httproute
spec:
  parentRefs:
  - name: example-gateway
  hostnames:
  - "www.example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /login
    backendRefs:
    - name: example-svc
      port: 8080

У цьому прикладі HTTP-трафік від Gateway example-gateway із заголовком Host: www.example.com та вказаним шляхом запиту /login буде направлений до Service example-svc на порт 8080.

Дивіться специфікацію HTTPRoute для повного визначення цього виду API.

Потік запитів

Ось простий приклад маршрутизації HTTP-трафіку до Service за допомогою Gateway та HTTPRoute:

graph LR; client([клієнт])-. HTTP
запит .->Gateway; Gateway-->HTTPRoute; HTTPRoute-->|Правила
маршрутизації|Service; Service-->pod1[Pod]; Service-->pod2[Pod]; classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000; classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5; class Gateway,HTTPRoute,Service,pod1,pod2 k8s; class client plain; class cluster cluster;

У цьому прикладі потік запиту для Gateway, реалізованого як зворотний проксі, є таким:

  1. Клієнт починає готувати HTTP-запит для URL http://www.example.com
  2. DNS-resolver клієнта запитує імʼя призначення та дізнається про звʼязок між однією чи кількома IP-адресами, повʼязаними з Gateway.
  3. Клієнт надсилає запит на IP-адресу Gateway; зворотній проксі отримує HTTP запит і використовує заголовок Host: заголовок має збігатись з налаштуваннями, які були отримані від Gateway та прикріпленого HTTPRoute. Опційно зворотній проксі може виконати порівняння заголовків або шляху запиту на основі правил відповідності HTTPRoute.
  4. Опційно зворотній проксі може змінювати запит; наприклад, додавати чи видаляти заголовки, відповідно до правил фільтрації HTTPRoute.
  5. Наприкінці зворотній проксі пересилає запит на один чи кілька бекендів.

Відповідність

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

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

Міграція з Ingress

Gateway API є наступником Ingress API. Однак він не включає вид Ingress. Внаслідок цього необхідно провести одноразове перетворення з наявних ресурсів Ingress на ресурси Gateway API.

Дивіться посібник з міграції з Ingress для отримання деталей щодо міграції ресурсів Ingress на ресурси Gateway API.

Що далі

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

Дивіться специфікацію API для отримання додаткових деталей про всі види API Gateway API.

3.5.5 - EndpointSlices

API EndpointSlice — це механізм, який Kubernetes використовує, щоб ваш Service масштабувався для обробки великої кількості бекендів і дозволяє кластеру ефективно оновлювати свій список справних бекендів.
СТАН ФУНКЦІОНАЛУ: Kubernetes v1.21 [stable]

EndpointSlice API Kubernetes надає можливість відстежувати мережеві точки доступу в межах кластера Kubernetes. EndpointSlices пропонують більш масштабований та розширюваний альтернативний варіант Endpoints.

EndpointSlice API

У Kubernetes, EndpointSlice містить посилання на набір мережевих точок доступу. Панель управління автоматично створює EndpointSlices для будь-якої служби Kubernetes, яка має вказаний селектор. Ці EndpointSlices містять посилання на всі Podʼи, які відповідають селектору Service. EndpointSlices групують мережеві точки доступу за унікальними комбінаціями протоколу, номеру порту та імені Service. Імʼя обʼєкта EndpointSlice повинно бути дійсним імʼям піддомену DNS.

Наприклад, ось приклад обʼєкта EndpointSlice, яким володіє Service Kubernetes з імʼям example.

apiVersion: discovery.k8s.io/v1
kind: EndpointSlice
metadata:
  name: example-abc
  labels:
    kubernetes.io/service-name: example
addressType: IPv4
ports:
  - name: http
    protocol: TCP
    port: 80
endpoints:
  - addresses:
      - "10.1.2.3"
    conditions:
      ready: true
    hostname: pod-1
    nodeName: node-1
    zone: us-west2-a

Типово, панель управління створює та керує EndpointSlices так, щоб в кожному з них було не більше 100 мережевих точок доступу. Це можна налаштувати за допомогою прапорця --max-endpoints-per-slice kube-controller-manager, до максимуму 1000.

EndpointSlices можуть виступати джерелом правди для kube-proxy щодо того, як маршрутизувати внутрішній трафік.

Типи адрес

EndpointSlices підтримують три типи адрес:

  • IPv4
  • IPv6
  • FQDN (Fully Qualified Domain Name — Повністю Кваліфіковане Доменне Імʼя)

Кожен обʼєкт EndpointSlice представляє конкретний тип IP-адреси. Якщо у вас є Service, який доступний через IPv4 та IPv6, буде принаймні два обʼєкти EndpointSlice (один для IPv4 та один для IPv6).

Стани

API EndpointSlice зберігає стани точок доступу, які можуть бути корисні для споживачів. Три стани: ready, serving та terminating.

Ready

ready — це стан, який відповідає стану Ready Pod. Запущений Pod зі станом Ready встановленим в True повинен мати стан ready також встановлений в true. З міркувань сумісності, ready НІКОЛИ не буває true, коли Pod видаляється. Споживачі повинні звертатися до стану serving, щоб перевірити готовність Podʼів, які видаляються. Єдиний виняток є для Services з spec.publishNotReadyAddresses, встановленим в true. Podʼи для цих служб завжди матимуть стан ready, встановлений в true.

Serving

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

Стан serving майже ідентичний стану ready. Різниця полягає в тому, що споживачі API EndpointSlice повинні перевіряти стан serving, якщо їм важливо перевірити готовність Podʼів в той час, коли Pod також примусово припиняє свою роботу.

Terminating

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

Terminating — це стан, що вказує, чи Pod видаляється. Для Podʼів це буде будь-який Pod з встановленою часовою міткою видалення.

Інформація про топологію

Кожна точка доступу в межах EndpointSlice може містити відповідну інформацію про топологію. Інформація про топологію включає місцезнаходження точки доступу та інформацію про відповідний вузол та зону. Ця інформація доступна в наступних полях на кожній кінцевій точці в EndpointSlices:

  • nodeName — Назва вузла, на якому знаходиться ця точка доступу.
  • zone — Зона, в якій знаходиться ця точка доступу.

Управління

Зазвичай обʼєкти EndpointSlice створюються та керуються панеллю управління зокрема, контролером EndpointSlice. Є різноманітні інші випадки використання EndpointSlices, такі як реалізації Service mesh, які можуть призвести до інших сутностей або контролерів, які керують додатковими наборами EndpointSlices.

Щоб забезпечити можливість кількох сутностей керувати EndpointSlices без взаємодії одна з одною, Kubernetes визначає label endpointslice.kubernetes.io/managed-by, яка вказує сутність, яка керує EndpointSlice. Контролер встановлює значення endpointslice-controller.k8s.io для цієї мітки на всіх точках доступу, якими він керує. Інші сутності, які керують EndpointSlices, також повинні встановити унікальне значення для цієї мітки.

Власність

У більшості випадків EndpointSlices належать Service, за яким обʼєкт EndpointSlices стежить для виявлення точок доступу. Право власності вказується власником посиланням на кожен EndpointSlice, а також міткою kubernetes.io/service-name для простого пошуку всіх EndpointSlices, які належать Service.

Віддзеркалення EndpointSlice

У деяких випадках застосунки створюють власні ресурси Endpoints. Щоб забезпечити що ці застосунки не повинні одночасно записувати як в ресурси Endpoints, так і в ресурси EndpointSlice, панель управління кластера віддзеркалює більшість ресурсів Endpoints на відповідні ресурси EndpointSlices.

Панель управління віддзеркалює ресурси Endpoints, якщо:

  • ресурс Endpoints має мітку endpointslice.kubernetes.io/skip-mirror встановлену в true.
  • ресурс Endpoints має анотацію control-plane.alpha.kubernetes.io/leader.
  • відповідний ресурс Service не існує.
  • відповідний ресурс Service має ненульовий селектор.

Окремі ресурси Endpoints можуть транслюватись в кілька ресурсів EndpointSlices. Це може відбуватись, якщо ресурс Endpoints має кілька підмножин або включає точки доступу з кількома сімействами IP (IPv4 та IPv6). Максимально 1000 адрес на підмножину буде віддзеркалено на EndpointSlices.

Розподіл EndpointSlices

Кожен EndpointSlice має набір портів, які застосовуються до всіх точок доступу ресурсу. При використанні іменованих портів для Service, Podʼи можуть мати різні номери цільового порту для того самого іменованого порту, що вимагає різних EndpointSlices. Це схоже на логіку того, як підмножини групуються з Endpoints.

Панель управління намагається заповнити EndpointSlices так повно, як це можливо, але не активно перерозподіляє їх. Логіка досить проста:

  1. Пройдіться по наявних EndpointSlices, вилучіть точки доступу, які вже не потрібні, і оновіть відповідні точки, які змінилися.
  2. Пройдіться по EndpointSlices, які були змінені на першому етапі, і заповніть їх будь-якими новими точками доступу, які потрібно додати.
  3. Якщо ще залишилися нові точки доступу для додавання, спробуйте додати їх в раніше не змінений EndpointSlice та/або створіть новий.

Важливо, що третій крок надає пріоритет обмеженню оновлень EndpointSlice над ідеально повним розподілом EndpointSlices. Наприклад, якщо є 10 нових точок доступу для додавання та 2 EndpointSlices з простором для ще 5 точок доступу кожна, цей підхід створить новий EndpointSlice замість заповнення 2 наявних EndpointSlices. Іншими словами, одне створення EndpointSlice краще, ніж кілька оновлень EndpointSlice.

З kube-proxy, який працює на кожному вузлі та слідкує за EndpointSlices, кожна зміна EndpointSlice стає відносно дорогою, оскільки вона буде передана кожному вузлу в кластері. Цей підхід призначений для обмеження кількості змін, які потрібно надіслати кожному вузлу, навіть якщо це може призвести до декількох EndpointSlices, які не є повністю заповненими.

На практиці це рідко трапляється. Більшість змін опрацьовуються контролером EndpointSlice буде достатньо малою, щоб поміститися в наявний EndpointSlice, і якщо ні, новий EndpointSlice, ймовірно, буде потрібен невдовзі. Поступові оновлення Deploymentʼів також надають природню перепаковку EndpointSlices з всіма Podʼами та їх відповідними точками доступу, що заміняються.

Дублікати endpoints

Через характер змін EndpointSlice точки доступу можуть бути представлені в більш ніж одному EndpointSlice одночасно. Це, природно, відбувається, оскільки зміни до різних обʼєктів EndpointSlice можуть надходити до клієнта Kubernetes watch / cache в різний час.

Порівняння з Endpoints

Оригінальний API Endpoints надавав простий і зрозумілий спосіб відстеження мережевих точок доступу в Kubernetes. Однак з ростом кластерів Kubernetes та Serviceʼів, які обробляють більше трафіку і надсилають трафік до більшої кількості підзадач, обмеження оригінального API стали більш помітними. Зокрема, до них входили проблеми масштабування до більшої кількості мережевих точок доступу.

Оскільки всі мережеві точки доступу для Service зберігалися в одному ресурсі Endpoints, ці обʼєкти Endpoints могли бути досить великими. Для служб, які залишалися стабільними (тобто тим самим набором точок доступу протягом тривалого періоду часу), вплив був менше помітний; навіть тоді деякі випадки використання Kubernetes працювали не дуже добре.

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

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

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

Що далі

3.5.6 - Мережеві політики

Якщо ви хочете контролювати потік трафіку на рівні IP-адреси чи порту (рівень OSI 3 або 4), мережеві політики Kubernetes дозволяють вам визначати правила потоку трафіку всередині вашого кластера, а також між Podʼами та зовнішнім світом. Ваш кластер повинен використовувати мережевий втулок, який підтримує NetworkPolicy.

Якщо ви хочете контролювати потік трафіку на рівні IP-адреси чи порту для протоколів TCP, UDP та SCTP, то вам, можливо, варто розглянути використання NetworkPolicies Kubernetes для конкретних застосунків у вашому кластері. NetworkPolicies — це конструкт, орієнтований на застосунок, який дозволяє вам визначати, як Pod може взаємодіяти з різними мережевими "сутностями" (ми використовуємо тут слово "сутність", щоб уникнути перевантаження більш загальноприйнятими термінами, такими як "Endpoints" та "Services", які мають конкретні конотації Kubernetes) мережею. NetworkPolicies – застосовується до зʼєднання з Pod на одному або обох кінцях і не має відношення до інших зʼєднань.

Сутності, з якими може взаємодіяти Pod, ідентифікуються за допомогою комбінації наступних трьох ідентифікаторів:

  1. Інші дозволені Podʼи (виняток: Pod не може блокувати доступ до себе самого)
  2. Дозволені простори імен
  3. IP-блоки (виняток: трафік до та від вузла, де працює Pod, завжди дозволений, незалежно від IP-адреси Podʼа чи вузла)

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

Тим часом при створенні мережевих політик на основі IP ми визначаємо політику на основі IP-блоків (діапазони CIDR).

Передумови

Мережеві політики впроваджуються мережевим втулком. Для використання мережевих політик вам слід використовувати рішення з підтримкою NetworkPolicy. Створення ресурсу NetworkPolicy без контролера, який його реалізує, не матиме ефекту.

Два види ізоляції для Podʼів

Існують два види ізоляції для Podʼа: ізоляція для вихідного трафіку (egress) та ізоляція для вхідного трафіку (ingress). Це стосується того, які зʼєднання можуть бути встановлені. Тут "ізоляція" не є абсолютною, але означає "діють деякі обмеження". Альтернатива, "non-isolated for $direction", означає, що в зазначеному напрямку обмеження відсутні. Два види ізоляції (або ні) декларуються незалежно та є важливими для підключення від одного Podʼа до іншого.

Типово Pod не є ізольованим для вихідного трафіку (egress); всі вихідні зʼєднання дозволені. Pod ізольований для вихідного трафіку, якщо є будь-яка мережева політика, яка одночасно вибирає Pod і має "Egress" у своєму policyTypes; ми кажемо, що така політика застосовується до Podʼа для вихідного трафіку. Коли Pod ізольований для вихідного трафіку, єдині дозволені зʼєднання з Podʼа — ті, які дозволені списком egress деякої мережевої політики, яка застосовується до Podʼа для вихідного трафіку. Також буде неявно дозволений вихідний трафік для цих дозволених зʼєднань. Ефекти цих списків egress обʼєднуються адитивно.

Типово Pod не є ізольованим для вхідного трафіку (ingress); всі вхідні зʼєднання дозволені. Pod ізольований для вхідного трафіку, якщо є будь-яка мережева політика, яка одночасно вибирає Pod і має "Ingress" у своєму policyTypes; ми кажемо, що така політика застосовується до Podʼа для вхідного трафіку. Коли Pod ізольований для вхідного трафіку, єдині дозволені зʼєднання до Podʼа - ті, що з вузла Podʼа та ті, які дозволені списком ingress деякої мережевої політики, яка застосовується до Podʼа для вхідного трафіку. Також буде неявно дозволений вхідний трафік для цих дозволених зʼєднань. Ефекти цих списків ingress обʼєднуються адитивно.

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

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

Ресурс NetworkPolicy

Для повного визначення ресурсу дивіться посилання на NetworkPolicy.

Приклад NetworkPolicy може виглядати наступним чином:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      role: db
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - ipBlock:
        cidr: 172.17.0.0/16
        except:
        - 172.17.1.0/24
    - namespaceSelector:
        matchLabels:
          project: myproject
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 6379
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/24
    ports:
    - protocol: TCP
      port: 5978

Обовʼязкові поля: Як і з усіма іншими конфігураціями Kubernetes, для NetworkPolicy потрібні поля apiVersion, kind та metadata. Для загальної інформації щодо роботи з конфігураційними файлами дивіться Налаштування Pod для використання ConfigMap та Управління обʼєктами.

spec: Специфікація мережевої політики spec містить всю інформацію, необхідну для визначення конкретної мережевої політики в заданому просторі імен.

podSelector: Кожна NetworkPolicy включає podSelector, який вибирає групу Podʼів, до яких застосовується політика. У прикладі політики вибираються Podʼи з міткою "role=db". Порожній podSelector вибирає всі Podʼи в просторі імен.

policyTypes: Кожна NetworkPolicy включає список policyTypes, який може містити або Ingress, або Egress, або обидва. Поле policyTypes вказує, чи політика застосовується, чи ні до трафіку ingress до вибраних Podʼів, трафіку egress від вибраних Podʼів чи обох. Якщо на NetworkPolicy не вказано жодних policyTypes, то станадартно буде завжди встановлено Ingress, а Egress буде встановлено, якщо у NetworkPolicy є хоча б одне правило egress.

ingress: Кожна NetworkPolicy може включати список дозволених правил ingress. Кожне правило дозволяє трафіку, який відповідає як from, так і секції ports. У прикладі політики є одне правило, яке відповідає трафіку на одному порту від одного з трьох джерел: перше вказано через ipBlock, друге через namespaceSelector, а третє через podSelector.

egress: Кожна NetworkPolicy може включати список дозволених правил egress. Кожне правило дозволяє трафіку, який відповідає як секції to, так і ports. У прикладі політики є одне правило, яке відповідає трафіку на одному порту до будь-якого призначення в 10.0.0.0/24.

Отже, приклад NetworkPolicy:

  1. ізолює Podʼи role=db в просторі імен default для трафіку як ingress, так і egress (якщо вони ще не були ізольовані)

  2. (Правила Ingress) дозволяє підключення до всіх Podʼів в просторі імен default з міткою role=db на TCP-порт 6379 від:

    • будь-якого Pod в просторі імен default з міткою role=frontend
    • будь-якого Pod в просторі імені з міткою project=myproject
    • IP-адреси в діапазонах 172.17.0.0172.17.0.255 nf 172.17.2.0172.17.255.255 (тобто, усе 172.17.0.0/16, за винятком 172.17.1.0/24)
  3. (Правила Egress) дозволяє підключення з будь-якого Pod в просторі імен default з міткою role=db до CIDR 10.0.0.0/24 на TCP-порт 5978

Дивіться Оголошення мережевої політики для ознайомлення з додатковими прикладами.

Поведінка селекторів to та from

Існує чотири види селекторів, які можна вказати в розділі from для ingress або to для egress:

podSelector: Вибирає певні Podʼи в тому ж просторі імен, що і NetworkPolicy, які мають бути допущені як джерела ingress або призначення egress.

namespaceSelector: Вибирає певні простори імен, для яких всі Podʼи повинні бути допущені як джерела ingress або призначення egress.

namespaceSelector та podSelector: Один елемент to/from, який вказує як namespaceSelector, так і podSelector, вибирає певні Podʼи в певних просторах імен. Будьте уважні при використанні правильного синтаксису YAML. Наприклад:

  ...
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          user: alice
      podSelector:
        matchLabels:
          role: client
  ...

Ця політика містить один елемент from, який дозволяє підключення від Podʼів з міткою role=client в просторах імен з міткою user=alice. Але наступна політика відрізняється:

  ...
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          user: alice
    - podSelector:
        matchLabels:
          role: client
  ...

Вона містить два елементи у масиві from та дозволяє підключення від Podʼів у локальному просторі імен з міткою role=client, або від будь-якого Podʼа в будь-якому просторі імен з міткою user=alice.

У випадку невизначеності використовуйте kubectl describe, щоб переглянути, як Kubernetes інтерпретував політику.

ipBlock: Вибирає певні діапазони IP CIDR для дозволу їх як джерел ingress або призначення egress. Це повинні бути зовнішні для кластера IP, оскільки IP Podʼів є ефемерними та непередбачуваними.

Механізми ingress та egress кластера часто вимагають переписування IP джерела або IP призначення пакетів. У випадках, коли це відбувається, не визначено, чи це відбувається до, чи після обробки NetworkPolicy, і поведінка може бути різною для різних комбінацій мережевого втулка, постачальника хмарних послуг, реалізації Service тощо.

У випадку ingress це означає, що у деяких випадках ви можете фільтрувати вхідні пакети на основі фактичної вихідної IP, тоді як в інших випадках "вихідна IP-адреса", на яку діє NetworkPolicy, може бути IP LoadBalancer або вузла Podʼа тощо.

Щодо egress це означає, що підключення з Podʼів до IP Service, які переписуються на зовнішні IP кластера, можуть або не можуть підпадати під політику на основі ipBlock.

Стандартні політики

Типово, якщо в просторі імен відсутні будь-які політики, то трафік ingress та egress дозволено до та від Podʼів в цьому просторі імен. Наступні приклади дозволяють змінити стандартну поведінку в цьому просторі імені.

Стандартна заборона всього вхідного трафіку

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

---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
spec:
  podSelector: {}
  policyTypes:
  - Ingress

Це забезпечить ізоляцію вхідного трафіку навіть для Podʼів, які не вибрані жодною іншою NetworkPolicy. Ця політика не впливає на ізоляцію egress трафіку з будь-якого Podʼа.

Дозвіл на весь вхідний трафік

Якщо ви хочете дозволити всі вхідні підключення до всіх Podʼів в просторі імен, ви можете створити політику, яка явно це дозволяє.

---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all-ingress
spec:
  podSelector: {}
  ingress:
  - {}
  policyTypes:
  - Ingress

З цією політикою ніяка додаткова політика або політики не можуть призвести до відмови у ingress підключенні до цих Podʼів. Ця політика не впливає на ізоляцію вихідного трафіку з будь-якого Podʼа.

Стандартна заборона всього вихідного трафіку

Ви можете створити стандартну політику ізоляції вихідного трафіку для простору імен, створивши NetworkPolicy, яка вибирає всі Podʼи, але не дозволяє будь-який egress трафік від цих Podʼів.

---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-egress
spec:
  podSelector: {}
  policyTypes:
  - Egress

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

Дозвіл на весь вихідний трафік

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

---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all-egress
spec:
  podSelector: {}
  egress:
  - {}
  policyTypes:
  - Egress

З цією політикою ніяка додаткова політика або політики не можуть призвести до відмови у вихідному підключенні з цих Podʼів. Ця політика не впливає на ізоляцію ingress трафіку до будь-якого Podʼа.

Стандартна заборона всього вхідного та всього вихідного трафіку

Ви можете створити "стандартну" політику для простору імен, яка забороняє весь ingress та egress трафік, створивши наступний NetworkPolicy в цьому просторі імені.

---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

Це забезпечить те, що навіть Podʼи, які не вибрані жодною іншою NetworkPolicy, не матимуть дозволу на трафік ingress та egress напрямку.

Фільтрація мережевого трафіку

NetworkPolicy визначений для зʼєднань layer 4 (TCP, UDP та за необхідності SCTP). Для всіх інших протоколів поведінка може варіюватися залежно від мережевих втулків.

Коли визначена мережева політика deny all, гарантується тільки відмова в TCP, UDP та SCTP зʼєднаннях. Для інших протоколів, таких як ARP чи ICMP, поведінка невизначена. Те ж саме стосується правил дозволу (allow): коли певний Pod дозволений як джерело ingress або призначення egress, не визначено, що відбувається з (наприклад) пакетами ICMP. Такі протоколи, як ICMP, можуть бути дозволені одними мережевими втулками та відхилені іншими.

Спрямування трафіку на діапазон портів

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

При написанні NetworkPolicy ви можете спрямовувати трафік на діапазон портів, а не на один окремий порт.

Це можливо завдяки використанню поля endPort, як показано в наступному прикладі:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: multi-port-egress
  namespace: default
spec:
  podSelector:
    matchLabels:
      role: db
  policyTypes:
    - Egress
  egress:
    - to:
        - ipBlock:
            cidr: 10.0.0.0/24
      ports:
        - protocol: TCP
          port: 32000
          endPort: 32768

Вищевказане правило дозволяє будь-якому Podʼа з міткою role=db в просторі імен default спілкуватися з будь-яким IP в діапазоні 10.0.0.0/24 по протоколу TCP, при умові, що цільовий порт знаходиться в діапазоні від 32000 до 32768.

Застосовуються наступні обмеження при використанні цього поля:

  • Поле endPort повинно бути рівним або більшим за поле port.
  • endPort може бути визначено тільки в тому випадку, якщо також визначено port.
  • Обидва порти повинні бути числовими значеннями.

Спрямування трафіку на кілька просторів імен за допомогою міток

У цім сценарії ця ваша Egress NetworkPolicy спрямована на більше ніж один простір імен, використовуючи їх мітки. Для цього необхідно додати мітки до цільових просторів імен. Наприклад:

kubectl label namespace frontend namespace=frontend
kubectl label namespace backend namespace=backend

Додайте мітки до namespaceSelector в вашому документі NetworkPolicy. Наприклад:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: egress-namespaces
spec:
  podSelector:
    matchLabels:
      app: myapp
  policyTypes:
  - Egress
  egress:
  - to:
    - namespaceSelector:
        matchExpressions:
        - key: namespace
          operator: In
          values: ["frontend", "backend"]

Спрямування трафіку на простір імен за його іменем

Керівництво Kubernetes встановлює незмінювану мітку kubernetes.io/metadata.name на всі простори імен, значення мітки — це імʼя простору імен.

Хоча NetworkPolicy не може спрямовуватися на простір імен за його іменем з допомогою поля обʼєкта, ви можете використовувати стандартизовану мітку для спрямування на конкретний простір імен.

Життєвий цикл Podʼа

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

Щойно NetworkPolicy оброблено мережевим втулком,

  1. Усі нові Podʼи, які стосуються даної NetworkPolicy, будуть ізольовані перед тим, як їх запустять. Реалізації NetworkPolicy повинні забезпечити, що фільтрація є ефективною впродовж усього життєвого циклу Podʼа, навіть з моменту першого запуску будь-якого контейнера у цьому Podʼі. Оскільки вони застосовуються на рівні Podʼа, NetworkPolicies однаково застосовуються до init-контейнерів, контейнерів-супутників та звичайних контейнерів.

  2. Правила дозволів будуть застосовані, остаточно після правил ізоляції (або можуть бути застосовані одночасно). У найгіршому випадку новий Pod може не мати жодного мережевого зʼєднання взагалі при першому запуску, якщо правила ізоляції вже були застосовані, але правила дозволів ще не були застосовані.

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

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

Кожна NetworkPolicy буде застосована до всіх вибраних Podʼів врешті-решт. Оскільки мережевий втулок може реалізовувати NetworkPolicy розподіленим чином, можливо, що Podʼи можуть бачити трохи неузгоджений вид мережевих політик при першому створенні Podʼа або при зміні Podʼів або політик. Наприклад, новий створений Pod, який повинен бути в змозі досягти як Podʼа на вузлі 1, так і Podʼа на вузлі 2, може знайти, що він може досягати Podʼа А негайно, але не може досягати Podʼа B впродовж кількох секунд.

NetworkPolicy та Podʼи з hostNetwork

Поведінка NetworkPolicy для Podʼів із hostNetwork є невизначеною, але вона повинна обмежуватися двома можливостями:

  • Мережевий втулок може відрізняти трафік Podʼів з hostNetwork від усього іншого трафіку (включаючи можливість відрізняти трафік від різних Podʼів з hostNetwork на тому ж вузлі) та застосовувати NetworkPolicy до Podʼів із hostNetwork, , так само як і до Podʼів мережі Podʼа.
  • Мережевий втулок не може належним чином відрізняти трафік Podʼів із hostNetwork, тому він ігнорує Podʼи з hostNetwork при відповідності podSelector та namespaceSelector. Трафік до/від Podʼів із hostNetwork обробляється так само як і весь інший трафік до/від IP-адреси вузла. (Це найбільш поширена реалізація.)

Це стосується випадків, коли

  1. Pod із hostNetwork вибирається за допомогою spec.podSelector.

      ...
      spec:
        podSelector:
          matchLabels:
            role: client
      ...
    
  2. Pod із hostNetwork вибирається за допомогою podSelector чи namespaceSelector в правилі ingress чи egress.

      ...
      ingress:
        - from:
          - podSelector:
              matchLabels:
                role: client
      ...
    

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

Що ви не можете зробити за допомогою мережевих політик (принаймні, зараз) {#what-you-can't-do-with-network-policies-at-least-not-yet}

В Kubernetes 1.31, наступна функціональність відсутня в API NetworkPolicy, але, можливо, ви зможете реалізувати обходні шляхи, використовуючи компоненти операційної системи (такі як SELinux, OpenVSwitch, IPTables та інші) або технології Layer 7 (контролери Ingress, реалізації Service Mesh) чи контролери допуску. У випадку, якщо ви новачок в мережевому захисті в Kubernetes, варто відзначити, що наступні випадки не можна (ще) реалізувати за допомогою API NetworkPolicy.

  • Примусова маршрутизація внутрішньокластерного трафіку через загальний шлюз (це, можливо, найкраще реалізувати за допомогою сервіс-мешу чи іншого проксі).
  • Будь-яка функціональність, повʼязана з TLS (для цього можна використовувати сервіс-меш чи контролер ingress).
  • Політики, специфічні для вузла (ви можете використовувати нотацію CIDR для цього, але ви не можете визначати вузли за їхніми ідентифікаторами Kubernetes).
  • Спрямування трафіку на service за іменем (проте ви можете спрямовувати трафік на Podʼи чи простори імен за їх мітками, що часто є прийнятним обхідним варіантом).
  • Створення або управління "Policy request", які виконуються третьою стороною.
  • Типові політики, які застосовуються до всіх просторів імен чи Podʼів (є деякі дистрибутиви Kubernetes від сторонніх постачальників та проєкти, які можуть це робити).
  • Розширені засоби надсилання запитів та інструменти перевірки досяжності політики.
  • Можливість ведення логу подій з мережевої безпеки (наприклад, заблоковані чи прийняті зʼєднання).
  • Можливість явно відмовляти в політиках (наразі модель для NetworkPolicy — це типова відмова, з можливістю додавання тільки правил дозволу).
  • Можливість уникнення loopback чи вхідного трафіку від хоста (Podʼи наразі не можуть блокувати доступ до localhost, і вони не мають можливості блокувати доступ від їхнього вузла-резидента).

Вплив мережевих політик на існуючі зʼєднання

Коли набір мережевих політик, які застосовуються до існуючого зʼєднання, змінюється — це може трапитися через зміну мережевих політик або якщо відповідні мітки обраних просторів імен/Podʼів, обраних політикою (як субʼєкт і peers), змінюються під час існуючого зʼєднання — не визначено в реалізації, чи буде врахована зміна для цього існуючого зʼєднання чи ні. Наприклад: створено політику, яка призводить до відмови в раніше дозволеному зʼєднанні, реалізація базового мережевого втулка відповідальна за визначення того, чи буде ця нова політика закривати існуючі зʼєднання чи ні. Рекомендується утримуватися від змін політик/Podʼів/просторів імен таким чином, що може вплинути на існуючі зʼєднання.

Що далі

3.5.7 - DNS для Service та Podʼів

Ваше робоче навантаження може виявляти Serviceʼи всередині вашого кластеру за допомогою DNS; ця сторінка пояснює, як це працює.

Kubernetes створює DNS-записи для Service та Podʼів. Ви можете звертатися до Service за допомогою стійких імен DNS замість IP-адрес.

Kubernetes публікує інформацію про Podʼи та Serviceʼи, яка використовується для налаштування DNS. Kubelet конфігурує DNS Podʼів так, щоб запущені контейнери могли знаходити Service за іменем, а не за IP.

Service, визначеним у кластері, призначаються імена DNS. Типово список пошуку DNS клієнта Pod включає власний простір імен Pod та стандартний домен кластера.

Простори імен Serviceʼів

DNS-запит може повертати різні результати залежно від простору імен Podʼа, який його створив. DNS-запити, які не вказують простір імен, обмежені простором імен Podʼа. Для доступу до Service в інших просторах імен, вказуйте його в DNS-запиті.

Наприклад, розгляньте Pod в просторі імен test. Service data перебуває в просторі імен prod.

Запит для data не повертає результатів, оскільки використовує простір імен Podʼа test.

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

DNS-запити можуть бути розширені за допомогою /etc/resolv.conf Podʼа. Kubelet налаштовує цей файл для кожного Podʼа. Наприклад, запит лише для data може бути розширений до data.test.svc.cluster.local. Значення опції search використовуються для розширення запитів. Щоб дізнатися більше про DNS-запити, див. сторінку довідки resolv.conf.

nameserver 10.32.0.10
search <namespace>.svc.cluster.local svc.cluster.local cluster.local
options ndots:5

Отже, узагальнюючи, Pod у просторі імен test може успішно знаходити як data.prod, так і data.prod.svc.cluster.local.

DNS-записи

Для яких обʼєктів створюються DNS-записи?

  1. Serviceʼи
  2. Podʼи

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

Serviceʼи

Записи A/AAAA

"Звичайні" (не headless) Serviceʼи отримують DNS-запис A та/або AAAA, залежно від IP-сімейства або сімейств Serviceʼів, з імʼям у вигляді my-svc.my-namespace.svc.cluster-domain.example. Це розгортається в кластерний IP Serviceʼу.

Headless Services (без кластерного IP) теж отримують DNS-записи A та/або AAAA, з імʼям у вигляді my-svc.my-namespace.svc.cluster-domain.example. На відміну від звичайних Serviceʼів, це розгортається в набір IP-адрес всіх Podʼів, вибраних Serviceʼом. Очікується, що клієнти будуть використовувати цей набір або використовувати стандартний round-robin вибір із набору.

Записи SRV

Записи SRV створюються для іменованих портів, які є частиною звичайних або headless сервісів. Для кожного іменованого порту запис SRV має вигляд _port-name._port-protocol.my-svc.my-namespace.svc.cluster-domain.example. Для звичайного Serviceʼу це розгортається в номер порту та доменне імʼя: my-svc.my-namespace.svc.cluster-domain.example. Для headless Serviceʼу це розгортається в кілька відповідей, по одній для кожного Podʼа, які підтримує Service, і містить номер порту та доменне імʼя Podʼа у вигляді hostname.my-svc.my-namespace.svc.cluster-domain.example.

Podʼи

Записи A/AAAA

Версії Kube-DNS, до впровадження специфікації DNS, мали наступне DNS-подання:

pod-ipv4-address.my-namespace.pod.cluster-domain.example.

Наприклад, якщо Pod в просторі імен default має IP-адресу 172.17.0.3, а доменне імʼя вашого кластера — cluster.local, то у Podʼа буде DNS-імʼя:

172-17-0-3.default.pod.cluster.local.

Будь-які Podʼи, на які поширюється Service, мають наступний доступ через DNS:

pod-ipv4-address.service-name.my-namespace.svc.cluster-domain.example.

Поля hostname та subdomain Podʼа

Наразі, при створенні Podʼа, його імʼя (як його видно зсередини Podʼа) визначається як значення metadata.name Podʼа.

У специфікації Podʼа є необовʼязкове поле hostname, яке можна використовувати для вказівки відмінного від імʼя Podʼа імені хосту. Коли вказано, воно має пріоритет над іменем Podʼа та стає імʼям хосту Podʼа (знову ж таки, в спостереженнях зсередини Podʼа). Наприклад, якщо у Podʼа вказано spec.hostname зі значенням "my-host", то у Podʼа буде імʼя хосту "my-host".

Специфікація Podʼа також має необовʼязкове поле subdomain, яке може використовуватися для вказівки того, що Pod є частиною підгрупи простору імен. Наприклад, Pod з spec.hostname встановленим на "foo", та spec.subdomain встановленим на "bar", у просторі імен "my-namespace", матиме імʼя хосту "foo" та повністю визначене доменне імʼя (FQDN) "foo.bar.my-namespace.svc.cluster.local" (знову ж таки, в спостереженнях зсередини Podʼа).

Якщо існує headless Service в тому ж просторі імен, що і Pod, із тим самим імʼям, що і піддомен, DNS-сервер кластера також поверне записи A та/або AAAA для повної доменної назви Podʼа.

Приклад:

apiVersion: v1
kind: Service
metadata:
  name: busybox-subdomain
spec:
  selector:
    name: busybox
  clusterIP: None
  ports:
  - name: foo # імʼя не є обовʼязковим для Serviceʼів з одним портом
    port: 1234
---
apiVersion: v1
kind: Pod
metadata:
  name: busybox1
  labels:
    name: busybox
spec:
  hostname: busybox-1
  subdomain: busybox-subdomain
  containers:
  - image: busybox:1.28
    command:
      - sleep
      - "3600"
    name: busybox
---
apiVersion: v1
kind: Pod
metadata:
  name: busybox2
  labels:
    name: busybox
spec:
  hostname: busybox-2
  subdomain: busybox-subdomain
  containers:
  - image: busybox:1.28
    command:
      - sleep
      - "3600"
    name: busybox

У вище наведеному Прикладі, із Service "busybox-subdomain" та Podʼами, які встановлюють spec.subdomain на "busybox-subdomain", перший Pod побачить своє власне FQDN як "busybox-1.busybox-subdomain.my-namespace.svc.cluster-domain.example". DNS повертає записи A та/або AAAA під цим іменем, що вказують на IP-адресу Podʼа. Обидва Podʼа "busybox1" та "busybox2" матимуть свої власні записи адрес.

EndpointSlice може визначати DNS-hostname для будь-якої адреси endpoint, разом з його IP.

Поле setHostnameAsFQDN Podʼа

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

Коли Pod налаштовано так, що він має повне доменне імʼя (FQDN), його імʼя хосту — це коротке імʼя хосту. Наприклад, якщо у вас є Pod із повним доменним імʼям busybox-1.busybox-subdomain.my-namespace.svc.cluster-domain.example, то стандартно команда hostname в цьому Podʼі повертає busybox-1, а команда hostname --fqdn повертає FQDN.

Коли ви встановлюєте setHostnameAsFQDN: true у специфікації Podʼа, kubelet записує FQDN Podʼа в імʼя хосту для простору імен цього Podʼа. У цьому випадку як hostname, так і hostname --fqdn повертають FQDN Podʼа.

Політика DNS Podʼа

Політику DNS можна встановлювати для кожного Podʼа окремо. Наразі Kubernetes підтримує наступні політики DNS, вказані у полі dnsPolicy в специфікації Podʼа:

  • "Default": Pod успадковує конфігурацію розпізнавання імені від вузла, на якому працюють Podʼи. Деталі можна переглянути у відповідному описі.
  • "ClusterFirst": Будь-який DNS-запит, який не відповідає налаштованому суфіксу домену кластера, такому як "www.kubernetes.io", пересилається на вихідний DNS-сервер DNS-сервером. Адміністратори кластера можуть мати додаткові налаштовані піддомени та вихідні DNS-сервери. Деталі щодо обробки DNS-запитів у цих випадках можна знайти відповідному дописі.
  • "ClusterFirstWithHostNet": Для Podʼів, які працюють із hostNetwork, ви повинні явно встановити для них політику DNS "ClusterFirstWithHostNet". В іншому випадку Podʼи, що працюють із hostNetwork та "ClusterFirst", будуть використовувати поведінку політики "Default".
    • Примітка: Це не підтримується в Windows. Деталі дивіться нижче.
  • "None": Це дозволяє Podʼу ігнорувати налаштування DNS з оточення Kubernetes. Всі налаштування DNS повинні надаватися за допомогою поля dnsConfig у специфікації Podʼа. Деталі дивіться у підрозділі DNS-конфігурація Podʼа нижче.

Наведений нижче приклад показує Pod із встановленою політикою DNS "ClusterFirstWithHostNet", оскільки у нього встановлено hostNetwork в true.

apiVersion: v1
kind: Pod
metadata:
  name: busybox
  namespace: default
spec:
  containers:
  - image: busybox:1.28
    command:
      - sleep
      - "3600"
    imagePullPolicy: IfNotPresent
    name: busybox
  restartPolicy: Always
  hostNetwork: true
  dnsPolicy: ClusterFirstWithHostNet

Конфігурація DNS для Podʼа

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

Конфігурація DNS для Podʼа дозволяє користувачам мати більше контролю над налаштуваннями DNS для конкретного Podʼа.

Поле dnsConfig є необовʼязковим і може використовуватися з будь-якими налаштуваннями dnsPolicy. Однак, коли поле dnsPolicy Podʼа встановлено в "None", поле dnsConfig повинно бути вказано.

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

  • nameservers: список IP-адрес, які будуть використовуватися як DNS-сервери для Podʼа. Можна вказати не більше 3 IP-адрес, але коли політика DNS Podʼа встановлена на "None", список повинен містити принаймні одну IP-адресу, інакше ця властивість є необовʼязковою. Зазначені сервери будуть обʼєднані з базовими серверами, згенерованими з вказаною політикою DNS, з вилученням дубльованих адрес.
  • searches: список доменів пошуку DNS для пошуку імен в хостах у Podʼі. Ця властивість є необовʼязковою. При вказанні, вказаний список буде обʼєднаний з базовими доменами пошуку, згенерованими з вибраної політики DNS. Дубльовані доменні імена вилучаються. Kubernetes дозволяє до 32 доменів пошуку.
  • options: необовʼязковий список обʼєктів, де кожний обʼєкт може мати властивість name (обовʼязкова) і властивість value (необовʼязкова). Зміст цієї властивості буде обʼєднаний з параметрами, згенерованими з вказаної політики DNS. Дубльовані елементи вилучаються.

Тут наведено приклад Podʼа з власними налаштуваннями DNS:

apiVersion: v1
kind: Pod
metadata:
  namespace: default
  name: dns-example
spec:
  containers:
    - name: test
      image: nginx
  dnsPolicy: "None"
  dnsConfig:
    nameservers:
      - 192.0.2.1 # тут адреса для прикладу
    searches:
      - ns1.svc.cluster-domain.example
      - my.dns.search.suffix
    options:
      - name: ndots
        value: "2"
      - name: edns0

Коли створюється Pod, контейнер test отримує наступний зміст у своєму файлі /etc/resolv.conf:

nameserver 192.0.2.1
search ns1.svc.cluster-domain.example my.dns.search.suffix
options ndots:2 edns0

Для налаштування IPv6 шляху пошуку та сервера імен слід встановити:

kubectl exec -it dns-example -- cat /etc/resolv.conf

Вивід буде подібний до наступного:

nameserver 2001:db8:30::a
search default.svc.cluster-domain.example svc.cluster-domain.example cluster-domain.example
options ndots:5

Обмеження списку доменів пошуку DNS

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

Kubernetes сам по собі не обмежує конфігурацію DNS до тих пір, поки довжина списку доменів пошуку не перевищить 32 або загальна довжина всіх доменів пошуку не перевищить 2048. Це обмеження стосується файлу конфігурації резолвера вузла, конфігурації DNS Podʼа та обʼєднаної конфігурації DNS відповідно.

DNS на вузлах з операційною системою Windows

  • ClusterFirstWithHostNet не підтримується для Podʼів, які працюють на вузлах з операційною системою Windows. У Windows всі імена з крапкою . розглядаються як повністю кваліфіковані та пропускають розгортання FQDN.
  • На Windows існують кілька резолверів DNS, які можна використовувати. Оскільки вони мають трохи відмінну поведінку, рекомендується використовувати Resolve-DNSName для отримання імені.
  • У Linux у вас є список суфіксів DNS, який використовується після того, як розгортання імені як повністю кваліфіковане не вдалося. У Windows можна вказати лише 1 суфікс DNS, який є суфіксом DNS, повʼязаним з простором імен цього Podʼа (наприклад, mydns.svc.cluster.local). Windows може розгортати FQDN, служби або мережеве імʼя, яке може бути розгорнуто за допомогою цього єдиного суфікса. Наприклад, Pod, створений у просторі імен default, матиме суфікс DNS default.svc.cluster.local. Всередині Windows імʼя Podʼа можна розгортати як kubernetes.default.svc.cluster.local, так і kubernetes, але не в частково кваліфіковані імена (kubernetes.default або kubernetes.default.svc).

Що далі

Для керівництва щодо адміністрування конфігурацій DNS дивіться Налаштування служби DNS

3.5.8 - Подвійний стек IPv4/IPv6

Kubernetes дозволяє налаштувати мережеве зʼєднання з одним стеком IPv4, з одним стеком IPv6 або з подвійним стеком з обома сімействами мереж. Ця сторінка пояснює, як це зробити.
СТАН ФУНКЦІОНАЛУ: Kubernetes v1.23 [stable]

Двостекова мережа IPv4/IPv6 дозволяє виділяти як адреси IPv4, так і IPv6 для Podʼів та Serviceʼів.

Двостекова мережа IPv4/IPv6 є стандартно увімкненою у вашому кластері Kubernetes починаючи з версії 1.21, що дозволяє одночасно призначати адреси як IPv4, так і IPv6.

Підтримувані функції

Двостекова мережа IPv4/IPv6 у вашому кластері Kubernetes надає наступні можливості:

  • Мережа Pod із двома стеками (призначення адреси IPv4 і IPv6 на один Pod)
  • Serviceʼи з підтримкою IPv4 і IPv6
  • Маршрутизація egress Pod за межі кластера (наприклад, в Інтернет) через інтерфейси IPv4 та IPv6

Передумови

Для використання двостекових кластерів Kubernetes IPv4/IPv6 потрібні наступні передумови:

  • Kubernetes 1.20 або новіше

    Для отримання інформації щодо використання двостекових Serviceʼів із попередніми версіями Kubernetes, дивіться документацію для відповідної версії Kubernetes.

  • Підтримка постачальником двостекової мережі (постачальник хмари або інший повинен забезпечити вузлам Kubernetes маршрутизовані мережеві інтерфейси IPv4/IPv6)

  • Мережевий втулок, який підтримує двостекову мережу.

Налаштування двостекової мережі IPv4/IPv6

Щоб налаштувати подвійний стек IPv4/IPv6, встановіть призначення мережі кластера з подвійним стеком:

  • kube-apiserver:
    • --service-cluster-ip-range=<CIDR IPv4>,<CIDR IPv6>
  • kube-controller-manager:
    • --cluster-cidr=<CIDR IPv4>,<CIDR IPv6>
    • --service-cluster-ip-range=<CIDR IPv4>,<CIDR IPv6>
    • --node-cidr-mask-size-ipv4|--node-cidr-mask-size-ipv6 типово /24 для IPv4 та /64 для IPv6
  • kube-proxy:
    • --cluster-cidr=<CIDR IPv4>,<CIDR IPv6>
  • kubelet:
    • --node-ip=<IP IPv4>,<IP IPv6>
      • Ця опція є обовʼязковою для bare metal двостекових вузлів (вузлів, які не визначають постачальника хмари прапорцем --cloud-provider). Якщо ви використовуєте постачальника хмари та вирішили перевизначити IP-адреси вузлів, визначені постачальником хмари, встановіть опцію --node-ip.
      • (Вбудовані застарілі постачальники хмари не підтримують двостековий параметр --node-ip.)

Serviceʼи

Ви можете створювати Serviceʼи, які можуть використовувати адреси IPv4, IPv6 або обидві.

Сімейство адрес Service типово відповідає сімейству адрес першого діапазону IP Service кластера (налаштованого через прапорець --service-cluster-ip-range у kube-apiserver).

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

  • SingleStack: Service з одним стеком. Панель управління виділяє IP кластера для Service, використовуючи перший налаштований діапазон IP кластера для Service.
  • PreferDualStack: Виділяє IP-адреси кластерів IPv4 та IPv6 для Service, коли ввімкнено подвійний стек. Якщо подвійний стек не ввімкнено або не підтримується, він повертається до одностекового режиму.
  • RequireDualStack: Виділяє IP-адреси Service .spec.clusterIP з діапазонів адрес IPv4 та IPv6, якщо увімкнено подвійний стек. Якщо подвійний стек не ввімкнено або не підтримується, створення обʼєкта Service API завершиться невдачею.
    • Вибирає .spec.clusterIP зі списку .spec.clusterIPs на основі сімейства адрес першого елемента у масиві .spec.ipFamilies.

Якщо ви хочете визначити, яке сімейство IP використовувати для одностекової конфігурації або визначити порядок IP для двостекової, ви можете вибрати сімейства адрес, встановивши необовʼязкове поле .spec.ipFamilies в Service.

Ви можете встановити .spec.ipFamilies в будь-яке з наступних значень масиву:

  • ["IPv4"]
  • ["IPv6"]
  • ["IPv4","IPv6"] (два стеки)
  • ["IPv6","IPv4"] (два стеки)

Перше сімейство, яке ви перераховуєте, використовується для легасі-поля .spec.clusterIP.

Сценарії конфігурації двостекового Service

Ці приклади демонструють поведінку різних сценаріїв конфігурації двостекового Service.

Параметри подвійного стека в нових Service

  1. Специфікація цього Service явно не визначає .spec.ipFamilyPolicy. Коли ви створюєте цей Service, Kubernetes виділяє кластерний IP для Service з першого налаштованого service-cluster-ip-range та встановлює значення .spec.ipFamilyPolicy на SingleStack. (Service без селекторів та headless Services із селекторами будуть працювати так само.)

    apiVersion: v1
    kind: Service
    metadata:
      name: my-service
      labels:
        app.kubernetes.io/name: MyApp
    spec:
      selector:
        app.kubernetes.io/name: MyApp
      ports:
        - protocol: TCP
          port: 80
    
  2. Специфікація цього Service явно визначає PreferDualStack в .spec.ipFamilyPolicy. Коли ви створюєте цей Service у двостековому кластері, Kubernetes призначає як IPv4, так і IPv6 адреси для Service. Панель управління оновлює .spec для Service, щоб зафіксувати адреси IP. Поле .spec.clusterIPs є основним полем і містить обидві призначені адреси IP; .spec.clusterIP є вторинним полем зі значенням, обчисленим з .spec.clusterIPs.

    • Для поля .spec.clusterIP панель управління записує IP-адресу, яка є з того ж самого сімейства адрес, що й перший діапазон кластерних IP Service.
    • У одностековому кластері поля .spec.clusterIPs та .spec.clusterIP містять лише одну адресу.
    • У кластері з увімкненими двома стеками вказання RequireDualStack в .spec.ipFamilyPolicy працює так само як і PreferDualStack.
    apiVersion: v1
    kind: Service
    metadata:
      name: my-service
      labels:
        app.kubernetes.io/name: MyApp
    spec:
      ipFamilyPolicy: PreferDualStack
      selector:
        app.kubernetes.io/name: MyApp
      ports:
        - protocol: TCP
          port: 80
    
  3. Специфікація цього Service явно визначає IPv6 та IPv4 в .spec.ipFamilies, а також визначає PreferDualStack в .spec.ipFamilyPolicy. Коли Kubernetes призначає IPv6 та IPv4 адреси в .spec.clusterIPs, .spec.clusterIP встановлюється на IPv6 адресу, оскільки це перший елемент у масиві .spec.clusterIPs, що перевизначає типові значення.

    apiVersion: v1
    kind: Service
    metadata:
      name: my-service
      labels:
        app.kubernetes.io/name: MyApp
    spec:
      ipFamilyPolicy: PreferDualStack
      ipFamilies:
      - IPv6
      - IPv4
      selector:
        app.kubernetes.io/name: MyApp
      ports:
        - protocol: TCP
          port: 80
    

Параметри подвійного стека в наявних Service

Ці приклади демонструють типову поведінку при увімкненні двостековості в кластері, де вже існують Service. (Оновлення наявного кластера до версії 1.21 або новіше вмикає двостековість.)

  1. Коли двостековість увімкнена в кластері, наявні Service (безперебійно IPv4 або IPv6) конфігуруються панеллю управління так, щоб встановити .spec.ipFamilyPolicy на SingleStack та встановити .spec.ipFamilies на сімейство адрес наявного Service. Кластерний IP наявного Service буде збережено в .spec.clusterIPs.

    apiVersion: v1
    kind: Service
    metadata:
      name: my-service
      labels:
        app.kubernetes.io/name: MyApp
    spec:
      selector:
        app.kubernetes.io/name: MyApp
      ports:
        - protocol: TCP
          port: 80
    

    Ви можете перевірити цю поведінку за допомогою kubectl, щоб переглянути наявний Service.

    kubectl get svc my-service -o yaml
    
    apiVersion: v1
    kind: Service
    metadata:
      labels:
        app.kubernetes.io/name: MyApp
      name: my-service
    spec:
      clusterIP: 10.0.197.123
      clusterIPs:
      - 10.0.197.123
      ipFamilies:
      - IPv4
      ipFamilyPolicy: SingleStack
      ports:
      - port: 80
        protocol: TCP
        targetPort: 80
      selector:
        app.kubernetes.io/name: MyApp
      type: ClusterIP
    status:
      loadBalancer: {}
    
  2. Коли двостековість увімкнена в кластері, наявні headless Services з селекторами конфігуруються панеллю управління так, щоб встановити .spec.ipFamilyPolicy на SingleStack та встановити .spec.ipFamilies на сімейство адрес першого діапазону кластерних IP Service (налаштованого за допомогою прапорця --service-cluster-ip-range для kube-apiserver), навіть якщо .spec.clusterIP встановлено в None.

    apiVersion: v1
    kind: Service
    metadata:
      name: my-service
      labels:
        app.kubernetes.io/name: MyApp
    spec:
      selector:
        app.kubernetes.io/name: MyApp
      ports:
        - protocol: TCP
          port: 80
    

    Ви можете перевірити цю поведінку за допомогою kubectl, щоб переглянути наявний headless Service з селекторами.

    kubectl get svc my-service -o yaml
    
    apiVersion: v1
    kind: Service
    metadata:
      labels:
        app.kubernetes.io/name: MyApp
      name: my-service
    spec:
      clusterIP: None
      clusterIPs:
      - None
      ipFamilies:
      - IPv4
      ipFamilyPolicy: SingleStack
      ports:
      - port: 80
        protocol: TCP
        targetPort: 80
      selector:
        app.kubernetes.io/name: MyApp
    

Перемикання Service між одностековим та двостековим режимами

Service можна перемикати з одностекового режиму на двостековий та навпаки.

  1. Для того щоби перемикнути Service з одностекового режиму на двостековий, змініть .spec.ipFamilyPolicy з SingleStack на PreferDualStack або RequireDualStack за необхідності. Коли ви змінюєте цей Service з одностекового режиму на двостековий, Kubernetes призначає відсутнє адресне сімейство, так що тепер Service має адреси IPv4 та IPv6.

    Відредагуйте специфікацію Service, оновивши .spec.ipFamilyPolicy з SingleStack на PreferDualStack.

    До:

    spec:
      ipFamilyPolicy: SingleStack
    

    Після:

    spec:
      ipFamilyPolicy: PreferDualStack
    
  2. Для того щоби змінити Service з двостекового режиму на одностековий, змініть .spec.ipFamilyPolicy з PreferDualStack або RequireDualStack на SingleStack. Коли ви змінюєте цей Service з двостекового режиму на одностековий, Kubernetes залишає лише перший елемент у масиві .spec.clusterIPs, і встановлює .spec.clusterIP на цю IP-адресу і встановлює .spec.ipFamilies на адресне сімейство .spec.clusterIPs.

Headless Services без селекторів

Для Headless Services без селекторів і без явно вказаного .spec.ipFamilyPolicy, поле .spec.ipFamilyPolicy має типове значення RequireDualStack.

Тип Service — LoadBalancer

Щоб налаштувати двостековий балансувальник навантаження для вашого Service:

  • Встановіть значення поля .spec.type в LoadBalancer
  • Встановіть значення поля .spec.ipFamilyPolicy в PreferDualStack або RequireDualStack

Трафік Egress

Якщо ви хочете увімкнути трафік Egress, щоб досягти призначення за межами кластера (наприклад, публічний Інтернет) з Podʼа, який використовує непублічно марковані адреси IPv6, вам потрібно увімкнути Pod для використання публічно-маршрутизованих адрес IPv6 за допомогою механізму, такого як прозорий проксі або IP маскування. Проєкт ip-masq-agent підтримує IP-маскування у двохстекових кластерах.

Підтримка Windows

Kubernetes на Windows не підтримує одностекову мережу "лише IPv6". Однак підтримується двохстекова мережа IPv4/IPv6 для Podʼів та вузлів з одностековими Service.

Ви можете використовувати двохстекову мережу IPv4/IPv6 з мережами l2bridge.

Ви можете дізнатися більше про різні режими мережі для Windows в розділі Мережа у Windows.

Що далі

3.5.9 - Маршрутизація з урахуванням топології

Маршрутизацію з урахуванням топології надає механізм для збереження мережевого трафіку в межах зони, з якої він походить. Віддача переваги трафіку в межах однієї зони між Podʼами в вашому кластері може допомогти з надійністю, продуктивністю (мережевою затримкою та пропускною здатністю) або вартістю.
СТАН ФУНКЦІОНАЛУ: Kubernetes v1.23 [beta]

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

Мотивація

Кластери Kubernetes все частіше розгортаються в багатозональних середовищах. Маршрутизацію з урахуванням топології забезпечує механізм для збереження трафіку в межах зони, з якої він походить. При розрахунку точок доступу для Service, контролер EndpointSlice враховує топологію (регіон і зону) кожної точки доступу та заповнює поле підказок для виділення її в зону. Компоненти кластера, такі як kube-proxy, можуть використовувати ці підказки для впливу на маршрутизацію трафіку (надання переваги точкам доступу, які знаходяться в топологічно ближчих зонах).

Увімкнення маршрутизації з урахуванням топології

Ви можете увімкнути маршрутизацію з урахуванням топології, для Service, встановивши анотацію service.kubernetes.io/topology-mode в значення Auto. Коли є достатня кількість точок доступу у кожній зоні, в EndpointSlice будуть заповнені підказки щодо топології для виділення окремих точок доступу конкретним зонам, що призводить до того, що трафік буде маршрутизуватися ближче до місця, звідки він походить.

Найкращий випадок застосування

Ця функція працює найкраще, коли:

1. Вхідний трафік рівномірно розподілений

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

2. У Service є 3 чи більше точок доступу на зону

У кластері з трьома зонами це означає 9 чи більше точок доступу. Якщо кількість точок доступу менше ніж 3 на зону, існує висока (≈50%) ймовірність, що контролер EndpointSlice не зможе рівномірно розподілити точки доступу та повернеться до застосування типового підходу до маршрутизації на рівні кластера.

Як це працює

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

Контролер EndpointSlice

Контролер EndpointSlice відповідає за встановлення підказок на EndpointSlice, коли цей евристичний підхід увімкнено. Контролер виділяє пропорційну кількість точок доступу кожній зоні. Ця пропорція ґрунтується на виділеному обсязі ядер ЦП для вузлів, що працюють в цій зоні. Наприклад, якщо в одній зоні є 2 ядра ЦП, а в іншій зоні лише 1 ядро ЦП, контролер виділить подвійну кількість точок доступу для зони з 2 ядрами ЦП.

Нижче наведено приклад того, як виглядає EndpointSlice, коли підказки вже заповнено:

apiVersion: discovery.k8s.io/v1
kind: EndpointSlice
metadata:
  name: example-hints
  labels:
    kubernetes.io/service-name: example-svc
addressType: IPv4
ports:
  - name: http
    protocol: TCP
    port: 80
endpoints:
  - addresses:
      - "10.1.2.3"
    conditions:
      ready: true
    hostname: pod-1
    zone: zone-a
    hints:
      forZones:
        - name: "zone-a"

kube-proxy

Компонент kube-proxy фільтрує точки доступу, до яких він направляє трафік, на підставі підказок, встановлених контролером EndpointSlice. У більшості випадків це означає, що kube-proxy може направляти трафік до точок доступу в тій самій зоні. Іноді контролер вибирає точки доступу з іншої зони, щоб забезпечити більш рівномірний розподіл точок доступу між зонами. Це може призвести до того, що деякий трафік буде направлятися до інших зон.

Запобіжники

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

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

  2. Неможливо досягнути збалансованого розподілу: У деяких випадках може бути неможливо досягти збалансованого розподілу точок доступу між зонами. Наприклад, якщо zone-a удвічі більша, ніж zone-b, але є лише 2 точки доступу, точка доступу, призначена zone-a, може отримати вдвічі більше трафіку, ніж zone-b. Контролер не призначає підказок, якщо він не може знизити це значення "очікуваного перевантаження" нижче прийнятного порогу для кожної зони. Важливо, що це не ґрунтується на зворотньому звʼязку в режимі реального часу. Можливе перенавантаження окремих точок доступу.

  3. Один чи декілька вузлів має недостатню інформацію: Якщо який-небудь вузол не має мітки topology.kubernetes.io/zone або не повідомляє значення виділеного ЦП, панель управління не встановлює жодних підказок точок доступу з відомостями про зони, і, отже, kube-proxy не фільтрує точки доступу за зоною.

  4. Одна чи декілька точок доступу не має підказки щодо зони: Коли це трапляється, kube-proxy припускає, що відбувається перехід до або з Topology Aware Hints. Фільтрація точок доступу для Serviceʼу в цьому стані була б небезпечною, тому kube-proxy використовує всі точки доступу.

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

Обмеження

  • Topology Aware Hints не використовуються, коли internalTrafficPolicy встановлено в Local для Service. Можливе використання обох функцій у тому ж кластері для різних Serviceʼів, просто не на одному і тому ж Service.

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

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

  • Контролер EndpointSlice ігнорує вузли з мітками node-role.kubernetes.io/control-plane або node-role.kubernetes.io/master. Це може бути проблематичним, якщо також на цих вузлах працюють робочі навантаження.

  • Контролер EndpointSlice не враховує tolerations при розгортанні або розрахунку пропорцій для кожної зони. Якщо Podʼи, які підтримують Service, обмежені у підмножині вузлів у кластері, це не буде враховано.

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

Власні евристики

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

Що далі

3.5.10 - Мережеві аспекти Windows

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

Мережева взаємодія контейнерів у Windows

Мережевий стек для контейнерів у Windows використовує CNI-втулки. Контейнери у Windows працюють схоже до віртуальних машин з погляду мережі. Кожен контейнер має віртуальний мережевий адаптер (vNIC), який підключений до віртуального комутатора Hyper-V (vSwitch). Host Networking Service (HNS) та Host Compute Service (HCS) спільно працюють для створення контейнерів і підключення віртуальних мережевих адаптерів контейнера до мереж. HCS відповідає за управління контейнерами, тоді як HNS відповідає за управління ресурсами мережі, такими як:

  • Віртуальні мережі (включаючи створення vSwitches)
  • Endpoint / vNIC
  • Namespaces
  • Політика, включаючи інкапсуляцію пакетів, правила балансування навантаження, ACL, та правила NAT.

Windows HNS та vSwitch реалізують простір імен та можуть створювати віртуальні мережеві адаптери за потреби для Podʼів чи контейнерів. Однак багато конфігурацій, таких як DNS, маршрути та метрики, зберігаються в базі даних реєстру Windows, а не як файли в /etc, як це робить Linux. Реєстр Windows для контейнера відрізняється від реєстру хосту, тому концепції, такі як передавання /etc/resolv.conf з хосту в контейнер, не мають такого ж ефекту, як у Linux. Їх потрібно налаштовувати за допомогою API Windows, що виконуються в контексті контейнера. Таким чином, реалізації CNI повинні викликати HNS, а не покладатися на доступ до файлів для передачі мережевих деталей у Pod чи контейнер.

Режими мережі

Windows підтримує пʼять різних драйверів/режимів мережі: L2bridge, L2tunnel, Overlay (Beta), Transparent та NAT. У гетерогенному кластері з вузлами Windows і Linux необхідно вибрати мережеве рішення, яке сумісне як з Windows, так і з Linux. У таблиці нижче наведено втулки, що не є частиною Kubernetes, які підтримуються у Windows, з рекомендаціями щодо використання кожного CNI:

Драйвер мережіОписМодифікації контейнерних пакетівВтулки мережіХарактеристики втулків мережі
L2bridgeКонтейнери підключені до зовнішнього vSwitch. Контейнери підключені до мережі нижнього рівня, хоча фізична мережа не повинна знати MAC-адреси контейнера, оскільки вони переписуються при вході/виході.MAC переписується на MAC хосту, IP може бути переписаний на IP хосту за допомогою політики HNS OutboundNAT.win-bridge, Azure-CNI, Flannel host-gateway використовує win-bridgewin-bridge використовує режим мережі L2bridge, підключаючи контейнери до нижнього рівня хостів, пропонуючи найкращу продуктивність. Вимагає маршрутів, визначених користувачем (UDR) для міжвузлової звʼязності.
L2TunnelЦе спеціальний випадок l2bridge, але використовується тільки на Azure. Всі пакети відсилаються на віртуальний хост, де застосовується політика SDN.MAC переписується, IP видно в мережі нижнього рівняAzure-CNIAzure-CNI дозволяє інтегрувати контейнери з Azure vNET та використовувати набір можливостей, які Azure Virtual Network надає. Наприклад, безпечно підключатися до служб Azure або використовувати NSG Azure. Див. azure-cni для прикладів
OverlayКонтейнерам надається vNIC, підключений до зовнішнього vSwitch. Кожна мережа має власну підмережу IP, визначену власним IP-префіксом. Драйвер мережі використовує інкапсуляцію VXLAN.Інкапсульований в зовнішній заголовок.win-overlay, Flannel VXLAN (використовує win-overlay)win-overlay слід використовувати, коли потрібна ізоляція віртуальних мереж контейнерів від нижнього рівня хостів (наприклад, з міркувань безпеки). Дозволяє використовувати однакові IP для різних віртуальних мереж (які мають різні теґи VNID), якщо у вас обмеження на IP в вашому датацентрі. Цей варіант вимагає KB4489899 у Windows Server 2019.
Transparent (спеціальний випадок для ovn-kubernetes)Вимагає зовнішнього vSwitch. Контейнери підключені до зовнішнього vSwitch, що дозволяє взаємодію всередині Podʼа за допомогою логічних мереж (логічні свічі та маршрутизатори).Пакет капсулюється через GENEVE або STT для доступу до Podʼів, які не знаходяться на тому самому хості.
Пакети пересилаються чи відкидаються через інформацію про тунель, яку надає контролер мережі ovn.
NAT виконується для комунікації північ-південь.
ovn-kubernetesРозгортається за допомогою ansible. Розподілені ACL можна застосовувати за допомогою політик Kubernetes. Підтримка IPAM. Балансування навантаження можливе без використання kube-proxy. NAT виконується без використання iptables/netsh.
NAT (не використовується в Kubernetes)Контейнерам надається віртуальний мережевий адаптер (vNIC), підключений до внутрішнього vSwitch. DNS/DHCP надається за допомогою внутрішнього компонента, називається WinNATMAC та IP переписуються на MAC/IP хосту.natВключено тут для повноти.

Як вказано вище, Flannel CNI plugin також підтримується у Windows через VXLAN мережевий бекенд (Бета-підтримка; делегує до win-overlay) та host-gateway мережевий бекенд (стабільна підтримка; делегує до win-bridge).

Цей втулок підтримує делегування до одного з втулків CNI за вибором користувача (win-overlay, win-bridge), для співпраці з демоном Flannel у Windows (Flanneld) для автоматичного присвоєння лізингу підмережі вузлу та створення мережі HNS. Цей втулок читає власний файл конфігурації (cni.conf) та агрегує його зі змінними середовища зі створеного FlannelD файлу subnet.env. Потім він делегує одному з втулків CNI для роботи з мережею, надсилаючи правильну конфігурацію, що містить призначену вузлом підмережу до IPAM-втулку (наприклад: host-local).

Для обʼєктів Node, Pod та Service підтримуються наступні потоки даних мережі для TCP/UDP-трафіку:

  • Pod → Pod (IP)
  • Pod → Pod (Імʼя)
  • Pod → Сервіс (Кластерний IP)
  • Pod → Сервіс (PQDN, але тільки якщо немає ".")
  • Pod → Сервіс (FQDN)
  • Pod → зовнішній (IP)
  • Pod → зовнішній (DNS)
  • Node → Pod
  • Pod → Node

Управління IP-адресами (IPAM)

У Windows підтримуються наступні параметри IPAM:

Балансування навантаження та Service

Service Kubernetes є абстракцією, яка визначає логічний набір Podʼів та засіб доступу до них мережею. У кластері, який включає вузли Windows, можна використовувати наступні типи Service:

  • NodePort
  • ClusterIP
  • LoadBalancer
  • ExternalName

Мережева взаємодія контейнерів у Windows відрізняється в деяких важливих аспектах від мережі Linux. Документація Microsoft з мережевої взаємодії контейнерів у Windows надає додаткові відомості та контекст.

У Windows можна використовувати наступні налаштування для конфігурації Service та поведінки балансування навантаження:

Налаштування Сервісів для Windows
ФункціяОписМінімальна підтримувана версія Windows OSЯк ввімкнути
Подібність сесій
(Session affinity)
Забезпечує, що підключення від певного клієнта передається тому самому Podʼу кожен раз.Windows Server 2022Встановіть у service.spec.sessionAffinity значення "ClientIP"
Direct Server Return (DSR)Режим балансування навантаження, де виправлення IP-адреси та LBNAT відбуваються на порту vSwitch контейнера напряму; трафік служби приходить з набору вихідних IP, встановленого як IP походження Podʼа.Windows Server 2019Встановіть наступні прапорці в kube-proxy: --feature-gates="WinDSR=true" --enable-dsr=true
Збереження-ПризначенняПропускає DNAT-трафік Servicʼу, тим самим зберігаючи віртуальну IP цільового Service в пакетах, що досягають фронтенду Podʼа. Також вимикає пересилання вузол-вузол.Windows Server, версія 1903Встановіть "preserve-destination": "true" в анотаціях служби та увімкніть DSR в kube-proxy.
Подвійний мережевий стек IPv4/IPv6Нативна підтримка IPv4-до-IPv4 поряд з IPv6-до-IPv6 комунікацією до, з і всередині кластераWindows Server 2019Див. Підтримка подвійного стеку IPv4/IPv6
Збереження IP клієнтаЗабезпечує збереження джерела ingress трафіку. Також вимикає пересилання вузол-вузол.Windows Server 2019Встановіть service.spec.externalTrafficPolicy у "Local" та увімкніть DSR в kube-proxy

Обмеження

Наступні функції мережі не підтримуються на вузлах Windows:

  • Режим мережі хосту
  • Локальний доступ NodePort з вузла (працює для інших вузлів або зовнішніх клієнтів)
  • Більше 64 бекенд-Podʼів (або унікальних адрес призначення) для одного Service
  • Звʼязок IPv6 між Pods Windows, підключеними до мереж оверлея
  • Local Traffic Policy в режимі без DSR
  • Вихідна комунікація за допомогою протоколу ICMP через win-overlay, win-bridge, або використовуючи втулок Azure-CNI. Зокрема панель даних Windows (VFP) не підтримує ICMP-перетворення пакетів, і це означає:
    • Пакети ICMP, спрямовані до пунктів призначення в одній мережі (наприклад, звʼязок Pod-Pod за допомогою ping), працюють належним чином;
    • TCP/UDP-пакети працюють, як очікується;
    • Пакети ICMP, спрямовані на проходження через віддалену мережу (наприклад, Pod-зовнішньої точки в інтернет через ping), не можуть бути перенесені та, таким чином, не будуть перенаправлені назад до свого джерела;
    • Оскільки TCP/UDP-пакети все ще можуть бути перетворені, ви можете замінити ping <destination> на curl <destination> при налагодженні зʼєднаності з зовнішнім світом.

Інші обмеження:

  • Референсні мережеві втулки Windows, такі як win-bridge та win-overlay, не мають реалізації специфікації CNI v0.4.0, через відсутність реалізації CHECK.
  • Втулок Flannel VXLAN має наступні обмеження на Windows:
    • Зʼєднаність Node-Pod можлива лише для локальних Podʼів з Flannel v0.12.0 (або вище).
    • Flannel обмежений використанням VNI 4096 та UDP-порту 4789. Див. офіційну Flannel VXLAN документацію про бекенд Flannel VXLAN щодо цих параметрів.

3.5.11 - Виділення IP-адрес ClusterIP Serviceʼам

У Kubernetes Service — це абстракція для експозиції застосунку, який працює на наборі Podʼів. Serviceʼи можуть мати віртуальну IP-адресу, доступну на рівні кластера (за допомогою Service з type: ClusterIP). Клієнти можуть підключатися за допомогою цієї віртуальної IP-адреси, і Kubernetes балансує трафік до цього Service між його Podʼами.

Як виділяються IP-адреси ClusterIP Сервісу?

Коли Kubernetes потрібно призначити віртуальну IP-адресу для Service, це відбувається одним із двох способів:

динамічно
панель управління кластера автоматично вибирає вільну IP-адресу з налаштованого діапазону IP для Service з type: ClusterIP.
статично
ви вказуєте IP-адресу за своїм вибором, з налаштованого діапазону IP для Service.

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

З чого випливає необхідність резервування IP-адрес для ClusterIP Service?

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

Найкращим прикладом є Service DNS для кластера. Як мʼяка конвенція, деякі встановлювачі Kubernetes відводять 10-ту IP-адресу з діапазону IP-адрес Service для служби DNS. Припустимо, ви налаштували кластер із діапазоном IP-адрес Service 10.96.0.0/16 і хочете, щоб ваша IP-адреса Service DNS була 10.96.0.10, вам доведеться створити Service, подібний до цього:

apiVersion: v1
kind: Service
metadata:
  labels:
    k8s-app: kube-dns
    kubernetes.io/cluster-service: "true"
    kubernetes.io/name: CoreDNS
  name: kube-dns
  namespace: kube-system
spec:
  clusterIP: 10.96.0.10
  ports:
  - name: dns
    port: 53
    protocol: UDP
    targetPort: 53
  - name: dns-tcp
    port: 53
    protocol: TCP
    targetPort: 53
  selector:
    k8s-app: kube-dns
  type: ClusterIP

але, як це було пояснено раніше, IP-адреса 10.96.0.10 не була зарезервована; якщо інші Service створюються перед або паралельно з динамічним виділенням, існує шанс, що вони можуть зайняти цю IP-адресу, тому ви не зможете створити Service DNS, оскільки це призведе до конфлікту.

Як уникнути конфліктів IP-адрес ClusterIP Сервісу?

Стратегія виділення, реалізована в Kubernetes для виділення ClusterIPs Service, зменшує ризик колізій.

ClusterIP діапазон поділений на основі формули min(max(16, cidrSize / 16), 256), описано як ніколи менше ніж 16 або більше за 256 із поступовим кроком між ними.

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

Приклади

Приклад 1

У цьому прикладі використовується діапазон IP-адрес: 10.96.0.0/24 (нотація CIDR) для IP-адрес Serviceʼів.

Розмір діапазону: 28 - 2 = 254
Зсув діапазону: min(max(16, 256/16), 256) = min(16, 256) = 16
Початок статичного діапазону: 10.96.0.1
Кінець статичного діапазону: 10.96.0.16
Кінець діапазону: 10.96.0.254

pie showData title 10.96.0.0/24 "Статичний" : 16 "Динамічний" : 238

Приклад 2

У цьому прикладі використовується діапазон IP-адрес: 10.96.0.0/20 (нотація CIDR) для IP-адрес Service.

Розмір діапазону: 212 - 2 = 4094
Зсув діапазону: min(max(16, 4096/16), 256) = min(256, 256) = 256
Початок статичного діапазону: 10.96.0.1
Кінець статичного діапазону: 10.96.1.0
Кінець діапазону: 10.96.15.254

pie showData title 10.96.0.0/20 "Статичний" : 256 "Динамічний" : 3838

Приклад 3

У цьому прикладі використовується діапазон IP-адрес: 10.96.0.0/16 (нотація CIDR) для IP-адрес Service.

Розмір діапазону: 216 - 2 = 65534
Зсув діапазону: min(max(16, 65536/16), 256) = min(4096, 256) = 256
Початок статичного діапазону: 10.96.0.1
Кінець статичного діапазону: 10.96.1.0
Кінець діапазону: 10.96.255.254

pie showData title 10.96.0.0/16 "Статичний" : 256 "Динамічний" : 65278

Що далі

3.5.12 - Політики внутрішнього трафіку Service

Якщо два Podʼа в вашому кластері хочуть взаємодіяти, і вони обидва фактично працюють на одному й тому ж вузлі, використовуйте Політики внутрішнього трафіку Service, щоб утримувати мережевий трафік в межах цього вузла. Уникнення зворотного зв’язку через кластерну мережу може допомогти підвищити надійність, продуктивність (затримку мережі та пропускну здатність) або вартість.
СТАН ФУНКЦІОНАЛУ: Kubernetes v1.26 [stable]

Політика внутрішнього трафіку Service дозволяє обмежувати внутрішній трафік, маршрутизуючи його лише до endpoint у межах вузла, з якого походить трафік. Тут "внутрішній" трафік означає трафік, який виник з Podʼів у поточному кластері. Це може допомогти зменшити витрати та покращити продуктивність.

Використання політики внутрішнього трафіку Service

Ви можете увімкнути політику тільки для внутрішнього трафіку для Service, встановивши його .spec.internalTrafficPolicy в Local. Це вказує kube-proxy використовувати лише вузлові локальні endpoint для внутрішнього трафіку кластера.

У наступному прикладі показано, як виглядає Service, коли ви встановлюєте .spec.internalTrafficPolicy в Local:

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app.kubernetes.io/name: MyApp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376
  internalTrafficPolicy: Local

Як це працює

Kube-proxy фільтрує endpointʼи, до яких він виконує маршрутизацію, на основі налаштувань spec.internalTrafficPolicy. Коли вона встановлена в Local, розглядаються тільки вузлові локальні endpointʼи. Коли вона встановлена в Cluster (стандартно), або не встановлена взагалі, Kubernetes розглядає всі endpointʼи.

Що далі

3.6 - Зберігання

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

3.6.1 - Томи

Файли на диску в контейнері є ефемерними, що викликає певні проблеми для складних застосунків при їх виконанні в контейнерах. Одна з проблем виникає під час аварії або зупинки контейнера. Стан контейнера не зберігається, тому всі файли, що були створені чи змінені під час життя контейнера, втрачаються. Під час аварії kubelet перезапускає контейнер в його первісному стані. Ще одна проблема виникає, коли кілька контейнерів працюють у Pod та потребують спільного доступу до файлів. Створення та отримання доступу до спільної файлової системи для всіх контейнерів може бути не простим завданням. Абстракція volume у Kubernetes дозволяє розвʼязати обидві ці проблеми. Рекомендується вже мати уявлення про Podʼи.

Контекст

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

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

Для використання тому вказуйте томи, які надаються для Podʼа в .spec.volumes і зазначте, куди монтувати ці томи в контейнери в .spec.containers[*].volumeMounts. Процес в контейнері бачить перегляд файлової системи, створений з початкового вмісту образу контейнера, а також томи (якщо визначено), змонтовані всередині контейнера. Процес бачить кореневу файлову систему, яка спочатку відповідає вмісту образу контейнера. Будь-які записи всередині ієрархії файлової системи, якщо дозволено, впливають на те, що цей процес бачить при виконанні наступного доступу до файлової системи. Томи монтуються за вказаними шляхами всередині образу. Для кожного контейнера, визначеного в Podʼі, ви повинні незалежно вказати, куди монтувати кожен том, яким користується контейнер.

Томи не можуть монтуватися всередині інших томів (але див. Використання subPath для повʼязаного механізму). Також том не може містити жорстке посилання на будь-що в іншому томі.

Типи томів

Kubernetes підтримує кілька типів томів.

awsElasticBlockStore (застаріло)

У Kubernetes 1.31, всі операції з типом awsElasticBlockStore будуть перенаправлені на драйвер ebs.csi.aws.com CSI.

Вбудований драйвер сховища AWSElasticBlockStore був застарілим у випуску Kubernetes v1.19 і потім був повністю вилучений у випуску v1.27.

Проєкт Kubernetes рекомендує використовувати сторонній драйвер сховища AWS EBS замість.

azureDisk (застаріло)

У Kubernetes 1.31, всі операції з типом azureDisk будуть перенаправлені на драйвер disk.csi.azure.com CSI.

Вбудований драйвер сховища AzureDisk був застарілим у випуску Kubernetes v1.19 і потім був повністю вилучений у випуску v1.27.

Проєкт Kubernetes рекомендує використовувати сторонній драйвер сховища Azure Disk замість.

azureFile (застаріло)

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

Тип тому azureFile монтує том файлу Microsoft Azure (SMB 2.1 і 3.0) в Pod.

Для отримання докладнішої інформації див. Втулок томів azureFile.

Міграція до CSI для azureFile

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

Функція CSIMigration для azureFile, якщо увімкнена, перенаправляє всі операції втулка з наявного вбудованого втулка до драйвера інтерфейсу зберігання (Container Storage Interface, CSI) file.csi.azure.com контейнера. Для використання цієї функції необхідно встановити Драйвер CSI для Azure File у кластері, і функціональна можливість CSIMigrationAzureFile має бути увімкненою.

Драйвер CSI для Azure File не підтримує використання одного й того ж тому з різними fsgroups. Якщо CSIMigrationAzureFile увімкнено, використання одного й того ж тому з різними fsgroups взагалі не підтримується.

Завершення міграції до CSI для azureFile

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

Щоб вимкнути завантаження втулка сховища azureFile контролером і менеджером kubelet, встановіть прапорець InTreePluginAzureFileUnregister в значення true.

cephfs (видалено)

Kubernetes 1.31 не містить типу тому cephfs.

Драйвер вбудованої системи зберігання cephfs був застарілий у випуску Kubernetes v1.28, а потім повністю видалений у випуску v1.31.

cinder (застаріло)

У Kubernetes 1.31, всі операції з типом cinder будуть перенаправлені на драйвер cinder.csi.openstack.org CSI.

Вбудований драйвер сховища Cinder для OpenStack був застарілим ще у випуску Kubernetes v1.11 і потім був повністю вилучений у випуску v1.26.

Проєкт Kubernetes рекомендує натомість використовувати сторонній драйвер сховища OpenStack Cinder.

configMap

ConfigMap надає можливість вводити конфігураційні дані у Podʼи. Дані, збережені в ConfigMap, можуть бути використані у томі типу configMap і потім використовуватись контейнеризованими застосунками, що працюють у Podʼі.

При посиланні на ConfigMap ви вказуєте імʼя ConfigMap у томі. Ви можете налаштувати шлях для конкретного запису в ConfigMap. Наведена нижче конфігурація показує, як замонтувати ConfigMap з імʼям log-config у Pod з імʼям configmap-pod:

apiVersion: v1
kind: Pod
metadata:
  name: configmap-pod
spec:
  containers:
    - name: test
      image: busybox:1.28
      command: ['sh', '-c', 'echo "The app is running!" && tail -f /dev/null']
      volumeMounts:
        - name: config-vol
          mountPath: /etc/config
  volumes:
    - name: config-vol
      configMap:
        name: log-config
        items:
          - key: log_level
            path: log_level

ConfigMap log-config змонтовано як том, і весь вміст, збережений у його запису log_level, змонтовано в Pod за шляхом /etc/config/log_level. Зверніть увагу, що цей шлях виводиться з mountPath тому та path з ключем log_level.

downwardAPI

Том downwardAPI робить дані downward API доступними для застосунків. У межах тому ви можете знайти відкриті дані, викладені у вигляді файлів у форматі звичайного тексту, доступні для читання.

Дивіться Передавання інформації про Podʼи контейнерам через файли для отримання докладнішої інформації.

emptyDir

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

Деякі використання тому emptyDir:

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

Поле emptyDir.medium контролює, де зберігаються томи emptyDir. Типово томи emptyDir зберігаються у томі, який підтримує вузол такому як диск, SSD або мережеве сховище, залежно від вашого середовища. Якщо ви встановите поле emptyDir.medium в "Memory", Kubernetes автоматично монтує tmpfs (віртуальна файлова система в памʼяті) замість цього. Хоча tmpfs дуже швидкий, слід памʼятати, що, на відміну від дисків, файли, які ви записуєте, враховуються у ліміті памʼяті контейнера, який їх записав.

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

Приклад налаштування emptyDir

apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: registry.k8s.io/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /cache
      name: cache-volume
  volumes:
  - name: cache-volume
    emptyDir:
      sizeLimit: 500Mi

fc (fibre channel)

Тип тому fc дозволяє монтувати наявний том з блочного зберігання по каналу звʼязку в Pod. Ви можете вказати одне чи кілька імен шляхів цілей (world wide name, WWN) за допомогою параметра targetWWNs у конфігурації вашого тому. Якщо вказано кілька WWN, targetWWNs очікує, що ці WWN належать до зʼєднань з багатьма шляхами.

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

gcePersistentDisk (застаріло)

У Kubernetes 1.31, всі операції з типом gcePersistentDisk будуть перенаправлені на драйвер pd.csi.storage.gke.io CSI.

Драйвер вбудованого сховища gcePersistentDisk був застарілим ще у випуску Kubernetes v1.17 і потім був повністю вилучений у випуску v1.28.

Проєкт Kubernetes рекомендує натомість використовувати сторонній драйвер сховища Google Compute Engine Persistent Disk CSI.

gitRepo (застаріло)

Том gitRepo є прикладом втулка тому. Цей втулок монтує порожній каталог і клонує репозиторій git у цей каталог для використання вашим Podʼом.

Ось приклад тому gitRepo:

apiVersion: v1
kind: Pod
metadata:
  name: server
spec:
  containers:
  - image: nginx
    name: nginx
    volumeMounts:
    - mountPath: /mypath
      name: git-volume
  volumes:
  - name: git-volume
    gitRepo:
      repository: "git@somewhere:me/my-git-repository.git"
      revision: "22f1d8406d464b0c0874075539c1f2e96c253775"

glusterfs (вилучено)

Тип тому glusterfs не включено в Kubernetes 1.31.

Вбудований драйвер сховища GlusterFS був застарілим ще у випуску Kubernetes v1.25 і потім був повністю вилучений у випуску v1.26.

hostPath

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

Деякі використання тому hostPath:

  • виконання контейнера, який потребує доступу до системних компонентів рівня вузла (такого як контейнер, який передає системні логи до центрального сховища, з доступом до цих логів за допомогою монтування /var/log тільки для читання)
  • надання конфігураційного файлу, збереженого на хост-системі, доступного тільки для читання для статичного Podʼа; на відміну від звичайних Podʼів, статичні Podʼи не можуть отримувати доступ до ConfigMaps.

Типи томів hostPath

Крім обовʼязкової властивості path, ви можете вказати необовʼязковий параметр type для тому hostPath.

Доступні значення для type:

ЗначенняПоведінка
‌""Порожній рядок (стандартно) призначений для забезпечення сумісності з попередніми версіями, що означає, що перед монтуванням тому hostPath не виконуватимуться перевірки.
DirectoryOrCreateЯкщо нічого не існує за вказаним шляхом, буде створено порожній каталог за необхідності з правами на виконання, встановленими на 0755, з тією ж групою і власником, що й Kubelet.
DirectoryПовинен існувати каталог за вказаним шляхом
FileOrCreateЯкщо нічого не існує за вказаним шляхом, буде створено порожній файл за необхідності з правами на виконання, встановленими на 0644, з тією ж групою і власником, що й Kubelet.
FileПовинен існувати файл за вказаним шляхом
SocketМає існувати UNIX-сокет за вказаним шляхом
CharDevice(Лише вузли Linux) Має існувати символьний пристрій за вказаним шляхом
BlockDevice(Лише вузли Linux) Має існувати блочний пристрій за вказаним шляхом

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

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


---
# Цей маніфест монтує /data/foo на вузлі як /foo всередині
# єдиного контейнера, який працює в межах Podʼа hostpath-example-linux
#
# Монтування в контейнер тільки для читання
apiVersion: v1
kind: Pod
metadata:
  name: hostpath-example-linux
spec:
  os: { name: linux }
  nodeSelector:
    kubernetes.io/os: linux
  containers:
  * name: example-container
    image: registry.k8s.io/test-webserver
    volumeMounts:
    * mountPath: /foo
      name: example-volume
      readOnly: true
  volumes:
  * name: example-volume
    # монтувати /data/foo, але тільки якщо цей каталог вже існує
    hostPath:
      path: /data/foo # розташування каталогу на вузлі
      type: Directory # це поле є необовʼязковим


---
# Цей маніфест монтує C:\Data\foo на вузлі як C:\foo всередині
# єдиного контейнера, який працює в межах Podʼа hostpath-example-windows
#
# Монтування в контейнер тільки для читання
apiVersion: v1
kind: Pod
metadata:
  name: hostpath-example-windows
spec:
  os: { name: windows }
  nodeSelector:
    kubernetes.io/os: windows
  containers:
  * name: example-container
    image: microsoft/windowsservercore:1709
    volumeMounts:
    * name: example-volume
      mountPath: "C:\\foo"
      readOnly: true
  volumes:
    # монтувати C:\Data\foo з вузла, але тільки якщо цей каталог вже існує
  * name: example-volume
      hostPath:
        path: "C:\\Data\\foo" # розташування каталогу на вузлі
        type: Directory       # це поле є необовʼязковим

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

У наступному маніфесті визначено Pod, який монтує /var/local/aaa всередині єдиного контейнера в Podʼі. Якщо на вузлі не існує шляху /var/local/aaa, kubelet створює його як каталог і потім монтує його в Pod.

Якщо /var/local/aaa вже існує, але не є каталогом, Pod зазнає невдачі. Крім того, kubelet намагається створити файл із назвою /var/local/aaa/1.txt всередині цього каталогу (як бачить його вузол); якщо щось вже існує за цим шляхом і це не є звичайним файлом, Pod також зазнає невдачі.

Ось приклад маніфесту:

apiVersion: v1
kind: Pod
metadata:
  name: test-webserver
spec:
  os: { name: linux }
  nodeSelector:
    kubernetes.io/os: linux
  containers:
  - name: test-webserver
    image: registry.k8s.io/test-webserver:latest
    volumeMounts:
    - mountPath: /var/local/aaa
      name: mydir
    - mountPath: /var/local/aaa/1.txt
      name: myfile
  volumes:
  - name: mydir
    hostPath:
      # Забезпечте створення каталогу файлів.
      path: /var/local/aaa
      type: DirectoryOrCreate
  - name: myfile
    hostPath:
      path: /var/local/aaa/1.txt
      type: FileOrCreate

image

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

Джерело тому image представляє обʼєкт OCI (образ контейнера або артефакт), який доступний на хост-машині kubelet.

Ось приклад використання джерела тому image:

apiVersion: v1
kind: Pod
metadata:
  name: image-volume
spec:
  containers:
  - name: shell
    command: ["sleep", "infinity"]
    image: debian
    volumeMounts:
    - name: volume
      mountPath: /volume
  volumes:
  - name: volume
    image:
      reference: quay.io/crio/artifact:v1
      pullPolicy: IfNotPresent

Том визначається при запуску Podʼа в залежності від значення pullPolicy:

Always
kubelet завжди намагається завантажити посилання. Якщо завантаження не вдається, kubelet встановлює статус Podʼа як Failed.
Never
kubelet ніколи не завантажує посилання і використовує лише локальний образ або артефакт. Pod стає Failed, якщо будь-які шари образу не присутні локально або якщо маніфест для цього образу не закешований.
IfNotPresent
kubelet завантажує образ, якщо посилання не присутнє на диску. Pod стає Failed, якщо посилання не присутнє і завантаження не вдалося.

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

Типи обʼєктів, які можуть бути змонтовані цим томом, визначені реалізацією середовища виконання контейнерів на хост-машині і повинні включати всі дійсні типи, підтримувані полем образу контейнера. Обʼєкт OCI монтується в одну теку (spec.containers[*].volumeMounts.mountPath) і буде змонтований в режимі тільки для читання. В Linux, середовище виконання контейнерів зазвичай також монтує том з блокуванням виконання файлів (noexec).

Крім того:

  • Субшляхи монтування контейнерів не підтримуються (spec.containers[*].volumeMounts.subpath).
  • Поле spec.securityContext.fsGroupChangePolicy не має жодного ефекту для цього типу тому.
  • Admission Controller AlwaysPullImages також працює для цього джерела тому, як і для образів контейнерів.

Доступні наступні поля для типу image:

reference
Посилання на артефакт, який слід використовувати. Наприклад, ви можете вказати registry.k8s.io/conformance:v1.31.0 для завантаження файлів з образу тестування Kubernetes. Працює так само, як pod.spec.containers[*].image. Секрети завантаження образів будуть зібрані так само, як для образу контейнера, шукаючи облікові дані вузла, секрети службового облікового запису завантаження образів та секрети завантаження образів з специфікації Podʼа. Це поле є необовʼязковим, щоб дозволити вищому рівню управління конфігурацією використовувати стандартні або перевизначати образи контейнерів у контролерах навантаження, таких як Deployments і StatefulSets. Більше інформації про образи контейнерів
pullPolicy
Політика завантаження обʼєктів OCI. Можливі значення: Always, Never або IfNotPresent. Стандартно встановлюється Always, якщо вказано теґ :latest, або IfNotPresent в іншому випадку.

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

iscsi

Обʼєкт iscsi дозволяє монтувати наявний том iSCSI (SCSI через IP) у ваш Pod. На відміну від emptyDir, який видаляється, коли Pod видаляється, вміст тому iscsi зберігається, і том просто розмонтується. Це означає, що том iSCSI можна наперед наповнити даними, і ці дані можна спільно використовувати між Podʼами.

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

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

local

Обʼєкт local представляє собою підключений локальний пристрій зберігання, такий як диск, розділ чи каталог.

Локальні томи можна використовувати лише як статично створені PersistentVolume. Динамічне розгортання не підтримується.

У порівнянні з томами hostPath, томи local використовуються в надійний та переносимий спосіб, не потрібно вручну планувати Podʼи на вузли. Система обізнана з обмеженнями вузла тому, переглядаючи приналежність вузла до PersistentVolume.

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

У наступному прикладі показано PersistentVolume з використанням тому local і nodeAffinity:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: example-pv
spec:
  capacity:
    storage: 100Gi
  volumeMode: Filesystem
  accessModes:
  - ReadWriteOnce
  persistentVolumeReclaimPolicy: Delete
  storageClassName: local-storage
  local:
    path: /mnt/disks/ssd1
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - example-node

Вам потрібно встановити nodeAffinity для PersistentVolume при використанні томів local. Планувальник Kubernetes використовує nodeAffinity PersistentVolume для планування цих Podʼів на відповідний вузол.

PersistentVolume volumeMode може бути встановлено на "Block" (замість станадартного значення "Filesystem") для експозиції локального тому як чистого (raw) блокового пристрою.

При використанні локальних томів рекомендується створити StorageClass із встановленим volumeBindingMode в WaitForFirstConsumer. Докладніше дивіться у прикладі StorageClass для локальних томів. Затримка вибору тому дозволяє переконатися, що рішення щодо привʼязки PersistentVolumeClaim буде оцінено разом із будь-якими іншими обмеженнями вузла, які може мати Pod, такими як вимоги до ресурсів вузла, вибір вузла, спорідненість Podʼа та анти-спорідненість Podʼа.

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

nfs

Обʼєкт nfs дозволяє приєднати наявний розділ NFS (Network File System) до Podʼа. На відміну від emptyDir, який видаляється, коли Pod видаляється, вміст тому nfs зберігається, і том просто відмонтується. Це означає, що том NFS можна попередньо наповнити даними, і ці дані можна спільно використовувати між Podʼами. Том NFS може бути приєднаний одночасно кількома записувачами.

apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: registry.k8s.io/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /my-nfs-data
      name: test-volume
  volumes:
  - name: test-volume
    nfs:
      server: my-nfs-server.example.com
      path: /my-nfs-volume
      readOnly: true

Дивіться приклад NFS для прикладу монтування томів NFS з PersistentVolumes.

persistentVolumeClaim

Обʼєкт persistentVolumeClaim використовується для монтування PersistentVolume в Pod. PersistentVolumeClaim є способом для користувачів "вимагати" надійне сховище (наприклад, том iSCSI) без знання деталей конкретного хмарного середовища.

Дивіться інформацію щодо PersistentVolumes для отримання додаткових деталей.

portworxVolume (застаріло)

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

Обʼєкт portworxVolume — це еластичний рівень блочного сховища, який працює в режимі гіперконвергенції з Kubernetes. Portworx визначає сховище на сервері, розділяє його за можливостями і агрегує місткість на кількох серверах. Portworx працює в гостьовій операційній системі віртуальних машин або на bare metal серверах з ОС Linux.

Обʼєкт portworxVolume можна динамічно створити через Kubernetes або його можна попередньо налаштувати та вказати в Podʼі. Тут наведено приклад Podʼа, який посилається на попередньо налаштований том Portworx:

apiVersion: v1
kind: Pod
metadata:
  name: test-portworx-volume-pod
spec:
  containers:
  - image: registry.k8s.io/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /mnt
      name: pxvol
  volumes:
  - name: pxvol
    # Цей том Portworx повинен вже існувати.
    portworxVolume:
      volumeID: "pxvol"
      fsType: "<fs-type>"

Докладніше дивіться приклади томів Portworx.

Міграція на Portworx CSI

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

Стандартно Kubernetes 1.31 намагається мігрувати старі томи Portworx для використання CSI. (Міграція CSI для Portworx була доступна з Kubernetes v1.23, але стала стандатно увімкненою лише з випуску v1.31). Якщо ви хочете вимкнути автоматичну міграцію, ви можете встановити функціональну можливість CSIMigrationPortworx у false; це необхідно зробити як для kube-controller-manager, так і для кожного відповідного kubelet.

Це перенаправляє всі операції втулка з існуючого втулка вбудованої системи до драйвера Container Storage Interface (CSI) pxd.portworx.com. Portworx CSI Driver повинен бути встановлений в кластері.

projected

Том projected підʼєднує кілька існуючих джерел томів в одну теку. Докладніше дивіться projected томи.

rbd (вилучено)

Kubernetes 1.31 не включає тип тому rbd.

Драйвер зберігання Rados Block Device (RBD) і підтримка його міграції CSI були визнані застарілими у випуску Kubernetes v1.28 і повністю видалені в випуску v1.31.

secret

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

Для отримання додаткової інформації дивіться Налаштування Secret.

vsphereVolume (застаріло)

vsphereVolume використовується для монтування тому vSphere VMDK у ваш Pod. Зміст тому зберігається при його демонтажі. Підтримуються обидва типи сховища VMFS та VSAN.

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

Міграція на vSphere CSI

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

У Kubernetes 1.31, всі операції для типу vsphereVolume, що використовується в інтегрованому стеку, перенаправляються на драйвер csi.vsphere.vmware.com CSI.

Для цього має бути встановлений драйвер CSI для vSphere на кластері. Додаткові поради щодо міграції з інтегрованого стеку vsphereVolume можна знайти на сторінці документації VMware Migrating In-Tree vSphere Volumes to vSphere Container Storage Plug-in. Якщо драйвер vSphere CSI не встановлено, не буде можливості виконати операції з томами, створеними за допомогою типу vsphereVolume з інтегрованим стеком.

Для успішної міграції до драйвера vSphere CSI вам слід використовувати vSphere версії 7.0u2 або пізніше.

Якщо ви використовуєте версію Kubernetes відмінну від v1.31, перевірте документацію для цієї версії Kubernetes.

Завершення міграція до vSphere CSI

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

Щоб вимкнути завантаження втулка vsphereVolume контролер-менеджером та kubelet, потрібно встановити прапорець InTreePluginvSphereUnregister в значення true. Драйвер csi.vsphere.vmware.com CSI повинен бути встановлений на всіх вузлах робочого навантаження.

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

Іноді корисно ділити один том для кількох цілей у одному Podʼі. Властивість volumeMounts[*].subPath вказує підшлях всередині посилання на том, а не його корінь.

У наступному прикладі показано, як налаштувати Pod із стеком LAMP (Linux Apache MySQL PHP) за допомогою одного загального тому. Ця конфігурація subPath у прикладі не рекомендується для використання в операційному середовищі.

Код та ресурси PHP-застосунку відображаються на томі у папці html, а база даних MySQL зберігається у папці mysql на цьому томі. Наприклад:

apiVersion: v1
kind: Pod
metadata:
  name: my-lamp-site
spec:
    containers:
    - name: mysql
      image: mysql
      env:
      - name: MYSQL_ROOT_PASSWORD
        value: "rootpasswd"
      volumeMounts:
      - mountPath: /var/lib/mysql
        name: site-data
        subPath: mysql
    - name: php
      image: php:7.0-apache
      volumeMounts:
      - mountPath: /var/www/html
        name: site-data
        subPath: html
    volumes:
    - name: site-data
      persistentVolumeClaim:
        claimName: my-lamp-site-data

Використання subPath із розширеними змінними середовища

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

Використовуйте поле subPathExpr для створення імен каталогів subPath із змінних середовища downward API. Властивості subPath та subPathExpr є взаємовиключними.

У цьому прикладі Pod використовує subPathExpr для створення каталогу pod1 всередині тома hostPath /var/log/pods. Том hostPath отримує імʼя Pod із downwardAPI. Директорія хоста /var/log/pods/pod1 монтується у /logs в контейнері.

apiVersion: v1
kind: Pod
metadata:
  name: pod1
spec:
  containers:
  - name: container1
    env:
    - name: POD_NAME
      valueFrom:
        fieldRef:
          apiVersion: v1
          fieldPath: metadata.name
    image: busybox:1.28
    command: [ "sh", "-c", "while [ true ]; do echo 'Hello'; sleep 10; done | tee -a /logs/hello.txt" ]
    volumeMounts:
    - name: workdir1
      mountPath: /logs
      # Для змінних використовуються круглі дужки (не фігурні).
      subPathExpr: $(POD_NAME)
  restartPolicy: Never
  volumes:
  - name: workdir1
    hostPath:
      path: /var/log/pods

Ресурси

Носій інформації (такий як диск чи SSD) тома emptyDir визначається середовищем файлової системи, яке утримує кореневий каталог kubelet (зазвичай /var/lib/kubelet). Немає обмежень щодо того, скільки місця може використовувати том emptyDir чи hostPath, і відсутня ізоляція між контейнерами чи між Podʼами.

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

Сторонні втулки томів

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

Раніше всі втулки томів були "вбудованими". "Вбудовані" втулки збиралися, звʼязувалися, компілювалися і входили до базових бінарних файлів Kubernetes. Це означало, що для додавання нової системи зберігання до Kubernetes (втулка тому) потрібно було додавати код у основний репозиторій коду Kubernetes.

Як CSI, так і FlexVolume дозволяють розробляти втулки томів незалежно від кодової бази Kubernetes і встановлювати їх (інсталювати) на кластерах Kubernetes як розширення.

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

csi

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

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

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

Том csi можна використовувати в Pod трьома різними способами:

Для налаштування постійного тому CSI адміністраторам доступні такі поля:

  • driver: Рядкове значення, яке вказує імʼя драйвера тома, яке треба використовувати. Це значення повинно відповідати значенню, що повертається відповіддю GetPluginInfoResponse драйвера CSI, як це визначено в специфікації CSI. Воно використовується Kubernetes для ідентифікації того, який драйвер CSI слід викликати, і драйверами CSI для ідентифікації того, які обʼєкти PV належать драйверу CSI.
  • volumeHandle: Рядкове значення, яке унікально ідентифікує том. Це значення повинно відповідати значенню, що повертається в полі volume.id відповіддю CreateVolumeResponse драйвера CSI, як це визначено в специфікації CSI. Значення передається як volume_id у всі виклики драйвера тома CSI при посиланні на том.
  • readOnly: Необовʼязкове булеве значення, яке вказує, чи повинен бути том «ControllerPublished» (приєднаний) як тільки для читання. Станадртно — false. Це значення передається драйверу CSI через поле readonly у ControllerPublishVolumeRequest.
  • fsType: Якщо VolumeMode PV — Filesystem, тоді це поле може бути використано для вказівки файлової системи, яку слід використовувати для монтування тому. Якщо том не був відформатований і підтримується форматування, це значення буде використано для форматування тому. Це значення передається драйверу CSI через поле VolumeCapability у ControllerPublishVolumeRequest, NodeStageVolumeRequest та NodePublishVolumeRequest.
  • volumeAttributes: Масив зі строк, що вказує статичні властивості тому. Цей масив має відповідати масиву, що повертається в полі volume.attributes відповіддю CreateVolumeResponse драйвера CSI, як це визначено в специфікації CSI. Масив передається драйверу CSI через поле volume_context у ControllerPublishVolumeRequest, NodeStageVolumeRequest та NodePublishVolumeRequest.
  • controllerPublishSecretRef: Посилання на обʼєкт secret, який містить конфіденційну інформацію для передачі драйверу CSI для завершення викликів ControllerPublishVolume та ControllerUnpublishVolume CSI. Це поле є необовʼязковим і може бути порожнім, якщо не потрібно жодного secretʼу. Якщо Secret містить більше одного secret, передаються всі secretʼи.
  • nodeExpandSecretRef: Посилання на secret, який містить конфіденційну інформацію для передачі драйверу CSI для завершення виклику NodeExpandVolume. Це поле є необовʼязковим і може бути порожнім, якщо не потрібен жоден secret. Якщо обʼєкт містить більше одного secret, передаються всі secretʼи. Коли ви налаштовуєте конфіденційні дані secret для розширення тому, kubelet передає ці дані через виклик NodeExpandVolume() драйверу CSI. Усі підтримувані версії Kubernetes пропонують поле nodeExpandSecretRef і мають його стандартно доступним. Випуски Kubernetes до v1.25 не включали цю підтримку.
  • Увімкніть функціональну можливість з назвою CSINodeExpandSecret для кожного kube-apiserver та для kubelet на кожному вузлі. З версії Kubernetes 1.27 цю функцію типово ввімкнено і не потрібно явно використовувати функціональну можливість. Також вам потрібно використовувати драйвер CSI, який підтримує або вимагає конфіденційні дані secret під час операцій зміни розміру зберігання, ініційованих вузлом.
  • nodePublishSecretRef: Посилання на обʼєкт secret, який містить конфіденційну інформацію для передачі драйверу CSI для завершення виклику NodePublishVolume. Це поле є необовʼязковим і може бути порожнім, якщо не потрібен жоден secret. Якщо обʼєкт secret містить більше одного secret, передаються всі secretʼи.
  • nodeStageSecretRef: Посилання на обʼєкт secret, який містить конфіденційну інформацію для передачі драйверу CSI для завершення виклику NodeStageVolume. Це поле є необовʼязковим і може бути порожнім, якщо не потрібен жоден secret. Якщо Secret містить більше одного secret, передаються всі secretʼи.

Підтримка CSI для блочних томів

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

Виробники зовнішніх драйверів CSI можуть реалізувати підтримку блочних томів безпосередньо в робочих навантаженнях Kubernetes.

Ви можете налаштувати ваш PersistentVolume/PersistentVolumeClaim із підтримкою блочний томів як зазвичай, без будь-яких конкретних змін CSI.

Ефемерні томи CSI

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

Ви можете безпосередньо налаштувати томи CSI в межах специфікації Pod. Такі томи є ефемерними і не зберігаються після перезапуску Podʼів. Див. Ефемерні томи для отримання додаткової інформації.

Для отримання додаткової інформації про те, як розробити драйвер CSI, див. документацію kubernetes-csi

Проксі CSI для Windows

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

Драйвери вузла CSI повинні виконувати різні привілейовані операції, такі як сканування пристроїв диска та монтування файлових систем. Ці операції відрізняються для кожної операційної системи хоста. Для робочих вузлів Linux, контейнеризовані вузли CSI зазвичай розгортуто як привілейовані контейнери. Для робочих вузлів Windows, підтримка привілеїрованих операцій для контейнеризованих вузлів CSI підтримується за допомогою csi-proxy, бінарного файлц, що розробляється спільнотою, який повинен бути встановлений на кожному вузлі Windows.

Докладніше див. в посібнику з розгортання втулку CSI, який ви хочете розгортати.

Міграція на драйвери CSI з вбудованих втулків

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

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

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

Вбудовані втулки, які підтримують CSIMigration і мають відповідний реалізований драйвер CSI перераховуються в Типи томів.

Підтримуються також вбудовані втулки, які підтримують постійне сховище на вузлах Windows:

flexVolume (застаріло)

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

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

Podʼи взаємодіють із драйверами FlexVolume через вбудований втулок тому flexVolume. Докладні відомості див. у документі FlexVolume README.

Наступні втулки FlexVolume, розгорнуті як сценарії PowerShell на хості, підтримують вузли Windows:

Поширення монтування

Поширення монтування дозволяє обʼєднувати томи, змонтовані контейнером, іншим контейнерам у тому ж Podʼі або навіть іншим Podʼам на тому самому вузлі.

Поширення монтування тому керується полем mountPropagation в containers[*].volumeMounts. Його значення такі:

  • None — Це монтування тома не отримає жодних подальших монтувань, які монтуються на цей том або будь-які його підкаталоги хостом. Також ніякі монтування, створені контейнером, не будуть видимими на хості. Це стандартний режим.

    Цей режим еквівалентний поширенню монтування rprivate, як описано в mount(8)

    Однак CRI runtime може вибрати поширення монтування rslave (тобто, HostToContainer), коли поширення rprivate не може бути використано. Відомо, що cri-dockerd (Docker) обирає поширення монтування rslave, коли джерело монтування містить кореневий каталог демона Docker (/var/lib/docker).

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

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

    Також, якщо будь-який Pod із поширенням монтування Bidirectional на той же том монтує будь-що там, контейнер із монтуванням HostToContainer буде це бачити.

    Цей режим еквівалентний поширенню монтування rslave, як описано в mount(8)

  • Bidirectional — Це монтування тома веде себе так само, як монтування HostToContainer. Крім того, всі монтування тома, створені контейнером, будуть поширені назад на хост і на всі контейнери всіх Podʼів, які використовують той самий том.

    Типовим використанням для цього режиму є Pod із драйвером FlexVolume або CSI або Pod, який повинен щось змонтувати на хості за допомогою тома типу hostPath.

    Цей режим еквівалентний поширенню монтування rshared, як описано в mount(8)

Монтування тільки для читання

Монтування може бути зроблено тільки для читання, втсановленням у поле .spec.containers[].volumeMounts[].readOnly значення true. Це не робить том сам по собі тільки для читання, але конкретний контейнер не зможе записувати в нього. Інші контейнери в Podʼі можуть монтувати той самий том з правами читання-запису.

У Linux, монтування тільки для читання стандартно не є рекурсивними. Наприклад, розгляньте Pod, який монтує /mnt хостів як том hostPath. Якщо існує інша файлова система, яка монтується для читання-запису на /mnt/<SUBMOUNT> (така як tmpfs, NFS або USB-сховище), то том, змонтований у контейнерах, також буде мати запис для /mnt/<SUBMOUNT>, навіть якщо монтування само було вказано як тільки для читання.

Рекурсивне монтування тільки для читання

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

Рекурсивне монтування тільки для читання може бути увімкнено встановленням функціональної можливості RecursiveReadOnlyMounts для kubelet та kube-apiserver, і встановленням поля .spec.containers[].volumeMounts[].recursiveReadOnly для Podʼа.

Допустимі значення:

  • Disabled (стандартно): без ефекту.
  • Enabled: робить монтування рекурсивно тільки для читання. Потрібно задовольняти всі наступні вимоги:
    • readOnly встановлено на true
    • mountPropagation не встановлено або встановлено на None
    • Хост працює з ядром Linux v5.12 або пізніше
    • Середовище виконання контейнерів рівня CRI підтримує рекурсивне монтування тільки для читання
    • Середовище виконання контейнерів рівня OCI підтримує рекурсивне монтування тільки для читання. Це не спрацює якщо хоча б одна з цих умов не виконується.
  • IfPossible: намагається застосувати Enabled і повертається до Disabled, якщо функція не підтримується ядром або класом середовища виконання.

Приклад:

apiVersion: v1
kind: Pod
metadata:
  name: rro
spec:
  volumes:
    - name: mnt
      hostPath:
        # tmpfs змонтовано у /mnt/tmpfs
        path: /mnt
  containers:
    - name: busybox
      image: busybox
      args: ["sleep", "infinity"]
      volumeMounts:
        # /mnt-rro/tmpfs не має права на запис
        - name: mnt
          mountPath: /mnt-rro
          readOnly: true
          mountPropagation: None
          recursiveReadOnly: Enabled
        # /mnt-ro/tmpfs має право на запис
        - name: mnt
          mountPath: /mnt-ro
          readOnly: true
        # /mnt-rw/tmpfs має право на запис
        - name: mnt
          mountPath: /mnt-rw

Коли ця властивість розпізнається kubelet та kube-apiserver, поле .status.containerStatuses[].volumeMounts[].recursiveReadOnly буде встановлено на Enabled або Disabled.

Реалізації

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

Рівень CRI:

Рівень OCI:

  • runc, починаючи з v1.1
  • crun, починаючи з v1.8.6

Що далі

Ознайомтесь з прикладом розгортання WordPress та MySQL з Persistent Volume.

3.6.2 - Постійні томи

Цей документ описує постійні томи (persistent volumes) в Kubernetes. Рекомендується вже мати уявлення про томи, StorageClasses та VolumeAttributesClasses.

Вступ

Управління зберіганням — це задача, що є відокремленою від управління обчислювальними ресурсами. Підсистема PersistentVolume надає API для користувачів та адміністраторів, яке абстрагує деталі того, як забезпечується зберігання від того, як воно використовується. Для цього ми вводимо два нових ресурси API: PersistentVolume та PersistentVolumeClaim.

PersistentVolume (PV) — це частина системи зберігання в кластері, яка була надана адміністратором або динамічно надана за допомогою Storage Classes. Це ресурс в кластері, так само як вузол — це ресурс кластера. PV — це втулки томів, так само як Volumes, але вони мають життєвий цикл, незалежний від будь-якого окремого Podʼа, який використовує PV. Цей обʼєкт API охоплює деталі реалізації зберігання, такі як NFS, iSCSI або система зберігання, специфічна для постачальника хмарних послуг.

PersistentVolumeClaim (PVC) — це запит на зберігання від користувача. Він схожий на Pod. Podʼи використовують ресурси вузла, а PVC використовують ресурси PV. Podʼи можуть запитувати конкретні рівні ресурсів (CPU та памʼять). Claims можуть запитувати конкретний розмір та режими доступу (наприклад, їх можна монтувати в режимі ReadWriteOnce, ReadOnlyMany, ReadWriteMany або ReadWriteOncePod, див. AccessModes).

Хоча PersistentVolumeClaims дозволяють користувачам споживати абстрактні ресурси зберігання, часто користувачам потрібні PersistentVolumes з різними властивостями, такими як продуктивність для різних завдань. Адміністратори кластера повинні мати можливість надавати різноманітні PersistentVolumes, які відрізняються не тільки розміром і режимами доступу, але й іншими характеристиками, не розголошуючи користувачам деталей того, як реалізовані ці томи. Для цих потреб існує ресурс StorageClass.

Дивіться докладний огляд із робочими прикладами.

Життєвий цикл тому та запиту

PV (PersistentVolume) — це ресурс в кластері. PVC (PersistentVolumeClaim) — це запити на ці ресурси та також діють як перевірки запитів ресурсів. Взаємодія між PV та PVC слідує такому життєвому циклу:

Виділення

Існує два способи надання PV: статичне чи динамічне.

Статичне

Адміністратор кластера створює кілька PV. Вони містять деталі реального зберігання, яке доступне для використання користувачами кластера. Вони існують в API Kubernetes і доступні для споживання.

Динамічне

Коли жоден зі статичних PV, які створив адміністратор, не відповідає PersistentVolumeClaim користувача, кластер може спробувати динамічно надати том спеціально для PVC. Це надання ґрунтується на StorageClasses: PVC повинен запитати клас зберігання, а адміністратор повинен створити та налаштувати цей клас для динамічного надання. Заявки, які запитують клас "", ефективно вимикають динамічне надання для себе.

Для активації динамічного надання сховища на основі класу зберігання адміністратор кластера повинен увімкнути контролер допуску DefaultStorageClass на API-сервері. Це можна зробити, наприклад, забезпечивши, що DefaultStorageClass знаходиться серед значень, розділених комами, у впорядкованому списку для прапорця --enable-admission-plugins компонента API-сервера. Для отримання додаткової інформації щодо прапорців командного рядка API-сервера перевірте документацію kube-apiserver.

Звʼязування

Користувач створює, або, у разі динамічного надання, вже створив, PersistentVolumeClaim із конкретним обсягом запитаного сховища та з певними режимами доступу. Цикл керування в панелі управління бачить нові PVC, знаходить відповідний PV (якщо це можливо), і звʼязує їх один з одним. Якщо PV був динамічно наданий для нового PVC, цикл завжди буде привʼязувати цей PV до PVC. В іншому випадку користувач завжди отримає принаймні те, про що вони просили, але том може бути більшим, ніж те, що було запитано. Як тільки звʼязування виконане, привʼязки PersistentVolumeClaim є ексклюзивними, незалежно від того, як вони були звʼязані. Привʼязка PVC до PV — це відображення один до одного, використовуючи ClaimRef, яке є двонапрямним звʼязуванням між PersistentVolume і PersistentVolumeClaim.

Заявки залишатимуться непривʼязаними нескінченно довго, якщо відповідного тому не існує. Заявки будуть привʼязані, в міру того як стають доступні відповідні томи. Наприклад, кластер, який має багато PV розміром 50Gi, не буде відповідати PVC розміром 100Gi. PVC може бути привʼязаний, коли до кластера додається PV розміром 100Gi.

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

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

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

Захист обʼєкта зберігання, що використовується

Мета функції захисту обʼєктів зберігання — це забезпечити, що PersistentVolumeClaims (PVC), які активно використовуються Podʼом, та PersistentVolume (PV), які привʼязані до PVC, не видаляються з системи, оскільки це може призвести до втрати даних.

Якщо користувач видаляє PVC, що активно використовується Podʼом, PVC не видаляється негайно. Видалення PVC відкладається до тих пір, поки PVC більше активно не використовується жодними Podʼами. Також, якщо адміністратор видаляє PV, який привʼязаний до PVC, PV не видаляється негайно. Видалення PV відкладається до тих пір, поки PV більше не є привʼязаним до PVC.

Ви можете перевірити, що PVC захищено, коли статус PVC — «Terminating», а список Finalizers включає kubernetes.io/pvc-protection:

kubectl describe pvc hostpath
Name:          hostpath
Namespace:     default
StorageClass:  example-hostpath
Status:        Terminating
Volume:
Labels:        <none>
Annotations:   volume.beta.kubernetes.io/storage-class=example-hostpath
               volume.beta.kubernetes.io/storage-provisioner=example.com/hostpath
Finalizers:    [kubernetes.io/pvc-protection]
...

Ви можете перевірити, що PV захищено, коли статус PV — «Terminating», а список Finalizers також включає kubernetes.io/pv-protection:

kubectl describe pv task-pv-volume
Name:            task-pv-volume
Labels:          type=local
Annotations:     <none>
Finalizers:      [kubernetes.io/pv-protection]
StorageClass:    standard
Status:          Terminating
Claim:
Reclaim Policy:  Delete
Access Modes:    RWO
Capacity:        1Gi
Message:
Source:
    Type:          HostPath (bare host directory volume)
    Path:          /tmp/data
    HostPathType:
Events:            <none>

Повторне використання

Коли користувач закінчує використання свого тому, він може видалити обʼєкти PVC з API, що дозволяє відновлення ресурсу. Політика відновлення для PersistentVolume повідомляє кластеру, що робити з томом після звільнення заявки на нього. Наразі томи можуть бути Retained, Recycled, або Deleted

Retain

Політика повторного використання Retain дозволяє ручне повторне використання ресурсу. Коли видаляється PersistentVolumeClaim, PersistentVolume все ще існує, і том вважається "звільненим". Але він ще не доступний для іншої заявки через те, що дані попередньої заявки залишаються на томі. Адміністратор може вручну відновити том виконавши наступні кроки.

  1. Видаліть PersistentVolume. Повʼязаний актив в зовнішній інфраструктурі все ще існує після видалення PV.
  2. Вручну очистіть дані на повʼязаному активі відповідно.
  3. Вручну видаліть повʼязаний актив.

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

Delete

Для втулків томів, які підтримують політику відновлення Delete, видалення видаляє як обʼєкт PersistentVolume з Kubernetes, так і повʼязаний актив зовнішньої інфраструктури. Томи, які були динамічно виділені, успадковують політику пвоторного використання їх StorageClass, яка типово встановлена в Delete. Адміністратор повинен налаштувати StorageClass відповідно до очікувань користувачів; в іншому випадку PV повинен бути відредагований або виправлений після створення. Див. Змінення політики повторного використання PersistentVolume.

Recycle

Якщо підтримується відповідний втулок томів, політика повторного використання Recycle виконує базове очищення (rm -rf /thevolume/*) тому та знову робить його доступним для нової заявки.

Однак адміністратор може налаштувати власний шаблон Podʼа для повторного використання тому за допомогою аргументів командного рядка контролера Kubernetes, як описано в довідці. Власний шаблон Podʼа повторного використання тому повинен містити специфікацію volumes, як показано у прикладі нижче:

apiVersion: v1
kind: Pod
metadata:
  name: pv-recycler
  namespace: default
spec:
  restartPolicy: Never
  volumes:
  - name: vol
    hostPath:
      path: /any/path/it/will/be/replaced
  containers:
  - name: pv-recycler
    image: "registry.k8s.io/busybox"
    command: ["/bin/sh", "-c", "test -e /scrub && rm -rf /scrub/..?* /scrub/.[!.]* /scrub/*  && test -z \"$(ls -A /scrub)\" || exit 1"]
    volumeMounts:
    - name: vol
      mountPath: /scrub

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

Завершувач захисту від видалення PersistentVolume

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

До PersistentVolume можна додавати завершувачі, щоб забезпечити, що PersistentVolume з політикою відновлення Delete буде видалено лише після видалення сховища, яке він забезпечував.

Завершувач external-provisioner.volume.kubernetes.io/finalizer (введений у v1.31) додається як до динамічно, так і до статично виділених томів CSI.

Завершувач kubernetes.io/pv-controller (введений у v1.31) додається до динамічно виділених томів внутрішнього втулка і пропускається для статично виділених томів внутрішнього втулка.

Ось приклад динамічно виділеного тому внутрішнього втулка:

kubectl describe pv pvc-74a498d6-3929-47e8-8c02-078c1ece4d78
Name:            pvc-74a498d6-3929-47e8-8c02-078c1ece4d78
Labels:          <none>
Annotations:     kubernetes.io/createdby: vsphere-volume-dynamic-provisioner
                 pv.kubernetes.io/bound-by-controller: yes
                 pv.kubernetes.io/provisioned-by: kubernetes.io/vsphere-volume
Finalizers:      [kubernetes.io/pv-protection kubernetes.io/pv-controller]
StorageClass:    vcp-sc
Status:          Bound
Claim:           default/vcp-pvc-1
Reclaim Policy:  Delete
Access Modes:    RWO
VolumeMode:      Filesystem
Capacity:        1Gi
Node Affinity:   <none>
Message:
Source:
    Type:               vSphereVolume (a Persistent Disk resource in vSphere)
    VolumePath:         [vsanDatastore] d49c4a62-166f-ce12-c464-020077ba5d46/kubernetes-dynamic-pvc-74a498d6-3929-47e8-8c02-078c1ece4d78.vmdk
    FSType:             ext4
    StoragePolicyName:  vSAN Default Storage Policy
Events:                 <none>

Завершувач external-provisioner.volume.kubernetes.io/finalizer додається для томів CSI. Наприклад:

Name:            pvc-2f0bab97-85a8-4552-8044-eb8be45cf48d
Labels:          <none>
Annotations:     pv.kubernetes.io/provisioned-by: csi.vsphere.vmware.com
Finalizers:      [kubernetes.io/pv-protection external-provisioner.volume.kubernetes.io/finalizer]
StorageClass:    fast
Status:          Bound
Claim:           demo-app/nginx-logs
Reclaim Policy:  Delete
Access Modes:    RWO
VolumeMode:      Filesystem
Capacity:        200Mi
Node Affinity:   <none>
Message:
Source:
    Type:              CSI (a Container Storage Interface (CSI) volume source)
    Driver:            csi.vsphere.vmware.com
    FSType:            ext4
    VolumeHandle:      44830fa8-79b4-406b-8b58-621ba25353fd
    ReadOnly:          false
    VolumeAttributes:      storage.kubernetes.io/csiProvisionerIdentity=1648442357185-8081-csi.vsphere.vmware.com
                           type=vSphere CNS Block Volume
Events:                <none>

Коли прапорець функції CSIMigration{provider} увімкнено для конкретного внутрішнього втулка, завершувач kubernetes.io/pv-controller замінюється завершувачем external-provisioner.volume.kubernetes.io/finalizer.

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

Резервування PersistentVolume

Панель управління може привʼязувати PersistentVolumeClaims до PersistentVolume в кластері. Однак, якщо вам потрібно, щоб PVC привʼязувався до певного PV, вам слід заздалегідь їх привʼязувати.

Вказавши PersistentVolume в PersistentVolumeClaim, ви оголошуєте привʼязку між цим конкретним PV та PVC. Якщо PersistentVolume існує і не зарезервував PersistentVolumeClaim через своє поле claimRef, тоді PersistentVolume і PersistentVolumeClaim будуть привʼязані.

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

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: foo-pvc
  namespace: foo
spec:
  storageClassName: "" # Порожній рядок повинен бути явно встановлений, інакше буде встановлено типовий StorageClass
  volumeName: foo-pv
  ...

Цей метод не гарантує жодних привʼязок для PersistentVolume. Якщо інші PersistentVolumeClaims можуть використовувати PV, який ви вказуєте, вам слід заздалегідь резервувати цей обсяг сховища. Вкажіть відповідний PersistentVolumeClaim у поле claimRef PV, щоб інші PVC не могли привʼязатися до нього.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: foo-pv
spec:
  storageClassName: ""
  claimRef:
    name: foo-pvc
    namespace: foo
  ...

Це корисно, якщо ви хочете використовувати PersistentVolumes з політикою повторного використання Retain, включаючи випадки, коли ви повторно використовуєте наявний PV.

Розширення Persistent Volume Claims

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.24 [stable]

Підтримка розширення PersistentVolumeClaims (PVCs) є типово увімкненою. Ви можете розширити наступні типи томів:

  • azureFile (застарілий)
  • csi
  • flexVolume (застарілий)
  • rbd (застарілий)
  • portworxVolume (застарілий)

Ви можете розширити PVC лише в тому випадку, якщо поле allowVolumeExpansion його класу сховища має значення true.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: example-vol-default
provisioner: vendor-name.example/magicstorage
parameters:
  resturl: "http://192.168.10.100:8080"
  restuser: ""
  secretNamespace: ""
  secretName: ""
allowVolumeExpansion: true

Для запиту більшого тому для PVC відредагуйте обʼєкт PVC та вказуйте більший розмір. Це спричинює розширення тому, який стоїть за основним PersistentVolume. Новий PersistentVolume ніколи не створюється для задоволення вимоги. Замість цього, змінюється розмір поточного тому.

Розширення томів CSI

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.24 [stable]

Підтримка розширення томів CSI типово увімкнена, але вона також вимагає, щоб конкретний драйвер CSI підтримував розширення тому. Зверніться до документації відповідного драйвера CSI для отримання додаткової інформації.

Зміна розміру тому, що містить файлову систему

Ви можете змінювати розмір томів, що містять файлову систему, тільки якщо файлова система є XFS, Ext3 або Ext4.

Коли том містить файлову систему, розмір файлової системи змінюється тільки тоді, коли новий Pod використовує PersistentVolumeClaim у режимі ReadWrite. Розширення файлової системи виконується при запуску нового Pod або коли Pod працює, і базова файлова система підтримує онлайн-розширення.

FlexVolumes (застарілий починаючи з Kubernetes v1.23) дозволяє змінювати розмір, якщо драйвер налаштований із можливістю RequiresFSResize встановленою в true. FlexVolume може бути змінений при перезапуску Pod.

Зміна розміру використовуваного PersistentVolumeClaim

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.24 [stable]

В цьому випадку вам не потрібно видаляти та перестворювати Pod або Deployment, який використовує наявний PVC. Будь-який PVC, який знаходиться у використанні, автоматично стає доступним для свого Pod, як тільки його файлова система буде розширена. Ця функція не впливає на PVC, які не використовуються Pod або Deployment. Ви повинні створити Pod, який використовує PVC, перш ніж розширення може завершитися.

Аналогічно іншим типам томів — томи FlexVolume також можуть бути розширені в разі використання Podʼом.

Відновлення після невдалих спроб розширення томів

Якщо користувач вказав новий розмір, який надто великий для задоволення базовою системою зберігання, розширення PVC буде намагатися робити спроби його задовольнити, доки користувач або адміністратор кластера не вживе будь-яких заходів. Це може бути небажаним, і, отже, Kubernetes надає наступні методи відновлення після таких невдач.

Якщо розширення базового сховища не вдається, адміністратор кластера може вручну відновити стан Persistent Volume Claim (PVC) та скасувати запити на зміну розміру. Інакше запити на зміну розміру буде продовжено автоматично контролером без втручання адміністратора.

  1. Позначте Persistent Volume (PV), який привʼязаний до Persistent Volume Claim (PVC), політикою вилучення Retain.
  2. Видаліть PVC. Оскільки PV має політику вилучення Retain, ми не втратимо жодних даних під час повторного створення PVC.
  3. Видаліть запис claimRef з характеристик PV, щоб новий PVC міг привʼязатися до нього. Це повинно зробити PV Available.
  4. Створіть заново PVC з меншим розміром, ніж у PV, і встановіть в поле volumeName PVC імʼя PV. Це повинно привʼязати новий PVC до наявного PV.
  5. Не забудьте відновити політику вилучення PV.

<div class="feature-state-notice feature-alpha">
  <span class="feature-state-name">СТАН ФУНКЦІОНАЛУ:</span> 
  <code>Kubernetes v1.23 [alpha]</code>
</div>

Якщо в вашому кластері увімкнено feature gate RecoverVolumeExpansionFailure, і розширення не вдалося для PVC, ви можете повторити спробу розширення з меншим розміром, ніж раніше запитаний. Щоб запросити нову спробу розширення з новим запропонованим розміром, відредагуйте .spec.resources для цього PVC і виберіть значення, яке менше за попереднє значення. Це корисно, якщо розширення до більшого значення не вдалося через обмеження місткості. Якщо це трапилося або ви підозрюєте, що це може трапитися, ви можете повторити спробу розширення, вказавши розмір, який знаходиться в межах обмежень місткості базового постачальника сховища. Ви можете слідкувати за станом операції зміни розміру, спостерігаючи за .status.allocatedResourceStatuses та подіями на PVC.

Зверніть увагу, що, навіть якщо ви можете вказати менше обсягу зберігання, ніж запитано раніше, нове значення все ще повинно бути вищим за .status.capacity. Kubernetes не підтримує зменшення PVC до меншого розміру, ніж його поточний розмір.

Типи Persistent Volume

Типи PersistentVolume реалізовані у вигляді втулків. Kubernetes наразі підтримує наступні втулки:

  • csi — Інтерфейс зберігання контейнерів (Container Storage Interface, CSI)
  • fc — Сховище Fibre Channel (FC)
  • hostPath — Том HostPath (для тестування на одному вузлі лише; НЕ ПРАЦЮВАТИМЕ в кластері з декількома вузлами; розгляньте використання тому local замість цього)
  • iscsi — Сховище iSCSI (SCSI через IP)
  • local — Локальні пристрої зберігання, підключені до вузлів.
  • nfs — Сховище в мережевій файловій системі (NFS)

Наступні типи PersistentVolume застарілі, але все ще доступні. Якщо ви використовуєте ці типи томів, окрім flexVolume, cephfs та rbd, будь ласка, встановіть відповідні драйвери CSI.

  • awsElasticBlockStore — AWS Elastic Block Store (EBS) (міграція типово увімкнена починаючи з v1.23)
  • azureDisk — Azure Disk (міграція типово увімкнена починаючи з v1.23)
  • azureFile — Azure File (міграція типово увімкнена починаючи з v1.24)
  • cinder — Cinder (блочне сховище OpenStack) (міграція типово увімкнена починаючи з v1.21)
  • flexVolume — FlexVolume (застаріло починаючи з версії v1.23, план міграції відсутній, планів припинення підтримки немає)
  • gcePersistentDisk — GCE Persistent Disk (застаріло починаючи з v1.23, план міграції відсутній, планів припинення підтримки немає)
  • portworxVolume — Том Portworx (міграція типово увімкнена починаючи з v1.31)
  • vsphereVolume - vSphere VMDK volume (міграція типово увімкнена починаючи з v1.25)

Старші версії Kubernetes також підтримували наступні типи вбудованих PersistentVolume:

  • cephfs (недоступно починаючи з версії v1.31)
  • flocker — Flocker storage. (недоступно починаючи з версії v1.25)
  • photonPersistentDisk — Photon controller persistent disk. (недоступно починаючи з версії v1.15)
  • quobyte — Том Quobyte. (недоступно починаючи з версії v1.25)
  • rbd — Rados Block Device (RBD) volume (недоступно починаючи з версії v1.31)
  • scaleIO — Том ScaleIO. (недоступно починаючи з версії v1.21)
  • storageos — Том StorageOS. (недоступно починаючи з версії v1.25)

Persistent Volumes

Кожен PersistentVolume (PV) містить специфікацію та статус, які являють собою характеристики та стан тому. Імʼя обʼєкта PersistentVolume повинно бути дійсним DNS імʼям субдомену.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv0003
spec:
  capacity:
    storage: 5Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Recycle
  storageClassName: slow
  mountOptions:
    - hard
    - nfsvers=4.1
  nfs:
    path: /tmp
    server: 172.17.0.2

Обсяг

Зазвичай у PV є конкретний обсяг зберігання. Він встановлюється за допомогою атрибута capacity PV, який є значенням кількості обсягу.

Наразі розмір — це єдиний ресурс, який можна встановити або вимагати. Майбутні атрибути можуть включати IOPS, пропускну здатність тощо.

Режим тому

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.18 [stable]

Kubernetes підтримує два режими volumeModes для PersistentVolumes: Filesystem та Block.

volumeMode є необовʼязковим параметром API. Filesystem є типовим режимом, який використовується, коли параметр volumeMode пропущено.

Том з volumeMode: Filesystem монтується в Podʼах в каталог. Якщо том підтримується блоковим пристроєм, і пристрій порожній, Kubernetes створює файлову систему на пристрої перед його першим монтуванням.

Ви можете встановити значення volumeMode в Block, щоб використовувати том як блоковий пристрій. Такий том представляється в Podʼі як блоковий пристрій, без будь-якої файлової системи на ньому. Цей режим корисний, щоб надати Podʼу найшвидший можливий спосіб доступу до тому, без будь-якого рівня файлової системи між Podʼом і томом. З іншого боку, застосунок, який працює в Podʼі, повинен знати, як взаємодіяти з блоковим пристроєм. Дивіться Підтримка блокового тому для прикладу використання тому з volumeMode: Block в Podʼі.

Режими доступу

PersistentVolume може бути підключений до вузла будь-яким способом, який підтримує постачальник ресурсів. Як показано в таблиці нижче, постачальники матимуть різні можливості, і кожному PV присвоюється набір режимів доступу, які описують можливості саме цього PV.

Режими доступу такі:

ReadWriteOnce
том може бути підключений як для читання-запису одним вузлом. Режим доступу ReadWriteOnce все ще може дозволяти доступ до тому для кількох Podʼів, коли Podʼи працюють на тому самому вузлі. Для доступу одного Podʼа, див. ReadWriteOncePod.
ReadOnlyMany
том може бути підключений як для читання лише багатьма вузлами.
ReadWriteMany
том може бути підключений як для читання-запису багатьма вузлами.
ReadWriteOncePod
СТАН ФУНКЦІОНАЛУ: Kubernetes v1.29 [stable]
том може бути підключений як для читання-запису одним Podʼом. Використовуйте режим доступу ReadWriteOncePod, якщо ви хочете забезпечити, що тільки один Pod по всьому кластеру може читати цей PVC або писати в нього.

У командному рядку режими доступу скорочено так:

  • RWO — ReadWriteOnce
  • ROX — ReadOnlyMany
  • RWX — ReadWriteMany
  • RWOP — ReadWriteOncePod

Важливо! Том може бути підключений лише одним режимом доступу одночасно, навіть якщо він підтримує багато.

Тип томуReadWriteOnceReadOnlyManyReadWriteManyReadWriteOncePod
AzureFile-
CephFS-
CSIзалежить від драйверазалежить від драйверазалежить від драйверазалежить від драйвера
FC--
FlexVolumeзалежить від драйвера-
HostPath---
iSCSI--
NFS-
RBD--
VsphereVolume-- (працює, коли Podʼи розташовані разом)-
PortworxVolume--

Class

PV може мати клас, який вказується, встановленням атрибуту storageClassName на імʼя StorageClass. PV певного класу може бути призначений лише до PVC, що запитує цей клас. PV без storageClassName не має класу і може бути призначений тільки до PVC, які не запитують жодного конкретного класу.

У минулому для цього використовувався атрибут volume.beta.kubernetes.io/storage-class замість storageClassName. Ця анотація все ще працює; однак вона повністю застаріє в майбутньому релізі Kubernetes.

Політика повторного використання

Поточні політики повторного використання:

  • Retain — ручне відновлення
  • Recycle — базова очистка (rm -rf /thevolume/*)
  • Delete — видалити том

Для Kubernetes 1.31 підтримують повторнн використання лише типи томів nfs та hostPath.

Параметри монтування

Адміністратор Kubernetes може вказати додаткові параметри монтування для випадку, коли постійний том монтується на вузлі.

Наступні типи томів підтримують параметри монтування:

  • azureFile
  • cephfs (застаріло в v1.28)
  • cinder (застаріло в v1.18)
  • iscsi
  • nfs
  • rbd (застаріло в v1.28)
  • vsphereVolume

Параметри монтування не перевіряються на валідність. Якщо параметр монтування недійсний, монтування не вдасться.

У минулому для цього використовувалася анотація volume.beta.kubernetes.io/mount-options замість атрибуту mountOptions. Ця анотація все ще працює; однак вона повністю застаріє в майбутньому релізі Kubernetes.

Node Affinity

Постійний том може вказувати властивості спорідненості вузла для визначення обмежень, які обмежують доступ до цього тому з визначених вузлів. Podʼи, які використовують PV, будуть заплановані тільки на ті вузли, які вибрані за допомогою спорідненості вузла. Щоб вказати спорідненість вузла, встановіть nodeAffinity в .spec PV. Деталі поля можна знайти у референсі API PersistentVolume.

Фаза

PersistentVolume може перебувати в одній з наступних фаз:

Available
вільний ресурс, який ще не призначений запиту
Bound
том призначено запиту
Released
запит було видалено, але повʼязане сховища ще не вилучено кластером
Failed
том не вдалося вилучити (автоматично)

Ви можете бачити імʼя PVC, призначеного для PV, використовуючи kubectl describe persistentvolume <імʼя>.

Час переходу фази

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.31 [stable]

Поле .status для PersistentVolume може включати альфа-поле lastPhaseTransitionTime. Це поле фіксує відмітку часу, коли том востаннє перейшов у свою фазу. Для новостворених томів фаза встановлюється як Pending, а lastPhaseTransitionTime встановлюється на поточний час.

PersistentVolumeClaims

Кожен PVC містить специфікацію та статус, які визначають вимоги та стан заявок. Імʼя обʼєкта PersistentVolumeClaim повинно бути дійсним DNS-піддоменом.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: myclaim
spec:
  accessModes:
    - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 8Gi
  storageClassName: slow
  selector:
    matchLabels:
      release: "stable"
    matchExpressions:
      - {key: environment, operator: In, values: [dev]}

Режим доступу

Заявки використовують ті ж самі конвенції, що й томи, коли вони вимагають зберігання з конкретними режимами доступу.

Режим тому

Заявки використовують ту ж саму конвенцію, що і томи, щоб вказати споживання тому як файлової системи чи блокового пристрою.

Ресурси

Заявки, подібно до Podʼів, можуть вимагати конкретну кількість ресурсів. У цьому випадку запит стосується зберігання. До заявок застосовується та ж модель ресурсів, що і до томів.

Селектор

Заявки можуть вказати селектор міток, щоб додатково фільтрувати набір томів. До заявки може бути привʼязано лише ті томи, мітки яких відповідають селектору. Селектор може складатися з двох полів:

  • matchLabels — том повинен містити мітку з таким значенням
  • matchExpressions — список вимог, які визначаються за допомогою ключа, списку значень та оператора, який повʼязує ключ і значення. Допустимі оператори включають In, NotIn, Exists та DoesNotExist.

Всі вимоги як з matchLabels, так і з matchExpressions обʼєднуються за допомогою ЛОГІЧНОГО «І» — всі вони повинні бути задоволені, щоб мати збіг.

Class

Заявка може вимагати певний клас, вказавши імʼя StorageClass за допомогою атрибута storageClassName. Тільки Томи з запитаним класом, тобто ті, у яких storageClassName збігається з PVC, можуть бути привʼязані до PVC.

PVC не обоʼязково повинен вимагати клас. PVC зі своїм storageClassName, встановленим рівним "", завжди інтерпретується як PVC, який вимагає PV без класу, тобто він може бути привʼязаний лише до PV без класу (без анотації або з анотацією, встановленою рівною ""). PVC без storageClassName не зовсім те ж саме і відзначається по-іншому кластером, залежно від того, чи включений втулок доступу DefaultStorageClass.

  • Якщо втулок доступу увімкнено, адміністратор може вказати типовий StorageClass. Усі PVC, у яких немає storageClassName, можуть бути привʼязані лише до PV з цим типовим StorageClass. Вказання типового StorageClass виконується, встановивши анотацію storageclass.kubernetes.io/is-default-class рівною true в обʼєкті StorageClass. Якщо адміністратор не вказав типовий StorageClass, кластер відповідає на створення PVC так, ніби втулок доступу був вимкнений. Якщо вказано більше одного типового StorageClass, для привʼязки PVC використовується остання версія типового StorageClass, коли PVC динамічно виділяється.
  • Якщо втулок доступу вимкнено, немає поняття типового StorageClass. Усі PVC, у яких storageClassName встановлено рівно "", можуть бути привʼязані лише до PV, у яких storageClassName також встановлено рівно "". Однак PVC з відсутнім storageClassName можна буде оновити пізніше, коли стане доступним типовий StorageClass. Якщо PVC оновлюється, він більше не буде привʼязуватися до PV з storageClassName, також встановленим рівно "".

Дивіться ретроактивне призначення типового StorageClass для отримання докладнішої інформації.

Залежно від методу встановлення, типовий StorageClass може бути розгорнутий в кластер Kubernetes менеджером надбудов під час встановлення.

Коли PVC вказує selector, крім вимоги типового StorageClass, вимоги використовують ЛОГІЧНЕ «І»: лише PV вказаного класу і з вказаними мітками може бути привʼязаний до PVC.

У минулому анотація volume.beta.kubernetes.io/storage-class використовувалася замість атрибута storageClassName. Ця анотація все ще працює; однак вона не буде підтримуватися в майбутньому релізі Kubernetes.

Ретроактивне призначення типового StorageClass

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.28 [stable]

Ви можете створювати PersistentVolumeClaim без вказівки storageClassName для нового PVC, і ви можете це робити навіть тоді, коли в кластері немає типового StorageClass. У цьому випадку новий PVC створюється так, як ви його визначили, і storageClassName цього PVC залишається невизначеним, доки не стане доступним типовий StorageClass.

Коли стає доступним типовий StorageClass, панель управління ідентифікує всі наявні PVC без storageClassName. Для PVC, у яких або встановлено порожнє значення для storageClassName, або цей ключ взагалі відсутній, панель управління оновлює ці PVC, встановлюючи storageClassName, щоб відповідати новому типовому StorageClass. Якщо у вас є наявний PVC, у якого storageClassName дорівнює "", і ви налаштовуєте типовий StorageClass, то цей PVC не буде оновлено.

Щоб продовжувати привʼязувати до PV з storageClassName, встановленим рівно "" (коли присутній типовий StorageClass), вам потрібно встановити storageClassName асоційованого PVC рівно "".

Це поведінка допомагає адміністраторам змінювати типовий StorageClass, видаляючи спочатку старий, а потім створюючи або встановлюючи інший. Це короткочасне вікно, коли немає типового StorageClass, призводить до того, що PVC без storageClassName, створені в цей час, не мають жодного типового значення, але завдяки ретроактивному призначенню типового StorageClass цей спосіб зміни типових значень є безпечним.

Заявки як томи

Podʼи отримують доступ до сховища, використовуючи заявки як томи. Заявки повинні існувати в тому ж просторі імен, що і Pod, який її використовує. Кластер знаходить заявку в просторі імен Pod і використовує її для отримання PersistentVolume, який підтримує заявку. Потім том монтується на хост та у Pod.

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
    - name: myfrontend
      image: nginx
      volumeMounts:
      - mountPath: "/var/www/html"
        name: mypd
  volumes:
    - name: mypd
      persistentVolumeClaim:
        claimName: myclaim

Примітка щодо просторів імен

Привʼязки PersistentVolumes є ексклюзивними, і оскільки PersistentVolumeClaims є обʼєктами з простором імен, монтування заявк з режимами "Many" (ROX, RWX) можливе лише в межах одного простору імен.

PersistentVolumes типу hostPath

PersistentVolume типу hostPath використовує файл або каталог на вузлі для емуляції мережевого сховища. Див. приклад тому типу hostPath.

Підтримка блокового тому

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.18 [stable]

Наступні втулки томів підтримують блокові томи, включаючи динамічне надання, де це можливо:

  • CSI
  • FC (Fibre Channel)
  • iSCSI
  • Локальний том
  • OpenStack Cinder
  • RBD (застаріло)
  • RBD (Ceph Block Device; застаріло)
  • VsphereVolume

PersistentVolume, що використовує блоковий том

apiVersion: v1
kind: PersistentVolume
metadata:
  name: block-pv
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  volumeMode: Block
  persistentVolumeReclaimPolicy: Retain
  fc:
    targetWWNs: ["50060e801049cfd1"]
    lun: 0
    readOnly: false

PersistentVolumeClaim, який запитує блоковий том

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: block-pvc
spec:
  accessModes:
    - ReadWriteOnce
  volumeMode: Block
  resources:
    requests:
      storage: 10Gi

Специфікація Pod з додаванням шляху блокового пристрою в контейнер

apiVersion: v1
kind: Pod
metadata:
  name: pod-with-block-volume
spec:
  containers:
    - name: fc-container
      image: fedora:26
      command: ["/bin/sh", "-c"]
      args: [ "tail -f /dev/null" ]
      volumeDevices:
        - name: data
          devicePath: /dev/xvda
  volumes:
    - name: data
      persistentVolumeClaim:
        claimName: block-pvc

Привʼязка блокових томів

Якщо користувач вимагає блокового тому, вказавши це за допомогою поля volumeMode у специфікації PersistentVolumeClaim, правила привʼязки трохи відрізняються від попередніх версій, які не враховували цей режим як частину специфікації. У таблиці наведено можливі комбінації, які користувач і адміністратор можуть вказати для запиту блокового пристрою. Таблиця показує, чи буде привʼязаний том чи ні, враховуючи ці комбінації: Матриця привʼязки томів для статично виділених томів:

PV volumeModePVC volumeModeРезультат
не вказаноне вказаноПРИВ'ЯЗАНИЙ
не вказаноБлоковийНЕ ПРИВ'ЯЗАНИЙ
не вказаноФайлова системаПРИВ'ЯЗАНИЙ
Блоковийне вказаноНЕ ПРИВ'ЯЗАНИЙ
БлоковийБлоковийПРИВ'ЯЗАНИЙ
БлоковийФайлова системаНЕ ПРИВ'ЯЗАНИЙ
Файлова системаФайлова системаПРИВ'ЯЗАНИЙ
Файлова системаБлоковийНЕ ПРИВ'ЯЗАНИЙ
Файлова системане вказаноПРИВ'ЯЗАНИЙ

Підтримка знімків томів та відновлення тому зі знімка

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.20 [stable]

Знімки томів підтримують лише зовнішні втулки томів CSI. Докладні відомості див. у Знімках томів. Втулки томів, які входять до складу Kubernetes, є застарілими. Про застарілі втулки томів можна прочитати в ЧаПи втулків томів.

Створення PersistentVolumeClaim із знімка тому

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: restore-pvc
spec:
  storageClassName: csi-hostpath-sc
  dataSource:
    name: new-snapshot-test
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

Клонування томів

Клонування томів доступне лише для втулків томів CSI.

Створення PersistentVolumeClaim із існуючого PVC

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: cloned-pvc
spec:
  storageClassName: my-csi-plugin
  dataSource:
    name: existing-src-pvc-name
    kind: PersistentVolumeClaim
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

Наповнювачі томів та джерела даних

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.24 [beta]

Kubernetes підтримує користувацькі заповнювачі томів. Для використання користувацьких заповнювачів томів слід увімкнути функціональну можливість AnyVolumeDataSource для kube-apiserver та kube-controller-manager.

Наповнювачі томів використовують поле специфікації PVC, що називається dataSourceRef. На відміну від поля dataSource, яке може містити тільки посилання на інший PersistentVolumeClaim або на VolumeSnapshot, поле dataSourceRef може містити посилання на будь-який обʼєкт у тому ж просторі імен, за винятком основних обʼєктів, окрім PVC. Для кластерів, які мають увімкнутий feature gate, використання dataSourceRef бажано перед dataSource.

Джерела даних зі змішаними просторами імен

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.26 [alpha]

Kubernetes підтримує джерела даних томів зі змішаними просторами імен. Для використання джерел даних томів із змішаними просторами імен слід увімкнути функціональну можливість AnyVolumeDataSource та CrossNamespaceVolumeDataSource для kube-apiserver та kube-controller-manager. Також вам слід увімкнути CrossNamespaceVolumeDataSource для csi-provisioner.

Увімкнення CrossNamespaceVolumeDataSource дозволяє вам вказати простір імен у полі dataSourceRef.

Посилання на джерела даних

Поле dataSourceRef поводиться майже так само, як і поле dataSource. Якщо в одне задано, а інше — ні, сервер API надасть обом полям одне й те ж значення. Жодне з цих полів не можна змінити після створення, і спроба вказати різні значення для обох полів призведе до помилки перевірки правильності. Таким чином, обидва поля завжди матимуть однаковий вміст.

Є дві різниці між полем dataSourceRef і полем dataSource, які користувачам слід знати:

  • Поле dataSource ігнорує неправильні значення (мовби поле було порожнім), тоді як поле dataSourceRef ніколи не ігнорує значення і призведе до помилки, якщо використано неправильне значення. Неправильними значеннями є будь-які обʼєкти основних обʼєктів (обʼєкти без apiGroup), окрім PVC.
  • Поле dataSourceRef може містити обʼєкти різних типів, тоді як поле dataSource дозволяє лише PVC та VolumeSnapshot.

Коли увімкнено CrossNamespaceVolumeDataSource, є додаткові відмінності:

  • Поле dataSource дозволяє лише локальні обʼєкти, тоді як поле dataSourceRef дозволяє обʼєкти у будь-яких просторах імен.
  • Коли вказано простір імен, dataSource і dataSourceRef не синхронізуються.

Користувачам завжди слід використовувати dataSourceRef в кластерах, де увімкнено feature gate, і використовувати dataSource в кластерах, де він вимкнений. В будь-якому випадку необхідно дивитися на обидва поля. Дубльовані значення із трошки різними семантиками існують лише з метою забезпечення сумісності з попередніми версіями. Зокрема, старі й нові контролери можуть взаємодіяти, оскільки поля однакові.

Використання засобів наповнення томів

Засоби наповнення томів — це контролери, які можуть створювати томи з не порожнім вмістом, де вміст тому визначається за допомогою Custom Resource. Користувачі створюють наповнений том, посилаючись на Custom Resource із використанням поля dataSourceRef:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: populated-pvc
spec:
  dataSourceRef:
    name: example-name
    kind: ExampleDataSource
    apiGroup: example.storage.k8s.io
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

Оскільки засоби наповнення томів — це зовнішні компоненти, спроби створити PVC, який використовує їх, можуть завершитися неуспішно, якщо встановлені не всі необхідні компоненти. Зовнішні контролери повинні генерувати події на PVC для надання зворотного звʼязку щодо стану створення, включаючи попередження, якщо PVC не може бути створено через відсутність деякого компонента.

Ви можете встановити альфа-контролер перевірки джерела даних тому у вашому кластері. Цей контролер генерує події попередження на PVC у випадку, якщо не зареєстровано жодного засобу наповнення для обробки цього виду джерела даних. Коли для PVC встановлюється відповідний засіб наповнення, це відповідальність цього контролера наповнення повідомляти про події, що стосуються створення тому та проблем під час цього процесу.

Використання джерела даних томів зі змішаними просторами імен

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.26 [alpha]

Створіть ReferenceGrant, щоб дозволити власнику простору імен приймати посилання. Ви визначаєте наповнений том, вказавши джерело даних тому між просторами імен за допомогою поля dataSourceRef. Вам вже повинен бути дійсний ReferenceGrant у вихідному просторі імен:

apiVersion: gateway.networking.k8s.io/v1beta1
kind: ReferenceGrant
metadata:
  name: allow-ns1-pvc
  namespace: default
spec:
  from:
  - group: ""
    kind: PersistentVolumeClaim
    namespace: ns1
  to:
  - group: snapshot.storage.k8s.io
    kind: VolumeSnapshot
    name: new-snapshot-demo
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: foo-pvc
  namespace: ns1
spec:
  storageClassName: example
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  dataSourceRef:
    apiGroup: snapshot.storage.k8s.io
    kind: VolumeSnapshot
    name: new-snapshot-demo
    namespace: default
  volumeMode: Filesystem

Написання переносимої конфігурації

Якщо ви пишете шаблони конфігурації або приклади, які повинні працювати на широкому спектрі кластерів і вам потрібне постійний сховище, рекомендується використовувати такий підхід:

  • Включайте обʼєкти PersistentVolumeClaim у ваш набір конфігурації (нарізі з Deployment, ConfigMap і т. д.).
  • Не включайте обєкти PersistentVolume в конфігурацію, оскільки користувач, який створює конфігурацію, може не мати прав на створення PersistentVolumes.
  • Дайте користувачеві можливість надавати імʼя класу сховища при створенні шаблону.
    • Якщо користувач вказує імʼя класу сховища, вставте це значення в поле persistentVolumeClaim.storageClassName. Це призведе до збігу PVC з відповідним класом сховища, якщо в адміністратора увімкнені класи сховища.
    • Якщо користувач не вказує імʼя класу сховища, залиште поле persistentVolumeClaim.storageClassName нульовим. Це призведе до автоматичного надання користувачеві PV в кластері. Багато середовищ кластеру мають типовий клас сховища, або адміністратори можуть створити свій типовий клас сховища.
  • В інструментах спостерігайте за PVC, які не привʼязуються протягом певного часу та виводьте це користувачеві, оскільки це може вказувати на те, що у кластері відсутня підтримка динамічного сховища (у цьому випадку користувач повинен створити відповідний PV) або у кластері відсутня система сховища (у цьому випадку користувач не може розгортати конфігурацію, що вимагає PVC).

Що далі

API references

Дізнайтеся більше про описані на цій сторінці API:

3.6.3 - Projected томи

У цьому документі описано спроєцьовані томи в Kubernetes. Рекомендується ознайомитися з томами для кращого розуміння.

Вступ

Том projected відображає кілька наявних джерел томів в один каталог.

Зараз наступні типи джерел томів можуть бути спроєцьовані:

Всі джерела повинні бути в тому ж просторі імен, що й Pod. Для отримання додаткових відомостей дивіться документ з дизайну все-в-одному томі.

Приклад конфігурації з secret, downwardAPI та configMap

apiVersion: v1
kind: Pod
metadata:
  name: volume-test
spec:
  containers:
  - name: container-test
    image: busybox:1.28
    command: ["sleep", "3600"]
    volumeMounts:
    - name: all-in-one
      mountPath: "/projected-volume"
      readOnly: true
  volumes:
  - name: all-in-one
    projected:
      sources:
      - secret:
          name: mysecret
          items:
            - key: username
              path: my-group/my-username
      - downwardAPI:
          items:
            - path: "labels"
              fieldRef:
                fieldPath: metadata.labels
            - path: "cpu_limit"
              resourceFieldRef:
                containerName: container-test
                resource: limits.cpu
      - configMap:
          name: myconfigmap
          items:
            - key: config
              path: my-group/my-config

Приклад конфігурації: secret з встановленим нестандартним режимом дозволу

apiVersion: v1
kind: Pod
metadata:
  name: volume-test
spec:
  containers:
  - name: container-test
    image: busybox:1.28
    command: ["sleep", "3600"]
    volumeMounts:
    - name: all-in-one
      mountPath: "/projected-volume"
      readOnly: true
  volumes:
  - name: all-in-one
    projected:
      sources:
      - secret:
          name: mysecret
          items:
            - key: username
              path: my-group/my-username
      - secret:
          name: mysecret2
          items:
            - key: password
              path: my-group/my-password
              mode: 511

Кожне спроєцьоване джерело тому перераховане в специфікації в розділі sources. Параметри майже такі ж, за винятком двох пунктів:

  • Для секретів поле secretName було змінено на name, щоб бути послідовним з назвою ConfigMap.
  • defaultMode можна вказати тільки на рівні спроєцьованого тому, а не для кожного джерела тому. Однак, як показано вище, ви можете явно встановити mode для кожної окремої проєкції.

Спроєцьовані томи serviceAccountToken

Ви можете впровадити токен для поточного service accountʼу в Pod за вказаним шляхом. Наприклад:

apiVersion: v1
kind: Pod
metadata:
  name: sa-token-test
spec:
  containers:
  - name: container-test
    image: busybox:1.28
    command: ["sleep", "3600"]
    volumeMounts:
    - name: token-vol
      mountPath: "/service-account"
      readOnly: true
  serviceAccountName: default
  volumes:
  - name: token-vol
    projected:
      sources:
      - serviceAccountToken:
          audience: api
          expirationSeconds: 3600
          path: token

Pod в прикладі має project том, що містить впроваджений токен service account. Контейнери в цьому Pod можуть використовувати цей токен для доступу до сервера API Kubernetes, автентифікуючись за відомостями service accountʼу Pod. Поле audience містить призначену аудиторію токена. Отримувач токена повинен ідентифікувати себе за ідентифікатором, вказаним в аудиторії токена, інакше він повинен відхилити токен. Це поле є необовʼязковим, але стандартним для ідентифікації в API сервері.

Поле expirationSeconds містить час, через який токен стане недійсним. Типовим є час в одну годину, але він має бути принаймні 10 хвилин (600 секунд). Адміністратор може обмежити максимальне значення вказавши параметр --service-account-max-token-expiration в API сервері. Поле path містить відносний шлях до точки монтування тому.

Спроєцьовані томи clusterTrustBundle

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.29 [alpha]

Спроєцьований том clusterTrustBundle дозволяє впроваджувати контент одного чи більше обʼєктів ClusterTrustBundle як автоматично оновлюваний файл у файловій системі контейнера.

ClusterTrustBundle може бути обраний за допомогою name або signer name.

Для вибору за імʼям використовуйте поле name, щоб вказати один обʼєкт ClusterTrustBundle.

Для вибору за імʼям підписанта використовуйте поле signerName (і, за необхідності, поле labelSelector), щоб вказати набір обʼєктів ClusterTrustBundle, які використовують задане імʼя підписанта. Якщо labelSelector відсутнє, то вибираються всі ClusterTrustBundle для цього підписанта.

Kubelet виконує відсіювання дублікатів сертифікатів у вибраних обʼєктах ClusterTrustBundle, нормалізує представлення PEM (видаляючи коментарі та заголовки), перегруповує сертифікати та записує їх у файл, вказаний полем path. При зміні набору вибраних обʼєктів ClusterTrustBundle або їх вмісту kubelet підтримує актуальність файлу.

Типово kubelet запобігає запуску Podʼа, якщо заданий обʼєкт ClusterTrustBundle не знайдено, або якщо signerName / labelSelector не відповідає жодному обʼєкту ClusterTrustBundle. Якщо ця поведінка не відповідає вашим вимогам, встановіть поле optional в true, і Pod буде запущено з порожнім файлом за шляхом path.

apiVersion: v1
kind: Pod
metadata:
  name: sa-ctb-name-test
spec:
  containers:
  - name: container-test
    image: busybox
    command: ["sleep", "3600"]
    volumeMounts:
    - name: token-vol
      mountPath: "/root-certificates"
      readOnly: true
  serviceAccountName: default
  volumes:
  - name: token-vol
    projected:
      sources:
      - clusterTrustBundle:
          name: example
          path: example-roots.pem
      - clusterTrustBundle:
          signerName: "example.com/mysigner"
          labelSelector:
            matchLabels:
              version: live
          path: mysigner-roots.pem
          optional: true

Взаємодія SecurityContext

Пропозиція щодо обробки дозволів файлів у розширенні projected service account volume представляє, що projected файли мають відповідні набори дозволів власника.

Linux

У Podʼах Linux, які мають projected том та RunAsUser вказано у SecurityContext, projected файли мають правильно встановлені права власності, включаючи власника контейнера.

Коли у всіх контейнерах в Podʼі встановлено одне й те ж runAsUser у їх PodSecurityContext або SecurityContext, то kubelet гарантує, що вміст тому serviceAccountToken належить цьому користувачеві, а файл токена має режим дозволів, встановлений в 0600.

Windows

У Windows Podʼах, які мають projected том та RunAsUsername вказано в SecurityContext Podʼа, права власності не забезпечуються через спосіб управління користувачами у Windows. Windows зберігає та управляє локальними обліковими записами користувачів і груп у файлі бази даних, який називається Security Account Manager (SAM). Кожен контейнер підтримує свій власний екземпляр бази даних SAM, до якого хост не має доступу під час роботи контейнера. Контейнери Windows призначені для запуску режиму користувача операційної системи в ізоляції від хосту, тому не зберігають динамічну конфігурацію власності файлів хосту для облікових записів віртуалізованих контейнерів. Рекомендується розміщувати файли, які слід спільно використовувати з контейнером на машині-хості, в окремому змісті поза C:\.

Типово у projected файлах буде встановлено наступні права, як показано для прикладу projected файлу тома:

PS C:\> Get-Acl C:\var\run\secrets\kubernetes.io\serviceaccount\..2021_08_31_22_22_18.318230061\ca.crt | Format-List

Path   : Microsoft.PowerShell.Core\FileSystem::C:\var\run\secrets\kubernetes.io\serviceaccount\..2021_08_31_22_22_18.318230061\ca.crt
Owner  : BUILTIN\Administrators
Group  : NT AUTHORITY\SYSTEM
Access : NT AUTHORITY\SYSTEM Allow  FullControl
         BUILTIN\Administr

ators Allow  FullControl
         BUILTIN\Users Allow  ReadAndExecute, Synchronize
Audit  :
Sddl   : O:BAG:SYD:AI(A;ID;FA;;;SY)(A;ID;FA;;;BA)(A;ID;0x1200a9;;;BU)

Це означає, що всі адміністратори, такі як ContainerAdministrator, матимуть доступ на читання, запис та виконання, тоді як не-адміністратори матимуть доступ на читання та виконання.

3.6.4 - Ефемерні томи

Цей документ описує ефемерні томи в Kubernetes. Рекомендується мати знайомство з томами, зокрема з PersistentVolumeClaim та PersistentVolume.

Деякі застосунки потребують додаткових ресурсів зберігання, але їм не важливо, чи зберігаються ці дані постійно між перезавантаженнями. Наприклад, служби кешування часто обмежені обсягом памʼяті та можуть переміщувати рідко використовувані дані в ресурси зберігання, які є повільнішими за памʼять з мінімальним впливом на загальну продуктивність.

Інші застосунки очікують, що деякі дані тільки-для-читання будуть присутні в файлах, таких як конфігураційні дані або секретні ключі.

Ефемерні томи призначені для таких сценаріїв використання. Оскільки томи слідкують за життєвим циклом Podʼа та створюються і видаляються разом з Podʼом, Podʼи можуть бути зупинені та перезапущені, не обмежуючись тим, чи доступний будь-який постійний том.

Ефемерні томи вказуються inline в специфікації Podʼа, що спрощує розгортання та управління застосунками.

Типи ефемерних томів

Kubernetes підтримує кілька різновидів ефемерних томів для різних цілей:

  • emptyDir: порожній при запуску Podʼа, зберігання здійснюється локально з базового каталогу kubelet (зазвичай кореневий диск) або в ОЗП
  • configMap, downwardAPI, secret: впровадження різних видів даних Kubernetes в Podʼі
  • image: дозволяє монтувати файли образів контейнерів або артефактів, безпосередньо у Pod.
  • CSI ефемерні томи: схожі на попередні види томів, але надаються спеціальними драйверами CSI, які спеціально підтримують цю функцію
  • загальні ефемерні томи, які можуть бути надані всіма драйверами зберігання, які також підтримують постійні томи

emptyDir, configMap, downwardAPI, secret надаються як локальне ефемерне сховище. Вони керуються kubelet на кожному вузлі.

CSI ефемерні томи обовʼязково повинні надаватися сторонніми драйверами зберігання CSI.

Загальні ефемерні томи можуть надаватися сторонніми драйверами зберігання CSI, але також будь-яким іншим драйвером зберігання, який підтримує динамічне виділення томів. Деякі драйвери CSI написані спеціально для ефемерних томів CSI та не підтримують динамічного виділення: їх тоді не можна використовувати для загальних ефемерних томів.

Перевагою використання сторонніх драйверів є те, що вони можуть пропонувати функціональність, яку Kubernetes сам не підтримує, наприклад сховища з іншими характеристиками продуктивності, ніж диск, яким керує kubelet, або впровадження різних даних.

Ефемерні томи CSI

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.25 [stable]

Концептуально, ефемерні томи CSI схожі на типи томів configMap, downwardAPI та secret: ресурси зберігання керується локально на кожному вузлі та створюються разом з іншими локальними ресурсами після того, як Pod було заплановано на вузол. Kubernetes не має поняття про перепланування Podʼів на цьому етапі. Створення тому має бути малоймовірним, інакше запуск Podʼа застрягне. Зокрема, планування Podʼів з урахуванням потужності ресурсів зберігання не підтримується для цих томів. Наразі вони також не входять до обмежень використання томів зберігання Podʼа, оскільки це є чимось, що kubelet може забезпечити лише для ресурсу зберігання, яким він управляє самостійно.

Ось приклад маніфесту для Podʼа, який використовує ефемерне зберігання CSI:

kind: Pod
apiVersion: v1
metadata:
  name: my-csi-app
spec:
  containers:
    - name: my-frontend
      image: busybox:1.28
      volumeMounts:
      - mountPath: "/data"
        name: my-csi-inline-vol
      command: [ "sleep", "1000000" ]
  volumes:
    - name: my-csi-inline-vol
      csi:
        driver: inline.storage.kubernetes.io
        volumeAttributes:
          foo: bar

Атрибути тому визначають, який том підготовлює драйвер. Ці атрибути є специфічними для кожного драйвера і не стандартизовані. Дивіться документацію кожного драйвера CSI для отримання додаткових інструкцій.

Обмеження драйверів CSI

Ефемерні томи CSI дозволяють користувачам передавати volumeAttributes прямо до драйвера CSI як частину специфікації Podʼа. Драйвер CSI, який дозволяє використання volumeAttributes, які зазвичай обмежені для адміністраторів, НЕ підходить для використання в ефемерному томі всередині Podʼа. Наприклад, параметри, які зазвичай визначаються в StorageClass, не повинні використовуватися користувачами через ефемерні томи всередині.

Адміністратори кластера, яким потрібно обмежити драйвери CSI, які дозволяють використання вбудованих томів всередині специфікації Podʼа, можуть зробити це, виконавши наступне:

  • Видаліть Ephemeral із volumeLifecycleModes в специфікації CSIDriver, що перешкоджає використанню драйвера в якості вбудованого ефемерного тому.
  • Використання admission webhook для обмеження того, як цей драйвер використовується.

Загальні ефемерні томи

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.23 [stable]

Загальні ефемерні томи схожі на томи emptyDir в тому сенсі, що вони надають директорію на кожен Pod для тимчасових даних, які, як правило, порожні після створення. Але вони також можуть мати додаткові функції:

Приклад:

kind: Pod
apiVersion: v1
metadata:
  name: my-app
spec:
  containers:
    - name: my-frontend
      image: busybox:1.28
      volumeMounts:
      - mountPath: "/scratch"
        name: scratch-volume
      command: [ "sleep", "1000000" ]
  volumes:
    - name: scratch-volume
      ephemeral:
        volumeClaimTemplate:
          metadata:
            labels:
              type: my-frontend-volume
          spec:
            accessModes: [ "ReadWriteOnce" ]
            storageClassName: "scratch-storage-class"
            resources:
              requests:
                storage: 1Gi

Життєвий цикл та PersistentVolumeClaim

Ключова концепція дизайну полягає в тому, що параметри для вимог тому дозволені всередині джерела тому Podʼа. Підтримуються мітки, анотації та весь набір полів для PersistentVolumeClaim. Коли такий Pod створюється, контролер ефемерних томів створює фактичний обʼєкт PersistentVolumeClaim в тому ж просторі імен, що і Pod, та забезпечує видалення PersistentVolumeClaim при видаленні Podʼа.

Це викликає привʼязку та/або резервування тому, або негайно, якщо StorageClass використовує негайне звʼязування тому, або коли Pod тимчасово запланований на вузол (WaitForFirstConsumer volume binding mode). Останній варіант рекомендований для загальних ефемерних томів, оскільки тоді планувальник може вибрати відповідний вузол для Podʼа. При негайному звʼязуванні планувальник змушений вибрати вузол, який має доступ до тому, якщо він доступний.

З погляду прав власності на ресурси, Pod, який має загальний ефемерний том, є власником PersistentVolumeClaim(s), які забезпечують цей ефемерний том. При видаленні Podʼа, збирач сміття Kubernetes видаляє PVC, що, як правило, спричиняє видалення тому через типову політику повторного використання класів зберігання — видалення томів. Ви можете створити квазі-ефемерне локальне зберігання за допомогою StorageClass з політикою повторного використання retain: ресурс зберігання існує поза життєвим циклом Podʼа, і в цьому випадку потрібно забезпечити, що очищення тому відбувається окремо.

Поки ці PVC існують, їх можна використовувати, подібно до будь-якого іншого PVC. Зокрема, їх можна вказати як джерело даних для клонування томів або створення знімків. Обʼєкт PVC також містить поточний статус тому.

Найменування PersistentVolumeClaim

Найменування автоматично створених PVC є детермінованим: назва є комбінацією назви Podʼа і назви тому, з дефісом (-) посередині. У вищезазначеному прикладі назва PVC буде my-app-scratch-volume. Це детерміноване найменування полегшує взаємодію з PVC, оскільки не потрібно шукати її, якщо відомі назва Podʼа та назва тому.

Детерміноване найменування також вводить потенційний конфлікт між різними Podʼами (Pod "pod-a" з томом "scratch" і інший Pod з імʼям "pod" і томом "a-scratch" обидва отримають однакове найменування PVC "pod-a-scratch") і між Podʼами та PVC, створеними вручну.

Такі конфлікти виявляються: PVC використовується лише для ефемерного тому, якщо він був створений для Podʼа. Ця перевірка базується на стосунках власності на ресурси. Наявний PVC не перезаписується або не змінюється. Проте це не вирішує конфлікт, оскільки без відповідного PVC Pod не може стартувати.

Безпека

Використання загальних ефемерних томів дозволяє користувачам створювати PVC непрямо, якщо вони можуть створювати Podʼи, навіть якщо у них немає дозволу на створення PVC безпосередньо. Адміністраторам кластера слід бути обізнаними щодо цього. Якщо це не відповідає їхньому зразку безпеки, вони повинні використовувати admission webhook, який відхиляє обʼєкти, такі як Podʼи, які мають загальний ефемерний том.

Звичайне обмеження квоти для PVC в просторі імен все ще застосовується, тому навіть якщо користувачам дозволено використовувати цей новий механізм, вони не можуть використовувати його для оминання інших політик.

Що далі

Ефемерні томи, керовані kubelet

Див. локальне ефемерне сховище.

Ефемерні томи CSI

Загальні ефемерні томи

3.6.5 - Класи сховищ

Цей документ описує концепцію StorageClass в Kubernetes. Рекомендується мати знайомство з томами та постійними томами.

StorageClass надає можливість адміністраторам описати класи сховищ, які вони надають. Різні класи можуть відповідати рівням обслуговування, політикам резервного копіювання або будь-яким політикам, визначеним адміністраторами кластера. Kubernetes сам не визначає, що являють собою класи.

Концепція Kubernetes StorageClass схожа на "профілі" в деяких інших дизайнах систем збереження.

Обʼєкти StorageClass

Кожен StorageClass містить поля provisioner, parameters та reclaimPolicy, які використовуються, коли PersistentVolume, який належить до класу, має бути динамічно резервований для задоволення PersistentVolumeClaim (PVC).

Імʼя обʼєкта StorageClass має значення, і саме воно дозволяє користувачам запитувати певний клас. Адміністратори встановлюють імʼя та інші параметри класу під час першого створення обʼєктів StorageClass.

Як адміністратор, ви можете вказати типовий StorageClass, який застосовується до будь-яких PVC, які не вимагають конкретного класу. Докладніше див. концепцію PersistentVolumeClaim.

Тут наведено приклад StorageClass:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: low-latency
  annotations:
    storageclass.kubernetes.io/is-default-class: "false"
provisioner: csi-driver.example-vendor.example
reclaimPolicy: Retain # типове значення — Delete
allowVolumeExpansion: true
mountOptions:
  - discard # Це може увімкнути UNMAP / TRIM на рівні зберігання блоків
volumeBindingMode: WaitForFirstConsumer
parameters:
  guaranteedReadWriteLatency: "true" # залежить від постачальника

Типовий StorageClass

Ви можете визначити StorageClass як типовий для вашого кластера. Щоб дізнатися, як встановити типовий StorageClass, див. Зміна типового StorageClass.

Якщо PVC не вказує storageClassName, буде використовуватися типовий StorageClass.

Якщо ви встановите анотацію storageclass.kubernetes.io/is-default-class у значення true для більше ніж одного StorageClass у вашому кластері, і потім створите PersistentVolumeClaim без вказання storageClassName, Kubernetes використовуватиме найновіший типовий StorageClass.

Ви можете створити PersistentVolumeClaim, не вказуючи storageClassName для нового PVC, і ви можете це зробити навіть тоді, коли у вашому кластері немає типового StorageClass. У цьому випадку новий PVC створюється так, як ви його визначили, і storageClassName цього PVC залишається невизначеним до тих пір, поки не стане доступний типовий StorageClass.

Ви можете мати кластер без типового StorageClass. Якщо ви не встановлюєте жодного StorageClass як типового (і його не визначено, наприклад, постачальником хмари), то Kubernetes не може застосовувати ці типові класи до PersistentVolumeClaims, які йому потрібні.

Якщо або коли стає доступний типовий StorageClass, система керування визначає будь-які наявні PVC без storageClassName. Для PVC, які або мають порожнє значення для storageClassName, або не мають цього ключа, система керування потім оновлює ці PVC, щоб встановити storageClassName відповідно до нового типового StorageClass. Якщо у вас є наявний PVC з storageClassName "", і ви налаштовуєте типовий StorageClass, то цей PVC не буде оновлено.

Щоб продовжити привʼязку до PV із storageClassName, встановленим як "" (при наявності типового StorageClass), вам потрібно встановити storageClassName асоційованого PVC як "".

Постачальник

У кожного StorageClass є постачальник, який визначає, який модуль обробника тому використовується для надання PV. Це поле повинно бути визначено.

Модуль обробника томуВнутрішній постачальникПриклад конфігурації
AzureFileAzure File
CephFS--
FC--
FlexVolume--
iSCSI--
Local-Local
NFS-NFS
PortworxVolumePortworx Volume
RBD-Ceph RBD
VsphereVolumevSphere

Ви не обмежені вказанням "внутрішніх" постачальників, вказаних тут (імена яких починаються з "kubernetes.io" і входять до складу Kubernetes). Ви також можете запускати і вказувати зовнішні постачальники, які є незалежними програмами і слідують специфікації, визначеній Kubernetes. Автори зовнішніх постачальників мають на власний розсуд поводитись щодо того, де розташований їх код, як постачальник надається, як його слід запускати, який модуль обробника тому він використовує (включаючи Flex) тощо. У репозиторії kubernetes-sigs/sig-storage-lib-external-provisioner знаходиться бібліотека для написання зовнішніх постачальників, яка реалізує більшість специфікації. Деякі зовнішні постачальники перелічені у репозиторії kubernetes-sigs/sig-storage-lib-external-provisioner.

Наприклад, NFS не надає внутрішнього постачальника, але можна використовувати зовнішній. Існують також випадки, коли сторонні виробники систем зберігання надають свій власний зовнішній постачальник.

Політика повторного використання

PersistentVolumes, які динамічно створюються за допомогою StorageClass, матимуть політику повторного використання вказану в полі reclaimPolicy класу, яке може бути або Delete, або Retain. Якщо поле reclaimPolicy не вказано при створенні обʼєкта StorageClass, то типово воно буде Delete.

PersistentVolumes, які створені вручну та управляються за допомогою StorageClass, матимуть таку політику повторного використання, яку їм було призначено при створенні.

Розширення тому

PersistentVolumes можуть бути налаштовані на розширення. Це дозволяє змінювати розмір тому, редагуючи відповідний обʼєкт PVC і запитуючи новий, більший том зберігання.

Наступні типи томів підтримують розширення тому, коли базовий StorageClass має поле allowVolumeExpansion, встановлене в значення true.

Таблиця типів томів та версії Kubernetes, які вони вимагають для розширення тому
Тип томуПотрібна версія Kubernetes для розширення тому
Azure File1.11
CSI1.24
FlexVolume1.13
Portworx1.11
rbd1.11

Опції монтування

PersistentVolumes, які динамічно створюються за допомогою StorageClass, матимуть опції монтування, вказані в полі mountOptions класу.

Якщо обʼєкт тому не підтримує опції монтування, але вони вказані, створення тому завершиться невдачею. Опції монтування не перевіряються ні на рівні класу, ні на рівні PV. Якщо опція монтування є недійсною, монтування PV не вдасться.

Режим привʼязки тому

Поле volumeBindingMode керує тим, коли привʼязка тому та динамічне створення повинно відбуватися. Коли воно не встановлене, типово використовується режим Immediate.

Режим Immediate вказує, що привʼязка тому та динамічне створення відбувається після створення PersistentVolumeClaim. Для сховищ, які обмежені топологією і не доступні з усіх вузлів в кластері, PersistentVolumes буде привʼязаний або створений без знання про планування Podʼа. Це може призвести до неможливості планування Podʼів.

Адміністратор кластера може розвʼязати цю проблему, вказавши режим WaitForFirstConsumer, який затримає привʼязку та створення PersistentVolume до створення Podʼа з PersistentVolumeClaim. PersistentVolumes будуть обрані або створені відповідно до топології, яку визначають обмеження планування Podʼа. Сюди входять, але не обмежуються вимоги до ресурсів, селектори вузлів, affinity та anti-affinity Podʼа, і taint та toleration.

Наступні втулки підтримують WaitForFirstConsumer разом із динамічним створенням:

  • CSI-томи, за умови, що конкретний драйвер CSI підтримує це

Наступні втулки підтримують WaitForFirstConsumer разом із попередньо створеною привʼязкою PersistentVolume:

  • CSI-томи, за умови, що конкретний драйвер CSI підтримує це
  • local
apiVersion: v1
kind: Pod
metadata:
  name: task-pv-pod
spec:
  nodeSelector:
    kubernetes.io/hostname: kube-01
  volumes:
    - name: task-pv-storage
      persistentVolumeClaim:
        claimName: task-pv-claim
  containers:
    - name: task-pv-container
      image: nginx
      ports:
        - containerPort: 80
          name: "http-server"
      volumeMounts:
        - mountPath: "/usr/share/nginx/html"
          name: task-pv-storage

Дозволені топології

Коли оператор кластера вказує режим привʼязки тому WaitForFirstConsumer, в більшості випадків не потрібно обмежувати забезпечення конкретних топологій. Однак, якщо це все ще необхідно, можна вказати allowedTopologies.

У цьому прикладі показано, як обмежити топологію запроваджених томів конкретними зонами та використовувати як заміну параметрам zone та zones для підтримуваних втулків.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: standard
provisioner: kubernetes.io/example
parameters:
  type: pd-standard
volumeBindingMode: WaitForFirstConsumer
allowedTopologies:
- matchLabelExpressions:
  - key: topology.kubernetes.io/zone
    values:
    - us-central-1a
    - us-central-1b

Параметри

У StorageClasses є параметри, які описують томи, які належать класу сховища. Різні параметри можуть прийматися залежно від provisioner. Коли параметр відсутній, використовується який-небудь типове значення.

Може бути визначено не більше 512 параметрів для StorageClass. Загальна довжина обʼєкта параметрів разом із ключами та значеннями не може перевищувати 256 КіБ.

AWS EBS

У Kubernetes 1.31 не включено тип тому awsElasticBlockStore.

Драйвер зберігання AWSElasticBlockStore у вузлі був відзначений як застарілий у релізі Kubernetes v1.19 і повністю видалений у релізі v1.27.

Проєкт Kubernetes рекомендує використовувати AWS EBS замість вбудованого драйвера зберігання.

Нижче подано приклад StorageClass для драйвера CSI AWS EBS:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ebs-sc
provisioner: ebs.csi.aws.com
volumeBindingMode: WaitForFirstConsumer
parameters:
  csi.storage.k8s.io/fstype: xfs
  type: io1
  iopsPerGB: "50"
  encrypted: "true"
allowedTopologies:
- matchLabelExpressions:
  - key: topology.ebs.csi.aws.com/zone
    values:
    - us-east-2c

AWS EFS

Щоб налаштувати сховище AWS EFS, можна використовувати сторонній драйвер AWS_EFS_CSI_DRIVER.

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: efs-sc
provisioner: efs.csi.aws.com
parameters:
  provisioningMode: efs-ap
  fileSystemId: fs-92107410
  directoryPerms: "700"
  • provisioningMode: Тип тому, що створюється за допомогою Amazon EFS. Наразі підтримується лише створення на основі точки доступу (efs-ap).
  • fileSystemId: Файлова система, під якою створюється точка доступу.
  • directoryPerms: Дозволи на теки для кореневої теки, створеної точкою доступу.

Для отримання додаткової інформації зверніться до документації AWS_EFS_CSI_Driver Dynamic Provisioning.

NFS

Для налаштування NFS-сховища можна використовувати вбудований драйвер або драйвер CSI для NFS в Kubernetes (рекомендовано).

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: example-nfs
provisioner: example.com/external-nfs
parameters:
  server: nfs-server.example.com
  path: /share
  readOnly: "false"
  • server: Server — це імʼя хосту або IP-адреса сервера NFS.
  • path: Шлях, який експортується сервером NFS.
  • readOnly: Прапорець, який вказує, чи буде сховище змонтовано тільки для читання (типово – false).

Kubernetes не включає внутрішній NFS-провайдер. Вам потрібно використовувати зовнішній провайдер для створення StorageClass для NFS. Ось деякі приклади:

vSphere

Існують два типи провайдерів для класів сховища vSphere:

Вбудовані провайдери застарілі. Для отримання додаткової інформації про провайдера CSI, див. Kubernetes vSphere CSI Driver та міграцію vSphereVolume CSI.

CSI провайдер

Постачальник сховища StorageClass для vSphere CSI працює з кластерами Tanzu Kubernetes. Для прикладу див. репозитарій vSphere CSI.

vCP провайдер

У наступних прикладах використовується постачальник сховища VMware Cloud Provider (vCP).

  1. Створіть StorageClass із зазначенням формату диска користувачем.

    apiVersion: storage.k8s.io/v1
    kind: StorageClass
    metadata:
      name: fast
    provisioner: kubernetes.io/vsphere-volume
    parameters:
      diskformat: zeroedthick
    

    diskformat: thin, zeroedthick та eagerzeroedthick. Стандартно: "thin".

  2. Створіть StorageClass із форматуванням диска на зазначеному користувачем сховищі.

    apiVersion: storage.k8s.io/v1
    kind: StorageClass
    metadata:
      name: fast
    provisioner: kubernetes.io/vsphere-volume
    parameters:
      diskformat: zeroedthick
      datastore: VSANDatastore
    

    datastore: Користувач також може вказати сховище в StorageClass. Том буде створено на сховищі, вказаному в StorageClass, у цьому випадку — VSANDatastore. Це поле є необовʼязковим. Якщо сховище не вказано, том буде створено у сховищі, вказаному в конфігураційному файлі vSphere, який використовується для ініціалізації хмарного провайдера vSphere.

  3. Керування політикою сховища в Kubernetes

    • Використання наявної політики SPBM vCenter

      Однією з найважливіших функцій vSphere для керування сховищем є керування на основі політики сховища (SPBM). Система управління сховищем на основі політики (SPBM) — це каркас політики сховища, який надає єдину уніфіковану панель управління для широкого спектра служб обробки даних та рішень зберігання. SPBM дозволяє адміністраторам vSphere подолати виклики щодо передбачуваного виділення сховища, такі як планування потужності, різні рівні обслуговування та управління потужністю.

      Політики SPBM можна вказати в StorageClass за допомогою параметра storagePolicyName.

    • Підтримка політики Virtual SAN всередині Kubernetes

      Адміністратори Vsphere Infrastructure (VI) будуть мати можливість вказувати власні віртуальні можливості сховища SAN під час динамічного виділення томів. Тепер ви можете визначити вимоги до сховища, такі як продуктивність та доступність, у вигляді можливостей сховища під час динамічного виділення томів. Вимоги до можливостей сховища перетворюються в політику Virtual SAN, яка потім передається на рівень віртуального SAN при створенні постійного тому (віртуального диска). Віртуальний диск розподіляється по сховищу віртуального SAN для відповідності вимогам.

      Детальнішу інформацію щодо використання політик сховища для управління постійними томами можна переглянути в Керуванні політикою на основі зберігання для динамічного виділення томів.

Є кілька прикладів для vSphere, які можна спробувати для керування постійним томом в Kubernetes для vSphere.

Ceph RBD (застарілий)

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast
provisioner: kubernetes.io/rbd
parameters:
  monitors: 10.16.153.105:6789
  adminId: kube
  adminSecretName: ceph-secret
  adminSecretNamespace: kube-system
  pool: kube
  userId: kube
  userSecretName: ceph-secret-user
  userSecretNamespace: default
  fsType: ext4
  imageFormat: "2"
  imageFeatures: "layering"
  • monitors: Монітори Ceph, розділені комою. Цей параметр є обовʼязковим.

  • adminId: Ідентифікатор клієнта Ceph, який може створювати образи в пулі. Типово — "admin".

  • adminSecretName: Імʼя секрету для adminId. Цей параметр є обовʼязковим. Наданий секрет повинен мати тип "kubernetes.io/rbd".

  • adminSecretNamespace: Простір імен для adminSecretName. Типово — "default".

  • pool: Ceph RBD pool. Типово — "rbd".

  • userId: Ідентифікатор клієнта Ceph, який використовується для зіставлення образу RBD. Типово — такий самий, як і adminId.

  • userSecretName: Імʼя Ceph Secret для userId для зіставлення образу RBD. Він повинен існувати в тому ж просторі імен, що і PVC. Цей параметр є обовʼязковим. Наданий секрет повинен мати тип "kubernetes.io/rbd", наприклад, створений таким чином:

    kubectl create secret generic ceph-secret --type="kubernetes.io/rbd" \
      --from-literal=key='QVFEQ1pMdFhPUnQrSmhBQUFYaERWNHJsZ3BsMmNjcDR6RFZST0E9PQ==' \
      --namespace=kube-system
    
  • userSecretNamespace: Простір імен для userSecretName.

  • fsType: fsType, який підтримується Kubernetes. Типово: "ext4".

  • imageFormat: Формат образу Ceph RBD, "1" або "2". Типово — "2".

  • imageFeatures: Цей параметр є необовʼязковим і слід використовувати тільки в разі якщо ви встановили imageFormat на "2". Зараз підтримуються тільки функції layering. Типово — "", і жодна функція не включена.

Azure Disk

У Kubernetes 1.31 не включено типу тому azureDisk.

Внутрішній драйвер зберігання azureDisk був застарілий у випуску Kubernetes v1.19 і потім був повністю вилучений у випуску v1.27.

Проєкт Kubernetes рекомендує використовувати замість цього сторонній драйвер зберігання Azure Disk.

Azure File (застаріло)

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: azurefile
provisioner: kubernetes.io/azure-file
parameters:
  skuName: Standard_LRS
  location: eastus
  storageAccount: azure_storage_account_name
  • skuName: Рівень SKU облікового запису Azure Storage. Типово відсутній.
  • location: Місце розташування облікового запису Azure Storage. Типово відсутнє.
  • storageAccount: Назва облікового запису Azure Storage. Типово відсутня. Якщо обліковий запис зберігання не наданий, весь обліковий запис, повʼязаний із групою ресурсів, перевіряється на наявність збігу skuName та location. Якщо обліковий запис зберігання надано, він повинен перебувати в тій самій групі ресурсів, що й кластер, і значення skuName та location ігноруються.
  • secretNamespace: простір імен секрету, що містить імʼя та ключ облікового запису Azure Storage. Типово такий самий, як у Pod.
  • secretName: імʼя секрету, що містить імʼя та ключ облікового запису Azure Storage. Типово azure-storage-account-<accountName>-secret.
  • readOnly: прапорець, що вказує, чи буде ресурс зберігання монтуватися лише для читання. Типово false, що означає монтування для читання/запису. Це значення впливає також на налаштування ReadOnly в VolumeMounts.

Під час надання ресурсів зберігання, для монтованих облікових даних створюється секрет з імʼям secretName. Якщо кластер активував як RBAC, так і Ролі контролера, додайте дозвіл create ресурсу secret для clusterrole контролера system:controller:persistent-volume-binder.

У контексті multi-tenancy настійно рекомендується явно встановлювати значення для secretNamespace, інакше дані облікового запису для зберігання можуть бути прочитані іншими користувачами.

Portworx volume (застаріло)

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: portworx-io-priority-high
provisioner: kubernetes.io/portworx-volume
parameters:
  repl: "1"
  snap_interval: "70"
  priority_io: "high"
  • fs: файлова система для створення: none/xfs/ext4 (типово: ext4).
  • block_size: розмір блоку у кілобайтах (типово: 32).
  • repl: кількість синхронних реплік у формі коефіцієнта реплікації 1..3 (типово: 1). Тут потрібен рядок, наприклад "1", а не 1.
  • priority_io: визначає, чи буде том створений з використанням зберігання високої чи низької пріоритетності high/medium/low (типово: low).
  • snap_interval: інтервал годинника/часу у хвилинах для того, щоб запускати моментальні знімки. Моментальні знімки є інкрементальними на основі різниці з попереднім знімком, 0 вимикає знімки (типово: 0). Тут потрібен рядок, наприклад "70", а не 70.
  • aggregation_level: вказує кількість частин, на які розподілений том, 0 вказує на нерозподілений том (типово: 0). Тут потрібен рядок, наприклад "0", а не 0.
  • ephemeral: вказує, чи слід очищати том після відмонтовування, чи він повинен бути постійним. Використання випадку emptyDir може встановлювати для цього значення true, а випадок використання постійних томів, таких як для баз даних, наприклад Cassandra, повинен встановлювати false, true/false (типово false). Тут потрібен рядок, наприклад "true", а не true.

Локальне сховище

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: local-storage
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: WaitForFirstConsumer

Локальні томи не підтримують динамічне впровадження в Kubernetes 1.31; однак все одно слід створити StorageClass, щоб відкласти звʼязування тому до моменту фактичного планування Podʼа на відповідний вузол. Це вказано параметром звʼязування тому WaitForFirstConsumer.

Відкладення звʼязування тому дозволяє планувальнику враховувати всі обмеження планування Podʼа при виборі відповідного PersistenVolume для PersistenVolumeClaim.

3.6.6 - Класи атрибутів тома

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.31 [beta]

Ця сторінка передбачає, що ви знайомі з StorageClasses, томами та постійними томами в Kubernetes.

Клас VolumeAttributesClass надає адміністраторам можливість описати змінні "класи" сховищ, які вони пропонують. Різні класи можуть відповідати різним рівням якості обслуговування. Kubernetes сам по собі не виражає думки про те, що представляють ці класи.

Це бета-функція, її типово вимкнено.

Якщо ви хочете протестувати функцію, поки вона бета, вам потрібно ввімкнути функціональну можливість VolumeAttributesClass для kube-controller-manager, kube-scheduler та kube-apiserver. Використовуйте аргумент командного рядка --feature-gates:

--feature-gates="...,VolumeAttributesClass=true"

Вам також потрібно буде увімкнути API групу storage.k8s.io/v1beta1 через kube-apiserver runtime-config. Для цього використовуйте наступний аргумент командного рядка:

--runtime-config=storage.k8s.io/v1beta1=true

Ви також можете використовувати VolumeAttributesClass лише зі сховищем, підтримуваним Container Storage Interface, і лише там, де відповідний драйвер CSI реалізує API ModifyVolume.

API VolumeAttributesClass

Кожен клас VolumeAttributesClass містить driverName та parameters, які використовуються, коли потрібно динамічно створити або змінити PersistentVolume (PV), що належить до цього класу.

Назва обʼєкта VolumeAttributesClass має значення, і вона використовується користувачами для запиту конкретного класу. Адміністратори встановлюють імʼя та інші параметри класу при створенні обʼєктів VolumeAttributesClass. Хоча імʼя обʼєкта VolumeAttributesClass в PersistentVolumeClaim може змінюватися, параметри в наявному класі є незмінними.

apiVersion: storage.k8s.io/v1beta1
kind: VolumeAttributesClass
metadata:
  name: silver
driverName: pd.csi.storage.gke.io
parameters:
  provisioned-iops: "3000"
  provisioned-throughput: "50" 

Постачальник

Кожен клас VolumeAttributesClass має постачальника, який визначає, який втулок тому використовується для надання PV. Поле driverName повинно бути вказане.

Підтримка функції для VolumeAttributesClass реалізована у kubernetes-csi/external-provisioner.

Ви не обмежені вказанням kubernetes-csi/external-provisioner. Ви також можете використовувати та вказувати зовнішні постачальники, які є незалежними програмами та відповідають специфікації, визначеною Kubernetes. Автори зовнішніх постачальників мають повну свободу в тому, де знаходиться їх код, як постачальник надається, як його потрібно запускати, який втулок тому він використовує та інше.

Модифікатор розміру

Кожен клас VolumeAttributesClass має модифікатор розміру, який визначає, який втулок тому використовується для модифікації PV. Поле driverName повинно бути вказане.

Підтримка функції модифікації розміру тому для VolumeAttributesClass реалізована у kubernetes-csi/external-resizer.

Наприклад, наявний запит PersistentVolumeClaim використовує клас VolumeAttributesClass з іменем silver:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: test-pv-claim
spec:
  
  volumeAttributesClassName: silver
  

В кластері доступний новий клас VolumeAttributesClass з імʼям gold:

apiVersion: storage.k8s.io/v1beta1
kind: VolumeAttributesClass
metadata:
  name: gold
driverName: pd.csi.storage.gke.io
parameters:
  iops: "4000"
  throughput: "60"

Користувач може оновити PVC за допомогою нового класу VolumeAttributesClass gold та застосувати зміни:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: test-pv-claim
spec:
  
  volumeAttributesClassName: gold
  

Параметри

Класи VolumeAttributesClass мають параметри, які описують томи, які до них належать. Різні параметри можуть бути прийняті залежно від обраного провайдера або модифікатора розміру. Наприклад, значення 4000 для параметра iops, та параметр throughput є специфічними для GCE PD. Якщо параметр опущено, використовуються стандартні значення під час створення тому. Якщо користувач застосовує PVC із використанням іншого VolumeAttributesClass з пропущеними параметрами, стандартні значення може використовуватися залежно від реалізації драйвера CSI. Будь ласка, звертайтесь до відповідної документації драйвера CSI для отримання деталей.

Може бути визначено не більше 512 параметрів для класу VolumeAttributesClass. Загальна довжина обʼєкта параметрів, включаючи ключі та значення, не може перевищувати 256 КіБ.

3.6.7 - Динамічне впровадження томів

Динамічне впровадження томів дозволяє створювати томи сховища при потребі. Без динамічного впровадження адміністратори кластера повинні вручну звертатися до свого хмарного або постачальника сховища, щоб створити нові томи сховища, а потім створювати обʼєкти PersistentVolume, щоб мати їх в Kubernetes. Функція динамічного впровадження томів усуває необхідність для адміністраторів кластера попередньо впровадження сховища. Замість цього воно автоматично впроваджує сховище, коли користувачі створюють обʼєкти PersistentVolumeClaim.

Причини

Реалізація динамічного впровадження томів базується на API-обʼєкті StorageClass з групи API storage.k8s.io. Адміністратор кластера може визначити стільки обʼєктів StorageClass, скільки потрібно, кожен з них вказуючи провайдера тому (також відомий як provisioner) для впровадження тому та набір параметрів, які слід передати цьому провайдеру. Адміністратор кластера може визначити та надавати кілька варіантів сховища (з того ж або різних систем сховищ) в межах кластера, кожен зі своїм набором параметрів. Цей дизайн також забезпечує те, що кінцеві користувачі не повинні турбуватися про складнощі та нюанси впровадження сховища, але все ще мають можливість вибрати з різних варіантів сховища.

Додаткову інформацію про класи сховища можна знайти тут.

Увімкнення динамічного впровадження

Для увімкнення динамічного впровадження адміністратор кластера повинен передбачити один або декілька обʼєктів StorageClass для користувачів. Обʼєкти StorageClass визначають, який провайдер повинен використовуватися та які параметри повинні йому передаватися під час виклику динамічного впровадження. Імʼя обʼєкта StorageClass повинно бути дійсним імʼям DNS-піддомену.

Наступний маніфест створює клас сховища "slow", який надає стандартні диски, схожі на постійні диски.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: slow


provisioner: kubernetes.io/gce-pd
parameters:
  type: pd-standard

Наступний маніфест створює клас сховища "fast", який надає диски, схожі на SSD.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast
provisioner: kubernetes.io/gce-pd
parameters:
  type: pd-ssd

Використання динамічного впровадження

Користувачі можуть запитувати динамічно впроваджене сховище, включаючи клас сховища у свій PersistentVolumeClaim. До версії Kubernetes v1.6 це робилося за допомогою анотації volume.beta.kubernetes.io/storage-class. Однак ця анотація застаріла з версії v1.9. Тепер користувачі можуть і повинні використовувати поле storageClassName обʼєкта PersistentVolumeClaim. Значення цього поля повинно відповідати імені StorageClass, налаштованому адміністратором (див. нижче).

Наприклад, щоб вибрати клас сховища "fast", користувач створює наступний PersistentVolumeClaim:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: claim1
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: fast
  resources:
    requests:
      storage: 30Gi

Цей запит призводить до автоматичного впровадження тому, схожого на SSD. Після видалення заявки том знищується.

Стандартна поведінка

Динамічне впровадження може бути увімкнено в кластері так, що всі заявки будуть динамічно надані, якщо не вказано жоден клас сховища. Адміністратор кластера може увімкнути цю поведінку шляхом:

Адміністратор може визначити певний StorageClass як типовий, додавши анотацію storageclass.kubernetes.io/is-default-class до нього. Коли в кластері існує типовий StorageClass, і користувач створює PersistentVolumeClaim із невказаним storageClassName, контролер DefaultStorageClass автоматично додає поле storageClassName, що вказує на типовий клас сховища.

Зверніть увагу, що якщо ви встановите анотацію storageclass.kubernetes.io/is-default-class в true для більше одного StorageClass у вашому кластері, а потім створите PersistentVolumeClaim із не встановленим storageClassName, Kubernetes використовує найновіший створений типовий StorageClass.

Врахування топології

У кластерах з кількома зонами можуть розташовуватися Podʼи в різних зонах одного регіону. Томи сховища в одній зоні повинні надаватися в ті зони, де заплановані Podʼи. Це можна здійснити, встановивши режим звʼязування тому.

3.6.8 - Знімки томів

У Kubernetes VolumeSnapshot представляє знімок тому в системі зберігання. Цей документ передбачає, що ви вже знайомі з постійними томами Kubernetes — persistent volumes.

Вступ

Так само як ресурси API PersistentVolume та PersistentVolumeClaim використовуються для створення томів для користувачів та адміністраторів, API-ресурси VolumeSnapshotContent та VolumeSnapshot надаються для створення знімків томів для користувачів та адміністраторів.

VolumeSnapshotContent — це знімок, зроблений з тому в кластері, який був створений адміністратором. Це ресурс в кластері, так само як PersistentVolume — це ресурс кластера.

VolumeSnapshot — це запит на знімок тому від користувача. Він схожий на PersistentVolumeClaim.

VolumeSnapshotClass дозволяє вам вказати різні атрибути, що належать до VolumeSnapshot. Ці атрибути можуть відрізнятися серед знімків, зроблених з того ж тому в системі зберігання, і тому не можуть бути виражені, використовуючи той самий StorageClass PersistentVolumeClaim.

Знімки томів надають користувачам Kubernetes стандартизований спосіб копіювання вмісту тому в певний момент часу без створення цілком нового тому. Ця функціональність, наприклад, дозволяє адміністраторам баз даних робити резервні копії баз даних перед внесенням змін або видаленням.

Користувачі повинні знати про наступне при використанні цієї функції:

  • API-обʼєкти VolumeSnapshot, VolumeSnapshotContent та VolumeSnapshotClass є CRDs, а не частиною основного API.
  • Підтримка VolumeSnapshot доступна лише для драйверів CSI.
  • В рамках процесу розгортання VolumeSnapshot команда Kubernetes надає контролер знімків для розгортання в панелі управління та допоміжний контейнер csi-snapshotter, який розгортається разом із драйвером CSI. Контролер знімків відстежує обʼєкти VolumeSnapshot та VolumeSnapshotContent та відповідає за створення та видалення обʼєкта VolumeSnapshotContent. Допоміжний контейнер (sidecar) csi-snapshotter відстежує обʼєкти VolumeSnapshotContent та виконує операції CreateSnapshot та DeleteSnapshot для точки доступу CSI.
  • Також існує сервер перевірки вебзапитів, який надає затвердження обʼєктів знімків. Його слід встановити дистрибутивами Kubernetes разом із контролером знімків та CRDs, а не драйверами CSI. Він повинен бути встановлений в усіх кластерах Kubernetes, в яких увімкнено функцію створення знімків.
  • Драйвери CSI можуть або не втілювати функціональність знімка тому. Драйвери CSI, які надали підтримку знімків тому, скоріш за все, використовуватимуть csi-snapshotter. Див. Документацію драйвера CSI для отримання деталей.
  • Встановлення CRDs та контролера знімків є обовʼязком дистрибутиву Kubernetes.

Життєвий цикл знімка тому та змісту знімка тому

VolumeSnapshotContents — це ресурси в кластері. VolumeSnapshots – це запити на отримання цих ресурсів. Взаємодія між VolumeSnapshotContents та VolumeSnapshots відповідає життєвому циклу:

Впровадження знімків томів

Існує два способи впровадження знімків: статичне попереднє впровадження або динамічне попереднє впровадження.

Статичне

Адміністратор кластера створює кілька VolumeSnapshotContents. Вони містять деталі реального знімка тому на системі зберігання, який доступний для використання користувачами кластера. Вони існують в API Kubernetes і доступні для використання.

Динамічне

Замість використання попередньо наявного знімку, можна запросити динамічне створення знімка з PersistentVolumeClaim. VolumeSnapshotClass вказує параметри, специфічні для постачальника зберігання, які слід використовувати при створенні знімка.

Звʼязування

Контролер знімків відповідає за звʼязування обʼєкта VolumeSnapshot з відповідним обʼєктом VolumeSnapshotContent, як у випадку попереднього впровадження, так і у випадку динамічного провадження. Звʼязування є зіставлення один до одного.

У випадку попереднього впровадження, обʼєкт VolumeSnapshot залишається незвʼязаним до тих пір, доки не буде створено запитаний обʼєкт VolumeSnapshotContent.

Persistent Volume Claim як захист джерела знімка

Метою цього захисту є забезпечення того, що обʼєкти API PersistentVolumeClaim використовуються і не видаляються з системи, поки відбувається створення знімка з нього (оскільки це може призвести до втрати даних).

Під час створення знімка з PersistentVolumeClaim, цей PersistentVolumeClaim знаходиться в стані використання. Якщо видалити обʼєкт API PersistentVolumeClaim, який активно використовується як джерело знімка, то обʼєкт PersistentVolumeClaim не видаляється негайно. Замість цього видалення обʼєкта PersistentVolumeClaim відкладається до готовності або анулювання знімка.

Видалення

Видалення спровоковане видаленням обʼєкта VolumeSnapshot, і буде дотримано DeletionPolicy. Якщо DeletionPolicy — це Delete, тоді підлеглий знімок сховища буде видалено разом з обʼєктом VolumeSnapshotContent. Якщо DeletionPolicy — це Retain, то як сховища, так і VolumeSnapshotContent залишаться.

VolumeSnapshots

Кожен том VolumeSnapshot містить специфікацію та стан.

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: new-snapshot-test
spec:
  volumeSnapshotClassName: csi-hostpath-snapclass
  source:
    persistentVolumeClaimName: pvc-test

persistentVolumeClaimName — це назва обʼєкта PersistentVolumeClaim, який є джерелом даних для знімка. Це поле є обовʼязковим для динамічного створення знімка.

Обʼєкт знімка тому може запитати певний клас, вказавши назву VolumeSnapshotClass за допомогою атрибута volumeSnapshotClassName. Якщо нічого не встановлено, то використовується типовий клас, якщо він доступний.

Для знімків, що були створені наперед, вам потрібно вказати volumeSnapshotContentName як джерело для знімка, як показано в наступному прикладі. Поле volumeSnapshotContentName як джерело є обовʼязковим для наперед створених знімків.

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: test-snapshot
spec:
  source:
    volumeSnapshotContentName: test-content

Вміст знімків томів

Кожен обʼєкт VolumeSnapshotContent містить специфікацію та стан. При динамічному створенні знімків загальний контролер створює обʼєкти VolumeSnapshotContent. Ось приклад:

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotContent
metadata:
  name: snapcontent-72d9a349-aacd-42d2-a240-d775650d2455
spec:
  deletionPolicy: Delete
  driver: hostpath.csi.k8s.io
  source:
    volumeHandle: ee0cfb94-f8d4-11e9-b2d8-0242ac110002
  sourceVolumeMode: Filesystem
  volumeSnapshotClassName: csi-hostpath-snapclass
  volumeSnapshotRef:
    name: new-snapshot-test
    namespace: default
    uid: 72d9a349-aacd-42d2-a240-d775650d2455

volumeHandle – це унікальний ідентифікатор тому, створеного на сховищі та поверненого драйвером CSI під час створення тому. Це поле обовʼязкове для динамічного створення знімка. Воно вказує джерело тому для знімка.

Для наперед створених знімків ви (як адміністратор кластера) відповідаєте за створення обʼєкта VolumeSnapshotContent наступним чином.

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotContent
metadata:
  name: new-snapshot-content-test
spec:
  deletionPolicy: Delete
  driver: hostpath.csi.k8s.io
  source:
    snapshotHandle: 7bdd0de3-aaeb-11e8-9aae-0242ac110002
  sourceVolumeMode: Filesystem
  volumeSnapshotRef:
    name: new-snapshot-test
    namespace: default

snapshotHandle — це унікальний ідентифікатор знімка тому, створеного в сховищі. Це поле є обовʼязковим для наперед створених знімків. Воно вказує ідентифікатор CSI знімка у сховищі, який представляє цей VolumeSnapshotContent.

sourceVolumeMode — це режим тому, з якого був зроблений знімок. Значення поля sourceVolumeMode може бути або Filesystem, або Block. Якщо режим джерела тому не вказано, Kubernetes розглядає знімок так, ніби режим джерела тому невідомий.

volumeSnapshotRef — це посилання на відповідний VolumeSnapshot. Зверніть увагу, що коли VolumeSnapshotContent створюється як наперед створений знімок, то VolumeSnapshot, на який посилається volumeSnapshotRef, може ще не існувати.

Зміна режиму тому знімка

Якщо API VolumeSnapshots, встановлене на вашому кластері, підтримує поле sourceVolumeMode, то API має можливість запобігати несанкціонованим користувачам зміни режиму тому.

Щоб перевірити, чи має ваш кластер цю функціональність, виконайте наступну команду:

kubectl get crd volumesnapshotcontent -o yaml

Якщо ви хочете дозволити користувачам створювати PersistentVolumeClaim з наявного VolumeSnapshot, але з іншим режимом тому, ніж у джерела, слід додати анотацію snapshot.storage.kubernetes.io/allow-volume-mode-change: "true" до VolumeSnapshotContent, який відповідає VolumeSnapshot.

Для наперед створених знімків spec.sourceVolumeMode повинно бути заповнено адміністратором кластера.

Приклад ресурсу VolumeSnapshotContent із включеною цією функцією виглядатиме так:

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotContent
metadata:
  name: new-snapshot-content-test
  annotations:
    - snapshot.storage.kubernetes.io/allow-volume-mode-change: "true"
spec:
  deletionPolicy: Delete
  driver: hostpath.csi.k8s.io
  source:
    snapshotHandle: 7bdd0de3-aaeb-11e8-9aae-0242ac110002
  sourceVolumeMode: Filesystem
  volumeSnapshotRef:
    name: new-snapshot-test
    namespace: default

Створення томів зі знімків

Ви можете створити новий том, наперед заповнений даними зі знімка, використовуючи поле dataSource в обʼєкті PersistentVolumeClaim.

Докладніше дивіться в Знімок тому та відновлення тому зі знімка.

3.6.9 - Класи знімків томів

У цьому документі описано концепцію VolumeSnapshotClass в Kubernetes. Рекомендується мати відомості про знімки томів та класи сховищ.

Вступ

Так само як StorageClass надає можливість адміністраторам описувати "класи" сховищ, які вони пропонують при виділенні тому, VolumeSnapshotClass надає можливість описувати "класи" сховищ при виділенні знімка тому.

Ресурс VolumeSnapshotClass

Кожен VolumeSnapshotClass містить поля driver, deletionPolicy та parameters, які використовуються, коли потрібно динамічно виділити том для VolumeSnapshot, який належить до цього класу.

Назва обʼєкта VolumeSnapshotClass має значення і вказує, як користувачі можуть запитувати певний клас. Адміністратори встановлюють назву та інші параметри класу при створенні обʼєктів VolumeSnapshotClass, і їх не можна оновлювати після створення.

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: csi-hostpath-snapclass
driver: hostpath.csi.k8s.io
deletionPolicy: Delete
parameters:

Адміністратори можуть вказати типовий VolumeSnapshotClass для тих VolumeSnapshots, які не вимагають конкретний клас для привʼязки, додавши анотацію snapshot.storage.kubernetes.io/is-default-class: "true":

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: csi-hostpath-snapclass
  annotations:
    snapshot.storage.kubernetes.io/is-default-class: "true"
driver: hostpath.csi.k8s.io
deletionPolicy: Delete
parameters:

Driver

Класи знімків томів мають власника, який визначає, який CSI втулок тому використовується для виділення VolumeSnapshots. Це поле обовʼязкове.

DeletionPolicy

Класи знімків томів мають DeletionPolicy. Вона дозволяє налаштувати, що відбудеться з VolumeSnapshotContent, коли буде видалено обʼєкт VolumeSnapshot, з яким він повʼязаний. DeletionPolicy класу знімків томів може бути або Retain, або Delete. Це поле обовʼязкове.

Якщо DeletionPolicy має значення Delete, тоді разом з обʼєктом VolumeSnapshotContent буде видалено знімок тому у сховищі. Якщо DeletionPolicy має значення Retain, то знімок тому та VolumeSnapshotContent залишаються.

Параметри

Класи знімків томів мають параметри, які описують знімки томів, що належать до класу знімків томів. Різні параметри можуть бути прийняті залежно від driver.

3.6.10 - Клонування CSI-томів

У цьому документі описано концепцію клонування наявних томів CSI в Kubernetes. Рекомендується мати уявлення про томи.

Вступ

Функція клонування томів CSI додає підтримку вказання наявних PVC у полі dataSource для позначення бажання користувача клонувати Том.

Клон визначається як дублікат наявного тому Kubernetes, який можна використовувати як будь-який стандартний том. Єдина відмінність полягає в тому, що після підготовки, а не створення "нового" порожнього тому, пристрій, що відповідає за підтримку томів, створює точний дублікат вказаного тому.

Реалізація клонування, з погляду API Kubernetes, додає можливість вказати наявний PVC як джерело даних під час створення нового PVC. Джерело PVC має бути повʼязане та доступне (не у використанні).

Користувачі повинні знати наступне при використанні цієї функції:

  • Підтримка клонування (VolumePVCDataSource) доступна лише для драйверів CSI.
  • Підтримка клонування доступна лише для динамічних постачальників.
  • Драйвери CSI можуть чи не можуть реалізувати функціонал клонування томів.
  • Ви можете клонувати тільки PVC, коли вони існують у тому ж просторі імен, що і PVC призначення (джерело та призначення повинні бути в одному просторі імен).
  • Клонування підтримується з різним Storage Class.
    • Призначений том може мати той самий або інший клас сховища, ніж джерело.
    • Можна використовувати типовий клас сховища, і вказування storageClassName можна пропустити в специфікації.
  • Клонування може бути виконане лише між двома томами, які використовують одне і те саме налаштування VolumeMode (якщо ви запитуєте том в блоковому режимі, то джерело ТАКОЖ повинно бути в блоковому режимі).

Впровадження

Клони забезпечуються так само як і інші PVC, за винятком додавання dataSource, яке посилається на поточний PVC у тому ж самому просторі імен.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
    name: clone-of-pvc-1
    namespace: myns
spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: cloning
  resources:
    requests:
      storage: 5Gi
  dataSource:
    kind: PersistentVolumeClaim
    name: pvc-1

Результатом є новий PVC з імʼям clone-of-pvc-1, який має точно такий самий зміст, як і вказане джерело pvc-1.

Використання

При доступності нового PVC клонований PVC використовується так само як і інші PVC. Також на цьому етапі очікується, що новий створений PVC є незалежним обʼєктом. Його можна використовувати, клонувати, створювати знімки чи видаляти незалежно та без врахування вихідного джерела PVC. Це також означає, що джерело ніяк не повʼязане з новим створеним клоном, його також можна модифікувати чи видалити, не впливаючи на новий клон.

3.6.11 - Обсяг сховища

Обсяг сховища обмежений і може відрізнятися залежно від вузла, на якому працює Pod: мережеве сховище, можливо, не буде доступним для всіх вузлів, або зберігання буде локальним для вузла з початку.

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.24 [stable]

Ця сторінка описує, як Kubernetes відстежує обсяг сховища та як планувальник використовує цю інформацію для планування Podʼів на вузлах, які мають доступ до достатнього обсягу сховища для томів, що залишились пропущеними. Без відстеження обсягу сховища планувальник може вибрати вузол, у якого немає достатнього обсягу для виділення тому, і буде потрібно кілька повторних спроб планування.

Перш ніж ви розпочнете

Kubernetes v1.31 включає підтримку API на рівні кластера для відстеження обсягу сховища. Для використання цього ви також повинні використовувати драйвер CSI, який підтримує відстеження обсягу. Консультуйтесь з документацією драйверів CSI, які ви використовуєте, щоб дізнатися, чи ця підтримка доступна, і як її використовувати. Якщо ви не використовуєте Kubernetes v1.31, перевірте документацію для цієї версії Kubernetes.

API

Існують дві API-розширення для цієї функції:

  • Обʼєкти CSIStorageCapacity: їх виробляє драйвер CSI в просторі імен, де встановлено драйвер. Кожен обʼєкт містить інформацію про обсяг для одного класу сховища і визначає, які вузли мають доступ до цього сховища.
  • Поле CSIDriverSpec.StorageCapacity: якщо встановлено значення true, планувальник Kubernetes буде враховувати обсяг сховища для томів, які використовують драйвер CSI.

Планування

Інформація про обсяг сховища використовується планувальником Kubernetes у випадку, якщо:

  • Pod використовує том, який ще не був створений,
  • цей том використовує StorageClass, який посилається на драйвер CSI та використовує режим привʼязки тому WaitForFirstConsumer, і
  • обʼєкт CSIDriver для драйвера має StorageCapacity зі значенням true.

У цьому випадку планувальник розглядає тільки вузли для Podʼів, які мають достатньо вільного обсягу сховища. Ця перевірка є дуже спрощеною і порівнює тільки розмір тому з обсягом, вказаним в обʼєктах CSIStorageCapacity з топологією, що включає вузол.

Для томів з режимом привʼязки Immediate драйвер сховища вирішує де створити том, незалежно від Podʼів, які використовуватимуть том. Планувальник потім планує Podʼи на вузли, де том доступний після створення.

Для ефемерних томів CSI планування завжди відбувається без врахування обсягу сховища. Це ґрунтується на припущенні, що цей тип тому використовується лише спеціальними драйверами CSI, які є локальними для вузла та не потребують значних ресурсів там.

Перепланування

Коли вузол був обраний для Pod з томами WaitForFirstConsumer, це рішення все ще є попереднім. Наступним кроком є те, що драйверу зберігання CSI буде запропоновано створити том з підказкою, що том повинен бути доступний на вибраному вузлі.

Оскільки Kubernetes може вибрати вузол на підставі застарілої інформації про обсяг, існує можливість, що том насправді не може бути створений. Вибір вузла скидається, і планувальник Kubernetes спробує знову знайти вузол для Podʼа.

Обмеження

Відстеження обсягу сховища збільшує ймовірність успішного планування з першої спроби, але не може гарантувати цього, оскільки планувальник повинен вирішувати на підставі можливо застарілої інформації. Зазвичай той самий механізм повторної спроби, що і для планування без будь-якої інформації про обсяг сховища, обробляє відмови в плануванні.

Одна ситуація, коли планування може назавжди зазнати відмови, це коли Pod використовує кілька томів: один том вже може бути створений в сегменті топології, в якому не залишилося достатньо обсягу для іншого тому. Потрібне ручне втручання для відновлення, наприклад, збільшення обсягу або видалення вже створеного тому.

Що далі

3.6.12 - Обмеження томів на вузлі

Ця сторінка описує максимальну кількість томів, які можна прикріпити до вузла для різних хмарних постачальників.

Хмарні постачальники, такі як Google, Amazon і Microsoft, зазвичай мають обмеження на те, скільки томів можна прикріпити до вузла. Важливо, щоб Kubernetes дотримувався цих обмежень. В іншому випадку Podʼи, заплановані на вузлі, можуть застрягти в очікуванні прикріплення томів.

Типові обмеження Kubernetes

У планувальнику Kubernetes є типові обмеження на кількість томів, які можна прикріпити до вузла:

Хмарний сервісМаксимальна кількість томів на вузол
Amazon Elastic Block Store (EBS)39
Google Persistent Disk16
Microsoft Azure Disk Storage16

Власні обмеження

Ви можете змінити ці обмеження, встановивши значення змінної середовища KUBE_MAX_PD_VOLS, а потім запустивши планувальник. Драйвери CSI можуть мати іншу процедуру, дивіться їх документацію щодо налаштування обмежень.

Будьте обережні, якщо ви встановлюєте ліміт, який перевищує стандартний ліміт. Зверніться до документації хмарного постачальника, щоб переконатися, що Nodes дійсно може підтримувати встановлений вами ліміт.

Обмеження застосовується до всього кластера, тому воно впливає на всі вузли.

Обмеження динамічних томів

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.17 [stable]

Обмеження динамічних томів підтримуються для наступних типів.

  • Amazon EBS
  • Google Persistent Disk
  • Azure Disk
  • CSI

Для томів, керованих вбудованими втулками томів, Kubernetes автоматично визначає тип вузла і накладає відповідне максимальне обмеження кількості томів для вузла. Наприклад:

  • У Google Compute Engine, до вузла може бути приєднано до 127 томів, залежно від типу вузла.

  • Для дисків Amazon EBS на типах екземплярів M5,C5,R5,T3 та Z1D Kubernetes дозволяє приєднувати тільки 25 томів до вузла. Для інших типів інстансів на Amazon Elastic Compute Cloud (EC2), Kubernetes дозволяє приєднувати 39 томів до вузла.

  • На Azure до вузла може бути приєднано до 64 дисків, залежно від типу вузла. Докладніше див. Sizes for virtual machines in Azure.

  • Якщо драйвер сховища CSI рекламує максимальну кількість томів для вузла (використовуючи NodeGetInfo), kube-scheduler дотримується цього обмеження. Див. специфікації CSI для отримання додаткових деталей.

  • Для томів, керованих вбудованими втулками, які були перенесені у драйвер CSI, максимальна кількість томів буде тією, яку повідомив драйвер CSI.

3.6.13 - Моніторинг справності томів

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.21 [alpha]

Моніторинг справності томів CSI дозволяє драйверам CSI виявляти ненормальні умови тому у підлеглих систем збереження та повідомляти про них як події у PVCs або Podʼи.

Моніторинг справності томів

Моніторинг справності томів Kubernetes є частиною того, як Kubernetes реалізує Container Storage Interface (CSI). Функція моніторингу справності томів реалізована у двох компонентах: контролері зовнішнього монітора справності та kubelet.

Якщо драйвер CSI підтримує функцію моніторингу справності томів зі сторони контролера, подія буде повідомлена у відповідний PersistentVolumeClaim (PVC) при виявленні ненормальної умови тому CSI.

Зовнішній контролер монітора справності також слідкує за подіями відмови вузла. Ви можете увімкнути моніторинг відмови вузла, встановивши прапорець enable-node-watcher в значення true. Коли зовнішній монітор справності виявляє подію відмови вузла, контролер повідомляє про подію PVC, щоб вказати, що Podʼи, які використовують цей PVC, розташовані на несправних вузлах.

Якщо драйвер CSI підтримує функцію моніторингу справності томів зі сторони вузла, подія буде повідомлена на кожному Pod, який використовує PVC, при виявленні ненормальної умови тому CSI. Крім того, інформація про справність томів викладена у вигляді метрик Kubelet VolumeStats. Додано нову метрику kubelet_volume_stats_health_status_abnormal. Ця метрика має дві мітки: namespace та persistentvolumeclaim. Лічильник приймає значення 1 або 0. 1 вказує на те, що том є несправним, 0 вказує на те, що том — справний. Докладніше див. у KEP.

Що далі

Див. документацію драйвера CSI, щоб дізнатися, які драйвери CSI реалізували цю функцію.

3.6.14 - Зберігання у Windows

Ця сторінка надає огляд зберігання, специфічного для операційної системи Windows.

Постійне зберігання

У Windows є багатошаровий файловий драйвер для монтування контейнерних шарів і створення копії файлової системи на основі NTFS. Всі шляхи файлів у контейнері вирішуються лише в межах контексту цього контейнера.

  • З Docker точки монтування томів можуть націлюватися лише на каталог у контейнері, а не на окремий файл. Це обмеження не стосується containerd.
  • Томи не можуть проєцювати файли або каталоги на файлову систему хосту.
  • Файлові системи тільки-читання не підтримуються, оскільки завжди потрібен доступ для запису до реєстру Windows та бази даних SAM. Однак томи тільки-читання підтримуються.
  • Маски користувача і дозволи для томів недоступні. Оскільки SAM не спільний між хостом і контейнером, немає зіставлення між ними. Всі дозволи вирішуються в межах контексту контейнера.

В результаті на вузлах Windows не підтримуються наступні можливості зберігання:

  • Монтування томів за підкаталогами: у Windows контейнер може монтувати лише весь том
  • Монтування томів за підкаталогами для секретів
  • Проєцювання монтування хосту
  • Коренева файлова система тільки-читання (зіставлені томи все ще підтримують readOnly)
  • Зіставлення блокового пристрою
  • Памʼять як носій зберігання (наприклад, emptyDir.medium встановлено на Memory)
  • Функції файлової системи, такі як uid/gid; дозволи Linux файлової системи для кожного користувача
  • Встановлення дозволів секрета з DefaultMode (залежність від UID/GID)
  • Підтримка зберігання/томів на основі NFS
  • Розширення змонтованого тому (resizefs)

Томи Kubernetes дозволяють розгортання складних застосунків, які вимагають постійності даних та вимог до спільного використання томів Pod, розгорнутих у Kubernetes. Управління постійними томами, повʼязаними із конкретним сховищем або протоколом, включає дії, такі як надання/відміна надання/зміна розміру томів, приєднання/відʼєднання тому від/до вузла Kubernetes та монтування/відмонтування тому від/до окремих контейнерів у Podʼі, які повинні зберігати дані.

Компоненти управління томами постачаються як втулок томів Kubernetes. У Windows підтримуються наступні широкі класи втулків томів Kubernetes:

Вбудовані втулки томів

На вузлах Windows підтримуються наступні вбудовані втулки, які підтримують постійне зберігання:

3.7 - Конфігурація

Ресурси, які Kubernetes надає для конфігурації Podів.

3.7.1 - Поради щодо конфігурації

Цей документ виділяє та консолідує найкращі практики конфігурації, які представлені в документації користувача, документації для початківців та прикладах.

Це живий документ. Якщо ви подумаєте про щось, що не включено до цього списку, але може бути корисним іншим користувачам, будь ласка, не соромтеся подати тікет або надіслати PR.

Загальні поради щодо конфігурації

  • При створенні конфігурацій вкажіть останню стабільну версію API.

  • Файли конфігурації повинні зберігатися у системі контролю версій, перш ніж бути перенесеними в кластер. Це дозволяє швидко відкочувати зміну конфігурації у разі необхідності. Це також сприяє перестворенню та відновленню кластера.

  • Пишіть файли конфігурації за допомогою YAML, а не JSON. Хоча ці формати можна використовувати взаємозамінно практично в усіх сценаріях, YAML зазвичай є більш зручним для користувачів.

  • Гуртуйте повʼязані обʼєкти в один файл, якщо це має сенс. Одним файлом часто легше керувати, ніж кількома. Podʼивіться на файл guestbook-all-in-one.yaml як приклад використання цього синтаксису.

  • Також зверніть увагу, що багато команд kubectl можна виконувати з теками. Наприклад, ви можете застосувати kubectl apply в теці з файлами конфігурації.

  • Не вказуйте типові значення без потреби: проста, мінімальна конфігурація зменшить ймовірність помилок.

  • Додайте описи обʼєктів в анотації, щоб забезпечити кращий самоаналіз.

"Чисті" Podʼи проти ReplicaSets, Deployments та Jobs

  • Не використовуйте "чисті" Podʼи (тобто Podʼи, не повʼязані з ReplicaSet або Deployment), якщо можна уникнути цього. "Чисті" Podʼи не будуть переплановані в разі відмови вузла.

    Використання Deployment, який як створює ReplicaSet для забезпечення того, що потрібна кількість Podʼів завжди доступна, так і вказує стратегію для заміни Podʼів (таку як RollingUpdate), майже завжди є переважним варіантом на відміну від створення Podʼів безпосередньо, за винятком деяких явних сценаріїв restartPolicy: Never. Також може бути прийнятним використання Job.

Services

  • Створіть Service перед створенням відповідного робочого навантаження (Deployments або ReplicaSets), і перед будь-якими створенням робочих навантажень, які мають до нього доступ. Коли Kubernetes запускає контейнер, він надає змінні середовища, які вказують на всі Serviceʼи, які працювали під час запуску контейнера. Наприклад, якщо існує Service з іменем foo, то всі контейнери отримають наступні змінні у своєму початковому середовищі:

    FOO_SERVICE_HOST=<хост, на якому працює Service>
    FOO_SERVICE_PORT=<порт, на якому працює Service>
    

    Це передбачає вимоги щодо черговості — будь-який Service, до якого Pod хоче отримати доступ, повинен бути створений перед створенням цього Podʼу, бо змінні середовища не будуть заповнені. DNS не має такого обмеження.

  • Необовʼязкова (хоча настійно рекомендована) надбудова для кластера — це DNS-сервер. DNS-сервер спостерігає за Kubernetes API за появою нових Serviceʼів та створює набір DNS-записів для кожного з них. Якщо DNS було активовано в усьому кластері, то всі Podʼи повинні мати можливість автоматичного використовувати назви Serviceʼів.

  • Не вказуйте hostPort для Podʼа, якщо це не є абсолютно необхідним. Коли ви привʼязуєте Pod до hostPort, це обмежує місця, де може бути запланований Pod, оскільки кожна комбінація <hostIP, hostPort, protocol> повинна бути унікальною. Якщо ви не вказуєте явно hostIP та protocol, Kubernetes використовуватиме 0.0.0.0 як типовий hostIP та TCP як типовий protocol.

    Якщо вам потрібен доступ до порту лише для налагодження, ви можете використовувати apiserver proxy або kubectl port-forward.

    Якщо вам дійсно потрібно використовувати порт Подʼа на вузлі, розгляньте можливість використання NodePort Service перед використанням hostPort.

  • Уникайте використання hostNetwork, з тих самих причин, що й hostPort.

  • Використовуйте headless Service (які мають ClusterIP None) для виявлення Service, коли вам не потрібен балансувальник навантаження kube-proxy.

Використання міток

  • Визначайте та використовуйте мітки, які ідентифікують семантичні атрибути вашого застосунку або Deployment, такі як { app.kubernetes.io/name: MyApp, tier: frontend, phase: test, deployment: v3 }. Ви можете використовувати ці мітки для вибору відповідних Podʼів для інших ресурсів; наприклад, Service, який вибирає всі Podʼи з tier: frontend, або всі складові phase: test з app.kubernetes.io/name: MyApp. Подивіться застосунок гостьова книга для прикладів застосування такого підходу.

    Service може охоплювати кілька Deploymentʼів, пропускаючи мітки, специфічні для релізу, від його селектора. Коли вам потрібно оновити робочий Service без простою, використовуйте Deployment.

    Бажаний стан обʼєкта описується Deploymentʼом, і якщо зміни до його специфікації будуть застосовані, контролер Deployment змінює фактичний стан на бажаний з контрольованою швидкістю.

  • Використовуйте загальні мітки Kubernetes для загальних випадків використання. Ці стандартизовані мітки збагачують метадані таким чином, що дозволяють інструментам, включаючи kubectl та інфопанель (dashboard), працювати в сумісний спосіб.

  • Ви можете маніпулювати мітками для налагодження. Оскільки контролери Kubernetes (такі як ReplicaSet) та Service отримують збіг з Podʼами за допомогою міток селектора, видалення відповідних міток з Podʼа зупинить його від обробки контролером або від обслуговування трафіку Serviceʼом. Якщо ви видалите мітки наявного Podʼа, його контролер створить новий Pod, щоб зайняти його місце. Це корисний спосіб налагоджувати раніше "справний" Pod в "карантинному" середовищі. Щоб інтерактивно видаляти або додавати мітки, використовуйте kubectl label.

Використання kubectl

3.7.2 - ConfigMaps

ConfigMap це обʼєкт API, призначений для зберігання неконфіденційних даних у вигляді пар ключ-значення. Podʼи можуть використовувати ConfigMap як змінні середовища, аргументи командного рядка чи файли конфігурації у томі.

ConfigMap дозволяє відділити конфігурацію, специфічну для середовища, від образів контейнерів, щоб ваші застосунки були легко переносимими.

Мотивація

Використовуйте ConfigMap для визначення конфігураційних даних окремо від коду застосунку.

Наприклад, уявіть, що ви розробляєте застосунок, який ви можете запускати на своєму власному компʼютері (для розробки) і в хмарі (для обробки реального трафіку). Ви пишете код, який переглядає змінну середовища з назвою DATABASE_HOST. Локально ви встановлюєте цю змінну як localhost. У хмарі ви встановлюєте її так, щоб вона посилалася на Service, який надає доступ до компонент бази даних вашому кластеру. Це дозволяє вам отримати образ контейнера, який працює в хмарі, і в разі потреби налагоджувати той самий код локально.

Обʼєкт ConfigMap

ConfigMap — це обʼєкт API, який дозволяє зберігати конфігураційні дані для використання іншими обʼєктами. На відміну від більшості обʼєктів Kubernetes, у яких є spec, ConfigMap має поля data та binaryData. Ці поля приймають пари ключ-значення як свої значення. Обидва поля data і binaryData є необовʼязковими. Поле data призначене для зберігання рядків UTF-8, тоді як поле binaryData призначене для зберігання бінарних даних у вигляді рядків, закодованих у base64.

Назва ConfigMap повинна бути дійсним піддоменом DNS.

Кожний ключ у полі data або binaryData повинен складатися з алфавітно-цифрових символів, -, _ або .. Ключі, збережені в data, не повинні перетинатися з ключами у полі binaryData.

Починаючи з версії v1.19, ви можете додати поле immutable до визначення ConfigMap, щоб створити незмінний ConfigMap.

ConfigMaps та Podʼи

Ви можете написати spec Podʼа, який посилається на ConfigMap і конфігурує контейнер(и) в цьому Podʼі на основі даних з ConfigMap. Pod і ConfigMap повинні бути в тому самому namespace.

Ось приклад ConfigMap, який має деякі ключі з одними значеннями, та інші ключі, де значення виглядає як фрагмент формату конфігурації.

apiVersion: v1
kind: ConfigMap
metadata:
  name: game-demo
data:
  # ключі у вигляді властивостей; кожен ключ зіставляється з простим значенням
  player_initial_lives: "3"
  ui_properties_file_name: "user-interface.properties"

  # ключі у формі файлів
  game.properties: |
    enemy.types=aliens,monsters
    player.maximum-lives=5    
  user-interface.properties: |
    color.good=purple
    color.bad=yellow
    allow.textmode=true    

Є чотири різних способи використання ConfigMap для конфігурації контейнера всередині Podʼа:

  1. В команді та аргументах контейнера
  2. В змінних середовища для контейнера
  3. Додайте файл до тому тільки для читання, щоб застосунок міг його читати
  4. Напишіть код для виконання всередині Podʼа, який використовує Kubernetes API для читання ConfigMap

Ці різні методи підходять для різних способів моделювання даних, які споживаються. Для перших трьох методів kubelet використовує дані з ConfigMap при запуску контейнер(ів) для Podʼа.

Четвертий метод означає, що вам потрібно написати код для читання ConfigMap та його даних. Однак, оскільки ви використовуєте прямий доступ до Kubernetes API, ваш застосунок може підписатися на отримання оновлень, коли змінюється ConfigMap, і реагувати на це. Завдяки прямому доступу до Kubernetes API цей технічний підхід також дозволяє вам отримувати доступ до ConfigMap в іншому namespace.

Ось приклад Podʼа, який використовує значення з game-demo для конфігурації Podʼа:

apiVersion: v1
kind: Pod
metadata:
  name: configmap-demo-pod
spec:
  containers:
    - name: demo
      image: alpine
      command: ["sleep", "3600"]
      env:
        # Визначення змінної середовища
        - name: PLAYER_INITIAL_LIVES # Зверніть увагу, що регістр відрізняється тут
                                     # від назви ключа в ConfigMap.
          valueFrom:
            configMapKeyRef:
              name: game-demo           # ConfigMap, з якого отримується це значення.
              key: player_initial_lives # Ключ для отримання значення.
        - name: UI_PROPERTIES_FILE_NAME
          valueFrom:
            configMapKeyRef:
              name: game-demo
              key: ui_properties_file_name
      volumeMounts:
      - name: config
        mountPath: "/config"
        readOnly: true
  volumes:
  # Ви встановлюєте томи на рівні Pod, а потім монтуєте їх в контейнери всередині цього Pod
  - name: config
    configMap:
      # Вкажіть назву ConfigMap, який ви хочете змонтувати.
      name: game-demo
      # Масив ключів з ConfigMap, які треба створити як файли
      items:
      - key: "game.properties"
        path: "game.properties"
      - key: "user-interface.properties"
        path: "user-interface.properties"

ConfigMap не розрізняє значення властивостей з окремих рядків та багаторядкові файлоподібні значення. Важливо, як Podʼи та інші обʼєкти використовують ці значення.

У цьому прикладі визначення тому та монтування його всередину контейнера demo як /config створює два файли, /config/game.properties та /config/user-interface.properties, навіть якщо в ConfigMap є чотири ключі. Це тому, що визначення Podʼа вказує на масив items в розділі volumes. Якщо ви взагалі опустите масив items, кожен ключ у ConfigMap стане файлом з тією ж навою, що й ключ, і ви отримаєте 4 файли.

Використання ConfigMap

ConfigMap можуть бути змонтовані як томи з даними. ConfigMap також можуть бути використані іншими частинами системи, не піддаючись безпосередньому впливу Podʼа. Наприклад, ConfigMap можуть містити дані, які повинні використовуватися іншими частинами системи для конфігурації.

Найпоширеніший спосіб використання ConfigMap — це конфігурація налаштувань для контейнерів, які запускаються в Podʼі в тому ж namespace. Ви також можете використовувати ConfigMap окремо.

Наприклад, ви можете зустріти надбудови або оператори, які налаштовують свою поведінку на основі ConfigMap.

Використання ConfigMaps як файлів в Pod

Щоб використовувати ConfigMap в томі в Podʼі:

  1. Створіть ConfigMap або використовуйте наявний. Декілька Podʼів можуть посилатися на один ConfigMap.
  2. Змініть ваше визначення Podʼа, щоб додати том в .spec.volumes[]. Назвіть том будь-яким імʼям, та встановіть поле .spec.volumes[].configMap.name для посилання на ваш обʼєкт ConfigMap.
  3. Додайте .spec.containers[].volumeMounts[] до кожного контейнера, який потребує ConfigMap. Вкажіть .spec.containers[].volumeMounts[].readOnly = true та .spec.containers[].volumeMounts[].mountPath в невикористану назву каталогу, де ви хочете, щоб зʼявився ConfigMap.
  4. Змініть ваш образ або командний рядок так, щоб програма шукала файли у цьому каталозі. Кожен ключ в ConfigMap data стає імʼям файлу в mountPath.

Ось приклад Podʼа, який монтує ConfigMap в том:

apiVersion: v1
kind:ʼPod {#configmap-object}
metadata:
  name: mypod
spec:
  containers:
  - name: mypod
    image: redis
    volumeMounts:
    - name: foo
      mountPath: "/etc/foo"
      readOnly: true
  volumes:
  - name: foo
    configMap:
      name: myconfigmap

Кожен ConfigMap, який ви хочете використовувати, слід зазначити в .spec.volumes.

Якщо в Podʼі є кілька контейнерів, то кожен контейнер потребує свого власного блоку volumeMounts, але потрібно лише одне полу .spec.volumes на ConfigMap.

Змонтовані ConfigMaps оновлюються автоматично

Коли ConfigMap, що наразі використовується в томі, оновлюється, ключі, що зіставляються, в кінцевому підсумку також оновлюються. Kubelet перевіряє, чи змонтований ConfigMap є свіжим під час кожної синхронізації. Однак Kubelet використовує свій локальний кеш для отримання поточного значення ConfigMap. Тип кешу настроюється за допомогою поля configMapAndSecretChangeDetectionStrategy в структурі KubeletConfiguration. ConfigMap можна поширити за допомогою watch (типово), на основі ttl або шляхом перенаправлення всіх запитів безпосередньо до сервера API. Отже, загальна затримка від моменту оновлення ConfigMap до моменту коли нові ключі зʼявляться в Pod може становити стільки, скільки й періодична затримка kubelet + затримка поширення кешу, де затримка поширення кешу залежить від обраного типу кешу (вона дорівнює затримці поширення watch, ttl кешу або нулю відповідно).

ConfigMap, що використовуються як змінні оточення, не оновлюються автоматично і потребують перезапуску Podʼа.

Використання ConfigMaps як змінних середовища

Щоб використовувати ConfigMap у змінних середовища в Podʼі:

  1. Для кожного контейнера у вашій специфікації Podʼа додайте змінну середовища для кожного ключа ConfigMap, який ви хочете використовувати, до поля env[].valueFrom.configMapKeyRef.
  2. Змініть ваш образ та/або командний рядок так, щоб програма шукала значення у вказаних змінних середовища.

Ось приклад визначення ConfigMap як змінної середовища Podʼа:

Цей ConfigMap (myconfigmap.yaml) містить дві властивості: username та access_level:

apiVersion: v1
kind: ConfigMap
metadata:
  name: myconfigmap
data:
  username: k8s-admin
  access_level: "1"

Наступна команда створить обʼєкт ConfigMap:

kubectl apply -f myconfigmap.yaml

Наступний Pod використовує вміст ConfigMap як змінні середовища:

apiVersion: v1
kind: Pod
metadata:
  name: env-configmap
spec:
  containers:
    - name: app
      command: ["/bin/sh", "-c", "printenv"]
      image: busybox:latest
      envFrom:
        - configMapRef:
            name: myconfigmap

Поле envFrom вказує Kubernetes створити змінні середовища з джерел, вкладених у нього. Внутрішній configMapRef посилається на ConfigMap за його імʼям і вибирає всі його пари ключ-значення. Додайте Pod до свого кластера, а потім перегляньте його логи, щоб побачити виведення команди printenv. Це має підтвердити, що дві пари ключ-значення з ConfigMap були встановлені як змінні середовища:

kubectl apply -f env-configmap.yaml
kubectl logs pod/ env-configmap

Вивід буде подібний до цього:

...
username: "k8s-admin"
access_level: "1"
...

Іноді Pod не потребуватиме доступу до всіх значень у ConfigMap. Наприклад, можна мати інший Pod, який використовує тільки значення username з ConfigMap. Для цього випадку можна використовувати синтаксис env.valueFrom, який дозволяє вибирати окремі ключі в ConfigMap. Імʼя змінної середовища також може відрізнятися від ключа в ConfigMap. Наприклад:

apiVersion: v1
kind: Pod
metadata:
  name: env-configmap
spec:
  containers:
  - name: envars-test-container
    image: nginx
    env:
    - name: CONFIGMAP_USERNAME
      valueFrom:
        configMapKeyRef:
          name: myconfigmap
          key: username

У Podʼі, створеному з цього маніфесту, ви побачите, що змінна середовища CONFIGMAP_USERNAME встановлена на значення username з ConfigMap. Інші ключі з даних ConfigMap не будуть скопійовані у середовище.

Важливо зауважити, що діапазон символів, дозволених для назв змінних середовища в Podʼах, обмежений. Якщо будь-які ключі не відповідають правилам, ці ключі не будуть доступні вашому контейнеру, хоча Pod може бути запущений.

Незмінні ConfigMap

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.21 [stable]

Функція Kubernetes Immutable Secrets та ConfigMaps надає опцію встановлення індивідуальних Secret та ConfigMap як незмінних. Для кластерів, що інтенсивно використовують ConfigMap (принаймні десятки тисяч унікальних монтувань ConfigMap до Podʼів), запобігання змінам їх даних має наступні переваги:

  • захищає від випадкових (або небажаних) оновлень, які можуть призвести до відмов застосунків
  • покращує продуктивність кластера шляхом значного зниження навантаження на kube-apiserver, закриваючи спостереження за ConfigMap, які позначені як незмінні.

Ви можете створити незмінний ConfigMap, встановивши поле immutable в true. Наприклад:

apiVersion: v1
kind: ConfigMap
metadata:
  ...
data:
  ...
immutable: true

Після того як ConfigMap позначено як незмінний, змінити цю властивість або змінити вміст поля data або binaryData неможливо. Ви можете лише видалити та створити ConfigMap знову. Тому що поточні Podʼи підтримують точку монтування для видаленого ConfigMap, рекомендується перестворити ці Podʼи.

Що далі

3.7.3 - Secrets

Secret — це обʼєкт, який містить невелику кількість конфіденційних даних, таких як пароль, токен або ключ. Така інформація також може бути включена до специфікації Pod або в образ контейнера. Використання Secret означає, що вам не потрібно включати конфіденційні дані у ваш код.

Оскільки Secret можуть бути створені незалежно від Podʼів, які їх використовують, існує менше ризику того, що Secret (і його дані) буде викрито під час процесу створення, перегляду та редагування Podʼів. Kubernetes та програми, які працюють у вашому кластері, також можуть вживати додаткових заходів безпеки щодо Secretʼів, наприклад, уникання запису конфіденційних даних у енергонезалежне сховище.

Secretʼи схожі на ConfigMap, але призначені для зберігання конфіденційних даних.

Дивіться Інформаційна безпека для Secret для отримання додаткових відомостей.

Застосування Secretʼів

Ви можете використовувати Secrets для таких цілей:

Панель управління Kubernetes також використовує Secretʼи; наприклад, Secret токену реєстрації вузлів — це механізм, що допомагає автоматизувати реєстрацію вузлів.

Сценарій використання: dotfiles у томі Secret

Ви можете зробити ваші дані "прихованими", визначивши ключ, який починається з крапки. Цей ключ являє собою dotfile або "прихований" файл. Наприклад, коли наступний Secret підключається до тому secret-volume, том буде містити один файл, з назвою .secret-file, і контейнер dotfile-test-container матиме цей файл присутнім у шляху /etc/secret-volume/.secret-file.

apiVersion: v1
kind: Secret
metadata:
  name: dotfile-secret
data:
  .secret-file: dmFsdWUtMg0KDQo=
---
apiVersion: v1
kind: Pod
metadata:
  name: secret-dotfiles-pod
spec:
  volumes:
    - name: secret-volume
      secret:
        secretName: dotfile-secret
  containers:
    - name: dotfile-test-container
      image: registry.k8s.io/busybox
      command:
        - ls
        - "-l"
        - "/etc/secret-volume"
      volumeMounts:
        - name: secret-volume
          readOnly: true
          mountPath: "/etc/secret-volume"

Сценарій використання: Secret видимий для одного контейнера в Pod

Припустимо, що у вас є програма, яка потребує обробки HTTP-запитів, виконання складної бізнес-логіки та підписування деяких повідомлень HMAC. Оскільки у неї складна логіка застосунків, може бути непоміченою вразливість на віддалене читання файлів з сервера, що може дати доступ до приватного ключа зловмиснику.

Це можна розділити на два процеси у двох контейнерах: контейнер інтерфейсу, який обробляє взаємодію з користувачем та бізнес-логіку, але не може бачити приватний ключ; і контейнер що перевіряє підписи, який може бачити приватний ключ, та відповідає на прості запити на підпис від фронтенду (наприклад, через мережу localhost).

З цим розділеним підходом зловмиснику зараз потрібно обманути сервер застосунків, щоб зробити щось досить довільне, що може бути складніше, ніж змусити його прочитати файл.

Альтернативи Secretʼам

Замість використання Secret для захисту конфіденційних даних, ви можете вибрати з альтернатив.

Ось деякі з варіантів:

  • Якщо ваш хмарно-орієнтований компонент потребує автентифікації від іншого застосунку, який, ви знаєте, працює в межах того ж кластера Kubernetes, ви можете використовувати ServiceAccount та його токени, щоб ідентифікувати вашого клієнта.
  • Існують сторонні інструменти, які ви можете запускати, як в межах, так і поза вашим кластером, які керують чутливими даними. Наприклад, Service, до якого Podʼи мають доступ через HTTPS, який використовує Secret, якщо клієнт правильно автентифікується (наприклад, з токеном ServiceAccount).
  • Для автентифікації ви можете реалізувати спеціальний підписувач для сертифікатів X.509, і використовувати CertificateSigningRequests, щоб дозволити цьому спеціальному підписувачу видавати сертифікати Podʼам, які їх потребують.
  • Ви можете використовувати втулок пристрою, щоб використовувати апаратне забезпечення шифрування, яке локалізоване на вузлі, для певного Podʼа. Наприклад, ви можете розмістити довірені Podʼи на вузлах, які надають Trusted Platform Module.

Ви також можете комбінувати два або більше з цих варіантів, включаючи варіант використання Secret самостійно.

Наприклад: реалізуйте (або розгорніть) оператор, що отримує тимчасові токени сеансів від зовнішнього Service, а потім створює Secretʼи на основі цих тимчасових токенів. Podʼи, що працюють у вашому кластері, можуть використовувати токени сеансів, а оператор забезпечує їхню дійсність. Це розподілення означає, що ви можете запускати Podʼи, які не знають точних механізмів створення та оновлення цих токенів сеансів.

Типи Secret

При створенні Secret ви можете вказати його тип, використовуючи поле type ресурсу Secret, або певні еквівалентні прапорці командного рядка kubectl (якщо вони доступні). Тип Secret використовується для сприяння програмному обробленню даних Secret.

Kubernetes надає кілька вбудованих типів для деяких типових сценаріїв використання. Ці типи відрізняються за умовами перевірки та обмеженнями, які Kubernetes накладає на них.

Вбудований ТипВикористання
Opaqueдовільні користувацькі дані
kubernetes.io/service-account-tokenтокен ServiceAccount
kubernetes.io/dockercfgсеріалізований файл ~/.dockercfg
kubernetes.io/dockerconfigjsonсеріалізований файл ~/.docker/config.json
kubernetes.io/basic-authоблікові дані для базової автентифікації
kubernetes.io/ssh-authоблікові дані для SSH автентифікації
kubernetes.io/tlsдані для TLS клієнта або сервера
bootstrap.kubernetes.io/tokenдані bootstrap token

Ви можете визначити та використовувати власний тип Secret, присвоївши непорожній рядок як значення type обʼєкту Secret (порожній рядок розглядається як тип Opaque).

Kubernetes не накладає жодних обмежень на назву типу. Однак, якщо ви використовуєте один з вбудованих типів, ви повинні задовольнити всі вимоги, визначені для цього типу.

Якщо ви визначаєте тип Secret, призначений для загального використання, дотримуйтесь домовленостей та структуруйте тип Secret так, щоб він мав ваш домен перед назвою, розділений знаком /. Наприклад: cloud-hosting.example.net/cloud-api-credentials.

Opaque Secrets

Opaque — це стандартний тип Secret, якщо ви не вказуєте явно тип у маніфесті Secret. При створенні Secret за допомогою kubectl вам потрібно використовувати команду generic, щоб вказати тип Secret Opaque. Наприклад, наступна команда створює порожній Secret типу Opaque:

kubectl create secret generic empty-secret
kubectl get secret empty-secret

Вивід виглядає наступним чином:

NAME           TYPE     DATA   AGE
empty-secret   Opaque   0      2m6s

У стовпчику DATA показується кількість елементів даних, збережених у Secret. У цьому випадку 0 означає, що ви створили порожній Secret.

Secret токенів ServiceAccount

Тип Secret kubernetes.io/service-account-token використовується для зберігання токену, який ідентифікує ServiceAccount. Це старий механізм, який забезпечує довгострокові облікові дані ServiceAccount для Podʼів.

У Kubernetes v1.22 та пізніших рекомендований підхід полягає в тому, щоб отримати короткостроковий, токен ServiceAccount який автоматично змінюється за допомогою API [TokenRequest](/uk/docs/reference/kubernetes-api/authentication-resources/ token-request-v1/) замість цього. Ви можете отримати ці короткострокові токени, використовуючи наступні методи:

  • Викликайте API TokenRequest або використовуйте клієнт API, такий як kubectl. Наприклад, ви можете використовувати команду kubectl create token.
  • Запитуйте монтований токен в томі projected у вашому маніфесті Podʼа. Kubernetes створює токен і монтує його в Pod. Токен автоматично анулюється, коли Pod, в якому він монтується, видаляється. Докладні відомості див. в розділі Запуск Podʼа за допомогою токена ServiceAccount.

При використанні цього типу Secret вам потрібно переконатися, що анотація kubernetes.io/service-account.name встановлена на наявне імʼя ServiceAccount. Якщо ви створюєте як Secret, так і обʼєкти ServiceAccount, ви повинні спочатку створити обʼєкт ServiceAccount.

Після створення Secret контролер Kubernetes заповнює деякі інші поля, такі як анотація kubernetes.io/service-account.uid, та ключ token в полі data, який заповнюється токеном автентифікації.

У наступному прикладі конфігурації оголошується Secret токена ServiceAccount:

apiVersion: v1
kind: Secret
metadata:
  name: secret-sa-sample
  annotations:
    kubernetes.io/service-account.name: "sa-name"
type: kubernetes.io/service-account-token
data:
  extra: YmFyCg==

Після створення Secret дочекайтеся, коли Kubernetes заповнить ключ token в полі data.

Для отримання додаткової інформації про роботу ServiceAccounts перегляньте документацію по ServiceAccount. Ви також можете перевірити поле automountServiceAccountToken та поле serviceAccountName у Pod для отримання інформації про посилання на облікові дані ServiceAccount з Podʼів.

Secret конфігурації Docker

Якщо ви створюєте Secret для зберігання облікових даних для доступу до реєстру образів контейнерів, ви повинні використовувати одне з наступних значень type для цього Secret:

  • kubernetes.io/dockercfg: збереже серіалізований ~/.dockercfg, який є старим форматом налаштування командного рядка Docker. У полі data Secret міститься ключ .dockercfg, значення якого — це вміст файлу ~/.dockercfg, закодованого у форматі base64.
  • kubernetes.io/dockerconfigjson: збереже серіалізований JSON, який слідує тим же правилам формату, що й файл ~/.docker/config.json, який є новим форматом для ~/.dockercfg. У полі data Secret має міститися ключ .dockerconfigjson, значення якого – це вміст файлу ~/.docker/config.json, закодованого у форматі base64.

Нижче наведено приклад для Secret типу kubernetes.io/dockercfg:

apiVersion: v1
kind: Secret
metadata:
  name: secret-dockercfg
type: kubernetes.io/dockercfg
data:
  .dockercfg: |
    eyJhdXRocyI6eyJodHRwczovL2V4YW1wbGUvdjEvIjp7ImF1dGgiOiJvcGVuc2VzYW1lIn19fQo=    

При створенні Secret конфігурації Docker за допомогою маніфесту, API сервер перевіряє, чи існує відповідний ключ у полі data, і перевіряє, чи надане значення можна розпізнати як дійсний JSON. API сервер не перевіряє, чи є цей JSON фактично файлом конфігурації Docker.

Ви також можете використовувати kubectl для створення Secret для доступу до реєстру контейнерів, наприклад, коли у вас немає файлу конфігурації Docker:

kubectl create secret docker-registry secret-tiger-docker \
  --docker-email=tiger@acme.example \
  --docker-username=tiger \
  --docker-password=pass1234 \
  --docker-server=my-registry.example:5000

Ця команда створює Secret типу kubernetes.io/dockerconfigjson.

Отримайте поле .data.dockerconfigjson з цього нового Secret та розкодуйте дані:

kubectl get secret secret-tiger-docker -o jsonpath='{.data.*}' | base64 -d

Вихід еквівалентний наступному JSON-документу (який також є дійсним файлом конфігурації Docker):

{
  "auths": {
    "my-registry.example:5000": {
      "username": "tiger",
      "password": "pass1234",
      "email": "tiger@acme.example",
      "auth": "dGlnZXI6cGFzczEyMzQ="
    }
  }
}

Secret базової автентифікації

Тип kubernetes.io/basic-auth наданий для зберігання облікових даних, необхідних для базової автентифікації. При використанні цього типу Secret, поле data Secret повинно містити один з двох наступних ключів:

  • username: імʼя користувача для автентифікації
  • password: пароль або токен для автентифікації

Обидва значення для цих ключів закодовані у формат base64. Ви також можете надати чіткий текст, використовуючи поле stringData у маніфесті Secret.

Наступний маніфест є прикладом Secret для базової автентифікації:

apiVersion: v1
kind: Secret
metadata:
  name: secret-basic-auth
type: kubernetes.io/basic-auth
stringData:
  username: admin # обовʼязкове поле для kubernetes.io/basic-auth
  password: t0p-Secret # обовʼязкове поле для kubernetes.io/basic-auth

Тип Secret для базової автентифікації наданий лише для зручності. Ви можете створити тип Opaque для облікових даних, які використовуються для базової автентифікації. Однак використання визначеного та публічного типу Secret (kubernetes.io/basic-auth) допомагає іншим людям зрозуміти призначення вашого Secret та встановлює домовленості для очікуваних назв ключів.

Secret для автентифікації SSH

Вбудований тип kubernetes.io/ssh-auth наданий для зберігання даних, що використовуються в автентифікації SSH. При використанні цього типу Secret, вам потрібно вказати пару ключ-значення ssh-privatekey в полі data (або stringData) як SSH-автентифікаційні дані для використання.

Наступний маніфест є прикладом Secret, який використовується для автентифікації SSH з використанням пари публічного/приватного ключів:

apiVersion: v1
kind: Secret
metadata:
  name: secret-ssh-auth
type: kubernetes.io/ssh-auth
data:
  # в цьомум прикладі поле data скорочене
  ssh-privatekey: |
    UG91cmluZzYlRW1vdGljb24lU2N1YmE=    

Тип Secret для автентифікації SSH наданий лише для зручності. Ви можете створити тип Opaque для облікових даних, які використовуються для автентифікації SSH. Однак використання визначеного та публічного типу Secret (kubernetes.io/ssh-auth) допомагає іншим людям зрозуміти призначення вашого Secret та встановлює домовленості для очікуваних назв ключів. API Kubernetes перевіряє, чи встановлені необхідні ключі для Secret цього типу.

TLS Secrets

Тип Secret kubernetes.io/tls призначений для зберігання сертифіката та його повʼязаного ключа, які зазвичай використовуються для TLS.

Одним з поширених використань TLS Secret є налаштування шифрування під час передачі для Ingress, але ви також можете використовувати його з іншими ресурсами або безпосередньо у вашій роботі. При використанні цього типу Secret ключі tls.key та tls.crt повинні бути надані в полі data (або stringData) конфігурації Secret, хоча сервер API фактично не перевіряє значення кожного ключа.

Як альтернативу використанню stringData, ви можете використовувати поле data для надання сертифіката та приватного ключа у вигляді base64-кодованого тексту. Докладніше див. Обмеження для назв і даних Secret.

Наступний YAML містить приклад конфігурації TLS Secret:

apiVersion: v1
kind: Secret
metadata:
  name: secret-tls
type: kubernetes.io/tls
data:
  # значення закодовані в форматі base64, що приховує їх, але НЕ забезпечує
  # жодного рівня конфіденційності
  tls.crt: |
    LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNVakNDQWJzQ0FnMytNQTBHQ1NxR1NJYjNE
    UUVCQlFVQU1JR2JNUXN3Q1FZRFZRUUdFd0pLVURFT01Bd0cKQTFVRUNCTUZWRzlyZVc4eEVEQU9C
    Z05WQkFjVEIwTm9kVzh0YTNVeEVUQVBCZ05WQkFvVENFWnlZVzVyTkVSRQpNUmd3RmdZRFZRUUxF
    dzlYWldKRFpYSjBJRk4xY0hCdmNuUXhHREFXQmdOVkJBTVREMFp5WVc1ck5FUkVJRmRsCllpQkRR
    VEVqTUNFR0NTcUdTSWIzRFFFSkFSWVVjM1Z3Y0c5eWRFQm1jbUZ1YXpSa1pDNWpiMjB3SGhjTk1U
    TXcKTVRFeE1EUTFNVE01V2hjTk1UZ3dNVEV3TURRMU1UTTVXakJMTVFzd0NRWURWUVFHREFKS1VE
    RVBNQTBHQTFVRQpDQXdHWEZSdmEzbHZNUkV3RHdZRFZRUUtEQWhHY21GdWF6UkVSREVZTUJZR0Ex
    VUVBd3dQZDNkM0xtVjRZVzF3CmJHVXVZMjl0TUlHYU1BMEdDU3FHU0liM0RRRUJBUVVBQTRHSUFE
    Q0JoQUo5WThFaUhmeHhNL25PbjJTbkkxWHgKRHdPdEJEVDFKRjBReTliMVlKanV2YjdjaTEwZjVN
    Vm1UQllqMUZTVWZNOU1vejJDVVFZdW4yRFljV29IcFA4ZQpqSG1BUFVrNVd5cDJRN1ArMjh1bklI
    QkphVGZlQ09PekZSUFY2MEdTWWUzNmFScG04L3dVVm16eGFLOGtCOWVaCmhPN3F1TjdtSWQxL2pW
    cTNKODhDQXdFQUFUQU5CZ2txaGtpRzl3MEJBUVVGQUFPQmdRQU1meTQzeE15OHh3QTUKVjF2T2NS
    OEtyNWNaSXdtbFhCUU8xeFEzazlxSGtyNFlUY1JxTVQ5WjVKTm1rWHYxK2VSaGcwTi9WMW5NUTRZ
    RgpnWXcxbnlESnBnOTduZUV4VzQyeXVlMFlHSDYyV1hYUUhyOVNVREgrRlowVnQvRGZsdklVTWRj
    UUFEZjM4aU9zCjlQbG1kb3YrcE0vNCs5a1h5aDhSUEkzZXZ6OS9NQT09Ci0tLS0tRU5EIENFUlRJ
    RklDQVRFLS0tLS0K    
  # У цьому прикладі, дані не є справжнім приватним ключем в форматі PEM
  tls.key: |
    RXhhbXBsZSBkYXRhIGZvciB0aGUgVExTIGNydCBmaWVsZA==    

Тип TLS Secret наданий лише для зручності. Ви можете створити тип Opaque для облікових даних, які використовуються для TLS-автентифікації. Однак використання визначеного та публічного типу Secret (kubernetes.io/tls) допомагає забезпечити однорідність формату Secret у вашому проєкті. Сервер API перевіряє, чи встановлені необхідні ключі для Secret цього типу.

Для створення TLS Secret за допомогою kubectl використовуйте підкоманду tls:

kubectl create secret tls my-tls-secret \
  --cert=path/to/cert/file \
  --key=path/to/key/file

Пара публічного/приватного ключа повинна бути створена заздалегідь. Публічний ключ сертифіката для --cert повинен бути закодований у .PEM форматі і повинен відповідати наданому приватному ключу для --key.

Secret bootstrap-токенів

Тип Secret bootstrap.kubernetes.io/token призначений для токенів, що використовуються під час процесу ініціалізації вузла. Він зберігає токени, які використовуються для підпису відомих ConfigMaps.

Secret токена ініціалізації зазвичай створюється в просторі імен kube-system і називається у формі bootstrap-token-<token-id>, де <token-id> — це 6-символьний рядок ідентифікатора токена.

Як Kubernetes маніфест, Secret токена ініціалізації може виглядати наступним чином:

apiVersion: v1
kind: Secret
metadata:
  name: bootstrap-token-5emitj
  namespace: kube-system
type: bootstrap.kubernetes.io/token
data:
  auth-extra-groups: c3lzdGVtOmJvb3RzdHJhcHBlcnM6a3ViZWFkbTpkZWZhdWx0LW5vZGUtdG9rZW4=
  expiration: MjAyMC0wOS0xM1QwNDozOToxMFo=
  token-id: NWVtaXRq
  token-secret: a3E0Z2lodnN6emduMXAwcg==
  usage-bootstrap-authentication: dHJ1ZQ==
  usage-bootstrap-signing: dHJ1ZQ==

У Secret токена ініціалізації вказані наступні ключі в data:

  • token-id: Випадковий рядок з 6 символів як ідентифікатор токена. Обовʼязковий.
  • token-secret: Випадковий рядок з 16 символів як сам Secret токена. Обовʼязковий.
  • description: Рядок, що призначений для користувачів, що описує, для чого використовується токен. Необовʼязковий.
  • expiration: Абсолютний час UTC, відповідно до RFC3339, що вказує, коли дія токена має бути закінчена. Необовʼязковий.
  • usage-bootstrap-<usage>: Логічний прапорець, який вказує додаткове використання для токена ініціалізації.
  • auth-extra-groups: Список імен груп, розділених комами, які будуть автентифікуватися як додатково до групи system:bootstrappers.

Ви також можете надати значення в полі stringData Secret без їх base64 кодування:

apiVersion: v1
kind: Secret
metadata:
  # Зверніть увагу, як названий Secret
  name: bootstrap-token-5emitj
  # Зазвичай, Secret з bootstrap token знаходиться в просторі імен kube-system
  namespace: kube-system
type: bootstrap.kubernetes.io/token
stringData:
  auth-extra-groups: "system:bootstrappers:kubeadm:default-node-token"
  expiration: "2020-09-13T04:39:10Z"
  # Цей ідентифікатор токена використовується в назві
  token-id: "5emitj"
  token-secret: "kq4gihvszzgn1p0r"
  # Цей токен може бути використаний для автентифікації
  usage-bootstrap-authentication: "true"
  # і він може бути використаний для підпису
  usage-bootstrap-signing: "true"

Робота з Secret

Створення Secret

Є кілька способів створення Secret:

Обмеження щодо імен і даних Secret

Імʼя обʼєкта Secret повинно бути дійсним імʼям DNS-піддомену.

Ви можете вказати поля data і/або stringData при створенні файлу конфігурації для Secret. Поля data і stringData є необовʼязковими. Значення для всіх ключів у полі data повинні бути base64-кодованими рядками. Якщо перетворення у рядок base64 не є бажаним, ви можете вибрати поле stringData, яке приймає довільні рядки як значення.

Ключі data і stringData повинні складатися з буквено-цифрових символів, -, _ або .. Усі пари ключ-значення в полі stringData внутрішньо обʼєднуються в поле data. Якщо ключ зустрічається як у полі data, так і у полі stringData, значення, вказане у полі stringData, має пріоритет.

Обмеження розміру

Індивідуальні Secretʼи обмежені розміром 1 МБ. Це зроблено для того, щоб уникнути створення дуже великих Secret, які можуть вичерпати памʼять API-сервера та kubelet. Однак створення багатьох менших Secret також може вичерпати памʼять. Ви можете використовувати квоту ресурсів для обмеження кількості Secret (або інших ресурсів) в просторі імен.

Редагування Secret

Ви можете редагувати наявний Secret, якщо він не є незмінним. Для редагування Secret скористайтеся одним із наступних методів:

Ви також можете редагувати дані у Secret за допомогою інструменту Kustomize. Проте цей метод створює новий обʼєкт Secret з відредагованими даними.

Залежно від того, як ви створили Secret, а також від того, як Secret використовується в ваших Podʼах, оновлення існуючих обʼєктів Secret автоматично поширюються на Podʼи, які використовують дані. Для отримання додаткової інформації звертайтеся до розділу Використання Secret як файлів у Podʼі.

Використання Secret

Secret можна монтувати як томи даних або використовувати як змінні оточення для використання контейнером в Podʼі. Secret також можна використовувати іншими частинами системи, не надаючи прямого доступу до Podʼа. Наприклад, Secret можуть містити автентифікаційні дані, які інші частини системи повинні використовувати для взаємодії зовнішніми системами від вашого імені.

Джерела томів Secret перевіряються на наявність для того, щоб переконатися, що вказано посилання на обʼєкт дійсно вказує на обʼєкт типу Secret. Тому Secret повинен бути створений перед будь-якими Podʼами, які залежать від нього.

Якщо Secret не може бути отриманий (можливо, через те, що він не існує, або через тимчасову відсутність зʼєднання з сервером API), kubelet періодично повторює спробу запуску цього Podʼа. Крім того, kubelet також реєструє подію для цього Podʼа, включаючи деталі проблеми отримання Secret.

Необовʼязкові Secret

Коли ви посилаєтеся на Secret у Podʼі, ви можете позначити Secret як необовʼязковий, як у наступному прикладі. Якщо необовʼязковий Secret не існує, Kubernetes ігнорує його.

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mypod
    image: redis
    volumeMounts:
    - name: foo
      mountPath: "/etc/foo"
      readOnly: true
  volumes:
  - name: foo
    secret:
      secretName: mysecret
      optional: true

Типово Secret є обовʼязковими. Жоден з контейнерів Podʼа не розпочне роботу, доки всі обовʼязкові Secret не будуть доступні.

Якщо Pod посилається на певний ключ у необовʼязковому Secret і цей Secret існує, але відсутній зазначений ключ, Pod не запускається під час старту.

Використання Secret у вигляді файлів у Pod

Якщо ви хочете отримати доступ до даних з Secret у Podʼі, один із способів зробити це — це дозволити Kubernetes робити значення цього Secret доступним як файл у файловій системі одного або декількох контейнерів Podʼа.

Щоб це зробити, дивіться Створення Podʼа, який має доступ до секретних даних через Volume.

Коли том містить дані з Secret, а цей Secret оновлюється, Kubernetes відстежує це і оновлює дані в томі, використовуючи підхід з подальшою згодою.

Kubelet зберігає кеш поточних ключів та значень для Secret, які використовуються у томах для Podʼів на цьому вузлі. Ви можете налаштувати спосіб, яким kubelet виявляє зміни від кешованих значень. Поле configMapAndSecretChangeDetectionStrategy в конфігурації kubelet контролює стратегію, яку використовує kubelet. Стандартною стратегією є Watch.

Оновлення Secret можуть бути передані за допомогою механізму спостереження за API (стандартно), на основі кешу з визначеним часом життя або отримані зі API-сервера кластера в кожнному циклі синхронізації kubelet.

Як результат, загальна затримка від моменту оновлення Secret до моменту, коли нові ключі зʼявляються в Podʼі, може бути такою ж тривалою, як період синхронізації kubelet + затримка розповсюдження кешу, де затримка розповсюдження кешу залежить від обраного типу кешу (перший у списку це затримка розповсюдження спостереження, налаштований TTL кешу або нуль для прямого отримання).

Використання Secret як змінних оточення

Для використання Secret в змінних оточення в Podʼі:

  1. Для кожного контейнера у вашому описі Podʼа додайте змінну оточення для кожного ключа Secret, який ви хочете використовувати, у поле env[].valueFrom.secretKeyRef.
  2. Змініть свій образ і/або командний рядок так, щоб програма шукала значення у вказаних змінних оточення.

Для отримання інструкцій дивіться Визначення змінних оточення контейнера за допомогою даних Secret.

Важливо зауважити, що діапазон символів, дозволених для назв змінних середовища в Podʼах, обмежений. Якщо будь-які ключі не відповідають правилам, ці ключі не будуть доступні вашому контейнеру, хоча Pod може бути запущений.

Використання Secret для витягування образів контейнерів

Якщо ви хочете отримувати образи контейнерів з приватного репозиторію, вам потрібен спосіб автентифікації для kubelet на кожному вузлі для доступу до цього репозиторію. Ви можете налаштувати Secret для витягування образів для досягнення цієї мети. Ці Secret налаштовані на рівні Pod.

Використання imagePullSecrets

Поле imagePullSecrets є списком посилань на Secret в тому ж просторі імен. Ви можете використовувати imagePullSecrets, щоб передати Secret, який містить пароль Docker (або іншого) репозиторію образів, в kubelet. Kubelet використовує цю інформацію для витягування приватного образу від імені вашого Podʼа. Для отримання додаткової інформації про поле imagePullSecrets, дивіться PodSpec API.

Ручне вказання imagePullSecret

Ви можете дізнатися, як вказати imagePullSecrets, переглянувши документацію про образи контейнерів.

Організація автоматичного приєднання imagePullSecrets

Ви можете вручну створити imagePullSecrets та посилатися на них з ServiceAccount. Будь-які Podʼи, створені з цим ServiceAccount або створені з цим ServiceAccount, отримають своє поле imagePullSecrets, встановлене на відповідне для сервісного облікового запису. Дивіться Додавання ImagePullSecrets до Service Account для детального пояснення цього процесу.

Використання Secret зі статичними Podʼами

Ви не можете використовувати ConfigMaps або Secrets зі статичними Podʼами.

Незмінні Secret

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.21 [stable]

Kubernetes дозволяє вам позначати певні Secret (і ConfigMaps) як незмінні. Запобігання змінам даних існуючого Secret має наступні переваги:

  • захищає вас від випадкових (або небажаних) оновлень, які можуть призвести до відмов застосунків
  • (для кластерів, що широко використовують Secret — щонайменше десятки тисяч унікальних монтувань Secret у Podʼи), перехід до незмінних Secret покращує продуктивність вашого кластера шляхом значного зменшення навантаження на kube-apiserver. kubeletʼу не потрібно підтримувати [watch] за будь-якими Secret, які позначені як незмінні.

Позначення Secret як незмінного

Ви можете створити незмінний Secret, встановивши поле immutable в true. Наприклад,

apiVersion: v1
kind: Secret
metadata: ...
data: ...
immutable: true

Ви також можете оновити будь-який наявний змінний Secret, щоб зробити його незмінним.

Інформаційна безпека для Secret

Хоча ConfigMap і Secret працюють схоже, Kubernetes застосовує додаткові заходи захисту для обʼєктів Secret.

Secret часто містять значення, які охоплюють широкий спектр важливостей, багато з яких можуть викликати ескалації всередині Kubernetes (наприклад, токени облікових записів служби) та зовнішніх систем. Навіть якщо окремий застосунок може мати на меті використання Secret, з якими він очікує взаємодіяти, інші застосунки в тому ж просторі імен можуть зробити ці припущення недійсними.

Secret буде відправлений на вузол тільки у випадку, якщо на цьому вузлі є Pod, якому він потрібен. Для монтування Secret Podʼи kubelet зберігає копію даних у tmpfs, щоб конфіденційні дані не записувалися у носії з довгостроковим зберіганням. Коли Pod, який залежить від Secret, видаляється, kubelet видаляє свою локальну копію конфіденційних даних з Secret.

У Podʼі може бути кілька контейнерів. Типово контейнери, які ви визначаєте, мають доступ тільки до службового стандартного облікового запису та повʼязаного з ним Secret. Вам потрібно явно визначити змінні середовища або відобразити том у контейнері, щоб надати доступ до будь-якого іншого Secret.

Може бути Secret для кількох Podʼів на тому ж вузлі. Проте тільки Secretʼи, які запитує Pod, можливо бачити всередині його контейнерів. Таким чином, один Pod не має доступу до Secretʼів іншого Podʼа.

Налаштування доступу за принципом найменшого дозволу до Secret

Для підвищення заходів безпеки навколо Secret Kubernetes надає механізм: ви можете анотувати ServiceAccount як kubernetes.io/enforce-mountable-secrets: "true".

Докладніше ви можете дізнатися з документації про цю анотацію.

Що далі

3.7.4 - Керування ресурсами Podʼів та Контейнерів

Коли ви визначаєте Pod, ви можете додатково вказати, скільки кожного ресурсу потребує контейнер. Найпоширеніші ресурси для вказання — це процесор та памʼять (RAM); є й інші.

Коли ви вказуєте запит ресурсів для контейнерів в Podʼі, kube-scheduler використовує цю інформацію для вибору вузла, на який розмістити Pod. Коли ви вказуєте обмеження ресурсів для контейнера, kubelet забезпечує виконання цих обмежень, щоб запущений контейнер не міг використовувати більше цього ресурсу, ніж обмеження, яке ви встановили. Крім того, kubelet резервує принаймні ту кількість запитуваних ресурсів спеціально для використання цим контейнером.

Запити та обмеження

Якщо вузол, на якому запущений Pod, має достатньо вільного ресурсу, то можливе (і дозволено), щоб контейнер використовував більше ресурсу, ніж його запит для цього ресурсу вказує. Однак контейнеру не дозволяється використовувати більше, ніж його обмеження ресурсу.

Наприклад, якщо ви встановите запит memory 256 МіБ для контейнера, і цей контейнер буде в Pod, запланованому на вузол з 8 ГіБ памʼяті та без інших Pod, то контейнер може спробувати використати більше оперативної памʼяті.

Якщо ви встановите обмеження memory 4 ГіБ для цього контейнера, kubelet (і середовище виконання контейнерів) забезпечують виконання обмеження. Середовище запобігає контейнеру використовувати більше, ніж налаштоване обмеження ресурсів. Наприклад: коли процес в контейнері намагається використати більше дозволеної кількості памʼяті, ядро системи припиняє виконання процесу, що спробував здійснити виділення, з помилкою нестача памʼяті (out of memory, OOM).

Обмеження можуть бути виконані реактивно (система втручається після виявлення порушення) або за допомогою заборони (система завжди запобігає контейнеру перевищувати обмеження). Різні середовища можуть мати різні способи реалізації тих самих обмежень.

Типи ресурсів

ЦП та памʼять кожен є типом ресурсу. Тип ресурсу має базові одиниці вимірювання. ЦП представляє обчислювальні ресурси та вказується в одиницях ЦП Kubernetes. Памʼять вказується в байтах. Для робочих завдань на Linux ви можете вказати huge page ресурсів. Huge page є функцією, специфічною для Linux, де ядро вузла виділяє блоки памʼяті, що значно більше, ніж розмір стандартної сторінки.

Наприклад, у системі, де розмір стандартної сторінки становить 4 КіБ, ви можете вказати обмеження hugepages-2Mi: 80Mi. Якщо контейнер намагається виділити більше ніж 40 2МіБ великих сторінок (всього 80 МіБ), то це виділення не вдасться.

ЦП та памʼять спільно називаються обчислювальними ресурсами або ресурсами. Обчислювальні ресурси – це вимірювальні величини, які можна запитувати, виділяти та використовувати. Вони відрізняються від ресурсів API. Ресурси API, такі як Pod та Service, є обʼєктами, які можна читати та змінювати за допомогою сервера API Kubernetes.

Запити та обмеження ресурсів для Podʼа та контейнера

Для кожного контейнера ви можете вказати обмеження та запити ресурсів, включаючи наступне:

  • spec.containers[].resources.limits.cpu
  • spec.containers[].resources.limits.memory
  • spec.containers[].resources.limits.hugepages-<size>
  • spec.containers[].resources.requests.cpu
  • spec.containers[].resources.requests.memory
  • spec.containers[].resources.requests.hugepages-<size>

Хоча ви можете вказувати запити та обмеження тільки для окремих контейнерів, також корисно думати про загальні запити та обмеження ресурсів для Podʼа. Для певного ресурсу запит/обмеження ресурсів Podʼа — це сума запитів/обмежень цього типу для кожного контейнера в Podʼі.

Одиниці виміру ресурсів в Kubernetes

Одиниці виміру ресурсів процесора

Обмеження та запити ресурсів процесора вимірюються в одиницях cpu. У Kubernetes 1 одиниця CPU еквівалентна 1 фізичному ядру процесора або 1 віртуальному ядру, залежно від того, чи є вузол фізичним хостом або віртуальною машиною, яка працює всередині фізичної машини.

Допускаються дробові запити. Коли ви визначаєте контейнер з spec.containers[].resources.requests.cpu встановленою на 0.5, ви просите вдвічі менше часу CPU порівняно з тим, якщо ви запросили 1.0 CPU. Для одиниць ресурсів процесора вираз кількості 0.1 еквівалентний виразу 100m, що може бути прочитано як "сто міліпроцесорів". Деякі люди кажуть "сто міліядер", і це розуміється так само.

Ресурс CPU завжди вказується як абсолютна кількість ресурсу, ніколи як відносна кількість. Наприклад, 500m CPU представляє приблизно ту саму обчислювальну потужність, не важливо чи цей контейнер працює на одноядерній, двоядерній або 48-ядерній машині.

Одиниці виміру ресурсів памʼяті

Обмеження та запити для memory вимірюються в байтах. Ви можете вказувати памʼять як звичайне ціле число або як число з плаваючою комою, використовуючи один з наступних суфіксів кількості: E, P, T, G, M, k. Ви також можете використовувати еквіваленти степенів двійки: Ei, Pi, Ti, Gi, Mi, Ki. Наприклад, наступне приблизно представляє те ж саме значення:

128974848, 129e6, 129M,  128974848000m, 123Mi

Звертайте увагу на регістр суфіксів. Якщо ви запитуєте 400m памʼяті, це запит на 0.4 байта. Той, хто вводить це, ймовірно, мав на увазі запросити 400 мебібайтів (400Mi) або 400 мегабайтів (400M).

Приклад ресурсів контейнера

У наступному Podʼі є два контейнери. Обидва контейнери визначені з запитом на 0,25 CPU і 64 МіБ (226 байт) памʼяті. Кожен контейнер має обмеження в 0,5 CPU та 128 МіБ памʼяті. Можна сказати, що у Podʼі є запит на 0,5 CPU та 128 МіБ памʼяті, та обмеження в 1 CPU та 256 МіБ памʼяті.

---
apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: app
    image: images.my-company.example/app:v4
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"
  - name: log-aggregator
    image: images.my-company.example/log-aggregator:v6
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

Як Podʼи з запитаними ресурсами плануються

Коли ви створюєте Pod, планувальник Kubernetes вибирає вузол, на якому Pod буде запущено. Кожен вузол має максимальну місткість для кожного з типів ресурсів: кількість процесорних ядер (CPU) та обсяг памʼяті, які він може надати для Podʼів. Планувальник забезпечує, що для кожного типу ресурсів сума запитів ресурсів запланованих контейнерів буде менше, ніж місткість вузла. Зверніть увагу, що навіть якщо фактичне використання ресурсів CPU або памʼяті на вузлі дуже низьке, планувальник все одно відмовляється розміщувати Pod на вузлі, якщо перевірка місткості не пройшла успішно. Це захищає від нестачі ресурсів на вузлі, коли пізніше збільшується використання ресурсів, наприклад, під час денного піка запитів.

Як Kubernetes застосовує запити на ресурси та обмеження

Коли kubelet запускає контейнер як частину Podʼа, він передає запити та обмеження для памʼяті та CPU цього контейнера до середовища виконання контейнера.

У Linux середовище виконання контейнера зазвичай налаштовує контрольні групи (cgroups) ядра, які застосовують і виконують обмеження, що ви визначили.

  • Обмеження CPU встановлює жорсткий ліміт на те, скільки часу процесора контейнер може використовувати. Протягом кожного інтервалу планування (часового відрізка) ядро Linux перевіряє, чи перевищується це обмеження; якщо так, ядро чекає, перш ніж дозволити цій групі продовжити виконання.
  • Запит CPU зазвичай визначає вагу. Якщо кілька різних контейнерів (cgroups) хочуть працювати на конкуруючій системі, робочі навантаження з більшими запитами CPU отримують більше часу CPU, ніж робочі навантаження з малими запитами.
  • Запит памʼяті в основному використовується під час планування Podʼа (Kubernetes). На вузлі, що використовує cgroups v2, середовище виконання контейнера може використовувати запит памʼяті як підказку для встановлення memory.min та memory.low.
  • Обмеження памʼяті встановлює обмеження памʼяті для цієї контрольної групи. Якщо контейнер намагається виділити більше памʼяті, ніж це обмеження, підсистема управління памʼяттю Linux активується і, зазвичай, втручається, зупиняючи один з процесів у контейнері, який намагався виділити памʼять. Якщо цей процес є PID 1 контейнера, і контейнер позначений як можливий до перезапуску, Kubernetes перезапускає контейнер.
  • Обмеження памʼяті для Podʼа або контейнера також може застосовуватися до сторінок в памʼяті, резервованих томами, як от emptyDir. Kubelet відстежує tmpfs томи emptyDir як використання памʼяті контейнера, а не як локальне ефемерне сховище. При використанні emptyDir в памʼяті, обовʼязково ознайомтеся з примітками нижче.

Якщо контейнер перевищує свій запит на памʼять і вузол, на якому він працює, стикається з браком памʼяті взагалі, ймовірно, що Pod, якому належить цей контейнер, буде виселено.

Контейнер може або не може дозволяти перевищувати своє обмеження CPU протягом тривалого часу. Однак середовища виконання контейнерів не припиняють роботу Podʼа або контейнерів через надмірне використання CPU.

Щоб визначити, чи не можна розмістити контейнер або, чи його роботи примусово припиняється через обмеження ресурсів, див. Налагодження.

Моніторинг використання обчислювальних ресурсів та ресурсів памʼяті

kubelet повідомляє про використання ресурсів Podʼа як частину статусу Podʼа.

Якщо в вашому кластері доступні інструменти для моніторингу, то використання ресурсів Podʼа можна отримати або безпосередньо з Metrics API, або з вашого інструменту моніторингу.

Міркування щодо томів emptyDir, що зберігаються в памʼяті

З точки зору управління памʼяттю, є деякі подібності між використанням памʼяті як робочої області процесу і використанням памʼяті для emptyDir, що зберігається в памʼяті. Але при використанні памʼяті як том, як у випадку з emptyDir, що зберігається в памʼяті, є додаткові моменти, на які слід звернути увагу.

  • Файли, збережені в томі, що зберігається в памʼяті, майже повністю управляються застосунком користувча. На відміну від використання памʼяті як робочої області процесу, ви не можете покладатися на такі речі, як збір сміття на рівні мови програмування.
  • Мета запису файлів в том полягає в збереженні даних або їх передачі між застосунками. Ні Kubernetes, ні ОС не можуть автоматично видаляти файли з тому, тому памʼять, яку займають ці файли, не може бути відновлена, коли система або Pod відчувають нестачу памʼяті.
  • Томи emptyDir, що зберігаються в памʼяті, корисні через свою продуктивність, але памʼять зазвичай набагато менша за розміром і набагато дорожча за інші носії, такі як диски або SSD. Використання великої кількості памʼяті для томів emptyDir може вплинути на нормальну роботу вашого Podʼа або всього вузла, тому їх слід використовувати обережно.

Якщо ви адмініструєте кластер або простір імен, ви також можете встановити ResourceQuota, що обмежує використання памʼяті; також може бути корисно визначити LimitRange для додаткового забезпечення обмежень. Якщо ви вказуєте spec.containers[].resources.limits.memory для кожного Podʼа, то максимальний розмір тому emptyDir буде дорівнювати граничному обсягу памʼяті Podʼа.

Як альтернатива, адміністратор кластера може забезпечити дотримання обмежень на розмір томів emptyDir в нових Podʼах, використовуючи механізм політики, такий як ValidationAdmissionPolicy.

Локальне тимчасове сховище

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.25 [stable]

На вузлах існує локальне тимчасове сховище, яке підтримується локально приєднаними пристроями для запису або іноді ОЗУ. "Тимчасове" означає, що не існує гарантії тривалості.

Podʼи використовують тимчасове локальне сховище для тимчасового простору, кешування та для логів. kubelet може надавати тимчасовий простір Podʼам, використовуючи локальне тимчасове сховище для підключення emptyDir тому до контейнерів.

Крім того, kubelet використовує цей тип сховища для збереження логів контейнерів на рівні вузла, образів контейнерів та шарів з можливістю запису запущених контейнерів.

Kubernetes дозволяє відстежувати, резервувати та обмежувати обсяг тимчасового локального сховища, яке може використовувати Pod.

Налаштування для локального тимчасового сховища

Kubernetes підтримує два способи налаштування локального тимчасового сховища на вузлі:

У цій конфігурації ви розміщуєте всі різновиди тимчасових локальних даних (таких як тимчасові томи emptyDir, шари з можливістю запису, образи контейнерів, логи) в одній файловій системі. Найефективніший спосіб налаштування kubelet — призначити цю файлову систему для даних Kubernetes (kubelet).

Kubelet також записує логи контейнерів на рівні вузла та обробляє їх аналогічно до тимчасового локального сховища.

Kubelet записує логи в файли всередині свого налаштованого каталогу журналів (/var/log типово); та має базовий каталог для інших локально збережених даних (/var/lib/kubelet типово).

Зазвичай як /var/lib/kubelet, так і /var/log знаходяться на кореневій файловій системі системи, і kubelet розроблений з урахуванням цієї структури.

Ваш вузол може мати стільки інших файлових систем, не використовуваних для Kubernetes, скільки вам потрібно.

Ви маєте файлову систему на вузлі, яку використовуєте для тимчасових даних, які надходять від запущених Podʼів: логи та томи emptyDir. Ви можете використовувати цю файлову систему для інших даних (наприклад: системні логи, не повʼязані з Kubernetes); це може навіть бути кореневою файловою системою.

Kubelet також записує логи контейнерів на рівні вузла у першу файлову систему та обробляє їх аналогічно до тимчасового локального сховища.

Ви також використовуєте окрему файлову систему, яка базується на іншому логічному пристрої зберігання. У цій конфігурації каталог, де ви вказуєте kubelet розміщувати шари образів контейнерів та шари з можливістю запису, знаходиться на цій другій файловій системі.

Перша файлова система не містить жодних шарів образів або шарів з можливістью запису.

Ваш вузол може мати стільки інших файлових систем, не використовуваних для Kubernetes, скільки вам потрібно.

Kubelet може вимірювати, скільки локального сховища він використовує. Він робить це, якщо ви налаштували вузол за однією з підтримуваних конфігурацій для локального тимчасового сховища.

Якщо у вас інша конфігурація, то kubelet не застосовує обмеження ресурсів для тимчасового локального сховища.

Налаштування запитів та обмежень для локального тимчасового сховища

Ви можете вказати ephemeral-storage для керування локальним тимчасовим сховищем. Кожен контейнер Podʼа може вказати одне або обидва з наступного:

  • spec.containers[].resources.limits.ephemeral-storage
  • spec.containers[].resources.requests.ephemeral-storage

Обмеження та запити для ephemeral-storage вимірюються в кількості байтів. Ви можете виражати сховище як звичайне ціле число або як число з плаваючою точкою, використовуючи один з наступних суфіксів: E, P, T, G, M, k. Ви також можете використовувати еквіваленти степенів двійки: Ei, Pi, Ti, Gi, Mi, Ki. Наприклад, наступні кількості приблизно представляють одне й те ж значення:

  • 128974848
  • 129e6
  • 129M
  • 123Mi

Звертайте увагу на регістр суфіксів. Якщо ви запитуєте 400m тимчасового сховища, це запит на 0,4 байти. Хтось, хто вводить це, мабуть, мав на меті запросити 400 мебібайтів (400Mi) або 400 мегабайтів (400M).

У наступному прикладі Pod має два контейнери. Кожен контейнер має запит на 2 гігабайти локального тимчасового сховища. Кожен контейнер має обмеження на 4 гігабайти локального тимчасового сховища. Отже, у Podʼа запит на 4 гігабайти локального тимчасового сховища, і обмеження на 8 ГіБ локального тимчасового сховища. З цього обмеження 500 Мі може бути витрачено на тимчасовий том emptyDir.

apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: app
    image: images.my-company.example/app:v4
    resources:
      requests:
        ephemeral-storage: "2Gi"
      limits:
        ephemeral-storage: "4Gi"
    volumeMounts:
    - name: ephemeral
      mountPath: "/tmp"
  - name: log-aggregator
    image: images.my-company.example/log-aggregator:v6
    resources:
      requests:
        ephemeral-storage: "2Gi"
      limits:
        ephemeral-storage: "4Gi"
    volumeMounts:
    - name: ephemeral
      mountPath: "/tmp"
  volumes:
    - name: ephemeral
      emptyDir:
        sizeLimit: 500Mi

Як розміщуються Podʼи з запитами на локальне тимчасове сховище

При створенні Podʼа планувальник Kubernetes вибирає вузол, на якому буде виконуватися Под. Кожен вузол має максимальну кількість локального тимчасового сховища, яке він може надати для Podʼів. Для отримання додаткової інформації дивіться розділ Виділення ресурсів вузла.

Планувальник забезпечує те, щоб сума запитів ресурсів запланованих контейнерів була меншою за потужність вузла.

Керування використанням локального тимчасового сховища

Якщо kubelet керує локальним тимчасовим сховищем як ресурсом, тоді kubelet вимірює використання сховища у таких областях:

  • emptyDir томи, за винятком tmpfs emptyDir томів
  • каталоги, де зберігаються логи на рівні вузла
  • шари контейнера з можливістю запису

Якщо Pod використовує більше тимчасового сховища, ніж дозволяється, kubelet встановлює сигнал виселення, який викликає виселення Podʼа.

Для ізоляції на рівні контейнера, якщо записуваний шар контейнера та використання логу перевищують обмеження щодо сховища, то kubelet позначає Pod для виселення.

Для ізоляції на рівні Podʼа kubelet визначає загальне обмеження сховища для Podʼа, підсумовуючи обмеження для контейнерів у цьому Podʼі. У цьому випадку, якщо сума використання локального тимчасового сховища з усіх контейнерів та emptyDir томів Podʼа перевищує загальне обмеження сховища для Podʼа, то kubelet також позначає Pod для виселення.

kubelet підтримує різні способи вимірювання використання сховища Podʼа:

kubelet виконує регулярні заплановані перевірки, які сканують кожний emptyDir том, каталог логів контейнера та записуваний шар контейнера.

Під час сканування вимірюється обсяг використаного простору.

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.31 [beta]

Квоти проєктів — це функціональність на рівні операційної системи для управління використанням сховища у файлових системах. У Kubernetes ви можете ввімкнути квоти проєктів для моніторингу використання сховища. Переконайтеся, що файлова система, яка підтримує emptyDir томи, на вузлі надає підтримку квот проєктів. Наприклад, XFS та ext4fs пропонують квоти проєктів.

Kubernetes використовує ідентифікатори проєктів, що починаються з 1048576. Використані ідентифікатори зареєстровані в /etc/projects та /etc/projid. Якщо ідентифікатори проєктів у цьому діапазоні використовуються для інших цілей у системі, ці ідентифікатори проєктів повинні бути зареєстровані в /etc/projects та /etc/projid, щоб Kubernetes не використовував їх.

Квоти є швидкими та точними, ніж сканування каталогів. Коли каталог призначений для проєкту, всі файли, створені в каталозі, створюються в цьому проєкті, і ядро просто відстежує, скільки блоків використовується файлами в цьому проєкті. Якщо файл створений і видалений, але має відкритий файловий дескриптор, він продовжує споживати місце. Відстеження квот точно відображає цей простір, тоді як сканування каталогів не враховує місце, використане видаленими файлами.

Щоб використовувати квоти для відстеження використання ресурсів Podʼів, Pod повинен знаходитися в просторі імен користувача. У просторах імен користувачів ядро обмежує зміни ідентифікаторів проєктів у файловій системі, забезпечуючи надійність зберігання метрик, розрахованих за квотами.

Якщо ви хочете використовувати квоти проєктів, вам потрібно:

  • Увімкнути функціональну можливість LocalStorageCapacityIsolationFSQuotaMonitoring=true використовуючи поле featureGates в конфігурації kubelet.

  • Переконайтеся, що функціональну можливість UserNamespacesSupport увімкнено, і що ядро, реалізація CRI та середовище виконання OCI підтримують простори імен користувачів.

  • Переконайтеся, що коренева файлова система (або додаткова файлова система запуску) має увімкнену підтримку квот проєктів. Всі файлові системи XFS підтримують квоти проєктів. Для файлових систем ext4fs вам потрібно увімкнути функцію відстеження квот проєктів допоки файлова система не змонтована.

    # Для ext4, з /dev/block-device, не змонтовано
    sudo tune2fs -O project -Q prjquota /dev/block-device
    
  • Переконайтеся, що коренева файлова система (або додаткова файлова система запуску) змонтована з увімкненими квотами проєктів. Для XFS та ext4fs параметр монтування має назву prjquota.

Якщо ви не хочете використовувати квоти проєкту, вам слід зробити так:

Розширені ресурси

Розширені ресурси — це повністю кваліфіковані імена ресурсів поза доменом kubernetes.io. Вони дозволяють операторам кластера оголошувати, а користувачам використовувати ресурси, які не вбудовані в Kubernetes.

Щоб скористатися Розширеними ресурсами, потрібно виконати два кроки. По-перше, оператор кластера повинен оголошувати Розширений Ресурс. По-друге, користувачі повинні запитувати Розширений Ресурс в Podʼах.

Керування розширеними ресурсами

Ресурси на рівні вузла

Ресурси на рівні вузла повʼязані з вузлами.

Керовані ресурси втулків пристроїв

Дивіться Втулок пристроїв щодо того, як оголошувати ресурси, що керуються втулком пристроїв на кожному вузлі.

Інші ресурси

Щоб оголошувати новий розширений ресурс на рівні вузла, оператор кластера може надіслати HTTP-запит типу PATCH до API-сервера, щоб вказати доступну кількість в полі status.capacity для вузла у кластері. Після цієї операції поле status.capacity вузла буде містити новий ресурс. Поле status.allocatable оновлюється автоматично з новим ресурсом асинхронно за допомогою kubelet.

Оскільки планувальник використовує значення status.allocatable вузла при оцінці придатності Podʼа, планувальник враховує нове значення лише після цього асинхронного оновлення. Між моментом зміни потужності вузла новим ресурсом і часом, коли перший Pod, який запитує ресурс, може бути запланований на цьому вузлі, може відбуватися коротка затримка.

Приклад:

Нижче наведено приклад використання curl для формування HTTP-запиту, який оголошує пʼять ресурсів "example.com/foo" на вузлі k8s-node-1, майстер якого k8s-master.

curl --header "Content-Type: application/json-patch+json" \
--request PATCH \
--data '[{"op": "add", "path": "/status/capacity/example.com~1foo", "value": "5"}]' \
http://k8s-master:8080/api/v1/nodes/k8s-node-1/status

Ресурси на рівні кластера

Ресурси на рівні кластера не повʼязані з вузлами. Зазвичай ними керують розширювачі планувальника, які відповідають за споживання ресурсів і квоту ресурсів.

Ви можете вказати розширені ресурси, які обробляються розширювачами планувальника, в конфігурації планувальника.

Приклад:

Наступна конфігурація для політики планувальника вказує на те, що ресурс на рівні кластера "example.com/foo" обробляється розширювачем планувальника.

  • Планувальник відправляє Pod до розширювача планувальника тільки у випадку, якщо Pod запитує "example.com/foo".
  • Поле ignoredByScheduler вказує, що планувальник не перевіряє ресурс "example.com/foo" в своєму предикаті PodFitsResources.
{
  "kind": "Policy",
  "apiVersion": "v1",
  "extenders": [
    {
      "urlPrefix":"<extender-endpoint>",
      "bindVerb": "bind",
      "managedResources": [
        {
          "name": "example.com/foo",
          "ignoredByScheduler": true
        }
      ]
    }
  ]
}

Використання розширених ресурсів

Користувачі можуть використовувати розширені ресурси у специфікаціях Podʼа, подібно до CPU та памʼяті. Планувальник відповідає за облік ресурсів, щоб одночасно не виділялося більше доступної кількості ресурсів для Podʼів.

Сервер API обмежує кількість розширених ресурсів цілими числами. Приклади дійсних значень: 3, 3000m та 3Ki. Приклади недійсних значень: 0.5 та 1500m (томущо 1500m буде давати в результаті 1.5).

Щоб використовувати розширений ресурс у Podʼі, включіть імʼя ресурсу як ключ у масив spec.containers[].resources.limits у специфікації контейнера.

Pod є запланованим лише у випадку, якщо всі запити ресурсів задовольняються, включаючи CPU, памʼять та будь-які розширені ресурси. Pod залишається у стані PENDING, поки запит ресурсу не може бути задоволений.

Приклад:

Нижче наведено Pod, який запитує 2 CPU та 1 "example.com/foo" (розширений ресурс).

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: myimage
    resources:
      requests:
        cpu: 2
        example.com/foo: 1
      limits:
        example.com/foo: 1

Обмеження PID

Обмеження ідентифікаторів процесів (PID) дозволяють налаштувати kubelet для обмеження кількості PID, яку може використовувати певний Pod. Див. Обмеження PID для отримання інформації.

Усунення несправностей

Мої Podʼи знаходяться в стані очікування з повідомленням події FailedScheduling

Якщо планувальник не може знайти жодного вузла, де може розмістити Pod, Pod залишається незапланованим, поки не буде знайдено місце. Кожного разу, коли планувальник не може знайти місце для Podʼа, створюється подія. Ви можете використовувати kubectl для перегляду подій Podʼа; наприклад:

kubectl describe pod frontend | grep -A 9999999999 Events
Events:
  Type     Reason            Age   From               Message
  ----     ------            ----  ----               -------
  Warning  FailedScheduling  23s   default-scheduler  0/42 nodes available: insufficient cpu

У прикладі Pod під назвою "frontend" не вдалося запланувати через недостатній ресурс CPU на будь-якому вузлі. Схожі повідомлення про помилку також можуть вказувати на невдачу через недостатню памʼять (PodExceedsFreeMemory). Загалом, якщо Pod знаходиться в стані очікування з таким типом повідомлення, є кілька речей, які варто спробувати:

  • Додайте більше вузлів у кластер.
  • Завершіть непотрібні Podʼи, щоб звільнити місце для очікуваних Podʼів.
  • Перевірте, що Pod не є більшим, ніж усі вузли. Наприклад, якщо всі вузли мають місткість cpu: 1, то Pod з запитом cpu: 1.1 ніколи не буде запланованим.
  • Перевірте наявність "taint" вузла. Якщо більшість ваших вузлів мають "taint", і новий Pod не толерує цей "taint", планувальник розглядає розміщення лише на залишкових вузлах, які не мають цього "taint".

Ви можете перевірити місткості вузлів та виділені обсяги ресурсів за допомогою команди kubectl describe nodes. Наприклад:

kubectl describe nodes e2e-test-node-pool-4lw4
Name:            e2e-test-node-pool-4lw4
[ ... lines removed for clarity ...]
Capacity:
 cpu:                               2
 memory:                            7679792Ki
 pods:                              110
Allocatable:
 cpu:                               1800m
 memory:                            7474992Ki
 pods:                              110
[ ... lines removed for clarity ...]
Non-terminated Pods:        (5 in total)
  Namespace    Name                                  CPU Requests  CPU Limits  Memory Requests  Memory Limits
  ---------    ----                                  ------------  ----------  ---------------  -------------
  kube-system  fluentd-gcp-v1.38-28bv1               100m (5%)     0 (0%)      200Mi (2%)       200Mi (2%)
  kube-system  kube-dns-3297075139-61lj3             260m (13%)    0 (0%)      100Mi (1%)       170Mi (2%)
  kube-system  kube-proxy-e2e-test-...               100m (5%)     0 (0%)      0 (0%)           0 (0%)
  kube-system  monitoring-influxdb-grafana-v4-z1m12  200m (10%)    200m (10%)  600Mi (8%)       600Mi (8%)
  kube-system  node-problem-detector-v0.1-fj7m3      20m (1%)      200m (10%)  20Mi

 (0%)        100Mi (1%)
Allocated resources:
  (Total limits may be over 100 percent, i.e., overcommitted.)
  CPU Requests    CPU Limits    Memory Requests    Memory Limits
  ------------    ----------    ---------------    -------------
  680m (34%)      400m (20%)    920Mi (11%)        1070Mi (13%)

У виводі ви можете побачити, що якщо Pod запитує більше 1,120 CPU або більше 6,23 ГБ памʼяті, то цей Pod не поміститься на вузлі.

Дивлячись на розділ "Podʼи", ви можете побачити, які Podʼи займають місце на вузлі.

Обсяг ресурсів, доступних для Podʼів, менший за місткість вузла, оскільки системні служби використовують частину доступних ресурсів. У Kubernetes API, кожен вузол має поле .status.allocatable (див. NodeStatus для деталей).

Поле .status.allocatable описує обсяг ресурсів, доступних для Podʼів на цьому вузлі (наприклад: 15 віртуальних ЦП та 7538 МіБ памʼяті). Для отримання додаткової інформації про виділені ресурси вузла в Kubernetes дивіться Резервування обчислювальних ресурсів для системних служб.

Ви можете налаштувати квоти ресурсів для обмеження загального обсягу ресурсів, який може споживати простір імен. Kubernetes забезпечує дотримання квот для обʼєктів в конкретному просторі імен, коли існує ResourceQuota в цьому просторі імен. Наприклад, якщо ви призначаєте конкретні простори імен різним командам, ви можете додавати ResourceQuotas в ці простори імен. Встановлення квот ресурсів допомагає запобігти використанню однією командою так багато будь-якого ресурсу, що це впливає на інші команди.

Вам також варто розглянути, який доступ ви надаєте в цьому просторі імен: повний дозвіл на запис у простір імен дозволяє тому, хто має такий доступ, видаляти будь-який ресурс, включаючи налаштований ResourceQuota.

Робота мого контейнера завершується примусово

Робота вашого контейнера може бути завершена через нестачу ресурсів. Щоб перевірити, чи контейнер був завершений через досягнення обмеження ресурсів, викличте kubectl describe pod для цікавого вас Podʼа:

kubectl describe pod simmemleak-hra99

Вивід буде схожий на:

Name:                           simmemleak-hra99
Namespace:                      default
Image(s):                       saadali/simmemleak
Node:                           kubernetes-node-tf0f/10.240.216.66
Labels:                         name=simmemleak
Status:                         Running
Reason:
Message:
IP:                             10.244.2.75
Containers:
  simmemleak:
    Image:  saadali/simmemleak:latest
    Limits:
      cpu:          100m
      memory:       50Mi
    State:          Running
      Started:      Tue, 07 Jul 2019 12:54:41 -0700
    Last State:     Terminated
      Reason:       OOMKilled
      Exit Code:    137
      Started:      Fri, 07 Jul 2019 12:54:30 -0700
      Finished:     Fri, 07 Jul 2019 12:54:33 -0700
    Ready:          False
    Restart Count:  5
Conditions:
  Type      Status
  Ready     False
Events:
  Type    Reason     Age   From               Message
  ----    ------     ----  ----               -------
  Normal  Scheduled  42s   default-scheduler  Successfully assigned simmemleak-hra99 to kubernetes-node-tf0f
  Normal  Pulled     41s   kubelet            Container image "saadali/simmemleak:latest" already present on machine
  Normal  Created    41s   kubelet            Created container simmemleak
  Normal  Started    40s   kubelet            Started container simmemleak
  Normal  Killing    32s   kubelet            Killing container with id ead3fb35-5cf5-44ed-9ae1-488115be66c6: Need to kill Pod

У прикладі Restart Count: 5 вказує на те, що контейнер simmemleak у Podʼі був завершений та перезапущений пʼять разів (до цього моменту). Причина OOMKilled показує, що контейнер намагався використовувати більше памʼяті, ніж встановлений йому ліміт.

Наступним кроком може бути перевірка коду програми на витік памʼяті. Якщо ви встановите, що програма працює так, як очікувалося, розгляньте встановлення вищого ліміту памʼяті (і, можливо, запит) для цього контейнера.

Що далі

3.7.5 - Проби життєздатності, готовності та запуску

Kubernetes має різні типи проб:

Проба життєздатності

Проби життєздатності (Liveness) визначають, коли перезапустити контейнер. Наприклад, проби життєздатності можуть виявити тупик, коли додаток працює, але не може виконувати роботу.

Якщо контейнеру не вдається пройти пробу життєздатності, kubelet перезапускає контейнер.

Проби життєздатності не чекають, поки проби готовності будуть успішними. Якщо ви хочете почекати перед виконанням проби життєздатності, ви можете визначити initialDelaySeconds або використовувати пробу запуску.

Проба готовності

Проби готовності (Readiness) визначають, коли контейнер готовий приймати трафік. Це корисно, коли потрібно зачекати, поки застосунок виконає тривалі початкові завдання, такі як встановлення мережевих зʼєднань, завантаження файлів та наповнення кешів.

Якщо проба готовності повертає неуспішний стан, Kubernetes видаляє Pod з усіх відповідних точок доступу сервісу.

Проби готовності виконуються в контейнері протягом всього його життєвого циклу.

Проба запуску

Проба запуску (Startup) перевіряє, чи застосунок у контейнері запущено. Це можна використовувати для виконання перевірок життєздатності на повільних контейнерах, уникнення їхнього примусового завершення kubelet до того, як вони будуть запущені.

Якщо така проба налаштована, вона вимикає перевірки життєздатності та готовності, поки вона не буде успішною.

Цей тип проби виконується лише при запуску, на відміну від проб життєздатності та готовності, які виконуються періодично.

3.7.6 - Організація доступу до кластеру за допомогою файлів kubeconfig

Використовуйте файли kubeconfig для організації інформації про кластери, користувачів, простори імен та механізми автентифікації. kubectl використовує файли kubeconfig, щоб знайти інформацію, необхідну для вибору кластера та звʼязку з сервером API кластера.

Типово kubectl шукає файл з імʼям config у каталозі $HOME/.kube. Ви можете вказати інші файли kubeconfig, встановивши змінну середовища KUBECONFIG або встановивши прапорець --kubeconfig.

Для покрокових інструкцій щодо створення та вказівки файлів kubeconfig див. Налаштування доступу до кількох кластерів.

Підтримка кількох кластерів, користувачів та механізмів автентифікації

Припустимо, у вас є декілька кластерів, і ваші користувачі та компоненти автентифікуються різними способами. Наприклад:

  • Робочий kubelet може автентифікуватися за допомогою сертифікатів.
  • Користувач може автентифікуватися за допомогою токенів.
  • Адміністратори можуть мати набори сертифікатів, які вони надають окремим користувачам.

За допомогою файлів kubeconfig ви можете організувати ваші кластери, користувачів та простори імен. Ви також можете визначити контексти, щоб швидко та легко перемикатися між кластерами та просторами імен.

Контекст

Елемент context в файлі kubeconfig використовується для групування параметрів доступу під зручною назвою. Кожен контекст має три параметри: кластер, простір імен та користувач. Типово, інструмент командного рядка kubectl використовує параметри з поточного контексту для звʼязку з кластером.

Щоб обрати поточний контекст:

kubectl config use-context

Змінна середовища KUBECONFIG

Змінна середовища KUBECONFIG містить список файлів kubeconfig. Для Linux та Mac список розділяється двокрапкою. Для Windows список розділяється крапкою з комою. Змінна середовища KUBECONFIG не є обовʼязковою. Якщо змінна середовища KUBECONFIG не існує, kubectl використовує стандартний файл kubeconfig, $HOME/.kube/config.

Якщо змінна середовища KUBECONFIG існує, kubectl використовує ефективну конфігурацію, яка є результатом обʼєднання файлів, перерахованих у змінній середовища KUBECONFIG.

Обʼєднання файлів kubeconfig

Щоб переглянути вашу конфігурацію, введіть цю команду:

kubectl config view

Як описано раніше, вихідні дані можуть бути з одного файлу kubeconfig або бути результатом обʼєднання кількох файлів kubeconfig.

Ось правила, які використовує kubectl під час обʼєднання файлів kubeconfig:

  1. Якщо встановлено прапорець --kubeconfig, використовуйте лише вказаний файл. Обʼєднання не здійснюється. Дозволяється лише один екземпляр цього прапорця.

    У іншому випадку, якщо встановлена змінна середовища KUBECONFIG, використовуйте її як список файлів, які потрібно обʼєднати. Обʼєднайте файли, перераховані у змінній середовища KUBECONFIG, згідно з наступними правилами:

    • Ігноруйте порожні імена файлів.
    • Виводьте помилки для файлів з вмістом, який не може бути десеріалізований.
    • Перший файл, що встановлює певне значення або ключ зіставлення, має перевагу.
    • Ніколи не змінюйте значення або ключ зіставлення. Наприклад: Зберігайте контекст першого файлу, який встановлює current-context. Наприклад: Якщо два файли вказують на red-user, використовуйте лише значення з red-user першого файлу. Навіть якщо другий файл має несумісні записи під red-user, відкиньте їх.

    Для прикладу встановлення змінної середовища KUBECONFIG дивіться Встановлення змінної середовища KUBECONFIG.

    В іншому випадку використовуйте стандартний файл kubeconfig, $HOME/.kube/config, без обʼєднання.

  2. Визначте контекст, який буде використовуватися на основі першого збігу в цьому ланцюжку:

    1. Використовуйте прапорець командного рядка --context, якщо він існує.
    2. Використовуйте current-context з обʼєднаних файлів kubeconfig.

    Порожній контекст допускається на цьому етапі.

  3. Визначте кластер та користувача. На цьому етапі може бути або не бути контексту. Визначте кластер та користувача на основі першого збігу в цьому ланцюжку, який запускається двічі: один раз для користувача та один раз для кластера:

    1. Використовуйте прапорці командного рядка, якщо вони існують: --user або --cluster.
    2. Якщо контекст не порожній, беріть користувача або кластер з контексту.

    Користувач та кластер можуть бути порожніми на цьому етапі.

  4. Визначте фактичну інформацію про кластер, яку слід використовувати. На цьому етапі може бути або не бути інформації про кластер. Побудуйте кожен елемент інформації про кластер на основі цього ланцюжка; перший збіг перемагає:

    1. Використовуйте прапорці командного рядка, якщо вони існують: --server, --certificate-authority, --insecure-skip-tls-verify.
    2. Якщо існують будь-які атрибути інформації про кластер з обʼєднаних файлів kubeconfig, використовуйте їх.
    3. Якщо немає розташування сервера, відмовтеся.
  5. Визначте фактичну інформацію про користувача, яку слід використовувати. Побудуйте інформацію про користувача, використовуючи ті ж правила, що і для інформації про кластер, за винятком того, що дозволяється лише одна техніка автентифікації для кожного користувача:

    1. Використовуйте прапорці командного рядка, якщо вони існують: --client-certificate, --client-key, --username, --password, --token.
    2. Використовуйте поля user з обʼєднаних файлів kubeconfig.
    3. Якщо є дві суперечливі техніки, відмовтеся.
  6. Для будь-якої інформації, що все ще відсутня, використовуйте стандартні значення і, можливо, запитайте інформацію для автентифікації.

Посилання на файли

Посилання на файли та шляхи в файлі kubeconfig є відносними до місця розташування файлу kubeconfig. Посилання на файли в командному рядку є відносними до поточного робочого каталогу. У файлі $HOME/.kube/config відносні шляхи зберігаються відносно, абсолютні шляхи зберігаються абсолютно.

Проксі

Ви можете налаштувати kubectl використовувати проксі для кожного кластера за допомогою proxy-url у вашому файлі kubeconfig, на зразок такого:

apiVersion: v1
kind: Config

clusters:
- cluster:
    proxy-url: http://proxy.example.org:3128
    server: https://k8s.example.org/k8s/clusters/c-xxyyzz
  name: development

users:
- name: developer

contexts:
- context:
  name: development

Що далі

3.7.7 - Управління ресурсами для вузлів Windows

Ця сторінка надає огляд різниці у способах управління ресурсами між Linux та Windows.

На Linux-вузлах використовуються cgroups як межа Pod для керування ресурсами. Контейнери створюються в межах цих груп для ізоляції мережі, процесів та файлової системи. API cgroup для Linux може використовуватися для збору статистики використання процесора, введення/виведення та памʼяті.

Натомість, у Windows використовує job object на кожен контейнер з фільтром системного простору імен, щоб обмежити всі процеси в контейнері та забезпечити логічну ізоляцію від хосту. (Обʼєкти завдань є механізмом ізоляції процесів Windows і відрізняються від того, що Kubernetes називає завданням).

Не існує можливості запуску контейнера Windows без фільтрації простору імен. Це означає, що системні привілеї не можуть бути встановлені в контексті хосту, і, отже, привілейовані контейнери не доступні в Windows. Контейнери не можуть припускати ідентичність хосту, оскільки менеджер облікових записів безпеки (Security Account Manager, SAM) є окремим.

Управління памʼяттю

Windows не має спеціального процесу припинення процесів з обмеженням памʼяті, як у Linux. Windows завжди трактує всі виділення памʼяті в режимі користувача як віртуальні, і сторінкові файли є обовʼязковими.

Вузли Windows не перевантажують памʼять для процесів. Основний ефект полягає в тому, що Windows не досягне умов нестачі памʼяті так само як Linux, і процеси будуть перенесені на диск замість виявлення випадків нестачі памʼяті (OOM). Якщо памʼять перевантажена, і всю фізичну памʼять вичерпано, то запис на диск може знизити продуктивність.

Управління CPU

Windows може обмежувати кількість часу CPU, виділену для різних процесів, але не може гарантувати мінімальну кількість часу CPU.

На Windows kubelet підтримує прапорець командного рядка для встановлення пріоритету планування процесу kubelet: --windows-priorityclass. Цей прапорець дозволяє процесу kubelet отримувати більше часових сегментів процесора порівняно з іншими процесами, які виконуються на хості Windows. Додаткову інформацію про допустимі значення та їх значення можна знайти за посиланням Класи пріоритетів Windows. Щоб переконатися, що запущені Podʼи не голодують kubelet між циклами CPU, встановіть цей прапорець на значення ABOVE_NORMAL_PRIORITY_CLASS або вище.

Резервування ресурсів

Для обліку памʼяті та процесора, що використовуються операційною системою, контейнерною системою та процесами хосту Kubernetes, можна (і потрібно) резервувати ресурси памʼяті та процесора за допомогою прапорців kubelet --kube-reserved та/або --system-reserved. У Windows ці значення використовуються лише для розрахунку доступних ресурсів вузла.

У Windows доброю практикою є резервування принаймні 2ГБ памʼяті.

Щоб визначити, скільки CPU резервувати, ідентифікуйте максимальну щільність Podʼів для кожного вузла та відстежуйте використання процесора системними службами, що працюють там, а потім виберіть значення, яке відповідає потребам вашої робочого навантаження.

3.8 - Безпека

Концепції для забезпечення безпеки ваших хмарних робочих навантажень.

Цей розділ документації Kubernetes призначений, щоб допомогти вам дізнатись, як запускати робочі навантаження безпечніше, а також про основні аспекти забезпечення безпеки кластера Kubernetes.

Kubernetes базується на архітектурі, орієнтованій на хмару, та використовує поради від CNCF щодо найкращих практик з безпеки інформації в хмарних середовищах.

Для отримання загального контексту щодо того, як забезпечити безпеку вашого кластера та застосунків, які ви на ньому запускаєте, прочитайте Безпека хмарних середовищ та Kubernetes.

Механізми безпеки Kubernetes

Kubernetes включає кілька API та елементів керування безпекою, а також способи визначення політик, які можуть бути частиною вашого управління інформаційною безпекою.

Захист панелі управління

Ключовий механізм безпеки для будь-якого кластера Kubernetes — це контроль доступу до API Kubernetes.

Kubernetes очікує, що ви налаштуєте та використовуватимете TLS для забезпечення шифрування даних під час їх руху у межах панелі управління та між панеллю управління та її клієнтами. Ви також можете активувати шифрування в стані спокою для даних, збережених у панелі управління Kubernetes; це відокремлено від використання шифрування в стані спокою для даних ваших власних робочих навантажень, що також може бути хорошою ідеєю.

Secrets

API Secret надає базовий захист для конфіденційних значень конфігурації.

Захист робочого навантаження

Забезпечуйте дотримання стандартів безпеки Pod, щоб переконатися, що Pod та їх контейнери ізольовані належним чином. Ви також можете використовувати RuntimeClasses, щоб визначити власну ізоляцію, якщо це потрібно.

Мережеві політики дозволяють вам контролювати мережевий трафік між Podʼами, або між Podʼами та мережею поза вашим кластером.

Ви можете розгортати компоненти керування безпекою з ширшої екосистеми для впровадження компонентів для запобігання або виявлення небезпеки навколо Pod, їх контейнерів та образів, що запускаються у них.

Аудит

Audit logging Kubernetes забезпечує безпековий, хронологічний набір записів, що документують послідовність дій в кластері. Кластер перевіряє дії, породжені користувачами, застосунками, які використовують API Kubernetes, та самою панеллю управління.

Безпека хмарних провайдерів

Якщо ви запускаєте кластер Kubernetes на власному обладнанні або в іншого хмарного провайдера, зверніться до вашої документації для ознайомлення з найкращими практиками безпеки. Ось посилання на документацію з безпеки деяких популярних хмарних провайдерів:

Безпека хмарних провайдерів
IaaS провайдерПосилання
Alibaba Cloudhttps://www.alibabacloud.com/trust-center
Amazon Web Serviceshttps://aws.amazon.com/security
Google Cloud Platformhttps://cloud.google.com/security
Huawei Cloudhttps://www.huaweicloud.com/intl/en-us/securecenter/overallsafety
IBM Cloudhttps://www.ibm.com/cloud/security
Microsoft Azurehttps://docs.microsoft.com/en-us/azure/security/azure-security
Oracle Cloud Infrastructurehttps://www.oracle.com/security
VMware vSpherehttps://www.vmware.com/security/hardening-guides

Політики

Ви можете визначати політики безпеки за допомогою механізмів, вбудованих у Kubernetes, таких як NetworkPolicy (декларативний контроль над фільтрацією мережевих пакетів) або ValidatingAdmissionPolicy (декларативні обмеження на те, які зміни може вносити кожен за допомогою API Kubernetes).

Однак ви також можете покладатися на реалізації політик з ширшої екосистеми навколо Kubernetes. Kubernetes надає механізми розширення, щоб ці проєкти екосистеми могли впроваджувати власні елементи керування політиками щодо перегляду вихідного коду, затвердження контейнерних образів, контролю доступу до API, мережевого звʼязку та інших аспектів.

Для отримання додаткової інформації про механізми політики та Kubernetes, читайте Політики.

Що далі

Дізнайтеся про повʼязані теми безпеки Kubernetes:

Дізнайтеся контекст:

Отримайте сертифікацію:

Докладніше в цьому розділі:

3.8.1 - Безпека хмарних середовищ та Kubernetes

Концепції забезпечення безпеки вашого робочого навантаження в хмарному середовищі.

Kubernetes базується на архітектурі, орієнтованій на хмару, та використовує поради від CNCF щодо найкращих практик з безпеки інформації в хмарних середовищах.

Прочитайте далі цю сторінку для отримання огляду того, як Kubernetes призначений допомагати вам розгортати безпечну хмарну платформу.

Інформаційна безпека хмарних середовищ

У документів CNCF white paper про безпеку хмарних середовищ визначаються компоненти та практики безпеки, які відповідають різним фазам життєвого циклу.

Фаза життєвого циклу Розробка

  • Забезпечте цілісність середовищ розробки.
  • Проєктуйте застосунки відповідно до найкращих практик інформаційної безпеки, які відповідають вашому контексту.
  • Враховуйте безпеку кінцевого користувача як частину проєктного рішення.

Для досягнення цього ви можете:

  1. Використовуйте архітектуру, таку як нульова довіра, яка мінімізує сферу атак, навіть для внутрішніх загроз.
  2. Визначте процес перевірки коду, який враховує питання безпеки.
  3. Створіть модель загроз вашої системи або застосунку, яка ідентифікує межі довіри. Використовуйте цю модель, щоб ідентифікувати ризики та допомогти знайти способи їх вирішення.
  4. Включіть розширену безпекову автоматизацію, таку як fuzzing та інжиніринг безпеки хаосу, де це обґрунтовано.

Фаза життєвого циклу Розповсюдження

  • Забезпечте безпеку ланцюга постачання образів контейнерів, які ви виконуєте.
  • Забезпечте безпеку ланцюга постачання кластера та інших компонентів, що виконують ваш застосунок. Прикладом іншого компонента може бути зовнішня база даних, яку ваше хмарне застосування використовує для стійкості.

Для досягнення цього:

  1. Скануйте образи контейнерів та інші артефакти на наявність відомих уразливостей.
  2. Забезпечте, що розповсюдження програмного забезпечення використовує шифрування у русі, з ланцюгом довіри до джерела програмного забезпечення.
  3. Ухвалюйте та дотримуйтесь процесів оновлення залежностей, коли оновлення доступні особливо повʼязані з оголошеннями про безпеку.
  4. Використовуйте механізми перевірки, такі як цифрові сертифікати для гарантій безпеки ланцюга постачання.
  5. Підписуйтесь на стрічки та інші механізми, щоб отримувати сповіщення про безпекові ризики.
  6. Обмежуйте доступ до артефактів. Розміщуйте образи контейнерів у приватному реєстрі, який дозволяє тільки авторизованим клієнтам отримувати образи.

Фаза життєвого циклу Розгортання

Забезпечте відповідні обмеження на те, що можна розгортати, хто може це робити, та куди це може бути розгорнуто. Ви можете застосовувати заходи з фази розповсюдження, такі як перевірка криптографічної ідентичності артефактів образів контейнерів.

При розгортанні Kubernetes ви також створюєте основу для робочого середовища ваших застосунків: кластер Kubernetes (або кілька кластерів). Ця ІТ-інфраструктура повинна забезпечувати гарантії безпеки на найвищому рівні.

Фаза життєвого циклу Виконання

Фаза Виконання включає три критичні області: обчислення, доступ, та зберігання.

Захист під час виконання: доступ

API Kubernetes — це те, що робить ваш кластер робочим. Захист цього API є ключовим для забезпечення ефективної безпеки кластера.

Інші сторінки документації Kubernetes містять більше деталей щодо того, як налаштувати конкретні аспекти контролю доступу. Перелік перевірок безпеки містить набір рекомендованих базових перевірок для вашого кластера.

Поза цим, захист вашого кластера означає впровадження ефективних способів автентифікації та авторизації для доступу до API. Використовуйте ServiceAccounts, щоб забезпечити та керувати перевірками безпеки для робочих навантажень та компонентів кластера.

Kubernetes використовує TLS для захисту трафіку API; переконайтеся, що кластер розгорнуто за допомогою TLS (включаючи трафік між вузлами та панеллю управління), та захистіть ключі шифрування. Якщо ви використовуєте власний API Kubernetes для CertificateSigningRequests, приділіть особливу увагу обмеженню зловживань там.

Захист під час виконання: обчислення

Контейнери надають дві речі: ізоляцію між різними застосунками та механізм для комбінування цих ізольованих застосунків для запуску на одному і тому ж хост-компʼютері. Ці два аспекти, ізоляція та агрегація, означають, що безпека виконання включає компроміси та пошук відповідного балансу.

Kubernetes покладається на програмне забезпечення виконання контейнерів, щоб фактично налаштувати та запустити контейнери. Проєкт Kubernetes не рекомендує конкретне програмне забезпечення виконання контейнерів, і вам слід переконатися, що вибране вами середовище виконання контейнерів відповідає вашим потребам у сфері інформаційної безпеки.

Для захисту обчислень під час виконання ви можете:

  1. Застосовувати стандарти безпеки для Pod для застосунків, щоб забезпечити їх запуск лише з необхідними привілеями.

  2. Запускати спеціалізовану операційну систему на ваших вузлах, яка призначена конкретно для виконання контейнеризованих робочих навантажень. Зазвичай це базується на операційній системі з доступом тільки для читання (незмінні образи), яка надає тільки послуги, необхідні для виконання контейнерів.

    Операційні системи, спеціально призначені для контейнерів, допомагають ізолювати компоненти системи та представляють зменшену осяг елементів для атаки в разі "втечі" з контейнера.

  3. Визначати ResourceQuotas для справедливого розподілу спільних ресурсів та використовувати механізми, такі як LimitRanges для забезпечення того, що Podʼи вказують свої вимоги до ресурсів.

  4. Розподіляти робочі навантаження по різних вузлах. Використовуйте механізми ізоляції вузлів, як від самого Kubernetes, так і від екосистеми, щоб гарантувати, що Pod з різними контекстами довіри виконуються на окремих наборах вузлів.

  5. Використовуйте програмне забезпечення виконання контейнерів, яке надає обмеження для підтримання безпеки.

  6. На вузлах Linux використовуйте модуль безпеки Linux, такий як AppArmor або seccomp.

Захист під час виконання: зберігання

Для захисту сховища для вашого кластера та застосунків, що працюють там:

  1. Інтегруйте свій кластер з зовнішнім втулком сховища, який надає шифрування в стані спокою для томів.
  2. Увімкніть шифрування в стані спокою для обʼєктів API.
  3. Захистіть стійкість даних за допомогою резервних копій. Перевірте, що ви можете відновити їх, коли це необхідно.
  4. Автентифікуйте зʼєднання між вузлами кластера та будь-яким мережевим сховищем, на яке вони спираються.
  5. Впровадить шифрування даних у межах вашого власного застосунку.

Для ключів шифрування, їх генерація у спеціалізованому обладнанні забезпечує найкращий захист від ризиків розголошення. Апаратний модуль безпеки може дозволити виконувати криптографічні операції без можливості копіювання ключа безпеки в інше місце.

Мережа та безпека

Ви також повинні врахувати заходи мережевої безпеки, такі як NetworkPolicy або сервісна мережа. Деякі мережеві втулки для Kubernetes надають шифрування для вашої мережі кластера, використовуючи технології, такі як прошарок віртуальної приватної мережі (VPN). За концепцією, Kubernetes дозволяє використовувати власний мережевий втулок для вашого кластера (якщо ви використовуєте керований Kubernetes, особа або організація, яка керує вашим кластером, може вибрати мережевий втулок за вас).

Мережевий втулок, який ви виберете, та спосіб його інтеграції можуть сильно вплинути на безпеку інформації під час її передачі.

Спостережність та безпека виконання

Kubernetes дозволяє розширювати ваш кластер додатковими інструментами. Ви можете налаштувати сторонні рішення, щоб допомогти вам моніторити або усувати несправності ваших застосунків та кластерів, на яких вони працюють. Ви також отримуєте деякі базові можливості спостережуваності, вбудовані в сам Kubernetes. Ваш код, що працює в контейнерах, може генерувати логи, публікувати метрики або надавати інші дані спостережуваності; при розгортанні вам потрібно переконатися, що ваш кластер забезпечує відповідний рівень захисту там.

Якщо ви налаштовуєте інформаційну панель метрик (дашбоард) або щось схоже, перегляньте ланцюжок компонентів, які передають дані в цю панель метрик, а також саму панель метрик. Переконайтеся, що весь ланцюжок розроблено з достатньою стійкістю та достатнім захистом цілісності, щоб ви могли покластися на нього навіть під час інциденту, коли ваш кластер може деградувати.

У відповідних випадках розгорніть заходи безпеки нижче рівня самого Kubernetes, такі як криптографічно захищений початок роботи або автентифікований розподіл часу (що допомагає забезпечити відповідність логів та записів аудиту).

Для середовища з високим рівнем безпеки розгорніть криптографічний захист, щоб переконатися, що логи є як захищеними від несанкціонованого доступу, так і конфіденційними.

Що далі

Безпека хмарного середовища

Kubernetes та інформаційна безпека

3.8.2 - Стандарти безпеки для Podʼів

Детальний огляд різних рівнів політики, визначених у стандартах безпеки для Podʼів.

Стандарти безпеки для Podʼів визначають три різні політики, щоб покрити широкий спектр безпеки. Ці політики є кумулятивними та охоплюють широкий діапазон від все дозволено до все обмежено. У цьому керівництві наведено вимоги кожної політики.

ПрофільОпис
PrivilegedНеобмежена політика, яка забезпечує найширший можливий рівень дозволів. Ця політика дозволяє відомі підвищення привілеїв.
BaselineМінімально обмежена політика, яка запобігає відомим підвищенням привілеїв. Дозволяє стандартну (мінімально визначену) конфігурацію Pod.
RestrictedДуже обмежена політика, яка відповідає поточним найкращим практикам забезпечення безпеки Pod.

Деталі профілю

Privileged

Політика Privileged спеціально є відкритою і цілковито необмеженою. Цей тип політики зазвичай спрямований на робочі навантаження рівня системи та інфраструктури, які керуються привілейованими, довіреними користувачами.

Політика Privileged визначається відсутністю обмежень. Якщо ви визначаєте Pod, до якого застосовується політика безпеки Privileged, визначений вами Pod може обходити типові механізми ізоляції контейнерів. Наприклад, ви можете визначити Pod, який має доступ до мережі хоста вузла.

Baseline

Політика Baseline спрямована на полегшення впровадження загальних контейнеризованих робочих навантажень та запобіганням відомим ескалаціям привілеїв. Ця політика призначена для операторів застосунків та розробників не критичних застосунків. Наведені нижче параметри мають бути виконані/заборонені:

Специфікація політики "Baseline"
ЕлементПолітика
HostProcess

Для Podʼів Windows надається можливість запуску HostProcess контейнерів, що дозволяє привілейований доступ до машини хосту Windows. Привілеї на вузлs заборонені політикою baseline.

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.26 [stable]

Заборонені поля

  • spec.securityContext.windowsOptions.hostProcess
  • spec.containers[*].securityContext.windowsOptions.hostProcess
  • spec.initContainers[*].securityContext.windowsOptions.hostProcess
  • spec.ephemeralContainers[*].securityContext.windowsOptions.hostProcess

Дозволені значення

  • Undefined/nil
  • false
Host Namespaces

Доступ до просторів імен вузла має бути заборонений.

Заборонені поля

  • spec.hostNetwork
  • spec.hostPID
  • spec.hostIPC

Дозволені значення

  • Undefined/nil
  • false
Привілейовані контейнери

Привілейовані Podʼи відключають більшість механізмів безпеки і повинні бути відключені.

Заборонені поля

  • spec.containers[*].securityContext.privileged
  • spec.initContainers[*].securityContext.privileged
  • spec.ephemeralContainers[*].securityContext.privileged

Дозволені значення

  • Undefined/nil
  • false
Capabilities

Додавання додаткових можливостей, крім перерахованих нижче, має бути заборонене.

Заборонені поля

  • spec.containers[*].securityContext.capabilities.add
  • spec.initContainers[*].securityContext.capabilities.add
  • spec.ephemeralContainers[*].securityContext.capabilities.add

Дозволені значення

  • Undefined/nil
  • AUDIT_WRITE
  • CHOWN
  • DAC_OVERRIDE
  • FOWNER
  • FSETID
  • KILL
  • MKNOD
  • NET_BIND_SERVICE
  • SETFCAP
  • SETGID
  • SETPCAP
  • SETUID
  • SYS_CHROOT
Томи HostPath

Томи HostPath мають бути заборонені.

Заборонені поля

  • spec.volumes[*].hostPath

Дозволені значення

  • Undefined/nil
Порти хосту

HostPort повинні бути заборонені повністю (рекомендовано) або обмежені до відомого списку

Заборонені поля

  • spec.containers[*].ports[*].hostPort
  • spec.initContainers[*].ports[*].hostPort
  • spec.ephemeralContainers[*].ports[*].hostPort

Дозволені значення

AppArmor

На підтримуваних вузлах стандартно застосовується профіль AppArmor RuntimeDefault. Політика Baseline має заборонити зміну або вимкнення профілю AppArmor стандартно, або обмежити заміни дозволеним набором профілів.

Заборонені поля

  • spec.securityContext.appArmorProfile.type
  • spec.containers[*].securityContext.appArmorProfile.type
  • spec.initContainers[*].securityContext.appArmorProfile.type
  • spec.ephemeralContainers[*].securityContext.appArmorProfile.type

Дозволені значення

  • Undefined/nil
  • RuntimeDefault
  • Localhost

  • metadata.annotations["container.apparmor.security.beta.kubernetes.io/*"]

Дозволені значення

  • Undefined/nil
  • runtime/default
  • localhost/*
SELinux

Встановлення типу SELinux обмежено, а встановлення користувацького SELinux або ролі заборонено.

Заборонені поля

  • spec.securityContext.seLinuxOptions.type
  • spec.containers[*].securityContext.seLinuxOptions.type
  • spec.initContainers[*].securityContext.seLinuxOptions.type
  • spec.ephemeralContainers[*].securityContext.seLinuxOptions.type

Дозволені значення

  • Визначено/""
  • container_t
  • container_init_t
  • container_kvm_t
  • container_engine_t (з Kubernetes 1.31)

Заборонені поля

  • spec.securityContext.seLinuxOptions.user
  • spec.containers[*].securityContext.seLinuxOptions.user
  • spec.initContainers[*].securityContext.seLinuxOptions.user
  • spec.ephemeralContainers[*].securityContext.seLinuxOptions.user
  • spec.securityContext.seLinuxOptions.role
  • spec.containers[*].securityContext.seLinuxOptions.role
  • spec.initContainers[*].securityContext.seLinuxOptions.role
  • spec.ephemeralContainers[*].securityContext.seLinuxOptions.role

Дозволені значення

  • Визначено/""
/proc Тип монтування

Типові маски /proc налаштовані для зменшення поверхні атаки і мають бути обовʼязковими.

Заборонені поля

  • spec.containers[*].securityContext.procMount
  • spec.initContainers[*].securityContext.procMount
  • spec.ephemeralContainers[*].securityContext.procMount

Дозволені значення

  • Undefined/nil
  • Default
Seccomp

Профіль Seccomp не повинен явно встановлюватися на значення Unconfined.

Заборонені поля

  • spec.securityContext.seccompProfile.type
  • spec.containers[*].securityContext.seccompProfile.type
  • spec.initContainers[*].securityContext.seccompProfile.type
  • spec.ephemeralContainers[*].securityContext.seccompProfile.type

Дозволені значення

  • Undefined/nil
  • RuntimeDefault
  • Localhost
Sysctls

Sysctls можуть вимкнути механізми безпеки або вплинути на всі контейнери на вузлі, тому вони мають бути заборонені за виключенням дозволеного "безпечного" піднабору. Sysctl вважається безпечним, якщо він знаходиться в просторі імен в контейнері чи Podʼі, і він ізольований від інших Podʼів або процесів на тому ж Вузлі.

Заборонені поля

  • spec.securityContext.sysctls[*].name

Дозволені значення

  • Undefined/nil
  • kernel.shm_rmid_forced
  • net.ipv4.ip_local_port_range
  • net.ipv4.ip_unprivileged_port_start
  • net.ipv4.tcp_syncookies
  • net.ipv4.ping_group_range
  • net.ipv4.ip_local_reserved_ports (з Kubernetes 1.27)
  • net.ipv4.tcp_keepalive_time (з Kubernetes 1.29)
  • net.ipv4.tcp_fin_timeout (з Kubernetes 1.29)
  • net.ipv4.tcp_keepalive_intvl (з Kubernetes 1.29)
  • net.ipv4.tcp_keepalive_probes (з Kubernetes 1.29)

Restricted

Політика Restricted призначена для забезпечення поточних кращих практик у забезпеченні безпеки Pod, за рахунок деякої сумісності. Вона спрямована на операторів та розробників критичних з точки зору безпеки застосунків, а також на користувачів з меншою довірою. Нижче наведено перелік контролів, які слід дотримуватися/забороняти:

Специфікація політики "Restricted"
ЕлементПолітика
Все з політики Baseline.
Типи томів

В політиці Restricted дозволяються лише наступні типи томів.

Заборонені поля

  • spec.volumes[*]

Дозволені значення

Кожен елемент списку spec.volumes[*] повинен встановлювати одне з наступних полів на ненульове значення:
  • spec.volumes[*].configMap
  • spec.volumes[*].csi
  • spec.volumes[*].downwardAPI
  • spec.volumes[*].emptyDir
  • spec.volumes[*].ephemeral
  • spec.volumes[*].persistentVolumeClaim
  • spec.volumes[*].projected
  • spec.volumes[*].secret
Підвищення привілеїв (v1.8+)

Підвищення привілеїв (наприклад, через файловий режим set-user-ID або set-group-ID) не повинно бути дозволено. Це політика лише для Linux у v1.25+ (spec.os.name != windows)

Заборонені поля

  • spec.containers[*].securityContext.allowPrivilegeEscalation
  • spec.initContainers[*].securityContext.allowPrivilegeEscalation
  • spec.ephemeralContainers[*].securityContext.allowPrivilegeEscalation

Дозволені значення

  • false
Запуск як не-root

Контейнери мають запускатися як не-root користувачі.

Заборонені поля

  • spec.securityContext.runAsNonRoot
  • spec.containers[*].securityContext.runAsNonRoot
  • spec.initContainers[*].securityContext.runAsNonRoot
  • spec.ephemeralContainers[*].securityContext.runAsNonRoot

Дозволені значення

  • true
Поля контейнера можуть бути undefined/nil, якщо рівень контейнера на рівні підпроцесу spec.securityContext.runAsNonRoot встановлено на true.
Запуск як не-root (v1.23+)

Контейнери не повинні встановлювати runAsUser на 0

Заборонені поля

  • spec.securityContext.runAsUser
  • spec.containers[*].securityContext.runAsUser
  • spec.initContainers[*].securityContext.runAsUser
  • spec.ephemeralContainers[*].securityContext.runAsUser

Дозволені значення

  • будь-яке ненульове значення
  • undefined/null
Seccomp (v1.19+)

Профіль Seccomp повинен бути явно встановлений на одне з дозволених значень. Обидва, Unconfined, так и відсутність профілю заборонені. Це політика лише для Linux у v1.25+ (spec.os.name != windows)

Заборонені поля

  • spec.securityContext.seccompProfile.type
  • spec.containers[*].securityContext.seccompProfile.type
  • spec.initContainers[*].securityContext.seccompProfile.type
  • spec.ephemeralContainers[*].securityContext.seccompProfile.type

Дозволені значення

  • RuntimeDefault
  • Localhost
Поля контейнера можуть бути undefined/nil, якщо на рівні підпроцесу spec.securityContext.seccompProfile.type встановлено відповідне значення. Навпаки, поле на рівні підпроцесу може бути undefined/nil, якщо _всі_ поля рівня контейнера встановлені.
Capabilities (v1.22+)

Контейнери повинні скидати ALL, і дозволяється лише додавання можливості NET_BIND_SERVICE. Це політика лише для Linux у v1.25+ (.spec.os.name != "windows")

Заборонені поля

  • spec.containers[*].securityContext.capabilities.drop
  • spec.initContainers[*].securityContext.capabilities.drop
  • spec.ephemeralContainers[*].securityContext.capabilities.drop

Дозволені значення

  • Будь-який список можливостей, який включає ALL

Заборонені поля

  • spec.containers[*].securityContext.capabilities.add
  • spec.initContainers[*].securityContext.capabilities.add
  • spec.ephemeralContainers[*].securityContext.capabilities.add

Дозволені значення

  • Undefined/nil
  • NET_BIND_SERVICE

Інстанціювання політики

Відокремлення визначення політики від її інстанціювання дозволяє отримати спільне розуміння та послідовне використання політик у кластерах, незалежно від механізму їх виконання.

Після того як механізми стануть більш зрілими, вони будуть визначені нижче на основі кожної політики. Методи виконання окремих політик тут не визначені.

Контролер Pod Security Admission

Альтернативи

Інші альтернативи для виконання політик розробляються в екосистемі Kubernetes, такі як:

Поле ОС Podʼа

У Kubernetes ви можете використовувати вузли, які працюють на операційних системах Linux або Windows. Ви можете комбінувати обидва типи вузлів в одному кластері. Windows в Kubernetes має деякі обмеження та відмінності від навантаженнь на базі Linux. Зокрема, багато з полів securityContext для контейнерів Pod не мають ефекту у Windows.

Зміни в стандарті обмеження безпеки Pod

Ще одна важлива зміна, внесена в Kubernetes v1.25, полягає в тому, що Restricted політики були оновлені для використання поля pod.spec.os.name. Залежно від назви ОС, деякі політики, які специфічні для певної ОС, можуть бути послаблені для іншої ОС.

Елементи політики, специфічні для ОС

Обмеження для наступних елементів є обовʼязковими лише в разі, якщо .spec.os.name не є windows:

  • Підвищення привілеїв
  • Seccomp
  • Linux Capabilities

Простори імен користувачів

Простори імен користувачів — це функція лише для операційних систем Linux, яка дозволяє запускати завдання з підвищеним рівнем ізоляції. Як вони працюють разом зі стандартами безпеки Pod описано в документації Podʼів, що використовують простори імен користувачів.

ЧаПи

Чому відсутній профіль між Privileged та Baseline?

Три профілі, що визначені тут, мають чітку лінійну прогресію від найбільш безпечного (Restricted) до найменш безпечного (Privileged) і охоплюють широкий набір завдань. Привілеї, необхідні вище baseline, зазвичай є дуже специфічними для застосунку, тому ми не пропонуємо стандартний профіль у цій області. Це не означає, що профіль privileged завжди має використовуватися в цьому випадку, але політику в цій області потрібно визначати індивідуально для кожного випадку.

SIG Auth може переосмислити цю позицію у майбутньому, якщо зʼявиться чітка потреба у інших профілях.

В чому різниця між профілем безпеки та контекстом безпеки?

Контексти безпеки налаштовують Podʼи та контейнери під час виконання. Контексти безпеки визначаються як частина специфікації Podʼа та контейнера в маніфесті Podʼа і представляють параметри для контейнерного середовища виконання.

Профілі безпеки — це механізми керування панелі управління для забезпечення певних налаштувань у контексті безпеки, а також інших повʼязаних параметрів поза контекстом безпеки. На даний момент, з липня 2021 року, Політики безпеки Podʼів є застарілими на користь вбудованого Контролера Pod Security Admission.

Що на рахунок Podʼів у пісочниці?

Наразі не існує стандартного API, що контролює, чи знаходиться Pod у пісочниці, чи ні. Podʼи у пісочниці можуть бути ідентифіковані за допомогою використання середовища виконання пісочниці (такого як gVisor або Kata Containers), але немає стандартного визначення того, що таке середовище виконання пісочниці.

Захист, необхідний для робочих навантажень у пісочниці, може відрізнятися від інших. Наприклад, необхідність обмежити привілейовані дозволи менше, коли робоче навантаження ізольоване від базового ядра. Це дозволяє робочим навантаженням, що потребують підвищених дозволів, залишатися ізольованими.

Крім того, захист робочих навантажень у пісочниці сильнго залежить від методу розташування у пісочниці. Таким чином, для всіх робочих навантажень у пісочниці не надається один рекомендований профіль.

3.8.3 - Pod Security Admission

Огляд контролера Pod Security Admission, який може застосовувати Стандарти Безпеки Podʼів.
СТАН ФУНКЦІОНАЛУ: Kubernetes v1.25 [stable]

Стандарти безпеки Podʼів Kubernetes визначають різні рівні ізоляції для Podʼів. Ці стандарти дозволяють визначити, як ви хочете обмежувати поведінку Podʼів в чіткий, послідовний спосіб.

У Kubernetes є вбудований контролер допуску безпеки Pod, щоб застосовувати Стандарти Безпеки Podʼів. Обмеження безпеки Podʼів застосовуються на рівні просторі імен під час створення Podʼів.

Вбудоване забезпечення Pod Security admission

Ця сторінка є частиною документації Kubernetes v1.31. Якщо ви використовуєте іншу версію Kubernetes, перегляньте документацію для цієї версії.

Рівні безпеки Podʼів

Забезпечення Pod Security admission ставить вимоги до Контексту Безпеки Podʼа та інших повʼязаних полів відповідно до трьох рівнів, визначених Стандартами безпеки Podʼів: privileged (привілейований), baseline (базовий) та restricted (обмежений). Для докладного огляду цих вимог дивіться сторінку Стандартів безпеки Podʼів.

Мітки Pod Security Admission для просторів імен

Після активації функції або встановлення вебхука ви можете налаштувати простори імен, щоб визначити режим контролю допуску, який ви хочете використовувати для безпеки Podʼа в кожному просторі імен. Kubernetes визначає набір міток, які можна встановити, щоб визначити, який з попередньо визначених рівнів стандартів безпеки Podʼів ви хочете використовувати для простору імен. Вибрана вами мітка визначає дію, яку панель управління виконує, якщо виявлено потенційне порушення:

Режими входу для безпеки Podʼа
РежимОпис
enforceПорушення політики призведе до відмови обслуговування Podʼа.
auditПорушення політики спричинить додавання аудит-анотації до події, записаної в аудит-лог, але в іншому випадку буде дозволено.
warnПорушення політики спричинить попередження для користувача, але в іншому випадку буде дозволено.

Простір імен може налаштувати будь-який або всі режими, або навіть встановити різний рівень для різних режимів.

Для кожного режиму існують дві позначки, які визначають використовувану політику:

# Мітка рівня режиму вказує, який рівень політики застосовується для режиму.
#
# РЕЖИМ повинен бути одним з `enforce`, `audit` або `warn`.
# РІВЕНЬ повинен бути одним з `privileged`, `baseline` або `restricted`.
pod-security.kubernetes.io/<РЕЖИМ>: <РІВЕНЬ>

# Опціонально: позначка версії режиму, яку можна використовувати для привʼязки політики до
# версії, що поставляється з певною мінорною версією Kubernetes (наприклад, v1.31).
#
# РЕЖИМ повинен бути одним з `enforce`, `audit` або `warn`.
# ВЕРСІЯ повинна бути дійсною мінорною версією Kubernetes або `latest`.
pod-security.kubernetes.io/<РЕЖИМ>-version: <ВЕРСІЯ>

Перегляньте Застосування стандартів безпеки Podʼів з використанням міток просторів імен, щоб побачити приклад використання.

Ресурси робочого навантаження та шаблони Podʼа

Podʼи часто створюються не безпосередньо, а шляхом створення обʼєкта робочого навантаження, такого як Deployment або Job. Обʼєкт робочого навантаження визначає шаблон Podʼа та контролер для ресурсу робочого навантаження, який створює Podʼи на основі цього шаблону. Щоб вчасно виявляти порушення, обидва режими аудиту та попередження застосовуються до ресурсів робочого навантаження. Проте режим виконання не застосовується до ресурсів робочого навантаження, а лише до отриманих обʼєктів Podʼа.

Виключення

Ви можете визначити Виключення з виконання політики безпеки Podʼа, щоб дозволити створення Podʼів, які інакше були б заборонені через політику, повʼязану з певним простором імен.

Виключення можна статично налаштувати в конфігурації контролера допуску.

Виключення повинні бути явно перераховані. Запити, які відповідають критеріям винятків, ігноруються контролером допуску (всі поведінки enforce, audit та warn пропускаються). Винятків включають:

Оновлення наступних полів Podʼа виключаються з перевірки політики, що означає, що якщо запит на оновлення Podʼа змінює лише ці поля, його не буде відхилено, навіть якщо Pod порушує поточний рівень політики:

  • Будь-які оновлення метаданих виключають зміну анотацій seccomp або AppArmor:
    • seccomp.security.alpha.kubernetes.io/pod (застарілий)
    • container.seccomp.security.alpha.kubernetes.io/* (застарілий)
    • container.apparmor.security.beta.kubernetes.io/* (застарілий)
  • Дійсні оновлення .spec.activeDeadlineSeconds
  • Дійсні оновлення .spec.tolerations

Метрики

Ось метрики Prometheus, які надаються kube-apiserver:

  • pod_security_errors_total: Ця метрика показує кількість помилок, які перешкоджають нормальній оцінці. Нефатальні помилки можуть призвести до використання останнього обмеженого профілю для виконання.
  • pod_security_evaluations_total: Ця метрика показує кількість оцінок політики, що відбулися, не враховуючи ігнорованих або запитів винятків під час експортування.
  • pod_security_exemptions_total: Ця метрика показує кількість запитів винятків, не враховуючи ігноровані або запити, що не входять в область застосування.

Що далі

Якщо ви використовуєте старішу версію Kubernetes і хочете оновитися до версії Kubernetes, яка не містить політик безпеки Podʼа, прочитайте перехід від PodSecurityPolicy до вбудованого контролера допуску для безпеки Podʼа.

3.8.4 - Облікові записи служб

Дізнайтеся про обʼєкти ServiceAccount в Kubernetes.

Ця сторінка розповідає про обʼєкт ServiceAccount в Kubernetes, надаючи інформацію про те, як працюють облікові записи служб, використання, обмеження, альтернативи та посилання на ресурси для додаткової допомоги.

Що таке облікові записи служб?

Обліковий запис служби — це тип облікового запису, що використовується компонентами системи (не людьми), який в Kubernetes забезпечує окремий ідентифікатор у кластері Kubernetes. Podʼи застосунків, системні компоненти та сутності всередині та поза кластером можуть використовувати облікові дані конкретного ServiceAccount, щоб ідентифікуватися як цей ServiceAccount. Це корисно в різних ситуаціях, включаючи автентифікацію в API-сервері або впровадження політик безпеки на основі ідентичності.

Облікові записи служб існують як обʼєкти ServiceAccount в API-сервері. Облікові записи служб мають наступні властивості:

  • Привʼязані до простору імен: Кожен обліковий запис служби привʼязаний до namespace Kubernetes. Кожен простір імен отримує default ServiceAccount при створенні.

  • Легкі: Облікові записи служб існують в кластері та визначені в API Kubernetes. Ви можете швидко створювати облікові записи служб для увімкнення певних завдань.

  • Переносні: Набір конфігурацій для складного контейнеризованого завдання може включати визначення облікових записів служб для системних компонентів. Легкість облікових записів служб та ідентичності в межах простору імен роблять конфігурації переносними.

Облікові записи служб відрізняються від облікових записів користувачів, які є автентифікованими користувачами-людьми у кластері. Типово облікові записи користувачів не існують в API-сервері Kubernetes; замість цього сервер API розглядає ідентичності користувачів як непрозорі дані. Ви можете автентифікуватися як обліковий запис користувача за допомогою кількох методів. Деякі дистрибутиви Kubernetes можуть додавати власні розширені API для представлення облікових записів користувачів в API-сервері.

Порівняння між обліковими записами служб та користувачами
ОписServiceAccountКористувач або група
МісцезнаходженняKubernetes API (обʼєкт ServiceAccount)Зовнішній
Контроль доступуКерування доступом за допомогою RBAC Kubernetes або іншими механізмами авторизаціїКерування доступом за допомогою RBAC Kubernetes або іншими механізмами управління ідентичністю та доступом
Призначене використанняРобочі завдання, автоматизаціяЛюди

Стандартні облікові записи служб

При створенні кластера Kubernetes автоматично створює обʼєкт ServiceAccount з імʼям default для кожного простору імен у вашому кластері. Стандартні облікові записи служб у кожному просторі імен типово не мають прав, окрім стандартних дозволів на знаходження API, які Kubernetes надає всім автентифікованим субʼєктам, якщо увімкнено контроль доступу на основі ролей (RBAC). Якщо ви видаляєте обʼєкт ServiceAccount з імʼям default в просторі імен, панель управління замінює його новим.

Якщо ви розгортаєте Pod у просторі імен, і ви не вручну призначаєте ServiceAccount для Podʼа, Kubernetes призначає ServiceAccount default для цього простору імен Podʼа.

Використання сервісних облікових записів Kubernetes

Загалом, ви можете використовувати сервісні облікові записи для надання ідентичності в таких сценаріях:

  • Вашим Podʼам потрібно спілкуватися з сервером API Kubernetes, наприклад у таких ситуаціях:
    • Надання доступу лише для читання конфіденційної інформації, збереженої у Secret.
    • Надання доступу між просторами імен, наприклад дозволу на читання, перелік та перегляд обʼєктів Lease в просторі імен example в просторі імен kube-node-lease.
  • Вашим Podʼам потрібно спілкуватися з зовнішнім сервісом. Наприклад, Podʼа робочого навантаження потрібна ідентичність для комерційного хмарного API, а комерційний постачальник дозволяє налаштувати відповідні довірчі стосунки.
  • Автентифікація в приватному реєстрі образів за допомогою imagePullSecret.
  • Зовнішньому сервісу потрібно спілкуватися з сервером API Kubernetes. Наприклад, автентифікація у кластері як частина конвеєра CI/CD.
  • Ви використовуєте стороннє програмне забезпечення безпеки у своєму кластері, яке покладається на ідентичність сервісного облікового запису різних Podʼів, щоб згрупувати ці Podʼи у різні контексти.

Як використовувати сервісні облікові записи

Щоб скористатися сервісним обліковим записом Kubernetes, виконайте наступне:

  1. Створіть обʼєкт ServiceAccount за допомогою клієнта Kubernetes, такого як kubectl, або за допомогою маніфесту, який визначає обʼєкт.

  2. Надайте дозволи обʼєкту ServiceAccount за допомогою механізму авторизації, такого як RBAC.

  3. Призначте обʼєкт ServiceAccount Podʼам під час створення Podʼа.

    Якщо ви використовуєте ідентифікацію з зовнішнього сервісу, отримайте токен ServiceAccount та використовуйте його з цього сервісу.

Щоб дізнатися, як це зробити, перегляньте Налаштування сервісних облікових записів для Podʼів.

Надання дозволів обліковому запису ServiceAccount

Ви можете використовувати вбудований механізм керування доступом на основі ролей (RBAC) Kubernetes, щоб надати мінімальні дозволи, необхідні кожному сервісному обліковому запису. Ви створюєте роль, яка надає доступ, а потім привʼязуєте роль до вашого ServiceAccount. RBAC дозволяє визначити мінімальний набір дозволів, щоб дозволи облікового запису слідували принципу найменших прав. Podʼи, які використовують цей сервісний обліковий запис, не отримують більше дозволів, ніж необхідно для правильної роботи.

Для інструкцій дивіться Дозволи ServiceAccount.

Крос-простірний доступ за допомогою облікового запису ServiceAccount

Ви можете використовувати RBAC, щоб дозволити сервісним обліковим записам в одному просторі імен виконувати дії з ресурсами в іншому просторі імен в кластері. Наприклад, розгляньте ситуацію, коли у вас є обліковий запис служби та Pod у просторі імен dev, і ви хочете, щоб ваш Pod бачив Job, які виконуються в просторі імен maintenance. Ви можете створити обʼєкт Role, який надає дозволи на перелік обʼєктів Job. Потім створіть обʼєкт RoleBinding у просторі імен maintenance, щоб привʼязати Role до ServiceAccount. Тепер Podʼи у просторі імен dev можуть бачити перелік обʼєктів Job у просторі імен maintenance, використовуючи цей сервісний обліковий запис.

Додавання ServiceAccount для Pod

Щоб додати ServiceAccount для Pod, ви встановлюєте поле spec.serviceAccountName у специфікації Pod. Kubernetes автоматично надає облікові дані для цього ServiceAccount для Pod. У версії v1.22 і пізніше Kubernetes отримує короткостроковий, автоматично змінюваний токен за допомогою API TokenRequest та монтує його як том projected.

Типово Kubernetes надає Podʼу облікові дані для призначеного ServiceAccount, хай то default ServiceAccount або спеціальний ServiceAccount, який ви вказуєте.

Щоб запобігти автоматичному впровадженню Kubernetes облікових даних для вказаного ServiceAccount або default ServiceAccount, встановіть поле automountServiceAccountToken у вашій специфікації Pod в значення false.

У версіях раніше 1.22 Kubernetes надає Pod довгостроковий статичний токен як Secret.

Отримання облікових даних ServiceAccount вручну

Якщо вам потрібні облікові дані для ServiceAccount, щоб вони монтувалися у нестандартне місце або для аудиторії, яка не є API-сервером, скористайтеся одним із наступних методів:

  • API TokenRequest (рекомендовано): Запитайте короткостроковий токен ServiceAccount безпосередньо з вашого власного коду застосунку. Токен автоматично закінчується і може змінюватись при закінченні строку дії. Якщо у вас є застаріла програма, яка не враховує Kubernetes, ви можете використовувати контейнер sidecar у тому ж самому Podʼі, щоб отримати ці токени та зробити їх доступними для робочого навантаження застосунку.
  • Token Volume Projection (також рекомендовано): У Kubernetes v1.20 і пізніше скористайтеся специфікацією Pod, щоб вказати kubelet додати токен ServiceAccount до Pod як projected том. Токени projected автоматично закінчуються, а kubelet змінює токен до закінчення строку дії.
  • Service Account Token Secrets (не рекомендується): Ви можете монтувати токени облікового запису служби як Secret Kubernetes у Podʼах. Ці токени не мають терміну дії та не ротуються. У версіях до v1.24 для кожного облікового запису служби автоматично створювався постійний токен. Цей метод більше не рекомендується, особливо у великому масштабі, через ризики, повʼязані зі статичними, довготривалими обліковими даними. Feature gate LegacyServiceAccountTokenNoAutoGeneration (який був стандартно увімкнений в Kubernetes з v1.24 по v1.26), перешкоджав автоматичному створенню цих токенів для облікових записів служб. Його було вилучено у версії v1.27, оскільки він був піднятий до статусу GA; ви все ще можете вручну створювати нескінченні токени облікового запису служби, але повинні враховувати наслідки для безпеки.

Обмеження доступу до Secret

У Kubernetes існує анотація під назвою kubernetes.io/enforce-mountable-secrets, яку ви можете додати до своїх ServiceAccounts. Коли ця анотація застосовується, Secret ServiceAccount можна монтувати лише на вказані типи ресурсів, покращуючи безпеку вашого кластера.

Ви можете додати анотацію до ServiceAccount за допомогою маніфесту:

apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    kubernetes.io/enforce-mountable-secrets: "true"
  name: my-serviceaccount
  namespace: my-namespace

Коли ця анотація встановлена в "true", панель управління Kubernetes переконується, що Secret з цього ServiceAccount піддаються певним обмеженням монтування.

  1. Назва кожного Secret, який монтується як том Podʼа, повинна зʼявитися в полі secrets ServiceAccount Podʼа.
  2. Назва кожного Secret, на який посилається за допомогою envFrom у Podʼі, також повинна зʼявитися в полі secrets ServiceAccount Podʼа.
  3. Назва кожного Secret, на який посилається за допомогою imagePullSecrets у Podʼі, також повинна зʼявитися в полі secrets ServiceAccount Podʼа.

Розуміючи та дотримуючись цих обмежень, адміністратори кластера можуть підтримувати більш тісний профіль безпеки та забезпечити, що Secret доступні лише відповідним ресурсам.

Автентифікація облікових записів служби

ServiceAccount використовують підписані JSON Web Tokens (JWT) для автентифікації в API-сервері Kubernetes та будь-якій іншій системі, де існує довіра. Залежно від того, як був виданий токен (або обмежений за часом за допомогою TokenRequest, або використовуючи застарілий механізм із Secret), токен ServiceAccount може також мати час дії, аудиторію та час, коли токен починає бути дійсним. Коли клієнт, який діє як ServiceAccount, намагається спілкуватися з API-сервером Kubernetes, клієнт включає заголовок Authorization: Bearer <token> з HTTP-запитом. API-сервер перевіряє чинність цього токена наступним чином:

  1. Перевіряє підпис токена.
  2. Перевіряє, чи не закінчився строк дії токена.
  3. Перевіряє, чи наразі дійсні посилання на обʼєкти у твердженнях токена.
  4. Перевіряє, чи наразі дійсний токен.
  5. Перевіряє аудиторію тверджень.

API TokenRequest створює звʼязані токени для ServiceAccount. Ця звʼязка повʼязана з життєвим циклом клієнта, такого як Pod, який діє як цей ServiceAccount. Дивіться Token Volume Projection для прикладу схеми та полів JWT звʼязаного токена облікового запису служби.

Для токенів, виданих за допомогою API TokenRequest, API-сервер також перевіряє, чи існує зараз конкретне посилання на обʼєкт, яке використовує ServiceAccount, відповідно до унікального ідентифікатора цього обʼєкта. Для застарілих токенів, які монтувалися як Secretʼи в Podʼах, API-сервер перевіряє токен за допомогою Secret.

Для отримання додаткової інформації про процес автентифікації, див. Автентифікація.

Автентифікація облікових записів служби у вашому власному коді

Якщо у вас є власні служби, яким потрібно перевіряти облікові дані служби Kubernetes, ви можете використовувати наступні методи:

Проєкт Kubernetes рекомендує використовувати API TokenReview, оскільки цей метод анулює токени, які привʼязані до обʼєктів API, таких як Secrets, ServiceAccounts, Podʼи або Вузли, коли ці обʼєкти видаляються. Наприклад, якщо ви видаляєте Pod, що містить projected токен ServiceAccount, кластер негайно анулює цей токен, і перевірка TokenReview негайно зазнає невдачі. Якщо ви використовуєте перевірку OIDC замість цього, ваші клієнти продовжують розглядати токен як дійсний, доки токен не досягне часу закінчення дії.

Ваш застосунок повинен завжди визначати аудиторію, яку він приймає, і перевіряти, що аудиторії токена відповідають аудиторіям, які очікує ваш застосунок. Це допомагає зменшити обсяг застосування токена так, що він може бути використаний лише у вашому застосунку і ніде більше.

Альтернативи

Що далі

3.8.5 - Політики безпеки для Podʼів

Замість використання PodSecurityPolicy, ви можете застосовувати схожі обмеження до Podʼів, використовуючи один чи обидва варіанти:

  • Pod Security Admission
  • втулок допуску від стороннього розробника, який ви розгортаєте та налаштовуєте самостійно

Для практичного керівництва з міграції дивіться Міграція з PodSecurityPolicy до вбудованого контролера Pod Security Admission. Для отримання додаткової інформації про вилучення цього API, дивіться Застарівання PodSecurityPolicy: минуле, сьогодення та майбутнє.

Якщо ви не використовуєте Kubernetes v1.31, перевірте документацію для вашої версії Kubernetes.

3.8.6 - Захист для вузлів з операційною системою Windows

На цій сторінці описано питання безпеки та найкращі практики, специфічні для операційної системи Windows.

Захист конфіденційних даних на вузлах

У Windows дані з Secret записуються у відкритому вигляді у локальне сховище вузла (на відміну від використання tmpfs / файлових систем у памʼяті в Linux). Як оператору кластера, вам слід вжити обидва наступні додаткові заходи:

  1. Використовуйте контроль доступу до файлів (file ACLs), щоб захистити місце розташування файлів Secrets.
  2. Застосовуйте шифрування на рівні тому за допомогою BitLocker.

Користувачі контейнерів

RunAsUsername може бути вказано для Podʼів Windows або контейнерів, щоб виконувати процеси контейнера як конкретний користувач. Це приблизно еквівалентно RunAsUser.

В контейнерах Windows доступні два типові облікових записів користувачів: ContainerUser та ContainerAdministrator. Різниця між цими двома обліковими записами користувачів описана у When to use ContainerAdmin and ContainerUser user accounts в документації Microsoft Secure Windows containers.

Локальні користувачі можуть бути додані до образів контейнерів під час процесу створення контейнера.

Контейнери Windows також можуть працювати як облікові записи активного каталогу за допомогою Group Managed Service Accounts

Ізоляція на рівні Podʼа

Механізми контексту безпеки Podʼів, специфічні для Linux (такі як SELinux, AppArmor, Seccomp або власні POSIX можливості), не підтримуються на вузлах з Windows.

Привілейовані контейнери не підтримуються на вузлах з Windows. Замість цього на вузлах з Windows можна використовувати HostProcess контейнери для виконання багатьох завдань, які виконуються привілейованими контейнерами у Linux.

3.8.7 - Керування доступом до API Kubernetes

Ця сторінка надає загальний огляд керування доступом до API Kubernetes.

Користувачі отримують доступ до API Kubernetes за допомогою kubectl, клієнтських бібліотек або за допомогою запитів REST. Як користувачі-люди, так і облікові записи служб Kubernetes можуть бути авторизовані для доступу до API. Коли запит досягає API, він проходить кілька етапів, які ілюструються на наступній діаграмі:

Діаграма етапів обробки запиту до API Kubernetes

Транспортна безпека

Стандартно сервер API Kubernetes прослуховує порт 6443 на першому нелокальному мережевому інтерфейсі, захищеному за допомогою TLS. У типовому промисловому кластері Kubernetes, API працює на порту 443. Порт можна змінити за допомогою прапорця --secure-port, а IP-адресу прослуховування – за допомогою --bind-address.

Сервер API представляє сертифікат. Цей сертифікат може бути підписаний за допомогою приватного центру сертифікації (ЦС), або на основі інфраструктури відкритих ключів, повʼязаної з загалом визнаним ЦС. Сертифікат та відповідний приватний ключ можна встановити за допомогою прапорців --tls-cert-file та --tls-private-key-file.

Якщо ваш кластер використовує приватний ЦС, вам потрібна копія цього сертифіката ЦС, налаштована в вашому ~/.kube/config на клієнті, щоб ви могли довіряти зʼєднанню і бути впевненими, що воно не було перехоплено.

На цьому етапі ваш клієнт може представити сертифікат клієнта TLS.

Автентифікація

Якщо TLS-зʼєднання встановлено, HTTP-запит переходить до кроку автентифікації. Це показано як крок 1 на діаграмі. Скрипт створення кластера або адміністратор кластера налаштовує сервер API на виконання одного або декількох модулів автентифікації. Модулі автентифікації детально описані в документації про Автентифікацію.

Вхідними даними для кроку автентифікації є весь HTTP-запит; проте, зазвичай перевіряються заголовки та/або сертифікат клієнта.

Модулі автентифікації включають клієнтські сертифікати, паролі та прості токени, токени ініціалізації та токени JSON Web Tokens (використовується для облікових записів служб).

Можна вказати кілька модулів автентифікації, при цьому кожен з них використовується послідовно, доки спроба не буде успішною.

Якщо запит не може бути автентифікований, він буде відхилений з HTTP-статусом 401. Інакше користувач автентифікується як конкретний username, та імʼя користувача доступне для наступних кроків для використання у їхніх рішеннях. Деякі автентифікатори також надають групові приналежності користувача, в той час, як інші автентифікатори цього не роблять.

Хоча Kubernetes використовує імена користувачів для прийняття рішень про контроль доступу та в логах запитів, в нього немає обʼєкта User, і він не зберігає імена користувачів чи іншу інформацію про користувачів у своєму API.

Авторизація

Після того як запит автентифікується як такий, що надійшов від певного користувача, йому потрібно пройти авторизацію. Це показано як крок 2 на діаграмі.

Запит повинен містити імʼя користувача, який робить запит, запитану дію та обʼєкт, на якому відбувається дія. Запит авторизується, якщо наявна політика вказує, що користувач має дозвіл на виконання запитаної дії.

Наприклад, якщо у Боба є така політика, то він може лише читати обʼєкти у просторі імен projectCaribou:

{
    "apiVersion": "abac.authorization.kubernetes.io/v1beta1",
    "kind": "Policy",
    "spec": {
        "user": "bob",
        "namespace": "projectCaribou",
        "resource": "pods",
        "readonly": true
    }
}

Якщо Боб зробить такий запит, то він буде авторизований, оскільки він має дозвіл на читання обʼєктів у просторі імен projectCaribou:

{
  "apiVersion": "authorization.k8s.io/v1beta1",
  "kind": "SubjectAccessReview",
  "spec": {
    "resourceAttributes": {
      "namespace": "projectCaribou",
      "verb": "get",
      "group": "unicorn.example.org",
      "resource": "pods"
    }
  }
}

Якщо Боб зробить запит на запис (create або update) обʼєктів у просторі імен projectCaribou, то йому буде відмовлено в авторизації. Якщо Боб зробить запит на читання (get) обʼєктів у іншому просторі імен, наприклад, projectFish, то йому буде відмовлено в авторизації.

Для авторизації в Kubernetes потрібно використовувати загальні атрибути REST для взаємодії з наявними системами керування доступом на рівні всієї організації або постачальника хмарних послуг. Важливо використовувати форматування REST, оскільки ці системи керування можуть взаємодіяти з іншими API, крім API Kubernetes.

Kubernetes підтримує кілька модулів авторизації, таких як режим ABAC, режим RBAC та режим Webhook. Коли адміністратор створює кластер, він налаштовує модулі авторизації, які повинні використовуватися в сервері API. Якщо налаштовано більше одного модуля авторизації, Kubernetes перевіряє кожен модуль, і якщо будь-який модуль авторизує запит, то запит може бути виконаний. Якщо всі модулі відхиляють запит, то запит відхиляється (HTTP-статус код 403).

Щоб дізнатися більше про авторизацію в Kubernetes, включно з деталями щодо створення політик з використанням підтримуваних модулів авторизації, див. Авторизація.

Контроль доступу

Модулі контролю доступу — це програмні модулі, які можуть змінювати або відхиляти запити. Крім атрибутів, доступних модулям авторизації, модулі контролю доступу можуть отримувати доступ до вмісту обʼєкта, який створюється або змінюється.

Контролери доступу діють на запити, які створюють, змінюють, видаляють або підключаються (проксі) до обʼєкта. Контролери доступу не діють на запити, які лише читають обʼєкти. Коли налаштовано кілька контролерів доступу, вони викликаються по черзі.

Це показано як крок 3 на діаграмі.

На відміну від модулів автентифікації та авторизації, якщо будь-який модуль контролю доступу відхиляє запит, то запит негайно відхиляється.

Крім відхилення обʼєктів, контролери доступу також можуть встановлювати складні стандартні значення для полів.

Доступні модулі контролю доступу описані в Контролерах доступу.

Після того як запит пройшов усі контролери доступу, він перевіряється за допомогою процедур валідації для відповідного обʼєкта API, і потім записується в сховище обʼєктів (показано як крок 4).

Аудит

Аудит Kubernetes забезпечує безпеку, хронологічний набір записів, що документують послідовність дій у кластері. Кластер аудитує активності, що генеруються користувачами, застосунками, які використовують API Kubernetes, і самою панелі управління.

Для отримання додаткової інформації див. Аудит.

Що далі

Прочитайте додаткову документацію щодо автентифікації, авторизації та контролю доступу до API:

Ви можете дізнатися про:

  • як Podʼи можуть використовувати Secret для отримання API-даних для доступу.

3.8.8 - Поради з безпеки для контролю доступу на основі ролей

Принципи та практики для належного про'ктування RBAC для операторів кластерів.

Kubernetes RBAC є ключовим елементом безпеки, який забезпечує те, що користувачі та робочі навантаження кластера мають доступ лише до ресурсів, необхідних для виконання їх ролей. Важливо переконатися, що при проєктуванні дозволів для користувачів кластера адміністратор кластера розуміє області, де може відбуватися ескалація привілеїв, щоб зменшити ризик надмірного доступу, що може призвести до інцидентів безпеки.

Рекомендації, викладені тут, слід читати разом із загальною документацією з RBAC.

Загальні рекомендації

Принцип найменших привілеїв

Ідеально, мінімальні права RBAC повинні бути надані користувачам та службовим обліковим записам. Використовуйте лише дозволи, які явно потрібні для їхньої роботи. Хоча кожен кластер буде відрізнятися, деякі загальні правила, які можна застосувати, включають наступне:

  • Надавайте дозволи на рівні простору імен, де це можливо. Використовуйте RoleBindings замість ClusterRoleBindings, щоб дати користувачам права лише в межах конкретного простору імен.
  • Уникайте надання дозволів за допомогою шаблонів (wildcard) при можливості, особливо для всіх ресурсів. Оскільки Kubernetes є розширюваною системою, надання доступу за допомогою шаблонів надає права не лише на всі типи обʼєктів, які наразі існують у кластері, а й на всі типи обʼєктів, які будуть створені у майбутньому.
  • Адміністратори не повинні використовувати облікові записи cluster-admin, крім випадків, коли це дійсно потрібно. Надання облікового запису з низькими привілеями з правами знеособлення може запобігти випадковій модифікації ресурсів кластера.
  • Уникайте додавання користувачів до групи system:masters. Будь-який користувач, який є членом цієї групи, обходить всі перевірки прав RBAC та завжди матиме необмежений доступ суперкористувача, який не може бути скасований шляхом видалення RoleBindings або ClusterRoleBindings. До речі, якщо кластер використовує вебхук авторизації, членство в цій групі також обходить цей вебхук (запити від користувачів, які є членами цієї групи, ніколи не відправляються вебхуку).

Мінімізація розповсюдження привілейованих токенів

В ідеалі, службові облікові записи не повинні бути призначені Podʼам, які мають надані потужні дозволи (наприклад, будь-які з перерахованих прав підвищення привілеїв). У випадках, коли робоче навантаження вимагає потужних дозволів, розгляньте такі практики:

  • Обмежте кількість вузлів, на яких запущені потужні Podʼи. Переконайтеся, що всі DaemonSets, які ви запускаєте, необхідні та запускаються з мінімальними привілеями, щоб обмежити зону поширення випадкових виходів з контейнера.
  • Уникайте запуску потужних Podʼів поруч з ненадійними або публічно-експонованими. Розгляньте використання Taints and Toleration, NodeAffinity або PodAntiAffinity, щоб переконатися, що Podʼи не запускаються поруч з ненадійними або менш надійними Podʼами. Особливу увагу слід приділяти ситуаціям, де менш надійні Podʼи не відповідають стандарту Restricted для безпеки Podʼів.

Зміцнення захисту

Kubernetes типово надає доступ, який може бути непотрібним у кожному кластері. Перегляд прав RBAC, які надаються типово, може створити можливості для зміцнення безпеки. Загалом, зміни не повинні вноситися до прав, наданих system: обліковим записам, але існують деякі опції для зміцнення прав кластера:

  • Перегляньте звʼязки для групи system:unauthenticated та видаліть їх, де це можливо, оскільки це надає доступ всім, хто може звертатися до сервера API на мережевому рівні.
  • Уникайте автоматичного монтування токенів службового облікового запису типово, встановивши automountServiceAccountToken: false. Докладніше дивіться використання токенів стандартного службового облікового запису. Встановлення цього значення для Podʼа перезапише налаштування службового облікового запису, робочі навантаження які потребують токени службового облікового запису, все ще можуть монтувати їх.

Періодичний огляд

Важливо періодично переглядати налаштування Kubernetes RBAC для виявлення зайвих записів та можливих ескалацій привілеїв. Якщо зловмисник може створити обліковий запис користувача з такою ж назвою, як видалений користувач, він автоматично може успадкувати всі права видаленого користувача, зокрема права, призначені цьому користувачу.

Ризики ескалації привілеїв RBAC у Kubernetes

У Kubernetes RBAC існує кілька привілеїв, які, якщо надані, можуть дозволити користувачеві або обліковому запису служби здійснити ескалацію своїх привілеїв у кластері або вплинути на системи за межами кластера.

Цей розділ призначений для того, щоб надати видимість тим областям, де оператори кластерів повинні бути уважними, щоб переконатися, що вони не надають більше доступу до кластерів, ніж було задумано.

Отримання Secret

Зазвичай зрозуміло, що надання доступу до отримання (get) Secret дозволить користувачеві переглядати їх вміст. Також важливо зауважити, що доступ до списку (list) та перегляду (watch) також фактично дозволяє користувачам розкривати вміст Secret. Наприклад, коли повертається відповідь списку (наприклад, за допомогою kubectl get secrets -A -o yaml), вона містить вміст усіх Secret.

Створення робочого навантаження

Дозвіл на створення робочих навантажень (будь-то Podʼи чи ресурси робочих навантажень, що керують Podʼами) у просторі імен неявно надає доступ до багатьох інших ресурсів у цьому просторі імен, таких як Secret, ConfigMap та PersistentVolume, які можна монтувати в Podʼах. Крім того, оскільки Podʼи можуть працювати як будь-який ServiceAccount, надання дозволу на створення робочих навантажень також неявно надає рівні доступу до API будь-якого облікового запису служби у цьому просторі імен.

Користувачі, які можуть запускати привілейовані Podʼи, можуть використовувати цей доступ для отримання доступу до вузла і, можливо, подальшого підвищення своїх привілеїв. Якщо ви не повністю довіряєте користувачеві або іншому принципалу з можливістю створювати відповідні заходи безпеки та ізоляції Podʼів, вам слід застосувати стандарт безпеки Podʼів Baseline або Restricted. Ви можете використовувати Pod Security admission або інші (сторонні) механізми для впровадження цього контролю.

З цих причин простори імен слід використовувати для розділення ресурсів, які потребують різних рівнів довіри або оренди. Вважається за кращу практику дотримуватися принципів найменших привілеїв і надавати мінімальний набір дозволів, але межі у межах простору імен слід розглядати як слабкі.

Створення постійного тому

Якщо дозволяється комусь, або застосунку, створювати довільні постійні томи (PersistentVolumes), цей доступ включає створення томів типу hostPath, що означає, що Pod отримає доступ до базової файлової системи (файлових систем) вузла, з яким повʼязаний цей том. Надання такої можливості — це ризик безпеки.

Існує багато способів, за допомогою яких контейнер з необмеженим доступом до файлової системи вузла може підвищити свої привілеї, включаючи читання даних з інших контейнерів та зловживання обліковими записами служб системи, такими як Kubelet.

Дозволяйте доступ до створення обʼєктів PersistentVolume (постійного тому) лише для:

  • Користувачів (операторів кластера), які потребують цього доступу для своєї роботи, і яким ви довіряєте.
  • Компонентів управління Kubernetes, які створюють обʼєкти PersistentVolume на основі PersistentVolumeClaims, які налаштовані для автоматичного розподілу. Зазвичай це налаштовано постачальником Kubernetes або оператором при встановленні драйвера CSI.

Де потрібен доступ до постійного сховища, довірені адміністратори повинні створювати PersistentVolumes, а обмежені користувачі повинні використовувати PersistentVolumeClaims для доступу до цього сховища.

Доступ до субресурсу proxy обʼєктів вузлів

Користувачі, які мають доступ до субресурсу proxy обʼєктів вузлів, мають права на використання API Kubelet, що дозволяє виконувати команди на кожному Podʼі на вузлі (вузлах), до якого вони мають права доступу. Цей доступ обходить логування подій та контроль допуску, тому слід бути обережним перед наданням прав на цей ресурс.

Escalate

Загалом, система RBAC запобігає користувачам створювати clusterroles з більшими правами, ніж має користувач. Виняток становить дієслово escalate. Як вказано в документації з RBAC, користувачі з цим правом можуть ефективно підвищувати свої привілеї.

Bind

Схоже до дієслова escalate, надання користувачам цього права дозволяє обхід вбудованих захистів Kubernetes від підвищення привілеїв, що дозволяє користувачам створювати привʼязки до ролей з правами, яких вони ще не мають.

Impersonate

Це дієслово дозволяє користувачам підміняти та отримувати права інших користувачів у кластері. Слід бути обережним при наданні цього права, щоб переконатися, що через один з знеособлених облікових записів не можна отримати занадто багато прав.

Запити на підпис сертифікатів (CSRs) і видача сертифікатів

API CSRs дозволяє користувачам з правами create на CSRs та update на certificatesigningrequests/approval з підписантом kubernetes.io/kube-apiserver-client створювати нові клієнтські сертифікати, що дозволяють користувачам автентифікуватися в кластері. Ці клієнтські сертифікати можуть мати довільні імена, включаючи дублікати компонентів системи Kubernetes. Це фактично дозволить підвищення привілеїв.

Запити токенів

Користувачі з правами create на serviceaccounts/token можуть створювати запити на токени для наявних сервісних облікових записів.

Керування вебхуками допуску

Користувачі з контролем над validatingwebhookconfigurations або mutatingwebhookconfigurations можуть керувати вебхуками, які можуть читати будь-який обʼєкт, допущений до кластера, і, у разі мутаційних вебхуків, також змінювати допущені обʼєкти.

Зміна Namespace

Користувачі, які можуть виконувати операції patch на обʼєктах Namespace (через привʼязку до ролі (RoleBinding) з таким доступом), можуть змінювати мітки цього Namespaceʼу. У кластерах, де використовується Pod Security Admission, це може дозволити користувачу налаштувати простір імен для більш дозволених політик, ніж передбачено адміністратором. Для кластерів, де використовується NetworkPolicy, користувачам можуть бути встановлені мітки, які опосередковано дозволяють доступ до служб, доступ до яких адміністратор не мав на меті давати.

Ризики відмови в обслуговуванні в Kubernetes RBAC

Відмова у створенні обʼєктів

Користувачі, які мають права на створення обʼєктів у кластері, можуть створювати достатньо великі обʼєкти або велику кількість обʼєктів, що може призвести до умов відмови в обслуговуванні, як обговорюється в etcd, що використовується в Kubernetes, піддається атакам типу OOM. Це може бути особливо актуальним у кластерах з кількома орендаторами, якщо користувачі з частковою довірою або користувачі без довіри мають обмежений доступ до системи.

Один зі способів попередження цієї проблеми — використовувати обмеження ресурсів для обмеження кількості обʼєктів, які можна створити.

Що далі

3.8.9 - Поради використання Secretʼів в Kubernetes

Принципи та практики керування Secretʼами для адміністраторів кластера та розробників застосунків.

У Kubernetes, Secret — це обʼєкт, який зберігає конфіденційну інформацію, таку як паролі, токени OAuth та ключі SSH.

Секрети дають вам більше контролю над тим, як використовується конфіденційна інформація і зменшують ризик випадкового її розголошення. Значення Secret кодуються як рядки base64 і зазвичай зберігаються в незашифрованому вигляді, але можуть бути налаштовані для шифрування в стані покою.

Pod може посилатися на Secret різними способами, такими як монтування тому, чи як змінна середовища. Secretʼи призначені для конфіденційних даних, а ConfigMaps призначені для неконфіденційних даних.

Наведені нижче поради призначені як для адміністраторів кластера, так і для розробників застосунків. Використовуйте ці рекомендації, щоб підвищити безпеку вашої конфіденційної інформації у Secret, а також ефективніше керувати вашими Secretʼами.

Адміністратори кластера

У цьому розділі наведені кращі практики, які адміністратори кластера можуть використовувати для покращення безпеки конфіденційної інформації в кластері.

Налаштування шифрування даних у спокої

Стандартно обʼєкти Secret зберігаються у кластері в etcd у незашифрованому вигляді. Вам слід налаштувати шифрування конфіденційної інформації з Secret в etcd. Для отримання інструкцій дивіться Шифрування конфіденційних даних у Secret у спокої.

Налаштування доступу з мінімальними привілеями до Secret

Плануючи механізм керування доступом, такий як Керування доступом на основі ролей Kubernetes (RBAC), слід врахувати наступні рекомендації щодо доступу до обʼєктів Secret. Також слід дотримуватися рекомендацій використання RBAC.

  • Компоненти: Обмежте доступ до watch або list тільки для найпривілейованіших системних компонентів. Дозвольте доступ лише для отримання Secret, якщо це необхідно для звичайної роботи компонента.
  • Люди: Обмежте доступ до Secrets на рівні get, watch або list. Дозвольте адміністраторам кластера отримувати доступ до etcd. Це включає доступ тільки для читання. Для складнішого керування доступом, такого як обмеження доступу до Secrets з конкретними анотаціями, слід розглянути використання механізмів авторизації сторонніх постачальників.

Користувач, який може створити Pod, який використовує Secret, також може побачити значення цього Secret. Навіть якщо політика кластера не дозволяє користувачу читати Secret безпосередньо, той же користувач може мати доступ до запуску Pod, який потім розкриває Secret. Ви можете виявити або обмежити вплив викриття даних Secret, як умисно, так і неумисно, користувачем з цим доступом. Деякі рекомендації включають:

  • Використовуйте Secret з коротким терміном дії
  • Реалізуйте правила аудиту, які сповіщають про певні події, такі як одночасне читання кількох Secret одним користувачем

Додаткові анотації ServiceAccount для керування Secret

Ви також можете використовувати анотацію kubernetes.io/enforce-mountable-secrets на ServiceAccount для виконання певних правил щодо того, як використовувати Secrets у Pod. Для отримання додаткових відомостей дивіться документацію по цій анотації.

Покращення політик управління etcd

Розгляньте очищення або знищення надійного сховища, використаного etcd, якщо воно більше не використовується.

Якщо є кілька екземплярів etcd, налаштуйте зашифровану SSL/TLS комунікацію між екземплярами для захисту конфіденційних даних Secret під час передачі.

Налаштування доступу до зовнішніх Secrets

Ви можете використовувати сторонніх постачальників систем збереження Secret, щоб зберігати вашу конфіденційну інформацію поза кластером, а потім налаштувати Podʼі для доступу до цієї інформації. Драйвер Kubernetes Secrets Store CSI — це DaemonSet, який дозволяє kubelet отримувати Secrets з зовнішніх сховищ та монтувати Secretʼи як томи у певні Podʼи, які ви авторизуєте для доступу до даних.

Для списку підтримуваних постачальників дивіться Постачальники для драйвера сховища Secret Store CSI.

Розробники

У цьому розділі наведено рекомендації для розробників щодо покращення безпеки конфіденційних даних при створенні та розгортанні ресурсів Kubernetes.

Обмежте доступ до Secret до певних контейнерів

Якщо ви визначаєте декілька контейнерів у Pod, і тільки один з цих контейнерів потребує доступу до Secret, визначте настройки монтування томів або змінних середовища так, щоб інші контейнери не мали доступ до цього Secret.

Захист даних Secret після їх зчитування

Застосунки все ще повинні захищати значення конфіденційної інформації після їх зчитування зі змінної середовища або тому. Наприклад, вашому застосунку слід уникати логування конфіденційних даних у відкритому вигляді або передачі їх ненадійній стороні.

Уникайте спільного використання маніфестів Secret

Якщо ви налаштовуєте Secret через маніфест, де дані Secret кодуються у base64, то обмінюючись цим файлом або включаючи його до репозиторію, цей Secret буде доступний всім, хто може читати маніфест.

3.8.10 - Мультиорендність

Ця сторінка надає огляд наявних параметрів конфігурації та найкращих практик для мультиорендності (multi-tenancy) кластера.

Спільне використання кластерів зменшує витрати та спрощує адміністрування. Однак спільне використання кластерів також ставить перед собою виклики, такі як безпека, справедливість та керування шумними сусідами.

Кластери можуть бути спільно використані багатьма способами. У деяких випадках різні програми можуть працювати у тому ж кластері. У інших випадках у тому ж кластері може працювати кілька екземплярів тієї самої програми, один для кожного кінцевого користувача. Усі ці типи спільного використання часто описуються за допомогою терміну мультиорендність.

Хоча Kubernetes не має концепцій кінцевих користувачів або орендарів першого класу, він надає кілька можливостей для керування різними вимогами до оренди. Про них буде нижче.

Сценарії використання

Першим кроком для визначення того, як ділити ваш кластер, є розуміння вашого сценарію використання, щоб ви могли оцінити доступні шаблони та інструменти. Загалом, мульторендність в кластерах Kubernetes може бути узагальнена у дві широкі категорії, хоча можливі також багато варіантів та гібриди.

Декілька команд

Одна з поширених форм мульторендності — це спільне використання кластера кількома командами у межах однієї організації, кожна з яких може працювати з одним або кількома робочими навантаженнями. Ці робочі навантаження часто потребують взаємодії між собою та з іншими робочими навантаженнями, що розташовані на тому самому або різних кластерах.

У цьому сценарії учасники команд часто мають прямий доступ до ресурсів Kubernetes за допомогою інструментів, таких як kubectl, або опосередкований доступ через контролери GitOps або інші типи інструментів автоматизації релізу. Часто існує певний рівень довіри між учасниками різних команд, але політики Kubernetes, такі як RBAC, квоти та мережеві політики, є невіддільним для безпечного та справедливого спільного використання кластерів.

Кілька клієнтів

Інша основна форма багатоорендності часто охоплює постачальника програмного забезпечення як сервісу (SaaS), який запускає кілька екземплярів робочого навантаження для клієнтів. Ця бізнес-модель настільки сильно повʼязана з цим стилем розгортання, що багато хто називає її "SaaS tenancy". Однак, кращим терміном може бути "багатоклієнтська оренда", оскільки постачальники SaaS також можуть використовувати інші моделі розгортання, і цю модель розгортання також можна використовувати поза межами SaaS.

У цьому сценарії клієнти не мають доступу до кластера; Kubernetes невидимий з їх точки погляду і використовується лише постачальником для керування робочими навантаженнями. Оптимізація витрат часто є критичною проблемою, і політики Kubernetes використовуються для забезпечення того, що робочі навантаження міцно ізольовані одне від одного.

Термінологія

Орендарі

При обговоренні мультиорендності в Kubernetes не існує єдиного визначення "орендаря" (tenant). Замість цього визначення орендаря буде залежати від того, чи обговорюється багатокомандна або багатоклієнтська мультиорендність.

У використанні багатокомандної моделі орендарем, як правило, є команда, при цьому кожна команда, як правило, розгортає невелику кількість робочих навантажень, яка зростає зі складністю сервісу. Однак визначення "команди" саме по собі може бути нечітким, оскільки команди складатись з високорівневих підрозділів або розділені на менші команди.

Натомість якщо кожна команда розгортає відокремлені робочі навантаження для кожного нового клієнта, вони використовують багатоклієнтську модель мультиорендності. У цьому випадку "орендарем" є просто група користувачів, які спільно використовують одне робоче навантаження. Це може бути як ціла компанія, так і одна команда в цій компанії.

У багатьох випадках одна й та ж організація може використовувати обидва визначення "орендарів" у різних контекстах. Наприклад, команда платформи може пропонувати спільні послуги, такі як інструменти безпеки та бази даних, кільком внутрішнім "клієнтам", і постачальник SaaS також може мати кілька команд, які спільно використовують кластер, який використовується для розробки. Нарешті, можливі також гібридні архітектури, такі як постачальник SaaS, який використовує комбінацію робочих навантажень для кожного клієнта для конфіденційних даних, спільно з багатокористувацькими спільними службами.

Кластер, на якому показані співіснуючі моделі оренди

Ізоляція

Існує кілька способів проєктування та побудови багатокористувацьких рішень з використанням Kubernetes. Кожен з цих методів має свій набір компромісів, які впливають на рівень ізоляції, складність реалізації, операційну складність та вартість обслуговування.

Кластер Kubernetes складається з панелі управління, на якій працює програмне забезпечення Kubernetes, та панелі даних, яка складається з робочих вузлів, де виконуються робочі навантаження орендарів у вигляді Podʼів. Ізоляція орендарів може бути застосована як в панелі управління, так і в панелі даних залежно від вимог організації.

Рівень ізоляції, який пропонується, іноді описується за допомогою термінів, таких як "жорстка" багатоорендність, що має на увазі міцну ізоляцію, і "мʼяка" багатоорендність, що означає слабшу ізоляцію. Зокрема, "жорстка" багатоорендність часто використовується для опису випадків, коли орендарі не довіряють один одному, часто з погляду безпеки та обміну ресурсами (наприклад, захист від атак, таких як ексфільтрація даних або DoS). Оскільки панелі даних зазвичай мають набагато більші площі атаки, "жорстка" багатоорендність часто вимагає додаткової уваги до ізоляції панелі даних, хоча ізоляція панелі управління також залишається критичною.

Однак терміни "жорстка" та "мʼяка" часто можуть бути плутаними, оскільки немає однозначного визначення, яке б підходило для всіх користувачів. Краще розуміти "жорсткість" або "мʼякість" як широкий спектр, у якому можна використовувати багато різних технік для забезпечення різних типів ізоляції у ваших кластерах, залежно від ваших вимог.

У більш екстремальних випадках може бути легше або необхідно відмовитися від будь-якого рівня спільного використання на рівні кластера та надати кожному орендареві його власний кластер, можливо, навіть запущений на власному обладнанні, якщо віртуальні машини не розглядаються як належний рівень безпеки. Це може бути легше з використанням кластерів Kubernetes, що розгортаються та керуються постачальником, де накладні витрати на створення та експлуатацію кластерів хоча б певною мірою беруться на себе провайдером хмарних послуг. Перевага більшої ізоляції орендарів повинна оцінюватися порівняно з витратами та складністю управління кількома кластерами. Група Multi-cluster SIG відповідає за вирішення цих типів використання.

Решта цієї сторінки присвячена технікам ізоляції, які використовуються для спільних кластерів Kubernetes. Однак, навіть якщо ви розглядаєте власні кластери, може бути корисно переглянути ці рекомендації, оскільки це дозволить вам гнучко змінювати свої потреби або можливості у майбутньому.

Ізоляція панелі управління

Ізоляція панелі управління забезпечує те, що різні орендарі не можуть отримати доступ або вплинути на ресурси Kubernetes API інших орендарів.

Простори імен

У Kubernetes Namespace надає механізм для ізоляції груп ресурсів API в межах одного кластера. Ця ізоляція має дві ключові виміри:

  1. Назви обʼєктів в межах простору імен можуть перекриватися з назвами в інших просторах імен, схоже на файли у теках. Це дозволяє орендарям називати свої ресурси, не переймаючись тим, що роблять інші орендарі.

  2. Багато політик безпеки Kubernetes мають обмеження на простори імен. Наприклад, ресурси RBAC Roles та Network Policies мають обмеження на простори імен. За допомогою RBAC користувачі та облікові записи служб можуть бути обмежені в просторі імен.

У середовищі з кількома орендарями простір імен допомагає сегментувати робоче навантаження орендаря на логічний та окремий підрозділ управління. Насправді поширена практика полягає в тому, щоб ізолювати кожне робоче навантаження у власному просторі імен, навіть якщо кількома робочими навантаженнями керує один і той же орендар. Це гарантує, що кожне робоче навантаження має власну ідентичність і може бути налаштоване з відповідною політикою безпеки.

Модель ізоляції простору імен вимагає конфігурації кількох інших ресурсів Kubernetes, мережевих застосунків та дотримання найкращих практик з безпеки для належної ізоляції робочих навантажень орендарів. Ці важливі аспекти обговорюються нижче.

Контроль доступу

Найважливіший тип ізоляції для панелі управління — це авторизація. Якщо команди або їх робочі навантаження можуть отримати доступ або модифікувати ресурси API інших, вони можуть змінювати або вимикати всі інші види політик, тим самим анулюючи будь-який захист, який ці політики можуть пропонувати. Тому критично забезпечити, що кожен орендар має відповідний доступ тільки до необхідних просторів імен, і ні до яких більше. Це відомо як "принцип найменших привілеїв".

Контроль доступу на основі ролей (RBAC) часто використовується для забезпечення авторизації в панелі управління Kubernetes, як для користувачів, так і для робочих навантажень (облікові записи служб). Role та RoleBinding — це обʼєкти Kubernetes, які використовуються на рівні простору імен для забезпечення контролю доступу у вашій програмі; аналогічні обʼєкти існують для авторизації доступу до обʼєктів на рівні кластера, хоча вони менш корисні для багатоорендних кластерів.

У багатокомандному середовищі RBAC має бути використаний для обмеження доступу орендарів до відповідних просторів імен, а також для забезпечення того, що ресурси на рівні кластера можуть бути отримані або змінені тільки привілейованими користувачами, такими як адміністратори кластера.

Якщо політика виявляється такою, що надає користувачеві більше дозволів, ніж йому потрібно, це найімовірніше сигнал того, що простір імен, який містить відповідні ресурси, повинен бути перероблений у більш деталізовані простори імен. Інструменти управління просторами імен можуть спростити управління цими більш деталізованими просторами імен за допомогою застосування загальних політик RBAC до різних просторів імен, дозволяючи при цьому використовувати детальніші політики за потреби.

Квоти

Робочі навантаження Kubernetes використовують ресурси вузла, такі як CPU та памʼять. У багатоорендному середовищі ви можете використовувати Квоти ресурсів для управління використанням ресурсів робочих навантажень орендарів. Для випадку з декількома командами, де орендарі мають доступ до API Kubernetes, ви можете використовувати квоти ресурсів, щоб обмежити кількість ресурсів API (наприклад: кількість Podʼів або кількість ConfigMap), яку може створити орендар. Обмеження на кількість обʼєктів забезпечують справедливість і спрямовані на уникнення проблем шумного сусіда, які можуть впливати на інших орендарів, які використовують спільну панель управління.

Квоти ресурсів — це обʼєкти, які мають область видимості простору імен. Шляхом зіставлення орендарів з просторами імен адміністратори кластера можуть використовувати квоти, щоб забезпечити, що орендар не може монополізувати ресурси кластера або перевантажувати його панель управління. Інструменти управління просторами імен спрощують адміністрування квот. Крім того, хоча квоти Kubernetes застосовуються лише у межах одного простору імен, деякі інструменти управління просторами імен дозволяють групам просторів імен використовувати спільні квоти, що дає адміністраторам набагато більше гнучкості з меншими зусиллями, ніж вбудовані квоти.

Квоти запобігають тому, щоб один орендар використовував більше, ніж йому призначено ресурсів, що мінімізує проблему "шумного сусіда", коли один орендар негативно впливає на продуктивність робочих навантажень інших орендарів.

При застосуванні квоти до простору імен Kubernetes вимагає вказати також запити та ліміти ресурсів для кожного контейнера. Ліміти — це верхня межа для кількості ресурсів, яку контейнер може використовувати. Контейнери, які намагаються використовувати ресурси, що перевищують налаштовані ліміти, будуть або обмежені, або примусово зупинені, залежно від типу ресурсу. Якщо запити ресурсів встановлені нижче лімітів, кожному контейнеру гарантується запитаний обсяг, але все ще може бути деякий потенціал для впливу на робочі навантаження.

Квоти не можуть надати захист для всіх видів ресурсів спільного використання, наприклад, таких як мережевий трафік. Для цієї проблеми може бути кращим рішенням ізоляція вузла (див. нижче).

Ізоляція панелі даних

Ізоляція панелі даних забезпечує достатню ізоляцію між Podʼами та робочими навантаженнями для різних орендарів.

Мережева ізоляція

Типово всі Podʼи в кластері Kubernetes можуть спілкуватися один з одним, і весь мережевий трафік не є зашифрованим. Це може призвести до вразливостей безпеки, де трафік випадково або зловмисно надсилається до непередбаченого призначення, або перехоплюється робочим навантаженням на скомпрометованому вузлі.

Комунікацію між Podʼами можна контролювати за допомогою мережевих політик, які обмежують комунікацію між Podʼами за допомогою міток простору імен або діапазонів IP-адрес. У багатоорендному середовищі, де потрібна строга мережева ізоляція між орендарями, рекомендується почати зі стандартної політики, яка відхиляє комунікацію між Podʼами, разом з іншим правилом, яке дозволяє всім Podʼам звертатись до сервера DNS для перевірки імен. З такою стандартною політикою ви можете почати додавати дозвільні правила, які дозволяють комунікацію всередині простору імен. Також рекомендується не використовувати порожній селектор мітки '{}' для поля namespaceSelector в визначенні мережевої політики, в разі потреби дозволу на трафік між просторами імен. Цю схему можна подальшим чином удосконалювати за потребою. Зверніть увагу, що це стосується лише Podʼів всередині однієї панелі управління; Podʼи, які належать до різних віртуальних панелей управління, не можуть спілкуватися один з одним в мережі Kubernetes.

Інструменти управління просторами імен можуть спростити створення стандартних або загальних мережевих політик. Крім того, деякі з цих інструментів дозволяють забезпечити послідовний набір міток просторів імен у вашому кластері, що гарантує їх справжність як основу для ваших політик.

Розширена мережева ізоляція може бути надана службовими мережами, які впроваджують політики OSI рівня 7 на основі ідентифікації робочих навантажень, крім просторів імен. Ці політики на вищому рівні можуть полегшити управління багатоорендними просторами імен, особливо коли декількох просторів імен призначених для одного орендаря. Вони часто також пропонують шифрування за допомогою взаємного TLS, захищаючи ваші дані навіть у випадку компрометованого вузла, і працюють на виділених або віртуальних кластерах. Однак вони можуть бути значно складнішими у керуванні і можуть бути недоречними для всіх користувачів.

Ізоляція сховищ

Kubernetes пропонує кілька типів томів, які можуть бути використані як постійне сховище для робочих навантажень. Для забезпечення безпеки та ізоляції даних рекомендується динамічне надання томів, а також варто уникати типів томів, які використовують ресурси вузла.

StorageClasses дозволяють описувати власні "класи" сховищ, які пропонуються вашим кластером, на основі рівнів якості обслуговування, політик резервного копіювання або власних політик, визначених адміністраторами кластера.

Podʼи можуть запитувати сховище за допомогою PersistentVolumeClaim. PersistentVolumeClaim є ресурсом, який належить до простору імен, що дозволяє ізолювати частину системи сховищ та призначати її орендарям у спільному кластері Kubernetes. Однак важливо зауважити, що PersistentVolume є ресурсом, доступним у всьому кластері, і має життєвий цикл, незалежний від робочих навантажень та просторів імен.

Наприклад, ви можете налаштувати окремий StorageClass для кожного орендаря і використовувати його для підсилення ізоляції. Якщо StorageClass є загальним, вам слід встановити політику повторного використання Delete, щоб забезпечити, що PersistentVolume не може бути використаний повторно в різних просторах імен.

Утримання контейнерів у пісочниці

Podʼи Kubernetes складаються з одного або декількох контейнерів, які виконуються на робочих вузлах. Контейнери використовують віртуалізацію на рівні ОС і, отже, пропонують слабку межу ізоляції порівняно з віртуальними машинами, які використовують апаратну віртуалізацію.

У спільному середовищі не виправлені вразливості на рівні застосунків та систем можуть бути використані зловмисниками для виходу контейнера за межі та виконання віддаленого коду, що дозволяє отримати доступ до ресурсів хосту. У деяких застосунках, наприклад, системах управління вмістом (CMS), користувачам може бути надана можливість завантажувати та виконувати ненадійні скрипти або код. В будь-якому випадку, механізми подальшої ізоляції та захисту робочих навантажень за допомогою сильної ізоляції бажані.

Утримання в пісочниці забезпечує спосіб ізоляції робочих навантажень, які запускаються в спільному кластері. Зазвичай це передбачає запуск кожного Podʼа в окремому середовищі виконання, такому як віртуальна машина або ядро простору рівня користувача. Утримання в пісочниці часто рекомендується, коли ви запускаєте ненадійний код, де робочі навантаження вважаються зловмисними. Частково це обумовлено тим, що контейнери — це процеси, які працюють на спільному ядрі; вони підключають файлові системи, такі як /sys та /proc, з базового хосту, що робить їх менш безпечними, ніж застосунок, який працює на віртуальній машині з власним ядром. Хоча такі контрольні механізми, як seccomp, AppArmor та SELinux, можуть бути використані для підвищення безпеки контейнерів, складно застосувати універсальний набір правил до всіх робочих навантажень, які запускаються в спільному кластері. Запуск робочих навантажень в середовищі пісочниці допомагає ізолювати хост від виходу контейнерів за межі, де зловмисник використовує вразливість, щоб отримати доступ до системи хосту та всіх процесів/файлів, що працюють на цьому хості.

Віртуальні машини та ядра користувацького простору — це 2 популярні підходи до пісочниці. Доступні наступні реалізації пісочниці:

  • gVisor перехоплює системні виклики з контейнерів та передає їх простору користувацького рівня ядра, написане на Go, з обмеженим доступом до базового хосту.
  • Kata Containers надають безпечний контейнерне середовище, що дозволяє виконувати контейнери в віртуальній машині. Апаратна віртуалізація, доступна в Kata, надає додатковий рівень безпеки для контейнерів, які запускають ненадійний код.

Ізоляція вузлів

Ізоляція вузлів — це ще один прийом, який можна використовувати для ізоляції робочих навантажень окремих орендарів один від одного. За допомогою ізоляції вузлів набір вузлів призначається для виконання Podʼів певного орендаря, і спільне розміщення Podʼів орендарів забороняється. Ця конфігурація зменшує проблему шумного орендаря, оскільки всі Podʼи, що працюють на вузлі, належать до одного орендаря. Ризик розкриття інформації трохи менше з ізоляцією вузлів, оскільки зловмисник, якому вдається вислизнути з контейнера, матиме доступ лише до контейнерів та томів, підключених до цього вузла.

Хоча робочі навантаження від різних орендарів працюють на різних вузлах, важливо памʼятати, що kubelet та (якщо використовується віртуальне керування) служба API все ще є спільними сервісами. Кваліфікований зловмисник може використовувати дозволи, надані kubelet або іншим Podʼам, що працюють на вузлі, для переміщення в межах кластера та отримання доступу до робочих навантажень орендарів, що працюють на інших вузлах. Якщо це є серйозною проблемою, розгляньте можливість впровадження компенсаційних заходів, таких як seccomp, AppArmor або SELinux, або дослідіть можливість використання Podʼів в пісочниці або створення окремих кластерів для кожного орендаря.

Ізоляція вузлів є трохи простішою з точки зору розрахунку, ніж утримання контейнерів у пісочниці, оскільки ви можете стягувати плату за кожен вузол, а не за кожен Pod. Вона також має менше проблем сумісності та продуктивності і може бути легше впроваджена, ніж утримання контейнерів у пісочниці. Наприклад, для кожного орендаря вузли можна налаштувати з taintʼами, щоб на них могли працювати лише Podʼи з відповідним toleration. Потім мутуючий веб-хук можна використовувати для автоматичного додавання толерантності та спорідненості вузлів до Podʼів, розгорнутих у просторах імен орендарів, щоб вони працювали на певному наборі вузлів, призначених для цього орендаря.

Ізоляцію вузлів можна реалізувати за допомогою селекторів вузла Podʼа або Virtual Kubelet.

На що також треба звертати увагу

У цьому розділі обговорюються інші конструкції та шаблони Kubernetes, які є важливими для багатоорендарних середовищ.

API Priority and Fairness

API Priority and Fairness — це функціональність Kubernetes, яка дозволяє призначити пріоритет певним Podʼам, що працюють у кластері. Коли застосунок викликає API Kubernetes, сервер API оцінює пріоритет, призначений для Podʼа. Виклики з Podʼів із вищим пріоритетом виконуються перш ніж ті, що мають нижчий пріоритет. Коли розбіжності високі, виклики з нижчим пріоритетом можуть бути поставлені в чергу до того часу, коли сервер стане менш зайнятим, або ви можете відхилити запити.

Використання API Priority and Fairness буде не дуже поширеним у середовищах SaaS, якщо ви не дозволяєте клієнтам запускати застосунки, які взаємодіють з API Kubernetes, наприклад, контролером.

Якість обслуговування (QoS)

Коли ви запускаєте застосунок SaaS, вам може знадобитися можливість надавати різні рівні якості обслуговування (QoS) для різних орендарів. Наприклад, ви можете мати безкоштовну службу з меншими гарантіями продуктивності та можливостями, або платну службу зі специфічними гарантіями продуктивності. На щастя, існують кілька конструкцій Kubernetes, які можуть допомогти вам досягти цього у спільному кластері, включаючи мережевий QoS, класи сховищ та пріоритети і випредження виконання Podʼів. Ідея полягає в тому, щоб надавати орендарям якість обслуговування, за яку вони заплатили. Давайте спочатку розглянемо мережевий QoS.

Зазвичай всі Podʼи на вузлі використовують один мережевий інтерфейс. Без мережевого QoS деякі Podʼи можуть споживати завелику частину доступної пропускної здатності, що шкодить іншим Podʼам. Kubernetes bandwidth plugin створює розширений ресурс для мережі, який дозволяє використовувати конструкції ресурсів Kubernetes, тобто запити/обмеження, щоб застосовувати обмеження швидкості до Podʼів за допомогою черг Linux tc. Варто зазначити, що втулок вважається експериментальним згідно з документацією про мережеві втулки і його слід ретельно перевірити перед використанням в продуктових середовищах.

Для керування QoS сховища вам, ймовірно, захочеться створити різні класи сховищ або профілі з різними характеристиками продуктивності. Кожен профіль сховища може бути повʼязаний з різним рівнем обслуговування, який оптимізований для різних завдань, таких як IO, надійність або пропускна здатність. Можливо, буде потрібна додаткова логіка для надання дозволу орендарю асоціювати відповідний профіль сховища з їхнім завданням.

Нарешті, є пріоритети та випредження виконання Podʼів, де ви можете призначити значення пріоритету Podʼів. При плануванні Podʼів планувальник спробує видаляти Podʼи з нижчим пріоритетом, коли недостатньо ресурсів для планування Podʼів із вищим пріоритетом. Якщо у вас є випадок використання, де орендарі мають різні рівні обслуговування в спільному кластері, наприклад, безкоштовні та платні, ви можете надати вищий пріоритет певним рівням за допомогою цієї функції.

DNS

У кластерах Kubernetes є служба системи доменних імен (DNS), щоб забезпечити переклад імен у IP-адреси для всіх Serviceʼів та Podʼів. Стандартно служба DNS Kubernetes дозволяє пошук у всіх просторах імен кластера.

У мультиорендних середовищах, де орендарі можуть отримувати доступ до Podʼів та інших ресурсів Kubernetes, або де потрібна сильніша ізоляція, може бути необхідно заборонити Podʼам здійснювати пошук служб в інших просторах імен. Ви можете обмежити пошук DNS між просторами імен, налаштувавши правила безпеки для служби DNS. Наприклад, CoreDNS (типова служба DNS для Kubernetes) може використовувати метадані Kubernetes для обмеження запитів до Podʼів та Serviceʼів в межах простору імен. Для отримання додаткової інформації подивіться приклад налаштування в документації CoreDNS.

Коли використовується модель віртуальної панелі управління для орендаря, службу DNS потрібно налаштувати для кожного орендара окремо або використовувати багатоорендну службу DNS. Ось приклад CoreDNS у зміненому вигляді, що підтримує кількох орендарів.

Оператори

Оператори — це контролери Kubernetes, які керують застосунками. Оператори можуть спростити управління кількома екземплярами програми, такими як служба баз даних, що робить їх загальним будівельним блоком у багатокористувацькому (SaaS) варіанті використання.

Оператори, які використовуються в середовищі з кількома орендарями, повинні дотримуватися більш суворого набору керівних принципів. Зокрема, Оператор повинен:

  • Підтримувати створення ресурсів у різних просторах імен орендарів, а не лише у просторі імен, в якому розгорнуто оператор.
  • Переконатись, що Podʼи налаштовані з запитами та обмеженнями ресурсів, щоб забезпечити планування та справедливість.
  • Підтримувати налаштування Podʼів для технік ізоляції панелі даних, таких як ізоляція вузла та контейнери в пісочниці.

Реалізації

Існують два основних способи поділу кластера Kubernetes для багатоорендності: використання просторів імен (тобто простір імен на орендаря) або віртуалізація панелі управління (тобто віртуальна панель управління на орендаря).

У обох випадках рекомендується також ізоляція панелі даних та керування додатковими аспектами, такими як API Priority and Fairness.

Ізоляція простору імен добре підтримується Kubernetes, має незначні витрати ресурсів і надає механізми, які дозволяють орендарям взаємодіяти належним чином, наприклад, дозволяючи комунікацію між Servicʼами. Однак її може бути складно налаштувати, і вона не застосовується до ресурсів Kubernetes, які не можуть розташовуватись в просоторах імен, таких як визначення спеціальних ресурсів, класи сховищ та веб-хуки.

Віртуалізація панелі управління дозволяє ізолювати ресурси, які не мають просторів імені, за рахунок трохи більшого використання ресурсів та складнішим спільним використанням між орендарями. Це хороший варіант, коли ізоляція простору імен недостатня, але виділені, окремі кластери небажані через великі витрати на їх утримання (особливо на місці) або через їх вищі накладні витрати та відсутність спільного використання ресурсів. Однак навіть у віртуальному плані управління ви, швидше за все, побачите переваги від використання просторів імен.

Два варіанти обговорюються докладніше у наступних розділах.

Простір імен на орендаря

Як вже зазначалося, варто розглянути ізоляцію кожного навантаження у власному просторі імен, навіть якщо ви використовуєте виключно спеціальні кластери або віртуалізовані панелі управління. Це забезпечує доступ кожного навантаження лише до власних ресурсів, таких як ConfigMap та Secret, і дозволяє налаштувати індивідуальні політики безпеки для кожного навантаження. Крім того, краще застосовувати унікальні назви для кожного простору імен у всьому вашому флоті (навіть якщо вони знаходяться у різних кластерах), оскільки це дозволяє вам в майбутньому переходити між спеціальними та спільними кластерами або використовувати багатокластерні інструменти, такі як сервісні мережі.

З іншого боку, є також переваги у призначенні просторів імен на рівні орендаря, а не лише на рівні навантаження, оскільки часто існують політики, що застосовуються до всіх навантажень, що належать одному орендарю. Однак це виникає власні проблеми. По-перше, це робить складним або неможливим налаштування політик для окремих навантажень, і, по-друге, може бути складно визначити єдиний рівень "оренди", який повинен мати простір імен. Наприклад, у організації можуть бути відділи, команди та підкоманди, які з них повинні бути призначені простору імен?

Для вирішення цього Kubernetes надає Контролер ієрархічних просторів імен (HNC), який дозволяє організовувати ваші простори імен у ієрархії та спільно використовувати певні політики та ресурси між ними. Він також допомагає вам керувати мітками просторів імен, життєвим циклом просторів імен та делегованим керуванням, а також спільно використовувати квоти ресурсів між повʼязаними просторами імен. Ці можливості можуть бути корисні як у багатокомандних, так і у багатокористувацьких сценаріях.

Інші проєкти, які надають подібні можливості та допомагають у керуванні просторами імен, перераховані нижче.

Багатокомандна оренда

Багатокористувацька оренда

Рушії політики

Рушії політики надають можливості для перевірки та генерації конфігурацій орендарів:

Віртуальна панель управління на орендаря

Ще один вид ізоляції панелі управління полягає у використанні розширень Kubernetes для надання кожному орендарю віртуальної панелі управління, що дозволяє сегментацію ресурсів API на рівні кластера. Техніки ізоляції панелі даних можна використовувати з цією моделлю для безпечного управління робочими вузлами між орендарями.

Модель багатокористувацької панелі управління на основі віртуального контролю розширює ізоляцію на основі простору імен шляхом надання кожному орендарю окремих компонентів панелі управління, а отже, повного контролю над ресурсами кластера і додатковими сервісами. Робочі вузли спільно використовуються всіма орендарями і керуються кластером Kubernetes, який зазвичай недоступний орендарям. Цей кластер часто називають суперкластером (іноді — хост кластер). Оскільки панель управління орендаря не прямо повʼязана з підлеглими обчислювальними ресурсами, її називають віртуальною панеллю управління.

Віртуальна панель управління зазвичай складається з сервера API Kubernetes, менеджера контролера та сховища даних etcd. Вона взаємодіє з суперкластером через контролер синхронізації метаданих, який координує зміни між панелями управління орендарів та панеллю управління суперкластера.

З використанням окремих віртуальних панелей управління для кожного орендаря вирішуються більшість проблем ізоляції, повʼязаних із тим, що всі орендарі використовують один сервер API. Прикладами є шумні сусіди в панелі управління, необмежений радіус вибуху неправильних налаштувань політики та конфлікти між обʼєктами на рівні кластера, такими як вебхуки та CRD. Таким чином, модель віртуальної панелі управління особливо підходить для випадків, коли кожен орендар потребує доступу до сервера API Kubernetes та очікує повного керування кластером.

Покращена ізоляція відбувається за рахунок запуску та підтримки окремих віртуальних панелей управління для кожного орендаря. Крім того, віртуальні панелі управління орендаря не вирішують проблеми ізоляції на рівні панелі даних, такі як шумні сусіди на рівні вузла або загрози безпеці. Ці проблеми все ще потрібно вирішувати окремо.

Проєкт Kubernetes Cluster API — Nested (CAPN) надає реалізацію віртуальних панелей управління.

Інші реалізації

3.8.11 - Поради з посилення безпеки — Механізми автентифікації

Інформація про варіанти автентифікації в Kubernetes та їх властивості безпеки.

Вибір відповідного механізму автентифікації — це ключовий аспект забезпечення безпеки вашого кластера. Kubernetes надає кілька вбудованих механізмів, кожен з власними перевагами та недоліками, які потрібно ретельно розглядати при виборі найкращого механізму автентифікації для вашого кластера.

Загалом рекомендується увімкнути як можливо менше механізмів автентифікації для спрощення управління користувачами та запобігання ситуаціям, коли користувачі мають доступ до кластера, який вже не потрібен.

Важливо зауважити, що Kubernetes не має вбудованої бази даних користувачів у межах кластера. Замість цього він бере інформацію про користувача з налаштованої системи автентифікації та використовує це для прийняття рішень щодо авторизації. Тому для аудиту доступу користувачів вам потрібно переглянути дані автентифікації з кожного налаштованого джерела автентифікації.

Для операційних кластерів з кількома користувачами, які безпосередньо отримують доступ до API Kubernetes, рекомендується використовувати зовнішні джерела автентифікації, такі як OIDC. Внутрішні механізми автентифікації, такі як сертифікати клієнта та токени службових облікових записів, описані нижче, не підходять для цього випадку використання.

Автентифікація сертифіката клієнта X.509

Kubernetes використовує автентифікацію сертифіката клієнта X.509 для системних компонентів, наприклад, коли Kubelet автентифікується на сервері API. Хоча цей механізм також можна використовувати для автентифікації користувачів, він може бути непридатним для операційного використання через кілька обмежень:

  • Сертифікати клієнта не можуть бути індивідуально скасовані. Після компрометації сертифікат може бути використаний зловмисником до тих пір, поки не закінчиться строк його дії. Для зменшення цього ризику рекомендується налаштувати короткі строки дії для автентифікаційних даних користувача, створених за допомогою клієнтських сертифікатів.
  • Якщо сертифікат потрібно анулювати, то потрібно змінити ключ сертифікації, що може призвести до ризиків доступності для кластера.
  • В кластері відсутній постійний запис про створені клієнтські сертифікати. Тому всі видані сертифікати повинні бути зафіксовані, якщо вам потрібно відстежувати їх.
  • Приватні ключі, що використовуються для автентифікації за допомогою клієнтського сертифіката, не можуть бути захищені паролем. Хто завгодно, хто може прочитати файл із ключем, зможе його використовувати.
  • Використання автентифікації за допомогою клієнтського сертифіката потребує прямого зʼєднання від клієнта до API-сервера без проміжних точок TLS, що може ускладнити архітектуру мережі.
  • Групові дані вбудовані в значення O клієнтського сертифіката, що означає, що членство користувача в групах не може бути змінено впродовж дії сертифіката.

Статичний файл токенів

Хоча Kubernetes дозволяє завантажувати облікові дані зі статичного файлу токенів, розташованого на дисках вузлів управління, цей підхід не рекомендується для операційних серверів з кількох причин:

  • Облікові дані зберігаються у відкритому вигляді на дисках вузлів управління, що може представляти ризик для безпеки.
  • Зміна будь-яких облікових даних потребує перезапуску процесу API-сервера для набуття чинності, що може вплинути на доступність.
  • Не існує механізму, доступного для того, щоб дозволити користувачам змінювати свої облікові дані. Для зміни облікових даних адміністратор кластера повинен змінити токен на диску та розповсюдити його серед користувачів.
  • Відсутність механізму блокування, який би запобігав атакам методом підбору.

Токени bootstrap

Токени bootstrap використовуються для приєднання вузлів до кластерів і не рекомендуються для автентифікації користувачів з кількох причин:

  • Вони мають затверджені членства у групах, які не підходять для загального використання, що робить їх непридатними для цілей автентифікації.
  • Ручне створення токенів bootstrap може призвести до створення слабких токенів, які може вгадати зловмисник, що може бути ризиком для безпеки.
  • Відсутність механізму блокування, який би запобігав атакам методом підбору, спрощує завдання зловмисникам для вгадування або підбору токена.

Secret токени ServiceAccount

Secret облікових записів служб доступні як опція для того, щоб дозволити робочим навантаженням, що працюють в кластері, автентифікуватися на сервері API. У версіях Kubernetes < 1.23 вони були типовою опцією, однак, їх замінюють токени API TokenRequest. Хоча ці Secretʼи можуть бути використані для автентифікації користувачів, вони, як правило, не підходять з кількох причин:

  • Їм неможливо встановити терміном дії, і вони залишатимуться чинними до тих пір, поки повʼязаний з ними обліковий запис служби не буде видалений.
  • Токени автентифікації видимі будь-якому користувачеві кластера, який може читати Secretʼи в просторі імен, в якому вони визначені.
  • Облікові записи служб не можуть бути додані до довільних груп, ускладнюючи управління RBAC там, де вони використовуються.

Токени API TokenRequest

API TokenRequest є корисним інструментом для генерації обмежених за часом існування автентифікаційних даних для автентифікації служб на сервері API або сторонніх системах. Проте, загалом не рекомендується використовувати їх для автентифікації користувачів, оскільки не існує методу скасування, і розподіл облікових даних користувачам у безпечний спосіб може бути складним.

При використанні токенів TokenRequest для автентифікації служб рекомендується встановити короткий термін їх дії, щоб зменшити можливі наслідки скомпрометованих токенів.

Автентифікація з використанням токенів OpenID Connect

Kubernetes підтримує інтеграцію зовнішніх служб автентифікації з API Kubernetes, використовуючи OpenID Connect (OIDC). Існує велика кількість програмного забезпечення, яке можна використовувати для інтеграції Kubernetes з постачальником ідентифікації. Однак, при використанні автентифікації OIDC для Kubernetes, важливо враховувати такі заходи з забезпечення безпеки:

  • Програмне забезпечення, встановлене в кластері для підтримки автентифікації OIDC, повинно бути відокремлене від загальних робочих навантажень, оскільки воно буде працювати з високими привілеями.
  • Деякі керовані Kubernetes сервіси обмежені в постачальниках OIDC, які можна використовувати.
  • Як і у випадку з токенами TokenRequest, токени OIDC повинні мати короткий термін дії, щоб зменшити наслідки скомпрометованих токенів.

Автентифікація з використанням вебхуків

Автентифікація з використанням вебхуків є ще одним варіантом інтеграції зовнішніх постачальників автентифікації в Kubernetes. Цей механізм дозволяє звертатися до служби автентифікації, яка працює в кластері або зовнішньо, для прийняття рішення щодо автентифікації через вебхук. Важливо зазначити, що придатність цього механізму, ймовірно, залежатиме від програмного забезпечення, використаного для служби автентифікації, і є деякі специфічні для Kubernetes аспекти, які варто врахувати.

Для налаштування автентифікації за допомогою вебхуків потрібний доступ до файлових систем серверів керування. Це означає, що це не буде можливо з керованим Kubernetes, якщо постачальник не зробить це специфічно доступним. Крім того, будь-яке програмне забезпечення, встановлене в кластері для підтримки цього доступу, повинно бути відокремлене від загальних робочих навантажень, оскільки воно буде працювати з високими привілеями.

Автентифікуючий проксі

Ще один варіант інтеграції зовнішніх систем автентифікації в Kubernetes — використання автентифікуючого проксі. У цьому механізмі Kubernetes очікує отримати запити від проксі з встановленими конкретними значеннями заголовків, які вказують імʼя користувача та членство в групах для призначення для цілей авторизації. Важливо зазначити, що існують певні аспекти, які слід врахувати при використанні цього механізму.

По-перше, для зменшення ризику перехоплення трафіку або атак типу sniffing між проксі та сервером API Kubernetes між ними має бути використане безпечне налаштування TLS. Це забезпечить безпеку комунікації між проксі та сервером API Kubernetes.

По-друге, важливо знати, що зловмисник, який може змінити заголовки запиту, може отримати неавторизований доступ до ресурсів Kubernetes. Тому важливо забезпечити належний захист заголовків та переконатися, що їх не можна підробити.

3.8.12 - Ризики обходу сервера API Kubernetes

Інформація про архітектуру безпеки, що стосується сервера API та інших компонентів

Сервер API Kubernetes є головним входом до кластера для зовнішніх сторін (користувачів та сервісів), що з ним взаємодіють.

У рамках цієї ролі сервер API має кілька ключових вбудованих елементів безпеки, таких як ведення логів аудити та контролери допуску. Однак існують способи модифікації конфігурації або вмісту кластера, які обминають ці елементи.

Ця сторінка описує способи обходу вбудованих в сервер API Kubernetes засобів контролю безпеки, щоб оператори кластера та архітектори безпеки могли переконатися, що ці обхідні механізми адекватно обмежені.

Статичні Podʼи

Kubelet на кожному вузлі завантажує та безпосередньо керує будь-якими маніфестами, що зберігаються в іменованій теці або завантажуються з конкретної URL-адреси як статичні Podʼи у вашому кластері. Сервер API не керує цими статичними Podʼами. Зловмисник з правами на запис у цьому місці може змінити конфігурацію статичних Podʼів, завантажених з цього джерела, або внести нові статичні Podʼи.

Статичним Podʼам заборонено доступ до інших обʼєктів у Kubernetes API. Наприклад, ви не можете налаштувати статичний Pod для монтування Secretʼу з кластера. Однак ці Podʼи можуть виконувати інші дії, що стосуються безпеки, наприклад, використовувати монтування з hostPath з підлеглого вузла.

Типово kubelet створює дзеркальний Pod, щоб статичні Podʼи були видимими у Kubernetes API. Однак якщо зловмисник використовує недійсне імʼя простору імен при створенні Podʼа, він не буде видимим у Kubernetes API та може бути виявлений лише інструментами, які мають доступ до пошкоджених вузлів.

Якщо статичний Pod не пройшов контроль допуску, kubelet не зареєструє Pod у сервері API. Однак Pod все ще працює на вузлі. Для отримання додаткової інформації зверніться до тікету kubeadm #1541.

Зменшення ризиків

  • Увімкніть функціональність маніфесту статичних Podʼів kubelet лише в разі необхідності для вузла.
  • Якщо вузол використовує функціональність статичних Podʼів, обмежте доступ до файлової системи до теки маніфестів статичних Podʼів або URL для користувачів, які потребують такого доступу.
  • Обмежте доступ до параметрів та файлів конфігурації kubelet, щоб запобігти зловмиснику встановлення шляху або URL статичного Podʼа.
  • Регулярно перевіряйте та централізовано звітуйте про всі доступи до тек або місць зберігання вебсайтів, які містять маніфести статичних Podʼів та файли конфігурації kubelet.

API kubelet

kubelet надає HTTP API, який, як правило, відкритий на TCP-порту 10250 на вузлах робочих груп кластера. API також може бути відкритим на вузлах панелі управління залежно від дистрибутиву Kubernetes, що використовується. Прямий доступ до API дозволяє розкривати інформацію про Podʼи, що працюють на вузлі, журнали з цих Podʼів та виконання команд у кожному контейнері, що працює на вузлі.

Коли у користувачів кластера Kubernetes є доступ RBAC до ресурсів обʼєкта Node, цей доступ слугує авторизацією для взаємодії з API kubelet. Точний доступ залежить від того, який доступ цим ресурсам був наданий, про що детально описано в авторизації kubelet.

Прямий доступ до API kubelet не є предметом уваги контролю допуску та не реєструється системою аудиту Kubernetes. Зловмисник з прямим доступом до цього API може здійснити обхід елементів захисту, що виявляють або запобігають певним діям.

API kubelet можна налаштувати для автентифікації запитів за допомогою кількох способів. Типово конфігурація kubelet дозволяє анонімний доступ. Більшість постачальників Kubernetes змінюють це на використання автентифікації за допомогою вебхуків та сертифікатів. Це дозволяє панелі управління перевірити, чи авторизований той хто надсилає запит має доступ до ресурсу API nodes або його ресурсів. Анонімний доступ типово не дає цього підтвердження панелі управління.

Зменшення ризиків

  • Обмежте доступ до ресурсів обʼєкта API nodes, використовуючи механізми, такі як RBAC. Надавайте цей доступ лише за необхідності, наприклад, для служб моніторингу.
  • Обмежте доступ до порту kubelet. Дозволяйте доступ до порту лише зазначеним та довіреним діапазонам IP-адрес.
  • Переконайтеся, що автентифікація kubelet налаштована на режим webhook або сертифікату.
  • Переконайтеся, що неавтентифікований "тільки для читання" порт kubelet не ввімкнено в кластері.

API etcd

Кластери Kubernetes використовують etcd як сховище даних. Сервіс etcd прослуховує TCP-порт 2379. Доступ до нього необхідний лише для сервера API Kubernetes та будь-яких інструментів резервного копіювання, які ви використовуєте. Прямий доступ до цього API дозволяє розголошення або зміну будь-яких даних, що зберігаються в кластері.

Доступ до API etcd зазвичай керується автентифікацією за допомогою сертифікатів клієнта. Будь-який сертифікат, виданий центром сертифікації, якому довіряє etcd, дозволяє повний доступ до даних, збережених всередині etcd.

Прямий доступ до etcd не підлягає контролю допуску Kubernetes і не реєструється журналом аудиту Kubernetes. Нападник, який має доступ до приватного ключа сертифіката клієнта etcd сервера API (або може створити новий довірений сертифікат клієнта), може отримати права адміністратора кластера, отримавши доступ до секретів кластера або зміни прав доступу. Навіть без підвищення привілеїв RBAC Kubernetes нападник, який може змінювати etcd, може отримати будь-який обʼєкт API або створювати нові робочі навантаження всередині кластера.

Багато постачальників Kubernetes налаштовують etcd для використання взаємного TLS (обидва, клієнт і сервер перевіряють сертифікати один одного для автентифікації). Наразі не існує загальноприйнятої реалізації авторизації для API etcd, хоча функція існує. Оскільки немає моделі авторизації, будь-який сертифікат з доступом клієнта до etcd може бути використаний для повного доступу до etcd. Зазвичай сертифікати клієнта etcd, які використовуються лише для перевірки стану, також можуть надавати повний доступ на читання та запис.

Зменшення ризиків

  • Переконайтеся, що центр сертифікації, якому довіряє etcd, використовується лише для цілей автентифікації цього сервісу.
  • Керуйте доступом до приватного ключа сертифіката сервера etcd, а також до сертифіката і ключа клієнта сервера API.
  • Призначте обмеження доступу до порту etcd на рівні мережі, щоб дозволити доступ лише зазначеним і довіреним діапазонам IP-адрес.

Сокет контейнера

На кожному вузлі в кластері Kubernetes доступ до взаємодії з контейнерами контролюється відносно контейнерного середовища (або середовищ, якщо ви налаштували більше одного). Зазвичай контейнерне середовище відкриває сокет Unix, до якого може отримати доступ kubelet. Нападник з доступом до цього сокету може запускати нові контейнери або взаємодіяти з працюючими контейнерами.

На рівні кластера вплив цього доступу залежить від того, чи мають контейнери, що працюють на скомпрометованому вузлі, доступ до Secretʼів або інших конфіденційних даних, які нападник може використати для підвищення привілеїв на інші вузли або для управління компонентами панелі управління.

Зменшення ризиків

  • Переконайтеся, що ви щільно контролюєте доступ до файлової системи для сокетів контейнерного середовища. Коли це можливо, обмежте цей доступ до користувача root.
  • Ізолюйте kubelet від інших компонентів, що працюють на вузлі, використовуючи механізми, такі як простори імен ядра Linux.
  • Переконайтеся, що ви обмежуєте або забороняєте використання монтуванню hostPath, які охоплюють робочий порт контейнерного середовища, або безпосередньо, або монтуванням батьківського каталогу. Крім того, монтування hostPath має бути встановлено тільки для читання для зменшення ризиків обходу обмежень каталогу.
  • Обмежте доступ користувачів до вузлів, особливо обмежте доступ суперкористувача до вузлів.

3.8.13 - Обмеження безпеки ядра Linux для Podʼів та контейнерів

Огляд модулів безпеки ядра Linux та обмежень, які можна використовувати для зміцнення вашого Podʼа та контейнерів.

Ця сторінка описує деякі з функцій безпеки, які вбудовані в ядро Linux і які ви можете використовувати у вашій роботі з Kubernetes. Щоб дізнатися, як застосувати ці функції до ваших Podʼів та контейнерів, див. Налаштування контексту безпеки для Podʼа або контейнера. Ви вже маєте бути знайомі з Linux та основами роботи з робочими навантаженням Kubernetes.

Запуск робочих навантажень без привілеїв адміністратора

Коли ви розгортаєте робоче навантаження в Kubernetes, використовуйте специфікацію Podʼа, щоб обмежити це навантаження від можливості запуску від імені користувача root на вузлі. Ви можете використовувати securityContext Podʼа, щоб визначити конкретного користувача та групу Linux для процесів у Podʼі, і явно обмежувати контейнери від запуску користувачем root. Встановлення цих значень у маніфесті Podʼа переважає аналогічні значення в образі контейнера, що особливо корисно, якщо ви запускаєте образи, які не належать вам.

Налаштування функцій безпеки ядра на цій сторінці надає деталізоване керування діями, які можуть виконувати процеси у вашому кластері, проте управління цими налаштуваннями може бути складним у великому масштабі. Запуск контейнерів від імені не-root користувача, або у просторах імен користувачів, якщо вам потрібні привілеї адміністратора, допомагає зменшити ймовірність того, що вам доведеться застосовувати встановлені функції безпеки ядра.

Функції безпеки в ядрі Linux

Kubernetes дозволяє вам налаштовувати та використовувати функції ядра Linux для покращення ізоляції та зміцнення ваших робочих навантажень у контейнерах. Серед загальних функцій:

  • Безпечний режим обчислення (seccomp): Фільтруйте, які системні виклики може робити процес
  • AppArmor: Обмежуйте привілеї доступу окремих програм
  • SELinux (Security Enhanced Linux): Назначайте мітки безпеки обʼєктам для простішого застосування політики безпеки

Для налаштування параметрів для однієї з цих функцій операційна система, яку ви обираєте для ваших вузлів, повинна увімкнути функцію у ядрі. Наприклад, Ubuntu 7.10 та пізніші версії стандартно увімкнені для AppArmor. Щоб дізнатися, чи увімкнено у вашій ОС певні функції, перегляньте документацію ОС.

Ви використовуєте поле securityContext у специфікації Podʼа, щоб визначити обмеження, які застосовуються до цих процесів. Поле securityContext також підтримує інші налаштування безпеки, такі як конкретні можливості Linux або дозволи на доступ до файлів за допомогою UID та GID. Докладніше див. Налаштування контексту безпеки для Podʼа або контейнера.

seccomp

Деякі з ваших робочих навантажень можуть потребувати привілеїв для виконання певних дій від імені користувача root на хостовій машині вашого вузла. Linux використовує можливості для розділення доступних привілеїв на категорії, щоб процеси могли отримати привілеї, необхідні для виконання певних дій без надання всіх привілеїв. Кожна можливість має набір системних викликів (syscalls), які може робити процес. seccomp дозволяє обмежувати ці окремі syscalls. Це може бути використано для ізоляції привілеїв процесу, обмежуючи виклики, які він може робити з простору користувача в ядро.

У Kubernetes ви використовуєте середовище виконання контейнерів на кожному вузлі для запуску ваших контейнерів. Прикладами середовища є CRI-O, Docker або containerd. Кожне середовище стандартно дозволяє лише певну підмножину можливостей Linux. Ви можете обмежити дозволені syscalls індивідуально за допомогою профілю seccomp. Зазвичай середовища виконання контейнерів містять стандартний профіль seccomp. Kubernetes дозволяє автоматично застосовувати профілі seccomp, завантажені на вузол, до ваших Podʼів та контейнерів.

Щоб дізнатись, як застосувати seccomp в Kubernetes, див. Обмеження системних викликів контейнера за допомогою seccomp.

Для отримання додаткової інформації про seccomp див. Seccomp BPF у документації ядра Linux.

Загальні положення щодо seccomp

seccomp — це конфігурація безпеки на низькому рівні, яку ви маєте налаштувати тільки у разі потреби в детальному контролі над системними викликами Linux. Використання seccomp, особливо на великих масштабах, має наступні ризики:

  • Конфігурації можуть ламатись під час оновлення програмного забезпечення
  • Зловмисники все ще можуть використовувати дозволені syscalls для використання вразливостей
  • Управління профілями для окремих застосунків стає складним на великих масштабах

Рекомендація: Використовуйте стандартний профіль seccomp, який поставляється разом із вашим середовищем виконання контейнерів. Якщо вам потрібна більш ізольоване середовище, розгляньте використання пісочниці, такої як gVisor. Пісочниці вирішують ризики, повʼязані з власними профілями seccomp, але вимагають більшого обсягу обчислювальних ресурсів на ваших вузлах та можуть мати проблеми сумісності з GPU та іншим спеціалізованим обладнанням.

AppArmor та SELinux: політика обовʼязкового контролю доступу

Ви можете використовувати механізми політики обовʼязкового контролю доступу (MAC) Linux, такі як AppArmor та SELinux, для зміцнення ваших робочих навантажень у Kubernetes.

AppArmor

AppArmor — це модуль безпеки ядра Linux, який доповнює стандартні дозволи на основі прав користувачів та груп Linux для обмеження доступу програм до обмеженого набору ресурсів. AppArmor може бути налаштований для будь-якого застосунку з метою зменшення його потенційної площини атаки та забезпечення глибшого захисту. Його налаштовують через профілі, настроєні на надання доступу, необхідного для конкретної програми або контейнера, такі як можливості Linux, мережевий доступ та дозволи на файли. Кожен профіль може працювати у режимі обовʼязкового виконання, який блокує доступ до заборонених ресурсів, або у режимі скарг, який лише реєструє порушення.

AppArmor може допомогти вам запустити більш безпечне розгортання, обмежуючи те, що контейнери мають право робити, або надавати кращі можливості аудиту через системні логи. Середовище виконання контейнерів, яке ви використовуєте, може поставлятися зі стандартним профілем AppArmor, або ви можете використовувати власний профіль.

Щоб дізнатись, як використовувати AppArmor у Kubernetes, див. Обмеження доступу контейнера до ресурсів за допомогою AppArmor.

SELinux

SELinu — це модуль безпеки ядра Linux, який дозволяє обмежувати доступ, який має певний субʼєкт, такий як процес, до файлів у вашій системі. Ви визначаєте політики безпеки, які застосовуються до субʼєктів з певними мітками SELinux. Коли процес, який має мітку SELinux, намагається отримати доступ до файлу, сервер SELinux перевіряє, чи дозволяє ця політика доступ та приймає рішення про авторизацію.

У Kubernetes ви можете встановити мітку SELinux у полі securityContext вашого маніфесту. Вказані мітки назначаються цим процесам. Якщо ви налаштували політики безпеки, які стосуються цих міток, ядро ОС хосту застосовує ці політики.

Щоб дізнатись, як використовувати SELinux у Kubernetes, див. Призначення міток SELinux контейнеру.

Різниця між AppArmor та SELinux

Операційна система на ваших вузлах Linux зазвичай містить один з механізмів захисту, або AppArmor, або SELinux. Обидва механізми забезпечують схожий тип захисту, але мають різниці, такі як:

  • Налаштування: AppArmor використовує профілі для визначення доступу до ресурсів. SELinux використовує політики, які застосовуються до певних міток.
  • Застосування політики: В AppArmor ви визначаєте ресурси за допомогою шляхів до файлів. SELinux використовує індексний вузол (inode) ресурсу для ідентифікації ресурсу.

Підсумок функцій

У таблиці нижче наведено використання та область застосування кожного контролю безпеки. Ви можете використовувати всі їх разом для створення більш захищеної системи.

Підсумок функцій безпеки ядра Linux
Функція безпекиОписЯк використовуватиПриклад
seccompОбмежуйте окремі виклики ядра в просторі користувача. Зменшує ймовірність того, що вразливість, яка використовує обмежений системний виклик, скомпрометує систему.Вказуйте завантажений профіль seccomp у специфікації Podʼа або контейнера, щоб застосувати його обмеження до процесів у Podʼі.Відхиляйте системні виклики unshare, які використовувались у [CVE-2022-0185](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-0185).
AppArmorОбмежуйте доступ програм до певних ресурсів. Зменшує поверхню атаки програми. Покращує аудит.Вкажіть завантажений профіль AppArmor у специфікації контейнера.Обмежити програму, яка працює тільки для читання, в записі будь-якого шляху до файлу у системі.
SELinuxОбмежуйте доступ до ресурсів, таких як файли, застосунки, порти та процеси за допомогою міток та політик безпеки.Вкажіть обмеження доступу для конкретних міток. Позначте процеси цими мітками, щоб застосувати обмеження доступу, повʼязані з міткою.Обмежити контейнер у доступі до файлів поза його власною файловою системою.

Загальні відомості щодо керування власними конфігураціями

seccomp, AppArmor та SELinux зазвичай мають стандартну конфігурацію, яка надає базовий захист. Ви також можете створити власні профілі та політики, які відповідають вимогам ваших робочих навантажень. Управління та розповсюдження цих власних конфігурацій на великому масштабі може бути складним, особливо якщо ви використовуєте всі три функції разом. Щоб допомогти вам керувати цими конфігураціями на великому масштабі, використовуйте інструмент, такий як Kubernetes Security Profiles Operator.

Функції безпеки на рівні ядра та привілейовані контейнери

Kubernetes дозволяє вам вказувати, що деякі довірені контейнери можуть працювати у привілейованому режимі. Будь-який контейнер у Podʼі може працювати у привілейованому режимі для використання адміністративних можливостей операційної системи, які інакше були б недоступні. Це доступно як для Windows, так і для Linux.

Привілейовані контейнери явно перевизначають деякі обмеження ядра Linux, які ви можливо використовуєте у ваших робочих навантаженнях, наступним чином:

  • seccomp: Привілейовані контейнери працюють як профіль Unconfined seccomp, перевизначаючи будь-який профіль seccomp, який ви вказали у своєму маніфесті.
  • AppArmor: Привілейовані контейнери ігнорують будь-які застосовані профілі AppArmor.
  • SELinux: Привілейовані контейнери працюють як домен unconfined_t.

Привілейовані контейнери

Будь-який контейнер у Podʼі може увімкнути привілейований режим, якщо ви встановите поле privileged: true у securityContext поле для контейнера. Привілейовані контейнери перевизначають або скасовують багато інших налаштувань зміцнення захисту, таких як застосований профіль seccomp, профіль AppArmor або обмеження SELinux. Привілейовані контейнери отримують всі можливості Linux, включаючи можливості, яких їм не потрібно. Наприклад, користувач root у привілейованому контейнері може мати можливість використовувати можливості CAP_SYS_ADMIN та CAP_NET_ADMIN на вузлі, оминання конфігурації часу виконання seccomp та інших обмежень.

У більшості випадків ви повинні уникати використання привілейованих контейнерів і натомість надавати конкретні можливості, необхідні для вашого контейнера, використовуючи поле capabilities у полі securityContext. Використовуйте привілейований режим лише у випадках, коли у вас є можливість, яку ви не можете надати за допомогою securityContext. Це корисно для контейнерів, які хочуть використовувати адміністративні можливості операційної системи, такі як керування мережевим стеком або доступ до апаратного забезпечення.

У версії Kubernetes 1.26 та пізніше ви також можете запускати контейнери Windows у подібному привілейованому режимі, встановивши прапорець windowsOptions.hostProcess у контексті безпеки специфікації Podʼа. Для отримання докладної інформації та інструкцій див. Створення Podʼа HostProcess для Windows.

Рекомендації та поради

  • Перш ніж налаштовувати можливості безпеки на рівні ядра, вам слід розглянути впровадження ізоляції на рівні мережі. Для отримання додаткової інформації прочитайте Перелік заходів безпеки.
  • Крім того, якщо це необхідно, запускайте робочі навантаження Linux як непривілейовані, вказавши конкретні ідентифікатори користувача та групи у вашому маніфесті Podʼа та, вказавши runAsNonRoot: true.

Крім того, ви можете запускати робочі навантаження в просторах користувачів, встановивши hostUsers: false у вашому маніфесті Podʼа. Це дозволяє запускати контейнери від імені користувачів root у просторі користувачів, але як не-root користувача в просторі користувачів на вузлі. Це все ще знаходиться на ранніх етапах розробки та може не мати необхідного рівня підтримки, який вам потрібно. Для отримання інструкцій див. Використання простору користувачів з Podʼом.

Що далі

3.8.14 - Список перевірок безпеки

Базовий список для забезпечення безпеки в кластерах Kubernetes.

Цей список має на меті надати базовий перелік рекомендацій з посиланнями на більш комплексну документацію з кожної теми. Він не претендує на повноту і може змінюватись.

Як користуватись цим документом:

  • Порядок тем не відображає порядок пріоритетів.
  • Деякі пункти списку розкриваються в абзац нижче переліку кожної секції.

Автентифікація та авторизація

  • Група system:masters не використовується для автентифікації користувачів чи компонентів після першого налаштування.
  • Компонент kube-controller-manager працює з увімкненим параметром --use-service-account-credentials.
  • Кореневий сертифікат захищений (або офлайн CA, або керований онлайн CA з ефективними елементами керування доступом).
  • Проміжний та листовий сертифікати мають строк дії не більше ніж 3 роки вперед.
  • Існує процес періодичного перегляду доступу, і перегляди проводяться не рідше ніж через кожні 24 місяці.
  • Дотримуються рекомендації щодо контролю доступу на основі ролей щодо автентифікації та авторизації.

Після першої налаштування ні користувачі, ні компоненти не повинні автентифікуватися в API Kubernetes як system:masters. Так само, варто уникати використання всіх компонентів kube-controller-manager як system:masters. Фактично, system:masters повинен використовуватися лише як механізм для виходу з аварійної ситуації, а не як адміністративний користувач.

Безпека мережі

  • Використані CNI-втулки підтримують політики мережі.
  • Політики мережі вхідного та вихідного трафіку застосовані до всіх навантажень в кластері.
  • У кожному просторі імен встановлені типові політики мережі, які вибирають всі Podʼи та забороняють все.
  • У разі необхідності використано сервісну сітку (service mesh) для шифрування всіх зʼєднань всередині кластера.
  • API Kubernetes, API kubelet та etcd не викладені публічно в Інтернеті.
  • Доступ від навантажень до API хмарних метаданих фільтрується.
  • Використання LoadBalancer та ExternalIPs обмежено.

Багато втулків мережевого інтерфейсу контейнера (CNI) забезпечують функціональність обмеження ресурсів мережі, з якими можуть спілкуватися Podʼи. Найчастіше це робиться за допомогою мережевих політик, які надають ресурс з простором імен для визначення правил. Типові політики мережі, які блокують вхідний та вихідний трафік, у кожному просторі імен, вибираючи всі Podʼи, можуть бути корисні для прийняття списку дозволів, щоб переконатися, що жодне навантаження не пропущене.

Не всі CNI-втулки надають шифрування під час транзиту. Якщо обраний втулок не має цієї функції, альтернативним рішенням може бути використання сервісної сітки для надання цієї функціональності.

Дані etcd панелі управління повинні мати елементи для обмеження доступу і не повинні бути публічно викладені в Інтернеті. Крім того, для безпечного звʼязку з нею має використовуватись взаємний TLS (mTLS). Центр сертифікації для цього повинен бути унікальним для etcd.

Зовнішній Інтернет-доступ до сервера API Kubernetes повинен бути обмежений, щоб не викладати API публічно. Будьте обережні, оскільки багато дистрибутивів Kubernetes, що надаються постачальниками послуг, стандартно викладають сервер API публічно. Потім можна використовувати хост-бастион для доступу до сервера.

Доступ до API kubelet повинен бути обмежений і не викладений публічно, стандартні налаштування автентифікації та авторизації, коли не вказаний файл конфігурації з прапорцем --config, є занадто дозвільними.

Якщо для розміщення Kubernetes використовується хмарний провайдер, доступ від навантажень до API хмарних метаданих 169.254.169.254 також повинен бути обмежений або заблокований, якщо він не потрібний, оскільки це може робити можливим витік інформації.

Для обмеженого використання LoadBalancer та ExternalIPs див. CVE-2020-8554: Man in the middle using LoadBalancer or ExternalIPs та контролер відмови ExternalIPs для отримання додаткової інформації.

Безпека Podʼів

  • Права RBAC create, update, patch, delete навантажень надаються лише за необхідності.
  • Для всіх просторів імен застосована та використовується відповідна політика стандартів безпеки Podʼів.
  • Ліміт памʼяті встановлено для навантажень з обмеженням, рівним або меншим за запит.
  • Ліміт CPU може бути встановлено для чутливих навантажень.
  • Для вузлів, що його підтримують, увімкнено Seccomp з відповідними профілями syscalls для програм.
  • Для вузлів, що його підтримують, увімкнено AppArmor або SELinux з відповідним профілем для програм.

Авторизація RBAC є важливою, але не може бути достатньо гранульованою для надання авторизації ресурсам Podʼів (або будь-якому ресурсу, який керує Podʼами). Єдиною гранулярністю є дії API на сам ресурс, наприклад, створення Podʼів. Без додаткового допуску, авторизація на створення цих ресурсів дозволяє прямий необмежений доступ до призначених для планування вузлів кластера.

Стандарти безпеки Podʼів визначають три різних політики: privileged, baseline та restricted, які обмежують, як поля можуть бути встановлені в PodSpec щодо безпеки. Ці стандарти можуть бути накладені на рівні простору імен за допомогою нового допуску безпеки Podʼів, ввімкненого стандартно, або за допомогою стороннього вебхуку допуску. Зауважте, що, на відміну від видаленого PodSecurityPolicy, яке він замінює, допуск безпеки Podʼів може легко поєднуватися з вебхуками допусків та зовнішніми службами.

Політика restricted безпеки Podʼів, найбільш обмежувальна політика зі стандартного набору безпеки Podʼів, може працювати у кількох режимах, warn, audit або enforce, щоб поступово застосовувати найбільш відповідний контекст безпеки відповідно до найкращих практик з безпеки. З усім тим, контекст безпеки Podʼів повинен окремо досліджуватися для обмеження привілеїв та доступу, які можуть мати Podʼи, крім попередньо визначених стандартів безпеки, для конкретних випадків використання.

Для підручника з безпеки Podʼів див. блог пост Kubernetes 1.23: Політика безпеки Podʼів переходить до бета-версії.

Ліміти памʼяті та CPU повинні бути встановлені для обмеження памʼяті та CPU, які може споживати Pod на вузлі, та, отже, запобігають можливим атакам DoS від зловмисних або порушених робочих навантажень. Така політика може бути накладена контролером допуску. Зверніть увагу, що ліміти CPU будуть обмежувати використання і можуть мати непередбачені наслідки для функцій автоматичного масштабування або ефективності, тобто виконання процесу з найкращими спробами з доступними ресурсами CPU.

Увімкнення Seccomp

Seccomp (secure computing mode) є функцією ядра Linux з версії 2.6.12. Він може бути використаний для ізоляції привілеїв процесу, обмежуючи виклики, які він може зробити з простору користувача в ядро. Kubernetes дозволяє автоматично застосовувати профілі seccomp, завантажені на вузол, до ваших Podʼів і контейнерів.

Seccomp може покращити безпеку вашого навантаження, зменшуючи доступну для атак на ядро Linux поверхню викликів системного виклику всередині контейнерів. Режим фільтрації seccomp використовує BPF для створення списку дозволених або заборонених конкретних системних викликів, які називаються профілями.

Починаючи з Kubernetes 1.27, ви можете увімкнути використання RuntimeDefault як типового профілю seccomp для всіх навантажень. Існує посібник з безпеки на цю тему. Крім того, Оператор профілів безпеки Kubernetes — це проєкт, який сприяє управлінню та використанню seccomp в кластерах.

Увімкнення AppArmor або SELinux

AppArmor

AppArmor — це модуль безпеки ядра Linux, який може забезпечити простий спосіб реалізації обовʼязкового контролю доступу (MAC, Mandatory Access Control) та кращого аудиту через системні логи. На вузлах, які його підтримують, застосовується стандартний профіль AppArmor, або може бути налаштований власний профіль. Як і seccomp, AppArmor також налаштовується через профілі, де кожен профіль працює в посиленому режимі, який блокує доступ до заборонених ресурсів, або в режимі скарг, який лише повідомляє про порушення. Профілі AppArmor застосовуються на рівні контейнера з анотацією, що дозволяє процесам отримати лише необхідні привілеї.

SELinux

SELinux також є модулем безпеки ядра Linux, який може забезпечити механізм для підтримки політик безпеки контролю доступу, включаючи обовʼязковий контроль доступу (MAC). Мітки SELinux можуть бути призначені для контейнерів або Podʼів через їх розділ securityContext.

Логи та аудит

  • Логи аудиту, якщо вони увімкнені, захищені від загального доступу.

Розташування Podʼів

  • Розташування Podʼів виконане відповідно до рівнів чутливості застосунку.
  • Чутливі застосунки працюють в ізольованому вигляді на вузлах або зі специфічними середовищами виконання, розміщеними в пісочниці.

Podʼи, які належать до різних рівнів чутливості, наприклад, Podʼи застосунку та сервера Kubernetes API, повинні бути розгорнуті на окремих вузлах. Метою ізоляції вузла є запобігання виходу з контейнера застосунку до прямого надання доступу до застосунків з вищим рівнем чутливості для легкого перехоплення у кластері. Це розділення повинно бути накладене для запобігання помилкового розгортання Podʼів на той самий вузол. Це можна забезпечити за допомогою таких функцій:

Селектори вузла
Пари ключ-значення, як частина специфікації Podʼів, що вказують, на які вузли їх розгорнути. Це може бути встановлено на рівні простору імен та кластера за допомогою контролера допуску PodNodeSelector.
PodTolerationRestriction
Контролер допуску, який дозволяє адміністраторам обмежувати дозволені толерантності в межах простору імен. Podʼів в межах простору імен можуть використовувати тільки толерантності, вказані в ключах анотацій обʼєктів простору імен, які надають типовий та дозволений набір толерантностей.
RuntimeClass
RuntimeClass — це функція для вибору конфігурації контейнера для запуску. Конфігурація контейнера використовується для запуску контейнерів Podʼів і може забезпечувати більшу або меншу ізоляцію від хосту коштом продуктивності.

Secret

  • ConfigMap не використовуються для зберігання конфіденційних даних.
  • Шифрування у спокої для Secret API налаштоване.
  • Якщо це необхідно, механізм для вбудовування Secret, збережених у сторонньому сховищі, розгорнуто та доступний.
  • Токени облікового запису служби не монтується в Podʼах, які не потребують їх.
  • Використовується привʼязанний том токенів облікового запису служби замість нескінченних токенів.

Secret, необхідні для Podʼів, повинні зберігатися у Secretʼах Kubernetes, на відміну від альтернатив, таких як ConfigMap. Ресурси Secret, збережені в etcd, повинні бути зашифровані у спокої.

Podʼи, що потребують Secret, повинні автоматично мати їх змонтовані через томи, попередньо збережені у памʼяті, наприклад, за допомогою опції emptyDir.medium. Механізм може бути використаний також для введення Secret зі сторонніх сховищ як томів, наприклад, Secrets Store CSI Driver. Це слід робити переважно порівняно з наданням Podʼам облікових записів служб доступу RBAC до Secret. Це дозволить додавати Secret до Podʼів як змінні середовища або файли. Зверніть увагу, що метод змінних середовища може бути більш схильним до витоку через аварійні записи в логах та неконфіденційний характер змінної середовища в Linux, на відміну від механізму дозволу на файли.

Токени облікових записів служби не повинні монтуватися в Podʼи, які не потребують їх. Це можна налаштувати, встановивши automountServiceAccountToken в значення false або для облікового запису служби, щоб застосувати це на всі простори імен або конкретно для Podʼа. Для Kubernetes v1.22 і новіше використовуйте привʼязані облікові записи служб для часово обмежених облікових записів служби.

Образи

  • Мінімізувати непотрібний вміст у образах контейнера.
  • Контейнерні образи налаштовані на запуск з правами непривілейованого користувача.
  • Посилання на контейнерні образи виконуються за допомогою хешів sha256 (замість міток), або походження образу перевіряється шляхом перевірки цифрового підпису образу під час розгортання через контролер допуску.
  • Контейнерні образи регулярно скануються під час створення та розгортання, і відоме вразливе програмне забезпечення піддається патчингу.

Контейнерний образ має містити мінімум необхідного для запуску програми, яку він упаковує. Найкраще, тільки програму та її залежності, створюючи образи з мінімально можливою базою. Зокрема, образи, які використовуються в операційній діяльності, не повинні містити оболонки або засоби налагодження, оскільки для усунення несправностей може використовуватися ефемерний контейнер для налагодження.

Побудуйте образи для прямого запуску від непривілейованого користувача, використовуючи інструкцію USER у Dockerfile. Контекст безпеки дозволяє запускати контейнерні образи з певним користувачем та групою за допомогою параметрів runAsUser та runAsGroup, навіть якщо вони не вказані у маніфесті образу. Однак дозволи на файли у шарах образів можуть зробити неможливим просто запуск процесу з новим непривілейованим користувачем без модифікації образу.

Уникайте використання міток для посилання на образи, особливо мітки latest, образи з міткою можуть бути легко змінені у реєстрі. Краще використовувати повний хеш sha256, який унікальний для маніфесту образу. Цю політику можна накладати за допомогою ImagePolicyWebhook. Підписи образів також можуть бути автоматично перевірені контролером допуску під час розгортання для перевірки їх автентичності та цілісності.

Сканування контейнерних образів може запобігти розгортанню критичних вразливостей у кластері разом з контейнерним образом. Сканування образів повинно бути завершено перед розгортанням контейнерного образу в кластері та, як правило, виконується як частина процесу розгортання у CI/CD конвеєрі. Метою сканування образу є отримання інформації про можливі вразливості та їх запобігання в контейнерному образі, такої як оцінка Загальної системи оцінки вразливостей (CVSS). Якщо результати сканування образів поєднуються з правилами відповідності конвеєра, операційне середовище буде використовувати лише належно виправлені контейнерні образи.

Контролери допуску

  • Включено відповідний вибір контролерів допуску.
  • Політика безпеки підпорядкована контролеру допуску про безпеку або/і вебхуку контролера допуску.
  • Втулки ланцюжка допуску та вебхуки надійно налаштовані.

Контролери допуску можуть допомогти покращити безпеку кластера. Однак вони можуть представляти ризики самі по собі, оскільки розширюють API-сервер і повинні бути належним чином захищені.

У наступних списках наведено кілька контролерів допуску, які можуть бути розглянуті для покращення безпеки вашого кластера та застосунків. Вони включають контролери, на які є посилання в інших частинах цього документа.

Ця перша група контролерів допуску включає втулки, типово увімкнені, розгляньте можливість залишити їх увімкненими, якщо ви розумієте, що робите:

CertificateApproval
Здійснює додаткові перевірки авторизації, щоб переконатися, що користувач, який затверджує, має дозвіл на затвердження запиту на отримання сертифіката.
CertificateSigning
Здійснює додаткові перевірки авторизації, щоб переконатися, що користувач, який підписує, має дозвіл на підписування запитів на отримання сертифіката.
CertificateSubjectRestriction
Відхиляє будь-який запит на сертифікат, який вказує 'групу' (або 'організаційний атрибут') system:masters.
LimitRanger
Застосовує обмеження API-контролера обмежень.
MutatingAdmissionWebhook
Дозволяє використання власних контролерів через вебхуки, ці контролери можуть змінювати запити, які вони переглядають.
PodSecurity
Заміна політики безпеки контейнера, обмежує контексти безпеки розгорнутих контейнерів.
ResourceQuota
Застосовує обмеження ресурсів для запобігання перевикористанню ресурсів.
ValidatingAdmissionWebhook
Дозволяє використання власних контролерів через вебхуки, ці контролери не змінюють запити, які вони переглядають.

Друга група включає втулки, які типово не увімкнені, але знаходяться в стані загальної доступності та рекомендуються для покращення вашої безпеки:

DenyServiceExternalIPs
Відхиляє всю нову мережеву взаємодію з полем Service.spec.externalIPs. Це захист від CVE-2020-8554: Man in the middle using LoadBalancer or ExternalIPs.
NodeRestriction
Обмежує дозволи kubelet тільки на модифікацію ресурсів API для точок доступу керування мережевими підключеннями, якими він володіє або ресурсу API вузла, які представляють себе. Він також заважає використанню kubelet анотації node-restriction.kubernetes.io/, яку може використовувати зловмисник з доступом до облікових даних kubelet, щоб вплинути на розміщення Podʼа на вузлі.

Третя група включає втулки, які за стандартно не увімкнені, але можуть бути розглянуті для певних випадків використання:

AlwaysPullImages
Застосовує використання останньої версії мітки образу та перевіряє, чи дозволи використання образ має той, хто здійснює розгортання.
ImagePolicyWebhook
Дозволяє застосовувати додаткові контролери для образів через вебхуки.

Що далі

3.9 - Політики

Керування безпекою та найкращі практики застосування політик.

Політики Kubernetes — це конфігурації, які керують поведінкою інших конфігурацій чи ресурсів. Kubernetes надає кілька різних рівнів політик, про які можна дізнатися в цьому розділі.

Застосування політик за допомогою обʼєктів API

Деякі обʼєкти API виступають як політики. Ось деякі приклади:

  • NetworkPolicies можуть бути використані для обмеження вхідного та вихідного трафіку для робочого навантаження.
  • LimitRanges керують обмеженнями розподілу ресурсів між різними типами обʼєктів.
  • ResourceQuotas обмежують споживання ресурсів для простору імен.

Застосування політик за допомогою admission-контролерів

Admission контролер працює в API-сервері та може перевіряти або змінювати запити до API. Деякі admission-контролери виступають як політики. Наприклад, admission-контролер AlwaysPullImages змінює новий обʼєкт Pod, щоб встановити політику завантаження образу на Always.

У Kubernetes є кілька вбудованих admission-контролерів, які можна налаштувати за допомогою прапорця --enable-admission-plugins API-сервера.

Детальні відомості про admission-контролери, з повним списком доступних admission-контролерів, ви знайдете в окремому розділі:

Застосування політик за допомогою ValidatingAdmissionPolicy

Перевірка політик допуску дозволяє виконувати налаштовані перевірки в API-сервері за допомогою мови виразів Common Expression Language (CEL). Наприклад, ValidatingAdmissionPolicy може бути використаний для заборони використання образів з теґом latest.

ValidatingAdmissionPolicy працює з запитом до API та може бути використаний для блокування, аудиту та попередження користувачів про невідповідні конфігурації.

Детальні відомості про API ValidatingAdmissionPolicy з прикладами ви знайдете в окремому розділі:

Застосування політик за допомогою динамічного контролю допуску

Контролери динамічного допуску (або вхідні вебхуки) працюють поза API-сервером як окремі застосунки, які реєструються для отримання запитів вебхуків для виконання перевірки або зміни запитів до API.

Контролери динамічного допуску можуть бути використані для застосування політик до запитів до API та спрацьовувати інші робочі процеси на основі політик. Контролер динамічного допуску може виконувати складні перевірки, включаючи ті, які вимагають отримання інших ресурсів кластера та зовнішніх даних. Наприклад, звірка перевірки образу може виконувати пошук даних у реєстрах OCI для перевірки підписів та атестації образу контейнерів.

Детальні відомості про динамічний контроль допуску ви знайдете в окремому розділі:

Реалізації

Контролери динамічного допуску, які виступають як гнучкі рушії політик, розробляються в екосистемі Kubernetes, серед них:

Застосування політик за конфігурацій Kubelet

Kubeletʼи дозволяють налаштовувати політики для кожного робочого вузла. Деякі конфігурації Kubeletʼів працюють як політики:

  • Резурвування та ліміти Process ID використовуються для обмеження та резервування PID.
  • Менеджер ресурсів вузлів може бути використаний для керування обчислювальними ресурсами, ресурсами памʼяті та ресурсами пристроїв для високопропускних та критичних до затримок робочих навантажень.

3.9.1 - Обмеження діапазонів

Типово контейнери запускаються з необмеженими обчислювальними ресурсами у кластері Kubernetes. Використовуючи квоти ресурсів Kubernetes, адміністратори (оператори кластера) можуть обмежити споживання та створення ресурсів кластера (таких як час ЦП, памʼять та постійне сховище) у визначеному namespace. У межах простору імен Pod може використовувати стільки ЦП та памʼяті, скільки дозволяють ResourceQuotas, що застосовуються до цього простору імен. Як оператору кластера або адміністратору на рівні простору імен вам також може бути важливо переконатися, що один обʼєкт не може монополізувати всі доступні ресурси у просторі імен.

LimitRange — це політика обмеження виділення ресурсів (ліміти та запити), яку можна вказати для кожного відповідного типу обʼєкта (такого як Pod або PersistentVolumeClaim) у просторі імен.

LimitRange надає обмеження, які можуть:

  • Застосовувати мінімальні та максимальні витрати обчислювальних ресурсів на Pod або Контейнер у просторі імен.
  • Застосовувати мінімальний та максимальний запит на сховище для PersistentVolumeClaim у просторі імен.
  • Застосовувати співвідношення між запитом та лімітом для ресурсу у просторі імен.
  • Встановлювати стандартний запит/ліміт для обчислювальних ресурсів у просторі імен та автоматично вставляти їх у контейнери під час виконання.

Обмеження діапазону діє в певному просторі імен, коли існує обʼєкт LimitRange у цьому просторі імен.

Назва обʼєкта LimitRange повинна бути дійсним піддоменом DNS.

Обмеження на ліміти ресурсів та запити

  • Адміністратор створює обмеження діапазону у просторі імен.
  • Користувачі створюють (або намагаються створити) обʼєкти у цьому просторі імен, такі як Podʼи або PersistentVolumeClaims.
  • По-перше, контролер допуску LimitRange застосовує типове значення запиту та ліміту для всіх Podʼів (та їхніх контейнерів), які не встановлюють вимоги щодо обчислювальних ресурсів.
  • По-друге, LimitRange відстежує використання, щоб забезпечити, що воно не перевищує мінімальне, максимальне та співвідношення ресурсів, визначених в будь-якому LimitRange, присутньому у просторі імен.
  • Якщо ви намагаєтеся створити або оновити обʼєкт (Pod або PersistentVolumeClaim), який порушує обмеження LimitRange, ваш запит до сервера API буде відхилено з HTTP-кодом стану 403 Forbidden та повідомленням, що пояснює порушене обмеження.
  • Якщо додати LimitRange в простір імен, який застосовується до обчислювальних ресурсів, таких як cpu та memory, необхідно вказати запити або ліміти для цих значень. В іншому випадку система може відхилити створення Podʼа.
  • Перевірка LimitRange відбувається тільки на етапі надання дозволу Podʼу, а не на працюючих Podʼах. Якщо ви додаєте або змінюєте LimitRange, Podʼи, які вже існують у цьому просторі імен, залишаються без змін.
  • Якщо у просторі імен існує два або більше обʼєкти LimitRange, то не визначено, яке типове значення буде застосовано.

LimitRange та перевірки допуску для Podʼів

LimitRange не перевіряє типово послідовність застосованих значень. Це означає, що стандартні значення для limit, встановлене LimitRange, може бути меншим за значення request, вказане для контейнера в специфікації, яку клієнт надсилає на сервер API. Якщо це станеться, Pod не буде запланованим.

Наприклад, ви визначаєте LimitRange цим маніфестом:

apiVersion: v1
kind: LimitRange
metadata:
  name: cpu-resource-constraint
spec:
  limits:
  - default: # ця секція визначає типові обмеження
      cpu: 500m
    defaultRequest: # ця секція визначає типові запити
      cpu: 500m
    max: # max та min визначают діапазон обмеження
      cpu: "1"
    min:
      cpu: 100m
    type: Container

разом з Podʼом, який вказує на запит ресурсу ЦП 700m, але не на ліміт:

apiVersion: v1
kind: Pod
metadata:
  name: example-conflict-with-limitrange-cpu
spec:
  containers:
  - name: demo
    image: registry.k8s.io/pause:2.0
    resources:
      requests:
        cpu: 700m

тоді цей Pod не буде запланованим, і він відмовиться з помилкою, схожою на:

Pod "example-conflict-with-limitrange-cpu" is invalid: spec.containers[0].resources.requests: Invalid value: "700m": must be less than or equal to cpu limit

Якщо ви встановите як request, так і limit, то цей новий Pod буде успішно запланований, навіть з тим самим LimitRange:

apiVersion: v1
kind: Pod
metadata:
  name: example-no-conflict-with-limitrange-cpu
spec:
  containers:
  - name: demo
    image: registry.k8s.io/pause:2.0
    resources:
      requests:
        cpu: 700m
      limits:
        cpu: 700m

Приклади обмежень ресурсів

Приклади політик, які можна створити за допомогою LimitRange, такі:

  • У кластері з 2 вузлами з місткістю 8 ГБ ОЗП та 16 ядрами обмежте Podʼи в просторі імен на роботу з 100m CPU з максимальним лімітом 500m для CPU та запит 200Mi для памʼяті з максимальним лімітом 600Mi для памʼяті.
  • Визначте стандартний ліміт та запит CPU на 150m та стандартний запит памʼяті на 300Mi для контейнерів, що запускаються без запитів ЦП та памʼяті у своїх специфікаціях.

У випадку, коли загальні ліміти простору імен менше суми лімітів Podʼів/Контейнерів, може виникнути конфлікт для ресурсів. У цьому випадку контейнери або Podʼи не будуть створені.

Ні конфлікт, ні зміни LimitRange не впливають на вже створені ресурси.

Що далі

Для прикладів використання обмежень дивіться:

Звертайтеся до документа проєкту LimitRanger для контексту та історичної інформації.

3.9.2 - Квоти ресурсів

Коли декілька користувачів або команд спільно використовують кластер з фіксованою кількістю вузлів, є можливість, що одна команда може використовувати більше, ніж свою справедливу частку ресурсів.

Квоти ресурсів є інструментом для адміністраторів для розвʼязання цієї проблеми.

Квота ресурсів, визначена обʼєктом ResourceQuota, надає обмеження, які обмежують загальне споживання ресурсів у просторі імен. Вона може обмежувати кількість обʼєктів, які можуть бути створені в просторі імен за типом, а також загальний обсяг обчислювальних ресурсів, які можуть бути спожиті ресурсами у цьому просторі імен.

Квоти ресурсів працюють наступним чином:

  • Різні команди працюють у різних просторах імен. Це може бути забезпечено з використанням RBAC.

  • Адміністратор створює одну квоту ресурсів для кожного простору імен.

  • Користувачі створюють ресурси (Podʼи, Serviceʼи тощо) у просторі імен, і система квот відстежує використання, щоб забезпечити, що воно не перевищує жорсткі обмеження ресурсів, визначені в ResourceQuota.

  • Якщо створення або оновлення ресурсу порушує обмеження квоти, запит буде відхилено з HTTP кодом стану 403 FORBIDDEN з повідомленням, яке пояснює обмеження, що було б порушено.

  • Якщо квота включена в простір імен для обчислювальних ресурсів, таких як cpu та memory, користувачі повинні вказати запити або ліміти для цих значень; інакше, система квот може відхилити створення Podʼа. Підказка: Використовуйте контролер допуску LimitRanger, щоб надати для Podʼів, які не мають вимог до обчислювальних ресурсів, стандартні обсяги ресурсів.

    Дивіться посібник для прикладу того, як уникнути цієї проблеми.

Назва обʼєкта ResourceQuota повинна бути дійсним піддоменом DNS.

Приклади політик, які можна створити за допомогою просторів імен та квот, такі:

  • У кластері з місткістю 32 ГБ ОЗП та 16 ядрами, дозвольте команді A використовувати 20 ГБ та 10 ядер, дозвольте команді B використовувати 10 ГБ та 4 ядра, і залиште 2 ГБ та 2 ядра у резерві на майбутнє.
  • Обмежте простір імен "testing" використанням 1 ядра та 1 ГБ ОЗП. Дозвольте простору імен "production" використовувати будь-який обсяг.

У випадку, коли загальна місткість кластера менше суми квот просторів імен, може виникнути конфлікт за ресурси. Це обробляється за принципом "хто перший прийшов, той і молотить" (FIFO).

Ні конфлікт, ні зміни квоти не впливають на вже створені ресурси.

Увімкнення квоти ресурсів

Підтримка квоти ресурсів є типово увімкненою для багатьох дистрибутивів Kubernetes. Вона увімкнена, коли прапорець --enable-admission-plugins= API serverʼа має ResourceQuota серед своїх аргументів.

Квота ресурсів застосовується в певному просторі імен, коли у цьому просторі імен є ResourceQuota.

Квота обчислювальних ресурсів

Ви можете обмежити загальну суму обчислювальних ресурсів, які можуть бути запитані в певному просторі імен.

Підтримуються наступні типи ресурсів:

Назва ресурсуОпис
limits.cpuУ всіх Podʼах у незавершеному стані сума лімітів CPU не може перевищувати це значення.
limits.memoryУ всіх Podʼах у незавершеному стані сума лімітів памʼяті не може перевищувати це значення.
requests.cpuУ всіх Podʼах у незавершеному стані сума запитів CPU не може перевищувати це значення.
requests.memoryУ всіх Podʼах у незавершеному стані сума запитів памʼяті не може перевищувати це значення.
hugepages-<size>У всіх Podʼах у незавершеному стані кількість запитів великих сторінок зазначеного розміру не може перевищувати це значення.
cpuТе саме, що і requests.cpu
memoryТе саме, що і requests.memory

Квота для розширених ресурсів

Крім ресурсів, згаданих вище, в релізі 1.10 було додано підтримку квоти для розширених ресурсів.

Оскільки перевищення не дозволяється для розширених ресурсів, немає сенсу вказувати як requests, так і limits для одного й того ж розширеного ресурсу у квоті. Таким чином, для розширених ресурсів дозволяються лише елементи квоти з префіксом requests. наразі.

Візьмімо ресурс GPU як приклад. Якщо імʼя ресурсу — nvidia.com/gpu, і ви хочете обмежити загальну кількість запитаних GPU в просторі імен до 4, ви можете визначити квоту так:

  • requests.nvidia.com/gpu: 4

Дивіться Перегляд та встановлення квот для більш детальної інформації.

Квота ресурсів зберігання

Ви можете обмежити загальну суму ресурсів зберігання, які можуть бути запитані в певному просторі імен.

Крім того, ви можете обмежити споживання ресурсів зберігання на основі повʼязаного класу зберігання.

Назва ресурсуОпис
requests.storageУ всіх запитах на постійний том, сума запитів зберігання не може перевищувати це значення.
persistentvolumeclaimsЗагальна кількість PersistentVolumeClaims, які можуть існувати у просторі імен.
<storage-class-name>.storageclass.storage.k8s.io/requests.storageУ всіх запитах на постійний том, повʼязаних з <storage-class-name>, сума запитів зберігання не може перевищувати це значення.
<storage-class-name>.storageclass.storage.k8s.io/persistentvolumeclaimsУ всіх запитах на постійний том, повʼязаних з <storage-class-name>, загальна кількість запитів на постійні томи, які можуть існувати у просторі імен.

Наприклад, якщо оператор хоче обмежити зберігання з класом зберігання gold окремо від класу зберігання bronze, оператор може визначити квоту так:

  • gold.storageclass.storage.k8s.io/requests.storage: 500Gi
  • bronze.storageclass.storage.k8s.io/requests.storage: 100Gi

У релізі 1.8, підтримка квоти для локального тимчасового сховища додана як альфа-функція:

Назва ресурсуОпис
requests.ephemeral-storageУ всіх Podʼах у просторі імен, сума запитів на локальне тимчасове сховище не може перевищувати це значення.
limits.ephemeral-storageУ всіх Podʼах у просторі імен, сума лімітів на локальне тимчасове сховище не може перевищувати це значення.
ephemeral-storageТе саме, що і requests.ephemeral-storage.

Квота на кількість обʼєктів

Ви можете встановити квоту на загальну кількість одного конкретного типу ресурсів у API Kubernetes, використовуючи наступний синтаксис:

  • count/<resource>.<group> для ресурсів з груп non-core
  • count/<resource> для ресурсів з групи core

Нижче наведено приклад набору ресурсів, які користувачі можуть хотіти обмежити квотою на кількість обʼєктів:

  • count/persistentvolumeclaims
  • count/services
  • count/secrets
  • count/configmaps
  • count/replicationcontrollers
  • count/deployments.apps
  • count/replicasets.apps
  • count/statefulsets.apps
  • count/jobs.batch
  • count/cronjobs.batch

Якщо ви визначаєте квоту таким чином, вона застосовується до API Kubernetes, які є частиною сервера API, а також до будь-яких власних ресурсів, підтримуваних CustomResourceDefinition. Якщо ви використовуєте агрегацію API, щоб додати додаткові, власні API, які не визначені як CustomResourceDefinitions, основна панель управління Kubernetes не застосовує квоту для агрегованого API. Очікується, що розширений сервер API забезпечить виконання квот, якщо це відповідає потребам власного API. Наприклад, щоб створити квоту на власний ресурс widgets у групі API example.com, використовуйте count/widgets.example.com.

При використанні такої квоти ресурсів (практично для всіх видів обʼєктів), обʼєкт враховується у квоті, якщо вид обʼєкта існує (визначений) у панелі управління. Ці типи квот корисні для захисту від вичерпання ресурсів зберігання. Наприклад, ви можете хотіти обмежити кількість Secretʼів на сервері, враховуючи їх великий розмір. Занадто багато Secretʼів у кластері може фактично завадити запуску серверів і контролерів. Ви можете встановити квоту для Job, щоб захиститися від погано налаштованого CronJob. CronJobs, які створюють занадто багато Job у просторі імен, можуть призвести до заподіяння відмови в обслуговуванні.

Існує інший синтаксис, який дозволяє встановити такий же тип квоти для певних ресурсів. Підтримуються наступні типи:

Назва ресурсуОпис
configmapsЗагальна кількість ConfigMaps, які можуть існувати в просторі імен.
persistentvolumeclaimsЗагальна кількість PersistentVolumeClaims, які можуть існувати в просторі імен.
podsЗагальна кількість Podʼів у просторі імен, що не перебувають в стані завершення роботи. Pod вважається таким, якщо .status.phase in (Failed, Succeeded) є true.
replicationcontrollersЗагальна кількість ReplicationControllers, які можуть існувати в просторі імен.
resourcequotasЗагальна кількість ResourceQuotas, які можуть існувати в просторі імен.
servicesЗагальна кількість Services, які можуть існувати в просторі імен.
services.loadbalancersЗагальна кількість Services типу LoadBalancer, які можуть існувати в просторі імен.
services.nodeportsЗагальна кількість NodePorts, виділених Services типу NodePort чи LoadBalancer, які можуть існувати в просторі імен.
secretsЗагальна кількість Secrets, які можуть існувати в просторі імен.

Наприклад, квота pods рахує та обмежує максимальну кількість Podʼів, створених у одному просторі імен, що не перебувають в стані завершення роботи. Ви можете встановити квоту pods у просторі імен, щоб уникнути випадку, коли користувач створює багато невеликих Podʼів і вичерпує запаси IP-адрес Podʼів кластері.

Ви можете знайти більше прикладів у розділі Перегляд і налаштування квот.

Області дії квоти

Кожна квота може мати повʼязаний набір scopes. Квота вимірюватиме використання ресурсу лише в тому випадку, якщо вона відповідає перетину перерахованих областей.

Коли до квоти додається область, вона обмежує кількість ресурсів, які вона підтримує, тими, які стосуються цієї області. Ресурси, вказані у квоті поза дозволеним набором, призводять до помилки перевірки.

ОбластьОпис
TerminatingВідповідає Podʼам, де .spec.activeDeadlineSeconds >= 0
NotTerminatingВідповідає Podʼам, де .spec.activeDeadlineSeconds is nil
BestEffortВідповідає Podʼам, які мають найкращий рівень якості обслуговування.
NotBestEffortВідповідає Podʼам, які не мають найкращого рівня якості обслуговування.
PriorityClassВідповідає Podʼам, які посилаються на вказаний клас пріоритету.
CrossNamespacePodAffinityВідповідає Podʼам, які мають міжпросторові (anti)affinity.

Область BestEffort обмежує квоту відстеження наступним ресурсом:

  • pods

Області Terminating, NotTerminating, NotBestEffort та PriorityClass обмежують квоту відстеження наступними ресурсами:

  • pods
  • cpu
  • memory
  • requests.cpu
  • requests.memory
  • limits.cpu
  • limits.memory

Зверніть увагу, що ви не можете вказати як Terminating, так і NotTerminating області в одній й тій же квоті, і ви також не можете вказати як BestEffort, так і NotBestEffort області в одній й тій же квоті.

Селектор області підтримує наступні значення у полі operator:

  • In
  • NotIn
  • Exists
  • DoesNotExist

При використанні одного з наступних значень як scopeName при визначенні scopeSelector, оператор повинен бути Exists.

  • Terminating
  • NotTerminating
  • BestEffort
  • NotBestEffort

Якщо оператором є In або NotIn, поле values повинно мати щонайменше одне значення. Наприклад:

  scopeSelector:
    matchExpressions:
      - scopeName: PriorityClass
        operator: In
        values:
          - middle

Якщо оператором є Exists або DoesNotExist, поле values НЕ повинно бути вказане.

Квота ресурсів за PriorityClass

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.17 [stable]

Podʼи можуть бути створені з певним пріоритетом. Ви можете контролювати використання ресурсів системи для Podʼів з урахуванням їх пріоритету, використовуючи поле scopeSelector у специфікації квоти.

Квота має збіг та використовується лише якщо scopeSelector у специфікації квоти вибирає Pod.

Коли квота обмежена класом пріоритету за допомогою поля scopeSelector, обʼєкт квоти обмежується відстеженням лише наступних ресурсів:

  • pods
  • cpu
  • memory
  • ephemeral-storage
  • limits.cpu
  • limits.memory
  • limits.ephemeral-storage
  • requests.cpu
  • requests.memory
  • requests.ephemeral-storage

У цьому прикладі створюється обʼєкт квоти та відповідною до нього підходить до Podʼів з певними пріоритетами. Приклад працює наступним чином:

  • Podʼи в кластері мають один з трьох класів пріоритету: "низький", "середній", "високий".
  • Для кожного пріоритету створюється один обʼєкт квоти.

Збережіть наступний YAML у файл quota.yml.

apiVersion: v1
kind: List
items:
- apiVersion: v1
  kind: ResourceQuota
  metadata:
    name: pods-high
  spec:
    hard:
      cpu: "1000"
      memory: 200Gi
      pods: "10"
    scopeSelector:
      matchExpressions:
      - operator : In
        scopeName: PriorityClass
        values: ["high"]
- apiVersion: v1
  kind: ResourceQuota
  metadata:
    name: pods-medium
  spec:
    hard:
      cpu: "10"
      memory: 20Gi
      pods: "10"
    scopeSelector:
      matchExpressions:
      - operator : In
        scopeName: PriorityClass
        values: ["medium"]
- apiVersion: v1
  kind: ResourceQuota
  metadata:
    name: pods-low
  spec:
    hard:
      cpu: "5"
      memory: 10Gi
      pods: "10"
    scopeSelector:
      matchExpressions:
      - operator : In
        scopeName: PriorityClass
        values: ["low"]

Застосуйте YAML за допомогою kubectl create.

kubectl create -f ./quota.yml
resourcequota/pods-high created
resourcequota/pods-medium created
resourcequota/pods-low created

Перевірте, що значення Used квоти дорівнює 0 за допомогою kubectl describe quota.

kubectl describe quota
Name:       pods-high
Namespace:  default
Resource    Used  Hard
--------    ----  ----
cpu         0     1k
memory      0     200Gi
pods        0     10


Name:       pods-low
Namespace:  default
Resource    Used  Hard
--------    ----  ----
cpu         0     5
memory      0     10Gi
pods        0     10


Name:       pods-medium
Namespace:  default
Resource    Used  Hard
--------    ----  ----
cpu         0     10
memory      0     20Gi
pods        0     10

Створіть Pod із пріоритетом "high". Збережіть наступний YAML у файл high-priority-pod.yml.

apiVersion: v1
kind: Pod
metadata:
  name: high-priority
spec:
  containers:
  - name: high-priority
    image: ubuntu
    command: ["/bin/sh"]
    args: ["-c", "while true; do echo hello; sleep 10;done"]
    resources:
      requests:
        memory: "10Gi"
        cpu: "500m"
      limits:
        memory: "10Gi"
        cpu: "500m"
  priorityClassName: high

Застосуйте його за допомогою kubectl create.

kubectl create -f ./high-priority-pod.yml

Перевірте, що статистика "Used" для квоти пріоритету "high", pods-high, змінилася і що для інших двох квот стан не змінився.

kubectl describe quota
Name:       pods-high
Namespace:  default
Resource    Used  Hard
--------    ----  ----
cpu         500m  1k
memory      10Gi  200Gi
pods        1     10


Name:       pods-low
Namespace:  default
Resource    Used  Hard
--------    ----  ----
cpu         0     5
memory      0     10Gi
pods        0     10


Name:       pods-medium
Namespace:  default
Resource    Used  Hard
--------    ----  ----
cpu         0     10
memory      0     20Gi
pods        0     10

Квота Pod Affinity між просторами імен

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.24 [stable]

Оператори можуть використовувати область квоти CrossNamespacePodAffinity, щоб обмежити, які простори імен можуть мати Podʼи з термінами спорідненості, які перетинають простори імен. Зокрема, вона контролює, яким Podʼам дозволено встановлювати поля namespaces або namespaceSelector у термінах спорідненості (Pod Affinity).

Бажано уникати використання термінів спорідненості, які перетинають простори імен, оскільки Pod з обмеженнями анти-спорідненості може заблокувати Podʼи з усіх інших просторів імен від планування в області відмов.

За допомогою цієї області оператори можуть запобігти певним просторам імен (наприклад, foo-ns у наведеному нижче прикладі) використання Podʼів, які використовують спорідненість між просторами імен, створивши обʼєкт квоти ресурсів в цьому просторі імен з областю CrossNamespacePodAffinity та жорстким обмеженням 0:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: disable-cross-namespace-affinity
  namespace: foo-ns
spec:
  hard:
    pods: "0"
  scopeSelector:
    matchExpressions:
    - scopeName: CrossNamespacePodAffinity
      operator: Exists

Якщо оператори хочуть заборонити стандартне використання namespaces та namespaceSelector, і дозволити це лише для певних просторів імен, вони можуть налаштувати CrossNamespacePodAffinity як обмежений ресурс, встановивши прапорець kube-apiserver --admission-control-config-file на шлях до наступного конфігураційного файлу:

apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: "ResourceQuota"
  configuration:
    apiVersion: apiserver.config.k8s.io/v1
    kind: ResourceQuotaConfiguration
    limitedResources:
    - resource: pods
      matchScopes:
      - scopeName: CrossNamespacePodAffinity
        operator: Exists

За такої конфігурації Podʼи можуть використовувати namespaces та namespaceSelector у термінах спорідненості тільки якщо простір імен, в якому вони створені, має обʼєкт квоти ресурсів з областю CrossNamespacePodAffinity та жорстким обмеженням, більшим або рівним кількості Podʼів, що використовують ці поля.

Запити порівняно з лімітами

При розподілі обчислювальних ресурсів кожен контейнер може вказати значення запиту та ліміту для CPU або памʼяті. Квоту можна налаштувати для обмеження будь-якого значення.

Якщо для квоти вказано значення для requests.cpu або requests.memory, то це вимагає, щоб кожен вхідний контейнер явно вказував запити для цих ресурсів. Якщо для квоти вказано значення для limits.cpu або limits.memory, то це вимагає, щоб кожен вхідний контейнер вказував явний ліміт для цих ресурсів.

Перегляд і налаштування квот

Kubectl підтримує створення, оновлення та перегляд квот:

kubectl create namespace myspace
cat <<EOF > compute-resources.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-resources
spec:
  hard:
    requests.cpu: "1"
    requests.memory: 1Gi
    limits.cpu: "2"
    limits.memory: 2Gi
    requests.nvidia.com/gpu: 4
EOF
kubectl create -f ./compute-resources.yaml --namespace=myspace
cat <<EOF > object-counts.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
  name: object-counts
spec:
  hard:
    configmaps: "10"
    persistentvolumeclaims: "4"
    pods: "4"
    replicationcontrollers: "20"
    secrets: "10"
    services: "10"
    services.loadbalancers: "2"
EOF
kubectl create -f ./object-counts.yaml --namespace=myspace
kubectl get quota --namespace=myspace
NAME                    AGE
compute-resources       30s
object-counts           32s
kubectl describe quota compute-resources --namespace=myspace
Name:                    compute-resources
Namespace:               myspace
Resource                 Used  Hard
--------                 ----  ----
limits.cpu               0     2
limits.memory            0     2Gi
requests.cpu             0     1
requests.memory          0     1Gi
requests.nvidia.com/gpu  0     4
kubectl describe quota object-counts --namespace=myspace
Name:                   object-counts
Namespace:              myspace
Resource                Used    Hard
--------                ----    ----
configmaps              0       10
persistentvolumeclaims  0       4
pods                    0       4
replicationcontrollers  0       20
secrets                 1       10
services                0       10
services.loadbalancers  0       2

Kubectl також підтримує квоту на кількість обʼєктів для всіх стандартних обʼєктів в просторі імен за допомогою синтаксису count/<resource>.<group>:

kubectl create namespace myspace
kubectl create quota test --hard=count/deployments.apps=2,count/replicasets.apps=4,count/pods=3,count/secrets=4 --namespace=myspace
kubectl create deployment nginx --image=nginx --namespace=myspace --replicas=2
kubectl describe quota --namespace=myspace
Name:                         test
Namespace:                    myspace
Resource                      Used  Hard
--------                      ----  ----
count/deployments.apps        1     2
count/pods                    2     3
count/replicasets.apps        1     4
count/secrets                 1     4

Квоти та місткість кластера

ResourceQuotas є незалежними від місткості кластера. Вони виражені в абсолютних одиницях. Таким чином, якщо ви додаєте вузли до свого кластера, це автоматично не надає кожному простору імен можливість використовувати більше ресурсів.

Іноді бажані складніші політики, такі як:

  • Пропорційне розподілення спільних ресурсів кластера серед кількох команд.
  • Дозвіл кожному орендареві збільшувати використання ресурсів за потреби, але мати щедру квоту, щоб уникнути випадкового вичерпання ресурсів.
  • Виявлення попиту з одного простору імен, додавання вузли та збільшення квоти.

Такі політики можна реалізувати, використовуючи ResourceQuotas як будівельні блоки, написавши "контролер", який спостерігає за використанням квоти та налаштовує межі квоти кожного простору імен згідно з іншими сигналами.

Зверніть увагу, що квота ресурсів розподіляє загальні ресурси кластера, але не створює обмежень щодо вузлів: Podʼи з кількох просторів імен можуть працювати на одному вузлі.

Типове обмеження споживання Priority Class

Може бути бажаним, щоб Podʼи з певного пріоритету, наприклад, "cluster-services", дозволялися в просторі імен, лише якщо існує відповідний обʼєкт квоти.

За допомогою цього механізму оператори можуть обмежувати використання певних високопріоритетних класів до обмеженої кількості просторів імен, і не кожний простір імен зможе стандартно споживати ці класи пріоритету.

Для цього потрібно використовувати прапорець --admission-control-config-file kube-apiserver для передачі шляху до наступного конфігураційного файлу:

apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: "ResourceQuota"
  configuration:
    apiVersion: apiserver.config.k8s.io/v1
    kind: ResourceQuotaConfiguration
    limitedResources:
    - resource: pods
      matchScopes:
      - scopeName: PriorityClass
        operator: In
        values: ["cluster-services"]

Потім створіть обʼєкт квоти ресурсів у просторі імен kube-system:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: pods-cluster-services
spec:
  scopeSelector:
    matchExpressions:
      - operator : In
        scopeName: PriorityClass
        values: ["cluster-services"]
kubectl apply -f https://k8s.io/examples/policy/priority-class-resourcequota.yaml -n kube-system
resourcequota/pods-cluster-services created

У цьому випадку створення Podʼа буде дозволено, якщо:

  1. Параметр priorityClassName Podʼа не вказано.
  2. Параметр priorityClassName Podʼа вказано на значення, відмінне від cluster-services.
  3. Параметр priorityClassName Podʼа встановлено на cluster-services, він має бути створений в просторі імен kube-system і пройти перевірку обмеження ресурсів.

Запит на створення Podʼа буде відхилено, якщо його priorityClassName встановлено на cluster-services і він має бути створений в просторі імен, відмінному від kube-system.

Що далі

3.9.3 - Обмеження та резервування ID процесів

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.20 [stable]

Kubernetes дозволяє обмежувати кількість ідентифікаторів процесів (PID), які може використовувати Pod. Також можна зарезервувати певну кількість доступних PID для кожного вузла для використання операційною системою та службами (на відміну від Podʼів).

Ідентифікатори процесів (PID) є фундаментальним ресурсом на вузлах. Досить легко досягти обмеження на кількість завдань без досягнення будь-яких інших обмежень ресурсів, що може призвести до нестабільності роботи хосту.

Адміністраторам кластерів потрібні механізми, щоб гарантувати, що Podʼи, що працюють у кластері, не зможуть спричинити вичерпання PID, що перешкоджає роботі системних служб (таких як kubelet або kube-proxy), а також, можливо, і контейнерного середовища. Крім того, важливо забезпечити обмеження PID серед Podʼів, щоб гарантувати, що вони мають обмежений вплив на інші робочі навантаження на тому ж вузлі.

Ви можете налаштувати kubelet для обмеження кількості PID, які може споживати конкретний Pod. Наприклад, якщо ОС вашого вузла налаштовано на використання максимуму 262144 PID та очікується, що буде зберігатися менше 250 Podʼів, кожному Podʼу можна надати бюджет в розмірі 1000 PID, щоб запобігти використанню загальної кількості доступних PID на вузлі. Якщо адміністратор хоче надати можливість перевищення ліміту PID, схожий на CPU чи памʼять, він може зробити це, але з певними додатковими ризиками. У будь-якому випадку, одиничний Pod не зможе зруйнувати весь вузол. Цей вид обмеження ресурсів допомагає запобігти простим форк-бомбам впливати на роботу всього кластера.

Обмеження PID на рівні Pod дозволяє адміністраторам захистити один Pod від іншого, але не гарантує, що всі Podʼи, заплановані на цей вузол, не зможуть вплинути на вузол загалом. Обмеження PID на рівні Pod також не захищає системні агенти від вичерпання PID.

Ви також можете зарезервувати певну кількість PID для накладних витрат вузла, окремо від виділених для Podʼів. Це аналогічно тому, як ви можете резервувати CPU, памʼять чи інші ресурси для використання операційною системою та іншими засобами поза Podʼами та їх контейнерами.

Обмеження PID є важливим компонентом наряду з ресурсами обчислення. Однак ви вказуєте його по-іншому: замість визначення ліміту ресурсу для Podʼів у .spec для Pod, ви налаштовуєте ліміт як параметр kubelet. Обмеження PID, визначене на рівні Podʼа, наразі не підтримується.

Обмеження PID вузла

Kubernetes дозволяє зарезервувати певну кількість ідентифікаторів процесів для системного використання. Для налаштування резервування використовуйте параметр pid=<кількість> у командних параметрах --system-reserved та --kube-reserved для kubelet. Зазначена вами кількість ідентифікаторів процесів оголошує, що вказана кількість ідентифікаторів процесів буде зарезервована для системи в цілому та для служб Kubernetes відповідно.

Обмеження PID на рівні Podʼа

Kubernetes дозволяє обмежити кількість процесів, які запущені в Podʼі. Ви вказуєте це обмеження на рівні вузла, а не налаштовуєте його як обмеження ресурсів для певного Podʼа. Кожен вузол може мати власний ліміт PID. Для налаштування ліміту ви можете вказати параметр командного рядка --pod-max-pids для kubelet або встановити PodPidsLimit в конфігураційному файлі kubelet.

Виселення на основі PID

Ви можете налаштувати kubelet для початку завершення роботи Podʼа, коли він працює некоректно та споживає аномальну кількість ресурсів. Ця функція називається виселення (eviction). Ви можете Налаштувати обробку випадків нестачі ресурсів для різних сигналів виселення. Використовуйте сигнал виселення pid.available, щоб налаштувати поріг кількості PID, використаних Podʼом. Ви можете встановити мʼякі та жорсткі політики виселення. Однак навіть з жорсткою політикою виселення, якщо кількість PID швидко зростає, вузол все ще може потрапити в нестабільний стан через досягнення обмеження PID вузла. Значення сигналу виселення обчислюється періодично і НЕ забезпечує його виконання.

Обмеження PID — на рівні Podʼа і вузла встановлює жорсткий ліміт. Як тільки ліміт буде досягнуто, робота почне стикатись з помилками при спробі отримати новий PID. Це може або не може призвести до перепланування Pod, залежно від того, як робоче навантаження реагує на ці помилки та як налаштовано проби на працездатність та готовність для Podʼа. Однак, якщо ліміти були налаштовані правильно, ви можете гарантувати, що інші робочі навантаження Podʼів та системні процеси не будуть вичерпувати PID, коли один Pod працює некоректно.

Що далі

3.9.4 - Менеджери ресурсів вузлів

Для підтримки критичних до затримки та високопродуктивних робочих навантажень Kubernetes пропонує набір менеджерів ресурсів. Менеджери прагнуть координувати та оптимізувати вирівнювання ресурсів вузла для Podʼів, налаштованих з конкретною вимогою до ресурсів процесорів, пристроїв та памʼяті (величезних сторінок).

Основний менеджер, Менеджер топології, є складовою частиною Kubelet, який координує загальний процес управління ресурсами через свою політику.

Конфігурація окремих менеджерів розглянута у відповідних документах:

3.10 - Планування, Випередження та Виселення

У Kubernetes планування означає забезпечення відповідності робочих навантажень (Pods) вузлам (Nodes), щоб kubelet міг їх запустити. Випередження — це процес припинення роботи Podʼів з низьким пріоритетом, щоб Podʼи з вищим пріоритетом могли розміщуватися на вузлах. Виселення — це процес проактивного припинення роботи одного або кількох Podʼів на вузлах з нестачею ресурсів.

У Kubernetes планування означає забезпечення відповідності Podʼів вузлам (Nodes), щоб kubelet міг їх запустити. Випередження — це процес припинення роботи Podʼів з низьким пріоритетом, щоб Podʼи з вищим пріоритетом могли розміщуватися на вузлах. Виселення — це процес проактивного припинення роботи одного або кількох Podʼів на вузлах.

Планування

Переривання роботи Podʼа

Розлад в роботі Podʼа — це процес, за якого Podʼи на вузлах припиняють роботу добровільно, або примусово.

Добровільні розлади запускаються навмисно власниками застосунків або адміністраторами кластера. Примусові розлади є ненавмисними та можуть бути спричинені невідворотними проблемами, такими як вичерпання ресурсів вузлів, або випадковими видаленнями.

3.10.1 - Планувальник Kubernetes

У Kubernetes планування означає забезпечення того, що Podʼи відповідно призначаються вузлам, щоб їх можна було запустити за допомогою Kubelet.

Огляд планування

Планувальник відстежує новостворені Podʼи, які не мають призначеного Вузла. Планувальник відповідає за знаходження найкращого Вузла для кожного виявленого Podʼа, на якому можна запустити цей Pod. Планувальник приймає рішення про розташування Podʼа, враховуючи принципи планування, описані нижче.

Якщо ви хочете зрозуміти, чому Podʼи розміщуються на певному Вузлі, або якщо ви плануєте реалізувати власний планувальник, ця сторінка допоможе вам дізнатися більше про планування.

kube-scheduler

kube-scheduler є стандартним планувальником для Kubernetes і працює як частина панелі управління. kube-scheduler розроблено так, що, якщо ви хочете і вам треба, ви можете написати власний компонент планування і використовувати його замість стандартного.

Kube-scheduler вибирає оптимальний вузол для запуску нових або ще не запланованих Podʼів. Оскільки контейнери в Podʼах, і самі Podʼи, можуть мати різні вимоги, планувальник фільтрує будь-які вузли, які не відповідають конкретним потребам планування Podʼа. Зазвичай через API можна вказати вузол для Podʼа при його створенні, але це робиться тільки у виняткових випадках.

У кластері Вузли, які відповідають вимогам планування для Podʼа, називаються feasible (придатними) вузлами. Якщо жоден з вузлів не підходить, Pod залишається незапланованим до тих пір, поки планувальник не зможе розмістити його.

Планувальник знаходить придатні Вузли для Podʼів, а потім виконує набір функцій для оцінки таких Вузлів і вибирає Вузол з найвищим рейтингом серед придатних для запуску Podʼа. Планувальник потім повідомляє сервер API про це рішення в процесі, який називається binding (привʼязкою).

Фактори, які потрібно враховувати при прийнятті рішень про планування, включають індивідуальні та загальні вимоги до ресурсів, обмеження апаратного та програмного забезпечення / політики, (анти)спорідненість (affinity), розташування даних, взаємовплив між робочими навантаженнями та інше.

Вибір вузла в kube-scheduler

kube-scheduler вибирає вузол для Podʼа в два етапи:

  1. Фільтрація.
  2. Оцінювання.

На етапі фільтрації визначається набір Вузлів, на яких можна розмістити Pod. Наприклад, фільтр PodFitsResources перевіряє, чи має Вузол-кандидат достатньо доступних ресурсів, щоб задовольнити конкретні вимоги до ресурсів Podʼа. Після цього етапу список вузлів містить придатні вузли; часто їх буде більше одного. Якщо список порожній, цей Pod не є (поки що) можливим для планування.

На етапі оцінювання планувальник ранжує вузли, що були обрані, щоб вибрати найбільш придатне розміщення для Podʼа. Планувальник надає кожному вузлу, який залишився після фільтрації, оцінку, базуючись на активних правилах оцінки.

На останньому етапі kube-scheduler призначає Pod вузлу з найвищим рейтингом. Якщо є більше одного вузла з однаковими рейтингами, kube-scheduler вибирає один з них випадковим чином.

Є два підтримуваних способи налаштування поведінки фільтрації та оцінювання планувальника:

  1. Політики планування дозволяють налаштувати Предикати для фільтрації та Пріоритети для оцінювання.
  2. Профілі планування дозволяють налаштувати Втулки, які реалізують різні етапи планування, включаючи: QueueSort, Filter, Score, Bind, Reserve, Permit та інші. Ви також можете налаштувати kube-scheduler для запуску різних профілів.

Що далі

3.10.2 - Призначення Podʼів до Вузлів

Ви можете обмежити Pod так, щоб він був обмежений для запуску на конкретних вузлах, або віддавав перевагу запуску на певних вузлах. Існують кілька способів як це зробити, а рекомендовані підходи використовують усі селектори міток для полегшення вибору. Зазвичай вам не потрібно встановлювати жодні обмеження такого роду; планувальник автоматично робить розумне розміщення (наприклад, розподіл Podʼів по вузлах так, щоб не розміщувати Podʼи на вузлі з недостатньою кількістю вільних ресурсів). Однак є деякі обставини, коли ви можете контролювати, на якому вузлі розгортається Pod, наприклад, щоб переконатися, що Pod потрапляє на вузол з прикріпленим до нього SSD, або спільно розміщувати Podʼи з двох різних служб, які багато спілкуються в одній зоні доступності.

Ви можете використовувати будь-який з наступних методів для вибору місця, де Kubernetes планує конкретні Podʼи:

Мітки вузлів

Як і багато інших обʼєктів Kubernetes, вузли мають мітки. Ви можете додавати мітки вручну. Kubernetes також заповнює стандартний набір міток на всіх вузлах кластера.

Ізоляція/обмеження вузлів

Додавання міток до вузлів дозволяє вам позначати Podʼи для розміщення на конкретних вузлах або групах вузлів. Ви можете використовувати цю функціональність, щоб забезпечити, що певні Podʼи працюватимуть тільки на вузлах із певною ізоляцією, безпекою або регуляторними властивостями.

Якщо ви використовуєте мітки для ізоляції вузлів, обирайте ключі міток, які kubelet не може змінювати. Це заважає скомпрометованому вузлу встановлювати ці мітки на себе, щоб планувальник планував навантаження на скомпрометований вузол.

Втулок допуску NodeRestriction перешкоджає kubelet встановлювати або змінювати мітки з префіксом node-restriction.kubernetes.io/.

Щоб скористатися цим префіксом міток для ізоляції вузлів:

  1. Переконайтеся, що ви використовуєте авторизатор вузлів і ввімкнули втулок допуску NodeRestriction.
  2. Додайте мітки з префіксом node-restriction.kubernetes.io/ на ваші вузли, і використовуйте ці мітки у ваших селекторах вузлів. Наприклад, example.com.node-restriction.kubernetes.io/fips=true або example.com.node-restriction.kubernetes.io/pci-dss=true.

Вибір вузла з використанням nodeSelector

nodeSelector є найпростішим рекомендованим способом обмеження вибору вузла. Ви можете додати поле nodeSelector до специфікації вашого Podʼа і вказати мітки вузла, які має мати цільовий вузол. Kubernetes розміщує Pod лише на тих вузлах, які мають всі мітки, які ви вказали.

Дивіться Призначення Podʼів на вузли для отримання додаткової інформації.

Спорідненість та антиспорідненість

nodeSelector є найпростішим способом обмежити Podʼи вузлами з певними мітками. Спорідненість та антиспорідненість розширюють типи обмежень, які ви можете визначити. Деякі з переваг спорідненості та антиспорідненості включають:

  • Мова (анти)спорідненості є більш виразною. nodeSelector вибирає лише вузли з усіма вказаними мітками. (Анти)спорідненіcть дає вам більший контроль над логікою вибору.
  • Ви можете вказати, що правило є soft або preferred, таким чином, планувальник все ще розміщує Pod навіть якщо не може знайти відповідного вузла.
  • Ви можете обмежити Pod, використовуючи мітки на інших Podʼах, які працюють на вузлі (або іншій топологічній області), а не лише мітки вузла, що дозволяє визначати правила для того, які Podʼи можуть бути розташовані на одному вузлі.

Функція affinity складається з двох типів значень:

  • Спорідненість вузла працює подібно до поля nodeSelector, але є більш виразним і дозволяє вказувати мʼякі правила.
  • Між-Podʼова (анти)спорідненість дозволяє обмежувати Podʼи проти міток інших Podʼів.

Спорідненість вузла

Спорідненість вузла концептуально подібне до nodeSelector і дозволяє вам обмежувати, на яких вузлах може бути запланований ваш Pod на основі міток вузла. Існують два типи спорідненості вузла:

  • requiredDuringSchedulingIgnoredDuringExecution: Планувальник не може запланувати Pod, якщо правило не виконується. Це працює подібно до nodeSelector, але з більш виразним синтаксисом.
  • preferredDuringSchedulingIgnoredDuringExecution: Планувальник намагається знайти вузол, який відповідає правилу. Якщо відповідний вузол недоступний, планувальник все одно планує Pod.

Ви можете вказати спорідненість вузла, використовуючи поле .spec.affinity.nodeAffinity в специфікації вашого Podʼа.

Наприклад, розгляньте наступну специфікацію Podʼа:

apiVersion: v1
kind: Pod
metadata:
  name: with-node-affinity
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: topology.kubernetes.io/zone
            operator: In
            values:
            - antarctica-east1
            - antarctica-west1
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: another-node-label-key
            operator: In
            values:
            - another-node-label-value
  containers:
  - name: with-node-affinity
    image: registry.k8s.io/pause:2.0

У цьому прикладі застосовуються наступні правила:

  • Вузол повинен мати мітку з ключем topology.kubernetes.io/zone, а значення цієї мітки повинно бути або antarctica-east1, або antarctica-west1.
  • Вузол переважно має мати мітку з ключем another-node-label-key, а значення another-node-label-value.

Ви можете використовувати поле operator, щоб вказати логічний оператор, який Kubernetes буде використовувати при інтерпретації правил. Ви можете використовувати In, NotIn, Exists, DoesNotExist, Gt і Lt.

Прочитайте розділ Оператори, щоб дізнатися більше про те, як вони працюють.

NotIn та DoesNotExist дозволяють визначати поведінку антиспорідненості. Альтернативно, ви можете використовувати node taints для відштовхування Podʼів від конкретних вузлів.

Дивіться Призначення Podʼів вузлам з використанням Node Affinity для отримання додаткової інформації.

Вага спорідненості вузла

Ви можете вказати weight (вагу) від 1 до 100 для кожного випадку спорідненості типу preferredDuringSchedulingIgnoredDuringExecution. Коли планувальник знаходить вузли, які відповідають усім іншим вимогам планування Podʼа, планувальник проходить по кожному правилу preferred, якому задовольняє вузол, і додає значення weight для цього виразу до суми.

Кінцева сума додається до загального балу інших функцій пріоритету для вузла. Вузли з найвищим загальним балом пріоритету отримують пріоритет у виборі планувальника при прийнятті рішення щодо планування Podʼа.

Наприклад, розгляньте наступну специфікацію Podʼа:

apiVersion: v1
kind: Pod
metadata:
  name: with-affinity-preferred-weight
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/os
            operator: In
            values:
            - linux
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: label-1
            operator: In
            values:
            - key-1
      - weight: 50
        preference:
          matchExpressions:
          - key: label-2
            operator: In
            values:
            - key-2
  containers:
  - name: with-node-affinity
    image: registry.k8s.io/pause:2.0

Якщо існують два можливих вузли, які відповідають правилу preferredDuringSchedulingIgnoredDuringExecution, один з міткою label-1:key-1, а інший з міткою label-2:key-2, планувальник бере до уваги weight кожного вузла і додає вагу до інших балів для цього вузла, і планує Pod на вузол з найвищим кінцевим балом.

Спорідненість вузла для кожного профілю планування

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.20 [beta]

При налаштуванні кількох профілів планування ви можете повʼязати профіль зі спорідненістю вузла, що є корисним, якщо профіль застосовується лише до певного набору вузлів. Для цього додайте addedAffinity до поля args втулка NodeAffinity у конфігурації планувальника. Наприклад:

apiVersion: kubescheduler.config.k8s.io/v1beta3
kind: KubeSchedulerConfiguration

profiles:
  - schedulerName: default-scheduler
  - schedulerName: foo-scheduler
    pluginConfig:
      - name: NodeAffinity
        args:
          addedAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
              nodeSelectorTerms:
              - matchExpressions:
                - key: scheduler-profile
                  operator: In
                  values:
                  - foo

addedAffinity застосовується до всіх Podʼів, які встановлюють .spec.schedulerName в foo-scheduler, на додачу до NodeAffinity, вказаного в PodSpec. Тобто для збігу вузла з Podʼом потрібно задовольнити збіг між addedAffinity та .spec.NodeAffinity Podʼа.

Оскільки addedAffinity не є видимим для кінцевих користувачів, його поведінка може бути неочікуваною для них. Використовуйте мітки вузлів, які мають чіткий взаємозвʼязок з іменем профілю планування.

Між-Podʼова спорідненість та антиспорідненість

Між-Podʼова спорідненість та антиспорідненість дозволяють обмежити, на яких вузлах ваші Podʼи можуть бути заплановані на основі міток Podʼів, які вже працюють на цьому вузлі, а не міток вузлів.

Правила між-Podʼової спорідненості та антиспорідненості мають наступний вигляд: "цей Pod повинен (або, у випадку антиспорідненості, не повинен) працювати у X, якщо на цьому X вже працюють один або декілька Podʼів, які задовольняють правилу Y", де X є областю топології, такою як вузол, стійка, зона або регіон постачальника хмарних послуг, або щос подібне, а Y — це правило, яке Kubernetes намагається задовольнити.

Ви виражаєте ці правила (Y) як селектори міток з опційним повʼязаним списком просторів імен. Podʼи є обʼєктами з простором імен в Kubernetes, тому мітки Podʼів також неявно мають простори імен. Будь-які селектори міток для міток Podʼа повинні вказувати простори імен, в яких Kubernetes має переглядати ці мітки.

Ви виражаєте область топології (X), використовуючи topologyKey, який є ключем для мітки вузла, яку система використовує для позначення домену. Для прикладу дивіться у Відомі мітки, анотації та позначення.

Типи між-Podʼової спорідненості та антиспорідненості

Подібно до Node affinnity, існують два типи спорідненості та антиспорідненості Podʼа:

  • requiredDuringSchedulingIgnoredDuringExecution
  • preferredDuringSchedulingIgnoredDuringExecution

Наприклад, ви можете використовувати спорідненість requiredDuringSchedulingIgnoredDuringExecution, щоб повідомити планувальник про те, що потрібно розташувати Podʼи двох служб в тій самій зоні постачальника хмарних послуг, оскільки вони взаємодіють між собою дуже часто. Так само ви можете використовувати антиспорідненість preferredDuringSchedulingIgnoredDuringExecution, щоб розподілити Podʼи служби по різних зонах постачальника хмарних послуг.

Для використання між-Podʼової спорідненості використовуйте поле affinity.podAffinity в специфікації Podʼа. Для між-Podʼової антиспорідненості використовуйте поле affinity. podAntiAffinity в специфікації Podʼа.

Планування групи Podʼів з між-Podʼовою спорідненістю

Якщо поточний Pod, який планується, є першим у серії, який має спорідненість один до одного, його можна планувати, якщо він проходить всі інші перевірки спорідненості. Це визначається тим, що не існує іншого Podʼа в кластері, який відповідає простору імен та селектору цього Podʼа, що Pod відповідає власним умовам і обраний вузол відповідає всім запитаним топологіям. Це забезпечує відсутність блокування навіть у випадку, якщо всі Podʼи мають вказану між-Podʼову спорідненість.

Приклад спорідненості Podʼа

Розгляньте наступну специфікацію Podʼа:

apiVersion: v1
kind: Pod
metadata:
  name: with-pod-affinity
spec:
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: security
            operator: In
            values:
            - S1
        topologyKey: topology.kubernetes.io/zone
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: security
              operator: In
              values:
              - S2
          topologyKey: topology.kubernetes.io/zone
  containers:
  - name: with-pod-affinity
    image: registry.k8s.io/pause:2.0

У цьому прикладі визначено одне правило спорідненості Podʼа та одне правило антиспорідненості Podʼа. Правило спорідненості Podʼа використовує "hard" requiredDuringSchedulingIgnoredDuringExecution, тоді як правило антиспорідненості використовує "soft" preferredDuringSchedulingIgnoredDuringExecution.

Правило спорідненості вказує, що планувальник може розмістити Pod лише на вузлі, який належить до певної зони, де інші Podʼи мають мітку security=S1. Наприклад, якщо у нас є кластер із призначеною зоною, скажімо, "Zone V", що складається з вузлів з міткою topology.kubernetes.io/zone=V, планувальник може призначити Pod на будь-який вузол у Zone V, якщо принаймні один Pod у Zone V вже має мітку security=S1. Зворотно, якщо в Zone V немає Podʼів з мітками security=S1, планувальник не призначить Pod з прикладц ні на один вузол в цій зоні.

Правило антиспорідненості вказує, що планувальник повинен уникати призначення Podʼа на вузол, якщо цей вузол належить до певної зони, де інші Podʼи мають мітку security=S2. Наприклад, якщо у нас є кластер із призначеною зоною, скажімо, "Zone R", що складається з вузлів з міткою topology.kubernetes.io/zone=R, планувальник повинен уникати призначення Podʼа на будь-який вузол у Zone R, якщо принаймні один Pod у Zone R вже має мітку security=S2. Зворотно, правило антиспорідненості не впливає на планування у Zone R, якщо немає Podʼів з мітками security=S2.

Щоб ближче ознайомитися з прикладами спорідненості та антиспорідненості Podʼів, зверніться до проєктної документації.

В полі operator для спорідненості та антиспорідненості Podʼа можна використовувати значення In, NotIn, Exists та DoesNotExist.

Для отримання додаткової інформації про те, як це працює, перегляньте Оператори.

У принципі, topologyKey може бути будь-яким допустимим ключем мітки з такими винятками з причин продуктивності та безпеки:

  • Для спорідненості та антиспорідненості Podʼа пусте поле topologyKey не дозволяється як для requiredDuringSchedulingIgnoredDuringExecution, так і для preferredDuringSchedulingIgnoredDuringExecution.
  • Для правил антиспорідненості Podʼа requiredDuringSchedulingIgnoredDuringExecution контролер допуску LimitPodHardAntiAffinityTopology обмежує topologyKey до kubernetes.io/hostname. Ви можете змінити або вимкнути контролер допуску, якщо хочете дозволити власні топології.

Крім labelSelector та topologyKey, ви можете опціонально вказати список просторів імен, з якими labelSelector повинен зіставлятися, використовуючи поле namespaces на тому ж рівні, що й labelSelector та topologyKey. Якщо відсутнє або порожнє, namespaces типово відноситься до простору імен Podʼа, де зʼявляється визначення спорідненості/антиспорідненості.

Селектор простору імен

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.24 [stable]

Ви також можете вибирати відповідні простори імен за допомогою namespaceSelector, який є запитом міток до набору просторів імен. Умова спорідненості застосовується до просторів імен, вибраних як namespaceSelector, так і полем namespaces. Зверніть увагу, що порожній namespaceSelector ({}) відповідає всім просторам імен, тоді як нульовий або порожній список namespaces і нульовий namespaceSelector відповідає простору імен Podʼа, де визначена правило.

matchLabelKeys

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.31 [beta]

У Kubernetes є опціональне поле matchLabelKeys для спорідненості або антиспорідненості Podʼа. Це поле вказує ключі для міток, які повинні відповідати міткам вхідного Podʼа під час задоволення спорідненості (антиспорідненості) Podʼа.

Ці ключі використовуються для отримання значень з міток Podʼа; ці ключ-значення міток поєднуються (використовуючи AND) з обмеженнями відповідно до поля labelSelector. Обʼєднане фільтрування вибирає набір наявниї Podʼів, які будуть враховуватися при розрахунку спорідненості (антиспорідненості) Podʼа.

Частим використанням є використання matchLabelKeys разом із pod-template-hash (встановленим у Podʼах, керованих як частина Deployment, де значення унікальне для кожного покоління). Використання pod-template-hash в matchLabelKeys дозволяє вам спрямовувати Podʼи, які належать тому ж поколінню, що й вхідний Pod, так щоб поступове оновлення не руйнувало споріденість.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: application-server
...
spec:
  template:
    spec:
      affinity:
        podAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - database
            topologyKey: topology.kubernetes.io/zone
            # Тільки Podʼи з певного розгортання беруться до уваги при обчисленні спорідненості Podʼа.
            # Якщо ви оновите Deployment, підмінні Podʼи дотримуватимуться своїх власних правил спорідненості
            # (якщо вони визначені в новому шаблоні Podʼа).
            matchLabelKeys:
            - pod-template-hash

mismatchLabelKeys

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.31 [beta]

Kubernetes включає додаткове поле mismatchLabelKeys для спорідненості або антиспорідненості Podʼа. Це поле вказує ключі для міток, які не повинні мати збігу з мітками вхідного Podʼа, при задоволенні спорідненості чи антиспорідненості Podʼа.

Один з прикладів використання — це забезпечення того, що Podʼи будуть розміщені в топологічному домені (вузол, зона і т. д.), де розміщені лише Podʼи від того ж орендаря або команди. Іншими словами, ви хочете уникнути запуску Podʼів від двох різних орендарів в одному топологічному домені одночасно.

apiVersion: v1
kind: Pod
metadata:
  labels:
    # Припустимо, що всі відповідні Podʼи мають встановлену мітку "tenant"
    tenant: tenant-a
...
spec:
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      # переконаємось, що Podʼи, повʼязані з цим орендарем, потрапляють у відповідний пул вузлів
      - matchLabelKeys:
          - tenant
        topologyKey: node-pool
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      # переконаємось, що Podʼи, повʼязані з цим орендарем, не можуть розміщуватися на вузлах,
      # які використовуються для іншого орендаря
      - mismatchLabelKeys:
        - tenant # незалежно від значення мітки "tenant" для цього Podʼа, заборонити
                 # розміщення на вузлах у будь-якому пулі, де працює будь-який Pod
                 # від іншого орендаря.
        labelSelector:
          # Ми повинні мати labelSelector, який вибирає лише Podʼи з міткою орендатора,
          # інакше цей Pod буде ворогувати Podʼам з DaemonSetʼів, наприклад,
          # які не повинні мати мітку орендаря.
          matchExpressions:
          - key: tenant
            operator: Exists
        topologyKey: node-pool

Ще кілька практичних прикладів

Між-Podʼові спорідненість та антиспорідненість можуть бути навіть більш корисними, коли вони використовуються з колекціями вищого рівня, такими як ReplicaSets, StatefulSets, Deployments і т. д. Ці правила дозволяють налаштувати спільне розташування набору робочих навантажень у визначеній топології; наприклад, віддаючи перевагу розміщенню двох повʼязаних Podʼів на одному вузлі.

Наприклад: уявіть кластер з трьох вузлів. Ви використовуєте кластер для запуску вебзастосунку та також сервіс кешування в памʼяті (наприклад, Redis). Нехай для цього прикладу також буде фіксований максимальний рівень затримки між вебзастосунком та цим кешем, як це практично можливо. Ви можете використовувати між-Podʼові спорідненість та антиспорідненість, щоб спільні вебсервери з кешем, як це можна точніше, розташовувалися поруч.

У наступному прикладі Deployment для кешування Redis, репліки отримують мітку app=store. Правило podAntiAffinity повідомляє планувальникові уникати розміщення декількох реплік з міткою app=store на одному вузлі. Це створює кожен кеш на окремому вузлі.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: redis-cache
spec:
  selector:
    matchLabels:
      app: store
  replicas: 3
  template:
    metadata:
      labels:
        app: store
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - store
            topologyKey: "kubernetes.io/hostname"
      containers:
      - name: redis-server
        image: redis:3.2-alpine

У наступному прикладі Deployment для вебсерверів створює репліки з міткою app=web-store. Правило спорідненості Podʼа повідомляє планувальнику розмістити кожну репліку на вузлі, де є Pod з міткою app=store. Правило антиспорідненості Podʼа повідомляє планувальнику ніколи не розміщати декілька серверів app=web-store на одному вузлі.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-server
spec:
  selector:
    matchLabels:
      app: web-store
  replicas: 3
  template:
    metadata:
      labels:
        app: web-store
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - web-store
            topologyKey: "kubernetes.io/hostname"
        podAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - store
            topologyKey: "kubernetes.io/hostname"
      containers:
      - name: web-app
        image: nginx:1.16-alpine

Створення цих двох попередніх Deploymentʼів призводить до наступного структури кластера, де кожен вебсервер знаходиться поруч з кешем, на трьох окремих вузлах.

вузол-1вузол-2вузол-3
webserver-1webserver-2webserver-3
cache-1cache-2cache-3

Загальний ефект полягає в тому, що кожен екземпляр кешу ймовірно використовується одним клієнтом, який працює на тому ж самому вузлі. Цей підхід спрямований на мінімізацію як перекосу (нерівномірного навантаження), так і затримки.

У вас можуть бути інші причини використання антиспорідненості Podʼа. Дивіться посібник по ZooKeeper для прикладу StatefulSet, налаштованого з антиспорідненостю для забезпечення високої доступності, використовуючи ту ж саму техніку, що й цей приклад.

nodeName

nodeName є більш прямим способом вибору вузла, ніж спорідненісь або nodeSelector. nodeName — це поле в специфікації Pod. Якщо поле nodeName не порожнє, планувальник ігнорує Pod, і kubelet на названому вузлі намагається розмістити Pod на цьому вузлі. Використання nodeName переважає використання nodeSelector або правил спорідненості та антиспорідненості.

Деякі з обмежень використання nodeName для вибору вузлів:

  • Якщо зазначений вузол не існує, Pod не буде запущено, і у деяких випадках його може бути автоматично видалено.
  • Якщо зазначений вузол не має достатньо ресурсів для розміщення Podʼа, Pod зазнає збою, про що буде повідомлено, наприклад, OutOfmemory або OutOfcpu.
  • Назви вузлів у хмарних середовищах не завжди передбачувані або стабільні.

Нижче наведено приклад специфікації Pod з використанням поля nodeName:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx
  nodeName: kube-01

Вищевказаний Pod буде запущено лише на вузлі kube-01.

Обмеження розподілу топології Pod

Ви можете використовувати обмеження розподілу топології для керування тим, як Podʼи розподіляються по вашому кластеру серед недоступних доменів, таких як регіони, зони, вузли або будь-які інші топологічні домени, які ви визначаєте. Ви можете це зробити, щоб покращити продуктивність, очікувану доступність або загальне використання.

Докладніше про роботу з обмеженнями розподілу топології Podʼів читайте тут.

Оператори

Наступні логічні оператори можна використовувати в полі operator для nodeAffinity та podAffinity, згаданих вище.

ОператорПоведінка
InЗначення мітки присутнє у заданому наборі рядків
NotInЗначення мітки не міститься у заданому наборі рядків
ExistsМітка з цим ключем існує на обʼєкті
DoesNotExistНа обʼєкті не існує мітки з цим ключем

Наступні оператори можна використовувати лише з nodeAffinity.

ОператорПоведінка
GtЗначення поля буде розібране як ціле число, і це ціле число менше цілого числа, яке отримується при розборі значення мітки, названої цим селектором
LtЗначення поля буде розібране як ціле число, і це ціле число більше цілого числа, яке отримується при розборі значення мітки, названої цим селектором

Що далі

3.10.3 - Накладні витрати, повʼязані з роботою Podʼів

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.24 [stable]

Коли ви запускаєте Pod на вузлі, сам Pod потребує певної кількості системних ресурсів. Ці ресурси додаються до ресурсів, необхідних для запуску контейнерів всередині Pod. У Kubernetes Pod Overhead — це спосіб обліку ресурсів, які використовуються інфраструктурою Pod, понад запити та обмеження контейнерів.

У Kubernetes накладні витрати Pod встановлюються під час допуску з урахуванням перевищення, повʼязаного з RuntimeClass Pod.

Накладні витрати Pod вважаються додатковими до суми запитів ресурсів контейнера при плануванні Pod. Так само, kubelet включатиме накладні витрати Pod при визначенні розміру cgroup Podʼа і при виконанні ранжування виселення Podʼа.

Налаштування накладних витрат Pod

Вам потрібно переконатися, що використовується RuntimeClass, який визначає поле overhead.

Приклад використання

Для роботи з накладними витратами Podʼів вам потрібен RuntimeClass, який визначає поле overhead. Наприклад, ви можете використати таке визначення RuntimeClass з контейнерним середовищем віртуалізації (в цьому прикладі використовується Kata Containers поєднане з монітором віртуальної машини Firecracker), яке використовує приблизно 120MiB на Pod для віртуальної машини та гостьової ОС:

# Вам треба внести зміни в цей приклад, щоб назва відповідала вашому контейнерному середовищу
# та ресурси overhead були додани до вашого кластера.
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: kata-fc
handler: kata-fc
overhead:
  podFixed:
    memory: "120Mi"
    cpu: "250m"

Робочі навантаження, які створюються з використанням обробника RuntimeClass з іменем kata-fc, беруть участь в обчисленнях квот ресурсів, плануванні вузла, а також розмірі групи контейнерів Pod для памʼяті та CPU.

Розгляньте виконання поданого прикладу робочого навантаження, test-pod:

apiVersion: v1
kind: Pod
metadata:
  name: test-pod
spec:
  runtimeClassName: kata-fc
  containers:
  - name: busybox-ctr
    image: busybox:1.28
    stdin: true
    tty: true
    resources:
      limits:
        cpu: 500m
        memory: 100Mi
  - name: nginx-ctr
    image: nginx
    resources:
      limits:
        cpu: 1500m
        memory: 100Mi

Під час обробки допуску (admission) контролер admission controller RuntimeClass оновлює PodSpec робочого навантаження, щоб включити overhead, що є в RuntimeClass. Якщо PodSpec вже має це поле визначеним, Pod буде відхилено. У поданому прикладі, оскільки вказано лише імʼя RuntimeClass, контролер обробки допуску змінює Pod, щоб включити overhead.

Після того, як контролер обробки допуску RuntimeClass вніс зміни, ви можете перевірити оновлене значення overhead Pod:

kubectl get pod test-pod -o jsonpath='{.spec.overhead}'

Вивід:

map[cpu:250m memory:120Mi]

Якщо визначено ResourceQuota, то обчислюється сума запитів контейнера, а також поля overhead.

Коли kube-scheduler вирішує, на якому вузлі слід запускати новий Pod, він бере до уваги overhead цього Pod, а також суму запитів контейнера для цього Pod. Для цього прикладу планувальник додає запити та overhead, а потім шукає вузол, на якому є 2,25 CPU та 320 MiB вільної памʼяті.

Після того, як Pod запланований на вузол, kubelet на цьому вузлі створює нову cgroup для Pod. Це саме той Pod, в межах якого контейнерне середовище створює контейнери.

Якщо для кожного контейнера визначено ліміт ресурсу (Guaranteed QoS або Burstable QoS з визначеними лімітами), то kubelet встановлює верхній ліміт для групи контейнерів Pod, повʼязаних з цим ресурсом (cpu.cfs_quota_us для CPU та memory.limit_in_bytes для памʼяті). Цей верхній ліміт базується на сумі лімітів контейнера плюс поле overhead, визначене в PodSpec.

Для CPU, якщо Pod має Guaranteed або Burstable QoS, то kubelet встановлює cpu.shares на основі суми запитів контейнера плюс поле overhead, визначене в PodSpec.

Подивіться приклад, перевірте запити контейнера для робочого навантаження:

kubectl get pod test-pod -o jsonpath='{.spec.containers[*].resources.limits}'

Загальні запити контейнера становлять 2000m CPU та 200MiB памʼяті:

map[cpu: 500m memory:100Mi] map[cpu:1500m memory:100Mi]

Перевірте це у порівнянні з тим, що спостерігається вузлом:

kubectl describe node | grep test-pod -B2

Вивід показує запити для 2250m CPU та 320MiB памʼяті. Запити включають перевищення Pod:

  Namespace    Name       CPU Requests  CPU Limits   Memory Requests  Memory Limits  AGE
  ---------    ----       ------------  ----------   ---------------  -------------  ---
  default      test-pod   2250m (56%)   2250m (56%)  320Mi (1%)       320Mi (1%)     36m

Перевірка обмежень cgroup для Pod

Перевірте cgroup памʼяті для Pod на вузлі, де запускається робоче навантаження. У наступному прикладі використовується crictl на вузлі, який надає інтерфейс командного рядка для сумісних з CRI контейнерних середовищ. Це передбачається для демонстрації поведінки overhead Podʼа, і не очікується, що користувачі повинні безпосередньо перевіряти cgroups на вузлі.

Спочатку, на конкретному вузлі, визначте ідентифікатор Pod:

# Виконайте це на вузлі, де запущено Pod
POD_ID="$(sudo crictl pods --name test-pod -q)"

З цього можна визначити шлях cgroup для Pod:

# Виконайте це на вузлі, де запущено Pod
sudo crictl inspectp -o=json $POD_ID | grep cgroupsPath

Результати шляху cgroup включають контейнер pause для Pod. Рівень cgroup на рівні Pod знаходиться на один каталог вище.

  "cgroupsPath": "/kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2/7ccf55aee35dd16aca4189c952d83487297f3cd760f1bbf09620e206e7d0c27a"

У цьому конкретному випадку, шлях cgroup для Pod — kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2. Перевірте налаштування рівня cgroup для памʼяті на рівні Pod:

# Виконайте це на вузлі, де запущено Pod.
# Також, змініть назву cgroup, щоб відповідати призначеному вашому pod cgroup.
 cat /sys/fs/cgroup/memory/kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2/memory.limit_in_bytes

Це 320 МіБ, як і очікувалося:

335544320

Спостережуваність

Деякі метрики kube_pod_overhead_* доступні у kube-state-metrics для ідентифікації використання накладних витрат Pod та спостереження стабільності робочих навантажень, які працюють з визначеним overhead.

Що далі

3.10.4 - Готовність планування Pod

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.30 [stable]

Podʼи вважалися готовими до планування відразу після створення. Планувальник Kubernetes виконує всі необхідні дії для знаходження вузлів для розміщення всіх Podʼів, що очікують. Однак на практиці деякі Podʼи можуть перебувати в стані "відсутні ресурси" ("miss-essential-resources") протягом тривалого періоду. Ці Podʼи фактично спричиняють зайве навантаження на планувальник (та інтегратори, по ходу далі, такі як Cluster AutoScaler), що є непотрібним.

Шляхом вказання/видалення поля .spec.schedulingGates для Podʼа ви можете контролювати, коли Pod готовий до розгляду для планування.

Налаштування schedulingGates Podʼа

Поле schedulingGates містить список рядків, і кожний рядок сприймається як критерій, який повинен бути задоволений перед тим, як Pod буде вважатися придатним для планування. Це поле можна ініціалізувати лише при створенні Podʼа (або клієнтом, або під час змін під час допуску). Після створення кожен schedulingGate можна видалити у довільному порядку, але додавання нового scheduling gate заборонено.

stateDiagram-v2 s1: Pod створено s2: Планування Pod очікується s3: Планування Pod готову s4: Pod виконується if: є порожні слоти планування? [*] --> s1 s1 --> if s2 --> if: обмеження
планування
зняте if --> s2: ні if --> s3: так s3 --> s4 s4 --> [*] classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; class s1,s2,s3,s4,if k8s

Приклад використання

Щоб позначити Pod як не готовий до планування, ви можете створити його з одним або кількома шлюзами планування так:

apiVersion: v1
kind: Pod
metadata:
  name: test-pod
spec:
  schedulingGates:
  - name: example.com/foo
  - name: example.com/bar
  containers:
  - name: pause
    image: registry.k8s.io/pause:3.6

Після створення Podʼа ви можете перевірити його стан за допомогою:

kubectl get pod test-pod

Вивід показує, що він знаходиться в стані SchedulingGated:

NAME       READY   STATUS            RESTARTS   AGE
test-pod   0/1     SchedulingGated   0          7s

Ви також можете перевірити його поле schedulingGates, запустивши:

kubectl get pod test-pod -o jsonpath='{.spec.schedulingGates}'

Вивід:

[{"name":"example.com/foo"},{"name":"example.com/bar"}]

Щоб повідомити планувальник, що цей Pod готовий до планування, ви можете повністю видалити його schedulingGates шляхом повторного застосування зміненого маніфесту:

apiVersion: v1
kind: Pod
metadata:
  name: test-pod
spec:
  containers:
  - name: pause
    image: registry.k8s.io/pause:3.6

Ви можете перевірити, чи очищено schedulingGates, виконавши:

kubectl get pod test-pod -o jsonpath='{.spec.schedulingGates}'

Очікується, що вивід буде порожнім. І ви можете перевірити його останній стан, запустивши:

kubectl get pod test-pod -o wide

Враховуючи те, що test-pod не запитує жодних ресурсів CPU/памʼяті, очікується, що стан цього Podʼа перейде з попереднього SchedulingGated в Running:

NAME       READY   STATUS    RESTARTS   AGE   IP         NODE
test-pod   1/1     Running   0          15s   10.0.0.4   node-2

Спостережуваність

Метрика scheduler_pending_pods має нову мітку "gated", щоб відрізняти, чи були спроби планувати Podʼа, але він був визначений як непридатний для планування, чи він явно позначений як не готовий для планування. Ви можете використовувати scheduler_pending_pods{queue="gated"} для перевірки результату метрики.

Змінні директиви планування Podʼа

Ви можете змінювати директиви планування Podʼа, коли вони мають шлюзи планування, з певними обмеженнями. Узагальнено, ви можете тільки робити директиви планування Podʼа жорсткішими. Іншими словами, оновлені директиви призведуть до можливості розміщення Podʼів тільки на підмножині вузлів, з якими вони раніше мали збіг. Конкретніше, правила для оновлення директив планування Podʼа такі:

  1. Для .spec.nodeSelector дозволяються лише додавання. Якщо відсутнє, його можна встановити.

  2. Для spec.affinity.nodeAffinity, якщо nil, тоді дозволяється встановлення будь-чого.

  3. Якщо NodeSelectorTerms був пустим, дозволено встановлення. Якщо не пустий, тоді дозволяються лише додавання NodeSelectorRequirements до matchExpressions або fieldExpressions, а зміни наявних matchExpressions і fieldExpressions не будуть дозволені. Це через те, що терміни в .requiredDuringSchedulingIgnoredDuringExecution.NodeSelectorTerms, оцінюються через OR тоді як вирази в nodeSelectorTerms[].matchExpressions та nodeSelectorTerms[].fieldExpressions оцінюються через AND.

  4. Для .preferredDuringSchedulingIgnoredDuringExecution всі оновлення дозволені. Це повʼязано з тим, що бажані умови не є авторитетними, і тому контролери політики не підтверджують ці умови.

Що далі

3.10.5 - Обмеження поширення топології Podʼів

Ви можете використовувати обмеження поширення топології для контролю того, як Podʼи розподіляються по вашому кластеру серед доменів відмов, таких як регіони, зони, вузли та інші користувацькі топологічні домени. Це може допомогти забезпечити високу доступність, а також ефективне використання ресурсів.

Ви можете встановлювати типові обмеження на рівні кластера або налаштовувати обмеження поширення топології для окремих навантажень.

Мотивація

Уявіть, що у вас є кластер, в якому до двадцяти вузлів, і ви хочете запустити навантаження, яке автоматично масштабує кількість реплік, які використовує. Тут може бути як два Podʼи, так і пʼятнадцять. Коли є лише два Podʼи, ви б хотіли, щоб обидва ці Podʼи не працювали на одному вузлі: ви ризикуєте, що відмова одного вузла призведе до зникнення доступу до вашого навантаження.

Крім цього основного використання, є деякі приклади використання, які дозволяють вашим навантаженням отримувати переваги високої доступності та використання кластера.

При масштабуванні та запуску більшої кількості Podʼів важливим стає інша проблема. Припустімо, що у вас є три вузли, на яких працюють по пʼять Podʼів кожен. У вузлах достатньо потужності для запуску такої кількості реплік; проте клієнти, які взаємодіють з цим навантаженням, розподілені по трьох різних центрах обробки даних (або зонах інфраструктури). Тепер ви менше хвилюєтеся про відмову одного вузла, але ви помічаєте, що затримка вища, ніж ви хотіли б, і ви платите за мережеві витрати, повʼязані з передачею мережевого трафіку між різними зонами.

Ви вирішуєте, що при нормальній роботі ви б хотіли, щоб у кожній інфраструктурній зоні була приблизно однакова кількість реплік, і ви хотіли б, щоб кластер самостійно відновлювався у разі виникнення проблеми.

Обмеження поширення топології Podʼів пропонують вам декларативний спосіб налаштування цього.

Поле topologySpreadConstraints

У API Pod є поле spec.topologySpreadConstraints. Використання цього поля виглядає так:

---
apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  # Налаштувати обмеження поширення топології
  topologySpreadConstraints:
    - maxSkew: <ціле число>
      minDomains: <ціле число> # необовʼязково
      topologyKey: <рядок>
      whenUnsatisfiable: <рядок>
      labelSelector: <обʼєкт>
      matchLabelKeys: <список> # необовʼязково; бета з v1.27
      nodeAffinityPolicy: [Honor|Ignore] # необовязково; бета з v1.26
      nodeTaintsPolicy: [Honor|Ignore] # необовязково; бета з v1.26
  ### інші поля Pod тут

Додаткову інформацію про це поле можна отримати, запустивши команду kubectl explain Pod.spec.topologySpreadConstraints або звернувшись до розділу планування довідки API для Pod.

Визначення обмежень поширення топології

Ви можете визначити один або кілька записів topologySpreadConstraints, щоб вказати kube-scheduler, як розмістити кожний вхідний Pod у відповідно до наявних Podʼів у всьому кластері. Ці поля включають:

  • maxSkew описує ступінь нерівномірного поширення Pod. Ви повинні вказати це поле, і число повинно бути більше нуля. Його семантика відрізняється залежно від значення whenUnsatisfiable:

    • якщо ви виберете whenUnsatisfiable: DoNotSchedule, тоді maxSkew визначає максимально допустиму різницю між кількістю відповідних Podʼів у цільовій топології та глобальним мінімумом (мінімальна кількість відповідних Podʼів у прийнятній області або нуль, якщо кількість прийнятних областей менше, ніж MinDomains). Наприклад, якщо у вас є 3 зони з 2, 2 та 1 відповідно відповідних Podʼів, MaxSkew встановлено на 1, тоді глобальний мінімум дорівнює 1.
    • якщо ви виберете whenUnsatisfiable: ScheduleAnyway, планувальник надає вищий пріоритет топологіям, які допомагають зменшити розрив.
  • minDomains вказує мінімальну кількість прийнятних областей. Це поле є необовʼязковим. Домен — це певний екземпляр топології. Прийнятний домен — це домен, чиї вузли відповідають селектору вузлів.

    • Значення minDomains повинно бути більше ніж 0, коли вказано. Ви можете вказати minDomains лише разом з whenUnsatisfiable: DoNotSchedule.
    • Коли кількість прийнятних доменів з відповідними ключами топології менше minDomains, розподіл топології Pod розглядає глобальний мінімум як 0, а потім виконується розрахунок skew. Глобальний мінімум — це мінімальна кількість відповідних Podʼів у прийнятному домені, або нуль, якщо кількість прийнятних доменів менше, ніж minDomains.
    • Коли кількість прийнятних доменів з відповідними ключами топології дорівнює або більше minDomains, це значення не впливає на планування.
    • Якщо ви не вказуєте minDomains, обмеження поводиться так, як якби minDomains дорівнював 1.
  • topologyKey — ключ міток вузла. Вузли, які мають мітку з цим ключем і ідентичними значеннями, вважаються присутніми в тій самій топології. Кожен екземпляр топології (іншими словами, пара <ключ, значення>) називається доменом. Планувальник спробує помістити вирівняну кількість Podʼів в кожен домен. Також ми визначаємо прийнятний домен як домен, вузли якої відповідають вимогам nodeAffinityPolicy та nodeTaintsPolicy.

  • whenUnsatisfiable вказує, як розвʼязувати проблему з Pod, якщо він не відповідає обмеженню поширення:

    • DoNotSchedule (типово) вказує планувальнику не планувати його.
    • ScheduleAnyway вказує планувальнику все одно його планувати, проте з пріоритетом вибору вузлів, що мінімізують розрив.
  • labelSelector використовується для знаходження відповідних Podʼів. Podʼи, які відповідають цьому селектору міток, враховуються для визначення кількості Podʼів у відповідному домені топології. Дивіться селектори міток для отримання додаткових відомостей.

  • matchLabelKeys — це список ключів міток Podʼа для вибору Podʼів, відносно яких буде розраховано поширення. Ключі використовуються для вибору значень з міток Podʼів, ці ключі-значення міток AND labelSelector вибирають групу наявних Podʼів, відносно яких буде розраховано поширення для вхідного Podʼа. Існування однакового ключа заборонене як у matchLabelKeys, так і в labelSelector. matchLabelKeys не може бути встановлено, коли labelSelector не встановлено. Ключі, яких не існує в мітках Podʼа, будуть проігноровані. Порожній або нульовий список означає, що збіг буде відповідати лише labelSelector.

    З matchLabelKeys вам не потрібно оновлювати pod.spec між різними версіями. Контролер/оператор просто повинен встановити різні значення для того самого ключа мітки для різних версій. Планувальник автоматично припускає значення на основі matchLabelKeys. Наприклад, якщо ви налаштовуєте Deployment, ви можете використовувати мітку за ключем pod-template-hash, яка додається автоматично контролером Deployment, для розрізнення різних версій в одному Deployment.

        topologySpreadConstraints:
            - maxSkew: 1
              topologyKey: kubernetes.io/hostname
              whenUnsatisfiable: DoNotSchedule
              labelSelector:
                matchLabels:
                  app: foo
              matchLabelKeys:
                - pod-template-hash
    
  • nodeAffinityPolicy вказує, як ми будемо обробляти nodeAffinity/nodeSelector Pod, коли розраховуємо розрив поширення топології Podʼів. Опції:

    • Honor: до розрахунків включаються лише вузли, які відповідають nodeAffinity/nodeSelector.
    • Ignore: nodeAffinity/nodeSelector ігноруються. Включаються всі вузли.

    Якщо це значення є null, поведінка еквівалентна політиці Honor.

  • nodeTaintsPolicy вказує, як ми будемо обробляти заплямованість вузлів при розрахунку розриву поширення топології Podʼів. Опції:

    • Honor: включаються вузли без заплямованості, разом з заплямованими вузлами, для яких вхідний Pod має толерантність.
    • Ignore: заплямованість вузла ігноруються. Включаються всі вузли.

    Якщо це значення є null, поведінка еквівалентна політиці Ignore.

Коли Pod визначає більше одного topologySpreadConstraint, ці обмеження комбінуються за допомогою операції AND: kube-scheduler шукає вузол для вхідного Podʼа, який задовольняє всі налаштовані обмеження.

Мітки вузлів

Обмеження поширення топології ґрунтуються на мітках вузлів для ідентифікації доменів топології, в яких знаходиться кожен вузол. Наприклад, вузол може мати такі мітки:

  region: us-east-1
  zone: us-east-1a

Припустимо, у вас є кластер з 4 вузлами з наступними мітками:

NAME    STATUS   ROLES    AGE     VERSION   LABELS
node1   Ready    <none>   4m26s   v1.16.0   node=node1,zone=zoneA
node2   Ready    <none>   3m58s   v1.16.0   node=node2,zone=zoneA
node3   Ready    <none>   3m17s   v1.16.0   node=node3,zone=zoneB
node4   Ready    <none>   2m43s   v1.16.0   node=node4,zone=zoneB

Тоді кластер логічно виглядає так:

graph TB subgraph "zoneB" n3(Node3) n4(Node4) end subgraph "zoneA" n1(Node1) n2(Node2) end classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000; classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5; class n1,n2,n3,n4 k8s; class zoneA,zoneB cluster;

Узгодженість

Вам слід встановити однакові обмеження поширення топології Podʼів для всіх Podʼів у групі.

Зазвичай, якщо ви використовуєте контролер робочого навантаження, такий як Deployment, шаблон Podʼа забезпечує це за вас. Якщо ви комбінуєте різні обмеження поширення, то Kubernetes дотримується визначення API поля; однак, це більш ймовірно призведе до плутанини в поведінці, а усунення несправностей буде менш прямолінійним.

Вам потрібен механізм для забезпечення того, що всі вузли в домені топології (наприклад, регіон хмарного постачальника) мають однакові мітки. Щоб уникнути необхідності ручного маркування вузлів, більшість кластерів автоматично заповнюють відомі мітки, такі як kubernetes.io/hostname. Перевірте, чи підтримує ваш кластер це.

Приклад обмеження розподілу топології

Приклад: одне обмеження розподілу топології

Припустимо, у вас є кластер із чотирма вузлами, де 3 Podʼа з міткою foo: bar знаходяться на вузлах node1, node2 та node3 відповідно:

graph BT subgraph "zoneB" p3(Pod) --> n3(Node3) n4(Node4) end subgraph "zoneA" p1(Pod) --> n1(Node1) p2(Pod) --> n2(Node2) end classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000; classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5; class n1,n2,n3,n4,p1,p2,p3 k8s; class zoneA,zoneB cluster;

Якщо ви хочете, щоб новий Pod рівномірно розподілявся з наявними Podʼами по зонах, ви можете використовувати маніфест Podʼів, схожий на такий:

kind: Pod
apiVersion: v1
metadata:
  name: mypod
  labels:
    foo: bar
spec:
  topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: zone
    whenUnsatisfiable: DoNotSchedule
    labelSelector:
      matchLabels:
        foo: bar
  containers:
  - name: pause
    image: registry.k8s.io/pause:3.1

У цьому маніфесті topologyKey: zone означає, що рівномірне поширення буде застосовуватися лише до вузлів, які мають мітку zone: <будь-яке значення> (вузли, які не мають мітки zone, будуть пропущені). Поле whenUnsatisfiable: DoNotSchedule повідомляє планувальнику, що потрібно залишити новий Pod у стані очікування, якщо планувальник не може знайти спосіб задовольнити обмеження.

Якщо планувальник розмістить цей новий Pod у зоні A, розподіл Podʼів стане [3, 1]. Це означає, що фактичне відхилення складає 2 (розраховане як 3 - 1), що порушує maxSkew: 1. Щоб задовольнити умови обмеження та контекст для цього прикладу, новий Pod може бути розміщений лише на вузлі в зоні B.

graph BT subgraph "zoneB" p3(Pod) --> n3(Node3) p4(mypod) --> n4(Node4) end subgraph "zoneA" p1(Pod) --> n1(Node1) p2(Pod) --> n2(Node2) end classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000; classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5; class n1,n2,n3,n4,p1,p2,p3 k8s; class p4 plain; class zoneA,zoneB cluster;

OR

graph BT subgraph "zoneB" p3(Pod) --> n3(Node3) p4(mypod) --> n3 n4(Node4) end subgraph "zoneA" p1(Pod) --> n1(Node1) p2(Pod) --> n2(Node2) end classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000; classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5; class n1,n2,n3,n4,p1,p2,p3 k8s; class p4 plain; class zoneA,zoneB cluster;

Ви можете змінити специфікацію Podʼа, щоб вона відповідала різним вимогам:

  • Змініть maxSkew на більше значення, наприклад 2, щоб новий Pod також можна було розмістити в зоні A.
  • Змініть topologyKey на node, щоб рівномірно розподілити Podʼи по вузлах, а не зонам. У вищезазначеному прикладі, якщо maxSkew залишиться 1, новий Pod може бути розміщений лише на вузлі node4.
  • Змініть whenUnsatisfiable: DoNotSchedule на whenUnsatisfiable: ScheduleAnyway, щоб гарантувати, що новий Pod завжди можна розмістити (якщо інші API планування задовольняються). Однак перевага надається розміщенню в області топології, яка має менше відповідних Podʼів. (Памʼятайте, що ця перевага спільно нормалізується з іншими внутрішніми пріоритетами планування, такими як відношення використання ресурсів).

Приклад: декілька обмежень поширення топології

Цей приклад будується на попередньому. Припустимо, у вашому кластері з 4 вузлами є 3 Podʼа, позначених як foo: bar, що знаходяться на вузлі node1, node2 і node3 відповідно:

graph BT subgraph "zoneB" p3(Pod) --> n3(Node3) n4(Node4) end subgraph "zoneA" p1(Pod) --> n1(Node1) p2(Pod) --> n2(Node2) end classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000; classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5; class n1,n2,n3,n4,p1,p2,p3 k8s; class p4 plain; class zoneA,zoneB cluster;

Ви можете поєднати два обмеження поширення топології, щоб контролювати розподіл Podʼів як за вузлами, так і за зонами:

kind: Pod
apiVersion: v1
metadata:
  name: mypod
  labels:
    foo: bar
spec:
  topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: zone
    whenUnsatisfiable: DoNotSchedule
    labelSelector:
      matchLabels:
        foo: bar
  - maxSkew: 1
    topologyKey: node
    whenUnsatisfiable: DoNotSchedule
    labelSelector:
      matchLabels:
        foo: bar
  containers:
  - name: pause
    image: registry.k8s.io/pause:3.1

У цьому випадку для збігу з першим обмеженням новий Pod може бути розміщений лише на вузлах у зоні B; тоді як для відповідності другому обмеженню новий Pod може бути розміщений лише на вузлі node4. Планувальник розглядає лише варіанти, які задовольняють всі визначені обмеження, тому єдине допустиме розташування — це на вузлі node4.

Приклад: конфліктуючі обмеження розподілу топології

Кілька обмежень може призвести до конфліктів. Припустимо, у вас є кластер з 3 вузлами у 2 зонах:

graph BT subgraph "zoneB" p4(Pod) --> n3(Node3) p5(Pod) --> n3 end subgraph "zoneA" p1(Pod) --> n1(Node1) p2(Pod) --> n1 p3(Pod) --> n2(Node2) end classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000; classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5; class n1,n2,n3,n4,p1,p2,p3,p4,p5 k8s; class zoneA,zoneB cluster;

Якщо ви застосуєте two-constraints.yaml (файл маніфесту з попереднього прикладу) до цього кластера, ви побачите, що Pod mypod залишається у стані Pending. Це трапляється тому, що для задоволення першого обмеження Pod mypod може бути розміщений лише у зоні B; тоді як для відповідності другому обмеженню Pod mypod може бути розміщений лише на вузлі node2. Перетин двох обмежень повертає порожній набір, і планувальник не може розмістити Pod.

Щоб подолати цю ситуацію, ви можете або збільшити значення maxSkew, або змінити одне з обмежень, щоб використовувати whenUnsatisfiable: ScheduleAnyway. Залежно від обставин, ви також можете вирішити видалити наявний Pod вручну — наприклад, якщо ви розвʼязуєте проблему, чому розгортання виправлення помилки не виконується.

Взаємодія з селектором вузла та спорідненістю вузла

Планувальник пропустить вузли, що не відповідають, з обчислень нерівності, якщо у вхідного Podʼа визначено spec.nodeSelector або spec.affinity.nodeAffinity.

Приклад: обмеження поширення топології зі спорідненістю вузла

Припустимо, у вас є 5-вузловий кластер, розташований у зонах A до C:

graph BT subgraph "zoneB" p3(Pod) --> n3(Node3) n4(Node4) end subgraph "zoneA" p1(Pod) --> n1(Node1) p2(Pod) --> n2(Node2) end classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000; classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5; class n1,n2,n3,n4,p1,p2,p3 k8s; class p4 plain; class zoneA,zoneB cluster;
graph BT subgraph "zoneC" n5(Node5) end classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000; classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5; class n5 k8s; class zoneC cluster;

і ви знаєте, що зону C потрібно виключити. У цьому випадку ви можете скласти маніфест, як наведено нижче, щоб Pod mypod був розміщений у зоні B, а не у зоні C. Так само Kubernetes також враховує spec.nodeSelector.

kind: Pod
apiVersion: v1
metadata:
  name: mypod
  labels:
    foo: bar
spec:
  topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: zone
    whenUnsatisfiable: DoNotSchedule
    labelSelector:
      matchLabels:
        foo: bar
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: zone
            operator: NotIn
            values:
            - zoneC
  containers:
  - name: pause
    image: registry.k8s.io/pause:3.1

Неявні домовленості

Тут є кілька неявних домовленостей, на які варто звернути увагу:

  • Тільки Podʼи, що належать тому же простору імен, що і вхідний Pod, можуть бути кандидатами на відповідність.

  • Планувальник обходить будь-які вузли, які не мають жодного присутнього topologySpreadConstraints[*].topologyKey. Це означає, що:

    1. будь-які Podʼи, що розташовані на цих обхідних вузлах, не впливають на обчислення maxSkew — в прикладі вище, припустимо, що вузол node1 не має мітки "zone", тоді 2 Podʼи будуть проігноровані, тому вхідний Pod буде заплановано в зону A.
    2. вхідний Pod не має шансів бути запланованим на такі вузли — у вищенаведеному прикладі, припустимо, що вузол node5 має невірно введену мітку zone-typo: zoneC (і не має жодної встановленої мітки zone). Після приєднання вузла node5 до кластера, він буде обходитися, і Podʼи для цього робочого навантаження не будуть плануватися туди.
  • Будьте уважні, якщо topologySpreadConstraints[*].labelSelector вхідного Podʼа не відповідає його власним міткам. У вищенаведеному прикладі, якщо ви видалите мітки вхідного Podʼа, він все ще може бути розміщений на вузлах у зоні B, оскільки обмеження все ще виконуються. Проте, після цього розміщення ступінь незбалансованості кластера залишається без змін — зона A все ще має 2 Podʼи з мітками foo: bar, а зона B має 1 Pod з міткою foo: bar. Якщо це не те, що ви очікуєте, оновіть topologySpreadConstraints[*].labelSelector робочого навантаження, щоб відповідати міткам в шаблоні Podʼа.

Типові обмеження на рівні кластера

Можливо встановити типові обмеження поширення топології для кластера. Типово обмеження поширення топології застосовуються до Podʼа лише в тому випадку, якщо:

  • Він не визначає жодних обмежень у своєму .spec.topologySpreadConstraints.
  • Він належить до Service, ReplicaSet, StatefulSet або ReplicationController.

Типові обмеження можна встановити як частину аргументів втулка PodTopologySpread в профілі планувальника. Обмеження вказуються з тими ж API вище, за винятком того, що labelSelector повинен бути пустим. Селектори обчислюються з Service, ReplicaSet, StatefulSet або ReplicationControllers, до яких належить Pod.

Приклад конфігурації може виглядати наступним чином:

apiVersion: kubescheduler.config.k8s.io/v1beta3
kind: KubeSchedulerConfiguration

profiles:
  - schedulerName: default-scheduler
    pluginConfig:
      - name: PodTopologySpread
        args:
          defaultConstraints:
            - maxSkew: 1
              topologyKey: topology.kubernetes.io/zone
              whenUnsatisfiable: ScheduleAnyway
          defaultingType: List

Вбудовані типові обмеження

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.24 [stable]

Якщо ви не налаштовуєте жодних типових обмежень для поширення топології Podʼа на рівні кластера, то kube-scheduler діє так, ніби ви вказали наступні обмеження:

defaultConstraints:
  - maxSkew: 3
    topologyKey: "kubernetes.io/hostname"
    whenUnsatisfiable: ScheduleAnyway
  - maxSkew: 5
    topologyKey: "topology.kubernetes.io/zone"
    whenUnsatisfiable: ScheduleAnyway

Також, типово відключений застарілий втулок SelectorSpread, який забезпечує еквівалентну поведінку.

Якщо ви не хочете використовувати типові обмеження поширення топології Podʼа для вашого кластера, ви можете відключити ці типові значення, встановивши defaultingType у List і залишивши порожніми defaultConstraints у конфігурації втулка PodTopologySpread:

apiVersion: kubescheduler.config.k8s.io/v1beta3
kind: KubeSchedulerConfiguration

profiles:
  - schedulerName: default-scheduler
    pluginConfig:
      - name: PodTopologySpread
        args:
          defaultConstraints: []
          defaultingType: List

Порівняння з podAffinity та podAntiAffinity

У Kubernetes, між-Podʼова (анти)спорідненість контролює те, як Podʼи розміщуються відносно один одного — чи ущільнені, чи розріджені.

podAffinity
притягує Podʼи; ви можете намагатися упакувати будь-яку кількість Podʼів в кваліфікуючі топологічні домени.
podAntiAffinity
відштовхує Podʼи. Якщо ви встановите це у режим requiredDuringSchedulingIgnoredDuringExecution, тоді тільки один Pod може бути запланований в один топологічний домен; якщо ви виберете preferredDuringSchedulingIgnoredDuringExecution, то ви втратите можливість змусити виконання обмеження.

Для більш точного контролю ви можете вказати обмеження поширення топології для розподілу podʼів по різним топологічним доменам — для досягнення як високої доступності, так і економії коштів. Це також може допомогти в роботі з оновленнями без відмов та плавному масштабуванні реплік.

Для отримання більш детальної інформації, див. розділ Motivation пропозиції щодо покращення про обмеження поширення топології Podʼів.

Відомі обмеження

  • Немає гарантії, що обмеження залишаться задоволеними при видаленні Podʼів. Наприклад, зменшення масштабування Deployment може призвести до нерівномірного розподілу Podʼів.

    Ви можете використовувати інструменти, такі як Descheduler, для перебалансування розподілу Podʼів.

  • Podʼи, що відповідають заплямованим вузлам, враховуються. Див. Issue 80921.

  • Планувальник не має попереднього знання всіх зон або інших топологічних доменів, які має кластер. Вони визначаються на основі наявних вузлів у кластері. Це може призвести до проблем у автоматизованих кластерах, коли вузол (або група вузлів) масштабується до нуля вузлів, і ви очікуєте масштабування кластера, оскільки в цьому випадку ці топологічні домени не будуть враховуватися, поки в них є хоча б один вузол.

    Ви можете обійти це, використовуючи інструменти автоматичного масштабування кластера, які враховують обмеження розподілу топології Podʼів та також знають загальний набір топологічних доменів.

Що далі

  • У статті блогу Introducing PodTopologySpread докладно пояснюється maxSkew, а також розглядаються деякі приклади використання.
  • Прочитайте розділ scheduling з довідки API для Pod.

3.10.6 - Заплямованість та Толерантність

Спорідненість вузла (node affinity) це властивість Podʼа, яка привертає Pod до набору вузлів (або як перевага, або як жорстка вимога). Заплямованість (taint) є протилежною властивістю — вона дозволяє вузлу відштовхувати набір Podʼів.

Толерантність застосовуються до Podʼів. Толерантність дозволяє планувальнику розміщувати Podʼи, що збігаються з відповідними позначками заплямованості. Толерантність дозволяє планування, але не гарантує його: планувальник також оцінює інші параметри в межах свого функціонала.

Заплямованість та толерантність працюють разом, щоб забезпечити те, щоб Podʼи не розміщувались на непридатних вузлах. Одна або декілька позначок заплямованості застосовуються до вузла; це дозволяє позначити, що вузол не повинен приймати жодних Podʼів, які не толерують цих позначок заплямованості.

Концепції

Ви додаєте позначку taint до вузла за допомогою kubectl taint. Наприклад,

kubectl taint nodes node1 key1=value1:NoSchedule

додає taint до вузла node1. Taint має ключ key1, значення value1 і ефект taint NoSchedule. Це означає, що жодний Pod не зможе розміститись на node1, якщо він не має відповідної толерантності.

Щоб видалити taint, доданий командою вище, можна виконати:

kubectl taint nodes node1 key1=value1:NoSchedule-

Ви вказуєте толерантність для Podʼа в PodSpec. Обидві наступні толерантності "відповідають" taint, створеному за допомогою команди kubectl taint вище, і, отже, Pod з будь-якою з толерантностей зможе розміститись на node1:

tolerations:
- key: "key1"
  operator: "Equal"
  value: "value1"
  effect: "NoSchedule"
tolerations:
- key: "key1"
  operator: "Exists"
  effect: "NoSchedule"

Основний планувальник Kubernetes бере до уваги taint та толерантності при виборі вузла для запуску певного Podʼа. Проте, якщо ви вручну вказуєте .spec.nodeName для Podʼа, ця дія оминає планувальник; Pod тоді привʼязується до вузла, на який ви його призначили, навіть якщо на цьому вузлі є taint типу NoSchedule, які ви обрали. Якщо це трапиться і на вузлі також встановлено taint типу NoExecute, kubelet видалятиме Pod, якщо не буде встановлено відповідну толерантність.

Ось приклад Podʼа, у якого визначено деякі толерантності:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  tolerations:
  - key: "example-key"
    operator: "Exists"
    effect: "NoSchedule"

Типово значення для operator є Equal.

Толерантність має "збіг" з taint, якщо ключі є однаковими та ефекти є однаковими також, і:

  • оператор — Exists (у цьому випадку не слід вказувати value), або
  • оператор — Equal, а значення повинні бути рівні.

У вищенаведеному прикладі використовувався effect NoSchedule. Також можна використовувати effect PreferNoSchedule.

Дозволені значення для поля effect:

NoExecute
Це впливає на Podʼи, які вже запущені на вузлі наступним чином:
  • Podʼи, які не толерують taint, негайно виселяються
  • Podʼи, які толерують taint, не вказуючи tolerationSeconds в їхній специфікації толерантності, залишаються привʼязаними назавжди
  • Podʼи, які толерують taint з вказаним tolerationSeconds залишаються привʼязаними протягом зазначеного часу. Після закінчення цього часу контролер життєвого циклу вузла виводить Podʼи з вузла.
NoSchedule
На позначеному taint вузлі не буде розміщено нові Podʼи, якщо вони не мають відповідної толерантності. Podʼи, які вже працюють на вузлі, не виселяються.
PreferNoSchedule
PreferNoSchedule — це "preference" або "soft" варіант NoSchedule. Планувальник спробує уникнути розміщення Podʼа, який не толерує taint на вузлі, але це не гарантовано.

На один вузол можна накласти декілька taint і декілька толерантностей на один Pod. Спосіб, яким Kubernetes обробляє декілька taint і толерантностей, схожий на фільтр: починаючи з усіх taint вузла, потім ігнорує ті, для яких Pod має відповідну толерантність; залишаються невідфільтровані taint, які мають зазначені ефекти на Pod. Зокрема,

  • якщо є принаймні один невідфільтрований taint з ефектом NoSchedule, тоді Kubernetes не буде планувати Pod на цей вузол
  • якщо немає невідфільтрованих taint з ефектом NoSchedule, але є принаймні один невідфільтрований taint з ефектом PreferNoSchedule, тоді Kubernetes спробує не планувати Pod на цей вузол
  • якщо є принаймні один невідфільтрований taint з ефектом NoExecute, тоді Pod буде виселено з вузла (якщо він вже працює на вузлі), і він не буде плануватися на вузол (якщо він ще не працює на вузлі).

Наприклад, уявіть, що ви накладаєте taint на вузол таким чином

kubectl taint nodes node1 key1=value1:NoSchedule
kubectl taint nodes node1 key1=value1:NoExecute
kubectl taint nodes node1 key2=value2:NoSchedule

І Pod має дві толерантності:

tolerations:
- key: "key1"
  operator: "Equal"
  value: "value1"
  effect: "NoSchedule"
- key: "key1"
  operator: "Equal"
  value: "value1"
  effect: "NoExecute"

У цьому випадку Pod не зможе плануватися на вузол, оскільки відсутня толерантність, яка відповідає третьому taint. Але він зможе продовжувати працювати, якщо він вже працює на вузлі, коли до нього додається taint, оскільки третій taint — єдиний з трьох, який не толерується Podʼом.

Зазвичай, якщо до вузла додається taint з ефектом NoExecute, то будь-які Podʼи, які не толерують taint, будуть негайно виселені, а Podʼи, які толерують taint, ніколи не будуть виселені. Однак толерантність з ефектом NoExecute може вказати необовʼязкове поле tolerationSeconds, яке визначає, як довго Pod буде привʼязаний до вузла після додавання taint. Наприклад,

tolerations:
- key: "key1"
  operator: "Equal"
  value: "value1"
  effect: "NoExecute"
  tolerationSeconds: 3600

означає, що якщо цей Pod працює і до вузла додається відповідний taint, то Pod залишиться привʼязаним до вузла протягом 3600 секунд, а потім буде виселений. Якщо taint видаляється до цього часу, то Pod не буде виселений.

Приклади використання

Заплямованість та Толерантність є гнучким способом відвадити Podʼи від вузлів або виселення Podʼів, які не повинні працювати. Деякі з варіантів використання:

  • Призначені вузли: Якщо ви хочете призначити певний набір вузлів для виключного використання конкретним набором користувачів, ви можете додати taint на ці вузли (наприклад, kubectl taint nodes nodename dedicated=groupName:NoSchedule) і потім додати відповідну толерантність до їхніх Podʼів (це найкраще робити за допомогою власного контролера допуску). Podʼам з толерантностями буде дозволено використовувати позначені (призначені) вузли, а також будь-які інші вузли в кластері. Якщо ви хочете призначити вузли виключно для них та забезпечити, що вони використовують лише призначені вузли, то ви також повинні додатково додати мітку, аналогічну taint, до того ж набору вузлів (наприклад, dedicated=groupName), і контролер допуску повинен додатково додати спорідненість вузла, щоб вимагати, щоб Podʼи могли плануватися лише на вузли з міткою dedicated=groupName.

  • Вузли зі спеціальним обладнанням: У кластері, де невелика підмножина вузлів має спеціалізоване обладнання (наприклад, GPU), бажано утримувати Podʼи, які не потребують спеціалізованого обладнання, поза цими вузлами, щоб залишити місце для Podʼів, які дійсно потребують спеціалізованого обладнання. Це можна зробити, накладаючи taint на вузли зі спеціалізованим обладнанням (наприклад, kubectl taint nodes nodename special=true:NoSchedule або kubectl taint nodes nodename special=true:PreferNoSchedule) і додавання відповідної толерантності до Podʼів, які використовують спеціалізоване обладнання. Як і у випадку з призначеними вузлами, найпростіше застосовувати толерантності за допомогою власного контролера допуску. Наприклад, рекомендується використовувати Розширені ресурси для представлення спеціального обладнання, позначайте вузли зі спеціальним обладнанням розширеним імʼям ресурсу і запускайте контролер допуску ExtendedResourceToleration. Тепер, оскільки вузли позначені, жоден Pod без толерантності не буде плануватися на них. Але коли ви надсилаєте Pod, який запитує розширений ресурс, контролер допуску ExtendedResourceToleration автоматично додасть правильну толерантність до Podʼа і цей Pod буде плануватися на вузли зі спеціальним обладнанням. Це забезпечить, що ці вузли зі спеціальним обладнанням призначені для Podʼів, які запитують таке обладнання, і вам не потрібно вручну додавати толерантності до ваших Podʼів.

  • Виселення на основі taint: Поведінка виселення, що налаштовується для кожного Podʼа, коли є проблеми з вузлом, яка описана в наступному розділі.

Виселення на основі taint

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.18 [stable]

Контролер вузла автоматично накладає taint на вузол, коли виконуються певні умови. Наступні taint є вбудованими:

  • node.kubernetes.io/not-ready: Вузол не готовий. Це відповідає тому, що стан NodeCondition "Ready" є "False".
  • node.kubernetes.io/unreachable: Вузол недоступний з контролера вузла. Це відповідає тому, що стан NodeCondition "Ready" є "Unknown".
  • node.kubernetes.io/memory-pressure: Вузол має проблеми з памʼяттю.
  • node.kubernetes.io/disk-pressure: Вузол має проблеми з диском.
  • node.kubernetes.io/pid-pressure: Вузол має проблеми з PID.
  • node.kubernetes.io/network-unavailable: Мережа вузла недоступна.
  • node.kubernetes.io/unschedulable: Вузол не піддається плануванню.
  • node.cloudprovider.kubernetes.io/uninitialized: Коли kubelet запускається з "зовнішнім" хмарним провайдером, цей taint накладається на вузол для позначення його як невикористовуваного. Після того як контролер з cloud-controller-manager ініціалізує цей вузол, kubelet видаляє цей taint.

У разі, якщо потрібно спорожнити вузол, контролер вузла або kubelet додає відповідні taint з ефектом NoExecute. Цей ефект типово додається для taint node.kubernetes.io/not-ready та node.kubernetes.io/unreachable. Якщо умова несправності повертається до нормального стану, kubelet або контролер вузла можуть видалити відповідні taint.

У деяких випадках, коли вузол недоступний, сервер API не може спілкуватися з kubelet на вузлі. Рішення про видалення Podʼів не може бути передане до kubelet до тих пір, поки звʼязок з сервером API не буде відновлено. Протягом цього часу Podʼи, які заплановані для видалення, можуть продовжувати працювати на розділеному вузлі.

Ви можете вказати tolerationSeconds для Podʼа, щоб визначити, як довго цей Pod залишається привʼязаним до несправного або вузла, ще не відповідає.

Наприклад, ви можете довго зберігати застосунок з великою кількістю локального стану, привʼязаного до вузла, у разі розділу мережі, сподіваючись, що розділ відновиться, і, таким чином, можна уникнути виселення Podʼа. Толерантність, яку ви встановили для цього Pod, може виглядати так:

tolerations:
- key: "node.kubernetes.io/unreachable"
  operator: "Exists"
  effect: "NoExecute"
  tolerationSeconds: 6000

Podʼи DaemonSet створюються з толерантностями NoExecute для наступних taint без tolerationSeconds:

  • node.kubernetes.io/unreachable
  • node.kubernetes.io/not-ready

Це забезпечує, що Podʼи DaemonSet ніколи не будуть видалені через ці проблеми.

Позначення вузлів taint за умовами

Панель управління, використовуючи контролер вузла, автоматично створює taint з ефектом NoSchedule для умов вузла.

Планувальник перевіряє taint, а не умови вузла, коли він приймає рішення про планування. Це забезпечує те, що умови вузла не впливають безпосередньо на планування. Наприклад, якщо умова вузла DiskPressure активна, панель управління додає taint node.kubernetes.io/disk-pressure і не планує нові Podʼи на уражений вузол. Якщо умова вузла MemoryPressure активна, панель управління додає taint node.kubernetes.io/memory-pressure.

Ви можете ігнорувати умови вузла для новостворених Podʼів, додавши відповідні толерантності Podʼів. Панель управління також додає толерантність node.kubernetes.io/memory-pressure на Podʼи, які мають клас QoS інший, ніж BestEffort. Це тому, що Kubernetes вважає Podʼи у класах QoS Guaranteed або Burstable (навіть Podʼи без встановленого запиту на памʼять) здатними впоратися з тиском на памʼять, тоді як нові Podʼи BestEffort не плануються на уражений вузол.

Контролер DaemonSet автоматично додає наступні толерантності NoSchedule для всіх демонів, щоб запобігти порушенню роботи DaemonSet.

  • node.kubernetes.io/memory-pressure
  • node.kubernetes.io/disk-pressure
  • node.kubernetes.io/pid-pressure (1.14 або пізніше)
  • node.kubernetes.io/unschedulable (1.10 або пізніше)
  • node.kubernetes.io/network-unavailable (тільки для мережі хосту)

Додавання цих толерантностей забезпечує сумісність з попередніми версіями. Ви також можете додавати довільні толерантності до DaemonSets.

Що далі

3.10.7 - Фреймворк планування

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.19 [stable]

Фреймворк планування — це розширювана архітектура для планувальника Kubernetes. Вона складається з набору "втулків" API, які компілюються безпосередньо в планувальник. Ці API дозволяють реалізувати більшість функцій планування у вигляді втулків, зберігаючи при цьому основне ядро планування легким та зручним у використанні. Для отримання більш технічної інформації про дизайн цієї архітектури зверніться до пропозиції проєкту дизайну системи планування.

Робота фреймворку

Фреймворк планування визначає кілька точок розширення. Втулки планувальника реєструються для виклику в одній або кількох таких точках розширення. Деякі з цих втулків можуть змінювати рішення щодо планування, а деякі надають тільки інформаційний вміст.

Кожна спроба запланувати один Pod розділяється на два етапи: цикл планування та цикл привʼязки.

Цикл планування та цикл привʼязки

Цикл планування вибирає вузол для Podʼа, а цикл привʼязки застосовує це рішення до кластера. Разом цикл планування та цикл привʼязки називаються "контекстом планування".

Цикли планування виконуються послідовно, тоді як цикли привʼязки можуть виконуватися паралельно.

Цикл планування або привʼязки може бути перерваний, якщо виявлено, що Pod не може бути запланованим або якщо відбувається внутрішня помилка. Pod буде повернуто у чергу і спроба буде повторена.

Інтерфейси

Наступне зображення показує контекст планування Podʼа та інтерфейси, які надає фреймворк планування.

Один втулок може реалізовувати кілька інтерфейсів для виконання складніших завдань або завдань зі збереженням стану.

Деякі інтерфейси відповідають точкам розширення планувальника, які можна налаштувати через Конфігурацію Планувальника.

Точки розширення фреймворку планування

PreEnqueue

Ці втулки викликаються перед додаванням Podʼів до внутрішньої активної черги, де Podʼи відзначаються як готові до планування.

Тільки коли всі втулки PreEnqueue повертають Success, Pod допускається до внутрішньої активної черги. В іншому випадку він поміщається у відсортований список незапланованих Podʼів і не отримує умову Unschedulable.

Для отримання докладнішої інформації про те, як працюють внутрішні черги планувальника, прочитайте Черга планування в kube-scheduler.

EnqueueExtension

EnqueueExtension — це інтерфейс, де втулок може контролювати, чи потрібно повторно спробувати планування Podʼів, відхилені цим втулком, на основі змін у кластері. Втулки, які реалізують PreEnqueue, PreFilter, Filter, Reserve або Permit, повинні реалізувати цей інтерфейс.

QueueingHint

QueueingHint — це функція зворотного виклику для вирішення того, чи можна повторно включити Pod до активної черги або черги відстрочки. Вона виконується кожного разу, коли в кластері відбувається певний вид події або зміна. Коли QueueingHint виявляє, що подія може зробити Pod запланованим, Pod поміщається в активну чергу або чергу відстрочки, щоб планувальник повторно спробував спланувати Pod.

QueueSort

Ці втулки використовуються для сортування Podʼів у черзі планування. Втулок сортування черги надає функцію Less(Pod1, Pod2). Одночасно може бути включений лише один втулок сортування черги.

PreFilter

Ці втулки використовуються для попередньої обробки інформації про Pod, або для перевірки певних умов, яким мають відповідати кластер або Pod. Якщо втулок PreFilter повертає помилку, цикл планування переривається.

Filter

Ці втулки використовуються для відфільтрування вузлів, на яких не можна запустити Pod. Для кожного вузла планувальник буде викликати втулки фільтрації в налаштованому порядку. Якщо будь-який втулок фільтра позначає вузол як неспроможний, для цього вузла не буде викликано інші втулки. Оцінка вузлів може відбуватися паралельно.

PostFilter

Ці втулки викликаються після фази фільтрації, але лише тоді, коли не було знайдено жодного можливого вузла для Podʼа. Втулки викликаються в налаштованому порядку. Якщо будь-який втулок postFilter позначає вузол як Schedulable, інші втулки не будуть викликані. Типовою реалізацією PostFilter є preemption, яка намагається зробити Pod запланованим, випереджаючи інші Pods.

PreScore

Ці втулки використовуються для виконання "попередньої оцінки", яка генерує загальний стан для використання втулками Score. Якщо втулок попередньої оцінки повертає помилку, цикл планування переривається.

Score

Ці втулки використовуються для ранжування вузлів, які пройшли фазу фільтрації. Планувальник викликає кожен втулок оцінювання для кожного вузла. Існує чіткий діапазон цілих чисел, який представляє мінімальні та максимальні оцінки. Після фази NormalizeScore, планувальник поєднує оцінки вузла з усіх втулків згідно з налаштованими коефіцієнтами втулків.

NormalizeScore

Ці втулки використовуються для модифікації оцінок перед тим, як планувальник обчислить кінцеве ранжування Вузлів. Втулок, який реєструється для цієї точки розширення, буде викликаний з результатами Score від того ж втулка. Це робиться один раз для кожного втулка на один цикл планування.

Наприклад, припустимо, що втулок BlinkingLightScorer ранжує вузли на основі того, скільки лампочок, що блимають, в них є.

func ScoreNode(_ *v1.pod, n *v1.Node) (int, error) {
    return getBlinkingLightCount(n)
}

Однак максимальна кількість лампочок, що блимають, може бути невеликою порівняно з NodeScoreMax. Щоб виправити це, BlinkingLightScorer також повинен реєструватися для цієї точки розширення.

func NormalizeScores(scores map[string]int) {
    highest := 0
    for _, score := range scores {
        highest = max(highest, score)
    }
    for node, score := range scores {
        scores[node] = score*NodeScoreMax/highest
    }
}

Якщо будь-який втулок NormalizeScore повертає помилку, цикл планування припиняється.

Reserve

Втулок, який реалізує інтерфейс Reserve, має два методи, а саме Reserve та Unreserve, які підтримують дві інформаційні фази планування, які називаються Reserve та Unreserve, відповідно. Втулки, які підтримують стан виконання (так звані "статичні втулки"), повинні використовувати ці фази для повідомлення планувальнику про те, що ресурси на вузлі резервуються та скасовуються для вказаного Podʼа.

Фаза резервування (Reserve) відбувається перед тим, як планувальник фактично привʼязує Pod до призначеного вузла. Це робиться для запобігання виникненню умов перегонів (race condition) під час очікування на успішне привʼязування. Метод Reserve кожного втулка Reserve може бути успішним або невдалим; якщо один виклик методу Reserve не вдасться, наступні втулки не виконуються, і фаза резервування вважається невдалою. Якщо метод Reserve всіх втулків успішний, фаза резервування вважається успішною, виконується решта циклу планування та циклу привʼязки.

Фаза скасування резервування (Unreserve) спрацьовує, якщо фаза резервування або пізніша фаза виявиться невдалою. У такому випадку метод Unreserve всіх втулків резервування буде виконано у порядку зворотному виклику методів Reserve. Ця фаза існує для очищення стану, повʼязаного з зарезервованим Podʼом.

Permit

Втулки Permit викликаються в кінці циклу планування для кожного Podʼа, щоб запобігти або затримати привʼязку до вузла-кандидата. Втулок дозволу може робити одну з трьох речей:

  1. approve
    Якщо всі втулки Permit схвалюють Pod, він відправляється для привʼязки.

  2. deny
    Якщо будь-який втулок Permit відхиляє Pod, він повертається до черги планування. Це спричинить запуск фази Unreserve у втулках Reserve.

  3. wait (із таймаутом)
    Якщо втулок Permit повертає "wait", тоді Pod залишається у внутрішньому списком "очікуючих" Podʼів, і цикл привʼязки цього Podʼа починається, але безпосередньо блокується, поки він не буде схвалений. Якщо виникає таймаут, wait стає deny і Pod повертається до черги планування, спричиняючи запуск фази Unreserve у втулках Reserve.

PreBind

Ці втулки використовуються для виконання будь-яких необхідних операцій перед привʼязкою Podʼа. Наприклад, втулок PreBind може надавати мережевий том і монтувати його на цільовому вузлі перед тим, як дозволити Podʼа запускатися там.

Якщо будь-який втулок PreBind повертає помилку, Pod відхиляється і повертається до черги планування.

Bind

Ці втулки використовуються для привʼязки Podʼа до Вузла. Втулки Bind не будуть викликані, поки всі втулки PreBind не завершаться. Кожен втулок привʼязки викликається в налаштованому порядку. Втулок привʼязки може вибрати, чи обробляти вказаний Pod. Якщо втулок привʼязки обирає Pod для опрацювання, решта втулків привʼязки пропускаються.

PostBind

Це інформаційний інтерфейс. Втулки PostBind викликаються після успішної привʼязки Podʼа. Це завершення циклу привʼязки та може бути використано для очищення повʼязаних ресурсів.

API втулку

Існують два кроки в API втулку. По-перше, втулки повинні зареєструватися та отримати налаштування, а потім вони використовують інтерфейси точок розширення. Інтерфейси точок розширення мають наступну форму.

type Plugin interface {
    Name() string
}

type QueueSortPlugin interface {
    Plugin
    Less(*v1.pod, *v1.pod) bool
}

type PreFilterPlugin interface {
    Plugin
    PreFilter(context.Context, *framework.CycleState, *v1.pod) error
}

// ...

Налаштування втулків

Ви можете увімкнути або вимкнути втулки у конфігурації планувальника. Якщо ви використовуєте Kubernetes v1.18 або пізнішу версію, більшість втулків планування використовуються та є стандартно увімкненими.

Окрім стандартних втулків, ви також можете реалізувати власні втулки планування та налаштувати їх разом з стандартними втулками. Ви можете дізнатися більше на scheduler-plugins.

Якщо ви використовуєте Kubernetes v1.18 або пізнішу версію, ви можете налаштувати набір втулків як профіль планувальника, а потім визначити кілька профілів для різних видів робочих навантажень. Дізнайтеся більше за про декілька профілів.

3.10.8 - Динамічне виділення ресурсів

Основний динамічний розподіл ресурсів зі структурованими параметрами:

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.30 [alpha]

Динамічне виділення ресурсів в контролері панелі управління:

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.26 [alpha]

Динамічне виділення ресурсів — це API для запиту та спільного використання ресурсів між Podʼами та контейнерами всередині Podʼа. Це узагальнення API для постійних томів для загальних ресурсів. Зазвичай ці ресурси є пристроями, такими як GPU.

Драйвери сторонніх ресурсів відповідають за відстеження та підготовку ресурсів, а виділення ресурсів здійснюється Kubernetes за допомогою структурованих параметрів (введених у Kubernetes 1.30). Різні види ресурсів підтримують довільні параметри для визначення вимог та ініціалізації.

Коли драйвер надає контролер панелі управління, драйвер самостійно керує виділенням ресурсів у співпраці з планувальником Kubernetes.

Перш ніж ви розпочнете

Kubernetes v1.31 включає підтримку API на рівні кластера для динамічного виділення ресурсів, але це потрібно включити явно. Ви також повинні встановити драйвер ресурсів для конкретних ресурсів, які мають бути керовані за допомогою цього API. Якщо ви не використовуєте Kubernetes v1.31, перевірте документацію для цієї версії Kubernetes.

API

Група API resource.k8s.io/v1alpha3 надає наступні типи:

ResourceClaim
Визначає запит на доступ до ресурсів у кластері для використання робочими навантаженнями. Наприклад, якщо робоче навантаження потребує пристрою прискорювача з певними властивостями, саме так виражається цей запит. Розділ статусу відстежує, чи було виконано цей запит і які конкретні ресурси було виділено.
ResourceClaimTemplate
Визначає специфікацію та деякі метадані для створення ResourceClaims. Створюється користувачем під час розгортання робочого навантаження. Kubernetes автоматично створює та видаляє ResourceClaims для кожного Podʼа.
DeviceClass
Містить заздалегідь визначені критерії вибору для певних пристроїв та їх конфігурацію. DeviceClass створюється адміністратором кластера під час встановлення драйвера ресурсів. Кожен запит на виділення пристрою в ResourceClaim повинен посилатися на один конкретний DeviceClass.
PodSchedulingContext
Використовується внутрішньо панеллю управління та драйверами ресурсів для координації планування Podʼів, коли ResourceClaims потрібно виділити для Podʼа, і ці ResourceClaims використовують контролер панелі управління.
ResourceSlice
Використовується зі структурованими параметрами для публікації інформації про ресурси, які доступні у кластері.

Розробник драйвера ресурсів вирішує, чи хоче він самостійно керувати виділенням ресурсів за допомогою контролера панелі управління або ж покластися на виділення через Kubernetes за допомогою структурованих параметрів. Власний контролер забезпечує більшу гнучкість, але автоматичне масштабування кластера не буде надійно працювати для ресурсів, прив’язаних до вузла. Структуровані параметри дозволяють автоматичне масштабування кластера, але можуть не задовольнити всі випадки використання.

Коли драйвер використовує структуровані параметри, всі параметри, що вибирають пристрої, визначаються в ResourceClaim і DeviceClass за допомогою вбудованих типів. Параметри конфігурації можуть бути вбудовані туди як довільні обʼєкти JSON.

PodSpec core/v1 визначає ResourceClaims, які потрібні для Podʼа в полі resourceClaims. Записи в цьому списку посилаються або на ResourceClaim, або на ResourceClaimTemplate. При посиланні на ResourceClaim всі Podʼи, які використовують цей PodSpec (наприклад, всередині Deployment або StatefulSet), спільно використовують один екземпляр ResourceClaim. При посиланні на ResourceClaimTemplate, кожен Pod отримує свій власний екземпляр.

Список resources.claims для ресурсів контейнера визначає, чи отримує контейнер доступ до цих екземплярів ресурсів, що дозволяє спільне використання ресурсів між одним або кількома контейнерами.

Нижче наведено приклад для умовного драйвера ресурсів. Для цього Podʼа буде створено два обʼєкти ResourceClaim, і кожен контейнер отримає доступ до одного з них.

apiVersion: resource.k8s.io/v1alpha3
kind: DeviceClass
name: resource.example.com
spec:
  selectors:
  - cel:
      expression: device.driver == "resource-driver.example.com"
---
apiVersion: resource.k8s.io/v1alpha2
kind: ResourceClaimTemplate
metadata:
  name: large-black-cat-claim-template
spec:
  spec:
    devices:
      requests:
      - name: req-0
        deviceClassName: resource.example.com
        selectors:
        - cel:
           expression: |-
              device.attributes["resource-driver.example.com"].color == "black" &&
              device.attributes["resource-driver.example.com"].size == "large"              
–--
apiVersion: v1
kind: Pod
metadata:
  name: pod-with-cats
spec:
  containers:
  - name: container0
    image: ubuntu:20.04
    command: ["sleep", "9999"]
    resources:
      claims:
      - name: cat-0
  - name: container1
    image: ubuntu:20.04
    command: ["sleep", "9999"]
    resources:
      claims:
      - name: cat-1
  resourceClaims:
  - name: cat-0
    resourceClaimTemplateName: large-black-cat-claim-template
  - name: cat-1
    resourceClaimTemplateName: large-black-cat-claim-template

Планування

З контролером панелі управління

На відміну від вбудованих ресурсів (CPU, RAM) та розширених ресурсів (керованих пристроєм драйвера, оголошуваних kubelet), без структурованих параметрів планувальник не має знань про те, які динамічні ресурси доступні в кластері та як вони можуть бути розподілені для задоволення вимог певного ResourceClaim. За це відповідальні драйвери ресурсів. Вони відмічають ResourceClaims як "allocated", як тільки для них зарезервовано ресурси. Це також показує планувальнику, де в кластері доступний ResourceClaim.

Коли Pod планується до виконання, планувальник перевіряє всі ResourceClaims, необхідні для Pod, і створює обʼєкт PodScheduling, де інформує драйвери ресурсів, відповідальні за ці ResourceClaims, про вузли, які планувальник вважає підходящими для Pod. Драйвери ресурсів відповідають, виключаючи вузли, які не мають достатньо ресурсів драйвера. Як тільки планувальник має цю інформацію, він вибирає один вузол та зберігає цей вибір в обʼєкті PodScheduling. Потім драйвери ресурсів виділяють свої ResourceClaims так, щоб ресурси були доступні на цьому вузлі. Після завершення цього процесу Pod стає запланованим.

У рамках цього процесу також для Podʼа резервуються ResourceClaims. Наразі ResourceClaims можуть використовуватися або ексклюзивно одним Podʼом, або необмеженою кількістю Podʼів.

Одна з ключових особливостей полягає в тому, що Podʼи не заплановані на вузол, поки всі їх ресурси не будуть виділені та зарезервовані. Це дозволяє уникати сценарію, коли Pod запланований на один вузол, а потім не може працювати там, що погано, оскільки такий очікуючий Pod також блокує всі інші ресурси, такі як RAM або CPU, які були відведені для нього.

Зі структурованими параметрами

Коли драйвер використовує структуровані параметри, планувальник бере на себе відповідальність за виділення ресурсів для ResourceClaim, кожного разу, коли Pod потребує їх. Він робить це, отримуючи повний список доступних ресурсів з обʼєктів ResourceSlice, відстежуючи, які з цих ресурсів вже були виділені наявним ResourceClaim, а потім вибираючи з тих ресурсів, що залишилися.

Єдиний тип підтримуваних ресурсів зараз — це пристрої. Пристрій має імʼя та кілька атрибутів та можливостей. Вибір пристроїв здійснюється за допомогою виразів CEL, які перевіряють ці атрибути та можливості. Крім того, набір вибраних пристроїв також може бути обмежений наборами, які відповідають певним обмеженням.

Обраний ресурс фіксується у статусі ResourceClaim разом з будь-якими вендор-специфічними налаштуваннями, тому коли Pod збирається запуститися на вузлі, драйвер ресурсу на вузлі має всю необхідну інформацію для підготовки ресурсу.

За допомогою структурованих параметрів планувальник може приймати рішення без спілкування з будь-якими драйверами ресурсів DRA. Він також може швидко планувати кілька Podʼів, зберігаючи інформацію про виділення ресурсів для ResourceClaim у памʼяті та записуючи цю інформацію в обʼєкти ResourceClaim у фоні, одночасно з привʼязкою Podʼа до вузла.

Моніторинг ресурсів

Kubelet надає службу gRPC для забезпечення виявлення динамічних ресурсів запущених Podʼів. Для отримання додаткової інформації про точки доступу gRPC дивіться звіт про виділення ресурсів.

Попередньо заплановані Podʼи

Коли ви, або інший клієнт API, створюєте Pod із вже встановленим spec.nodeName, планувальник пропускається. Якщо будь-який ResourceClaim, потрібний для цього Podʼа, ще не існує, не виділений або не зарезервований для Podʼа, то kubelet не зможе запустити Pod і періодично перевірятиме це, оскільки ці вимоги можуть бути задоволені пізніше.

Така ситуація також може виникнути, коли підтримка динамічного виділення ресурсів не була увімкнена в планувальнику на момент планування Podʼа (різниця версій, конфігурація, feature gate і т. д.). kube-controller-manager виявляє це і намагається зробити Pod працюючим, провокуючи виділення та/або резервування потрібних ResourceClaims.

Краще уникати цього оминаючи планувальник, оскільки Pod, який призначений для вузла, блокує нормальні ресурси (ОЗП, ЦП), які потім не можуть бути використані для інших Podʼів, поки Pod є застряглим. Щоб запустити Pod на певному вузлі, при цьому проходячи через звичайний потік планування, створіть Pod із селектором вузла, який точно відповідає бажаному вузлу:

apiVersion: v1
kind: Pod
metadata:
  name: pod-with-cats
spec:
  nodeSelector:
    kubernetes.io/hostname: назва-призначеного-вузла
  ...

Можливо, ви також зможете змінити вхідний Pod під час допуску, щоб скасувати поле .spec.nodeName і використовувати селектор вузла замість цього.

Увімкнення динамічного виділення ресурсів

Динамічне виділення ресурсів є альфа-функцією та увімкнуто лише тоді, коли увімкнуто функціональну можливість DynamicResourceAllocation та групу API resource.k8s.io/v1alpha3. Для отримання деталей щодо цього дивіться параметри kube-apiserver --feature-gates та --runtime-config. Також варто увімкнути цю функцію в kube-scheduler, kube-controller-manager та kubelet.

Коли драйвер ресурсів використовує контролер панелі управління, крім DynamicResourceAllocation, також потрібно увімкнути функціональну можливість DRAControlPlaneController.

Швидка перевірка того, чи підтримує кластер Kubernetes цю функцію, полягає у виведенні обʼєктів DeviceClass за допомогою наступної команди:

kubectl get deviceclasses

Якщо ваш кластер підтримує динамічне виділення ресурсів, відповідь буде або список обʼєктів DeviceClass, або:

No resources found

Якщо це не підтримується, буде виведено помилку:

error: the server doesn't have a resource type "deviceclasses"

Контролер панелі управління підтримується, коли є можливість створити обʼєкт ResourceClaim, де поле spec.controller встановлене. Якщо DRAControlPlaneController вимкнено, це поле автоматично очищується під час збереження ResourceClaim.

Типова конфігурація kube-scheduler вмикає втулок "DynamicResources" лише в разі увімкнення feature gate та при використанні конфігурації API v1. Налаштування конфігурації може змінюватися, щоб включити його.

Крім увімкнення функції в кластері, також потрібно встановити драйвер ресурсів. Для отримання додаткової інформації звертайтеся до документації драйвера.

Що далі

3.10.9 - Налаштування продуктивності планувальника

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.14 [beta]

kube-scheduler — стандартний планувальник для Kubernetes. Він відповідає за розміщення Podʼів на вузлах кластера.

Вузли кластера, які відповідають вимогам планування Podʼа, називаються відповідними вузлами для Podʼа. Планувальник знаходить відповідні вузли для Podʼа, а потім виконує набір функцій для оцінки цих вузлів, вибираючи вузол з найвищим балом серед відповідних для запуску Podʼа. Планувальник потім повідомляє API-серверу про це рішення в процесі, що називається звʼязування.

На цій сторінці пояснюються оптимізації налаштування продуктивності, які є актуальними для великих кластерів Kubernetes.

У великих кластерах ви можете налаштувати роботу планувальника, збалансовуючи результати планування між часом відгуку (нові Podʼи розміщуються швидко) та точністю (планувальник рідко приймає погані рішення про розміщення).

Ви можете налаштувати це налаштування через параметр kube-scheduler percentageOfNodesToScore. Це налаштування KubeSchedulerConfiguration визначає поріг для планування вузлів у вашому кластері.

Налаштування порога

Опція percentageOfNodesToScore приймає цілі числові значення від 0 до 100. Значення 0 є спеціальним числом, яке позначає, що kube-scheduler повинен використовувати типовав вбудоване значення. Якщо ви встановлюєте percentageOfNodesToScore більше 100, kube-scheduler діє так, ніби ви встановили значення 100.

Щоб змінити значення, відредагуйте файл конфігурації kube-scheduler і перезапустіть планувальник. У багатьох випадках файл конфігурації можна знайти за шляхом /etc/kubernetes/config/kube-scheduler.yaml.

Після внесення цих змін ви можете виконати

kubectl get pods -n kube-system | grep kube-scheduler

щоб перевірити, що компонент kube-scheduler працює належним чином.

Поріг оцінки вузлів

Для поліпшення продуктивності планування kube-scheduler може припинити пошук відповідних вузлів, як тільки він знайде їх достатню кількість. У великих кластерах це заощаджує час порівняно з підходом, який би враховував кожен вузол.

Ви вказуєте поріг для того, яка кількість вузлів є достатньою, у відсотках від усіх вузлів у вашому кластері. Kube-scheduler перетворює це в ціле число вузлів. Під час планування, якщо kube-scheduler визначив достатню кількість відповідних вузлів, щоб перевищити налаштований відсоток, він припиняє пошук додаткових відповідних вузлів і переходить до фази оцінки.

У розділі Як планувальник проходиться по вузлах детально описано цей процес.

Стандартний поріг

Якщо ви не вказуєте поріг, Kubernetes розраховує значення за допомогою лінійної формули, яка дає 50% для кластера зі 100 вузлами та 10% для кластера з 5000 вузлів. Нижня межа для автоматичного значення — 5%.

Це означає, що kube-scheduler завжди оцінює принаймні 5% вашого кластера, незалежно від розміру кластера, якщо ви явно не встановили percentageOfNodesToScore менше ніж 5.

Якщо ви хочете, щоб планувальник оцінював всі вузли у вашому кластері, встановіть percentageOfNodesToScore на 100.

Приклад

Нижче наведено приклад конфігурації, яка встановлює percentageOfNodesToScore на 50%.

apiVersion: kubescheduler.config.k8s.io/v1alpha1
kind: KubeSchedulerConfiguration
algorithmSource:
  provider: DefaultProvider

...

percentageOfNodesToScore: 50

Налаштування percentageOfNodesToScore

percentageOfNodesToScore повинен бути значенням від 1 до 100, а стандартне значення розраховується на основі розміру кластера. Також існує зашите мінімальне значення в 100 вузлів.

Важливою деталлю, яку слід врахувати при встановленні цього значення, є те, що при меншій кількості вузлів у кластері, які перевіряються на придатність, деякі вузли не надсилаються для оцінки для вказаного Podʼа. В результаті вузол, який можливо міг би набрати більший бал для запуску вказаного Podʼа, може навіть не надійти до фази оцінки. Це призведе до менш ідеального розміщення Podʼа.

Вам слід уникати встановлення percentageOfNodesToScore дуже низьким, щоб kube-scheduler не часто приймав неправильні рішення щодо розміщення Podʼа. Уникайте встановлення відсотка нижче 10%, якщо продуктивність планувальника критична для вашого застосунку та оцінка вузлів не є важливою. Іншими словами, ви віддаєте перевагу запуску Podʼа на будь-якому вузлі, який буде придатним.

Як планувальник проходиться по вузлах

Цей розділ призначений для тих, хто бажає зрозуміти внутрішні деталі цієї функції.

Щоб всі вузли кластера мали рівні можливості бути враховані для запуску Podʼів, планувальник проходиться по вузлах по колу. Ви можете уявити, що вузли знаходяться у масиві. Планувальник починає з початку масиву вузлів і перевіряє придатність вузлів, поки не знайде достатню кількість відповідних вузлів, як вказано у percentageOfNodesToScore. Для наступного Podʼа планувальник продовжує з точки в масиві вузлів, де він зупинився при перевірці придатності вузлів для попереднього Podʼа.

Якщо вузли знаходяться в кількох зонах, планувальник проходиться по вузлах у різних зонах, щоб забезпечити, що враховуються вузли з різних зон. Наприклад, розгляньте шість вузлів у двох зонах:

Zone 1: Node 1, Node 2, Node 3, Node 4
Zone 2: Node 5, Node 6

Планувальник оцінює придатність вузлів у такому порядку:

Node 1, Node 5, Node 2, Node 6, Node 3, Node 4

Після переходу усіх вузлів він повертається до Вузла 1.

Що далі

3.10.10 - Пакування ресурсів

У scheduling-plugin NodeResourcesFit kube-scheduler є дві стратегії оцінювання, які підтримують пакування ресурсів: MostAllocated та RequestedToCapacityRatio.

Включення пакування ресурсів за допомогою стратегії MostAllocated

Стратегія MostAllocated оцінює вузли на основі використання ресурсів, віддаючи перевагу тим, у яких використання вище. Для кожного типу ресурсів ви можете встановити коефіцієнт, щоб змінити його вплив на оцінку вузла.

Щоб встановити стратегію MostAllocated для втулка NodeResourcesFit, використовуйте конфігурацію планувальника подібну до наступної:

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
- pluginConfig:
  - args:
      scoringStrategy:
        resources:
        - name: cpu
          weight: 1
        - name: memory
          weight: 1
        - name: intel.com/foo
          weight: 3
        - name: intel.com/bar
          weight: 3
        type: MostAllocated
    name: NodeResourcesFit

Щоб дізнатися більше про інші параметри та їх стандартну конфігурацію, див. документацію API для NodeResourcesFitArgs.

Включення пакування ресурсів за допомогою стратегії RequestedToCapacityRatio

Стратегія RequestedToCapacityRatio дозволяє користувачам вказати ресурси разом з коефіцієнтами для кожного ресурсу для оцінювання вузлів на основі відношення запиту до потужності. Це дозволяє користувачам пакувати розширені ресурси, використовуючи відповідні параметри для покращення використання рідкісних ресурсів у великих кластерах. Вона віддає перевагу вузлам згідно з налаштованою функцією виділених ресурсів. Поведінку RequestedToCapacityRatio в функції оцінювання NodeResourcesFit можна керувати за допомогою поля scoringStrategy. У межах поля scoringStrategy ви можете налаштувати два параметри: requestedToCapacityRatio та resources. Параметр shape в requestedToCapacityRatio дозволяє користувачу налаштувати функцію як найменш чи найбільш затребувані на основі значень utilization та score. Параметр resources охоплює як name ресурсу, що оцінюється, так і weight для кожного ресурсу.

Нижче наведено приклад конфігурації, яка встановлює поведінку пакування ресурсів intel.com/foo та intel.com/bar за допомогою поля requestedToCapacityRatio.

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
- pluginConfig:
  - args:
      scoringStrategy:
        resources:
        - name: intel.com/foo
          weight: 3
        - name: intel.com/bar
          weight: 3
        requestedToCapacityRatio:
          shape:
          - utilization: 0
            score: 0
          - utilization: 100
            score: 10
        type: RequestedToCapacityRatio
    name: NodeResourcesFit

Посилання на файл KubeSchedulerConfiguration з прапорцем kube-scheduler --config=/path/to/config/file передасть конфігурацію планувальнику.

Щоб дізнатися більше про інші параметри та їх стандартну конфігурацію, див. документацію API для NodeResourcesFitArgs.

Налаштування функції оцінювання

Параметр shape використовується для вказівки поведінки функції RequestedToCapacityRatio.

shape:
  - utilization: 0
    score: 0
  - utilization: 100
    score: 10

Вищезазначені аргументи надають вузлу score 0, якщо utilization дорівнює 0%, та 10 для utilization 100%, що дозволяє пакування ресурсів. Щоб увімкнути найменш затребувані значення оцінки, значення оцінки має бути оберненим наступним чином.

shape:
  - utilization: 0
    score: 10
  - utilization: 100
    score: 0

resources є необовʼязковим параметром, який типово має значення:

resources:
  - name: cpu
    weight: 1
  - name: memory
    weight: 1

Він може бути використаний для додавання розширених ресурсів наступними чином:

resources:
  - name: intel.com/foo
    weight: 5
  - name: cpu
    weight: 3
  - name: memory
    weight: 1

Параметр weight є необовʼязковим та встановлений у 1, якщо він не вказаний. Також, він може бути встановлений у відʼємне значення.

Оцінка вузла для розподілу потужностей

Цей розділ призначений для тих, хто бажає зрозуміти внутрішні деталі цієї функціональності. Нижче наведено приклад того, як обчислюється оцінка вузла для заданого набору значень.

Запитані ресурси:

intel.com/foo : 2
memory: 256MB
cpu: 2

Коефіцієнти ресурсів:

intel.com/foo : 5
memory: 1
cpu: 3

FunctionShapePoint {{0, 0}, {100, 10}}

Специфікація вузла 1:

Available:
  intel.com/foo: 4
  memory: 1 GB
  cpu: 8

Used:
  intel.com/foo: 1
  memory: 256MB
  cpu: 1

Оцінка вузла:

intel.com/foo  = resourceScoringFunction((2+1),4)
               = (100 - ((4-3)*100/4)
               = (100 - 25)
               = 75                       # запитано + використано = 75% * доступно
               = rawScoringFunction(75)
               = 7                        # floor(75/10)

memory         = resourceScoringFunction((256+256),1024)
               = (100 -((1024-512)*100/1024))
               = 50                       # запитано + використано = 50% * доступно
               = rawScoringFunction(50)
               = 5                        # floor(50/10)

cpu            = resourceScoringFunction((2+1),8)
               = (100 -((8-3)*100/8))
               = 37.5                     # запитано + використано = 37.5% * доступно
               = rawScoringFunction(37.5)
               = 3                        # floor(37.5/10)

NodeScore   =  ((7 * 5) + (5 * 1) + (3 * 3)) / (5 + 1 + 3)
            =  5

Специфікація вузла 2:

Available:
  intel.com/foo: 8
  memory: 1GB
  cpu: 8
Used:
  intel.com/foo: 2
  memory: 512MB
  cpu: 6

Оцінка вузла:

intel.com/foo  = resourceScoringFunction((2+2),8)
               =  (100 - ((8-4)*100/8)
               =  (100 - 50)
               =  50
               =  rawScoringFunction(50)
               = 5

memory         = resourceScoringFunction((256+512),1024)
               = (100 -((1024-768)*100/1024))
               = 75
               = rawScoringFunction(75)
               = 7

cpu            = resourceScoringFunction((2+6),8)
               = (100 -((8-8)*100/8))
               = 100
               = rawScoringFunction(100)
               = 10

NodeScore   =  ((5 * 5) + (7 * 1) + (10 * 3)) / (5 + 1 + 3)
            =  7

Що далі

3.10.11 - Пріоритет та Випередження Podʼів

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.14 [stable]

Podʼи можуть мати пріоритети. Пріоритети вказують на порівняну важливість одних Podʼів порівняно з іншими. Якщо Pod не може бути запланованим, планувальник намагається випередити (виселити) Pod з меншим пріоритетом, щоб зробити можливим планування Podʼів, які перебуваються в стані очікування.

Як використовувати пріоритет та випередження

Для використання пріоритету та випередження:

  1. Додайте один чи декілька PriorityClasses.

  2. Створіть Podʼи з параметром priorityClassName, встановленим на один з доданих PriorityClasses. Звісно, вам не потрібно створювати Podʼи безпосередньо; зазвичай ви додаєте priorityClassName до шаблону Podʼа обʼєкта колекції, такого як Deployment.

Продовжуйте читати для отримання додаткової інформації про ці кроки.

PriorityClass

PriorityClassє є обʼєктом, що не належить до простору імен, і визначає зіставлення імені класу пріоритету з цілим значенням пріоритету. Імʼя вказується в полі name метаданих обʼєкта PriorityClass. Значення вказується в обовʼязковому полі value. Чим вище значення, тим вищий пріоритет. Імʼя обʼєкта PriorityClass повинно бути дійсним піддоменом DNS, і воно не може мати префікс system-.

Обʼєкт PriorityClass може мати будь-яке 32-розрядне ціле значення, яке менше або дорівнює 1 мільярду. Це означає, що діапазон значень для обʼєкта PriorityClass становить від -2147483648 до 1000000000 включно. Більші числа зарезервовані для вбудованих PriorityClass, які представляють критичні системні Podʼів. Адміністратор кластера повинен створити один обʼєкт PriorityClass для кожного такого зіставлення.

PriorityClass також має два необовʼязкові поля: globalDefault та description. Поле globalDefault вказує, що значення цього класу пріоритету повинно використовуватися для Podʼів без priorityClassName. В системі може існувати лише один обʼєкт PriorityClass з globalDefault, встановленим в true. Якщо обʼєкт PriorityClass з globalDefault не встановлено, пріоритет Podʼів без priorityClassName буде рівний нулю.

Поле description є довільним рядком. Воно призначене для сповіщення користувачів кластера про те, коли вони повинні використовувати цей PriorityClass.

Примітки щодо PodPriority та наявних кластерів

  • Якщо ви оновлюєте наявний кластер без цієї функції, пріоритет ваших поточних Podʼів фактично дорівнює нулю.

  • Додавання PriorityClass з globalDefault, встановленим в true, не змінює пріоритети поточних Podʼів. Значення такого PriorityClass використовується тільки для Podʼів, створених після додавання PriorityClass.

  • Якщо ви видаляєте PriorityClass, поточні Podʼи, які використовують імʼя видаленого PriorityClass, залишаються незмінними, але ви не можете створювати більше Podʼів, які використовують імʼя видаленого PriorityClass.

Приклад PriorityClass

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 1000000
globalDefault: false
description: "This priority class should be used for XYZ service pods only."

Невипереджаючий PriorityClass

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.24 [stable]

Podʼи з preemptionPolicy: Never будуть розміщені в черзі планування перед Podʼами з меншим пріоритетом, але вони не можуть випереджати інші Podʼи. Pod, який очікує на планування, залишиться в черзі планування, доки не буде достатньо вільних ресурсів, і його можна буде запланувати. Невипереджаючі Podʼи, подібно до інших Podʼів, підлягають відстроченню планування. Це означає, що якщо планувальник спробує запланувати ці Podʼи, і вони не можуть бути заплановані, спроби їх планування будуть здійснені з меншою частотою, що дозволяє іншим Podʼам з нижчим пріоритетом бути запланованими перед ними.

Невипереджаючі Podʼи все ще можуть бути випереджені іншими, Podʼами з високим пріоритетом. Типове значення preemptionPolicy — PreemptLowerPriority, що дозволяє Podʼам цього PriorityClass випереджати Podʼи з нижчим пріоритетом (бо це поточна типова поведінка). Якщо preemptionPolicy встановлено в Never, Podʼи в цьому PriorityClass будуть невипереджаючими.

Прикладом використання є робочі навантаження для роботи з дослідження даних. Користувач може надіслати завдання, якому він хоче дати пріоритет перед іншими робочими навантаженнями, але не бажає скасувати поточне робоче навантаження, випереджаючи запущені Podʼи. Завдання з високим пріоритетом із preemptionPolicy: Never буде заплановано перед іншими Podʼами в черзі, як тільки будуть наявні вільні ресурси кластера.

Приклад невипереджаючого PriorityClass

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority-nonpreempting
value: 1000000
preemptionPolicy: Never
globalDefault: false
description: "This priority class will not cause other pods to be preempted."

Пріоритет Podʼа

Після того, як у вас є один або кілька PriorityClasses, ви можете створювати Podʼи, які вказують одне з імен цих PriorityClass у їх специфікаціях. Контролер допуску пріоритетів використовує поле priorityClassName і заповнює ціле значення пріоритету. Якщо клас пріоритету не знайдено, Pod відхиляється.

Наведений нижче YAML — це приклад конфігурації Podʼа, який використовує PriorityClass, створений у попередньому прикладі. Контролер допуску пріоритетів перевіряє специфікацію та розраховує пріоритет Podʼа як 1000000.

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  priorityClassName: high-priority

Вплив пріоритету Podʼа на порядок планування

Коли пріоритет Podʼа увімкнено, планувальник впорядковує Podʼи, що перебувають в очікуванні за їх пріоритетом, і такий Pod розташовується попереду інших очікуючих Podʼів з меншим пріоритетом в черзі планування. В результаті Pod з вищим пріоритетом може бути запланований швидше, ніж Podʼи з нижчим пріоритетом, якщо відповідні вимоги до планування виконуються. Якщо такий Pod не може бути запланований, планувальник продовжить спроби запланувати інші Podʼи з меншим пріоритетом.

Випередження

Коли Podʼи створюються, вони потрапляють у чергу та очікують на планування. Планувальник вибирає Pod з черги та намагається запланувати його на вузлі. Якщо не знайдено жодного вузла, який задовольняє всі вказані вимоги Podʼа, для очікуючого Podʼа спрацьовує логіка випередження в черзі. Назвімо очікуючий Pod P. Логіка випередження спробує знайти вузол, де видалення одного або декількох Podʼів з нижчим пріоритетом, ніж P, дозволить запланувати P на цьому вузлі. Якщо такий вузол знайдено, один або декілька Podʼів з нижчим пріоритетом будуть виселені з вузла. Після того, як Podʼи підуть, P може бути запланований на вузлі.

Інформація, доступна користувачеві

Коли Pod P випереджає один або кілька Podʼів на вузлі N, поле nominatedNodeName статусу Podʼа P встановлюється ​​на імʼя вузла N. Це поле допомагає планувальнику відстежувати ресурси, зарезервовані для Podʼа P, і також надає користувачам інформацію про випередження в їх кластерах.

Зверніть увагу, що Pod P не обовʼязково планується на "назначений вузол". Планувальник завжди спочатку спробує "назначений вузол", перед тим як перевіряти будь-які інші вузли. Після того, як Podʼи жертви випереджуються, вони отримують свій період належної зупинки. Якщо під час очікування на завершення роботи Podʼів жертв зʼявляється інший вузол, планувальник може використати інший вузол для планування Podʼа P. В результаті поля nominatedNodeName та nodeName специфікації Podʼа не завжди збігаються. Крім того, якщо планувальник випереджає Podʼи на вузлі N, а потім прибуває Pod вищого пріоритету, ніж Pod P, планувальник може надати вузол N новому Podʼу вищого пріоритету. У такому випадку планувальник очищає nominatedNodeName Podʼа P. Цим самим планувальник робить Pod P придатним для випередження Podʼів на іншому вузлі.

Обмеження випередження

Відповідне завершення роботи жертв випередження

Коли Podʼи випереджаються, жертви отримують свій період належного завершення роботи. У них є стільки часу, скільки вказано в цьому періоді, для завершення своєї роботи та виходу. Якщо вони цього не роблять, їх робота завершується примусово. Цей період належного завершення створює проміжок часу між моментом, коли планувальник випереджає Podʼи, і моментом, коли Pod (P), який перебуває в очікування, може бути запланований на вузол (N). Тим часом планувальник продовжує планувати інші Podʼи, що чекають. Поки жертви завершують роботу самі або примусово, планувальник намагається запланувати Podʼи з черги очікування. Тому, зазвичай є проміжок часу між моментом, коли планувальник випереджає жертв, і моментом, коли Pod P стає запланований. Щоб зменшити цей проміжок, можна встановити період належного завершення для Podʼів з низьким пріоритетом на нуль або мале число.

PodDisruptionBudget підтримується, але не гарантується

PodDisruptionBudget (PDB) дозволяє власникам застосунків обмежувати кількість Podʼів реплікованого застосунку, які одночасно вимикаються через добровільні розлади. Kubernetes підтримує PDB при випередженні Podʼів, але гарантоване дотримання PDB не забезпечується. Планувальник намагається знайти жертв, PDB яких не порушується в результаті випередження, але якщо жодної такої жертви не знайдено, випередження все одно відбудеться, і Podʼи з низьким пріоритетом будуть видалені, попри порушення їх PDB.

Між-Podʼова спорідненість для Podʼів з низьким пріоритетом

Вузол розглядається для випередження тільки тоді, коли відповідь на це питання ствердна: "Якщо всі Podʼи з меншим пріоритетом, ніж очікуваний Pod, будуть видалені з вузла, чи може очікуваний Pod бути запланованим на вузлі?"

Якщо очікуваний Pod має між-Podʼову спорідненість з одним або декількома Podʼами з низьким пріоритетом на вузлі, правило між-Podʼової спорідненості не може бути виконане у відсутності цих Podʼів з низьким пріоритетом. У цьому випадку планувальник не випереджає жодних Podʼів на вузлі. Замість цього він шукає інший вузол. Планувальник може знайти відповідний вузол або може і не знайти. Немає гарантії, що очікуваний Pod може бути запланований.

Рекомендованим рішенням для цієї проблеми є створення між-Podʼової спорідненості лише для Podʼів з рівним або вищим пріоритетом.

Міжвузлове випередження

Припустимо, що вузол N розглядається для випередження, щоб запланувати очікуваний Pod P на N. Pod P може стати можливим на вузлі N лише у випадку випередження Podʼа на іншому вузлі. Ось приклад:

  • Pod P розглядається для вузла N.
  • Pod Q запущений на іншому вузлі в тій же зоні, що й вузол N.
  • Pod P має антиспорідненість по всій зоні з Podʼом Q (з topologyKey: topology.kubernetes.io/zone).
  • Інших випадків антиспорідненості між Podʼом P та іншими Podʼами в зоні немає.
  • Щоб запланувати Pod P на вузлі N, Pod Q може бути випереджений, але планувальник не виконує міжвузлове випередження. Отже, Pod P буде вважатися незапланованим на вузлі N.

Якщо Pod Q буде видалено зі свого вузла, порушення антиспорідненості Podʼа буде усунено, і Pod P, можливо, можна буде запланувати на вузлі N.

Ми можемо розглянути додавання міжвузлового випередження в майбутніх версіях, якщо буде достатньо попиту і якщо ми знайдемо алгоритм з прийнятною продуктивністю.

Розвʼязання проблем

Пріоритет та випередження Podʼа можуть мати небажані побічні ефекти. Ось кілька прикладів потенційних проблем і способів їх вирішення.

Podʼи випереджаються безпідставно

Випередження видаляє наявні Podʼи з кластера в умовах недостатнього ресурсу для звільнення місця для високопріоритетних очікуваних Podsʼів. Якщо ви помилково встановили високі пріоритети для певних Podʼів, ці Podʼи можуть призвести до випередження в кластері. Пріоритет Podʼа вказується, встановленням поля priorityClassName в специфікації Podʼа. Потім ціле значення пріоритету розраховується і заповнюється у поле priority podSpec.

Щоб розвʼязати цю проблему, ви можете змінити priorityClassName для цих Podʼів, щоб використовувати класи з меншим пріоритетом, або залишити це поле порожнім. Порожній priorityClassName типово вважається нулем.

Коли Pod випереджається, для такого Podʼа будуть записані події. Випередження повинно відбуватися лише тоді, коли в кластері недостатньо ресурсів для Podʼа. У таких випадках випередження відбувається лише тоді, коли пріоритет очікуваного Podʼа (випереджаючого) вище, ніж у Podʼів жертв. Випередження не повинно відбуватися, коли немає очікуваного Podʼа, або коли очікувані Podʼи мають рівні або нижчі пріоритети, ніж у жертв. Якщо випередження відбувається в таких сценаріях, будь ласка, сповістіть про це для розвʼязання проблеми.

Podʼи випереджаються, але кандидат не планується

Коли Podʼи випереджаються, вони отримують запитаний період належного завершення, який типово становить 30 секунд. Якщо використовувані Podʼи не завершуються протягом цього періоду, вони завершуються примусово. Після того, як всі жертви зникають, Pod кандидат, може бути запланований.

Поки Pod кандидат, чекає, поки жертви зникнуть, може бути створений Pod з вищим пріоритетом, який підходить на той самий вузол. У цьому випадку планувальник запланує Pod з вищим пріоритетом замість кандидата.

Це очікувана поведінка: Pod з вищим пріоритетом повинен зайняти місце Podʼа з нижчим пріоритетом.

Podʼи з вищим пріоритетом припиняють роботу перед Podʼами з нижчим пріоритетом

Планувальник намагається знайти вузли, на яких можна запустити очікуваний Pod. Якщо вузол не знайдено, планувальник намагається видалити Podʼи з меншим пріоритетом з довільного вузла, щоб звільнити місце для очікуваного Podʼа. Якщо вузол з Podʼами низького пріоритету не може бути використаний для запуску очікуваного Podʼа, планувальник може вибрати інший вузол з Podʼами вищого пріоритету (порівняно з Podʼами на іншому вузлі) для випередження. Жертви все ще повинні мати нижчий пріоритет, ніж Pod кандидат.

Коли є доступні кілька вузлів для випередження, планувальник намагається вибрати вузол з набором Podʼів з найнижчим пріоритетом. Однак якщо такі Podʼи мають PodDisruptionBudget, який буде порушений, якщо вони будуть випереджені, то планувальник може вибрати інший вузол з Podʼами вищого пріоритету.

Коли є кілька вузлів для випередження і жоден з вищезазначених сценаріїв не застосовується, планувальник вибирає вузол з найнижчим пріоритетом.

Взаємодія між пріоритетом Podʼа та якістю обслуговування

Пріоритет Podʼа та клас QoS є двома протилежними функціями з невеликою кількістю взаємодій та без типових обмежень щодо встановлення пріоритету Podʼа на основі його класів QoS. Логіка випередження планувальника не враховує QoS при виборі цілей випередження. Випередження враховує пріоритет Podʼа і намагається вибрати набір цілей з найнижчим пріоритетом. Podʼи вищого пріоритету розглядаються для випередження лише тоді, коли видалення Podʼів з найнижчим пріоритетом не є достатнім для того, щоб дозволити планувальнику розмістити Pod кандидат, або якщо Podʼи з найнижчим пріоритетом захищені PodDisruptionBudget.

kubelet використовує пріоритет для визначення порядку Podʼів для виселення через тиск на вузол. Ви можете використовувати клас QoS для оцінки порядку, в якому ймовірно будуть виселятись Podʼи. kubelet ранжує Podʼи для виселення на основі наступних факторів:

  1. Чи використання, якому недостатньо ресурсів, перевищує запити
  2. Пріоритет Podʼа
  3. Обсяг використання ресурсів в порівнянні із запитами

Дивіться Вибір Podʼа для виселення kubelet для отримання додаткової інформації.

Виселення kubeletʼом через тиск на вузол не виселяє Podʼи, коли їх використання не перевищує їх запити. Якщо Pod з нижчим пріоритетом не перевищує свої запити, він не буде виселений. Інший Pod з вищим пріоритетом, який перевищує свої запити, може бути виселений.

Що далі

3.10.12 - Виселення внаслідок тиску на вузол

Виселення через тиск на вузол — це процес, при якому kubelet активно завершує роботу Podʼів для звільнення ресурсів на вузлах.

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.31 [beta]

The kubelet моніторить ресурси, такі як памʼять, простір на диску та i-nodeʼи файлової системи на вузлах вашого кластера. Коли один або декілька з цих ресурсів досягають певних рівнів використання, kubelet може проактивно припинити роботу одного або кількох Podʼів на вузлі, щоб відновити ресурси та запобігти голодуванню.

Під час виселення внаслідок тиску на вузол, kubelet встановлює фазу для вибраних Podʼів в значення Failed та завершує роботу Podʼа.

Виселення внаслідок тиску на вузол, не є тим самим, що й виселення, ініційоване API.

kubelet не дотримується вашого налаштованого PodDisruptionBudget або параметру terminationGracePeriodSeconds Podʼа. Якщо ви використовуєте порогові значення мʼякого виселення, kubelet дотримується вашого налаштованого eviction-max-pod-grace-period. Якщо ви використовуєте порогові значення жорсткого виселення, kubelet використовує граничний період 0s (негайне завершення) для завершення роботи Podʼа.

Самовідновлення

kubelet намагається відновлювати ресурси на рівні вузла перед тим, як він завершує роботу Podʼів кінцевих користувачів. Наприклад, він видаляє не використані образи контейнерів, коли дискових ресурсів недостатньо.

Якщо Podʼи управляються обʼєктом workload (таким як StatefulSet або Deployment), який заміщує несправні Podʼи, панель управління (kube-controller-manager) створює нові Podʼи на місці виселених Podʼів.

Самовідновлення статичних Podʼів

Якщо ви запускаєте статичний Pod на вузлі, який перебуває під тиском нестачі ресурсів, kubelet може виселити цей статичний Pod. Потім kubelet намагається створити заміну, оскільки статичні Podʼи завжди представляють намір запустити Pod на цьому вузлі.

Kubelet враховує пріоритет статичного Podʼа при створенні заміни. Якщо маніфест статичного Podʼа вказує низький пріоритет, і в межах панелі управління кластера визначені Podʼи з вищим пріоритетом, і вузол перебуває під тиском нестачі ресурсів, то kubelet може не мати можливості звільнити місце для цього статичного Podʼа. Kubelet продовжує намагатися запустити всі статичні Podʼи навіть тоді, коли на вузлі є тиск на ресурси.

Сигнали та пороги виселення

Kubelet використовує різні параметри для прийняття рішень щодо виселення, такі як:

  • Сигнали виселення
  • Пороги виселення
  • Інтервали моніторингу

Сигнали виселення

Сигнали виселення — це поточний стан певного ресурсу в конкретний момент часу. Kubelet використовує сигнали виселення для прийняття рішень про виселення, порівнюючи їх з порогами виселення, які є мінімальною кількістю ресурсу, яка повинна бути доступна на вузлі.

Лubelet використовує такі сигнали виселення:

Сигнал виселенняОписLinux Only
memory.availablememory.available := node.status.capacity[memory] - node.stats.memory.workingSet
nodefs.availablenodefs.available := node.stats.fs.available
nodefs.inodesFreenodefs.inodesFree := node.stats.fs.inodesFree
imagefs.availableimagefs.available := node.stats.runtime.imagefs.available
imagefs.inodesFreeimagefs.inodesFree := node.stats.runtime.imagefs.inodesFree
containerfs.availablecontainerfs.available := node.stats.runtime.containerfs.available
containerfs.inodesFreecontainerfs.inodesFree := node.stats.runtime.containerfs.inodesFree
pid.availablepid.available := node.stats.rlimit.maxpid - node.stats.rlimit.curproc

У цій таблиці стовпець Опис показує, як kubelet отримує значення сигналу. Кожен сигнал підтримує відсоткове або літеральне значення. Kubelet обчислює відсоткове значення відносно загальної потужності, повʼязаної з сигналом.

Сигнали памʼяті

На вузлах Linux, значення для memory.available походить з cgroupfs замість таких інструментів, як free -m. Це важливо, оскільки free -m не працює у контейнері, і якщо користувачі використовують можливість виділення ресурсів для вузла, рішення про відсутність ресурсів приймаються локально для Podʼа кінцевого користувача, який є частиною ієрархії cgroup, а також кореневого вузла. Цей скрипт або скрипт cgroupv2 відтворює той самий набір кроків, які kubelet виконує для обчислення memory.available. Kubelet виключає зі свого обчислення inactive_file (кількість байтів памʼяті, що резервується файлами, у списку неактивних LRU) на основі припущення, що памʼять можна вилучити під час натиску.

На Windows-вузлах значення memory.available отримується з глобального рівня комітів памʼяті вузла (запитується через системний виклик GetPerformanceInfo()) шляхом віднімання глобального значення CommitTotal від CommitLimit вузла. Зверніть увагу, що значення CommitLimit може змінюватися, якщо змінюється розмір файлу підкачки вузла!

Сигнали файлової системи

Kubelet розпізнає три конкретні ідентифікатори файлової системи, які можна використовувати зі сигналами виселення (<identifier>.inodesFree або <identifier>.available):

  1. nodefs: Основна файлова система вузла, використовується для локальних дискових томів, томів emptyDir, які не підтримуються памʼяттю, зберігання логів, ефемерного зберігання та іншого. Наприклад, nodefs містить /var/lib/kubelet.

  2. imagefs: Опціональна файлова система, яку середовище виконання контейнерів може використовувати для зберігання образів контейнерів (що є тільки для читання) і записуваних шарів контейнерів.

  3. containerfs: Опціональна файлова система, яку середовище виконання контейнерів може використовувати для зберігання записуваних шарів. Подібно до основної файлової системи (див. nodefs), вона використовується для зберігання локальних дискових томів, томів emptyDir, які не підтримуються памʼяттю, зберігання логів і ефемерного зберігання, за винятком образів контейнерів. Коли використовується containerfs, файлова система imagefs може бути розділена так, щоб зберігати лише образи (шари тільки для читання) і більше нічого.

Таким чином, kubelet зазвичай підтримує три варіанти файлових систем для контейнерів:

  • Все зберігається на єдиній файловій системі nodefs, також відомій як "rootfs" або просто "root", і немає окремої файлової системи для образів.

  • Зберігання контейнерів (див. nodefs) на окремому диску, а imagefs (записувані та лише для читання шари) відокремлені від кореневої файлової системи. Це часто називають "split disk" (або "separate disk") файловою системою.

  • Файлова система контейнерів containerfs (така ж, як nodefs, плюс записувані шари) знаходиться на root, а образи контейнерів (шари лише для читання) зберігаються на окремій imagefs. Це часто називають "split image" файловою системою.

Kubelet спробує автоматично виявити ці файлові системи з їхньою поточною конфігурацією безпосередньо з підсистеми контейнерів і ігноруватиме інші локальні файлові системи вузла.

Kubelet не підтримує інші файлові системи контейнерів або конфігурації зберігання і наразі не підтримує кілька файлових систем для образів і контейнерів.

Застарілі функції збору сміття kubelet

Деякі функції сміттєзбірника kubelet застаріли на користь процесу виселення:

Наявний ПрапорецьОбґрунтування
--maximum-dead-containersзастаріло, коли старі журнали зберігаються поза контекстом контейнера
--maximum-dead-containers-per-containerзастаріло, коли старі журнали зберігаються поза контекстом контейнера
--minimum-container-ttl-durationзастаріло, коли старі журнали зберігаються поза контекстом контейнера

Пороги виселення

Ви можете вказати спеціальні пороги виселення для kubelet, які він буде використовувати під час прийняття рішень про виселення. Ви можете налаштувати мʼякі та жорсткі пороги виселення.

Пороги виселення мають формат [eviction-signal][operator][quantity], де:

  • eviction-signal — це сигнал виселення, який використовується.
  • operator — це оператор відношення, який ви хочете використати, наприклад, < (менше ніж).
  • quantity — це кількість порогу виселення, наприклад, 1Gi. Значення quantity повинно відповідати представленню кількості, яке використовується в Kubernetes. Ви можете використовувати як літеральні значення, так і відсотки (%).

Наприклад, якщо вузол має загальний обсяг памʼяті 10ГіБ і ви хочете спровокувати виселення, якщо доступна памʼять знизиться до менше ніж 1ГіБ, ви можете визначити поріг виселення як memory.available<10% або memory.available<1Gi (використовувати обидва варіанти одночасно не можна).

Мʼякі пороги виселення

Мʼякий поріг виселення поєднує в собі поріг виселення з обовʼязковим пільговим періодом, вказаним адміністратором. Kubelet не виселяє Podʼи до закінчення пільгового періоду. Kubelet повертає помилку при запуску, якщо ви не вказали пільговий період.

Ви можете вказати як пільговий період для мʼякого порогу виселення, так і максимально дозволений пільговий період для завершення Podʼів, який kubelet використовуватиме під час виселення. Якщо ви вказали максимально дозволений пільговий період і мʼякий поріг виселення досягнутий, kubelet використовує менший із двох пільгових періодів. Якщо ви не вказали максимально дозволений пільговий період, kubelet негайно завершує роботу виселених Podʼів без очікування належного завершення їх роботи.

Ви можете використовувати наступні прапорці для налаштування мʼяких порогів виселення:

  • eviction-soft: Набір порогів виселення, наприклад, memory.available<1.5Gi, які можуть спровокувати виселення Podʼів, якщо вони утримуються протягом вказаного пільгового періоду.
  • eviction-soft-grace-period: Набір пільгових періодів для виселення, наприклад, memory.available=1m30s, які визначають, як довго мʼякий поріг виселення повинен утримуватися, перш ніж буде спровоковане виселення Podʼа.
  • eviction-max-pod-grace-period: Максимально дозволений пільговий період (у секундах) для використання при завершенні Podʼів у відповідь на досягнення мʼякого порогу виселення.

Жорсткі пороги виселення

Жорсткий поріг виселення не має пільгового періоду. Коли досягнуто жорсткого порогу виселення, kubelet негайно завершує роботу Podʼів без очікування належного завершення їх роботи, щоб повернути ресурси, яких бракує.

Ви можете використовувати прапорець eviction-hard для налаштування набору жорстких порогів виселення, наприклад memory.available<1Gi.

Kubelet має наступні стандартні жорсткі пороги виселення:

  • memory.available<100Mi (для вузлів Linux)
  • memory.available<50Mi (для вузлів Windows)
  • nodefs.available<10%
  • imagefs.available<15%
  • nodefs.inodesFree<5% (для вузлів Linux)
  • imagefs.inodesFree<5% (для вузлів Linux)

Ці стандартні значення жорстких порогів виселення будуть встановлені лише у випадку, якщо жоден з параметрів не змінено. Якщо ви зміните значення будь-якого параметра, то значення інших параметрів не будуть успадковані як стандартні та будуть встановлені в нуль. Щоб надати власні значення, ви повинні вказати всі пороги відповідно.

Порогові стандартні значення для containerfs.available і containerfs.inodesFree (для Linux-вузлів) будуть встановлені наступним чином:

  • Якщо для всього використовується одна файлова система, то порогові значення для containerfs встановлюються такими ж, як і для nodefs.

  • Якщо налаштовані окремі файлові системи для образів і контейнерів, то порогові значення для containerfs встановлюються такими ж, як і для imagefs.

Наразі налаштування власниї порогових значень, повʼязаних із containerfs, не підтримується, і буде видано попередження, якщо спробувати це зробити; будь-які надані власні значення будуть ігноровані.

Інтервал моніторингу виселення

Kubelet оцінює пороги виселення, виходячи з налаштованого інтервалу прибирання (housekeeping-interval), який типово становить 10с.

Стани вузла

Kubelet повідомляє про стан вузла, показуючи, що вузол перебуває під тиском через досягнення порогу жорсткого або мʼякого виселення, незалежно від налаштованих пільгових періодів для належного завершення роботи.

Kubelet зіставляє сигнали виселення зі станами вузла наступним чином:

Умова вузлаСигнал виселенняОпис
MemoryPressurememory.availableДоступна памʼять на вузлі досягла порогового значення для виселення
DiskPressurenodefs.available, nodefs.inodesFree, imagefs.available, imagefs.inodesFree, containerfs.available, або containerfs.inodesFreeДоступний диск і вільні іноди на кореневій файловій системі вузла, файловій системі образів або файловій системі контейнерів досягли порогового значення для виселення
PIDPressurepid.availableДоступні ідентифікатори процесів на (Linux) вузлі зменшилися нижче порогового значення для виселення

Панель управління також зіставляє ці стани вузла у вигляді taint.

Kubelet оновлює стани вузла відповідно до налаштованої частоти оновлення стану вузла (--node-status-update-frequency), яка за типово становить 10с.

Коливання стану вузла

У деяких випадках вузли коливаються вище та нижче мʼяких порогів виселення без затримки на визначених пільгових періодах. Це призводить до того, що звітний стан вузла постійно перемикається між true та false, що призводить до поганих рішень щодо виселення.

Для захисту від коливань можна використовувати прапорець eviction-pressure-transition-period, який контролює, як довго kubelet повинен чекати перед переходом стану вузла в інший стан. Період переходу має стандартне значення 5 хв.

Повторне використання ресурсів на рівні вузла

Kubelet намагається повторно використовувати ресурси на рівні вузла перед виселенням контейнерів кінцевих користувачів.

Коли вузол повідомляє про умову DiskPressure, kubelet відновлює ресурси на рівні вузла на основі файлових систем на вузлі.

Без imagefs або containerfs

Якщо на вузлі є лише файлова система nodefs, яка відповідає пороговим значенням для виселення, kubelet звільняє диск у наступному порядку:

  1. Виконує збір сміття для померлих Podʼів і контейнерів.
  2. Видаляє непотрібні образи.

З використанням imagefs

Якщо на вузлі є окрема файлова система imagefs, яку використовують інструменти управління контейнерами, то kubelet робить наступне:

  • Якщо файлова система nodefs відповідає пороговим значенням для виселення, то kubelet видаляє мертві Podʼи та мертві контейнери.
  • Якщо файлова система imagefs відповідає пороговим значенням для виселення, то kubelet видаляє всі невикористані образи.

З imagefs та containerfs

Якщо на вузлі налаштовані окремі файлові системи containerfs разом із файловою системою imagefs, яку використовують середовища виконання контейнерів, то kubelet намагатиметься відновити ресурси наступним чином:

  • Якщо файлова система containerfs досягає порогових значень для виселення, kubelet виконує збір сміття метрвих Podʼів і контейнерів.

  • Якщо файлова система imagefs досягає порогових значень для виселення, kubelet видаляє всі непотрібні образи.

Вибір Podʼів для виселення kubelet

Якщо спроби kubelet відновити ресурси на рівні вузла не знижують сигнал виселення нижче порогового значення, kubelet починає виселяти Podʼи кінцевих користувачів.

Kubelet використовує наступні параметри для визначення порядку виселення Podʼів:

  1. Чи перевищує використання ресурсів Podʼа їх запити
  2. Пріоритет Podʼа
  3. Використання ресурсів Podʼа в порівнянні з запитами

В результаті kubelet ранжує та виселяє Podʼи в наступному порядку:

  1. Podʼи BestEffort або Burstable, де використання перевищує запити. Ці Podʼи виселяються на основі їх пріоритету, а потім на те, наскільки їхнє використання перевищує запит.
  2. Podʼи Guaranteed та Burstable, де використання менше за запити, виселяються останніми, на основі їх пріоритету.

Podʼи Guaranteed гарантовані лише тоді, коли для всіх контейнерів вказано запити та обмеження, і вони є однаковими. Ці Podʼи ніколи не будуть виселятися через споживання ресурсів іншим Podʼом. Якщо системний демон (наприклад, kubelet та journald) споживає більше ресурсів, ніж було зарезервовано за допомогою розподілів system-reserved або kube-reserved, і на вузлі залишилися лише Guaranteed або Burstable Podʼи, які використовують менше ресурсів, ніж запити, то kubelet повинен вибрати Pod для виселення для збереження стабільності вузла та обмеження впливу нестачі ресурсів на інші Podʼи. У цьому випадку він вибере Podʼи з найнижчим пріоритетом першими.

Якщо ви використовуєте статичний Pod і хочете уникнути його виселення під час нестачі речурсів, встановіть поле priority для цього Podʼа безпосередньо. Статичні Podʼи не підтримують поле priorityClassName.

Коли kubelet виселяє Podʼи у відповідь на вичерпання inode або ідентифікаторів процесів, він використовує відносний пріоритет Podʼів для визначення порядку виселення, оскільки для inode та PID не існує запитів.

Kubelet сортує Podʼи по-різному залежно від того, чи є на вузлі відведений файловий ресурс imagefs чи containerfs:

Без imagefs або containerfs (nodefs і imagefs використовують одну і ту ж файлову систему)

  • Якщо nodefs ініціює виселення, kubelet сортує Podʼи на основі їх загального використання диска (локальні томи + логи та записуваний шар усіх контейнерів).

З imagefs (nodefs і imagefs — окремі файлові системи)

  • Якщо nodefs ініціює виселення, kubelet сортує Podʼи на основі використання nodefs (локальні томи + логи всіх контейнерів).

  • Якщо imagefs ініціює виселення, kubelet сортує Podʼи на основі використання записуваного шару всіх контейнерів.

З imagefs та containerfs (imagefs та containerfs розділені)

  • Якщо containerfs ініціює виселення, kubelet сортує Podʼи на основі використання containerfs (локальні томи + логи та записуваний шар усіх контейнерів).

  • Якщо imagefs ініціює виселення, kubelet сортує Podʼи на основі ранжування storage of images, яке відображає використання диска для даного образу.

Мінімальна кількість ресурсів для відновлення після виселення

У деяких випадках виселення підтримує лише невелику кількість виділеного ресурсу. Це може призвести до того, що kubelet постійно стикається з пороговими значеннями для виселення та виконує кілька виселень.

Ви можете використовувати прапорець --eviction-minimum-reclaim або файл конфігурації kubelet для налаштування мінімальної кількості відновлення для кожного ресурсу. Коли kubelet помічає нестачу ресурсу, він продовжує відновлення цього ресурсу до тих пір, поки не відновить кількість, яку ви вказали.

Наприклад, наступна конфігурація встановлює мінімальні кількості відновлення:

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
evictionHard:
  memory.available: "500Mi"
  nodefs.available: "1Gi"
  imagefs.available: "100Gi"
evictionMinimumReclaim:
  memory.available: "0Mi"
  nodefs.available: "500Mi"
  imagefs.available: "2Gi"

У цьому прикладі, якщо сигнал nodefs.available досягає порога виселення, kubelet відновлює ресурс до тих пір, поки сигнал не досягне порога в 1 ГіБ, а потім продовжує відновлення мінімальної кількості 500 МіБ до тих пір, поки доступне значення nodefs збереження не досягне 1,5 ГіБ.

Аналогічно, kubelet намагається відновити ресурс imagefs до тих пір, поки значення imagefs.available не досягне 102 ГіБ, що представляє 102 ГіБ доступного сховища для образів контейнерів. Якщо кількість сховища, яку може відновити kubelet, менше за 2 ГіБ, kubelet нічого не відновлює.

Стандартно eviction-minimum-reclaim є 0 для всіх ресурсів.

Поведінка в разі вичерпання памʼяті на вузлі

Якщо вузол зазнає події out of memory (OOM) до того, як kubelet зможе відновити памʼять, вузол залежить від реагування oom_killer.

Kubelet встановлює значення oom_score_adj для кожного контейнера на основі QoS для Podʼа.

Якість обслуговуванняoom_score_adj
Guaranteed-997
BestEffort1000
Burstableмін(макс(2, 1000 - (1000 × memoryRequestBytes) / machineMemoryCapacityBytes), 999)

Якщо kubelet не може відновити памʼять до того, як вузол зазнає OOM, oom_killer обчислює оцінку oom_score на основі відсотка памʼяті, яку він використовує на вузлі, а потім додає oom_score_adj, щоб отримати ефективну оцінку oom_score для кожного контейнера. Потім він примусово завершує роботу контейнера з найвищим показником.

Це означає, що спочатку припиняється робота контейнерів у Podʼах низького QoS, які споживають велику кількість памʼяті в порівнянні з їх запитами на планування.

На відміну від виселення Podʼа, якщо роботу контейнера було припинено через вичерпання памʼяті, kubelet може перезапустити його відповідно до його restartPolicy.

Поради

У наступних розділах описано найкращі практики конфігурації виселення.

Ресурси, доступні для планування, та політики виселення

При конфігурації kubelet з політикою виселення слід переконатися, що планувальник не буде розміщувати Podʼи, які спричинять виселення через те, що вони безпосередньо викликають тиск на памʼять.

Розгляньте такий сценарій:

  • Обсяг памʼяті вузла: 10 ГіБ
  • Оператор бажає зарезервувати 10% обсягу памʼяті для системних служб (ядро, kubelet, тощо)
  • Оператор бажає виселяти Podʼи при використанні памʼяті на рівні 95%, щоб зменшити випадки виснаження системи.

Для цього kubelet запускається наступним чином:

--eviction-hard=memory.available<500Mi
--system-reserved=memory=1.5Gi

У цій конфігурації прапорець --system-reserved резервує 1,5 ГіБ памʼяті для системи, що становить 10% від загальної памʼяті + кількість порогу виселення.

Вузол може досягти порогу виселення, якщо Pod використовує більше, ніж його запит, або якщо система використовує більше 1 ГіБ памʼяті, що знижує значення memory.available нижче 500 МіБ і спричиняє спрацювання порогу.

DaemonSets та виселення через тиск на вузол

Пріоритет Podʼа — це основний фактор при прийнятті рішень про виселення. Якщо вам не потрібно, щоб kubelet виселяв Podʼи, які належать до DaemonSet, встановіть цим Podʼам достатньо високий пріоритет, вказавши відповідний priorityClassName в специфікації Podʼа. Ви також можете використовувати менший пріоритет або типове значення, щоб дозволити запускати Podʼи з цього DaemonSet тільки тоді, коли є достаньо ресурсів.

Відомі проблеми

У наступних розділах описані відомі проблеми, повʼязані з обробкою вичерпання ресурсів.

kubelet може не сприймати тиск на памʼять одразу

Стандартно, kubelet опитує cAdvisor, щоб регулярно збирати статистику використання памʼяті. Якщо використання памʼяті збільшується протягом цього інтервалу швидко, kubelet може не помітити MemoryPressure настільки швидко, і буде викликаний OOM killer.

Ви можете використовувати прапорець --kernel-memcg-notification, щоб увімкнути API сповіщення memcg в kubelet і отримувати повідомлення негайно, коли перетинається поріг.

Якщо ви не намагаєтеся досягти екстремального використання, але не перескочити розумний рівень перевикористання, розумним обходом для цієї проблеми є використання прапорців --kube-reserved та --system-reserved для виділення памʼяті для системи.

active_file памʼять не вважається доступною памʼяттю

В Linux ядро відстежує кількість байтів файлової памʼяті в активному списку останніх використаних (LRU) як статистику active_file. Kubelet розглядає області памʼяті active_file як непіддаються вилученню. Для робочих навантажень, що інтенсивно використовують локальне сховище з блоковою підтримкою, включаючи ефемерне локальне сховище, кеші ядра файлів та блоків означає, що багато недавно доступних сторінок кеша, ймовірно, будуть враховані як active_file. Якщо достатньо цих буферів блоків ядра перебувають на активному списку LRU, kubelet може сприйняти це як високе використання ресурсів та позначити вузол як такий, що страждає від тиску на памʼять — спровокувавши виселення Podʼів.

Для отримання додаткової інформації дивіться https://github.com/kubernetes/kubernetes/issues/43916.

Ви можете обійти цю проблему, встановивши для контейнерів, які ймовірно виконують інтенсивну діяльність з операцій введення/виведення, однакове обмеження памʼяті та запит памєяті. Вам потрібно оцінити або виміряти оптимальне значення обмеження памʼяті для цього контейнера.

Що далі

3.10.13 - Виселення, ініційоване API

Виселення, ініційоване API — процес, під час якого використовується Eviction API для створення обʼєкта Eviction, який викликає належне завершення роботи Podʼа.

Ви можете ініціювати виселення, викликавши Eviction API безпосередньо або програмно, використовуючи клієнт API-сервера, наприклад, команду kubectl drain. Це створює обʼєкт Eviction, що призводить до завершення роботи Podʼа через API-сервер.

Виселення ініційовані API дотримуються вашого налаштованого PodDisruptionBudgets та terminationGracePeriodSeconds.

Використання API для створення обʼєкта Eviction для Podʼа схоже на виконання контрольованої політикою операції DELETE на Podʼі.

Виклик Eviction API

Ви можете використовувати клієнт кластера Kubernetes, щоб отримати доступ до API Kubernetes та створити обʼєкт Eviction. Для цього ви надсилаєте POST-запит на виконання операції, схожий на наступний приклад:

{
  "apiVersion": "policy/v1",
  "kind": "Eviction",
  "metadata": {
    "name": "quux",
    "namespace": "default"
  }
}

{
  "apiVersion": "policy/v1beta1",
  "kind": "Eviction",
  "metadata": {
    "name": "quux",
    "namespace": "default"
  }
}

Також ви можете спробувати виконати операцію виселення, звернувшись до API за допомогою curl або wget, схожою на наступний приклад:

curl -v -H 'Content-type: application/json' https://your-cluster-api-endpoint.example/api/v1/namespaces/default/pods/quux/eviction -d @eviction.json

Як працює виселення, ініційоване через API

Коли ви запитуєте виселення за допомогою API, сервер API виконує перевірки допуску і відповідає одним із таких способів:

  • 200 ОК: виселення дозволено, субресурс Eviction створюється, і Pod видаляється, подібно до надсилання DELETE-запиту на URL Podʼа.
  • 429 Забагато запитів: виселення на цей момент не дозволено через налаштований PodDisruptionBudget. Можливо, ви зможете спробувати виселення пізніше. Ви також можете отримати цю відповідь через обмеження швидкості API.
  • 500 Внутрішня помилка сервера: виселення не дозволено через помилкову конфігурацію, наприклад, якщо декілька PodDisruptionBudget посилаються на той самий Pod.

Якщо Pod, який ви хочете виселити, не є частиною робочого навантаження, яке має PodDisruptionBudget, сервер API завжди повертає 200 OK та дозволяє виселення.

Якщо сервер API дозволяє виселення, Pod видаляється наступним чином:

  1. Ресурс Pod в сервері API оновлюється з часовою міткою видалення, після чого сервер API вважає ресурс Pod таким, що завершив роботу. Ресурс Pod також позначений для відповідного звершення роботи.
  2. Kubelet на вузлі, на якому запущений локальний Pod, помічає, що ресурс Pod позначений для припинення та починає видаляти локальний Pod.
  3. Під час вимкнення Podʼа kubelet видаляє Pod з обʼєктів Endpoint та EndpointSlice. В результаті контролери більше не вважають Pod за дійсний обʼєкт.
  4. Після закінчення періоду належного завершення роботи для Podʼа kubelet примусово вимикає локальний Pod.
  5. kubelet повідомляє сервер API про видалення ресурсу Pod.
  6. Сервер API видаляє ресурс Pod.

Виправлення застряглих виселень

У деяких випадках ваші застосунки можуть потрапити в непрацездатний стан, де Eviction API буде повертати лише відповіді 429 або 500, поки ви не втрутитеся. Це може відбуватися, наприклад, якщо ReplicaSet створює Podʼи для вашого застосунку, але нові Podʼи не переходять в стан Ready. Ви також можете помітити це поведінку у випадках, коли останній виселений Pod мав довгий період належного завершення роботи при примусовому завершенні роботи.

Якщо ви помічаєте застряглі виселення, спробуйте одне з таких рішень:

  • Скасуйте або призупиніть автоматизовану операцію, що викликає проблему. Дослідіть застряглий застосунок, перш ніж перезапустити операцію.
  • Почекайте трохи, а потім безпосередньо видаліть Pod з панелі управління вашого кластера замість використання API виселення.

Що далі

3.11 - Адміністрування кластера

Деталі низького рівня, що стосуються створення та адміністрування кластера Kubernetes.

Огляд адміністрування кластера призначений для всіх, хто створює або адмініструє кластер Kubernetes. Він передбачає певний рівень знайомства з основними концепціями.

Планування кластера

Ознайомтеся з посібниками в розділі Встановлення для прикладів планування, налаштування та конфігурації кластерів Kubernetes. Рішення, перераховані в цій статті, називаються distros.

Перед вибором посібника врахуйте наступні моменти:

  • Чи хочете ви спробувати Kubernetes на своєму компʼютері, чи хочете побудувати кластер високої доступності з кількома вузлами? Вибирайте distros, які найкраще підходять для ваших потреб.
  • Чи будете ви використовувати кластер Kubernetes, розміщений на хостингу, такому як Google Kubernetes Engine, чи створюватимете свій власний кластер?
  • Чи буде ваш кластер на місці, чи в хмарі (IaaS)? Kubernetes напряму не підтримує гібридні кластери. Замість цього ви можете налаштувати кілька кластерів.
  • Якщо ви налаштовуєте Kubernetes на місці, розгляньте, яка модель мережі підходить найкраще.
  • Чи будете ви запускати Kubernetes на "bare metal" обладнанні чи на віртуальних машинах (VMs)?
  • Ви хочете мати робочий кластер, чи плануєте активний розвиток коду проєкту Kubernetes? Якщо останнє, вибирайте distros, які активно розвиваються. Деякі distros використовують лише бінарні релізи, але пропонують більшу різноманітність вибору.
  • Ознайомтеся з компонентами, необхідними для запуску кластера.

Адміністрування кластера

Захист кластера

Захист kubelеt

Додаткові служби кластера

3.11.1 - Вимикання вузлів

У кластері Kubernetes вузол може бути вимкнутий плановим відповідним способом або несподівано через такі причини, як відключення електропостачання або інші зовнішні обставини. Вимкнення вузла може призвести до відмови робочого навантаження, якщо вузол не буде виводитись з обслуговування перед вимкненням. Вимкнення вузла може бути відповідним або невідповідним (graceful or non-graceful).

Відповідне вимикання вузла

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.21 [beta]

Kubelet намагається виявити вимикання системи вузла та завершує виконання Podʼів на вузлі.

Kubelet забезпечує виконання нормального процесу завершення роботи Podʼа під час вимикання вузла. Під час вимикання вузла kubelet не приймає нові Podʼи (навіть якщо ці Podʼи вже призначені вузлу).

Можливість відповідного вимикання вузла (Graceful node shutdown) залежить від systemd, оскільки вона використовує блокування інгібіторів systemd для затримки вимкнення вузла на певний час.

Вимикання вузла керується функціональною можливістю GracefulNodeShutdown, що є типово увімкненим з версії 1.21.

Зауважте, що типово обидва налаштування конфігурації, описані нижче, shutdownGracePeriod та shutdownGracePeriodCriticalPods, встановлені на нуль, таким чином, не активуючи функціональність відповідного вимикання вузла. Для активації цієї функції, два налаштування конфігурації kubelet повинні бути належним чином налаштовані та встановлені на значення, відмінні від нуля.

Як тільки systemd виявляє або повідомляє про вимикання вузла, kubelet встановлює умову NotReady на вузлі з причиною "node is shutting down". Kube-scheduler дотримується цієї умови та не планує жодних Podʼів на цьому вузлі; очікується, що інші планувальники сторонніх постачальників дотримуватимуться такої ж логіки. Це означає, що нові Podʼи не будуть плануватися на цьому вузлі, і, отже, жоден із них не розпочне роботу.

Kubelet також відхиляє Podʼи під час фази PodAdmission, якщо виявлено поточне вимикання вузла, так що навіть Podʼи з toleration для node.kubernetes.io/not-ready:NoSchedule не почнуть виконання там.

Водночас коли kubelet встановлює цю умову на своєму вузлі через API, kubelet також починає завершення будь-яких Podʼів, які виконуються локально.

Під час вимикання kubelet завершує Podʼи у два етапи:

  1. Завершує роботу звичайних Podʼів, які виконуються на вузлі.
  2. Завершує роботу критичних Podʼи, які виконуються на вузлі.

Функція відповідного вимикання вузла налаштовується двома параметрами конфігурації kubelet:

  • shutdownGracePeriod:
    • Визначає загальний час, протягом якого вузол повинен затримати вимикання. Це загальний термін допомагає завершити Podʼи як звичайні, так і критичні.
  • shutdownGracePeriodCriticalPods:
    • Визначає термін, який використовується для завершення критичних Podʼів під час вимикання вузла. Це значення повинно бути менше за shutdownGracePeriod.

Наприклад, якщо shutdownGracePeriod=30s, а shutdownGracePeriodCriticalPods=10s, kubelet затримає вимикання вузла на 30 секунд. Під час вимикання перші 20 (30-10) секунд будуть зарезервовані для відповідного завершення звичайних Podʼів, а останні 10 секунд будуть зарезервовані для завершення критичних Podʼів.

Відповідне вимикання вузла на основі пріоритету Podʼа

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.24 [beta]

Щоб забезпечити більше гнучкості під час відповідного вимикання вузла щодо порядку Podʼів під час вимикання, поступове вимикання вузла враховує PriorityClass для Podʼів, за умови, що ви активували цю функцію у своєму кластері. Функція дозволяє адміністраторам кластера явно визначити порядок Podʼів під час відповідного вимикання вузла на основі priority classes.

Функція відповідного вимикання вузла, яка описана вище, вимикає Podʼи у дві фази: звичайні Podʼи, а потім критичні Podʼи. Якщо потрібна додаткова гнучкість для явного визначення порядку Podʼа під час вимикання в більш деталізований спосіб, можна використовувати відповідне (graceful) вимикання вузла на основі пріоритету Podʼа.

Коли вимикання вузла враховує пріоритет Podʼів, це дозволяє виконувати вимикання вузла у кілька етапів, кожен етап — це завершення роботи Podʼів певного класу пріоритету. Kubelet можна налаштувати з точним числом етапів та часом вимикання для кожного етапу.

Припустимо, що в кластері існують наступні власні класи пріоритету Podʼів:

Назва класу пріоритету PodʼаЗначення класу пріоритету Podʼа
custom-class-a100000
custom-class-b10000
custom-class-c1000
regular/unset0

В межах конфігурації kubelet налаштування для shutdownGracePeriodByPodPriority може виглядати так:

Значення класу пріоритету PodʼаПеріод вимкнення
10000010 seconds
10000180 seconds
1000120 seconds
060 seconds

Відповідна конфігурація YAML kubelet виглядатиме так:

shutdownGracePeriodByPodPriority:
  - priority: 100000
    shutdownGracePeriodSeconds: 10
  - priority: 10000
    shutdownGracePeriodSeconds: 180
  - priority: 1000
    shutdownGracePeriodSeconds: 120
  - priority: 0
    shutdownGracePeriodSeconds: 60

Вищеописана таблиця означає, що будь-який Pod зі значенням priority >= 100000 отримає лише 10 секунд на зупинку, будь-який Pod зі значенням >= 10000 і < 100000 отримає 180 секунд для зупинки, будь-який Pod зі значенням >= 1000 і < 10000 отримає 120 секунд для зупинки. Нарешті, всі інші Podʼи отримають 60 секунд для зупинки.

Не обовʼязково вказувати значення, відповідні всім класам. Наприклад, можна використовувати ці налаштування:

Значення класу пріоритету PodʼаПеріод вимкнення
100000300 seconds
1000120 seconds
060 seconds

У вищезазначеному випадку Podʼи з custom-class-b потраплять в ту ж саму групу, що й custom-class-c для вимкнення.

Якщо в певному діапазоні відсутні Podʼи, то kubelet не чекатиме на Podʼи у цьому діапазоні пріоритетів. Замість цього, kubelet безпосередньо перейде до наступного діапазону значень пріоритету.

Якщо ця функція увімкнена, а жодна конфігурація не надана, то дії з упорядкування не будуть виконані.

Використання цієї функції передбачає активацію функціональної можливості GracefulNodeShutdownBasedOnPodPriority, та встановлення ShutdownGracePeriodByPodPriority в kubelet config до потрібної конфігурації, яка містить значення класу пріоритету Podʼа та відповідні періоди вимкнення.

Метрики graceful_shutdown_start_time_seconds та graceful_shutdown_end_time_seconds публікуються у підсистему kubelet для моніторингу вимкнень вузлів.

Обробка невідповідних вимкнень вузлів

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.28 [stable]

Дія вимкнення вузла може бути не виявленою Node Shutdown Manager вузла kubelet, чи то через те, що команда не спричинює механізм блокування інгібітора, який використовується kubelet, чи через помилку користувача, тобто ShutdownGracePeriod та ShutdownGracePeriodCriticalPods налаштовані неправильно. Будь ласка, зверніться до вищезазначеної секції Відповідне вимикання вузла для отримання докладнішої інформації.

Коли вузол вимикається, але це не виявляється Node Shutdown Manager вузла kubelet, Podʼи, які є частиною StatefulSet, залишаться в стані завершення на вимкненому вузлі та не зможуть перейти до нового робочого вузла. Це тому, що kubelet на вимкненому вузлі недоступний для видалення Podʼів, і StatefulSet не може створити новий Pod із такою ж назвою. Якщо є томи, які використовуються Podʼами, то VolumeAttachments не буде видалено з оригінального вимкненого вузла, і тому томи використовувані цими Podʼами не можуть бути приєднані до нового робочого вузла. В результаті застосунок, що виконується з StatefulSet, не може працювати належним чином. Якщо оригінальний вимкнений вузол вмикається, Podʼи будуть видалені kubelet, і нові Podʼи будуть створені на іншому робочому вузлі. Якщо оригінальний вимкнений вузол не повертається, ці Podʼи залишаться в стані завершення на вимкненому вузлі назавжди.

Для помʼякшення вищезазначеної ситуації користувач може вручну додати позначку (taint) node.kubernetes.io/out-of-service з ефектом NoExecute чи NoSchedule до вузла, вказавши, що він вийшов із ладу. Якщо у kube-controller-manager увімкнено функціональну можливість NodeOutOfServiceVolumeDetach, і вузол відзначений як такий, що вийшов з ладу з такою позначкою, Podʼи на вузлі будуть примусово видалені, якщо на них немає відповідних toleration, і операції відʼєднання томів для завершення Podʼів на вузлі відбудуться негайно. Це дозволяє Podʼам на вузлі, що вийшов з ладу, швидко відновитися на іншому вузлі.

Під час такого (non-graceful) вимикання робота Podʼів завершується у дві фази:

  1. Насильно видаляються Podʼи, які не мають відповідних toleration out-of-service.
  2. Негайно виконується операція відʼєднання томів для таких Podʼів.

Примусове відʼєднання сховища при перевищенні часу очікування

У будь-якій ситуації, де видалення Podʼа не вдалося протягом 6 хвилин, Kubernetes примусово відʼєднає томи, які розмонтувалися, якщо в цей момент вузол несправний. Будь-яке робоче навантаження, що все ще працює на вузлі та використовує том, який примусово відʼєднується, спричинить порушення специфікації CSI, яка стверджує, що ControllerUnpublishVolume "повинен бути викликаний після всіх викликів NodeUnstageVolume та NodeUnpublishVolume в томі, і вони успішно завершилися". В таких обставинах томи на такому вузлі можуть зіткнутися з пошкодженням даних.

Поведінка примусового відʼєднання сховища є необовʼязковою; користувачі можуть вибрати використання функції "Non-graceful node shutdown" замість цього.

Примусове відʼєднання сховища при перевищенні часу очікування можна вимкнути, встановивши поле конфігурації disable-force-detach-on-timeout в kube-controller-manager. Вимкнення функції примусового відʼєднання при перевищенні часу очікування означає, що у тому, який розміщено на вузлі, який несправний протягом понад 6 хвилин, не буде видалено його повʼязаний VolumeAttachment.

Після застосування цього налаштування, несправні Podʼи, які все ще приєднані до томів, повинні бути відновлені за допомогою процедури Обробки невідповідних вимкнень вузлів, згаданої вище.

Що далі

Дізнайтеся більше про наступне:

3.11.2 - Сертифікати

Щоб дізнатись, як генерувати сертифікати для вашого кластера, дивіться розділ Завдань — Сертифікати.

3.11.3 - Мережа в кластері

Мережі є центральною частиною Kubernetes, але часто важко зрозуміти, як саме вони мають працювати. Існують 4 відмінних мережевих проблеми, які потрібно вирішити:

  1. Взаємодія контейнерів між собою: цю проблему вирішує використання Podʼів та взаємодія з localhost.
  2. Взаємодія між Podʼами: це основна ціль даного документа.
  3. Взаємодія між Podʼом та Service: ця проблема описана у Service.
  4. Взаємодія Service із зовнішнім світом: це також описано в контексті Service.

Kubernetes — це система розподілу машин між застосунками. Зазвичай для розподілу машин потрібно переконатися, що два застосунки не намагаються використовувати одні й ті самі порти. Координацію портів між кількома розробниками дуже важко зробити в масштабі та наражає користувачів на проблеми на рівні кластера, що знаходяться поза їхнім контролем.

Динамічне призначення портів приносить багато ускладнень в систему — кожен застосунок має приймати порти як прапорці, серверам API потрібно знати, як вставляти динамічні номери портів у блоки конфігурації, сервісам потрібно знати, як знаходити один одного тощо. Замість цього Kubernetes обирає інший підхід.

Ознайомтесь докладніше з мережевою моделлю Kubernetes.

Діапазони IP-адрес Kubernetes

Кластери Kubernetes потребують виділення IP-адрес, які не перекриваються, для Podʼів, Service та Вузлів, з діапазону доступних адрес, налаштованих у наступних компонентах:

  • Втулок мережі налаштований для призначення IP-адрес Podʼам.
  • Kube-apiserver налаштований для призначення IP-адрес Service.
  • Kubelet або cloud-controller-manager налаштовані для призначення IP-адрес Вузлам.
Схема, яка ілюструє різні діапазони мережі у кластері Kubernetes

Типи мереж в кластері

Кластери Kubernetes, залежно від налаштованих типів IP адрес, можуть бути категоризовані на:

  • Лише IPv4: Втулок мережі, kube-apiserver та kubelet/cloud-controller-manager налаштовані для призначення лише IPv4-адрес.
  • Лише IPv6: Втулок мережі, kube-apiserver та kubelet/cloud-controller-manager налаштовані для призначення лише IPv6-адрес.
  • IPv4/IPv6 або IPv6/IPv4 подвійний стек:
    • Втулок мережі налаштований для призначення IPv4 та IPv6-адрес.
    • Kube-apiserver налаштований для призначення IPv4 та IPv6-адрес.
    • Kubelet або cloud-controller-manager налаштовані для призначення IPv4 та IPv6-адрес.
    • Усі компоненти повинні узгоджуватися щодо налаштованої основного типу IP адрес.

Кластери Kubernetes враховують лише типи IP, які присутні в обʼєктах Podʼів, Service та Вузлів, незалежно від наявних IP-адрес представлених обʼєктів. Наприклад, сервер або Pod може мати кілька IP-адрес на своїх інтерфейсах, але для реалізації мережевої моделі Kubernetes та визначення типу кластера беруться до уваги лише IP-адреси в node.status.addresses або pod.status.ips.

Як реалізувати мережеву модель Kubernetes

Модель мережі реалізується середовищем виконання контейнерів на кожному вузлі. Найпоширеніші середовища використовують Інтерфейс мережі контейнера (CNI) для керування своєю мережею та забезпечення безпеки. Існує багато різних CNI-втулків від різних вендорів. Деякі з них надають лише базові можливості додавання та видалення мережевих інтерфейсів, тоді як інші надають складніші рішення, такі як інтеграція з іншими системами оркестрування контейнерів, запуск кількох CNI-втулків, розширені функції IPAM та інше.

Див. цю сторінку для неповного переліку мережевих надбудов, які підтримуються в Kubernetes.

Що далі

Ранній дизайн мережевої моделі та її обґрунтування докладно описані у документі дизайну мережі. Щодо майбутніх планів та деяких поточних зусиль, спрямованих на поліпшення мережевих функцій Kubernetes, будь ласка, звертайтеся до SIG-Network KEPs.

3.11.4 - Архітектура логування

Логи застосунків можуть допомогти вам зрозуміти, що відбувається у нього всередині. Логи особливо корисні для виправлення проблем та моніторингу активності кластера. Більшість сучасних застосунків мають деякий механізм логування. Так само, рушії виконання контейнерів розроблені з підтримкою логування. Найпростіший і найбільш прийнятий метод логування для контейнеризованих застосунків — це запис у стандартні потоки виводу та помилок.

Однак, природня функціональність, яку надає рушій виконання контейнерів або середовище виконання, зазвичай недостатня для повного вирішення завдань логування.

Наприклад, вам може бути необхідно дістатись до логів вашого застосунку, якщо контейнер зазнає збою, Pod видаляється, або вузол припиняє роботу.

У кластері логи повинні мати окреме сховище та життєвий цикл незалежно від вузлів, Podʼів або контейнерів. Ця концепція називається логування на рівні кластера.

Архітектури логування на рівні кластера вимагають окремого бекенду для зберігання, аналізу, та отримання логів. Kubernetes не надає власного рішення для зберігання даних логів. Натомість існує багато рішень для логування, які інтегруються з Kubernetes. Наступні розділи описують, як обробляти та зберігати логи на вузлах.

Логи Podʼів та контейнерів

Kubernetes збирає логи з кожного контейнера в запущеному Podʼі.

Цей приклад використовує маніфест для Podʼу з контейнером, який записує текст у стандартний потік виводу, раз на секунду.

apiVersion: v1
kind: Pod
metadata:
  name: counter
spec:
  containers:
  - name: count
    image: busybox:1.28
    args: [/bin/sh, -c,
            'i=0; while true; do echo "$i: $(date)"; i=$((i+1)); sleep 1; done']

Для запуску цього Podʼа використовуйте наступну команду:

kubectl apply -f https://k8s.io/examples/debug/counter-pod.yaml

Вивід буде таким:

pod/counter created

Для отримання логів використовуйте команду kubectl logs, як показано нижче:

kubectl logs counter

Вивід буде схожим на:

0: Fri Apr  1 11:42:23 UTC 2022
1: Fri Apr  1 11:42:24 UTC 2022
2: Fri Apr  1 11:42:25 UTC 2022

Ви можете використовувати kubectl logs --previous для отримання логів з попереднього запуску контейнера. Якщо ваш Pod має кілька контейнерів, вкажіть, логи якого контейнера ви хочете переглянути, додавши назву контейнера до команди з прапорцем -c, ось так:

kubectl logs counter -c count

Дивіться документацію kubectl logs для отримання додаткових деталей.

Як вузли обробляють логи контейнерів

Логування на рівні вузла

Система управління контейнерами обробляє та перенаправляє будь-який вивід, створений потоками stdout та stderr контейнеризованого застосунку. Різні системи управління контейнерами реалізують це по-різному; однак, інтеграція з kubelet стандартизована як формат логування CRI.

Стандартно, якщо контейнер перезапускається, kubelet зберігає один зупинений контейнер з його логами. Якщо Pod видаляється з вузла, всі відповідні контейнери також видаляються разом з їхніми логами.

Kubelet надає доступ до логів клієнтам через спеціальну функцію Kubernetes API. Зазвичай доступ до неї здійснюється за допомогою команди kubectl logs.

Ротація логів

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.21 [stable]

Kubelet відповідає за ротацію логів контейнерів та управління структурою тек логів. Kubelet передає цю інформацію до системи управління контейнерами (використовуючи CRI), а середовище виконання записує логи контейнерів у вказане місце.

Ви можете налаштувати два параметри конфігурації kubelet containerLogMaxSize (типово 10Mi) та containerLogMaxFiles (типово 5), використовуючи файл конфігурації kubelet. Ці параметри дозволяють вам налаштувати максимальний розмір для кожного файлу лога та максимальну кількість файлів, дозволених для кожного контейнера відповідно.

Для ефективної ротації логів у кластерах, де обсяг логів, згенерованих робочим навантаженням, великий, kubelet також надає механізм налаштування ротації логів з погляду кількості одночасних ротацій логів та інтервалу, з яким логи відстежуються та ротуються за потребою. Ви можете налаштувати два параметри конфігурації kubelet, containerLogMaxWorkers та containerLogMonitorInterval за допомогою файлу конфігурації kubelet.

Коли ви виконуєте kubectl logs як у прикладі базового логування, kubelet на вузлі обробляє запит і безпосередньо читає з файлу лога. Kubelet повертає вміст файлу лога.

Логи системних компонентів

Існують два типи системних компонентів: ті, які зазвичай працюють у контейнерах, та ті компоненти, які безпосередньо відповідають за запуск контейнерів. Наприклад:

  • Kubelet та система управління контейнерами не працюють у контейнерах. Kubelet виконує ваші контейнери (згруповані разом у Podʼи).
  • Планувальник Kubernetes, менеджер контролерів та сервер API працюють у Podʼах (зазвичай статичних Podʼах). Компонент etcd працює у планувальнику, і зазвичай також як статичний Pod. Якщо ваш кластер використовує kube-proxy, зазвичай ви запускаєте його як DaemonSet.

Знаходження логів

Спосіб, яким kubelet та система управління контейнерами записують логи, залежить від операційної системи, яку використовує вузол:

На вузлах Linux, які використовують systemd, типово kubelet та система управління контейнерами записують логи у журнал systemd. Ви можете використовувати journalctl для читання журналу systemd; наприклад: journalctl -u kubelet.

Якщо systemd відсутній, kubelet та система управління контейнерами записують логи у файли .log в директорії /var/log. Якщо ви хочете, щоб логи були записані в інше місце, ви можете опосередковано запустити kubelet через допоміжний інструмент, kube-log-runner, та використовувати цей інструмент для перенаправлення логів kubelet у вибрану вами теку.

Типово, kubelet спрямовує систему управління контейнерами на запис логів у теці всередині /var/log/pods.

Для отримання додаткової інформації про kube-log-runner, читайте Системні логи.

Типово kubelet записує логи у файли всередині теки C:\var\logs (⚠️ зверніть увагу, що це не C:\var\log).

Хоча C:\var\log є типовим місцем для цих логів Kubernetes, деякі інструменти розгортання кластера налаштовують вузли Windows так, щоб логи записувались у C:\var\log\kubelet.

Якщо ви хочете, щоб логи були записані в інше місце, ви можете опосередковано запустити kubelet через допоміжний інструмент, kube-log-runner, та використовувати цей інструмент для перенаправлення логів kubelet у вибрану вами директорію.

Проте, типово kubelet скеровує систему управління контейнерами на запис логів у теці всередині C:\var\log\pods.

Для отримання додаткової інформації про kube-log-runner, читайте Системні логи.


Для компонентів кластера Kubernetes, які працюють у Podʼах, логи записуються у файли всередині директорії /var/log, оминаючи типовий механізм логування (компоненти не записуються у журнал systemd). Ви можете використовувати механізми зберігання Kubernetes для відображення постійного зберігання у контейнері, який виконує компонент.

Kubelet дозволяє змінювати теку логів Podʼів зі стандартної /var/log/pods на власну. Це можна зробити за допомогою параметра podLogsDir у конфігураційному файлі kubelet.

Для отримання детальної інформації про etcd та його логи, перегляньте документацію etcd. Знову ж таки, ви можете використовувати механізми зберігання Kubernetes для відображення постійного зберігання у контейнері, який виконує компонент.

Архітектури логування на рівні кластера

Хоча Kubernetes не надає власного рішення для логування на рівні кластера, існують кілька загальних підходів, які ви можете розглянути. Ось деякі варіанти:

  • Використання агента логування на рівні вузла, який працює на кожному вузлі.
  • Додавання в Pod з застосунком в спеціального sidecaar-контейнера для логування.
  • Пряме надсилання логів безпосередньо до бекенду з застосунка.

Використання агента логування на рівні вузла

Використання агента логування на рівні вузла

Ви можете реалізувати логування на рівні кластера, включивши агента логування на рівні вузла на кожному вузлі. Агент логування — це спеціальний інструмент, який надає логи або надсилає їх до бекенду. Зазвичай агент логування є контейнером, який має доступ до теки з файлами логів з усіх контейнерів застосунків на цьому вузлі.

Оскільки агент логування повинен працювати на кожному вузлі, рекомендується запускати агента як DaemonSet.

Логування на рівні вузла створює лише одного агента на вузол і не вимагає жодних змін в застосунках, що працюють на вузлі.

Контейнери пишуть у stdout та stderr, але без узгодженого формату. Агент на рівні вузла збирає ці логи та пересилає їх для агрегації.

Використання sidecar контейнера з агентом логування

Ви можете використовувати sidecar контейнер у такий спосіб:

  • sidecar контейнер транслює логи застосунку у свій власний stdout.
  • sidecar контейнер запускає агента логування, який налаштований на збір логів з контейнера застосунку.

Sidecar контейнер для трансляції

Sidecar контейнер з контейнером для трансляції

Маючи свої sidecar контейнери які пишуть у власні stdout та stderr, ви можете скористатися kubelet та агентом логування, які вже працюють на кожному вузлі. Sidecar контейнери читають логи з файлу, сокета або журналу. Кожен sidecar контейнер виводить лог у свій власний потік stdout або stderr.

Цей підхід дозволяє вам розділити кілька потоків логів з різних частин вашого застосунку деякі з яких можуть не підтримувати запис у stdout або stderr. Логіка перенаправлення логів мінімальна, тому це не становить значного навантаження. Крім того, оскільки stdout та stderr обробляються kubelet, ви можете використовувати вбудовані інструменти, такі як kubectl logs.

Наприклад, Pod запускає один контейнер, і контейнер записує до двох різних файлів логів з використанням двох різних форматів. Ось маніфест для Podʼа:

apiVersion: v1
kind: Pod
metadata:
  name: counter
spec:
  containers:
  - name: count
    image: busybox:1.28
    args:
    - /bin/sh
    - -c
    - >
      i=0;
      while true;
      do
        echo "$i: $(date)" >> /var/log/1.log;
        echo "$(date) INFO $i" >> /var/log/2.log;
        i=$((i+1));
        sleep 1;
      done      
    volumeMounts:
    - name: varlog
      mountPath: /var/log
  volumes:
  - name: varlog
    emptyDir: {}

Не рекомендується записувати записи логів з різними форматами у той самий потік логу, навіть якщо вам вдалося перенаправити обидва компоненти до потоку stdout контейнера. Замість цього ви можете створити два додаткових sidecar контейнери. Кожен додатковий sidecar контейнер може перехоплювати певний файл логів зі спільного тома та перенаправляти логи до власного потоку stdout.

Ось маніфест для Podʼа, в якому є два sidecar контейнери:

apiVersion: v1
kind: Pod
metadata:
  name: counter
spec:
  containers:
  - name: count
    image: busybox:1.28
    args:
    - /bin/sh
    - -c
    - >
      i=0;
      while true;
      do
        echo "$i: $(date)" >> /var/log/1.log;
        echo "$(date) INFO $i" >> /var/log/2.log;
        i=$((i+1));
        sleep 1;
      done      
    volumeMounts:
    - name: varlog
      mountPath: /var/log
  - name: count-log-1
    image: busybox:1.28
    args: [/bin/sh, -c, 'tail -n+1 -F /var/log/1.log']
    volumeMounts:
    - name: varlog
      mountPath: /var/log
  - name: count-log-2
    image: busybox:1.28
    args: [/bin/sh, -c, 'tail -n+1 -F /var/log/2.log']
    volumeMounts:
    - name: varlog
      mountPath: /var/log
  volumes:
  - name: varlog
    emptyDir: {}

Тепер, коли ви запускаєте цей Pod, ви можете отримати доступ до кожного потоку логів окремо, запустивши такі команди:

kubectl logs counter count-log-1

Результат буде подібним до:

0: Fri Apr  1 11:42:26 UTC 2022
1: Fri Apr  1 11:42:27 UTC 2022
2: Fri Apr  1 11:42:28 UTC 2022
...
kubectl logs counter count-log-2

Результат буде подібним до:

Fri Apr  1 11:42:29 UTC 2022 INFO 0
Fri Apr  1 11:42:30 UTC 2022 INFO 0
Fri Apr  1 11:42:31 UTC 2022 INFO 0
...

Якщо ви встановили агент на рівні вузла у свій кластер, цей агент автоматично перехоплює ці потоки логів без будь-якої додаткової конфігурації. Якщо вам цікаво, ви можете налаштувати агента для розбору рядків логів залежно від вихідного контейнера.

Навіть для Podʼів, які використовують низьке використання CPU та памʼяті (наприклад, декілька мілікорів (millicore) для CPU та кілька мегабайтів для памʼяті), запис логів до файлу та їх трансляція до stdout можуть подвоїти обсяг памʼяті, необхідний на вузлі. Якщо у вас є застосунок, який записує у єдиний файл, рекомендується встановити /dev/stdout як призначення, а не впроваджувати підхід з sidecar контейнером для трансляції.

Sidecar контейнери також можуть використовуватися для ротації файлів логів, ротація яких не може бути зроблена самим застосунком. Прикладом такого підходу є малий контейнер, який періодично запускає logrotate. Однак набагато простіше використовувати stdout та stderr безпосередньо і залишити ротації та політику зберігання kubelet.

Sidecar контейнер з агентом логування

Sidecar контейнер з агентом логування

Якщо агент логування на рівні вузла не має достатньої гнучкості для вашої ситуації, ви можете створити sidecar контейнер з окремим агентом логування, який ви налаштували спеціально для роботи з вашим застосунком.

Ось два приклади маніфестів, які ви можете використати для впровадження sidecar контейнера з агентом логування. Перший маніфест містить ConfigMap, щоб налаштувати fluentd.

apiVersion: v1
kind: ConfigMap
metadata:
  name: fluentd-config
data:
  fluentd.conf: |
    <source>
      type tail
      format none
      path /var/log/1.log
      pos_file /var/log/1.log.pos
      tag count.format1
    </source>

    <source>
      type tail
      format none
      path /var/log/2.log
      pos_file /var/log/2.log.pos
      tag count.format2
    </source>

    <match **>
      type google_cloud
    </match>    

Другий маніфест описує Pod, в якому є sidecar контейнер, що запускає fluentd. Pod монтує том, де fluentd може отримати свої дані конфігурації.

apiVersion: v1
kind: Pod
metadata:
  name: counter
spec:
  containers:
  - name: count
    image: busybox:1.28
    args:
    - /bin/sh
    - -c
    - >
      i=0;
      while true;
      do
        echo "$i: $(date)" >> /var/log/1.log;
        echo "$(date) INFO $i" >> /var/log/2.log;
        i=$((i+1));
        sleep 1;
      done      
    volumeMounts:
    - name: varlog
      mountPath: /var/log
  - name: count-agent
    image: registry.k8s.io/fluentd-gcp:1.30
    env:
    - name: FLUENTD_ARGS
      value: -c /etc/fluentd-config/fluentd.conf
    volumeMounts:
    - name: varlog
      mountPath: /var/log
    - name: config-volume
      mountPath: /etc/fluentd-config
  volumes:
  - name: varlog
    emptyDir: {}
  - name: config-volume
    configMap:
      name: fluentd-config

Викладення логів безпосередньо з застосунку

Викладення логів безпосередньо з застосунку

Кластерне логування, яке викладає або надсилає логи безпосередньо з кожного застосунку, виходить за межі цілей Kubernetes.

Що далі

3.11.5 - Метрики для компонентів системи Kubernetes

Метрики системних компонентів можуть краще показати, що відбувається всередині. Метрики особливо корисні для побудови інформаційних панелей та сповіщень.

Компоненти Kubernetes видають метрики у форматі Prometheus. Цей формат являє собою структурований звичайний текст, призначений для зручного сприйняття як людьми, так і машинами.

Метрики в Kubernetes

У більшості випадків метрики доступні на точці доступу /metrics HTTP сервера. Для компонентів, які типово не показують цю точку, її можна активувати за допомогою прапорця --bind-address.

Приклади таких компонентів:

У промисловому середовищі ви, можливо, захочете налаштувати Prometheus Server або інший інструмент збору метрик для їх періодичного отримання і доступу у якомусь виді бази даних часових рядів.

Зверніть увагу, що kubelet також викладає метрики на /metrics/cadvisor, /metrics/resource та /metrics/probes. Ці метрики не мають того самого життєвого циклу.

Якщо ваш кластер використовує RBAC, для читання метрик потрібна авторизація через користувача, групу або ServiceAccount з ClusterRole, що дозволяє доступ до /metrics. Наприклад:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: prometheus
rules:
  - nonResourceURLs:
      - "/metrics"
    verbs:
      - get

Життєвий цикл метрик

Метрики альфа → Стабільні метрики → Застарілі метрики → Приховані метрики → Видалені метрики

Альфа метрики не мають гарантій щодо їх стабільності. Ці метрики можуть бути змінені або навіть вилучені в будь-який момент.

Стабільні метрики гарантують, що їх формат залишиться незмінним. Це означає що:

  • Стабільні метрики, які не мають позначки "DEPRECATED", не будуть змінені чи вилучені.
  • Тип стабільних метрик не буде змінений.

Метрики, які позначені як застарілі, заплановані для видалення, але все ще доступні для використання. Ці метрики мають анотацію щодо версії, у якій вони стали застарілими.

Наприклад:

  • Перед застарінням

    # HELP some_counter this counts things
    # TYPE some_counter counter
    some_counter 0
    
  • Після застаріння

    # HELP some_counter (Deprecated since 1.15.0) this counts things
    # TYPE some_counter counter
    some_counter 0
    

Приховані метрики більше не публікуються для збирання, але все ще доступні для використання. Щоб використовувати приховану метрику, будь ласка, звертайтесь до розділу Показ прихованих метрик.

Видалені метрики більше не публікуються і не можуть бути використані.

Показ прихованих метрик

Як описано вище, адміністратори можуть увімкнути приховані метрики через прапорець командного рядка для конкретного бінарного файлу. Це призначено для використання адміністраторами, якщо вони пропустили міграцію метрик, які стали застарілими в останньому релізі.

Прапорець show-hidden-metrics-for-version приймає версію, для якої ви хочете показати метрики, які стали застарілими у цьому релізі. Версія зазначається як x.y, де x — головна версія, y — мінорна версія. Версія патчу не потрібна, хоча метрика може бути застарілою в патч-релізі, причина в тому, що політика застарілих метрик працює з мінорними релізами.

Прапорець може приймати тільки попередню мінорну версію як своє значення. Усі метрики, які були приховані в попередній версії, будуть доступні, якщо адміністратори встановлять попередню версію на show-hidden-metrics-for-version. Занадто стара версія не дозволяється, оскільки це порушує політику застарілих метрик.

Візьміть метрику A як приклад, тут припускається, що A застаріла в 1.n. Згідно з політикою застарілих метрик, ми можемо зробити наступні висновки:

  • У випуску 1.n, метрика застаріла і може бути типово доступною.
  • У випуску 1.n+1, метрика є типово прихованою і може бути доступна через параметр командного рядка show-hidden-metrics-for-version=1.n.
  • У випуску 1.n+2, метрику слід видалити з кодової бази. Більше немає можливості її отримання.

Якщо ви оновлюєтеся з випуску 1.12 до 1.13, але все ще залежите від метрики A, яка застаріла в 1.12, ви повинні встановити приховані метрики через командний рядок: --show-hidden-metrics=1.12 і памʼятати про те, щоб видалити цю залежність від метрики до оновлення до 1.14.

Метрики компонентів

Метрики kube-controller-manager

Метрики менеджера контролера надають важливі відомості про продуктивність та стан контролера. Ці метрики включають загальні метрики часу виконання мови програмування Go, такі як кількість go_routine, а також специфічні для контролера метрики, такі як час виконання запитів до etcd або час виконання API Cloudprovider (AWS, GCE, OpenStack), які можна використовувати для оцінки стану кластера.

Починаючи з Kubernetes 1.7, доступні докладні метрики Cloudprovider для операцій зберігання для GCE, AWS, Vsphere та OpenStack. Ці метрики можуть бути використані для моніторингу стану операцій з постійними томами.

Наприклад, для GCE ці метрики називаються:

cloudprovider_gce_api_request_duration_seconds { request = "instance_list"}
cloudprovider_gce_api_request_duration_seconds { request = "disk_insert"}
cloudprovider_gce_api_request_duration_seconds { request = "disk_delete"}
cloudprovider_gce_api_request_duration_seconds { request = "attach_disk"}
cloudprovider_gce_api_request_duration_seconds { request = "detach_disk"}
cloudprovider_gce_api_request_duration_seconds { request = "list_disk"}

Метрики kube-scheduler

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.21 [beta]

Планувальник надає опціональні метрики, які повідомляють про запитані ресурси та бажані обмеження всіх запущених Podʼів. Ці метрики можна використовувати для побудови панелей управління ресурсами, оцінки поточних або історичних обмежень планування, швидкого виявлення навантажень, які не можуть бути розміщені через відсутність ресурсів, і порівняння фактичного використання з запитом Podʼа.

kube-scheduler ідентифікує ресурсні запити та обмеження для кожного Podʼа; коли запит або обмеження не дорівнює нулю, kube-scheduler повідомляє про метричні часові ряди. Часові ряди мають мітки:

  • простір імен
  • імʼя Podʼа
  • вузол, на якому запущений Pod, або пустий рядок, якщо він ще не запущений
  • пріоритет
  • призначений планувальник для цього Podʼа
  • назва ресурсу (наприклад, cpu)
  • одиниця ресурсу, якщо відома (наприклад, core)

Як тільки Pod досягає завершення (має restartPolicy Never або OnFailure і перебуває в стані Succeeded або Failed, або був видалений і всі контейнери мають стан завершення), часова послідовність більше не повідомляється, оскільки тепер планувальник вільний для розміщення інших Podʼів для запуску. Дві метрики називаються kube_pod_resource_request та kube_pod_resource_limit.

Метрики доступні за адресою HTTP /metrics/resources та вимагають такої ж авторизації, що і точка доступу /metrics планувальника. Вам потрібно використовувати прапорець --show-hidden-metrics-for-version=1.20, щоб показати ці альфа-метрики.

Вимкнення метрик

Ви можете явно вимкнути метрики за допомогою прапорця командного рядка --disabled-metrics. Це може бути бажано, наприклад, якщо метрика викликає проблеми з продуктивністю. Вхідні дані — це список вимкнених метрик (тобто --disabled-metrics=метрика1,метрика2).

Забезпечення послідовності метрик

Метрики з нескінченними розмірами можуть викликати проблеми з памʼяттю в компонентах, які їх інструментують. Щоб обмежити використання ресурсів, ви можете використовувати опцію командного рядка --allow-label-value, щоб динамічно налаштувати список дозволених значень міток для метрики.

На стадії альфа, цей прапорець може приймати лише серію зіставлень як список дозволених міток метрики. Кожне зіставлення має формат <metric_name>,<label_name>=<allowed_labels>, де <allowed_labels> — це розділені комами допустимі назви міток.

Загальний формат виглядає так:

--allow-label-value <metric_name>,<label_name>='<allow_value1>, <allow_value2>...', <metric_name2>,<label_name>='<allow_value1>, <allow_value2>...', ...

Ось приклад:

--allow-label-value number_count_metric,odd_number='1,3,5', number_count_metric,even_number='2,4,6', date_gauge_metric,weekend='Saturday,Sunday'

Крім того, що це можна вказати з командного рядка, теж саме можна зробити за допомогою конфігураційного файлу. Ви можете вказати шлях до цього файлу конфігурації, використовуючи аргумент командного рядка --allow-metric-labels-manifest для компонента. Ось приклад вмісту цього конфігураційного файлу:

allow-list:
- "metric1,label2": "v1,v2,v3"
- "metric2,label1": "v1,v2,v3"

Додатково, метрика cardinality_enforcement_unexpected_categorizations_total записує кількість неочікуваних категоризацій під час вказання послідовності, тобто кожного разу, коли значення мітки зустрічається, що не дозволяється з урахуванням обмежень списку дозволених значень.

Що далі

3.11.6 - Метрики для станів обʼєктів Kubernetes

kube-state-metrics — це агент-надбудова для генерації та надання метрик на рівні кластера.

Стан обʼєктів Kubernetes у Kubernetes API може бути поданий у вигляді метрик. Агент-надбудова kube-state-metrics може підключатися до сервера Kubernetes API та надавати доступ до точки доступу з метриками, що генеруються зі стану окремих обʼєктів у кластері. Він надає різні дані про стан обʼєктів, такі як мітки та анотації, час запуску та завершення, статус або фазу, в яких обʼєкт знаходиться зараз. Наприклад, контейнери, що працюють у Podʼах, створюють метрику kube_pod_container_info. Вона включає імʼя контейнера, імʼя Podʼа, до якого він належить, простір імен, в якому працює Pod, імʼя образу контейнера, ідентифікатор образу, імʼя образу з опису контейнера, ідентифікатор працюючого контейнера та ідентифікатор Podʼа як мітки.

Зовнішній компонент, який може зчитувати точку доступу kube-state-metrics (наприклад, за допомогою Prometheus), можна використовувати для активації наступних варіантів використання.

Приклад: використання метрик з kube-state-metrics для запиту стану кластера

Серії метрик, що генеруються kube-state-metrics, допомагають отримати додаткові уявлення про кластер, оскільки їх можна використовувати для запитів.

Якщо ви використовуєте Prometheus або інструмент, який використовує ту саму мову запитів, наступний запит PromQL поверне кількість Podʼів, які не готові:

count(kube_pod_status_ready{condition="false"}) by (namespace, pod)

Приклад: сповіщення на основі kube-state-metrics

Метрики, що генеруються з kube-state-metrics, також дозволяють сповіщати про проблеми в кластері.

Якщо ви використовуєте Prometheus або схожий інструмент, який використовує ту саму мову правил сповіщень, наступне сповіщення буде активовано, якщо є Podʼи, які перебувають у стані Terminating протягом понад 5 хвилин:

groups:
- name: Pod state
  rules:
  - alert: PodsBlockedInTerminatingState
    expr: count(kube_pod_deletion_timestamp) by (namespace, pod) * count(kube_pod_status_reason{reason="NodeLost"} == 0) by (namespace, pod) > 0
    for: 5m
    labels:
      severity: page
    annotations:
      summary: Pod {{$labels.namespace}}/{{$labels.pod}} blocked in Terminating state.

3.11.7 - Системні логи

Логи компонентів системи фіксують події, які відбуваються в кластері, що може бути дуже корисним для налагодження. Ви можете налаштувати рівень деталізації логів, щоб бачити більше або менше деталей. Логи можуть бути настільки грубими, що вони показують лише помилки у компоненті, або настільки дрібними, що вони показують крок за кроком слідування за подіями (наприклад, логи доступу HTTP, зміни стану події, дії контролера або рішення планувальника).

Klog

klog — це бібліотека реєстрації подій для системних компонентів Kubernetes. klog генерує повідомлення логу для системних компонентів Kubernetes.

Kubernetes знаходиться в процесі спрощення реєстрації подій у своїх компонентах. Наступні прапорці командного рядка klog є застарілими починаючи з Kubernetes v1.23 і будуть видалені у Kubernetes v1.26:

  • --add-dir-header
  • --alsologtostderr
  • --log-backtrace-at
  • --log-dir
  • --log-file
  • --log-file-max-size
  • --logtostderr
  • --one-output
  • --skip-headers
  • --skip-log-headers
  • --stderrthreshold

Вивід буде завжди записуватися у stderr, незалежно від формату виводу. Очікується, що перенаправлення виводу буде оброблено компонентом, який викликає компонент Kubernetes. Це може бути оболонка POSIX або інструмент, такий як systemd.

У деяких випадках, наприклад, у контейнері distroless або службі Windows, ці параметри недоступні. У цьому випадку можна використовувати бінарний файл kube-log-runner як обгортку навколо компонента Kubernetes для перенаправлення виводу. Вже скомпільований бінарний файл включено в декілька базових образів Kubernetes під його традиційною назвою /go-runner та як kube-log-runner в архівах випусків сервера та вузла.

Ця таблиця показує відповідність викликів kube-log-runner перенаправленню оболонки:

ВикористанняPOSIX оболонка (напр. bash)kube-log-runner <options> <cmd>
Обʼєднати stderr і stdout, записати у stdout2>&1kube-log-runner (типова поведінка)
Перенаправити обидва в лог1>>/tmp/log 2>&1kube-log-runner -log-file=/tmp/log
Скопіювати в лог і до stdout2>&1 | tee -a /tmp/logkube-log-runner -log-file=/tmp/log -also-stdout
Перенаправити лише stdout в лог>/tmp/logkube-log-runner -log-file=/tmp/log -redirect-stderr=false

Вивід klog

Приклад традиційного формату виводу klog:

I1025 00:15:15.525108       1 httplog.go:79] GET /api/v1/namespaces/kube-system/pods/metrics-server-v0.3.1-57c75779f-9p8wg: (1.512ms) 200 [pod_nanny/v0.0.0 (linux/amd64) kubernetes/$Format 10.56.1.19:51756]

Рядок повідомлення може містити перенесення рядків:

I1025 00:15:15.525108       1 example.go:79] This is a message
which has a line break.

Структуроване ведення логів

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.23 [beta]

Структуроване ведення логів вводить єдину структуру в повідомлення логів, що дозволяє програмно отримувати інформацію. Ви можете зберігати та обробляти структуровані логи з меншими зусиллями та витратами. Код, який генерує повідомлення логів, визначає, чи використовує він традиційний неструктурований вивід klog, чи структуроване ведення логів.

Формат структурованих повідомлень логів є типово текстовим, у форматі, який зберігає сумісність з традиційним klog:

<klog заголовок> "<повідомлення>" <ключ1>="<значення1>" <ключ2>="<значення2>" ...

Приклад:

I1025 00:15:15.525108       1 controller_utils.go:116] "Pod status updated" pod="kube-system/kubedns" status="ready"

Рядки беруться в лапки. Інші значення форматуються за допомогою %+v, що може призводити до того, що повідомлення логів продовжуватимуться на наступному рядку залежно від даних.

I1025 00:15:15.525108       1 example.go:116] "Example" data="This is text with a line break\nand \"quotation marks\"." someInt=1 someFloat=0.1 someStruct={StringField: First line,
second line.}

Контекстне ведення логів

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.30 [beta]

Контекстне ведення логів базується на структурованому веденні логів. Це переважно стосується того, як розробники використовують системні виклики ведення логів: код, побудований на цьому концепті, є більш гнучким і підтримує додаткові варіанти використання, як описано в KEP щодо контекстного ведення логів.

Якщо розробники використовують додаткові функції, такі як WithValues або WithName, у своїх компонентах, то записи в журнал міститимуть додаткову інформацію, яка передається у функції своїм абонентам.

Для Kubernetes Kubernetes 1.31, це керується через функціональну можливість ContextualLogging, що є типово увімкненою. Інфраструктура для цього була додана в 1.24 без модифікації компонентів. Команда component-base/logs/example показує, як використовувати нові виклики ведення логів та як компонент поводиться, якщо він підтримує контекстне ведення логів.

$ cd $GOPATH/src/k8s.io/kubernetes/staging/src/k8s.io/component-base/logs/example/cmd/
$ go run . --help
...
      --feature-gates mapStringBool  Набір пар ключ=значення, які описують feature gate для експериментальних функцій. Опції:
                                     AllAlpha=true|false (ALPHA - стандартно=false)
                                     AllBeta=true|false (BETA - стандартно=false)
                                     ContextualLogging=true|false (BETA - default=true)
$ go run . --feature-gates ContextualLogging=true
...
I0222 15:13:31.645988  197901 example.go:54] "runtime" logger="example.myname" foo="bar" duration="1m0s"
I0222 15:13:31.646007  197901 example.go:55] "another runtime" logger="example" foo="bar" duration="1h0m0s" duration="1m0s"

Ключ logger та foo="bar" були додані абонентом функції, яка записує повідомлення runtime та значення duration="1m0s", без необхідності модифікувати цю функцію.

Коли контекстне ведення логів вимкнене, функції WithValues та WithName нічого не роблять, а виклики ведення логів пройшли через глобальний реєстратор klog. Отже, ця додаткова інформація більше не виводиться в журнал:

$ go run . --feature-gates ContextualLogging=false
...
I0222 15:14:40.497333  198174 example.go:54] "runtime" duration="1m0s"
I0222 15:14:40.497346  198174 example.go:55] "another runtime" duration="1h0m0s" duration="1m0s"

Формат логу у форматі JSON

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.19 [alpha]

Прапорець --logging-format=json змінює формат логу з власного формату klog на формат JSON. Приклад формату логу у форматі JSON (форматований для зручності):

{
   "ts": 1580306777.04728,
   "v": 4,
   "msg": "Pod status updated",
   "pod":{
      "name": "nginx-1",
      "namespace": "default"
   },
   "status": "ready"
}

Ключі з особливим значенням:

  • ts — відмітка часу у форматі Unix (обовʼязково, дійсне число)
  • v — деталізація (тільки для інформаційних повідомлень, а не для повідомлень про помилки, ціле число)
  • err — рядок помилки (необовʼязково, рядок)
  • msg — повідомлення (обовʼязково, рядок)

Список компонентів, що наразі підтримують формат JSON:

Рівень деталізації логів

Прапорець -v керує рівнем деталізації логу. Збільшення значення збільшує кількість зареєстрованих подій. Зменшення значення зменшує кількість зареєстрованих подій. Збільшення рівнів деталізації записує все менш важливі події. На рівні деталізації 0 журнал реєструє лише критичні події.

Розташування логів

Існують два типи системних компонентів: ті, які працюють у контейнері, та ті, які не працюють у контейнері. Наприклад:

На машинах з systemd, kubelet та середовище виконання контейнерів записують логи в journald. В іншому випадку вони записуються в файли .log в теці /var/log. Системні компоненти всередині контейнерів завжди записуються в файли .log у теці /var/log, обходячи типовий механізм ведення логу. Аналогічно логам контейнерів, вам слід регулярно виконувати ротацію логів системних компонентів у теці /var/log. У кластерах Kubernetes, створених сценарієм kube-up.sh, ротація логів налаштована за допомогою інструменту logrotate. Інструмент logrotate виконує ротацію логів щоденно або якщо розмір логу перевищує 100 МБ.

Отримання логів

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.30 [beta]

Для допомоги у розвʼязанні проблем на вузлах Kubernetes версії v1.27 введено функцію, яка дозволяє переглядати логи служб, що працюють на вузлі. Щоб скористатися цією функцією, переконайтеся, що для цього вузла увімкнути функціональну можливість NodeLogQuery, а також що параметри конфігурації kubelet enableSystemLogHandler та enableSystemLogQuery обидва встановлені в значення true. На Linux ми припускаємо, що логи служб доступні через journald. На Windows ми припускаємо, що логи служб доступні в постачальнику логів застосунків. В обох операційних системах логи також доступні за допомогою читання файлів у теці /var/log/.

Якщо у вас є дозвіл на взаємодію з обʼєктами Node, ви можете спробувати цю функцію на всіх ваших вузлах або лише на їх підмножині. Ось приклад отримання логу служби kubelet з вузла:

# Отримати логи kubelet з вузла під назвою node-1.example
kubectl get --raw "/api/v1/nodes/node-1.example/proxy/logs/?query=kubelet"

Ви також можете отримувати файли, за умови, що файли знаходяться в теці, для якої kubelet дозволяє читання логів. Наприклад, ви можете отримати лог з /var/log/ на вузлі Linux:

kubectl get --raw "/api/v1/nodes/<назва-вузла>/proxy/logs/?query=/<назва-файлу-логу>"

Kubelet використовує евристику для отримання логів. Це допомагає, якщо ви не знаєте, чи даний системний сервіс записує логи до стандартного реєстратора операційної системи, такого як journald, чи до файлу логу у /var/log/. Спочатку евристика перевіряє стандартний реєстратор, а якщо його немає, вона намагається отримати перші логи з /var/log/<імʼя-служби> або /var/log/<назва-служби>.log або /var/log/<назва-служби>/<назва-служби>.log.

Повний перелік параметрів, які можна використовувати:

ОпціяОпис
bootпоказує повідомлення про завантаження з певного завантаження системи
patternфільтрує записи логу за заданим регулярним виразом, сумісним з Perl
queryвказує службу(и) або файли, з яких слід повернути логи (обовʼязково)
sinceTimeчас відображення логу, починаючи з RFC3339 (включно)
untilTimeчас до якого показувати логи, за RFC3339 (включно)
tailLinesвказує, скільки рядків з кінця логу отримати; типово отримується весь журнал

Приклад складнішого запиту:

# Отримати логи kubelet з вузла під назвою node-1.example, у яких є слово "error"
kubectl get --raw "/api/v1/nodes/node-1.example/proxy/logs/?query=kubelet&pattern=error"

Що далі

3.11.8 - Трейси для системних компонентів Kubernetes

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.27 [beta]

Трейси системних компонентів реєструють затримку та звʼязки між операціями у кластері.

Компоненти Kubernetes відправляють трейси за допомогою Протоколу OpenTelemetry з експортером gRPC і можуть бути зібрані та направлені до різних систем відслідковування за допомогою OpenTelemetry Collector.

Збір трейсів

Компоненти Kubernetes мають вбудовані експортери gRPC для OTLP для експорту трейсів, або через OpenTelemetry Collector, або без нього.

Для повного посібника зі збору трейсів та використання колектора див. Початок роботи з OpenTelemetry Collector. Однак є кілька речей, на які варто звернути увагу, що є специфічними для компонентів Kubernetes.

Типово компоненти Kubernetes експортують трейси за допомогою експортера grpc для OTLP на порт IANA OpenTelemetry, 4317. Наприклад, якщо колектор працює як sidecar контейнер для компонента Kubernetes, наступна конфігурація приймача збере спани (spans) та відправить їх у стандартний вивід:

receivers:
  otlp:
    protocols:
      grpc:
exporters:
  # Замініть цей експортер на експортер для вашої системи
  logging:
    logLevel: debug
service:
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [logging]

Для безпосереднього надсилання трейсів до бекенду без використання колектора, вкажіть поле endpoint у конфігурації Kubernetes з адресою бекенду. Цей метод усуває потребу в колекторі та спрощує загальну структуру.

Для конфігурації заголовків backend trace, включаючи дані автентифікації, можна використовувати змінні середовища з OTEL_EXPORTER_OTLP_HEADERS, див. Конфігурація Експортера OTLP.

Додатково, для конфігурації атрибутів ресурсів trace, таких як назва кластера Kubernetes, простір імен, імʼя Pod і т. д., також можна використовувати змінні середовища з OTEL_RESOURCE_ATTRIBUTES, див. Ресурс Kubernetes OTLP.

Трейси компонентів

Трейси kube-apiserver

Kube-apiserver генерує спани для вхідних HTTP-запитів та для вихідних запитів до веб-хуків, etcd та повторних запитів. Він передає W3C Trace Context з вихідними запитами, але не використовує контекст трейса, доданий до вхідних запитів, оскільки kube-apiserver часто є загальнодоступною точкою доступу.

Увімкнення трейсів в kube-apiserver

Щоб увімкнути трейси, надайте kube-apiserver файл конфігурації тресів з --tracing-config-file=<шлях-до-конфігу>. Це приклад конфігурації, яка записує спани для 1 з 10000 запитів та використовує типову точку доступу OpenTelemetry:

apiVersion: apiserver.config.k8s.io/v1beta1
kind: TracingConfiguration
# типове значення
#endpoint: localhost:4317
samplingRatePerMillion: 100

Для отримання додаткової інформації про структуру TracingConfiguration, див. API сервера конфігурації (v1beta1).

Трейси kubelet

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.27 [beta]

Інтерфейс CRI kubelet та автентифіковані http-сервери інструментовані для генерації спанів трейсів. Як і apiserver, адресу та частоту зразків можна налаштувати. Контекст трейсів також налаштований. Рішення про зразок батьківського спану завжди береться до уваги. Частота зразків трейсів, надана в конфігурації, застосовуватиметься до спанів без батьків. Ввімкнено без налаштованої точки доступу, типова адреса приймача OpenTelemetry Collector — "localhost:4317".

Увімкнення трейсів в kubelet

Щоб увімкнути трейси, застосуйте конфігурацію. Це приклад шматка конфігурації kubelet, що записує спани для 1 з 10000 запитів та використовує типову точку доступу OpenTelemetry:

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
featureGates:
  KubeletTracing: true
tracing:
  # типове значення
  #endpoint: localhost:4317
  samplingRatePerMillion: 100

Якщо samplingRatePerMillion встановлено на мільйон (1000000), то кожен спан буде відправлений до експортера.

Kubelet у Kubernetes v1.31 збирає спани зі збирання сміття, процесів синхронізації Podʼів, а також кожного методу gRPC. Kubelet передає контекст трейсів із запитами gRPC, щоб контейнерні середовища з інструментованими трейсами, такі як CRI-O та containerd, могли асоціювати їх експортовані спани з контекстом трейсів від kubelet. Отримані трейси будуть мати посилання батько-дитина між спанами kubelet та контейнерним середовищем, надаючи корисний контекст при налагодженні вузла.

Зверніть увагу, що експортування спанів завжди супроводжується невеликим перевантаженням мережі та CPU, залежно від загальної конфігурації системи. Якщо в кластері, в якому увімкнено трейси, виникає будь-яка проблема, така як ця, то помʼякшіть проблему шляхом зменшення samplingRatePerMillion або повністю вимкніть трейси, видаливши конфігурацію.

Стабільність

Інструментування трейсів все ще перебуває в активній розробці та може змінюватися різними способами. Це стосується назв спанів, приєднаних атрибутів, інструментованих точок доступу та інших. До того часу, поки ця функція не стане стабільною, не надається жодних гарантій зворотної сумісності для інструментів трейсів.

Що далі

3.11.9 - Проксі у Kubernetes

На цій сторінці пояснюються проксі, що використовуються з Kubernetes.

Проксі

У вас можуть зустрітися декілька різних проксі, коли ви використовуєте Kubernetes:

  1. Проксі kubectl:

    • працює на робочому столі користувача або в контейнері
    • забезпечує проксі з локальної адреси до apiserver Kubernetes
    • клієнт до проксі використовує HTTP
    • проксі до apiserver використовує HTTPS
    • знаходить apiserver
    • додає заголовки автентифікації
  2. Проксі apiserver:

    • є бастіоном, вбудованим в apiserver
    • зʼєднує користувача поза кластером з IP-адресами кластера, які інакше можуть бути недоступними
    • працює в процесах apiserver
    • клієнт до проксі використовує HTTPS (або http, якщо apiserver налаштовано так)
    • проксі до цілі може використовувати HTTP або HTTPS, як вибрав проксі за наявною інформацією
    • може бути використаний для доступу до Node, Pod або Service
    • виконує балансування навантаження при використанні для доступу до Service
  3. kube proxy:

    • працює на кожному вузлі
    • забезпечує проксі UDP, TCP та SCTP
    • не розуміє HTTP
    • надає балансування навантаження
    • використовується лише для доступу до Service
  4. Проксі/балансувальник перед apiserver(s):

    • існування та реалізація різниться від кластера до кластера (наприклад, nginx)
    • розташований між всіма клієнтами та одним або кількома apiservers
    • діє як балансувальник навантаження, якщо є кілька apiservers.
  5. Хмарні балансувальники навантаження на зовнішньому Service:

    • надаються деякими хмарними провайдерами (наприклад, AWS ELB, Google Cloud Load Balancer)
    • створюються автоматично, коли у Service Kubernetes тип — LoadBalancer
    • зазвичай підтримують лише UDP/TCP
    • підтримка SCTP залежить від реалізації балансувальника навантаження хмарного провайдера
    • реалізація відрізняється від провайдера хмарних послуг.

Зазвичай користувачі Kubernetes не повинні турбуватися про щось, крім перших двох типів. Зазвичай адміністратор кластера забезпечує правильне налаштування останніх типів.

Запит на перенаправлення

Проксі замінили можливості перенаправлення. Перенаправлення були визнані застарілими.

3.11.10 - API Priority та Fairness

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.29 [stable]

Контроль поведінки сервера API Kubernetes у ситуації перевантаження є основним завданням для адміністраторів кластера. У kube-apiserver є деякі елементи керування (тобто прапорці командного рядка --max-requests-inflight та --max-mutating-requests-inflight), щоб обмежити обсяг невиконаної роботи, яка буде прийнята, запобігаючи перевантаженню потоку вхідних запитів та потенційному збою сервера API, але цих прапорців недостатньо для забезпечення проходження найважливіших запитів у період високого навантаження.

Елементи API Priority та Fairness (APF) є альтернативою, яка покращує зазначені обмеження щодо максимального числа невиконаних завдань. APF класифікує та ізолює запити більш деталізованим способом. Вони також вводять обмеження на черги, щоб ніякі запити не були відхилені в разі дуже коротких вибухів. Запити надсилаються з черг за допомогою техніки справедливих черг, так що, наприклад, контролер, який погано поводиться не має вичерпати інші ресурси (навіть на тому ж рівні пріоритету).

Ця функція розроблена для співпраці зі стандартними контролерами, які використовують інформатори та реагують на невдачі запитів API з експоненційним збільшенням часу очікування, та іншими клієнтами, які також працюють таким чином.

Увімкнення/вимкнення API Priority та Fairness

API Priority та Fairness контролюється прапорцем командного рядка та є типово увімкненим. Див. Опції для загального пояснення доступних опцій командного рядка kube-apiserver та того, як їх увімкнути та вимкнути. Назва параметра командного рядка для APF — "--enable-priority-and-fairness". Ця функція також включає API Group, яка має: (a) стабільну версію v1, введена у версії 1.29, і типово увімкнена, (b) версію v1beta3, типово увімкнена та застаріла у версії v1.29. Ви можете вимкнути бета-версію групи API v1beta3, додавши наступні параметри командного рядка до запуску kube-apiserver:

kube-apiserver \
--runtime-config=flowcontrol.apiserver.k8s.io/v1beta3=false \
 # …і інші прапорці, як завжди

Параметр командного рядка --enable-priority-and-fairness=false вимкне API Priority та Fairness.

Рекурсивні сценарії сервера

API Priority and Fairness повинні використовуватися обережно в рекурсивних сценаріях сервера. Це сценарії, в яких сервер A, обробляючи запит, надсилає допоміжний запит на сервер B. Можливо, сервер B може навіть зробити подальший допоміжний виклик назад до сервера A. У ситуаціях, коли контроль Пріоритету і Справедливості застосовується як до оригінального запиту, так і до деяких допоміжних, незалежно від глибини рекурсії, існує небезпека пріоритетних інверсій та/або взаємоблокувань.

Прикладом рекурсії є випадок, коли kube-apiserver робить виклик admission webhook на сервер B, і під час обробки цього виклику сервер B робить подальший допоміжний запит назад до kube-apiserver. Інший приклад рекурсії — коли обʼєкт APIService спрямовує kube-apiserver делегувати запити щодо певної групи API на власний зовнішній сервер B користувача (це один з аспектів, які називаються "агрегацією").

Коли відомо, що оригінальний запит належить до певного рівня пріоритету, і допоміжні контрольовані запити класифікуються на вищі рівні пріоритету, це може бути одним з можливих рішень. Коли оригінальні запити можуть належати до будь-якого рівня пріоритету, допоміжні контрольовані запити повинні бути звільнені від обмежень Priority and Fairness. Один із способів це зробити — за допомогою обʼєктів, які налаштовують класифікацію та обробку, обговорених нижче. Інший спосіб — повністю відключити Priority and Fairness на сервері B, використовуючи техніки, обговорені вище. Третій спосіб, який найпростіше використовувати, коли сервер B не є kube-apiserver, це побудувати сервер B з відключеним у коді Priority and Fairness.

Концепції

API Priority та Fairness включає кілька різних функцій. Вхідні запити класифікуються за атрибутами запиту за допомогою FlowSchemas, і призначаються пріоритетним рівням. Пріоритетні рівні додають ступінь ізоляції, підтримуючи окремі обмеження паралелізму, так що запити, які призначені для різних пріоритетних рівнів, не можуть позбавляти ресурсів один одного. У межах пріоритетного рівня алгоритм справедливого чергування не дозволяє запитам з різних потоків позбавляти ресурсів один одного, і дозволяє чергувати запити, щоб запобігти відмовам від запитів у випадках, коли середнє навантаження прийнятно низьке.

Рівні пріоритету

Без увімкненої функції APF загальний паралелізм в API-сервері обмежується прапорцями --max-requests-inflight та --max-mutating-requests-inflight у kube-apiserver. З увімкненою функцією APF ліміти паралелізму, визначені цими прапорцями, сумуються, а потім сума розподіляється серед налаштованого набору рівнів пріоритету. Кожен вхідний запит призначається одному з рівнів пріоритету, і кожен рівень пріоритету буде обробляти лише стільки одночасних запитів, скільки дозволяє його конкретний ліміт.

Наприклад, у типовій конфігурації існують окремі рівні пріоритету для запитів на вибір лідера, запитів від вбудованих контролерів і запитів від Podʼів. Це означає, що Podʼи, які поводяться погано і завалюють API-сервер запитами, не можуть перешкодити вибору лідера або виконанню дій вбудованими контролерами.

Межі паралелізму рівнів пріоритету періодично коригуються, що дозволяє недостатньо використовуваним рівням пріоритету тимчасово надавати паралелізм сильно використовуваних рівнів. Ці обмеження базуються на номінальних обмеженнях та межах того, скільки паралелізму може позичити рівень пріоритету та скільки він може позичити, всі отримані з обʼєктів конфігурації, згаданих нижче.

Місця, зайняті за запитом

Наведений вище опис управління паралелізмом є базовою поведінкою. Запити мають різну тривалість, але враховуються однаково в будь-який момент при порівнянні з лімітом паралелізму на рівні пріоритету. У базовій поведінці кожен запит займає одну одиницю паралелізму. Слово "місце" (seat) використовується для позначення однієї одиниці паралелізму, під впливом від того, як кожен пасажир у поїзді або літаку займає одне з фіксованих місць.

Але деякі запити займають більше, ніж одне місце. Деякі з них — це запити list, які сервер оцінює, що повертають велику кількість обʼєктів. Вони виявилися надзвичайно важкою ношею для сервера. З цієї причини сервер оцінює кількість обʼєктів, які будуть повернуті, і вважає, що запит займає кількість місць, пропорційну цій оцінці.

Коригування часу виконання для запитів watch

API Priority та Fairness керує запитами watch, але це передбачає ще кілька відступів від базової поведінки. Перше стосується того, як довго запит watch вважається таким, що займає своє місце. Залежно від параметрів запиту, відповідь на запит на watch може або не може розпочинатися зі сповіщень create для всіх відповідних попередніх обʼєктів. API Priority та Fairness вважає, що запит watch завершено зі своїм місцем, як тільки цей початковий вибух сповіщень, якщо такі є, закінчився.

Нормальні сповіщення надсилаються у паралельному сплеску на всі потрібні потоки відповіді на watch, коли сервер отримує сповіщення про створення/оновлення/видалення обʼєкта. Для врахування цієї роботи API Priority та Fairness вважає, що кожен записний запит витрачає додатковий час, займаючи місця після завершення фактичного запису. Сервер оцінює кількість сповіщень, які будуть надіслані, і коригує кількість місць та час зайнятості місця для записного запиту, щоб врахувати цю додаткову роботу.

Черги

Навіть на рівні пріоритету може бути велика кількість різних джерел трафіку. У ситуації перевантаження важливо запобігти тому, щоб один потік вичерпував ресурси інших (зокрема, у відносно поширеному випадку, коли один помилковий клієнт переповнює kube-apiserver запитами, цей помилковий клієнт в ідеалі взагалі не мав би помітного впливу на інших клієнтів). Це обробляється за допомогою алгоритму справедливої черги для обробки запитів, яким присвоєно однаковий рівень пріоритету. Кожен запит присвоюється потоку, ідентифікованому за назвою відповідної FlowSchema плюс розрізнювач потоку - який є або запитуючим користувачем, або простором імен цільового ресурсу, або нічим - і система намагається надати приблизно однакову вагу запитам у різних потоках одного і того ж рівня пріоритету. Щоб забезпечити чітку обробку різних екземплярів, контролери, які мають багато екземплярів, повинні автентифікуватися за допомогою різних імен користувачів

Це забезпечується за допомогою алгоритму справедливих черг обробки запитів, які призначені для того ж рівня пріоритету. Кожен запит призначається для потоку, ідентифікованого імʼям відповідного FlowSchema плюс розрізнювач потоку — яким є або користувач-абонент, або простір імен цільового ресурсу, або нічого — і система намагається надати приблизно рівну вагу запитам в різних потоках того ж рівня пріоритету.

Після класифікації запиту у потік, API Priority та Fairness може призначити запит до черги. Це призначення використовує техніку, відому як shuffle sharding, яка досить ефективно використовує черги для ізоляції потоків низької інтенсивності від потоків високої інтенсивності.

Деталі алгоритму черг налаштовуються для кожного рівня пріоритету і дозволяють адміністраторам збалансувати використання памʼяті, справедливість (властивість того, що незалежні потоки всі рухатимуться вперед, коли загальний трафік перевищує потужність), толерантність до бурхливого трафіку та доданий час очікування, що виникає через черги.

Ексклюзивні запити

Деякі запити вважаються достатньо важливими, щоб не підлягати жодним обмеженням, які накладає ця функція. Ці винятки запобігають тому, щоб неправильно налаштована конфігурація керування потоком повністю вимкнула API-сервер.

Ресурси

API керування потоком включає два види ресурсів. Конфігурації рівня пріоритету визначають доступні рівні пріоритету, частку доступного бюджету паралелізму, яку кожен може обробити, та дозволяють налаштовувати поведінку черги. FlowSchemas використовуються для класифікації окремих вхідних запитів, відповідність кожного з PriorityLevelConfiguration.

PriorityLevelConfiguration

PriorityLevelConfiguration представляє один рівень пріоритету. Кожен PriorityLevelConfiguration має незалежні обмеження на кількість невиконаних запитів та обмеження на кількість запитів у черзі.

Номінальне обмеження паралелізму для PriorityLevelConfiguration не визначається в абсолютній кількості місць, а в "номінальних частках паралелізму". Загальне обмеження паралелізму для API-сервера розподіляється серед наявних конфігурацій рівня пріоритету пропорційно цим часткам, щоб кожен рівень отримав своє номінальне обмеження у вигляді місць. Це дозволяє адміністратору кластера збільшувати або зменшувати загальний обсяг трафіку до сервера, перезапускаючи kube-apiserver з іншим значенням для --max-requests-inflight (або --max-mutating-requests-inflight), і всі PriorityLevelConfiguration побачать, що їх максимально допустимий паралелізм збільшиться (або зменшиться) на ту саму частку.

Межі того, скільки паралелізму може надати рівень пріоритету та скільки він може позичити, виражені в PriorityLevelConfiguration у відсотках від номінального обмеження рівня. Ці значення перетворюються на абсолютні числа місць, множачи їх на номінальне обмеження / 100.0 та округлюючи. Динамічно кориговане обмеження паралелізму рівня пріоритету обмежене нижньою межею його номінального обмеження мінус кількість місць, які він може позичити, та верхньою межею його номінального обмеження плюс місця, які він може позичити. Під час кожного налаштування динамічні межі визначаються кожним рівнем пріоритету, відновлюючи будь-які позичені місця, на які востаннє зʼявлявся попит, та спільно відповідаючи на попит за місцями на рівнях пріоритету в межах вищезазначених меж.

Коли обсяг вхідних запитів, які призначені для одного PriorityLevelConfiguration, перевищує його дозволений рівень паралелізму, поле type його специфікації визначає, що відбудеться з додатковими запитами. Тип Reject означає, що зайвий трафік буде негайно відхилено з помилкою HTTP 429 (Too Many Requests). Тип Queue означає, що запити, які перевищують поріг, будуть ставитися у чергу, із використанням технік випадкового розміщення та справедливої черги для збалансування прогресу між потоками запитів.

Конфігурація черги дозволяє налаштувати алгоритм справедливої черги для рівня пріоритету. Деталі алгоритму можна знайти у пропозиції про вдосконалення, ось скорочено:

  • Збільшення queues зменшує швидкість зіткнень між різними потоками, коштом збільшення використання памʼяті. Значення 1 тут фактично вимикає логіку справедливої черги, але все ще дозволяє ставити запити в чергу.

  • Збільшення queueLengthLimit дозволяє підтримувати більші потоки трафіку без відкидання будь-яких запитів, коштом збільшення затримки та використання памʼяті.

  • Зміна handSize дозволяє вам налаштувати ймовірність зіткнень між різними потоками та загальний паралелізм, доступний для одного потоку в ситуації перевантаження.

Нижче наведена таблиця з цікавою колекцією конфігурацій випадкового розміщення, що показує для кожної ймовірність те, що певна миша (потік низької інтенсивності) буде розчавлена слонами (потоками високої інтенсивності) для ілюстративної колекції числа слонів. Див. https://play.golang.org/p/Gi0PLgVHiUg, який обчислює цю таблицю.

Приклади конфігурацій випадкового розміщення
HandSizeЧерги1 слон4 слони16 слонів
12324.428838398950118e-090.114313488300991440.9935089607656024
10321.550093439632541e-080.06264798402235450.9753101519027554
10646.601827268370426e-120.000455713209903707760.49999929150089345
9643.6310049976037345e-110.000455012123041122730.4282314876454858
8642.25929199850899e-100.00048866970530404460.35935114681123076
81286.994461389026097e-133.4055790161620863e-060.02746173137155063
71281.0579122850901972e-116.960839379258192e-060.02406157386340147
72567.597695465552631e-146.728547142019406e-080.0006709661542533682
62562.7134626662687968e-122.9516464018476436e-070.0008895654642000348
65124.116062922897309e-144.982983350480894e-092.26025764343413e-05
610246.337324016514285e-168.09060164312957e-114.517408062903668e-07

FlowSchema

FlowSchema — це визначення, яке відповідає деяким вхідним запитам і призначає їх певному рівню пріоритету. Кожний вхідний запит перевіряється на відповідність FlowSchemas, починаючи з тих, що мають найменше числове значення matchingPrecedence, і працюючи вгору. Перший збіг перемагає.

FlowSchema відповідає даному запиту, якщо принаймні одне з rules має збіг. Правило має збіг, якщо принаймні один з його subjects та принаймні один з його resourceRules або nonResourceRules (залежно від того, чи є вхідний запит для ресурсу, чи нересурсного URL) відповідає запиту.

Для поля name в підсумках та полів verbs, apiGroups, resources, namespaces та nonResourceURLs правил ресурсів та нересурсних правил можна вказати маску *, щоб відповідати всім значенням для вказаного поля, яке фактично видаляє його з використання.

Тип distinguisherMethod.type FlowSchema визначає, як запити, які відповідають цій схемі, будуть розділені на потоки. Це може бути ByUser, коли один користувач має можливість позбавити інших користувачів можливості використовувати ресурси; ByNamespace, коли запити до ресурсів в одному просторі імен не можуть позбавити запити до ресурсів в інших просторах імен можливості використовувати їх; або порожнє значення (або distinguisherMethod може бути пропущений повністю), коли всі запити, які відповідають цій FlowSchema, будуть вважатися частиною одного потоку. Правильний вибір для даної FlowSchema залежить від ресурсу та вашого конкретного середовища.

Стандартні

Кожен kube-apiserver підтримує два різновиди обʼєктів API Priority та Fairnes: обовʼязкові та рекомендовані.

Обовʼязкові обʼєкти конфігурації

Чотири обовʼязкові обʼєкти конфігурації відображають фіксовану вбудовану поведінку обмежень безпеки. Це поведінка, яку сервери мають до того, як ці обʼєкти почнуть існувати, і коли ці обʼєкти існують, їх специфікації відображають цю поведінку. Чотири обовʼязкові обʼєкти є такими:

  • Обовʼязковий пріоритетний рівень exempt використовується для запитів, які взагалі не підлягають контролю потоку: вони завжди будуть надсилатися негайно. Обовʼязкова FlowSchema exempt класифікує всі запити з групи system:masters у цей рівень пріоритету. Ви можете визначити інші FlowSchemas, які направляють інші запити на цей рівень пріоритету, якщо це доцільно.

  • Обовʼязковий пріоритетний рівень catch-all використовується в поєднанні з обовʼязковою FlowSchema catch-all, щоб переконатися, що кожен запит отримує якийсь вид класифікації. Зазвичай ви не повинні покладатися на цю універсальну catch-all конфігурацію і повинні створити свою власну FlowSchema та PriorityLevelConfiguration для обробки всіх запитів. Оскільки очікується, що він не буде використовуватися нормально, обовʼязковий рівень пріоритету catch-all має дуже невелику частку паралелізму і не ставить запити в чергу.

Рекомендовані обʼєкти конфігурації

Рекомендовані FlowSchema та PriorityLevelConfigurations складають обґрунтовану типову конфігурацію. Ви можете змінювати їх або створювати додаткові обʼєкти конфігурації за необхідності. Якщо ваш кластер може зазнати високого навантаження, то варто розглянути, яка конфігурація працюватиме краще.

Рекомендована конфігурація групує запити в шість рівнів пріоритету:

  • Рівень пріоритету node-high призначений для оновлень стану вузлів.

  • Рівень пріоритету system призначений для запитів, які не стосуються стану справності, з групи system:nodes, тобто Kubelets, які повинні мати можливість звʼязатися з сервером API, щоб завдання могли плануватися на них.

  • Рівень пріоритету leader-election призначений для запитів на вибір лідера від вбудованих контролерів (зокрема, запити на endpoints, configmaps або leases, що надходять від користувачів та облікових записів служб з групи system:kube-controller-manager або system:kube-scheduler в просторі імен kube-system). Ці запити важливо ізолювати від іншого трафіку, оскільки невдачі у виборі лідера призводять до збоїв їх контролерів і перезапуску, що в свою чергу призводить до більших витрат трафіку, оскільки нові контролери синхронізують свої сповіщувачі.

  • Рівень пріоритету workload-high призначений для інших запитів від вбудованих контролерів.

  • Рівень пріоритету workload-low призначений для запитів від будь-якого іншого облікового запису служби, що зазвичай включає всі запити від контролерів, що працюють в капсулах.

  • Рівень пріоритету global-default обробляє весь інший трафік, наприклад, інтерактивні команди kubectl, запущені непривілейованими користувачами.

Рекомендовані FlowSchema служать для направлення запитів на вищезазначені рівні пріоритету, і тут вони не перераховані.

Підтримка обовʼязкових та рекомендованих обʼєктів конфігурації

Кожен kube-apiserver незалежно підтримує обовʼязкові та рекомендовані обʼєкти конфігурації, використовуючи початкову та періодичну поведінку. Отже, в ситуації з сумішшю серверів різних версій може відбуватися турбулентність, поки різні сервери мають різні погляди на відповідний вміст цих обʼєктів.

Кожен kube-apiserver робить початковий обхід обовʼязкових та рекомендованих обʼєктів конфігурації, а після цього здійснює періодичну обробку (один раз на хвилину) цих обʼєктів.

Для обовʼязкових обʼєктів конфігурації підтримка полягає в тому, щоб забезпечити наявність обʼєкта та, якщо він існує, мати правильну специфікацію. Сервер відмовляється дозволити створення або оновлення зі специфікацією, яка не узгоджується з поведінкою огородження сервера.

Підтримка рекомендованих обʼєктів конфігурації призначена для того, щоб дозволити перевизначення їх специфікації. Видалення, з іншого боку, не враховується: підтримка відновить обʼєкт. Якщо вам не потрібен рекомендований обʼєкт конфігурації, то вам потрібно залишити його, але встановити його специфікацію так, щоб мінімально впливати на систему. Підтримка рекомендованих обʼєктів також призначена для підтримки автоматичної міграції при виході нової версії kube-apiserver, хоча, можливо, з турбулентністю при змішаній популяції серверів.

Підтримка рекомендованого обʼєкта конфігурації включає його створення, зі специфікацією, яку пропонує сервер, якщо обʼєкт не існує. З іншого боку, якщо обʼєкт вже існує, поведінка підтримка залежить від того, чи контролюють обʼєкт kube-apiservers чи користувачі. У першому випадку сервер забезпечує, що специфікація обʼєкта відповідає тому, що пропонує сервер; у другому випадку специфікація залишається без змін.

Питання про те, хто контролює обʼєкт, вирішується спочатку шляхом пошуку анотації з ключем apf.kubernetes.io/autoupdate-spec. Якщо така анотація є і її значення true, то обʼєкт контролюється kube-apiservers. Якщо така анотація існує і її значення false, то обʼєкт контролюють користувачі. Якщо жодна з цих умов не виконується, тоді перевіряється metadata.generation обʼєкта. Якщо вона дорівнює 1, то обʼєкт контролюють kube-apiservers. В іншому випадку обʼєкт контролюють користувачі. Ці правила були введені у версії 1.22, і врахування ними metadata.generation призначена для міграції з більш простої попередньої поведінки. Користувачі, які хочуть контролювати рекомендований обʼєкт конфігурації, повинні встановити анотацію apf.kubernetes.io/autoupdate-spec в false.

Підтримка обовʼязкового або рекомендованого обʼєкта конфігурації також включає забезпечення наявності анотації apf.kubernetes.io/autoupdate-spec, яка точно відображає те, чи контролюють kube-apiservers обʼєкт.

Підтримка також включає видалення обʼєктів, які не є обовʼязковими або рекомендованими, анотованих як apf.kubernetes.io/autoupdate-spec=true.

Звільнення від паралелізму перевірки справності

Запропонована конфігурація не надає спеціального поводження запитам на перевірку стану здоровʼя на kube-apiservers від їхніх локальних kubelets, які зазвичай використовують захищений порт, але не надають жодних облікових даних. Запити цього типу вказаної конфігурації призначаються до FlowSchema global-default і відповідного пріоритетного рівня global-default, де інші запити можуть їх перенавантажувати.

Якщо ви додасте наступний додатковий FlowSchema, це звільнить ці запити від обмежень.

apiVersion: flowcontrol.apiserver.k8s.io/v1
kind: FlowSchema
metadata:
  name: health-for-strangers
spec:
  matchingPrecedence: 1000
  priorityLevelConfiguration:
    name: exempt
  rules:
    - nonResourceRules:
      - nonResourceURLs:
          - "/healthz"
          - "/livez"
          - "/readyz"
        verbs:
          - "*"
      subjects:
        - kind: Group
          group:
            name: "system:unauthenticated"

Спостережуваність

Метрики

Після увімкнення функції API Priority та Fairness, kube-apiserver експортує додаткові метрики. Моніторинг цих метрик може допомогти вам визначити, чи правильно ваша конфігурація обробляє важливий трафік, або знайти проблемні робочі навантаження, які можуть шкодити справності системи.

Рівень зрілості BETA

  • apiserver_flowcontrol_rejected_requests_total — це вектор лічильника (накопичувальний з моменту запуску сервера) запитів, які були відхилені, розбитий за мітками flow_schema (показує той, який підходить до запиту), priority_level (показує той, до якого був призначений запит) і reason. Мітка reason буде мати одне з наступних значень:

    • queue-full, що вказує на те, що занадто багато запитів вже було в черзі.
    • concurrency-limit, що вказує на те, що конфігурація PriorityLevelConfiguration налаштована відхиляти замість того, щоб ставити в чергу зайві запити.
    • time-out, що вказує на те, що запит все ще перебував в черзі, коли його обмеження часу в черзі закінчилося.
    • cancelled, що вказує на те, що запит не закріплений і викинутий з черги.
  • apiserver_flowcontrol_dispatched_requests_total — це вектор лічильника (накопичувальний з моменту запуску сервера) запитів, які почали виконуватися, розбитий за flow_schema та priority_level.

  • apiserver_flowcontrol_current_inqueue_requests — це вектор мітки миттєвого числа запитів, які знаходяться в черзі (не виконуються), розбитий за priority_level та flow_schema.

  • apiserver_flowcontrol_current_executing_requests — це вектор мітки миттєвого числа виконуваних (не очікуючих в черзі) запитів, розбитий за priority_level та flow_schema.

  • apiserver_flowcontrol_current_executing_seats — це вектор мітки миттєвого числа зайнятих місць, розбитий за priority_level та flow_schema.

  • apiserver_flowcontrol_request_wait_duration_seconds — це вектор гістограми того, скільки часу запити провели в черзі, розбитий за мітками flow_schema, priority_level та execute. Мітка execute вказує, чи почалося виконання запиту.

  • apiserver_flowcontrol_nominal_limit_seats — це вектор вектор, що містить номінальну межу паралелізму кожного рівня пріоритету, обчислювану з загального ліміту паралелізму сервера API та налаштованих номінальних спільних ресурсів паралелізму рівня пріоритету.

Рівень зрілості ALPHA

  • apiserver_current_inqueue_requests — це вектор вимірювання останніх найвиших значень кількості запитів, обʼєднаних міткою request_kind, значення якої можуть бути mutating або readOnly. Ці величини описують найбільше значення спостереження в односекундному вікні процесів, що недавно завершилися. Ці дані доповнюють старий графік apiserver_current_inflight_requests, що містить високу точку кількості запитів в останньому вікні, які активно обслуговуються.

  • apiserver_current_inqueue_seats — це вектор мітки миттєвого підсумку запитів, які будуть займати найбільшу кількість місць, згрупованих за мітками з назвами flow_schema та priority_level.

  • apiserver_flowcontrol_read_vs_write_current_requests — це гістограма спостережень, зроблених в кінці кожної наносекунди, кількості запитів, розбита за мітками phase (приймає значення waiting та executing) та request_kind (приймає значення mutating та readOnly). Кожне спостереження є коефіцентом, від 0 до 1, кількості запитів, поділеним на відповідний ліміт кількості запитів (обмеження обсягу черги для очікування та обмеження паралелізму для виконання).

  • apiserver_flowcontrol_request_concurrency_in_use — це вектор мітки миттєвого числа зайнятих місць, розбитий за priority_level та flow_schema.

  • apiserver_flowcontrol_priority_level_request_utilization — це гістограма спостережень, зроблених в кінці кожної наносекунди, кількості запитів, розбита за мітками phase (яка приймає значення waiting та executing) та priority_level. Кожне спостереження є відношенням, від 0 до 1, кількості запитів поділеної на відповідний ліміт кількості запитів (обмеження обсягу черги для очікування та обмеження паралелізму для виконання).

  • apiserver_flowcontrol_priority_level_seat_utilization — це гістограма спостережень, зроблених в кінці кожної наносекунди, використання обмеження пріоритету паралелізму, розбита за priority_level. Це використання є часткою (кількість зайнятих місць) / (обмеження паралелізму). Цей показник враховує всі етапи виконання (як нормальні, так і додаткові затримки в кінці запису для відповідного сповіщення про роботу) всіх запитів, крім WATCH; для них він враховує лише початковий етап, що доставляє сповіщення про попередні обʼєкти. Кожна гістограма в векторі також має мітку phase: executing (для фази очікування не існує обмеження на кількість місць).

  • apiserver_flowcontrol_request_queue_length_after_enqueue — це гістограма вектора довжини черги для черг, розбита за priority_level та flow_schema, як вибірка за запитом у черзі. Кожен запит, який потрапив в чергу, вносить один зразок в свою гістограму, що вказує довжину черги негайно після додавання запиту. Зверніть увагу, що це дає інші показники, ніж неупереджене опитування.

  • apiserver_flowcontrol_request_concurrency_limit такий же, як apiserver_flowcontrol_nominal_limit_seats. До введення пралелізму запозичення між рівнями пріоритету, це завжди дорівнювало apiserver_flowcontrol_current_limit_seats (який не існував як окремий метричний показник).

  • apiserver_flowcontrol_lower_limit_seats — це вектор мітки миттєвої нижньої межі динамічного обмеження паралелізму для кожного рівня пріоритету.

  • apiserver_flowcontrol_upper_limit_seats — це вектор мітки миттєвої верхньої межі динамічного обмеження паралелізму для кожного рівня пріоритету.

  • apiserver_flowcontrol_demand_seats — це гістограма вектора підрахунку спостережень, в кінці кожної наносекунди, відношення кожного рівня пріоритету до (вимоги місць) / (номінального обмеження паралелізму). Вимога місць на рівні пріоритету — це сума, як віконаних запитів, так і тих, які перебувають у початковій фазі виконання, максимум кількості зайнятих місць у початкових та кінцевих фазах виконання запиту.

  • apiserver_flowcontrol_demand_seats_high_watermark — це вектор мітки миттєвого максимального запиту на місця, що спостерігався протягом останнього періоду адаптації до позичання паралелізму для кожного рівня пріоритету.

  • apiserver_flowcontrol_demand_seats_average - це вектор мітки миттєвого часового середнього значення вимог місць для кожного рівня пріоритету, що спостерігався протягом останнього періоду адаптації до позичання паралелізму.

  • apiserver_flowcontrol_demand_seats_stdev - це вектор мітки миттєвого стандартного відхилення популяції вимог місць для кожного рівня пріоритету, що спостерігався протягом останнього періоду адаптації до позичання паралелізму.

  • apiserver_flowcontrol_demand_seats_smoothed - це вектор мітки миттєвого вирівняного значення вимог місць для кожного рівня пріоритету, визначений на останній період адаптації.

  • apiserver_flowcontrol_target_seats - це вектор мітки миттєвого усередненого значення вимог місць для кожного рівня пріоритету, яке виходить в алокації позичання.

  • apiserver_flowcontrol_seat_fair_frac - це мітка миттєвого значення частки справедливого розподілу, визначеного при останній адаптації позичання.

  • apiserver_flowcontrol_current_limit_seats - це вектор мітки миттєвого динамічного обмеження паралелізму для кожного рівня пріоритету, яке було виведено в останню корекцію.

  • apiserver_flowcontrol_request_execution_seconds - це гістограма, яка показує, скільки часу займає виконання запитів, розбита за flow_schema та priority_level.

  • apiserver_flowcontrol_watch_count_samples - це гістограма вектора кількості активних WATCH-запитів, що стосуються певного запису, розбита за flow_schema та priority_level.

  • apiserver_flowcontrol_work_estimated_seats - це гістограма вектора кількості оцінених місць (максимум початкової та кінцевої стадії виконання) для запитів, розбита за flow_schema та priority_level.

  • apiserver_flowcontrol_request_dispatch_no_accommodation_total - це лічильник вектора кількості подій, які в принципі могли призвести до відправки запиту, але не зробили цього через відсутність доступного паралелізму, розбитий за flow_schema та priority_level.

  • apiserver_flowcontrol_epoch_advance_total - це лічильник вектора кількості спроб зрушити вимірювач прогресу рівня пріоритету назад, щоб уникнути переповнення числових значень, згрупований за priority_level та success.

Поради щодо використання API Priority та Fairness

Коли певний рівень пріоритету перевищує свій дозволений паралелізм, запити можуть зазнавати збільшеного часу очікування або бути відкинуті з HTTP 429 (Забагато запитів) помилкою. Щоб запобігти цим побічним ефектам APF, ви можете змінити ваше навантаження або налаштувати ваші налаштування APF, щоб забезпечити достатню кількість місць для обслуговування ваших запитів.

Щоб виявити, чи відкидаються запити через APF, перевірте наступні метрики:

  • apiserver_flowcontrol_rejected_requests_total — загальна кількість відкинутих запитів за FlowSchema та PriorityLevelConfiguration.
  • apiserver_flowcontrol_current_inqueue_requests — поточна кількість запитів в черзі за FlowSchema та PriorityLevelConfiguration.
  • apiserver_flowcontrol_request_wait_duration_seconds — затримка, додана до запитів, що очікують у черзі.
  • apiserver_flowcontrol_priority_level_seat_utilization — використання місць на рівні пріоритету за PriorityLevelConfiguration.

Зміни в навантаженні

Щоб запобігти встановленню запитів у чергу та збільшенню затримки або їх відкиданню через APF, ви можете оптимізувати ваші запити шляхом:

  • Зменшення швидкості виконання запитів. Менша кількість запитів протягом фіксованого періоду призведе до меншої потреби у місцях в будь-який момент часу.
  • Уникання видачі великої кількості дороговартісних запитів одночасно. Запити можна оптимізувати, щоб вони використовували менше місць або мали меншу затримку, щоб ці запити утримували ці місця протягом коротшого часу. Запити списку можуть займати більше 1 місця в залежності від кількості обʼєктів, отриманих під час запиту. Обмеження кількості обʼєктів, отриманих у запиті списку, наприклад, за допомогою розбиття на сторінки (pagination), буде використовувати менше загальних місць протягом коротшого періоду. Крім того, заміна запитів списку запитами перегляду потребуватиме менше загальних часток паралелізму, оскільки запити перегляду займають лише 1 місце під час свого початкового потоку повідомлень. Якщо використовується потоковий перегляд списків у версіях 1.27 і пізніше, запити перегляду займатимуть таку ж кількість місць, як і запит списку під час його початкового потоку повідомлень, оскільки всі стани колекції мають бути передані по потоку. Зауважте, що в обох випадках запит на перегляд не буде утримувати жодних місць після цієї початкової фази.

Памʼятайте, що встановлення запитів у чергу або їх відкидання через APF можуть бути викликані як збільшенням кількості запитів, так і збільшенням затримки для існуючих запитів. Наприклад, якщо запити, які зазвичай виконуються за 1 секунду, починають виконуватися за 60 секунд, це може призвести до того, що APF почне відкидати запити, оскільки вони займають місця протягом тривалого часу через це збільшення затримки. Якщо APF починає відкидати запити на різних рівнях пріоритету без значного змінення навантаження, можливо, існує проблема з продуктивністю контролера, а не з навантаженням або налаштуваннями APF.

Налаштування Priority та fairness

Ви також можете змінити типові обʼєкти FlowSchema та PriorityLevelConfiguration або створити нові обʼєкти цих типів, щоб краще врахувати ваше навантаження.

Налаштування APF можна змінити для:

  • Надання більшої кількості місць для запитів високого пріоритету.
  • Ізоляція необовʼязкових або дорогих запитів, які можуть забрати рівень паралелізму, якщо він буде спільно використовуватися з іншими потоками.

Надання більшої кількості місць для запитів високого пріоритету

  1. У разі можливості кількість місць, доступних для всіх рівнів пріоритету для конкретного kube-apiserver, можна збільшити, збільшивши значення прапорців max-requests-inflight та max-mutating-requests-inflight. Іншим варіантом є горизонтальне масштабування кількості екземплярів kube-apiserver, що збільшить загальну одночасність на рівень пріоритету по всьому кластеру за умови належного балансування навантаження запитів.
  2. Ви можете створити новий FlowSchema, який посилається на PriorityLevelConfiguration з більшим рівнем паралелізму. Ця нова PriorityLevelConfiguration може бути існуючим рівнем або новим рівнем зі своїм набором номінальних поширень паралелізму. Наприклад, новий FlowSchema може бути введений для зміни PriorityLevelConfiguration для ваших запитів з global-default на workload-low з метою збільшення кількості місць, доступних для ваших користувачів. Створення нової PriorityLevelConfiguration зменшить кількість місць, призначених для існуючих рівнів. Нагадаємо, що редагування типових FlowSchema або PriorityLevelConfiguration потребує встановлення анотації apf.kubernetes.io/autoupdate-spec в значення false.
  3. Ви також можете збільшити значення NominalConcurrencyShares для PriorityLevelConfiguration, що обслуговує ваші запити високого пріоритету. Як альтернативу, для версій 1.26 та пізніших, ви можете збільшити значення LendablePercent для конкуруючих рівнів пріоритету, щоб даний рівень пріоритету мав вищий пул місць, які він може позичати.

Ізоляція неважливих запитів, для попередження виснаження інших потоків

Для ізоляції запитів можна створити FlowSchema, чий субʼєкт збігається з користувачеві, що робить ці запити, або створити FlowSchema, яка відповідає самому запиту (відповідає resourceRules). Далі цю FlowSchema можна зіставити з PriorityLevelConfiguration з низьким пулом місць.

Наприклад, припустимо, що запити на перегляд подій з Podʼів, що працюють в стандартному просторі імен, використовують по 10 місць кожен і виконуються протягом 1 хвилини. Щоб запобігти впливу цих дорогих запитів на інші запити від інших Podʼів, які використовують поточну FlowSchema для сервісних облікових записів, можна застосувати таку FlowSchema для ізоляції цих викликів списків від інших запитів.

Приклад обʼєкта FlowSchema для ізоляції запитів на перегляд подій:

apiVersion: flowcontrol.apiserver.k8s.io/v1
kind: FlowSchema
metadata:
  name: list-events-default-service-account
spec:
  distinguisherMethod:
    type: ByUser
  matchingPrecedence: 8000
  priorityLevelConfiguration:
    name: catch-all
  rules:
    - resourceRules:
      - apiGroups:
          - '*'
        namespaces:
          - default
        resources:
          - events
        verbs:
          - list
      subjects:
        - kind: ServiceAccount
          serviceAccount:
            name: default
            namespace: default
  • FlowSchema захоплює всі виклики списків подій, виконані типовим сервісним обліковим записом у стандартному просторі імен. Пріоритет відповідності 8000 менший за значення 9000, що використовується поточною FlowSchema для сервісних облікових записів, тому ці виклики списків подій будуть відповідати list-events-default-service-account, а не service-accounts.
  • Використовується конфігурація пріоритету catch-all для ізоляції цих запитів. Пріоритетний рівень catch-all має дуже малий пул місць і не ставить запитів в чергу.

Що далі

3.11.11 - Автомасштабування кластера

Автоматичне керування вузлами кластера для адаптації до попиту.

Kubernetes потрібні вузли у вашому кластері для роботи Podʼів. Це означає, що потрібно забезпечити місце для робочих Podʼів та для самого Kubernetes.

Ви можете автоматично налаштувати кількість ресурсів, доступних у вашому кластері: автомасштабування вузлів. Ви можете змінювати кількість вузлів або змінювати потужність, яку надають вузли. Перший підхід називається горизонтальним масштабуванням, а другий — вертикальним масштабуванням.

Kubernetes може навіть забезпечити багатовимірне автоматичне масштабування для вузлів.

Керування вузлами вручну

Ви можете вручну керувати потужністю на рівні вузла, де ви налаштовуєте фіксовану кількість вузлів; ви можете використовувати цей підхід навіть якщо забезпечення (процес встановлення, управління та виведення з експлуатації) для цих вузлів автоматизоване.

Ця сторінка присвячена наступному кроку, а саме автоматизації управління обсягом потужності вузла (ЦП, памʼяті та інших ресурсів вузла), доступним у вашому кластері.

Автоматичне горизонтальне масштабування

Автомасштабувальник

Ви можете використовувати Автомасштабувальник, щоб автоматично керувати масштабуванням ваших вузлів. Автомасштабувальник може інтегруватися з хмарним постачальником або з кластерним API Kubernetes, щоб забезпечити фактичне управління вузлами, яке потрібно.

Автомасштабувальник додає вузли, коли неможливо розмістити потоки, і видаляє вузли, коли ці вузли порожні.

Інтеграції з хмарними постачальниками

README для кластерного масштабувальника містить список деяких доступних інтеграцій з хмарними постачальниками.

Багатовимірне масштабування з урахуванням вартості

Karpenter

Karpenter підтримує пряме керування вузлами через втулки, які інтегруються з конкретними хмарними постачальниками та можуть керувати вузлами для вас, оптимізуючи загальну вартість.

Karpenter автоматично запускає саме ті обчислювальні ресурси, які потрібні вашим застосункам. Його спроєктовано, щоб ви могли повною мірою скористатись можливостями хмари з швидким та простим розгортанням обчислювальних ресурсів для вашого кластера Kubernetes.

Інструмент Karpenter призначений для інтеграції з хмарним постачальником, який надає управління серверами через API, і де інформація про ціни на доступні сервери також доступна через веб-API.

Наприклад, якщо ви маєте декілька Podʼів у вашому кластері, інструмент Karpenter може купити новий вузол, який більший за один з вузлів, які ви вже використовуєте, а потім вимкнути наявний вузол, як тільки новий вузол буде готовий до використання.

Інтеграції з постачальниками хмарних послуг

Існують інтеграції між ядром Karpenter та наступними постачальниками хмарних послуг:

Descheduler

Descheduler може допомогти вам консолідувати Podʼи на меншій кількості вузлів, що дозволяє вам вимкнути вузли, які не використовуються, і зменшити витрати на обслуговування.

Визначення розміру навантаження на основі розміру кластера

Пропорційне автомасштабування кластера

Для навантажень, які потрібно масштабувати залежно від розміру кластера, таких як cluster-dns або інші системні компоненти, ви можете використовувати Cluster Proportional Autoscaler.

Cluster Proportional Autoscaler спостерігає за кількістю придатних до планування вузлів та ядер, і масштабує кількість реплік цільового навантаження відповідно.

Вертикальний пропорційний автомасштабувальник кластера

Якщо кількість реплік має залишитися незмінною, ви можете масштабувати ваші робочі навантаження вертикально відповідно до розміру кластера, використовуючи Cluster Proportional Vertical Autoscaler. Цей проєкт перебуває в бета-версії та знаходиться на GitHub.

У той час, як Cluster Proportional Autoscaler масштабує кількість реплік робочого навантаження, Cluster Proportional Vertical Autoscaler налаштовує запити ресурсів для робочого навантаження (наприклад, Deployment або DaemonSet) на основі кількості вузлів та/або ядер у кластері.

Що далі

3.11.12 - Встановлення надбудов

Надбудови розширюють функціональність Kubernetes.

Ця сторінка містить список доступних надбудов та посилання на відповідні інструкції з встановлення. Список не намагається бути вичерпним.

Мережа та політика мережі

  • ACI надає інтегровану мережу контейнерів та мережеву безпеку з Cisco ACI.
  • Antrea працює на рівні 3/4, щоб надати мережеві та служби безпеки для Kubernetes, використовуючи Open vSwitch як мережеву панель даних. Antrea є проєктом CNCF на рівні Sandbox.
  • Calico є постачальником мережі та мережевої політики. Calico підтримує гнучкий набір мережевих опцій, щоб ви могли вибрати найефективнішу опцію для вашої ситуації, включаючи мережі з та без оверлею, з або без BGP. Calico використовує однаковий рушій для забезпечення мережевої політики для хостів, Podʼів та (якщо використовуєте Istio та Envoy) застосунків на рівні шару сервісної мережі.
  • Canal обʼєднує Flannel та Calico, надаючи мережу та мережеву політику.
  • Cilium: це рішення для мережі, спостереження та забезпечення безпеки з eBPF-орієнтованою панеллю даних. Cilium надає просту мережу Layer 3 з можливістю охоплення декількох кластерів в режимі маршрутизації або режимі налагодження/інкапсуляції та може застосовувати політики мережі на рівнях L3-L7 з використанням моделі безпеки на основі ідентифікації, що відʼєднана від мережевого адресування. Cilium може діяти як заміна для kube-proxy; він також пропонує додаткові функції спостереження та безпеки.
  • CNI-Genie: Дозволяє Kubernetes безперешкодно підключатися до вибору втулків CNI, таких як Calico, Canal, Flannel або Weave.
  • Contiv: надає налаштовану мережу (L3 з використанням BGP, оверлей за допомогою vxlan, класичний L2 та Cisco-SDN/ACI) для різних варіантів використання та повнофункціональний фреймворк політик. Проєкт Contiv є проєктом з повністю відкритими сирцями. Встановлювач надає як варіанти установки, як з, так і без, kubeadm.
  • Contrail: оснований на Tungsten Fabric, це відкритою платформою мережевої віртуалізації та управління політикою для кількох хмар. Contrail і Tungsten Fabric інтегровані з системами оркестрування, такими як Kubernetes, OpenShift, OpenStack і Mesos, і надають режими ізоляції для віртуальних машин, контейнерів/Podʼів та обробки робочих навантажень на bare metal.
  • Flannel: постачальник мережі на основі оверлеїв, який можна використовувати з Kubernetes.
  • Gateway API: відкритий проєкт, керований SIG Network, який надає виразний, розширюваний та рольовий API для моделювання сервісних мереж.
  • Knitter є втулком для підтримки кількох мережевих інтерфейсів в Podʼі Kubernetes.
  • Multus: мультивтулок для підтримки кількох мереж у Kubernetes для підтримки всіх втулків CNI (наприклад, Calico, Cilium, Contiv, Flannel), а також навантаження SRIOV, DPDK, OVS-DPDK та VPP у Kubernetes.
  • OVN-Kubernetes: постачальник мережі для Kubernetes на основі OVN (Open Virtual Network), віртуальної мережевої реалізації, яка вийшла з проєкту Open vSwitch (OVS). OVN-Kubernetes забезпечує реалізацію мережі на основі оверлеїв для Kubernetes, включаючи реалізацію балансування навантаження на основі OVS та політики мережі.
  • Nodus: втулок контролера CNI на основі OVN для надання хмарних послуг на основі послуг хмарної обробки (SFC).
  • NSX-T Container Plug-in (NCP): забезпечує інтеграцію між VMware NSX-T та оркестраторами контейнерів, такими як Kubernetes, а також інтеграцію між NSX-T та контейнерними платформами CaaS/PaaS, такими як Pivotal Container Service (PKS) та OpenShift.
  • Nuage: платформа SDN, яка забезпечує мережеву політику між кластерами Kubernetes Pods та некластерними середовищами з можливістю моніторингу видимості та безпеки.
  • Romana: рішення мережі рівня Layer 3 для мережевих мереж Podʼів, яке також підтримує NetworkPolicy API.
  • Spiderpool: рішення мережі основи та RDMA для Kubernetes. Spiderpool підтримується на bare metal, віртуальних машинах та публічних хмарних середовищах.
  • Weave Net: надає мережу та політику мережі, буде продовжувати працювати з обох боків розділу мережі та не потребує зовнішньої бази даних.

Виявлення служб

  • CoreDNS — це гнучкий, розширюваний DNS-сервер, який може бути встановлений як DNS в кластері для Podʼів.

Візуалізація та управління

  • Dashboard — це вебінтерфейс для управління Kubernetes.

Інфраструктура

  • KubeVirt — це додатковий інструмент для запуску віртуальних машин на Kubernetes. Зазвичай використовується на кластерах на bare metal.
  • Виявлення проблем вузла — працює на вузлах Linux та повідомляє про проблеми системи як події або стан вузла.

Інструментування

Старі надбудови

Існують ще кілька інших надбудов, які документуються в застарілій теці cluster/addons.

Добре підтримувані мають бути вказані тут. Приймаються запити на включення!

3.11.13 - Координовані вибори лідера

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.31 [alpha]

Kubernetes 1.31 включає альфа-функцію, яка дозволяє компонентам панелі управління детерміновано обирати лідера через координовані вибори лідера. Це корисно для задоволення обмежень щодо несумісності версій Kubernetes під час оновлення кластера. Наразі єдина вбудована стратегія вибору — це OldestEmulationVersion, що надає перевагу лідеру з найнижчою версією емуляції, за яким йде бінарна версія, а потім позначка часу створення.

Увімкнення координованих виборів лідера

Переконайтеся, що функціональну можливість CoordinatedLeaderElection увімкнено під час запуску API Server та що група API coordination.k8s.io/v1alpha1 увімкнена також.

Це можна зробити, встановивши прапорці --feature-gates="CoordinatedLeaderElection=true" та --runtime-config="coordination.k8s.io/v1alpha1=true".

Конфігурація компонентів

За умови, що ви увімкнули функціональну можливість CoordinatedLeaderElection та увімкнули групу API coordination.k8s.io/v1alpha1, сумісні компоненти панелі управління автоматично використовують LeaseCandidate та Lease API для вибору лідера за потреби.

Для Kubernetes 1.31 два компоненти панелі управління (kube-controller-manager і kube-scheduler) автоматично використовують координовані вибори лідера, коли функціональну можливість та група API увімкнені.

3.12 - Windows у Kubernetes

Kubernetes підтримує роботу вузлів на яких запущено Microsoft Windows.

Kubernetes підтримує робочі вузли які запущених на Linux або Microsoft Windows.

CNCF та батьківська організація Linux Foundation використовують вендор-нейтральний підхід до сумісності. Це означає, що можна додати ваш Windows сервер як робочий вузол до кластера Kubernetes.

Ви можете встановити та налаштувати kubectl на Windows незалежно від операційної системи, яку ви використовуєте в своєму кластері.

Якщо ви використовуєте вузли Windows, ви можете прочитати:

або, для ознайомлення, подивіться:

3.12.1 - Контейнери Windows у Kubernetes

Застосунки Windows становлять значну частину сервісів та застосунків, що працюють у багатьох організаціях. Контейнери Windows забезпечують спосіб інкапсуляції процесів та пакування залежностей, що спрощує використання практик DevOps та слідування хмарним рідним патернам для застосунків Windows.

Організації, що вклались у застосунки на базі Windows та Linux, не мають шукати окремі оркестратори для управління своїми навантаженнями, що призводить до збільшення оперативної ефективності у їх розгортаннях, незалежно від операційної системи.

Windows-вузли у Kubernetes

Для увімкнення оркестрування контейнерів Windows у Kubernetes, додайте Windows-вузли до вашого поточного Linux-кластера. Планування розміщення контейнерів Windows у Podʼах на Kubernetes подібне до планування розміщення контейнерів на базі Linux.

Для запуску контейнерів Windows ваш Kubernetes кластер має включати декілька операційних систем. Хоча панель управління можна запускати лише на Linux, ви можете розгортати робочі вузли, що працюють як на Windows, так і на Linux.

Windows вузли є підтримуваними, за умови, що операційна система є Windows Server 2019 або Windows Server 2022.

Цей документ використовує термін контейнери Windows для позначення контейнерів Windows з ізоляцією на рівні процесу. Kubernetes не підтримує запуск контейнерів Windows з ізоляцією Hyper-V.

Сумісність та обмеження

Деякі функції вузла доступні лише при використанні певного середовища для виконання контейнерів; інші не доступні на Windows-вузлах, зокрема:

  • HugePages: не підтримуються для контейнерів Windows
  • Привілейовані контейнери: не підтримуються для контейнерів Windows. Контейнери HostProcess пропонують схожий функціонал.
  • TerminationGracePeriod: вимагає containerD

Не всі функції спільних просторів імен підтримуються. Дивіться Сумісність API для детальнішої інформації.

Дивіться Сумісність версій Windows OS для деталей щодо версій Windows, з якими Kubernetes протестовано.

З точки зору API та kubectl, контейнери Windows поводяться майже так само, як і контейнери на базі Linux. Проте, існують деякі помітні відмінності у ключовому функціоналі, які окреслені в цьому розділі.

Порівняння з Linux

Ключові елементи Kubernetes працюють однаково в Windows, як і в Linux. Цей розділ описує кілька ключових абстракцій робочих навантажень та їх співвідносяться у Windows.

  • Podsʼи

    Pod є базовим будівельним блоком Kubernetes — найменшою та найпростішою одиницею в моделі об’єктів Kubernetes, яку ви створюєте або розгортаєте. Ви не можете розгортати Windows та Linux контейнери в одному Podʼі. Всі контейнери в Podʼі плануються на один вузол, де кожен вузол представляє певну платформу та архітектуру. Наступні можливості, властивості та події Podʼа підтримуються з контейнерами Windows:

    • Один або кілька контейнерів на Pod з ізоляцією процесів та спільним використанням томів

    • Поля status Podʼа

    • Проби готовності, життєздатності та запуску

    • Хуки життєвого циклу контейнера postStart & preStop

    • ConfigMap, Secrets: як змінні оточення або томи

    • Томи emptyDir

    • Монтування іменованих каналів хоста

    • Ліміти ресурсів

    • Поле OS:

      Значення поля .spec.os.name має бути встановлено у windows, щоб вказати, що поточний Pod використовує контейнери Windows.

      Якщо ви встановлюєте поле .spec.os.name у windows, вам не слід встановлювати наступні поля в .spec цього Podʼа:

      • spec.hostPID
      • spec.hostIPC
      • spec.securityContext.seLinuxOptions
      • spec.securityContext.seccompProfile
      • spec.securityContext.fsGroup
      • spec.securityContext.fsGroupChangePolicy
      • spec.securityContext.sysctls
      • spec.shareProcessNamespace
      • spec.securityContext.runAsUser
      • spec.securityContext.runAsGroup
      • spec.securityContext.supplementalGroups
      • spec.containers[*].securityContext.seLinuxOptions
      • spec.containers[*].securityContext.seccompProfile
      • spec.containers[*].securityContext.capabilities
      • spec.containers[*].securityContext.readOnlyRootFilesystem
      • spec.containers[*].securityContext.privileged
      • spec.containers[*].securityContext.allowPrivilegeEscalation
      • spec.containers[*].securityContext.procMount
      • spec.containers[*].securityContext.runAsUser
      • spec.containers[*].securityContext.runAsGroup

      У вищезазначеному списку, символи зірочки (*) вказують на всі елементи у списку. Наприклад, spec.containers[*].securityContext стосується обʼєкта SecurityContext для всіх контейнерів. Якщо будь-яке з цих полів вказано, Pod не буде прийнято API сервером.

  • [Ресурси робочих навантажень]](/docs/concepts/workloads/controllers/):

    • ReplicaSet
    • Deployment
    • StatefulSet
    • DaemonSet
    • Job
    • CronJob
    • ReplicationController
  • Service. Дивіться Балансування навантаження та Service для деталей.

Podʼи, ресурси робочого навантаження та Service є критичними елементами для управління Windows навантаженнями у Kubernetes. Однак, самі по собі вони недостатні для забезпечення належного управління життєвим циклом Windows навантажень у динамічному хмарному середовищі.

Параметри командного рядка для kubelet

Деякі параметри командного рядка для kubelet ведуть себе по-іншому у Windows, як описано нижче:

  • Параметр --windows-priorityclass дозволяє встановлювати пріоритет планування процесу kubelet (див. Управління ресурсами процесора)
  • Прапорці --kube-reserved, --system-reserved та --eviction-hard оновлюють NodeAllocatable
  • Виселення за допомогою --enforce-node-allocable не реалізовано
  • При запуску на вузлі Windows kubelet не має обмежень памʼяті або процесора. --kube-reserved та --system-reserved віднімаються лише від NodeAllocatable і не гарантують ресурсів для навантаження. Дивіться Управління ресурсами для вузлів Windows для отримання додаткової інформації.
  • Умова PIDPressure не реалізована
  • Kubelet не вживає дій щодо виселення з приводу OOM (Out of memory)

Сумісність API

Існують важливі відмінності в роботі API Kubernetes для Windows через ОС та середовище виконання контейнерів. Деякі властивості навантаження були розроблені для Linux, і їх не вдається виконати у Windows.

На високому рівні концепції ОС відрізняються:

  • Ідентифікація — Linux використовує ідентифікатор користувача (UID) та ідентифікатор групи (GID), які представлені як цілі числа. Імена користувачів і груп не є канонічними — це просто псевдоніми у /etc/groups або /etc/passwd до UID+GID. Windows використовує більший бінарний ідентифікатор безпеки (SID), який зберігається в базі даних Windows Security Access Manager (SAM). Ця база даних не використовується спільно між хостом та контейнерами або між контейнерами.
  • Права доступу до файлів — Windows використовує список управління доступом на основі (SID), тоді як POSIX-системи, такі як Linux, використовують бітову маску на основі дозволів обʼєкта та UID+GID, плюс опціональні списки управління доступом.
  • Шляхи до файлів — у Windows зазвичай використовується \ замість /. Бібліотеки вводу-виводу Go зазвичай приймають обидва і просто забезпечують їх роботу, але коли ви встановлюєте шлях або командний рядок, що інтерпретується всередині контейнера, можливо, буде потрібен символ \.
  • Сигнали — інтерактивні програми Windows обробляють завершення по-іншому і можуть реалізувати одне або декілька з цього:
    • UI-потік обробляє чітко визначені повідомлення, включаючи WM_CLOSE.
    • Консольні програми обробляють Ctrl-C або Ctrl-break за допомогою обробника керування.
    • Служби реєструють функцію обробника керування службами, яка може приймати коди керування SERVICE_CONTROL_STOP.

Коди виходу контейнера дотримуються тієї ж самої конвенції, де 0 є успіхом, а ненульове значення є помилкою. Конкретні коди помилок можуть відрізнятися між Windows та Linux. Однак коди виходу, передані компонентами Kubernetes (kubelet, kube-proxy), залишаються незмінними.

Сумісність полів для специфікацій контейнера

Наступний список документує відмінності у роботі специфікацій контейнерів Podʼа між Windows та Linux:

  • Великі сторінки не реалізовані в контейнері Windows та недоступні. Вони потребують встановлення привілеїв користувача, які не налаштовуються для контейнерів.
  • requests.cpu та requests.memory — запити віднімаються від доступних ресурсів вузла, тому вони можуть використовуватися для уникнення перевстановлення вузла. Проте вони не можуть гарантувати ресурси в перевстановленому вузлі. Їх слід застосовувати до всіх контейнерів як найкращу практику, якщо оператор хоче уникнути перевстановлення повністю.
  • securityContext.allowPrivilegeEscalation — неможливо на Windows; жодна з можливостей не підключена
  • securityContext.capabilities — можливості POSIX не реалізовані у Windows
  • securityContext.privileged — Windows не підтримує привілейовані контейнери, замість них використовуйте Контейнери HostProcess
  • securityContext.procMount — Windows не має файлової системи /proc
  • securityContext.readOnlyRootFilesystem — неможливо на Windows; запис доступу необхідний для реєстру та системних процесів, щоб виконуватися всередині контейнера
  • securityContext.runAsGroup — неможливо на Windows, оскільки відсутня підтримка GID
  • securityContext.runAsNonRoot — це налаштування перешкоджатиме запуску контейнерів як ContainerAdministrator, який є найближчим еквівалентом користувача root у Windows.
  • securityContext.runAsUser — використовуйте runAsUserName замість цього
  • securityContext.seLinuxOptions — неможливо у Windows, оскільки SELinux специфічний для Linux
  • terminationMessagePath — у цьому є деякі обмеження, оскільки Windows не підтримує зіставлення одного файлу. Стандартне значення — /dev/termination-log, що працює, оскільки воно стандартно не існує у Windows.

Сумісність полів для специфікацій Podʼа

Наступний список документує відмінності у роботі специфікацій Podʼа між Windows та Linux:

  • hostIPC та hostpid — спільне використання простору імен хосту неможливе у Windows
  • hostNetwork — див. нижче
  • dnsPolicy — встановлення dnsPolicy Podʼа на ClusterFirstWithHostNet не підтримується у Windows, оскільки мережа хосту не надається. Podʼи завжди працюють з мережею контейнера.
  • podSecurityContext див. нижче
  • shareProcessNamespace — це бета-функція, яка залежить від просторів імен Linux, які не реалізовані у Windows. Windows не може ділитися просторами імен процесів або кореневою файловою системою контейнера. Можлива лише спільна мережа.
  • terminationGracePeriodSeconds — це не повністю реалізовано в Docker у Windows, див. тікет GitHub. Поведінка на сьогодні полягає в тому, що процес ENTRYPOINT отримує сигнал CTRL_SHUTDOWN_EVENT, потім Windows типово чекає 5 секунд, і нарешті вимикає всі процеси за допомогою звичайної поведінки вимкнення Windows. Значення 5 секунд визначаються в реєстрі Windows всередині контейнера, тому їх можна перевизначити при збиранні контейнера.
  • volumeDevices — це бета-функція, яка не реалізована у Windows. Windows не може підключати блочні пристрої безпосередньо до Podʼів.
  • volumes
    • Якщо ви визначаєте том emptyDir, ви не можете встановити його джерело тома на memory.
  • Ви не можете активувати mountPropagation для монтування томів, оскільки це не підтримується у Windows.

Сумісність полів для hostNetwork

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.26 [alpha]

Тепер kubelet може вимагати, щоб Podʼи, що працюють на вузлах Windows, використовували мережевий простір імен хоста замість створення нового простору імен мережі Podʼа. Щоб увімкнути цю функціональність, передайте --feature-gates=WindowsHostNetwork=true в kubelet.

Сумісність полів для контексту безпеки Podʼа

Тільки поля securityContext.runAsNonRoot та securityContext.windowsOptions з поля Podʼа securityContext працюють у Windows.

Виявлення проблем вузла

Механізм виявлення проблем вузла (див. Моніторинг справності вузла) має попередню підтримку для Windows. Для отримання додаткової інформації відвідайте сторінку проєкту на GitHub.

Контейнер паузи

У кластері Kubernetes спочатку створюється інфраструктурний або контейнер "пауза", щоб вмістити інший контейнер. У Linux, групи керування та простори імен, що утворюють з Pod, потребують процесу для підтримки їхнього подальшого існування; процес паузи забезпечує це. Контейнери, які належать до одного Podʼа, включаючи інфраструктурні та робочі контейнери, мають спільну мережеву точку доступу (з тою ж самою IPv4 та / або IPv6 адресою, тими самими просторами портів мережі). Kubernetes використовує контейнери паузи для того, щоб дозволити робочим контейнерам виходити з ладу або перезапускатися без втрати будь-якої конфігурації мережі.

Kubernetes підтримує багатоархітектурний образ, який включає підтримку для Windows. Для Kubernetes v1.31.0 рекомендований образ паузи — registry.k8s.io/pause:3.6. Вихідний код доступний на GitHub.

Microsoft підтримує інший багатоархітектурний образ, з підтримкою Linux та Windows amd64, це mcr.microsoft.com/oss/kubernetes/pause:3.6. Цей образ побудований з того ж вихідного коду, що й образ, підтримуваний Kubernetes, але всі виконавчі файли Windows підписані authenticode Microsoft. Проєкт Kubernetes рекомендує використовувати образ, підтримуваний Microsoft, якщо ви розгортаєте в операційному середовищі або середовищі подібному до операційного, яке вимагає підписаних виконавчих файлів.

Середовища виконання контейнерів

Вам потрібно встановити середовище виконання контейнерів на кожний вузол у кластері, щоб Podʼи могли там працювати.

Наступні середовища виконання контейнерів ппрацюютьу Windows:

ContainerD

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.20 [stable]

Ви можете використовувати ContainerD версії 1.4.0+ як середовище виконання контейнера для вузлів Kubernetes, які працюють на Windows.

Дізнайтеся, як встановити ContainerD на вузол Windows.

Mirantis Container Runtime

Mirantis Container Runtime (MCR) є доступним середовищем виконання контейнерів для всіх версій Windows Server 2019 та пізніших.

Для отримання додаткової інформації дивіться Встановлення MCR на серверах Windows.

Сумісність версій операційної системи Windows

На вузлах Windows діють строгі правила сумісності, де версія операційної системи хосту повинна відповідати версії операційної системи базового образу контейнера. Повністю підтримуються лише Windows контейнери з операційною системою контейнера Windows Server 2019.

Для Kubernetes v1.31, сумісність операційної системи для вузлів Windows (та Podʼів) виглядає так:

Випуск LTSC Windows Server
Windows Server 2019
Windows Server 2022
Випуск SAC Windows Server
Windows Server версії 20H2

Також застосовується політика відхилення версій Kubernetes.

Рекомендації та важливі аспекти апаратного забезпечення

  • 64-бітний процесор з 4 ядрами CPU або більше, здатний підтримувати віртуалізацію
  • 8 ГБ або більше оперативної памʼяті
  • 50 ГБ або більше вільного місця на диску

Для отримання найновішої інформації про мінімальні апаратні вимоги дивіться Вимоги апаратного забезпечення для Windows Server у документації Microsoft. Для керівництва у виборі ресурсів для операційних робочих вузлів дивіться Робочі вузли для операційного середовища в документації Kubernetes.

Для оптимізації ресурсів системи, якщо не потрібний графічний інтерфейс, бажано використовувати операційну систему Windows Server, яка не включає опцію встановлення Windows Desktop Experience, оскільки така конфігурація зазвичай звільняє більше ресурсів системи.

При оцінці дискового простору для робочих вузлів Windows слід враховувати, що образи контейнера Windows зазвичай більші за образи контейнера Linux, розмір образів контейнерів може становити від 300 МБ до понад 10 ГБ для одного образу. Додатково, слід зауважити, що типово диск C: в контейнерах Windows являє собою віртуальний вільний розмір 20 ГБ, це не фактично використаний простір, а лише розмір диска, який може займати один контейнер при використанні локального сховища на хості. Дивіться Контейнери на Windows — Документація зберігання контейнерів для отримання більш детальної інформації.

Отримання допомоги та усунення несправностей

Для усунення несправностей звертайтесь до відповідного розділу цієї документації, він стане вашим головним джерелом в отриманні потрібних відомостей.

Додаткова допомога з усунення несправностей, специфічна для Windows, є в цьому розділі. Логи є важливою складовою усунення несправностей у Kubernetes. Переконайтеся, що ви додаєте їх кожного разу, коли звертаєтеся за допомогою у розвʼязані проблем до інших учасників. Дотримуйтесь інструкцій у керівництві щодо збору логів від SIG Windows.

Повідомлення про проблеми та запити нових функцій

Якщо у вас є підозра на помилку або ви хочете подати запит на нову функцію, будь ласка, дотримуйтесь настанов з участі від SIG Windows, щоб створити новий тікет. Спочатку вам слід переглянути список проблем у разі, якщо вона вже була повідомлена раніше, і додавати коментар зі своїм досвідом щодо проблеми та додавати додаткові логи. Канал SIG Windows у Slack Kubernetes також є чудовим способом отримати підтримку та ідеї для усунення несправностей перед створенням тікету.

Перевірка правильності роботи кластера Windows

Проєкт Kubernetes надає специфікацію Готовності до роботи у середовищі Windows разом з структурованим набором тестів. Цей набір тестів розділений на два набори тестів: базовий та розширений, кожен з яких містить категорії, спрямовані на тестування конкретних областей. Його можна використовувати для перевірки всіх функцій системи Windows та гібридної системи (змішана з Linux вузлами) з повним охопленням.

Щоб налаштувати проєкт на новому створеному кластері, дивіться інструкції у посібнику проєкту.

Інструменти розгортання

Інструмент kubeadm допомагає вам розгортати кластер Kubernetes, надаючи панель управління для управління кластером та вузли для запуску ваших робочих навантажень.

Проєкт кластерного API Kubernetes також надає засоби для автоматизації розгортання вузлів Windows.

Канали поширення Windows

Для докладного пояснення каналів поширення Windows дивіться документацію Microsoft.

Інформацію про різні канали обслуговування Windows Server, включаючи їх моделі підтримки, можна знайти на сторінці каналів обслуговування Windows Server.

3.12.2 - Посібник з запуску контейнерів Windows у Kubernetes

Ця сторінка надає покроковий опис, які ви можете виконати, щоб запустити контейнери Windows за допомогою Kubernetes. На сторінці також висвітлені деякі специфічні для Windows функції в Kubernetes.

Важливо зауважити, що створення та розгортання служб і робочих навантажень у Kubernetes працює практично однаково для контейнерів Linux та Windows. Команди kubectl, щоб працювати з кластером, ідентичні. Приклади на цій сторінці надаються для швидкого старту з контейнерами Windows.

Цілі

Налаштувати приклад розгортання для запуску контейнерів Windows на вузлі з операційною системою Windows.

Перш ніж ви розпочнете

Ви вже повинні мати доступ до кластера Kubernetes, який містить робочий вузол з операційною системою Windows Server.

Початок роботи: Розгортання робочого навантаження Windows

Наведений нижче приклад файлу YAML розгортає простий вебсервер, який працює в контейнері Windows.

Створіть файл маніфесту з назвою win-webserver.yaml з наступним вмістом:

---
apiVersion: v1
kind: Service
metadata:
  name: win-webserver
  labels:
    app: win-webserver
spec:
  ports:
    # порт, на якому має працювати ця служба
    - port: 80
      targetPort: 80
  selector:
    app: win-webserver
  type: NodePort
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: win-webserver
  name: win-webserver
spec:
  replicas: 2
  selector:
    matchLabels:
      app: win-webserver
  template:
    metadata:
      labels:
        app: win-webserver
      name: win-webserver
    spec:
     containers:
      - name: windowswebserver
        image: mcr.microsoft.com/windows/servercore:ltsc2019
        command:
        - powershell.exe
        - -command
        - "<#code used from https://gist.github.com/19WAS85/5424431#> ; $$listener = New-Object System.Net.HttpListener ; $$listener.Prefixes.Add('http://*:80/') ; $$listener.Start() ; $$callerCounts = @{} ; Write-Host('Listening at http://*:80/') ; while ($$listener.IsListening) { ;$$context = $$listener.GetContext() ;$$requestUrl = $$context.Request.Url ;$$clientIP = $$context.Request.RemoteEndPoint.Address ;$$response = $$context.Response ;Write-Host '' ;Write-Host('> {0}' -f $$requestUrl) ;  ;$$count = 1 ;$$k=$$callerCounts.Get_Item($$clientIP) ;if ($$k -ne $$null) { $$count += $$k } ;$$callerCounts.Set_Item($$clientIP, $$count) ;$$ip=(Get-NetAdapter | Get-NetIpAddress); $$header='<html><body><H1>Windows Container Web Server</H1>' ;$$callerCountsString='' ;$$callerCounts.Keys | % { $$callerCountsString+='<p>IP {0} callerCount {1} ' -f $$ip[1].IPAddress,$$callerCounts.Item($$_) } ;$$footer='</body></html>' ;$$content='{0}{1}{2}' -f $$header,$$callerCountsString,$$footer ;Write-Output $$content ;$$buffer = [System.Text.Encoding]::UTF8.GetBytes($$content) ;$$response.ContentLength64 = $$buffer.Length ;$$response.OutputStream.Write($$buffer, 0, $$buffer.Length) ;$$response.Close() ;$$responseStatus = $$response.StatusCode ;Write-Host('< {0}' -f $$responseStatus)  } ; "
     nodeSelector:
      kubernetes.io/os: windows
  1. Перевірте, що всі вузли справні:

    kubectl get nodes
    
  2. Розгорніть Service та спостерігайте за оновленнями робочих навантажень:

    kubectl apply -f win-webserver.yaml
    kubectl get pods -o wide -w
    

    Коли служба розгорнута правильно, обидва робочі навантаження позначаються як готові. Щоб вийти з команди спостереження, натисніть Ctrl+C.

  3. Перевірте успішність розгортання. Для перевірки:

    • Кілька Podʼів показуються з вузла керування Linux, скористайтеся kubectl get pods
    • Комунікація від вузла до Podʼа через мережу, за допомогою curl перевірте доступність порту 80 за IP-адресою Podʼів з вузла керування Linux, щоб перевірити відповідь вебсервера
    • Комунікація від Podʼа до Podʼа, пінг між Podʼами (і між хостами, якщо у вас більше одного вузла Windows) за допомогою kubectl exec
    • Комунікація Service-Pod, за допомогою curl перевірте віртуальний IP-адрес служби (вказаний у kubectl get services) з вузла керування Linux і з окремих Podʼів
    • Виявлення Service, за допомогою curl перевірте імʼя Service з типовим суфіксом DNS Kubernetes
    • Вхідне підключення, за допомогою curl перевірте NodePort з вузла керування Linux або зовнішніх машин поза кластером
    • Вихідне підключення, за допомогою curl перевірте зовнішні IP-адреси зсередини Podʼа за допомогою kubectl exec

Спостережуваність

Збір логів з навантажень

Логи — важливий елемент спостереження; вони дозволяють користувачам отримувати інформацію про роботу навантажень та є ключовим інгредієнтом для розвʼязання проблем. Оскільки контейнери Windows та робочі навантаження всередині контейнерів Windows поводяться по-іншому ніж контейнери в Linux, користувачі мали проблеми зі збором логів, що обмежувало операційну видимість. Робочі навантаження Windows, наприклад, зазвичай налаштовані на ведення логу подій ETW (Event Tracing for Windows) або надсилання записів в журнал подій програми. LogMonitor, відкритий інструмент від Microsoft, є рекомендованим способом моніторингу налаштованих джерел логів всередині контейнера Windows. LogMonitor підтримує моніторинг логів подій, провайдерів ETW та власних логів програм, перенаправляючи їх у STDOUT для використання за допомогою kubectl logs <pod>.

Дотримуйтеся інструкцій на сторінці GitHub LogMonitor, щоб скопіювати його бінарні файли та файли конфігурації до всіх ваших контейнерів та додати необхідні точки входу для LogMonitor, щоб він міг надсилати ваші логи у STDOUT.

Налаштування користувача для роботи контейнера

Використання налаштовуваних імен користувача контейнера

Контейнери Windows можуть бути налаштовані для запуску своїх точок входу та процесів з іншими іменами користувачів, ніж ті, що типово встановлені в образі. Дізнайтеся більше про це тут.

Управління ідентифікацією робочого навантаження за допомогою групових керованих облікових записів служб

Робочі навантаження контейнерів Windows можна налаштувати для використання облікових записів керованих служб групи (Group Managed Service Accounts — GMSA). Облікові записи керованих служб групи є конкретним типом облікових записів Active Directory, які забезпечують автоматичне керування паролями, спрощене керування іменами службових принципалів (service principal name — SPN) та можливість делегування управління іншим адміністраторам на кількох серверах. Контейнери, налаштовані з GMSA, можуть отримувати доступ до зовнішніх ресурсів домену Active Directory, надаючи тим самим ідентифікацію, налаштовану за допомогою GMSA. Дізнайтеся більше про налаштування та використання GMSA для контейнерів Windows тут.

Заплямованість та Толерантність

Користувачам необхідно використовувати певну комбінацію taintʼів та селекторів вузлів, щоб розміщувати робочі навантаження Linux та Windows на відповідних вузлах з операційними системами. Рекомендований підхід викладений нижче, однією з його головних цілей є те, що цей підхід не повинен порушувати сумісність для наявних робочих навантажень Linux.

Ви можете (і повинні) встановлювати значення .spec.os.name для кожного Pod, щоб вказати операційну систему, для якої призначені контейнери у цьому Pod. Для Podʼів, які запускають контейнери Linux, встановіть .spec.os.name на linux. Для Podʼів, які запускають контейнери Windows, встановіть .spec.os.name на windows.

Планувальник не використовує значення .spec.os.name при призначенні Podʼів вузлам. Ви повинні використовувати звичайні механізми Kubernetes для призначення Podʼів вузлам, щоб забезпечити, що панель управління вашого кластера розміщує Podʼи на вузлах, на яких працюють відповідні операційні системи.

Значення .spec.os.name не впливає на планування Podʼів Windows, тому все ще потрібні taint та толерантності (або селектори вузлів), щоб забезпечити, що Podʼи Windows розміщуються на відповідних вузлах Windows.

Забезпечення того, що навантаження, специфічні для ОС, розміщуються на відповідний хост

Користувачі можуть забезпечувати, що Windows контейнери можуть бути заплановані на відповідний хост за допомогою taint та толерантностей. Усі вузли Kubernetes, які працюють під керуванням Kubernetes 1.31, типово мають такі мітки:

  • kubernetes.io/os = [windows|linux]
  • kubernetes.io/arch = [amd64|arm64|...]

Якщо специфікація Pod не вказує селектор вузла, такий як "kubernetes.io/os": windows, це може означати можливість розміщення Pod на будь-якому хості, Windows або Linux. Це може бути проблематичним, оскільки Windows контейнер може працювати лише на Windows, а Linux контейнер може працювати лише на Linux. Найкраща практика для Kubernetes 1.31 — використовувати селектор вузлів.

Однак у багатьох випадках користувачі мають вже наявну велику кількість розгортань для Linux контейнерів, а також екосистему готових конфігурацій, таких як Helm-чарти створені спільнотою, і випадки програмної генерації Podʼів, такі як оператори. У таких ситуаціях ви можете мати сумнів що до того, щоб внести зміну конфігурації для додавання полів nodeSelector для всіх Podʼів і шаблонів Podʼів. Альтернативою є використання taint. Оскільки kubelet може встановлювати taint під час реєстрації, його можна легко змінити для автоматичного додавання taint при запуску лише на Windows.

Наприклад: --register-with-taints='os=windows:NoSchedule'

Додавши taint до всіх вузлів Windows, на них нічого не буде заплановано (це стосується наявних Podʼів Linux). Щоб запланувати Pod Windows на вузлі Windows, для цього потрібно вказати як nodeSelector, так і відповідну толерантність для вибору Windows.

nodeSelector:
    kubernetes.io/os: windows
    node.kubernetes.io/windows-build: '10.0.17763'
tolerations:
    - key: "os"
      operator: "Equal"
      value: "windows"
      effect: "NoSchedule"

Робота з кількома версіями Windows в одному кластері

Версія Windows Server, що використовується кожним Pod, повинна відповідати версії вузла. Якщо ви хочете використовувати кілька версій Windows Server в одному кластері, то вам слід встановити додаткові мітки вузлів та поля nodeSelector.

Kubernetes автоматично додає мітку, node.kubernetes.io/windows-build для спрощення цього.

Ця мітка відображає основний, додатковий і номер збірки Windows, які повинні збігатись для сумісності. Ось значення, що використовуються для кожної версії Windows Server:

Назва продуктуВерсія
Windows Server 201910.0.17763
Windows Server 202210.0.20348

Спрощення за допомогою RuntimeClass

RuntimeClass може бути використаний для спрощення процесу використання taints та tolerations. Адміністратор кластера може створити обʼєкт RuntimeClass, який використовується для інкапсуляції цих taint та toleration.

  1. Збережіть цей файл як runtimeClasses.yml. Він містить відповідний nodeSelector для ОС Windows, архітектури та версії.

    ---
    apiVersion: node.k8s.io/v1
    kind: RuntimeClass
    metadata:
      name: windows-2019
    handler: example-container-runtime-handler
    scheduling:
      nodeSelector:
        kubernetes.io/os: 'windows'
        kubernetes.io/arch: 'amd64'
        node.kubernetes.io/windows-build: '10.0.17763'
      tolerations:
      - effect: NoSchedule
        key: os
        operator: Equal
        value: "windows"
    
  2. Виконайте команду kubectl create -f runtimeClasses.yml з правами адміністратора кластера.

  3. Додайте runtimeClassName: windows-2019 відповідно до специфікацій Pod.

    Наприклад:

    ---
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: iis-2019
      labels:
        app: iis-2019
    spec:
      replicas: 1
      template:
        metadata:
          name: iis-2019
          labels:
            app: iis-2019
        spec:
          runtimeClassName: windows-2019
          containers:
          - name: iis
            image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019
            resources:
              limits:
                cpu: 1
                memory: 800Mi
              requests:
                cpu: .1
                memory: 300Mi
            ports:
              - containerPort: 80
     selector:
        matchLabels:
          app: iis-2019
    ---
    apiVersion: v1
    kind: Service
    metadata:
      name: iis
    spec:
      type: LoadBalancer
      ports:
      - protocol: TCP
        port: 80
      selector:
        app: iis-2019
    

3.13 - Розширення можливостей Kubernetes

Різні способи зміни поведінки вашого кластера Kubernetes.

Kubernetes добре налаштовується та розширюється. Тому випадки, коли вам потрібно робити форки та накладати патчі на Kubernetes, щоб змінити його поведінку, дуже рідкісні.

Цей розділ описує різні способи зміни поведінки вашого кластера Kubernetes. Він призначений для операторів, які хочуть зрозуміти, як адаптувати кластер до своїх потреб свого робочого оточення. Розробники, які є потенційними розробниками платформ чи учасники проєкту Kubernetes, також знайдуть цей розділ корисним як вступ до того, які точки та шаблони розширення існують, а також їх компроміси та обмеження.

Підходи до налаштувань можна взагалі розділити на конфігурацію, яка включає лише зміну аргументів командного рядка, локальних конфігураційних файлів або ресурсів API; та розширення, яке передбачає виконання додаткових програм, додаткових мережевих служб або обох. Цей документ в основному присвячений розширенням.

Конфігурація

Конфігураційні файли та аргументи командного рядка описані в розділі Довідник онлайн-документації, де кожен файл має свою сторінку:

Аргументи команд та файли конфігурації не завжди можуть бути змінені в службі Kubernetes, що надається постачальником, або дистрибутиві з керованою установкою. Коли їх можна змінювати, вони, як правило, змінюються лише оператором кластера. Крім того, вони можуть бути змінені в майбутніх версіях Kubernetes, і для їх налаштування може знадобитися перезапуск процесів. З цих причин їх слід використовувати лише тоді, коли немає інших варіантів.

Вбудовані API політики, такі як ResourceQuota, NetworkPolicy та доступ на основі ролей (RBAC), є вбудованими API Kubernetes, які надають можливості декларативного налаштування політик. API є доступними та в кластерах, які надаються провайдером, і в кластерах, якими ви керуєте самостійно. Вбудовані API політик використовують ті ж самі конвенції, що й інші ресурси Kubernetes, такі як Podʼи. Коли ви використовуєте стабільний API політик, ви отримуєте зиск від визначеної підтримки політик так само як й інші API Kubernetes. З цих причин використання API політик рекомендується на перевагу до конфігураційних файлів та аргументів командного рядка, де це можливо.

Розширення

Розширення — це компонент програмного забезпечення, який глибоко інтегрується з Kubernetes. Вони використовуються для додавання нових типів ресурсів та видів апаратного забезпечення.

Багато адміністраторів класів Kubernetes використовують кластери, що надаються провайдерами, чи встановленими з дистрибутивів. Ці кластери вже йдуть з розширеннями. В результаті, більшість користувачів Kubernetes не потребують встановлення розширень та дуже невелика частка потребує їх створення.

Шаблони розширень

Kubernetes спроєктовано так, щоб він був автоматизований шляхом створення клієнтських застосунків. Будь-яка програма, яка може писати та читати з API Kubernetes, може надавати корисні функції автоматизації. Ці функції можуть працювати як всередині кластера, так і ззовні. Слідуючи настановам з цього посібника, ви зможете створити надійні та високопродуктивні розширення. Автоматизація, як правило, працює з будь-яким кластером Kubernetes, незалежно від того, як він був встановлений.

Існує конкретний патерн написання клієнтських програм, які ефективно взаємодіють із Kubernetes, відомий як патерн контролера. Зазвичай контролери читають .spec обʼєкта, можливо виконують певні операції, а потім оновлюють .status обʼєкта.

Контролери є клієнтами API Kubernetes. Коли Kubernetes сам є клієнтом та звертається до віддаленого сервісу, виклики Kubernetes є вебхуками. Віддалений сервіс називається вебхук-бекендом. Так само як і стороні контролери, вебхуки додають ще одну точку вразливості.

В моделі вебхуків, Kubernetes надсилає мережеві запити до віддалених сервісів. Альтернативою є модель бінарних втулків, коли Kubernetes виконує бінарник (застосунок). Бінарні втулки використовуються в kublet (наприклад, втулок зберігання CSI та втулок мережі CNI), а також в kubeсtl (дивітьс розширення kubectl за допомогою втулків).

Точки розширення

На цій діаграмі показано точки розширення в кластері Kubernetes та клієнти з доступом до них.

Символічне представлення семи пронумерованих точок розширення для Kubernetes.

Точки розширення Kubernetes

Пояснення до діаграми

  1. Користувачі часто взаємодіють з API Kubernetes через kubectl. Втулки підлаштовують поведінку клієнтів. Існують загальні розширення, які можна використовувати з будь-якими клієнтами, так само як і специфічні розширення для kubectl.

  2. API сервер обробляє запити. Різні типи точок розширення на сервері API дозволяють автентифікувати запити або блокувати їх на основі їх вмісту, редагувати вміст та обробляти видалення. Про це в розділі розширення API доступу.

  3. API сервер також обслуговує різні типи ресурсів. Вбудовані типи ресурсі, такі як Pod, визначені проєктом Kubernetes та не можуть бути змінені. Дивіться розширення API щоб дізнатися про можливості розширення API.

  4. Планувальник вирішує на якому вузлі запустити кожний Pod. Існує кілька способів розширити планування, про це в розділі розширення планувальника.

  5. Більшість варіантів поведінки Kubernetes реалізовано через контролери, які є клієнтами API сервера. Контролери часто використовуються разом з нестандартними ресурсами. Дивіться поєднання нових API з автоматизаціями та зміна вбудованих ресурсів, щоб дізнатися більше.

  6. Kublet виконує контейнери на вузлах, та допомагає Podʼами виглядати як віртуальні сервери з їх власними IP в мережі кластера. Мережеві втулки дозволяють реалізувати різні мережеві моделі.

  7. Ви можете використовувати втулки пристроїв для використання спеціалізованих пристроїв або інших розташованих на вузлах ресурсів, та робити їх доступними для Podʼів у вашому кластері. Kublent містить підтримку для роботи з втулками пристроїв.

    Kublet також монтує томи для Podʼів та їх контейнерів. Втулки зберігання дозволяють реалізувати різні моделі зберігання.

Вибір точки розширення

Якщо ви вагаєтесь звідки розпочати, ця діаграма може допомогти вам. Зауважте, що деякі рішення можуть включати кілька типів розширень.

Flowchart with questions about use cases and guidance for implementers. Green circles indicate yes; red circles indicate no.

Діаграма-посібник для вибору методу розширення.


Розширення клієнта

Втулки до kubectl дозволяють є окремими програмами, які можуть додавати чи замінувати поведінку певних команд. kubectl може інтегруватись з втулком облікових даних. Ці розширення впливають лише на локальне оточення користувача і не можуть додавати нові політики до кластера.

Якщо ви бажаєте розширити kubectl, ознаиомтесь з розширення kubectl за допомогою втулків.

Розширення API

Визначення власних ресурсів

Зважте на додавання власних ресурсів у Kubernetes, якщо ви бажаєте визначити нові контролери, обʼєкти налаштування застосунків або інші декларативні API, та керувати ними використовуючи інструменти подібні до kubectl.

Докладніше про Custom Resource дивіться в розділі Custom Resources.

Шар агрегації API

Ви можете використовувати шар агрегації API Kubernetes, щоб додати нові ресурси до API Kubernetes разом з додатковими службами, такими як метрики.

Поєднання нових API з автоматизаціями

Поєднання API власних ресурсів та циклів управління називається шаблонами контролерів. Якщо ваш контролер виконує функції оператора-людини, та розгортає інфраструктуру на основі бажаного стану, то, можливо, він також дотримується шаблону оператора. Шаблон Оператор використовується для управління конкретними застосунками; зазвичай це застосунки, які підтримують стан та вимагають уважного управління.

Ви також можете створювати власні API та цикли управління, які керують іншими ресурсами, такими як сховище, або визначають політики (наприклад, обмеження контролю доступу).

Зміна вбудованих ресурсів

Коли ви розширюєте API Kubernetes шляхом додавання власних ресурсів, ці ресурси завжди потрапляють до нової групи API. Ви не можете замінити чи змінити наявні групи API. Додавання API напряму не впливає на поведінку наявних API (таких як Podʼи), однак мають вплив на розширення API доступу.

Розширення API доступу

Коли запит потрапляє до API сервера Kubernetes, він спочатку автентифікується, потім авторизується, і потім він потрапляє до перевірки допуску (admission control) (по факту деякі запити є неавтентифікованими та отримують особливу обробку). Дивіться розділ про керування доступу до API Kubernetes для отримання деталей.

Кожен крок в процесі автентифікації/авторизації пропонує точки розширення.

Автентифікація

Автентифікація зіставляє заголовки або сертифікати усіх запитів з користувачами, які зробили запит.

Kubernetes має кілька вбудованих методів автентифікації. Крім того, він може знаходитись поза проксі-сервером автентифікації та може надсилати токени з заголовком Authorization до інших віддалених служб для перевірки (вебхуки автентифікації), якщо вбудовані методи не підходять.

Авторизація

Авторизація визначає, чи має користувач право читати, писати чи виконувати інші дії з ресурсами API. Це відбувається на рівні всього ресурсу, а не на рівні окремих обʼєктів.

Якщо вбудовані методи авторизації не підходять, Kubernetes може використовувати вебхуки авторизації, що дозволяють викликати власний код для визначення, чи має користувач право виконувати дію.

Динамічний контроль допуску

Після того, як запит пройшов та авторизацію, і якщо це операція запису, він також проходить через крок контролю допуску. На додачу до вбудованих кроків, є кілька розширень:

  • Вебхуки політик образів дозволяють визначити, які образи можуть бути запущені в контейнерах.
  • Для прийняття довільних рішень щодо допуску можуть використовуватись загальні вебхуки допуску. Деякі з вебхуків допуску змінюють дані вхідних запитів до того, як вони будуть опрацьовані Kubernetes.

Розширення інфраструктури

Втулки пристроїв

Втулки пристроїв дозволяють вузлам знаходити нові ресурси Node (на додачу до вбудованих, таких як ЦП та памʼять) за допомогою Втулків пристроїв.

Втулки зберігання

Втулок Container Storage Interface (CSI) надає спосіб розширювати Kubernetes шляхом підтримки нових типів сховищ. Томи можуть знаходитись в надійних зовнішніх системах зберігання, або впроваджувати ефемерні пристрої зберігання, або можуть надавити read-only інтерфейс до інформації використовуючи парадигму роботи з файловою системою.

Kubernetes має підтримку втулків FlexVolume, які вже визнані застаріилими у v1.23 (на користь CSI).

FlexVolume дозволяв користувачам монтувати типи томів які не підтримувались самим Kubernetes. Коли ви запускали Pod, що вимагав FlexVolume, kublet викликав відповідний FlexVolume драйвер, який виконував монтування томів. Архівована пропозиція з проєктування FlexVolume містить більше докладної інформації про те, як все мало відбуватись.

ЧаПи про втулки роботи з томами в Kubernetes для постачальників рішень містить загальні відомості про втулки роботи з томами в Kubernetes.

Мережеві втулки

Ваш кластер Kubernetes потребує мережеві втулки для того, щоб мати робочу мережу для ваших Podʼів та підтримки аспектів мережевої моделі Kubernetes.

Мережеві втулки дозволяють Kubernetes працювати з різними мережевими топологіями та технологіями.

Втулки kublet image credential provider

СТАН ФУНКЦІОНАЛУ: Kubernetes 1.26 [stable]

Втулки kublet image credential provider дозволяють динамічно отримувати облікові дані для образів контейнерів з різних джерел. Облікові дані можуть бути використані для отримання образів контейнерів, які відповідають поточній конфігурації.

Втулки можуть спілкуватись з зовнішніми службами чи використовувати локальні файли для отримання облікових даних. В такому разу kublet не треба мати статичні облікові дані для кожного реєстру, і він може підтримувати різноманітні методи та протоколи автентифікації.

Щоб дізнатись про параметри налаштування втулка дивіться налаштування kubelet image credential provider.

Розширення планувальника

Планувальник є спеціальним типом контролера, який вирішує, на якому вузлі запустити який Pod. Стандартний планувальник можна повністю замінити, продовжуючи використовувати інші компоненти Kubernetes, або ж кілька планувальників можуть працювати разом.

Це значне завдання, і майже всі користувачі Kubernetes вважають, що їм не потрібно змінювати планувальник.

Ви можете контролювати активність втулків планувальника або асоціювати набори втулків з різними іменованими профілями планування. Ви також можете створювати свої власні втулки, які інтегруються з однією або кількома точками розширення kube-scheduler.

Зрештою, вбудований компонент kube-scheduler підтримує вебхуки, що дозволяє віддаленому HTTP-бекенду (розширенню планувальника) фільтрувати та/або пріоритизувати вузли, які kube-scheduler обирає для Podʼів.

Що далі

3.13.1 - Розширення обчислення, зберігання та мережі

Цей розділ охоплює розширення вашого кластера, які не входять до складу Kubernetes. Ви можете використовувати ці розширення для розширення функціональності вузлів у вашому кластері або для створення основи для мережі, яка зʼєднує Podʼи.

  • Втулки зберігання CSI та FlexVolume

    Втулки Container Storage Interface (CSI) надають можливість розширити Kubernetes підтримкою нових типів томів. Томи можуть спиратись на надійні зовнішні сховища, або надавати тимчасові сховища, або можуть надавати доступ до інформації лише для читання використовуючи парадигму файлової системи.

    Kubernetes також включає підтримку втулків FlexVolume, які є застарілими з моменту випуску Kubernetes v1.23 (використовуйте CSI замість них).

    Втулки FlexVolume дозволяють користувачам монтувати типи томів, які не підтримуються нативно Kubernetes. При запуску Pod, який залежить від сховища FlexVolume, kubelet викликає бінарний втулок для монтування тому. В заархівованій пропозиції про дизайн FlexVolume є більше деталей щодо цього підходу.

    Kubernetes Volume Plugin FAQ для постачальників зберігання містить загальну інформацію про втулки зберігання.

  • Втулки пристроїв

    Втулки пристроїв дозволяють вузлу виявляти нові можливості Node (на додаток до вбудованих ресурсів вузла, таких як cpu та memory) та надавати ці додаткові локальні можливості вузла для Podʼів, які їх запитують.

  • Втулки мережі

    Втулки мережі дозволяють Kubernetes працювати з різними топологіями та технологіями мереж. Вашому кластеру Kubernetes потрібен втулок мережі для того, щоб мати працюючу мережу для Podʼів та підтримувати інші аспекти мережевої моделі Kubernetes.

    Kubernetes 1.31 сумісний з втулками CNI мережі.

3.13.1.1 - Мережеві втулки

Kubernetes (з версії 1.3 і до останньої версії 1.31 та можливо й потім) дозволяє використовувати мережевий інтерфейс контейнерів (CNI, Container Network Interface) для втулків мережі кластера. Вам потрібно використовувати втулок CNI, який сумісний з вашим кластером та відповідає вашим потребам. В екосистемі Kubernetes доступні різні втулки (як з відкритим, так і закритим кодом).

Для імплементації мережевої моделі Kubernetes необхідно використовувати втулок CNI.

Вам потрібно використовувати втулок CNI, який сумісний з v0.4.0 або більш пізніми версіями специфікації CNI. Проєкт Kubernetes рекомендує використовувати втулок, який сумісний з v1.0.0 специфікації CNI (втулки можуть бути сумісними з кількома версіями специфікації).

Встановлення

Середовище виконання контейнерів (Container Runtime) у контексті мережі — це служба на вузлі, налаштована для надання сервісів CRI для kubelet. Зокрема, середовище виконання контейнерів повинно бути налаштоване для завантаження втулків CNI, необхідних для реалізації мережевої моделі Kubernetes.

Для конкретної інформації про те, як середовище виконання контейнерів керує втулками CNI, дивіться документацію для цього середовища виконання контейнерів, наприклад:

Для конкретної інформації про те, як встановити та керувати втулком CNI, дивіться документацію для цього втулка або постачальника мережі.

Вимоги до мережевих втулків

Loopback CNI

Крім втулка CNI, встановленого на вузлах для реалізації мережевої моделі Kubernetes, Kubernetes також вимагає, щоб середовища виконання контейнерів надавали loopback інтерфейс lo, який використовується для кожної пісочниці (пісочниці Podʼів, пісочниці віртуальних машин тощо). Реалізацію інтерфейсу loopback можна виконати, використовуючи втулок loopback CNI або розробивши власний код для досягнення цього (дивіться цей приклад від CRI-O).

Підтримка hostPort

Втулок мережі CNI підтримує hostPort. Ви можете використовувати офіційний втулок portmap, який пропонується командою втулків CNI, або використовувати свій власний втулок з функціональністю portMapping.

Якщо ви хочете ввімкнути підтримку hostPort, вам потрібно вказати capability portMappings у вашому cni-conf-dir. Наприклад:

{
  "name": "k8s-pod-network",
  "cniVersion": "0.4.0",
  "plugins": [
    {
      "type": "calico",
      "log_level": "info",
      "datastore_type": "kubernetes",
      "nodename": "127.0.0.1",
      "ipam": {
        "type": "host-local",
        "subnet": "usePodCidr"
      },
      "policy": {
        "type": "k8s"
      },
      "kubernetes": {
        "kubeconfig": "/etc/cni/net.d/calico-kubeconfig"
      }
    },
    {
      "type": "portmap",
      "capabilities": {"portMappings": true},
      "externalSetMarkChain": "KUBE-MARK-MASQ"
    }
  ]
}

Підтримка формування трафіку

Експериментальна функція

Втулок мережі CNI також підтримує формування вхідного та вихідного трафіку для Podʼів. Ви можете використовувати офіційний втулок bandwidth, що пропонується командою втулків CNI, або використовувати власний втулок з функціональністю контролю ширини смуги.

Якщо ви хочете ввімкнути підтримку формування трафіку, вам потрібно додати втулок bandwidth до вашого файлу конфігурації CNI (типово /etc/cni/net.d) та забезпечити наявність відповідного виконавчого файлу у вашій теці виконавчих файлів CNI (типово /opt/cni/bin).

{
  "name": "k8s-pod-network",
  "cniVersion": "0.4.0",
  "plugins": [
    {
      "type": "calico",
      "log_level": "info",
      "datastore_type": "kubernetes",
      "nodename": "127.0.0.1",
      "ipam": {
        "type": "host-local",
        "subnet": "usePodCidr"
      },
      "policy": {
        "type": "k8s"
      },
      "kubernetes": {
        "kubeconfig": "/etc/cni/net.d/calico-kubeconfig"
      }
    },
    {
      "type": "bandwidth",
      "capabilities": {"bandwidth": true}
    }
  ]
}

Тепер ви можете додати анотації kubernetes.io/ingress-bandwidth та kubernetes.io/egress-bandwidth до вашого Podʼа. Наприклад:

apiVersion: v1
kind: Pod
metadata:
  annotations:
    kubernetes.io/ingress-bandwidth: 1M
    kubernetes.io/egress-bandwidth: 1M
...

Що далі

3.13.1.2 - Втулки пристроїв

Втулки пристроїв дозволяють налаштувати кластер із підтримкою пристроїв або ресурсів, які вимагають налаштування від постачальника, наприклад GPU, NIC, FPGA або енергонезалежної основної памʼяті.
СТАН ФУНКЦІОНАЛУ: Kubernetes v1.26 [stable]

Kubernetes надає фреймворк втулків пристроїв, який ви можете використовувати для оголошення системних апаратних ресурсів Kubelet.

Замість того, щоб вносити зміни в код самого Kubernetes, вендори можуть реалізувати втулки пристроїв, які ви розгортаєте або вручну, або як DaemonSet. Цільові пристрої включають GPU, мережеві інтерфейси високої продуктивності, FPGA, адаптери InfiniBand, та інші подібні обчислювальні ресурси, які можуть вимагати ініціалізації та налаштування від вендора.

Реєстрація втулка пристрою

kubelet надає службу Registration через gRPC:

service Registration {
	rpc Register(RegisterRequest) returns (Empty) {}
}

Втулок пристрою може зареєструвати себе в kubelet через цю службу gRPC. Під час реєстрації втулок пристрою повинен надіслати:

  • Назву свого Unix сокету.
  • Версію API втулка пристрою, під яку він був зібраний.
  • ResourceName, яке він хоче оголошувати. Тут ResourceName повинно відповідати розширеній схемі найменування ресурсів у вигляді vendor-domain/resourcetype. (Наприклад, NVIDIA GPU рекламується як nvidia.com/gpu.)

Після успішної реєстрації втулок пристрою надсилає kubelet список пристроїв, якими він керує, і тоді kubelet стає відповідальним за оголошення цих ресурсів на сервері API як частини оновлення стану вузла. Наприклад, після того, як втулок пристрою зареєструє hardware-vendor.example/foo в kubelet і повідомить про наявність двох пристроїв на вузлі, статус вузла оновлюється для оголошення того, що на вузлі встановлено 2 пристрої "Foo" і вони доступні для використання.

Після цього користувачі можуть запитувати пристрої як частину специфікації Podʼа (див. container). Запит розширених ресурсів схожий на те, як ви керуєте запитами та лімітами для інших ресурсів, з такими відмінностями:

  • Розширені ресурси підтримуються лише як цілочисельні ресурси та не можуть бути перевищені.
  • Пристрої не можуть бути спільно використані між контейнерами.

Приклад

Припустимо, що в кластері Kubernetes працює втулок пристрою, який оголошує ресурс hardware-vendor.example/foo на певних вузлах. Ось приклад Podʼа, який використовує цей ресурс для запуску демонстраційного завдання:

---
apiVersion: v1
kind: Pod
metadata:
  name: demo-pod
spec:
  containers:
    - name: demo-container-1
      image: registry.k8s.io/pause:2.0
      resources:
        limits:
          hardware-vendor.example/foo: 2
#
# Цей Pod потребує 2 пристроїв hardware-vendor.example/foo
# і може бути розміщений тільки на Вузлі, який може задовольнити
# цю потребу.
#
# Якщо на Вузлі доступно більше 2 таких пристроїв, то
# залишок буде доступний для використання іншими Podʼами.

Імплементація втулка пристрою

Загальний робочий процес втулка пристрою включає наступні кроки:

  1. Ініціалізація. Під час цієї фази втулок пристрою виконує ініціалізацію та налаштування, специфічні для вендора, щоб забезпечити те, що пристрої перебувають в готовому стані.

  2. Втулок запускає службу gRPC з Unix сокетом за шляхом хоста /var/lib/kubelet/device-plugins/, що реалізує наступні інтерфейси:

    service DevicePlugin {
          // GetDevicePluginOptions повертає параметри, що будуть передані до Менеджера пристроїв.
          rpc GetDevicePluginOptions(Empty) returns (DevicePluginOptions) {}
    
          // ListAndWatch повертає потік списку пристроїв
          // Кожного разу, коли змінюється стан пристрою або пристрій зникає, ListAndWatch
          // повертає новий список
          rpc ListAndWatch(Empty) returns (stream ListAndWatchResponse) {}
    
          // Allocate викликається під час створення контейнера, щоб втулок
          // пристрою міг виконати операції, специфічні для пристрою, та підказати kubelet
          // кроки для доступу до пристрою в контейнері
          rpc Allocate(AllocateRequest) returns (AllocateResponse) {}
    
          // GetPreferredAllocation повертає набір пріоритетних пристроїв для виділення
          // зі списку доступних. Остаточне пріоритетне виділення не гарантується,
          // це буде зроблене devicemanager. Це призначено лише для допомоги devicemanager у
          // прийнятті більш обізнаних рішень про виділення, коли це можливо.
          rpc GetPreferredAllocation(PreferredAllocationRequest) returns (PreferredAllocationResponse) {}
    
          // PreStartContainer викликається, якщо це вказано втулком пристрою під час фази реєстрації,
          // перед кожним запуском контейнера. Втулок пристроїв може виконати певні операції
          // такі як перезаватаження пристрою перед забезпеченням доступу до пристроїв в контейнері.
          rpc PreStartContainer(PreStartContainerRequest) returns (PreStartContainerResponse) {}
    }
    
  3. Втулок реєструється з kubelet через Unix сокет за шляхом хосту /var/lib/kubelet/device-plugins/kubelet.sock.

  4. Після успішної реєстрації втулок працює в режимі обслуговування, під час якого він постійно відстежує стан пристроїв та повідомляє kubelet про будь-які зміни стану пристрою. Він також відповідальний за обслуговування запитів gRPC Allocate. Під час Allocate втулок пристрою може виконувати підготовку, специфічну для пристрою; наприклад, очищення GPU або ініціалізація QRNG. Якщо операції успішно виконуються, втулок повертає відповідь AllocateResponse, яка містить конфігурації контейнера для доступу до виділених пристроїв. Kubelet передає цю інформацію середовищу виконання контейнерів.

    AllocateResponse містить нуль або більше обʼєктів ContainerAllocateResponse. У цих обʼєктах втулок визначає зміни, які потрібно внести в опис контейнера для забезпечення доступу до пристрою. Ці зміни включають:

    • анотації
    • вузли пристроїв
    • змінні середовища
    • монтування
    • повні імена пристроїв CDI

Обробка перезапусків kubelet

Очікується, що втулок пристрою виявлятиме перезапуски kubelet і повторно реєструватиметься з новим екземпляром kubelet. Новий екземпляр kubelet видаляє всі наявні Unix-сокети під /var/lib/kubelet/device-plugins, коли він стартує. Втулок пристрою може відстежувати вилучення своїх Unix-сокетів та повторно реєструватися після цієї події.

Втулок пристроїв та несправні пристрої

Існують випадки, коли пристрої виходять з ладу або вимикаються. Відповідальність втулку пристроїв у такому випадку полягає в тому, щоб повідомити kubelet про ситуацію за допомогою API ListAndWatchResponse.

Після того, як пристрій позначено як несправний, kubelet зменшить кількість виділених ресурсів для цього ресурсу на Вузлі, щоб відобразити, скільки пристроїв можна використовувати для планування нових Podʼів. Загальна величина кількості для ресурсу не змінюватиметься.

Podʼи, які були призначені несправним пристроям, залишаться призначеними до цього пристрою. Зазвичай код, що покладається на пристрій, почне виходити з ладу, і Pod може перейти у фазу Failed, якщо restartPolicy для Podʼа не був Always, або увійти в цикл збоїв в іншому випадку.

До Kubernetes v1.31, щоб дізнатися, чи повʼязаний Pod із несправним пристроєм, потрібно було використовувати PodResources API.

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.31 [alpha]

Увімкнувши функціональну можливість ResourceHealthStatus, до кожного статусу контейнера в полі .status для кожного Pod буде додано поле allocatedResourcesStatus. Поле allocatedResourcesStatus надає інформацію про стан справності для кожного пристрою, призначеного контейнеру.

Для несправного Pod або коли ви підозрюєте несправність, ви можете використовувати цей статус, щоб зрозуміти, чи може поведінка Podʼа бути повʼязаною з несправністю пристрою. Наприклад, якщо прискорювач повідомляє про подію перегріву, поле allocatedResourcesStatus може відобразити цю інформацію.

Розгортання втулка пристрою

Ви можете розгорнути втулок пристрою як DaemonSet, як пакунок для операційної системи вузла або вручну.

Канонічна тека /var/lib/kubelet/device-plugins потребує привілейованого доступу, тому втулок пристрою повинен працювати у привілейованому контексті безпеки. Якщо ви розгортаєте втулок пристрою як DaemonSet, тека /var/lib/kubelet/device-plugins має бути змонтована як Том у PodSpec втулка.

Якщо ви обираєте підхід з використанням DaemonSet, ви можете розраховувати на Kubernetes щодо: розміщення Podʼа втулка пристрою на Вузлах, перезапуску Podʼа демона після відмови та автоматизації оновлень.

Сумісність API

Раніше схема керування версіями вимагала, щоб версія API втулка пристрою точно відповідала версії Kubelet. З моменту переходу цієї функції до бета-версії у версії 1.12 це більше не є жорсткою вимогою. API має версію і є стабільним з моменту випуску бета-версії цієї функції. Через це оновлення kubelet повинні бути безперебійними, але все ще можуть бути зміни в API до стабілізації, що робить оновлення не гарантовано непорушними.

Як проєкт, Kubernetes рекомендує розробникам втулка пристрою:

  • Слідкувати за змінами API втулка пристрою у майбутніх релізах.
  • Підтримувати кілька версій API втулка пристрою для забезпечення зворотної/майбутньої сумісності.

Для запуску втулка пристрою на вузлах, які потрібно оновити до випуску Kubernetes з новішою версією API втулка пристрою, оновіть ваші втулки пристроїв, щоб підтримувати обидві версії перед оновленням цих вузлів. Такий підхід забезпечить безперервну роботу виділення пристроїв під час оновлення.

Моніторинг ресурсів втулка пристрою

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.28 [stable]

Для моніторингу ресурсів, наданих втулками пристроїв, агенти моніторингу повинні мати змогу виявляти набір пристроїв, які використовуються на вузлі, та отримувати метадані, щоб описати, з яким контейнером повʼязаний показник метрики. Метрики Prometheus, експоновані агентами моніторингу пристроїв, повинні відповідати Рекомендаціям щодо інструментування Kubernetes, ідентифікуючи контейнери за допомогою міток prometheus pod, namespace та container.

Kubelet надає gRPC-сервіс для виявлення використовуваних пристроїв та надання метаданих для цих пристроїв:

// PodResourcesLister — це сервіс, який надається kubelet, який надає інформацію про
// ресурси вузла, використані контейнерами та Podʼами на вузлі
service PodResourcesLister {
    rpc List(ListPodResourcesRequest) returns (ListPodResourcesResponse) {}
    rpc GetAllocatableResources(AllocatableResourcesRequest) returns (AllocatableResourcesResponse) {}
    rpc Get(GetPodResourcesRequest) returns (GetPodResourcesResponse) {}
}

Точка доступу gRPC List

Точка доступу List надає інформацію про ресурси запущених Podʼів, з деталями, такими як ідентифікатори виключно виділених ЦП, ідентифікатор пристрою так, як він був повідомлений втулками пристроїів, і ідентифікатор NUMA-вузла, де ці пристрої розміщені. Крім того, для машин, що базуються на NUMA, вона містить інформацію про памʼять та великі сторінки, призначені для контейнера.

Починаючи з Kubernetes v1.27, точка доступу List може надавати інформацію про ресурси запущених Podʼів, виділені в ResourceClaims за допомогою API DynamicResourceAllocation. Щоб увімкнути цю функцію, kubelet повинен бути запущений з наступними прапорцями:

--feature-gates=DynamicResourceAllocation=true,KubeletPodResourcesDynamicResources=true
// ListPodResourcesResponse — це відповідь, повернута функцією List
message ListPodResourcesResponse {
    repeated PodResources pod_resources = 1;
}

// PodResources містить інформацію про ресурси вузла, призначені для Podʼа
message PodResources {
    string name = 1;
    string namespace = 2;
    repeated ContainerResources containers = 3;
}

// ContainerResources містить інформацію про ресурси, призначені для контейнера
message ContainerResources {
    string name = 1;
    repeated ContainerDevices devices = 2;
    repeated int64 cpu_ids = 3;
    repeated ContainerMemory memory = 4;
    repeated DynamicResource dynamic_resources = 5;
}

// ContainerMemory містить інформацію про памʼять та великі сторінки, призначені для контейнера
message ContainerMemory {
    string memory_type = 1;
    uint64 size = 2;
    TopologyInfo topology = 3;
}

// Topology описує апаратну топологію ресурсу
message TopologyInfo {
        repeated NUMANode nodes = 1;
}

// NUMA представлення NUMA-вузла
message NUMANode {
        int64 ID = 1;
}

// ContainerDevices містить інформацію про пристрої, призначені для контейнера
message ContainerDevices {
    string resource_name = 1;
    repeated string device_ids = 2;
    TopologyInfo topology = 3;
}

// DynamicResource містить інформацію про пристрої, призначені для контейнера за допомогою Dynamic Resource Allocation
message DynamicResource {
    string class_name = 1;
    string claim_name = 2;
    string claim_namespace = 3;
    repeated ClaimResource claim_resources = 4;
}

// ClaimResource містить інформацію про ресурси у втулках
message ClaimResource {
    repeated CDIDevice cdi_devices = 1 [(gogoproto.customname) = "CDIDevices"];
}

// CDIDevice визначає інформацію про пристрій CDI
message CDIDevice {
    // Повністю кваліфіковане імʼя пристрою CDI
    // наприклад: vendor.com/gpu=gpudevice1
    // див. більше деталей в специфікації CDI:
    // https://github.com/container-orchestrated-devices/container-device-interface/blob/main/SPEC.md
    string name = 1;
}

Точка доступу gRPC GetAllocatableResources

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.28 [stable]

Точка доступу GetAllocatableResources надає інформацію про ресурси, що спочатку доступні на робочому вузлі. Вона надає більше інформації, ніж kubelet експортує в APIServer.

// AllocatableResourcesResponses містить інформацію про всі пристрої, відомі kubelet
message AllocatableResourcesResponse {
    repeated ContainerDevices devices = 1;
    repeated int64 cpu_ids = 2;
    repeated ContainerMemory memory = 3;
}

ContainerDevices дійсно викладають інформацію про топологію, що вказує, до яких NUMA-клітин пристрій прикріплений. NUMA-клітини ідентифікуються за допомогою прихованого цілочисельного ідентифікатора, значення якого відповідає тому, що втулки пристроїв повідомляють коли вони реєструються у kubelet.

Сервіс gRPC обслуговується через unix-сокет за адресою /var/lib/kubelet/pod-resources/kubelet.sock. Агенти моніторингу для ресурсів втулків пристроїв можуть бути розгорнуті як демони, або як DaemonSet. Канонічна тека /var/lib/kubelet/pod-resources вимагає привілейованого доступу, тому агенти моніторингу повинні працювати у привілейованому контексті безпеки. Якщо агент моніторингу пристроїв працює як DaemonSet, /var/lib/kubelet/pod-resources має бути підключена як Том у PodSpec агента моніторингу пристроїв PodSpec.

Точка доступу gRPC Get

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.27 [alpha]

Точка доступу Get надає інформацію про ресурси робочого Pod. Вона експонує інформацію, аналогічну тій, що описана в точці доступу List. Точка доступу Get вимагає PodName і PodNamespace робочого Pod.

// GetPodResourcesRequest містить інформацію про Pod
message GetPodResourcesRequest {
    string pod_name = 1;
    string pod_namespace = 2;
}

Для включення цієї функції вам потрібно запустити ваші служби kubelet з такими прапорцями:

--feature-gates=KubeletPodResourcesGet=true

Точка доступу Get може надавати інформацію про Pod, повʼязану з динамічними ресурсами, виділеними за допомогою API динамічного виділення ресурсів. Для включення цієї функції вам потрібно забезпечити, щоб ваші служби kubelet були запущені з наступними прапорцями:

--feature-gates=KubeletPodResourcesGet=true,DynamicResourceAllocation=true,KubeletPodResourcesDynamicResources=true

Інтеграція втулка пристрою з Менеджером Топології

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.27 [stable]

Менеджер Топології (Topology Manager) є компонентом Kubelet, який дозволяє координувати ресурси в манері, орієнтованій на топологію. Для цього API втулка пристрою (Device Plugin API) було розширено, щоб включити структуру TopologyInfo.

message TopologyInfo {
    repeated NUMANode nodes = 1;
}

message NUMANode {
    int64 ID = 1;
}

Втулки пристроїв, які хочуть використовувати Менеджер Топології, можуть надсилати заповнену структуру TopologyInfo як частину реєстрації пристрою, разом з ідентифікаторами пристроїв та станом справності пристрою. Менеджер пристроїв потім використовуватиме цю інформацію для консультації з Менеджером Топології та прийняття рішень щодо призначення ресурсів.

TopologyInfo підтримує встановлення поля nodes або у nil, або у список вузлів NUMA. Це дозволяє Втулку Пристрою оголошувати пристрій, який охоплює кілька вузлів NUMA.

Встановлення TopologyInfo в nil або надання порожнього списку вузлів NUMA для даного пристрою вказує на те, що Втулок Пристрою не має переваги щодо спорідненості NUMA для цього пристрою.

Приклад структури TopologyInfo, заповненої для пристрою Втулком Пристрою:

pluginapi.Device{ID: "25102017", Health: pluginapi.Healthy, Topology:&pluginapi.TopologyInfo{Nodes: []*pluginapi.NUMANode{&pluginapi.NUMANode{ID: 0,},}}}

Приклади втулків пристроїв

Ось деякі приклади реалізації втулків пристроїв:

Що далі

3.13.2 - Розширючи API Kubernetes

Власні ресурси користувача є розширенням API Kubernetes. Kubernetes надає два способи додавання власних ресурсів до вашого кластера:

  • Механізм CustomResourceDefinition (CRD) дозволяє вам декларативно визначити новий власний API з API-групою, видом (kind) та схемою, які ви вказуєте. Панель управління Kubernetes обслуговує та обробляє зберіганням вашого власного ресурсу. CRD дозволяє створювати нові типи ресурсів для вашого кластера без написання та запуску власного API-сервера.
  • Шар агрегації розташований за основним API-сервером, який діє як проксі. Таке розташування називається агрегацією API (AA), яка дозволяє вам надавати спеціалізовані реалізації для ваших власних ресурсів, написавши та розгорнувши власний API-сервер. Основний API-сервер делегує запити до вашого API-сервера для власних API, які ви вказуєте, зробивши їх доступними для всіх своїх клієнтів.

3.13.2.1 - Власні Ресурси

Власні ресурси є розширеннями API Kubernetes. Ця сторінка обговорює, коли додавати власний ресурс до вашого кластера Kubernetes та коли використовувати як самостійний сервіс. Вона описує два методи додавання власних ресурсів і як вибрати між ними.

Власні ресурси

Ресурс — це точка доступу в API Kubernetes, яка зберігає колекцію обʼєктів API певного виду; наприклад, вбудований ресурс pods містить колекцію обʼєктів Pod.

Власний ресурс — це розширення API Kubernetes, яке не обовʼязково доступне в типовій установці Kubernetes. Він представляє собою налаштування конкретного встановлення Kubernetes. Однак багато основних функцій Kubernetes тепер побудовані з використанням власних ресурсів, що робить Kubernetes більш модульним.

Власні ресурси можуть зʼявлятися та зникають в працюючому кластері через динамічну реєстрацію, і адміністратори кластера можуть оновлювати власні ресурси незалежно від самого кластера. Як тільки власний ресурс встановлено, користувачі можуть створювати та отримувати доступ до його обʼєктів за допомогою kubectl, так само як для вбудованих ресурсів, таких як Pod.

Власні контролери

Самі по собі власні ресурси дозволяють зберігати та отримувати структуровані дані. Коли ви поєднуєте власний ресурс з власним контролером, власні ресурси надають справжній декларативний API.

Декларативний API Kubernetes забезпечує розділення обовʼязків. Ви оголошуєте бажаний стан вашого ресурсу. Контролер Kubernetes підтримує поточний стан обʼєктів Kubernetes відповідно до вашого оголошеного бажаного стану. Це відрізняється від імперативного API, де ви вказуєте серверу, що робити.

Ви можете розгортати та оновлювати власний контролер на робочому кластері, незалежно від життєвого циклу кластера. Власні контролери можуть працювати з будь-яким видом ресурсів, але вони особливо ефективні, коли поєднуються з власними ресурсами. Шаблон Оператора поєднує власні ресурси та власні контролери. Ви можете використовувати власні контролери для включення доменного знання для конкретних застосунків у розширення API Kubernetes.

Чи слід додавати власний ресурс до мого кластера Kubernetes?

При створенні нового API розгляньте можливість агрегування вашого API з API кластера Kubernetes або дозвольте вашому API залишитися незалежним.

Розгляньте агрегацію API, якщо:Віддайте перевагу незалежному API, якщо:
Ваш API є Декларативним.Ваш API не відповідає моделі Декларативного API.
Ви хочете, щоб ваші нові типи були доступні для читання та запису за допомогою kubectl.Підтримка kubectl не є необхідною.
Ви хочете бачити свої нові типи в UI Kubernetes, такому як панель управління, поряд з вбудованими типами.Підтримка UI Kubernetes не є необхідною.
Ви розробляєте новий API.Ви вже маєте програму, яка обслуговує ваш API та працює добре.
Ви готові прийняти обмеження формату, які Kubernetes накладає на шляхи REST ресурсів, такі як групи API та простори імен. (Дивіться Огляд API.)Вам потрібні специфічні шляхи REST для сумісності з уже визначеним REST API.
Ваші ресурси природно обмежені кластером або просторами імен кластера.Ресурси, обмежені кластером або простором імен, погано підходять; вам потрібен контроль над специфікою шляхів ресурсів.
Ви хочете повторно використовувати функції підтримки API Kubernetes.Вам не потрібні ці функції.

Декларативні API

У декларативному API зазвичай:

  • Ваш API складається з відносно невеликої кількості відносно невеликих обʼєктів (ресурсів).
  • Обʼєкти визначають конфігурацію застосунків або інфраструктури.
  • Обʼєкти оновлюються відносно рідко.
  • Люди часто мають читати та записувати обʼєкти.
  • Основні операції з обʼєктами — це CRUD (створення, читання, оновлення та видалення).
  • Транзакції між обʼєктами не потрібні: API представляє бажаний стан, а не точний стан.

Імперативні API не є декларативними. Ознаки того, що ваш API може не бути декларативним, включають:

  • Клієнт каже "зробіть це", і потім отримує синхронну відповідь, коли це виконано.
  • Клієнт каже "зробіть це", а потім отримує ідентифікатор операції назад і повинен перевірити окремий обʼєкт операції, щоб визначити завершення запиту.
  • Ви говорите про виклики віддалених процедур (RPC).
  • Пряме зберігання великої кількості даних; наприклад, > кілька кБ на обʼєкт, або > 1000 обʼєктів.
  • Потрібен високий доступ до пропускної здатності (десятки запитів на секунду тривалий час).
  • Збереження даних кінцевого користувача (наприклад, зображень, PII тощо) або інших великих обсягів даних, оброблених застосунками.
  • Природні операції з обʼєктами не є CRUD-подібними.
  • API не легко моделюється як обʼєкти.
  • Ви вибрали представлення очікуючих операцій за допомогою ідентифікатора операції або обʼєкта операції.

Чи слід використовувати ConfigMap або власний ресурс?

Використовуйте ConfigMap, якщо застосовується будь-який з наступних пунктів:

  • Існує вже відомий, добре задокументований формат файлу конфігурації, такий як mysql.cnf або pom.xml.
  • Ви хочете помістити всю конфігурацію в один ключ ConfigMap.
  • Основне використання файлу конфігурації — для програми, що працює у Pod у вашому кластері, для використання файлу для самоналаштування.
  • Споживачі файлу вважають за краще отримувати його через файл у Pod або змінну оточення у Pod, а не через Kubernetes API.
  • Ви хочете виконувати послідовне оновлення за допомогою Deployment тощо, коли файл оновлюється.

Використовуйте власний ресурс (CRD або Aggregated API), якщо застосовується більшість з наступних пунктів:

  • Ви хочете використовувати бібліотеки та CLI Kubernetes для створення та оновлення нового ресурсу.
  • Ви хочете отримати підтримку на вищому рівні від kubectl; наприклад, kubectl get my-object object-name.
  • Ви хочете побудувати нову автоматизацію, яка стежить за оновленнями нового обʼєкта, а потім виконує CRUD інших обʼєктів, або навпаки.
  • Ви хочете написати автоматизацію, яка обробляє оновлення обʼєкта.
  • Ви хочете використовувати конвенції Kubernetes API, такі як .spec, .status, та .metadata.
  • Ви хочете, щоб обʼєкт був абстракцією над колекцією контрольованих ресурсів або узагальненням інших ресурсів.

Додавання власних ресурсів

Kubernetes надає два способи додавання власних ресурсів до вашого кластера:

  • CRD (Custom Resource Definition) є простим і може бути створений без будь-якого програмування.
  • API Aggregation потребує програмування, але надає більший контроль над поведінкою API, такою як зберігання даних та конвертація між версіями API.

Kubernetes надає ці два варіанти, щоб задовольнити потреби різних користувачів, щоб ні зручність використання, ні гнучкість не зазнавали утисків.

Агреговані API є підлеглими API-серверами, які розташовані позаду основного API-сервера, який діє як проксі. Ця організація називається API Aggregation(AA). Для користувачів API Kubernetes виглядає розширеним.

CRD дозволяють користувачам створювати нові типи ресурсів без додавання іншого API-сервера. Вам не потрібно розуміти API Aggregation, щоб використовувати CRD.

Незалежно від того, як вони встановлені, нові ресурси називаються Custom Resources, щоб відрізняти їх від вбудованих ресурсів Kubernetes (наприклад, Pod).

CustomResourceDefinitions

API-ресурс CustomResourceDefinition дозволяє вам визначати власні ресурси. Визначення обʼєкта CRD створює новий власний ресурс з імʼям і схемою, яку ви вказуєте. API Kubernetes обслуговує та обробляє зберігання вашого власного ресурсу. Назва самого обʼєкта CRD повинна бути дійсною назвою піддомену DNS, утвореною від визначеної назви ресурсу та його API групи; для детальнішої інформації дивіться як створити CRD. Крім того, назва обʼєкта, чий тип/ресурс визначається CRD, також повинна бути дійсною назвою піддомену DNS.

Це звільняє вас від написання власного API-сервера для обробки власного ресурсу, але загальна природа реалізації означає, що у вас менше гнучкості, ніж з агрегацією сервера API.

Для прикладу того, як зареєструвати новий власний ресурс, для роботи з екземплярами вашого нового типу ресурсу та використовувати контролер для обробки подій, дивіться приклад власного контролера.

Агрегація сервера API

Зазвичай кожен ресурс в API Kubernetes вимагає коду, який обробляє REST-запити та керує постійним зберіганням обʼєктів. Основний сервер API Kubernetes обробляє вбудовані ресурси, такі як Pod та Service, а також узагальнено може керувати власними ресурсами через CRD.

Шар агрегації дозволяє вам надати спеціалізовані реалізації для ваших власних ресурсів, написавши та розгорнувши власний сервер API. Основний сервер API делегує запити до вашого сервера API для власних ресурсів, які ви обробляєте, роблячи їх доступними для всіх його клієнтів.

Вибір методу для додавання власних ресурсів

CRD простіші у використанні. Агреговані API більш гнучкі. Виберіть метод, який найкраще відповідає вашим потребам.

Зазвичай CRD підходять, якщо:

  • У вас багато полів.
  • Ви використовуєте ресурс у своїй компанії або як частину невеликого відкритого проєкту (на відміну від комерційного продукту).

Порівняння простоти використання

Створення CRD простіше, ніж Aggregated APIs.

CRDAggregated API
Не потребує програмування. Користувачі можуть вибрати будь-яку мову для контролера CRD.Вимагає програмування та створення бінарного файлу та образу.
Немає додаткової служби для запуску; CRD обробляються сервером API.Додаткова служба для створення, яка може зазнати невдачі.
Немає підтримки після створення CRD. Будь-які виправлення помилок виконуються як частина звичайних оновлень майстра Kubernetes.Може вимагати періодичного отримування виправлення помилок від постачальника та перебудови та оновлення сервера Aggregated API.
Не потрібно керувати декількома версіями вашого API; наприклад, коли ви контролюєте клієнта для цього ресурсу, ви можете оновлювати його синхронно з API.Потрібно керувати декількома версіями вашого API; наприклад, коли розробляєте розширення для спільного використання.

Розширені функції та гнучкість

Агреговані API пропонують більше розширених можливостей API та налаштування інших функцій; наприклад, рівень зберігання.

ФункціяОписCRDAggregated API
ВалідаціяДопомагає користувачам уникати помилок та дозволяє вам самостійно розвивати ваше API незалежно від ваших клієнтів. Ці функції найбільш корисні, коли є багато клієнтів, які не можуть всі одночасно оновлюватися.Так. Більшість валідацій можуть бути вказані у CRD за допомогою валідації OpenAPI v3.0. Можливість CRDValidationRatcheting дозволяє ігнорувати валідації, вказані за допомогою OpenAPI, якщо збійна частина ресурсу не була змінена. Будь-яка інша валідація підтримується за допомогою Вебхука валідації.Так, довільні перевірки валідації
Стандартне значенняДив. вищеТак, або через валідацію OpenAPI v3.0 за допомогою ключового слова default (GA в 1.17), або через Вебхук мутації (хоча це не буде виконано при зчитуванні з etcd для старих обʼєктів).Так
МультиверсіонністьДозволяє обслуговувати той самий обʼєкт через дві версії API. Може допомогти спростити зміни API, такі як перейменування полів. Менш важливо, якщо ви контролюєте версії вашого клієнта.ТакТак
Власне сховищеЯкщо вам потрібне сховище з іншим режимом продуктивності (наприклад, база даних часових рядів замість сховища ключ-значення) або ізоляція для безпеки (наприклад, шифрування конфіденційної інформації тощо).НемаєТак
Власна бізнес-логікаВиконуйте довільні перевірки або дії при створенні, читанні, оновленні або видаленні обʼєктаТак, за допомогою Вебхуків.Так
Масштабування SubresourceДозволяє системам, таким як HorizontalPodAutoscaler та PodDisruptionBudget, взаємодіяти з вашим новим ресурсомТакТак
Статус SubresourceДозволяє деталізований контроль доступу, де користувач записує розділ spec, а контролер записує розділ status. Дозволяє інкрементувати Generation обʼєкту при мутації даних власного ресурсу (вимагає окремих розділів spec та status у ресурсі).ТакТак
Інші SubresourcesДодавання операцій крім CRUD, таких як "logs" або "exec".НемаєТак
strategic-merge-patchНові точки доступу підтримують PATCH з Content-Type: application/strategic-merge-patch+json. Корисно для оновлення обʼєктів, які можуть бути змінені як локально, так і сервером. Докладніше див. "Оновлення обʼєктів API на місці за допомогою kubectl patch"НемаєТак
Protocol BuffersНовий ресурс підтримує клієнтів, які хочуть використовувати Protocol BuffersНемаєТак
Схема OpenAPIЧи є схема OpenAPI (swagger) для типів, які можуть бути динамічно завантажені з сервера? Чи захищений користувач від помилок у написанні назв полів, забезпечуючи, що лише дозволені поля встановлені? Чи використовуються типи (іншими словами, не розміщуйте int в string полі?)Так, на основі схеми валідації OpenAPI v3.0 (GA в 1.16).Так
Назва екземпляраЧи накладає цей механізм розширення будь-які обмеження на назви обʼєктів, тип/ресурс яких визначено таким чином?Так, назва такого обʼєкта повинна бути дійсною назвою піддомену DNS.Ні

Загальні функції

При створенні власного ресурсу, будь-то через CRD або AA, ви отримуєте багато функцій для вашого API порівняно з його втіленням поза платформою Kubernetes:

ФункціяОпис
CRUDНові точки доступу підтримують CRUD базові операції через HTTP та kubectl
WatchНові точки доступу підтримують операції Watch Kubernetes через HTTP
DiscoveryКлієнти, такі як kubectl та інтерфейс, автоматично пропонують операції list, display та edit для полів у ваших ресурсах
json-patchНові точки доступу підтримують PATCH з Content-Type: application/json-patch+json
merge-patchНові точки доступу підтримують PATCH з Content-Type: application/merge-patch+json
HTTPSНові точки доступу використовують HTTPS
Вбудована автентифікаціяДоступ до розширення використовує ядро сервера API (рівень агрегації) для автентифікації
Вбудована авторизаціяДоступ до розширення може використовувати авторизацію, яка використовується ядром сервера API; наприклад, RBAC.
FinalizersБлокування видалення ресурсів розширення до тих пір, поки не відбудеться зовнішнє очищення.
Admission WebhooksВстановлення стандартних значень та валідація ресурсів розширення під час будь-якої операції створення/оновлення/видалення.
Відображення в інтерфейсі/CLIKubectl, інтерфейс можуть відображати ресурси розширення.
Не встановлено чи ПорожньоКлієнти можуть розрізняти невстановлені поля від полів з нульовим значенням.
Генерація бібліотек клієнтівKubernetes надає загальні бібліотеки клієнтів, а також інструменти для генерації бібліотек клієнтів для конкретних типів даних.
Мітки та анотаціїЗагальні метадані між обʼєктами, для яких інструменти знають, як їх редагувати для основних та власних ресурсів.

Підготовка до встановлення власного ресурсу

Перш ніж додавати власний ресурс до вашого кластера, слід врахувати кілька моментів.

Код від сторонніх розробників та нові точки відмов

Створення CRD не автоматично додає будь-які нові точки відмов (наприклад, за допомогою запуску коду сторонніх розробників на вашому сервері API), проте пакети (наприклад, Charts) або інші збірники для встановлення часто включають CRD, а також Deployment з кодом сторонніх розробників, який реалізує бізнес-логіку для нового власного ресурсу.

Встановлення агрегованого сервера API завжди передбачає запуск нового Deployment.

Зберігання

Власні ресурси споживають місце зберігання так само як і ConfigMaps. Створення занадто великих власних ресурсів може перевантажити простір зберігання сервера API.

Агреговані сервери API можуть використовувати те саме зберігання, що і головний сервер API, в такому разі застосовуються ті самі попередження.

Автентифікація, авторизація та аудит

CRD завжди використовують ту саму автентифікацію, авторизацію та ведення аудиту, що й вбудовані ресурси вашого сервера API.

Якщо ви використовуєте RBAC для авторизації, більшість ролей RBAC не надають доступ до нових ресурсів (окрім ролі cluster-admin або будь-якої ролі, створеної з шаблонами). Вам потрібно явно надати доступ до нових ресурсів. CRD та агреговані сервери API часто постачаються з новими визначеннями ролей для типів, які вони додають.

Агреговані сервери API можуть або не можуть використовувати ту саму автентифікацію, авторизацію та ведення аудиту, що й основний сервер API.

Доступ до власного ресурсу

Бібліотеки клієнтів Kubernetes можна використовувати для доступу до власних ресурсів. Не всі бібліотеки клієнтів підтримують власні ресурси. Go та Python бібліотеки клієнтів це роблять.

Після додавання власного ресурсу ви можете отримати до нього доступ за допомогою:

  • kubectl
  • Динамічного клієнта Kubernetes.
  • REST-клієнта, який ви напишете.
  • Клієнта, згенерованого за допомогою інструментів генерації клієнта Kubernetes (генерація є складним завданням, але деякі проєкти можуть постачати клієнтів разом з CRD або AA).

Селектори полів власних ресурсів

Селектори полів дозволяють клієнтам вибирати власні ресурси за значенням полів одного чи більше ресурсів.

Всі власні ресурси підтримують селектори полів metadata.name та metadata.namespace.

Поля оголошені у CustomResourceDefinition можуть бути використані з селекторами полів, коли вони вказані у полі spec.versions[*].selectableFields в CustomResourceDefinition.

Поля власних ресурсів, які підтримуються селекторами

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.31 [beta]

Поле spec.versions[*].selectableFields в CustomResourceDefinition може бути використане для вказівки, які інші поля в власному ресурсі можуть бути використані в полях селекторах за допомоги функціональної можливості CustomResourceFieldSelectors (яка є увімкенною починаючи з Kubernetes v1.31). Наступний приклад додає поля .spec.color та .spec.size як поля для селекторів.

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: shirts.stable.example.com
spec:
  group: stable.example.com
  scope: Namespaced
  names:
    plural: shirts
    singular: shirt
    kind: Shirt
  versions:
  - name: v1
    served: true
    storage: true
    schema:
      openAPIV3Schema:
        type: object
        properties:
          spec:
            type: object
            properties:
              color:
                type: string
              size:
                type: string
    selectableFields:
    - jsonPath: .spec.color
    - jsonPath: .spec.size
    additionalPrinterColumns:
    - jsonPath: .spec.color
      name: Color
      type: string
    - jsonPath: .spec.size
      name: Size
      type: string

За допомогою полів селекторів можна отримати лише ресурси color зі значенням blue:

kubectl get shirts.stable.example.com --field-selector spec.color=blue

Вивід повинен бути наступним:

NAME       COLOR  SIZE
example1   blue   S
example2   blue   M

Що далі

3.13.2.2 - Шар агрегації API Kubernetes

Шар агрегації дозволяє розширювати можливості Kubernetes за допомогою додаткових API, поза тим, що пропонується ядром основних API Kubernetes. Додаткові API можуть бути як готові рішення, такі як сервер метрик, так і API, які ви розробляєте самостійно.

Шар агрегації відрізняється від Custom Resource Definitions, які є способом зробити так, щоб kube-apiserver визнавав нові види обʼєктів.

Шар агрегації

Шар агрегації працює в процесі разом з kube-apiserver. До того, як розширений ресурс буде зареєстровано, шар агрегації не виконуватиме жодних дій. Для реєстрації API ви додаєте обʼєкт APIService, який "запитує" URL-шлях у Kubernetes API. На цьому етапі шар агрегації буде передавати будь-що, що надійде на цей API-шлях (наприклад, /apis/myextension.mycompany.io/v1/…), зареєстрованому APIService.

Найпоширеніший спосіб реалізації APIService — це запуск розширеного API-сервера в Podʼах, які працюють у вашому кластері. Якщо ви використовуєте розширений API-сервер для управління ресурсами у своєму кластері, розширений API-сервер (також пишеться як "extension-apiserver") зазвичай сполучається з одним або кількома контролерами. Бібліотека apiserver-builder надає кістяк як для розширених API-серверів, так і для відповідних контролерів.

Затримки відповіді

Розширені API-сервери повинні мати малі затримки мережевого звʼязку до та від kube-apiserver. Запити на виявлення повинні долати шлях до та від kube-apiserver до пʼяти секунд або менше.

Якщо ваш розширений API-сервер не може досягти цієї вимоги щодо затримки, розгляньте внесення змін, які дозволять вам відповідати їй.

Що далі

Альтернативно: дізнайтеся, як розширити API Kubernetes, використовуючи визначення власних ресурсів.

3.13.3 - Шаблон Operator

Оператори — це розширення програмного забезпечення для Kubernetes, які використовують власні ресурси для управління застосунками та їх компонентами. Оператори дотримуються принципів Kubernetes, зокрема control loop.

Мотивація

Шаблон operator спрямований на досягнення ключової мети людини-оператора, яка керує сервісом або набором сервісів. Люди-оператори, які відповідають за конкретні застосунки та сервіси, мають глибокі знання про те, як система повинна себе вести, як її розгорнути та як реагувати у разі проблем.

Люди, які запускають робочі навантаження в Kubernetes, часто хочуть використовувати автоматизацію для виконання повторюваних завдань. Шаблон operator показує, як ви можете написати код для автоматизації завдання, яке виходить за межі того, що надає сам Kubernetes.

Оператори в Kubernetes

Kubernetes створений для автоматизації. З коробки ви отримуєте багато вбудованої автоматизації від ядра Kubernetes. Ви можете використовувати Kubernetes для автоматизації розгортання та запуску робочих навантажень, та ви можете автоматизувати те, як це робить Kubernetes.

Концепція шаблону operator Kubernetes дозволяє розширити поведінку кластера без зміни коду самого Kubernetes, звʼязавши контролери з одним або кількома власними ресурсами. Оператори є клієнтами API Kubernetes, які діють як контролери для власного ресурсу.

Приклад оператора

Деякі завдання, які можна автоматизувати за допомогою оператора, включають:

  • розгортання застосунку за запитом
  • створення та відновлення резервних копій стану цього застосунку
  • керування оновленнями коду застосунку разом з повʼязаними змінами, такими як схеми баз даних або додаткові налаштування
  • публікація Serviceʼів для застосунків, які не підтримують Kubernetes API, для їх виявлення
  • емуляція відмови в усьому або частині кластера для перевірки його стійкості
  • обрання лідера для розподіленого застосунку без внутрішнього процесу такого вибору.

Яким може бути оператор у більш детальному вигляді? Ось приклад:

  1. Власний ресурс з назвою SampleDB, який можна налаштувати в кластері.
  2. Deployment, який запускає Pod, що містить частину контролера оператора.
  3. Образ контейнера з кодом оператора.
  4. Код контролера, який надсилає запити до панелі управління, щоб дізнатися, яким чином налаштовано ресурси SampleDB.
  5. Ядром оператора є код, який говорить API серверу, які дії потрібно виконати, щоб поточний стан ресурсу SampleDB відповідав бажаному стану ресурсів.
    • Якщо ви додаєте новий ресурс SampleDB, оператор створює PersistentVolumeClaim для забезпечення місця для надійного зберігання даних, StatefulSet — для запуску SampleDB, та завдання (Job) для ініціалізації бази даних.
    • Якщо ви видаляєте ресурс SampleDB, оператор зробить зліпок з усіх даних, потім переконається, що ресурси StatefulSet та Volume також видалені.
  6. Оператор також керує процесом створення резервних копій бази даних. Для кожного ресурсу SampleDB оператор визначає, коли потрібно створити Pod, який підʼєднається до бази даних, та зробить резервну копію. Ці Podʼи можуть використовувати ConfigMap чи Secret, що містять облікові дані для підʼєднання до бази даних.
  7. Оскільки оператор призначений для надання високого рівня автоматизації для керування ресурсами, тож для цього може використовуватись додатковий код. Наприклад, код, що визначає, чи база даних працює на старій версії, та якщо так, то створює Job для оновлення бази даних.

Розгортання операторів

Найпоширеніший спосіб розгортання операторів — це додавання CustomResourceDefinition (CRD) та контролера для них до вашого кластера. Контролери мають зазвичай запускатись за межами панелі управління кластера, так само як ви запускаєте будь-який інший контейнеризований застосунок. Наприклад, ви можете запустити ваш контролер як Deployment.

Використання операторів

Після того, як ви розгорнете оператора, ви будете використовувати його, додаючи, змінюючи або видаляючи тип ресурсу, який використовує оператор. Наслідуючи наведений вище приклад, ви б налаштували розгортання для самого оператора, а потім:

kubectl get SampleDB                   # пошук налаштованої бази даних

kubectl edit SampleDB/example-database # ручна заміна деяких параметрів

…і все! Оператор візьме на себе роботу застосування змін, а такою як і підтримання сервісу у відповідному стані.

Створення власних операторів

Якщо в екосистемі немає оператора, який реалізує потрібну вам поведінку, ви можете створити власний.

Ви також можете створити оператор (тобто, Контролер) використовуючи мову або рушій виконання, який працює як клієнт API Kubernetes.

Нижче наведено кілька бібліотек та інструментів, які ви можете використовувати для написання власного хмарного оператора.

Що далі

  • Ознайомтесь з CNCF Operator White Paper.
  • Дізнайтесь більше про Custom Resources
  • Пошукайте готові оператори в OperatorHub, що можуть відповідати вашому випадку
  • Опублікуйте свій оператор для використання іншими
  • Подивіться оригінальну статтю від CoreOS, що розповідає про шаблон оператора (тут посилання на архівну версію статті)
  • Ознайомтесь зі статтею від Google Cloud про найкращі практики створення операторів

4 - Завдання

Цей розділ документації Kubernetes містить сторінки, які показують, як виконувати окремі завдання. Сторінка завдання показує, як виконати конкретну дію, зазвичай надаючи коротку послідовність кроків.

Якщо ви хочете написати сторінку завдання, див. Створення запиту на злиття для документації.

4.1 - Встановлення інструментів

Встановлення інструментів Kubernetes на ваш компʼютер.

kubectl

Інструмент командного рядка Kubernetes, kubectl, дозволяє вам виконувати команди відносно кластерів Kubernetes. Ви можете використовувати kubectl для розгортання застосунків, огляду та управління ресурсами кластера, а також перегляду логів. Для отримання додаткової інформації, включаючи повний перелік операцій kubectl, див. Документацію з посилань на kubectl.

kubectl можна встановити на різноманітних платформах Linux, macOS та Windows. Знайдіть свою вибрану операційну систему нижче.

kind

kind дозволяє вам запускати Kubernetes на вашому локальному компʼютері. Цей інструмент вимагає встановлення або Docker, або Podman.

На сторінці Швидкий старт з kind показано, що вам потрібно зробити, щоб розпочати роботу з kind.

Переглянути посібник Швидкий старт з kind

minikube

Подібно до kind, minikube — це інструмент, який дозволяє вам запускати Kubernetes локально. minikube запускає одно- або багатовузловий локальний кластер Kubernetes на вашому персональному компʼютері (включаючи ПК з операційними системами Windows, macOS і Linux), так щоб ви могли випробувати Kubernetes або використовувати його для щоденної розробки.

Якщо ваша основна мета — встановлення інструменту, ви можете скористатися офіційним посібником Швидкий старт.

Переглянути посібник Швидкий старт з Minikube

Якщо у вас вже працює minikube, ви можете використовувати його для запуску застосунку-прикладу.

kubeadm

Ви можете використовувати інструмент kubeadm для створення та управління кластерами Kubernetes. Він виконує необхідні дії для запуску мінімально життєздатного та захищеного кластера за допомогою зручного інтерфейсу користувача.

На сторінці Встановлення kubeadm показано, як встановити kubeadm. Після встановлення ви можете використовувати його для створення кластера.

Переглянути посібник з встановлення kubeadm

4.1.1 - Встановлення та налаштування kubectl у Linux

Перш ніж ви розпочнете

Вам потрібно використовувати версію kubectl, яка має мінорну версію що відрізняється не більше ніж на одиницю від мінорної версії вашого кластера. Наприклад, клієнт v1.31 може співпрацювати з панелями управління v1.30, v1.31 та v1.32. Використання останньої сумісної версії kubectl допомагає уникнути непередбачуваних проблем.

Встановлення kubectl у Linux

Існують наступні методи встановлення kubectl у Linux:

Встановлення бінарного файлу kubectl за допомогою curl у Linux

  1. Завантажте останній випуск за допомогою команди:

    
       curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
       

    
       curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/arm64/kubectl"
       
  2. Перевірте бінарний файл (опційно)

    Завантажте файл хеш-суми kubectl:

    
       curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl.sha256"
       

    
       curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/arm64/kubectl.sha256"
       

    Перевірте бінарний файл kubectl за допомогою файлу хеш-суми:

    echo "$(cat kubectl.sha256)  kubectl" | sha256sum --check
    

    Якщо результат валідний, виведе:

    kubectl: OK
    

    Якщо перевірка не пройшла, sha256 поверне ненульовий статус і виведе повідомлення подібне до:

    kubectl: FAILED
    sha256sum: WARNING: 1 computed checksum did NOT match
    
  3. Встановіть kubectl

    sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl
    
  4. Перевірте, щоб переконатися, що встановлена вами версія є актуальною:

    kubectl version --client
    

    Або скористайтеся цим для детального перегляду версії:

    kubectl version --client --output=yaml
    

Встановлення за допомогою стандартного пакетного менеджера

  1. Оновіть індекс пакунків apt та встановіть пакунки, необхідні для використання репозиторію apt Kubernetes:

    sudo apt-get update
    # apt-transport-https може бути макетним пакетом; якщо так, ви можете пропустити цей пакет
    sudo apt-get install -y apt-transport-https ca-certificates curl gnupg
    
  2. Завантажте публічний ключ підпису для репозиторіїв пакунків Kubernetes. Той самий ключ підпису використовується для всіх репозиторіїв, тому ви можете проігнорувати версію в URL:

    # Якщо тека `/etc/apt/keyrings` не існує, її слід створити перед запуском curl, прочитайте примітку нижче.
    # sudo mkdir -p -m 755 /etc/apt/keyrings
    curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.31/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg
    sudo chmod 644 /etc/apt/keyrings/kubernetes-apt-keyring.gpg # дозволяє непривілейованим програмам APT читати цей ключ
    
  1. Додайте відповідний репозиторій Kubernetes apt. Якщо ви хочете використовувати версію Kubernetes, відмінну від v1.31, замініть v1.31 на потрібну мінорну версію в команді нижче:

    # Це перезапише будь-яку існуючу конфігурацію в /etc/apt/sources.list.d/kubernetes.list
    echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.31/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list
    sudo chmod 644 /etc/apt/sources.list.d/kubernetes.list   # допомагає правильно працювати з такими інструментами, як command-not-found
    
  1. Оновіть індекс пакунків apt, а потім встановіть kubectl:

    sudo apt-get update
    sudo apt-get install -y kubectl
    

  1. Додайте репозиторій Kubernetes yum. Якщо ви хочете використовувати версію Kubernetes, відмінну від v1.31, замініть v1.31 на потрібну мінорну версію в команді нижче.

    # Це перезапише будь-яку існуючу конфігурацію у /etc/yum.repos.d/kubernetes.repo
    cat <<EOF | sudo tee /etc/yum.repos.d/kubernetes.repo
    [kubernetes]
    name=Kubernetes
    baseurl=https://pkgs.k8s.io/core:/stable:/v1.31/rpm/
    enabled=1
    gpgcheck=1
    gpgkey=https://pkgs.k8s.io/core:/stable:/v1.31/rpm/repodata/repomd.xml.key
    EOF
    
  1. Встановіть kubectl за допомогою yum:

    sudo yum install -y kubectl
    

  1. Додайте репозиторій Kubernetes zypper. Якщо ви хочете використовувати версію Kubernetes, відмінну від v1.31, замініть v1.31 на потрібну мінорну версію в команді нижче.

    # Це перезапише будь-яку існуючу конфігурацію у /etc/zypp/repos.d/kubernetes.repo
    cat <<EOF | sudo tee /etc/zypp/repos.d/kubernetes.repo
    [kubernetes]
    name=Kubernetes
    baseurl=https://pkgs.k8s.io/core:/stable:/v1.31/rpm/
    enabled=1
    gpgcheck=1
    gpgkey=https://pkgs.k8s.io/core:/stable:/v1.31/rpm/repodata/repomd.xml.key
    EOF
    
  1. Оновіть zypper і підтвердіть додавання нового репозиторію:

    sudo zypper update
    

    Коли зʼявиться таке повідомлення, натисніть 't' або 'a':

    New repository or package signing key received:
    
    Repository:       Kubernetes
    Key Fingerprint:  1111 2222 3333 4444 5555 6666 7777 8888 9999 AAAA
    Key Name:         isv:kubernetes OBS Project <isv:kubernetes@build.opensuse.org>
    Key Algorithm:    RSA 2048
    Key Created:      Thu 25 Aug 2022 01:21:11 PM -03
    Key Expires:      Sat 02 Nov 2024 01:21:11 PM -03 (expires in 85 days)
    Rpm Name:         gpg-pubkey-9a296436-6307a177
    
    Note: Signing data enables the recipient to verify that no modifications occurred after the data
    were signed. Accepting data with no, wrong or unknown signature can lead to a corrupted system
    and in extreme cases even to a system compromise.
    
    Note: A GPG pubkey is clearly identified by its fingerprint. Do not rely on the key's name. If
    you are not sure whether the presented key is authentic, ask the repository provider or check
    their web site. Many providers maintain a web page showing the fingerprints of the GPG keys they
    are using.
    
    Do you want to reject the key, trust temporarily, or trust always? [r/t/a/?] (r): a
    
  2. Встановіть kubectl, використовуючи zypper:

    sudo zypper install -y kubectl
    

Встановлення за допомогою іншого пакетного менеджера

Якщо ви користуєтеся Ubuntu або іншим дистрибутивом Linux, який підтримує менеджер пакунків snap, kubectl доступний як застосунок snap.

snap install kubectl --classic
kubectl version --client

Якщо ви користуєтеся Linux і використовуєте пакетний менеджер Homebrew, kubectl доступний для встановлення.

brew install kubectl
kubectl version --client

Перевірка конфігурації Verify

Щоб kubectl знайшов та отримав доступ до кластера Kubernetes, вам потрібен файл kubeconfig, який створюється автоматично при створенні кластера за допомогою kube-up.sh або успішного розгортання кластера Minikube. Типово конфігурація kubectl знаходиться в ~/.kube/config.

Перевірте, що kubectl належним чином налаштований, отримавши стан кластера:

kubectl cluster-info

Якщо ви бачите у відповідь URL, kubectl налаштований на доступ до вашого кластера.

Якщо ви бачите повідомлення, подібне до наведеного нижче, kubectl не налаштований належним чином або не може приєднатися до кластера Kubernetes.

The connection to the server <server-name:port> was refused - did you specify the right host or port?

Наприклад, якщо ви плануєте запустити кластер Kubernetes на своєму ноутбуці (локально), вам спочатку потрібно встановити інструмент, такий як Minikube, а потім повторно виконати вказані вище команди.

Якщо kubectl cluster-info повертає у відповідь URL, але ви не можете отримати доступ до свого кластера, щоб перевірити, чи він налаштований належним чином, використовуйте:

kubectl cluster-info dump

Усунення несправностей повідомлення про помилку 'No Auth Provider Found'

У Kubernetes 1.26, kubectl видалив вбудовану автентифікацію для Kubernetes-кластерів керованих хмарними провайдерами. Ці провайдери випустили втулок для kubectl для надання хмарно-специфічної автентифікації. Для інструкцій див. документацію відповідного провайдера:

(Також можуть бути інші причини для показу цього повідомлення про помилку, не повʼязані з цією зміною.)

Необовʼязкові налаштування та втулки kubectl

Увімкнення функціонала автодоповнення оболонки

kubectl надає підтримку автодоповнення для оболонок Bash, Zsh, Fish та PowerShell, що може зекономити вам багато часу на набір тексту.

Нижче наведені процедури для налаштування автодоповнення для оболонок Bash, Fish та Zsh.

Вступ

Сценарій автодоповнення kubectl для Bash може бути створений за допомогою команди kubectl completion bash. Підключення цього сценарію у вашій оболонці дозволить вам мати автодоповнення для kubectl.

Однак сценарій залежить від bash-completion, що означає, що спочатку вам потрібно встановити цей скрипт (ви можете перевірити, чи вже встановлено bash-completion, виконавши команду type _init_completion).

Встановлення bash-completion

bash-completion надається багатьма менеджерами пакунків (див. тут). Ви можете встановити його за допомогою apt-get install bash-completion або yum install bash-completion тощо.

Вищевказані команди створюють /usr/share/bash-completion/bash_completion, який є основним сценарієм bash-completion. Залежно від вашого менеджера пакунків, вам доведеться вручну додати цей файл у ваш ~/.bashrc файл.

Щоб дізнатися, перезавантажте вашу оболонку і виконайте type _init_completion. Якщо команда виконується успішно, значить, ви вже його встановили, інакше додайте наступне до вашого ~/.bashrc файлу:

source /usr/share/bash-completion/bash_completion

Перезавантажте вашу оболонку і перевірте, чи bash-completion правильно встановлено, ввівши type _init_completion.

Увімкнення автодоповнення kubectl

Bash

Тепер вам потрібно переконатися, що сценарій автодоповнення kubectl підключений у всіх ваших сеансах оболонки. Є два способи, якими це можна зробити:


echo 'source <(kubectl completion bash)' >>~/.bashrc


kubectl completion bash | sudo tee /etc/bash_completion.d/kubectl > /dev/null
sudo chmod a+r /etc/bash_completion.d/kubectl

Якщо у вас є аліас для kubectl, ви можете розширити автодоповнення оболонки, щоб воно працювало з ним:

echo 'alias k=kubectl' >>~/.bashrc
echo 'complete -o default -F __start_kubectl k' >>~/.bashrc

Обидва підходи еквівалентні. Після перезавантаження вашої оболонки автодоповнення kubectl повинно працювати. Щоб увімкнути автодоповнення bash у поточному сеансі оболонки, переініціалізуйте файл ~/.bashrc:

source ~/.bashrc

Сценарій автозавершення kubectl для Fish може бути створений за допомогою команди kubectl completion fish. Підключення цього сценарію автозавершення у вашій оболонці вмикає автодоповнення для kubectl.

Щоб зробити це у всіх сеансах вашої оболонки, додайте наступний рядок до вашого файлу ~/.config/fish/config.fish:

kubectl completion fish | source

Після перезавантаження вашої оболонки, автодоповнення kubectl повинно працювати.

Сценарій автозавершення kubectl для Zsh може бути створений за допомогою команди kubectl completion zsh. Підключення цього сценарію автозавершення у вашій оболонці дозволяє ввімкнути автодоповнення для kubectl.

Щоб зробити це у всіх сеансах вашої оболонки, додайте наступне до вашого файлу ~/.zshrc:

source <(kubectl completion zsh)

Якщо у вас є аліас для kubectl, автодоповнення kubectl автоматично працюватиме з ним.

Після перезавантаження вашої оболонки автодоповнення kubectl повинно працювати.

Якщо ви отримуєте помилку типу 2: command not found: compdef, то додайте наступне до початку вашого файлу ~/.zshrc:

autoload -Uz compinit
compinit

Встановлення втулка kubectl convert

Втулок для командного рядка Kubernetes kubectl, який дозволяє конвертувати маніфести між різними версіями API. Це може бути особливо корисно для міграції маніфестів до версій API, які все ще є актуальними, на новіші випуски Kubernetes. Для отримання додаткової інформації відвідайте перехід на актуальні API.

  1. Завантажте останній випуск за допомогою наступної команди:

    
       curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl-convert"
       

    
       curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/arm64/kubectl-convert"
       
  2. Перевірте бінарний файл (опціонально)

    Завантажте файл контрольної суми для kubectl-convert:

    
       curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl-convert.sha256"
       

    
       curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/arm64/kubectl-convert.sha256"
       

    Перевірте бінарний файл kubectl-convert за допомогою файлу контрольної суми:

    echo "$(cat kubectl-convert.sha256) kubectl-convert" | sha256sum --check
    

    Якщо перевірка пройшла успішно, вивід буде таким:

    kubectl-convert: OK
    

    Якщо перевірка не вдалася, sha256 виходить з ненульовим статусом і виводить подібне повідомлення:

    kubectl-convert: FAILED
    sha256sum: WARNING: 1 computed checksum did NOT match
    
  3. Встановіть kubectl-convert

    sudo install -o root -g root -m 0755 kubectl-convert /usr/local/bin/kubectl-convert
    
  4. Перевірте, чи втулок успішно встановлено

    kubectl convert --help
    

    Якщо ви не бачите помилку, це означає, що втулок успішно встановлено.

  5. Після встановлення втулка, вилучіть файли встановлення:

    rm kubectl-convert kubectl-convert.sha256
    

Що далі

4.1.2 - Встановлення та налаштування kubectl у macOS

Перш ніж ви розпочнете

Вам потрібно використовувати версію kubectl, яка має мінорну версію що відрізняється не більше ніж на одиницю від мінорної версії вашого кластера. Наприклад, клієнт v1.31 може співпрацювати з панелями управління v1.30, v1.31 та v1.32. Використання останньої сумісної версії kubectl допомагає уникнути непередбачуваних проблем.

Встановлення kubectl у macOS

Існують наступні методи встановлення kubectl у macOS:

Встановлення бінарника kubectl з curl у macOS

  1. Завантажте останнє видання:

    
       curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl"
       

    
       curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/arm64/kubectl"
       
  2. Перевірте бінарний файл (опціонально)

    Завантажте файл контрольної суми для kubectl:

    
       curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl.sha256"
       

    
       curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/arm64/kubectl.sha256"
       

    Перевірте бінарний файл kubectl за допомогою файлу контрольної суми:

    echo "$(cat kubectl.sha256)  kubectl" | shasum -a 256 --check
    

    Якщо перевірка пройшла успішно, вивід буде таким:

    kubectl: OK
    

    Якщо перевірка не вдалася, shasum виходить з ненульовим статусом і виводить подібне повідомлення:

    kubectl: FAILED
    shasum: WARNING: 1 computed checksum did NOT match
    
  3. Зробіть бінарний файл kubectl виконуваним.

    chmod +x ./kubectl
    
  4. Перемістіть бінарний файл kubectl до розташування файлу на вашій системі PATH.

    sudo mv ./kubectl /usr/local/bin/kubectl
    sudo chown root: /usr/local/bin/kubectl
    
  5. Перевірте, що встановлена версія kubectl актуальна:

    kubectl version --client
    

    Або використовуйте це для детального перегляду версії:

    kubectl version --client --output=yaml
    
  6. Після встановлення та перевірки kubectl видаліть файл контрольної суми:

    rm kubectl.sha256
    

Встановлення за допомогою Homebrew у macOS

Якщо ви користуєтеся macOS і пакетним менеджером Homebrew, ви можете встановити kubectl за допомогою Homebrew.

  1. Виконайте команду встановлення:

    brew install kubectl
    

    або

    brew install kubernetes-cli
    
  2. Перевірте, що встановлена версія актуальна:

    kubectl version --client
    

Встановлення за допомогою Macports у macOS

Якщо ви користуєтеся macOS і пакетним менеджером Macports, ви можете встановити kubectl за допомогою Macports.

  1. Виконайте команду встановлення:

    sudo port selfupdate
    sudo port install kubectl
    
  2. Перевірте, що встановлена версія актуальна:

    kubectl version --client
    

Перевірка конфігурації kubectl

Щоб kubectl знайшов та отримав доступ до кластера Kubernetes, вам потрібен файл kubeconfig, який створюється автоматично при створенні кластера за допомогою kube-up.sh або успішного розгортання кластера Minikube. Типово конфігурація kubectl знаходиться в ~/.kube/config.

Перевірте, що kubectl належним чином налаштований, отримавши стан кластера:

kubectl cluster-info

Якщо ви бачите у відповідь URL, kubectl налаштований на доступ до вашого кластера.

Якщо ви бачите повідомлення, подібне до наведеного нижче, kubectl не налаштований належним чином або не може приєднатися до кластера Kubernetes.

The connection to the server <server-name:port> was refused - did you specify the right host or port?

Наприклад, якщо ви плануєте запустити кластер Kubernetes на своєму ноутбуці (локально), вам спочатку потрібно встановити інструмент, такий як Minikube, а потім повторно виконати вказані вище команди.

Якщо kubectl cluster-info повертає у відповідь URL, але ви не можете отримати доступ до свого кластера, щоб перевірити, чи він налаштований належним чином, використовуйте:

kubectl cluster-info dump

Усунення несправностей повідомлення про помилку 'No Auth Provider Found'

У Kubernetes 1.26, kubectl видалив вбудовану автентифікацію для Kubernetes-кластерів керованих хмарними провайдерами. Ці провайдери випустили втулок для kubectl для надання хмарно-специфічної автентифікації. Для інструкцій див. документацію відповідного провайдера:

(Також можуть бути інші причини для показу цього повідомлення про помилку, не повʼязані з цією зміною.)

Опціональне налаштування kubectl та втулка

Увімкнення автопідстановки оболонки

kubectl надає підтримку автодоповнення для оболонок Bash, Zsh, Fish та PowerShell, що може значно зекономити ваш час при введенні команд.

Нижче подані процедури для налаштування автодоповнення для оболонок Bash, Fish та Zsh.

Вступ

Сценарій автодоповнення для Bash kubectl можна згенерувати за допомогою команди kubectl completion bash. Підключення цього сценарію в вашій оболонці дозволяє використовувати автодоповнення для kubectl.

Проте, сценарій автодоповнення для kubectl залежить від bash-completion, який потрібно встановити заздалегідь.

Оновлення Bash

Інструкції тут передбачають, що ви використовуєте Bash 4.1+. Ви можете перевірити версію свого Bash, виконавши:

echo $BASH_VERSION

Якщо вона є занадто старою, ви можете встановити/оновити її за допомогою Homebrew:

brew install bash

Перезавантажте вашу оболонку і перевірте, що використовується бажана версія:

echo $BASH_VERSION $SHELL

Зазвичай Homebrew встановлює його в /usr/local/bin/bash.

Встановлення bash-completion

Ви можете перевірити, чи вже встановлена bash-completion v2, використавши команду type _init_completion. Якщо ні, ви можете встановити її за допомогою Homebrew:

brew install bash-completion@2

Як зазначено в виводі цієї команди, додайте наступне до вашого файлу ~/.bash_profile:

brew_etc="$(brew --prefix)/etc" && [[ -r "${brew_etc}/profile.d/bash_completion.sh" ]] && . "${brew_etc}/profile.d/bash_completion.sh"

Перезавантажте вашу оболонку і перевірте, що bash-completion v2 встановлена коректно за допомогою type _init_completion.

Активація автодоповнення для kubectl

Тепер вам потрібно забезпечити, щоб сценарій автодоповнення для kubectl підключався в усіх ваших сеансах оболонки. Існують кілька способів досягнення цього:

  • Підключіть сценарій автодоповнення до вашого файлу ~/.bash_profile:

    echo 'source <(kubectl completion bash)' >>~/.bash_profile
    
  • Додайте сценарій автодоповнення до теки /usr/local/etc/bash_completion.d:

    kubectl completion bash >/usr/local/etc/bash_completion.d/kubectl
    
  • Якщо у вас є аліас для kubectl, ви можете розширити автодоповнення оболонки, щоб воно працювало з цим аліасом:

    echo 'alias k=kubectl' >>~/.bash_profile
    echo 'complete -o default -F __start_kubectl k' >>~/.bash_profile
    
  • Якщо ви встановили kubectl за допомогою Homebrew (як пояснено тут), то сценарій автодоповнення для kubectl вже повинен знаходитися у /usr/local/etc/bash_completion.d/kubectl. У цьому випадку вам нічого робити не потрібно.

У будь-якому випадку, після перезавантаження оболонки, автодоповнення для kubectl повинно працювати.

Сценарій автозавершення kubectl для Fish може бути створений за допомогою команди kubectl completion fish. Підключення цього сценарію автозавершення у вашій оболонці вмикає автодоповнення для kubectl.

Щоб зробити це у всіх сеансах вашої оболонки, додайте наступний рядок до вашого файлу ~/.config/fish/config.fish:

kubectl completion fish | source

Після перезавантаження вашої оболонки, автодоповнення kubectl повинно працювати.

Сценарій автозавершення kubectl для Zsh може бути створений за допомогою команди kubectl completion zsh. Підключення цього сценарію автозавершення у вашій оболонці дозволяє ввімкнути автодоповнення для kubectl.

Щоб зробити це у всіх сеансах вашої оболонки, додайте наступне до вашого файлу ~/.zshrc:

source <(kubectl completion zsh)

Якщо у вас є аліас для kubectl, автодоповнення kubectl автоматично працюватиме з ним.

Після перезавантаження вашої оболонки автодоповнення kubectl повинно працювати.

Якщо ви отримуєте помилку типу 2: command not found: compdef, то додайте наступне до початку вашого файлу ~/.zshrc:

autoload -Uz compinit
compinit

Встановлення втулка kubectl convert

Втулок для командного рядка Kubernetes kubectl, який дозволяє конвертувати маніфести між різними версіями API. Це може бути особливо корисно для міграції маніфестів до версій API, які все ще є актуальними, на новіші випуски Kubernetes. Для отримання додаткової інформації відвідайте перехід на актуальні API.

  1. Завантажте останній випуск команди:

    
       curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl-convert"
       

    
       curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/arm64/kubectl-convert"
       
  2. Перевірте двійковий файл (опціонально):

    Завантажте файл контрольної суми для kubectl-convert:

    
       curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl-convert.sha256"
       

    
       curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/arm64/kubectl-convert.sha256"
       

    Перевірте двійковий файл kubectl-convert за допомогою файлу контрольної суми:

    echo "$(cat kubectl-convert.sha256)  kubectl-convert" | shasum -a 256 --check
    

    Якщо перевірка пройшла успішно, вивід буде таким:

    kubectl-convert: OK
    

    Якщо перевірка не вдалася, shasum виходить з ненульовим статусом і виводить подібне повідомлення:

    kubectl-convert: FAILED
    shasum: WARNING: 1 computed checksum did NOT match
    
  3. Зробіть двійковий файл kubectl-convert виконуваним.

    chmod +x ./kubectl-convert
    
  4. Перемістіть двійковий файл kubectl-convert до розташування файлу у вашій системі PATH.

    sudo mv ./kubectl-convert /usr/local/bin/kubectl-convert
    sudo chown root: /usr/local/bin/kubectl-convert
    
  5. Перевірте, що втулок було встановлено:

    kubectl convert --help
    

    Якщо ви не бачите жодних помилок, втулок було встановлено успішно.

  6. Після встановлення та перевірки kubectl-convert видаліть файл контрольної суми:

    rm kubectl-convert kubectl-convert.sha256
    

Видалення kubectl

Залежно від того, як ви встановили kubectl, використовуйте один з наступних методів.

Видалення kubectl за допомогою командного рядка

  1. Знайдіть бінарний файл kubectl у вашій системі:

    which kubectl
    
  2. Видаліть бінарний файл kubectl:

    sudo rm <path>
    

    Замініть <path> на шлях до бінарного файлу kubectl з попереднього кроку. Наприклад, sudo rm /usr/local/bin/kubectl.

Видалення kubectl за допомогою Homebrew

Якщо ви встановили kubectl за допомогою Homebrew, виконайте наступну команду:

brew remove kubectl

Що далі

4.1.3 - Встановлення та налаштування kubectl у Windows

Перш ніж ви розпочнете

Вам потрібно використовувати версію kubectl, яка має мінорну версію що відрізняється не більше ніж на одиницю від мінорної версії вашого кластера. Наприклад, клієнт v1.31 може співпрацювати з панелями управління v1.30, v1.31 та v1.32. Використання останньої сумісної версії kubectl допомагає уникнути непередбачуваних проблем.

Встановлення kubectl у Windows

Існують наступні методи встановлення kubectl у Windows:

Встановлення бінарника kubectl у Windows (за допомогою прямого завантаження або за допомогою curl)

  1. У вас є два варіанти встановлення kubectl на вашому пристрої з Windows

    • Безпосереднє завантаження:

      Завантажте останню версію 1.31 патчу безпосередньо для вашої архітектури, відвідавши сторінку випуску Kubernetes. Переконайтеся, що вибрано правильний двійковий файл для вашої архітектури (наприклад, amd64, arm64 тощо).

    • Використовуючи curl

      Або, якщо у вас встановлено curl, використовуйте цю команду:

      curl.exe -LO "https://dl.k8s.io/release/v1.31.0/bin/windows/amd64/kubectl.exe"
      
  2. Перевірте бінарний файл (опціонально)

    Завантажте файл контрольної суми для kubectl:

    curl.exe -LO "https://dl.k8s.io/v1.31.0/bin/windows/amd64/kubectl.exe.sha256"
    

    Перевірте бінарний файл kubectl за допомогою файлу контрольної суми:

    • Використовуючи командний рядок для ручного порівняння виводу CertUtil з завантаженим файлом контрольної суми:

      CertUtil -hashfile kubectl.exe SHA256
      type kubectl.exe.sha256
      
    • Використовуючи PowerShell для автоматизації перевірки за допомогою оператора -eq для отримання результату True або False:

      Compare-String -eq (Get-FileHash kubectl.exe -Algorithm SHA256).Hash (Get-Content kubectl.exe.sha256)
      
  3. Додайте на початок чи в кінець змінної середовища PATH шлях до теки з kubectl.

  4. Перевірте, що версія kubectl збігається з завантаженою:

    kubectl version --client
    

    Або використайте це для детального перегляду версії:

    kubectl version --client --output=yaml
    

Встановлення на Windows за допомогою Chocolatey, Scoop або winget

  1. Для встановлення kubectl у Windows ви можете використовувати пакетний менеджер Chocolatey, командний інсталятор Scoop, або менеджер пакунків winget.

    choco install kubernetes-cli
    

    scoop install kubectl
    

    winget install -e --id Kubernetes.kubectl
    
  2. Перевірте, що встановлена версія оновлена:

    kubectl version --client
    
  3. Перейдіть до вашого домашнього каталогу:

    # Якщо ви використовуєте cmd.exe, виконайте: cd %USERPROFILE%
    cd ~
    
  4. Створіть каталог .kube:

    mkdir .kube
    
  5. Перейдіть до каталогу .kube, що ви щойно створили:

    cd .kube
    
  6. Налаштуйте kubectl для використання віддаленого кластера Kubernetes:

    New-Item config -type file
    

Перевірка конфігурації kubectl

Щоб kubectl знайшов та отримав доступ до кластера Kubernetes, вам потрібен файл kubeconfig, який створюється автоматично при створенні кластера за допомогою kube-up.sh або успішного розгортання кластера Minikube. Типово конфігурація kubectl знаходиться в ~/.kube/config.

Перевірте, що kubectl належним чином налаштований, отримавши стан кластера:

kubectl cluster-info

Якщо ви бачите у відповідь URL, kubectl налаштований на доступ до вашого кластера.

Якщо ви бачите повідомлення, подібне до наведеного нижче, kubectl не налаштований належним чином або не може приєднатися до кластера Kubernetes.

The connection to the server <server-name:port> was refused - did you specify the right host or port?

Наприклад, якщо ви плануєте запустити кластер Kubernetes на своєму ноутбуці (локально), вам спочатку потрібно встановити інструмент, такий як Minikube, а потім повторно виконати вказані вище команди.

Якщо kubectl cluster-info повертає у відповідь URL, але ви не можете отримати доступ до свого кластера, щоб перевірити, чи він налаштований належним чином, використовуйте:

kubectl cluster-info dump

Усунення несправностей повідомлення про помилку 'No Auth Provider Found'

У Kubernetes 1.26, kubectl видалив вбудовану автентифікацію для Kubernetes-кластерів керованих хмарними провайдерами. Ці провайдери випустили втулок для kubectl для надання хмарно-специфічної автентифікації. Для інструкцій див. документацію відповідного провайдера:

(Також можуть бути інші причини для показу цього повідомлення про помилку, не повʼязані з цією зміною.)

Опціональні конфігурації та втулки kubectl

Увімкнення автопідстановки оболонки

kubectl надає підтримку автодоповнення для оболонок Bash, Zsh, Fish та PowerShell, що може значно зекономити ваш час при введенні команд.

Нижче подані процедури для налаштування автодоповнення для PowerShell.

Скрипт автодоповнення для kubectl в PowerShell можна згенерувати командою kubectl completion powershell.

Для того, щоб це працювало у всіх сесіях вашої оболонки, додайте наступний рядок до вашого файлу $PROFILE:

kubectl completion powershell | Out-String | Invoke-Expression

Ця команда буде генерувати скрипт автодоповнення при кожному запуску PowerShell. Ви також можете додати згенерований скрипт безпосередньо до вашого файлу $PROFILE.

Щоб додати згенерований скрипт до вашого файлу $PROFILE, виконайте наступний рядок у вашому PowerShell:

kubectl completion powershell >> $PROFILE

Після перезавантаження вашої оболонки автодоповнення для kubectl має працювати.

Встановлення втулка kubectl convert

Втулок для командного рядка Kubernetes kubectl, який дозволяє конвертувати маніфести між різними версіями API. Це може бути особливо корисно для міграції маніфестів до версій API, які все ще є актуальними, на новіші випуски Kubernetes. Для отримання додаткової інформації відвідайте перехід на актуальні API.

  1. Завантажте останній випуск команди:

    curl.exe -LO "https://dl.k8s.io/v1.31.0/bin/windows/amd64/kubectl-convert.exe"
    
  2. Перевірте двійковий файл (опціонально).

    Завантажте файл контрольної суми для kubectl-convert:

    curl.exe -LO "https://dl.k8s.io/v1.31.0/bin/windows/amd64/kubectl-convert.exe.sha256"
    

    Перевірте бінарний файл kubectl-convert за допомогою файлу контрольної суми:

    • Використовуючи командний рядок для ручного порівняння виводу CertUtil з завантаженим файлом контрольної суми:

      CertUtil -hashfile kubectl-convert.exe SHA256
      type kubectl-convert.exe.sha256
      
    • Використовуючи PowerShell для автоматизації перевірки за допомогою оператора -eq для отримання результату True або False:

      Compare-String -eq (Get-FileHash kubectl-convert.exe -Algorithm SHA256).Hash (Get-Content kubectl-convert.exe.sha256)
      
  3. Додайте на початок чи в кінець змінної середовища PATH шлях до теки з kubectl-convert.

  4. Перевірте, що версія kubectl-convert збігається з завантаженою:

    kubectl-convert version
    

    Або використайте це для детального перегляду версії:

    kubectl-convert version --output=yaml
    
  5. Після встановлення втулка, вилучіть інсталяційні файли:

    Remove-Item kubectl-convert.exe
    Remove-Item kubectl-convert.exe.sha256
    

Що далі

4.2 - Адміністрування кластера

Дізнайтеся про загальні завдання адміністрування кластера.

4.2.1 - Адміністрування з kubeadm

Якщо у вас немає кластера, зверніться до сторінки Запуск кластерів з kubeadm.

Завдання в цьому розділі призначені для адміністрування наявного кластера:

4.2.1.1 - Додавання робочих вузлів Linux

Ця сторінка пояснює, як додати робочі вузли Linux до кластера, створеного за допомогою kubeadm.

Перш ніж ви розпочнете

Додавання робочих вузлів Linux

Щоб додати нові робочі вузли Linux до кластера, виконайте наступне для кожної машини:

  1. Підʼєднатесь до машини за допомогою SSH або іншого методу.
  2. Запустіть команду, яка була виведена kubeadm init. Наприклад:
sudo kubeadm join \
  --token <token> <control-plane-host>:<control-plane-port> \
  --discovery-token-ca-cert-hash sha256:<hash>

Додаткова інформація для kubeadm join

Якщо у вас немає токена, ви можете отримати його, запустивши наступну команду на вузлі панелі управління:

# Запустіть це на вузлі панелі управління
sudo kubeadm token list

Вивід буде приблизно таким:

TOKEN                    TTL  EXPIRES              USAGES           DESCRIPTION            EXTRA GROUPS
8ewj1p.9r9hcjoqgajrj4gi  23h  2018-06-12T02:51:28Z authentication,  The default bootstrap  system:
                                                   signing          token generated by     bootstrappers:
                                                                    'kubeadm init'.        kubeadm:
                                                                                           default-node-token

Стандартно токени для приєднання вузлів мають термін дії 24 години. Якщо ви додаєте вузол до кластера після того, як поточний токен закінчився, ви можете створити новий токен, виконавши наступну команду на вузлі панелі управління:

# Запустіть це на вузлі панелі управління
sudo kubeadm token create

Вивід буде приблизно таким:

5didvk.d09sbcov8ph2amjw

Якщо у вас немає значення --discovery-token-ca-cert-hash, ви можете отримати його, виконавши наступні команди на вузлі панелі управління:

# Запустіть це на вузлі панелі управління
sudo cat /etc/kubernetes/pki/ca.crt | \
  openssl x509 -pubkey  | \
  openssl rsa -pubin -outform der 2>/dev/null | \
  openssl dgst -sha256 -hex | \
  sed 's/^.* //'

Вивід буде приблизно таким:

8cb2de97839780a412b93877f8507ad6c94f73add17d5d7058e91741c9d5ec78

Вивід команди kubeadm join має виглядати приблизно так:

[preflight] Running pre-flight checks

... (вивід процесу приєднання) ...

Node join complete:
* Запит на підписання сертифікату надіслано до панелі управління, отримано відповідь.
* Kubelet проінформований про нові деталі безпечного зʼєднання.

Запустіть 'kubectl get nodes' на панелі управління, щоб побачити приєднання цього вузла.

Через кілька секунд ви повинні побачити цей вузол у виводі команди kubectl get nodes. (наприклад, запустіть kubectl на вузлі панелі управління).

Що далі

4.2.1.2 - Додавання робочих вузлів Windows

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.18 [beta]

Ця сторінка пояснює, як додати робочі вузли Windows до кластера kubeadm.

Перш ніж ви розпочнете

  • Запущений екземпляр Windows Server 2022 (або новіший) з адміністративним доступом.
  • Запущений кластер kubeadm, створений за допомогою kubeadm init та з дотриманням кроків з документа Створення кластера з kubeadm.

Додавання робочих вузлів Windows

Виконайте наступні кроки для кожної машини:

  1. Відкрийте сесію PowerShell на машині.
  2. Переконайтеся, що ви є адміністратором або привілейованим користувачем.

Потім виконайте наведені нижче кроки.

Встановлення containerd

Щоб встановити containerd, спочатку виконайте наступну команду:

curl.exe -LO https://raw.githubusercontent.com/kubernetes-sigs/sig-windows-tools/master/hostprocess/Install-Containerd.ps1

Потім виконайте наступну команду, але спочатку замініть CONTAINERD_VERSION на нещодавній реліз з репозиторію containerd. Версія не повинна містити префікс v. Наприклад, використовуйте 1.7.22 замість v1.7.22:

.\Install-Containerd.ps1 -ContainerDVersion CONTAINERD_VERSION
  • Налаштуйте будь-які інші параметри для Install-Containerd.ps1, такі як netAdapterName, за необхідності.
  • Встановіть skipHypervisorSupportCheck, якщо ваша машина не підтримує Hyper-V і не може розміщувати контейнери ізольовані Hyper-V.
  • Якщо ви змінюєте необовʼязкові параметри CNIBinPath та/або CNIConfigPath у Install-Containerd.ps1, вам потрібно буде налаштувати встановлений втулок CNI Windows з відповідними значеннями.

Встановлення kubeadm і kubelet

Виконайте наступні команди для установки kubeadm і kubelet:

curl.exe -LO https://raw.githubusercontent.com/kubernetes-sigs/sig-windows-tools/master/hostprocess/PrepareNode.ps1
.\PrepareNode.ps1 -KubernetesVersion v1.31
  • Налаштуйте параметр KubernetesVersion у PrepareNode.ps1 за необхідності.

Запуск kubeadm join

Виконайте команду, з виводу kubeadm init. Наприклад:

kubeadm join --token <token> <control-plane-host>:<control-plane-port> --discovery-token-ca-cert-hash sha256:<hash>

Додаткова інформація про kubeadm join

Якщо у вас немає токена, ви можете отримати його, виконавши наступну команду на вузлі панелі управління:

# Виконайте це на вузлі панелі управління
sudo kubeadm token list

Вивід буде подібний до цього:

TOKEN                    TTL  EXPIRES              USAGES           DESCRIPTION            EXTRA GROUPS
8ewj1p.9r9hcjoqgajrj4gi  23h  2018-06-12T02:51:28Z authentication,  The default bootstrap  system:
                                                   signing          token generated by     bootstrappers:
                                                                    'kubeadm init'.        kubeadm:
                                                                                           default-node-token

Стандартно, токени приєднання вузлів діють 24 години. Якщо ви приєднуєте вузол до кластера після того, як токен закінчився, ви можете створити новий токен, виконавши наступну команду на вузлі панелі управління:

# Виконайте це на вузлі панелі управління
sudo kubeadm token create

Вивід буде подібний до цього:

5didvk.d09sbcov8ph2amjw

Якщо ви не маєте значення --discovery-token-ca-cert-hash, ви можете отримати його, виконавши наступні команди на вузлі панелі управління:

sudo cat /etc/kubernetes/pki/ca.crt | \
  openssl x509 -pubkey  | \
  openssl rsa -pubin -outform der 2>/dev/null | \
  openssl dgst -sha256 -hex | \
  sed 's/^.* //'

Вивід буде подібний до:

8cb2de97839780a412b93877f8507ad6c94f73add17d5d7058e91741c9d5ec78

Вивід команди kubeadm join має виглядати приблизно так:

[preflight] Running pre-flight checks

... (вивід журналу процесу приєднання) ...

Приєднання вузла завершено:
* Запит на підпис сертифіката надіслано до панелі управління та отримано відповідь.
* Kubelet поінформований про нові деталі захищеного з'єднання.

Запустіть 'kubectl get nodes' на панелі управління, щоб побачити цей вузол.

Через кілька секунд ви повинні помітити цей вузол у виводі kubectl get nodes. (наприклад, виконайте kubectl на вузлі панелі управління).

Налаштування мережі

Налаштування CNI в кластерах, що містять як Linux, так і вузли Windows, вимагає більше кроків, ніж просто запуск kubectl apply з файлом маніфесту. Крім того, втулок CNI, що працює на вузлах панелі управління, повинен бути підготовлений для підтримки втулка CNI, що працює на робочих вузлах Windows.

Зараз лише кілька втулків CNI підтримують Windows. Нижче наведені інструкції для їх налаштування:

Встановлення kubectl для Windows (необовʼязково)

Дивіться Встановлення та налаштування kubectl у Windows.

Що далі

4.2.1.3 - Оновлення кластерів з kubeadm

Ця сторінка пояснює, як оновити кластер Kubernetes, створений за допомогою kubeadm, з версії 1.30.x до версії 1.31.x і з версії 1.31.x до 1.31.y (де y > x). Пропуск МІНОРНИХ версій при оновленні не підтримується. Для отримання додаткових відомостей відвідайте Політику версій зміни.

Щоб переглянути інформацію про оновлення кластерів, створених за допомогою старіших версій kubeadm, зверніться до наступних сторінок:

Процес оновлення загалом виглядає наступним чином:

  1. Оновлення первинного вузла панелі управління.
  2. Оновлення додаткових вузлів панелі управління.
  3. Оновлення вузлів робочого навантаження.

Перш ніж ви розпочнете

  • Переконайтеся, що ви уважно прочитали примітки до випуску.
  • Кластер повинен використовувати статичні вузли керування та контейнери etcd або зовнішній etcd.
  • Переконайтеся, що ви зробили резервне копіювання важливих компонентів, таких як стан на рівні застосунків, збережений у базі даних. kubeadm upgrade не торкнеться вашого робочого навантаження, лише компонентів, внутрішніх для Kubernetes, але резервне копіювання завжди є найкращою практикою.
  • Своп має бути вимкнено.

Додаткова інформація

  • Наведені нижче інструкції описують, коли потрібно вивести з експлуатації кожний вузол під час процесу оновлення. Якщо ви виконуєте оновлення для мінорного номера версії для будь-якого kubelet, ви обовʼязково спочатку повинні вивести вузол (або вузли) з експлуатації, які ви оновлюєте. У випадку вузлів панелі управління, на них можуть працювати контейнери CoreDNS або інші критичні робочі навантаження. Для отримання додаткової інформації дивіться Виведення вузлів з експлуатації.
  • Проєкт Kubernetes рекомендує щоб версії kubelet і kubeadm збігались. Замість цього ви можете використовувати версію kubelet, яка є старішою, ніж kubeadm, за умови, що вона знаходиться в межах підтримуваних версій. Для отримання додаткових відомостей, будь ласка, відвідайте Відхилення kubeadm від kubelet.
  • Всі контейнери перезавантажуються після оновлення, оскільки змінюється значення хешу специфікації контейнера.
  • Щоб перевірити, що служба kubelet успішно перезапустилась після оновлення kubelet, ви можете виконати systemctl status kubelet або переглянути логи служби за допомогою journalctl -xeu kubelet.
  • kubeadm upgrade підтримує параметр --config із типом API UpgradeConfiguration, який можна використовувати для налаштування процесу оновлення.
  • kubeadm upgrade не підтримує переналаштування наявного кластера. Замість цього виконайте кроки, описані в Переналаштування кластера kubeadm.

Що треба враховувати при оновленні etcd

Оскільки статичний Pod kube-apiserver працює постійно (навіть якщо ви вивели вузол з експлуатації), під час виконання оновлення kubeadm, яке включає оновлення etcd, запити до сервера зупиняться, поки новий статичний Pod etcd не перезапуститься. Як обхідний механізм, можна активно зупинити процес kube-apiserver на кілька секунд перед запуском команди kubeadm upgrade apply. Це дозволяє завершити запити, що вже відправлені, і закрити наявні зʼєднання, що знижує наслідки перерви роботи etcd. Це можна зробити на вузлах панелі управління таким чином:

killall -s SIGTERM kube-apiserver # виклик належного припинення роботи kube-apiserver
sleep 20 # зачекайте трохи, щоб завершити запити, які вже були відправлені
kubeadm upgrade ... # виконати команду оновлення kubeadm

Зміна репозиторію пакунків

Якщо ви використовуєте репозиторії пакунків, що керуються спільнотою (pkgs.k8s.io), вам потрібно увімкнути репозиторій пакунків для бажаної мінорної версії Kubernetes. Як це зробити можна дізнатись з документа Зміна репозиторію пакунків Kubernetes.

Визначення версії, на яку потрібно оновитися

Знайдіть останнє патч-видання для Kubernetes 1.31 за допомогою менеджера пакунків ОС:

# Знайдіть останню версію 1.31 у списку.
# Вона має виглядати як 1.31.x-*, де x — останній патч.
sudo apt update
sudo apt-cache madison kubeadm

# Знайдіть останню версію 1.31 у списку.
# Вона має виглядати як 1.31.x-*, де x — останній патч.
sudo yum list --showduplicates kubeadm --disableexcludes=kubernetes

Оновлення вузлів панелі управління

Процедуру оновлення на вузлах панелі управління слід виконувати по одному вузлу за раз. Виберіть перший вузол панелі управління, який ви хочете оновити. Він повинен мати файл /etc/kubernetes/admin.conf.

Here's the translation:

Виклик "kubeadm upgrade"

Для першого вузла панелі управління

  1. Оновіть kubeadm:

    # замініть x на останню версію патча
    sudo apt-mark unhold kubeadm && \
    sudo apt-get update && sudo apt-get install -y kubeadm='1.31.x-*' && \
    sudo apt-mark hold kubeadm
    

    # замініть x на останню версію патча
    sudo yum install -y kubeadm-'1.31.x-*' --disableexcludes=kubernetes
    
  2. Перевірте, що завантаження працює і має очікувану версію:

    kubeadm version
    
  3. Перевірте план оновлення:

    sudo kubeadm upgrade plan
    

    Ця команда перевіряє можливість оновлення вашого кластера та отримує версії, на які ви можете оновитися. Також вона показує таблицю стану версій компонентів.

  4. Виберіть версію для оновлення та запустіть відповідну команду. Наприклад:

    # замініть x на версію патча, яку ви вибрали для цього оновлення
    sudo kubeadm upgrade apply v1.31.x
    

    Після завершення команди ви маєте побачити:

    [upgrade/successful] SUCCESS! Your cluster was upgraded to "v1.31.x". Enjoy!
    
    [upgrade/kubelet] Now that your control plane is upgraded, please proceed with upgrading your kubelets if you haven't already done so.
    
  5. Вручну оновіть втулок постачальник мережевого інтерфейсу контейнера (CNI).

    Ваш постачальник мережевого інтерфейсу контейнера (CNI) може мати власні інструкції щодо оновлення. Перевірте надбудови для знаходження вашого постачальника CNI та перегляньте, чи потрібні додаткові кроки оновлення.

    Цей крок не потрібен на додаткових вузлах панелі управління, якщо постачальник CNI працює як DaemonSet.

Для інших вузлів панелі управління

Те саме, що для першого вузла керування, але використовуйте:

sudo kubeadm upgrade node

замість:

sudo kubeadm upgrade apply

Також виклик kubeadm upgrade plan та оновлення постачальника мережевого інтерфейсу контейнера (CNI) вже не потрібні.

Виведення вузла з експлуатації

Готуємо вузол для обслуговування, відмітивши його як непридатний для планування та вивівши з нього робочі навантаження:

# замініть <node-to-drain> іменем вашого вузла, який ви хочете вивести з експлуатації
kubectl drain <node-to-drain> --ignore-daemonsets

Оновлення kubelet та kubectl

  1. Оновіть kubelet та kubectl:

    # замініть x у 1.31.x-* на останню патч-версію
    sudo apt-mark unhold kubelet kubectl && \
    sudo apt-get update && sudo apt-get install -y kubelet='1.31.x-*' kubectl='1.31.x-*' && \
    sudo apt-mark hold kubelet kubectl
    

    # замініть x у 1.31.x-* на останню патч-версію
    sudo yum install -y kubelet-'1.31.x-*' kubectl-'1.31.x-*' --disableexcludes=kubernetes
    
  2. Перезапустіть kubelet:

    sudo systemctl daemon-reload
    sudo systemctl restart kubelet
    

Повернення вузла до експлуатації

Відновіть роботу вузла, позначивши його як доступний для планування:

# замініть <node-to-uncordon> на імʼя вашого вузла
kubectl uncordon <node-to-uncordon>

Оновлення вузлів робочих навантажень

Процедуру оновлення на робочих вузлах слід виконувати один за одним або декільком вузлами одночасно, не посягаючи на мінімально необхідні можливості для виконання вашого навантаження.

Наступні сторінки показують, як оновити робочі вузли у Linux та Windows:

Перевірка стану кластера

Після оновлення kubelet на всіх вузлах перевірте доступність всіх вузлів, виконавши наступну команду з будь-якого місця, де кubectl має доступу до кластера:

kubectl get nodes

У стовпці STATUS повинно бути вказано Ready для всіх ваших вузлів, а номер версії повинен бути оновлений.

Відновлення після несправності

Якщо kubeadm upgrade виявляється несправним і не відновлює роботу, наприклад через неочікуване вимкнення під час виконання, ви можете виконати kubeadm upgrade ще раз. Ця команда є ідемпотентною і, зрештою, переконується, що фактичний стан відповідає заданому вами стану.

Для відновлення з несправного стану ви також можете запустити sudo kubeadm upgrade apply --force без зміни версії, яку використовує ваш кластер.

Під час оновлення kubeadm записує наступні резервні теки у /etc/kubernetes/tmp:

  • kubeadm-backup-etcd-<дата>-<час>
  • kubeadm-backup-manifests-<дата>-<час>

kubeadm-backup-etcd містить резервну копію даних локального etcd для цього вузла панелі управління. У разі невдачі оновлення etcd і якщо автоматичне відновлення не працює, вміст цієї теки може бути відновлений вручну в /var/lib/etcd. У разі використання зовнішнього etcd ця тека резервного копіювання буде порожньою.

kubeadm-backup-manifests містить резервну копію файлів маніфестів статичних Podʼів для цього вузла панелі управління. У разі невдачі оновлення і якщо автоматичне відновлення не працює, вміст цієї теки може бути відновлений вручну в /etc/kubernetes/manifests. Якщо з будь-якої причини немає різниці між попереднім та файлом маніфесту після оновлення для певного компонента, резервна копія файлу для нього не буде записана.

Як це працює

kubeadm upgrade apply робить наступне:

  • Перевіряє, що ваш кластер можна оновити:
    • Сервер API доступний
    • Всі вузли знаходяться у стані Ready
    • Панель управління працює належним чином
  • Застосовує політику різниці версій.
  • Переконується, що образи панелі управління доступні або доступні для отримання на машині.
  • Генерує заміни та/або використовує зміни підготовлені користувачем, якщо компонентні конфігурації вимагають оновлення версії.
  • Оновлює компоненти панелі управління або відкочується, якщо будь-який з них не може бути запущений.
  • Застосовує нові маніфести CoreDNS і kube-proxy і переконується, що створені всі необхідні правила RBAC.
  • Створює нові сертифікати та файли ключів API-сервера і робить резервні копії старих файлів, якщо вони мають закінчитися за 180 днів.

kubeadm upgrade node робить наступне на додаткових вузлах панелі управління:

  • Витягує ClusterConfiguration kubeadm з кластера.
  • Опційно робить резервні копії сертифіката kube-apiserver.
  • Оновлює маніфести статичних Podʼів для компонентів панелі управління.
  • Оновлює конфігурацію kubelet для цього вузла.

kubeadm upgrade node робить наступне на вузлах робочих навантажень:

  • Витягує ClusterConfiguration kubeadm з кластера.
  • Оновлює конфігурацію kubelet для цього вузла.

4.2.1.4 - Оновлення вузлів Linux

Ця сторінка пояснює, як оновити вузли робочих навантажень Linux, створені за допомогою kubeadm.

Перш ніж ви розпочнете

Вам потрібен доступ до оболонки на всіх вузлах, а також інструмент командного рядка kubectl повинен бути налаштований для спілкування з вашим кластером. Рекомендується виконувати цю інструкцію у кластері, який має принаймні два вузли, які не виконують функції вузлів панелі управління.

Для перевірки версії введіть kubectl version.

Зміна репозиторію пакунків

Якщо ви використовуєте репозиторії пакунків (pkgs.k8s.io), вам потрібно увімкнути репозиторій пакунків для потрібного мінорного релізу Kubernetes. Це пояснено в документі Зміна репозиторію пакунків Kubernetes.

Оновлення робочих вузлів

Оновлення kubeadm

Оновіть kubeadm:

# замініть x у 1.31.x-* на останню версію патча
sudo apt-mark unhold kubeadm && \
sudo apt-get update && sudo apt-get install -y kubeadm='1.31.x-*' && \
sudo apt-mark hold kubeadm

# замініть x у 1.31.x-* на останню версію патча
sudo yum install -y kubeadm-'1.31.x-*' --disableexcludes=kubernetes

Виклик "kubeadm upgrade"

Для робочих вузлів це оновлює локальну конфігурацію kubelet:

sudo kubeadm upgrade node

Виведіть вузол з експлуатації

Підготуйте вузол до обслуговування, позначивши його як недоступний для планування та виселивши завдання:

# виконайте цю команду на вузлі панелі управління
# замініть <node-to-drain> імʼям вузла, який ви виводите з експлуатації
kubectl drain <node-to-drain> --ignore-daemonsets

Оновлення kubelet та kubectl

  1. Оновіть kubelet та kubectl:

    # замініть x у 1.31.x-* на останню версію патча
    sudo apt-mark unhold kubelet kubectl && \
    sudo apt-get update && sudo apt-get install -y kubelet='1.31.x-*' kubectl='1.31.x-*' && \
    sudo apt-mark hold kubelet kubectl
    

    # замініть x у 1.31.x-* на останню версію патча
    sudo yum install -y kubelet-'1.31.x-*' kubectl-'1.31.x-*' --disableexcludes=kubernetes
    
  2. Перезавантажте kubelet:

    sudo systemctl daemon-reload
    sudo systemctl restart kubelet
    

Відновіть роботу вузла

Поверніть вузол в роботу, позначивши його як придатний для планування:

# виконайте цю команду на вузлі панелі управління
# замініть <node-to-uncordon> імʼям вашого вузла
kubectl uncordon <node-to-uncordon>

Що далі

4.2.1.5 - Оновлення вузлів Windows

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.18 [beta]

Ця сторінка пояснює, як оновити вузол Windows, створений за допомогою kubeadm.

Перш ніж ви розпочнете

Вам потрібен доступ до оболонки на всіх вузлах, а також інструмент командного рядка kubectl повинен бути налаштований для спілкування з вашим кластером. Рекомендується виконувати цю інструкцію у кластері, який має принаймні два вузли, які не виконують функції вузлів панелі управління.

Версія вашого Kubernetes сервера має бути не старішою ніж 1.17. Для перевірки версії введіть kubectl version.

Оновлення робочих вузлів

Оновлення kubeadm

  1. З вузла Windows оновіть kubeadm:

    # замініть 1.31.0 на вашу бажану версію
    curl.exe -Lo <path-to-kubeadm.exe>  "https://dl.k8s.io/v1.31.0/bin/windows/amd64/kubeadm.exe"
    

Виведіть вузол з експлуатації

  1. З машини з доступом до API Kubernetes підготуйте вузол до обслуговування, позначивши його як недоступний для планування та виселивши завдання:

    # замініть <node-to-drain> імʼям вашого вузла, який ви виводите з експлуатації
    kubectl drain <node-to-drain> --ignore-daemonsets
    

    Ви повинні побачити подібний вивід:

    node/ip-172-31-85-18 cordoned
    node/ip-172-31-85-18 drained
    

Оновлення конфігурації kubelet

  1. З вузла Windows викличте наступну команду, щоб синхронізувати нову конфігурацію kubelet:

    kubeadm upgrade node
    

Оновлення kubelet та kube-proxy

  1. З вузла Windows оновіть та перезапустіть kubelet:

    stop-service kubelet
    curl.exe -Lo <path-to-kubelet.exe> "https://dl.k8s.io/v1.31.0/bin/windows/amd64/kubelet.exe"
    restart-service kubelet
    
  2. З вузла Windows оновіть та перезапустіть kube-proxy.

    stop-service kube-proxy
    curl.exe -Lo <path-to-kube-proxy.exe> "https://dl.k8s.io/v1.31.0/bin/windows/amd64/kube-proxy.exe"
    restart-service kube-proxy
    

Відновіть роботу вузла

  1. З машини з доступом до API Kubernetes, поверніть вузол в роботу, позначивши його як придатний для планування:

    # замініть <node-to-drain> імʼям вашого вузла
    kubectl uncordon <node-to-drain>
    

Що далі

4.2.1.6 - Налаштування драйвера cgroup

Ця сторінка пояснює, як налаштувати драйвер cgroup kubelet, щоб він відповідав драйверу cgroup контейнера для кластерів kubeadm.

Перш ніж ви розпочнете

Вам слід ознайомитися з вимогами до контейнерних середовищ Kubernetes.

Налаштування драйвера cgroup середовища виконання контейнерів

Сторінка Середовища виконання контейнерів пояснює, що для налаштувань на основі kubeadm рекомендується використовувати драйвер systemd замість типового драйвера cgroupfs kubelet, оскільки kubeadm керує kubelet як сервісом systemd.

На сторінці також наведено деталі щодо того, як налаштувати різні контейнерні середовища зі стандартним використанням драйвера systemd.

Налаштування драйвера cgroup для kubelet

kubeadm дозволяє передавати структуру KubeletConfiguration під час ініціалізації за допомогою kubeadm init. Ця структура KubeletConfiguration може включати поле cgroupDriver, яке контролює драйвер cgroup для kubelet.

Ось мінімальний приклад, який явним чином вказує значення поля cgroupDriver:

# kubeadm-config.yaml
kind: ClusterConfiguration
apiVersion: kubeadm.k8s.io/v1beta4
kubernetesVersion: v1.21.0
---
kind: KubeletConfiguration
apiVersion: kubelet.config.k8s.io/v1beta1
cgroupDriver: systemd

Такий файл конфігурації можна передати команді kubeadm:

kubeadm init --config kubeadm-config.yaml

Використання драйвера cgroupfs

Для використання cgroupfs і запобігання модифікації драйвера cgroup в KubeletConfiguration під час оновлення kubeadm в поточних налаштуваннях, вам потрібно явно вказати його значення. Це стосується випадку, коли ви не хочете, щоб майбутні версії kubeadm стандартно застосовували драйвер systemd.

Дивіться нижче розділ "Зміна ConfigMap у kubelet" для отримання деталей щодо явного вказання значення.

Якщо ви хочете налаштувати середовище виконання контейнерів на використання драйвера cgroupfs, вам слід звернутися до документації вашого середовища виконання контейнерів.

Міграція на використання драйвера systemd

Щоб змінити драйвер cgroup поточного кластера kubeadm з cgroupfs на systemd на місці, потрібно виконати подібну процедуру до оновлення kubelet. Це повинно включати обидва зазначені нижче кроки.

Зміна ConfigMap у kubelet

  • Викличте kubectl edit cm kubelet-config -n kube-system.

  • Змініть наявне значення cgroupDriver або додайте нове поле, яке виглядає наступним чином:

    cgroupDriver: systemd
    

    Це поле повинно бути присутнє у розділі kubelet: в ConfigMap.

Оновлення драйвера cgroup на всіх вузлах

Для кожного вузла в кластері:

  • Відключіть вузол за допомогою kubectl drain <імʼя-вузла> --ignore-daemonsets
  • Зупиніть kubelet за допомогою systemctl stop kubelet
  • Зупиніть середовище виконання контейнерів
  • Змініть драйвер cgroup середовища виконання контейнерів на systemd
  • Встановіть cgroupDriver: systemd у /var/lib/kubelet/config.yaml
  • Запустіть середовище виконання контейнерів
  • Запустіть kubelet за допомогою systemctl start kubelet
  • Увімкніть вузол за допомогою kubectl uncordon <імʼя-вузла>

Виконайте ці кроки на вузлах по одному, щоб забезпечити достатній час для розміщення робочих навантажень на різних вузлах.

Після завершення процесу переконайтеся, що всі вузли та робочі навантаження є справними.

4.2.1.7 - Управління сертифікатами з kubeadm

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.15 [stable]

Клієнтські сертифікати, що генеруються kubeadm, закінчуються через 1 рік. Ця сторінка пояснює, як управляти поновленням сертифікатів за допомогою kubeadm. Вона також охоплює інші завдання, повʼязані з управлінням сертифікатами kubeadm.

Перш ніж ви розпочнете

Ви повинні бути знайомі з сертифікатами PKI та вимогами Kubernetes.

Використання власних сертифікатів

Типово, kubeadm генерує всі необхідні сертифікати для роботи кластера. Ви можете перевизначити цю поведінку, надавши власні сертифікати.

Для цього вам потрібно помістити їх у ту теку, яка вказується за допомогою прапорця --cert-dir або поля certificatesDir конфігурації кластера ClusterConfiguration kubeadm. Типово це /etc/kubernetes/pki.

Якщо певна пара сертифікатів і приватний ключ існують до запуску kubeadm init, kubeadm не перезаписує їх. Це означає, що ви можете, наприклад, скопіювати наявний ЦС (Центр сертифікації — Certificate authority) в /etc/kubernetes/pki/ca.crt та /etc/kubernetes/pki/ca.key, і kubeadm використовуватиме цей ЦС для підпису решти сертифікатів.

Режим зовнішнього ЦС

Також можливо надати лише файл ca.crt і не файл ca.key (це доступно лише для файлу кореневого ЦС, а не інших пар сертифікатів). Якщо всі інші сертифікати та файли kubeconfig на місці, kubeadm розпізнає цю умову та активує режим "Зовнішній ЦС". kubeadm буде продовжувати без ключа ЦС на диску.

Замість цього, запустіть контролер-менеджер самостійно з параметром --controllers=csrsigner та вкажіть на сертифікат та ключ ЦС.

Існують різні способи підготовки облікових даних компонента при використанні режиму зовнішнього ЦС.

Ручна підготовка облікових даних компонента

Сертифікати PKI та вимоги містять інформацію про те, як підготувати всі необхідні облікові дані для компонентів, які вимагаються kubeadm, вручну.

Підготовка облікових даних компонента шляхом підпису CSR, що генеруються kubeadm

kubeadm може генерувати файли CSR, які ви можете підписати вручну за допомогою інструментів, таких як openssl, та вашого зовнішнього ЦС. Ці файли CSR будуть включати всі вказівки для облікових даних, які вимагаються компонентами, розгорнутими kubeadm.

Автоматизована підготовка облікових даних компонента за допомогою фаз kubeadm

З іншого боку, можливо використовувати команди фаз kubeadm для автоматизації цього процесу.

  • Перейдіть на хост, який ви хочете підготувати як вузол панелі управління kubeadm з зовнішнім ЦС.
  • Скопіюйте зовнішні файли ЦС ca.crt та ca.key, які ви маєте, до /etc/kubernetes/pki на вузлі.
  • Підготуйте тимчасовий файл конфігурації kubeadm під назвою config.yaml, який можна використовувати з kubeadm init. Переконайтеся, що цей файл містить будь-яку відповідну інформацію на рівні кластера або хосту, яка може бути включена в сертифікати, таку як, ClusterConfiguration.controlPlaneEndpoint, ClusterConfiguration.certSANs та InitConfiguration.APIEndpoint.
  • На тому ж самому хості виконайте команди kubeadm init phase kubeconfig all --config config.yaml та kubeadm init phase certs all --config config.yaml. Це згенерує всі необхідні файли kubeconfig та сертифікати у теці /etc/kubernetes/ та її підтеці pki.
  • Перевірте згенеровані файли. Видаліть /etc/kubernetes/pki/ca.key, видаліть або перемістіть в безпечне місце файл /etc/kubernetes/super-admin.conf.
  • На вузлах, де буде викликано kubeadm join, також видаліть /etc/kubernetes/kubelet.conf. Цей файл потрібний лише на першому вузлі, де буде викликано kubeadm init.
  • Зауважте, що деякі файли, такі як pki/sa.*, pki/front-proxy-ca.* та pki/etc/ca.*, спільно використовуються між вузлами панелі управління, Ви можете згенерувати їх один раз та розподілити їх вручну на вузли, де буде викликано kubeadm join, або ви можете використовувати функціональність --upload-certs kubeadm init та --certificate-key kubeadm join для автоматизації цього розподілу.

Після того, як облікові дані будуть підготовлені на всіх вузлах, викличте kubeadm init та kubeadm join для цих вузлів, щоб приєднати їх до кластера. kubeadm використовуватиме наявні файли kubeconfig та сертифікати у теці /etc/kubernetes/ та її підтеці pki.

Перевірка закінчення терміну дії сертифікатів

Ви можете використовувати підкоманду check-expiration, щоб перевірити термін дії сертифікатів:

kubeadm certs check-expiration

Вивід подібний до наступного:

CERTIFICATE                EXPIRES                  RESIDUAL TIME   CERTIFICATE AUTHORITY   EXTERNALLY MANAGED
admin.conf                 Dec 30, 2020 23:36 UTC   364d                                    no
apiserver                  Dec 30, 2020 23:36 UTC   364d            ca                      no
apiserver-etcd-client      Dec 30, 2020 23:36 UTC   364d            etcd-ca                 no
apiserver-kubelet-client   Dec 30, 2020 23:36 UTC   364d            ca                      no
controller-manager.conf    Dec 30, 2020 23:36 UTC   364d                                    no
etcd-healthcheck-client    Dec 30, 2020 23:36 UTC   364d            etcd-ca                 no
etcd-peer                  Dec 30, 2020 23:36 UTC   364d            etcd-ca                 no
etcd-server                Dec 30, 2020 23:36 UTC   364d            etcd-ca                 no
front-proxy-client         Dec 30, 2020 23:36 UTC   364d            front-proxy-ca          no
scheduler.conf             Dec 30, 2020 23:36 UTC   364d                                    no

CERTIFICATE AUTHORITY   EXPIRES                  RESIDUAL TIME   EXTERNALLY MANAGED
ca                      Dec 28, 2029 23:36 UTC   9y              no
etcd-ca                 Dec 28, 2029 23:36 UTC   9y              no
front-proxy-ca          Dec 28, 2029 23:36 UTC   9y              no

Команда показує час закінчення та залишковий час для сертифікатів клієнта у теці /etc/kubernetes/pki та для сертифіката клієнта, вбудованого у файли kubeconfig, що використовуються kubeadm (admin.conf, controller-manager.conf та scheduler.conf).

Крім того, kubeadm повідомляє користувача, якщо керування сертифікатом відбувається ззовні; у цьому випадку користувачу слід самостійно забезпечити керування поновленням сертифікатів вручну/за допомогою інших інструментів.

Автоматичне поновлення сертифікатів

kubeadm поновлює всі сертифікати під час оновлення панелі управління.

Ця функція призначена для вирішення найпростіших випадків використання; якщо у вас немає конкретних вимог до поновлення сертифікатів і ви регулярно виконуєте оновлення версії Kubernetes (частіше ніж 1 раз на рік між кожним оновленням), kubeadm буде піклуватися про те, щоб ваш кластер був завжди актуальним і досить безпечним.

Якщо у вас є складніші вимоги до поновлення сертифікатів, ви можете відмовитися від стандартної поведінки, передавши --certificate-renewal=false до kubeadm upgrade apply або до kubeadm upgrade node.

Ручне поновлення сертифікатів

Ви можете в будь-який момент вручну оновити свої сертифікати за допомогою команди kubeadm certs renew з відповідними параметрами командного рядка.

Ця команда виконує поновлення за допомогою сертифіката та ключа ЦС (або front-proxy-CA), збережених у /etc/kubernetes/pki.

Після виконання команди вам слід перезапустити Podʼи панелі управління. Це необхідно, оскільки динамічне перезавантаження сертифікатів наразі не підтримується для всіх компонентів та сертифікатів. Статичні Podʼи керуються локальним kubelet і не API-сервером, тому kubectl не може бути використаний для їх видалення та перезапуску. Щоб перезапустити статичний Pod, ви можете тимчасово видалити файл його маніфеста з /etc/kubernetes/manifests/ і зачекати 20 секунд (див. значення fileCheckFrequency у KubeletConfiguration struct). kubelet завершить роботу Pod, якщо він більше не знаходиться в теці маніфестів. Потім ви можете повернути файл назад і після ще одного періоду fileCheckFrequency kubelet знову створить Pod, і поновлення сертифікатів для компонента буде завершено.

kubeadm certs renew може оновити будь-який конкретний сертифікат або, за допомогою підкоманди all, він може оновити всі з них, як показано нижче:

kubeadm certs renew all

Поновлення сертифікатів за допомогою API сертифікатів Kubernetes

У цьому розділі надаються додаткові відомості про те, як виконати ручне поновлення сертифікатів за допомогою API сертифікатів Kubernetes.

Налаштування підписувача

Kubernetes Certificate Authority не працює зразу. Ви можете налаштувати зовнішнього підписувача, такого як cert-manager, або можете використовувати вбудованого підписувача.

Вбудований підписувач є частиною kube-controller-manager.

Для активації вбудованого підписувача вам необхідно передати прапорці --cluster-signing-cert-file та --cluster-signing-key-file.

Якщо ви створюєте новий кластер, ви можете використовувати файл конфігурації kubeadm:

apiVersion: kubeadm.k8s.io/v1beta4
kind: ClusterConfiguration
controllerManager:
  extraArgs:
  - name: "cluster-signing-cert-file"
    value: "/etc/kubernetes/pki/ca.crt"
  - name: "cluster-signing-key-file"
    value: "/etc/kubernetes/pki/ca.key"

Створення запитів на підпис сертифікатів (CSR)

Дивіться Створення CertificateSigningRequest для створення CSRs за допомогою API Kubernetes.

Поновлення сертифікатів зовнішнім ЦС

У цьому розділі надаються додаткові відомості про те, як виконати ручне поновлення сертифікатів за допомогою зовнішнього ЦС.

Для кращої інтеграції з зовнішніми ЦС, kubeadm також може створювати запити на підпис сертифікатів (CSR). Запит на підпис сертифіката є запитом до ЦС на підписаний сертифікат для клієнта. За термінологією kubeadm, будь-який сертифікат, який зазвичай підписується ЦС на диску, може бути створений у вигляді CSR. Однак ЦС не може бути створено як CSR.

Поновлення за допомогою запитів на підпис сертифікатів (CSR)

Поновлення сертифікатів можливе шляхом генерації нових CSR і підпису їх зовнішнім ЦС. Для отримання докладнішої інформації щодо роботи з CSR, створеними kubeadm, див. розділ Підпис запитів на підпис сертифікатів (CSR), згенерованих kubeadm.

Оновлення Certificate authority (ЦС)

Kubeadm не підтримує автоматичне оновлення або заміну сертифікатів ЦС зразу.

Для отримання додаткової інформації про ручне оновлення або заміну ЦС дивіться ручне оновлення сертифікатів ЦС.

Ввімкнення підписаних службових сертифікатів kubelet

Типово службовий сертифікат kubelet, розгорнутий за допомогою kubeadm, є самопідписним. Це означає, що зʼєднання зовнішніх служб, наприклад, сервера метрик з kubelet, не може бути захищено TLS.

Щоб налаштувати kubelet в новому кластері kubeadm для отримання належно підписаних службових сертифікатів, ви повинні передати наступну мінімальну конфігурацію до kubeadm init:

apiVersion: kubeadm.k8s.io/v1beta4
kind: ClusterConfiguration
---
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
serverTLSBootstrap: true

Якщо ви вже створили кластер, вам слід адаптувати його, виконавши наступне:

  • Знайдіть і відредагуйте ConfigMap kubelet-config-1.31 в просторі імен kube-system. У ConfigMap ключ kubelet має документ KubeletConfiguration як своє значення. Відредагуйте документ KubeletConfiguration, щоб встановити serverTLSBootstrap: true.
  • На кожному вузлі додайте поле serverTLSBootstrap: true у /var/lib/kubelet/config.yaml і перезапустіть kubelet за допомогою systemctl restart kubelet.

Поле serverTLSBootstrap: true дозволить ініціювати завантаження службових сертифікатів kubelet, запитуючи їх з API certificates.k8s.io. Одне з відомих обмежень поля serverTLSBootstrap: true — CSRs (запити на підпис сертифікатів) для цих сертифікатів не можуть бути автоматично затверджені типовим підписувачем в kube-controller-manager — kubernetes.io/kubelet-serving. Це потребує дій користувача або стороннього контролера.

Ці CSRs можна переглянути за допомогою:

kubectl get csr
NAME        AGE     SIGNERNAME                        REQUESTOR                      CONDITION
csr-9wvgt   112s    kubernetes.io/kubelet-serving     system:node:worker-1           Pending
csr-lz97v   1m58s   kubernetes.io/kubelet-serving     system:node:control-plane-1    Pending

Щоб затвердити їх, ви можете виконати наступне:

kubectl certificate approve <CSR-name>

Типово ці службові сертифікати закінчуються через рік. Kubeadm встановлює поле rotateCertificates в true у KubeletConfiguration, що означає, що близько до закінчення буде створено новий набір CSRs для службових сертифікатів і їх слід затвердити, щоб завершити оновлення. Для отримання додаткової інформації дивіться Оновлення сертифікатів.

Якщо ви шукаєте рішення для автоматичного затвердження цих CSRs, рекомендується звернутися до свого постачальника хмарних послуг і дізнатись, чи він має підписувача CSR, який перевіряє ідентифікацію вузла за допомогою окремого механізму.

Ви можете використовувати власні контролери сторонніх постачальників:

Такий контролер не є безпечним механізмом, якщо він перевіряє лише CommonName в CSR, але також перевіряє запитані IP-адреси та доменні імена. Це запобігло б зловмиснику, який має доступ до сертифіката клієнта kubelet, створювати CSRs, запитуючи службові сертифікати для будь-якої IP-адреси або доменного імені.

Генерація файлів kubeconfig для додаткових користувачів

Під час створення кластера, kubeadm підписує сертифікат у admin.conf, щоб мати Subject: O = system:masters, CN = kubernetes-admin. system:masters є групою суперкористувачів, яка обходить рівень авторизації (наприклад, RBAC). Не рекомендується ділитися admin.conf з додатковими користувачами!

Замість цього, ви можете використовувати команду kubeadm kubeconfig user для генерації файлів kubeconfig для додаткових користувачів. Команда приймає змішаний набір параметрів командного рядка та опцій конфігурації kubeadm. Згенерований kubeconfig буде записаний до stdout і може бути перенаправлений у файл за допомогою kubeadm kubeconfig user ... > somefile.conf.

Приклад конфігураційного файлу, який можна використовувати з --config:

# example.yaml
apiVersion: kubeadm.k8s.io/v1beta4
kind: ClusterConfiguration
# Буде використано як цільовий "кластер" у kubeconfig
clusterName: "kubernetes"
# Буде використано як "сервер" (IP або DNS-імʼя) цього кластера в kubeconfig
controlPlaneEndpoint: "some-dns-address:6443"
# Ключ і сертифікат ЦС кластера будуть завантажені з цієї локальної теки
certificatesDir: "/etc/kubernetes/pki"

Переконайтеся, що ці параметри відповідають бажаним параметрам цільового кластера. Щоб переглянути параметри поточного кластера, скористайтеся:

kubectl get cm kubeadm-config -n kube-system -o=jsonpath="{.data.ClusterConfiguration}"

Наступний приклад згенерує файл kubeconfig з обліковими даними, дійсними протягом 24 годин, для нового користувача johndoe, який належить до групи appdevs:

kubeadm kubeconfig user --config example.yaml --org appdevs --client-name johndoe --validity-period 24h

Наступний приклад згенерує файл kubeconfig з обліковими даними адміністратора, дійсними протягом 1 тижня:

kubeadm kubeconfig user --config example.yaml --client-name admin --validity-period 168h

Підписування запитів на підпис сертифікатів (CSR), згенерованих kubeadm

Ви можете створювати запити на підпис сертифікатів за допомогою kubeadm certs generate-csr. Виклик цієї команди згенерує пари файлів .csr / .key для звичайних сертифікатів. Для сертифікатів, вбудованих у файли kubeconfig, команда згенерує пару файлів .csr / .conf, де ключ вже вбудований у файл .conf.

Файл CSR містить всю необхідну інформацію для ЦС для підпису сертифіката. kubeadm використовує чітко визначену специфікацію для всіх своїх сертифікатів і CSR.

Типовою текою для сертифікатів є /etc/kubernetes/pki, тоді як типова тека для файлів kubeconfig є /etc/kubernetes. Ці стандартні значення можна змінити за допомогою прапорців --cert-dir та --kubeconfig-dir, відповідно.

Для передачі власних параметрів команді kubeadm certs generate-csr використовуйте прапорець --config, який приймає файл конфігурації kubeadm, так само як і команди, такі як kubeadm init. Будь-яка специфікація, така як додаткові SAN та власні IP-адреси, повинна зберігатися в тому ж файлі конфігурації та використовуватися для всіх відповідних команд kubeadm, передаючи його як --config.

Підготовка файлів ЦС та сервісного облікового запису

На головному вузлі панелі управління, де буде виконано команду kubeadm init, виконайте наступні команди:

sudo kubeadm init phase certs ca
sudo kubeadm init phase certs etcd-ca
sudo kubeadm init phase certs front-proxy-ca
sudo kubeadm init phase certs sa

Це заповнить теки /etc/kubernetes/pki та /etc/kubernetes/pki/etcd усіма самопідписними файлами ЦС (сертифікати та ключі) та сервісним обліковим записом (публічні та приватні ключі), які необхідні kubeadm для вузла панелі управління.

Для другорядних вузлів панелі управління (kubeadm join --control-plane) нема потреби викликати вищезазначені команди. Залежно від того, як ви налаштували Високодоступний кластер, вам або потрібно вручну скопіювати ті ж самі файли з головного вузла панелі управління, або використати автоматизовану функціональність --upload-certs від kubeadm init.

Генерація CSR

Команда kubeadm certs generate-csr генерує CSR для всіх відомих сертифікатів, якими керує kubeadm. Після завершення команди вам потрібно вручну видалити файли .csr, .conf або .key, які вам не потрібні.

Врахування kubelet.conf

Цей розділ стосується як вузлів панелі управління, так і робочих вузлів.

Якщо ви видалили файл ca.key з вузлів панелі управління (Режим зовнішнього ЦС), активний kube-controller-manager у цьому кластері не зможе підписати клієнтські сертифікати kubelet. Якщо у вашій конфігурації не існує зовнішнього методу для підписання цих сертифікатів (наприклад, зовнішній підписувач), ви могли б вручну підписати kubelet.conf.csr, як пояснено в цьому посібнику.

Зверніть увагу, що це також означає, що автоматичне оновлення клієнтського сертифіката kubelet буде відключено. Таким чином, близько до закінчення терміну дії сертифіката, вам потрібно буде генерувати новий kubelet.conf.csr, підписувати сертифікат, вбудовувати його в kubelet.conf і перезапускати kubelet.

Якщо це не стосується вашої конфігурації, ви можете пропустити обробку kubelet.conf.csr на другорядних вузлах панелі управління та на робочих вузлах (всі вузли, що викликають kubeadm join ...). Це тому, що активний kube-controller-manager буде відповідальний за підписання нових клієнтських сертифікатів kubelet.

Вузли панелі управління

Виконайте наступну команду на головному (kubeadm init) та вторинних (kubeadm join --control-plane) вузлах панелі управління, щоб згенерувати всі файли CSR:

sudo kubeadm certs generate-csr

Якщо має використовуватися зовнішній etcd, дотримуйтесь керівництва Зовнішній etcd з kubeadm, щоб зрозуміти, які файли CSR потрібні на вузлах kubeadm та etcd. Інші файли .csr та .key у теці /etc/kubernetes/pki/etcd можна видалити.

Виходячи з пояснення у розділі Врахування kubelet.conf, збережіть або видаліть файли kubelet.conf та kubelet.conf.csr.

Робочі вузли

Згідно з поясненням у розділі Врахування kubelet.conf, за необхідності викличте:

sudo kubeadm certs generate-csr

та залиште лише файли kubelet.conf та kubelet.conf.csr. Альтернативно, повністю пропустіть кроки для робочих вузлів.

Підписання CSR для всіх сертифікатів

Повторіть цей крок для всіх вузлів, що мають файли CSR.

Запишіть наступний скрипт у теку /etc/kubernetes, перейдіть до цієї теки та виконайте скрипт. Скрипт згенерує сертифікати для всіх файлів CSR, які присутні в дереві /etc/kubernetes.

#!/bin/bash

# Встановіть термін дії сертифіката в днях
DAYS=365

# Обробіть всі файли CSR, крім тих, що призначені для front-proxy і etcd
find ./ -name "*.csr" | grep -v "pki/etcd" | grep -v "front-proxy" | while read -r FILE;
do
    echo "* Обробка ${FILE} ..."
    FILE=${FILE%.*} # Відкинути розширення
    if [ -f "./pki/ca.srl" ]; then
        SERIAL_FLAG="-CAserial ./pki/ca.srl"
    else
        SERIAL_FLAG="-CAcreateserial"
    fi
    openssl x509 -req -days "${DAYS}" -CA ./pki/ca.crt -CAkey ./pki/ca.key ${SERIAL_FLAG} \
        -in "${FILE}.csr" -out "${FILE}.crt"
    sleep 2
done

# Обробіть всі CSR для etcd
find ./pki/etcd -name "*.csr" | while read -r FILE;
do
    echo "* Обробка ${FILE} ..."
    FILE=${FILE%.*} # Відкинути розширення
    if [ -f "./pki/etcd/ca.srl" ]; then
        SERIAL_FLAG=-CAserial ./pki/etcd/ca.srl
    else
        SERIAL_FLAG=-CAcreateserial
    fi
    openssl x509 -req -days "${DAYS}" -CA ./pki/etcd/ca.crt -CAkey ./pki/etcd/ca.key ${SERIAL_FLAG} \
        -in "${FILE}.csr" -out "${FILE}.crt"
done

# Обробіть CSR для front-proxy
echo "* Обробка ./pki/front-proxy-client.csr ..."
openssl x509 -req -days "${DAYS}" -CA ./pki/front-proxy-ca.crt -CAkey ./pki/front-proxy-ca.key -CAcreateserial \
    -in ./pki/front-proxy-client.csr -out ./pki/front-proxy-client.crt

Вбудовування сертифікатів у файли kubeconfig

Повторіть цей крок для всіх вузлів, що мають файли CSR.

Запишіть наступний скрипт у теку /etc/kubernetes, перейдіть до цієї теки та виконайте скрипт. Скрипт візьме файли .crt, які були підписані для файлів kubeconfig з CSR на попередньому кроці, та вбудує їх у файли kubeconfig.

#!/bin/bash

CLUSTER=kubernetes
find ./ -name "*.conf" | while read -r FILE;
do
    echo "* Обробка ${FILE} ..."
    KUBECONFIG="${FILE}" kubectl config set-cluster "${CLUSTER}" --certificate-authority ./pki/ca.crt --embed-certs
    USER=$(KUBECONFIG="${FILE}" kubectl config view -o jsonpath='{.users[0].name}')
    KUBECONFIG="${FILE}" kubectl config set-credentials "${USER}" --client-certificate "${FILE}.crt" --embed-certs
done

Виконання очищення

Виконайте цей крок на всіх вузлах, які мають файли CSR.

Запишіть наступний скрипт у теці /etc/kubernetes, перейдіть до цієї теки та виконайте скрипт.

#!/bin/bash

# Очищення файлів CSR
rm -f ./*.csr ./pki/*.csr ./pki/etcd/*.csr # Очистка всіх файлів CSR

# Очищення файлів CRT, які вже були вбудовані у файли kubeconfig
rm -f ./*.crt

За бажанням, перемістіть файли .srl на наступний вузол, який буде оброблено.

За бажанням, якщо використовується зовнішній ЦС, видаліть файл /etc/kubernetes/pki/ca.key, як пояснено у розділі Вузол зовнішнього ЦС.

Ініціалізація вузла kubeadm

Як тільки файли CSR підписані і необхідні сертифікати розміщені на хостах, які ви хочете використовувати як вузли, ви можете використовувати команди kubeadm init та kubeadm join для створення Kubernetes кластера з цих вузлів. Під час init та join, kubeadm використовує існуючі сертифікати, ключі шифрування та файли kubeconfig, які він знаходить у дереві /etc/kubernetes у локальній файловій системі хоста.

4.2.1.8 - Переконфігурація кластера за допомогою kubeadm

kubeadm не підтримує автоматизованих способів переконфігурації компонентів, що були розгорнуті на керованих вузлах. Один зі способів автоматизації цього — використання власного оператора.

Для зміни конфігурації компонентів вам потрібно вручну редагувати повʼязані обʼєкти кластера та файли на диску.

Цей посібник показує правильну послідовність кроків, які потрібно виконати для досягнення переконфігурації кластера kubeadm.

Перш ніж ви розпочнете

  • Вам потрібен кластер, що був розгорнутий за допомогою kubeadm.
  • У вас мають бути адміністративні облікові дані (/etc/kubernetes/admin.conf) та мережеве зʼєднання з робочим kube-apiserver у кластері з хосту, на якому встановлено kubectl.
  • Мати текстовий редактор встановлений на всіх хостах.

Переконфігурація кластера

kubeadm записує набір параметрів конфігурації компонентів на рівні кластера у ConfigMaps та в інших обʼєктах. Ці обʼєкти потрібно редагувати вручну. Команда kubectl edit може бути використана для цього.

Команда kubectl edit відкриє текстовий редактор, в якому ви можете редагувати та зберегти обʼєкт безпосередньо.

Ви можете використовувати змінні середовища KUBECONFIG та KUBE_EDITOR для вказівки розташування файлу kubeconfig, який використовується kubectl, та обраного текстового редактора.

Наприклад:

KUBECONFIG=/etc/kubernetes/admin.conf KUBE_EDITOR=nano kubectl edit <параметри>

Застосування змін у конфігурації кластера

Оновлення ClusterConfiguration

Під час створення кластера та його оновлення, kubeadm записує ClusterConfiguration у ConfigMap, з назвою kubeadm-config у просторі імен kube-system.

Щоб змінити певну опцію у ClusterConfiguration, ви можете редагувати ConfigMap за допомогою цієї команди:

kubectl edit cm -n kube-system kubeadm-config

Конфігурація знаходиться в ключі data.ClusterConfiguration.

Віддзеркалення змін ClusterConfiguration на вузлах панелі управління

kubeadm керує компонентами панелі управління як статичними маніфестами Pod, які розташовані в теці /etc/kubernetes/manifests. Будь-які зміни у ClusterConfiguration в ключах apiServer, controllerManager, scheduler або etcd повинні віддзеркалюватись у відповідних файлах у теці маніфестів на вузлі панелі управління.

Такі зміни можуть включати:

  • extraArgs — потребує оновлення списку прапорців, які передаються контейнеру компонента
  • extraVolumes — потребує оновлення точок монтування для контейнера компонента
  • *SANs — потребує написання нових сертифікатів з Subject Alternative Names.

Перед продовженням цих змін переконайтеся, що ви зробили резервну копію теки /etc/kubernetes/.

Для написання нових сертифікатів ви можете використовувати:

kubeadm init phase certs <component-name> --config <config-file>

Для написання нових файлів маніфестів у теці /etc/kubernetes/manifests ви можете використовувати:

# Для компонентів панелі управління Kubernetes
kubeadm init phase control-plane <component-name> --config <config-file>
# Для локального etcd
kubeadm init phase etcd local --config <config-file>

Зміст <config-file> повинен відповідати оновленням в ClusterConfiguration. Значення <component-name> повинно бути імʼям компонента панелі управління Kubernetes (apiserver, controller-manager або scheduler).

Застосування змін конфігурації kubelet

Оновлення KubeletConfiguration

Під час створення кластера та оновлення, kubeadm записує KubeletConfiguration у ConfigMap з назвою kubelet-config в просторі імен kube-system.

Ви можете редагувати цей ConfigMap за допомогою такої команди:

kubectl edit cm -n kube-system kubelet-config

Конфігурація розташована в ключі data.kubelet.

Віддзеркалення змін в kubelet

Щоб віддзеркалити зміни на вузлах kubeadm, вам потрібно виконати наступне:

  • Увійдіть на вузол kubeadm.
  • Виконайте команду kubeadm upgrade node phase kubelet-config, щоб завантажити свіжий вміст kubelet-config ConfigMap в локальний файл /var/lib/kubelet/config.yaml.
  • Відредагуйте файл /var/lib/kubelet/kubeadm-flags.env, щоб застосувати додаткову конфігурацію за допомогою прапорців.
  • Перезапустіть службу kubelet за допомогою systemctl restart kubelet.

Застосування змін у конфігурації kube-proxy

Оновлення KubeProxyConfiguration

Під час створення кластера та оновлення, kubeadm записує KubeProxyConfiguration у ConfigMap в просторі імен kube-system з назвою kube-proxy.

Цей ConfigMap використовується DaemonSet kube-proxy в просторі імен kube-system.

Щоб змінити певну опцію в KubeProxyConfiguration, ви можете відредагувати ConfigMap за допомогою цієї команди:

kubectl edit cm -n kube-system kube-proxy

Конфігурація знаходиться в ключі data.config.conf.

Віддзеркалення змін у kube-proxy

Після оновлення ConfigMap kube-proxy, ви можете перезапустити всі Podʼи kube-proxy:

Отримайте імена Podʼів:

kubectl get po -n kube-system | grep kube-proxy

Видаліть Pod за допомогою:

kubectl delete po -n kube-system <імʼя-поду>

Створюватимуться нові Podʼи, які використовують оновлений ConfigMap.

Застосування змін конфігурації CoreDNS

Оновлення розгортання CoreDNS та сервісу

kubeadm розгортає CoreDNS як Deployment з назвою coredns та Service з назвою kube-dns, обидва у просторі імен kube-system.

Для оновлення будь-яких налаштувань CoreDNS ви можете редагувати обʼєкти Deployment та Service:

kubectl edit deployment -n kube-system coredns
kubectl edit service -n kube-system kube-dns

Віддзеркалення змін у CoreDNS

Після застосування змін у CoreDNS ви можете видалити його Podʼи:

Отримайте назви Podʼів:

kubectl get po -n kube-system | grep coredns

Видаліть Pod за допомогою:

kubectl delete po -n kube-system <імʼя-пода>

Нові Podʼи з оновленою конфігурацією CoreDNS будуть створені.

Збереження переконфігурації

Під час виконання команди kubeadm upgrade на керованому вузлі kubeadm може перезаписати конфігурацію, яка була застосована після створення кластера (переконфігурація).

Збереження переконфігурації обʼєкту Node

kubeadm записує Labels, Taints, сокенти CRI та іншу інформацію в обʼєкті Node для конкретного вузла Kubernetes. Для зміни будь-якого змісту цього обʼєкта Node ви можете використовувати:

kubectl edit no <імʼя-вузла>

Під час виконання kubeadm upgrade вміст такого Node може бути перезаписаний. Якщо ви бажаєте зберегти свої зміни в обʼєкті Node після оновлення, ви можете підготувати команду патча для kubectl і застосувати її до обʼєкта Node:

kubectl patch no <імʼя-вузла> --patch-file <файл-патча>

Збереження переконфігурації компонента панелі управління

Основним джерелом конфігурації панелі управління є обʼєкт ClusterConfiguration, збережений у кластері. Для розширення конфігурації статичних маніфестів Podʼів можна використовувати патчі.

Ці файли патчів повинні залишатися як файли на вузлах панелі управління, щоб забезпечити можливість їх використання командою kubeadm upgrade ... --patches <directory>.

Якщо переконфігурування виконується для ClusterConfiguration і статичних маніфестів Podʼів на диску, то набір патчів для конкретного вузла повинен бути відповідно оновлений.

Збереження переконфігурації kubelet

Будь-які зміни в KubeletConfiguration, збережені у /var/lib/kubelet/config.yaml, будуть перезаписані під час виконання kubeadm upgrade, завантажуючи вміст конфігурації kubelet-config ConfigMap для всього кластера. Для збереження конфігурації kubelet для Node потрібно або вручну змінити файл /var/lib/kubelet/config.yaml після оновлення, або файл /var/lib/kubelet/kubeadm-flags.env може містити прапорці. Прапорці kubelet перевизначають відповідні параметри KubeletConfiguration, але слід зауважити, що деякі з прапорців є застарілими.

Після зміни /var/lib/kubelet/config.yaml або /var/lib/kubelet/kubeadm-flags.env потрібен перезапуск kubelet.

Що далі

4.2.1.9 - Зміна репозиторія пакунків Kubernetes

Ця сторінка пояснює, як увімкнути репозиторій пакунків для бажаного мінорного випуску Kubernetes під час оновлення кластера. Це потрібно лише для користувачів репозиторіїв пакунків, що підтримуються спільнотою та розміщені на pkgs.k8s.io. На відміну від застарілих репозиторіїв пакунків, репозиторії пакунків, що підтримуються спільнотою, структуровані таким чином, що для кожної мінорної версії Kubernetes є окремий репозиторій пакунків.

Перш ніж ви розпочнете

У цьому документі припускається, що ви вже використовуєте репозиторії пакунків, які підтримуються спільнотою (pkgs.k8s.io). Якщо це не так, настійно рекомендується перейти на репозиторії пакунків, які підтримуються спільнотою, як описано в офіційному оголошенні.

Перевірка використання репозиторіїв пакунків Kubernetes

Якщо ви не впевнені, чи ви використовуєте репозиторії пакунків, які підтримуються спільнотою, чи застарілі репозиторії пакунків, виконайте наступні кроки для перевірки:

Виведіть вміст файлу, який визначає apt-репозиторій Kubernetes:

# У вашій системі цей файл конфігурації може мати іншу назву
pager /etc/apt/sources.list.d/kubernetes.list

Якщо ви бачите рядок, схожий на:

deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.30/deb/ /

Ви використовуєте репозиторії пакунків Kubernetes, і цей посібник стосується вас. Інакше настійно рекомендується перейти на репозиторії пакунків Kubernetes, які підтримуються спільнотою, як описано в офіційному оголошенні.

Виведіть вміст файлу, який визначає yum-репозиторій Kubernetes:

# У вашій системі цей файл конфігурації може мати іншу назву
cat /etc/yum.repos.d/kubernetes.repo

Якщо ви бачите baseurl, схожий на baseurl в наведеному нижче виводі:

[kubernetes]
name=Kubernetes
baseurl=https://pkgs.k8s.io/core:/stable:/v1.30/rpm/
enabled=1
gpgcheck=1
gpgkey=https://pkgs.k8s.io/core:/stable:/v1.30/rpm/repodata/repomd.xml.key
exclude=kubelet kubeadm kubectl

Ви використовуєте репозиторії пакунків Kubernetes, і цей посібник стосується вас. Інакше настійно рекомендується перейти на репозиторії пакунків Kubernetes, які підтримуються спільнотою, як описано в офіційному оголошенні.

Виведіть вміст файлу, який визначає zypper-репозиторій Kubernetes:

# У вашій системі цей файл конфігурації може мати іншу назву
cat /etc/zypp/repos.d/kubernetes.repo

Якщо ви бачите baseurl, схожий на baseurl в наведеному нижче виводі:

[kubernetes]
name=Kubernetes
baseurl=https://pkgs.k8s.io/core:/stable:/v1.30/rpm/
enabled=1
gpgcheck=1
gpgkey=https://pkgs.k8s.io/core:/stable:/v1.30/rpm/repodata/repomd.xml.key
exclude=kubelet kubeadm kubectl

Ви використовуєте репозиторії пакунків Kubernetes, і цей посібник стосується вас. Інакше настійно рекомендується перейти на репозиторії пакунків Kubernetes, які підтримуються спільнотою, як описано в офіційному оголошенні.

Перехід на інший репозиторій пакунків Kubernetes

Цей крок слід виконати при оновленні з одного мінорного випуску Kubernetes на інший для отримання доступу до пакунків бажаної мінорної версії Kubernetes.

  1. Відкрийте файл, який визначає apt-репозиторій Kubernetes за допомогою текстового редактора на ваш вибір:

    nano /etc/apt/sources.list.d/kubernetes.list
    

    Ви повинні побачити один рядок з URL, що містить вашу поточну мінорну версію Kubernetes. Наприклад, якщо ви використовуєте v1.30, ви повинні побачити це:

    deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.30/deb/ /
    
  2. Змініть версію в URL на наступний доступний мінорний випуск, наприклад:

    deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.31/deb/ /
    
  3. Збережіть файл і вийдіть з текстового редактора. Продовжуйте дотримуватися відповідних інструкцій щодо оновлення.

  1. Відкрийте файл, який визначає yum-репозиторій Kubernetes за допомогою текстового редактора на ваш вибір:

    nano /etc/yum.repos.d/kubernetes.repo
    

    Ви повинні побачити файл з двома URL, що містять вашу поточну мінорну версію Kubernetes. Наприклад, якщо ви використовуєте v1.30, ви повинні побачити це:

    [kubernetes]
    name=Kubernetes
    baseurl=https://pkgs.k8s.io/core:/stable:/v1.30/rpm/
    enabled=1
    gpgcheck=1
    gpgkey=https://pkgs.k8s.io/core:/stable:/v1.30/rpm/repodata/repomd.xml.key
    exclude=kubelet kubeadm kubectl cri-tools kubernetes-cni
    
  2. Змініть версію в цих URL на наступний доступний мінорний випуск, наприклад:

    [kubernetes]
    name=Kubernetes
    baseurl=https://pkgs.k8s.io/core:/stable:/v1.31/rpm/
    enabled=1
    gpgcheck=1
    gpgkey=https://pkgs.k8s.io/core:/stable:/v1.31/rpm/repodata/repomd.xml.key
    exclude=kubelet kubeadm kubectl cri-tools kubernetes-cni
    
  3. Збережіть файл і вийдіть з текстового редактора. Продовжуйте дотримуватися відповідних інструкцій щодо оновлення.

Що далі

4.2.2 - Міграція з dockershim

Цей розділ містить інформацію, яку вам потрібно знати при міграції з dockershim на інші оточення виконання контейнерів.

Після оголошення про застарівання dockershim в Kubernetes 1.20, виникли питання, як це вплине на різні робочі навантаження та розгортання самого Kubernetes. Наш Dockershim Removal FAQ допоможе вам краще зрозуміти проблему.

Dockershim був видалений з Kubernetes з випуском v1.24. Якщо ви використовуєте Docker Engine через dockershim як своє оточення виконання контейнерів і хочете оновитись до v1.24, рекомендується або мігрувати на інше оточення виконання, або знайти альтернативний спосіб отримання підтримки Docker Engine. Ознайомтеся з розділом оточення виконання контейнерів, щоб дізнатися про ваші варіанти.

Версія Kubernetes з dockershim (1.23) вийшла з стану підтримки, а v1.24 скоро вийде зі стану підтримки. Переконайтеся, що повідомляєте про проблеми з міграцією, щоб проблеми могли бути вчасно виправлені, і ваш кластер був готовий до видалення dockershim. Після виходу v1.24 зі стану підтримки вам доведеться звертатися до вашого постачальника Kubernetes за підтримкою або оновлювати кілька версій одночасно, якщо є критичні проблеми, які впливають на ваш кластер.

Ваш кластер може мати більше одного типу вузлів, хоча це не є загальною конфігурацією.

Ці завдання допоможуть вам здійснити міграцію:

Що далі

4.2.2.1 - Заміна середовища виконання контейнерів на вузлі з Docker Engine на containerd

Це завдання визначає кроки, необхідні для оновлення вашого середовища виконання контейнерів на containerd з Docker. Воно буде корисним для операторів кластерів, які працюють з Kubernetes 1.23 або старішими версіями. Воно також охоплює приклад сценарію міграції з dockershim на containerd. З цієї сторінки можна вибрати альтернативні середовища виконання контейнерів.

Перш ніж ви розпочнете

Встановіть containerd. Для отримання додаткової інформації дивіться документацію з встановлення containerd і для конкретних передумов виконуйте кроки описані в посібнику containerd.

Виведення вузла з експлуатації

kubectl drain <node-to-drain> --ignore-daemonsets

Замініть <node-to-drain> на імʼя вузла, який ви збираєтеся виводити з експлуатації.

Зупиніть службу Docker

systemctl stop kubelet
systemctl disable docker.service --now

Встановлення Containerd

Дотримуйтесь настанов посібника для отримання детальних кроків з встановлення containerd.

  1. Встановіть пакунок containerd.io з офіційних репозиторіїв Docker. Інструкції щодо налаштування репозиторію Docker для вашого конкретного дистрибутиву Linux і встановлення пакунка containerd.io можна знайти у Починаючи з containerd.

  2. Налаштуйте containerd:

    sudo mkdir -p /etc/containerd
    containerd config default | sudo tee /etc/containerd/config.toml
    
  3. Перезапустіть containerd:

    sudo systemctl restart containerd
    

Розпочніть сеанс PowerShell, встановіть значення $Version на бажану версію (наприклад, $Version="1.4.3"), а потім виконайте наступні команди:

  1. Завантажте containerd:

    curl.exe -L https://github.com/containerd/containerd/releases/download/v$Version/containerd-$Version-windows-amd64.tar.gz -o containerd-windows-amd64.tar.gz
    tar.exe xvf .\containerd-windows-amd64.tar.gz
    
  2. Розпакуйте та налаштуйте:

    Copy-Item -Path ".\bin\" -Destination "$Env:ProgramFiles\containerd" -Recurse -Force
    cd $Env:ProgramFiles\containerd\
    .\containerd.exe config default | Out-File config.toml -Encoding ascii
    
    # Перегляньте конфігурацію. Залежно від налаштувань можливо, ви захочете внести корективи:
    # - образ sandbox_image (образ pause Kubernetes)
    # - розташування cni bin_dir та conf_dir
    Get-Content config.toml
    
    # (Необовʼязково, але дуже рекомендується) Виключіть containerd зі сканування Windows Defender
    Add-MpPreference -ExclusionProcess "$Env:ProgramFiles\containerd\containerd.exe"
    
  3. Запустіть containerd:

    .\containerd.exe --register-service
    Start-Service containerd
    

Налаштування kubelet для використання containerd як його середовища виконання контейнерів

Відредагуйте файл /var/lib/kubelet/kubeadm-flags.env та додайте середовище виконання контейнерів до прапорців; --container-runtime-endpoint=unix:///run/containerd/containerd.sock.

Користувачі, які використовують kubeadm, повинні знати, що інструмент kubeadm зберігає сокет CRI для кожного хосту як анотацію в обʼєкті Node для цього хосту. Щоб змінити його, ви можете виконати наступну команду на машині, на якій є файл kubeadm /etc/kubernetes/admin.conf.

kubectl edit no <імʼя-вузла>

Це запустить текстовий редактор, де ви можете редагувати обʼєкт Node. Для вибору текстового редактора ви можете встановити змінну середовища KUBE_EDITOR.

  • Змініть значення kubeadm.alpha.kubernetes.io/cri-socket з /var/run/dockershim.sock на шлях сокета CRI за вашим вибором (наприклад, unix:///run/containerd/containerd.sock).

    Зауважте, що нові шляхи сокета CRI в ідеалі повині мати префікс unix://.

  • Збережіть зміни в текстовому редакторі, що оновить обʼєкт Node.

Перезапустіть kubelet

systemctl start kubelet

Перевірте, що вузол справний

Запустіть kubectl get nodes -o wide, і containerd зʼявиться як середовище виконання для вузла, який ми щойно змінили.

Видаліть Docker Engine

Якщо вузол виглядає справним, видаліть Docker.

sudo yum remove docker-ce docker-ce-cli

sudo apt-get purge docker-ce docker-ce-cli

sudo dnf remove docker-ce docker-ce-cli

sudo apt-get purge docker-ce docker-ce-cli

Попередні команди не видаляють образи, контейнери, томи або налаштовані файли конфігурації на вашому хості. Щоб їх видалити, слідуйте інструкціям Docker щодо Видалення Docker Engine.

Введення вузла в експлуатацію

kubectl uncordon <node-to-uncordon>

Замініть <node-to-uncordon> на імʼя вузла, який ви раніше вивели з експлуатації.

4.2.2.2 - Міграція вузлів Docker Engine з dockershim на cri-dockerd

Ця сторінка показує вам, як перевести ваші вузли з Docker Engine на використання cri-dockerd замість dockershim. Ви повинні дотримуватися цих кроків у таких сценаріях:

  • Ви хочете перейти від dockershim і все ще використовувати Docker Engine для запуску контейнерів у Kubernetes.
  • Ви хочете оновити до Kubernetes v1.31 і ваш наявний кластер покладається на dockershim, у такому випадку вам необхідно перейти з dockershim, де cri-dockerd є одним з варіантів.

Щоб дізнатися більше про видалення dockershim, прочитайте сторінку ЧаПи.

Що таке cri-dockerd?

У Kubernetes 1.23 та раніше ви могли використовувати Docker Engine з Kubernetes, покладаючись на вбудований компонент Kubernetes, що називався dockershim. Компонент dockershim було вилучено у випуску Kubernetes 1.24; проте доступний сторонній замінник, cri-dockerd. Адаптер cri-dockerd дозволяє використовувати Docker Engine через інтерфейс середовища виконання контейнерів.

Якщо ви хочете мігрувати на cri-dockerd, щоб продовжувати використовувати Docker Engine як своє середовище виконання контейнерів, вам слід виконати наступне для кожного вузла:

  1. Встановіть cri-dockerd.
  2. Відключіть та вимкніть вузол.
  3. Налаштуйте kubelet для використання cri-dockerd.
  4. Перезапустіть kubelet.
  5. Перевірте, що вузол справний.

Спочатку протестуйте міграцію на не критичних вузлах.

Ви повинні виконати наступні кроки для кожного вузла, який ви хочете перевести на cri-dockerd.

Перш ніж ви розпочнете

Відключіть та вимкніть вузол

  1. Відключіть вузол, щоб зупинити нові запуски капсул на ньому:

    kubectl cordon <NODE_NAME>
    

    Замініть <NODE_NAME> на імʼя вузла.

  2. Вимкніть вузол, щоб безпечно виселити працюючі Podʼи:

    kubectl drain <NODE_NAME> \
        --ignore-daemonsets
    

Налаштуйте kubelet для використання cri-dockerd

Ці кроки застосовуються до кластерів, створених за допомогою інструменту kubeadm. Якщо ви використовуєте інший інструмент, вам слід модифікувати kubelet, використовуючи інструкції з налаштування для цього інструменту.

  1. Відкрийте /var/lib/kubelet/kubeadm-flags.env на кожному ураженому вузлі.
  2. Змініть прапорець --container-runtime-endpoint на unix:///var/run/cri-dockerd.sock.
  3. Змініть прапорець --container-runtime на remote (недоступно в Kubernetes v1.27 та пізніше).

Інструмент kubeadm зберігає сокет вузла як анотацію обʼєкта Node в панелі управління. Щоб змінити цей сокет для кожного ураженого вузла:

  1. Відредагуйте YAML-представлення обʼєкта Node:

    KUBECONFIG=/шлях/до/admin.conf kubectl edit no <NODE_NAME>
    

    Замініть наступне:

    • /шлях/до/admin.conf: шлях до файлу конфігурації kubectl, admin.conf.
    • <NODE_NAME>: імʼя вузла, яке ви хочете змінити.
  2. Змініть kubeadm.alpha.kubernetes.io/cri-socket з /var/run/dockershim.sock на unix:///var/run/cri-dockerd.sock.

  3. Збережіть зміни. Обʼєкт Node оновлюється при збереженні.

Перезапустіть kubelet

systemctl restart kubelet

Перевірте, що вузол справний

Щоб перевірити, чи використовує вузол точку доступу cri-dockerd, слідувати інструкціям Дізнайтеся, яке середовище виконання контейнерів використовується. Прапорець --container-runtime-endpoint для kubelet повинен бути unix:///var/run/cri-dockerd.sock.

Введення вузла в експлуатацію

Введіть вузол в експлуатацію, щоб Podʼи могли запускатися на ньому:

kubectl uncordon <NODE_NAME>

Що далі

4.2.2.3 - Перевірте, яке середовище виконання контейнерів використовується на вузлі

На цій сторінці наведено кроки для визначення того, яке середовище виконання контейнерів використовують вузли у вашому кластері.

Залежно від того, як ви запускаєте свій кластер, середовище виконання контейнерів для вузлів може бути попередньо налаштованим або вам потрібно його налаштувати. Якщо ви використовуєте сервіс Kubernetes, що надається вам постачальником послуг, можуть існувати специфічні для нього способи перевірки того, яке середовище виконання контейнерів налаштоване для вузлів. Метод, описаний на цій сторінці, повинен працювати завжди, коли дозволяється виконання kubectl.

Перш ніж ви розпочнете

Встановіть та налаштуйте kubectl. Див. розділ Встановлення інструментів для отримання деталей.

Визначте середовище виконання контейнерів, яке використовується на вузлі

Використовуйте kubectl, щоб отримати та показати інформацію про вузли:

kubectl get nodes -o wide

Вивід подібний до такого. Стовпець CONTAINER-RUNTIME виводить інформацію про середовище та його версію.

Для Docker Engine вивід схожий на цей:

NAME         STATUS   VERSION    CONTAINER-RUNTIME
node-1       Ready    v1.16.15   docker://19.3.1
node-2       Ready    v1.16.15   docker://19.3.1
node-3       Ready    v1.16.15   docker://19.3.1

Якщо ваше середовище показується як Docker Engine, це все одно не означає, що вас точно торкнеться видалення dockershim у Kubernetes v1.24. Перевірте точку доступу середовища, щоб побачити, чи використовуєте ви dockershim. Якщо ви не використовуєте dockershim, вас це не стосується.

Для containerd вивід схожий на цей:

NAME         STATUS   VERSION   CONTAINER-RUNTIME
node-1       Ready    v1.19.6   containerd://1.4.1
node-2       Ready    v1.19.6   containerd://1.4.1
node-3       Ready    v1.19.6   containerd://1.4.1

Дізнайтеся більше інформації про середовища виконання контейнерів на сторінці Середовища виконання контейнерів.

Дізнайтеся, яку точку доступу середовища виконання контейнерів ви використовуєте

Середовище виконання контейнерів спілкується з kubelet через Unix-сокет, використовуючи протокол CRI, який базується на фреймворку gRPC. Kubelet діє як клієнт, а середовище — як сервер. У деяких випадках може бути корисно знати, який сокет використовується на ваших вузлах. Наприклад, з видаленням dockershim у Kubernetes v1.24 і пізніше ви, можливо, захочете знати, чи використовуєте ви Docker Engine з dockershim.

Ви можете перевірити, який сокет ви використовуєте, перевіривши конфігурацію kubelet на своїх вузлах.

  1. Прочитайте початкові команди для процесу kubelet:

    tr \\0 ' ' < /proc/"$(pgrep kubelet)"/cmdline
    

    Якщо у вас немає tr або pgrep, перевірте командний рядок для процесу kubelet вручну.

  2. У виведенні шукайте прапорець --container-runtime та прапорець --container-runtime-endpoint.

    • Якщо ваші вузли використовують Kubernetes v1.23 та старіший, і ці прапори відсутні або прапорець --container-runtime не є remote, ви використовуєте сокет dockershim з Docker Engine. Параметр командного рядка --container-runtime не доступний у Kubernetes v1.27 та пізніше.
    • Якщо прапорець --container-runtime-endpoint присутній, перевірте імʼя сокета, щоб дізнатися, яке середовище ви використовуєте. Наприклад, unix:///run/containerd/containerd.sock — це точка доступу containerd.

Якщо ви хочете змінити середовище виконання контейнерів на вузлі з Docker Engine на containerd, ви можете дізнатися більше інформації про міграцію з Docker Engine на containerd, або, якщо ви хочете продовжити використовувати Docker Engine у Kubernetes v1.24 та пізніше, мігруйте на сумісний з CRI адаптер, наприклад cri-dockerd.

4.2.2.4 - Виправлення помилок, повʼязаних з втулками CNI

Щоб уникнути помилок, повʼязаних з втулками CNI, переконайтеся, що ви використовуєте або оновлюєте середовище виконання контейнерів, яке було протестовано й працює коректно з вашою версією Kubernetes.

Про помилки "Incompatible CNI versions" та "Failed to destroy network for sandbox"

Проблеми з Service існують для налаштування та демонтажу мережі CNI для Pod в containerd v1.6.0-v1.6.3, коли втулки CNI не були оновлені та/або версія конфігурації CNI не вказана в файлах конфігурації CNI. Команда containerd повідомляє, що "ці проблеми вирішені в containerd v1.6.4."

З containerd v1.6.0-v1.6.3, якщо ви не оновите втулки CNI та/або не вкажете версію конфігурації CNI, ви можете стикнутися з наступними умовами помилок "Incompatible CNI versions" або "Failed to destroy network for sandbox".

Помилка "Incompatible CNI versions"

Якщо версія вашого втулка CNI не відповідає версії втулка в конфігурації, тому що версія конфігурації є новішою, ніж версія втулка, лог containerd, швидше за все, покаже повідомлення про помилку при запуску Pod подібнe до:

incompatible CNI versions; config is \"1.0.0\", plugin supports [\"0.1.0\" \"0.2.0\" \"0.3.0\" \"0.3.1\" \"0.4.0\"]"

Щоб виправити цю проблему, оновіть свої втулки CNI та файли конфігурації CNI.

Помилка "Failed to destroy network for sandbox"

Якщо версія втулка відсутня в конфігурації втулка CNI, Pod може запускатися. Однак припинення Podʼа призводить до помилки, подібної до:

ERROR[2022-04-26T00:43:24.518165483Z] StopPodSandbox for "b" failed
error="failed to destroy network for sandbox \"bbc85f891eaf060c5a879e27bba9b6b06450210161dfdecfbb2732959fb6500a\": invalid version \"\": the version is empty"

Ця помилка залишає Pod у стані "not-ready" з приєднаним простором імен мережі. Щоб відновити роботу після цієї проблеми, відредагуйте файл конфігурації CNI, щоб додати відсутню інформацію про версію. Наступна спроба зупинити Pod повинна бути успішною.

Оновлення ваших втулків CNI та файлів конфігурації CNI

Якщо ви використовуєте containerd v1.6.0-v1.6.3 та зіткнулися з помилками "Incompatible CNI versions" або "Failed to destroy network for sandbox", розгляньте можливість оновлення ваших втулків CNI та редагування файлів конфігурації CNI.

Ось огляд типових кроків для кожного вузла:

  1. Безпечно виведіть та введіть вузол в експлуатацію.

  2. Після зупинки ваших служб середовища виконання контейнерів та kubelet виконайте наступні операції оновлення:

    • Якщо ви використовуєте втулки CNI, оновіть їх до останньої версії.
    • Якщо ви використовуєте не-CNI втулки, замініть їх втулками CNI. Використовуйте останню версію втулків.
    • Оновіть файл конфігурації втулка, щоб вказати або відповідати версії специфікації CNI, яку підтримує втулок, як показано у наступному розділі "Приклад файлу конфігурації containerd".
    • Для containerd переконайтеся, що ви встановили останню версію (v1.0.0 або пізніше) втулка CNI loopback.
    • Оновіть компоненти вузла (наприклад, kubelet) до Kubernetes v1.24.
    • Оновіть або встановіть найновішу версію середовища виконання контейнерів.
  3. Поверніть вузол у ваш кластер, перезапустивши ваше середовище виконання контейнерів та kubelet. Увімкніть вузол (kubectl uncordon <імʼя_вузла>).

Приклад файлу конфігурації containerd

Наведений нижче приклад показує конфігурацію для середовища виконання контейнерів containerd версії v1.6.x, яке підтримує останню версію специфікації CNI (v1.0.0).

Будь ласка, перегляньте документацію від вашого постачальника втулків та мереж для подальших інструкцій з налаштування вашої системи.

У Kubernetes, середовище виконання контейнерів containerd додає типовий інтерфейс loopback, lo, до Podʼів. Середовище виконання контейнерів containerd налаштовує інтерфейс loopback через втулок CNI, loopback. Втулок loopback розповсюджується як частина пакунків релізу containerd, які мають позначення cni. containerd v1.6.0 та пізніше включає сумісний з CNI v1.0.0 втулок loopback, а також інші типові втулки CNI. Налаштування втулка loopback виконується внутрішньо за допомогою контейнерного середовища containerd і встановлюється для використання CNI v1.0.0. Це також означає, що версія втулка loopback повинна бути v1.0.0 або пізніше при запуску цієї новішої версії containerd.

Наступна команда bash генерує приклад конфігурації CNI. Тут значення 1.0.0 для версії конфігурації призначено для поля cniVersion для використання при запуску containerd втулком bridge CNI.

cat << EOF | tee /etc/cni/net.d/10-containerd-net.conflist
{
 "cniVersion": "1.0.0",
 "name": "containerd-net",
 "plugins": [
   {
     "type": "bridge",
     "bridge": "cni0",
     "isGateway": true,
     "ipMasq": true,
     "promiscMode": true,
     "ipam": {
       "type": "host-local",
       "ranges": [
         [{
           "subnet": "10.88.0.0/16"
         }],
         [{
           "subnet": "2001:db8:4860::/64"
         }]
       ],
       "routes": [
         { "dst": "0.0.0.0/0" },
         { "dst": "::/0" }
       ]
     }
   },
   {
     "type": "portmap",
     "capabilities": {"portMappings": true},
     "externalSetMarkChain": "KUBE-MARK-MASQ"
   }
 ]
}
EOF

Оновіть діапазони IP-адрес у прикладі відповідно до вашого випадку використання та плану адресації мережі.

4.2.2.5 - Перевірка впливу видалення dockershim на ваш кластер

Компонент dockershim Kubernetes дозволяє використовувати Docker як середовище виконання контейнерів Kubernetes. Вбудований компонент dockershim Kubernetes був видалений у випуску v1.24.

Ця сторінка пояснює, як ваш кластер може використовувати Docker як середовище виконання контейнерів, надає деталі щодо ролі, яку відіграє dockershim при використанні, і показує кроки, які можна виконати, щоб перевірити, чи може видалення dockershim впливати на робочі навантаження.

Пошук залежностей вашого застосунку від Docker

Якщо ви використовуєте Docker для побудови контейнерів вашого застосунку, ви все ще можете запускати ці контейнери на будь-якому середовищі виконання контейнерів. Це використання Docker не вважається залежністю від Docker як середовища виконання контейнерів.

Коли використовується альтернативне середовище виконання контейнерів, виконання команд Docker може або не працювати, або призводити до неочікуваного виводу. Ось як ви можете зʼясувати, чи є у вас залежність від Docker:

  1. Переконайтеся, що привілейовані Podʼи не виконують команди Docker (наприклад, docker ps), перезапускають службу Docker (команди типу systemctl restart docker.service) або змінюють файли Docker, такі як /etc/docker/daemon.json.
  2. Перевірте наявність приватних реєстрів або налаштувань дзеркал образів у файлі конфігурації Docker (наприклад, /etc/docker/daemon.json). Зазвичай їх потрібно повторно налаштувати для іншого середовища виконання контейнерів.
  3. Перевірте, що скрипти та застосунки, які працюють на вузлах поза вашою інфраструктурою Kubernetes, не виконують команди Docker. Це може бути:
    • SSH на вузли для усунення несправностей;
    • Сценарії запуску вузлів;
    • Встановлені безпосередньо на вузлах агенти безпеки та моніторингу.
  4. Інструменти сторонніх розробників, які виконують вищезгадані привілейовані операції. Див. Міграція телеметрії та агентів безпеки з dockershim для отримання додаткової інформації.
  5. Переконайтеся, що немає непрямих залежностей від поведінки dockershim. Це крайній випадок і ймовірно не вплине на ваш застосунок. Деякі інструменти можуть бути налаштовані реагувати на специфічну поведінку Docker, наприклад, видаляти сповіщення про певні метрики або шукати певне повідомлення у лозі як частину інструкцій щодо усунення несправностей. Якщо у вас налаштовано такі інструменти, перевірте поведінку на тестовому кластері перед міграцією.

Пояснення залежності від Docker

Середовище виконання контейнерів — це програмне забезпечення, яке може виконувати контейнери, які складаються з Podʼів Kubernetes. Kubernetes відповідає за оркестрування та планування Podʼів; на кожному вузлі kubelet використовує інтерфейс середовища виконання контейнерів як абстракцію, щоб ви могли використовувати будь-яке сумісне середовище виконання контейнерів.

У своїх перших випусках Kubernetes пропонував сумісність з одним середовищем виконання контейнерів — Docker. Пізніше, в історії проєкту Kubernetes, оператори кластерів хотіли б використовувати додаткові середовища виконання контейнерів. CRI було розроблено для того, щоб дозволити такий вид гнучкості — і kubelet почав підтримувати CRI. Однак, оскільки Docker існував до того, як була винайдена специфікація CRI, проєкт Kubernetes створив адаптер dockershim. Адаптер dockershim дозволяє kubelet взаємодіяти з Docker так, ніби Docker був середовищем виконання контейнерів, сумісним з CRI.

Ви можете прочитати про це в блозі Інтеграція Kubernetes Containerd стає загально доступною.

Dockershim vs. CRI з Containerd

Перехід до Containerd як середовища виконання контейнерів прибирає посередника. Всі ті самі контейнери можуть бути запущені середовищем виконання контейнерів, такими як Containerd, як і раніше. Але тепер, оскільки контейнери розміщуються безпосередньо з середовищем виконання контейнерів, вони не є видимими для Docker. Отже, будь-який інструментарій Docker або стильний інтерфейс користувача, який ви могли використовувати раніше для перевірки цих контейнерів, більше не доступний.

Ви не можете отримати інформацію про контейнери за допомогою команд docker ps або docker inspect. Оскільки ви не можете отримувати перелік контейнерів, ви не можете отримати логи, зупинити контейнери або виконати щось всередині контейнера за допомогою docker exec.

Ви все ще можете отримувати образи або будувати їх за допомогою команди docker build. Але образи, побудовані або отримані Docker, не будуть видимі для середовища виконання контейнерів та Kubernetes. Їх потрібно буде розмістити у якомусь реєстрі, щоб їх можна було використовувати в Kubernetes.

Відомі проблеми

Деякі метрики файлової системи відсутні та формат метрик відрізняється

Точка доступу Kubelet /metrics/cadvisor надає метрики Prometheus, як описано в Метрики для системних компонентів Kubernetes. Якщо ви встановите збирач метрик, який залежить від цієї точки доступу, ви можете побачити такі проблеми:

  • Формат метрик на вузлі Docker - це k8s_<container-name>_<pod-name>_<namespace>_<pod-uid>_<restart-count>, але формат у іншому середовищі відрізняється. Наприклад, на вузлі containerd він має вигляд <container-id>.

  • Деякі метрики файлової системи відсутні, як описано нижче:

    container_fs_inodes_free
    container_fs_inodes_total
    container_fs_io_current
    container_fs_io_time_seconds_total
    container_fs_io_time_weighted_seconds_total
    container_fs_limit_bytes
    container_fs_read_seconds_total
    container_fs_reads_merged_total
    container_fs_sector_reads_total
    container_fs_sector_writes_total
    container_fs_usage_bytes
    container_fs_write_seconds_total
    container_fs_writes_merged_total
    

Обхідний шлях

Ви можете помʼякшити цю проблему, використовуючи cAdvisor як автономний DaemonSet.

  1. Знайдіть останній реліз cAdvisor із шаблоном імені vX.Y.Z-containerd-cri (наприклад, v0.42.0-containerd-cri).
  2. Дотримуйтесь кроків у DaemonSet Kubernetes cAdvisor, щоб створити DaemonSet.
  3. Drf;Вкажіть збирачу метрик використовувати точку доступу /metrics cAdvisor, яка надає повний набір метрик контейнера в форматі Prometheus.

Альтернативи:

  • Використовуйте альтернативне рішення для збору метрик сторонніх розробників.
  • Збирайте метрики з Kubelet summary API, який доступний через /stats/summary.

Що далі

4.2.2.6 - Міграція агентів телеметрії та безпеки з dockershim

Підтримка Kubernetes прямої інтеграції з Docker Engine є застарілою та була видалена. Більшість застосунків не мають прямої залежності від середовища виконання контейнерів. Однак, є ще багато агентів телеметрії та моніторингу, які мають залежність від Docker для збору метаданих, логів та метрик контейнерів. Цей документ збирає інформацію про те, як виявити ці залежності, а також посилання на те, як перенести ці агенти для використання загальних інструментів або альтернативних середовищ виконання.

Агенти телеметрії та безпеки

У кластері Kubernetes є кілька різних способів запуску агентів телеметрії чи безпеки. Деякі агенти мають пряму залежність від Docker Engine, коли вони працюють як DaemonSets або безпосередньо на вузлах.

Чому деякі агенти телеметрії взаємодіють з Docker Engine?

Історично Kubernetes був спеціально створений для роботи з Docker Engine. Kubernetes займався мережею та плануванням, покладаючись на Docker Engine для запуску та виконання контейнерів (у Podʼах) на вузлі. Деяка інформація, яка стосується телеметрії, наприклад, імʼя Podʼа, доступна лише з компонентів Kubernetes. Інші дані, такі як метрики контейнерів, не є обовʼязком середовища виконання контейнера. Ранні агенти телеметрії мали потребу у запиті середовища виконання контейнера та Kubernetes для передачі точної картини. З часом Kubernetes набув можливості підтримки кількох середовищ виконання контейнерів, і зараз підтримує будь-яке середовище виконання, яке сумісне з інтерфейсом середовища виконання контейнерів.

Деякі агенти телеметрії покладаються тільки на інструменти Docker Engine. Наприклад, агент може виконувати команду, таку як docker ps чи docker top для отримання переліку контейнерів та процесів або docker logs для отримання поточних логів. Якщо вузли у вашому проточному кластері використовують Docker Engine, і ви переходите на інше середовище виконання контейнерів, ці команди більше не працюватимуть.

Виявлення DaemonSets, що залежать від Docker Engine

Якщо Pod хоче викликати dockerd, що працює на вузлі, він повинен або:

  • змонтувати файлову систему, що містить привілейований сокет Docker, як том; або
  • безпосередньо змонтувати конкретний шлях привілейованого сокета Docker, також як том.

Наприклад: на образах COS Docker відкриває свій Unix сокет у /var/run/docker.sock. Це означає, що специфікація Pod буде містити монтування тому hostPath з /var/run/docker.sock.

Нижче наведено приклад сценарію оболонки для пошуку Podʼів, які мають монтування, які безпосередньо зіставляються з сокетом Docker. Цей сценарій виводить простір імен та імʼя Podʼа. Ви можете видалити grep '/var/run/docker.sock', щоб переглянути інші монтування.

kubectl get pods --all-namespaces \
-o=jsonpath='{range .items[*]}{"\n"}{.metadata.namespace}{":\t"}{.metadata.name}{":\t"}{range .spec.volumes[*]}{.hostPath.path}{", "}{end}{end}' \
| sort \
| grep '/var/run/docker.sock'

Виявлення залежності від Docker агентів вузлів

Якщо вузли кластера налаштовані та встановлюють додаткові заходи безпеки та агенти телеметрії на вузлі, перевірте у вендора агента, чи має він будь-які залежності від Docker.

Вендори агентів телеметрії та безпеки

Цей розділ призначений для збирання інформації про різноманітних агентів телеметрії та безпеки, які можуть мати залежність від середовищ виконання контейнерів.

Ми зберігаємо робочу версію інструкцій щодо перенесення для різних вендорів агентів телеметрії та безпеки у документі Google. Будь ласка, звʼяжіться з вендором, щоб отримати актуальні інструкції щодо міграції з dockershim.

Міграція з dockershim

Aqua

Ніяких змін не потрібно: все має працювати без перешкод при перемиканні середовища виконання.

Datadog

Як перенести: Застарівання Docker у Kubernetes Pod, який має доступ до Docker Engine, може мати назву, яка містить будь-що з:

  • datadog-agent
  • datadog
  • dd-agent

Dynatrace

Як перенести: Міграція з Docker до загальних метрик контейнера в Dynatrace

Оголошення підтримки Containerd: Автоматична повна видимість у стеку в середовищах Kubernetes на основі containerd

Оголошення підтримки CRI-O: Автоматична повна видимість у ваших контейнерах Kubernetes з CRI-O (бета)

Pod, який має доступ до Docker, може мати назву, яка містить:

  • dynatrace-oneagent

Falco

Як перенести: Міграція Falco з dockershim. Falco підтримує будь-яке середовище виконання, сумісне з CRI (стандартно використовується containerd); документація пояснює всі деталі. Pod, який має доступ до Docker, може мати назву, яка містить:

  • falco

Prisma Cloud Compute

Перевірте документацію для Prisma Cloud, в розділі "Встановлення Prisma Cloud в кластер CRI (не Docker)". Pod, який має доступ до Docker, може мати назву, подібну до:

  • twistlock-defender-ds

SignalFx (Splunk)

Смарт-агент SignalFx (застарілий) використовує кілька різних моніторів для Kubernetes, включаючи kubernetes-cluster, kubelet-stats/kubelet-metrics та docker-container-stats. Монітор kubelet-stats раніше був застарілим вендором на користь kubelet-metrics. Монітор docker-container-stats є одним з тих, що стосуються видалення dockershim. Не використовуйте монітор docker-container-stats з середовищами виконання контейнерів, відмінними від Docker Engine.

Як перейти з агента, залежного від dockershim:

  1. Видаліть docker-container-stats зі списку налаштованих моніторів. Зверніть увагу, що залишення цього монітора увімкненим з не-dockershim середовищем виконання призведе до неправильних метрик при встановленні docker на вузлі та відсутності метрик, коли docker не встановлено.
  2. Увімкніть та налаштуйте монітор kubelet-metrics.

Pod, який має доступ до Docker, може мати назву, подібну до:

  • signalfx-agent

Yahoo Kubectl Flame

Flame не підтримує середовищ виконання контейнера, відмінні від Docker. Див. https://github.com/yahoo/kubectl-flame/issues/51

4.2.3 - Генерація сертифікатів вручну

При використанні автентифікації сертифіката клієнта ви можете генерувати сертифікати вручну за допомогою easyrsa, openssl або cfssl.

easyrsa

З easyrsa ви можете вручну генерувати сертифікати для вашого кластера.

  1. Завантажте, розпакуйте та ініціалізуйте патчену версію easyrsa3.

    curl -LO https://dl.k8s.io/easy-rsa/easy-rsa.tar.gz
    tar xzf easy-rsa.tar.gz
    cd easy-rsa-master/easyrsa3
    ./easyrsa init-pki
    
  2. Згенеруйте новий центр сертифікації (CA). --batch встановлює автоматичний режим; --req-cn вказує загальну назву (CN, Common Name) для нового кореневого сертифіката CA.

    ./easyrsa --batch "--req-cn=${MASTER_IP}@`date +%s`" build-ca nopass
    
  3. Згенеруйте сертифікат та ключ сервера.

    Аргумент --subject-alt-name встановлює можливі IP-адреси та імена DNS, за якими буде доступний сервер API. MASTER_CLUSTER_IP зазвичай є першою IP-адресою з діапазону служб CIDR, який вказаний як аргумент --service-cluster-ip-range для сервера API та компонента керування контролером. Аргумент --days використовується для встановлення кількості днів чинності сертифіката. У прикладі нижче також припускається, що ви використовуєте cluster.local як типове імʼя домену DNS.

    ./easyrsa --subject-alt-name="IP:${MASTER_IP},"\
    "IP:${MASTER_CLUSTER_IP},"\
    "DNS:kubernetes,"\
    "DNS:kubernetes.default,"\
    "DNS:kubernetes.default.svc,"\
    "DNS:kubernetes.default.svc.cluster,"\
    "DNS:kubernetes.default.svc.cluster.local" \
    --days=10000 \
    build-server-full server nopass
    
  4. Скопіюйте pki/ca.crt, pki/issued/server.crt та pki/private/server.key у вашу теку.

  5. Заповніть та додайте наступні параметри до параметрів запуску сервера API:

    --client-ca-file=/yourdirectory/ca.crt
    --tls-cert-file=/yourdirectory/server.crt
    --tls-private-key-file=/yourdirectory/server.key
    

openssl

Ви також можете вручну генерувати сертифікати за допомогою openssl.

  1. Згенеруйте 2048-бітний ca.key :

    openssl genrsa -out ca.key 2048
    
  2. Згенеруйте ca.crt для ca.key (використовуйте -days для встановлення кількості днів чинності сертифіката):

    openssl req -x509 -new -nodes -key ca.key -subj "/CN=${MASTER_IP}" -days 10000 -out ca.crt
    
  3. Згенеруйте 2048-бітний server.key:

    openssl genrsa -out server.key 2048
    
  4. Створіть конфігураційний файл для генерування Certificate Signing Request (CSR).

    Переконайтеся, що ви встановили власні значення для параметрів в кутових дужках, наприклад <MASTER_IP>, замінивши їх на власні значення перед збереженням файлу, наприклад з назвою csr.conf. Зауважте, що значення <MASTER_CLUSTER_IP> є IP-адресою API-сервера, як про це йдеться в попередньому розділі. Приклад конфігураційного файлу нижче використовує cluster.local як типове імʼя домену DNS.

    [ req ]
    default_bits = 2048
    prompt = no
    default_md = sha256
    req_extensions = req_ext
    distinguished_name = dn
    
    [ dn ]
    C = <country>
    ST = <state>
    L = <city>
    O = <organization>
    OU = <organization unit>
    CN = <MASTER_IP>
    
    [ req_ext ]
    subjectAltName = @alt_names
    
    [ alt_names ]
    DNS.1 = kubernetes
    DNS.2 = kubernetes.default
    DNS.3 = kubernetes.default.svc
    DNS.4 = kubernetes.default.svc.cluster
    DNS.5 = kubernetes.default.svc.cluster.local
    IP.1 = <MASTER_IP>
    IP.2 = <MASTER_CLUSTER_IP>
    
    [ v3_ext ]
    authorityKeyIdentifier=keyid,issuer:always
    basicConstraints=CA:FALSE
    keyUsage=keyEncipherment,dataEncipherment
    extendedKeyUsage=serverAuth,clientAuth
    subjectAltName=@alt_names
    
  5. Згенеруйте Certificate Signing Request (CSR) на основі конфігураційного файлу:

    openssl req -new -key server.key -out server.csr -config csr.conf
    
  6. Згенеруйте сертифікат сервера, використовуючи ca.key, ca.crt та server.csr:

    openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \
        -CAcreateserial -out server.crt -days 10000 \
        -extensions v3_ext -extfile csr.conf -sha256
    
  7. Перегляньте запит на підписання сертифіката:

    openssl req  -noout -text -in ./server.csr
    
  8. Перегляньте сертифікат:

    openssl x509 -noout -text -in ./server.crt
    

Нарешті, додайте ті ж самі параметри до параметрів запуску сервера API.

cfssl

Ви також можете вручну генерувати сертифікати за допомогою cfssl.

  1. Завантажте, розпакуйте та підготуйте інструменти як показано нижче

    curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssl_1.5.0_linux_amd64 -o cfssl
    chmod +x cfssl
    curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssljson_1.5.0_linux_amd64 -o cfssljson
    chmod +x cfssljson
    curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssl-certinfo_1.5.0_linux_amd64 -o cfssl-certinfo
    chmod +x cfssl-certinfo
    
  2. Створіть теку для зберігання артифактів та ініціалізації cfssl:

    mkdir cert
    cd cert
    ../cfssl print-defaults config > config.json
    ../cfssl print-defaults csr > csr.json
    
  3. Створіть конфігураційний файл JSON для генерації файлу CA, наприклад, ca-config.json:

    {
      "signing": {
        "default": {
          "expiry": "8760h"
        },
        "profiles": {
          "kubernetes": {
            "usages": [
              "signing",
              "key encipherment",
              "server auth",
              "client auth"
            ],
            "expiry": "8760h"
          }
        }
      }
    }
    
  4. Створіть конфігураційний файл JSON для генерації Certificate Signing Request (CSR), наприклад, ca-csr.json. Переконайтеся, що ви встановили власні значення для параметрів в кутових дужках.

    {
      "CN": "kubernetes",
      "key": {
        "algo": "rsa",
        "size": 2048
      },
      "names":[{
        "C": "<country>",
        "ST": "<state>",
        "L": "<city>",
        "O": "<organization>",
        "OU": "<organization unit>"
      }]
    }
    
  5. Згенеруйте сертифікат CA (ca.pem) та ключ CA (ca-key.pem):

    ../cfssl gencert -initca ca-csr.json | ../cfssljson -bare ca
    
  6. Створіть конфігураційний файл JSON для генерації ключів та сертифікатів для сервера API, наприклад, server-csr.json. Переконайтеся, що ви встановили власні значення для параметрів в кутових дужках. <MASTER_CLUSTER_IP> є IP-адресою кластера, як про це йдеться в попередньому розділі. В прикладі нижче також припускається, що ви використовуєте cluster.local як типове імʼя домену DNS.

    {
      "CN": "kubernetes",
      "hosts": [
        "127.0.0.1",
        "<MASTER_IP>",
        "<MASTER_CLUSTER_IP>",
        "kubernetes",
        "kubernetes.default",
        "kubernetes.default.svc",
        "kubernetes.default.svc.cluster",
        "kubernetes.default.svc.cluster.local"
      ],
      "key": {
        "algo": "rsa",
        "size": 2048
      },
      "names": [{
        "C": "<country>",
        "ST": "<state>",
        "L": "<city>",
        "O": "<organization>",
        "OU": "<organization unit>"
      }]
    }
    
  7. Згенеруйте ключ та сертифікат для сервера API, які типово зберігаються у файлах server-key.pem та server.pem, відповідно:

    ../cfssl gencert -ca=ca.pem -ca-key=ca-key.pem \
         --config=ca-config.json -profile=kubernetes \
         server-csr.json | ../cfssljson -bare server
    

Розповсюдження самопідписних сертифікатів CA

Клієнтський вузол може не визнавати самопідписні сертифікати CA. Для оточення, що не є операційним, або для операційного оточення, що працює за корпоративним фаєрволом, ви можете розповсюджувати самопідписні сертифікати CA на всіх клієнтів та оновлювати перелік довірених сертифікатів.

На кожному клієнті виконайте наступні кроки:

sudo cp ca.crt /usr/local/share/ca-certificates/kubernetes.crt
sudo update-ca-certificates
Updating certificates in /etc/ssl/certs...
1 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d....
done.

API сертифікатів

Ви можете використовувати certificates.k8s.io API для надання сертифікатів x509 для використання для автентифікації, як про це йдеться на сторінці Керування TLS в кластері.

4.2.4 - Керування ресурсами памʼяті, CPU та API

4.2.4.1 - Налаштування типових запитів та обмежень памʼяті для простору імен

Визначте типове обмеження ресурсів памʼяті для простору імен, щоб кожний новий Контейнер у цьому просторі імен мав налаштоване обмеження ресурсів памʼяті.

Ця сторінка показує, як налаштувати типові запити та обмеження памʼяті для простору імен.

Кластер Kubernetes може бути розділений на простори імен. Якщо у вас є простір імен, в якому вже є типове обмеження памʼяті limit, і ви спробуєте створити Pod з контейнером, який не вказує своє власне обмеження памʼяті, то панель управління назначає типове обмеження памʼяті цьому контейнеру.

Kubernetes назначає типовий запит памʼяті за певних умов, які будуть пояснені пізніше в цій темі.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

У вас має бути доступ до створення просторів імен у вашому кластері.

Кожен вузол у вашому кластері повинен мати принаймні 2 ГіБ памʼяті.

Створення простору імен

Створіть простір імен, щоб ресурси, які ви створюєте у цьому завданні, були ізольовані від решти вашого кластера.

kubectl create namespace default-mem-example

Створення LimitRange та Pod

Ось маніфест для прикладу LimitRange. Маніфест вказує типовий запит памʼяті та типове обмеження памʼяті.

apiVersion: v1
kind: LimitRange
metadata:
  name: mem-limit-range
spec:
  limits:
  - default:
      memory: 512Mi
    defaultRequest:
      memory: 256Mi
    type: Container

Створіть LimitRange у просторі імен default-mem-example:

kubectl apply -f https://k8s.io/examples/admin/resource/memory-defaults.yaml --namespace=default-mem-example

Тепер, якщо ви створите Pod у просторі імен default-mem-example, і будь-який контейнер у цьому Podʼі не вказує свої власні значення для запиту та обмеження памʼяті, то панель управління застосовує типові значення: запит памʼяті 256MiB та обмеження памʼяті 512MiB.

Ось приклад маніфесту для Pod, який має один контейнер. Контейнер не вказує запиту та обмеження памʼяті.

apiVersion: v1
kind: Pod
metadata:
  name: default-mem-demo
spec:
  containers:
  - name: default-mem-demo-ctr
    image: nginx

Створіть цей Pod.

kubectl apply -f https://k8s.io/examples/admin/resource/memory-defaults-pod.yaml --namespace=default-mem-example

Перегляньте інформацію про цей Pod:

kubectl get pod memory-defaults-pod --namespace=default-mem-example

Вивід має показати, що контейнер Podʼа має обмеження на запит памʼяті 256MiB та обмеження памʼяті 512MiB. Ці значення були назначені через типові обмеження памʼяті, вказані в LimitRange.

containers:
- image: nginx
  imagePullPolicy: Always
  name: default-mem-demo-ctr
  resources:
    limits:
      memory: 512Mi
    requests:
      memory: 256Mi

Видаліть свій Pod:

kubectl delete pod memory-defaults-pod --namespace=default-mem-example

Що якщо ви вказуєте обмеження контейнера, але не його запит?

Ось маніфест для Podʼа з одним контейнером. Контейнер вказує обмеження памʼяті, але не запит:

apiVersion: v1
kind: Pod
metadata:
  name: default-mem-demo-2
spec:
  containers:
  - name: default-mem-demo-2-ctr
    image: nginx
    resources:
      limits:
        memory: "1Gi"

Створіть Pod:

kubectl apply -f https://k8s.io/examples/admin/resource/memory-defaults-pod-2.yaml --namespace=default-mem-example

Перегляньте детальну інформацію про Pod:

kubectl get pod default-mem-demo-2 --output=yaml --namespace=default-mem-example

Вивід показує, що запит памʼяті контейнера встановлено таким чином, щоб відповідати його обмеженню памʼяті. Зверніть увагу, що контейнеру не було назначено типового значення запиту памʼяті 256Mi.

resources:
  limits:
    memory: 1Gi
  requests:
    memory: 1Gi

Що якщо ви вказуєте запит контейнера, але не його обмеження?

Ось маніфест для Podʼа з одним контейнером. Контейнер вказує запит памʼяті, але не обмеження:

apiVersion: v1
kind: Pod
metadata:
  name: default-mem-demo-3
spec:
  containers:
  - name: default-mem-demo-3-ctr
    image: nginx
    resources:
      requests:
        memory: "128Mi"

Створіть Pod:

kubectl apply -f https://k8s.io/examples/admin/resource/memory-defaults-pod-3.yaml --namespace=default-mem-example

Перегляньте специфікацію Podʼа:

kubectl get pod default-mem-demo-3 --output=yaml --namespace=default-mem-example

Вивід показує, що запит памʼяті контейнера встановлено на значення, вказане в маніфесті контейнера. Контейнер обмежений використовувати не більше 512MiB памʼяті, що відповідає типовому обмеженню памʼяті для простору імен.

resources:
  limits:
    memory: 512Mi
  requests:
    memory: 128Mi

Мотивація для типових обмежень та запитів памʼяті

Якщо у вашому просторі імен налаштовано квоту ресурсів памʼяті, корисно мати типове значення для обмеження памʼяті. Ось три обмеження, які накладає квота ресурсів на простір імен:

  • Для кожного Podʼа, який працює у просторі імен, Pod та кожен з його контейнерів повинні мати обмеження памʼяті. (Якщо ви вказуєте обмеження памʼяті для кожного контейнера у Podʼі, Kubernetes може вивести типове обмеження памʼяті на рівні Podʼа, додавши обмеження для його контейнерів).
  • Обмеження памʼяті застосовує резервування ресурсів на вузлі, де запускається відповідний Pod. Загальна кількість памʼяті, зарезервована для всіх Podʼів у просторі імен, не повинна перевищувати вказаного обмеження.
  • Загальна кількість памʼяті, що фактично використовується всіма Podʼами у просторі імен, також не повинна перевищувати вказаного обмеження.

Коли ви додаєте обмеження (LimitRange):

Якщо будь-який Pod у цьому просторі імен, що містить контейнер, не вказує своє власне обмеження памʼяті, панель управління застосовує типове обмеження памʼяті для цього контейнера, і Podʼу може бути дозволено запуститися в просторі імен, який обмежено квотою ресурсів памʼяті.

Очищення

Видаліть простір імен:

kubectl delete namespace default-mem-example

Що далі

Для адміністраторів кластера

Для розробників додатків

4.2.4.2 - Налаштування типових запитів та обмежень CPU для простору імен

Визначте типове обмеження ресурсів CPU для простору імен так, щоб усі нові Podʼи у цьому просторі імен мали налаштоване обмеження ресурсів CPU.

Ця сторінка показує, як налаштувати типові запити та обмеження CPU для просторів імен.

Кластер Kubernetes може бути розділений на простори імен. Якщо ви створюєте Pod у просторі імен, який має типове обмеження CPU limit, і будь-який контейнер у цьому Podʼі не вказує своє власне обмеження CPU, то панель управління назначає типове обмеження CPU цьому контейнеру.

Kubernetes назначає типовий запит CPU request, але лише за певних умов, які будуть пояснені пізніше на цій сторінці.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Вам потрібно мати доступ для створення просторів імен у вашому кластері.

Якщо ви ще не знайомі з тим, що означає 1.0 CPU в Kubernetes, прочитайте значення CPU.

Створення простору імен

Створіть простір імен, щоб ресурси, які ви створюєте у цьому завданні, були ізольовані від решти вашого кластера.

kubectl create namespace default-cpu-example

Створення LimitRange та Podʼа

Ось маніфест для прикладу LimitRange. У маніфесті вказано типовий запит CPU та типове обмеження CPU.

apiVersion: v1
kind: LimitRange
metadata:
  name: cpu-limit-range
spec:
  limits:
  - default:
      cpu: 1
    defaultRequest:
      cpu: 0.5
    type: Container

Створіть LimitRange у просторі імен default-cpu-example:

kubectl apply -f https://k8s.io/examples/admin/resource/cpu-defaults.yaml --namespace=default-cpu-example

Тепер, якщо ви створюєте Pod у просторі імен default-cpu-example, і будь-який контейнер у цьому Podʼі не вказує свої власні значення для запиту та обмеження CPU, то панель управління застосовує типові значення: запит CPU 0.5 та типове обмеження CPU 1.

Ось маніфест для Podʼа з одним контейнером. Контейнер не вказує запит CPU та обмеження.

apiVersion: v1
kind: Pod
metadata:
  name: default-cpu-demo
spec:
  containers:
  - name: default-cpu-demo-ctr
    image: nginx

Створіть Pod.

kubectl apply -f https://k8s.io/examples/admin/resource/cpu-defaults-pod.yaml --namespace=default-cpu-example

Перегляньте специфікацію Podʼа :

kubectl get pod default-cpu-demo --output=yaml --namespace=default-cpu-example

Вивід показує, що єдиний контейнер Podʼа має запит CPU 500m cpu (що ви можете читати як “500 millicpu”), і обмеження CPU 1 cpu. Це типові значення, вказані обмеженням.

containers:
- image: nginx
  imagePullPolicy: Always
  name: default-cpu-demo-ctr
  resources:
    limits:
      cpu: "1"
    requests:
      cpu: 500m

Що якщо ви вказуєте обмеження контейнера, але не його запит?

Ось маніфест для Podʼа з одним контейнером. Контейнер вказує обмеження CPU, але не запит:

apiVersion: v1
kind: Pod
metadata:
  name: default-cpu-demo-2
spec:
  containers:
  - name: default-cpu-demo-2-ctr
    image: nginx
    resources:
      limits:
        cpu: "1"

Створіть Pod:

kubectl apply -f https://k8s.io/examples/admin/resource/cpu-defaults-pod-2.yaml --namespace=default-cpu-example

Перегляньте специфікацію Podʼа, який ви створили:

kubectl get pod default-cpu-demo-2 --output=yaml --namespace=default-cpu-example

Вивід показує, що запит CPU контейнера встановлено таким чином, щоб відповідати його обмеженню CPU. Зверніть увагу, що контейнеру не було назначено типове значення запиту CPU 0.5 cpu:

resources:
  limits:
    cpu: "1"
  requests:
    cpu: "1"

Що якщо ви вказуєте запит контейнера, але не його обмеження?

Ось приклад маніфесту для Podʼа з одним контейнером. Контейнер вказує запит CPU, але не обмеження:

apiVersion: v1
kind: Pod
metadata:
  name: default-cpu-demo-3
spec:
  containers:
  - name: default-cpu-demo-3-ctr
    image: nginx
    resources:
      requests:
        cpu: "0.75"

Створіть Pod:

kubectl apply -f https://k8s.io/examples/admin/resource/cpu-defaults-pod-3.yaml --namespace=default-cpu-example

Перегляньте специфікацію Podʼа , який ви створили:

kubectl get pod default-cpu-demo-3 --output=yaml --namespace=default-cpu-example

Вивід показує, що запит CPU контейнера встановлено на значення, яке ви вказали при створенні Podʼа (іншими словами: воно відповідає маніфесту). Однак обмеження CPU цього ж контейнера встановлено на 1 cpu, що є типовим обмеженням CPU для цього простору імен.

resources:
  limits:
    cpu: "1"
  requests:
    cpu: 750m

Мотивація для типових обмежень та запитів CPU

Якщо ваш простір імен має налаштовану квоту ресурсів CPU, корисно мати типове значення для обмеження CPU. Ось два обмеження, які накладає квота ресурсів CPU на простір імен:

  • Для кожного Podʼа, який працює в просторі імен, кожен з його контейнерів повинен мати обмеження CPU.
  • Обмеження CPU застосовує резервування ресурсів на вузлі, де запускається відповідний Pod. Загальна кількість CPU, яка зарезервована для використання всіма Podʼами в просторі імен, не повинна перевищувати вказане обмеження.

Коли ви додаєте LimitRange:

Якщо будь-який Pod у цьому просторі імен, що містить контейнер, не вказує своє власне обмеження CPU, панель управління застосовує типове обмеження CPU цьому контейнеру, і Pod може отримати дозвіл на запуск у просторі імен, який обмежено квотою ресурсів CPU.

Прибирання

Видаліть ваш простір імен:

kubectl delete namespace default-cpu-example

Що далі

Для адміністраторів кластера

Для розробників додатків

4.2.4.3 - Налаштування мінімальних та максимальних обмежень памʼяті для простору імен

Визначте діапазон дійсних обмежень ресурсів памʼяті для простору імен, так щоб кожний новий Pod у цьому просторі імен знаходився в межах встановленого вами діапазону.

Ця сторінка показує, як встановити мінімальні та максимальні значення для памʼяті, яку використовують контейнери, що працюють у просторі імен. Мінімальні та максимальні значення памʼяті ви вказуєте у LimitRange обʼєкті. Якщо Pod не відповідає обмеженням, накладеним LimitRange, його неможливо створити в просторі імен.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

У вас повинен бути доступ до створення просторів імен у вашому кластері.

Кожен вузол у вашому кластері повинен мати щонайменше 1 GiB памʼяті для Podʼів.

Створення простору імен

Створіть простір імен, щоб ресурси, які ви створюєте в цьому завданні, були відокремлені від решти вашого кластера.

kubectl create namespace constraints-mem-example

Створення LimitRange та Podʼа

Ось приклад маніфесту для LimitRange:

apiVersion: v1
kind: LimitRange
metadata:
  name: mem-min-max-demo-lr
spec:
  limits:
  - max:
      memory: 1Gi
    min:
      memory: 500Mi
    type: Container

Створіть LimitRange:

kubectl apply -f https://k8s.io/examples/admin/resource/memory-constraints.yaml --namespace=constraints-mem-example

Перегляньте докладну інформацію про LimitRange:

kubectl get limitrange mem-min-max-demo-lr --namespace=constraints-mem-example --output=yaml

Вивід показує мінімальні та максимальні обмеження памʼяті як очікувалося. Але зверніть увагу, що, навіть якщо ви не вказали типові значення в конфігураційному файлі для LimitRange, вони були створені автоматично.

  limits:
  - default:
      memory: 1Gi
    defaultRequest:
      memory: 1Gi
    max:
      memory: 1Gi
    min:
      memory: 500Mi
    type: Container

Тепер кожного разу, коли ви визначаєте Pod у просторі імен constraints-mem-example, Kubernetes виконує такі кроки:

  • Якщо будь-який контейнер в цьому Podʼі не вказує свій власний запит памʼяті та обмеження, панель управління надає типовий запит та обмеження памʼяті цьому контейнеру.

  • Перевірте, що кожний контейнер у цьому Podʼі запитує принаймні 500 MiB памʼяті.

  • Перевірте, що кожний контейнер у цьому Podʼі запитує не більше 1024 MiB (1 GiB) памʼяті.

Ось маніфест для Podʼа з одним контейнером. У специфікації Podʼа, єдиний контейнер вказує запит памʼяті 600 MiB та обмеження памʼяті 800 MiB. Ці значення задовольняють мінімальні та максимальні обмеження памʼяті, накладені LimitRange.

apiVersion: v1
kind: Pod
metadata:
  name: constraints-mem-demo
spec:
  containers:
  - name: constraints-mem-demo-ctr
    image: nginx
    resources:
      limits:
        memory: "800Mi"
      requests:
        memory: "600Mi"

Створіть Pod:

kubectl apply -f https://k8s.io/examples/admin/resource/memory-constraints-pod.yaml --namespace=constraints-mem-example

Перевірте, що Pod працює і його контейнер є справним:

kubectl get pod constraints-mem-demo --namespace=constraints-mem-example

Перегляньте докладну інформацію про Pod:

kubectl get pod constraints-mem-demo --output=yaml --namespace=constraints-mem-example

Вивід показує, що контейнер у цьому Podʼі має запит памʼяті 600 MiB та обмеження памʼяті 800 MiB. Ці значення задовольняють обмеження, накладені LimitRange на цей простір імен:

resources:
  limits:
     memory: 800Mi
  requests:
    memory: 600Mi

Видаліть свій Pod:

kubectl delete pod constraints-mem-demo --namespace=constraints-mem-example

Спроба створення Podʼа, який перевищує максимальне обмеження памʼяті

Ось маніфест для Podʼа з одним контейнером. Контейнер вказує запит памʼяті 800 MiB та обмеження памʼяті 1.5 GiB.

apiVersion: v1
kind: Pod
metadata:
  name: constraints-mem-demo-2
spec:
  containers:
  - name: constraints-mem-demo-2-ctr
    image: nginx
    resources:
      limits:
        memory: "1.5Gi"
      requests:
        memory: "800Mi"

Спробуйте створити Pod:

kubectl apply -f https://k8s.io/examples/admin/resource/memory-constraints-pod-2.yaml --namespace=constraints-mem-example

Вивід показує, що Pod не було створено, оскільки він визначає контейнер, який запитує більше памʼяті, ніж дозволяється:

Error from server (Forbidden): error when creating "examples/admin/resource/memory-constraints-pod-2.yaml":
pods "constraints-mem-demo-2" is forbidden: maximum memory usage per Container is 1Gi, but limit is 1536Mi.

Спроба створення Podʼа, який не відповідає мінімальному запиту памʼяті

Ось маніфест для Podʼа з одним контейнером. Цей контейнер вказує запит памʼяті 100 MiB та обмеження памʼяті 800 MiB.

apiVersion: v1
kind: Pod
metadata:
  name: constraints-mem-demo-3
spec:
  containers:
  - name: constraints-mem-demo-3-ctr
    image: nginx
    resources:
      limits:
        memory: "800Mi"
      requests:
        memory: "100Mi"

Спробуйте створити Pod:

kubectl apply -f https://k8s.io/examples/admin/resource/memory-constraints-pod-3.yaml --namespace=constraints-mem-example

Вивід показує, що Pod не було створено, оскільки він визначає контейнер який запитує менше памʼяті, ніж вимагається:

Error from server (Forbidden): error when creating "examples/admin/resource/memory-constraints-pod-3.yaml":
pods "constraints-mem-demo-3" is forbidden: minimum memory usage per Container is 500Mi, but request is 100Mi.

Створення Podʼа, який не вказує жодного запиту памʼяті чи обмеження

Ось маніфест для Podʼа з одним контейнером. Контейнер не вказує запиту памʼяті, і він не вказує обмеження памʼяті.

apiVersion: v1
kind: Pod
metadata:
  name: constraints-mem-demo-4
spec:
  containers:
  - name: constraints-mem-demo-4-ctr
    image: nginx

Створіть Pod:

kubectl apply -f https://k8s.io/examples/admin/resource/memory-constraints-pod-4.yaml --namespace=constraints-mem-example

Перегляньте докладну інформацію про Pod:

kubectl get pod constraints-mem-demo-4 --namespace=constraints-mem-example --output=yaml

Вивід показує, що єдиний контейнер у цьому Podʼі має запит памʼяті 1 GiB та обмеження памʼяті 1 GiB. Як цей контейнер отримав ці значення?

resources:
  limits:
    memory: 1Gi
  requests:
    memory: 1Gi

Тому що ваш Pod не визначає жодного запиту памʼяті та обмеження для цього контейнера, кластер застосував типовий запит памʼяті та обмеження з LimitRange.

Це означає, що визначення цього Podʼа показує ці значення. Ви можете перевірити це за допомогою kubectl describe:

# Подивіться розділ "Requests:" виводу
kubectl describe pod constraints-mem-demo-4 --namespace=constraints-mem-example

На цей момент ваш Pod може працювати або не працювати. Памʼятайте, що передумовою для цього завдання є те, що ваші вузли мають щонайменше 1 GiB памʼяті. Якщо кожен з ваших вузлів має лише 1 GiB памʼяті, тоді недостатньо виділеної памʼяті на будь-якому вузлі для обслуговування запиту памʼяті 1 GiB. Якщо ви використовуєте вузли з 2 GiB памʼяті, то, ймовірно, у вас достатньо місця для розміщення запиту 1 GiB.

Видаліть свій Pod:

kubectl delete pod constraints-mem-demo-4 --namespace=constraints-mem-example

Застосування мінімальних та максимальних обмежень памʼяті

Максимальні та мінімальні обмеження памʼяті, накладені на простір імен LimitRange, діють тільки під час створення або оновлення Podʼа. Якщо ви змінюєте LimitRange, це не впливає на Podʼи, що були створені раніше.

Причини для мінімальних та максимальних обмежень памʼяті

Як адміністратор кластера, вам може знадобитися накладати обмеження на кількість памʼяті, яку можуть використовувати Podʼи. Наприклад:

  • Кожен вузол у кластері має 2 GiB памʼяті. Ви не хочете приймати будь-який Pod, який запитує більше ніж 2 GiB памʼяті, оскільки жоден вузол у кластері не може підтримати запит.

  • Кластер використовується як виробництвом, так і розробкою вашими відділами. Ви хочете дозволити навантаженням в експлуатації використовувати до 8 GiB памʼяті, але ви хочете обмежити навантаження в розробці до 512 MiB. Ви створюєте окремі простори імен для експлуатації та розробки і застосовуєте обмеження памʼяті для кожного простору імен.

Прибирання

Видаліть свій простір імен:

kubectl delete namespace constraints-mem-example

Що далі

Для адміністраторів кластера

Для розробників додатків

4.2.4.4 - Налаштування мінімальних та максимальних обмеженнь CPU для простору імен

Визначте діапазон допустимих обмежень ресурсів CPU для простору імен так, щоб кожен новий Pod у цьому просторі імен відповідав налаштованому діапазону.

Ця сторінка показує, як встановити мінімальні та максимальні значення ресурсів CPU, що використовуються контейнерами та Podʼами в просторі імен. Ви вказуєте мінімальні та максимальні значення CPU в обʼєкті LimitRange. Якщо Pod не відповідає обмеженням, накладеним LimitRange, його не можна створити у просторі імен.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Ви повинні мати доступ до створення просторів імен у своєму кластері.

Кожен вузол у вашому кластері повинен мати щонайменше 1,0 CPU, доступний для Podʼів. Див. значення CPU, щоб дізнатися, що означає в Kubernetes "1 CPU".

Створення простору імен

Створіть простір імен, щоб ресурси, які ви створюєте у цьому завданні, були відокремлені від інших частин вашого кластера.

kubectl create namespace constraints-cpu-example

Створення LimitRange та Podʼа

Ось маніфест для прикладу LimitRange:

apiVersion: v1
kind: LimitRange
metadata:
  name: cpu-min-max-demo-lr
spec:
  limits:
  - max:
      cpu: "800m"
    min:
      cpu: "200m"
    type: Container

Створіть LimitRange:

kubectl apply -f https://k8s.io/examples/admin/resource/cpu-constraints.yaml --namespace=constraints-cpu-example

Перегляньте детальну інформацію про LimitRange:

kubectl get limitrange cpu-min-max-demo-lr --output=yaml --namespace=constraints-cpu-example

Вивід показує мінімальні та максимальні обмеження CPU, як очікувалося. Але зверніть увагу, що навіть якщо ви не вказали типових значень у конфігураційному файлі для LimitRange, вони були створені автоматично.

limits:
- default:
    cpu: 800m
  defaultRequest:
    cpu: 800m
  max:
    cpu: 800m
  min:
    cpu: 200m
  type: Container

Тепер, кожного разу, коли ви створюєте Pod у просторі імен constraints-cpu-example (або який-небудь інший клієнт API Kubernetes створює еквівалентний Pod), Kubernetes виконує ці кроки:

  • Якщо який-небудь контейнер у цьому Podʼі не вказує свої власні CPU-запити та обмеження, панель управління призначає контейнеру типове значення для CPU-запиту та обмеження.

  • Перевірте, що кожен контейнер у цьому Podʼі вказує CPU-запит, який більший або дорівнює 200 мілі-CPU.

  • Перевірте, що кожен контейнер у цьому Podʼі вказує обмеження CPU, яке менше або дорівнює 800 мілі-CPU.

Ось маніфест для Podʼа з одним контейнером. Маніфест контейнера вказує CPU-запит у розмірі 500 мілі-CPU та обмеження CPU у розмірі 800 мілі-CPU. Це задовольняє мінімальні та максимальні обмеження CPU, накладені LimitRange на цей простір імен.

apiVersion: v1
kind: Pod
metadata:
  name: constraints-cpu-demo
spec:
  containers:
  - name: constraints-cpu-demo-ctr
    image: nginx
    resources:
      limits:
        cpu: "800m"
      requests:
        cpu: "500m"

Створіть Pod:

kubectl apply -f https://k8s.io/examples/admin/resource/cpu-constraints-pod.yaml --namespace=constraints-cpu-example

Перевірте, що Pod працює, а його контейнер є справним:

kubectl get pod constraints-cpu-demo --namespace=constraints-cpu-example

Перегляньте детальну інформацію про Pod:

kubectl get pod constraints-cpu-demo --output=yaml --namespace=constraints-cpu-example

Вивід показує, що єдиний контейнер Podʼа має запит CPU у розмірі 500 мілі-CPU та обмеження CPU 800 мілі-CPU. Це задовольняє обмеження, накладеним LimitRange.

resources:
  limits:
    cpu: 800m
  requests:
    cpu: 500m

Видаліть Pod

kubectl delete pod constraints-cpu-demo --namespace=constraints-cpu-example

Спроба створити Pod, який перевищує максимальне обмеження CPU

Ось маніфест для Podʼа з одним контейнером. Контейнер вказує запит CPU у розмірі 500 мілі-CPU та обмеження CPU у розмірі 1,5 CPU.

apiVersion: v1
kind: Pod
metadata:
  name: constraints-cpu-demo-2
spec:
  containers:
  - name: constraints-cpu-demo-2-ctr
    image: nginx
    resources:
      limits:
        cpu: "1.5"
      requests:
        cpu: "500m"

Спробуйте створити Pod:

kubectl apply -f https://k8s.io/examples/admin/resource/cpu-constraints-pod-2.yaml --namespace=constraints-cpu-example

Вивід показує, що Pod не створено, оскільки визначений контейнер є неприйнятним. Цей контейнер є неприйнятним, оскільки він вказує обмеження CPU, яке занадто велике:

Error from server (Forbidden): error when creating "examples/admin/resource/cpu-constraints-pod-2.yaml":
pods "constraints-cpu-demo-2" is forbidden: maximum cpu usage per Container is 800m, but limit is 1500m.

Спроба створити Pod, який не відповідає мінімальному запиту CPU

Ось маніфест для Podʼа з одним контейнером. Контейнер вказує запит CPU у розмірі 100 мілі-CPU та обмеження CPU у розмірі 800 мілі-CPU.

apiVersion: v1
kind: Pod
metadata:
  name: constraints-cpu-demo-3
spec:
  containers:
  - name: constraints-cpu-demo-3-ctr
    image: nginx
    resources:
      limits:
        cpu: "800m"
      requests:
        cpu: "100m"

Спробуйте створити Pod:

kubectl apply -f https://k8s.io/examples/admin/resource/cpu-constraints-pod-3.yaml --namespace=constraints-cpu-example

Вивід показує, що Pod не створено, оскільки визначений контейнер є неприйнятним. Цей контейнер є неприйнятним, оскільки він вказує запит CPU, який нижче мінімального:

Error from server (Forbidden): error when creating "examples/admin/resource/cpu-constraints-pod-3.yaml":
pods "constraints-cpu-demo-3" is forbidden: minimum cpu usage per Container is 200m, but request is 100m.

Створення Podʼа, який не вказує жодного запиту або обмеження CPU

Ось маніфест для Podʼа з одним контейнером. Контейнер не вказує запит CPU і не вказує обмеження CPU.

apiVersion: v1
kind: Pod
metadata:
  name: constraints-cpu-demo-4
spec:
  containers:
  - name: constraints-cpu-demo-4-ctr
    image: vish/stress

Створіть Pod:

kubectl apply -f https://k8s.io/examples/admin/resource/cpu-constraints-pod-4.yaml --namespace=constraints-cpu-example

Перегляньте детальну інформацію про Pod:

kubectl get pod constraints-cpu-demo-4 --namespace=constraints-cpu-example --output=yaml

Вивід показує, що у Podʼі єдиний контейнер має запит CPU у розмірі 800 мілі-CPU та обмеження CPU у розмірі 800 мілі-CPU. Як цей контейнер отримав ці значення?

resources:
  limits:
    cpu: 800m
  requests:
    cpu: 800m

Тому що цей контейнер не вказав свій власний запит CPU та обмеження, панель управління застосовує стандартні обмеження та запит CPU з LimitRange для цього простору імен.

На цьому етапі ваш Pod може бути запущеним або не запущеним. Згадайте, що передумовою для цієї задачі є те, що у ваших вузлах повинно бути щонайменше 1 CPU для використання. Якщо в кожному вузлі у вас є лише 1 CPU, то, можливо, немає достатньої кількості CPU на будь-якому вузлі для виконання запиту у розмірі 800 мілі-CPU. Якщо ви використовуєте вузли з 2 CPU, то, ймовірно, у вас достатньо CPU для виконання запиту у розмірі 800 мілі-CPU.

Видаліть ваш Pod:

kubectl delete pod constraints-cpu-demo-4 --namespace=constraints-cpu-example

Застосування мінімальних та максимальних обмежень CPU

Максимальні та мінімальні обмеження CPU, накладені на простір імен за допомогою LimitRange, застосовуються лише при створенні або оновленні Podʼа. Якщо ви зміните LimitRange, це не вплине на Podʼи, які були створені раніше.

Причини для мінімальних та максимальних обмежень CPU

Як адміністратор кластера, ви можете бажати накладати обмеження на ресурси CPU, які можуть використовувати Podʼи. Наприклад:

  • Кожен вузол у кластері має 2 CPU. Ви не хочете приймати жодного Podʼа, який запитує більше, ніж 2 CPU, оскільки жоден вузол у кластері не може підтримати цей запит.

  • Кластер використовується вашими відділами експлуатації та розробки. Ви хочете дозволити навантаженням в експлуатації споживати до 3 CPU, але ви хочете обмежити навантаження в розробці до 1 CPU. Ви створюєте окремі простори імен для експлуатації та розробки та застосовуєте обмеження CPU до кожного простору імен.

Прибирання

Видаліть ваш простір імен:

kubectl delete namespace constraints-cpu-example

Що далі

Для адміністраторів кластера

Для розробників застосунків

4.2.4.5 - Налаштування квот памʼяті та CPU для простору імен

Визначте загальні обмеження памʼяті та CPU для всіх Podʼів, які працюють у просторі імен.

На цій сторінці показано, як встановити квоти для загальної кількості памʼяті та CPU, які можуть бути використані всіма Podʼами, що працюють у просторі імен. Ви вказуєте квоти в обʼєкті ResourceQuota.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Вам потрібен доступ до створення просторів імен у вашому кластері.

Кожен вузол у вашому кластері повинен мати принаймні 1 ГБ памʼяті.

Створення простору імен

Створіть простір імен, щоб ресурси, які ви створюєте у цьому завданні, були ізольовані від інших частин вашого кластера.

kubectl create namespace quota-mem-cpu-example

Створення ResourceQuota

Ось маніфест для прикладу ResourceQuota:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: mem-cpu-demo
spec:
  hard:
    requests.cpu: "1"
    requests.memory: 1Gi
    limits.cpu: "2"
    limits.memory: 2Gi

Створіть ResourceQuota:

kubectl apply -f https://k8s.io/examples/admin/resource/quota-mem-cpu.yaml --namespace=quota-mem-cpu-example

Перегляньте детальну інформацію про ResourceQuota:

kubectl get resourcequota mem-cpu-demo --namespace=quota-mem-cpu-example --output=yaml

ResourceQuota накладає такі вимоги на простір імен quota-mem-cpu-example:

  • Для кожного Podʼа у просторі імен кожен контейнер повинен мати запит памʼяті, обмеження памʼяті, запит CPU та обмеження CPU.
  • Загальний запит памʼяті для всіх Podʼів у цьому просторі імен не повинен перевищувати 1 ГБ.
  • Загальне обмеження памʼяті для всіх Podʼів у цьому просторі імен не повинно перевищувати 2 ГБ.
  • Загальний запит CPU для всіх Podʼів у цьому просторі імен не повинен перевищувати 1 CPU.
  • Загальне обмеження CPU для всіх Podʼів у цьому просторі імен не повинно перевищувати 2 CPU.

Дивіться значення CPU, щоб дізнатися, що має на увазі Kubernetes, коли говорить про "1 CPU".

Створення Podʼа

Ось маніфест для прикладу Podʼа:

apiVersion: v1
kind: Pod
metadata:
  name: quota-mem-cpu-demo
spec:
  containers:
  - name: quota-mem-cpu-demo-ctr
    image: nginx
    resources:
      limits:
        memory: "800Mi"
        cpu: "800m"
      requests:
        memory: "600Mi"
        cpu: "400m"

Створіть Pod:

kubectl apply -f https://k8s.io/examples/admin/resource/quota-mem-cpu-pod.yaml --namespace=quota-mem-cpu-example

Перевірте, що Pod працює, і його (єдиний) контейнер є справним:

kubectl get pod quota-mem-cpu-demo --namespace=quota-mem-cpu-example

Знову перегляньте детальну інформацію про ResourceQuota:

kubectl get resourcequota mem-cpu-demo --namespace=quota-mem-cpu-example --output=yaml

У виводі вказано квоту разом з тим, скільки з квоти було використано. Ви можете побачити, що запити памʼяті та CPU для вашого Podʼа не перевищують квоту.

status:
  hard:
    limits.cpu: "2"
    limits.memory: 2Gi
    requests.cpu: "1"
    requests.memory: 1Gi
  used:
    limits.cpu: 800m
    limits.memory: 800Mi
    requests.cpu: 400m
    requests.memory: 600Mi

Якщо у вас є інструмент jq, ви також можете запитувати (використовуючи JSONPath) лише значення used, і друкувати ці значення з приємним форматуванням. Наприклад:

kubectl get resourcequota mem-cpu-demo --namespace=quota-mem-cpu-example -o jsonpath='{ .status.used }' | jq .

Спроба створити другий Pod

Ось маніфест для другого Podʼа:

apiVersion: v1
kind: Pod
metadata:
  name: quota-mem-cpu-demo-2
spec:
  containers:
  - name: quota-mem-cpu-demo-2-ctr
    image: redis
    resources:
      limits:
        memory: "1Gi"
        cpu: "800m"
      requests:
        memory: "700Mi"
        cpu: "400m"

У маніфесті можна побачити, що Pod має запит памʼяті 700 MiB. Зверніть увагу, що сума використаного запиту памʼяті та цього нового запиту памʼяті перевищує квоту запиту памʼяті: 600 MiB + 700 MiB > 1 GiB.

Спробуйте створити Pod:

kubectl apply -f https://k8s.io/examples/admin/resource/quota-mem-cpu-pod-2.yaml --namespace=quota-mem-cpu-example

Другий Pod не створюється. У виводі вказано, що створення другого Podʼа призведе до того, що загальний запит памʼяті перевищить квоту запиту памʼяті.

Error from server (Forbidden): error when creating "examples/admin/resource/quota-mem-cpu-pod-2.yaml":
pods "quota-mem-cpu-demo-2" is forbidden: exceeded quota: mem-cpu-demo,
requested: requests.memory=700Mi,used: requests.memory=600Mi, limited: requests.memory=1Gi

Обговорення

Як ви бачили у цьому завданні, ви можете використовувати ResourceQuota для обмеження загального запиту памʼяті для всіх Podʼів, що працюють у просторі імен. Ви також можете обмежити загальні суми для обмеження памʼяті, запиту CPU та обмеження CPU.

Замість керування загальним використанням ресурсів у просторі імен, ви, можливо, захочете обмежити окремі Podʼи або контейнери у цих Podʼах. Щоб досягти такого обмеження, використовуйте LimitRange.

Прибирання

Видаліть ваш простір імен:

kubectl delete namespace quota-mem-cpu-example

Що далі

Для адміністраторів кластера

Для розробників застосунків

4.2.4.6 - Налаштування квоти Podʼів для простору імен

Обмежте кількість Podʼів, які можна створити у просторі імен.

На цій сторінці показано, як встановити квоту на загальну кількість Podʼів, які можуть працювати в просторі імен. Ви вказуєте квоти в обʼєкті ResourceQuota.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Вам потрібен доступ до створення просторів імен у вашому кластері.

Створення простору імен

Створіть простір імен, щоб ресурси, які ви створюєте у цьому завданні, були ізольовані від інших частин вашого кластера.

kubectl create namespace quota-pod-example

Створення ResourceQuota

Ось приклад маніфесту для ResourceQuota:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: pod-demo
spec:
  hard:
    pods: "2"

Створіть ResourceQuota:

kubectl apply -f https://k8s.io/examples/admin/resource/quota-pod.yaml --namespace=quota-pod-example

Перегляньте детальну інформацію про ResourceQuota:

kubectl get resourcequota pod-demo --namespace=quota-pod-example --output=yaml

У виводі показано, що у просторі імен є квота на два Podʼи, і наразі немає Podʼів; іншими словами, жодна частина квоти не використовується.

spec:
  hard:
    pods: "2"
status:
  hard:
    pods: "2"
  used:
    pods: "0"

Ось приклад маніфесту для Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: pod-quota-demo
spec:
  selector:
    matchLabels:
      purpose: quota-demo
  replicas: 3
  template:
    metadata:
      labels:
        purpose: quota-demo
    spec:
      containers:
      - name: pod-quota-demo
        image: nginx

У цьому маніфесті replicas: 3 повідомляє Kubernetes спробувати створити три нові Podʼи, які всі працюватимуть з одним і тим же застосунком.

Створіть Deployment:

kubectl apply -f https://k8s.io/examples/admin/resource/quota-pod-deployment.yaml --namespace=quota-pod-example

Перегляньте детальну інформацію про Deployment:

kubectl get deployment pod-quota-demo --namespace=quota-pod-example --output=yaml

У виводі показано, що навіть якщо Deployment вказує три репліки, було створено лише два Podʼи через раніше визначену вами квоту:

spec:
  ...
  replicas: 3
...
status:
  availableReplicas: 2
...
lastUpdateTime: 2021-04-02T20:57:05Z
    message: 'unable to create pods: pods "pod-quota-demo-1650323038-" is forbidden:
      exceeded quota: pod-demo, requested: pods=1, used: pods=2, limited: pods=2'

Вибір ресурсу

У цьому завданні ви визначили ResourceQuota, яке обмежує загальну кількість Podʼів, але ви також можете обмежити загальну кількість інших видів обʼєктів. Наприклад, ви можете вирішити обмежити кількість CronJobs, які можуть існувати в одному просторі імен.

Прибирання

Видаліть ваш простір імен:

kubectl delete namespace quota-pod-example

Для адміністраторів кластера

Для розробників застосунків

4.2.5 - Встановлення постачальника мережевої політики

4.2.5.1 - Використання Antrea для NetworkPolicy

Ця сторінка показує, як встановити та використовувати втулок Antrea CNI в Kubernetes. Щоб дізнатися більше про проєкт Antrea, прочитайте Вступ до Antrea.

Перш ніж ви розпочнете

Вам потрібно мати кластер Kubernetes. Слідуйте початковому керівництву kubeadm для його створення.

Розгортання Antrea за допомогою kubeadm

Слідуйте керівництву Початок роботи для розгортання Antrea за допомогою kubeadm.

Що далі

Після того, як ваш кластер буде запущений, ви можете перейти до Оголошення мережевої політики, щоб спробувати в дії Kubernetes NetworkPolicy.

4.2.5.2 - Використання Calico для NetworkPolicy

Ця сторінка показує кілька швидких способів створення кластера Calico в Kubernetes.

Перш ніж ви розпочнете

Вирішіть, чи ви хочете розгорнути хмарний або локальний кластер.

Створення кластера Calico з Google Kubernetes Engine (GKE)

Передумова: gcloud.

  1. Щоб запустити кластер GKE з Calico, включіть прапорець --enable-network-policy.

    Синтаксис

    gcloud container clusters create [ІМ'Я_КЛАСТЕРА] --enable-network-policy
    

    Приклад

    gcloud container clusters create my-calico-cluster --enable-network-policy
    
  2. Для перевірки розгортання використовуйте наступну команду.

    kubectl get pods --namespace=kube-system
    

    Podʼи Calico починаються з calico. Перевірте, щоб кожен з них мав статус Running.

Створення локального кластера Calico з kubeadm

Щоб отримати локальний кластер Calico для одного хосту за пʼятнадцять хвилин за допомогою kubeadm, див. Швидкий старт Calico.

Що далі

Після того, як ваш кластер буде запущений, ви можете перейти до Оголошення мережевої політики, щоб спробувати в дії Kubernetes NetworkPolicy.

4.2.5.3 - Використання Cilium для NetworkPolicy

Ця сторінка показує, як використовувати Cilium для NetworkPolicy.

Щоб ознайомитися з основною інформацією про Cilium, прочитайте Вступ до Cilium.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Для перевірки версії введіть kubectl version.

Розгортання Cilium на Minikube для базового тестування

Щоб легко ознайомитися з Cilium, ви можете слідувати Початковому керівництву Cilium Kubernetes для виконання базової інсталяції Cilium як DaemonSet у Minikube.

Щоб запустити Minikube, мінімально необхідна версія >= v1.5.2, виконайте з наступними аргументами:

minikube version
minikube version: v1.5.2
minikube start --network-plugin=cni

Для Minikube ви можете встановити Cilium за допомогою його CLI інструменту. Спочатку завантажте останню версію CLI за допомогою наступної команди:

curl -LO https://github.com/cilium/cilium-cli/releases/latest/download/cilium-linux-amd64.tar.gz

Потім розпакуйте завантажений файл у вашу теку /usr/local/bin за допомогою наступної команди:

sudo tar xzvfC cilium-linux-amd64.tar.gz /usr/local/bin
rm cilium-linux-amd64.tar.gz

Після виконання вищевказаних команд, ви тепер можете встановити Cilium за допомогою наступної команди:

cilium install

Cilium автоматично визначить конфігурацію кластера та створить і встановить відповідні компоненти для успішної інсталяції. Компоненти включають:

  • Центр сертифікації (CA) у Secret cilium-ca та сертифікати для Hubble (шар спостереження Cilium).
  • Сервісні облікові записи.
  • Кластерні ролі.
  • ConfigMap.
  • Agent DaemonSet та Operator Deployment.

Після інсталяції ви можете переглянути загальний статус розгортання Cilium за допомогою команди cilium status. Дивіться очікуваний вивід команди status тут.

Решта Початкового керівництва пояснює, як застосувати політики безпеки як L3/L4 (тобто IP-адреса + порт), так і L7 (наприклад, HTTP) за допомогою прикладної програми.

Розгортання Cilium для використання в операційному середовищі

Для докладних інструкцій з розгортання Cilium для операційного використання, дивіться: Керівництво з інсталяції Cilium Kubernetes. Ця документація включає докладні вимоги, інструкції та приклади файлів DaemonSet для продуктивного використання.

Розуміння компонентів Cilium

Розгортання кластера з Cilium додає Podʼи до простору імен kube-system. Щоб побачити цей список Podʼів, виконайте:

kubectl get pods --namespace=kube-system -l k8s-app=cilium

Ви побачите список Podʼів, подібний до цього:

NAME           READY   STATUS    RESTARTS   AGE
cilium-kkdhz   1/1     Running   0          3m23s
...

Pod cilium працює на кожному вузлі вашого кластера і забезпечує виконання мережевої політики для трафіку до/від Podʼів на цьому вузлі за допомогою Linux BPF.

Що далі

Після того, як ваш кластер буде запущений, ви можете перейти до Оголошення мережевої політики для випробування Kubernetes NetworkPolicy з Cilium. Якщо у вас є запитання, звʼяжіться з нами за допомогою Каналу Cilium у Slack.

4.2.5.4 - Використання Kube-router для NetworkPolicy

Ця сторінка показує, як використовувати Kube-router для NetworkPolicy.

Перш ніж ви розпочнете

Вам потрібно мати запущений кластер Kubernetes. Якщо у вас ще немає кластера, ви можете створити його, використовуючи будь-які інсталятори кластерів, такі як Kops, Bootkube, Kubeadm тощо.

Встановлення надбудови Kube-router

Надбудова Kube-router містить контролер мережевих політик, який відстежує сервер API Kubernetes на предмет будь-яких оновлень NetworkPolicy та Podʼів і налаштовує правила iptables та ipsets для дозволу або блокування трафіку відповідно до політик. Будь ласка, слідуйте керівництву спробуйте Kube-router з інсталяторами кластерів для встановлення надбудови Kube-router.

Що далі

Після того, як ви встановили надбудову Kube-router, ви можете перейти до Оголошення мережевої політики для випробування Kubernetes NetworkPolicy.

4.2.5.5 - Використання Romana для NetworkPolicy

Ця сторінка показує, як використовувати Romana для NetworkPolicy.

Перш ніж ви розпочнете

Виконайте кроки 1, 2 та 3 з початкового керівництва kubeadm.

Встановлення Romana за допомогою kubeadm

Слідуйте керівництву з контейнеризованого встановлення для kubeadm.

Застосування мережевих політик

Для застосування мережевих політик використовуйте одне з наступного:

Що далі

Після встановлення Romana ви можете перейти до Оголошення мережевої політики для випробування Kubernetes NetworkPolicy.

4.2.5.6 - Використання Weave Net для NetworkPolicy

Ця сторінка показує, як використовувати Weave Net для NetworkPolicy.

Перш ніж ви розпочнете

Вам потрібен Kubernetes кластер. Слідуйте початковому керівництву kubeadm, щоб його налаштувати.

Встановлення надбудови Weave Net

Слідуйте керівництву Інтеграція Kubernetes через надбудову.

Надбудова Weave Net для Kubernetes містить Контролер мережевих політик, який автоматично відстежує всі анотації мережевих політик у Kubernetes у всіх просторах імен і налаштовує правила iptables для дозволу або блокування трафіку відповідно до цих політик.

Тестування встановлення

Перевірте, що Weave працює коректно.

Введіть наступну команду:

kubectl get pods -n kube-system -o wide

Вивід буде схожим на це:

NAME                                    READY     STATUS    RESTARTS   AGE       IP              NODE
weave-net-1t1qg                         2/2       Running   0          9d        192.168.2.10    worknode3
weave-net-231d7                         2/2       Running   1          7d        10.2.0.17       worknodegpu
weave-net-7nmwt                         2/2       Running   3          9d        192.168.2.131   masternode
weave-net-pmw8w                         2/2       Running   0          9d        192.168.2.216   worknode2

На кожному вузлі є Pod Weave, і всі Podʼи Running та 2/2 READY. (2/2 означає, що кожен Pod має weave і weave-npc.)

Що далі

Після встановлення надбудови Weave Net ви можете перейти до Оголошення мережевої політики, щоб спробувати Kubernetes NetworkPolicy. Якщо у вас є запитання, звертайтеся до нас #weave-community у Slack або Weave User Group.

4.2.6 - Доступ до кластера через API Kubernetes

Ця сторінка описує, як отримати доступ до кластера через API Kubernetes.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Для перевірки версії введіть kubectl version.

Доступ до API Kubernetes

Перший доступ за допомогою kubectl

При першому доступі до API Kubernetes використовуйте інструмент командного рядка Kubernetes, kubectl.

Для отримання доступу до кластера вам потрібно знати його розташування та мати облікові дані для входу. Зазвичай вони встановлюються автоматично, коли ви користуєтесь настановами зі сторінки Початок роботи, або ж ви вже маєте розгорнутий кластер з налаштованим доступом.

Перевірте місце знаходження та облікові дані, про які знає kubectl, за допомогою цієї команди:

kubectl config view

Багато прикладів містять введення в користування kubectl. Повну документацію ви можете знайти в довідці kubectl.

Прямий доступ до REST API

kubectl використовується для знаходження та автентифікації на сервері API. Якщо ви хочете дістатись REST API за допомогою інструментів на кшталт curl або wget, чи вебоглядача, існує кілька способів якими ви можете знайти та автентифікуватись на сервері API.

  1. Запустіть kubectl у режимі проксі (рекомендовано). Цей метод рекомендується, оскільки він використовує збережене розташування сервера API та перевіряє відповідність сервера API за допомогою самопідписного сертифіката. За допомогою цього методу неможлива атака man-in-the-middle (MITM).
  2. Крім того, ви можете вказати знаходження та облікові дані безпосередньо http-клієнту. Це працює з клієнтським кодом, який плутають проксі. Щоб захиститися від атак man in the middle, вам потрібно буде імпортувати кореневий сертифікат у свій вебоглядач.

Використання клієнтських бібліотек Go або Python забезпечує доступ до kubectl у режимі проксі.

Використання kubectl proxy

Наступна команда запускає kubectl у режимі, де він діє як зворотний проксі. Він виконує пошук сервера API та автентифікацію.

kubectl proxy --port=8080 &

Дивіться kubectl proxy для отримання додаткової інформації.

Потім ви можете дослідити API за допомогою curl, wget або вебоглядача, наприклад:

curl http://localhost:8080/api/

Вивід має бути схожий на цей:

{
  "versions": [
    "v1"
  ],
  "serverAddressByClientCIDRs": [
    {
      "clientCIDR": "0.0.0.0/0",
      "serverAddress": "10.0.1.149:443"
    }
  ]
}

Без використання kubectl proxy

Можна уникнути використання kubectl proxy, передаючи токен автентифікації безпосередньо на сервер API, наприклад:

Використовуючи підхід grep/cut:

# Перевірте всі можливі кластери, оскільки ваш .KUBECONFIG може мати кілька контекстів:
kubectl config view -o jsonpath='{"Cluster name\tServer\n"}{range .clusters[*]}{.name}{"\t"}{.cluster.server}{"\n"}{end}'

# Виберіть назву кластера, з яким ви хочете взаємодіяти, з виводу вище:
export CLUSTER_NAME="some_server_name"

# Вкажіть сервер API, посилаючись на імʼя кластера
APISERVER=$(kubectl config view -o jsonpath="{.clusters[?(@.name==\"$CLUSTER_NAME\")].cluster.server}")

# Створіть секрет для зберігання токена для облікового запису служби
kubectl apply -f - <<EOF
apiVersion: v1
kind: Secret
metadata:
  name: default-token
  annotations:
    kubernetes.io/service-account.name: default
type: kubernetes.io/service-account-token
EOF

# Зачекайте, поки контролер заповнить секрет токеном:
while ! kubectl describe secret default-token | grep -E '^token' >/dev/null; do
  echo "waiting for token..." >&2
  sleep 1
done

# Отримайте значення токена
TOKEN=$(kubectl get secret default-token -o jsonpath='{.data.token}' | base64 --decode)

# Дослідіть API скориставшись TOKEN
curl -X GET $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure

Вивід має бути схожий на цей:

{
  "kind": "APIVersions",
  "versions": [
    "v1"
  ],
  "serverAddressByClientCIDRs": [
    {
      "clientCIDR": "0.0.0.0/0",
      "serverAddress": "10.0.1.149:443"
    }
  ]
}

У вищенаведеному прикладі використовується прапорець --insecure. Це залишає систему вразливою до атак типу MITM (Man-In-The-Middle). Коли kubectl отримує доступ до кластера, він використовує збережений кореневий сертифікат та сертифікати клієнта для доступу до сервера. (Ці дані встановлені у каталозі ~/.kube). Оскільки сертифікати кластера зазвичай самопідписні, може знадобитися спеціальна конфігурація, щоб ваш HTTP-клієнт використовував кореневий сертифікат.

На деяких кластерах сервер API може не вимагати автентифікації; він може обслуговувати локальний хост або бути захищений фаєрволом. Не існує стандарту для цього. Документ Керування доступом до API Kubernetes описує, як ви можете налаштувати це, як адміністратор кластера.

Програмний доступ до API

Kubernetes офіційно підтримує клієнтські бібліотеки для Go, Python, Java, dotnet, JavaScript та Haskell. Існують інші клієнтські бібліотеки, які надаються та підтримуються їхніми авторами, а не командою Kubernetes. Дивіться бібліотеки клієнтів для доступу до API з інших мов програмування та їхнього методу автентифікації.

Go-клієнт

  • Щоб отримати бібліотеку, виконайте наступну команду: go get k8s.io/client-go@kubernetes-<номер-версії-kubernetes>. Дивіться https://github.com/kubernetes/client-go/releases, щоб переглянути підтримувані версії.
  • Напишіть застосунок поверх клієнтів client-go.

Go-клієнт може використовувати той самий файл kubeconfig, як і kubectl CLI, для пошуку та автентифікації на сервері API. Дивіться цей приклад:

package main

import (
  "context"
  "fmt"
  "k8s.io/apimachinery/pkg/apis/meta/v1"
  "k8s.io/client-go/kubernetes"
  "k8s.io/client-go/tools/clientcmd"
)

func main() {
  // використовуємо поточний контекст з kubeconfig
  // path-to-kubeconfig -- наприклад, /root/.kube/config
  config, _ := clientcmd.BuildConfigFromFlags("", "<path-to-kubeconfig>")
  // створює clientset
  clientset, _ := kubernetes.NewForConfig(config)
  // доступ API до списку Podʼів
  pods, _ := clientset.CoreV1().Pods("").List(context.TODO(), v1.ListOptions{})
  fmt.Printf("There are %d pods in the cluster\n", len(pods.Items))
}

Якщо застосунок розгорнуто як Pod у кластері, дивіться Доступ до API зсередини Pod.

Python-клієнт

Щоб використовувати Python-клієнт, виконайте наступну команду: pip install kubernetes. Дивіться сторінку бібліотеки Python-клієнта для отримання додаткових варіантів встановлення.

Python-клієнт може використовувати той самий файл kubeconfig, як і kubectl CLI, для пошуку та автентифікації на сервері API. Дивіться цей приклад:

from kubernetes import client, config

config.load_kube_config()

v1=client.CoreV1Api()
print("Listing pods with their IPs:")
ret = v1.list_pod_for_all_namespaces(watch=False)
for i in ret.items:
    print("%s\t%s\t%s" % (i.status.pod_ip, i.metadata.namespace, i.metadata.name))

Java-клієнт

Для встановлення Java-клієнта виконайте наступну команду:

# Зколнуйте код білліотеки java
git clone --recursive https://github.com/kubernetes-client/java

# Встановлення артефактів проєкту, POM й так даіл:
cd java
mvn install

Дивіться https://github.com/kubernetes-client/java/releases, щоб переглянути підтримувані версії.

Java-клієнт може використовувати той самий файл kubeconfig, що і kubectl CLI, для пошуку та автентифікації на сервері API. Дивіться цей приклад:

package io.kubernetes.client.examples;

import io.kubernetes.client.ApiClient;
import io.kubernetes.client.ApiException;
import io.kubernetes.client.Configuration;
import io.kubernetes.client.apis.CoreV1Api;
import io.kubernetes.client.models.V1Pod;
import io.kubernetes.client.models.V1PodList;
import io.kubernetes.client.util.ClientBuilder;
import io.kubernetes.client.util.KubeConfig;
import java.io.FileReader;
import java.io.IOException;

/**
 * Простий приклад використання Java API з застосунку поза кластером Kubernetes.
 *
 * Найпростіший спосіб запуску цього: mvn exec:java
 * -Dexec.mainClass="io.kubernetes.client.examples.KubeConfigFileClientExample"
 *
 */
public class KubeConfigFileClientExample {
  public static void main(String[] args) throws IOException, ApiException {

    // шлях до файлуу KubeConfig
    String kubeConfigPath = "~/.kube/config";

    // завантаження конфігурації ззовні кластера, kubeconfig із файлової системи
    ApiClient client =
        ClientBuilder.kubeconfig(KubeConfig.loadKubeConfig(new FileReader(kubeConfigPath))).build();

    // встановлення глобального api-client на того, що працює в межах кластера, як описано вище
    Configuration.setDefaultApiClient(client);

    // the CoreV1Api завантажує api-client з глобальної конфігурації.
    CoreV1Api api = new CoreV1Api();

    // виклик клієнта CoreV1Api
    V1PodList list = api.listPodForAllNamespaces(null, null, null, null, null, null, null, null, null);
    System.out.println("Listing all pods: ");
    for (V1Pod item : list.getItems()) {
      System.out.println(item.getMetadata().getName());
    }
  }
}

dotnet-клієнт

Щоб використовувати dotnet-клієнт, виконайте наступну команду: dotnet add package KubernetesClient --version 1.6.1. Дивіться сторінку бібліотеки dotnet-клієнта для отримання додаткових варіантів встановлення. Дивіться https://github.com/kubernetes-client/csharp/releases, щоб переглянути підтримувані версії.

Dotnet-клієнт може використовувати той самий файл kubeconfig, що і kubectl CLI, для пошуку та автентифікації на сервері API. Дивіться цей приклад:

using System;
using k8s;

namespace simple
{
    internal class PodList
    {
        private static void Main(string[] args)
        {
            var config = KubernetesClientConfiguration.BuildDefaultConfig();
            IKubernetes client = new Kubernetes(config);
            Console.WriteLine("Starting Request!");

            var list = client.ListNamespacedPod("default");
            foreach (var item in list.Items)
            {
                Console.WriteLine(item.Metadata.Name);
            }
            if (list.Items.Count == 0)
            {
                Console.WriteLine("Empty!");
            }
        }
    }
}

JavaScript-клієнт

Щоб встановити JavaScript-клієнт, виконайте наступну команду: npm install @kubernetes/client-node. Дивіться сторінку бібліотеки JavaScript-клієнта для отримання додаткових варіантів встановлення. Дивіться https://github.com/kubernetes-client/javascript/releases, щоб переглянути підтримувані версії.

JavaScript-клієнт може використовувати той самий файл kubeconfig, що і kubectl CLI, для пошуку та автентифікації на сервері API. Дивіться цей приклад:

const k8s = require('@kubernetes/client-node');

const kc = new k8s.KubeConfig();
kc.loadFromDefault();

const k8sApi = kc.makeApiClient(k8s.CoreV1Api);

k8sApi.listNamespacedPod('default').then((res) => {
    console.log(res.body);
});

Haskell-клієнт

Дивіться https://github.com/kubernetes-client/haskell/releases, щоб переглянути підтримувані версії.

Haskell-клієнт може використовувати той самий файл kubeconfig, що і kubectl CLI, для пошуку та автентифікації на сервері API. Дивіться цей приклад:

exampleWithKubeConfig :: IO ()
exampleWithKubeConfig = do
    oidcCache <- atomically $ newTVar $ Map.fromList []
    (mgr, kcfg) <- mkKubeClientConfig oidcCache $ KubeConfigFile "/path/to/kubeconfig"
    dispatchMime
            mgr
            kcfg
            (CoreV1.listPodForAllNamespaces (Accept MimeJSON))
        >>= print

Що далі

4.2.7 - Оголошення розширених ресурсів для вузла

Ця сторінка показує, як вказати розширені ресурси для вузла. Розширені ресурси дозволяють адміністраторам кластера оголошувати ресурси на рівні вузла, які інакше були б невідомі для Kubernetes.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Для перевірки версії введіть kubectl version.

Отримання імен ваших вузлів

kubectl get nodes

Виберіть один з ваших вузлів для цього завдання.

Щоб оголосити новий розширений ресурс на вузлі, відправте HTTP PATCH запит до сервера API Kubernetes. Наприклад, припустимо, що один з ваших вузлів має чотири підключені dongle. Ось приклад запиту PATCH, який оголошує чотири ресурси dongle для вашого вузла.

PATCH /api/v1/nodes/<your-node-name>/status HTTP/1.1
Accept: application/json
Content-Type: application/json-patch+json
Host: k8s-master:8080

[
  {
    "op": "add",
    "path": "/status/capacity/example.com~1dongle",
    "value": "4"
  }
]

Зверніть увагу, що Kubernetes не потрібно знати, що таке dongle або для чого він призначений. Попередній запит PATCH повідомляє Kubernetes, що ваш вузол має чотири речі, які ви називаєте dongle.

Запустіть проксі, щоб відправляти запити на сервер API Kubernetes:

kubectl proxy

У іншому вікні термінала відправте HTTP PATCH запит. Замініть <your-node-name> на імʼя вашого вузла:

curl --header "Content-Type: application/json-patch+json" \
  --request PATCH \
  --data '[{"op": "add", "path": "/status/capacity/example.com~1dongle", "value": "4"}]' \
  http://localhost:8001/api/v1/nodes/<your-node-name>/status

Вивід показує, що вузол має потужність 4 dongle:

"capacity": {
  "cpu": "2",
  "memory": "2049008Ki",
  "example.com/dongle": "4",

Опишіть свій вузол:

kubectl describe node <your-node-name>

Ще раз, вивід показує ресурс dongle:

Capacity:
  cpu: 2
  memory: 2049008Ki
  example.com/dongle: 4

Тепер розробники застосунків можуть створювати Podʼи, які вимагають певну кількість dongle. Див. Призначення розширених ресурсів контейнеру.

Обговорення

Розширені ресурси схожі на памʼять та ресурси CPU. Наприклад, так само як на вузлі є певна кількість памʼяті та CPU для спільного використання всіма компонентами, що працюють на вузлі, він може мати певну кількість dongle для спільного використання всіма компонентами, що працюють на вузлі. І так само як розробники застосунків можуть створювати Podʼи, які вимагають певної кількості памʼяті та CPU, вони можуть створювати Podʼи, які вимагають певну кількість dongle.

Розширені ресурси є непрозорими для Kubernetes; Kubernetes не знає нічого про їх призначення. Kubernetes знає лише, що у вузла є їх певна кількість. Розширені ресурси мають оголошуватись у цілих числах. Наприклад, вузол може оголошувати чотири dongle, але не 4,5 dongle.

Приклад зберігання

Припустимо, що вузол має 800 ГіБ особливого типу дискового простору. Ви можете створити назву для спеціального сховища, скажімо, example.com/special-storage. Потім ви можете оголошувати його в частинах певного розміру, скажімо, 100 ГіБ. У цьому випадку, ваш вузол буде повідомляти, що в ньому є вісім ресурсів типу example.com/special-storage.

Capacity:
 ...
 example.com/special-storage: 8

Якщо ви хочете дозволити довільні запити на спеціальне зберігання, ви можете оголошувати спеціальне сховище частками розміром 1 байт. У цьому випадку ви оголошуєте 800Gi ресурсів типу example.com/special-storage.

Capacity:
 ...
 example.com/special-storage:  800Gi

Потім контейнер може запросити будь-яку кількість байтів спеціального сховища, до 800Gi.

Очищення

Ось запит PATCH, який видаляє оголошення dongle з вузла.

PATCH /api/v1/nodes/<your-node-name>/status HTTP/1.1
Accept: application/json
Content-Type: application/json-patch+json
Host: k8s-master:8080

[
  {
    "op": "remove",
    "path": "/status/capacity/example.com~1dongle",
  }
]

Запустіть проксі, щоб відправляти запити на сервер API Kubernetes:

kubectl proxy

У іншому вікні термінала відправте HTTP PATCH запит. Замініть <your-node-name> на імʼя вашого вузла:

curl --header "Content-Type: application/json-patch+json" \
  --request PATCH \
  --data '[{"op": "remove", "path": "/status/capacity/example.com~1dongle"}]' \
  http://localhost:8001/api/v1/nodes/<your-node-name>/status

Перевірте, що оголошення dongle було видалено:

kubectl describe node <your-node-name> | grep dongle

(ви не повинні бачити жодного виводу)

Що далі

Для розробників застосунків

Для адміністраторів кластера

4.2.8 - Автоматичне масштабування служби DNS в кластері

Ця сторінка показує, як увімкнути та налаштувати автоматичне масштабування служби DNS у вашому кластері Kubernetes.

Перш ніж ви розпочнете

  • Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

    Для перевірки версії введіть kubectl version.

  • Цей посібник передбачає, що ваші вузли використовують архітектуру процесора AMD64 або Intel 64.

  • Переконайтеся, що DNS Kubernetes увімкнений.

Визначте, чи вже увімкнуто горизонтальне автоматичне масштабування DNS

Перегляньте Deploymentʼи у вашому кластері у просторі імен kube-system:

kubectl get deployment --namespace=kube-system

Вивід схожий на такий:

NAME                   READY   UP-TO-DATE   AVAILABLE   AGE
...
kube-dns-autoscaler    1/1     1            1           ...
...

Якщо ви бачите "kube-dns-autoscaler" у виводі, горизонтальне автоматичне масштабування DNS вже увімкнено, і ви можете перейти до Налаштування параметрів автоматичного масштабування.

Отримайте імʼя вашого Deployment DNS

Перегляньте Deployment DNS у вашому кластері у просторі імен kube-system:

kubectl get deployment -l k8s-app=kube-dns --namespace=kube-system

Вивід схожий на такий:

NAME      READY   UP-TO-DATE   AVAILABLE   AGE
...
coredns   2/2     2            2           ...
...

Якщо ви не бачите Deployment для DNS-служб, ви також можете знайти його за імʼям:

kubectl get deployment --namespace=kube-system

і пошукайте Deployment з назвою coredns або kube-dns.

Ваша ціль масштабування:

Deployment/<імʼя вашого розгортання>

де <імʼя вашого розгортання> — це імʼя вашого Deployment DNS. Наприклад, якщо імʼя вашого Deployment для DNS — coredns, ваша ціль масштабування — Deployment/coredns.

Увімкніть горизонтальне автоматичне масштабування DNS

У цьому розділі ви створюєте нове Deployment. Podʼи в Deployment працюють з контейнером на основі образу cluster-proportional-autoscaler-amd64.

Створіть файл з назвою dns-horizontal-autoscaler.yaml з таким вмістом:

kind: ServiceAccount
apiVersion: v1
metadata:
  name: kube-dns-autoscaler
  namespace: kube-system
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: system:kube-dns-autoscaler
rules:
  - apiGroups: [""]
    resources: ["nodes"]
    verbs: ["list", "watch"]
  - apiGroups: [""]
    resources: ["replicationcontrollers/scale"]
    verbs: ["get", "update"]
  - apiGroups: ["apps"]
    resources: ["deployments/scale", "replicasets/scale"]
    verbs: ["get", "update"]
# Remove the configmaps rule once below issue is fixed:
# kubernetes-incubator/cluster-proportional-autoscaler#16
  - apiGroups: [""]
    resources: ["configmaps"]
    verbs: ["get", "create"]
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: system:kube-dns-autoscaler
subjects:
  - kind: ServiceAccount
    name: kube-dns-autoscaler
    namespace: kube-system
roleRef:
  kind: ClusterRole
  name: system:kube-dns-autoscaler
  apiGroup: rbac.authorization.k8s.io

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: kube-dns-autoscaler
  namespace: kube-system
  labels:
    k8s-app: kube-dns-autoscaler
    kubernetes.io/cluster-service: "true"
spec:
  selector:
    matchLabels:
      k8s-app: kube-dns-autoscaler
  template:
    metadata:
      labels:
        k8s-app: kube-dns-autoscaler
    spec:
      priorityClassName: system-cluster-critical
      securityContext:
        seccompProfile:
          type: RuntimeDefault
        supplementalGroups: [ 65534 ]
        fsGroup: 65534
      nodeSelector:
        kubernetes.io/os: linux
      containers:
      - name: autoscaler
        image: registry.k8s.io/cpa/cluster-proportional-autoscaler:1.8.4
        resources:
            requests:
                cpu: "20m"
                memory: "10Mi"
        command:
          - /cluster-proportional-autoscaler
          - --namespace=kube-system
          - --configmap=kube-dns-autoscaler
          # Should keep target in sync with cluster/addons/dns/kube-dns.yaml.base
          - --target=<SCALE_TARGET>
          # When cluster is using large nodes(with more cores), "coresPerReplica" should dominate.
          # If using small nodes, "nodesPerReplica" should dominate.
          - --default-params={"linear":{"coresPerReplica":256,"nodesPerReplica":16,"preventSinglePointFailure":true,"includeUnschedulableNodes":true}}
          - --logtostderr=true
          - --v=2
      tolerations:
      - key: "CriticalAddonsOnly"
        operator: "Exists"
      serviceAccountName: kube-dns-autoscaler

У файлі замініть <SCALE_TARGET> на вашу ціль масштабування.

Перейдіть в теку, яка містить ваш файл конфігурації, та введіть цю команду для створення Deployment:

kubectl apply -f dns-horizontal-autoscaler.yaml

Вивід успішної команди:

deployment.apps/kube-dns-autoscaler created

Тепер горизонтальне автоматичне масштабування DNS увімкнено.

Налаштування параметрів автоматичного масштабування DNS

Перевірте, що існує ConfigMap kube-dns-autoscaler:

kubectl get configmap --namespace=kube-system

Вивід схожий на такий:

NAME                  DATA      AGE
...
kube-dns-autoscaler   1

     ...
...

Змініть дані в ConfigMap:

kubectl edit configmap kube-dns-autoscaler --namespace=kube-system

Знайдіть цей рядок:

linear: '{"coresPerReplica":256,"min":1,"nodesPerReplica":16}'

Змініть поля відповідно до ваших потреб. Поле "min" вказує на мінімальну кількість резервних DNS. Фактична кількість резервних копій обчислюється за цією формулою:

replicas = max( ceil( cores × 1/coresPerReplica ) , ceil( nodes × 1/nodesPerReplica ) )

Зверніть увагу, що значення як coresPerReplica, так і nodesPerReplica — це числа з комою.

Ідея полягає в тому, що, коли кластер використовує вузли з багатьма ядрами, coresPerReplica домінує. Коли кластер використовує вузли з меншою кількістю ядер, домінує nodesPerReplica.

Існують інші підтримувані шаблони масштабування. Докладні відомості див. у cluster-proportional-autoscaler.

Вимкніть горизонтальне автоматичне масштабування DNS

Існують декілька варіантів налаштування горизонтального автоматичного масштабування DNS. Який варіант використовувати залежить від різних умов.

Опція 1: Зменшити масштаб розгортання kube-dns-autoscaler до 0 резервних копій

Цей варіант працює для всіх ситуацій. Введіть цю команду:

kubectl scale deployment --replicas=0 kube-dns-autoscaler --namespace=kube-system

Вивід:

deployment.apps/kube-dns-autoscaler scaled

Перевірте, що кількість резервних копій дорівнює нулю:

kubectl get rs --namespace=kube-system

Вивід показує 0 в колонках DESIRED та CURRENT:

NAME                                  DESIRED   CURRENT   READY   AGE
...
kube-dns-autoscaler-6b59789fc8        0         0         0       ...
...

Опція 2: Видаліть розгортання kube-dns-autoscaler

Цей варіант працює, якщо kube-dns-autoscaler знаходиться під вашим контролем, що означає, що його ніхто не буде знову створювати:

kubectl delete deployment kube-dns-autoscaler --namespace=kube-system

Вивід:

deployment.apps "kube-dns-autoscaler" deleted

Опція 3: Видаліть файл маніфесту kube-dns-autoscaler з майстер-вузла

Цей варіант працює, якщо kube-dns-autoscaler знаходиться під контролем (застарілий) Addon Manager, і ви маєте права запису на майстер-вузол.

Увійдіть на майстер-вузол та видаліть відповідний файл маніфесту. Загальний шлях для цього kube-dns-autoscaler:

/etc/kubernetes/addons/dns-horizontal-autoscaler/dns-horizontal-autoscaler.yaml

Після видалення файлу маніфесту Addon Manager видалить розгортання kube-dns-autoscaler.

Розуміння того, як працює горизонтальне автоматичне масштабування DNS

  • Застосунок cluster-proportional-autoscaler розгортається окремо від служби DNS.

  • Pod автомасштабування працює клієнтом, який опитує сервер API Kubernetes для отримання кількості вузлів та ядер у кластері.

  • Обчислюється та застосовується бажана кількість резервних копій на основі поточних запланованих вузлів та ядер та заданих параметрів масштабування.

  • Параметри масштабування та точки даних надаються через ConfigMap Podʼа автомасштабування, і він оновлює свою таблицю параметрів щоразу під час періодичного опитування, щоб вона була актуальною з найновішими бажаними параметрами масштабування.

  • Зміни параметрів масштабування дозволені без перебудови або перезапуску Podʼа автомасштабування.

  • Автомасштабування надає інтерфейс контролера для підтримки двох шаблонів керування: linear та ladder.

Що далі

4.2.9 - Зміна режиму доступу до PersistentVolume на ReadWriteOncePod

Ця сторінка показує, як змінити режим доступу наявного PersistentVolume на ReadWriteOncePod.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Версія вашого Kubernetes сервера має бути не старішою ніж v1.22. Для перевірки версії введіть kubectl version.

Чому слід використовувати ReadWriteOncePod?

До версії Kubernetes v1.22 часто використовувався режим доступу ReadWriteOnce, щоб обмежити доступ до PersistentVolume для робочих навантажень, яким потрібен доступ одноосібного запису до сховища. Однак цей режим доступу мав обмеження: він обмежував доступ до тому одним вузлом, дозволяючи кільком Podʼам на одному вузлі одночасно читати та записувати в один і той же том. Це могло становити ризик для застосунків, які вимагають строгого доступу одноосібного запису для безпеки даних.

Якщо забезпечення доступу одноосібного запису є критичним для ваших робочих навантажень, розгляньте можливість міграції ваших томів на ReadWriteOncePod.

Міграція наявних PersistentVolumes

Якщо у вас є наявні PersistentVolumes, їх можна мігрувати на використання ReadWriteOncePod. Підтримується тільки міграція з ReadWriteOnce на ReadWriteOncePod.

У цьому прикладі вже є ReadWriteOnce "cat-pictures-pvc" PersistentVolumeClaim, який привʼязаний до "cat-pictures-pv" PersistentVolume, і "cat-pictures-writer" Deployment, який використовує цей PersistentVolumeClaim.

І ви можете переглянути PVC перед тим, як робити зміни. Перегляньте маніфест локально або виконайте kubectl get pvc <name-of-pvc> -o yaml. Вивід буде схожий на:

# cat-pictures-pvc.yaml
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: cat-pictures-pvc
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

Ось приклад Deployment, який залежить від цього PersistentVolumeClaim:

# cat-pictures-writer-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: cat-pictures-writer
spec:
  replicas: 3
  selector:
    matchLabels:
      app: cat-pictures-writer
  template:
    metadata:
      labels:
        app: cat-pictures-writer
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80
        volumeMounts:
        - name: cat-pictures
          mountPath: /mnt
      volumes:
      - name: cat-pictures
        persistentVolumeClaim:
          claimName: cat-pictures-pvc
          readOnly: false

На першому етапі вам потрібно відредагувати spec.persistentVolumeReclaimPolicy вашого PersistentVolume і встановити його на Retain. Це забезпечить, що ваш PersistentVolume не буде видалений, коли ви видалите відповідний PersistentVolumeClaim:

kubectl patch pv cat-pictures-pv -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'

Потім вам потрібно зупинити будь-які робочі навантаження, які використовують PersistentVolumeClaim, повʼязаний з PersistentVolume, який ви хочете мігрувати, а потім видалити PersistentVolumeClaim. Уникайте вносити будь-які інші зміни до PersistentVolumeClaim, такі як зміна розміру тому, поки міграція не буде завершена.

Якщо це зроблено, вам потрібно очистити spec.claimRef.uid вашого PersistentVolume, щоб забезпечити можливість звʼязування PersistentVolumeClaims з ним під час перестворення:

kubectl scale --replicas=0 deployment cat-pictures-writer
kubectl delete pvc cat-pictures-pvc
kubectl patch pv cat-pictures-pv -p '{"spec":{"claimRef":{"uid":""}}}'

Після цього замініть список дійсних режимів доступу до PersistentVolume, щоб був (тільки) ReadWriteOncePod:

kubectl patch pv cat-pictures-pv -p '{"spec":{"accessModes":["ReadWriteOncePod"]}}'

Після цього вам потрібно змінити ваш PersistentVolumeClaim, щоб встановити ReadWriteOncePod як єдиний режим доступу. Ви також повинні встановити spec.volumeName PersistentVolumeClaim на назву вашого PersistentVolume, щоб забезпечити його привʼязку саме до цього конкретного PersistentVolume.

Після цього ви можете перестворити ваш PersistentVolumeClaim та запустити ваші робочі навантаження:

# ВАЖЛИВО: Переконайтеся, що ви відредагували свій PVC в cat-pictures-pvc.yaml перед застосуванням. Вам потрібно:
# - Встановити ReadWriteOncePod як єдиний режим доступу
# - Встановити spec.volumeName на "cat-pictures-pv"

kubectl apply -f cat-pictures-pvc.yaml
kubectl apply -f cat-pictures-writer-deployment.yaml

Нарешті, ви можете відредагувати spec.persistentVolumeReclaimPolicy вашого PersistentVolume і встановити його знову на Delete, якщо ви раніше змінювали його.

kubectl patch pv cat-pictures-pv -p '{"spec":{"persistentVolumeReclaimPolicy":"Delete"}}'

Що далі

4.2.10 - Зміна типового StorageClass

Ця сторінка показує, як змінити типовий StorageClass, який використовується для створення томів для PersistentVolumeClaims, які не мають особливих вимог.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Для перевірки версії введіть kubectl version.

Чому змінювати типовий StorageClass?

Залежно від методу встановлення, ваш кластер Kubernetes може бути розгорнутий з наявним StorageClass, який позначений як типовий. Цей типовий StorageClass потім використовується для динамічного створення сховищ для PersistentVolumeClaims, які не вимагають будь-якого конкретного класу сховища. Див. документацію по PersistentVolumeClaim для деталей.

Попередньо встановлений типовий StorageClass може не відповідати вашим очікуваним навантаженням; наприклад, він може створювати занадто дороге сховище. У цьому випадку ви можете змінити типовий StorageClass або повністю вимкнути його, щоб уникнути динамічного створення сховища.

Видалення типового StorageClass може бути недійсним, оскільки він може бути автоматично створений знову менеджером надбудов, що працює в вашому кластері. Будь ласка, перегляньте документацію для вашого встановлення для деталей про менеджера надбудов та способи вимкнення окремих надбудов.

Зміна типового StorageClass

  1. Перегляньте StorageClasses у вашому кластері:

    kubectl get storageclass
    

    Вивід буде схожий на це:

    NAME                 PROVISIONER               AGE
    standard (default)   kubernetes.io/gce-pd      1д
    gold                 kubernetes.io/gce-pd      1д
    

    Типовий StorageClass позначений як (default).

  2. Позначте типовий StorageClass як не типовий:

    У типового StorageClass є анотація storageclass.kubernetes.io/is-default-class, встановлена на true. Будь-яке інше значення або відсутність анотації розглядається як false.

    Щоб позначити StorageClass як не типовий, вам потрібно змінити його значення на false:

    kubectl patch storageclass standard -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}'
    

    де standard — це назва вашого вибраного StorageClass.

  3. Позначте StorageClass як типовий:

    Аналогічно попередньому кроку, вам потрібно додати/встановити анотацію storageclass.kubernetes.io/is-default-class=true.

    kubectl patch storageclass gold -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
    

    Зверніть увагу, що максимум один StorageClass може бути позначений як типовий. Якщо два або більше з них позначені як типові, PersistentVolumeClaim без явно вказаного storageClassName не може бути створений.

  4. Перевірте, що ваш вибраний StorageClass є default:

    kubectl get storageclass
    

    Вивід буде схожий на це:

    NAME             PROVISIONER               AGE
    standard         kubernetes.io/gce-pd      1д
    gold (default)   kubernetes.io/gce-pd      1д
    

Що далі

4.2.11 - Перехід від опитування до оновлення стану контейнера на основі подій CRI

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.25 [alpha]

Ця сторінка показує, як мігрувати вузли для використання оновлення стану контейнера на основі подій. Реалізація на основі подій зменшує використання ресурсів вузла kubeletʼом порівняно зі старим підходом, який ґрунтується на опитуванні. Ви можете знати цю функцію як evented Pod lifecycle event generator (PLEG). Це назва, яка використовується внутрішньо в проєкті Kubernetes для основних деталей реалізації.

Підхід на основі опитування відомий як generic PLEG.

Перш ніж ви розпочнете

  • Ви повинні запускати версію Kubernetes, яка надає цю функцію. Kubernetes v1.27 включає підтримку бета-версії оновлення стану контейнера на основі подій. Функція є бета-версією, але стандартно вимкнена, оскільки вона потребує підтримки від середовища виконання контейнерів.
  • Версія вашого Kubernetes сервера має бути не старішою ніж 1.26. Для перевірки версії введіть kubectl version. Якщо ви використовуєте іншу версію Kubernetes, перевірте документацію для цього релізу.
  • Використане контейнерне середовище повинно підтримувати події життєвого циклу контейнера. Kubelet автоматично повертається до старого механізму опитування generic PLEG, якщо контейнерне середовище не оголошує підтримку подій життєвого циклу контейнера, навіть якщо у вас увімкнено цей функціонал.

Навіщо переходити на Evented PLEG?

  • Generic PLEG викликає значне навантаження через часте опитування стану контейнерів.
  • Це навантаження загострюється паралельним опитуванням стану контейнерів kublet, що обмежує його масштабованість та призводить до проблем з поганим функціонуванням та надійністю.
  • Мета Evented PLEG — зменшити непотрібну роботу під час бездіяльності шляхом заміни періодичного опитування.

Перехід на Evented PLEG

  1. Запустіть Kubelet з увімкненою функціональною можливістю EventedPLEG. Ви можете керувати feature gate kubelet редагуючи файл конфігурації kubelet і перезапустіть службу kubelet. Вам потрібно зробити це на кожному вузлі, де ви використовуєте цю функцію.

  2. Переконайтеся, що вузол виведено з експлуатації перед продовженням.

  3. Запустіть контейнерне середовище з увімкненою генерацією подій контейнера.

    Версія 1.7+

    Версія 1.26+

    Перевірте, чи CRI-O вже налаштований на відправлення CRI-подій, перевіривши конфігурацію,

    crio config | grep enable_pod_events
    

    Якщо він увімкнений, вивід повинен бути схожий на наступний:

    enable_pod_events = true
    

    Щоб увімкнути його, запустіть демон CRI-O з прапорцем --enable-pod-events=true або використовуйте конфігурацію dropin з наступними рядками:

    [crio.runtime]
    enable_pod_events: true
    
    Версія вашого Kubernetes сервера має бути не старішою ніж 1.26. Для перевірки версії введіть kubectl version.
  4. Перевірте, що kubelet використовує моніторинг стану контейнера на основі подій. Щоб перевірити це, шукайте термін EventedPLEG в журналах kubelet.

    Вивід буде схожий на це:

    I0314 11:10:13.909915 1105457 feature_gate.go:249] feature gates: &{map[EventedPLEG:true]}
    

    Якщо ви встановили --v у значення 4 і вище, ви можете побачити більше записів, що підтверджують, що kubelet використовує моніторинг стану контейнера на основі подій.

    I0314 11:12:42.009542 1110177 evented.go:238] "Evented PLEG: Generated pod status from the received event" podUID=3b2c6172-b112-447a-ba96-94e7022912dc
    I0314 11:12:44.623326 1110177 evented.go:238] "Evented PLEG: Generated pod status from the received event" podUID=b3fba5ea-a8c5-4b76-8f43-481e17e8ec40
    I0314 11:12:44.714564 1110177 evented.go:238] "Evented PLEG: Generated pod status from the received event" podUID=b3fba5ea-a8c5-4b76-8f43-481e17e8ec40
    

Що далі

4.2.12 - Зміна політики відновлення PersistentVolume

Ця сторінка показує, як змінити політику відновлення PersistentVolume в Kubernetes.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Для перевірки версії введіть kubectl version.

Навіщо змінювати політику відновлення PersistentVolume

У PersistentVolume можуть бути різні політики відновлення, включаючи "Retain", "Recycle" та "Delete". Для динамічно створених PersistentVolume типовою політикою відновлення є "Delete". Це означає, що динамічно створений том автоматично видаляється, коли користувач видаляє відповідний PersistentVolumeClaim. Ця автоматична поведінка може бути неприйнятною, якщо том містить важливі дані. У цьому випадку більш відповідною буде політика "Retain". З політикою "Retain", якщо користувач видаляє PersistentVolumeClaim, відповідний PersistentVolume не буде видалено. Замість цього він переміщується до фази Released, де всі його дані можуть бути вручну відновлені.

Зміна політики відновлення PersistentVolume

  1. Виведіть список PersistentVolume в вашому кластері:

    kubectl get pv
    

    Вивід буде схожий на такий:

    NAME                                       CAPACITY   ACCESSMODES   RECLAIMPOLICY   STATUS    CLAIM             STORAGECLASS     REASON    AGE
    pvc-b6efd8da-b7b5-11e6-9d58-0ed433a7dd94   4Gi        RWO           Delete          Bound     default/claim1    manual                     10s
    pvc-b95650f8-b7b5-11e6-9d58-0ed433a7dd94   4Gi        RWO           Delete          Bound     default/claim2    manual                     6s
    pvc-bb3ca71d-b7b5-11e6-9d58-0ed433a7dd94   4Gi        RWO           Delete          Bound     default/claim3    manual                     3s
    

    Цей список також включає імена заявок, які привʼязані до кожного тому для полегшення ідентифікації динамічно створених томів.

  2. Виберіть один з ваших PersistentVolume та змініть його політику відновлення:

    kubectl patch pv <your-pv-name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'
    

    де <your-pv-name> — це імʼя вашого обраного PersistentVolume.

  3. Перевірте, що ваш обраний PersistentVolume має відповідну політику:

    kubectl get pv
    

    Вивід буде схожий на такий:

    NAME                                       CAPACITY   ACCESSMODES   RECLAIMPOLICY   STATUS    CLAIM             STORAGECLASS     REASON    AGE
    pvc-b6efd8da-b7b5-11e6-9d58-0ed433a7dd94   4Gi        RWO           Delete          Bound     default/claim1    manual                     40s
    pvc-b95650f8-b7b5-11e6-9d58-0ed433a7dd94   4Gi        RWO           Delete          Bound     default/claim2    manual                     36s
    pvc-bb3ca71d-b7b5-11e6-9d58-0ed433a7dd94   4Gi        RWO           Retain          Bound     default/claim3    manual                     33s
    

    У попередньому виводі ви можете побачити, що том, привʼязаний до заявки default/claim3, має політику відновлення Retain. Він не буде автоматично видалений, коли користувач видаляє заявку default/claim3.

Що далі

Посилання

4.2.13 - Адміністрування менеджера хмарного контролера

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.11 [beta]

Оскільки хмарні провайдери розвиваються та випускають нові функції в іншому темпі порівняно з проєктом Kubernetes, абстрагування провайдеро-залежного коду у бінарний файл cloud-controller-manager дозволяє хмарним постачальникам розвиватися незалежно від основного коду Kubernetes.

cloud-controller-manager може бути повʼязаний з будь-яким хмарним провайдером, який відповідає вимогам cloudprovider.Interface. Для забезпечення зворотної сумісності, cloud-controller-manager, що постачається у складі основного проєкту Kubernetes, використовує ті ж хмарні бібліотеки, що і kube-controller-manager. Очікується, що хмарні постачальники, які вже підтримуються у ядрі Kubernetes, використовуватимуть вбудований cloud-controller-manager для передачі даних з ядра Kubernetes.

Адміністрування

Вимоги

Кожна хмара має свій власний набір вимог для запуску своєї інтеграції з власним провайдером, це не повинно суттєво відрізнятися від вимог до запуску kube-controller-manager. Загалом вам знадобиться:

  • автентифікація/авторизація в хмарі: вашій хмарі може знадобитися токен або правила IAM, щоб дозволити доступ до їхніх API
  • автентифікація/авторизація в Kubernetes: cloud-controller-manager може потребувати налаштування RBAC правила для звʼязку з apiserver Kubernetes
  • висока доступність: як і kube-controller-manager, вам може знадобитися налаштування високої доступності для cloud controller manager з використанням вибору лідера (стандартно увімкнено).

Робота cloud-controller-manager

Успішне виконання cloud-controller-manager вимагає деяких змін у конфігурації кластера.

  • kubelet, kube-apiserver та kube-controller-manager повинні бути налаштовані відповідно до використання користувачем зовнішнього CCM. Якщо користувач має зовнішній CCM (не внутрішні цикли управління хмарою в Kubernetes Controller Manager), то --cloud-provider=external повинен бути вказаний. В іншому випадку це не повинно бути вказано.

Майте на увазі, що налаштування кластера на використання контролера хмарного провайдера змінить поведінку вашого кластера:

  • Компоненти, що вказують --cloud-provider=external, додають спеціальний taint node.cloudprovider.kubernetes.io/uninitialized з ефектом NoSchedule під час ініціалізації. Це помічає вузол як такий, що потребує другої ініціалізації з зовнішнього контролера перед тим, як він зможе розпочати роботу. Зверніть увагу, що в разі недоступності cloud-controller-manager, нові вузли у кластері залишаться незапланованими. Taint важливий, оскільки планувальник може вимагати специфічної для хмари інформації про вузли, такої як їхній регіон чи тип (high cpu, gpu, high memory, spot instance тощо).
  • інформація про вузли в кластері більше не буде вибиратися з локальних метаданих, а замість цього всі виклики API для вибору інформації про вузли будуть проходити через cloud controller manager. Це може означати, що ви можете обмежити доступ до вашого API хмари на kubelet для кращої безпеки. Для великих кластерів вам може бути доцільно розглянути можливість обмеження швидкості викликів API cloud controller manager, оскільки він тепер відповідальний майже за всі виклики API вашої хмари зсередини кластера.

Контролер хмарного провайдера може надавати:

  • контролер Node — відповідає за оновлення вузлів Kubernetes з використанням API хмари та видалення вузлів Kubernetes, які були видалені у вашій хмарі.
  • контролер Service — відповідає за балансування навантаження у вашій хмарі для сервісів типу LoadBalancer.
  • контролер Route — відповідає за налаштування мережевих маршрутів у вашій хмарі
  • будь-які інші функції, які ви хочете реалізувати, якщо ви використовуєте провайдера не з ядра Kubernetes.

Приклади

Якщо ви використовуєте хмару, яка наразі підтримується в ядрі Kubernetes і хочете використовувати контролер хмарного провайдера, див. контролер хмарного провайдера в ядрі Kubernetes.

Для контролерів хмарних провайдерів, які не входять у ядро Kubernetes, ви можете знайти відповідні проєкти у репозиторіях, підтримуваних хмарними постачальниками або SIGs.

Для провайдерів, які вже є в ядрі Kubernetes, ви можете запускати вбудований контролер хмарного провайдера як DaemonSet у вашому кластері, використовуючи наступне як рекомендацію:

# Це приклад налаштування cloud-controller-manager як Daemonset у вашому кластері.
# Він передбачає, що ваші мастери можуть запускати Podʼи та мають роль node-role.kubernetes.io/master.
# Зверніть увагу, що цей Daemonset не працюватиме безпосередньо з коробки для вашого хмарного середовища, це
# призначено як рекомендація.

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: cloud-controller-manager
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: system:cloud-controller-manager
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- kind: ServiceAccount
  name: cloud-controller-manager
  namespace: kube-system
---
apiVersion: apps/v1
kind: DaemonSet
metadata:
  labels:
    k8s-app: cloud-controller-manager
  name: cloud-controller-manager
  namespace: kube-system
spec:
  selector:
    matchLabels:
      k8s-app: cloud-controller-manager
  template:
    metadata:
      labels:
        k8s-app: cloud-controller-manager
    spec:
      serviceAccountName: cloud-controller-manager
      containers:
      - name: cloud-controller-manager
        # for in-tree providers we use registry.k8s.io/cloud-controller-manager
        # this can be replaced with any other image for out-of-tree providers
        image: registry.k8s.io/cloud-controller-manager:v1.8.0
        command:
        - /usr/local/bin/cloud-controller-manager
        - --cloud-provider=[YOUR_CLOUD_PROVIDER]  # Add your own cloud provider here!
        - --leader-elect=true
        - --use-service-account-credentials
        # these flags will vary for every cloud provider
        - --allocate-node-cidrs=true
        - --configure-cloud-routes=true
        - --cluster-cidr=172.17.0.0/16
      tolerations:
      # this is required so CCM can bootstrap itself
      - key: node.cloudprovider.kubernetes.io/uninitialized
        value: "true"
        effect: NoSchedule
      # these tolerations are to have the daemonset runnable on control plane nodes
      # remove them if your control plane nodes should not run pods
      - key: node-role.kubernetes.io/control-plane
        operator: Exists
        effect: NoSchedule
      - key: node-role.kubernetes.io/master
        operator: Exists
        effect: NoSchedule
      # this is to restrict CCM to only run on master nodes
      # the node selector may vary depending on your cluster setup
      nodeSelector:
        node-role.kubernetes.io/master: ""

Обмеження

Запуск контролера хмарного провайдера супроводжується кількома можливими обмеженнями. Хоча ці обмеження вирішуються у майбутніх релізах, важливо, щоб ви були обізнані з цими обмеженнями для операційних робочих навантажень.

Підтримка томів

Контролер хмарного провайдера не реалізує жодного з контролерів томів, що знаходяться в kube-controller-manager, оскільки інтеграція томів також потребує координації з kubelet. Під час розвитку CSI (інтерфейс контейнерного сховища) та додавання більш надійної підтримки втулків flex томів буде додано необхідну підтримку до контролера хмарного провайдера, щоб хмари могли повністю інтегруватися з томами. Дізнайтеся більше про зовнішні втулки томів CSI тут.

Масштабованість

Контролер хмарного провайдера запитує API вашого хмарного постачальника для отримання інформації про всі вузли. Для дуже великих кластерів розгляньте можливі вузькі місця, такі як вимоги до ресурсів та обмеження швидкості API.

Курча і яйце

Метою проєкту контролера хмарного провайдера є відділення розробки хмарних функцій від розробки проєкту ядра Kubernetes. На жаль, багато аспектів проєкту Kubernetes мають припущення, що функції хмарного провайдера тісно інтегровані у проєкт. Внаслідок цього, прийняття цієї нової архітектури може створити кілька ситуацій, коли робиться запит інформації від хмарного постачальника, але контролер хмарного провайдера може не мати можливості повернути цю інформацію без завершення початкового запиту.

Хорошим прикладом цього є функція TLS bootstrapping в Kubelet. TLS bootstrapping передбачає, що Kubelet має можливість запитати у хмарного провайдера (або локального сервісу метаданих) всі його типи адрес (приватні, публічні і т. д.), але контролер хмарного провайдера не може встановити типи адрес вузла без попередньої ініціалізації, що потребує, щоб kubelet мав TLS-сертифікати для звʼязку з apiserver.

Під час розвитку цієї ініціативи будуть внесені зміни для розвʼязання цих питань у майбутніх релізах.

Що далі

Щоб створити та розробити свій власний контролер хмарного провайдера, прочитайте Розробка контролера хмарного провайдера.

4.2.14 - Налаштування постачальника облікових даних образів в kubelet

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.26 [stable]

Починаючи з Kubernetes v1.20, kubelet може динамічно отримувати облікові дані для реєстру образів контейнерів за допомогою використання втулків. Kubelet та втулок спілкуються через stdio (stdin, stdout та stderr), використовуючи версійні API Kubernetes. Ці втулки дозволяють kubelet запитувати облікові дані для реєстру контейнерів динамічно, на відміну від зберігання статичних облікових даних на диску. Наприклад, втулок може звертатися до локального сервера метаданих, щоб отримати облікові дані з обмеженим терміном дії для образу, який завантажується kubelet.

Ви можете бути зацікавлені у використанні цієї можливості, якщо будь-яке з нижче перерахованих тверджень є правдивим:

  • Потрібні виклики API до служби хмарного постачальника для отримання інформації для автентифікації реєстру.
  • Облікові дані мають короткий термін дії, і потрібно часто запитувати нові облікові дані.
  • Зберігання облікових даних реєстру на диску або в imagePullSecrets неприпустиме.

Цей посібник демонструє, як налаштувати механізм втулка постачальника облікових даних зображення kubelet.

Перш ніж ви розпочнете

  • Вам потрібен кластер Kubernetes з вузлами, які підтримують втулки постачальника облікових даних kubelet. Ця підтримка доступна у Kubernetes 1.31; Kubernetes v1.24 та v1.25 мали це як бета-функцію, яка є типово увімкненою.
  • Робоча реалізація втулка постачальника облікових даних. Ви можете створити власний втулок або використовувати той що, наданий хмарним постачальником.
Версія вашого Kubernetes сервера має бути не старішою ніж v1.26. Для перевірки версії введіть kubectl version.

Встановлення втулків на вузлах

Втулок постачальника облікових даних — це виконавчий бінарний файл, який kubelet буде використовувати. Переконайтеся, що бінарний файл втулка існує на кожному вузлі вашого кластера і зберігається в відомій теці. Ця тека буде потрібна пізніше при налаштуванні прапорців kubelet.

Налаштування Kubelet

Для використання цієї функції kubelet очікує встановлення двох прапорців:

  • --image-credential-provider-config — шлях до файлу конфігурації втулка постачальника облікових даних.
  • --image-credential-provider-bin-dir — шлях до теки, де знаходяться бінарні файли втулка постачальника облікових даних.

Налаштування постачальника облікових даних kubelet

Файл конфігурації, переданий в --image-credential-provider-config, зчитується kubelet для визначення, які виконавчі втулки слід викликати для яких образів контейнерів. Нижче наведено приклад файлу конфігурації, який ви, можливо, будете використовувати, якщо використовуєте втулок, оснований на ECR:

apiVersion: kubelet.config.k8s.io/v1
kind: CredentialProviderConfig
# providers — це список допоміжних втулків постачальників облікових даних, які будуть активовані
# kubelet. Одному образу може відповідати декілька постачальників, в такому випадку облікові дані
# від усіх постачальників будуть повернуті kubelet. Якщо для одного образу є кілька 
# постачальників, результати будуть обʼєднані. Якщо постачальники повертають ключі автентифікації,
# що перекриваються, використовується значення від постачальника, який знаходиться раніше в цьому 
# списку.
providers:
  # name — це обовʼязкове імʼя постачальника облікових даних. Воно повинно відповідати імені
  # виконавчого файлу постачальника, яке бачить kubelet. Виконавчий файл повинен знаходитися в 
  # теці bin kubelet (встановлено за допомогою прапорця --image-credential-provider-bin-dir).
  - name: ecr-credential-provider
    # matchImages - обовʼязковий список рядків, які використовуються для порівняння з образами, щоб
    # визначити, чи потрібно викликати цього постачальника. Якщо один із рядків відповідає
    # запитаному образу від kubelet, втулок буде викликаний і отримає шанс надати облікові дані. 
    # Очікується, що образи містять домен реєстру та URL-шлях.
    #
    # Кожний запис в matchImages — це шаблон, який може необовʼязково містити порт та шлях.
    # Можна використовувати шаблони для домену, але не для порту або шляху. Шаблони підтримуються
    # як піддомени, наприклад, '*.k8s.io' або 'k8s.*.io', так і верхніх рівнів доменів, наприклад, 
    # 'k8s.*'. Підтримується також частковий збіг піддоменів, наприклад, 'app*.k8s.io'. Кожен 
    # шаблон може відповідати лише одному сегменту піддомену, тому `*.io` **не** відповідає 
    # `*.k8s.io`.
    #
    # Збіг існує між образами та matchImage, коли виконуються всі наведені нижче умови:
    # - Обидва мають однакову кількість частин домену і кожна частина має збіг.
    # - URL-шлях matchImages повинен бути префіксом URL-шляху цільового образу.
    # - Якщо matchImages містить порт, то порт також повинен мати збіг в образі.
    # Приклади значент matchImages:
    # - 123456789.dkr.ecr.us-east-1.amazonaws.com
    # - *.azurecr.io
    # - gcr.io
    # - *.*.registry.io
    # - registry.io:8080/path
    matchImages:
      - "*.dkr.ecr.*.amazonaws.com"
      - "*.dkr.ecr.*.amazonaws.com.cn"
      - "*.dkr.ecr-fips.*.amazonaws.com"
      - "*.dkr.ecr.us-iso-east-1.c2s.ic.gov"
      - "*.dkr.ecr.us-isob-east-1.sc2s.sgov.gov"
    # defaultCacheDuration — це типовий час, протягом якої втулок буде кешувати облікові дані у памʼяті,
    # якщо тривалість кешу не надана у відповіді втулку. Це поле є обовʼязковим.
    defaultCacheDuration: "12h"
    # Вхідна версія CredentialProviderRequest є обовʼязковою. Відповідь CredentialProviderResponse
    # ПОВИННА використовувати ту ж версію кодування, що й вхідна. Поточні підтримувані значення:
    # - credentialprovider.kubelet.k8s.io/v1
    apiVersion: credentialprovider.kubelet.k8s.io/v1
    # Аргументи, що перндаються команді під час її виконання.
    # +optional
    # args:
    #   - --example-argument
    # Env визначає додаткові змінні середовища, які слід надати процесу. Ці
    # змінні обʼєднуються з оточенням хоста, а також змінними, які використовує client-go
    # для передачі аргументів до втулка.
    # +optional
    env:
      - name: AWS_PROFILE
        value: example_profile

Поле providers — це список увімкнених втулків, які використовує kubelet. Кожен запис має кілька обовʼязкових полів:

  • name: назва втулка, яка ПОВИННА відповідати назві виконавчого бінарного файлу, який існує в теці, вказаній у --image-credential-provider-bin-dir.
  • matchImages: список рядків, які використовуються для порівняння образів з метою визначення, чи слід викликати цього постачальника для конкретного образу контейнера. Докладніше про це нижче.
  • defaultCacheDuration: термін, протягом якого kubelet буде кешувати облікові дані в памʼяті, якщо втулок не надав термін кешування.
  • apiVersion: версія API, яку використовуватимуть kubelet і виконавчий втулок під час спілкування.

Кожен постачальник облікових даних також може мати додаткові аргументи та змінні середовища. Перегляньте реалізацію втулків, щоб визначити, який набір аргументів та змінних середовища потрібний для певного втулка.

Налаштування збігу образів

Поле matchImages для кожного постачальника облікових даних використовується kubelet для визначення того, чи слід викликати втулок для певного образу, що використовується в Podʼі. Кожний запис у matchImages — це шаблон образу, який може опціонально містити порт та шлях. Символи підстановки дозволяють використовувати шаблони для піддоменів, такі як *.k8s.io або k8s.*.io, а також для доменів верхнього рівня, такі як k8s.*. Збіг між імʼям образу та записом matchImage існує тоді, коли виконуються всі умови:

  • Обидва містять однакову кількість частин домену, і кожна частина має збіг.
  • Шлях URL matchImage повинен бути префіксом шляху URL цільового образу.
  • Якщо matchImages містить порт, то порт також повинен мати збіг в образі.

Деякі приклади значень шаблонів matchImages:

  • 123456789.dkr.ecr.us-east-1.amazonaws.com
  • *.azurecr.io
  • gcr.io
  • *.*.registry.io
  • foo.registry.io:8080/path

Що далі

4.2.15 - Налаштування квот для обʼєктів API

Ця сторінка показує, як налаштувати квоти для обʼєктів API, включаючи PersistentVolumeClaims та Services. Квота обмежує кількість обʼєктів певного типу, які можуть бути створені в просторі імен. Ви вказуєте квоти в обʼєкті ResourceQuota.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Для перевірки версії введіть kubectl version.

Створення простору імен

Створіть простір імен, щоб ресурси, які ви створюєте у цьому завданні, були ізольовані від решти вашого кластера.

kubectl create namespace quota-object-example

Створення ResourceQuota

Ось файл конфігурації для обʼєкта ResourceQuota:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: object-quota-demo
spec:
  hard:
    persistentvolumeclaims: "1"
    services.loadbalancers: "2"
    services.nodeports: "0"

Створіть ResourceQuota:

kubectl apply -f https://k8s.io/examples/admin/resource/quota-objects.yaml --namespace=quota-object-example

Перегляньте докладну інформацію про ResourceQuota:

kubectl get resourcequota object-quota-demo --namespace=quota-object-example --output=yaml

У виводі показано, що в просторі імен quota-object-example може бути максимум один PersistentVolumeClaim, максимум два Services типу LoadBalancer та жодного Services типу NodePort.

status:
  hard:
    persistentvolumeclaims: "1"
    services.loadbalancers: "2"
    services.nodeports: "0"
  used:
    persistentvolumeclaims: "0"
    services.loadbalancers: "0"
    services.nodeports: "0"

Створення PersistentVolumeClaim

Ось файл конфігурації для обʼєкта PersistentVolumeClaim:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-quota-demo
spec:
  storageClassName: manual
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 3Gi

Створіть PersistentVolumeClaim:

kubectl apply -f https://k8s.io/examples/admin/resource/quota-objects-pvc.yaml --namespace=quota-object-example

Перевірте, що PersistentVolumeClaim було створено:

kubectl get persistentvolumeclaims --namespace=quota-object-example

У виводі показано, що PersistentVolumeClaim існує і має статус Pending:

NAME             STATUS
pvc-quota-demo   Pending

Спроба створити другий PersistentVolumeClaim

Ось файл конфігурації для другого PersistentVolumeClaim:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-quota-demo-2
spec:
  storageClassName: manual
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 4Gi

Спробуйте створити другий PersistentVolumeClaim:

kubectl apply -f https://k8s.io/examples/admin/resource/quota-objects-pvc-2.yaml --namespace=quota-object-example

У виводі показано, що другий PersistentVolumeClaim не був створений, оскільки це перевищило квоту для простору імен.

persistentvolumeclaims "pvc-quota-demo-2" is forbidden:
exceeded quota: object-quota-demo, requested: persistentvolumeclaims=1,
used: persistentvolumeclaims=1, limited: persistentvolumeclaims=1

Примітки

Ці рядки використовуються для ідентифікації обʼєктів API, які можуть бути обмежені за допомогою квот:

РядокОбʼєкт API
"pods"Pod
"services"Service
"replicationcontrollers"ReplicationController
"resourcequotas"ResourceQuota
"secrets"Secret
"configmaps"ConfigMap
"persistentvolumeclaims"PersistentVolumeClaim
"services.nodeports"Service типу NodePort
"services.loadbalancers"Service типу LoadBalancer

Очищення

Видаліть свій простір імен:

kubectl delete namespace quota-object-example

Що далі

Для адміністраторів кластера

Для розробників застосунків

4.2.16 - Управління політиками керування ЦП на вузлі

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.26 [stable]

Kubernetes зберігає багато аспектів того, як Podʼи виконуються на вузлах, абстрагованими від користувача. Це зроблено навмисно. Проте деякі завдання вимагають більших гарантій з погляду часу реакції та/або продуктивності, щоб працювати задовільно. Kubelet надає методи для включення складніших політик розміщення завдань, зберігаючи абстракцію вільною від явних директив розміщення.

Для отримання докладної інформації щодо управління ресурсами, будь ласка, зверніться до документації Управління ресурсами для Podʼів та контейнерів.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Версія вашого Kubernetes сервера має бути не старішою ніж v1.26. Для перевірки версії введіть kubectl version.

Якщо ви використовуєте старішу версію Kubernetes, будь ласка, перегляньте документацію для версії, яку ви фактично використовуєте.

Політики керування ЦП

Стандартно, kubelet використовує квоту CFS, щоб обмежувати ЦП для Podʼів. Коли вузол виконує багато Podʼів, залежних від ЦП, навантаження може переміщуватися на різні ядра ЦП залежно від того, чи обмежений Pod, і які ядра ЦП доступні на момент планування. Багато завдань не чутливі до цього переміщення і, отже, працюють нормально без будь-якого втручання.

Проте, в завданнях, де спорідненість кешу ЦП та затримка планування значно впливають на продуктивність робочого завдання, kubelet дозволяє використовувати альтернативні політики керування ЦП для визначення деяких вподобань розміщення на вузлі.

Налаштування

Політика керування ЦП встановлюється прапорцем kubelet --cpu-manager-policy або полем cpuManagerPolicy в KubeletConfiguration. Підтримуються дві політики:

  • none: стандартна політика.
  • static: дозволяє контейнерам з певними характеристиками ресурсів отримувати збільшену спорідненість ЦП та ексклюзивність на вузлі.

Керування ЦП періодично записує оновлення ресурсів через CRI, щоб звести до мінімуму проблеми сумісності памʼяті та виправити їх. Частота зведення встановлюється за допомогою нового значення конфігурації Kubelet --cpu-manager-reconcile-period. Якщо вона не вказана, стандартно вона дорівнює тому ж часу, що й --node-status-update-frequency.

Поведінку статичної політики можна налаштувати за допомогою прапорця --cpu-manager-policy-options. Прапорець приймає список параметрів політики у вигляді ключ=значення. Якщо ви вимкнули функціональну можливість CPUManagerPolicyOptions, то ви не зможете налаштувати параметри політик керування ЦП. У цьому випадку керування ЦП працюватиме лише зі своїми стандартними налаштуваннями.

Окрім верхнього рівня CPUManagerPolicyOptions, параметри політики розділені на дві групи: якість альфа (типово прихована) та якість бета (типово видима). Відмінно від стандарту Kubernetes, ці feature gate захищають групи параметрів, оскільки було б надто складно додати feature gate для кожного окремого параметра.

Зміна політики керування ЦП

Оскільки політику керування ЦП можна застосовувати лише коли kubelet створює нові Podʼи, просте змінення з "none" на "static" не застосується до наявних Podʼів. Тому, щоб правильно змінити політику керування ЦП на вузлі, виконайте наступні кроки:

  1. Виведіть з експлуатації вузол.
  2. Зупиніть kubelet.
  3. Видаліть старий файл стану керування ЦП. Типовий шлях до цього файлу /var/lib/kubelet/cpu_manager_state. Це очищує стан, що зберігається CPUManager, щоб множини ЦП, налаштовані за новою політикою, не конфліктували з нею.
  4. Відредагуйте конфігурацію kubelet, щоб змінити політику керування ЦП на потрібне значення.
  5. Запустіть kubelet.

Повторіть цей процес для кожного вузла, який потребує зміни політики керування ЦП. Пропуск цього процесу призведе до постійної аварійної роботи kubelet з такою помилкою:

could not restore state from checkpoint: configured policy "static" differs from state checkpoint policy "none", please drain this node and delete the CPU manager checkpoint file "/var/lib/kubelet/cpu_manager_state" before restarting Kubelet

Політика none

Політика none явно активує наявну стандартну схему спорідненості ЦП, не надаючи спорідненості поза тим, що робить планувальник ОС автоматично. Обмеження на використання ЦП для Podʼів з гарантованою продуктивністю та Podʼів з бурхливою продуктивністю накладаються за допомогою квоти CFS.

Політика static

Політика static дозволяє контейнерам у Podʼах з гарантованою продуктивністю із цілими requests ЦП мати доступ до ексклюзивних ЦП на вузлі. Ця ексклюзивність забезпечується за допомогою контролера груп cgroup для cpuset.

Ця політика керує спільним пулом ЦП, який на початку містить всі ЦП на вузлі. Кількість ексклюзивно виділених ЦП дорівнює загальній кількості ЦП на вузлі мінус будь-які резерви ЦП за допомогою параметрів kubelet --kube-reserved або --system-reserved. З версії 1.17 список резервувань ЦП може бути вказаний явно за допомогою параметру kubelet --reserved-cpus. Явний список ЦП, вказаний за допомогою --reserved-cpus, має пріоритет над резервуванням ЦП, вказаним за допомогою --kube-reserved та --system-reserved. ЦП, зарезервовані цими параметрами, беруться, у цілочисельній кількості, зі спільного пулу на основі фізичного ідентифікатора ядра. Цей спільний пул — це множина ЦП, на яких працюють контейнери в Podʼах з BestEffort та Burstable. Контейнери у Podʼах з гарантованою продуктивністю з цілими requests ЦП також працюють на ЦП у спільному пулі. Ексклюзивні ЦП призначаються лише контейнерам, які одночасно належать до Podʼа з гарантованою продуктивністю та мають цілочисельні requests ЦП.

Коли Podʼи з гарантованою продуктивністю (Guaranteed), чий контейнер відповідає вимогам для статичного призначення, планується на вузол, ЦП видаляються зі спільного пулу і поміщаються у cpuset для контейнера. Квота CFS не використовується для обмеження використання ЦП цих контейнерів, оскільки їх використання обмежується самою областю планування. Іншими словами, кількість ЦП у cpuset контейнера дорівнює цілому limit ЦП, вказаному в специфікації Podʼа. Це статичне призначення підвищує спорідненість ЦП та зменшує перемикання контексту через обмеження для навантаження, залежного від ЦП.

Розгляньте контейнери в наступних специфікаціях Podʼа:

spec:
  containers:
  - name: nginx
    image: nginx

Pod, вказаний вище, працює в класі QoS BestEffort, оскільки не вказані requests або limits ресурсів. Він працює у спільному пулі.

spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        memory: "200Mi"
      requests:
        memory: "100Mi"

Pod, вказаний вище, працює в класі QoS Burstable, оскільки requests ресурсів не дорівнюють limits, а кількість cpu не вказана. Він працює у спільному пулі.

spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        memory: "200Mi"
        cpu: "2"
      requests:
        memory: "100Mi"
        cpu: "1"

Pod, вказаний вище, працює в класі QoS Burstable, оскільки requests ресурсів не дорівнюють limits. Він працює у спільному пулі.

spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        memory: "200Mi"
        cpu: "2"
      requests:
        memory: "200Mi"
        cpu: "2"

Pod, вказаний вище, працює в класі QoS Guaranteed, оскільки requests дорівнюють limits. І ліміт ресурсу ЦП контейнера є цілим числом більшим або рівним одиниці. Контейнер nginx отримує 2 ексклюзивних ЦП.

spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        memory: "200Mi"
        cpu: "1.5"
      requests:
        memory: "200Mi"
        cpu: "1.5"

Pod, вказаний вище, працює в класі QoS Guaranteed, оскільки requests дорівнюють limits. Але ліміт ресурсу ЦП контейнера є дробовим числом. Він працює у спільному пулі.

spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        memory: "200Mi"
        cpu: "2"

Pod, вказаний вище, працює в класі QoS Guaranteed, оскільки вказані тільки limits, а requests встановлені рівними limits, коли не вказано явно. І ліміт ресурсу ЦП контейнера є цілим числом більшим або рівним одиниці. Контейнер nginx отримує 2 ексклюзивних ЦП.

Параметри політики static

Ви можете включати та виключати групи параметрів на основі їх рівня зрілості, використовуючи наступні feature gate:

  • CPUManagerPolicyBetaOptions — стандартно увімкнено. Вимкніть, щоб приховати параметри рівня бета.
  • CPUManagerPolicyAlphaOptions — стандартно вимкнено. Увімкніть, щоб показати параметри рівня альфа. Ви все ще повинні увімкнути кожен параметр за допомогою опції kubelet CPUManagerPolicyOptions.

Для політики static CPUManager існують наступні параметри:

  • full-pcpus-only (бета, типово видимий) (1.22 або вище)
  • distribute-cpus-across-numa (альфа, типово прихований) (1.23 або вище)
  • align-by-socket (альфа, типово прихований) (1.25 або вище)
  • distribute-cpus-across-cores (альфа, типово прихований) (1.31 або вище)

Якщо вказано параметр політики full-pcpus-only, статична політика завжди виділятиме повні фізичні ядра. Стандартно, без цієї опції, статична політика розподіляє ЦП, використовуючи найкращий вибір з урахуванням топології. На системах з увімкненими SMT, політика може виділяти окремі віртуальні ядра, які відповідають апаратним потокам. Це може призвести до того, що різні контейнери будуть використовувати одні й ті ж фізичні ядра; ця поведінка, своєю чергою, спричиняє проблему шумних сусідів. З включеною опцією, Pod буде прийнятий kubelet лише в тому випадку, якщо запити на ЦП всіх його контейнерів можна задовольнити виділенням повних фізичних ядер. Якщо Pod не пройде процедуру допуску, він буде переведений в стан Failed з повідомленням SMTAlignmentError.

Якщо вказано параметр політики distribute-cpus-across-numa, статична політика рівномірно розподілить ЦП по вузлах NUMA у випадках, коли для задоволення розподілу необхідно більше одного вузла NUMA. Стандартно CPUManager буде пакувати ЦП на один вузол NUMA, поки він не буде заповнений, і будь-які залишкові ЦП просто перейдуть на наступний вузол NUMA. Це може призвести до небажаних заторів у паралельному коді, що покладається на барʼєри (та подібні примітиви синхронізації), оскільки цей тип коду, як правило, працює лише так швидко, як його найповільніший робітник (який сповільнюється тим, що на одному з вузлів NUMA доступно менше ЦП). Рівномірний розподіл ЦП по вузлах NUMA дозволяє розробникам програм легше забезпечувати те, що жоден окремий робітник не страждає від ефектів NUMA більше, ніж будь-який інший, що покращує загальну продуктивність цих типів програм.

Якщо вказано параметр політики align-by-socket, ЦП будуть вважатися вирівненими на межі сокета при вирішенні того, як розподілити ЦП між контейнерами. Стандартно, CPUManager вирівнює виділення ЦП на межі NUMA, що може призвести до погіршання продуктивності, якщо ЦП потрібно вилучати з більш ніж одного вузла NUMA для задоволення виділення. Попри те, що він намагається забезпечити, щоб всі ЦП були виділені з мінімальної кількості вузлів NUMA, немає гарантії, що ці вузли NUMA будуть на одному сокеті. Вказуючи CPUManager явно вирівнювати ЦП на межі сокета, а не NUMA, ми можемо уникнути таких проблем. Зауважте, що ця опція політики несумісна з політикою TopologyManager single-numa-node і не застосовується до апаратного забезпечення, де кількість сокетів більша, ніж кількість вузлів NUMA.

Якщо вказана опція політики distribute-cpus-across-cores, статична політика спробує розподілити віртуальні ядра (апаратні потоки) по різних фізичних ядрах. Стандартно, CPUManager має тенденцію запаковувати процесори на якомога меншій кількості фізичних ядер, що може призвести до конфліктів між процесорами на одному фізичному ядрі та, як наслідок, до проблем з продуктивністю. Увімкнувши політику distribute-cpus-across-cores, статична політика забезпечує розподіл процесорів по якомога більшій кількості фізичних ядер, зменшуючи конфлікти на одному фізичному ядрі й тим самим покращуючи загальну продуктивність. Проте, важливо зазначити, що ця стратегія може бути менш ефективною, коли система сильно навантажена. За таких умов вигода від зменшення конфліктів зменшується. З іншого боку, стандартна поведінка може допомогти зменшити витрати на комунікацію між ядрами, що потенційно забезпечує кращу продуктивність при високих навантаженнях.

Параметр full-pcpus-only можна включити, додавши full-pcpus-only=true до параметрів політики CPUManager. Так само параметр distribute-cpus-across-numa можна включити, додавши distribute-cpus-across-numa=true до параметрів політики CPUManager. Якщо обидва встановлені, вони "адитивні" у тому сенсі, що ЦП будуть розподілені по вузлах NUMA в шматках повних фізичних ядер, а не окремих ядер. Параметр політики align-by-socket можна увімкнути, додавши align-by-socket=true до параметрів політики CPUManager. Він також адитивний до параметрів політики full-pcpus-only та distribute-cpus-across-numa.

Опцію distribute-cpus-across-cores можна увімкнути, додавши distribute-cpus-across-cores=true до параметрів політики CPUManager. Зараз її не можна використовувати разом з параметрами політики full-pcpus-only або distribute-cpus-across-numa.

4.2.17 - Керування політиками топології на вузлі

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.27 [stable]

Зростаюча кількість систем використовує комбінацію ЦП та апаратних прискорювачів для підтримки виконання, критичного з погляду затримок, та високопродуктивних паралельних обчислень. Ці системи включають робочі навантаження у таких галузях, як телекомунікації, наукові обчислення, машинне навчання, фінансові послуги та аналітика даних. Такі гібридні системи складають високопродуктивне середовище.

Для досягнення найкращої продуктивності потрібні оптимізації, що стосуються ізоляції ЦП, памʼяті та локальності пристроїв. Проте, в Kubernetes ці оптимізації обробляються роздільним набором компонентів.

Topology Manager — це компонент Kubelet, який має на меті координацію набору компонентів, відповідальних за ці оптимізації.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Версія вашого Kubernetes сервера має бути не старішою ніж v1.18. Для перевірки версії введіть kubectl version.

Як працює Topology Manager

Перед введенням Topology Manager, CPU та Device Manager в Kubernetes приймають рішення про розподіл ресурсів незалежно одне від одного. Це може призводити до небажаних розподілів на системах з кількома сокетами, де застосунки, що чутливі до продуктивності/затримки, будуть страждати через ці небажані розподіли. Небажані в цьому випадку означає, наприклад, виділення ЦП та пристроїв з різних вузлів NUMA, що призводить до додаткової затримки.

Topology Manager — це компонент Kubelet, який діє як джерело правди, щоб інші компоненти Kubelet могли робити вибір щодо розподілу ресурсів з урахуванням топології.

Topology Manager надає інтерфейс для компонентів, званих Hint Providers, для надсилання та отримання інформації про топологію. У Topology Manager є набір політик рівня вузла, які пояснюються нижче.

Topology manager отримує інформацію про топологію від Hint Providers у вигляді бітової маски, яка позначає доступні вузли NUMA та попередній показник виділення. Політики Topology Manager виконують набір операцій з наданими підказками та сходяться на підказці, визначеній політикою, щоб дати оптимальний результат, якщо зберігається небажана підказка, бажане поле для підказки буде встановлено у false. У поточних політиках найприйнятніше — це найвужча попередня маска. Обрана підказка зберігається як частина Topology Manager. Залежно від налаштованої політики, Pod може бути прийнятий або відхилений на вузлі на основі обраної підказки. Підказка потім зберігається в Topology Manager для використання Hint Providers під час прийняття рішень про розподіл ресурсів.

Scope та Policy в Topology Manager

Topology Manager наразі:

  • Вирівнює Podʼи усіх класів QoS.
  • Вирівнює запитані ресурси, які Hint Provider надає підказки топології.

Якщо ці умови виконані, Topology Manager вирівнює запитані ресурси.

Для того, щоб налаштувати, як це вирівнювання виконується, Topology Manager надає два відмінні регулятори: scope та policy.

scope визначає гранулярність, на якій ви хочете, щоб виконувалось вирівнювання ресурсів (наприклад, на рівні pod або container). А policy визначає фактичну стратегію, яка використовується для виконання вирівнювання (наприклад, best-effort, restricted, single-numa-node і т.д.). Деталі щодо різних scopes та policies, доступних на сьогодні, можна знайти нижче.

Scope в Topology Manager

Topology Manager може вирівнювати ресурси у кількох різних сферах:

  • container (стандартно)
  • pod

Будь-яку з цих опцій можна вибрати під час запуску kubelet, налаштувавши параметр topologyManagerScope у файлі конфігурації kubelet.

Scope container

Scope container використовується стандартно. Ви також можете явно встановити параметр topologyManagerScope в container у файлі конфігурації kubelet.

У цьому scope Topology Manager виконує кілька послідовних вирівнювань ресурсів, тобто для кожного контейнера (у Pod) окреме вирівнювання. Іншими словами, відсутнє поняття групування контейнерів у певний набір вузлів NUMA, для цього конкретного scope. Фактично Topology Manager виконує довільне вирівнювання окремих контейнерів на вузли NUMA.

Ідея групування контейнерів була затверджена та реалізована навмисно в наступному scope, наприклад, у scope pod.

Scope pod

Для вибору scope pod, встановіть параметр topologyManagerScope у файлі конфігурації kubelet на pod.

Цей scope дозволяє групувати всі контейнери у Podʼі у спільний набір вузлів NUMA. Іншими словами, Topology Manager розглядає Pod як ціле та намагається виділити весь Pod (всі контейнери) на один вузол NUMA або спільний набір вузлів NUMA. Нижче наведено приклади вирівнювання, які виробляє Topology Manager у різні моменти:

  • всі контейнери можуть бути та виділені на один вузол NUMA;
  • всі контейнери можуть бути та виділені на спільний набір вузлів NUMA.

Загальна кількість певного ресурсу, запитаного для всього Podʼа, розраховується за формулою ефективні запити/обмеження, і, таким чином, це загальне значення дорівнює максимуму з:

  • сума всіх запитів контейнерів застосунку,
  • максимум запитів контейнерів ініціалізації,

для ресурсу.

Використання scope pod разом з політикою Topology Manager single-numa-node особливо цінне для робочих навантажень, які чутливі до затримок, або для високопродуктивних застосунків, які виконують міжпроцесну комунікацію (IPC). Поєднуючи обидва варіанти, ви можете помістити всі контейнери в Pod на один вузол NUMA; отже, можливість між-NUMA комунікації може бути усунена для цього Pod.

У випадку політики single-numa-node Pod приймається лише в тому разі, якщо серед можливих виділень є відповідний набір вузлів NUMA. Перегляньте приклад вище:

  • набір, що містить лише один вузол NUMA — це призводить до допуску Podʼа,
  • тоді як набір, що містить більше вузлів NUMA — це призводить до відхилення Podʼа (тому, що для задоволення виділення потрібен один вузол NUMA).

У підсумку, Topology Manager спочатку розраховує набір вузлів NUMA, а потім перевіряє його з політикою Topology Manager, яка призводить до відхилення або допуску Podʼа.

Політики Topology Manager

Topology Manager підтримує чотири політики виділення. Ви можете встановити політику за допомогою прапорця Kubelet --topology-manager-policy. Існують чотири підтримувані політики:

  • none (стандартно)
  • best-effort
  • restricted
  • single-numa-node

Політика none

Це стандартна політика і вона не виконує жодного вирівнювання топології.

Політика best-effort

Для кожного контейнера у Pod kubelet з політикою керування топологією best-effort викликає кожен Hint Provider, щоб дізнатися їхню доступність ресурсів. Використовуючи цю інформацію, Topology Manager зберігає привʼязку до найближчого вузла NUMA для цього контейнера. Якщо привʼязка не є бажаною, Topology Manager також зберігає це і допускає Pod до вузла не зважаючи на це.

Hint Providers можуть використовувати цю інформацію при прийнятті рішення про розподіл ресурсів.

Політика restricted

Для кожного контейнера у Pod kubelet з політикою керування топологією restricted викликає кожен Hint Provider, щоб дізнатися їхню доступність ресурсів. Використовуючи цю інформацію, Topology Manager зберігає привʼязку до вузла NUMA для цього контейнера. Якщо привʼязка не є бажаною, Topology Manager відхиляє Pod від вузла. Це призводить до того, що Pod перебуває в стані Terminated з помилкою допуску Podʼа.

Якщо Pod перебуває в стані Terminated, планувальник Kubernetes не буде намагатися знову запланувати його. Рекомендується використовувати ReplicaSet або Deployment для того, щоб викликати повторне розгортання Podʼа. Зовнішній цикл керування також може бути реалізований для того, щоб викликати повторне розгортання Podʼів, які мають помилку Topology Affinity.

Якщо Pod прийнято, Hint Providers можуть використовувати цю інформацію при прийнятті рішення про розподіл ресурсів.

Політика single-numa-node

Для кожного контейнера у Pod kubelet з політикою керування топологією single-numa-node викликає кожен Hint Provider, щоб дізнатися їхню доступність ресурсів. Використовуючи цю інформацію, Topology Manager визначає, чи можлива привʼязка до одного вузла NUMA. Якщо можливо, Topology Manager зберігає це і Hint Providers можуть використовувати цю інформацію при прийнятті рішення про розподіл ресурсів. Якщо привʼязка не можлива, Topology Manager відхиляє Pod від вузла. Це призводить до того, що Pod перебуває в стані Terminated з помилкою прийняття Podʼа.

Якщо Pod перебуває в стані Terminated, планувальник Kubernetes не буде намагатися знову запланувати його. Рекомендується використовувати ReplicaSet або Deployment для того, щоб викликати повторне розгортання Podʼа. Зовнішній цикл керування також може бути реалізований для того, щоб викликати повторне розгортання Podʼів, які мають помилку Topology Affinity.

Параметри політики керування топологією

Підтримка параметрів політики керування топологією вимагає активації функціональної можливоітсі TopologyManagerPolicyOptions, щоб бути ввімкненими (типово увімкнено).

Ви можете увімкнути та вимкнути групи параметрів на основі їхнього рівня зрілості за допомогою наступних feature gate:

  • TopologyManagerPolicyBetaOptions типово увімкнено. Увімкніть, щоб показати параметри рівня бета.
  • TopologyManagerPolicyAlphaOptions типово вимкнено. Увімкніть, щоб показати параметри рівня альфа.

Ви все ще повинні активувати кожний параметр за допомогою опції kubelet TopologyManagerPolicyOptions.

prefer-closest-numa-nodes (бета)

Опція prefer-closest-numa-nodes є бета-функцією з версії Kubernetes 1.28. У версії Kubernetes 1.31 ця політика стандартно доступна, якщо увімкнено функціональні можливості TopologyManagerPolicyOptions та TopologyManagerPolicyBetaOptions.

Типово менеджер топології не враховує відстані між NUMA вузлами та не бере їх до уваги при прийнятті рішень про допуск Pod. Це обмеження проявляється в системах з кількома сокетами, а також у системах з одним сокетом і кількома NUMA вузлами, і може спричинити значне погіршення продуктивності у виконанні з критичною затримкою та високим пропуском даних, якщо менеджер топології вирішить розмістити ресурси на не сусідніх NUMA вузлах.

Якщо вказано параметр політики prefer-closest-numa-nodes, політики best-effort та restricted будуть віддавати перевагу наборам вузлів NUMA з коротшими відстанями між ними при прийнятті рішень про прийняття.

Стандартно (без цієї опції) менеджер топології розміщує ресурси або на одному NUMA вузлі, або, у випадку, коли потрібно більше одного NUMA вузла, використовує мінімальну кількість NUMA вузлів.

max-allowable-numa-nodes (бета)

Опція max-allowable-numa-nodes є бета-функцією з версії Kubernetes 1.31. У версії Kubernetes 1.31 ця політика стандартно доступна, якщо увімкнено функціональні можливості TopologyManagerPolicyOptions та TopologyManagerPolicyBetaOptions.

Час на прийняття Podʼа повʼязаний з кількістю NUMA вузлів на фізичній машині. стандартно, Kubernetes не запускає kubelet з увімкненим менеджером топології на жодному (Kubernetes) вузлі, де виявлено більше ніж 8 NUMA вузлів.

Ви можете увімкнути цю опцію, додавши max-allowable-numa-nodes=true до параметрів політики Topology Manager.

Встановлення значення max-allowable-numa-nodes не впливає безпосередньо на затримку допуску Pod, але привʼязка Pod до вузла (Kubernetes) з великою кількістю NUMA вузлів має вплив. Майбутні можливі поліпшення в Kubernetes можуть покращити продуктивність допуску Podʼів і зменшити високу затримку, яка виникає зі збільшенням кількості NUMA вузлів.

Взаємодія точок доступу Pod з політиками Topology Manager

Розгляньте контейнери у наступному маніфесті Podʼа:

spec:
  containers:
  - name: nginx
    image: nginx

Цей Pod працює в класі QoS BestEffort, оскільки не вказано жодних ресурсів requests або limits.

spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        memory: "200Mi"
      requests:
        memory: "100Mi"

Цей Pod працює в класі QoS Burstable, оскільки запити менше, ніж ліміти.

Якщо вибрана політика відрізняється від none, Topology Manager враховуватиме ці специфікації Pod. Topology Manager буде консультувати Hint Provider для отримання підказок топології. У випадку static політики CPU Manager поверне типову підказку топології, оскільки ці Podʼи не мають явних запитів ресурсів CPU.

spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        memory: "200Mi"
        cpu: "2"
        example.com/device: "1"
      requests:
        memory: "200Mi"
        cpu: "2"
        example.com/device: "1"

Цей Pod із цілим запитом CPU працює в класі QoS Guaranteed, оскільки requests дорівнює limits.

spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        memory: "200Mi"
        cpu: "300m"
        example.com/device: "1"
      requests:
        memory: "200Mi"
        cpu: "300m"
        example.com/device: "1"

Цей Pod з спільним запитом CPU працює в класі QoS Guaranteed, оскільки requests дорівнює limits.

spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        example.com/deviceA: "1"
        example.com/deviceB: "1"
      requests:
        example.com/deviceA: "1"
        example.com/deviceB: "1"

Цей Pod працює в класі QoS BestEffort, оскільки немає запитів CPU та памʼяті.

Topology Manager враховуватиме вищезазначені Podʼи. Topology Manager буде консультувати Hint Provider, які є CPU та Device Manager, для отримання підказок топології для Pod.

У випадку Guaranteed Pod із цілим запитом CPU, політика CPU Manager static поверне підказки топології, що стосуються виключно CPU, а Device Manager надішле підказки для запитаного пристрою.

У випадку Guaranteed Pod з спільним запитом CPU, політика CPU Manager static поверне типову підказку топології, оскільки немає виключного запиту CPU, а Device Manager надішле підказки для запитаних пристроїв.

У вищезазначених двох випадках Guaranteed Pod політика CPU Manager none поверне типову підказку топології.

У випадку BestEffort Pod, політика CPU Manager static поверне типову підказку топології, оскільки немає запиту CPU, а Device Manager надішле підказки для кожного запитаного пристрою.

На основі цієї інформації Topology Manager обчислить оптимальну підказку для Pod і збереже цю інформацію, яка буде використовуватися постачальниками підказок при призначенні ресурсів.

Відомі обмеження

  1. Максимальна кількість вузлів NUMA, яку дозволяє Topology Manager, — 8. З більш ніж 8 вузлами NUMA відбудеться вибух стану при спробі перерахувати можливі спорідненості NUMA та генерувати їх підказки. Дивіться max-allowable-numa-nodes (бета) для отримання додаткової інформації.

  2. Планувальник не знає топології, тому його можна запланувати на вузлі, а потім вивести з ладу на вузлі через Topology Manager.

4.2.18 - Налаштування служби DNS

На цій сторінці пояснюється, як налаштувати ваші DNS Pod та настроїти процес розвʼязання імен DNS у вашому кластері.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Ваш кластер повинен працювати з надбудовою CoreDNS.

Версія вашого Kubernetes сервера має бути не старішою ніж v1.12. Для перевірки версії введіть kubectl version.

Вступ

DNS — це вбудована служба Kubernetes, яка автоматично запускається з допомогою менеджера надбудов cluster add-on.

Якщо ви працюєте з CoreDNS як з Deployment, його зазвичай викладають як Service Kubernetes зі статичною IP-адресою. Kubelet передає інформацію про резолвер DNS кожному контейнеру з прапорцем --cluster-dns=<ір-адреса-dns-служби>.

DNS-імена також потребують доменів. Ви налаштовуєте локальний домен в kubelet з прапорцем --cluster-domain=<типовий-локальний-домен>.

DNS-сервер підтримує прямий пошук (записи A та AAAA), пошук портів (записи SRV), зворотній пошук IP-адрес (записи PTR) та інші. Для отримання додаткової інформації дивіться DNS для Service та Pod.

Якщо для Pod dnsPolicy встановлено значення default, він успадковує конфігурацію розвʼязку імен від вузла, на якому працює Pod. Розвʼязок імен Pod повинен поводитися так само як і на вузлі. Проте див. Відомі проблеми.

Якщо вам це не потрібно, або якщо ви хочете іншу конфігурацію DNS для Podʼів, ви можете використовувати прапорець --resolv-conf kubelet. Встановіть цей прапорець у "" для того, щоб запобігти успадкуванню DNS від Podʼів. Встановіть його на дійсний шлях до файлу, щоб вказати файл, відмінний від /etc/resolv.conf для успадкування DNS.

CoreDNS

CoreDNS — це універсальний авторитетний DNS-сервер, який може служити як кластерний DNS, відповідаючи специфікаціям DNS.

Опції ConfigMap CoreDNS

CoreDNS — це DNS-сервер, який є модульним та розширюваним, з допомогою втулків, які додають нові можливості. Сервер CoreDNS може бути налаштований за допомогою збереження Corefile, який є файлом конфігурації CoreDNS. Як адміністратор кластера, ви можете змінювати ConfigMap для Corefile CoreDNS для зміни того, як поводитися служба виявлення служби DNS для цього кластера.

У Kubernetes CoreDNS встановлюється з наступною стандартною конфігурацією Corefile:

apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns
  namespace: kube-system
data:
  Corefile: |
    .:53 {
        errors
        health {
            lameduck 5s
        }
        ready
        kubernetes cluster.local in-addr.arpa ip6.arpa {
            pods insecure
            fallthrough in-addr.arpa ip6.arpa
            ttl 30
        }
        prometheus :9153
        forward . /etc/resolv.conf
        cache 30
        loop
        reload
        loadbalance
    }    

Конфігурація Corefile включає наступні втулки CoreDNS:

  • errors: Помилки реєструються в stdout.
  • health: Справність CoreDNS повідомляється за адресою http://localhost:8080/health. У цьому розширеному синтаксисі lameduck зробить процес несправним, а потім зачекає 5 секунд, перш ніж процес буде вимкнено.
  • ready: HTTP-точка на порту 8181 поверне 200 ОК, коли всі втулки, які можуть сигналізувати готовність, зроблять це.
  • kubernetes: CoreDNS відповість на DNS-запити на основі IP-адрес Service та Pod. Ви можете знайти більше деталей про цей втулок на вебсайті CoreDNS.
    • ttl дозволяє встановити власний TTL для відповідей. Стандартно — 5 секунд. Мінімальний дозволений TTL — 0 секунд, а максимальний обмежений 3600 секундами. Встановлення TTL на 0 запобіжить кешуванню записів.
    • Опція pods insecure надається для сумісності з kube-dns.
    • Ви можете використовувати опцію pods verified, яка поверне запис A лише у випадку, якщо існує Pod в тому ж просторі імен зі потрібним IP.
    • Опцію pods disabled можна використовувати, якщо ви не використовуєте записи Podʼів.
  • prometheus: Метрики CoreDNS доступні за адресою http://localhost:9153/metrics у форматі Prometheus (також відомий як OpenMetrics).
  • forward: Будь-які запити, які не належать до домену Kubernetes кластера, будуть переслані на попередньо визначені резолвери (/etc/resolv.conf).
  • cache: Це увімкнення кешу фронтенду.
  • loop: Виявлення простих переспрямовуваннь та припинення процесу CoreDNS у випадку виявлення циклу.
  • reload: Дозволяє автоматичне перезавантаження зміненого Corefile. Після редагування конфігурації ConfigMap дайте дві хвилини для того, щоб ваші зміни набули чинності.
  • loadbalance: Це round-robin DNS-балансувальник, який випадковим чином змінює порядок записів A, AAAA та MX в відповіді.

Ви можете змінити типову поведінку CoreDNS, змінивши ConfigMap.

Конфігурація Stub-домену та віддаленого сервера імен за допомогою CoreDNS

CoreDNS має можливість налаштувати stub-домени та віддалені сервери імен за допомогою втулку forward.

Приклад

Якщо оператор кластера має сервер домену Consul за адресою "10.150.0.1", і всі імена Consul мають суфікс ".consul.local". Для його налаштування в CoreDNS адміністратор кластера створює наступний запис в ConfigMap CoreDNS.

consul.local:53 {
    errors
    cache 30
    forward . 10.150.0.1
}

Щоб явно пересилати всі не-кластерні DNS-пошуки через конкретний сервер імен за адресою 172.16.0.1, вказуйте forward на сервер імен замість /etc/resolv.conf.

forward .  172.16.0.1

Кінцевий ConfigMap разом з типовою конфігурацією Corefile виглядає так:

apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns
  namespace: kube-system
data:
  Corefile: |
    .:53 {
        errors
        health
        kubernetes cluster.local in-addr.arpa ip6.arpa {
           pods insecure
           fallthrough in-addr.arpa ip6.arpa
        }
        prometheus :9153
        forward . 172.16.0.1
        cache 30
        loop
        reload
        loadbalance
    }
    consul.local:53 {
        errors
        cache 30
        forward . 10.150.0.1
    }    

Що далі

4.2.19 - Налагодження розвʼязання імен DNS

Ця сторінка надає вказівки щодо діагностування проблем DNS.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Ваш кластер повинен бути налаштований на використання надбудови CoreDNS або її попередника, kube-dns.

Версія вашого Kubernetes сервера має бути не старішою ніж v1.6. Для перевірки версії введіть kubectl version.

Створіть простий Pod для використання як тестове середовище

apiVersion: v1
kind: Pod
metadata:
  name: dnsutils
  namespace: default
spec:
  containers:
  - name: dnsutils
    image: registry.k8s.io/e2e-test-images/agnhost:2.39
    imagePullPolicy: IfNotPresent
  restartPolicy: Always

Використайте цей маніфест, щоб створити Pod:

kubectl apply -f https://k8s.io/examples/admin/dns/dnsutils.yaml
pod/dnsutils created

…і перевірте його статус:

kubectl get pods dnsutils
NAME       READY     STATUS    RESTARTS   AGE
dnsutils   1/1       Running   0          <some-time>

Після того, як цей Pod працює, ви можете виконати nslookup в цьому середовищі. Якщо ви бачите щось схоже на наступне, DNS працює правильно.

kubectl exec -i -t dnsutils -- nslookup kubernetes.default
Server:    10.0.0.10
Address 1: 10.0.0.10

Name:      kubernetes.default
Address 1: 10.0.0.1

Якщо команда nslookup не вдається, перевірте наступне:

Спочатку перевірте локальну конфігурацію DNS

Подивіться всередину файлу resolv.conf. (Див. Налаштування служби DNS та Відомі проблеми нижче для отримання додаткової інформації)

kubectl exec -ti dnsutils -- cat /etc/resolv.conf

Перевірте, що шлях пошуку та імʼя сервера налаштовані так, як показано нижче (зверніть увагу, що шлях пошуку може відрізнятися для різних постачальників хмарних послуг):

search default.svc.cluster.local svc.cluster.local cluster.local google.internal c.gce_project_id.internal
nameserver 10.0.0.10
options ndots:5

Помилки, такі як наведені нижче, вказують на проблему з CoreDNS (або kube-dns) або з повʼязаними службами:

kubectl exec -i -t dnsutils -- nslookup kubernetes.default
Server:    10.0.0.10
Address 1: 10.0.0.10

nslookup: can't resolve 'kubernetes.default'

або

kubectl exec -i -t dnsutils -- nslookup kubernetes.default
Server:    10.0.0.10
Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local

nslookup: can't resolve 'kubernetes.default'

Перевірте, чи працює Pod DNS

Використайте команду kubectl get pods, щоб перевірити, що Pod DNS працює.

kubectl get pods --namespace=kube-system -l k8s-app=kube-dns
NAME                       READY     STATUS    RESTARTS   AGE
...
coredns-7b96bf9f76-5hsxb   1/1       Running   0           1h
coredns-7b96bf9f76-mvmmt   1/1       Running   0           1h
...

Якщо ви бачите, що жоден Pod CoreDNS не працює або що Pod несправний/завершено, надбудова DNS може не бути типово розгорнута у вашому поточному середовищі та вам доведеться розгорнути його вручну.

Перевірка помилок у Podʼі DNS

Використайте команду kubectl logs, щоб переглянути логи контейнерів DNS.

Для CoreDNS:

kubectl logs --namespace=kube-system -l k8s-app=kube-dns

Ось приклад здорових журналів CoreDNS:

.:53
2018/08/15 14:37:17 [INFO] CoreDNS-1.2.2
2018/08/15 14:37:17 [INFO] linux/amd64, go1.10.3, 2e322f6
CoreDNS-1.2.2
linux/amd64, go1.10.3, 2e322f6
2018/08/15 14:37:17 [INFO] plugin/reload: Running configuration MD5 = 24e6c59e83ce706f07bcc82c31b1ea1c

Перегляньте, чи є будь-які підозрілі або несподівані повідомлення у логах.

Чи працює служба DNS?

Перевірте, чи працює служба DNS за допомогою команди kubectl get service.

kubectl get svc --namespace=kube-system
NAME         TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)             AGE
...
kube-dns     ClusterIP   10.0.0.10      <none>        53/UDP,53/TCP        1h
...

Якщо ви створили Service або у випадку, якщо вона повинна типово створюватися, але вона не зʼявляється, див. налагодження Service для отримання додаткової інформації.

Чи відкриті точки доступу DNS?

Ви можете перевірити, чи викриті точки доступу DNS, використовуючи команду kubectl get endpoints.

kubectl get endpoints kube-dns --namespace=kube-system
NAME       ENDPOINTS                       AGE
kube-dns   10.180.3.17:53,10.180.3.17:53    1h

Якщо ви не бачите точки доступу, дивіться розділ про точки доступу у документації налагодження Service.

Для додаткових прикладів DNS Kubernetes дивіться приклади dns в кластері у репозиторії Kubernetes GitHub.

Чи надходять/обробляються DNS-запити?

Ви можете перевірити, чи надходять запити до CoreDNS, додавши втулок log до конфігурації CoreDNS (тобто файлу Corefile). Файл CoreDNS Corefile зберігається у ConfigMap з назвою coredns. Щоб редагувати його, використовуйте команду:

kubectl -n kube-system edit configmap coredns

Потім додайте log у розділ Corefile, як показано у прикладі нижче:

apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns
  namespace: kube-system
data:
  Corefile: |
    .:53 {
        log
        errors
        health
        kubernetes cluster.local in-addr.arpa ip6.arpa {
          pods insecure
          upstream
          fallthrough in-addr.arpa ip6.arpa
        }
        prometheus :9153
        forward . /etc/resolv.conf
        cache 30
        loop
        reload
        loadbalance
    }    

Після збереження змін може знадобитися до хвилини або двох, щоб Kubernetes поширив ці зміни на Podʼи CoreDNS.

Далі зробіть кілька запитів і перегляньте логи, як показано у попередніх розділах цього документа. Якщо Podʼи CoreDNS отримують запити, ви повинні побачити їх в логах.

Ось приклад запиту у логах:

.:53
2018/08/15 14:37:15 [INFO] CoreDNS-1.2.0
2018/08/15 14:37:15 [INFO] linux/amd64, go1.10.3, 2e322f6
CoreDNS-1.2.0
linux/amd64, go1.10.3, 2e322f6
2018/09/07 15:29:04 [INFO] plugin/reload: Running configuration MD5 = 162475cdf272d8aa601e6fe67a6ad42f
2018/09/07 15:29:04 [INFO] Reloading complete
172.17.0.18:41675 - [07/Sep/2018:15:29

:11 +0000] 59925 "A IN kubernetes.default.svc.cluster.local. udp 54 false 512" NOERROR qr,aa,rd,ra 106 0.000066649s

Чи має CoreDNS достатні дозволи?

CoreDNS повинен мати можливість переглядати повʼязані Service та endpoint ресурси для правильного розпізнавання імен служб.

Приклад повідомлення про помилку:

2022-03-18T07:12:15.699431183Z [INFO] 10.96.144.227:52299 - 3686 "A IN serverproxy.contoso.net.cluster.local. udp 52 false 512" SERVFAIL qr,aa,rd 145 0.000091221s

Спочатку отримайте поточну ClusterRole system:coredns:

kubectl describe clusterrole system:coredns -n kube-system

Очікуваний вивід:

PolicyRule:
  Resources                        Non-Resource URLs  Resource Names  Verbs
  ---------                        -----------------  --------------  -----
  endpoints                        []                 []              [list watch]
  namespaces                       []                 []              [list watch]
  pods                             []                 []              [list watch]
  services                         []                 []              [list watch]
  endpointslices.discovery.k8s.io  []                 []              [list watch]

Якщо відсутні будь-які дозволи, відредагуйте ClusterRole, щоб додати їх:

kubectl edit clusterrole system:coredns -n kube-system

Приклад вставки дозволів для EndpointSlices:

...
- apiGroups:
  - discovery.k8s.io
  resources:
  - endpointslices
  verbs:
  - list
  - watch
...

Чи ви у правильному просторі імен для служби?

DNS-запити, які не вказують простір імен, обмежені простором імен Podʼа.

Якщо простір імен Podʼа та Service відрізняються, DNS-запит повинен включати простір імен Service.

Цей запит обмежений простором імен Podʼа:

kubectl exec -i -t dnsutils -- nslookup <service-name>

Цей запит вказує простір імен:

kubectl exec -i -t dnsutils -- nslookup <service-name>.<namespace>

Щоб дізнатися більше про розпізнавання імен, дивіться DNS для Service та Pod.

Відомі проблеми

Деякі дистрибутиви Linux (наприклад, Ubuntu) стандартно використовують локальний резолвер DNS (systemd-resolved). Systemd-resolved переміщує та замінює /etc/resolv.conf на файл-заглушку, що може спричинити фатальний цикл переспрямовування при розпізнаванні імен на вихідних серверах. Це можна виправити вручну, використовуючи прапорець --resolv-conf kubelet, щоб вказати правильний resolv.confsystemd-resolved це /run/systemd/resolve/resolv.conf). kubeadm автоматично визначає systemd-resolved та налаштовує відповідні прапорці kubelet.

Установки Kubernetes не налаштовують файли resolv.conf вузлів для використання кластерного DNS стандартно, оскільки цей процес властивий для певного дистрибутиву. Це, можливо, має бути реалізовано надалі.

У Linux бібліотека libc (відома як glibc) має обмеження для записів nameserver DNS на 3 стандартно, і Kubernetes потрібно використовувати 1 запис nameserver. Це означає, що якщо локальна установка вже використовує 3 nameserver, деякі з цих записів будуть втрачені. Щоб обійти це обмеження, вузол може запускати dnsmasq, який надасть більше записів nameserver. Ви також можете використовувати прапорець --resolv-conf kubelet.

Якщо ви використовуєте Alpine версії 3.17 або раніше як базовий образ, DNS може працювати неправильно через проблему з дизайном Alpine. До версії musl 1.24 не включено резервне перемикання на TCP для stub-резолвера DNS, що означає, що будь-який виклик DNS понад 512 байтів завершиться невдачею. Будь ласка, оновіть свої образи до версії Alpine 3.18 або вище.

Що далі

4.2.20 - Оголошення мережевої політики

Цей документ допоможе вам розпочати використання API мережевої політики Kubernetes NetworkPolicy API, щоб оголосити політики мережі, які керують тим, як Podʼи спілкуються один з одним.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Версія вашого Kubernetes сервера має бути не старішою ніж v1.8. Для перевірки версії введіть kubectl version.

Переконайтеся, що ви налаштували постачальника мережі з підтримкою політики мережі. Існує кілька постачальників мережі, які підтримують NetworkPolicy, включаючи:

Створення nginx deployment та надання доступу через Service

Щоб переглянути, як працює політика мережі Kubernetes, почніть зі створення Deployment nginx.

kubectl create deployment nginx --image=nginx
deployment.apps/nginx created

Експонуйте Deployment через Service під назвою nginx.

kubectl expose deployment nginx --port=80
service/nginx exposed

Вищезазначені команди створюють Deployment з Podʼом nginx і експонують Deployment через Service під назвою nginx. Pod nginx та Deployment знаходяться в просторі імен default.

kubectl get svc,pod
NAME                        CLUSTER-IP    EXTERNAL-IP   PORT(S)    AGE
service/kubernetes          10.100.0.1    <none>        443/TCP    46m
service/nginx               10.100.0.16   <none>        80/TCP     33s

NAME                        READY         STATUS        RESTARTS   AGE
pod/nginx-701339712-e0qfq   1/1           Running       0          35s

Перевірте роботу Service, звернувшись до неї з іншого Podʼа

Ви повинні мати можливість звернутися до нового Service nginx з інших Podʼів. Щоб отримати доступ до Service nginx з іншого Podʼа в просторі імен default, запустіть контейнер busybox:

kubectl run busybox --rm -ti --image=busybox:1.28 -- /bin/sh

У вашій оболонці запустіть наступну команду:

wget --spider --timeout=1 nginx
Connecting to nginx (10.100.0.16:80)
remote file exists

Обмеження доступу до Service nginx

Щоб обмежити доступ до Service nginx так, щоб запити до неї могли робити лише Podʼи з міткою access: true, створіть обʼєкт NetworkPolicy наступним чином:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: access-nginx
spec:
  podSelector:
    matchLabels:
      app: nginx
  ingress:
  - from:
    - podSelector:
        matchLabels:
          access: "true"

Назва обʼєкта NetworkPolicy повинна бути дійсним піддоменом DNS.

Назначте політику для Service

Використовуйте kubectl для створення NetworkPolicy з файлу nginx-policy.yaml вище:

kubectl apply -f https://k8s.io/examples/service/networking/nginx-policy.yaml
networkpolicy.networking.k8s.io/access-nginx created

Перевірте доступ до Service, коли мітка доступу не визначена

Коли ви намагаєтеся отримати доступ до Service nginx з Podʼа без відповідних міток, запит завершується тайм-аутом:

kubectl run busybox --rm -ti --image=busybox:1.28 -- /bin/sh

У вашій оболонці виконайте команду:



wget --spider --timeout=1 nginx
Connecting to nginx (10.100.0.16:80)
wget: download timed out

Визначте мітку доступу і перевірте знову

Ви можете створити Pod із відповідними мітками, щоб переконатися, що запит дозволено:

kubectl run busybox --rm -ti --labels="access=true" --image=busybox:1.28 -- /bin/sh

У вашій оболонці запустіть команду:

wget --spider --timeout=1 nginx
Connecting to nginx (10.100.0.16:80)
remote file exists

4.2.21 - Розробка Cloud Controller Manager

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.11 [beta]

Cloud Controller Manager (cloud-controller-manager) є компонент панелі управління Kubernetes, що інтегрує управління логікою певної хмари. Cloud controller manager дозволяє звʼязувати ваш кластер з API хмарного провайдера та відокремлює компоненти, що взаємодіють з хмарною платформою від компонентів, які взаємодіють тільки в кластері.

Відокремлюючи логіку сумісності між Kubernetes і базовою хмарною інфраструктурою, компонент cloud-controller-manager дає змогу хмарним провайдерам випускати функції з іншою швидкістю порівняно з основним проєктом Kubernetes.

Контекст

Оскільки постачальники хмар розвиваються та випускаються іншим темпом порівняно з проєктом Kubernetes, абстрагування специфічного для постачальників коду в окремий бінарний файл cloud-controller-manager дозволяє хмарним постачальникам еволюціонувати незалежно від основного коду Kubernetes.

Проєкт Kubernetes надає кістяк коду cloud-controller-manager з інтерфейсами Go, щоб дозволити вам (або вашому постачальнику хмар) додати свої власні реалізації. Це означає, що постачальник хмар може реалізувати cloud-controller-manager, імпортуючи пакунки з ядра Kubernetes; кожен постачальник хмар буде реєструвати свій власний код, викликаючи cloudprovider.RegisterCloudProvider, щоб оновити глобальну змінну доступних постачальників хмар.

Розробка

Зовнішня реалізація

Для створення зовнішнього cloud-controller-manager для вашої хмари:

  1. Створіть пакунок Go з реалізацією, яка задовольняє cloudprovider.Interface.
  2. Використовуйте main.go у cloud-controller-managerр з ядра Kubernetes як шаблон для свого main.go. Як зазначено вище, єдина відмінність полягатиме у пакунку хмари, який буде імпортуватися.
  3. Імпортуйте свій пакунок хмари в main.go, переконайтеся, що ваш пакунок має блок init для запуску cloudprovider.RegisterCloudProvider.

Багато постачальників хмар публікують свій код контролера як відкритий код. Якщо ви створюєте новий cloud-controller-manager з нуля, ви можете взяти наявний зовнішній cloud-controller-manager як вашу вихідну точку.

У коді Kubernetes

Для внутрішніх постачальників хмар ви можете запустити cloud-controller-managerу, що працює у внутрішньому коді, як DaemonSet у вашому кластері. Див. Адміністрування Cloud Controller Manager для отримання додаткової інформації.

4.2.22 - Увімкнення або вимкнення API Kubernetes

На цій сторінці показано, як увімкнути або вимкнути версію API зі вузла панелі управління вашого кластера.

Конкретні версії API можна увімкнути або вимкнути, передаючи --runtime-config=api/<version> як аргумент командного рядка до сервера API. Значення для цього аргументу є розділеним комами списком версій API. Пізніші значення перекривають попередні.

Аргумент командного рядка runtime-config також підтримує 2 спеціальні ключі:

  • api/all, що представляє всі відомі API.
  • api/legacy, що представляє лише застарілі API. Застарілі API — це будь-які API, які були явно визнані застарілими.

Наприклад, щоб вимкнути всі версії API, крім v1, передайте --runtime-config=api/all=false,api/v1=true до kube-apiserver.

Що далі

Прочитайте повну документацію для компонента kube-apiserver.

4.2.23 - Шифрування конфіденційних даних у спокої

Усі API в Kubernetes, які дозволяють записувати постійні дані ресурсів API, підтримують шифрування у спокої. Наприклад, ви можете увімкнути шифрування у спокої для Secret. Це шифрування у спокої є додатковим до будь-якого шифрування на рівні системи для кластера etcd або для файлових систем на вузлах, де ви запускаєте kube-apiserver.

На цій сторінці показано, як увімкнути та налаштувати шифрування даних API у спокої.

Перш ніж ви розпочнете

  • Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

  • Це завдання передбачає, що ви запускаєте сервер API Kubernetes як статичний Pod на кожному вузлі панелі управління.

  • Панель управління кластера обовʼязково має використовувати etcd версії 3.x (головна версія 3, будь-яка мінорна версія).

  • Для шифрування власного ресурсу ваш кластер повинен працювати на Kubernetes v1.26 або новіше.

  • Щоб використовувати символ підстановки для відповідності ресурсів, ваш кластер повинен працювати на Kubernetes v1.27 або новіше.

Для перевірки версії введіть kubectl version.

Визначте, чи вже увімкнено шифрування у спокої

Стандартно, сервер API зберігає текстові представлення ресурсів у etcd без шифрування у спокої.

Процес kube-apiserver приймає аргумент --encryption-provider-config, який вказує шлях до конфігураційного файлу. Зміст цього файлу, якщо ви його вказали, контролює спосіб шифрування даних API Kubernetes у etcd. Якщо ви запускаєте kube-apiserver без аргументу командного рядка --encryption-provider-config, то у вас немає увімкненого шифрування у спокої. Якщо ви запускаєте kube-apiserver з аргументом командного рядка --encryption-provider-config, і файл, на який він посилається, вказує на постачальника шифрування identity як першого постачальника шифрування у списку, то у вас немає увімкненого шифрування у спокої (типовий постачальник identity не надає захисту конфіденційності.)

Якщо ви запускаєте kube-apiserver з аргументом командного рядка --encryption-provider-config, і файл, на який він посилається, вказує на іншого постачальника, а не identity, як першого постачальника шифрування у списку, то ви вже маєте увімкнене шифрування у спокої. Однак ця перевірка не показує, чи вдалася попередня міграція до зашифрованого сховища. Якщо ви не впевнені, переконайтеся, що всі відповідні дані зашифровані.

Розуміння конфігурації шифрування у спокої

---
#
# УВАГА: це приклад конфігурації.
# Не використовуйте його для вашого кластера!
#
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
      - configmaps
      - pandas.awesome.bears.example # a custom resource API
    providers:
      # Ця конфігурація не забезпечує конфіденційність даних. Перший
      # налаштований постачальник вказує механізм "identity", який
      # зберігає ресурси як простий текст.
      #
      - identity: {} # простий текст, іншими словами, шифрування НЕМАЄ
      - aesgcm:
          keys:
            - name: key1
              secret: c2VjcmV0IGlzIHNlY3VyZQ==
            - name: key2
              secret: dGhpcyBpcyBwYXNzd29yZA==
      - aescbc:
          keys:
            - name: key1
              secret: c2VjcmV0IGlzIHNlY3VyZQ==
            - name: key2
              secret: dGhpcyBpcyBwYXNzd29yZA==
      - secretbox:
          keys:
            - name: key1
              secret: YWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXoxMjM0NTY=
  - resources:
      - events
    providers:
      - identity: {} # не шифрувати Events навіть якщо *.* вказаний нижче
  - resources:
      - '*.apps' # використання символу підстановки потребує Kubernetes 1.27 або пізніше
    providers:
      - aescbc:
          keys:
          - name: key2
            secret: c2VjcmV0IGlzIHNlY3VyZSwgb3IgaXMgaXQ/Cg==
  - resources:
      - '*.*' # використання символу підстановки потребує Kubernetes 1.27 або пізніше
    providers:
      - aescbc:
          keys:
          - name: key3
            secret: c2VjcmV0IGlzIHNlY3VyZSwgSSB0aGluaw==

Кожен елемент масиву resources — це окрема конфігурація і містить повну конфігурацію. Поле resources.resources — це масив імен ресурсів Kubernetes (resource або resource.group), які мають бути зашифровані, наприклад, Secrets, ConfigMaps або інші ресурси.

Якщо ви додаєте власні ресурси до EncryptionConfiguration, і версія кластера — 1.26 або новіша, то будь-які нові створені власні ресурси, зазначені в EncryptionConfiguration, будуть зашифровані. Будь-які власні ресурси, які існували в etcd до цієї версії та конфігурації, залишаться незашифрованими до тих пір, поки вони наступного разу не будуть записані у сховище. Така ж поведінка застосовується й до вбудованих ресурсів. Дивіться розділ Переконайтеся, що всі секрети зашифровані.

Масив providers — це упорядкований список можливих постачальників шифрування, які можна використовувати для перелічених вами API. Кожен постачальник підтримує кілька ключів — ключі перевіряються по черзі для розшифрування, і якщо постачальник є першим, перший ключ використовується для шифрування.

Для кожного елементу може бути вказано лише один тип постачальника (identity або aescbc може бути наданий, але не обидва в одному елементі). Перший постачальник у списку використовується для шифрування ресурсів, записаних у сховище. При читанні ресурсів зі сховища кожен постачальник, який відповідає збереженим даним, намагається по черзі розшифрувати дані. Якщо жоден постачальник не може прочитати збережені дані через несумісність формату або секретного ключа, повертається помилка, яка перешкоджає клієнтам отримати доступ до цього ресурсу.

EncryptionConfiguration підтримує використання символів підстановки для вказівки ресурсів, які мають бути зашифровані. Використовуйте '*.<group>', щоб зашифрувати всі ресурси у групі (наприклад, '*.apps' у вищезазначеному прикладі) або '*.*' для шифрування всіх ресурсів. '*.' може бути використаний для шифрування всіх ресурсів у групі ядра. '*.*' зашифрує всі ресурси, навіть власні ресурси, які додаються після запуску сервера API.

Якщо у вас є символ підстановки, який охоплює ресурси, і ви хочете відмовитися від шифрування у спокої певного типу ресурсу, ви можете досягати цього, додавши окремий елемент масиву resources з іменем ресурсу, який ви хочете виключити, за яким слідує елемент масиву providers, де ви вказуєте постачальника identity. Ви додаєте цей елемент до списку так, щоб він зʼявився раніше, ніж конфігурація, де ви вказуєте шифрування (постачальник, який не є identity).

Наприклад, якщо ввімкнено '*.*', і ви хочете відмовитися від шифрування для Events та ConfigMaps, додайте новий раніший елемент до resources, за яким слідує елемент масиву постачальників з identity як постачальник. Більш конкретний запис повинен зʼявитися перед записом з символом підстановки.

Новий елемент буде схожий на:

  ...
  - resources:
      - configmaps. # спеціально з ядра API групи,
                    # через крапку в кінці
      - events
    providers:
      - identity: {}
  # а потім інші записи в resources

Переконайтеся, що виключення перераховане до позначки символу підстановки '*.*' в масиві ресурсів, щоб надати йому пріоритет.

Для отримання більш детальної інформації про структуру EncryptionConfiguration, зверніться до API конфігурації шифрування.

Доступні постачальники

Перш ніж налаштувати шифрування у спокої для даних у Kubernetes API вашого кластера, вам потрібно вибрати, які постачальники ви будете використовувати.

Наступна таблиця описує кожного доступного постачальника.

Постачальники для шифрування у спокої Kubernetes
НазваШифруванняСтійкістьШвидкістьДовжина ключа
identityВідсутнєН/ДН/ДН/Д
Ресурси зберігаються як є без шифрування. Коли встановлено як перший постачальник, ресурс буде розшифрований при записі нових значень. Існуючі зашифровані ресурси автоматично не перезаписуються даними у відкритому тексті. Постачальник `identity` є типовим, якщо ви не вказали інше.
aescbcAES-CBC з використанням padding PKCS#7СлабкаШвидка32 байти
Не рекомендується через вразливість CBC до атаки padding oracle attacks. Вміст ключа доступний з хоста панелі управління.
aesgcmAES-GCM з випадковим нонсомПотрібно оновлювати через кожні 200,000 записівНайшвидший16, 24 або 32 байти
Не рекомендується для використання, крім як у випадку, коли реалізована автоматизована схема оновлення ключів. Вміст ключа доступний з хоста панелі управління.
kms v1 (застарілий з Kubernetes v1.28)Використовує схему шифрування конвертів із DEK для кожного ресурсу.НайміцнішийПовільний (порівняно з kms версією 2)32 байти
Дані шифруються за допомогою ключів шифрування даних (DEK) з використанням AES-GCM; DEK шифруються ключами шифрування ключів (KEKs) згідно з конфігурацією в Службі управління ключами (KMS). Просте оновлення ключа, з новим DEK, що генерується для кожного шифрування, та оновлення KEK, контрольоване користувачем.
Прочитайте, як налаштувати постачальника KMS V1.
kms v2Використовує схему шифрування конвертів із DEK для кожного сервера API.НайміцнішийШвидкий32 байти
Дані шифруються за допомогою ключів шифрування даних (DEKs) з використанням AES-GCM; DEKs шифруються ключами шифрування ключів (KEKs) згідно з конфігурацією в Службі управління ключами (KMS). Kubernetes генерує новий DEK для кожного шифрування з секретного насіння. Насіння змінюється кожного разу, коли змінюється KEK.
Добрий вибір, якщо використовується сторонній інструмент для управління ключами. Доступний як стабільний з Kubernetes v1.29.
Прочитайте, як налаштувати постачальника KMS V2.
secretboxXSalsa20 і Poly1305НайміцнішийШвидший32 байти
Використовує відносно нові технології шифрування, які можуть не бути прийнятними в середовищах, які вимагають високого рівня перегляду. Вміст ключа доступний з хоста панелі управління.

Постачальник identity є типовим, якщо ви не вказали інше. Постачальник identity не шифрує збережені дані та не надає жодного додаткового захисту конфіденційності.

Зберігання ключів

Локальне зберігання ключів

Шифрування конфіденційних даних за допомогою локально керованих ключів захищає від компрометації etcd, але не забезпечує захисту від компрометації хосту. Оскільки ключі шифрування зберігаються на хості у файлі EncryptionConfiguration YAML, кваліфікований зловмисник може отримати доступ до цього файлу і витягнути ключі шифрування.

Зберігання ключів сервісом KMS

Постачальник KMS використовує шифрування конвертів: Kubernetes шифрує ресурси за допомогою ключа даних, а потім шифрує цей ключ даних за допомогою служби керування шифруванням. Kubernetes генерує унікальний ключ даних для кожного ресурсу. API-сервер зберігає зашифровану версію ключа даних в etcd поряд із шифротекстом; при читанні ресурсу API-сервер викликає служби керування шифруванням і надає як шифротекст, так і (зашифрований) ключ даних. У межах служби керування шифруванням, постачальник використовує ключ шифрування ключа, щоб розшифрувати ключ даних, розшифровує ключ даних і, нарешті, відновлює звичайний текст. Комунікація між панеллю управління та KMS вимагає захисту під час передачі, такого як TLS.

Використання шифрування конвертів створює залежність від ключа шифрування ключа, який не зберігається в Kubernetes. У випадку KMS зловмиснику, який намагається отримати несанкціонований доступ до значень у відкритому тексті, необхідно скомпрометувати etcd та стороннього постачальника KMS.

Захист для ключів шифрування

Вам слід прийняти належні заходи для захисту конфіденційної інформації, що дозволяє розшифрування, чи то це локальний ключ шифрування, чи то токен автентифікації, який дозволяє API-серверу викликати KMS.

Навіть коли ви покладаєтесь на постачальника для керування використанням та життєвим циклом основного ключа шифрування (або ключів), ви все одно відповідаєте за те, щоб контроль доступу та інші заходи безпеки для служби керування шифруванням були відповідними для ваших потреб у безпеці.

Зашифруйте ваші дані

Згенеруйте ключ шифрування

Наступні кроки передбачають, що ви не використовуєте KMS, тому кроки також передбачають, що вам потрібно згенерувати ключ шифрування. Якщо у вас вже є ключ шифрування, перейдіть до Написання файлу конфігурації шифрування.

Розпочніть з генерації нового ключа шифрування, а потім закодуйте його за допомогою base64:

Згенеруйте випадковий ключ з 32 байтів і закодуйте його у форматі base64. Ви можете використовувати цю команду:

head -c 32 /dev/urandom | base64

Ви можете використовувати /dev/hwrng замість /dev/urandom, якщо ви хочете використовувати вбудований апаратний генератор ентропії вашого ПК. Не всі пристрої з Linux надають апаратний генератор випадкових чисел.

Згенеруйте випадковий ключ з 32 байтів і закодуйте його у форматі base64. Ви можете використовувати цю команду:

head -c 32 /dev/urandom | base64

Згенеруйте випадковий ключ з 32 байтів і закодуйте його у форматі base64. Ви можете використовувати цю команду:

# Не запускайте це в сесії, де ви встановили насіння генератора випадкових чисел.
[Convert]::ToBase64String((1..32|%{[byte](Get-Random -Max 256)}))

Реплікація ключа шифрування

Використовуючи безпечний механізм передачі файлів, зробіть копію цього ключа шифрування доступною кожному іншому вузлу керування.

Як мінімум використовуйте шифрування під час передачі даних — наприклад, захищену оболонку (SSH). Для більшої безпеки використовуйте асиметричне шифрування між вузлами або змініть підхід, який ви використовуєте, щоб ви покладалися на шифрування KMS.

Створіть файл конфігурації шифрування

Створіть новий файл конфігурації шифрування. Зміст повинен бути подібним до:

---
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
      - configmaps
      - pandas.awesome.bears.example
    providers:
      - aescbc:
          keys:
            - name: key1
              # Див. наступний текст для отримання додаткової інформації про секретне значення
              secret: <BASE 64 ENCODED SECRET>
      - identity: {} # цей резервний варіант дозволяє читати незашифровані секрети;
                     # наприклад, під час початкової міграції

Щоб створити новий ключ шифрування (який не використовує KMS), див. Згенеруйте ключ шифрування.

Використовуйте новий файл конфігурації шифрування

Вам потрібно буде приєднати новий файл конфігурації шифрування до статичного Podʼа kube-apiserver. Ось приклад того, як це зробити:

  1. Збережіть новий файл конфігурації шифрування у /etc/kubernetes/enc/enc.yaml на вузлі панелі управління.

  2. Відредагуйте маніфест для статичного Podʼа kube-apiserver: /etc/kubernetes/manifests/kube-apiserver.yaml, щоб він був подібний до:

    ---
    #
    # Це фрагмент маніфеста для статичного Podʼа.
    # Перевірте, чи це правильно для вашого кластера та для вашого API-сервера.
    #
    apiVersion: v1
    kind: Pod
    metadata:
      annotations:
        kubeadm.kubernetes.io/kube-apiserver.advertise-address.endpoint: 10.20.30.40:443
      creationTimestamp: null
      labels:
        app.kubernetes.io/component: kube-apiserver
        tier: control-plane
      name: kube-apiserver
      namespace: kube-system
    spec:
      containers:
      - command:
        - kube-apiserver
        ...
        - --encryption-provider-config=/etc/kubernetes/enc/enc.yaml  # додайте цей рядок
        volumeMounts:
        ...
        - name: enc                           # додайте цей рядок
          mountPath: /etc/kubernetes/enc      # додайте цей рядок
          readOnly: true                      # додайте цей рядок
        ...
      volumes:
      ...
      - name: enc                             # додайте цей рядок
        hostPath:                             # додайте цей рядок
          path: /etc/kubernetes/enc           # додайте цей рядок
          type: DirectoryOrCreate             # додайте цей рядок
      ...
    
  3. Перезапустіть свій API-сервер.

Тепер у вас є шифрування для одного вузла панелі управління. У типовому кластері Kubernetes є кілька вузлів керування, тому зробіть це на інших вузлах.

Переконфігуруйте інші вузли керування

Якщо у вашому кластері є кілька API-серверів, вам слід розгорнути зміни по черзі на кожному API-сервері.

Коли ви плануєте оновлення конфігурації шифрування вашого кластера, сплануйте це так, щоб API-сервери у вашій панелі управління завжди могли розшифрувати збережені дані (навіть під час часткового впровадження змін).

Переконайтеся, що ви використовуєте однакову конфігурацію шифрування на кожному вузлі керування.

Перевірте, що нові дані записані зашифровано

Дані зашифровуються під час запису в etcd. Після перезапуску вашого kube-apiserver будь-який новий створений або оновлений Secret (або інші види ресурсів, налаштовані в EncryptionConfiguration), повинні бути зашифровані при зберіганні.

Щоб перевірити це, ви можете використовувати інтерфейс командного рядка etcdctl, щоб отримати вміст вашого секретного ключа.

Цей приклад показує, як це перевірити для шифрування Secret API.

  1. Створіть новий Secret під назвою secret1 у просторі імен default:

    kubectl create secret generic secret1 -n default --from-literal=mykey=mydata
    
  2. Використовуючи інтерфейс командного рядка etcdctl, прочитайте цей Секрет з etcd:

    ETCDCTL_API=3 etcdctl get /registry/secrets/default/secret1 [...] | hexdump -C
    

    де [...] повинно бути додатковими аргументами для приєднання до сервера etcd.

    Наприклад:

    ETCDCTL_API=3 etcdctl \
       --cacert=/etc/kubernetes/pki/etcd/ca.crt   \
       --cert=/etc/kubernetes/pki/etcd/server.crt \
       --key=/etc/kubernetes/pki/etcd/server.key  \
       get /registry/secrets/default/secret1 | hexdump -C
    

    Вивід подібний до цього (скорочено):

    00000000  2f 72 65 67 69 73 74 72  79 2f 73 65 63 72 65 74  |/registry/secret|
    00000010  73 2f 64 65 66 61 75 6c  74 2f 73 65 63 72 65 74  |s/default/secret|
    00000020  31 0a 6b 38 73 3a 65 6e  63 3a 61 65 73 63 62 63  |1.k8s:enc:aescbc|
    00000030  3a 76 31 3a 6b 65 79 31  3a c7 6c e7 d3 09 bc 06  |:v1:key1:.l.....|
    00000040  25 51 91 e4 e0 6c e5 b1  4d 7a 8b 3d b9 c2 7c 6e  |%Q...l..Mz.=..|n|
    00000050  b4 79 df 05 28 ae 0d 8e  5f 35 13 2c c0 18 99 3e  |.y..(..._5.,...>|
    [...]
    00000110  23 3a 0d fc 28 ca 48 2d  6b 2d 46 cc 72 0b 70 4c  |#:..(.H-k-F.r.pL|
    00000120  a5 fc 35 43 12 4e 60 ef  bf 6f fe cf df 0b ad 1f  |..5C.N`..o......|
    00000130  82 c4 88 53 02 da 3e 66  ff 0a                    |...S..>f..|
    0000013a
    
  3. Перевірте, що збережений Secret має префікс k8s:enc:aescbc:v1:, що вказує на те, що провайдер aescbc зашифрував результати. Переконайтеся, що імʼя ключа, вказане в etcd, відповідає імені ключа, вказаному в EncryptionConfiguration вище. У цьому прикладі ви бачите, що ключ шифрування під назвою key1 використовується в etcd і в EncryptionConfiguration.

  4. Перевірте, що Secret правильно розшифровується під час отримання через API:

    kubectl get secret secret1 -n default -o yaml
    

    Вивід повинен містити mykey: bXlkYXRh, з вмістом mydata, закодованим за допомогою base64; прочитайте декодування Secret, щоб дізнатися, як повністю декодувати Secret.

Забезпечте шифрування всіх відповідних даних

Часто недостатньо лише переконатися, що нові обʼєкти зашифровані: ви також хочете, щоб шифрування застосовувалося до обʼєктів, які вже збережені.

У цьому прикладі ви налаштували свій кластер таким чином, що Secret зашифровані при записі. Виконання операції заміни для кожного Secret зашифрує цей вміст в спокої, де обʼєкти залишаються незмінними.

Ви можете виконати цю зміну для всіх Secret у вашому кластері:

# Виконайте це в якості адміністратора, який може читати і записувати всі Secret
kubectl get secrets --all-namespaces -o json | kubectl replace -f -

Команда вище зчитує всі Secret, а потім оновлює їх з тими самими даними, щоб застосувати шифрування на стороні сервера.

Запобігання отриманню відкритого тексту

Якщо ви хочете переконатися, що доступ до певного виду API здійснюється тільки за допомогою шифрування, ви можете позбавити API-сервер можливості читати дані, що підтримують це API, у вигляді простого тексту.

Після того, як всі Secret у вашому кластері зашифровані, ви можете видалити identity частину конфігурації шифрування. Наприклад:

---
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
    providers:
      - aescbc:
          keys:
            - name: key1
              secret: <BASE 64 ENCODED SECRET>
      - identity: {} # ВИДАЛІТЬ ЦЮ СТРОКУ

… а потім перезапустіть кожен API-сервер по черзі. Ця зміна запобігає API-серверу отримувати доступ до Secret у відкритому текстовому форматі, навіть випадково.

Ротація ключа розшифрування

Зміна ключа шифрування для Kubernetes без простою вимагає багатокрокової операції, особливо в умовах високодоступного розгортання, де працюють кілька процесів kube-apiserver.

  1. Згенеруйте новий ключ і додайте його як другий запис ключа для поточного провайдера на всіх вузлах панелі управління.
  2. Перезапустіть усі процеси kube-apiserver, щоб кожен сервер міг розшифрувати будь-які дані, які зашифровані новим ключем.
  3. Зробіть безпечне резервне копіювання нового ключа шифрування. Якщо ви втратите всі копії цього ключа, вам доведеться видалити всі ресурси, які були зашифровані загубленим ключем, і робочі навантаження можуть не працювати як очікується протягом часу, коли шифровання у спокої зламане.
  4. Зробіть новий ключ першим записом у масиві keys, щоб він використовувався для шифрування у спокої для нових записів.
  5. Перезапустіть всі процеси kube-apiserver, щоб кожен хост панелі управління тепер шифрував за допомогою нового ключа.
  6. Як привілейований користувач виконайте команду kubectl get secrets --all-namespaces -o json | kubectl replace -f -, щоб зашифрувати всі наявні секрети новим ключем.
  7. Після того, як ви оновили всі наявні секрети, щоб вони використовували новий ключ, і зробили безпечне резервне копіювання нового ключа, видаліть старий ключ розшифрування з конфігурації.

Розшифрування всіх даних

У цьому прикладі показано, як зупинити шифрування API Secret у спокої. Якщо ви шифруєте інші види API, адаптуйте кроки відповідно.

Щоб вимкнути шифрування у спокої, розмістіть провайдера identity як перший запис у вашому файлі конфігурації шифрування:

---
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
      # перерахуйте тут будь-які інші ресурси, які ви раніше
      # шифрували у спокої
    providers:
      - identity: {} # додайте цей рядок
      - aescbc:
          keys:
            - name: key1
              secret: <BASE 64 ENCODED SECRET> # залиште це на місці
                                               # переконайтеся, що воно йде після "identity"

Потім виконайте таку команду, щоб примусити розшифрування всіх Secrets:

kubectl get secrets --all-namespaces -o json | kubectl replace -f -

Після того, як ви замінили всі наявні зашифровані ресурси резервними даними, які не використовують шифрування, ви можете видалити налаштування шифрування з kube-apiserver.

Налаштування автоматичного перезавантаження

Ви можете налаштувати автоматичне перезавантаження конфігурації провайдера шифрування. Ця настройка визначає, чи має API server завантажувати файл, який ви вказали для --encryption-provider-config тільки один раз при запуску, або автоматично кожного разу, коли ви змінюєте цей файл. Увімкнення цієї опції дозволяє змінювати ключі для шифрування у спокої без перезапуску API server.

Щоб дозволити автоматичне перезавантаження, налаштуйте API server для запуску з параметром: --encryption-provider-config-automatic-reload=true. Коли ввімкнено, зміни файлів перевіряються кожну хвилину для спостереження за модифікаціями. Метрика apiserver_encryption_config_controller_automatic_reload_last_timestamp_seconds визначає час, коли нова конфігурація набирає чинності. Це дозволяє виконувати ротацію ключів шифрування без перезапуску API-сервера.

Що далі

4.2.24 - Розшифровування конфіденційних даних, які вже зашифровані у спокої

Усі API в Kubernetes, що дозволяють записувати постійні дані ресурсів, підтримують шифрування у спокої. Наприклад, ви можете увімкнути шифрування у спокої для Secret. Це шифрування у спокої додається до будь-якого шифрування системного рівня для кластера etcd або файлових систем на вузлах, де запущений kube-apiserver.

Ця сторінка показує, як перейти від шифрування даних API у спокої, щоб дані API зберігалися у незашифрованому вигляді. Ви можете зробити це для покращення продуктивності; проте, якщо шифрування було раціональним рішенням для деяких даних, то його також варто залишити.

Перш ніж ви розпочнете

  • Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

  • Це завдання передбачає, що Kubernetes API server працює як статичний Pod на кожному вузлі панелі управління.

  • Панель управління вашого кластера має використовувати etcd v3.x (основна версія 3, будь-яка мінорна версія).

  • Щоб зашифрувати власний ресурс, ваш кластер повинен працювати на Kubernetes v1.26 або новіше.

  • У вас повинні бути деякі дані API, які вже зашифровані.

Для перевірки версії введіть kubectl version.

Визначте, чи вже увімкнене шифрування у спокої

Стандартно API server використовує провайдера identity, який зберігає представлення ресурсів у текстовому вигляді. Стандартний провайдер identity не надає жодного захисту конфіденційності.

Процес kube-apiserver приймає аргумент --encryption-provider-config, який вказує шлях до файлу конфігурації. Вміст цього файлу, якщо ви вказали його, керує тим, як дані API Kubernetes шифруються в etcd. Якщо він не вказаний, у вас не увімкнене шифрування у спокої.

Форматом цього файлу конфігурації є YAML, який представляє конфігурацію API-ресурсу під назвою EncryptionConfiguration. Приклад конфігурації ви можете побачити в Шифрування конфіденційних даних у спокої.

Якщо встановлено --encryption-provider-config, перевірте, які ресурси (наприклад, secrets) налаштовані для шифрування, і який провайдер використовується. Переконайтеся, що вподобаний провайдер для цього типу ресурсу не є identity; ви встановлюєте лише identity (без шифрування) як типовий, коли хочете вимкнути шифрування у спокої. Перевірте, чи перший провайдер, зазначений для ресурсу, щось інше, ніж identity, що означає, що будь-яка нова інформація, записана до ресурсів цього типу, буде зашифрована, як налаштовано. Якщо ви бачите, що identity — перший провайдер для якого-небудь ресурсу, це означає, що ці ресурси записуються в etcd без шифрування.

Розшифруйте всі дані

Цей приклад показує, як зупинити шифрування API Secret у спокої. Якщо ви шифруєте інші види API, адаптуйте кроки відповідно.

Визначте файл конфігурації шифрування

Спочатку знайдіть файли конфігурації API server. На кожному вузлі панелі управління маніфест статичного Pod для kube-apiserver вказує аргумент командного рядка --encryption-provider-config. Ймовірно, цей файл монтується у статичний Pod за допомогою томуhostPath. Після того, як ви знайдете том, ви можете знайти файл у файловій системі вузла і перевірити його.

Налаштуйте API server для розшифрування обʼєктів

Щоб вимкнути шифрування у спокої, розмістіть провайдера identity як перший запис у вашому файлі конфігурації шифрування.

Наприклад, якщо ваш наявний файл EncryptionConfiguration виглядає так:

---
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
    providers:
      - aescbc:
          keys:
            # Не використовуйте цей (недійсний) приклад ключа для шифрування
            - name: example
              secret: 2KfZgdiq2K0g2YrYpyDYs9mF2LPZhQ==

то змініть його на:

---
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
    providers:
      - identity: {} # додайте цей рядок
      - aescbc:
          keys:
            - name: example
              secret: 2KfZgdiq2K0g2YrYpyDYs9mF2LPZhQ==

і перезапустіть kube-apiserver Pod на цьому вузлі.

Переконфігуруйте інші вузли панелі управління

Якщо у вашому кластері є кілька серверів API, ви повинні по черзі впроваджувати зміни на кожен з серверів API.

Переконайтеся, що ви використовуєте однакову конфігурацію шифрування на кожному вузлі панелі управління.

Примусове розшифрування

Потім виконайте таку команду, щоб примусити розшифрування всіх Secrets:

# Якщо ви розшифровуєте інший тип обʼєкта, змініть "secrets" відповідно.
kubectl get secrets --all-namespaces -o json | kubectl replace -f -

Після того, як ви замінили всі наявні зашифровані ресурси резервними даними, які не використовують шифрування, ви можете видалити налаштування шифрування з kube-apiserver.

Параметри командного рядка, які потрібно видалити:

  • --encryption-provider-config
  • --encryption-provider-config-automatic-reload

Знову перезапустіть kube-apiserver Pod, щоб застосувати нову конфігурацію.

Переконфігуруйте інші вузли панелі управління

Якщо у вашому кластері є кілька серверів API, ви знову повинні по черзі впроваджувати зміни на кожен з серверів API.

Переконайтеся, що ви використовуєте однакову конфігурацію шифрування на кожному вузлі панелі управління.

Що далі

4.2.25 - Гарантоване планування для критичних Podʼів надбудов

Основні компоненти Kubernetes, такі як сервер API, планувальник і контролер-менеджер, працюють на вузлі панелі управління. Однак надбудови мають працювати на звичайному вузлі кластера. Деякі з цих надбудов є критичними для повноцінної функціональності кластера, наприклад, metrics-server, DNS та інтерфейс користувача. Кластер може перестати правильно працювати, якщо критичний Pod надбудови буде видалений (або вручну, або як побічний ефект іншої операції, такої як оновлення) і стане в очікуванні (наприклад, коли кластер високо завантажений і інші очікувані Podʼи заплановані на місце, звільнене видаленим критичним Podʼом надбудови, або кількість доступних ресурсів на вузлі змінилася з якоїсь іншої причини).

Зверніть увагу, що позначення Podʼа як критичного не означає для повного запобігання його видаленню; це лише запобігає тому, що Pod стає постійно недоступним. Статичний Pod, позначений як критичний, не може бути видалений. Однак, нестатичні Podʼи, позначені як критичні, завжди будуть переплановані.

Позначення Podʼа як критичного

Щоб позначити Pod як критичний, встановіть для цього Podʼа priorityClassName у system-cluster-critical або system-node-critical. system-node-critical має найвищий доступний пріоритет, вищий навіть, ніж system-cluster-critical.

4.2.26 - Керівництво користувача агента маскування IP

Ця сторінка показує, як налаштувати та ввімкнути ip-masq-agent.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Для перевірки версії введіть kubectl version.

Керівництво користувача агента маскування IP

ip-masq-agent налаштовує правила iptables для приховування IP-адреси Podʼа за IP-адресою вузла кластера. Це зазвичай робиться, коли трафік надсилається до пунктів призначення за межами діапазону CIDR Podʼів кластера.

Основні терміни

  • NAT (Network Address Translation): Це метод переназначення однієї IP-адреси на іншу шляхом модифікації інформації адреси відправника та/або одержувача у заголовку IP. Зазвичай виконується пристроєм, що здійснює маршрутизацію IP.
  • Маскування (Masquerading): Форма NAT, яка зазвичай використовується для здійснення трансляції багатьох адрес в одну, де декілька початкових IP-адрес маскуються за однією адресою, яка зазвичай є адресою пристрою, що виконує маршрутизацію. У Kubernetes це IP-адреса вузла.
  • CIDR (Classless Inter-Domain Routing): Заснований на маскуванні підмереж змінної довжини, дозволяє вказувати префікси довільної довжини. CIDR ввів новий метод представлення IP-адрес, тепер відомий як нотація CIDR, у якій адреса або маршрутизаційний префікс записується з суфіксом, що вказує кількість бітів префікса, наприклад 192.168.2.0/24.
  • Локальне посилання: Локальна адреса посилання — це мережева адреса, яка є дійсною лише для комунікацій у межах сегмента мережі або домену розсилки, до якого підʼєднано хост. Локальні адреси для IPv4 визначені в блоку адрес 169.254.0.0/16 у нотації CIDR.

ip-masq-agent налаштовує правила iptables для обробки маскування IP-адрес вузлів/Podʼів при надсиланні трафіку до пунктів призначення за межами IP вузла кластера та діапазону IP кластера. Це по суті приховує IP-адреси Podʼів за IP-адресою вузла кластера. У деяких середовищах, трафік до "зовнішніх" адрес має походити з відомої адреси машини. Наприклад, у Google Cloud будь-який трафік до Інтернету має виходити з IP VM. Коли використовуються контейнери, як у Google Kubernetes Engine, IP Podʼа не буде мати виходу. Щоб уникнути цього, ми повинні приховати IP Podʼа за IP адресою VM — зазвичай відомою як "маскування". Типово агент налаштований так, що три приватні IP-діапазони, визначені RFC 1918, не вважаються діапазонами маскування CIDR. Ці діапазони — 10.0.0.0/8, 172.16.0.0/12 і 192.168.0.0/16. Агент також типово вважає локальне посилання (169.254.0.0/16) CIDR не-маскуванням. Агент налаштований на перезавантаження своєї конфігурації з розташування /etc/config/ip-masq-agent кожні 60 секунд, що також можна налаштувати.

приклад маскування/немаскування

Файл конфігурації агента повинен бути написаний у синтаксисі YAML або JSON і може містити три необовʼязкові ключі:

  • nonMasqueradeCIDRs: Список рядків у форматі CIDR, які визначають діапазони без маскування.
  • masqLinkLocal: Булеве значення (true/false), яке вказує, чи маскувати трафік до локального префіксу 169.254.0.0/16. Типово — false.
  • resyncInterval: Інтервал часу, через який агент намагається перезавантажити конфігурацію з диска. Наприклад: '30s', де 's' означає секунди, 'ms' — мілісекунди.

Трафік до діапазонів 10.0.0.0/8, 172.16.0.0/12 і 192.168.0.0/16 НЕ буде маскуватися. Будь-який інший трафік (вважається Інтернетом) буде маскуватися. Прикладом локального пункту призначення з Podʼа може бути IP-адреса його вузла, а також адреса іншого вузла або одна з IP-адрес у діапазоні IP кластера. Будь-який інший трафік буде стандартно маскуватися. Нижче наведено стандартний набір правил, які застосовує агент ip-masq:

iptables -t nat -L IP-MASQ-AGENT
target     prot opt source               destination
RETURN     all  --  anywhere             169.254.0.0/16       /* ip-masq-agent: клієнтський трафік в межах кластера не повинен піддаватися маскуванню */ ADDRTYPE match dst-type !LOCAL
RETURN     all  --  anywhere             10.0.0.0/8           /* ip-masq-agent: клієнтський трафік в межах кластера не повинен піддаватися маскуванню */ ADDRTYPE match dst-type !LOCAL
RETURN     all  --  anywhere             172.16.0.0/12        /* ip-masq-agent: клієнтський трафік в межах кластера не повинен піддаватися маскуванню */ ADDRTYPE match dst-type !LOCAL
RETURN     all  --  anywhere             192.168.0.0/16       /* ip-masq-agent: клієнтський трафік в межах кластера не повинен піддаватися маскуванню */ ADDRTYPE match dst-type !LOCAL
MASQUERADE  all  --  anywhere             anywhere             /* ip-masq-agent: вихідний трафік повинен піддаватися маскуванню (ця відповідність повинна бути після відповідності клієнтським CIDR у межах кластера) */ ADDRTYPE match dst-type !LOCAL

Стандартно, в середовищі GCE/Google Kubernetes Engine, якщо ввімкнуто мережеву політику або ви використовуєте CIDR кластера не в діапазоні 10.0.0.0/8, агент ip-masq-agent буде запущений у вашому кластері. Якщо ви працюєте в іншому середовищі, ви можете додати DaemonSet ip-masq-agent до свого кластера.

Створення агента маскування IP

Щоб створити агента маскування IP, виконайте наступну команду kubectl:

kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/ip-masq-agent/master/ip-masq-agent.yaml

Також вам потрібно застосувати відповідну мітку вузла на будь-яких вузлах вашого кластера, на яких ви хочете запустити агента.

kubectl label nodes my-node node.kubernetes.io/masq-agent-ds-ready=true

Додаткову інформацію можна знайти в документації агента маскування IP тут.

У більшості випадків стандартний набір правил має бути достатнім; однак, якщо це не так для вашого кластера, ви можете створити та застосувати ConfigMap, щоб налаштувати діапазони IP-адрес, що залучаються. Наприклад, щоб дозволити розгляд тільки діапазону 10.0.0.0/8 ip-masq-agent, ви можете створити наступний ConfigMap у файлі з назвою "config".

Виконайте наступну команду, щоб додати configmap до вашого кластера:

kubectl create configmap ip-masq-agent --from-file=config --namespace=kube-system

Це оновить файл, розташований у /etc/config/ip-masq-agent, який періодично перевіряється кожен resyncInterval та застосовується до вузла кластера. Після закінчення інтервалу синхронізації ви повинні побачити, що правила iptables відображають ваші зміни:

iptables -t nat -L IP-MASQ-AGENT
Chain IP-MASQ-AGENT (1 references)
target     prot opt source               destination
RETURN     all  --  anywhere             169.254.0.0/16       /* ip-masq-agent: cluster-local traffic should not be subject to MASQUERADE */ ADDRTYPE match dst-type !LOCAL
RETURN     all  --  anywhere             10.0.0.0/8           /* ip-masq-agent: cluster-local
MASQUERADE  all  --  anywhere             anywhere             /* ip-masq-agent: outbound traffic should be subject to MASQUERADE (this match must come after cluster-local CIDR matches) */ ADDRTYPE match dst-type !LOCAL

Стандартно, діапазон локальних посилань (169.254.0.0/16) також обробляється агентом ip-masq, який налаштовує відповідні правила iptables. Щоб агент ip-masq ігнорував локальні посилання, ви можете встановити masqLinkLocal як true у ConfigMap.

nonMasqueradeCIDRs:
  - 10.0.0.0/8
resyncInterval: 60s
masqLinkLocal: true

4.2.27 - Обмеження використання сховища

Цей приклад демонструє, як обмежити обсяг використання сховища в просторі імен.

У демонстрації використовуються наступні ресурси: ResourceQuota, LimitRange, та PersistentVolumeClaim.

Перш ніж ви розпочнете

  • Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

    Для перевірки версії введіть kubectl version.

Сценарій: Обмеження використання сховища

Адміністратор кластера керує кластером від імені користувачів і хоче контролювати, скільки сховища може використати один простір імен, щоб контролювати витрати.

Адміністратор хоче обмежити:

  1. Кількість заявок на постійні томи в просторі імен
  2. Обсяг сховища, який може бути запитаний кожною заявкою
  3. Загальний обсяг сховища, який може мати простір імен

LimitRange для обмеження запитів на сховище

Додавання LimitRange до простору імен забезпечує встановлення мінімального і максимального розміру запитів на сховище. Сховище запитується через PersistentVolumeClaim. Контролер допуску, який забезпечує дотримання лімітів, відхилить будь-яку PVC, яка перевищує або не досягає встановлених адміністратором значень.

У цьому прикладі, PVC, що запитує 10Gi сховища, буде відхилено, оскільки це перевищує максимум у 2Gi.

apiVersion: v1
kind: LimitRange
metadata:
  name: storagelimits
spec:
  limits:
  - type: PersistentVolumeClaim
    max:
      storage: 2Gi
    min:
      storage: 1Gi

Мінімальні запити на сховище використовуються, коли провайдер сховища вимагає певних мінімумів. Наприклад, диски AWS EBS мають мінімальну вимогу у 1Gi.

ResourceQuota для обмеження кількості PVC та загальної місткості сховища

Адміністратори можуть обмежити кількість PVC в просторі імен, а також загальну місткість цих PVC. Нові PVC, які перевищують будь-яке максимальне значення, будуть відхилені.

У цьому прикладі, шоста PVC у просторі імен буде відхилена, оскільки вона перевищує максимальну кількість у 5. Альтернативно, максимальна квота у 5Gi при поєднанні з максимальним лімітом у 2Gi вище, не може мати 3 PVC, де кожна має по 2Gi. Це було б 6Gi, запитані для простору імен з лімітом у 5Gi.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: storagequota
spec:
  hard:
    persistentvolumeclaims: "5"
    requests.storage: "5Gi"

Підсумок

Limit range може встановити максимальний поріг для запитів на сховище, тоді як квота на ресурси може ефективно обмежити обсяг сховища, використовуваного простором імен через кількість заявок та загальну місткість. Це дозволяє адміністратору кластера планувати бюджет на сховище кластера без ризику перевитрати будь-якого проєкту.

4.2.28 - Міграція реплікованої панелі управління на використання менеджера керування хмарою

Менеджер керування хмарою — компонент панелі управління Kubernetes, що інтегрує управління логікою певної хмари. Cloud controller manager дозволяє звʼязувати ваш кластер з API хмарного провайдера та відокремлює компоненти, що взаємодіють з хмарною платформою від компонентів, які взаємодіють тільки в кластері.

Відокремлюючи логіку сумісності між Kubernetes і базовою хмарною інфраструктурою, компонент cloud-controller-manager дає змогу хмарним провайдерам випускати функції з іншою швидкістю порівняно з основним проєктом Kubernetes.

Контекст

У рамках зусиль щодо виокремлення хмарного провайдера, всі контролери, специфічні для хмари, повинні бути виокремлені з kube-controller-manager. Усі поточні кластери, які використовують контролери хмари в kube-controller-manager, повинні перейти на запуск контролерів за допомогою специфічному для хмарного провайдера cloud-controller-manager.

Міграція лідера надає механізм, за допомогою якого високодоступні кластери можуть безпечно мігрувати у "хмароспецифічні" контролери між kube-controller-manager та cloud-controller-manager за допомогою загального замикання ресурсів між двома компонентами під час оновлення реплікованої панелі управління. Для панелі управління з одним вузлом або якщо недоступність менеджерів контролерів може бути терпимим під час оновлення, міграція лідера не потрібна, і цей посібник можна ігнорувати.

Міграція лідера може бути увімкнена, встановленням --enable-leader-migration у kube-controller-manager або cloud-controller-manager. Міграція лідера застосовується лише під час оновлення і може бути безпечно вимкнена або залишена увімкненою після завершення оновлення.

Цей посібник на крок за кроком показує вам процес оновлення вручну панелі управління з kube-controller-manager із вбудованим хмарним провайдером до запуску як kube-controller-manager, так і cloud-controller-manager. Якщо ви використовуєте інструмент для розгортання та управління кластером, будь ласка, зверніться до документації інструменту та хмарного провайдера для конкретних інструкцій щодо міграції.

Перш ніж ви розпочнете

Припускається, що панель управління працює на версії Kubernetes N і планується оновлення до версії N + 1. Хоча можливе мігрування в межах однієї версії, ідеально міграцію слід виконати як частину оновлення, щоб зміни конфігурації можна було узгодити з кожним випуском. Точні версії N та N + 1 залежать від кожного хмарного провайдера. Наприклад, якщо хмарний провайдер створює cloud-controller-manager для роботи з Kubernetes 1.24, то N може бути 1.23, а N + 1 може бути 1.24.

Вузли панелі управління повинні запускати kube-controller-manager з увімкненим вибором лідера, що є стандартною поведінкою. З версії N, вбудований хмарний провайдер має бути налаштований за допомогою прапорця --cloud-provider, а cloud-controller-manager ще не повинен бути розгорнутим.

Зовнішній хмарний провайдер повинен мати cloud-controller-manager зібраний з реалізацією міграції лідера. Якщо хмарний провайдер імпортує k8s.io/cloud-provider та k8s.io/controller-manager версії v0.21.0 або пізніше, міграція лідера буде доступною. Однак для версій до v0.22.0 міграція лідера є альфа-версією та потребує увімкнення ControllerManagerLeaderMigration в cloud-controller-manager.

Цей посібник передбачає, що kubelet кожного вузла панелі управління запускає kube-controller-manager та cloud-controller-manager як статичні контейнери, визначені їх маніфестами. Якщо компоненти працюють в іншому середовищі, будь ласка, відповідно скорегуйте дії.

Щодо авторизації цей посібник передбачає, що кластер використовує RBAC. Якщо інший режим авторизації надає дозволи на компоненти kube-controller-manager та cloud-controller-manager, будь ласка, надайте необхідний доступ таким чином, що відповідає режиму.

Надання доступу до Лізингу Міграції

Стандартні дозволи менеджера керування дозволяють доступ лише до їхнього основного Лізингу. Для того, щоб міграція працювала, потрібен доступ до іншого Лізингу.

Ви можете надати kube-controller-manager повний доступ до API лізингів, змінивши роль system::leader-locking-kube-controller-manager. Цей посібник передбачає, що назва лізингу для міграції — cloud-provider-extraction-migration.

kubectl patch -n kube-system role 'system::leader-locking-kube-controller-manager' -p '{"rules": [ {"apiGroups":[ "coordination.k8s.io"], "resources": ["leases"], "resourceNames": ["cloud-provider-extraction-migration"], "verbs": ["create", "list", "get", "update"] } ]}' --type=merge`

Зробіть те саме для ролі system::leader-locking-cloud-controller-manager.

kubectl patch -n kube-system role 'system::leader-locking-cloud-controller-manager' -p '{"rules": [ {"apiGroups":[ "coordination.k8s.io"], "resources": ["leases"], "resourceNames": ["cloud-provider-extraction-migration"], "verbs": ["create", "list", "get", "update"] } ]}' --type=merge`

Початкова конфігурація міграції лідера

Міграція лідера опціонально використовує файл конфігурації, що представляє стан призначення контролерів до менеджера. На цей момент, з вбудованим хмарним провайдером, kube-controller-manager запускає route, service, та cloud-node-lifecycle. Наведений нижче приклад конфігурації показує призначення.

Міграцію лідера можна увімкнути без конфігурації. Будь ласка, див. Станадартну конфігурацію для отримання деталей.

kind: LeaderMigrationConfiguration
apiVersion: controllermanager.config.k8s.io/v1
leaderName: cloud-provider-extraction-migration
controllerLeaders:
  - name: route
    component: kube-controller-manager
  - name: service
    component: kube-controller-manager
  - name: cloud-node-lifecycle
    component: kube-controller-manager

Альтернативно, оскільки контролери можуть працювати з менеджерами контролера, налаштування component на * для обох сторін робить файл конфігурації збалансованим між обома сторонами міграції.

# версія з підстановкою
kind: LeaderMigrationConfiguration
apiVersion: controllermanager.config.k8s.io/v1
leaderName: cloud-provider-extraction-migration
controllerLeaders:
  - name: route
    component: *
  - name: service
    component: *
  - name: cloud-node-lifecycle
    component: *

На кожному вузлі панелі управління збережіть вміст у /etc/leadermigration.conf, та оновіть маніфест kube-controller-manager, щоб файл був змонтований всередині контейнера за тим самим шляхом. Також, оновіть цей маніфест, щоб додати наступні аргументи:

  • --enable-leader-migration для увімкнення міграції лідера у менеджері керування
  • --leader-migration-config=/etc/leadermigration.conf для встановлення файлу конфігурації

Перезапустіть kube-controller-manager на кожному вузлі. Тепер, kube-controller-manager має увімкнену міграцію лідера і готовий до міграції.

Розгортання менеджера керування хмарою

У версії N + 1, бажаний стан призначення контролерів до менеджера може бути представлений новим файлом конфігурації, який показано нижче. Зверніть увагу, що поле component кожного controllerLeaders змінюється з kube-controller-manager на cloud-controller-manager. Альтернативно, використовуйте версію з підстановкою, згадану вище, яка має той самий ефект.

kind: LeaderMigrationConfiguration
apiVersion: controllermanager.config.k8s.io/v1
leaderName: cloud-provider-extraction-migration
controllerLeaders:
  - name: route
    component: cloud-controller-manager
  - name: service
    component: cloud-controller-manager
  - name: cloud-node-lifecycle
    component: cloud-controller-manager

Під час створення вузлів панелі управління версії N + 1, вміст повинен бути розгорнутим в /etc/leadermigration.conf. Маніфест cloud-controller-manager повинен бути оновлений для монтування файлу конфігурації так само як і kube-controller-manager версії N. Також, додайте --enable-leader-migration та --leader-migration-config=/etc/leadermigration.conf до аргументів cloud-controller-manager.

Створіть новий вузол панелі управління версії N + 1 з оновленим маніфестом cloud-controller-manager, та з прапорцем --cloud-provider, встановленим на external для kube-controller-manager. kube-controller-manager версії N + 1 НЕ МУСИТЬ мати увімкненої міграції лідера, оскільки, зовнішній хмарний провайдер вже не запускає мігровані контролери, і, отже, він не бере участі в міграції.

Будь ласка, зверніться до Адміністрування менеджера керування хмарою для отримання детальнішої інформації щодо розгортання cloud-controller-manager.

Оновлення панелі управління

Панель управління тепер містить вузли як версії N, так і N + 1. Вузли версії N запускають лише kube-controller-manager, а вузли версії N + 1 запускають як kube-controller-manager, так і cloud-controller-manager. Мігровані контролери, зазначені у конфігурації, працюють під менеджером управління хмарою версії N або cloud-controller-manager версії N + 1 залежно від того, який менеджер управління утримує лізинг міграції. Жоден контролер ніколи не працюватиме під обома менеджерами управління одночасно.

Поступово створіть новий вузол панелі управління версії N + 1 та вимкніть один вузол версії N до тих пір, поки панель управління не буде містити лише вузли версії N + 1. Якщо потрібно відкотитись з версії N + 1 на версію N, додайте вузли версії N з увімкненою міграцією лідера для kube-controller-manager назад до панелі управління, замінюючи один вузол версії N + 1 кожен раз, поки не залишаться лише вузли версії N.

(Необовʼязково) Вимкнення міграції лідера

Тепер, коли панель управління була оновлена для запуску як kube-controller-manager, так і cloud-controller-manager версії N + 1, міграція лідера завершила свою роботу і може бути безпечно вимкнена для збереження ресурсу лізингу. У майбутньому можна безпечно повторно увімкнути міграцію лідера для відкату.

Поступово у менеджері оновіть маніфест cloud-controller-manager, щоб скасувати встановлення як --enable-leader-migration, так і --leader-migration-config=, також видаліть підключення /etc/leadermigration.conf, а потім видаліть /etc/leadermigration.conf. Щоб повторно увімкнути міграцію лідера, створіть знову файл конфігурації та додайте його монтування та прапорці, які увімкнуть міграцію лідера назад до cloud-controller-manager.

Стандартна конфігурація

Починаючи з Kubernetes 1.22, Міграція лідера надає стандартну конфігурацію, яка підходить для стандартного призначення контролерів до менеджера. Стандартну конфігурацію можна увімкнути, встановивши --enable-leader-migration, але без --leader-migration-config=.

Для kube-controller-manager та cloud-controller-manager, якщо немає жодних прапорців, що увімкнуть будь-якого вбудованого хмарного провайдера або змінять володільця контролерів, можна використовувати стандартну конфігурацію, щоб уникнути ручного створення файлу конфігурації.

Спеціальний випадок: міграція контролера Node IPAM

Якщо ваш хмарний провайдер надає реалізацію контролера Node IPAM, вам слід перейти до реалізації в cloud-controller-manager. Вимкніть контролер Node IPAM в kube-controller-manager версії N + 1, додавши --controllers=*,-nodeipam до його прапорців. Потім додайте nodeipam до списку мігрованих контролерів.

# версія з підстановкою, з nodeipam
kind: LeaderMigrationConfiguration
apiVersion: controllermanager.config.k8s.io/v1
leaderName: cloud-provider-extraction-migration
controllerLeaders:
  - name: route
    component: *
  - name: service
    component: *
  - name: cloud-node-lifecycle
    component: *
  - name: nodeipam
    component: *

Що далі

4.2.29 - Посібник з роботи з просторами імен

Kubernetes namespaces допомагають різним проєктам, командам або клієнтам спільно використовувати кластер Kubernetes.

Вони це роблять, надаючи наступне:

  1. Область для Імен.
  2. Механізм для прикріплення авторизації та політики до підрозділу кластера.

Використання кількох просторів імен є необовʼязковим.

У цьому прикладі показано, як використовувати простори імен Kubernetes для розділення вашого кластера.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Для перевірки версії введіть kubectl version.

Передумови

У цьому прикладі передбачається наступне:

  1. У вас є кластер Kubernetes.
  2. Ви маєте базове розуміння що таке Pod, Service та Deployment в Kubernetes.

Стандартний простір імен

Типово кластер Kubernetes створює стандартний простір імен default під час створення кластера для утримання стандартного набору Podʼів, Serviceʼів та Deploymentʼів, що використовуються кластером.

Якщо у вас є свіжий кластер, ви можете перевірити доступні простори імен, виконавши наступне:

kubectl get namespaces
NAME      STATUS    AGE
default   Active    13m

Створення нових просторів імен

Для цієї вправи ми створимо два додаткові простори імен Kubernetes для зберігання нашого контенту.

Уявімо собі сценарій, де організація використовує спільний кластер Kubernetes для розробки та операційної експлуатації.

Команда розробки хоче мати простір в кластері, де вони можуть переглядати список Podʼів, Serviceʼів та Deploymentʼів, які вони використовують для створення та запуску свого застосунку. У цьому просторі ресурси Kubernetes приходять і йдуть, і обмеження на те, хто може або не може змінювати ресурси, не є жорсткими, щоб забезпечити гнучкість розробки.

Операційна команда хоче мати простір в кластері, де вони можуть дотримуватися строгих процедур щодо того, хто може або не може маніпулювати набором Podʼів, Serviceʼів та Deploymentʼів, які підтримують операційну роботу.

Одним із шаблонів, який ця організація може використовувати, є розбиття кластера Kubernetes на два простори імен: development та production.

Створімо два нових простори імен для зберігання нашої роботи.

Використовуйте файл namespace-dev.yaml, який описує простір імен development:

apiVersion: v1
kind: Namespace
metadata:
  name: development
  labels:
    name: development

Створіть простір імен development за допомогою kubectl.

kubectl create -f https://k8s.io/examples/admin/namespace-dev.yaml

Збережіть наступний вміст у файл namespace-prod.yaml, який описує простір імен production:

apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    name: production

А потім створімо простір імен production за допомогою kubectl.

kubectl create -f https://k8s.io/examples/admin/namespace-prod.yaml

Щоб бути впевненими, що все правильно, перелічімо всі простори імен у нашому кластері.

kubectl get namespaces --show-labels
NAME          STATUS    AGE       LABELS
default       Active    32m       <none>
development   Active    29s       name=development
production    Active    23s       name=production

Створення Podʼів у кожному просторі імен

Простір імен Kubernetes надає область для Podʼів, Service та Deployment у кластері.

Користувачі, які взаємодіють з одним простором імен, не бачать вмісту в іншому просторі імен.

Щоб продемонструвати це, запустімо простий Deployment та Podʼи у просторі імен development.

Спочатку перевіримо поточний контекст:

kubectl config view
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: REDACTED
    server: https://130.211.122.180
  name: lithe-cocoa-92103_kubernetes
contexts:
- context:
    cluster: lithe-cocoa-92103_kubernetes
    user: lithe-cocoa-92103_kubernetes
  name: lithe-cocoa-92103_kubernetes
current-context: lithe-cocoa-92103_kubernetes
kind: Config
preferences: {}
users:
- name: lithe-cocoa-92103_kubernetes
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED
    token: 65rZW78y8HbwXXtSXuUw9DbP4FLjHi4b
- name: lithe-cocoa-92103_kubernetes-basic-auth
  user:
    password: h5M0FtUUIflBSdI7
    username: admin
kubectl config current-context
lithe-cocoa-92103_kubernetes

Наступний крок — визначення контексту для клієнта kubectl для роботи в кожному просторі імен. Значення полів "cluster" та "user" копіюються з поточного контексту.

kubectl config set-context dev --namespace=development \
  --cluster=lithe-cocoa-92103_kubernetes \
  --user=lithe-cocoa-92103_kubernetes

kubectl config set-context prod --namespace=production \
  --cluster=lithe-cocoa-92103_kubernetes \
  --user=lithe-cocoa-92103_kubernetes

Типово, ці команди додають два контексти, які зберігаються у файлі .kube/config. Тепер ви можете переглянути контексти та перемикатися між двома новими контекстами запитів, залежно від того, з яким простором імен ви хочете працювати.

Щоб переглянути нові контексти:

kubectl config view
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: REDACTED
    server: https://130.211.122.180
  name: lithe-cocoa-92103_kubernetes
contexts:
- context:
    cluster: lithe-cocoa-92103_kubernetes
    user: lithe-cocoa-92103_kubernetes
  name: lithe-cocoa-92103_kubernetes
- context:
    cluster: lithe-cocoa-92103_kubernetes
    namespace: development
    user: lithe-cocoa-92103_kubernetes
  name: dev
- context:
    cluster: lithe-cocoa-92103_kubernetes
    namespace: production
    user: lithe-cocoa-92103_kubernetes
  name: prod
current-context: lithe-cocoa-92103_kubernetes
kind: Config
preferences: {}
users:
- name: lithe-cocoa-92103_kubernetes
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED
    token: 65rZW78y8HbwXXtSXuUw9DbP4FLjHi4b
- name: lithe-cocoa-92103_kubernetes-basic-auth
  user:
    password: h5M0FtUUIflBSdI7
    username: admin

Перемкнімся, щоб працювати у просторі імен development.

kubectl config use-context dev

Ви можете перевірити поточний контекст за допомогою наступного:

kubectl config current-context
dev

На цьому етапі всі запити, які ми робимо до кластера Kubernetes з командного рядка, зосереджені на просторі імен development.

Створімо деякий вміст.

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: snowflake
  name: snowflake
spec:
  replicas: 2
  selector:
    matchLabels:
      app: snowflake
  template:
    metadata:
      labels:
        app: snowflake
    spec:
      containers:
      - image: registry.k8s.io/serve_hostname
        imagePullPolicy: Always
        name: snowflake

Застосуйте маніфест для створення Deployment

kubectl apply -f https://k8s.io/examples/admin/snowflake-deployment.yaml

Ми створили розгортання, кількість реплік якого становить 2, що запускає Pod під назвою snowflake з базовим контейнером, який обслуговує імʼя хосту.

kubectl get deployment
NAME         READY   UP-TO-DATE   AVAILABLE   AGE
snowflake    2/2     2            2           2m
kubectl get pods -l app=snowflake
NAME                         READY     STATUS    RESTARTS   AGE
snowflake-3968820950-9dgr8   1/1       Running   0          2m
snowflake-3968820950-vgc4n   1/1       Running   0          2m

І це чудово, розробники можуть робити все, що вони хочуть, і їм не потрібно хвилюватися про вплив на вміст у просторі імен production.

Тепер перейдемо до простору імен production та покажемо, як ресурси в одному просторі імен приховані від іншого.

kubectl config use-context prod

Простір імен production повинен бути порожнім, і наступні команди не повернуть нічого.

kubectl get deployment
kubectl get pods

Операційна діяльність вимагає догляду за худобою, тому створімо кілька Podʼів для худоби.

kubectl create deployment cattle --image=registry.k8s.io/serve_hostname --replicas=5

kubectl get deployment
NAME         READY   UP-TO-DATE   AVAILABLE   AGE
cattle       5/5     5            5           10s
kubectl get pods -l app=cattle
NAME                      READY     STATUS    RESTARTS   AGE
cattle-2263376956-41xy6   1/1       Running   0          34s
cattle-2263376956-kw466   1/1       Running   0          34s
cattle-2263376956-n4v97   1/1       Running   0          34s
cattle-2263376956-p5p3i   1/1       Running   0          34s
cattle-2263376956-sxpth   1/1       Running   0          34s

На цьому етапі повинно бути зрозуміло, що ресурси, які користувачі створюють в одному просторі імен, приховані від іншого простору імен.

З розвитком підтримки політики в Kubernetes ми розширимо цей сценарій, щоб показати, як можна надавати різні правила авторизації для кожного простору імен.

4.2.30 - Управління кластерами etcd для Kubernetes

etcd — це сумісне та високодоступне сховище ключ-значення, яке використовується як сховище Kubernetes для резервування всіх даних кластера.

Якщо ваш кластер Kubernetes використовує etcd як сховище для резервування, переконайтеся, що у вас є план резервного копіювання даних.

Ви можете знайти докладну інформацію про etcd в офіційній документації.

Перш ніж ви розпочнете

Перш ніж слідувати інструкціям на цій сторінці щодо розгортання, керування, резервного копіювання або відновлення etcd, необхідно зрозуміти типові очікування при експлуатації кластера etcd. Зверніться до документації etcd для отримання додаткової інформації.

Основні деталі включають:

  • Мінімальні рекомендовані версії etcd для використання в операційній діяльності: 3.4.22+ і 3.5.6+.

  • etcd є розподіленою системою з визначенням лідера. Забезпечте, щоб лідер періодично надсилав своєчасні сигнали всім підлеглим для підтримки стабільності кластера.

  • Ви повинні запускати etcd як кластер з непарною кількістю членів.

  • Намагайтеся уникати виснаження ресурсів.

    Продуктивність і стабільність кластера чутлива до наявності ресурсів мережі та введення/виведення даних на диск. Будь-яка нестача ресурсів може призвести до вичерпання тайм-ауту пульсу, що призводить до нестабільності кластера. Нестабільність etcd означає, що лідер не обраний. У таких обставинах кластер не може вносити зміни до свого поточного стану, що означає, що нові Podʼи не можуть бути заплановані.

Вимоги до ресурсів для etcd

Експлуатація etcd з обмеженими ресурсами підходить тільки для тестових цілей. Для розгортання в операційній діяльності потрібна розширена конфігурація обладнання. Перед розгортанням etcd в операційній діяльності дивіться довідник щодо вимог до ресурсів.

Підтримання стабільності кластерів etcd є критичним для стабільності кластерів Kubernetes. Тому запускайте кластери etcd на виділених машинах або в ізольованих середовищах для гарантованих вимог до ресурсів.

Інструменти

Залежно від конкретного завдання, яке ви виконуєте, вам знадобиться інструмент etcdctl або etcdutl (можливо, обидва).

Розуміння etcdctl і etcdutl

etcdctl і etcdutl — це інструменти командного рядка для взаємодії з кластерами etcd, але вони виконують різні завдання:

  • etcdctl — це основний клієнт командного рядка для взаємодії з etcd через мережу. Використовується для повсякденних операцій, таких як керування ключами та значеннями, адміністрування кластера, перевірка справності та багато іншого.

  • etcdutl — це утиліта адміністратора, призначена для роботи безпосередньо з файлами даних etcd, включаючи міграцію даних між версіями etcd, дефрагментацію бази даних, відновлення знімків і перевірку цілісності даних. Для мережевих операцій слід використовувати etcdctl.

Для отримання додаткової інформації про etcdutl, ви можете звернутися до документації з відновлення etcd.

Запуск кластерів etcd

У цьому розділі розглядається запуск одно- та багатовузлового кластерів etcd.

Це керівництво передбачає, що etcd встановлено.

Одновузловий кластер etcd

Використовуйте одновузловий кластер etcd лише для тестування.

  1. Виконайте наступне:

    etcd --listen-client-urls=http://$PRIVATE_IP:2379 \
       --advertise-client-urls=http://$PRIVATE_IP:2379
    
  2. Запустіть сервер API Kubernetes з прапорцем --etcd-servers=$PRIVATE_IP:2379.

    Переконайтеся, що PRIVATE_IP встановлено на ваш IP-адрес клієнта etcd.

Багатовузловий кластер etcd

Для забезпечення надійності та високої доступності запускайте etcd як багатовузловий кластер для операційної діяльності та періодично робіть резервні копії. В операційній діяльності рекомендується використовувати кластер з пʼятьма членами. Для отримання додаткової інформації див. ЧаПи.

Оскільки ви використовуєте Kubernetes, у вас є можливість запускати etcd як контейнер всередині одного або декількох Podʼів. Інструмент kubeadm типово налаштовує etcd як статичні Podʼи, або ви можете розгорнути окремий кластер і вказати kubeadm використовувати цей кластер etcd як сховище для контрольної площини.

Ви можете налаштувати кластер etcd або за допомогою статичної інформації про учасників, або за допомогою динамічного виявлення. Для отримання додаткової інформації про кластеризацію дивіться документацію з кластеризації etcd.

Наприклад, розглянемо кластер etcd з пʼятьох членів, що працює з наступними URL-адресами клієнта: http://$IP1:2379, http://$IP2:2379, http://$IP3:2379, http://$IP4:2379 та http://$IP5:2379. Щоб запустити сервер API Kubernetes:

  1. Виконайте наступне:

    etcd --listen-client-urls=http://$IP1:2379,http://$IP2:2379,http://$IP3:2379,http://$IP4:2379,http://$IP5:2379 --advertise-client-urls=http://$IP1:2379,http://$IP2:2379,http://$IP3:2379,http://$IP4:2379,http://$IP5:2379
    
  2. Запустіть сервери API Kubernetes з прапорцем --etcd-servers=$IP1:2379,$IP2:2379,$IP3:2379,$IP4:2379,$IP5:2379.

    Переконайтеся, що змінні IP<n> встановлені на ваші IP-адреси клієнтів.

Багатовузловий кластер etcd з балансувальником навантаження

Для запуску кластера etcd з балансувальником навантаження:

  1. Налаштуйте кластер etcd.
  2. Налаштуйте балансувальник навантаження перед кластером etcd. Наприклад, адреса балансувальника навантаження може бути $LB.
  3. Запустіть сервери API Kubernetes з прапорцем --etcd-servers=$LB:2379.

Захист кластерів etcd

Доступ до etcd еквівалентний правам кореневого користувача в кластері, тому ідеально, щоб доступ до нього мав лише сервер API. З урахуванням чутливості даних рекомендується надавати дозвіл лише тим вузлам, які потребують доступу до кластерів etcd.

Для захисту etcd налаштуйте правила брандмауера або використовуйте засоби безпеки, надані etcd. Функції безпеки etcd залежать від інфраструктури відкритого ключа x509 (PKI). Для початку налаштуйте безпечні канали звʼязку, згенерувавши пару ключа та сертифікату. Наприклад, використовуйте пари ключів peer.key та peer.cert для захисту звʼязку між членами etcd та client.key та client.cert для захисту звʼязку між etcd та його клієнтами. Див. приклади скриптів, надані проєктом etcd, для генерації пар ключів та файлів ЦС для автентифікації клієнтів.

Захист комунікації

Для налаштування etcd з безпечною взаємодією між членами вкажіть прапорці --peer-key-file=peer.key та --peer-cert-file=peer.cert, та використовуйте протокол HTTPS у схемі URL.

Аналогічно, для налаштування etcd з безпечною взаємодією клієнтів вкажіть прапорці --key-file=k8sclient.key та --cert-file=k8sclient.cert, та використовуйте протокол HTTPS у схемі URL. Ось приклад команди клієнта, яка використовує безпечну комунікацію:

ETCDCTL_API=3 etcdctl --endpoints 10.2.0.9:2379 \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  member list

Обмеження доступу до кластерів etcd

Після налаштування безпечної комунікації обмежте доступ до кластера etcd лише для серверів API Kubernetes, використовуючи автентифікацію TLS.

Наприклад, розгляньте пари ключів k8sclient.key та k8sclient.cert, яким довіряє ЦС etcd.ca. Коли etcd налаштовано з параметром --client-cert-auth разом з TLS, він перевіряє сертифікати від клієнтів, використовуючи системні ЦС або ЦС, передані за допомогою прапорця --trusted-ca-file. Вказівка прапорців --client-cert-auth=true та --trusted-ca-file=etcd.ca обмежить доступ до клієнтів з сертифікатом k8sclient.cert.

Після коректного налаштування etcd до нього можуть отримувати доступ лише клієнти з дійсними сертифікатами. Щоб дати серверам API Kubernetes доступ, налаштуйте їх з прапорцями --etcd-certfile=k8sclient.cert, --etcd-keyfile=k8sclient.key та --etcd-cafile=ca.cert.

Заміна несправного члена etcd

Кластер etcd досягає високої доступності, толеруючи невеликі відмови членів. Однак, для покращення загального стану кластера, замінюйте несправних членів негайно. Коли відмовляють декілька членів, замінюйте їх по одному. Заміна несправного члена включає два кроки: видалення несправного члена та додавання нового члена.

Хоча etcd зберігає унікальні ідентифікатори членів всередині, рекомендується використовувати унікальне імʼя для кожного члена, щоб уникнути фактора людської помилки. Наприклад, розгляньте кластер etcd з трьох членів. Нехай URL буде таким: member1=http://10.0.0.1, member2=http://10.0.0.2, і member3=http://10.0.0.3. Коли відмовляє member1, замініть його на member4=http://10.0.0.4.

  1. Отримайте ідентифікатор несправного member1:

    etcdctl --endpoints=http://10.0.0.2,http://10.0.0.3 member list
    

    Показується наступне повідомлення:

    8211f1d0f64f3269, started, member1, http://10.0.0.1:2380, http://10.0.0.1:2379
    91bc3c398fb3c146, started, member2, http://10.0.0.2:2380, http://10.0.0.2:2379
    fd422379fda50e48, started, member3, http://10.0.0.3:2380, http://10.0.0.3:2379
    
  2. Виконайте одне з наступного:

    1. Якщо кожен сервер API Kubernetes налаштований на спілкування з усіма членами etcd, видаліть несправного члена з прапорця --etcd-servers, а потім перезапустіть кожен сервер API Kubernetes.
    2. Якщо кожен сервер API Kubernetes спілкується з одним членом etcd, зупиніть сервер API Kubernetes, який спілкується з несправним etcd.
  3. Зупиніть сервер etcd на несправному вузлі. Можливо, інші клієнти окрім сервера API Kubernetes створюють трафік до etcd, і бажано зупинити весь трафік, щоб запобігти записам до теки з даними.

  4. Видаліть несправного члена:

    etcdctl member remove 8211f1d0f64f3269
    

    Показується наступне повідомлення:

    Removed member 8211f1d0f64f3269 from cluster
    
  5. Додайте нового члена:

    etcdctl member add member4 --peer-urls=http://10.0.0.4:2380
    

    Показується наступне повідомлення:

    Member 2be1eb8f84b7f63e added to cluster ef37ad9dc622a7c4
    
  6. Запустіть новододаного члена на машині з IP 10.0.0.4:

    export ETCD_NAME="member4"
    export ETCD_INITIAL_CLUSTER="member2=http://10.0.0.2:2380,member3=http://10.0.0.3:2380,member4=http://10.0.0.4:2380"
    export ETCD_INITIAL_CLUSTER_STATE=existing
    etcd [flags]
    
  7. Виконайте одне з наступного:

    1. Якщо кожен сервер API Kubernetes налаштований на спілкування з усіма членами etcd, додайте новододаного члена до прапорця --etcd-servers, а потім перезапустіть кожен сервер API Kubernetes.
    2. Якщо кожен сервер API Kubernetes спілкується з одним членом etcd, запустіть сервер API Kubernetes, який був зупинений на кроці 2. Потім налаштуйте клієнти сервера API Kubernetes знову маршрутизувати запити до сервера API Kubernetes, який був зупинений. Це часто можна зробити, налаштувавши балансувальник навантаження.

За додатковою інформацією про налаштування кластера etcd див. документацію з переналаштування etcd.

Резервне копіювання кластера etcd

Усі обʼєкти Kubernetes зберігаються в etcd. Періодичне резервне копіювання даних кластера etcd важливо для відновлення кластерів Kubernetes у випадку катастрофи, такої як втрата всіх вузлів панелі управління. Файл знімка містить весь стан Kubernetes та критичну інформацію. Для збереження конфіденційних даних Kubernetes в безпеці зашифруйте файли знімків.

Резервне копіювання кластера etcd можна виконати двома способами: вбудованим засобами знімків etcd та знімком тому.

Вбудовані засоби знімків

etcd підтримує вбудовані засоби знімків. Знімок можна створити з активного члена за допомогою команди etcdctl snapshot save або скопіювавши файл member/snap/db з теки даних etcd, яка в цей момент не використовується процесом etcd. Створення знімка не вплине на продуктивність члена.

Нижче наведено приклад створення знімка простору ключів, який обслуговується за адресою $ENDPOINT, у файл snapshot.db:

ETCDCTL_API=3 etcdctl --endpoints $ENDPOINT snapshot save snapshot.db

Перевірте знімок:

Приклад нижче показує, як використовувати etcdutl для перевірки знімка:

etcdutl --write-out=table snapshot status snapshot.db

Це повинно згенерувати результат, подібний до наведеного нижче прикладу:

+----------+----------+------------+------------+
|   HASH   | REVISION | TOTAL KEYS | TOTAL SIZE |
+----------+----------+------------+------------+
| fe01cf57 |       10 |          7 | 2.1 MB     |
+----------+----------+------------+------------+

Приклад нижче показує, як використовувати etcdctl для перевірки знімка:

export ETCDCTL_API=3
etcdctl --write-out=table snapshot status snapshot.db

Це повинно згенерувати результат, подібний до наведеного нижче прикладу:

Застаріло: Використовуйте `etcdutl snapshot status` натомість.

+----------+----------+------------+------------+
|   HASH   | REVISION | TOTAL KEYS | TOTAL SIZE |
+----------+----------+------------+------------+
| fe01cf57 |       10 |          7 | 2.1 MB     |
+----------+----------+------------+------------+

Знімок тому {volume-snapshot}

Якщо etcd працює за томом сховища, який підтримує резервне копіювання, наприклад, Amazon Elastic Block Store, зробіть резервну копію даних etcd, створивши знімок тому сховища.

Знімок за допомогою параметрів etcdctl

Ми також можемо створити знімок, використовуючи різноманітні параметри, надані etcdctl. Наприклад:

ETCDCTL_API=3 etcdctl -h

покаже різні параметри, доступні з etcdctl. Наприклад, ви можете створити знімок, вказавши точку доступу, сертифікати та ключ, як показано нижче:

ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
  --cacert=<trusted-ca-file> --cert=<cert-file> --key=<key-file> \
  snapshot save <backup-file-location>

де trusted-ca-file, cert-file та key-file можна отримати з опису модуля etcd.

Масштабування кластерів etcd

Масштабування кластерів etcd підвищує доступність шляхом зниження продуктивності. Масштабування не збільшує продуктивність або можливості кластера. Загальне правило — не масштабуйте кластери etcd. Не налаштовуйте жодних автоматичних груп масштабування для кластерів etcd. Настійно рекомендується завжди запускати статичний кластер etcd з 5-ти членів для операційних кластерів Kubernetes будь-якого офіційно підтримуваного масштабу.

Доречне масштабування — це оновлення кластера з трьох до пʼяти членів, коли потрібно більше надійності. Див. документацію з переконфігурації etcd для інформації про те, як додавати учасників у наявний кластер.

Відновлення кластера etcd

etcd підтримує відновлення зі знімків, які були створені з процесу etcd версії major.minor. Відновлення версії з іншої версії патча etcd також підтримується. Операція відновлення використовується для відновлення даних несправного кластера.

Перед початком операції відновлення повинен бути наявний файл знімка. Це може бути файл знімка з попередньої операції резервного копіювання або теки даних, що залишилась.

Під час відновлення кластера використовуючи etcdutl використовуйте опцію --data-dir, щоб вказати, у яку теку слід відновити кластер:

etcdutl --data-dir <data-dir-location> snapshot restore snapshot.db

де <data-dir-location> — це тека, яка буде створена під час процесу відновлення.

У наведеному нижче прикладі показано використання інструмента etcdctl для операції відновлення:

export ETCDCTL_API=3
etcdctl --data-dir <data-dir-location> snapshot restore snapshot.db

Якщо <data-dir-location> є тою самою текою, що й раніше, видаліть її та зупиніть процес etcd перед відновленням кластера. В іншому випадку, змініть конфігурацію etcd і перезапустіть процес etcd після відновлення, щоб він використовував нову теку даних: спочатку змініть /etc/kubernetes/manifests/etcd.yaml у volumes.hostPath.path для name: etcd-data на <data-dir-location>, потім виконайте kubectl -n kube-system delete pod <name-of-etcd-pod> або ystemctl restart kubelet.service (або обидві команди).

Для отримання додаткової інформації та прикладів відновлення кластера з файлу знімка, див. документацію з відновлення після збою etcd.

Якщо доступні URL-адреси відновленого кластера відрізняються від попереднього кластера, сервер API Kubernetes повинен бути відповідно переконфігурований. У цьому випадку перезапустіть сервери API Kubernetes з прапорцем --etcd-servers=$NEW_ETCD_CLUSTER замість прапорця --etcd-servers=$OLD_ETCD_CLUSTER. Замініть $NEW_ETCD_CLUSTER та $OLD_ETCD_CLUSTER на відповідні IP-адреси. Якщо перед кластером etcd використовується балансувальник навантаження, можливо, потрібно оновити балансувальник навантаження.

Якщо більшість членів etcd є остаточно несправними, кластер etcd вважається несправним. У цьому сценарії Kubernetes не може вносити зміни у свій поточний стан. Хоча заплановані Podʼи можуть продовжувати працювати, нові Podʼи не можуть бути заплановані. У таких випадках відновіть кластер etcd та, можливо, переконфігуруйте сервери API Kubernetes, щоб усунути проблему.

Оновлення кластерів etcd

Для отримання додаткових відомостей щодо оновлення etcd дивіться документацію з оновлення etcd.

Обслуговування кластерів etcd

Для отримання додаткових відомостей щодо обслуговування etcd дивіться документацію з обслуговування etcd.

Дефрагментація кластера

Дефрагментація є дорогою операцією, тому її слід виконувати якомога рідше. З іншого боку, також необхідно переконатися, що жоден з учасників etcd не перевищить квоту зберігання. Проєкт Kubernetes рекомендує, що при виконанні дефрагментації ви використовували інструмент, такий як etcd-defrag.

Ви також можете запускати інструмент дефрагментації як Kubernetes CronJob, щоб переконатися, що дефрагментація відбувається регулярно. Дивіться etcd-defrag-cronjob.yaml для отримання деталей.

4.2.31 - Резервування обчислювальних ресурсів для системних служб

Вузли Kubernetes можуть бути заплановані на Capacity. Podʼи можуть використовувати типово всю доступну місткість на вузлі. Це проблема, оскільки на вузлах зазвичай працює досить багато системних служб, які забезпечують операційну систему та сам Kubernetes. Якщо не виділити ресурси для цих системних служб, Podʼи та системні служби конкурують за ресурси, що призводить до проблем з вичерпання ресурсів на вузлі.

kubelet надає можливість під назвою 'Node Allocatable', яка допомагає резервувати обчислювальні ресурси для системних служб. Kubernetes рекомендує адміністраторам кластера налаштовувати 'Node Allocatable' на основі щільності робочого навантаження на кожному вузлі.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Ви можете налаштувати kubelet за допомогою параметрів конфігурації використовуючи конфігураційний файл kubelet.

Node Allocatable

ємність вузла

'Виділення' (Allocatable) на вузлі Kubernetes визначається як обсяг обчислювальних ресурсів, які доступні для Podʼів. Планувальник не надає перевищення обсягу 'Виділення'. Зараз підтримуються 'CPU', 'memory' та 'ephemeral-storage'.

Node Allocatable експонується як частина обʼєкта v1.Node в API та як частина kubectl describe node в CLI.

Ресурси можуть бути зарезервовані для двох категорій системних служб в kubelet.

Увімкнення QoS та cgroups на рівні Pod

Для належного застосування обмежень на вузлі виділення ресурсів вузлові вам потрібно увімкнути нову ієрархію cgroup за допомогою параметру налаштувань cgroupsPerQOS. Цей параметр є типово увімкненим. Коли він увімкнений, kubelet буде розташовувати всі Podʼи кінцевих користувачів в ієрархії cgroup, керованій kubelet.

Налаштування драйвера cgroup

kubelet підтримує маніпулювання ієрархією cgroup на хості за допомогою драйвера cgroup. Драйвер налаштовується за допомогою параметра cgroupDriver.

Підтримувані значення наступні:

  • cgroupfs — це типовий драйвер, який виконує пряме маніпулювання файловою системою cgroup на хості для управління пісочницями cgroup.
  • systemd — це альтернативний драйвер, який управляє пісочницями cgroup за допомогою тимчасових сегментів для ресурсів, які підтримуються цією системою ініціалізації.

Залежно від конфігурації відповідного контейнерного середовища, оператори можуть вибрати певний драйвер cgroup, щоб забезпечити належну роботу системи. Наприклад, якщо оператори використовують драйвер cgroup systemd, наданий контейнерним середовищем containerd, kubelet повинен бути налаштований на використання драйвера cgroup systemd.

Kube Reserved

  • KubeletConfiguration Setting: kubeReserved: {}. Example value {cpu: 100m, memory: 100Mi, ephemeral-storage: 1Gi, pid=1000}
  • KubeletConfiguration Setting: kubeReservedCgroup: ""

kubeReserved призначено для захоплення резервування ресурсів для системних демонів Kubernetes, таких як kubelet, container runtime тощо. Він не призначений для резервування ресурсів для системних служб, які запускаються як Podʼи. kubeReserved зазвичай є функцією pod density на вузлах.

Крім cpu, memory та ephemeral-storage, можна вказати pid, щоб зарезервувати вказану кількість ідентифікаторів процесів для системних демонів Kubernetes.

Для необовʼязкового застосування kubeReserved до системних демонів Kubernetes вкажіть батьківську контрольну групу для демонів kube як значення параметра kubeReservedCgroup та додайте kube-reserved до enforceNodeAllocatable.

Рекомендується розміщувати системні демони Kubernetes під верхньою контрольною групою (runtime.slice на машинах з systemd, наприклад). Кожен системний демон повинен ідеально працювати у власній дочірній контрольній групі. Докладнішу інформацію про рекомендовану ієрархію контрольних груп дивіться у пропозиції дизайну.

Зверніть увагу, що Kubelet не створює kubeReservedCgroup, якщо він не існує. Kubelet не запуститься, якщо вказано недійсну контрольну групу. З драйвером cgroup systemd вам слід дотримуватися певного шаблону для імені контрольної групи, яку ви визначаєте: імʼя повинно бути значенням, яке ви встановлюєте для kubeReservedCgroupp, з додаванням .slice.

System Reserved

  • KubeletConfiguration Setting: systemReserved: {}. Example value {cpu: 100m, memory: 100Mi, ephemeral-storage: 1Gi, pid=1000}
  • KubeletConfiguration Setting: systemReservedCgroup: ""

systemReserved призначено для захоплення резервування ресурсів для системних служб операційної системи, таких як sshd, udev і т. д. systemReserved повинно резервувати memory для kernel, оскільки памʼять kernel наразі не враховується для Podʼів у Kubernetes. Рекомендується також резервувати ресурси для сеансів входу користувача (user.slice у світі systemd).

Крім cpu, memory та ephemeral-storage, можна вказати pid, щоб зарезервувати вказану кількість ідентифікаторів процесів для системних служб операційної системи.

Для необовʼязкового застосування systemReserved до системних служб вкажіть батьківську контрольну групу для системних служб операційної системи як значення параметра systemReservedCgroup та додайте system-reserved до enforceNodeAllocatable.

Рекомендується розміщувати системні служби операційної системи під верхньою контрольною групою (system.slice на машинах з systemd, наприклад).

Зверніть увагу, що kubelet не створює systemReservedCgroup, якщо він не існує. kubelet відмовить у запуску, якщо вказано недійсну контрольну групу. З драйвером cgroup systemd вам слід дотримуватися певного шаблону для імені контрольної групи, яку ви визначаєте: імʼя повинно бути значенням, яке ви встановлюєте для systemReservedCgroup, з додаванням .slice.

Явно зарезервований список CPU

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.17 [stable]

Параметр KubeletConfiguration Setting: reservedSystemCPUs:. Наприклад: 0-3

reservedSystemCPUs призначено для визначення явного набору CPU для системних служб операційної системи та системних служб Kubernetes. reservedSystemCPUs призначений для систем, які не мають наміру визначати окремі верхні рівні контрольні групи для системних служб операційної системи та системних служб Kubernetes з урахуванням ресурсу cpuset. Якщо Kubelet не має kubeReservedCgroup та systemReservedCgroup, явний набір cpuset, наданий reservedSystemCPUs, переважатиме над CPU, визначеними параметрами kubeReservedCgroup та systemReservedCgroup.

Ця опція спеціально розроблена для випадків використання в телекомунікаціях/NFV, де неконтрольовані переривання/таймери можуть впливати на продуктивність робочого навантаження. Ви можете використовувати цю опцію для визначення явного набору cpuset для системних/кластерних служб та переривань/таймерів, щоб решта процесорів у системі могли використовуватися виключно для робочих навантажень, з меншим впливом неконтрольованих переривань/таймерів. Щоб перенести системні служби, системні служби Kubernetes та переривання/таймери до явного набору cpuset, визначеного цією опцією, слід використовувати інші механізми поза Kubernetes. Наприклад: у CentOS це можна зробити за допомогою інструменту tuned.

Пороги виселення

Параметр KubeletConfiguration: evictionHard: {memory.available: "100Mi", nodefs.available: "10%", nodefs.inodesFree: "5%", imagefs.available: "15%"}. Наприклад: {memory.available: "<500Mi"}

Нестача памʼяті на рівні вузла призводить до System OOMs, що впливає на весь вузол та всі Podʼи, що працюють на ньому. Вузли можуть тимчасово вийти з ладу, поки памʼять не буде відновлена. Щоб уникнути (або зменшити ймовірність) System OOMs, kubelet надає управління ресурсами. Виселення підтримується тільки для memory та ephemeral-storage. Резервуючи певний обсяг памʼяті за допомогою параметра evictionHard, kubelet намагається виселити Podʼи, коли доступність памʼяті на вузлі впаде нижче зарезервованого значення. Гіпотетично, якщо системні служби не існують на вузлі, Podʼи не можуть використовувати більше, ніж capacity - eviction-hard. З цієї причини ресурси, зарезервовані для виселень, не доступні для Podʼів.

Застосування Node Allocatable

KubeletConfiguration setting: enforceNodeAllocatable: [pods]. Наприклад: [pods,system-reserved,kube-reserved]

Планувальник розглядає 'Allocatable' як доступну capacity для Podʼів.

kubelet типово застосовує 'Allocatable' на всіх Podʼах. Застосування виконується шляхом видалення Podʼів, коли загальне використання у всіх Podʼах перевищує 'Allocatable'. Додаткові відомості про політику виселення можна знайти на сторінці Виселення внаслідок тиску на вузол. Це застосування контролюється, вказуючи значення pods для параметра enforceNodeAllocatable.

Необовʼязково, kubelet можна змусити застосовувати kubeReserved та systemReserved, вказавши значення kube-reserved та system-reserved у в одному і тому ж параметрі. Зверніть увагу, що для застосування kubeReserved або systemReserved, потрібно вказати kubeReservedCgroup або ystemReservedCgroup відповідно.

Загальні настанови

Очікується, що системні служби будуть оброблятися аналогічно гарантованим Podʼам. Системні служби можуть розширюватися в межах своїх обмежувальних контрольних груп, і цією поведінкою потрібно керувати як частиною розгортань Kubernetes. Наприклад, kubelet повинен мати свою власну контрольну групу і ділити ресурси kubeReserved з контейнерним середовищем. Однак Kubelet не може розширюватися і використовувати всі доступні ресурси вузла, якщо застосовується kubeReserved.

Будьте особливо обережні при застосуванні резервування systemReserved, оскільки це може призвести до нестачі ресурсів CPU для критичних системних служб, припинення роботи через нестачу памʼяті (OOM) або неможливості форка на вузлі. Рекомендація полягає в застосуванні systemReserved лише у випадку, якщо користувач детально проаналізував свої вузли, щоб надати точні оцінки та має впевненість у своїй здатності відновитися, якщо будь-який процес у цій групі буде примусово завершений через брак памʼяті.

  • Спочатку застосовуйте 'Allocatable' на Pod.
  • Як тільки буде встановлено достатньо моніторингу та попереджень для відстеження системних служб kube, спробуйте застосувати kubeReserved на основі використання евристик.
  • Якщо це абсолютно необхідно, з часом застосуйте systemReserved.

Вимоги до ресурсів системних служб kube можуть зростати з часом з введенням все більшої кількості функцій. З часом проєкт Kubernetes буде намагатися знизити використання системних служб вузла, але зараз це не пріоритет. Так що очікуйте зниження доступної місткості Allocatable у майбутніх версіях.

Приклад сценарію

Ось приклад для ілюстрації обчислення виділення ресурсів вузла:

  • Вузол має 32Гб памʼяті, 16 ЦП і 100Гб сховища
  • kubeReserved встановлено у {cpu: 1000m, memory: 2Gi, ephemeral-storage: 1Gi}
  • systemReserved встановлено у {cpu: 500m, memory: 1Gi, ephemeral-storage: 1Gi}
  • evictionHard встановлено у {memory.available: "<500Mi", nodefs.available: "<10%"}

У цьому сценарії "Allocatable" складатиме 14,5 ЦП, 28,5Гб памʼяті та 88Гб локального сховища. Планувальник забезпечує, що загальна памʼять запитів у всіх Podʼів на цьому вузлі не перевищує 28,5Гб, а сховище не перевищує 88Гб. Kubelet виселяє Podʼи, коли загальне використання памʼяті у всіх Podʼах перевищує 28,5Гб, або якщо загальне використання диска перевищує 88Гб. Якщо всі процеси на вузлі використовують як можна більше ЦП, Podʼи разом не можуть використовувати більше ніж 14,5 ЦП.

Якщо kubeReserved та/або systemReserved не застосовується, і системні служби перевищують своє резервування, kubelet виводить Podʼи, коли загальне використання памʼяті вузла вище 31,5Гб або storage перевищує 90Гб.

4.2.32 - Запуск компонентів вузла Kubernetes користувачем без прав root

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.22 [alpha]

У цьому документі описано, як запустити компоненти вузла Kubernetes, такі як kubelet, CRI, OCI та CNI, без прав root, використовуючи простір імен користувача.

Ця техніка також відома як rootless mode.

Перш ніж ви розпочнете

Версія вашого Kubernetes сервера має бути не старішою ніж 1.22. Для перевірки версії введіть kubectl version.

Запуск Kubernetes в Rootless Docker або Rootless Podman

kind

kind підтримує запуск Kubernetes в середовищі Rootless Docker або Rootless Podman.

Див. Запуск kind з Rootless Docker.

minikube

minikube також підтримує запуск Kubernetes в середовищі Rootless Docker або Rootless Podman.

Див. документацію Minikube:

Запуск Kubernetes всередині непривілейованих контейнерів

sysbox

Sysbox — це відкрите програмне забезпечення для виконання контейнерів (подібне до "runc"), яке підтримує запуск робочих навантажень на рівні системи, таких як Docker та Kubernetes, всередині непривілейованих контейнерів, ізольованих за допомогою просторів користувачів Linux.

Дивіться Sysbox Quick Start Guide: Kubernetes-in-Docker для отримання додаткової інформації.

Sysbox підтримує запуск Kubernetes всередині непривілейованих контейнерів без потреби в Cgroup v2 і без використання KubeletInUserNamespace. Він досягає цього за допомогою розкриття спеціально створених файлових систем /proc та /sys всередині контейнера, а також кількох інших передових технік віртуалізації операційної системи.

Запуск Rootless Kubernetes безпосередньо на хості

K3s

K3s експериментально підтримує режим без root-прав.

Дивіться Запуск K3s у режимі Rootless для використання.

Usernetes

Usernetes — це референсний дистрибутив Kubernetes, який може бути встановлений у теці $HOME без привілеїв root.

Usernetes підтримує як containerd, так і CRI-O як середовище виконання контейнерів CRI. Usernetes підтримує багатовузлові кластери з використанням Flannel (VXLAN).

Дивіться репозиторій Usernetes для використання.

Ручне розгортання вузла, який використовує kubelet в просторі користувача

У цьому розділі надаються вказівки для запуску Kubernetes у просторі користувача вручну.

Створення простору користувача

Першим кроком є створення простору користувача.

Якщо ви намагаєтеся запустити Kubernetes в контейнері з простором користувача, такому як Rootless Docker/Podman або LXC/LXD, ви готові та можете перейти до наступного підрозділу.

Інакше вам доведеться створити простір користувача самостійно, викликавши unshare(2) з CLONE_NEWUSER.

Простір користувача також можна відокремити за допомогою інструментів командного рядка, таких як:

Після відокремлення простору користувача вам також доведеться відокремити інші простори імен, такі як простір імен монтування.

Вам не потрібно викликати chroot() або pivot_root() після відокремлення простору імен монтування, однак вам потрібно буде монтувати записувані файлові системи у кількох теках в просторі імен.

Принаймні, наступні теки повинні бути записуваними в просторі імен (не поза простором імен):

  • /etc
  • /run
  • /var/logs
  • /var/lib/kubelet
  • /var/lib/cni
  • /var/lib/containerd (для containerd)
  • /var/lib/containers (для CRI-O)

Створення делегованого дерева cgroup

Крім простору користувача, вам також потрібно мати записуване дерево cgroup з cgroup v2.

Якщо ви намагаєтеся запустити Kubernetes у Rootless Docker/Podman або LXC/LXD на хості на основі systemd, у вас все готове.

У противному вам доведеться створити службу systemd з властивістю Delegate=yes, щоб делегувати дерево cgroup з правами на запис.

На вашому вузлі система systemd вже повинна бути налаштована на дозвіл делегування; для отримання докладнішої інформації дивіться cgroup v2 в документації Rootless Containers.

Налаштування мережі

Простір імен мережі компонентів вузла повинен мати не-loopback інтерфейс, який, наприклад, може бути налаштований з використанням slirp4netns, VPNKit, або lxc-user-nic(1).

Простори імен мережі Podʼів можна налаштувати за допомогою звичайних втулків CNI. Для мережі з багатьма вузлами відомо, що Flannel (VXLAN, 8472/UDP) працює.

Порти, такі як порт kubelet (10250/TCP) і порти служби NodePort, повинні бути викриті з простору імен мережі вузла на хост зовнішнім перенаправлювачем портів, таким як RootlessKit, slirp4netns, або socat(1).

Ви можете використовувати перенаправлювач портів від K3s. Див. Запуск K3s в режимі без root-прав для отримання докладнішої інформації. Реалізацію можна знайти в пакунку pkg/rootlessports k3s.

Налаштування CRI

Kubelet покладається на середовище виконання контейнерів. Ви повинні розгорнути середовище виконання контейнерів, таке як containerd або CRI-O, і переконатися, що воно працює у просторі користувача до запуску kubelet.

Запуск CRI втулка containerd в просторі користувача підтримується з версії containerd 1.4.

Запуск containerd у просторі користувача вимагає наступних налаштувань.

version = 2

[plugins."io.containerd.grpc.v1.cri"]
# Вимкнути AppArmor
  disable_apparmor = true
# Ігнорувати помилку під час встановлення oom_score_adj
  restrict_oom_score_adj = true
# Вимкнути контролер hugetlb cgroup v2 (тому що systemd не підтримує делегування контролера hugetlb)
  disable_hugetlb_controller = true

[plugins."io.containerd.grpc.v1.cri".containerd]
# Можливий також використання non-fuse overlayfs для ядра >= 5.11, але потребує вимкненого SELinux
  snapshotter = "fuse-overlayfs"

[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
# Ми використовуємо cgroupfs, який делегується системою systemd, тому ми не використовуємо драйвер SystemdCgroup
# (якщо ви не запускаєте іншу систему systemd у просторі імен)
  SystemdCgroup = false

Типовий шлях конфігураційного файлу — /etc/containerd/config.toml. Шлях можна вказати з containerd -c /шлях/до/конфігураційного/файлу.toml.

Запуск CRI-O у просторі користувача підтримується з версії CRI-O 1.22.

CRI-O вимагає, щоб була встановлена змінна середовища _CRIO_ROOTLESS=1.

Також рекомендуються наступні налаштування:

[crio]
  storage_driver = "overlay"
# Можливий також використання non-fuse overlayfs для ядра >= 5.11, але потребує вимкненого SELinux
  storage_option = ["overlay.mount_program=/usr/local/bin/fuse-overlayfs"]

[crio.runtime]
# Ми використовуємо cgroupfs, який делегується системою systemd, тому ми не використовуємо драйвер "systemd"
# (якщо ви не запускаєте іншу систему systemd у просторі імен)
  cgroup_manager = "cgroupfs"

Типовий шлях конфігураційного файлу — /etc/crio/crio.conf. Шлях можна вказати з crio --config /шлях/до/конфігураційного/файлу/crio.conf.

Налаштування kubelet

Запуск kubelet у просторі користувача вимагає наступної конфігурації:

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
featureGates:
  KubeletInUserNamespace: true
# Ми використовуємо cgroupfs, який делегується системою systemd, тому ми не використовуємо драйвер "systemd"
# (якщо ви не запускаєте іншу систему systemd у просторі імен)
cgroupDriver: "cgroupfs"

Коли увімкнено KubeletInUserNamespace, kubelet ігнорує помилки, які можуть виникнути під час встановлення наступних значень sysctl на вузлі.

  • vm.overcommit_memory
  • vm.panic_on_oom
  • kernel.panic
  • kernel.panic_on_oops
  • kernel.keys.root_maxkeys
  • kernel.keys.root_maxbytes.

У просторі користувача kubelet також ігнорує будь-яку помилку, яка виникає при спробі відкрити /dev/kmsg. Цей feature gate також дозволяє kube-proxy ігнорувати помилку під час встановлення RLIMIT_NOFILE.

KubeletInUserNamespace був введений у Kubernetes v1.22 зі статусом "alpha".

Запуск kubelet у просторі користувача без використання цього feature gate також можливий, шляхом монтування спеціально створеного файлової системи proc (як це робить Sysbox), але це не є офіційно підтримуваним.

Налаштування kube-proxy

Запуск kube-proxy у просторі користувача вимагає наступної конфігурації:

apiVersion: kubeproxy.config.k8s.io/v1alpha1
kind: KubeProxyConfiguration
mode: "iptables" # або "userspace"
conntrack:
# Пропустити встановлення значення sysctl "net.netfilter.nf_conntrack_max"
  maxPerCore: 0
# Пропустити встановлення "net.netfilter.nf_conntrack_tcp_timeout_established"
  tcpEstablishedTimeout: 0s
# Пропустити встановлення "net.netfilter.nf_conntrack_tcp_timeout_close"
  tcpCloseWaitTimeout: 0s

Застереження

  • Більшість "нелокальних" драйверів томів, таких як nfs та iscsi, не працюють. Відомо, що працюють локальні томи, такі як local, hostPath, emptyDir, configMap, secret та downwardAPI.

  • Деякі втулки CNI можуть не працювати. Відомо, що працює Flannel (VXLAN).

Для отримання додаткової інформації з цього питання, див. сторінку Застереження та майбутня робота на веб-айті rootlesscontaine.rs.

Дивіться також

4.2.33 - Безпечне очищення вузла

Ця сторінка показує, як безпечно очистити вузол, опційно дотримуючись PodDisruptionBudget, який ви визначили.

Перш ніж ви розпочнете

Це завдання передбачає, що ви виконали такі попередні умови:

  1. Вам не потрібно, щоб ваші застосунки були високодоступними під час очищення вузла, або
  2. Ви прочитали про концепцію PodDisruptionBudget та налаштували PodDisruptionBudget для застосунків, які їх потребують.

(Необовʼязково) Налаштування бюджету відмови

Щоб забезпечити доступність ваших робочих навантажень під час технічного обслуговування, ви можете налаштувати PodDisruptionBudget.

Якщо доступність важлива для будь-яких застосунків, які запускаються або можуть запускатися на вузлах, які ви очищуєте, спочатку налаштуйте PodDisruptionBudget, а потім продовжуйте виконувати цей посібник.

Рекомендується встановити AlwaysAllow Політика виселення несправного Podʼа для PodDisruptionBudgets, щоб підтримувати виселення погано працюючих застосунків під час очищення вузла. Стандартна поведінка полягає в очікуванні на те, щоб Podʼи застосунків стали справними, перш ніж можна буде продовжити очищення.

Використання kubectl drain для очищення вузла

Ви можете використовувати kubectl drain для безпечного виселення всіх ваших Podʼів з вузла перед тим, як ви будете виконувати обслуговування вузла (наприклад, оновлення ядра, обслуговування обладнання тощо). Безпечні виселення дозволяють контейнерам Podʼів належним чином завершувати роботу і дотримуватись PodDisruptionBudgets, які ви визначили.

Коли kubectl drain успішно завершується, це означає, що всі Podʼи (крім тих, які виключені, як описано в попередньому абзаці) безпечно виселені (дотримуючись бажаного періоду належного завершення роботи та PodDisruptionBudget, який ви визначили). Тоді безпечно вимкніть вузол, вимкнувши його фізичний компʼютер або, якщо ви працюєте на хмарній платформі, видаливши його віртуальну машину.

Спочатку визначте імʼя вузла, який ви хочете очистити. Ви можете перелічити всі вузли у своєму кластері за допомогою

kubectl get nodes

Далі скажіть Kubernetes очистити вузол:

kubectl drain --ignore-daemonsets <імʼя вузла>

Якщо є Podʼи, керовані DaemonSet, вам потрібно вказати --ignore-daemonsets в kubectl, щоб успішно очистити вузол. Підкоманда kubectl drain сама по собі насправді не очищує вузол від його Podʼів DaemonSet: контролер DaemonSet (частина контролера управління) негайно замінює відсутні Podʼи новими еквівалентними Podʼами. Контролер DaemonSet також створює Podʼи, які ігнорують taint, що перешкоджають плануванню, що дозволяє новим Podʼам запуститися на вузлі, який ви очистили.

Після того, як процес завершиться (без помилки), ви можете безпечно вимкнути вузол (або еквівалентно, якщо ви працюєте на хмарній платформі, видалити віртуальну машину, на якій працює вузол). Якщо ви залишите вузол у кластері під час операції обслуговування, вам потрібно виконати

kubectl uncordon <імʼя вузла>

після того, як ви дасте цю команду Kubernetes, він може продовжити планування нових Podʼів на вузол.

Очищення кількох вузлів паралельно

Команду kubectl drain слід використовувати тільки для одного вузла за раз. Однак ви можете запускати кілька команд kubectl drain для різних вузлів паралельно, в різних терміналах або у фоні. Декілька команд очищення, які працюють паралельно, все одно дотримуються PodDisruptionBudget, який ви вказуєте.

Наприклад, якщо у вас є StatefulSet із трьома репліками та ви встановили PodDisruptionBudget для цього набору, вказуючи minAvailable: 2, kubectl drain видаляє тільки Pod з StatefulSet, якщо всі три репліки Pod є справними; якщо дати декілька команд паралельно, Kubernetes дотримується PodDisruptionBudget та забезпечує, що в будь-який момент часу лише один (обчислюється як replicas - minAvailable) Pod недоступний. Будь-які очищення, які призведуть до того, що кількість справних реплік падає нижче визначеного бюджету, блокуються.

API Eviction

Якщо ви не бажаєте використовувати kubectl drain (наприклад, для уникнення виклику зовнішньої команди або для отримання більш детального керування процесом виселення Podʼа), ви також можете програмно викликати виселення, використовуючи API Eviction.

Для отримання додаткової інформації див. Виселення, ініційоване API.

Що далі

4.2.34 - Захист кластера

У цьому документі розглядаються теми, повʼязані з захистом кластера від випадкового або зловмисного доступу та надаються загальні рекомендації безпеки.

Перш ніж ви розпочнете

  • Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

    Для перевірки версії введіть kubectl version.

Контроль доступу до API Kubernetes

Оскільки Kubernetes повністю заснований на API, контроль та обмеження, хто може мати доступ до кластера та які дії вони можуть виконувати, є першою лінією захисту.

Використання Transport Layer Security (TLS) для всього трафіку API

Kubernetes очікує, що всі комунікації API в кластері будуть типово зашифровані за допомогою TLS, і більшість методів встановлення дозволять створювати необхідні сертифікати та розподіляти їх між компонентами кластера. Зверніть увагу, що деякі компоненти та методи встановлення можуть дозволяти локальні порти через HTTP, і адміністраторам варто ознайомитися з налаштуваннями кожного компонента для ідентифікації потенційно незахищеного трафіку.

Автентифікація API

Виберіть механізм автентифікації для використання API-серверами, який відповідає загальним сценаріям доступу при встановленні кластера. Наприклад, невеликі, однокористувацькі кластери можуть бажати використовувати простий підхід з використанням сертифікатів або статичних токенів Bearer. Більші кластери можуть бажати інтегрувати наявний сервер OIDC або LDAP, який дозволяє розподіляти користувачів на групи.

Всі клієнти API повинні бути автентифіковані, навіть ті, що є частиною інфраструктури, такі як вузли, проксі, планувальник та втулки томів. Зазвичай ці клієнти є сервісними обліковими записами або використовують сертифікати клієнта x509, і вони створюються автоматично при запуску кластера або налаштовуються як частина встановлення кластера.

Для отримання додаткової інформації звертайтеся до документації з автентифікації.

Авторизація API

Після автентифікації кожен виклик API також повинен пройти перевірку авторизації. Kubernetes має вбудований компонент контролю доступу на основі ролей (Role-Based Access Control (RBAC)), який зіставляє користувача або групу набору дозволів, згрупованих за ролями. Ці дозволи поєднують дії (отримати, створити, видалити) з ресурсами (Podʼи, служби, вузли) і можуть бути обмежені простором імен або розгортанням кластера. Доступні набори стандартних ролей, які надають розумне розділення відповідальності залежно від дій, які може бажати виконати клієнт. Рекомендується використовувати авторизатори Node та RBAC разом з втулком входу NodeRestriction.

Так само як і з автентифікацією, для менших кластерів можуть бути відповідні прості та загальні ролі, але зі збільшенням кількості користувачів, які взаємодіють з кластером, може знадобитися розділити команди на окремі простори імен з більш обмеженими ролями.

При авторизації важливо розуміти, як оновлення одного обʼєкта може призвести до дій в інших місцях. Наприклад, користувач не зможе створити Podʼи безпосередньо, але дозволивши їм створювати Deployment, що створює Podʼи для них, дозволить їм створювати ці Podʼи опосередковано. Так само, видалення вузла з API призведе до припинення роботи Podʼів, запланованих на цей вузол, і їх повторного створення на інших вузлах. Стандартні ролі являють собою компроміс між гнучкістю та загальними випадками використання, але більш обмежені ролі повинні бути уважно переглянуті, щоб запобігти випадковому підвищенню привілеїв. Якщо стандартні ролі не відповідають вашим потребам, ви можете створити ролі, специфічні для вашого випадку використання.

Для отримання додаткової інформації звертайтеся до розділу довідки з авторизації.

Контроль доступу до Kubelet

Kubelet експонує HTTPS-точки доступу, які надають потужний контроль над вузлом та контейнерами. Типово Kubelet дозволяє неавтентифікований доступ до цього API.

Операційні кластери повинні увімкнути автентифікацію та авторизацію Kubelet.

Для отримання додаткової інформації звертайтеся до розділу довідки з автентифікації/авторизації Kubelet.

Керування можливостями робочого навантаження або користувача під час виконання

Авторизація в Kubernetes має високий рівень, спрямований на грубі дії з ресурсами. Більш потужні елементи керування існують як політики для обмеження за випадком використання того, як ці обʼєкти діють на кластер, себе та інші ресурси.

Обмеження використання ресурсів у кластері

Квоти ресурсів обмежують кількість або потужність виділених ресурсів для простору імен. Це найчастіше використовується для обмеження обсягу процесора, памʼяті або постійного дискового простору, який може виділятися простору імен, але також може контролювати кількість Podʼів, Serviceʼів або томів, що існують у кожному просторі імен.

Діапазони обмежень обмежують максимальний або мінімальний розмір деяких з вищезазначених ресурсів, щоб уникнути можливості користувачів запитувати надмірно високі або низькі значення для часто зарезервованих ресурсів, таких як памʼять, або надавати типові значення, коли вони не вказані.

Керування привілеями, з якими працюють контейнери

В описі Podʼа міститься контекст безпеки, який дозволяє запитувати доступ до виконання від імені конкретного користувача Linux на вузлі (наприклад, root), доступ до виконання з підвищеними привілеями або доступ до мережі хосту та інші елементи керування, які інакше дозволили б йому працювати без обмежень на вузлі хосту.

Ви можете налаштувати допуски безпеки Pod, щоб забезпечити використання певного стандарту безпеки Pod у просторі імен або виявити порушення.

Загалом, більшість робочих навантажень застосунків потребують обмеженого доступу до ресурсів хосту, щоб вони могли успішно працювати як процес root (uid 0) без доступу до інформації про хост. Однак, враховуючи привілеї, повʼязані з користувачем root, слід робити контейнери застосунків такими, що не вимагають прав root для виконання. Так само адміністратори, які бажають запобігти втечі клієнтських застосунків з їхніх контейнерів, повинні застосувати стандарт безпеки Pod Baseline або Restricted.

Запобігання завантаженню небажаних модулів ядра контейнерами

Ядро Linux автоматично завантажує модулі ядра з диска за потребою в певних обставинах, наприклад, коли пристрій приєднаний або файлова система змонтована. Особливо актуальним для Kubernetes є те, що навіть непривілейовані процеси можуть спричинити завантаження певних модулів, повʼязаних з мережевими протоколами, просто створюючи сокет відповідного типу. Це може дозволити зловмиснику використовувати дірку в безпеці ядра, щодо якої адміністратор має припущення, що вона не використовується.

Щоб запобігти автоматичному завантаженню конкретних модулів, ви можете деінсталювати їх з вузла або додати правила для їх блокування. У більшості дистрибутивів Linux ви можете це зробити, створивши файл, наприклад, /etc/modprobe.d/kubernetes-blacklist.conf, з таким вмістом:

# DCCP майже не потрібен, має кілька серйозних вразливостей
# і не знаходиться у доброму стані обслуговування.
blacklist dccp

# SCTP не використовується в більшості кластерів Kubernetes, і також мав
# вразливості в минулому.
blacklist sctp

Для більш загального блокування завантаження модулів можна використовувати Linux Security Module (наприклад, SELinux), щоб абсолютно відмовити контейнерам у дозволі module_request, запобігаючи ядру завантажувати модулі для контейнерів у будь-яких обставинах. (Podʼи все ще можуть використовувати модулі, які були завантажені вручну або модулі, які були завантажені ядром від імені якогось більш привілейованого процесу.)

Обмеження доступу до мережі

Мережеві політики для простору імен дозволяють авторам застосунків обмежувати, які Podʼи в інших просторах імен можуть отримувати доступ до Podʼів і портів у їхніх просторах імен. Багато з підтримуваних постачальників мережі Kubernetes зараз враховують мережеві політики.

Також можна використовувати квоти та діапазони обмежень, щоб контролювати, чи можуть користувачі запитувати порти вузла або послуги з балансування навантаження, що у багатьох кластерах може контролювати видимість застосунків цих користувачів поза межами кластера.

Додаткові захисти можуть бути доступні, які контролюють правила мережі на рівні втулка чи середовища, такі як брандмауери на рівні вузла, фізичне розділення вузлів кластера для запобігання звʼязку між ними або розширена політика мережевого зʼєднання.

Обмеження доступу до API метаданих хмари

Хмарні платформи (AWS, Azure, GCE і т. д.) часто надають доступ до служб метаданих локально на екземплярах обчислювальних потужностей. Типово ці API доступні Podʼам, що працюють на екземплярі, і можуть містити облікові дані хмари для цього вузла або дані про створення, такі як облікові дані kubelet. Ці облікові дані можуть бути використані для підвищення привілеїв всередині кластера або до інших хмарних служб за тим самим обліковим записом.

При запуску Kubernetes на хмарній платформі обмежуйте дозволи, надані обліковим записам екземплярів, використовуйте мережеві політики для обмеження доступу Podʼів до API метаданих та уникайте використання даних про створення для передачі секретів.

Керування того, до яких вузлів мають доступ Podʼи

Стандартно не має обмежень, щодо того, на яких вузлах може запускатися Pod. Kubernetes пропонує широкий набір політик для керування розміщенням Podʼів на вузлах та політику розміщення та виселення Podʼів на основі позначок, доступні для кінцевих користувачів. Для багатьох кластерів використання цих політик для розділення робочих навантажень може бути домовленістю, якої автори дотримуються або впроваджують через інструментарій.

Як адміністратор, бета-втулок обробки доспуску PodNodeSelector може бути використаний для примусового призначення Podʼів у межах стандартного простору імен або для вимоги до вказання певного селектора вузла, і якщо кінцеві користувачі не можуть змінювати простори імен, це може суттєво обмежити розміщення всіх Podʼів в певному робочому навантаженні.

Захист компонентів кластера від компрометації

У цьому розділі описані деякі загальні шаблони для захисту кластерів від компрометації.

Обмеження доступу до etcd

Права на запис до бази даних etcd для API еквівалентні отриманню root-прав на весь кластер, а доступ на читання може бути використаний для ескалації досить швидко. Адміністратори повинні завжди використовувати надійні облікові дані від серверів API до сервера etcd, такі як взаємна автентифікація за допомогою сертифікатів TLS клієнта, і часто рекомендується ізолювати сервери etcd за допомогою брандмауера, до яких можуть отримувати доступ лише сервери API.

Увімкнення логування аудиту

Audit logger є бета-функцією, яка записує дії, виконані API, для подальшого аналізу в разі компрометації. Рекомендується увімкнути логування аудиту та архівувати файл аудиту на захищеному сервері.

Обмеження доступу до альфа- або бета-функцій

Альфа- і бета-функції Kubernetes знаходяться в активній розробці і можуть мати обмеження або помилки, які призводять до вразливостей безпеки. Завжди оцінюйте цінність, яку можуть надати альфа- або бета-функції, у порівнянні з можливим ризиком для вашої безпеки. У разі сумнівів вимикайте функції, які ви не використовуєте.

Часто змінюйте облікові дані інфраструктури

Чим коротший термін дії Secret або облікового запису, тим складніше для зловмисника використати цей обліковий запис. Встановлюйте короткі терміни дії на сертифікати та автоматизуйте їх ротацію. Використовуйте постачальника автентифікації, який може контролювати терміни дії виданих токенів та використовуйте короткі терміни дії, де це можливо. Якщо ви використовуєте токени облікового запису служби в зовнішніх інтеграціях, плануйте часту ротацію цих токенів. Наприклад, як тільки завершиться фаза запуску, токен запуску, використаний для налаштування вузлів, повинен бути відкликаний або його запис авторизації скасований.

Перегляд інтеграцій сторонніх розробників перед їх включенням

Багато сторонніх інтеграцій до Kubernetes можуть змінювати профіль безпеки вашого кластера. При включенні інтеграції завжди переглядайте дозволи, які запитує розширення, перед наданням доступу. Наприклад, багато інтеграцій з безпеки можуть запитувати доступ до перегляду всіх секретів у вашому кластері, що фактично робить цей компонент адміністратором кластера. У разі сумнівів обмежте інтеграцію на роботу в одному просторі імен, якщо це можливо.

Компоненти, які створюють Podʼи, також можуть мати неочікувану потужність, якщо вони можуть робити це всередині просторів імен, таких як простір імен kube-system, оскільки ці Podʼи можуть отримати доступ до секретів облікових записів служб або працювати з підвищеними привілеями, якщо цим службовим обліковим записам надано доступ до дозвольних PodSecurityPolicies.

Якщо ви використовуєте Pod Security admission та дозволяєте будь-якому компоненту створювати Podʼи в межах простору імен, що дозволяє привілейовані Podʼи, ці Podʼи можуть мати здатність втікати зі своїх контейнерів і використовувати цей розширений доступ для підвищення своїх привілеїв.

Ви не повинні дозволяти ненадійним компонентам створювати Podʼи в будь-якому системному просторі імен (те, що починається з kube-) або в будь-якому просторі імен, де цей доступ дозволяє можливість підвищення привілеїв.

Шифрування секретів у спокої

Загалом, база даних etcd буде містити будь-яку інформацію, доступну через API Kubernetes і може надати зловмиснику значний обсяг інформації про стан вашого кластера. Завжди шифруйте свої резервні копії за допомогою розглянутого рішення для резервного копіювання та шифрування, і розгляньте можливість використання повного шифрування диска, де це можливо.

Kubernetes підтримує необовʼязкове шифрування у спокої для інформації в API Kubernetes. Це дозволяє вам забезпечити те, що при збереженні Kubernetes даних для обʼєктів (наприклад, обʼєктів Secret або ConfigMap), сервер API записує зашифроване представлення обʼєкта. Це шифрування означає, що навіть у того, хто має доступ до даних резервних копій etcd, не має можливості переглянути вміст цих обʼєктів. У Kubernetes 1.31 ви також можете шифрувати власні ресурси; шифрування в спокої для розширених API, визначених у визначеннях CustomResourceDefinitions, було додано в Kubernetes як частина випуску v1.26.

Отримання сповіщень про оновлення безпеки та повідомлення про вразливості

Приєднуйтесь до групи kubernetes-announce, щоб отримувати електронні листи про оголошення з питань безпеки. Див. сторінку повідомлень про безпеку для отримання додаткової інформації щодо повідомлення про вразливості.

Що далі

4.2.35 - Встановлення параметрів Kubelet через файл конфігурації

Перш ніж ви розпочнете

Деякі кроки на цій сторінці використовують інструмент jq. Якщо у вас немає jq, ви можете встановити його через отримання оновлень програм вашої операційної системи або завантажити з https://jqlang.github.io/jq/.

Деякі кроки також включають встановлення curl, який також можна встановити засобами встановлення програмного забезпечення вашої операційної системи.

Частину параметрів конфігурації kubelet можна встановити за допомогою конфігураційного файлу на диску, як альтернативу командним прапорцям.

Надання параметрів через файл конфігурації є рекомендованим підходом, оскільки це спрощує розгортання вузлів та управління конфігурацією.

Створіть файл конфігурації

Підмножина конфігурації kubelet, яку можна налаштувати через файл, визначається структурою KubeletConfiguration.

Файл конфігурації повинен бути у форматі JSON або YAML, який представляє параметри цієї структури. Переконайтеся, що у kubelet є права для читання файлу.

Ось приклад того, як може виглядати цей файл:

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
address: "192.168.0.8"
port: 20250
serializeImagePulls: false
evictionHard:
    memory.available:  "100Mi"
    nodefs.available:  "10%"
    nodefs.inodesFree: "5%"
    imagefs.available: "15%"

У цьому прикладі kubelet налаштовано з наступними параметрами:

  1. address: Kubelet буде доступний за IP-адресою 192.168.0.8.
  2. port: Kubelet буде слухати порт 20250.
  3. serializeImagePulls: Завантаження образів виконуватиметься паралельно.
  4. evictionHard: Kubelet буде виселяти Podʼи за однією з наступних умов:
    • Коли доступна памʼять вузла впаде нижче 100 МіБ.
    • Коли доступний простір основної файлової системи вузла менше 10%.
    • Коли доступний простір файлової системи образів менше 15%.
    • Коли більше ніж 95% inodes основної файлової системи вузла використано.

imagefs — це опціональна файлова система, яку середовища виконання контейнерів використовують для зберігання образів контейнерів та записуваних шарів контейнерів.

Запуск процесу kubelet, налаштованого через файл конфігурації

Запустіть kubelet з параметром --config, вказавши шлях до файлу конфігурації kubelet. Після цього kubelet завантажить свою конфігурацію з цього файлу.

Зверніть увагу, що параметри командного рядка, які стосуються того ж значення, що й файл конфігурації, перекриватимуть це значення. Це допомагає забезпечити зворотну сумісність з API командного рядка.

Також зверніть увагу, що відносні шляхи файлів у файлі конфігурації kubelet розглядаються відносно місця розташування файлу конфігурації kubelet, тоді як відносні шляхи в параметрах командного рядка розглядаються відносно поточної робочої теки kubelet.

Зауважте, що деякі типові значення відрізняються між параметрами командного рядка та файлом конфігурації kubelet. Якщо наданий параметр --config і значення не вказані через командний рядок, то застосовуються типові значення для версії KubeletConfiguration. У згаданому вище прикладі ця версія є kubelet.config.k8s.io/v1beta1.

Тека для файлів конфігурації kubelet

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.30 [beta]

Ви можете вказати теку конфігурації drop-in для kubelet. Стандартно kubelet не шукає файли конфігурації drop-in — ви повинні вказати шлях. Наприклад: --config-dir=/etc/kubernetes/kubelet.conf.d

Для Kubernetes v1.28 по v1.29 ви можете вказати лише --config-dir, якщо також встановите змінну середовища KUBELET_CONFIG_DROPIN_DIR_ALPHA для процесу kubelet (значення цієї змінної не має значення).

Kubelet обробляє файли у своїй теці конфігурації drop-in, сортуючи по повному імені файлу. Наприклад, 00-kubelet.conf обробляється першим, а потім перезаписується файлом з назвою 01-kubelet.conf.

Ці файли можуть містити часткові конфігурації, але не повинні бути не валідними та обовʼязково повинні включати метадані типу, зокрема apiVersion та kind. Перевірка виконується лише на кінцевій результівній структурі конфігурації, збереженій внутрішньо в kubelet. Це надає гнучкість в управлінні та злитті конфігурацій kubelet з різних джерел, запобігаючи небажаній конфігурації. Однак важливо зазначити, що поведінка варіюється залежно від типу даних поля конфігурації.

Різні типи даних у структурі конфігурації kubelet обʼєднуються по-різному. Дивіться посилання на довідку для отримання додаткової інформації.

Порядок обʼєднання конфігурації kubelet

При запуску kubelet обʼєднує конфігурацію з:

  • Feature gate, вказаних через командний рядок (найнижчий пріоритет).
  • Конфігурація kubelet.
  • Файли конфігурації drop-in, відповідно до порядку сортування.
  • Аргументи командного рядка, за винятком feature gate (найвищий пріоритет).

Перегляд конфігурації kubelet

Оскільки конфігурація тепер може бути розподілена у декілька файлів за допомогою цієї функції, якщо хтось хоче переглянути остаточну активовану конфігурацію, то вони можуть скористатися цими кроками для перегляду конфігурації kubelet:

  1. Запустіть проксі-сервер за допомогою команди kubectl proxy у вашому терміналі.

    kubectl proxy
    

    Це дозволить отримати вивід подібний до:

    Starting to serve on 127.0.0.1:8001
    
  2. Відкрийте інше вікно термінала і скористайтесь curl, щоб отримати конфігурацію kubelet. Замініть <node-name> на фактичне імʼя вашого вузла:

    curl -X GET http://127.0.0.1:8001/api/v1/nodes/<node-name>/proxy/configz | jq .
    
    {
      "kubeletconfig": {
        "enableServer": true,
        "staticPodPath": "/var/run/kubernetes/static-pods",
        "syncFrequency": "1m0s",
        "fileCheckFrequency": "20s",
        "httpCheckFrequency": "20s",
        "address": "192.168.1.16",
        "port": 10250,
        "readOnlyPort": 10255,
        "tlsCertFile": "/var/lib/kubelet/pki/kubelet.crt",
        "tlsPrivateKeyFile": "/var/lib/kubelet/pki/kubelet.key",
        "rotateCertificates": true,
        "authentication": {
          "x509": {
            "clientCAFile": "/var/run/kubernetes/client-ca.crt"
          },
          "webhook": {
            "enabled": true,
            "cacheTTL": "2m0s"
          },
          "anonymous": {
            "enabled": true
          }
        },
        "authorization": {
          "mode": "AlwaysAllow",
          "webhook": {
            "cacheAuthorizedTTL": "5m0s",
            "cacheUnauthorizedTTL": "30s"
          }
        },
        "registryPullQPS": 5,
        "registryBurst": 10,
        "eventRecordQPS": 50,
        "eventBurst": 100,
        "enableDebuggingHandlers": true,
        "healthzPort": 10248,
        "healthzBindAddress": "127.0.0.1",
        "oomScoreAdj": -999,
        "clusterDomain": "cluster.local",
        "clusterDNS": [
          "10.0.0.10"
        ],
        "streamingConnectionIdleTimeout": "4h0m0s",
        "nodeStatusUpdateFrequency": "10s",
        "nodeStatusReportFrequency": "5m0s",
        "nodeLeaseDurationSeconds": 40,
        "imageMinimumGCAge": "2m0s",
        "imageMaximumGCAge": "0s",
        "imageGCHighThresholdPercent": 85,
        "imageGCLowThresholdPercent": 80,
        "volumeStatsAggPeriod": "1m0s",
        "cgroupsPerQOS": true,
        "cgroupDriver": "systemd",
        "cpuManagerPolicy": "none",
        "cpuManagerReconcilePeriod": "10s",
        "memoryManagerPolicy": "None",
        "topologyManagerPolicy": "none",
        "topologyManagerScope": "container",
        "runtimeRequestTimeout": "2m0s",
        "hairpinMode": "promiscuous-bridge",
        "maxPods": 110,
        "podPidsLimit": -1,
        "resolvConf": "/run/systemd/resolve/resolv.conf",
        "cpuCFSQuota": true,
        "cpuCFSQuotaPeriod": "100ms",
        "nodeStatusMaxImages": 50,
        "maxOpenFiles": 1000000,
        "contentType": "application/vnd.kubernetes.protobuf",
        "kubeAPIQPS": 50,
        "kubeAPIBurst": 100,
        "serializeImagePulls": true,
        "evictionHard": {
          "imagefs.available": "15%",
          "memory.available": "100Mi",
          "nodefs.available": "10%",
          "nodefs.inodesFree": "5%"
        },
        "evictionPressureTransitionPeriod": "1m0s",
        "enableControllerAttachDetach": true,
        "makeIPTablesUtilChains": true,
        "iptablesMasqueradeBit": 14,
        "iptablesDropBit": 15,
        "featureGates": {
          "AllAlpha": false
        },
        "failSwapOn": false,
        "memorySwap": {},
        "containerLogMaxSize": "10Mi",
        "containerLogMaxFiles": 5,
        "configMapAndSecretChangeDetectionStrategy": "Watch",
        "enforceNodeAllocatable": [
          "pods"
        ],
        "volumePluginDir": "/usr/libexec/kubernetes/kubelet-plugins/volume/exec/",
        "logging": {
          "format": "text",
          "flushFrequency": "5s",
          "verbosity": 3,
          "options": {
            "json": {
              "infoBufferSize": "0"
            }
          }
        },
        "enableSystemLogHandler": true,
        "enableSystemLogQuery": false,
        "shutdownGracePeriod": "0s",
        "shutdownGracePeriodCriticalPods": "0s",
        "enableProfilingHandler": true,
        "enableDebugFlagsHandler": true,
        "seccompDefault": false,
        "memoryThrottlingFactor": 0.9,
        "registerNode": true,
        "localStorageCapacityIsolation": true,
        "containerRuntimeEndpoint": "unix:///var/run/crio/crio.sock"
      }
    }
    

Що далі

4.2.36 - Спільне використання кластера з просторами імен

Ця сторінка показує, як переглядати, працювати та видаляти простори імен. На сторінці також розказується, як використовувати простори імен Kubernetes для розділення вашого кластера.

Перш ніж ви розпочнете

Перегляд просторів імен

Перелік поточних просторів імен у кластері можна отримати за допомогою команди:

kubectl get namespaces
NAME              STATUS   AGE
default           Active   11d
kube-node-lease   Active   11d
kube-public       Active   11d
kube-system       Active   11d

Kubernetes запускається з чотирма просторами імен:

  • default — стандартний простір імен для обʼєктів без іншого простору імен.
  • kube-node-lease — цей простір імен містить обʼєкти Lease, повʼязані з кожним вузлом. Лізинги вузлів дозволяють kubelet надсилати пульси, щоб панель управління було в змозі виявляти збої вузлів.
  • kube-public — цей простір імен створюється автоматично і доступний для читання всіма користувачами (включаючи неавтентифікованих). Цей простір імен зазвичай зарезервований для використання у межах кластера, у випадках коли деякі ресурси мають бути відкриті та доступні для загального огляду у всьому кластері. Публічний аспект цього простору імен є лише конвенцією, а не вимогою.
  • kube-system — простір імен для обʼєктів, створених системою Kubernetes.

Також ви можете отримати інформацію про певний простір імен за допомогою команди:

kubectl get namespaces <name>

Або отримати детальну інформацію за допомогою:

kubectl describe namespaces <name>
Name:           default
Labels:         <none>
Annotations:    <none>
Status:         Active

No resource quota.

Resource Limits
 Type       Resource    Min Max Default
 ----       --------    --- --- -------
 Container  cpu         -   -   100m

Зверніть увагу, що ці деталі включають інформацію про квоти ресурсів (якщо вони є) та обмеження діапазону ресурсів.

Квота ресурсів відстежує загальне використання ресурсів у просторі імен та дозволяє операторам кластера встановлювати жорсткі ліміти використання ресурсів, які може споживати простір імен.

Обмеження діапазону визначає мінімальні/максимальні обмеження на кількість ресурсів, які може споживати одиниця у просторі імен.

Див. Контроль допуску: Limit Range

Простір імен може перебувати в одному з двох станів:

  • Active — простір імен використовується
  • Terminating — простір імен видаляється і не може бути використаний для нових обʼєктів

Для отримання додаткової інформації дивіться Простір імен в довідковій документації API.

Створення нового простору імен

Створіть новий файл YAML з назвою my-namespace.yaml з таким вмістом:

apiVersion: v1
kind: Namespace
metadata:
  name: <вставте-назву-простору-імен-тут>

Потім виконайте:

kubectl create -f ./my-namespace.yaml

Або ви можете створити простір імен за допомогою такої команди:

kubectl create namespace <вставте-назву-простору-імен-тут>

Назва вашого простору імен повинна бути дійсною DNS-міткою.

Є необовʼязкове поле finalizers, яке дозволяє спостережувачам очищати ресурси кожного разу, коли простір імен видаляється. Майте на увазі, що якщо ви вказуєте неіснуючий finalizer, простір імен буде створений, але залишиться в стані Terminating, якщо користувач спробує його видалити.

Більше інформації про finalizers можна знайти в документі про проєктування просторів імен.

Видалення простору імен

Видаліть простір імен за допомогою команди:

kubectl delete namespaces <вставте-назву-простору-імен-тут>

Ця операція видалення є асинхронною, тому протягом певного часу ви будете бачити простір імен у стані Terminating.

Поділ кластера за допомогою просторів імен Kubernetes

Типово кластер Kubernetes створює простір імен default при його розгортанні, щоб утримувати стандартний набір Podʼів, Serviceʼів та Deploymentʼів, які використовуються в кластері.

Припускаючи, що у вас є новий кластер, ви можете перевірити наявні простори імен, виконавши наступне:

kubectl get namespaces
NAME      STATUS    AGE
default   Active    13m

Створення нових просторів імен

У цьому завданні ми створимо два додаткових простори імен Kubernetes, щоб утримувати наш контент.

У випадку, коли організація використовує спільний кластер Kubernetes для розробки та операційної діяльності:

  • Команда розробників хотіла б мати простір у кластері, де вони можуть переглядати список Podʼів, Serviceʼів та Deploymentʼів, які вони використовують для створення та запуску свого застосунку. У цьому просторі ресурси Kubernetes зʼявляються та зникають, і обмеження на те, хто може або не може змінювати ресурси є слабкими для забезпечення гнучкої розробки.

  • Команда операторів хотіла б мати простір у кластері, де вони можуть використовувати строгі процедури на те, хто може або не може маніпулювати набором Podʼів, Serviceʼів та Deploymentʼів, що працюють в операційному середовищі.

Одним з можливих варіантів для цієї організації є розподіл кластера Kubernetes на два простори імен: development та production. Створімо два нових простори імен для нашої роботи.

Створіть простір імен development за допомогою kubectl:

kubectl create -f https://k8s.io/examples/admin/namespace-dev.json

А потім створімо простір імен production за допомогою kubectl:

kubectl create -f https://k8s.io/examples/admin/namespace-prod.json

Щоб переконатися, що все в порядку, виведемо список всіх просторів імен у нашому кластері.

kubectl get namespaces --show-labels
NAME          STATUS    AGE       LABELS
default       Active    32m       <none>
development   Active    29s       name=development
production    Active    23s       name=production

Створення Podʼів в кожному просторі імен

Простір імен Kubernetes забезпечує область для Podʼів, Serviceʼів та Deploymentʼів у кластері. Користувачі, що взаємодіють з одним простором імен, не бачать вмісту іншого простору імен. Щоб продемонструвати це, створімо простий Deployment та Podʼи в просторі імен development.

kubectl create deployment snowflake \
  --image=registry.k8s.io/serve_hostname \
  -n=development --replicas=2

Ми створили Deployment з 2 реплік, що запускає Pod з назвою snowflake з базовим контейнером, який обслуговує імʼя хосту.

kubectl get deployment -n=development
NAME         READY   UP-TO-DATE   AVAILABLE   AGE
snowflake    2/2     2            2           2m
kubectl get pods -l app=snowflake -n=development
NAME                         READY     STATUS    RESTARTS   AGE
snowflake-3968820950-9dgr8   1/1       Running   0          2m
snowflake-3968820950-vgc4n   1/1       Running   0          2m

Це чудово, розробники можуть робити те, що вони хочуть, і їм не потрібно хвилюватися про те, як це вплине на контент у просторі імен production.

Перейдімо до простору імен production і покажемо, як ресурси в одному просторі імен приховані від іншого. Простір імен production повинен бути порожнім, і наступні команди не повинні повертати нічого.

kubectl get deployment -n=production
kubectl get pods -n=production

Операційна діяльність вимагає догляду за худобою, тому створімо кілька Podʼів для худоби.

kubectl create deployment cattle --image=registry.k8s.io/serve_hostname -n=production
kubectl scale deployment cattle --replicas=5 -n=production

kubectl get deployment -n=production
NAME         READY   UP-TO-DATE   AVAILABLE   AGE
cattle       5/5     5            5           10s
kubectl get pods -l app=cattle -n=production
NAME                      READY     STATUS    RESTARTS   AGE
cattle-2263376956-41xy6   1/1       Running   0          34s
cattle-2263376956-kw466   1/1       Running   0          34s
cattle-2263376956-n4v97   1/1       Running   0          34s
cattle-2263376956-p5p3i   1/1       Running   0          34s
cattle-2263376956-sxpth   1/1       Running   0          34s

На цьому етапі має бути зрозуміло, що ресурси, які користувачі створюють в одному просторі імен, приховані від іншого простору імен.

Поки політика підтримки в Kubernetes розвивається, ми розширимо цей сценарій, щоб показати, як можна надавати різні правила авторизації для кожного простору імен.

Розуміння мотивації використання просторів імен

Один кластер повинен задовольняти потреби кількох користувачів або груп користувачів (далі в цьому документі спільнота користувачів).

Простори імен Kubernetes допомагають різним проєктам, командам або клієнтам спільно використовувати кластер Kubernetes.

Це робиться за допомогою такого:

  1. Області для імен.
  2. Механізму для прикріплення авторизації та політики до підрозділу кластера.

Використання кількох просторів імен не є обовʼязковим.

Кожна спільнота користувачів хоче мати можливість працювати в ізоляції від інших спільнот користувачів. У кожної спільноти користувачів свої:

  1. ресурси (pods, services, replication controllers тощо)
  2. політики (хто може або не може виконувати дії у своїй спільноті)
  3. обмеження (цій спільноті дозволено стільки квоти тощо)

Оператор кластера може створити простір імен для кожної унікальної спільноти користувачів.

Простір імен забезпечує унікальну область для:

  1. іменованих ресурсів (щоб уникнути базових конфліктів імен)
  2. делегування прав управління довіреним користувачам
  3. здатності обмежувати використання ресурсів спільнотою

Сценарії використання включають такі:

  1. Як оператор кластера, я хочу підтримувати кілька спільнот користувачів на одному кластері.
  2. Як оператор кластера, я хочу делегувати владу управління підрозділам кластера довіреним користувачам у цих спільнотах.
  3. Як оператор кластера, я хочу обмежити кількість ресурсів, які кожна спільнота може споживати, щоб обмежити вплив на інші спільноти, що використовують кластер.
  4. Як користувач кластера, я хочу взаємодіяти з ресурсами, які є важливими для моєї спільноти користувачів в ізоляції від того, що роблять інші спільноти користувачів на кластері.

Розуміння просторів імен та DNS

Коли ви створюєте Service, він створює відповідний DNS-запис. Цей запис має вигляд <імʼя-сервісу>.<імʼя-простору-імен>.svc.cluster.local, що означає, що якщо контейнер використовує <імʼя-сервісу>, воно буде розпізнано як сервіс, який знаходиться в межах простору імен. Це корисно для використання однакової конфігурації в кількох просторах імен, таких як Development, Staging та Production. Якщо ви хочете отримати доступ за межі просторів імен, вам потрібно використовувати повністю кваліфіковане доменне імʼя (FQDN).

Що далі

4.2.37 - Оновлення кластера

Ця сторінка надає огляд кроків, які вам слід виконати для оновлення кластера Kubernetes.

Спосіб оновлення кластера залежить від того, як ви спочатку розгорнули його та від будь-яких наступних змін.

На високому рівні кроки, які ви виконуєте, такі:

  • Оновити панель управління
  • Оновити вузли в вашому кластері
  • Оновити клієнтів, такі як kubectl
  • Відредагувати маніфести та інші ресурси на основі змін API, які супроводжують нову версію Kubernetes

Перш ніж ви розпочнете

Вам потрібно мати кластер. Ця сторінка присвячена оновленню з Kubernetes 1.30 до Kubernetes 1.31. Якщо ваш кластер зараз працює на Kubernetes 1.30, тоді, будь ласка, перевірте документацію для версії Kubernetes, на яку ви плануєте оновити.

Підходи до оновлення

kubeadm

Якщо ваш кластер був розгорнутий за допомогою інструменту kubeadm, дивіться Оновлення кластерів kubeadm для докладної інформації щодо оновлення кластера.

Після того, як ви оновили кластер, не забудьте встановити останню версію kubectl.

Ручне розгортання

Вам слід вручну оновити панель управління наступним чином:

  • etcd (всі екземпляри)
  • kube-apiserver (всі хости панелі управління)
  • kube-controller-manager
  • kube-scheduler
  • контролер управління хмари, якщо ви використовуєте його

На цьому етапі вам слід встановити останню версію kubectl.

Для кожного вузла в вашому кластері, очистіть цей вузол, а потім або замініть його новим вузлом, який використовує 1.31 kubelet, або оновіть kubelet на цьому вузлі та відновіть його Service.

Інші розгортання

Дивіться документацію для вашого інструменту розгортання кластера, щоб дізнатися рекомендовані кроки для підтримки.

Завдання після оновлення

Перемикання версії API зберігання кластера

Обʼєкти, які серіалізуються в etcd для внутрішнього представлення кластера ресурсів Kubernetes, записуються за допомогою певної версії API.

Коли підтримуване API змінюється, ці обʼєкти можуть потребувати перезаписування в новому API. Невиконання цього призведе до того, що ресурси не можна буде декодувати або використовувати за допомогою сервера API Kubernetes.

Для кожного ураженого обʼєкта, отримайте його, використовуючи останню підтримувану версію API, а потім записуйте його також, використовуючи останню підтримувану версію API.

Оновлення маніфестів

Оновлення до нової версії Kubernetes може надати нові API.

Ви можете використовувати команду kubectl convert для конвертації маніфестів між різними версіями API. Наприклад:

kubectl convert -f pod.yaml --output-version v1

Інструмент kubectl замінює вміст pod.yaml на маніфест, який встановлює kind на Pod (незмінно), але з оновленим apiVersion.

Втулки пристроїв

Якщо ваш кластер використовує втулки пристроїв і вузол потребує оновлення до випуску Kubernetes з новішою версією API втулка пристроїв, втулки пристроїв повинні бути оновлені для підтримки обох версій перед оновленням вузла, щоб гарантувати, що виділення пристроїв продовжує успішно завершуватися під час оновлення.

Дивіться Сумісність API та Версії API керуючого пристрою Kubelet для отримання додаткової інформації.

4.2.38 - Використання каскадного видалення у кластері

Ця сторінка показує, як вказати тип каскадного видалення у вашому кластері під час збору сміття.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Вам також потрібно створити приклад Deployment, щоб експериментувати з різними типами каскадного видалення. Вам доведеться перестворити Deployment для кожного типу.

Перевірка власників у ваших Podʼах

Перевірте, що поле ownerReferences присутнє у ваших Podʼах:

kubectl get pods -l app=nginx --output=yaml

Вивід має поле ownerReferences, схоже на це:

apiVersion: v1
    ...
    ownerReferences:
    - apiVersion: apps/v1
      blockOwnerDeletion: true
      controller: true
      kind: ReplicaSet
      name: nginx-deployment-6b474476c4
      uid: 4fdcd81c-bd5d-41f7-97af-3a3b759af9a7
    ...

Використання каскадного видалення на видності

Стандартно Kubernetes використовує фонове каскадне видалення для видалення залежностей обʼєкта. Ви можете переключитися на каскадне видалення на видноті за допомогою kubectl або за допомогою API Kubernetes, залежно від версії Kubernetes вашого кластера. Для перевірки версії введіть kubectl version.

Ви можете видаляти обʼєкти за допомогою каскадного видалення, використовуючи kubectl або API Kubernetes.

За допомогою kubectl

Виконайте наступну команду:

kubectl delete deployment nginx-deployment --cascade=foreground

За допомогою API Kubernetes

  1. Запустіть локальний проксі:

    kubectl proxy --port=8080
    
  2. Використовуйте curl для виклику видалення:

    curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/deployments/nginx-deployment \
        -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}' \
        -H "Content-Type: application/json"
    

    Вивід містить foregroundDeletion finalizer подібно до цього:

    "kind": "Deployment",
    "apiVersion": "apps/v1",
    "metadata": {
        "name": "nginx-deployment",
        "namespace": "default",
        "uid": "d1ce1b02-cae8-4288-8a53-30e84d8fa505",
        "resourceVersion": "1363097",
        "creationTimestamp": "2021-07-08T20:24:37Z",
        "deletionTimestamp": "2021-07-08T20:27:39Z",
        "finalizers": [
          "foregroundDeletion"
        ]
        ...
    

Використання фонового каскадного видалення

  1. Створіть приклад Deployment.
  2. Використовуйте або kubectl, або API Kubernetes для видалення Deployment, залежно від версії Kubernetes вашого кластера. Для перевірки версії введіть kubectl version.

Ви можете видаляти обʼєкти за допомогою фонового каскадного видалення за допомогою kubectl або API Kubernetes.

Kubernetes типово використовує фонове каскадне видалення, і робить це навіть якщо ви виконуєте наступні команди без прапорця --cascade або аргументу propagationPolicy.

За допомогою kubectl

Виконайте наступну команду:

kubectl delete deployment nginx-deployment --cascade=background

За допомогою API Kubernetes

  1. Запустіть локальний проксі:

    kubectl proxy --port=8080
    
  2. Використовуйте curl для виклику видалення:

    curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/deployments/nginx-deployment \
        -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Background"}' \
        -H "Content-Type: application/json"
    

    Вивід подібний до цього:

    "kind": "Status",
    "apiVersion": "v1",
    ...
    "status": "Success",
    "details": {
        "name": "nginx-deployment",
        "group": "apps",
        "kind": "deployments",
        "uid": "cc9eefb9-2d49-4445-b1c1-d261c9396456"
    }
    

Видалення власних обʼєктів та загублених залежностей

Типово, коли ви вказуєте Kubernetes видалити обʼєкт, controller також видаляє залежні обʼєкти. Ви можете загубити залежності використовуючи kubectl або API Kubernetes, залежно від версії Kubernetes вашого кластера. Для перевірки версії введіть kubectl version.

За допомогою kubectl

Виконайте наступну команду:

kubectl delete deployment nginx-deployment --cascade=orphan

За допомогою API Kubernetes

  1. Запустіть локальний проксі:

    kubectl proxy --port=8080
    
  2. Використовуйте curl для виклику видалення:

    curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/deployments/nginx-deployment \
        -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Orphan"}' \
        -H "Content-Type: application/json"
    

    Вивід містить orphan у полі finalizers, подібно до цього:

    "kind": "Deployment",
    "apiVersion": "apps/v1",
    "namespace": "default",
    "uid": "6f577034-42a0-479d-be21-78018c466f1f",
    "creationTimestamp": "2021-07-09T16:46:37Z",
    "deletionTimestamp": "2021-07-09T16:47:08Z",
    "deletionGracePeriodSeconds": 0,
    "finalizers": [
      "orphan"
    ],
    ...
    

Ви можете перевірити, що Podʼи, керовані Deployment, все ще працюють:

kubectl get pods -l app=nginx

Що далі

4.2.39 - Використання постачальника KMS для шифрування даних

Ця сторінка показує, як налаштувати постачальника Служби керування ключами (KMS) та втулок для шифрування конфіденційних даних. У Kubernetes 1.31 існують дві версії шифрування даних за допомогою KMS у спокої. Якщо це можливо, вам слід використовувати KMS v2, оскільки KMS v1 застарів (починаючи з Kubernetes v1.28) та є типово вимкненим (починаючи з Kubernetes v1.29). KMS v2 пропонує значно кращі характеристики продуктивності, ніж KMS v1.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Версія Kubernetes, яка вам потрібна, залежить від того, яку версію API KMS ви вибрали. Kubernetes рекомендує використовувати KMS v2.

  • Якщо ви вибрали KMS API v1 для підтримки кластерів до версії v1.27 або якщо у вас є застарілий плагін KMS, який підтримує лише KMS v1, будь-яка підтримувана версія Kubernetes буде працювати. Цей API є застарілим починаючи з Kubernetes v1.28. Kubernetes не рекомендує використовувати цей API.
Для перевірки версії введіть kubectl version.

KMS v1

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.28 [deprecated]
  • Потрібна версія Kubernetes 1.10.0 або пізніше.

  • Починаючи з версії 1.29, реалізація v1 KMS типово вимкнена. Щоб увімкнути функцію, встановіть --feature-gates=KMSv1=true, щоб налаштувати постачальника KMS v1.

  • Ваш кластер повинен використовувати etcd v3 або пізніше.

KMS v2

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.29 [stable]
  • Ваш кластер повинен використовувати etcd v3 або пізніше.

Шифрування KMS та ключі для кожного обʼєкта

Постачальник шифрування KMS використовує схему шифрування конвертів для шифрування даних в etcd. Дані шифруються за допомогою ключа шифрування даних (data encryption key — DEK). DEK шифруються за допомогою ключа шифрування ключа (key encryption key — KEK), який зберігається та обслуговується на віддаленому KMS.

Якщо ви використовуєте (застарілу) реалізацію v1 KMS, для кожного шифрування генерується новий DEK.

З KMS v2 для кожного шифрування генерується новий DEK: API-сервер використовує функцію похідного ключа для генерації ключів шифрування даних з одноразовим використанням секретного початкового елемента (seed — насіння) у поєднанні з випадковими даними. Ротація насіння відбувається при кожній зміні KEK (див. розділ Розуміння key_id та Ротація ключів нижче для докладніших відомостей).

Постачальник KMS використовує gRPC для звʼязку з певним втулком KMS через сокет UNIX-домену. Втулок KMS, який реалізований як сервер gRPC та розгорнутий на тих самих вузлах що і панель управління Kubernetes, відповідає за всі комунікації з віддаленим KMS.

Налаштування постачальника KMS

Для налаштування постачальника KMS на API-сервері включіть постачальника типу kms у масиві providers у файлі конфігурації шифрування і встановіть наступні властивості:

KMS v1

  • apiVersion: Версія API для постачальника KMS. Залиште це значення порожнім або встановіть його на v1.
  • name: Показує назву втулка KMS. Не може бути змінено після встановлення.
  • endpoint: Адреса прослуховування сервера gRPC (втулка KMS). Точка доступу — це сокет UNIX-домену.
  • cachesize: Кількість ключів шифрування даних (DEK), які будуть збережені в кеші у відкритому вигляді. Коли ключі DEK збережені в кеші, вони можуть бути використані без додаткового звертання до KMS; тоді як ключі DEK, які не збережені в кеші, потребують звертання до KMS для розшифрування.
  • timeout: Скільки часу kube-apiserver має чекати на відповідь від втулка kms, перш ніж сповістити про помилку (типово — 3 секунди).

KMS v2

  • apiVersion: Версія API для постачальника KMS. Встановіть це на v2.
  • name:Показує назву втулка KMS. Не може бути змінено після встановлення.
  • endpoint: Адреса прослуховування сервера gRPC (втулка KMS). Точка доступу — це сокет UNIX-домену.
  • timeout: Скільки часу kube-apiserver має чекати на відповідь від втулка kms, перш ніж сповістити про помилку (типово — 3 секунди).

KMS v2 не підтримує властивість cachesize. Всі ключі шифрування даних (DEK) будуть збережені в кеші у відкритому вигляді, як тільки сервер розкриє їх за допомогою звертання до KMS. Після збереження в кеші, ключі DEK можуть бути використані для виконання розшифрування нескінченно довго без звертання до KMS.

Дивіться Розуміння налаштування шифрування в спокої.

Реалізація втулка KMS

Для реалізації втулка KMS ви можете розробити новий сервер gRPC втулка або увімкнути втулок KMS, який вже надається вашим постачальником хмарних послуг. Потім ви інтегруєте втулок з віддаленим KMS та розгортаєте його на панелі управління Kubernetes.

Увімкнення KMS, що підтримується вашим постачальником хмарних послуг

Зверніться до вашого постачальника хмарних послуг для отримання інструкцій щодо увімкнення втулка KMS, який він надає.

Розробка сервера gRPC втулка KMS

Ви можете розробити сервер gRPC втулка KMS, використовуючи файл шаблону, доступний для мови програмування Go. Для інших мов програмування ви можете використовувати файл proto для створення файлу шаблону, який ви можете використовувати для написання коду сервера gRPC.

KMS v1

  • Використовуючи Go: Використовуйте функції та структури даних у файлі шаблону: api.pb.go для написання коду сервера gRPC.

  • Використовуючи інших мов програмування: Використовуйте компілятор protoc з файлом proto: api.proto для генерації файлу шаблону для конкретної мови програмування.

KMS v2

  • Використовуючи Go: Надається високорівнева бібліотека для спрощення процесу. Низькорівневі реалізації можуть використовувати функції та структури даних у файлі шаблону: api.pb.go для написання коду сервера gRPC.

  • Використовуючи інших мов програмування: Використовуйте компілятор protoc з файлом proto: api.proto для генерації файлу шаблону для конкретної мови програмування.

Потім використовуйте функції та структури даних у файлі шаблону для написання коду сервера.

Примітки

KMS v1
  • Версія втулка kms: v1beta1

    У відповідь на виклик процедури Version сумісний втулок KMS повинен повернути v1beta1 як VersionResponse.version.

  • Версія повідомлення: v1beta1

    Усі повідомлення від постачальника KMS мають поле версії встановлене на v1beta1.

  • Протокол: UNIX доменний сокет (unix)

    Втулок реалізований як сервер gRPC, який слухає UNIX доменний сокет. Розгортання втулка повинно створити файл у файловій системі для запуску зʼєднання gRPC unix domain socket. API-сервер (клієнт gRPC) налаштований на постачальника KMS (сервер gRPC) за допомогою точки доступу UNIX доменного сокета для звʼязку з ним. Може використовуватися абстрактний Linux сокет, точка доступу якого починається з /@, наприклад, unix:///@foo. Слід бути обережним при використанні цього типу сокета, оскільки вони не мають концепції ACL (на відміну від традиційних файлових сокетів). Однак вони підпадають під простір імен мережі Linux, тому будуть доступні лише контейнерам у тому ж самому Podʼі, якщо не використовується мережа хосту.

KMS v2
  • Версія втулка KMS: v2

    У відповідь на віддалений виклик процедури Status сумісний втулок KMS повинен повернути свою версію сумісності KMS як StatusResponse.version. У цій відповіді на статус також повинен бути включений "ok" як StatusResponse.healthz і key_id (ідентифікатор KEK віддаленого KMS) як StatusResponse.key_id. Проєкт Kubernetes рекомендує зробити ваш втулок сумісним зі стабільним v2 API KMS. Kubernetes 1.31 також підтримує v2beta1 API для KMS; майбутні релізи Kubernetes, швидше за все, будуть продовжувати підтримувати цю бета-версію.

    API-сервер надсилає віддалений виклик процедури Status приблизно кожну хвилину, коли все в справному стані, і кожні 10 секунд, коли втулок не справний. Втулки повинні пильнувати за оптимізацією цього виклику, оскільки він буде під постійним навантаженням.

  • Шифрування

    Виклик процедури EncryptRequest надає текст для шифрування та UID для цілей логування. У відповіді повинен бути включений шифротекст, key_id для використаного KEK та, опціонально, будь-які метадані, які потрібні втулку KMS для допомоги в майбутніх викликах DecryptRequest (через поле annotations). Втулок повинен гарантувати, що будь-який різний текст призводить до різної відповіді (шифротекст, key_id, annotations).

    Якщо втулок повертає непорожній масив annotations, всі ключі масиву повинні бути повністю кваліфікованими доменними іменами, такими як example.com. Приклад використання annotations — {"kms.example.io/remote-kms-auditid":"<audit ID використаний віддаленим KMS>"}

    API-сервер не виконує виклик процедури EncryptRequest на високому рівні. Реалізації втулків повинні все ж старатися, щоб зберегти час очікування кожного запиту менше 100 мілісекунд.

  • Розшифрування

    Виклик процедури DecryptRequest надає (ciphertext, key_id, annotations) з EncryptRequest та UID для цілей логування. Як і очікується, це протилежне виклику EncryptRequest. Втулки повинні перевірити, що key_id є тим, що вони розуміють — вони не повинні намагатися розшифрувати дані, якщо вони не впевнені, що вони були зашифровані ними раніше.

    API-сервер може виконати тисячі викликів процедури DecryptRequest під час запуску для заповнення свого кешу перегляду. Таким чином, реалізації втулків повинні виконати ці виклики якнайшвидше, і повинні старатися зберегти час очікування кожного запиту менше 10 мілісекунд.

  • Розуміння key_id та Ротації ключа

    key_id є публічним, незасекреченим імʼям віддаленого KEK KMS, який в цей момент використовується. Він може бути зареєстрований під час регулярної роботи API-сервера та, отже, не повинен містити ніяких приватних даних. Реалізації втулків повинні використовувати хеш, щоб уникнути витоку будь-яких даних. Метрики KMS v2 пильнують за хешуванням цього значення перед показом його через точку доступу /metrics.

    API-сервер вважає, що key_id, отриманий з виклику процедури Status, є авторитетним. Отже, зміна цього значення сигналізує API-серверу, що віддалений KEK змінився, і дані, зашифровані старим KEK, повинні бути позначені як застарілі при виконанні операція запису без операції (як описано нижче). Якщо виклик процедури EncryptRequest повертає key_id, який відрізняється від Status, відповідь відкидається, і втулок вважається несправним. Таким чином, реалізації повинні гарантувати, що key_id, що повертається зі Status, буде таким самим, як той, що повертається з EncryptRequest. Крім того, втулки повинні забезпечити стабільність key_id і не допускати перемикання між значеннями (тобто під час ротації віддаленого KEK).

    Втулки не повинні повторно використовувати key_id, навіть у ситуаціях, коли раніше використаний віддалений KEK був відновлений. Наприклад, якщо втулок використовував key_id=A, перемикнувся на key_id=B, а потім повернувся до key_id=A — замість того, щоб повідомити key_id=A, втулок повинен повідомити якесь похідне значення, таке як key_id=A_001 або використовувати нове значення, наприклад key_id=C.

    Оскільки API-сервер опитує Status приблизно кожну хвилину, ротація key_id не є миттєвою. Крім того, API-сервер буде користуватися останнім дійсним станом протягом приблизно трьох хвилин. Таким чином, якщо користувач хоче здійснити пасивний підхід до міграції зберігання (тобто, чекаючи), він повинен запланувати міграцію на 3 + N + M хвилин після ротації віддаленого KEK (N — це час, необхідний для того, щоб втулок помітив зміну key_id, і M — бажаний буфер, щоб дозволити обробку змін конфігурації, рекомендується мінімальне значення M в пʼять хвилин). Зазначте, що для виконання ротації KEK перезапуск API-сервера не потрібен.

  • Протокол: UNIX доменний сокет (unix)

    Втулок реалізований як сервер gRPC, який слухає UNIX доменний сокет. Розгортання втулка повинно створити файл у файловій системі для запуску зʼєднання gRPC unix domain socket. API-сервер (клієнт gRPC) налаштований на постачальника KMS (сервер gRPC) за допомогою точки доступу UNIX доменного сокета для звʼязку з ним. Може використовуватися абстрактний Linux сокет, точка доступу якого починається з /@, наприклад, unix:///@foo. Слід бути обережним при використанні цього типу сокета, оскільки вони не мають концепції ACL (на відміну від традиційних файлових сокетів). Однак вони підпадають під простір імен мережі Linux, тому будуть доступні лише контейнерам у тому ж самому Podʼі, якщо не використовується мережа хосту.

Інтеграція втулка KMS з віддаленим KMS

Втулок KMS може спілкуватися з віддаленим KMS за допомогою будь-якого протоколу, який підтримується KMS. Усі дані конфігурації, включаючи облікові дані автентифікації, які використовує втулок KMS для спілкування з віддаленим KMS, зберігаються і керуються втулком KMS незалежно. Втулок KMS може кодувати шифротекст з додатковими метаданими, які можуть бути потрібні перед відправленням його в KMS для розшифрування (KMS v2 робить цей процес простішим, надаючи спеціальне поле annotations).

Розгортання втулка KMS

Переконайтеся, що втулок KMS працює на тих самих хостах, що і сервер(и) API Kubernetes.

Шифрування даних за допомогою постачальника KMS

Для шифрування даних виконайте наступні кроки:

  1. Створіть новий файл EncryptionConfiguration, використовуючи відповідні властивості для постачальника kms, щоб шифрувати ресурси, такі як Secrets та ConfigMaps. Якщо ви хочете зашифрувати розширення API, яке визначено у визначенні CustomResourceDefinition, ваш кластер повинен працювати на Kubernetes v1.26 або новіше.

  2. Встановіть прапорець --encryption-provider-config на kube-apiserver, щоб вказати місце розташування файлу конфігурації.

  3. Аргумент --encryption-provider-config-automatic-reload типу boolean визначає, чи слід автоматично перезавантажувати файл, встановлений за допомогою --encryption-provider-config, у разі зміни вмісту на диску.

  4. Перезапустіть свій API-сервер.

KMS v1

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
      - configmaps
      - pandas.awesome.bears.example
    providers:
      - kms:
          name: myKmsPluginFoo
          endpoint: unix:///tmp/socketfile-foo.sock
          cachesize: 100
          timeout: 3s
      - kms:
          name: myKmsPluginBar
          endpoint: unix:///tmp/socketfile-bar.sock
          cachesize: 100
          timeout: 3s

KMS v2

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
      - configmaps
      - pandas.awesome.bears.example
    providers:
      - kms:
          apiVersion: v2
          name: myKmsPluginFoo
          endpoint: unix:///tmp/socketfile-foo.sock
          timeout: 3s
      - kms:
          apiVersion: v2
          name: myKmsPluginBar
          endpoint: unix:///tmp/socketfile-bar.sock
          timeout: 3s

Встановлення --encryption-provider-config-automatic-reload в true обʼєднує всі перевірки стану в одну точку доступу перевірки стану. Індивідуальні перевірки стану доступні тільки тоді, коли використовуються постачальники KMS v1 і конфігурація шифрування не перезавантажується автоматично.

Наступна таблиця містить підсумки точок доступу перевірки стану для кожної версії KMS:

Конфігурації KMSБез автоматичного перезавантаженняЗ автоматичним перезавантаженням
Тільки KMS v1Індивідуальні перевіркиОдна перевірка
Тільки KMS v2Одна перевіркаОдна перевірка
KMS v1 та KMS v2Індивідуальні перевіркиОдна перевірка
Без KMSНемаєОдна перевірка

Одна перевірка означає, що єдиною точкою доступу перевірки стану є /healthz/kms-providers.

Індивідуальні перевірки означає, що для кожного втулка KMS є асоційована точка доступу перевірки стану на основі його місця в конфігурації шифрування: /healthz/kms-provider-0, /healthz/kms-provider-1 тощо.

Ці шляхи точок доступу перевірки стану жорстко закодовані та генеруються/контролюються сервером. Індекси для індивідуальних перевірок відповідають порядку, у якому обробляється конфігурація шифрування KMS.

До виконання кроків, визначених у Забезпечення шифрування всіх секретів, список providers повинен закінчуватися постачальником identity: {}, щоб можна було читати незашифровані дані. Після шифрування всіх ресурсів постачальника identity слід видалити, щоб запобігти обробці незашифрованих даних сервером API.

Для отримання деталей про формат EncryptionConfiguration, будь ласка, перегляньте довідник API шифрування API сервера.

Перевірка того, що дані зашифровані

Коли шифрування даних у стані спокою правильно налаштовано, ресурси шифруються під час запису. Після перезапуску вашого kube-apiserver, будь-які новостворені або оновлені Secret чи інші типи ресурсів, налаштовані в EncryptionConfiguration, мають бути зашифровані при зберіганні. Щоб перевірити, ви можете використовувати програму командного рядка etcdctl для отримання вмісту ваших секретних даних.

  1. Створіть новий Secret з назвою secret1 в просторі імен default:

    kubectl create secret generic secret1 -n default --from-literal=mykey=mydata
    
  2. Використовуючи командний рядок etcdctl, прочитайте цей Secret з etcd:

    ETCDCTL_API=3 etcdctl get /kubernetes.io/secrets/default/secret1 [...] | hexdump -C
    

    де [...] містить додаткові аргументи для підключення до сервера etcd.

  3. Переконайтеся, що збережений Secret починається з префікса k8s:enc:kms:v1: для KMS v1 або з префікса k8s:enc:kms:v2: для KMS v2, що вказує на те, що постачальник kms зашифрував результати даних.

  4. Перевірте, що Secret правильно розшифровується при отриманні через API:

    kubectl describe secret secret1 -n default
    

    Secret повинен містити mykey: mydata.

Забезпечення шифрування всіх секретів

Коли шифрування даних у стані спокою правильно налаштовано, ресурси шифруються під час запису. Таким чином, ми можемо виконати оновлення без змін на місці, щоб переконатися, що дані зашифровані.

Наведена нижче команда читає всі Secret, а потім оновлює їх для застосування шифрування на сервері. У разі помилки через конфліктний запис, повторіть команду. Для більших кластерів вам може знадобитися поділити Secret за просторами імен або написати скрипт для оновлення.

kubectl get secrets --all-namespaces -o json | kubectl replace -f -

Перехід від локального постачальника шифрування до постачальника KMS

Щоб перейти від локального постачальника шифрування до постачальника kms та перешифрувати всі секрети:

  1. Додайте постачальника kms як перший запис у файлі конфігурації, як показано в наступному прикладі.

    apiVersion: apiserver.config.k8s.io/v1
    kind: EncryptionConfiguration
    resources:
      - resources:
          - secrets
        providers:
          - kms:
              apiVersion: v2
              name: myKmsPlugin
              endpoint: unix:///tmp/socketfile.sock
          - aescbc:
              keys:
                - name: key1
                  secret: <BASE 64 ENCODED SECRET>
    
  2. Перезапустіть усі процеси kube-apiserver.

  3. Виконайте наступну команду, щоб змусити всі секрети перешифруватися за допомогою постачальника kms.

    kubectl get secrets --all-namespaces -o json | kubectl replace -f -
    

Що далі

Якщо ви більше не хочете використовувати шифрування для даних, збережених в API Kubernetes, прочитайте розшифровування даних, які вже зберігаються у спокої.

4.2.40 - Використання CoreDNS для виявлення Service

Ця сторінка описує процес оновлення CoreDNS та як встановити CoreDNS замість kube-dns.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Версія вашого Kubernetes сервера має бути не старішою ніж v1.9. Для перевірки версії введіть kubectl version.

Про CoreDNS

CoreDNS — це гнучкий, розширюваний DNS-сервер, який може обслуговувати DNS кластера Kubernetes. Як і Kubernetes, проєкт CoreDNS є проєктом CNCF.

Ви можете використовувати CoreDNS замість kube-dns у своєму кластері, замінивши kube-dns у наявному розгортанні, або використовуючи інструменти, такі як kubeadm, які встановлюють і оновлюють кластер за вас.

Встановлення CoreDNS

Для ручного розгортання або заміни kube-dns, дивіться документацію на вебсайті CoreDNS.

Міграція на CoreDNS

Оновлення наявного кластера за допомогою kubeadm

У версії Kubernetes 1.21, kubeadm припинив підтримку kube-dns як застосунку DNS. Для kubeadm v1.31, єдиний підтримуваний DNS застосунок кластера — це CoreDNS.

Ви можете перейти на CoreDNS, використовуючи kubeadm для оновлення кластера, який використовує kube-dns. У цьому випадку, kubeadm генерує конфігурацію CoreDNS ("Corefile") на основі ConfigMap kube-dns, зберігаючи конфігурації для stub доменів та сервера імен вище в ієрархії.

Оновлення CoreDNS

Ви можете перевірити версію CoreDNS, яку kubeadm встановлює для кожної версії Kubernetes на сторінці Версія CoreDNS у Kubernetes.

CoreDNS можна оновити вручну, якщо ви хочете тільки оновити CoreDNS або використовувати власний кастомізований образ. Є корисні рекомендації та посібник, доступні для забезпечення плавного оновлення. Переконайтеся, що поточна конфігурація CoreDNS ("Corefile") зберігається при оновленні вашого кластера.

Якщо ви оновлюєте свій кластер за допомогою інструменту kubeadm, kubeadm може самостійно зберегти поточну конфігурацію CoreDNS.

Налаштування CoreDNS

Коли використання ресурсів є проблемою, може бути корисним налаштувати конфігурацію CoreDNS. Для детальнішої інформації перевірте документацію зі збільшення масштабу CoreDNS.

Що далі

Ви можете налаштувати CoreDNS для підтримки багатьох інших сценаріїв, ніж kube-dns, змінивши конфігурацію CoreDNS ("Corefile"). Для отримання додаткової інформації дивіться документацію для втулка kubernetes CoreDNS, або читайте Власні DNS записи для Kubernetes в блозі CoreDNS.

4.2.41 - Використання NodeLocal DNSCache в кластерах Kubernetes

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.18 [stable]

Ця сторінка надає огляд функції NodeLocal DNSCache в Kubernetes.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Для перевірки версії введіть kubectl version.

Вступ

NodeLocal DNSCache поліпшує продуктивність кластерного DNS, запускаючи агента кешування DNS на вузлах кластера як DaemonSet. За поточної архітектури, Podʼи в режимі DNS ClusterFirst звертаються до serviceIP kube-dns для DNS-запитів. Вони переводяться в точку доступу kube-dns/CoreDNS за допомогою прав iptables, доданих kube-proxy. За цією новою архітектурою Podʼи звертаються до агента кешування DNS, що працює на тому ж вузлі, тим самим уникнувши прав iptables DNAT та відстеження зʼєднань. Локальний агент кешування буде запитувати службу kube-dns про пропуски кешування для імен кластера (типовий суфікс "cluster.local").

Мотивація

  • За поточної архітектури DNS, є можливість того, що Podʼи з найвищим QPS DNS повинні звертатися до іншого вузла, якщо на цьому вузлі немає локального екземпляра kube-dns/CoreDNS. Наявність локального кешу допоможе покращити час відгуку в таких сценаріях.

  • Пропускаючи iptables DNAT та відстеження зʼєднань допоможе зменшити перегони з відстеженням зʼєднань та уникнути заповнення таблиці conntrack UDP DNS-записами.

  • Зʼєднання від локального агента кешування до служби kube-dns можуть бути підвищені до TCP. Записи conntrack для TCP будуть видалені при закритті зʼєднання, на відміну від записів UDP, які мусять перейти у режим очікування (типово nf_conntrack_udp_timeout становить 30 секунд)

  • Перехід DNS-запитів з UDP до TCP зменшить хвостовий час відповіді, спричинений втратою пакетів UDP та зазвичай таймаутами DNS до 30 секунд (3 повтори + 10 секунд таймауту). Оскільки кеш NodeLocal прослуховує UDP DNS-запити, застосунки не потребують змін.

  • Метрики та видимість DNS-запитів на рівні вузла.

  • Відʼємне кешування можна повторно включити, тим самим зменшивши кількість запитів до служби kube-dns.

Діаграма архітектури

Це шлях, яким йдуть DNS-запити після ввімкнення NodeLocal DNSCache:

Потік NodeLocal DNSCache

Потік NodeLocal DNSCache

Ця картинка показує, як NodeLocal DNSCache обробляє DNS-запити.

Конфігурація

Цю функцію можна ввімкнути за допомогою таких кроків:

  • Підготуйте маніфест, схожий на зразок nodelocaldns.yaml та збережіть його як nodelocaldns.yaml.

  • Якщо використовуєте IPv6, файл конфігурації CoreDNS потрібно закрити всі IPv6-адреси у квадратні дужки, якщо вони використовуються у форматі 'IP:Port'. Якщо ви використовуєте зразок маніфесту з попереднього пункту, це потребує зміни рядка конфігурації L70 таким чином: "health [__PILLAR__LOCAL__DNS__]:8080"

  • Підставте змінні в маніфест з правильними значеннями:

    kubedns=`kubectl get svc kube-dns -n kube-system -o jsonpath={.spec.clusterIP}`
    domain=<cluster-domain>
    localdns=<node-local-address>
    

    <cluster-domain> типово "cluster.local". <node-local-address> — це локальна IP-адреса прослуховування, обрана для NodeLocal DNSCache.

    • Якщо kube-proxy працює в режимі IPTABLES:

      sed -i "s/__PILLAR__LOCAL__DNS__/$localdns/g; s/__PILLAR__DNS__DOMAIN__/$domain/g; s/__PILLAR__DNS__SERVER__/$kubedns/g" nodelocaldns.yaml
      

      __PILLAR__CLUSTER__DNS__ та __PILLAR__UPSTREAM__SERVERS__ будуть заповнені під час роботи підсистеми node-local-dns. У цьому режимі підсистеми node-local-dns прослуховують як IP-адресу служби kube-dns, так і <node-local-address>, тому Podʼи можуть шукати записи DNS, використовуючи будь-яку з цих IP-адрес.

    • Якщо kube-proxy працює в режимі IPVS:

      sed -i "s/__PILLAR__LOCAL__DNS__/$localdns/g; s/__PILLAR__DNS__DOMAIN__/$domain/g; s/,__PILLAR__DNS__SERVER__//g; s/__PILLAR__CLUSTER__DNS__/$kubedns/g" nodelocaldns.yaml
      

      У цьому режимі підсистеми node-local-dns прослуховують лише <node-local-address>. Інтерфейс node-local-dns не може привʼязати кластерну IP kube-dns, оскільки інтерфейс, що використовується для IPVS-балансування навантаження, вже використовує цю адресу. __PILLAR__UPSTREAM__SERVERS__ буде заповнено підсистемами node-local-dns.

  • Запустіть kubectl create -f nodelocaldns.yaml.

  • Якщо використовуєте kube-proxy в режимі IPVS, прапорець --cluster-dns для kubelet потрібно змінити на <node-local-address>, який прослуховує NodeLocal DNSCache. В іншому випадку не потрібно змінювати значення прапорця --cluster-dns, оскільки NodeLocal DNSCache прослуховує як IP-адресу служби kube-dns, так і <node-local-address>.

Після ввімкнення, Podʼи node-local-dns будуть працювати у просторі імен kube-system на кожному з вузлів кластера. Цей Pod працює з CoreDNS у режимі кешування, тому всі метрики CoreDNS, що надаються різними втулками, будуть доступні на рівні кожного вузла.

Цю функцію можна вимкнути, видаливши DaemonSet, використовуючи kubectl delete -f <manifest>. Також слід скасувати будь-які зміни, внесені до конфігурації kubelet.

Конфігурація StubDomains та Upstream серверів

StubDomains та upstream сервери, вказані в ConfigMap kube-dns в просторі імен kube-system автоматично використовуються підсистемами node-local-dns. Вміст ConfigMap повинен відповідати формату, показаному у прикладі. ConfigMap node-local-dns також можна змінити безпосередньо з конфігурацією stubDomain у форматі Corefile. Деякі хмарні постачальники можуть не дозволяти змінювати ConfigMap node-local-dns безпосередньо. У цьому випадку ConfigMap kube-dns можна оновити.

Налаштування обмежень памʼяті

Podʼи node-local-dns використовують памʼять для зберігання записів кешу та обробки запитів. Оскільки вони не стежать за обʼєктами Kubernetes, розмір кластера або кількість Service / EndpointSlice не впливає на використання памʼяті безпосередньо. Використання памʼяті впливає на шаблон DNS-запитів. З документації CoreDNS:

Типовий розмір кешу — 10000 записів, що використовує приблизно 30 МБ, коли повністю заповнений.

Це буде використання памʼяті для кожного блоку сервера (якщо кеш буде повністю заповнений). Використання памʼяті можна зменшити, вказавши менші розміри кешу.

Кількість одночасних запитів повʼязана з попитом памʼяті, оскільки кожен додатковий goroutine, використаний для обробки запиту, потребує певної кількості памʼяті. Ви можете встановити верхню межу за допомогою опції max_concurrent у втулку forward.

Якщо Pod node-local-dns намагається використовувати більше памʼяті, ніж доступно (через загальні системні ресурси або через налаштовані обмеження ресурсів), операційна система може вимкнути контейнер цього Podʼа. У разі цього, контейнер, якого вимкнено ("OOMKilled"), не очищає власні правила фільтрації пакетів, які він раніше додавав під час запуску. Контейнер node-local-dns повинен бути перезапущений (оскільки він керується як частина DaemonSet), але це призведе до короткої перерви у роботі DNS кожного разу, коли контейнер зазнає збою: правила фільтрації пакетів направляють DNS-запити до локального Podʼа, який не є справним.

Ви можете визначити прийнятне обмеження памʼяті, запустивши Podʼи node-local-dns без обмеження та вимірявши максимальне використання. Ви також можете налаштувати та використовувати VerticalPodAutoscaler у recommender mode, а потім перевірити його рекомендації.

4.2.42 - Використання sysctl в кластері Kubernetes

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.21 [stable]

У цьому документі описано, як налаштовувати та використовувати параметри ядра в межах кластера Kubernetes, використовуючи інтерфейс sysctl.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Для деяких кроків вам також потрібно мати змогу змінювати параметри командного рядка для kubelet, що працюють на вашому кластері.

Перелік всіх параметрів Sysctl

У Linux інтерфейс sysctl дозволяє адміністратору змінювати параметри ядра під час виконання. Параметри доступні через віртуальну файлову систему /proc/sys/. Параметри охоплюють різні підсистеми, такі як:

  • ядро (загальний префікс: kernel.)
  • мережа (загальний префікс: net.)
  • віртуальна памʼять (загальний префікс: vm.)
  • MDADM (загальний префікс: dev.)
  • Більше підсистем описано у документації ядра.

Щоб отримати список всіх параметрів, ви можете виконати команду:

sudo sysctl -a

Безпечні та Небезпечні Sysctl

Kubernetes класифікує sysctl як безпечні або небезпечні. Крім належного просторового розмежування, безпечний sysctl повинен бути належним чином ізольованим між Podʼами на тому ж вузлі. Це означає, що встановлення безпечного sysctl для одного Podʼа

  • не повинно мати жодного впливу на інші Podʼи на вузлі
  • не повинно дозволяти шкодити справності вузла
  • не повинно дозволяти отримувати CPU або ресурси памʼяті поза межами обмежень ресурсів Podʼа.

Наразі більшість просторово розмежованих (по просторах імен) sysctl не обовʼязково вважаються безпечними. До набору безпечних sysctl входять наступні параметри:

  • kernel.shm_rmid_forced;
  • net.ipv4.ip_local_port_range;
  • net.ipv4.tcp_syncookies;
  • net.ipv4.ping_group_range (починаючи з Kubernetes 1.18);
  • net.ipv4.ip_unprivileged_port_start (починаючи з Kubernetes 1.22);
  • net.ipv4.ip_local_reserved_ports (починаючи з Kubernetes 1.27, потрібне ядро 3.16+);
  • net.ipv4.tcp_keepalive_time (починаючи з Kubernetes 1.29, потрібне ядро 4.5+);
  • net.ipv4.tcp_fin_timeout (починаючи з Kubernetes 1.29, потрібне ядро 4.6+);
  • net.ipv4.tcp_keepalive_intvl (починаючи з Kubernetes 1.29, потрібне ядро 4.5+);
  • net.ipv4.tcp_keepalive_probes (починаючи з Kubernetes 1.29, потрібне ядро 4.5+).

Цей список буде розширюватися у майбутніх версіях Kubernetes, коли kubelet буде підтримувати кращі механізми ізоляції.

Увімкнення небезпечних Sysctl

Всі безпечні sysctl є типово увімкненими.

Всі небезпечні sysctl типово вимкнені та повинні бути дозволені вручну адміністратором кластера на кожному вузлі окремо. Podʼи з вимкненими небезпечними sysctl будуть заплановані, але їх не вдасться запустити.

З врахуванням попередження вище, адміністратор кластера може дозволити певні небезпечні sysctl для дуже спеціальних ситуацій, таких як налаштування високопродуктивних або застосунків реального часу. Небезпечні sysctl вмикаються на основі вузла з прапорцем kubelet; наприклад:

kubelet --allowed-unsafe-sysctls \
  'kernel.msg*,net.core.somaxconn' ...

Для Minikube, це можна зробити за допомогою прапорця extra-config:

minikube start --extra-config="kubelet.allowed-unsafe-sysctls=kernel.msg*,net.core.somaxconn"...

Таким чином можна увімкнути лише просторово розмежовані sysctl.

Налаштування Sysctl для Podʼа

Численні sysctl просторово розмежовані в сучасних ядрах Linux. Це означає, що їх можна налаштовувати незалежно для кожного Pod на вузлі. Лише просторово розмежовані sysctl можна налаштовувати через securityContext Podʼа в межах Kubernetes.

Відомо, що наступні sysctl мають просторове розмежування. Цей список може змінитися в майбутніх версіях ядра Linux.

  • kernel.shm*
  • kernel.msg*
  • kernel.sem
  • fs.mqueue.*
  • Ті net.*, які можна налаштувати в просторі імен мережі контейнера. Однак є винятки (наприклад, net.netfilter.nf_conntrack_max та net.netfilter.nf_conntrack_expect_max можуть бути налаштовані в просторі імен мережі контейнера, але не мають просторового розмежування до Linux 5.12.2).

Sysctl без просторового розмежування називають вузловими sysctl. Якщо вам потрібно налаштувати їх, ви повинні вручну налаштувати їх в операційній системі кожного вузла або за допомогою DaemonSet з привілейованими контейнерами.

Використовуйте securityContext Podʼа для налаштування просторово розмежованих sysctl. securityContext застосовується до всіх контейнерів у тому ж Podʼі.

У цьому прикладі використовується securityContext Podʼа для встановлення безпечного sysctl kernel.shm_rmid_forced та двох небезпечних sysctl net.core.somaxconn та kernel.msgmax. В специфікації немає розрізнення між безпечними та небезпечними sysctl.

apiVersion: v1
kind: Pod
metadata:
  name: sysctl-example
spec:
  securityContext:
    sysctls:
    - name: kernel.shm_rmid_forced
      value: "0"
    - name: net.core.somaxconn
      value: "1024"
    - name: kernel.msgmax
      value: "65536"
  ...

Хорошою практикою є вважати вузли з особливими налаштуваннями sysctl як позначені taint в межах кластера і планувати на них лише ті Podʼи, яким потрібні ці налаштування sysctl. Рекомендується використовувати функцію Заплямованість та Толерантність кластера Kubernetes, щоб реалізувати це.

Pod з небезпечними sysctl не вдасться запустити на будь-якому вузлі, на якому не були явно увімкнені ці два небезпечні sysctl. Як і з вузловими sysctl, рекомендується використовувати функцію Заплямованість та Толерантність або заплямованість вузлів для планування цих Podʼів на відповідні вузли.

4.2.43 - Використання NUMA-орієнтованого менеджера памʼяті

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.22 [beta]

Менеджер памʼяті Kubernetes дозволяє функцію гарантованого виділення памʼяті (та великих сторінок) для Podʼів QoS класу Guaranteed.

Менеджер памʼяті використовує протокол генерації підказок для вибору найбільш відповідної спорідненості NUMA для точки доступу. Менеджер памʼяті передає ці підказки центральному менеджеру (Менеджеру топології). На основі як підказок, так і політики Менеджера топології, Pod відхиляється або допускається на вузол.

Крім того, Менеджер памʼяті забезпечує, що памʼять, яку запитує Pod, виділяється з мінімальної кількості NUMA-вузлів.

Менеджер памʼяті має відношення тільки до хостів на базі Linux.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Версія вашого Kubernetes сервера має бути не старішою ніж v1.21. Для перевірки версії введіть kubectl version.

Для вирівнювання ресурсів памʼяті з іншими запитаними ресурсами у специфікації Podʼа:

Починаючи з версії v1.22, Менеджер памʼяті типово увімкнено за допомогою функціональної можливості MemoryManager.

Для версій до v1.22, kubelet повинен бути запущений з наступним прапорцем:

--feature-gates=MemoryManager=true

щоб увімкнути функцію Менеджера памʼяті.

Як працює Менеджер памʼяті?

Зараз Менеджер памʼяті пропонує виділення гарантованої памʼяті (та великих сторінок) для Podʼів у класі QoS Guaranteed. Щоб негайно ввести Менеджер памʼяті в роботу, слідкуйте вказівкам у розділі Налаштування Менеджера памʼяті, а потім підготуйте та розгорніть Pod Guaranteed, як показано в розділі Розміщення Podʼів класу QoS Guaranteed.

Менеджер памʼяті є постачальником підказок і надає підказки топології для Менеджера топології, який потім вирівнює запитані ресурси згідно з цими підказками топології. Він також застосовує cgroups (тобто cpuset.mems) для Podʼів. Повна схематична діаграма щодо процесу допуску та розгортання Podʼа показано у Memory Manager KEP: Design Overview та нижче:

Memory Manager у процесі прийняття та розгортання Podʼа

Під час цього процесу Менеджер памʼяті оновлює свої внутрішні лічильники, що зберігаються в Node Map та Memory Maps, для управління гарантованим виділенням памʼяті.

Менеджер памʼяті оновлює Node Map під час запуску та виконання наступним чином.

Запуск

Це відбувається один раз, коли адміністратор вузла використовує --reserved-memory (розділ Прапорець зарезервованої памʼяті). У цьому випадку Node Map оновлюється, щоб відображати це резервування, як показано в Memory Manager KEP: Memory Maps at start-up (with examples).

Адміністратор повинен надати прапорець --reserved-memory при налаштуванні політики Static.

Робота

Посилання Memory Manager KEP: Memory Maps at runtime (with examples) ілюструє, як успішне розгортання Podʼа впливає на Node Map, і також повʼязано з тим, як потенційні випадки вичерпання памʼяті (OOM) далі обробляються Kubernetes або операційною системою.

Важливою темою в контексті роботи Менеджера памʼяті є керування NUMA-групами. Кожного разу, коли запит памʼяті Podʼа перевищує місткість одного NUMA-вузла, Менеджер памʼяті намагається створити групу, яка включає декілька NUMA-вузлів і має розширений обсяг памʼяті. Проблему вирішено, як про це йдеться у Memory Manager KEP: How to enable the guaranteed memory allocation over many NUMA nodes?. Також, посилання Memory Manager KEP: Simulation - how the Memory Manager works? (by examples) показує, як відбувається управління групами.

Налаштування Менеджера памʼяті

Інші Менеджери повинні бути спочатку попередньо налаштовані. Далі, функцію Менеджера памʼяті слід увімкнути та запустити з політикою Static (розділ Політика Static). Опційно можна зарезервувати певну кількість памʼяті для системи або процесів kubelet, щоб збільшити стабільність вузла (розділ Прапорець зарезервованої памʼяті).

Політики

Менеджер памʼяті підтримує дві політики. Ви можете вибрати політику за допомогою прапорця kubelet --memory-manager-policy:

  • None (типово)
  • Static

Політика None

Це типова політика і вона не впливає на виділення памʼяті жодним чином. Вона працює так само як і коли Менеджер памʼяті взагалі відсутній.

Політика None повертає типову підказку топології. Ця спеціальна підказка позначає, що Hint Provider (в цьому випадку Менеджер памʼяті) не має переваги щодо спорідненості NUMA з будь-яким ресурсом.

Політика Static

У випадку Guaranteed Podʼа політика Менеджера памʼяті Static повертає підказки топології, що стосуються набору NUMA-вузлів, де памʼять може бути гарантованою, та резервує памʼять, оновлюючи внутрішній обʼєкт NodeMap.

У випадку Podʼа BestEffort або Burstable політика Менеджера памʼяті Static повертає назад типову підказку топології, оскільки немає запиту на гарантовану памʼять, і не резервує памʼять внутрішнього обʼєкта NodeMap.

Прапорець зарезервованої памʼяті

Механізм виділення ресурсів вузла (Node Allocatable) зазвичай використовується адміністраторами вузлів для резервування системних ресурсів вузла K8S для kubelet або процесів операційної системи, щоб підвищити стабільність вузла. Для цього можна використовувати відповідний набір прапорців, щоб вказати загальну кількість зарезервованої памʼяті для вузла. Це попередньо налаштоване значення далі використовується для розрахунку реальної кількості "виділеної" памʼяті вузла, доступної для Podʼів.

Планувальник Kubernetes використовує "виділену" памʼять для оптимізації процесу планування Podʼів. Для цього використовуються прапорці --kube-reserved, --system-reserved та --eviction-threshold. Сума їх значень враховує загальну кількість зарезервованої памʼяті.

Новий прапорець --reserved-memory було додано до Memory Manager, щоб дозволити цю загальну зарезервовану памʼять розділити (адміністратором вузла) і відповідно зарезервувати для багатьох вузлів NUMA.

Прапорець визначається як розділений комами список резервування памʼяті різних типів на NUMA-вузол. Резервації памʼяті по кількох NUMA-вузлах можна вказати, використовуючи крапку з комою як роздільник. Цей параметр корисний лише в контексті функції Менеджера памʼяті. Менеджер памʼяті не використовуватиме цю зарезервовану памʼять для виділення контейнерних робочих навантажень.

Наприклад, якщо у вас є NUMA-вузол "NUMA0" з доступною памʼяттю 10 ГБ, і було вказано --reserved-memory, щоб зарезервувати 1 ГБ памʼяті в "NUMA0", Менеджер памʼяті припускає, що для контейнерів доступно тільки 9 ГБ.

Ви можете не вказувати цей параметр, але слід памʼятати, що кількість зарезервованої памʼяті з усіх NUMA-вузлів повинна дорівнювати кількості памʼяті, вказаній за допомогою функції виділення ресурсів вузла. Якщо принаймні один параметр виділення вузла не дорівнює нулю, вам слід вказати --reserved-memory принаймні для одного NUMA-вузла. Фактично, порогове значення eviction-hard типово становить 100 Mi, отже, якщо використовується політика Static, --reserved-memory є обовʼязковим.

Також слід уникати наступних конфігурацій:

  1. дублікатів, тобто того самого NUMA-вузла або типу памʼяті, але з іншим значенням;
  2. встановлення нульового ліміту для будь-якого типу памʼяті;
  3. ідентифікаторів NUMA-вузлів, які не існують в апаратному забезпеченні машини;
  4. назв типів памʼяті відмінних від memory або hugepages-<size> (великі сторінки певного розміру <size> також повинні існувати).

Синтаксис:

--reserved-memory N:memory-type1=value1,memory-type2=value2,...

  • N (ціле число) — індекс NUMA-вузла, наприклад 0
  • memory-type (рядок) — представляє тип памʼяті:
    • memory — звичайна памʼять
    • hugepages-2Mi або hugepages-1Gi — великі сторінки
  • value (рядок) - кількість зарезервованої памʼяті, наприклад 1Gi.

Приклад використання:

--reserved-memory 0:memory=1Gi,hugepages-1Gi=2Gi

або

--reserved-memory 0:memory=1Gi --reserved-memory 1:memory=2Gi

або

--reserved-memory '0:memory=1Gi;1:memory=2Gi'

При вказанні значень для прапорця --reserved-memory слід дотримуватися налаштування, яке ви вказали раніше за допомогою прапорців функції виділення вузла. Іншими словами, слід дотримуватися такого правила для кожного типу памʼяті:

sum(reserved-memory(i)) = kube-reserved + system-reserved + eviction-threshold,

де i - це індекс NUMA-вузла.

Якщо ви не дотримуєтесь вищезазначеної формули, Менеджер памʼяті покаже помилку при запуску.

Іншими словами, у вищезазначеному прикладі показано, що для звичайної памʼяті (type=memory) ми загалом резервуємо 3 ГБ, а саме:

sum(reserved-memory(i)) = reserved-memory(0) + reserved-memory(1) = 1 ГБ + 2 ГБ = 3 ГБ

Приклад командних аргументів kubelet, що стосуються конфігурації виділення вузла:

  • --kube-reserved=cpu=500m,memory=50Mi
  • --system-reserved=cpu=123m,memory=333Mi
  • --eviction-hard=memory.available<500Mi

Нижче наведено приклад правильної конфігурації:

--feature-gates=MemoryManager=true
--kube-reserved=cpu=4,memory=4Gi
--system-reserved=cpu=1,memory=1Gi
--memory-manager-policy=Static
--reserved-memory '0:memory=3Gi;1:memory=2148Mi'

Перевірмо цю конфігурацію:

  1. kube-reserved + system-reserved + eviction-hard(за замовчуванням) = reserved-memory(0) + reserved-memory(1)
  2. 4GiB + 1GiB + 100MiB = 3GiB + 2148MiB
  3. 5120MiB + 100MiB = 3072MiB + 2148MiB
  4. 5220MiB = 5220MiB (що є правильним)

Розміщення Podʼа в класі QoS Guaranteed

Якщо вибрана політика відрізняється від None, Менеджер памʼяті ідентифікує Podʼи, які належать до класу обслуговування Guaranteed. Менеджер памʼяті надає конкретні підказки топології Менеджеру топології для кожного Podʼа з класом обслуговування Guaranteed. Для Podʼів, які належать до класу обслуговування відмінного від Guaranteed, Менеджер памʼяті надає Менеджеру топології типові підказки топології.

Наведені нижче уривки з маніфестів Podʼа призначають Pod до класу обслуговування Guaranteed.

Pod з цілим значенням CPU працює в класі обслуговування Guaranteed, коли requests дорівнюють limits:

spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        memory: "200Mi"
        cpu: "2"
        example.com/device: "1"
      requests:
        memory: "200Mi"
        cpu: "2"
        example.com/device: "1"

Також Pod, який спільно використовує CPU, працює в класі обслуговування Guaranteed, коли requests дорівнюють limits.

spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        memory: "200Mi"
        cpu: "300m"
        example.com/device: "1"
      requests:
        memory: "200Mi"
        cpu: "300m"
        example.com/device: "1"

Зверніть увагу, що для Podʼа потрібно вказати як запити CPU, так і памʼяті, щоб він належав до класу обслуговування Guaranteed.

Розвʼязання проблем

Для виявлення причин, чому Pod не вдалося розгорнути або він був відхилений на вузлі, можуть бути використані наступні засоби:

  • статус Podʼа — вказує на помилки топологічної спорідненості
  • системні логи — містять цінну інформацію для налагодження, наприклад, про згенеровані підказки
  • файл стану — вивід внутрішнього стану Менеджера памʼяті (включає Node Map та Memory Map)
  • починаючи з v1.22, можна використовувати API втулка ресурсів пристроїв, щоб отримати інформацію про памʼять, зарезервовану для контейнерів.

Статус Podʼа (TopologyAffinityError)

Ця помилка зазвичай виникає у наступних ситуаціях:

  • вузол не має достатньо ресурсів, щоб задовольнити запит Podʼа
  • запит Podʼа відхилено через обмеження певної політики Менеджера топології

Помилка показується у статусі Podʼа:

kubectl get pods
NAME         READY   STATUS                  RESTARTS   AGE
guaranteed   0/1     TopologyAffinityError   0          113s

Використовуйте kubectl describe pod <id> або kubectl get events, щоб отримати докладне повідомлення про помилку:

Warning  TopologyAffinityError  10m   kubelet, dell8  Resources cannot be allocated with Topology locality

Системні логи

Шукайте системні логи для певного Podʼа.

У логах можна знайти набір підказок, які згенерував Менеджер памʼяті для Podʼа. Також у логах повинен бути присутній набір підказок, згенерований Менеджером CPU.

Менеджер топології обʼєднує ці підказки для обчислення єдиної найкращої підказки. Найкраща підказка також повинна бути присутня в логах.

Найкраща підказка вказує, куди виділити всі ресурси. Менеджер топології перевіряє цю підказку за своєю поточною політикою і, залежно від вердикту, або допускає Pod до вузла, або відхиляє його.

Також шукайте логи для випадків, повʼязаних з Менеджером памʼяті, наприклад, для отримання інформації про оновлення cgroups та cpuset.mems.

Аналіз стану менеджера памʼяті на вузлі

Спочатку розгляньмо розгорнутий зразок Guaranteed Podʼа, специфікація якого виглядає так:

apiVersion: v1
kind: Pod
metadata:
  name: guaranteed
spec:
  containers:
  - name: guaranteed
    image: consumer
    imagePullPolicy: Never
    resources:
      limits:
        cpu: "2"
        memory: 150Gi
      requests:
        cpu: "2"
        memory: 150Gi
    command: ["sleep","infinity"]

Потім увійдімо на вузол, де він був розгорнутий, і розглянемо файл стану у /var/lib/kubelet/memory_manager_state:

{
   "policyName":"Static",
   "machineState":{
      "0":{
         "numberOfAssignments":1,
         "memoryMap":{
            "hugepages-1Gi":{
               "total":0,
               "systemReserved":0,
               "allocatable":0,
               "reserved":0,
               "free":0
            },
            "memory":{
               "total":134987354112,
               "systemReserved":3221225472,
               "allocatable":131766128640,
               "reserved":131766128640,
               "free":0
            }
         },
         "nodes":[
            0,
            1
         ]
      },
      "1":{
         "numberOfAssignments":1,
         "memoryMap":{
            "hugepages-1Gi":{
               "total":0,
               "systemReserved":0,
               "allocatable":0,
               "reserved":0,
               "free":0
            },
            "memory":{
               "total":135286722560,
               "systemReserved":2252341248,
               "allocatable":133034381312,
               "reserved":29295144960,
               "free":103739236352
            }
         },
         "nodes":[
            0,
            1
         ]
      }
   },
   "entries":{
      "fa9bdd38-6df9-4cf9-aa67-8c4814da37a8":{
         "guaranteed":[
            {
               "numaAffinity":[
                  0,
                  1
               ],
               "type":"memory",
               "size":161061273600
            }
         ]
      }
   },
   "checksum":4142013182
}

З цього файлу стану можна дізнатись, що Pod був привʼязаний до обох NUMA вузлів, тобто:

"numaAffinity":[
   0,
   1
],

Термін "привʼязаний" означає, що споживання памʼяті Podʼом обмежено (через конфігурацію cgroups) цими NUMA вузлами.

Це автоматично означає, що Менеджер памʼяті створив нову групу, яка обʼєднує ці два NUMA вузли, тобто вузли з індексами 0 та 1.

Зверніть увагу, що управління групами виконується досить складним способом, і подальші пояснення надані в Memory Manager KEP в цьому та цьому розділах.

Для аналізу ресурсів памʼяті, доступних у групі, потрібно додати відповідні записи з NUMA вузлів, які належать до групи.

Наприклад, загальна кількість вільної "звичайної" памʼяті в групі може бути обчислена шляхом додавання вільної памʼяті, доступної на кожному NUMA вузлі в групі, тобто в розділі "memory" NUMA вузла 0 ("free":0) та NUMA вузла 1 ("free":103739236352). Таким чином, загальна кількість вільної "звичайної" памʼяті в цій групі дорівнює 0 + 103739236352 байт.

Рядок "systemReserved":3221225472 вказує на те, що адміністратор цього вузла зарезервував 3221225472 байти (тобто 3Gi) для обслуговування процесів kubelet та системи на NUMA вузлі 0, використовуючи прапорець --reserved-memory.

API втулка ресурсів пристроїв

Kubelet надає службу gRPC PodResourceLister для включення виявлення ресурсів та повʼязаних метаданих. Використовуючи його точку доступу List gRPC, можна отримати інформацію про зарезервовану памʼять для кожного контейнера, яка міститься у protobuf повідомленні ContainerMemory. Цю інформацію можна отримати лише для Podʼів у класі якості обслуговування Guaranteed.

Що далі

4.2.44 - Перевірка підписаних артефактів Kubernetes

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.26 [beta]

Перш ніж ви розпочнете

Вам знадобиться мати встановлені наступні інструменти:

Перевірка підписів бінарних файлів

В процесі підготовки випуску Kubernetes підписує всі бінарні артефакти (tarballs, файли SPDX, окремі бінарні файли) за допомогою безключового підписування cosign. Щоб перевірити певний бінарний файл, отримайте його разом з підписом та сертифікатом:

URL=https://dl.k8s.io/release/v1.31.0/bin/linux/amd64
BINARY=kubectl

FILES=(
    "$BINARY"
    "$BINARY.sig"
    "$BINARY.cert"
)

for FILE in "${FILES[@]}"; do
    curl -sSfL --retry 3 --retry-delay 3 "$URL/$FILE" -o "$FILE"
done

Потім перевірте блоб, використовуючи cosign verify-blob:

cosign verify-blob "$BINARY" \
  --signature "$BINARY".sig \
  --certificate "$BINARY".cert \
  --certificate-identity krel-staging@k8s-releng-prod.iam.gserviceaccount.com \
  --certificate-oidc-issuer https://accounts.google.com

Перевірка підписів образів

Для повного списку образів, які підписані, дивіться Випуски.

Оберіть один образ з цього списку та перевірте його підпис, використовуючи команду cosign verify:

cosign verify registry.k8s.io/kube-apiserver-amd64:v1.31.0 \
  --certificate-identity krel-trust@k8s-releng-prod.iam.gserviceaccount.com \
  --certificate-oidc-issuer https://accounts.google.com \
  | jq .

Перевірка образів для всіх компонентів панелі управління

Щоб перевірити всі підписані образи компонентів панелі управління для останньої стабільної версії (v1.31.0), запустіть наступні команди:

curl -Ls "https://sbom.k8s.io/$(curl -Ls https://dl.k8s.io/release/stable.txt)/release" \
  | grep "SPDXID: SPDXRef-Package-registry.k8s.io" \
  | grep -v sha256 | cut -d- -f3- | sed 's/-/\//' | sed 's/-v1/:v1/' \
  | sort > images.txt
input=images.txt
while IFS= read -r image
do
  cosign verify "$image" \
    --certificate-identity krel-trust@k8s-releng-prod.iam.gserviceaccount.com \
    --certificate-oidc-issuer https://accounts.google.com \
    | jq .
done < "$input"

Після перевірки образу можна вказати його за його дайджестом у вашому маніфесті Podʼа, як у цьому прикладі:

registry-url/image-name@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2

Для отримання додаткової інформації, див. Розділ Політика отримання образів.

Перевірка підписів образів за допомогою контролера допуску

Для образів, що не є частиною компонентів панелі управління (наприклад, образ conformance), підписи також можна перевірити під час розгортання за допомогою контролера допуску sigstore policy-controller.

Ось кілька корисних ресурсів для початку роботи з policy-controller:

Перевірка специфікації на програмне забезпечення

Ви можете перевірити Kubernetes Software Bill of Materials (SBOM), використовуючи сертифікат та підпис sigstore, або відповідні файли SHA:

# Отримайте останню доступну версію релізу Kubernetes
VERSION=$(curl -Ls https://dl.k8s.io/release/stable.txt)

# Перевірте суму SHA512
curl -Ls "https://sbom.k8s.io/$VERSION/release" -o "$VERSION.spdx"
echo "$(curl -Ls "https://sbom.k8s.io/$VERSION/release.sha512") $VERSION.spdx" | sha512sum --check

# Перевірте суму SHA256
echo "$(curl -Ls "https://sbom.k8s.io/$VERSION/release.sha256") $VERSION.spdx" | sha256sum --check

# Отримайте підпис та сертифікат sigstore
curl -Ls "https://sbom.k8s.io/$VERSION/release.sig" -o "$VERSION.spdx.sig"
curl -Ls "https://sbom.k8s.io/$VERSION/release.cert" -o "$VERSION.spdx.cert"

# Перевірте підпис sigstore
cosign verify-blob \
    --certificate "$VERSION.spdx.cert" \
    --signature "$VERSION.spdx.sig" \
    --certificate-identity krel-staging@k8s-releng-prod.iam.gserviceaccount.com \
    --certificate-oidc-issuer https://accounts.google.com \
    "$VERSION.spdx"

4.3 - Налаштування Podʼів та контейнерів

Виконайте загальні завдання конфігурації для Pod і контейнерів.

4.3.1 - Виділення ресурсів памʼяті для контейнерів та Podʼів

Ця сторінка показує, як вказати запити та ліміти памʼяті для контейнерів. Контейнери гарантовано матимуть стільки памʼяті, скільки вказано у запиті, і не отримають більше, ніж вказано у ліміті.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Для перевірки версії введіть kubectl version.

Кожен вузол у вашому кластері повинен мати принаймні 300 МіБ памʼяті.

Деякі кроки на цій сторінці вимагають запуску служби metrics-server у вашому кластері. Якщо у вас запущено metrics-server, ви можете пропустити ці кроки.

Якщо ви використовуєте Minikube, виконайте таку команду, щоб увімкнути metrics-server:

minikube addons enable metrics-server

Щоб перевірити, чи запущений metrics-server, або інший постачальник API ресурсів метрик (metrics.k8s.io), виконайте таку команду:

kubectl get apiservices

Якщо API ресурсів метрик доступне, у виводі буде міститися посилання на metrics.k8s.io.

NAME
v1beta1.metrics.k8s.io

Створення простору імен

Створіть простір імен, щоб ресурси, які ви створюєте у цьому завданні, були відокремлені від інших ресурсів у вашому кластері.

kubectl create namespace mem-example

Визначення запитів та лімітів памʼяті

Щоб вказати запит памʼяті для Контейнера, включіть поле resources:requests у маніфесті ресурсів Контейнера. Для вказівки ліміти памʼяті включіть resources:limits.

У цьому завданні ви створюєте Pod, який має один Контейнер. У Контейнера вказано запит памʼяті 100 МіБ і ліміти памʼяті 200 МіБ. Ось файл конфігурації для Podʼа:

apiVersion: v1
kind: Pod
metadata:
  name: memory-demo
  namespace: mem-example
spec:
  containers:
  - name: memory-demo-ctr
    image: polinux/stress
    resources:
      requests:
        memory: "100Mi"
      limits:
        memory: "200Mi"
    command: ["stress"]
    args: ["--vm", "1", "--vm-bytes", "150M", "--vm-hang", "1"]

Розділ args у файлі конфігурації надає аргументи для Контейнера при його запуску. Аргументи "--vm-bytes", "150M" вказують Контейнеру спробувати виділити 150 МіБ памʼяті.

Створіть Pod:

kubectl apply -f https://k8s.io/examples/pods/resource/memory-request-limit.yaml --namespace=mem-example

Перевірте, що Контейнер Podʼа працює:

kubectl get pod memory-demo --namespace=mem-example

Перегляньте детальну інформацію про Pod:

kubectl get pod memory-demo --output=yaml --namespace=mem-example

Вивід показує, що один Контейнер у Podʼі має запит памʼяті 100 МіБ та ліміти памʼяті 200 МіБ.

...
resources:
  requests:
    memory: 100Mi
  limits:
    memory: 200Mi
...

Виконайте команду kubectl top, щоб отримати метрики для Podʼа:

kubectl top pod memory-demo --namespace=mem-example

Вивід показує, що Pod використовує приблизно 162,900,000 байт памʼяті, що становить близько 150 МіБ. Це більше, ніж запит Podʼа на 100 МіБ, але в межах ліміти Podʼа на 200 МіБ.

NAME                        CPU(cores)   MEMORY(bytes)
memory-demo                 <something>  162856960

Видаліть свій Pod:

kubectl delete pod memory-demo --namespace=mem-example

Перевищення лімітів памʼяті Контейнера

Контейнер може перевищити свій запит на памʼять, якщо на вузлі є вільна памʼять. Але Контейнер не може використовувати памʼяті більше, ніж його ліміт памʼяті. Якщо Контейнер використовує більше памʼяті, ніж його ліміт, Контейнер стає кандидатом на зупинку роботи. Якщо Контейнер продовжує використовувати памʼять поза своїм лімітом, він зупиняється. Якщо Контейнер може бути перезапущений, kubelet перезапускає його, як із будь-яким іншим типом відмови під час роботи.

У цьому завданні ви створюєте Pod, який намагається виділити більше памʼяті, ніж його ліміт. Ось файл конфігурації для Podʼа, який має один Контейнер з запитом памʼяті 50 МіБ та лімітом памʼяті 100 МіБ:

apiVersion: v1
kind: Pod
metadata:
  name: memory-demo-2
  namespace: mem-example
spec:
  containers:
  - name: memory-demo-2-ctr
    image: polinux/stress
    resources:
      requests:
        memory: "50Mi"
      limits:
        memory: "100Mi"
    command: ["stress"]
    args: ["--vm", "1", "--vm-bytes", "250M", "--vm-hang", "1"]

У розділі args файлу конфігурації видно, що Контейнер спробує використати 250 МіБ памʼяті, що значно перевищує ліміт в 100 МіБ.

Створіть Pod:

kubectl apply -f https://k8s.io/examples/pods/resource/memory-request-limit-2.yaml --namespace=mem-example

Перегляньте детальну інформацію про Pod:

kubectl get pod memory-demo-2 --namespace=mem-example

На цей момент Контейнер може працювати або бути знищеним. Повторіть попередню команду, доки Контейнер не буде знищено:

NAME            READY     STATUS      RESTARTS   AGE
memory-demo-2   0/1       OOMKilled   1          24s

Отримайте більш детальний огляд стану Контейнера:

kubectl get pod memory-demo-2 --output=yaml --namespace=mem-example

Вивід показує, що Контейнер був знищений через вичерпання памʼяті (OOM):

lastState:
   terminated:
     containerID: 65183c1877aaec2e8427bc95609cc52677a454b56fcb24340dbd22917c23b10f
     exitCode: 137
     finishedAt: 2017-06-20T20:52:19Z
     reason: OOMKilled
     startedAt: null

Контейнер у цьому завданні може бути перезапущений, тому kubelet перезапускає його. Повторіть цю команду кілька разів, щоб переконатися, що Контейнер постійно знищується та перезапускається:

kubectl get pod memory-demo-2 --namespace=mem-example

Вивід показує, що Контейнер знищується, перезапускається, знищується знову, знову перезапускається і так далі:

kubectl get pod memory-demo-2 --namespace=mem-example
NAME            READY     STATUS      RESTARTS   AGE
memory-demo-2   0/1       OOMKilled   1          37s
kubectl get pod memory-demo-2 --namespace=mem-example
NAME            READY     STATUS    RESTARTS   AGE
memory-demo-2   1/1       Running   2          40s

Перегляньте детальну інформацію про історію Podʼа:

kubectʼ describe pod лімітомo-2 ʼ-namespace=mem-example

Вивід показує, що Контейнер починається і знову не вдається:

... Normal  Created   Created container with id 66a3a20aa7980e61be4922780bf9d24d1a1d8b7395c09861225b0eba1b1f8511
... Warning BackOff   Back-off restarting failed container

Перегляньте детальну інформацію про вузли вашого кластера:

kubectl describe nodes

Вивід містить запис про знищення Контейнера через умову вичерпання памʼяті:

Warning OOMKilling Memory cgroup out of memory: Kill process 4481 (stress) score 1994 or sacrifice child

Видаліть свій Pod:

kubectl delete pod memory-demo-2 --namespace=mem-example

Визначення запиту памʼяті, що є завеликим для вашого вузла

Запити та ліміт памʼяті повʼязані з Контейнерами, але корисно думати про Pod як про елемент, що має запит та ліміт памʼяті. Запит памʼяті для Podʼа — це сума запитів памʼяті для всіх Контейнерів у Podʼі. Аналогічно, ліміт памʼяті для Podʼа — це сума лімітів всіх Контейнерів у Podʼі.

Планування Podʼа ґрунтується на запитах. Pod планується кзапуску на вузлі лише у разі, якщо вузол має достатньо вільної памʼяті, щоб задовольнити запит памʼяті Podʼа.

У цьому завданні ви створюєте Pod, у якого запит памʼяті настільки великий, що перевищує можливості будь-якого вузла у вашому кластері. Ось файл конфігурації для Podʼа, у якого один Контейнер з запитом на 1000 ГіБ памʼяті, що, ймовірно, перевищує можливості будь-якого вузла у вашому кластері.

apiVersion: v1
kind: Pod
metadata:
  name: memory-demo-3
  namespace: mem-example
spec:
  containers:
  - name: memory-demo-3-ctr
    image: polinux/stress
    resources:
      requests:
        memory: "1000Gi"
      limits:
        memory: "1000Gi"
    command: ["stress"]
    args: ["--vm", "1", "--vm-bytes", "150M", "--vm-hang", "1"]

Створіть Pod:

kubectl apply -f https://k8s.io/examples/pods/resource/memory-request-limit-3.yaml --namespace=mem-example

Перегляньте статус Podʼа:

kubectl get pod memory-demo-3 --namespace=mem-example

Вивід показує, що статус Podʼа — PENDING. Це означає, що Pod не заплановано для запуску на жодному вузлі, і він залишатиметься у стані PENDING безстроково:

kubectl get pod memory-demo-3 --namespace=mem-example
NAME            READY     STATUS    RESTARTS   AGE
memory-demo-3   0/1       Pending   0          25s

Перегляньте детальну інформацію про Pod, включаючи події:

kubectl describe pod memory-demo-3 --namespace=mem-example

Вивід показує, що Контейнер не може бути запланований через нестачу памʼяті на вузлах:

Events:
  ...  Reason            Message
       ------            -------
  ...  FailedScheduling  No nodes are available that match all of the following predicates:: Insufficient memory (3).

Одиниці памʼяті

Ресурс памʼяті вимірюється у байтах. Ви можете виразити памʼять як ціле число або ціле число з одним із наступних суфіксів: E, P, T, G, M, K, Ei, Pi, Ti, Gi, Mi, Ki. Наприклад, наступні значення приблизно однакові:

128974848, 129e6, 129M, 123Mi

Видаліть свій Pod:

kubectl delete pod memory-demo-3 --namespace=mem-example

Якщо ви не вказуєте ліміт памʼяті

Якщо ви не вказуєте ліміт памʼяті для Контейнера, відбувається одне з наступного:

  • Контейнер не має верхньої межі на кількість використаної памʼяті. Контейнер може використовувати всю доступну памʼять на вузлі, де він працює, що, своєю чергою, може спричинити активацію "OOM Killer". Крім того, в разі активації "OOM Kill" Контейнер без обмежень ресурсів матиме більше шансів на знищення.

  • Контейнер працює в просторі імен, який має стандартний ліміт памʼяті, і Контейнер автоматично отримує визначений стандартний ліміт. Адміністратори кластера можуть використовувати LimitRange для зазначення стандартного ліміту памʼяті.

Для чого вказувати запит та ліміт памʼяті

Налаштовуючи запити та ліміти памʼяті для Контейнерів, які працюють у вашому кластері, ви можете ефективно використовувати ресурси памʼяті, доступні на вузлах вашого кластера. Знижуючи запит памʼяті для Podʼа, ви даєте Podʼу хороший шанс на планування. Маючи ліміти памʼяті, який перевищує запит памʼяті, ви досягаєте двох цілей:

  • Pod може мати періоди сплеску активності, коли він використовує доступну памʼять.
  • Обсяг памʼяті, який Pod може використовувати під час сплесків, обмежений до якогось розумного значення.

Очищення

Видаліть простір імен. Це видалить всі Podʼи, які ви створили для цього завдання:

kubectl delete namespace mem-example

Що далі

Для розробників застосунків

Для адміністраторів кластера

4.3.2 - Виділення ресурсів CPU контейнерам та Podʼам

Ця сторінка показує, як вказати запит та ліміт CPU для контейнера. Контейнери не можуть використовувати більше CPU, ніж налаштований ліміт. При наявності вільного часу процесора контейнера гарантується виділення стільки CPU, скільки він запитує.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Для перевірки версії введіть kubectl version.

Кожен вузол у вашому кластері повинен мати принаймні 1 CPU.

Деякі кроки на цій сторінці вимагають запуску служби metrics-server у вашому кластері. Якщо у вас запущено metrics-server, ви можете пропустити ці кроки.

Якщо ви використовуєте Minikube, виконайте таку команду, щоб увімкнути metrics-server:

minikube addons enable metrics-server

Щоб перевірити, чи запущений metrics-server, або інший постачальник API ресурсів метрик (metrics.k8s.io), виконайте таку команду:

kubectl get apiservices

Якщо API ресурсів метрик доступне, у виводі буде міститися посилання на metrics.k8s.io.

NAME
v1beta1.metrics.k8s.io

Створення простору імен

Створіть простір імен, щоб ресурси, які ви створюєте у цьому завданні, були відокремлені від інших ресурсів у вашому кластері.

kubectl create namespace cpu-example

Визначте запит ЦП та ліміт ЦП

Для вказання запиту ЦП для контейнера включіть поле resources:requests в маніфест ресурсів Контейнера. Щоб вказати ліміт ЦП, включіть resources:limits.

У цьому завданні ви створюєте Pod, у якого є один контейнер. Контейнер має запит на 0,5 CPU та ліміт 1 CPU. Ось файл конфігурації для Podʼа:

apiVersion: v1
kind: Pod
metadata:
  name: cpu-demo
  namespace: cpu-example
spec:
  containers:
  - name: cpu-demo-ctr
    image: vish/stress
    resources:
      limits:
        cpu: "1"
      requests:
        cpu: "0.5"
    args:
    - -cpus
    - "2"

Секція args у файлі конфігурації надає аргументи для контейнера при його запуску. Аргумент -cpus "2" каже Контейнеру спробувати використовувати 2 CPU.

Створіть Pod:

kubectl apply -f https://k8s.io/examples/pods/resource/cpu-request-limit.yaml --namespace=cpu-example

Перевірте, що Pod працює:

kubectl get pod cpu-demo --namespace=cpu-example

Перегляньте детальну інформацію про Pod:

kubectl get pod cpu-demo --output=yaml --namespace=cpu-example

Вивід показує, що один контейнер у Podʼі має запит ЦП 500 міліCPU та ліміт ЦП 1 CPU.

resources:
  limits:
    cpu: "1"
  requests:
    cpu: 500m

Використовуйте kubectl top, щоб отримати метрики для Podʼа:

kubectl top pod cpu-demo --namespace=cpu-example

У цьому прикладі виводу показано, що Pod використовує 974 міліCPU, що незначно менше, ніж ліміт 1 CPU, вказане в конфігурації Podʼа.

NAME                        CPU(cores)   MEMORY(bytes)
cpu-demo                    974m         <something>

Нагадуємо, що, встановивши -cpu "2", ви налаштували контейнер на спробу використати 2 CPU, але контейнер може використовувати лише близько 1 CPU. Використання ЦП контейнером обмежується, оскільки контейнер намагається використовувати більше ресурсів ЦП, ніж його ліміт.

Одиниці ЦП

Ресурс ЦП вимірюється в одиницях ЦП. Одна одиниця ЦП в Kubernetes еквівалентна:

  • 1 AWS vCPU
  • 1 GCP Core
  • 1 Azure vCore
  • 1 Hyperthread на процесорі Intel з гіперпотоками

Дозволені дробові значення. Контейнер, який запитує 0,5 ЦП, гарантовано отримує половину ЦП порівняно з контейнером, який запитує 1 ЦП. Ви можете використовувати суфікс m для позначення мілі. Наприклад, 100m ЦП, 100 міліЦП і 0,1 ЦП — це все одне й те саме. Точність, більша за 1m, не допускається.

ЦП завжди запитується як абсолютна кількість, ніколи як відносна кількість; 0.1 — це та сама кількість ЦП на одноядерному, двоядерному або 48-ядерному компʼютері.

Видаліть свій Pod:

kubectl delete pod cpu-demo --namespace=cpu-example

Визначте запит ЦП, який перевищує можливості ваших вузлів

Запити та ліміти ЦП повʼязані з контейнерами, але корисно вважати Pod таким, що має запит ЦП та ліміти. Запит ЦП для Podʼа — це сума запитів ЦП для всіх контейнерів у Podʼі. Так само, ліміти ЦП для Podʼа — це сума обмежень ЦП для всіх контейнерів у Podʼі.

Планування Podʼа базується на запитах. Pod буде запланований для запуску на вузлі тільки у випадку, якщо на вузлі є достатньо ресурсів ЦП для задоволення запиту ЦП Podʼа.

У цьому завданні ви створюєте Pod, який має запит ЦП такий великий, що він перевищує можливості будь-якого вузла у вашому кластері. Ось файл конфігурації для Podʼа, який має один контейнер. Контейнер запитує 100 ЦП, що ймовірно перевищить можливості будь-якого вузла у вашому кластері.

apiVersion: v1
kind: Pod
metadata:
  name: cpu-demo-2
  namespace: cpu-example
spec:
  containers:
  - name: cpu-demo-ctr-2
    image: vish/stress
    resources:
      limits:
        cpu: "100"
      requests:
        cpu: "100"
    args:
    - -cpus
    - "2"

Створіть Pod:

kubectl apply -f https://k8s.io/examples/pods/resource/cpu-request-limit-2.yaml --namespace=cpu-example

Перегляньте статус Podʼа:

kubectl get pod cpu-demo-2 --namespace=cpu-example

Вивід показує, що статус Podʼа — Pending. Тобто Pod не був запланований для запуску на будь-якому вузлі, і він буде залишатися в стані Pending нескінченно:

NAME         READY     STATUS    RESTARTS   AGE
cpu-demo-2   0/1       Pending   0          7m

Перегляньте детальну інформацію про Pod, включаючи події:

kubectl describe pod cpu-demo-2 --namespace=cpu-example

Вивід показує, що контейнер не може бути запланований через недостатні ресурси ЦП на вузлах:

Events:
  Reason                        Message
  ------                        -------
  FailedScheduling      No nodes are available that match all of the following predicates:: Insufficient cpu (3).

Видаліть свій Pod:

kubectl delete pod cpu-demo-2 --namespace=cpu-example

Якщо ви не вказуєте ліміт ЦП

Якщо ви не вказуєте ліміт ЦП для контейнера, то застосовується одне з наступного:

  • Контейнер не має верхньої межі ресурсів ЦП, які він може використовувати. Контейнер може використовувати всі доступні ресурси ЦП на вузлі, на якому він працює.

  • Контейнер працює в просторі імен, який має стандартний ліміт ЦП, і контейнеру автоматично призначається цей стандартний ліміт. Адміністратори кластера можуть використовувати LimitRange для зазначення стандартних значень лімітів ЦП.

Якщо ви вказуєте ліміт ЦП, але не вказуєте запит ЦП

Якщо ви вказуєте ліміт ЦП для контейнера, але не вказуєте запит ЦП, Kubernetes автоматично призначає запит ЦП, який збігається з лімітом. Аналогічно, якщо контейнер вказує свій власний ліміт памʼяті, але не вказує запит памʼяті, Kubernetes автоматично призначає запит памʼяті, який збігається з лімітом.

Для чого вказувати запит та ліміт ЦП

Налаштувавши запити та ліміти ЦП контейнерів, що працюють у вашому кластері, ви можете ефективно використовувати доступні ресурси ЦП на вузлах вашого кластера. Зберігаючи низький запит ЦП для Podʼа, ви забезпечуєте хороші шанси на його планування. Маючи ліміти ЦП, який перевищує запит ЦП, ви досягаєте двох речей:

  • Pod може мати періоди підвищеної активності, коли він використовує доступні ресурси ЦП.
  • Кількість ресурсів ЦП, які Pod може використовувати під час такої активності, обмежена розумною кількістю.

Очищення

Видаліть ваш простір імен:

kubectl delete namespace cpu-example

Що далі

Для розробників застосунків

Для адміністраторів кластерів

4.3.3 - Налаштування GMSA для Windows Podʼів та контейнерів

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.18 [stable]

Ця сторінка показує, як налаштувати Group Managed Service Accounts (GMSA) для Podʼів та контейнерів, які будуть запущені на вузлах Windows. Group Managed Service Accounts це специфічний тип облікового запису Active Directory, який забезпечує автоматичне управління паролями, спрощене управління іменами служб (SPN) та можливість делегування управління іншим адміністраторам на кількох серверах.

У Kubernetes специфікації облікових даних GMSA налаштовуються на рівні кластера Kubernetes як Custom Resources. Windows Podʼи, також як і окремі контейнери в Podʼі, можуть бути налаштовані для використання GMSA для доменних функцій (наприклад, автентифікація Kerberos) при взаємодії з іншими службами Windows.

Перш ніж ви розпочнете

Вам необхідно мати кластер Kubernetes і інструмент командного рядка kubectl, налаштований для керування з вашим кластером. Очікується, що в кластері будуть вузли Windows. Цей розділ охоплює набір початкових кроків, необхідних один раз для кожного кластера:

Встановлення CRD для GMSACredentialSpec

CustomResourceDefinition(CRD) для ресурсів специфікації облікових даних GMSA потрібно налаштувати на кластері, щоб визначити тип настроюваного ресурсу GMSACredentialSpec. Завантажте GMSA CRD YAML і збережіть як gmsa-crd.yaml. Далі встановіть CRD за допомогою kubectl apply -f gmsa-crd.yaml.

Встановлення вебхуків для перевірки користувачів GMSA

Два вебхуки потрібно налаштувати на кластері Kubernetes для заповнення та перевірки посилань на специфікації облікових даних GMSA на рівні Podʼа або контейнера:

  1. Модифікаційний вебхук, який розширює посилання на GMSAs (за іменем зі специфікації Podʼа) до повної специфікації облікових даних у форматі JSON у специфікації Podʼа.

  2. Валідаційний вебхук забезпечує, що всі посилання на GMSAs уповноважені для використання обліковим записом служби Podʼа.

Встановлення зазначених вище вебхуків та повʼязаних обʼєктів вимагає наступних кроків:

  1. Створіть пару ключів сертифікатів (яка буде використовуватися для забезпечення звʼязку контейнера вебхука з кластером)

  2. Встановіть Secret із вищезазначеним сертифікатом.

  3. Створіть Deployment для основної логіки вебхука.

  4. Створіть конфігурації валідаційного та модифікаційного вебхуків, посилаючись на Deployment.

Скрипт можна використовувати для розгортання та налаштування вебхуків GMSA та повʼязаних з ними обʼєктів, зазначених вище. Скрипт можна запускати з опцією --dry-run=server, щоб ви могли переглянути зміни, які будуть внесені в ваш кластер.

YAML шаблон, що використовується скриптом, також може бути використаний для ручного розгортання вебхуків та повʼязаних обʼєктів (з відповідними замінами параметрів)

Налаштування GMSA та вузлів Windows в Active Directory

Перш ніж Podʼи в Kubernetes можуть бути налаштовані на використання GMSA, необхідно провести налаштування бажаних GMSA в Active Directory, як описано в документації Windows GMSA. Вузли робочих станцій Windows (які є частиною кластера Kubernetes) повинні бути налаштовані в Active Directory для доступу до секретних облікових даних, що повʼязані з бажаним GMSA, як описано в документації Windows GMSA.

Створення ресурсів GMSA Credential Spec

Після встановлення CRD GMSACredentialSpec (як описано раніше), можна налаштувати власні ресурси, що містять специфікації облікових даних GMSA. Специфікація облікових даних GMSA не містить конфіденційні або секретні дані. Це інформація, яку контейнерне середовище може використовувати для опису бажаної GMSA контейнера для Windows. Специфікації облікових даних GMSA можуть бути створені у форматі YAML за допомогою утиліти сценарію PowerShell.

Ось кроки для створення YAML-файлу специфікації облікових даних GMSA вручну у форматі JSON і подальше його конвертування:

  1. Імпортуйте модуль CredentialSpec module: ipmo CredentialSpec.psm1.

  2. Створіть специфікацію облікових даних у форматі JSON за допомогою команди New-CredentialSpec. Щоб створити специфікацію облікових даних GMSA з іменем WebApp1, викличте New-CredentialSpec -Name WebApp1 -AccountName WebApp1 -Domain $(Get-ADDomain -Current LocalComputer).

  3. Використайте команду Get-CredentialSpec, щоб показати шлях до файлу JSON.

  4. Конвертуйте файл credspec з формату JSON у YAML та застосуйте необхідні заголовкові поля apiVersion, kind, metadata та credspec, щоб зробити його специфікацією GMSACredentialSpec, яку можна налаштувати в Kubernetes.

Наступна конфігурація YAML описує специфікацію облікових даних GMSA з іменем gmsa-WebApp1:

apiVersion: windows.k8s.io/v1
kind: GMSACredentialSpec
metadata:
  name: gmsa-WebApp1  # Це довільне імʼя, але воно буде використовуватися як посилання
credspec:
  ActiveDirectoryConfig:
    GroupManagedServiceAccounts:
    - Name: WebApp1   # Імʼя користувача облікового запису GMSA
      Scope: CONTOSO  # Імʼя домену NETBIOS
    - Name: WebApp1   # Імʼя користувача облікового запису GMSA
      Scope: contoso.com # Імʼя домену DNS
  CmsPlugins:
  - ActiveDirectory
  DomainJoinConfig:
    DnsName: contoso.com  # Імʼя домену DNS
    DnsTreeName: contoso.com # Корінь імені домену DNS
    Guid: 244818ae-87ac-4fcd-92ec-e79e5252348a  # GUID для Domain
    MachineAccountName: WebApp1 # Імʼя користувача облікового запису GMSA
    NetBiosName: CONTOSO  # Імʼя домену NETBIOS
    Sid: S-1-5-21-2126449477-2524075714-3094792973 # SID для Domain

Вищезазначений ресурс специфікації облікових даних може бути збережений як gmsa-Webapp1-credspec.yaml і застосований до кластера за допомогою: kubectl apply -f gmsa-Webapp1-credspec.yaml.

Налаштування ролі кластера для включення RBAC у конкретні специфікації облікових даних GMSA

Для кожного ресурсу специфікації облікових даних GMSA потрібно визначити роль в кластері. Це авторизує дію use ("використовувати") на конкретному ресурсі GMSA певним субʼєктом, який, як правило, є службовим обліковим записом. Наведений нижче приклад показує роль в кластері, яка авторизує використання специфікації облікових даних gmsa-WebApp1 зверху. Збережіть файл як gmsa-webapp1-role.yaml і застосуйте його за допомогою kubectl apply -f gmsa-webapp1-role.yaml.

# Створення ролі для читання credspec
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: webapp1-role
rules:
- apiGroups: ["windows.k8s.io"]
  resources: ["gmsacredentialspecs"]
  verbs: ["use"]
  resourceNames: ["gmsa-WebApp1"]

Призначення ролі службовому обліковому запису для використання конкретних специфікацій облікових даних GMSA

Службовий обліковий запис (з якими будуть налаштовані Podʼи) повинен бути привʼязаний до ролі в кластері, створеної вище. Це авторизує службовий обліковий запис використовувати бажаний ресурс специфікації облікових даних GMSA. Нижче показано, як стандартний службовий обліковий запис привʼязується до ролі в кластера webapp1-role для використання ресурсу специфікації облікових даних gmsa-WebApp1, створеного вище.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: allow-default-svc-account-read-on-gmsa-WebApp1
  namespace: default
subjects:
- kind: ServiceAccount
  name: default
  namespace: default
roleRef:
  kind: ClusterRole
  name: webapp1-role
  apiGroup: rbac.authorization.k8s.io

Налаштування посилання на специфікацію облікових даних GMSA в специфікації Pod

Поле securityContext.windowsOptions.gmsaCredentialSpecName у специфікації Pod використовується для вказівки посилань на бажані ресурси специфікації облікових даних GMSA в специфікаціях Pod. Це налаштовує всі контейнери в специфікації Pod на використання вказаного GMSA. Нижче наведено приклад специфікації Pod з анотацією, заповненою для посилання на gmsa-WebApp1:

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    run: with-creds
  name: with-creds
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      run: with-creds
  template:
    metadata:
      labels:
        run: with-creds
    spec:
      securityContext:
        windowsOptions:
          gmsaCredentialSpecName: gmsa-webapp1
      containers:
      - image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019
        imagePullPolicy: Always
        name: iis
      nodeSelector:
        kubernetes.io/os: windows

Індивідуальні контейнери в специфікації Pod також можуть вказати бажану специфікацію облікових даних GMSA, використовуючи поле securityContext.windowsOptions.gmsaCredentialSpecName на рівні окремого контейнера. Наприклад:

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    run: with-creds
  name: with-creds
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      run: with-creds
  template:
    metadata:
      labels:
        run: with-creds
    spec:
      containers:
      - image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019
        imagePullPolicy: Always
        name: iis
        securityContext:
          windowsOptions:
            gmsaCredentialSpecName: gmsa-Webapp1
      nodeSelector:
        kubernetes.io/os: windows

Під час застосування специфікацій Pod з заповненими полями GMSA (як описано вище) в кластері відбувається наступна послідовність подій:

  1. Модифікаційний вебхук розвʼязує та розширює всі посилання на ресурси специфікації облікових даних GMSA до вмісту специфікації облікових даних GMSA.

  2. Валідаційний вебхук переконується, що обліковий запис служби, повʼязаний з Pod, авторизований для дії use на вказаній специфікації облікових даних GMSA.

  3. Контейнерне середовище налаштовує кожен контейнер Windows із вказаною специфікацією облікових даних GMSA, щоб контейнер міг прийняти елемент GMSA в Active Directory та отримати доступ до служб в домені, використовуючи цей елемент.

Автентифікація на мережевих ресурсах за допомогою імені хосту або повного доменного імені

Якщо ви маєте проблеми з підключенням до SMB-ресурсів з Podʼів за допомогою імені хосту або повного доменного імені, але можете отримати доступ до ресурсів за їх адресою IPv4, переконайтеся, що встановлений наступний ключ реєстру на вузлах Windows.

reg add "HKLM\SYSTEM\CurrentControlSet\Services\hns\State" /v EnableCompartmentNamespace /t REG_DWORD /d 1

Після цього потрібно перестворити Podʼи, щоб вони врахували зміни в поведінці. Додаткову інформацію про те, як використовується цей ключ реєстру, можна знайти тут.

Усунення несправностей

Якщо у вас виникають труднощі з налаштуванням роботи GMSA в вашому середовищі, існують кілька кроків усунення несправностей, які ви можете виконати.

Спочатку переконайтеся, що credspec був переданий до Podʼа. Для цього вам потрібно виконати команду exec в одному з ваших Podʼів і перевірити вивід команди nltest.exe /parentdomain.

У наступному прикладі Pod не отримав credspec правильно:

kubectl exec -it iis-auth-7776966999-n5nzr powershell.exe

Результат команди nltest.exe /parentdomain показує наступну помилку:

Getting parent domain failed: Status = 1722 0x6ba RPC_S_SERVER_UNAVAILABLE

Якщо ваш Pod отримав credspec правильно, наступним кроком буде перевірка звʼязку з доменом. Спочатку, зсередини вашого Podʼа, виконайте nslookup, щоб знайти корінь вашого домену.

Це дозволить нам визначити 3 речі:

  1. Pod може досягти контролера домену (DC).
  2. Контролер домену (DC) може досягти Podʼа.
  3. DNS працює правильно.

Якщо тест DNS та комунікації успішний, наступним буде перевірка, чи Pod встановив захищений канал звʼязку з доменом. Для цього, знову ж таки, виконайте команду exec в вашому Podʼі та запустіть команду nltest.exe /query.

nltest.exe /query

Результат буде наступним:

I_NetLogonControl failed: Статус = 1722 0x6ba RPC_S_SERVER_UNAVAILABLE

Це говорить нам те, що з якоїсь причини Pod не зміг увійти в домен, використовуючи обліковий запис, вказаний у credspec. Ви можете спробувати полагодити захищений канал за допомогою наступного:

nltest /sc_reset:domain.example

Якщо команда успішна, ви побачите подібний вивід:

Flags: 30 HAS_IP  HAS_TIMESERV
Trusted DC Name \\dc10.domain.example
Trusted DC Connection Status Status = 0 0x0 NERR_Success
The command completed successfully

Якщо дії вище виправили помилку, ви можете автоматизувати цей крок, додавши наступний виклик у час життєвого циклу до специфікації вашого Podʼа. Якщо це не виправило помилку, вам потрібно перевірити ваш credspec ще раз та підтвердити, що він правильний та повний.

        image: registry.domain.example/iis-auth:1809v1
        lifecycle:
          postStart:
            exec:
              command: ["powershell.exe","-command","do { Restart-Service -Name netlogon } while ( $($Result = (nltest.exe /query); if ($Result -like '*0x0 NERR_Success*') {return $true} else {return $false}) -eq $false)"]
        imagePullPolicy: IfNotPresent

Якщо ви додасте розділ lifecycle до специфікації вашого Podʼа, Pod виконає вказані команди для перезапуску служби netlogon до того, як команда nltest.exe /query вийде без помилок.

4.3.4 - Зміна обсягів CPU та памʼяті, призначених для контейнерів

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.27 [alpha]

Ця сторінка передбачає, що ви обізнані з Якістю обслуговування для Podʼів Kubernetes.

Ця сторінка показує, як змінити обсяги CPU та памʼяті, призначені для контейнерів працюючого Podʼа без перезапуску самого Podʼа або його контейнерів. Вузол Kubernetes виділяє ресурси для Podʼа на основі його запитів, і обмежує використання ресурсів Podʼа на основі лімітів, вказаних у контейнерах Podʼа.

Зміна розподілу ресурсів для запущеного Podʼа вимагає, що функціональна можливість InPlacePodVerticalScaling має бути увімкнено. Альтернативою може бути видалення Podʼа і ввімкнення параметра, щоб workload controller створив новий Pod з іншими вимогами до ресурсів.

Для зміни ресурсів Podʼа на місці:

  • Ресурси запитів та лімітів контейнера є змінними для ресурсів CPU та памʼяті.
  • Поле allocatedResources у containerStatuses статусу Podʼа відображає ресурси, виділені контейнерам Podʼа.
  • Поле resources у containerStatuses статусу Podʼа відображає фактичні ресурси запитів та лімітів, які налаштовані на запущених контейнерах відповідно до звіту контейнерного середовища.
  • Поле resize у статусі Podʼа показує статус останнього запиту очікуваної зміни розміру. Воно може мати наступні значення:
    • Proposed: Це значення показує, що було отримано підтвердження запиту на зміну розміру та що запит був перевірений та зареєстрований.
    • InProgress: Це значення вказує, що вузол прийняв запит на зміну розміру та знаходиться у процесі застосування його до контейнерів Podʼа.
    • Deferred: Це значення означає, що запитаної зміни розміру наразі не можна виконати, і вузол буде спробувати її виконати пізніше. Зміна розміру може бути виконана, коли інші Podʼи покинуть і звільнять ресурси вузла.
    • Infeasible: це сигнал того, що вузол не може задовольнити запит на зміну розміру. Це може статися, якщо запит на зміну розміру перевищує максимальні ресурси, які вузол може виділити для Podʼа.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Версія вашого Kubernetes сервера має бути не старішою ніж 1.27. Для перевірки версії введіть kubectl version.

Має бути увімкнено функціональну можливість InPlacePodVerticalScaling для вашої панелі управління і для всіх вузлів вашого кластера.

Політики зміни розміру контейнера

Політики зміни розміру дозволяють більш детально керувати тим, як контейнери Podʼа змінюють свої ресурси CPU та памʼяті. Наприклад, застосунок з контейнера може використовувати ресурси CPU, змінені без перезапуску, але зміна памʼяті може вимагати перезапуску застосунку та відповідно контейнерів.

Для активації цього користувачам дозволяється вказати resizePolicy у специфікації контейнера. Наступні політики перезапуску можна вказати для зміни розміру CPU та памʼяті:

  • NotRequired: Змінити ресурси контейнера під час його роботи.
  • RestartContainer: Перезапустити контейнер та застосувати нові ресурси після перезапуску.

Якщо resizePolicy[*].restartPolicy не вказано, воно стандартно встановлюється в NotRequired.

У наведеному нижче прикладі Podʼа CPU контейнера може бути змінено без перезапуску, але змінювання памʼяті вимагає перезапуску контейнера.

apiVersion: v1
kind: Pod
metadata:
  name: qos-demo-5
  namespace: qos-example
spec:
  containers:
  - name: qos-demo-ctr-5
    image: nginx
    resizePolicy:
    - resourceName: cpu
      restartPolicy: NotRequired
    - resourceName: memory
      restartPolicy: RestartContainer
    resources:
      limits:
        memory: "200Mi"
        cpu: "700m"
      requests:
        memory: "200Mi"
        cpu: "700m"

Створення Podʼа із запитами та лімітами ресурсів

Ви можете створити Guaranteed або Burstable клас якості обслуговування Podʼу, вказавши запити та/або ліміти для контейнерів Podʼа.

Розгляньте наступний маніфест для Podʼа, який має один контейнер.

apiVersion: v1
kind: Pod
metadata:
  name: qos-demo-5
  namespace: qos-example
spec:
  containers:
  - name: qos-demo-ctr-5
    image: nginx
    resources:
      limits:
        memory: "200Mi"
        cpu: "700m"
      requests:
        memory: "200Mi"
        cpu: "700m"

Створіть Pod у просторі імен qos-example:

kubectl create namespace qos-example
kubectl create -f https://k8s.io/examples/pods/qos/qos-pod-5.yaml

Цей Pod класифікується як Pod класу якості обслуговування Guaranteed, і має запит 700 мілі CPU та 200 мегабайтів памʼяті.

Перегляньте детальну інформацію про Pod:

kubectl get pod qos-demo-5 --output=yaml --namespace=qos-example

Також погляньте, що значення resizePolicy[*].restartPolicy типово встановлено в NotRequired, що вказує, що CPU та памʼять можна змінити, поки контейнер працює.

spec:
  containers:
    ...
    resizePolicy:
    - resourceName: cpu
      restartPolicy: NotRequired
    - resourceName: memory
      restartPolicy: NotRequired
    resources:
      limits:
        cpu: 700m
        memory: 200Mi
      requests:
        cpu: 700m
        memory: 200Mi
...
  containerStatuses:
...
    name: qos-demo-ctr-5
    ready: true
...
    allocatedResources:
      cpu: 700m
      memory: 200Mi
    resources:
      limits:
        cpu: 700m
        memory: 200Mi
      requests:
        cpu: 700m
        memory: 200Mi
    restartCount: 0
    started: true
...
  qosClass: Guaranteed

Оновлення ресурсів Podʼа

Скажімо, вимоги до CPU зросли, і тепер потрібно 0.8 CPU. Це можна вказати вручну, або визначити і застосувати програмно, наприклад, за допомогою таких засобів, як VerticalPodAutoscaler (VPA).

Тепер відредагуйте контейнер Podʼа, встановивши як запити, так і ліміти CPU на 800m:

kubectl -n qos-example patch pod qos-demo-5 --patch '{"spec":{"containers":[{"name":"qos-demo-ctr-5", "resources":{"requests":{"cpu":"800m"}, "limits":{"cpu":"800m"}}}]}}'

Отримайте докладну інформацію про Pod після внесення змін.

kubectl get pod qos-demo-5 --output=yaml --namespace=qos-example

Специфікація Podʼа нижче показує оновлені запити та ліміти CPU.

spec:
  containers:
    ...
    resources:
      limits:
        cpu: 800m
        memory: 200Mi
      requests:
        cpu: 800m
        memory: 200Mi
...
  containerStatuses:
...
    allocatedResources:
      cpu: 800m
      memory: 200Mi
    resources:
      limits:
        cpu: 800m
        memory: 200Mi
      requests:
        cpu: 800m
        memory: 200Mi
    restartCount: 0
    started: true

Зверніть увагу, що значення allocatedResources були оновлені, щоб відображати нові бажані запити CPU. Це вказує на те, що вузол зміг забезпечити потреби у збільшених ресурсах CPU.

У статусі контейнера оновлені значення ресурсів CPU показують, що нові CPU ресурси були застосовані. Значення restartCount контейнера залишається без змін, що вказує на те, що ресурси CPU контейнера були змінені без перезапуску контейнера.

Очищення

Видаліть ваш простір імен:

kubectl delete namespace qos-example

Для розробників застосунків

Для адміністраторів кластерів

4.3.5 - Налаштування RunAsUserName для Podʼів та контейнерів Windows

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.18 [stable]

Ця сторінка показує, як використовувати параметр runAsUserName для Podʼів та контейнерів, які будуть запущені на вузлах Windows. Це приблизно еквівалент параметра runAsUser, який використовується для Linux, і дозволяє виконувати програми в контейнері від імені іншого імені користувача, ніж типово.

Перш ніж ви розпочнете

Вам потрібно мати кластер Kubernetes, а також інструмент командного рядка kubectl повинен бути налаштований для взаємодії з вашим кластером. Очікується, що в кластері будуть використовуватися вузли Windows, де будуть запускатися Podʼи з контейнерами, що виконують робочі навантаження у Windows.

Встановлення імені користувача для Podʼа

Щоб вказати імʼя користувача, з яким потрібно виконати процеси контейнера Podʼа, включіть поле securityContext (PodSecurityContext) в специфікацію Podʼа, а всередині нього — поле windowsOptions (WindowsSecurityContextOptions), що містить поле runAsUserName.

Опції безпеки Windows, які ви вказуєте для Podʼа, застосовуються до всіх контейнерів та контейнерів ініціалізації у Podʼі.

Ось конфігураційний файл для Podʼа Windows зі встановленим полем runAsUserName:

apiVersion: v1
kind: Pod
metadata:
  name: run-as-username-pod-demo
spec:
  securityContext:
    windowsOptions:
      runAsUserName: "ContainerUser"
  containers:
  - name: run-as-username-demo
    image: mcr.microsoft.com/windows/servercore:ltsc2019
    command: ["ping", "-t", "localhost"]
  nodeSelector:
    kubernetes.io/os: windows

Створіть Pod:

kubectl apply -f https://k8s.io/examples/windows/run-as-username-pod.yaml

Перевірте, що Контейнер Podʼа працює:

kubectl get pod run-as-username-pod-demo

Отримайте доступ до оболонки контейнера:

kubectl exec -it run-as-username-pod-demo -- powershell

Перевірте, що оболонка працює від імені відповідного користувача:

echo $env:USERNAME

Вивід повинен бути:

ContainerUser

Встановлення імені користувача для контейнера

Щоб вказати імʼя користувача, з яким потрібно виконати процеси контейнера, включіть поле securityContext (SecurityContext) у маніфесті контейнера, а всередині нього — поле windowsOptions (WindowsSecurityContextOptions), що містить поле runAsUserName.

Опції безпеки Windows, які ви вказуєте для контейнера, застосовуються тільки до цього окремого контейнера, і вони перевизначають налаштування, зроблені на рівні Podʼа.

Ось конфігураційний файл для Podʼа, який має один Контейнер, а поле runAsUserName встановлене на рівні Podʼа та на рівні Контейнера:

apiVersion: v1
kind: Pod
metadata:
  name: run-as-username-container-demo
spec:
  securityContext:
    windowsOptions:
      runAsUserName: "ContainerUser"
  containers:
  - name: run-as-username-demo
    image: mcr.microsoft.com/windows/servercore:ltsc2019
    command: ["ping", "-t", "localhost"]
    securityContext:
        windowsOptions:
            runAsUserName: "ContainerAdministrator"
  nodeSelector:
    kubernetes.io/os: windows

Створіть Pod:

kubectl apply -f https://k8s.io/examples/windows/run-as-username-container.yaml

Перевірте, що Контейнер Podʼа працює:

kubectl get pod run-as-username-container-demo

Отримайте доступ до оболонки контейнера:

kubectl exec -it run-as-username-container-demo -- powershell

Перевірте, що оболонка працює від імені відповідного користувача (того, який встановлений на рівні контейнера):

echo $env:USERNAME

Вивід повинен бути:

ContainerAdministrator

Обмеження імен користувачів Windows

Для використання цієї функції значення, встановлене у полі runAsUserName, повинно бути дійсним імʼям користувача. Воно повинно мати наступний формат: DOMAIN\USER, де DOMAIN\ є необовʼязковим. Імена користувачів Windows регістронезалежні. Крім того, існують деякі обмеження стосовно DOMAIN та USER:

  • Поле runAsUserName не може бути порожнім і не може містити керуючі символи (ASCII значення: 0x00-0x1F, 0x7F)
  • DOMAIN може бути або NetBios-імʼям, або DNS-імʼям, кожне з власними обмеженнями:
    • NetBios імена: максимум 15 символів, не можуть починатися з . (крапка), і не можуть містити наступні символи: \ / : * ? " < > |
    • DNS-імена: максимум 255 символів, містять тільки буквено-цифрові символи, крапки та дефіси, і не можуть починатися або закінчуватися . (крапка) або - (дефіс).
  • USER може мати не більше 20 символів, не може містити тільки крапки або пробіли, і не може містити наступні символи: " / \ [ ] : ; | = , + * ? < > @.

Приклади припустимих значень для поля runAsUserName: ContainerAdministrator, ContainerUser, NT AUTHORITY\NETWORK SERVICE, NT AUTHORITY\LOCAL SERVICE.

Для отримання додаткової інформації про ці обмеження, перевірте тут та тут.

Що далі

4.3.6 - Створення Podʼа Windows HostProcess

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.26 [stable]

Windows HostProcess контейнери дозволяють вам запускати контейнеризовані робочі навантаження на хості Windows. Ці контейнери працюють як звичайні процеси, але мають доступ до мережевого простору імен хосту, сховища та пристроїв, коли надані відповідні права користувача. Контейнери HostProcess можуть бути використані для розгортання мережевих втулків, сховищ конфігурацій, пристроїв, kube-proxy та інших компонентів на вузлах Windows без потреби у власних проксі або безпосереднього встановлення служб хосту.

Адміністративні завдання, такі як встановлення патчів безпеки, збір подій логів тощо, можна виконувати без потреби входу операторів кластера на кожен вузол Windows. Контейнери HostProcess можуть працювати як будь-який користувач, що доступний на хості або в домені машини хосту, що дозволяє адміністраторам обмежити доступ до ресурсів через дозволи користувача. Хоча і не підтримуються ізоляція файлової системи або процесу, при запуску контейнера на хості створюється новий том, щоб надати йому чисте та обʼєднане робоче середовище. Контейнери HostProcess також можуть бути побудовані на базі наявних образів базової системи Windows і не успадковують ті ж вимоги сумісності як контейнери Windows server, що означає, що версія базового образу не повинна відповідати версії хосту. Однак рекомендується використовувати ту ж версію базового образу, що й ваші робочі навантаження контейнерів Windows Server, щоб уникнути зайвого використання місця на вузлі. Контейнери HostProcess також підтримують монтування томів всередині тома контейнера.

Коли варто використовувати контейнери Windows HostProcess?

  • Коли потрібно виконати завдання, які потребують мережевого простору імен хосту. Контейнери HostProcess мають доступ до мережевих інтерфейсів хосту та IP-адрес.
  • Вам потрібен доступ до ресурсів на хості, таких як файлова система, події логів тощо.
  • Встановлення конкретних драйверів пристроїв або служб Windows.
  • Обʼєднання адміністративних завдань та політик безпеки. Це зменшує ступінь привілеїв, які потрібні вузлам Windows.

Перш ніж ви розпочнете

Цей посібник стосується конкретно Kubernetes v1.31. Якщо ви використовуєте іншу версію Kubernetes, перевірте документацію для цієї версії Kubernetes.

У Kubernetes 1.31 контейнери HostProcess є типово увімкненими. kubelet буде спілкуватися з containerd безпосередньо, передаючи прапорець hostprocess через CRI. Ви можете використовувати останню версію containerd (v1.6+) для запуску контейнерів HostProcess. Як встановити containerd.

Обмеження

Ці обмеження стосуються Kubernetes v1.31:

  • Контейнери HostProcess вимагають середовища виконання контейнерів containerd 1.6 або вище, рекомендується використовувати containerd 1.7.
  • Podʼи HostProcess можуть містити лише контейнери HostProcess. Це поточне обмеження ОС Windows; непривілейовані контейнери Windows не можуть спільно використовувати vNIC з простором імен IP хосту.
  • Контейнери HostProcess запускаються як процес на хості та не мають жодного рівня ізоляції, окрім обмежень ресурсів, накладених на обліковий запис користувача HostProcess. Ізоляція ні файлової системи, ні ізоляції Hyper-V не підтримуються для контейнерів HostProcess.
  • Монтування томів підтримуються і монтуватимуться як томом контейнера. Див. Монтування томів
  • Стандартно для контейнерів HostProcess доступний обмежений набір облікових записів користувачів хосту. Див. Вибір облікового запису користувача.
  • Обмеження ресурсів (диск, памʼять, кількість процесорів) підтримуються так само як і процеси на хості.
  • Як іменовані канали, так і сокети Unix-домену не підтримуються і замість цього слід отримувати доступ до них через їх шлях на хості (наприклад, \\.\pipe\*)

Вимоги до конфігурації HostProcess Pod

Для активації Windows HostProcess Pod необхідно встановити відповідні конфігурації у конфігурації безпеки Podʼа. З усіх політик, визначених у Стандартах безпеки Pod, HostProcess Podʼи заборонені за базовою та обмеженою політиками. Тому рекомендується, щоб HostProcess Podʼи працювали відповідно до привілейованого профілю.

Під час роботи з привілейованою політикою, ось конфігурації, які потрібно встановити для активації створення HostProcess Pod:

Специфікація привілейованої політики
ЕлементПолітика
securityContext.windowsOptions.hostProcess

Windows Podʼи надають можливість запуску контейнерів HostProcess, які дозволяють привілейований доступ до вузла Windows.

Дозволені значення

  • true
hostNetwork

Контейнери HostProcess Podʼи повинні використовувати мережевий простір хоста.

Дозволені значення

  • true
securityContext.windowsOptions.runAsUserName

Необхідно вказати, яким користувачем має виконуватися контейнер HostProcess в специфікації Podʼа.

Дозволені значення

  • NT AUTHORITY\SYSTEM
  • NT AUTHORITY\Local service
  • NT AUTHORITY\NetworkService
  • Назви локальних груп користувачів (див. нижче)
runAsNonRoot

Оскільки контейнери HostProcess мають привілейований доступ до хоста, поле runAsNonRoot не може бути встановлене в true.

Дозволені значення

  • Undefined/Nil
  • false

Приклад маніфесту (частково)

spec:
  securityContext:
    windowsOptions:
      hostProcess: true
      runAsUserName: "NT AUTHORITY\\Local service"
  hostNetwork: true
  containers:
  - name: test
    image: image1:latest
    command:
      - ping
      - -t
      - 127.0.0.1
  nodeSelector:
    "kubernetes.io/os": windows

Монтування томів

Контейнери HostProcess підтримують можливість монтування томів у просторі томів контейнера. Поведінка монтування томів відрізняється залежно від версії контейнерного середовища containerd, яке використовується на вузлі.

Containerd v1.6

Застосунки, що працюють усередині контейнера, можуть отримувати доступ до підключених томів безпосередньо за допомогою відносних або абсолютних шляхів. Під час створення контейнера встановлюється змінна середовища $CONTAINER_SANDBOX_MOUNT_POINT, яка містить абсолютний шлях хосту до тому контейнера. Відносні шляхи базуються на конфігурації .spec.containers.volumeMounts.mountPath.

Для доступу до токенів облікового запису служби (наприклад) у контейнері підтримуються такі структури шляхів:

  • .\var\run\secrets\kubernetes.io\serviceaccount\
  • $CONTAINER_SANDBOX_MOUNT_POINT\var\run\secrets\kubernetes.io\serviceaccount\

Containerd v1.7 (та новіші версії)

Застосунки, які працюють усередині контейнера, можуть отримувати доступ до підключених томів безпосередньо через вказаний mountPath тому (аналогічно Linux і не-HostProcess контейнерам Windows).

Для забезпечення зворотної сумісності зі старими версіями, доступ до томів також може бути здійснений через використання тих самих відносних шляхів, які були налаштовані у containerd v1.6.

Наприклад, для доступу до токенів службового облікового запису усередині контейнера ви можете використовувати один із таких шляхів:

  • c:\var\run\secrets\kubernetes.io\serviceaccount
  • /var/run/secrets/kubernetes.io/serviceaccount/
  • $CONTAINER_SANDBOX_MOUNT_POINT\var\run\secrets\kubernetes.io\serviceaccount\

Обмеження ресурсів

Обмеження ресурсів (диск, памʼять, кількість CPU) застосовуються до задачі і є загальними для всієї задачі. Наприклад, при обмеженні в 10 МБ памʼяті, памʼять, виділена для будь-якого обʼєкта задачі HostProcess, буде обмежена 10 МБ. Це така ж поведінка, як і в інших типах контейнерів Windows. Ці обмеження вказуються так само як і зараз для будь-якого середовища виконання контейнерів або оркестрування, яке використовується. Єдина відмінність полягає у розрахунку використання дискових ресурсів для відстеження ресурсів через відмінності у способі ініціалізації контейнерів HostProcess.

Вибір облікового запису користувача

Системні облікові записи

Типово контейнери HostProcess підтримують можливість запуску з одного з трьох підтримуваних облікових записів служб Windows:

Вам слід вибрати відповідний обліковий запис служби Windows для кожного контейнера HostProcess, спираючись на обмеження ступеня привілеїв, щоб уникнути випадкових (або навіть зловмисних) пошкоджень хосту. Обліковий запис служби LocalSystem має найвищий рівень привілеїв серед трьох і повинен використовуватися лише у разі абсолютної необхідності. Де це можливо, використовуйте обліковий запис служби LocalService, оскільки він має найнижчий рівень привілеїв серед цих трьох варіантів.

Локальні облікові записи

Якщо налаштовано, контейнери HostProcess також можуть запускатися як локальні облікові записи користувачів, що дозволяє операторам вузлів надавати деталізований доступ до робочих навантажень.

Для запуску контейнерів HostProcess як локального користувача, спершу на вузлі має бути створена локальна група користувачів, і імʼя цієї локальної групи користувачів повинно бути вказане у полі runAsUserName у Deployment. Перед ініціалізацією контейнера HostProcess має бути створено новий ефемерний локальний обліковий запис користувача та приєднано його до вказаної групи користувачів, з якої запускається контейнер. Це надає кілька переваг, включаючи уникнення необхідності управління паролями для локальних облікових записів користувачів. Початковий контейнер HostProcess, що працює як службовий обліковий запис, може бути використаний для підготовки груп користувачів для подальших контейнерів HostProcess.

Приклад:

  1. Створіть локальну групу користувачів на вузлі (це може бути зроблено в іншому контейнері HostProcess).

    net localgroup hpc-localgroup /add
    
  2. Надайте доступ до потрібних ресурсів на вузлі локальній групі користувачів. Це можна зробити за допомогою інструментів, таких як icacls.

  3. Встановіть runAsUserName на імʼя локальної групи користувачів для Podʼа або окремих контейнерів.

    securityContext:
      windowsOptions:
        hostProcess: true
        runAsUserName: hpc-localgroup
    
  4. Заплануйте Pod!

Базовий образ для контейнерів HostProcess

Контейнери HostProcess можуть бути побудовані з будь-яких наявних базових образів контейнерів Windows.

Крім того, був створений новий базовий образ спеціально для контейнерів HostProcess! Для отримання додаткової інформації перегляньте проєкт windows-host-process-containers-base-image на github.

Розвʼязання проблем з контейнерами HostProcess

  • Контейнери HostProcess не запускаються, помилка failed to create user process token: failed to logon user: Access is denied.: unknown.

    Переконайтеся, що containerd працює як службовий обліковий запис LocalSystem або LocalService. Облікові записи користувачів (навіть адміністраторські облікові записи) не мають дозволів на створення токенів входу для будь-яких підтримуваних облікових записів користувачів.

4.3.7 - Налаштування якості обслуговування для Podʼів

Ця сторінка показує, як налаштувати Podʼи так, щоб їм були призначені певні класи якості обслуговування (QoS). Kubernetes використовує класи QoS для прийняття рішень про видалення Podʼів, коли використання ресурсів вузла збільшується.

Коли Kubernetes створює Pod, він призначає один з таких класів QoS для Podʼа:

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Також вам потрібно мати можливість створювати та видаляти простори імен.

Створення простору імен

Створіть простір імен, щоб ресурси, які ви створюєте у цьому завданні, були ізольовані від решти вашого кластера.

kubectl create namespace qos-example

Створення Podʼа, якому призначено клас QoS Guaranteed

Щоб Podʼа був наданий клас QoS Guaranteed:

  • Кожний контейнер у Pod повинен мати ліміт памʼяті та запит памʼяті.
  • Для кожного контейнера у Pod ліміт памʼяті повинен дорівнювати запиту памʼяті.
  • Кожний контейнер у Pod повинен мати ліміт CPU та запит CPU.
  • Для кожного контейнера у Pod ліміт CPU повинен дорівнювати запиту CPU.

Ці обмеження так само застосовуються до контейнерів ініціалізації і до контейнерів застосунків. Ефемерні контейнери не можуть визначати ресурси, тому ці обмеження не застосовуються до них.

Нижче подано маніфест для Podʼа з одним контейнером. Контейнер має ліміт памʼяті та запит памʼяті, обидва дорівнюють 200 MiB. Контейнер має ліміт CPU та запит CPU, обидва дорівнюють 700 міліCPU:

apiVersion: v1
kind: Pod
metadata:
  name: qos-demo
  namespace: qos-example
spec:
  containers:
  - name: qos-demo-ctr
    image: nginx
    resources:
      limits:
        memory: "200Mi"
        cpu: "700m"
      requests:
        memory: "200Mi"
        cpu: "700m"

Створіть Pod:

kubectl apply -f https://k8s.io/examples/pods/qos/qos-pod.yaml --namespace=qos-example

Перегляньте докладну інформацію про Pod:

kubectl get pod qos-demo --namespace=qos-example --output=yaml

Вивід показує, що Kubernetes призначив Podʼу клас QoS Guaranteed. Також вивід підтверджує, що у контейнера Podʼа є запит памʼяті, який відповідає його ліміту памʼяті, і є запит CPU, який відповідає його ліміту CPU.

spec:
  containers:
    ...
    resources:
      limits:
        cpu: 700m
        memory: 200Mi
      requests:
        cpu: 700m
        memory: 200Mi
    ...
status:
  qosClass: Guaranteed

Очищення

Видаліть свій Pod:

kubectl delete pod qos-demo --namespace=qos-example

Створення Podʼа, якому призначено клас QoS Burstable

Podʼу надається клас QoS Burstable, якщо:

  • Pod не відповідає критеріям для класу QoS Guaranteed.
  • Принаймні один контейнер у Podʼі має запит або ліміт памʼяті або CPU.

Нижче подано маніфест для Podʼа з одним контейнером. Контейнер має ліміт памʼяті 200 MiB та запит памʼяті 100 MiB.

apiVersion: v1
kind: Pod
metadata:
  name: qos-demo-2
  namespace: qos-example
spec:
  containers:
  - name: qos-demo-2-ctr
    image: nginx
    resources:
      limits:
        memory: "200Mi"
      requests:
        memory: "100Mi"

Створіть Pod:

kubectl apply -f https://k8s.io/examples/pods/qos/qos-pod-2.yaml --namespace=qos-example

Перегляньте докладну інформацію про Pod:

kubectl get pod qos-demo-2 --namespace=qos-example --output=yaml

Вивід показує, що Kubernetes призначив Podʼу клас QoS Burstable:

spec:
  containers:
  - image: nginx
    imagePullPolicy: Always
    name: qos-demo-2-ctr
    resources:
      limits:
        memory: 200Mi
      requests:
        memory: 100Mi
  ...
status:
  qosClass: Burstable

Очищення

Видаліть свій Pod:

kubectl delete pod qos-demo-2 --namespace=qos-example

Створення Podʼа, якому призначено клас QoS BestEffort

Для того, щоб Podʼу був призначений клас QoS BestEffort, контейнери у Podʼі не повинні мати жодних лімітів або запитів памʼяті чи CPU.

Нижче подано маніфест для Podʼа з одним контейнером. контейнер не має лімітів або запитів памʼяті чи CPU:

apiVersion: v1
kind: Pod
metadata:
  name: qos-demo-3
  namespace: qos-example
spec:
  containers:
  - name: qos-demo-3-ctr
    image: nginx

Створіть Pod:

kubectl apply -f https://k8s.io/examples/pods/qos/qos-pod-3.yaml --namespace=qos-example

Перегляньте докладну інформацію про Pod:

kubectl get pod qos-demo-3 --namespace=qos-example --output=yaml

Вивід показує, що Kubernetes призначив Podʼа клас QoS BestEffort:

spec:
  containers:
    ...
    resources: {}
  ...
status:
  qosClass: BestEffort

Очищення

Видаліть свій Pod:

kubectl delete pod qos-demo-3 --namespace=qos-example

Створення Podʼа з двома контейнерами

Нижче подано маніфест для Podʼа з двома контейнерами. Один контейнер вказує запит памʼяті 200 MiB. Інший контейнер не вказує жодних запитів або лімітів.

apiVersion: v1
kind: Pod
metadata:
  name: qos-demo-4
  namespace: qos-example
spec:
  containers:

  - name: qos-demo-4-ctr-1
    image: nginx
    resources:
      requests:
        memory: "200Mi"

  - name: qos-demo-4-ctr-2
    image: redis

Зверніть увагу, що цей Pod відповідає критеріям класу QoS Burstable. Тобто, він не відповідає критеріям для класу QoS Guaranteed, і один з його контейнерів має запит памʼяті.

Створіть Pod:

kubectl apply -f https://k8s.io/examples/pods/qos/qos-pod-4.yaml --namespace=qos-example

Перегляньте докладну інформацію про Pod:

kubectl get pod qos-demo-4 --namespace=qos-example --output=yaml

Вивід показує, що Kubernetes призначив Podʼу клас QoS Burstable:

spec:
  containers:
    ...
    name: qos-demo-4-ctr-1
    resources:
      requests:
        memory: 200Mi
    ...
    name: qos-demo-4-ctr-2
    resources: {}
    ...
status:
  qosClass: Burstable

Отримання класу QoS Podʼа

Замість того, щоб бачити всі поля, ви можете переглянути лише поле, яке вам потрібно:

kubectl --namespace=qos-example get pod qos-demo-4 -o jsonpath='{ .status.qosClass}{"\n"}'
Burstable

Очищення

Видаліть ваш простір імен:

kubectl delete namespace qos-example

Що далі

Для розробників застосунків

Для адміністраторів кластера

4.3.8 - Призначення розширених ресурсів контейнеру

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.31 [stable]

Ця сторінка показує, як призначити розширені ресурси контейнеру.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Для перевірки версії введіть kubectl version.

Перш ніж виконувати це завдання, виконайте завдання Оголошення розширених ресурсів для вузла. Це налаштує один з ваших вузлів для оголошення ресурсу "dongle".

Призначте розширений ресурс Podʼу

Щоб запитати розширений ресурс, включіть поле resources:requests у ваш маніфест контейнера. Розширені ресурси повністю кваліфікуються будь-яким доменом поза *.kubernetes.io/. Дійсні імена розширених ресурсів мають форму example.com/foo, де example.com замінено на домен вашої організації, а foo — це описове імʼя ресурсу.

Нижче подано конфігураційний файл для Podʼа з одним контейнером:

apiVersion: v1
kind: Pod
metadata:
  name: extended-resource-demo
spec:
  containers:
  - name: extended-resource-demo-ctr
    image: nginx
    resources:
      requests:
        example.com/dongle: 3
      limits:
        example.com/dongle: 3

У конфігураційному файлі можна побачити, що контейнер запитує 3 розширених ресурси "dongle".

Створіть Pod:

kubectl apply -f https://k8s.io/examples/pods/resource/extended-resource-pod.yaml

Перевірте, що Pod працює:

kubectl get pod extended-resource-demo

Опишіть Pod:

kubectl describe pod extended-resource-demo

Виведений текст показує запити донглів:

Limits:
  example.com/dongle: 3
Requests:
  example.com/dongle: 3

Спроба створення другого Podʼа

Нижче наведено конфігураційний файл для Podʼа з одним контейнером. Контейнер запитує два розширені ресурси "dongle".

apiVersion: v1
kind: Pod
metadata:
  name: extended-resource-demo-2
spec:
  containers:
  - name: extended-resource-demo-2-ctr
    image: nginx
    resources:
      requests:
        example.com/dongle: 2
      limits:
        example.com/dongle: 2

Kubernetes не зможе задовольнити запит на два донгли, оскільки перший Pod використав три з чотирьох доступних донглів.

Спроба створити Pod:

kubectl apply -f https://k8s.io/examples/pods/resource/extended-resource-pod-2.yaml

Опишіть Pod:

kubectl describe pod extended-resource-demo-2

Текст виводу показує, що Pod не може бути запланованим, оскільки немає вузла, на якому було б доступно 2 донгли:

Conditions:
  Type    Status
  PodScheduled  False
...
Events:
  ...
  ... Warning   FailedScheduling  pod (extended-resource-demo-2) failed to fit in any node
fit failure summary on nodes : Insufficient example.com/dongle (1)

Перегляньте статус Podʼа:

kubectl get pod extended-resource-demo-2

Текст виводу показує, що Pod було створено, але не заплановано для виконання на вузлі. Він має статус Pending:

NAME                       READY     STATUS    RESTARTS   AGE
extended-resource-demo-2   0/1       Pending   0          6m

Очищення

Видаліть Podʼи, які ви створили для цього завдання:

kubectl delete pod extended-resource-demo
kubectl delete pod extended-resource-demo-2

Для розробників застосунків

Для адміністраторів кластера

4.3.9 - Налаштування Podʼа для використання тому для зберігання

Ця сторінка показує, як налаштувати Pod для використання тому для зберігання.

Файлова система контейнера існує лише поки існує сам контейнер. Отже, коли контейнер завершує роботу та перезавантажується, зміни в файловій системі втрачаються. Для більш стійкого зберігання, яке не залежить від контейнера, ви можете використовувати том. Це особливо важливо для застосунків, що зберігають стан, таких як бази даних і сховища ключ-значення (наприклад, Redis).

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Для перевірки версії введіть kubectl version.

Налаштування тому для Podʼа

У цьому завданні ви створюєте Pod, який запускає один контейнер. У цьому Podʼі є том типу emptyDir, який існує протягом усього життєвого циклу Podʼа, навіть якщо контейнер завершиться та перезапуститься. Ось конфігураційний файл для Podʼа:

apiVersion: v1
kind: Pod
metadata:
  name: redis
spec:
  containers:
  - name: redis
    image: redis
    volumeMounts:
    - name: redis-storage
      mountPath: /data/redis
  volumes:
  - name: redis-storage
    emptyDir: {}
  1. Створіть Pod:

    kubectl apply -f https://k8s.io/examples/pods/storage/redis.yaml
    
  2. Перевірте, що контейнер Podʼа працює, а потім спостерігайте за змінами в Podʼі:

    kubectl get pod redis --watch
    

    Вивід буде подібний до цього:

    NAME      READY     STATUS    RESTARTS   AGE
    redis     1/1       Running   0          13s
    
  3. В іншому терміналі отримайте доступ до оболонки запущеного контейнера:

    kubectl exec -it redis -- /bin/bash
    
  4. У вашій оболонці перейдіть до /data/redis, а потім створіть файл:

    root@redis:/data# cd /data/redis/
    root@redis:/data/redis# echo Hello > test-file
    
  5. У вашій оболонці виведіть список запущених процесів:

    root@redis:/data/redis# apt-get update
    root@redis:/data/redis# apt-get install procps
    root@redis:/data/redis# ps aux
    

    Вивід буде схожий на це:

    USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
    redis        1  0.1  0.1  33308  3828 ?        Ssl  00:46   0:00 redis-server *:6379
    root        12  0.0  0.0  20228  3020 ?        Ss   00:47   0:00 /bin/bash
    root        15  0.0  0.0  17500  2072 ?        R+   00:48   0:00 ps aux
    
  6. У вашій оболонці завершіть процес Redis:

    root@redis:/data/redis# kill <pid>
    

    де <pid> — це ідентифікатор процесу Redis (PID).

  7. У вашому початковому терміналі спостерігайте за змінами в Podʼі Redis. В кінцевому результаті ви побачите щось подібне:

    NAME      READY     STATUS     RESTARTS   AGE
    redis     1/1       Running    0          13s
    redis     0/1       Completed  0         6m
    redis     1/1       Running    1         6m
    

На цьому етапі контейнер завершився та перезапустився. Це тому, що Pod Redis має restartPolicy Always.

  1. Отримайте доступ до оболонки в перезапущеному контейнері:

    kubectl exec -it redis -- /bin/bash
    
  2. У вашій оболонці перейдіть до /data/redis та перевірте, що test-file все ще там.

    root@redis:/data/redis# cd /data/redis/
    root@redis:/data/redis# ls
    test-file
    
  3. Видаліть Pod, який ви створили для цього завдання:

    kubectl delete pod redis
    

Що далі

  • Дивіться Volume.

  • Дивіться Pod.

  • Крім локального сховища на диску, яке надає emptyDir, Kubernetes підтримує багато різних рішень для мережевого сховища, включаючи PD на GCE та EBS на EC2, які бажані для критичних даних та будуть обробляти деталі, такі як монтування та розмонтування пристроїв на вузлах. Дивіться Volumes для отримання додаткової інформації.

4.3.10 - Налаштування Podʼа для використання PersistentVolume для зберігання

Ця сторінка показує, як налаштувати Pod для використання PersistentVolumeClaim для зберігання. Ось короткий опис процесу:

  1. Ви, як адміністратор кластера, створюєте PersistentVolume на основі фізичного сховища. Ви не повʼязуєте том з жодним Podʼом.

  2. Ви, як розробник / користувач кластера, створюєте PersistentVolumeClaim, який автоматично привʼязується до відповідного PersistentVolume.

  3. Ви створюєте Pod, який використовує вищезгаданий PersistentVolumeClaim для зберігання.

Перш ніж ви розпочнете

  • Вам потрібно мати кластер Kubernetes, який має лише один вузол, і kubectl повинен бути налаштований на спілкування з вашим кластером. Якщо у вас ще немає кластера з одним вузлом, ви можете створити його, використовуючи Minikube.

  • Ознайомтеся з матеріалом в Постійні томи.

Створіть файл index.html на вашому вузлі

Відкрийте оболонку на єдиному вузлі вашого кластера. Спосіб відкриття оболонки залежить від того, як ви налаштували ваш кластер. Наприклад, якщо ви використовуєте Minikube, ви можете відкрити оболонку до вашого вузла, введенням minikube ssh.

У вашій оболонці на цьому вузлі створіть теку /mnt/data:

# Це передбачає, що ваш вузол використовує "sudo" для запуску команд
# як суперкористувач
sudo mkdir /mnt/data

У теці /mnt/data створіть файл index.html:

# Це також передбачає, що ваш вузол використовує "sudo" для запуску команд
# як суперкористувач
sudo sh -c "echo 'Hello from Kubernetes storage' > /mnt/data/index.html"

Перевірте, що файл index.html існує:

cat /mnt/data/index.html

Виведення повинно бути:

Hello from Kubernetes storage

Тепер ви можете закрити оболонку вашого вузла.

Створення PersistentVolume

У цьому завданні ви створюєте hostPath PersistentVolume. Kubernetes підтримує hostPath для розробки та тестування на одновузловому кластері. PersistentVolume типу hostPath використовує файл або теку на вузлі для емуляції мережевого сховища.

В операційному кластері ви не використовували б hostPath. Замість цього адміністратор кластера створив би мережевий ресурс, такий як постійний диск Google Compute Engine, розділ NFS або том Amazon Elastic Block Store. Адміністратори кластера також можуть використовувати StorageClasses для динамічного налаштування.

Ось файл конфігурації для PersistentVolume типу hostPath:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: task-pv-volume
  labels:
    type: local
spec:
  storageClassName: manual
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/mnt/data"

Файл конфігурації вказує, що том знаходиться в /mnt/data на вузлі кластера. Конфігурація також вказує розмір 10 гібібайт та режим доступу ReadWriteOnce, що означає, що том може бути підключений як для читання-запису лише одним вузлом. Визначається імʼя StorageClass manual для PersistentVolume, яке буде використовуватися для привʼязки запитів PersistentVolumeClaim до цього PersistentVolume.

Створіть PersistentVolume:

kubectl apply -f https://k8s.io/examples/pods/storage/pv-volume.yaml

Перегляньте інформацію про PersistentVolume:

kubectl get pv task-pv-volume

Вивід показує, що PersistentVolume має STATUS Available. Це означає, що він ще не був привʼязаний до PersistentVolumeClaim.

NAME             CAPACITY   ACCESSMODES   RECLAIMPOLICY   STATUS      CLAIM     STORAGECLASS   REASON    AGE
task-pv-volume   10Gi       RWO           Retain          Available             manual                   4s

Створення PersistentVolumeClaim

Наступним кроком є створення PersistentVolumeClaim. Podʼи використовують PersistentVolumeClaim для запиту фізичного сховища. У цій вправі ви створюєте PersistentVolumeClaim, який запитує том не менше трьох гібібайт, який може забезпечити доступ до читання-запису не більше одного вузла за раз.

Ось файл конфігурації для PersistentVolumeClaim:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: task-pv-claim
spec:
  storageClassName: manual
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 3Gi

Створіть PersistentVolumeClaim:

kubectl apply -f https://k8s.io/examples/pods/storage/pv-claim.yaml

Після створення PersistentVolumeClaim панель управління Kubernetes шукає PersistentVolume, який відповідає вимогам заявки. Якщо панель управління знаходить відповідний PersistentVolume з тим самим StorageClass, вона привʼязує заявку до тому.

Знову подивіться на PersistentVolume:

kubectl get pv task-pv-volume

Тепер вивід показує STATUS як Bound.

NAME             CAPACITY   ACCESSMODES   RECLAIMPOLICY   STATUS    CLAIM                   STORAGECLASS   REASON    AGE
task-pv-volume   10Gi       RWO           Retain          Bound     default/task-pv-claim   manual                   2m

Подивіться на PersistentVolumeClaim:

kubectl get pvc task-pv-claim

Вивід показує, що PersistentVolumeClaim привʼязаний до вашого PersistentVolume, task-pv-volume.

NAME            STATUS    VOLUME           CAPACITY   ACCESSMODES   STORAGECLASS   AGE
task-pv-claim   Bound     task-pv-volume   10Gi       RWO           manual         30s

Створення Podʼа

Наступним кроком є створення Podʼа, який використовує ваш PersistentVolumeClaim як том.

Ось файл конфігурації для Podʼа:

apiVersion: v1
kind: Pod
metadata:
  name: task-pv-pod
spec:
  volumes:
    - name: task-pv-storage
      persistentVolumeClaim:
        claimName: task-pv-claim
  containers:
    - name: task-pv-container
      image: nginx
      ports:
        - containerPort: 80
          name: "http-server"
      volumeMounts:
        - mountPath: "/usr/share/nginx/html"
          name: task-pv-storage


Зверніть увагу, що файл конфігурації Podʼа вказує PersistentVolumeClaim, але не вказує PersistentVolume. З погляду Podʼа, заявка є томом.

Створіть Pod:

kubectl apply -f https://k8s.io/examples/pods/storage/pv-pod.yaml

Перевірте, що контейнер у Podʼі працює:

kubectl get pod task-pv-pod

Відкрийте оболонку для контейнера, що працює у вашому Podʼі:

kubectl exec -it task-pv-pod -- /bin/bash

У вашій оболонці перевірте, що nginx обслуговує файл index.html з тому hostPath:

# Обовʼязково запустіть ці 3 команди всередині кореневої оболонки, яка є результатом
# виконання "kubectl exec" на попередньому кроці
apt update
apt install curl
curl http://localhost/

Вивід показує текст, який ви записали у файл index.html у томі hostPath:

Hello from Kubernetes storage

Якщо ви бачите це повідомлення, ви успішно налаштували Pod для використання зберігання з PersistentVolumeClaim.

Очищення

Видаліть Pod, PersistentVolumeClaim та PersistentVolume:

kubectl delete pod task-pv-pod
kubectl delete pvc task-pv-claim
kubectl delete pv task-pv-volume

Якщо у вас ще не відкрито оболонку до вузла у вашому кластері, відкрийте нову оболонку так само як ви робили це раніше.

У оболонці на вашому вузлі видаліть файл і теку, які ви створили:

# Це передбачає, що ваш вузол використовує "sudo" для виконання команд
# з правами суперкористувача
sudo rm /mnt/data/index.html
sudo rmdir /mnt/data

Тепер ви можете закрити оболонку доступу до вашого вузла.

Монтування одного PersistentVolume у два місця


apiVersion: v1
kind: Pod
metadata:
  name: test
spec:
  containers:
    - name: test
      image: nginx
      volumeMounts:
        # a mount for site-data
        - name: config
          mountPath: /usr/share/nginx/html
          subPath: html
        # another mount for nginx config
        - name: config
          mountPath: /etc/nginx/nginx.conf
          subPath: nginx.conf
  volumes:
    - name: config
      persistentVolumeClaim:
        claimName: test-nfs-claim

Ви можете виконати монтування томуу двох місцях у вашому контейнері nginx:

  • /usr/share/nginx/html для статичного вебсайту
  • /etc/nginx/nginx.conf для стандартної конфігурації

Контроль доступу

Зберігання даних із використанням ідентифікатора групи (GID) дозволяє запис лише для Podʼів, які використовують той самий GID. Невідповідність або відсутність GID призводить до помилок доступу. Щоб зменшити необхідність координації з користувачами, адміністратор може анотувати PersistentVolume з GID. Після цього GID автоматично додається до будь-якого Podʼа, який використовує цей PersistentVolume.

Використовуйте анотацію pv.beta.kubernetes.io/gid наступним чином:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv1
  annotations:
    pv.beta.kubernetes.io/gid: "1234"

Коли Pod використовує PersistentVolume з анотацією GID, анотований GID застосовується до всіх контейнерів у Podʼі так само як GID, зазначені у контексті безпеки Podʼа. Кожен GID, незалежно від того, чи походить він з анотації PersistentVolume або специфікації Podʼа, застосовується до першого процесу, запущеного в кожному контейнері.

Що далі

Довідка

4.3.11 - Налаштування Pod для використання projected тому для зберігання

Ця сторінка показує, як використовувати projected том, щоб змонтувати декілька наявних джерел томів у одну теку. Наразі можна проєктувати томи типів secret, configMap, downwardAPI, та serviceAccountToken.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Для перевірки версії введіть kubectl version.

Налаштування projected тому для Pod

У цьому завданні ви створите Secrets із локальних файлів для імені користувача та пароля. Потім ви створите Pod, який запускає один контейнер, використовуючи projected том для монтування секретів у спільну теку.

Ось файл конфігурації для Pod:

apiVersion: v1
kind: Pod
metadata:
  name: test-projected-volume
spec:
  containers:
  - name: test-projected-volume
    image: busybox:1.28
    args:
    - sleep
    - "86400"
    volumeMounts:
    - name: all-in-one
      mountPath: "/projected-volume"
      readOnly: true
  volumes:
  - name: all-in-one
    projected:
      sources:
      - secret:
          name: user
      - secret:
          name: pass
  1. Створіть Secrets:

    # Створіть файли, що містять імʼя користувача та пароль:
    echo -n "admin" > ./username.txt
    echo -n "1f2d1e2e67df" > ./password.txt
    
    # Запакуйте ці файли у секрети:
    kubectl create secret generic user --from-file=./username.txt
    kubectl create secret generic pass --from-file=./password.txt
    
  2. Створіть Pod:

    kubectl apply -f https://k8s.io/examples/pods/storage/projected.yaml
    
  3. Перевірте, що контейнер Pod запущено, а потім слідкуйте за змінами в Podʼі:

    kubectl get --watch pod test-projected-volume
    

    Вивід буде виглядати так:

    NAME                    READY     STATUS    RESTARTS   AGE
    test-projected-volume   1/1       Running   0          14s
    
  4. В іншому терміналі отримайте оболонку до запущеного контейнера:

    kubectl exec -it test-projected-volume -- /bin/sh
    
  5. У вашій оболонці перевірте, що тека projected-volume містить ваші projected джерела:

    ls /projected-volume/
    

Очищення

Видаліть Pod та Secrets:

kubectl delete pod test-projected-volume
kubectl delete secret user pass

Що далі

  • Дізнайтеся більше про projected томи.
  • Прочитайте документ про проєктування all-in-one volume.

4.3.12 - Налаштування контексту безпеки для Podʼа або контейнера

Контекст безпеки визначає параметри привілеїв та контролю доступу для Podʼа або контейнера. Налаштування контексту безпеки включають, але не обмежуються:

  • Дискреційний контроль доступу: Дозвіл на доступ до обʼєкта, такого як файл, базується на ідентифікаторі користувача (UID) та ідентифікаторі групи (GID).

  • Security Enhanced Linux (SELinux): Обʼєкти призначаються мітки безпеки.

  • Виконання з привілеями або без них.

  • Linux Capabilities: Надає процесу деякі привілеї, але не всі привілеї користувача root.

  • AppArmor: Використовуйте профілі програм для обмеження можливостей окремих програм.

  • Seccomp: Фільтрує системні виклики процесу.

  • allowPrivilegeEscalation: Контролює, чи може процес отримувати більше привілеїв, ніж його батьківський процес. Ця логічна величина безпосередньо контролює, чи встановлюється прапорець no_new_privs для процесу контейнера. allowPrivilegeEscalation завжди true, коли контейнер:

    • запущений з привілеями, або
    • має CAP_SYS_ADMIN
  • readOnlyRootFilesystem: Підключає кореневу файлову систему контейнера тільки для читання.

Вищевказані пункти не є повним набором налаштувань контексту безпеки,докладну інформацію див. у SecurityContext для повного переліку.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Для перевірки версії введіть kubectl version.

Встановлення контексту безпеки для Pod

Щоб вказати параметри безпеки для Podʼа, включіть поле securityContext в специфікацію Pod. Поле securityContext є обʼєктом PodSecurityContext. Параметри безпеки, які ви вказуєте для Pod, застосовуються до всіх контейнерів в Podʼі. Ось файл конфігурації для Podʼа з securityContext та томом emptyDir:

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
    fsGroup: 2000
    supplementalGroups: [4000]
  volumes:
  - name: sec-ctx-vol
    emptyDir: {}
  containers:
  - name: sec-ctx-demo
    image: busybox:1.28
    command: [ "sh", "-c", "sleep 1h" ]
    volumeMounts:
    - name: sec-ctx-vol
      mountPath: /data/demo
    securityContext:
      allowPrivilegeEscalation: false

У файлі конфігурації поле runAsUser вказує, що для будь-яких контейнерів в Podʼі, всі процеси виконуються з ідентифікатором користувача 1000. Поле runAsGroup вказує основний ідентифікатор групи 3000 для усіх процесів у контейнерах Pod. Якщо це поле відсутнє, основний ідентифікатор групи контейнерів буде root(0). Будь-які створені файли також належатимуть користувачу 1000 та групі 3000 при вказанні runAsGroup. Оскільки вказано поле fsGroup, всі процеси контейнера також належать до додаткової групи ідентифікатора 2000. Власником тому /data/demo та всіх створених файлів у цьому томі буде груповий ідентифікатор 2000. Додатково, коли вказане поле supplementalGroups, всі процеси контейнера також є частиною вказаних груп. Якщо це поле пропущене, це означає, що воно порожнє.

Створіть Pod:

kubectl apply -f https://k8s.io/examples/pods/security/security-context.yaml

Перевірте, що контейнер Pod запущений:

kubectl get pod security-context-demo

Отримайте оболонку до запущеного контейнера:

kubectl exec -it security-context-demo -- sh

У вашій оболонці перелічіть запущені процеси:

ps

Виведений результат показує, що процеси виконуються від імені користувача 1000, що є значенням runAsUser:

PID   USER     TIME  COMMAND
    1 1000      0:00 sleep 1h
    6 1000      0:00 sh
...

У вашій оболонці перейдіть до /data, та виведіть список тек:

cd /data
ls -l

Виведений результат показує, що тека /data/demo має ідентифікатор групи 2000, що є значенням fsGroup.

drwxrwsrwx 2 root 2000 4096 Jun  6 20:08 demo

У вашій оболонці перейдіть до /data/demo, та створіть файл:

cd demo
echo hello > testfile

Виведіть список файлів у теці /data/demo:

ls -l

Виведений результат показує, що testfile має ідентифікатор групи 2000, що є значенням fsGroup.

-rw-r--r-- 1 1000 2000 6 Jun  6 20:08 testfile

Виконайте наступну команду:

id

Результат буде схожий на цей:

uid=1000 gid=3000 groups=2000,3000,4000

З результату видно, що gid дорівнює 3000, що є таким самим, як поле runAsGroup. Якби поле runAsGroup було пропущено, gid залишився б 0 (root), і процес зміг би взаємодіяти з файлами, які належать групі root(0) та групам, які мають необхідні права групи для групи root (0). Ви також можете побачити, що groups містить ідентифікатори груп, які вказані в fsGroup і supplementalGroups, поряд з gid.

Вийдіть з оболонки:

exit

Неявні членства груп, визначені в /etc/group в контейнерному образі

Стандартно Kubernetes обʼєднує інформацію про групи з Podʼа з інформацією, визначеною в /etc/group в контейнерному образі.

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
    supplementalGroups: [4000]
  containers:
  - name: sec-ctx-demo
    image: registry.k8s.io/e2e-test-images/agnhost:2.45
    command: [ "sh", "-c", "sleep 1h" ]
    securityContext:
      allowPrivilegeEscalation: false

Цей контекст безпеки Podʼа містить runAsUser, runAsGroup та supplementalGroups. Проте ви можете побачити, що фактичні додаткові групи, що прикріплені до процесу контейнера, включатимуть ідентифікатори груп, які походять з /etc/group всередині контейнерного образу.

Створіть Pod:

kubectl apply -f https://k8s.io/examples/pods/security/security-context-5.yaml

Перевірте, чи контейнер Pod запущений:

kubectl get pod security-context-demo

Отримайте оболонку для запущеного контейнера:

kubectl exec -it security-context-demo -- sh

Перевірте ідентичність процесу:

$ id

Вивід буде схожий на:

uid=1000 gid=3000 groups=3000,4000,50000

Ви можете побачити, що groups включає ідентифікатор групи 50000. Це тому, що користувач (uid=1000), який визначений в образі, належить до групи (gid=50000), яка визначена в /etc/group всередині контейнерного образу.

Перевірте /etc/group в контейнерному образі:

$ cat /etc/group

Ви побачите, що uid 1000 належить до групи 50000.

...
user-defined-in-image:x:1000:
group-defined-in-image:x:50000:user-defined-in-image

Вийдіть з оболонки:

exit

Налаштування SupplementalGroups для Podʼа

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.31 [alpha]

Цю функцію можна увімкнути, встановивши функціональну можливість SupplementalGroupsPolicy для kubelet та kube-apiserver, а також налаштувавши поле .spec.securityContext.supplementalGroupsPolicy для Podʼа.

Поле supplementalGroupsPolicy визначає політику для розрахунку додаткових груп для процесів контейнера в Podʼі. Для цього поля є два дійсних значення:

  • Merge: Членство в групах, визначене в /etc/group для основного користувача контейнера, буде обʼєднано. Це є стандартною політикою, якщо не зазначено інше.

  • Strict: Тільки ідентифікатори груп у полях fsGroup, supplementalGroups або runAsGroup прикріплюються як додаткові групи для процесів контейнера. Це означає, що жодне членство в групах з /etc/group для основного користувача контейнера не буде обʼєднано.

Коли функція увімкнена, вона також надає ідентичність процесу, прикріплену до першого процесу контейнера в полі .status.containerStatuses[].user.linux. Це буде корисно для виявлення, чи прикріплені неявні ідентифікатори груп.

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
    supplementalGroups: [4000]
    supplementalGroupsPolicy: Strict
  containers:
  - name: sec-ctx-demo
    image: registry.k8s.io/e2e-test-images/agnhost:2.45
    command: [ "sh", "-c", "sleep 1h" ]
    securityContext:
      allowPrivilegeEscalation: false

Цей маніфест Podʼа визначає supplementalGroupsPolicy=Strict. Ви можете побачити, що жодне членство в групах, визначене в /etc/group, не обʼєднується в додаткові групи для процесів контейнера.

Створіть Pod:

kubectl apply -f https://k8s.io/examples/pods/security/security-context-6.yaml

Перевірте, що контейнер Podʼа працює:

kubectl get pod security-context-demo

Перевірте ідентичність процесу:

kubectl exec -it security-context-demo -- id

Вивід буде подібним до цього:

uid=1000 gid=3000 groups=3000,4000

Перегляньте статус Podʼа:

kubectl get pod security-context-demo -o yaml

Ви можете побачити, що поле status.containerStatuses[].user.linux надає ідентичність процесу, прикріплену до першого процесу контейнера.

...
status:
  containerStatuses:
  - name: sec-ctx-demo
    user:
      linux:
        gid: 3000
        supplementalGroups:
        - 3000
        - 4000
        uid: 1000
...

Реалізації

Відомо, що наступні середовища виконання контейнерів підтримують контроль додаткових груп з тонкою настройкою.

На рівні CRI:

Ви можете перевірити, чи підтримується функція в статусі вузла.

apiVersion: v1
kind: Node
...
status:
  features:
    supplementalGroupsPolicy: true

Налаштування політики зміни дозволів та прав власності тому для Pod

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.23 [stable]

Типово Kubernetes рекурсивно змінює права власності та дозволи для вмісту кожного тому так, щоб вони відповідали значенню fsGroup, вказаному в securityContext Podʼа при підключенні цього тому. Для великих томів перевірка та зміна власності та дозволів може займати багато часу, сповільнюючи запуск Podʼів. Ви можете використовувати поле fsGroupChangePolicy в securityContext для контролю способу, яким Kubernetes перевіряє та керує власністю та дозволами для тому.

fsGroupChangePolicy — fsGroupChangePolicy визначає поведінку зміни власності та дозволів тому перед тим, як він буде використаний в Pod. Це поле застосовується лише до типів томів, які підтримують контроль власності та дозволів за допомогою fsGroup. Це поле має два можливі значення:

  • OnRootMismatch: Змінювати дозволи та права власності тільки у випадку, якщо дозволи та права кореневої теки не відповідають очікуваним дозволам тому. Це може допомогти скоротити час зміни власності та дозволів тому.
  • Always: Завжди змінювати дозволи та права власності тому під час підключення.

Наприклад:

securityContext:
  runAsUser: 1000
  runAsGroup: 3000
  fsGroup: 2000
  fsGroupChangePolicy: "OnRootMismatch"

Делегування зміни прав власності та дозволів тому до драйвера CSI

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.26 [stable]

Якщо ви розгортаєте драйвер Container Storage Interface (CSI), який підтримує VOLUME_MOUNT_GROUP NodeServiceCapability, процес встановлення права власності та дозволів файлу на основі fsGroup, вказаного в securityContext, буде виконуватися драйвером CSI, а не Kubernetes. У цьому випадку, оскільки Kubernetes не виконує жодної зміни права власності та дозволів, fsGroupChangePolicy не набуває чинності, і згідно з вказаним CSI, очікується, що драйвер монтує том з наданим fsGroup, що призводить до отримання тому, який є доступними для читаання/запису для fsGroup.

Встановлення контексту безпеки для контейнера

Для вказання параметрів безпеки для контейнера, включіть поле securityContext в маніфест контейнера. Поле securityContext є обʼєктом SecurityContext. Параметри безпеки, які ви вказуєте для контейнера, застосовуються тільки до окремого контейнера, і вони перевизначають налаштування, зроблені на рівні Podʼа, коли є перетин. Налаштування контейнера не впливають на томи Podʼів.

Ось файл конфігурації для Podʼа з одним контейнером. Як Pod, так і контейнер мають поле securityContext:

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo-2
spec:
  securityContext:
    runAsUser: 1000
  containers:
  - name: sec-ctx-demo-2
    image: gcr.io/google-samples/hello-app:2.0
    securityContext:
      runAsUser: 2000
      allowPrivilegeEscalation: false

Створіть Pod:

kubectl apply -f https://k8s.io/examples/pods/security/security-context-2.yaml

Перевірте, що контейнер Pod запущений:

kubectl get pod security-context-demo-2

Отримайте оболонку до запущеного контейнера:

kubectl exec -it security-context-demo-2 -- sh

У вашій оболонці перегляньте запущені процеси:

ps aux

Виведений результат показує, що процеси виконуються від імені користувача 2000. Це значення runAsUser, вказане для контейнера. Воно перевизначає значення 1000, вказане для Pod.

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
2000         1  0.0  0.0   4336   764 ?        Ss   20:36   0:00 /bin/sh -c node server.js
2000         8  0.1  0.5 772124 22604 ?        Sl   20:36   0:00 node server.js
...

Вийдіть з оболонки:

exit

Встановлення можливостей для контейнера

За допомогою можливостей Linux, ви можете надати певні привілеї процесу, не надаючи всі привілеї користувачеві з правами root. Щоб додати або видалити можливості Linux для контейнера, включіть поле capabilities в розділ securityContext маніфесту контейнера.

Спочатку подивімося, що відбувається, коли ви не включаєте поле capabilities. Ось файл конфігурації, який не додає або не видаляє жодних можливостей контейнера:

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo-3
spec:
  containers:
  - name: sec-ctx-3
    image: gcr.io/google-samples/hello-app:2.0

Створіть Pod:

kubectl apply -f https://k8s.io/examples/pods/security/security-context-3.yaml

Перевірте, що контейнер Pod запущений:

kubectl get pod security-context-demo-3

Отримайте оболонку до запущеного контейнера:

kubectl exec -it security-context-demo-3 -- sh

У вашій оболонці перегляньте запущені процеси:

ps aux

Виведений результат показує ідентифікатори процесів (PID) для контейнера:

USER  PID %CPU %MEM    VSZ   RSS TTY   STAT START   TIME COMMAND
root    1  0.0  0.0   4336   796 ?     Ss   18:17   0:00 /bin/sh -c node server.js
root    5  0.1  0.5 772124 22700 ?     Sl   18:17   0:00 node server.js

У вашій оболонці перегляньте статус для процесу 1:

cd /proc/1
cat status

Виведений результат показує bitmap можливостей для процесу:

...
CapPrm:	00000000a80425fb
CapEff:	00000000a80425fb
...

Запамʼятайте bitmap можливостей, а потім вийдіть з оболонки:

exit

Далі, запустіть контейнер, який є такий самий, як попередній контейнер, за винятком того, що він має додаткові можливості.

Ось файл конфігурації для Pod, який запускає один контейнер. Конфігурація додає можливості CAP_NET_ADMIN та CAP_SYS_TIME:

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo-4
spec:
  containers:
  - name: sec-ctx-4
    image: gcr.io/google-samples/hello-app:2.0
    securityContext:
      capabilities:
        add: ["NET_ADMIN", "SYS_TIME"]

Створіть Pod:

kubectl apply -f https://k8s.io/examples/pods/security/security-context-4.yaml

Отримайте оболонку до запущеного контейнера:

kubectl exec -it security-context-demo-4 -- sh

У вашій оболонці перегляньте можливості для процесу 1:

cd /proc/1
cat status

Виведений результат показує бітову карту можливостей для процесу:

...
CapPrm:	00000000aa0435fb
CapEff:	00000000aa0435fb
...

Порівняйте можливості двох контейнерів:

00000000a80425fb
00000000aa0435fb

У bitmap можливостей першого контейнера біти 12 і 25 не встановлені. У другому контейнері, біти 12 і 25 встановлені. Біт 12 — це CAP_NET_ADMIN, а біт 25 — це CAP_SYS_TIME. Дивіться capability.h для визначень констант можливостей.

Встановлення профілю Seccomp для контейнера

Щоб встановити профіль Seccomp для контейнера, включіть поле seccompProfile в розділ securityContext вашого маніфесту Pod або контейнера. Поле seccompProfile є обʼєктом SeccompProfile, який складається з type та localhostProfile. Допустимі варіанти для type включають RuntimeDefault, Unconfined та Localhost. localhostProfile повинен бути встановлений лише якщо type: Localhost. Він вказує шлях до попередньо налаштованого профілю на вузлі, повʼязаного з розташуванням налаштованого профілю Seccomp kubelet (налаштованого за допомогою прапорця --root-dir).

Ось приклад, який встановлює профіль Seccomp до стандартного профілю контейнера вузла:

...
securityContext:
  seccompProfile:
    type: RuntimeDefault

Ось приклад, який встановлює профіль Seccomp до попередньо налаштованого файлу за шляхом <kubelet-root-dir>/seccomp/my-profiles/profile-allow.json:

...
securityContext:
  seccompProfile:
    type: Localhost
    localhostProfile: my-profiles/profile-allow.json

Налаштування профілю AppArmor для контейнера

Щоб налаштувати профіль AppArmor для контейнера, включіть поле appArmorProfile в секцію securityContext вашого контейнера. Поле appArmorProfile є обʼєктом AppArmorProfile, що складається з type та localhostProfile. Дійсні опції для type включають RuntimeDefault (стандартно), Unconfined і Localhost. localhostProfile слід встановлювати тільки якщо type є Localhost. Це вказує на назву попередньо налаштованого профілю на вузлі. Профіль повинен бути завантажений на всіх вузлах, які підходять для Podʼа, оскільки ви не знаєте, де буде розгорнуто Pod. Підходи до налаштування власних профілів обговорюються в Налаштування вузлів з профілями.

Примітка: Якщо containers[*].securityContext.appArmorProfile.type явно встановлено на RuntimeDefault, то Pod не буде допущено, якщо AppArmor не включено на вузлі. Однак, якщо containers[*].securityContext.appArmorProfile.type не зазначено, то стандартне значення (що також є RuntimeDefault) буде застосовано тільки якщо вузол має увімкнений AppArmor. Якщо вузол має вимкнений AppArmor, Pod буде допущено, але контейнер не буде обмежено профілем RuntimeDefault.

Ось приклад, який встановлює профіль AppArmor на стандартний профіль контейнерного середовища вузла:

...
containers:
- name: container-1
  securityContext:
    appArmorProfile:
      type: RuntimeDefault

Ось приклад, який встановлює профіль AppArmor на попередньо налаштований профіль з назвою k8s-apparmor-example-deny-write:

...
containers:
- name: container-1
  securityContext:
    appArmorProfile:
      type: Localhost
      localhostProfile: k8s-apparmor-example-deny-write

Для отримання додаткової інформації дивіться Обмеження доступу контейнера до ресурсів з AppArmor.

Призначення міток SELinux контейнеру

Щоб призначити мітки SELinux контейнеру, включіть поле seLinuxOptions в розділ securityContext вашого маніфесту Podʼа або контейнера. Поле seLinuxOptions є обʼєктом SELinuxOptions. Ось приклад, який застосовує рівень SELinux:

...
securityContext:
  seLinuxOptions:
    level: "s0:c123,c456"

Ефективне переозначення обʼєктів SELinux в томах

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.28 [beta]

Стандартно, контейнерне середовище рекурсивно призначає мітку SELinux для всіх файлів на всіх томах Pod. Щоб прискорити цей процес, Kubernetes може миттєво змінити мітку SELinux тому за допомогою параметра монтування -o context=<мітка>.

Щоб скористатися цим прискоренням, мають бути виконані всі ці умови:

  • Функціональні можливості ReadWriteOncePod та SELinuxMountReadWriteOncePod повинні бути увімкнені.
  • Pod повинен використовувати PersistentVolumeClaim з відповідними accessModes та функціональною можливстю:
    • Або том має accessModes: ["ReadWriteOncePod"], і властивість включення SELinuxMountReadWriteOncePod увімкнена.
    • Або том може використовувати будь-які інші режими доступу та обидва SELinuxMountReadWriteOncePod та SELinuxMount повинні бути увімкнені.
  • Pod (або всі його контейнери, які використовують PersistentVolumeClaim) повинні мати встановлені параметри seLinuxOptions.
  • Відповідний PersistentVolume повинен бути або:
    • Том, який використовує старі типи томів iscsi, rbd або fc.
    • Або том, який використовує драйвер CSI CSI. Драйвер CSI повинен оголосити, що він підтримує монтування з -o context, встановивши spec.seLinuxMount: true у його екземплярі CSIDriver.

Для будь-яких інших типів томів переозначення SELinux відбувається іншим шляхом: контейнерне середовище рекурсивно змінює мітку SELinux для всіх inodes (файлів і тек) у томі. Чим більше файлів і тек у томі, тим довше відбувається це переозначення.

Управління доступом до файлової системи /proc

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.12 [alpha]

Для середовищ виконання, які слідують специфікації виконання OCI, контейнери типово запускаються у режимі, де є кілька шляхів, які промасковані та доступні тільки для читання. Результатом цього є те, що в межах простору імен монтування контейнера присутні ці шляхи, і вони можуть працювати подібно до того, якби контейнер був ізольованим хостом, але процес контейнера не може записувати до них. Список промаскованих і доступних тільки для читання шляхів такий:

  • Промасковані шляхи:

    • /proc/asound
    • /proc/acpi
    • /proc/kcore
    • /proc/keys
    • /proc/latency_stats
    • /proc/timer_list
    • /proc/timer_stats
    • /proc/sched_debug
    • /proc/scsi
    • /sys/firmware
    • /sys/devices/virtual/powercap
  • Шляхи доступні тільки для читання:

    • /proc/bus
    • /proc/fs
    • /proc/irq
    • /proc/sys
    • /proc/sysrq-trigger

Для деяких Podʼів вам може знадобитися обійти стандартний шлях маскування. Найбільш поширений контекст, коли це потрібно, — це спроба запуску контейнерів у межах контейнера Kubernetes (у межах Podʼа).

Поле procMount в securityContext дозволяє користувачеві запитати, щоб /proc контейнера був Unmasked, або міг бути підмонтований для читання-запису контейнерним процесом. Це також стосується /sys/firmware, який не знаходиться в /proc.

...
securityContext:
  procMount: Unmasked

Обговорення

Контекст безпеки для Pod застосовується до Контейнерів Pod і також до Томів Pod при необхідності. Зокрема, fsGroup та seLinuxOptions застосовуються до Томів наступним чином:

  • fsGroup: Томи, які підтримують управління власністю, модифікуються так, щоб бути власністю та доступними для запису за GID, вказаним у fsGroup. Докладніше див. Документ із проєктування управління власністю томів.

  • seLinuxOptions: Томи, які підтримують мітку SELinux, переозначаються так, щоб бути доступними за міткою, вказаною у seLinuxOptions. Зазвичай вам потрібно лише встановити розділ level. Це встановлює мітку Multi-Category Security (MCS), яку отримують всі Контейнери у Pod, а також Томи.

Очищення

Видаліть Pod:

kubectl delete pod security-context-demo
kubectl delete pod security-context-demo-2
kubectl delete pod security-context-demo-3
kubectl delete pod security-context-demo-4

Що далі

4.3.13 - Налаштування службових облікових записів для Podʼів

Kubernetes пропонує два відмінні способи автентифікації для клієнтів, які працюють у межах вашого кластера або мають взаємозвʼязок з панеллю управління вашого кластера для автентифікації в API-сервері.

Службовий обліковий запис надає ідентичність процесам, які працюють у Podʼі, і відповідає обʼєкту ServiceAccount. Коли ви автентифікуєтеся в API-сервері, ви ідентифікуєте себе як певного користувача. Kubernetes визнає поняття користувача, але сам Kubernetes не має API User.

Це завдання стосується Службових облікових записів, які існують в API Kubernetes. Керівництво показує вам деякі способи налаштування Службових облікових записів для Podʼів.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Використання стандартного службового облікового запису для доступу до API-сервера

Коли Podʼи звертаються до API-сервера, вони автентифікуються як певний Службовий обліковий запис (наприклад, default). В кожному просторі імен завжди є принаймні один Службовий обліковий запис.

У кожному просторі імен Kubernetes завжди міститься принаймні один Службовий обліковий запис: стандартний службовий обліковий запис для цього простору імен, з назвою default. Якщо ви не вказуєте Службовий обліковий запис при створенні Podʼа, Kubernetes автоматично призначає Службовий обліковий запис з назвою default у цьому просторі імен.

Ви можете отримати деталі для Podʼа, який ви створили. Наприклад:

kubectl get pods/<імʼя_пода> -o yaml

У виводі ви побачите поле spec.serviceAccountName. Kubernetes автоматично встановлює це значення, якщо ви не вказали його при створенні Podʼа.

Застосунок, який працює усередині Podʼа, може отримати доступ до API Kubernetes, використовуючи автоматично змонтовані облікові дані службового облікового запису. Для отримання додаткової інформації див. доступ до кластера.

Коли Pod автентифікується як Службовий обліковий запис, його рівень доступу залежить від втулка авторизації та політики, які використовуються.

Облікові дані API автоматично відкликаються, коли Pod видаляється, навіть якщо є завершувачі. Зокрема, облікові дані API відкликаються через 60 секунд після встановленого на Pod значення .metadata.deletionTimestamp (час видалення зазвичай дорівнює часу, коли запит на видалення був прийнятий плюс період належного завершення роботи Pod).

Відмова від автоматичного монтування облікових даних API

Якщо ви не бажаєте, щоб kubelet автоматично монтував облікові дані API ServiceAccount, ви можете відмовитися від такої стандартної поведінки. Ви можете відмовитися від автоматичного монтування облікових даних API у /var/run/secrets/kubernetes.io/serviceaccount/token для службового облікового запису, встановивши значення automountServiceAccountToken: false у ServiceAccount:

Наприклад:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: build-robot
automountServiceAccountToken: false
...

Ви також можете відмовитися від автоматичного монтування облікових даних API для певного Podʼа:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  serviceAccountName: build-robot
  automountServiceAccountToken: false
  ...

Якщо як ServiceAccount, так і .spec Podʼа вказують значення для automountServiceAccountToken, специфікація Podʼа має перевагу.

Використання більше ніж одного ServiceAccount

У кожному просторі імен є принаймні один ServiceAccount: типовий ServiceAccount, який називається default. Ви можете переглянути всі ресурси ServiceAccount у вашому поточному просторі імен за допомогою:

kubectl get serviceaccounts

Вихідні дані схожі на наступні:

NAME      SECRETS    AGE
default   1          1d

Ви можете створити додаткові обʼєкти ServiceAccount таким чином:

kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
  name: build-robot
EOF

Імʼя обʼєкта ServiceAccount повинно бути дійсним DNS-піддоменним імʼям.

Якщо ви отримуєте повний дамп обʼєкта ServiceAccount, подібний до цього:

kubectl get serviceaccounts/build-robot -o yaml

Вихідні дані схожі на наступні:

apiVersion: v1
kind: ServiceAccount
metadata:
  creationTimestamp: 2019-06-16T00:12:34Z
  name: build-robot
  namespace: default
  resourceVersion: "272500"
  uid: 721ab723-13bc-11e5-aec2-42010af0021e

Ви можете використовувати розширення дозволів для встановлення дозволів на облікові записи служб.

Щоб використовувати не-стандартний обліковий запис, встановіть поле spec.serviceAccountName Podʼа на імʼя ServiceAccount, який ви хочете використовувати.

Ви можете встановити лише поле serviceAccountName при створенні Podʼа або в шаблоні для нового Podʼа. Ви не можете оновлювати поле .spec.serviceAccountName Podʼа, який вже існує.

Очищення

Якщо ви спробували створити ServiceAccount build-robot з прикладу вище, ви можете видалити його виконавши:

kubectl delete serviceaccount/build-robot

Вручну створіть API-токен для ServiceAccount

Припустимо, у вас вже є службовий обліковий запис з назвою "build-robot", як зазначено вище.

Ви можете отримати тимчасовий API-токен для цього ServiceAccount за допомогою kubectl:

kubectl create token build-robot

Вихідні дані з цієї команди — це токен, який ви можете використовувати для автентифікації цього ServiceAccount. Ви можете запросити певний час дії токена, використовуючи аргумент командного рядка --duration для kubectl create token (фактичний час дії виданого токену може бути коротшим або навіть довшим).

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.31 [beta]

Коли увімкнено функції ServiceAccountTokenNodeBinding і ServiceAccountTokenNodeBindingValidation, а також використовується kubectl версії 1.31 або пізнішої, можна створити токен службового облікового запису, який безпосередньо привʼязаний до Node.

kubectl create token build-robot --bound-object-kind Node --bound-object-name node-001 --bound-object-uid 123...456

Токен буде чинний до закінчення його терміну дії або до видалення відповідного вузла чи службового облікового запису.

Вручну створіть довговічний API-токен для ServiceAccount

Якщо ви бажаєте отримати API-токен для службового облікового запису, ви створюєте новий Secret з особливою анотацією kubernetes.io/service-account.name.

kubectl apply -f - <<EOF
apiVersion: v1
kind: Secret
metadata:
  name: build-robot-secret
  annotations:
    kubernetes.io/service-account.name: build-robot
type: kubernetes.io/service-account-token
EOF

Якщо ви переглянете Secret використовуючи:

kubectl get secret/build-robot-secret -o yaml

ви побачите, що тепер Secret містить API-токен для ServiceAccount "build-robot".

Через анотацію, яку ви встановили, панель управління автоматично генерує токен для цього службового облікового запису і зберігає їх у відповідному Secret. Крім того, панель управління також очищає токени для видалених облікових записів служб.

kubectl describe secrets/build-robot-secret

Вивід схожий на такий:

Name:           build-robot-secret
Namespace:      default
Labels:         <none>
Annotations:    kubernetes.io/service-account.name: build-robot
                kubernetes.io/service-account.uid: da68f9c6-9d26-11e7-b84e-002dc52800da

Type:   kubernetes.io/service-account-token

Data
====
ca.crt:         1338 байтів
namespace:      7 байтів
token:          ...

При видаленні ServiceAccount, який має відповідний Secret, панель управління Kubernetes автоматично очищає довговічний токен з цього Secret.

Додайте ImagePullSecrets до ServiceAccount

Спочатку створіть imagePullSecret. Потім перевірте, чи він був створений. Наприклад:

  • Створіть imagePullSecret, як описано в Вказування ImagePullSecrets в контейнері.

    kubectl create secret docker-registry myregistrykey --docker-server=<імʼя реєстру> \
            --docker-username=ІМ'Я_КОРИСТУВАЧА --docker-password=ПАРОЛЬ_ДЛЯ_DOCKER \
            --docker-email=ЕЛЕКТРОННА_ПОШТА_ДЛЯ_DOCKER
    
  • Перевірте, чи він був створений.

    kubectl get secrets myregistrykey
    

    Вивід схожий на такий:

    NAME             TYPE                              DATA    AGE
    myregistrykey    kubernetes.io/.dockerconfigjson   1       1д
    

Додайте imagePullSecret до ServiceAccount

Далі, змініть типовий обліковий запис служби для цього простору імен так, щоб він використовував цей Secret як imagePullSecret.

kubectl patch serviceaccount default -p '{"imagePullSecrets": [{"name": "myregistrykey"}]}'

Ви можете досягти того ж самого результату, відредагувавши обʼєкт вручну:

kubectl edit serviceaccount/default

Вивід файлу sa.yaml буде схожий на такий:

Вибраний вами текстовий редактор відкриється з конфігурацією, що схожа на цю:

apiVersion: v1
kind: ServiceAccount
metadata:
  creationTimestamp: 2021-07-07T22:02:39Z
  name: default
  namespace: default
  resourceVersion: "243024"
  uid: 052fb0f4-3d50-11e5-b066-42010af0d7b6

За допомогою вашого редактора видаліть рядок з ключем resourceVersion, додайте рядки для imagePullSecrets: та збережіть це. Залиште значення uid таким же, як ви його знайшли.

Після внесення змін, відредагований ServiceAccount виглядатиме схоже на це:

apiVersion: v1
kind: ServiceAccount
metadata:
  creationTimestamp: 2021-07-07T22:02:39Z
  name: default
  namespace: default
  uid: 052fb0f4-3d50-11e5-b066-42010af0d7b6
imagePullSecrets:
  - name: myregistrykey

Перевірте, що imagePullSecrets встановлені для нових Podʼів

Тепер, коли створюється новий Pod у поточному просторі імен і використовується типовий ServiceAccount, у новому Podʼі автоматично встановлюється поле spec.imagePullSecrets:

kubectl run nginx --image=<імʼя реєстру>/nginx --restart=Never
kubectl get pod nginx -o=jsonpath='{.spec.imagePullSecrets[0].name}{"\n"}'

Вивід:

myregistrykey

Проєцювання токенів ServiceAccount

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.20 [stable]

Kubelet також може проєцювати токен ServiceAccount в Pod. Ви можете вказати бажані властивості токена, такі як аудиторія та тривалість дії. Ці властивості не конфігуруються для типового токена ServiceAccount. Токен також стане недійсним щодо API, коли будь-який з Podʼів або ServiceAccount буде видалено.

Ви можете налаштувати цю поведінку для spec Podʼа за допомогою типу projected тому, що називається ServiceAccountToken.

Токен з цього projected тому — JSON Web Token (JWT). JSON-вміст цього токена слідує чітко визначеній схемі — приклад вмісту для токена, повʼязаного з Pod:

{
  "aud": [  # відповідає запитаним аудиторіям або стандартним аудиторіям API-сервера, якщо явно не запитано
    "https://kubernetes.default.svc"
  ],
  "exp": 1731613413,
  "iat": 1700077413,
  "iss": "https://kubernetes.default.svc",  # відповідає першому значенню, переданому прапорцю --service-account-issuer
  "jti": "ea28ed49-2e11-4280-9ec5-bc3d1d84661a",  # Функція ServiceAccountTokenJTI повинна бути активована для того, щоб вимагати присутності цього запиту
  "kubernetes.io": {
    "namespace": "kube-system",
    "node": {  # Функція ServiceAccountTokenPodNodeInfo повинна бути активована для того, щоб API-сервер додавав цей запит посилання на вузол
      "name": "127.0.0.1",
      "uid": "58456cb0-dd00-45ed-b797-5578fdceaced"
    },
    "pod": {
      "name": "coredns-69cbfb9798-jv9gn",
      "uid": "778a530c-b3f4-47c0-9cd5-ab018fb64f33"
    },
    "serviceaccount": {
      "name": "coredns",
      "uid": "a087d5a0-e1dd-43ec-93ac-f13d89cd13af"
    },
    "warnafter": 1700081020
  },
  "nbf": 1700077413,
  "sub": "system:serviceaccount:kube-system:coredns"
}

Запуск Podʼа з використанням проєцювання токену службового облікового запису

Щоб надати Podʼу токен з аудиторією vault та терміном дії дві години, ви можете визначити маніфест Podʼа, схожий на цей:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - image: nginx
    name: nginx
    volumeMounts:
    - mountPath: /var/run/secrets/tokens
      name: vault-token
  serviceAccountName: build-robot
  volumes:
  - name: vault-token
    projected:
      sources:
      - serviceAccountToken:
          path: vault-token
          expirationSeconds: 7200
          audience: vault

Створіть Pod:

kubectl create -f https://k8s.io/examples/pods/pod-projected-svc-token.yaml

Kubelet буде: запитувати та зберігати токен від імені Podʼа; робити токен доступним для Podʼа за налаштованим шляхом до файлу; і оновлювати токен поблизу його закінчення. Kubelet активно запитує ротацію для токена, якщо він старший, ніж 80% від загального часу життя (TTL), або якщо токен старший, ніж 24 години.

Застосунок відповідає за перезавантаження токена при його ротації. Зазвичай для застосунку достатньо завантажувати токен за розкладом (наприклад: один раз кожні 5 хвилин), без відстеження фактичного часу закінчення.

Виявлення емітента службового облікового запису

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.21 [stable]

Якщо ви увімкнули проєцювання токенів для ServiceAccounts у вашому кластері, то ви також можете скористатися функцією виявлення. Kubernetes надає спосіб клієнтам обʼєднуватись як постачальник ідентифікаційних даних, щоб одна або кілька зовнішніх систем могли діяти як сторона, що їм довіряє.

Якщо увімкнено, Kubernetes API-сервер публікує документ конфігурації постачальника OpenID через HTTP. Документ конфігурації публікується за адресою /.well-known/openid-configuration. Документ конфігурації OpenID постачальника іноді називається документом виявлення. Kubernetes API-сервер також публікує повʼязаний набір ключів JSON Web (JWKS), також через HTTP, за адресою /openid/v1/jwks.

Кластери, які використовують RBAC, включають типову роль кластера з назвою system:service-account-issuer-discovery. Типовий ClusterRoleBinding надає цю роль групі system:serviceaccounts, до якої неявно належать всі ServiceAccounts. Це дозволяє Podʼам, які працюють у кластері, отримувати доступ до документа виявлення службового облікового запису через їх змонтований токен службового облікового запису. Адміністратори також можуть вибрати привʼязку ролі до system:authenticated або system:unauthenticated залежно від їх вимог до безпеки та зовнішніх систем, з якими вони мають намір обʼєднуватись.

Відповідь JWKS містить публічні ключі, які може використовувати залежна сторона для перевірки токенів службових облікових записів Kubernetes. Залежні сторони спочатку запитують конфігурацію постачальника OpenID, а потім використовують поле jwks_uri у відповіді, щоб знайти JWKS.

У багатьох випадках API-сервери Kubernetes не доступні через глобальну мережу, але публічні точки доступу, які обслуговують кешовані відповіді від API-сервера, можуть бути доступні для користувачів або постачальників послуг. У таких випадках можливо перевизначити jwks_uri в конфігурації постачальника OpenID, щоб вона вказувала на глобальну точку доступу, а не на адресу API-сервера, передаючи прапорець --service-account-jwks-uri до API-сервера. Як і URL емітента, URI JWKS повинен використовувати схему https.

Що далі

Дивіться також:

4.3.14 - Отримання образів з приватного реєстру

Ця сторінка показує, як створити Pod, що використовує Secret для отримання образу з приватного реєстру або сховища контейнерних образів. Існує багато приватних реєстрів, які використовуються. У цьому завданні використовується Docker Hub як приклад реєстру.

Перш ніж ви розпочнете

  • Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

  • Для виконання цієї вправи вам потрібно мати інструмент командного рядка docker, а також ідентифікатор Docker, та пароль до якого ви знаєте.

  • Якщо ви використовуєте інший приватний контейнерний реєстр, вам потрібен інструмент командного рядка для цього реєстру та будь-яка інформація для входу в реєстр.

Увійдіть до Docker Hub

На вашому компʼютері вам необхідно автентифікуватися в реєстрі, щоб отримати приватний образ.

Використовуйте інструмент docker, щоб увійти до Docker Hub. Докладніше про це дивіться у розділі log in на сторінці Docker ID accounts.

docker login

Коли буде запитано, введіть свій ідентифікатор Docker, а потім обрані вами облікові дані (токен доступу чи пароль до вашого Docker ID).

Процес входу створює або оновлює файл config.json, який містить токен авторизації. Ознайомтеся з тим, як Kubernetes інтерпретує цей файл.

Перегляньте файл config.json:

cat ~/.docker/config.json

Вивід містить секцію, подібну до цієї:

{
    "auths": {
        "https://index.docker.io/v1/": {
            "auth": "c3R...zE2"
        }
    }
}

Створення Secret на основі наявних облікових даних

Кластер Kubernetes використовує Secret типу kubernetes.io/dockerconfigjson для автентифікації в контейнерному реєстрі для отримання приватного образу.

Якщо ви вже виконали команду docker login, ви можете скопіювати ці облікові дані в Kubernetes:

kubectl create secret generic regcred \
    --from-file=.dockerconfigjson=<шлях/до/.docker/config.json> \
    --type=kubernetes.io/dockerconfigjson

Якщо вам потрібно більше контролю (наприклад, встановити простір імен чи мітку для нового Secret), то ви можете налаштувати Secret перед збереженням його. Переконайтеся, що:

  • встановлено назву елемента даних як .dockerconfigjson
  • файл конфігурації Docker закодовано у base64, а потім вставлено цей рядок без розривів як значення для поля data[".dockerconfigjson"]
  • встановлено type як kubernetes.io/dockerconfigjson

Приклад:

apiVersion: v1
kind: Secret
metadata:
  name: myregistrykey
  namespace: awesomeapps
data:
  .dockerconfigjson: UmVhbGx5IHJlYWxseSByZWVlZWVlZWVlZWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGx5eXl5eXl5eXl5eXl5eXl5eXl5eSBsbGxsbGxsbGxsbGxsbG9vb29vb29vb29vb29vb29vb29vb29vb29vb25ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubmdnZ2dnZ2dnZ2dnZ2dnZ2dnZ2cgYXV0aCBrZXlzCg==
type: kubernetes.io/dockerconfigjson

Якщо ви отримали повідомлення про помилку error: no objects passed to create, це може означати, що закодований у base64 рядок є недійсним. Якщо ви отримали повідомлення про помилку, подібне до Secret "myregistrykey" is invalid: data[.dockerconfigjson]: invalid value ..., це означає, що закодований у base64 рядок у даних успішно декодувався, але не може бути розпізнаний як файл .docker/config.json.

Створення Secret, за допомогою вводу облікових даних в командному рядку

Створіть цей Secret, назвавши його regcred:

kubectl create secret docker-registry regcred \
    --docker-server=<your-registry-server> \
    --docker-username=<your-name> \
    --docker-password=<your-pword> \
    --docker-email=<your-email>

де:

  • <your-registry-server> — це повна доменна назва вашого приватного реєстру Docker. Використовуйте https://index.docker.io/v1/ для DockerHub.
  • <your-name> — це ваше імʼя користувача Docker.
  • <your-pword> — це ваш пароль Docker.
  • <your-email> — це ваша електронна адреса Docker.

Ви успішно встановили ваші облікові дані Docker у кластері як Secret під назвою regcred.

Перегляд Secret regcred

Щоб зрозуміти вміст Secret regcred, який ви створили, спочатку перегляньте Secret у форматі YAML:

kubectl get secret regcred --output=yaml

Вивід подібний до такого:

apiVersion: v1
kind: Secret
metadata:
  ...
  name: regcred
  ...
data:
  .dockerconfigjson: eyJodHRwczovL2luZGV4L ... J0QUl6RTIifX0=
type: kubernetes.io/dockerconfigjson

Значення поля .dockerconfigjson — це представлення в base64 ваших облікових даних Docker.

Щоб зрозуміти, що знаходиться у полі .dockerconfigjson, конвертуйте дані Secret в читабельний формат:

kubectl get secret regcred --output="jsonpath={.data.\.dockerconfigjson}" | base64 --decode

Вивід подібний до такого:

{"auths":{"your.private.registry.example.com":{"username":"janedoe","password":"xxxxxxxxxxx","email":"jdoe@example.com","auth":"c3R...zE2"}}}

Щоб зрозуміти, що знаходиться у полі auth, конвертуйте дані, закодовані в base64, у читабельний формат:

echo "c3R...zE2" | base64 --decode

Вивід, імʼя користувача та пароль, зʼєднані через :, подібний до такого:

janedoe:xxxxxxxxxxx

Зверніть увагу, що дані Secret містять токен авторизації, аналогічний вашому локальному файлу ~/.docker/config.json.

Ви успішно встановили ваші облікові дані Docker як Secret з назвою regcred у кластері.

Створення Pod, який використовує ваш Secret

Нижче подано опис для прикладу Pod, який потребує доступу до ваших облікових даних Docker у regcred:

apiVersion: v1
kind: Pod
metadata:
  name: private-reg
spec:
  containers:
  - name: private-reg-container
    image: <your-private-image>
  imagePullSecrets:
  - name: regcred

Завантажте вищезазначений файл на свій компʼютер:

curl -L -o my-private-reg-pod.yaml https://k8s.io/examples/pods/private-reg-pod.yaml

У файлі my-private-reg-pod.yaml замініть <your-private-image> на шлях до образу у приватному реєстрі, наприклад:

your.private.registry.example.com/janedoe/jdoe-private:v1

Для отримання образу з приватного реєстру Kubernetes потрібні облікові дані. Поле imagePullSecrets у файлі конфігурації вказує, що Kubernetes повинен отримати облікові дані з Secret з назвою regcred.

Створіть Pod, який використовує ваш Secret, і перевірте, що Pod працює:

kubectl apply -f my-private-reg-pod.yaml
kubectl get pod private-reg

Також, якщо запуск Podʼа не вдається і ви отримуєте статус ImagePullBackOff, перегляньте події Pod:

kubectl describe pod private-reg

Якщо ви побачите подію з причиною, встановленою на FailedToRetrieveImagePullSecret, Kubernetes не може знайти Secret із назвою (regcred, у цьому прикладі). Якщо ви вказали, що Pod потребує облікових даних для отримання образів, kubelet перевіряє, чи може він отримати доступ до цього Secret, перед тим як спробувати отримати образ.

Переконайтеся, що вказаний вами Secret існує і що його назва вірно вказана.

Events:
  ...  Reason                           ...  Message
       ------                                -------
  ...  FailedToRetrieveImagePullSecret  ...  Unable to retrieve some image pull secrets (<regcred>); attempting to pull the image may not succeed.

Що далі

4.3.15 - Налаштування проб життєздатності, готовності та запуску

Ця сторінка показує, як налаштувати проби життєздатності, готовності та запуску для контейнерів.

Для отримання додаткової інформації про проби див. Проби життєздатності, готовності та запуску

Kubelet використовує проби життєздатності для визначення моменту перезапуску контейнера. Наприклад, проби життєздатності можуть виявити проблеми, коли застосунок працює, але не може досягти результату. Перезапуск контейнера в такому стані може допомогти зробити застосунок більш доступним, попри помилки.

Загальний шаблон для проб життєздатності — використовувати той самий недорогу HTTP-точку доступу, що й для проб готовності, але з більшим значенням failureThreshold. Це гарантує, що Pod може спостерігатись як не готовий впродовж певного часу перед тим, як примусово завершити його роботу.

Kubelet використовує проби готовності для визначення моменту, коли контейнер готовий приймати трафік. Pod вважається готовим, коли всі його контейнери готові. Одним з використань цього сигналу є контроль за тим, які Podʼи використовуються як бекенди для Service. Коли Pod не готовий, його видаляють з балансувальників навантаження Serviceʼів.

Kubelet використовує проби запуску для визначення моменту запуску застосунку контейнера. Якщо така проба налаштована, проби життєздатності та готовності не починають працювати, поки вона не успішна, щоб переконатися, що ці проби не перешкоджають запуску застосунку. Це може бути використано для впровадження перевірки життєздатності для повільних контейнерів, що дозволяє уникати їхнього вимкнення kubelet перед тим, як вони будуть готові до роботи.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Визначте команду життєздатності

Багато застосунки, що працюють протягом тривалого часу, зрештою переходять у непрацездатний стан і не можуть відновитися, крім як знову бути перезапущеними. Kubernetes надає проби життєздатності для виявлення та виправлення таких ситуацій.

У цьому завданні ви створите Pod, який запускає контейнер на основі образу registry.k8s.io/busybox. Ось файл конфігурації для Podʼа:

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-exec
spec:
  containers:
  - name: liveness
    image: registry.k8s.io/busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -f /tmp/healthy; sleep 600
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5
      periodSeconds: 5

У файлі конфігурації можна побачити, що у Podʼа є один Container. Поле periodSeconds вказує, що kubelet повинен виконувати пробу життєздатності кожні 5 секунд. Поле initialDelaySeconds повідомляє kubelet, що він повинен зачекати 5 секунд перед виконанням першої проби. Для виконання проби kubelet виконує команду cat /tmp/healthy у цільовому контейнері. Якщо команда успішно виконується, вона повертає 0, і kubelet вважає контейнер живим і справним. Якщо команда повертає ненульове значення, kubelet примусово зупиняє контейнер і перезапускає його.

Під час запуску контейнера виконується ця команда:

/bin/sh -c "touch /tmp/healthy; sleep 30; rm -f /tmp/healthy; sleep 600"

Протягом перших 30 секунд життя контейнера існує файл /tmp/healthy. Таким чином, протягом перших 30 секунд команда cat /tmp/healthy повертає код успіху. Після 30 секунд cat /tmp/healthy повертає код невдачі.

Створіть Pod:

kubectl apply -f https://k8s.io/examples/pods/probe/exec-liveness.yaml

Протягом 30 секунд перегляньте події Podʼа:

kubectl describe pod liveness-exec

Виведений текст показує, що жодна проба життєздатності ще не зазнав невдачі:

Type    Reason     Age   From               Message
----    ------     ----  ----               -------
Normal  Scheduled  11s   default-scheduler  Successfully assigned default/liveness-exec to node01
Normal  Pulling    9s    kubelet, node01    Pulling image "registry.k8s.io/busybox"
Normal  Pulled     7s    kubelet, node01    Successfully pulled image "registry.k8s.io/busybox"
Normal  Created    7s    kubelet, node01    Created container liveness
Normal  Started    7s    kubelet, node01    Started container liveness

Після 35 секунд знову перегляньте події Podʼа:

kubectl describe pod liveness-exec

У нижній частині виводу є повідомлення про те, що проби життєздатності зазнали невдачі, і непрацездатні контейнери були примусово зупинені та перезапущені.

Type     Reason     Age                From               Message
----     ------     ----               ----               -------
Normal   Scheduled  57s                default-scheduler  Successfully assigned default/liveness-exec to node01
Normal   Pulling    55s                kubelet, node01    Pulling image "registry.k8s.io/busybox"
Normal   Pulled     53s                kubelet, node01    Successfully pulled image "registry.k8s.io/busybox"
Normal   Created    53s                kubelet, node01    Created container liveness
Normal   Started    53s                kubelet, node01    Started container liveness
Warning  Unhealthy  10s (x3 over 20s)  kubelet, node01    Liveness probe failed: cat: can't open '/tmp/healthy': No such file or directory
Normal   Killing    10s                kubelet, node01    Container liveness failed liveness probe, will be restarted

Почекайте ще 30 секунд та перевірте, що контейнер був перезапущений:

kubectl get pod liveness-exec

Виведений текст показує, що RESTARTS було збільшено. Зауважте, що лічильник RESTARTS збільшується, як тільки непрацездатний контейнер знову переходить у стан виконання:

NAME            READY     STATUS    RESTARTS   AGE
liveness-exec   1/1       Running   1          1m

Визначення HTTP-запиту життєздатності

Ще один вид проб життєздатності використовує HTTP GET-запит. Ось файл конфігурації для Podʼа, який запускає контейнер на основі образу registry.k8s.io/e2e-test-images/agnhost.

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-http
spec:
  containers:
  - name: liveness
    image: registry.k8s.io/e2e-test-images/agnhost:2.40
    args:
    - liveness
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
        httpHeaders:
        - name: Custom-Header
          value: Awesome
      initialDelaySeconds: 3
      periodSeconds: 3

У файлі конфігурації можна побачити, що у Podʼа є один контейнер. Поле periodSeconds вказує, що kubelet повинен виконувати пробу життєздатності кожні 3 секунди. Поле initialDelaySeconds повідомляє kubelet, що він повинен зачекати 3 секунди перед виконанням першої проби. Для виконання проби kubelet надсилає HTTP GET-запит на сервер, який працює в контейнері та слухає порт 8080. Якщо обробник для шляху /healthz сервера повертає код успіху, kubelet вважає контейнер живим і справним. Якщо обробник повертає код невдачі, ubelet примусово зупиняє контейнер і перезапускає його.

Будь-який код, більший або рівний 200 і менший за 400, вказує на успіх. Будь-який інший код вказує на невдачу.

Ви можете переглянути вихідний код сервера в server.go.

Протягом перших 10 секунд, коли контейнер живий, обробник /healthz повертає статус 200. Після цього обробник повертає статус 500.

http.HandleFunc("/healthz", func(w http.ResponseWriter, r *http.Request) {
    duration := time.Now().Sub(started)
    if duration.Seconds() > 10 {
        w.WriteHeader(500)
        w.Write([]byte(fmt.Sprintf("error: %v", duration.Seconds())))
    } else {
        w.WriteHeader(200)
        w.Write([]byte("ok"))
    }
})

Kubelet починає виконувати перевірку стану справності через 3 секунди після запуску контейнера. Таким чином, перші кілька перевірок стану справності будуть успішними. Але після 10 секунд перевірки стану справності будуть невдалими, і kubelet зупинить та перезапустить контейнер.

Щоб спробувати перевірку стану справності через HTTP, створіть Pod:

kubectl apply -f https://k8s.io/examples/pods/probe/http-liveness.yaml

Через 10 секунд перегляньте події Podʼа, щоб перевірити, що проби життєздатності зазнали невдачі, і контейнер був перезапущений:

kubectl describe pod liveness-http

У випусках після v1.13 налаштування локального HTTP-проксі не впливають на пробу життєздатності через HTTP.

Визначення проби життєздатності через TCP-сокет

Третій тип проби життєздатності використовує TCP сокет. З цією конфігурацією kubelet спробує відкрити зʼєднання з вашим контейнером на вказаному порту. Якщо він може встановити зʼєднання, контейнер вважається справним, якщо ні — це вважається невдачею.

apiVersion: v1
kind: Pod
metadata:
  name: goproxy
  labels:
    app: goproxy
spec:
  containers:
  - name: goproxy
    image: registry.k8s.io/goproxy:0.1
    ports:
    - containerPort: 8080
    readinessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 15
      periodSeconds: 10
    livenessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 15
      periodSeconds: 10

Як можна побачити, конфігурація для перевірки TCP досить схожа на перевірку через HTTP. У цьому прикладі використовуються як проби готовності, так і життєздатності. Kubelet надішле першу пробу життєздатності через 15 секунд після запуску контейнера. Ця проба спробує підʼєднатися до контейнера goproxy на порту 8080. Якщо проба на життєздатність не спрацює, контейнер буде перезапущено. Kubelet продовжить виконувати цю перевірку кожні 10 секунд.

Крім проби життєздатності, ця конфігурація включає пробу готовності. Kubelet запустить першу пробу готовності через 15 секунд після запуску контейнера. Аналогічно проби життєздатності, це спроба підʼєднатися до контейнера goproxy на порту 8080. Якщо проба пройде успішно, Pod буде позначений як готовий і отримає трафік від сервісів. Якщо перевірка готовності не вдасться, то Pod буде позначений як не готовий і не отримає трафік від жодного з сервісів.

Щоб спробувати перевірку життєздатності через TCP, створіть Pod:

kubectl apply -f https://k8s.io/examples/pods/probe/tcp-liveness-readiness.yaml

Через 15 секунд перегляньте події Podʼа, щоб перевірити, що проби життєздатності:

kubectl describe pod goproxy

Визначення проби життєздатності через gRPC

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.27 [stable]

Якщо ваш застосунок реалізує Протокол gRPC перевірки стану справності, цей приклад показує, як налаштувати Kubernetes для його використання для перевірок життєздатності застосунку. Так само ви можете налаштувати проби готовності та запуску.

Ось приклад маніфесту:

apiVersion: v1
kind: Pod
metadata:
  name: etcd-with-grpc
spec:
  containers:
  - name: etcd
    image: registry.k8s.io/etcd:3.5.1-0
    command: [ "/usr/local/bin/etcd", "--data-dir",  "/var/lib/etcd", "--listen-client-urls", "http://0.0.0.0:2379", "--advertise-client-urls", "http://127.0.0.1:2379", "--log-level", "debug"]
    ports:
    - containerPort: 2379
    livenessProbe:
      grpc:
        port: 2379
      initialDelaySeconds: 10

Для використання проби gRPC має бути налаштований port. Якщо ви хочете розрізняти проби різних типів та проби для різних функцій, ви можете використовувати поле service. Ви можете встановити service у значення liveness та вказати вашій точці доступу gRPC перевірки стану справності відповідати на цей запит інакше, ніж коли ви встановлюєте service у значення readiness. Це дозволяє використовувати ту саму точку доступу для різних видів перевірки стану справності контейнера замість прослуховування двох різних портів. Якщо ви хочете вказати свою власну назву сервісу та також вказати тип проби, Kubernetes рекомендує використовувати імʼя, яке складається з цих двох частин. Наприклад: myservice-liveness (використовуючи - як роздільник).

Проблеми конфігурації (наприклад: неправильний порт чи Service, нереалізований протокол перевірки стану справності) вважаються невдачею проби, подібно до проб через HTTP та TCP.

Щоб спробувати перевірку життєздатності через gRPC, створіть Pod за допомогою наступної команди. У наведеному нижче прикладі, Pod etcd налаштований для використання проби життєздатності через gRPC.

kubectl apply -f https://k8s.io/examples/pods/probe/grpc-liveness.yaml

Через 15 секунд перегляньте події Podʼа, щоб перевірити, що перевірка життєздатності не зазнала невдачі:

kubectl describe pod etcd-with-grpc

При використанні проби через gRPC, є кілька технічних деталей, на які варто звернути увагу:

  • Проби запускаються для IP-адреси Podʼа або його імені хосту. Обовʼязково налаштуйте вашу кінецеву точку gRPC для прослуховування IP-адреси Podʼа.
  • Проби не підтримують жодних параметрів автентифікації (наприклад, -tls).
  • Немає кодів помилок для вбудованих проб. Усі помилки вважаються невдачами проби.
  • Якщо ExecProbeTimeout feature gate встановлено у false, grpc-health-probe не дотримується налаштування timeoutSeconds (яке стандартно становить 1 с), тоді як вбудована проба зазнає невдачі через тайм-аут.

Використання іменованого порту

Ви можете використовувати іменований port для проб HTTP та TCP. Проби gRPC не підтримують іменовані порти.

Наприклад:

ports:
- name: liveness-port
  containerPort: 8080

livenessProbe:
  httpGet:
    path: /healthz
    port: liveness-port

Захист контейнерів, що повільно запускаються за допомогою проб запуску

Іноді вам доводиться мати справу з застосунками, які вимагають додаткового часу запуску при їх першій ініціалізації. У таких випадках може бути складно налаштувати параметри проби життєздатності без компромісів щодо швидкої відповіді на затримки, які мотивували використання такої проби. Рішення полягає в тому, щоб налаштувати пробу запуску з тою самою командою, перевіркою через HTTP або TCP, з failureThreshold * periodSeconds, достатньо довгим, щоб покрити найгірший випадок щодо часу запуску.

Отже, попередній приклад стане:

ports:
- name: liveness-port
  containerPort: 8080

livenessProbe:
  httpGet:
    path: /healthz
    port: liveness-port
  failureThreshold: 1
  periodSeconds: 10

startupProbe:
  httpGet:
    path: /healthz
    port: liveness-port
  failureThreshold: 30
  periodSeconds: 10

Завдяки пробі запуску застосунок матиме максимум 5 хвилин (30 * 10 = 300 с), щоб завершити свій запуск. Як тільки проба запуску вдалася один раз, проба життєздатності бере роль на себе, щоб забезпечити швидку відповідь на затримки роботи контейнера. Якщо проба запуску ніколи не вдається, контейнер буде зупинений після 300 с і підпадатиме під restartPolicy Podʼа.

Визначення проб готовності

Іноді застосунки тимчасово не можуть обслуговувати трафік. Наприклад, застосунок може потребувати завантаження великих даних або конфігураційних файлів під час запуску, або залежати від зовнішніх служб після запуску. У таких випадках ви не хочете примусово припиняти роботу застосунку, але ви також не хочете надсилати йому запити. Kubernetes надає проби готовності для виявлення та помʼякшення таких ситуацій. Pod з контейнерами, які повідомляють, що вони не готові, не отримують трафіку через Service Kubernetes.

Проби готовності налаштовуються аналогічно пробам життєздатності. Єдина відмінність полягає в тому, що ви використовуєте поле readinessProbe замість поля livenessProbe.

readinessProbe:
  exec:
    command:
    - cat
    - /tmp/healthy
  initialDelaySeconds: 5
  periodSeconds: 5

Конфігурація для проб готовності через HTTP та TCP також залишається ідентичною конфігурації пробам життєздатності.

Проби готовності та життєздатності можуть використовуватися паралельно для того самого контейнера. Використання обох може забезпечити, що трафік не досягне контейнера, який не готовий до нього, та що контейнери будуть перезапускатися у разі виникнення несправностей.

Налаштування проб

Проби мають кілька полів, які можна використовувати для більш точного керування поведінкою перевірок запуску, життєздатності та готовності:

  • initialDelaySeconds: Кількість секунд після запуску контейнера, перед тим як будуть запущені перевірки запуску, життєздатності або готовності. Якщо визначено пробу запуску, проби життєздатності та готовності не починаються, поки проба запуску не вдалася. Якщо значення periodSeconds більше, ніж initialDelaySeconds, то значення initialDelaySeconds буде проігнороване. Стандартно — 0 секунд. Мінімальне значення — 0.
  • periodSeconds: Як часто (у секундах) виконувати пробу. Стандартно — 10 секунд. Мінімальне значення — 1. Поки контейнер не має статусу Ready, ReadinessProbe може бути виконаний у час, відмінний від налаштованого інтервалу periodSeconds. Це робиться для того, щоб пришвидшити готовність Podʼа.
  • timeoutSeconds: Кількість секунд, після яких проба завершиться по тайм-ауту. Стандартно — 1 секунда. Мінімальне значення — 1.
  • successThreshold: Мінімальна послідовна кількість успіхів для того, щоб проба вважалася успішною після невдачі. Стандартно — 1. Має бути 1 для проб життєздатності та запуску. Мінімальне значення — 1.
  • failureThreshold: Після того, як проба не вдається failureThreshold разів поспіль, Kubernetes вважає, що загальна перевірка невдала: контейнер не готовий/справний. У випадку проби запуску або життєздатності, якщо принаймні failureThreshold проб зазнали невдачі, Kubernetes розглядає контейнер як несправний та виконує перезапуск для цього конкретного контейнера. Kubelet дотримується налаштування terminationGracePeriodSeconds для цього контейнера. Для невдалих проб готовності kubelet продовжує запускати контейнер, який не пройшов перевірку, і також продовжує запускати додаткові проби; через те, що перевірка не пройшла, kubelet встановлює умову Ready для Podʼа у значення false.
  • terminationGracePeriodSeconds: налаштуйте період-допуск для kubelet, щоб чекати між тригером вимкнення невдалих контейнерів та примусовим зупиненням контейнера середовищем виконання. Стандартно — значення успадковується від рівня Podʼа для terminationGracePeriodSeconds (якщо не вказано, то 30 секунд), а мінімальне значення — 1. Див. terminationGracePeriodSeconds на рівні проби для більш детальної інформації.

HTTP проби

HTTP проби мають додаткові поля, які можна встановити в httpGet:

  • host: Імʼя хосту для підключення, стандартно — IP-адреса Podʼа. Ймовірно, ви захочете встановити "Host" в httpHeaders замість цього.
  • scheme: Схема для підключення до хосту (HTTP або HTTPS). Стандартно — "HTTP".
  • path: Шлях до доступу на HTTP сервері. Стандартно — "/".
  • httpHeaders: Власні заголовки, що встановлюються у запиті. HTTP дозволяє повторювані заголовки.
  • port: Імʼя або номер порту для доступу до контейнера. Номер повинен бути в діапазоні від 1 до 65535.

Для HTTP проби kubelet надсилає HTTP-запит на вказаний порт та шлях, щоб виконати перевірку. Kubelet надсилає пробу до IP-адреси Podʼа, якщо адреса не перевизначена необовʼязковим полем host у httpGet. Якщо поле scheme встановлено ​​на HTTPS, kubelet надсилає запит HTTPS, пропускаючи перевірку сертифіката. У більшості сценаріїв ви не хочете встановлювати поле host. Ось один сценарій, коли ви його встановлюєте. Припустимо, що контейнер слухає на 127.0.0.1, а поле hostNetwork Podʼа встановлене ​​на true. Тоді host у httpGet повинен бути встановлений ​​на 127.0.0.1. Якщо ваш Pod спирається на віртуальні хости, що, ймовірно, є більш поширеним випадком, ви не повинні використовувати host, але краще встановити заголовок Host в httpHeaders.

Для HTTP проби kubelet надсилає два заголовки запиту, крім обовʼязкового заголовка Host:

  • User-Agent: Стандартне значення — kube-probe/1.31, де 1.31 — версія kubelet.
  • Accept: Стандартне значення — */*.

Ви можете перевизначити стандартне значення цих двох заголовків, визначивши httpHeaders для проби. Наприклад:

livenessProbe:
  httpGet:
    httpHeaders:
      - name: Accept
        value: application/json

startupProbe:
  httpGet:
    httpHeaders:
      - name: User-Agent
        value: MyUserAgent

Ви також можете видалити ці два заголовки, визначивши їх з порожнім значенням.

livenessProbe:
  httpGet:
    httpHeaders:
      - name: Accept
        value: ""

startupProbe:
  httpGet:
    httpHeaders:
      - name: User-Agent
        value: ""

TCP проби

Для TCP-проби kubelet встановлює зʼєднання проби на вузлі, а не в Podʼі, що означає, що ви не можете використовувати імʼя сервісу в параметрі host, оскільки kubelet не може його розпізнати.

terminationGracePeriodSeconds на рівні проб

СТАН ФУНКЦІОНАЛУ: Kubernetes 1.25 [stable]

У версіях 1.25 і вище користувачі можуть вказувати terminationGracePeriodSeconds на рівні проби в рамках специфікації проби. Коли одночасно встановлені terminationGracePeriodSeconds на рівні Podʼа і на рівні проби, kubelet використовуватиме значення на рівні проби.

При встановленні terminationGracePeriodSeconds слід звернути увагу на наступне:

  • Kubelet завжди враховує поле terminationGracePeriodSeconds на рівні проби, якщо воно присутнє в Podʼі.

  • Якщо у вас є поточні Podʼи, де поле terminationGracePeriodSeconds встановлене і ви більше не бажаєте використовувати індивідуальні терміни відповідного завершення роботи для пробт, вам слід видалити ці Podʼи.

Наприклад:

spec:
  terminationGracePeriodSeconds: 3600  # на рівні Podʼа
  containers:
  - name: test
    image: ...

    ports:
    - name: liveness-port
      containerPort: 8080

    livenessProbe:
      httpGet:
        path: /healthz
        port: liveness-port
      failureThreshold: 1
      periodSeconds: 60
      # Перевизначити `terminationGracePeriodSeconds` на рівні Podʼа #
      terminationGracePeriodSeconds: 60

terminationGracePeriodSeconds на рівні проби не може бути встановлене для проб готовності. Воно буде відхилене API-сервером.

Що далі

Також ви можете прочитати API-посилання на:

4.3.16 - Призначення Podʼів на вузли

Ця сторінка показує, як призначити Pod Kubernetes на певний вузол в кластері Kubernetes.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Для перевірки версії введіть kubectl version.

Додайте мітку до вузла

  1. Виведіть список вузлів у вашому кластері разом з їхніми мітками:

    kubectl get nodes --show-labels
    

    Вивід буде схожий на такий:

    NAME      STATUS    ROLES    AGE     VERSION        LABELS
    worker0   Ready     <none>   1d      v1.13.0        ...,kubernetes.io/hostname=worker0
    worker1   Ready     <none>   1d      v1.13.0        ...,kubernetes.io/hostname=worker1
    worker2   Ready     <none>   1d      v1.13.0        ...,kubernetes.io/hostname=worker2
    
  2. Виберіть один з ваших вузлів і додайте до нього мітку:

    kubectl label nodes <your-node-name> disktype=ssd
    

    де <your-node-name> — це імʼя вашого обраного вузла.

  3. Перевірте, що ваш обраний вузол має мітку disktype=ssd:

    kubectl get nodes --show-labels
    

    Вивід буде схожий на такий:

    NAME      STATUS    ROLES    AGE     VERSION        LABELS
    worker0   Ready     <none>   1d      v1.13.0        ...,disktype=ssd,kubernetes.io/hostname=worker0
    worker1   Ready     <none>   1d      v1.13.0        ...,kubernetes.io/hostname=worker1
    worker2   Ready     <none>   1d      v1.13.0        ...,kubernetes.io/hostname=worker2
    

    У попередньому виводі можна побачити, що вузол worker0 має мітку disktype=ssd.

Створіть Pod, який буде призначений на ваш обраний вузол

Цей файл конфігурації Podʼа описує Pod, який має селектор вузла disktype: ssd. Це означає, що Pod буде призначений на вузол, який має мітку disktype=ssd.

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  nodeSelector:
    disktype: ssd
  1. Використайте файл конфігурації, щоб створити Pod, який буде призначений на ваш обраний вузол:

    kubectl apply -f https://k8s.io/examples/pods/pod-nginx.yaml
    
  2. Перевірте, що Pod працює на вашому обраному вузлі:

    kubectl get pods --output=wide
    

    Вивід буде схожий на такий:

    NAME     READY     STATUS    RESTARTS   AGE    IP           NODE
    nginx    1/1       Running   0          13s    10.200.0.4   worker0
    

Створіть Pod, який буде призначений на конкретний вузол

Ви також можете призначити Pod на один конкретний вузол, встановивши nodeName.

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  nodeName: foo-node # призначення Podʼу конкретному вузлу
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent

Використовуйте файл конфігурації, щоб створити Pod, який буде призначений тільки на foo-node.

Що далі

4.3.17 - Призначення Podʼів на вузли за допомогою спорідненості вузла

На цій сторінці показано, як призначити Pod Kubernetes на певний вузол за допомогою спорідненості вузла в кластері Kubernetes.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Версія вашого Kubernetes сервера має бути не старішою ніж v1.10. Для перевірки версії введіть kubectl version.

Додайте мітку до вузла

  1. Виведіть список вузлів у вашому кластері разом з їхніми мітками:

    kubectl get nodes --show-labels
    

    Вивід буде схожий на такий:

    NAME      STATUS    ROLES    AGE     VERSION        LABELS
    worker0   Ready     <none>   1d      v1.13.0        ...,kubernetes.io/hostname=worker0
    worker1   Ready     <none>   1d      v1.13.0        ...,kubernetes.io/hostname=worker1
    worker2   Ready     <none>   1d      v1.13.0        ...,kubernetes.io/hostname=worker2
    
  2. Виберіть один з ваших вузлів і додайте до нього мітку:

    kubectl label nodes <your-node-name> disktype=ssd
    

    де <your-node-name> — це імʼя вашого обраного вузла.

  3. Перевірте, що ваш обраний вузол має мітку disktype=ssd:

    kubectl get nodes --show-labels
    

    Вивід буде схожий на такий:

    NAME      STATUS    ROLES    AGE     VERSION        LABELS
    worker0   Ready     <none>   1d      v1.13.0        ...,disktype=ssd,kubernetes.io/hostname=worker0
    worker1   Ready     <none>   1d      v1.13.0        ...,kubernetes.io/hostname=worker1
    worker2   Ready     <none>   1d      v1.13.0        ...,kubernetes.io/hostname=worker2
    

    У попередньому виводі можна побачити, що вузол worker0 має мітку disktype=ssd.

Розмістіть Pod, використовуючи потрібну спорідненість вузла

Цей маніфест описує Pod, який має спорідненість вузла requiredDuringSchedulingIgnoredDuringExecution, disktype: ssd. Це означає, що Pod буде розміщений лише на вузлі, який має мітку disktype=ssd.

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: disktype
            operator: In
            values:
            - ssd            
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  1. Застосуйте маніфест, щоб створити Pod, який буде розміщений на вашому обраному вузлі:

    kubectl apply -f https://k8s.io/examples/pods/pod-nginx-required-affinity.yaml
    
  2. Перевірте, що Pod працює на вашому обраному вузлі:

    kubectl get pods --output=wide
    

    Вивід буде схожий на такий:

    NAME     READY     STATUS    RESTARTS   AGE    IP           NODE
    nginx    1/1       Running   0          13s    10.200.0.4   worker0
    

Розмістіть Pod, використовуючи бажану спорідненість вузла

Цей маніфест описує Pod, який має бажану спорідненість вузла preferredDuringSchedulingIgnoredDuringExecution, disktype: ssd. Це означає, що Pod надасть перевагу вузлу, який має мітку disktype=ssd.

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  affinity:
    nodeAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: disktype
            operator: In
            values:
            - ssd          
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  1. Застосуйте маніфест, щоб створити Pod, який буде розміщений на вашому обраному вузлі:

    kubectl apply -f https://k8s.io/examples/pods/pod-nginx-preferred-affinity.yaml
    
  2. Перевірте, що Pod працює на вашому обраному вузлі:

    kubectl get pods --output=wide
    

    Вивід буде схожий на такий:

    NAME     READY     STATUS    RESTARTS   AGE    IP           NODE
    nginx    1/1       Running   0          13s    10.200.0.4   worker0
    

Що далі

Дізнайтеся більше про Спорідненість вузла.

4.3.18 - Налаштування ініціалізації Podʼа

На цій сторінці показано, як використовувати Init Container для ініціалізації Podʼа перед запуском контейнера застосунку.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Для перевірки версії введіть kubectl version.

Створіть Pod, який має Init Container

У цьому завданні ви створите Pod, який має один контейнер застосунку та один Init Container. Контейнер ініціалізації виконується до завершення перед тим, як розпочне виконання контейнер застосунку.

Ось файл конфігурації для Podʼа:

apiVersion: v1
kind: Pod
metadata:
  name: init-demo
spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 80
    volumeMounts:
    - name: workdir
      mountPath: /usr/share/nginx/html
  # Цей контейр виконуєть під час ініціалізації podʼу
  initContainers:
  - name: install
    image: busybox:1.28
    command:
    - wget
    - "-O"
    - "/work-dir/index.html"
    - http://info.cern.ch
    volumeMounts:
    - name: workdir
      mountPath: "/work-dir"
  dnsPolicy: Default
  volumes:
  - name: workdir
    emptyDir: {}

У файлі конфігурації ви бачите, що в Podʼі є Том, який обидва контейнери (ініціалізації та застосунку) спільно використовують.

Контейнер ініціалізації монтує спільний Том у /work-dir, а контейнер застосунку монтує спільний Том у /usr/share/nginx/html. Контейнер ініціалізації виконує наступну команду, а потім завершується:

wget -O /work-dir/index.html http://info.cern.ch

Зверніть увагу, що контейнер ініціалізації записує файл index.html в кореневу теку сервера nginx.

Створіть Pod:

kubectl apply -f https://k8s.io/examples/pods/init-containers.yaml

Перевірте, що контейнер nginx працює:

kubectl get pod init-demo

Вивід показує, що контейнер nginx працює:

NAME        READY     STATUS    RESTARTS   AGE
init-demo   1/1       Running   0          1m

Отримайте доступ до оболонки в контейнері nginx, що працює в Podʼі init-demo:

kubectl exec -it init-demo -- /bin/bash

У своїй оболонці надішліть запит GET на сервер nginx:

root@nginx:~# apt-get update
root@nginx:~# apt-get install curl
root@nginx:~# curl localhost

Вивід показує, що nginx обслуговує вебсторінку, яку записав контейнер ініціалізації:

<html><head></head><body><header>
<title>http://info.cern.ch</title>
</header>

<h1>http://info.cern.ch - home of the first website</h1>
  ...
  <li><a href="http://info.cern.ch/hypertext/WWW/TheProject.html">Browse the first website</a></li>
  ...

Що далі

4.3.19 - Обробники подій життєвого циклу контейнера

Ця сторінка показує, як прикріплювати обробники до подій життєвого циклу контейнера. Kubernetes підтримує події postStart та preStop. Kubernetes надсилає подію postStart безпосередньо після того, як контейнер стартує, і він надсилає подію preStop безпосередньо перед завершенням роботи контейнера. Контейнер може вказати один обробник для кожної події.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Для перевірки версії введіть kubectl version.

Визначте обробники postStart та preStop

У цьому завдані ви створите Pod, який має один контейнер. У контейнері встановлені обробники для подій postStart та preStop.

Ось файл конфігурації для Podʼа:

apiVersion: v1
kind: Pod
metadata:
  name: lifecycle-demo
spec:
  containers:
  - name: lifecycle-demo-container
    image: nginx
    lifecycle:
      postStart:
        exec:
          command: ["/bin/sh", "-c", "echo Hello from the postStart handler > /usr/share/message"]
      preStop:
        exec:
          command: ["/bin/sh","-c","nginx -s quit; while killall -0 nginx; do sleep 1; done"]

У файлі конфігурації ви бачите, що команда postStart записує файл message в теку /usr/share контейнера. Команда preStop відповідним чином вимикає nginx. Це корисно, якщо контейнер перериває роботу через помилку.

Створіть Pod:

kubectl apply -f https://k8s.io/examples/pods/lifecycle-events.yaml

Перевірте, що контейнер у Podʼі працює:

kubectl get pod lifecycle-demo

Отримайте доступ до оболонки контейнера, який працює в Podʼі:

kubectl exec -it lifecycle-demo -- /bin/bash

У своїй оболонці перевірте, що обробник postStart створив файл message:

root@lifecycle-demo:/# cat /usr/share/message

Вивід показує текст, записаний обробником postStart:

Hello from the postStart handler

Обговорення

Kubernetes надсилає подію postStart безпосередньо після створення контейнера. Проте, немає гарантії, що обробник postStart буде викликаний перед тим, як буде викликано точку входу контейнера. Обробник postStart працює асинхронно відносно коду контейнера, але керування Kubernetes блокується до завершення обробника postStart. Статус контейнера не встановлюється як RUNNING до завершення обробника postStart.

Kubernetes надсилає подію preStop безпосередньо перед завершенням роботи контейнера. Керування Kubernetes контейнером блокується до завершення обробника preStop, якщо тайм-аут оновлення Podʼа не закінчився. Докладніше див. Життєвий цикл Podʼа.

Що далі

Довідка

4.3.20 - Налаштування Podʼів для використання ConfigMap

Велика кількість застосунків покладаються на налаштування, які використовуються під час їх ініціалізації та виконання. В більшості випадків ці налаштування можна визначити за допомогою конфігураційних параметрів. Kubernetes надає можливість додавати конфігураційні параметри до Podʼів за допомогою обʼєктів ConfigMap.

Концепція ConfigMap дозволяє виокремити конфігураційні параметри з образу контейнера, що робить застосунок більш переносним. Наприклад, ви можете завантажити та використовувати один й той самий образ контейнера для використання контейнера для потреб локальної розробки, тестування системи, або в операційному середовищі.

Ця сторінка надає ряд прикладів, які демонструють як створювати ConfigMap та налаштувати Podʼи для використання даних, що містяться в ConfigMap.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

У вас має бути встановлено wget. Якщо ви використовуєте інший інструмент, такий як curl, замініть команди wget на відповідні команди для вашого інструменту.

Створення ConfigMap

Ви можете скористатись або kubectl create configmap або генератором ConfigMap в kustomization.yaml для створення ConfigMap.

Створення ConfigMap за допомогою kubectl create configmap

Скористайтесь командою kubectl create configmap, щоб створити ConfigMap з тек, файлів, або літералів:

kubectl create configmap <map-name> <data-source>

де, <map-name> — це імʼя ConfigMap, а <data-source> — це тека, файл чи літерал з даними, які ви хочете включити в ConfigMap. Імʼя обʼєкта ConfigMap повинно бути вірним імʼям субдомену DNS.

Коли ви створюєте ConfigMap на основі файлу, ключ в <data-source> визначається імʼям файлу, а значення — вмістом файлу.

Ви можете використовувати kubectl describe або kubectl get для отримання інформації про ConfigMap.

Створення ConfigMap з тек

Ви можете використовувати kubectl create configmap, щоб створити ConfigMap з кількох файлів у тій самій теці. Коли ви створюєте ConfigMap на основі теки, kubectl ідентифікує файли, імʼя яких є допустимим ключем у теці, та пакує кожен з цих файлів у новий ConfigMap. Всі записи теки, окрім звичайних файлів, ігноруються (наприклад: підтеки, символьні посилання, пристрої, канали тощо).

Створіть локальну теку:

mkdir -p configure-pod-container/configmap/

Тепер завантажте приклад конфігурації та створіть ConfigMap:

# Завантажте файли у теку `configure-pod-container/configmap/`
wget https://kubernetes.io/examples/configmap/game.properties -O configure-pod-container/configmap/game.properties
wget https://kubernetes.io/examples/configmap/ui.properties -O configure-pod-container/configmap/ui.properties

# Створіть ConfigMap
kubectl create configmap game-config --from-file=configure-pod-container/configmap/

Вказана вище команда упаковує кожен файл, у цьому випадку game.properties та ui.properties у теці configure-pod-container/configmap/ у ConfigMap game-config. Ви можете показати деталі ConfigMap за допомогою наступної команди:

kubectl describe configmaps game-config

Вивід буде приблизно таким:

Name:         game-config
Namespace:    default
Labels:       <none>
Annotations:  <none>

Data
====
game.properties:
----
enemies=aliens
lives=3
enemies.cheat=true
enemies.cheat.level=noGoodRotten
secret.code.passphrase=UUDDLRLRBABAS
secret.code.allowed=true
secret.code.lives=30
ui.properties:
----
color.good=purple
color.bad=yellow
allow.textmode=true
how.nice.to.look=fairlyNice

Файли game.properties та ui.properties у теці configure-pod-container/configmap/ представлені у секції data ConfigMap.

kubectl get configmaps game-config -o yaml

Вивід буде приблизно таким:

apiVersion: v1
kind: ConfigMap
metadata:
  creationTimestamp: 2022-02-18T18:52:05Z
  name: game-config
  namespace: default
  resourceVersion: "516"
  uid: b4952dc3-d670-11e5-8cd0-68f728db1985
data:
  game.properties: |
    enemies=aliens
    lives=3
    enemies.cheat=true
    enemies.cheat.level=noGoodRotten
    secret.code.passphrase=UUDDLRLRBABAS
    secret.code.allowed=true
    secret.code.lives=30    
  ui.properties: |
    color.good=purple
    color.bad=yellow
    allow.textmode=true
    how.nice.to.look=fairlyNice    

Створення ConfigMaps з файлів

Ви можете використовувати kubectl create configmap для створення ConfigMap з окремого файлу або з декількох файлів.

Наприклад,

kubectl create configmap game-config-2 --from-file=configure-pod-container/configmap/game.properties

створить наступний ConfigMap:

kubectl describe configmaps game-config-2

де вивід буде схожий на це:

Name:         game-config-2
Namespace:    default
Labels:       <none>
Annotations:  <none>

Data
====
game.properties:
----
enemies=aliens
lives=3
enemies.cheat=true
enemies.cheat.level=noGoodRotten
secret.code.passphrase=UUDDLRLRBABAS
secret.code.allowed=true
secret.code.lives=30

Ви можете вказати аргумент --from-file кілька разів, щоб створити ConfigMap із кількох джерел даних.

kubectl create configmap game-config-2 --from-file=configure-pod-container/configmap/game.properties --from-file=configure-pod-container/configmap/ui.properties

Можете переглянути деталі ConfigMap game-config-2 за допомогою наступної команди:

kubectl describe configmaps game-config-2

Вивід буде схожий на це:

Name:         game-config-2
Namespace:    default
Labels:       <none>
Annotations:  <none>

Data
====
game.properties:
----
enemies=aliens
lives=3
enemies.cheat=true
enemies.cheat.level=noGoodRotten
secret.code.passphrase=UUDDLRLRBABAS
secret.code.allowed=true
secret.code.lives=30
ui.properties:
----
color.good=purple
color.bad=yellow
allow.textmode=true
how.nice.to.look=fairlyNice

Використовуйте опцію --from-env-file для створення ConfigMap з env-файлу, наприклад:

# Env-файли містять список змінних оточення.
# На ці синтаксичні правила слід звертати увагу:
#   Кожен рядок у env-файлі повинен бути у форматі VAR=VAL.
#   Рядки, які починаються з # (тобто коментарі), ігноруються.
#   Порожні рядки ігноруються.
#   Особливого врахування лапок немає (тобто вони будуть частиною значення у ConfigMap).

# Завантажте приклад файлів у теку `configure-pod-container/configmap/`
wget https://kubernetes.io/examples/configmap/game-env-file.properties -O configure-pod-container/configmap/game-env-file.properties
wget https://kubernetes.io/examples/configmap/ui-env-file.properties -O configure-pod-container/configmap/ui-env-file.properties

# Env-файл `game-env-file.properties` виглядає так
cat configure-pod-container/configmap/game-env-file.properties
enemies=aliens
lives=3
allowed="true"

# Цей коментар та порожній рядок вище ігноруються
kubectl create configmap game-config-env-file \
       --from-env-file=configure-pod-container/configmap/game-env-file.properties

створить ConfigMap. Перегляньте ConfigMap:

kubectl get configmap game-config-env-file -o yaml

вивід буде схожий на:

apiVersion: v1
kind: ConfigMap
metadata:
  creationTimestamp: 2019-12-27T18:36:28Z
  name: game-config-env-file
  namespace: default
  resourceVersion: "809965"
  uid: d9d1ca5b-eb34-11e7-887b-42010a8002b8
data:
  allowed: '"true"'
  enemies: aliens
  lives: "3"

Починаючи з Kubernetes v1.23, kubectl підтримує аргумент --from-env-file, який може бути вказаний кілька разів для створення ConfigMap із кількох джерел даних.

kubectl create configmap config-multi-env-files \
        --from-env-file=configure-pod-container/configmap/game-env-file.properties \
        --from-env-file=configure-pod-container/configmap/ui-env-file.properties

створить наступний ConfigMap:

kubectl get configmap config-multi-env-files -o yaml

де вивід буде схожий на це:

apiVersion: v1
kind: ConfigMap
metadata:
  creationTimestamp: 2019-12-27T18:38:34Z
  name: config-multi-env-files
  namespace: default
  resourceVersion: "810136"
  uid: 252c4572-eb35-11e7-887b-42010a8002b8
data:
  allowed: '"true"'
  color: purple
  enemies: aliens
  how: fairlyNice
  lives: "3"
  textmode: "true"

Визначення ключа для створення ConfigMap з файлу

Ви можете визначити ключ, відмінний від імені файлу, який буде використаний у розділі data вашого ConfigMap під час використання аргументу --from-file:

kubectl create configmap game-config-3 --from-file=<my-key-name>=<path-to-file>

де <my-key-name> — це ключ, який ви хочете використовувати в ConfigMap, а <path-to-file> — це місцезнаходження файлу джерела даних, яке ключ має представляти.

Наприклад:

kubectl create configmap game-config-3 --from-file=game-special-key=configure-pod-container/configmap/game.properties

створить наступний ConfigMap:

kubectl get configmaps game-config-3 -o yaml

де вивід буде схожий на це:

apiVersion: v1
kind: ConfigMap
metadata:
  creationTimestamp: 2022-02-18T18:54:22Z
  name: game-config-3
  namespace: default
  resourceVersion: "530"
  uid: 05f8da22-d671-11e5-8cd0-68f728db1985
data:
  game-special-key: |
    enemies=aliens
    lives=3
    enemies.cheat=true
    enemies.cheat.level=noGoodRotten
    secret.code.passphrase=UUDDLRLRBABAS
    secret.code.allowed=true
    secret.code.lives=30    

Створення ConfigMaps з літеральних значень

Ви можете використовувати kubectl create configmap з аргументом --from-literal, щоб визначити літеральне значення з командного рядка:

kubectl create configmap special-config --from-literal=special.how=very --from-literal=special.type=charm

Ви можете передати декілька пар ключ-значення. Кожна пара, надана у командному рядку, представлена як окремий запис у розділі data ConfigMap.

kubectl get configmaps special-config -o yaml

Вивід буде схожий на це:

apiVersion: v1
kind: ConfigMap
metadata:
  creationTimestamp: 2022-02-18T19:14:38Z
  name: special-config
  namespace: default
  resourceVersion: "651"
  uid: dadce046-d673-11e5-8cd0-68f728db1985
data:
  special.how: very
  special.type: charm

Створення ConfigMap за допомогою генератора

Ви також можете створити ConfigMap за допомогою генераторів, а потім застосувати його для створення обʼєкта на API сервері кластера. Ви повинні вказати генератори у файлі kustomization.yaml в межах теки.

Генерація ConfigMaps з файлів

Наприклад, для створення ConfigMap з файлів configure-pod-container/configmap/game.properties:

# Створіть файл kustomization.yaml з ConfigMapGenerator
cat <<EOF >./kustomization.yaml
configMapGenerator:
- name: game-config-4
  options:
    labels:
      game-config: config-4
  files:
  - configure-pod-container/configmap/game.properties
EOF

Застосуйте теку kustomization для створення обʼєкта ConfigMap:

kubectl apply -k .
configmap/game-config-4-m9dm2f92bt created

Ви можете перевірити, що ConfigMap був створений так:

kubectl get configmap
NAME                       DATA   AGE
game-config-4-m9dm2f92bt   1      37s

а також:

kubectl describe configmaps game-config-4-m9dm2f92bt
Name:         game-config-4-m9dm2f92bt
Namespace:    default
Labels:       game-config=config-4
Annotations:  kubectl.kubernetes.io/last-applied-configuration:
                {"apiVersion":"v1","data":{"game.properties":"enemies=aliens\nlives=3\nenemies.cheat=true\nenemies.cheat.level=noGoodRotten\nsecret.code.p...

Data
====
game.properties:
----
enemies=aliens
lives=3
enemies.cheat=true
enemies.cheat.level=noGoodRotten
secret.code.passphrase=UUDDLRLRBABAS
secret.code.allowed=true
secret.code.lives=30
Events:  <none>

Зверніть увагу, що до згенерованої назви ConfigMap додано суфікс хешування вмісту. Це забезпечує генерацію нового ConfigMap кожного разу, коли вміст змінюється.

Визначення ключа для використання при генерації ConfigMap з файлу

Ви можете визначити ключ, відмінний від імені файлу, для використання у генераторі ConfigMap. Наприклад, для генерації ConfigMap з файлів configure-pod-container/configmap/game.properties з ключем game-special-key:

# Створіть файл kustomization.yaml з ConfigMapGenerator
cat <<EOF >./kustomization.yaml
configMapGenerator:
- name: game-config-5
  options:
    labels:
      game-config: config-5
  files:
  - game-special-key=configure-pod-container/configmap/game.properties
EOF

Застосуйте теки kustomization для створення обʼєкта ConfigMap.

kubectl apply -k .
configmap/game-config-5-m67dt67794 created

Генерація ConfigMap з літералів

У цьому прикладі показано, як створити ConfigMap з двох пар ключ/значення: special.type=charm та special.how=very, використовуючи Kustomize та kubectl. Для досягнення цього, ви можете вказати генератор ConfigMap. Створіть (або замініть) kustomization.yaml, щоб мати наступний вміст:

---
# Вміст kustomization.yaml для створення ConfigMap з літералів
configMapGenerator:
- name: special-config-2
  literals:
  - special.how=very
  - special.type=charm

Застосуйте теку kustomization для створення обʼєкта ConfigMap:

kubectl apply -k .
configmap/special-config-2-c92b5mmcf2 created

Проміжна очистка

Перед продовженням, очистіть деякі з ConfigMaps, які ви створили:

kubectl delete configmap special-config
kubectl delete configmap env-config
kubectl delete configmap -l 'game-config in (config-4,config-5)'

Тепер, коли ви вивчили, як визначати ConfigMaps, ви можете перейти до наступного розділу і дізнатися, як використовувати ці обʼєкти з Pod.


Визначення змінних середовища контейнера за допомогою даних з ConfigMap

Визначення змінної середовища контейнера за допомогою даних з одного ConfigMap

  1. Визначте змінну середовища як пару ключ-значення в ConfigMap:

    kubectl create configmap special-config --from-literal=special.how=very
    
  2. Присвойте значення special.how, визначене в ConfigMap, змінній середовища SPECIAL_LEVEL_KEY у специфікації Pod.

    apiVersion: v1
    kind: Pod
    metadata:
      name: dapi-test-pod
    spec:
      containers:
        - name: test-container
          image: registry.k8s.io/busybox
          command: [ "/bin/sh", "-c", "env" ]
          env:
            # Визначення змінної середовища
            - name: SPECIAL_LEVEL_KEY
              valueFrom:
                configMapKeyRef:
                  # ConfigMap, що містить значення, яке потрібно присвоїти SPECIAL_LEVEL_KEY
                  name: special-config
                  # Вказує ключ, повʼязаний зі значенням
                  key: special.how
      restartPolicy: Never
    

    Створіть Pod:

    kubectl create -f https://kubernetes.io/examples/pods/pod-single-configmap-env-variable.yaml
    

    Тепер вивід Podʼа містить змінну середовища SPECIAL_LEVEL_KEY=very.

Визначення змінних середовища контейнера з даних з кількох ConfigMaps

Так само як у попередньому прикладі, спочатку створіть ConfigMaps. Ось маніфест, який ви будете використовувати:

apiVersion: v1
kind: ConfigMap
metadata:
  name: special-config
  namespace: default
data:
  special.how: very
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: env-config
  namespace: default
data:
  log_level: INFO
  • Створіть ConfigMap:

    kubectl create -f https://kubernetes.io/examples/configmap/configmaps.yaml
    
  • Визначте змінні середовища у специфікації Pod.

    apiVersion: v1
    kind: Pod
    metadata:
      name: dapi-test-pod
    spec:
      containers:
        - name: test-container
          image: registry.k8s.io/busybox
          command: [ "/bin/sh", "-c", "env" ]
          env:
            - name: SPECIAL_LEVEL_KEY
              valueFrom:
                configMapKeyRef:
                  name: special-config
                  key: special.how
            - name: LOG_LEVEL
              valueFrom:
                configMapKeyRef:
                  name: env-config
                  key: log_level
      restartPolicy: Never
    

    Створіть Pod:

    kubectl create -f https://kubernetes.io/examples/pods/pod-multiple-configmap-env-variable.yaml
    

    Тепер виведення Pod містить змінні середовища SPECIAL_LEVEL_KEY=very та LOG_LEVEL=INFO.

    Як тільки ви готові перейти далі, видаліть цей Pod:

    kubectl delete pod dapi-test-pod --now
    

Налаштування всіх пар ключ-значення в ConfigMap як змінних середовища контейнера

  • Створіть ConfigMap, який містить кілька пар ключ-значення.

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: special-config
      namespace: default
    data:
      SPECIAL_LEVEL: very
      SPECIAL_TYPE: charm
    

    Створіть ConfigMap:

    kubectl create -f https://kubernetes.io/examples/configmap/configmap-multikeys.yaml
    
  • Використовуйте envFrom, щоб визначити всі дані ConfigMap як змінні середовища контейнера. Ключ з ConfigMap стає іменем змінної середовища в Pod.

    apiVersion: v1
    kind: Pod
    metadata:
      name: dapi-test-pod
    spec:
      containers:
        - name: test-container
          image: registry.k8s.io/busybox
          command: [ "/bin/sh", "-c", "env" ]
          envFrom:
          - configMapRef:
              name: special-config
      restartPolicy: Never
    

    Створіть Pod:

    kubectl create -f https://kubernetes.io/examples/pods/pod-configmap-envFrom.yaml
    

    Тепер виведення Pod містить змінні середовища SPECIAL_LEVEL=very та SPECIAL_TYPE=charm.

    Як тільки ви готові перейти далі, видаліть цей Pod:

    kubectl delete pod dapi-test-pod --now
    

Використання змінних середовища, визначених у ConfigMap, у командах Pod

Ви можете використовувати змінні середовища, визначені у ConfigMap, у розділі command та args контейнера за допомогою синтаксису підстановки Kubernetes $(VAR_NAME).

Наприклад, у наступному маніфесті Pod:

apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers:
    - name: test-container
      image: registry.k8s.io/busybox
      command: [ "/bin/echo", "$(SPECIAL_LEVEL_KEY) $(SPECIAL_TYPE_KEY)" ]
      env:
        - name: SPECIAL_LEVEL_KEY
          valueFrom:
            configMapKeyRef:
              name: special-config
              key: SPECIAL_LEVEL
        - name: SPECIAL_TYPE_KEY
          valueFrom:
            configMapKeyRef:
              name: special-config
              key: SPECIAL_TYPE
  restartPolicy: Never

Створіть цей Pod, запустивши:

kubectl create -f https://kubernetes.io/examples/pods/pod-configmap-env-var-valueFrom.yaml

Цей Pod видає наступний вивід від контейнера test-container:

kubectl logs dapi-test-pod
very charm

Як тільки ви готові перейти далі, видаліть цей Pod:

kubectl delete pod dapi-test-pod --now

Додавання даних ConfigMap до тому

Як пояснено у розділі Створення ConfigMap з файлів, коли ви створюєте ConfigMap, використовуючи --from-file, імʼя файлу стає ключем, збереженим у розділі data ConfigMap. Вміст файлу стає значенням ключа.

Приклади в цьому розділі відносяться до ConfigMap з іменем special-config:

apiVersion: v1
kind: ConfigMap
metadata:
  name: special-config
  namespace: default
data:
  SPECIAL_LEVEL: very
  SPECIAL_TYPE: charm

Створіть ConfigMap:

kubectl create -f https://kubernetes.io/examples/configmap/configmap-multikeys.yaml

Заповнення тому даними, збереженими в ConfigMap

Додайте імʼя ConfigMap у розділ volumes специфікації Pod. Це додасть дані ConfigMap до теки, вказаної як volumeMounts.mountPath (у цьому випадку, /etc/config). Розділ command перераховує файли теки з іменами, що відповідають ключам у ConfigMap.

apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers:
    - name: test-container
      image: registry.k8s.io/busybox
      command: [ "/bin/sh", "-c", "ls /etc/config/" ]
      volumeMounts:
      - name: config-volume
        mountPath: /etc/config
  volumes:
    - name: config-volume
      configMap:
        # Надає назву ConfigMap, що містить файли, які ви бажаєте
        # додати до контейнера
        name: special-config
  restartPolicy: Never

Створіть Pod:

kubectl create -f https://kubernetes.io/examples/pods/pod-configmap-volume.yaml

Коли Pod працює, команда ls /etc/config/ виводить наступне:

SPECIAL_LEVEL
SPECIAL_TYPE

Текстові дані показуються у вигляді файлів з використанням кодування символів UTF-8. Щоб використовувати інше кодування символів, скористайтеся binaryData (див. обʼєкт ConfigMap для докладніших відомостей).

Якщо ви готові перейти до наступного кроку, видаліть цей Pod:

kubectl delete pod dapi-test-pod --now

Додавання конфігурації ConfigMap до певного шляху у томі

Використовуйте поле path, щоб вказати бажаний шлях до файлів для конкретних елементів ConfigMap. У цьому випадку елемент SPECIAL_LEVEL буде змонтовано у томі config-volume за адресою /etc/config/keys.

apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers:
    - name: test-container
      image: registry.k8s.io/busybox
      command: [ "/bin/sh","-c","cat /etc/config/keys" ]
      volumeMounts:
      - name: config-volume
        mountPath: /etc/config
  volumes:
    - name: config-volume
      configMap:
        name: special-config
        items:
        - key: SPECIAL_LEVEL
          path: keys
  restartPolicy: Never

Створіть pod:

kubectl create -f https://kubernetes.io/examples/pods/pod-configmap-volume-specific-key.yaml

Коли pod запущено, команда cat /etc/config/keys видасть наведений нижче вивід:

very

Видаліть цей Pod:

kubectl delete pod dapi-test-pod --now

Спроєцюйте ключі на конкретні шляхи та встановлюйте права доступу до файлів

Ви можете спроєцювати ключі на конкретні шляхи. Зверніться до відповідного розділу в Посібнику Secret для ознайомлення з синтаксисом. Ви можете встановлювати права доступу POSIX для ключів. Зверніться до відповідного розділу в Посібнику Secret ознайомлення з синтаксисом.

Необовʼязкові посилання

Посилання на ConfigMap може бути позначене як необовʼязкове. Якщо ConfigMap не існує, змонтований том буде порожнім. Якщо ConfigMap існує, але посилання на ключ не існує, шлях буде відсутній під точкою монтування. Дивіться Опціональні ConfigMaps для отримання додаткових відомостей.

Змонтовані ConfigMap оновлюються автоматично

Коли змонтований ConfigMap оновлюється, спроєцьований вміст врешті-решт оновлюється також. Це стосується випадку, коли ConfigMap, на який посилатися необовʼязково, зʼявляється після того, як Pod вже почав працювати.

Kubelet перевіряє, чи змонтований ConfigMap є актуальним під час кожної періодичної синхронізації. Однак він використовує свій локальний кеш на основі TTL для отримання поточного значення ConfigMap. В результаті загальна затримка від моменту оновлення ConfigMap до моменту, коли нові ключі проєцюються у Pod може бути таким, як період синхронізації kubelet (стандартно — 1 хвилина) + TTL кешу ConfigMaps (стандартно — 1 хвилина) в kubelet. Ви можете викликати негайне оновлення, оновивши одну з анотацій Podʼа.

Розуміння ConfigMap та Podʼів

Ресурс ConfigMap API зберігає конфігураційні дані у вигляді пар ключ-значення. Дані можуть бути використані в Podʼах або надавати конфігураційні дані для системних компонентів, таких як контролери. ConfigMap схожий на Secret, але надає засоби для роботи з рядками, що не містять конфіденційної інформації. Користувачі та системні компоненти можуть зберігати конфігураційні дані в ConfigMap.

Поле data у ConfigMap містить дані конфігурації. Як показано у прикладі нижче, це може бути простим (наприклад, окремі властивості, визначені за допомогою --from-literal) або складним (наприклад, файли конфігурації або JSON-фрагменти, визначені за допомогою --from-file).

apiVersion: v1
kind: ConfigMap
metadata:
  creationTimestamp: 2016-02-18T19:14:38Z
  name: example-config
  namespace: default
data:
  # приклад простої властивості, визначеної за допомогою --from-literal
  example.property.1: hello
  example.property.2: world
  # приклад складної властивості, визначеної за допомогою --from-file
  example.property.file: |-
    property.1=value-1
    property.2=value-2
    property.3=value-3    

Коли kubectl створює ConfigMap з вхідних даних, які не є ASCII або UTF-8, цей інструмент поміщає їх у поле binaryData ConfigMap, а не в data. Як текстові, так і бінарні дані можуть бути поєднані в одному ConfigMap.

Якщо ви хочете переглянути ключі binaryData (і їх значення) в ConfigMap, ви можете виконати kubectl get configmap -o jsonpath='{.binaryData}' <імʼя>.

Podʼи можуть завантажувати дані з ConfigMap, що використовують як data, так і binaryData.

Опціональні ConfigMaps

Ви можете позначити посилання на ConfigMap як опціональне в специфікації Pod. Якщо ConfigMap не існує, конфігурація, для якої вона надає дані в Pod (наприклад: змінна середовища, змонтований том), буде пустою. Якщо ConfigMap існує, але посилання на ключ не існує, дані також будуть пустими.

Наприклад, наступна специфікація Pod позначає змінну середовища з ConfigMap як опціональну:

apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers:
    - name: test-container
      image: gcr.io/google_containers/busybox
      command: ["/bin/sh", "-c", "env"]
      env:
        - name: SPECIAL_LEVEL_KEY
          valueFrom:
            configMapKeyRef:
              name: a-config
              key: akey
              optional: true # позначає змінну як опціональну
  restartPolicy: Never

Якщо ви запустите цей Pod, і ConfigMap з імʼям a-config не існує, вивід буде пустим. Якщо ви запустите цей Pod, і ConfigMap з імʼям a-config існує, але в цьому ConfigMap немає ключа з імʼям akey, вивід також буде пустим. Якщо ж ви задасте значення для akey в ConfigMap a-config, цей Pod надрукує це значення і потім завершить роботу.

Ви також можете позначити томи та файли, надані ConfigMap, як опціональні. Kubernetes завжди створює шляхи для монтування томів, навіть якщо зазначений ConfigMap або ключ не існують. Наприклад, наступна специфікація Pod позначає том, який посилається на ConfigMap, як опціональний:

apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers:
    - name: test-container
      image: gcr.io/google_containers/busybox
      command: ["/bin/sh", "-c", "ls /etc/config"]
      volumeMounts:
      - name: config-volume
        mountPath: /etc/config
  volumes:
    - name: config-volume
      configMap:
        name: no-config
        optional: true # позначає ConfigMap як опціональний
  restartPolicy: Never

Обмеження

  • Ви повинні створити обʼєкт ConfigMap до того, як ви посилатиметесь на нього в специфікації Pod. Альтернативно, позначте посилання на ConfigMap як optional в специфікації Pod (див. Опціональні ConfigMaps). Якщо ви посилаєтесь на ConfigMap, який не існує, і ви не позначите посилання як optional, Podʼи не запуститься. Аналогічно, посилання на ключі, які не існують в ConfigMap, також перешкоджатимуть запуску Podʼа, якщо ви не позначите посилання на ключі як optional.

  • Якщо ви використовуєте envFrom для визначення змінних середовища з ConfigMaps, ключі, які вважаються недійсними, будуть пропущені. Podʼу буде дозволено запускатися, але недійсні імена будуть записані в лог подій (InvalidVariableNames). Повідомлення логу містить кожен пропущений ключ. Наприклад:

    kubectl get events
    

    Вивід буде схожий на цей:

    LASTSEEN FIRSTSEEN COUNT NAME          KIND  SUBOBJECT  TYPE      REASON                            SOURCE                MESSAGE
    0s       0s        1     dapi-test-pod Pod              Warning   InvalidEnvironmentVariableNames   {kubelet, 127.0.0.1}  Keys [1badkey, 2alsobad] from the EnvFrom configMap default/myconfig were skipped since they are considered invalid environment variable names.
    
  • ConfigMaps знаходяться в конкретному Namespace. Podʼи можуть посилатися лише на ConfigMaps, які знаходяться в тому ж контексті, що і сам Под.

  • Ви не можете використовувати ConfigMaps для статичних Podʼів, оскільки kubelet їх не підтримує.

Очищення

Вилучить ConfigMaps та Pod, які ви створили, використовуючи наступні команди:

kubectl delete configmaps/game-config configmaps/game-config-2 configmaps/game-config-3 \
               configmaps/game-config-env-file
kubectl delete pod dapi-test-pod --now

# Можливо, ви вже видалили наступний набір
kubectl delete configmaps/special-config configmaps/env-config
kubectl delete configmap -l 'game-config in (config-4,config-5)'

Якщо ви створили ntre configure-pod-container і вже не потребуєте її, вам слід також її видалити або перемістити в кошик або місце для видалених файлів.

Що далі

4.3.21 - Поділ простору імен процесів між контейнерами у Podʼі

На цій сторінці показано, як налаштувати поділ простору імен процесів для Podʼа. Коли поділ простору імен процесів увімкнено, процеси в контейнері стають видимими для всіх інших контейнерів у тому ж Podʼі.

Ви можете використовувати цю функцію для налаштування контейнерів, що взаємодіють один з одним, таких як контейнер sidecar обробника логу, або для дослідження образів контейнера, які не містять інструментів для налагодження, наприклад, оболонки.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Налаштування Podʼа

Поділ простору імен процесів увімкнено за допомогою поля shareProcessNamespace в розділі .spec Podʼа. Наприклад:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  shareProcessNamespace: true
  containers:
  - name: nginx
    image: nginx
  - name: shell
    image: busybox:1.28
    command: ["sleep", "3600"]
    securityContext:
      capabilities:
        add:
        - SYS_PTRACE
    stdin: true
    tty: true
  1. Створіть Pod nginx у вашому кластері:

    kubectl apply -f https://k8s.io/examples/pods/share-process-namespace.yaml
    
  2. Приєднайтеся до контейнера shell та запустіть команду ps:

    kubectl attach -it nginx -c shell
    

    Якщо ви не бачите символу командного рядка, спробуйте натиснути клавішу Enter. У оболонці контейнера:

    # виконайте це всередині контейнера "shell"
    ps ax
    

    Вивід схожий на такий:

    PID   USER     TIME  COMMAND
        1 root      0:00 /pause
        8 root      0:00 nginx: master process nginx -g daemon off;
       14 101       0:00 nginx: worker process
       15 root      0:00 sh
       21 root      0:00 ps ax
    

Ви можете відправляти сигнали процесам в інших контейнерах. Наприклад, відправте SIGHUP до nginx, щоб перезапустити робочий процес. Для цього потрібна можливість SYS_PTRACE.

# виконайте це всередині контейнера "shell"
kill -HUP 8   # змініть "8" на відповідний PID лідера процесу nginx, якщо потрібно
ps ax

Вивід схожий на такий:

PID   USER     TIME  COMMAND
    1 root      0:00 /pause
    8 root      0:00 nginx: master process nginx -g daemon off;
   15 root      0:00 sh
   22 101       0:00 nginx: worker process
   23 root      0:00 ps ax

Навіть можливо отримати доступ до файлової системи іншого контейнера, використовуючи посилання /proc/$pid/root.

# виконайте це всередині контейнера "shell"
# змініть "8" на PID процесу Nginx, якщо потрібно
head /proc/8/root/etc/nginx/nginx.conf

Вивід схожий на такий:

user  nginx;
worker_processes  1;

error_log  /var/log/nginx/error.log warn;
pid        /var/run/nginx.pid;


events {
    worker_connections  1024;

Розуміння поділу простору імен процесів

Podʼи ділять багато ресурсів, тому логічно, що вони також будуть ділитися простором імен процесів. Деякі контейнери можуть очікувати ізоляції від інших, тому важливо розуміти відмінності:

  1. Процес контейнера вже не має PID 1. Деякі контейнери відмовляються запускатися без PID 1 (наприклад, контейнери, що використовують systemd) або виконують команди типу kill -HUP 1 для відправлення сигналу процесу контейнера. У Podʼах зі спільним простором імен процесів kill -HUP 1 відправить сигнал пісочниці Podʼа (/pause у вищезазначеному прикладі).

  2. Процеси видимі іншим контейнерам у Podʼі. Це включає всю інформацію, доступну у /proc, таку як паролі, що були передані як аргументи або змінні середовища. Ці дані захищені лише звичайними правами Unix.

  3. Файлові системи контейнерів видимі іншим контейнерам у Podʼі через посилання /proc/$pid/root. Це полегшує налагодження, але також означає, що секрети файлової системи захищені лише правами файлової системи.

4.3.22 - Використання простору імен користувача з Podʼом

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.30 [beta]

Ця сторінка показує, як налаштувати простір імен користувача для Podʼів. Це дозволяє ізолювати користувача, що працює всередині контейнера, від того, який працює на хості.

Процес, що працює як root у контейнері, може працювати як інший (не root) користувач на хості; іншими словами, процес має повні привілеї для операцій всередині простору імен користувача, але не має привілеїв для операцій за межами простору імен.

Ви можете використовувати цю функцію, щоб зменшити шкоду, яку скомпрометований контейнер може завдати хосту або іншим Podʼам на тому ж вузлі. Є кілька уразливостей безпеки, оцінених як ВИСОКІ або КРИТИЧНІ, які не були використовні при активному використанні просторів імен користувача. Очікується, що простори імен користувача захистять від деяких майбутніх уразливостей також.

Без використання просторів імен користувача контейнер, що працює як root, у випадку втечі з контейнера має привілеї root на вузлі. І якщо деякі можливості були надані контейнеру, то ці можливості також дійсні на хості. Цього не відбувається, коли використовуються простори імен користувача.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Версія вашого Kubernetes сервера має бути не старішою ніж v1.25. Для перевірки версії введіть kubectl version.

  • ОС вузла повинна бути Linux
  • Ви повинні мати можливість виконувати команди на хості
  • Ви повинні мати можливість виконувати команди у Podʼах
  • Вам потрібно увімкнути функціональну можливість UserNamespacesSupport

Кластер, який ви використовуєте, обовʼязково повинен містити принаймні один вузол, який відповідає вимогам щодо використання просторів імен користувача з Podʼами.

Якщо у вас є суміш вузлів і лише деякі з них надають підтримку просторів імен користувача для Podʼів, вам також потрібно забезпечити те, що Podʼи з просторами імен користувача будуть заплановані на відповідні вузли.

Запуск Podʼа, що використовує простір імен користувача

Простір імен користувача для Podʼа вимкається, встановленням поля hostUsers в .spec на false. Наприклад:

apiVersion: v1
kind: Pod
metadata:
  name: userns
spec:
  hostUsers: false
  containers:
  - name: shell
    command: ["sleep", "infinity"]
    image: debian
  1. Створіть Pod у вашому кластері:

    kubectl apply -f https://k8s.io/examples/pods/user-namespaces-stateless.yaml
    
  2. Приєднайтеся до контейнера і виконайте readlink /proc/self/ns/user:

    kubectl attach -it userns bash
    

Виконайте цю команду:

read

link /proc/self/ns/user

Вивід схожий на:

user:[4026531837]

Також виконайте:

cat /proc/self/uid_map

Вивід схожий на:

0  833617920      65536

Потім відкрийте оболонку на хості та виконайте ті ж самі команди.

Команда readlink показує простір імен користувача, в якому працює процес. Він повинен бути різним, коли ви виконуєте його на хості і всередині контейнера.

Останнє число у файлі uid_map всередині контейнера повинно бути 65536, на хості це число повинно бути більшим.

Якщо ви запускаєте kubelet всередині простору імен користувача, вам потрібно порівняти вивід команди в Pod з виводом, отриманим на хості:

readlink /proc/$pid/ns/user

замінивши $pid на PID kubelet.

4.3.23 - Використання тому Image в Pod

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.31 [alpha]

Ця сторінка демонструє, як налаштувати Pod для використання томів image. Це дозволяє монтувати вміст з OCI реєстрів всередині контейнерів.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Версія вашого Kubernetes сервера має бути v1.31. Для перевірки версії введіть kubectl version.

  • Середовище виконання контейнерів має підтримувати функцію томів image.
  • Вам потрібно мати можливість виконувати команди на хості.
  • Вам потрібно мати можливість підключатися до pod.
  • Вам потрібно увімкнути функціональну можливість ImageVolume.

Запуск Podʼа, що використовує том image

Том image для Podʼа активується шляхом налаштування поля volumes.[*].image у .spec на дійсне посилання та використання його в volumeMounts контейнера. Наприклад:

apiVersion: v1
kind: Pod
metadata:
  name: image-volume
spec:
  containers:
  - name: shell
    command: ["sleep", "infinity"]
    image: debian
    volumeMounts:
    - name: volume
      mountPath: /volume
  volumes:
  - name: volume
    image:
      reference: quay.io/crio/artifact:v1
      pullPolicy: IfNotPresent
  1. Створіть Pod у вашому кластері:

    kubectl apply -f https://k8s.io/examples/pods/image-volumes.yaml
    
  2. Приєднайтесь до контейнера:

    kubectl attach -it image-volume bash
    
  3. Перевірте вміст файлу в томі:

    cat /volume/dir/file
    

    Вивід буде подібний до:

    1
    

    Ви також можете перевірити інший файл з іншим шляхом:

    cat /volume/file
    

    Вивід буде подібний до:

    2
    

Додатково

4.3.24 - Створення статичних Podʼів

Статичні Podʼи керуються безпосередньо демоном kubelet на конкретному вузлі, без спостереження за ними з боку API сервера. На відміну від Podʼів, які керуються панеллю управління (наприклад, Deployment}), kubelet спостерігає за кожним статичним Podʼом (і перезапускає його у разі невдачі).

Статичні Podʼи завжди привʼязані до одного Kubelet на конкретному вузлі.

Kubelet автоматично намагається створити дзеркальний Pod на сервері Kubernetes API для кожного статичного Podʼа. Це означає, що Podʼи, які запущені на вузлі, є видимими на сервері API, але не можуть бути керовані звідти. Назви Podʼів будуть мати суфікс з іменем хосту вузла відділеним дефісом.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Для перевірки версії введіть kubectl version.

На цій сторінці передбачається, що ви використовуєте CRI-O для запуску Podʼів, а також що ваші вузли працюють під управлінням операційної системи Fedora. Інструкції для інших дистрибутивів або встановлень Kubernetes можуть відрізнятися.

Створення статичного Podʼа

Ви можете налаштувати статичний Pod з використанням файлу конфігурації, що зберігається в файловій системі або файлу конфігурації, що зберігається на вебсервері.

Статичний Pod з файлової системи

Маніфести — це стандартні визначення Podʼів у форматі JSON або YAML в певній теці. Використовуйте поле staticPodPath: <тека> у конфігураційному файлі kubelet, який періодично сканує теку і створює/видаляє статичні Podʼи, коли у цій теці зʼявляються/зникають файли YAML/JSON. Зверніть увагу, що kubelet ігнорує файли, що починаються з крапки при скануванні вказаної теки.

Наприклад, так можна запустити простий вебсервер як статичний Pod:

  1. Виберіть вузол, на якому ви хочете запустити статичний Pod. У цьому прикладі це my-node1.

    ssh my-node1
    
  2. Виберіть теку, наприклад /etc/kubernetes/manifests, і помістіть туди визначення Podʼа вебсервера, наприклад, /etc/kubernetes/manifests/static-web.yaml:

    # Виконайте цю команду на вузлі, де працює kubelet
    mkdir -p /etc/kubernetes/manifests/
    cat <<EOF >/etc/kubernetes/manifests/static-web.yaml
    apiVersion: v1
    kind: Pod
    metadata:
      name: static-web
      labels:
        role: myrole
    spec:
      containers:
        - name: web
          image: nginx
          ports:
            - name: web
              containerPort: 80
              protocol: TCP
    EOF
    
  3. Налаштуйте kubelet на тому вузлі, щоб встановити значення staticPodPath в конфігураційному файлі kubelet. Див. Встановлення параметрів kubelet через конфігураційний файл для отримання додаткової інформації.

    Альтернативний і застарілий метод полягає в налаштуванні kubelet на тому вузлі, щоб він шукав маніфести статичного Podʼа локально, використовуючи аргумент командного рядка. Щоб використовувати застарілий підхід, запустіть kubelet з аргументом --pod-manifest-path=/etc/kubernetes/manifests/.

  4. Перезапустіть kubelet. У Fedora ви виконаєте:

    # Виконайте цю команду на вузлі, де працює kubelet
    systemctl restart kubelet
    

Маніфест Podʼа, розміщений на вебсервері

Kubelet періодично завантажує файл, вказаний аргументом --manifest-url=<URL>, і розглядає його як файл JSON/YAML, який містить визначення Podʼів. Подібно до того, як працюють маніфести, розміщені в файловій системі, kubelet перевіряє маніфест за розкладом. Якщо відбулися зміни в списку статичних Podʼів, kubelet застосовує їх.

Щоб скористатися цим підходом:

  1. Створіть YAML-файл і збережіть його на веб-сервері, щоб ви могли передати URL цього файлу kubelet.

    apiVersion: v1
    kind: Pod
    metadata:
      name: static-web
      labels:
        role: myrole
    spec:
      containers:
        - name: web
          image: nginx
          ports:
            - name: web
              containerPort: 80
              protocol: TCP
    
  2. Налаштуйте kubelet на обраному вузлі для використання цього веб-маніфесту, запустивши його з аргументом --manifest-url=<URL-маніфесту>. У Fedora відредагуйте /etc/kubernetes/kubelet, щоб додати цей рядок:

    KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --manifest-url=<URL-маніфесту>"
    
  3. Перезапустіть kubelet. У Fedora ви виконаєте:

    # Виконайте цю команду на вузлі, де працює kubelet
    systemctl restart kubelet
    

Спостереження за поведінкою статичного Podʼа

Після запуску kubelet автоматично запускає всі визначені статичні Podʼи. Оскільки ви визначили статичний Pod і перезапустили kubelet, новий статичний Pod вже має бути запущений.

Ви можете переглянути запущені контейнери (включно зі статичними Podʼами), виконавши (на вузлі):

# Виконайте цю команду на вузлі, де працює kubelet
crictl ps

Вивід може бути наступним:

CONTAINER       IMAGE                                 CREATED           STATE      NAME    ATTEMPT    POD ID
129fd7d382018   docker.io/library/nginx@sha256:...    11 minutes ago    Running    web     0          34533c6729106

Ви можете побачити дзеркальний Pod на сервері API:

kubectl get pods
NAME                  READY   STATUS    RESTARTS        AGE
static-web-my-node1   1/1     Running   0               2m

Мітки зі статичного Podʼа передаються в дзеркальний Pod. Ви можете використовувати ці мітки як зазвичай через селектори, і т.д.

Якщо ви спробуєте використовувати kubectl для видалення дзеркального Podʼа з сервера API, kubelet не видаляє статичний Pod:

kubectl delete pod static-web-my-node1
pod "static-web-my-node1" deleted

Ви побачите, що Pod все ще працює:

kubectl get pods
NAME                  READY   STATUS    RESTARTS   AGE
static-web-my-node1   1/1     Running   0          4s

Поверніться на вузол, де працює kubelet, і спробуйте вручну зупинити контейнер. Ви побачите, що після певного часу kubelet помітить це та автоматично перезапустить Pod:

# Виконайте ці команди на вузлі, де працює kubelet
crictl stop 129fd7d382018 # замініть на ID вашого контейнера
sleep 20
crictl ps
CONTAINER       IMAGE                                 CREATED           STATE      NAME    ATTEMPT    POD ID
89db4553e1eeb   docker.io/library/nginx@sha256:...    19 seconds ago    Running    web     1          34533c6729106

Після того як ви визначите потрібний контейнер, ви можете отримати журнал для цього контейнера за допомогою crictl:

# Виконайте ці команди на вузлі, де працює контейнер
crictl logs <container_id>
10.240.0.48 - - [16/Nov/2022:12:45:49 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.47.0" "-"
10.240.0.48 - - [16/Nov/2022:12:45:50 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.47.0" "-"
10.240.0.48 - - [16/Nove/2022:12:45:51 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.47.0" "-"

Щоб дізнатися більше про те, як налагоджувати за допомогою crictl, відвідайте Налагодження вузлів Kubernetes за допомогою crictl.

Динамічне додавання та видалення статичних Podʼів

Запущений kubelet періодично сканує налаштовану теку (/etc/kubernetes/manifests у нашому прикладі) на предмет змін та додає/видаляє Podʼи при появі/зникненні файлів в цій теці.

# Це передбачає, що ви використовуєте файлову конфігурацію статичних Podʼів
# Виконайте ці команди на вузлі, де працює контейнер
#
mv /etc/kubernetes/manifests/static-web.yaml /tmp
sleep 20
crictl ps
# Ви бачите, що ніякий контейнер nginx не працює
mv /tmp/static-web.yaml  /etc/kubernetes/manifests/
sleep 20
crictl ps
CONTAINER       IMAGE                                 CREATED           STATE      NAME    ATTEMPT    POD ID
f427638871c35   docker.io/library/nginx@sha256:...    19 seconds ago    Running    web     1          34533c6729106

Що далі

4.3.25 - Конвертація файлу Docker Compose в ресурси Kubernetes

Що таке Kompose? Це інструмент конвертації для всього, що стосується композиції (зокрема Docker Compose) в ресурси систем оркестрування (Kubernetes або OpenShift).

Додаткову інформацію можна знайти на вебсайті Kompose за адресою http://kompose.io.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Для перевірки версії введіть kubectl version.

Встановлення Kompose

Є кілька способів встановлення Kompose. Наш спосіб - завантаження бінарного файлу з останнього релізу GitHub.

Kompose випускається через GitHub кожні три тижні, ви можете переглянути всі поточні релізи на сторінці релізів GitHub.

# Linux
curl -L https://github.com/kubernetes/kompose/releases/download/v1.34.0/kompose-linux-amd64 -o kompose

# macOS
curl -L https://github.com/kubernetes/kompose/releases/download/v1.34.0/kompose-darwin-amd64 -o kompose

# Windows
curl -L https://github.com/kubernetes/kompose/releases/download/v1.34.0/kompose-windows-amd64.exe -o kompose.exe

chmod +x kompose
sudo mv ./kompose /usr/local/bin/kompose

Також ви можете завантажити архів.

Встановлення за допомогою go get витягує дані з гілки master з останніми змінами розробки.

go get -u github.com/kubernetes/kompose

Kompose є в репозиторії EPEL для CentOS. Якщо у вас ще немає встановленого та увімкненого репозиторію EPEL, ви можете зробити це, виконавши sudo yum install epel-release.

Якщо у вас увімкнений репозиторій EPEL у вашій системі, ви можете встановити Kompose як будь-який інший пакунок.

sudo yum -y install kompose

Kompose є в репозиторіях Fedora 24, 25 та 26. Ви можете встановити його, як і будь-який інший пакунок.

sudo dnf -y install kompose

У macOS ви можете встановити останній реліз за допомогою Homebrew:

brew install kompose

Використання Kompose

За кілька кроків ми переведемо вас з Docker Compose до Kubernetes. Вам потрібен лише наявний файл docker-compose.yml.

  1. Перейдіть до теки, що містить ваш файл docker-compose.yml. Якщо у вас його немає, ви можете випробувати використовуючи цей.

    
    services:
    
      redis-leader:
        container_name: redis-leader
        image: redis
        ports:
          - "6379"
    
      redis-replica:
        container_name: redis-replica
        image: redis
        ports:
          - "6379"
        command: redis-server --replicaof redis-leader 6379 --dir /tmp
    
      web:
        container_name: web
        image: quay.io/kompose/web
        ports:
          - "8080:8080"
        environment:
          - GET_HOSTS_FROM=dns
        labels:
          kompose.service.type: LoadBalancer
    
  2. Щоб конвертувати файл docker-compose.yml у файли, які можна використовувати з kubectl, запустіть kompose convert, а потім kubectl apply -f <output file>.

    kompose convert
    

    Вивід подібний до:

    INFO Kubernetes file "redis-leader-service.yaml" created
    INFO Kubernetes file "redis-replica-service.yaml" created
    INFO Kubernetes file "web-tcp-service.yaml" created
    INFO Kubernetes file "redis-leader-deployment.yaml" created
    INFO Kubernetes file "redis-replica-deployment.yaml" created
    INFO Kubernetes file "web-deployment.yaml" created
    
     kubectl apply -f web-tcp-service.yaml,redis-leader-service.yaml,redis-replica-service.yaml,web-deployment.yaml,redis-leader-deployment.yaml,redis-replica-deployment.yaml
    

    Вивід подібний до:

    deployment.apps/redis-leader created
    deployment.apps/redis-replica created
    deployment.apps/web created
    service/redis-leader created
    service/redis-replica created
    service/web-tcp created
    

    Ваші розгортання, що працюють в Kubernetes.

  3. Доступ до вашого застосунку.

    Якщо ви вже використовуєте minikube для вашого процесу розробки:

    minikube service web-tcp
    

    В іншому випадку, подивімось, яку IP використовує ваш Service!

    kubectl describe svc web-tcp
    
    Name:                     web-tcp
    Namespace:                default
    Labels:                   io.kompose.service=web-tcp
    Annotations:              kompose.cmd: kompose convert
                            kompose.service.type: LoadBalancer
                            kompose.version: 1.33.0 (3ce457399)
    Selector:                 io.kompose.service=web
    Type:                     LoadBalancer
    IP Family Policy:         SingleStack
    IP Families:              IPv4
    IP:                       10.102.30.3
    IPs:                      10.102.30.3
    Port:                     8080  8080/TCP
    TargetPort:               8080/TCP
    NodePort:                 8080  31624/TCP
    Endpoints:                10.244.0.5:8080
    Session Affinity:         None
    External Traffic Policy:  Cluster
    Events:                   <none>
    

    Якщо ви використовуєте хмарного постачальника, ваша IP буде вказана поруч з LoadBalancer Ingress.

    curl http://192.0.2.89
    
  4. Прибирання.

    Після завершення тестування розгортання прикладного застосунку просто запустіть наступну команду в вашій оболонці, щоб видалити використані ресурси.

    kubectl delete -f web-tcp-service.yaml,redis-leader-service.yaml,redis-replica-service.yaml,web-deployment.yaml,redis-leader-deployment.yaml,redis-replica-deployment.yaml
    

Посібник користувача

Kompose підтримує двох провайдерів: OpenShift і Kubernetes. Ви можете вибрати відповідного постачальника, використовуючи глобальну опцію --provider. Якщо постачальник не вказаний, буде встановлено Kubernetes.

kompose convert

Kompose підтримує конвертацію файлів Docker Compose версій V1, V2 і V3 в обʼєкти Kubernetes та OpenShift.

Приклад kompose convert для Kubernetes

kompose --file docker-voting.yml convert
WARN Unsupported key networks - ignoring
WARN Unsupported key build - ignoring
INFO Kubernetes file "worker-svc.yaml" created
INFO Kubernetes file "db-svc.yaml" created
INFO Kubernetes file "redis-svc.yaml" created
INFO Kubernetes file "result-svc.yaml" created
INFO Kubernetes file "vote-svc.yaml" created
INFO Kubernetes file "redis-deployment.yaml" created
INFO Kubernetes file "result-deployment.yaml" created
INFO Kubernetes file "vote-deployment.yaml" created
INFO Kubernetes file "worker-deployment.yaml" created
INFO Kubernetes file "db-deployment.yaml" created
ls
db-deployment.yaml  docker-compose.yml         docker-gitlab.yml  redis-deployment.yaml  result-deployment.yaml  vote-deployment.yaml  worker-deployment.yaml
db-svc.yaml         docker-voting.yml          redis-svc.yaml     result-svc.yaml        vote-svc.yaml           worker-svc.yaml

Ви також можете надати кілька файлів docker-compose одночасно:

kompose -f docker-compose.yml -f docker-guestbook.yml convert
INFO Kubernetes file "frontend-service.yaml" created         
INFO Kubernetes file "mlbparks-service.yaml" created         
INFO Kubernetes file "mongodb-service.yaml" created          
INFO Kubernetes file "redis-master-service.yaml" created     
INFO Kubernetes file "redis-slave-service.yaml" created      
INFO Kubernetes file "frontend-deployment.yaml" created      
INFO Kubernetes file "mlbparks-deployment.yaml" created      
INFO Kubernetes file "mongodb-deployment.yaml" created       
INFO Kubernetes file "mongodb-claim0-persistentvolumeclaim.yaml" created
INFO Kubernetes file "redis-master-deployment.yaml" created  
INFO Kubernetes file "redis-slave-deployment.yaml" created   
ls
mlbparks-deployment.yaml  mongodb-service.yaml                       redis-slave-service.jsonmlbparks-service.yaml  
frontend-deployment.yaml  mongodb-claim0-persistentvolumeclaim.yaml  redis-master-service.yaml
frontend-service.yaml     mongodb-deployment.yaml                    redis-slave-deployment.yaml
redis-master-deployment.yaml

Коли надається кілька файлів docker-compose, конфігурація обʼєднується. Будь-яка конфігурація, яка є спільною, буде перевизначена наступним файлом.

Приклад kompose convert для OpenShift

kompose --provider openshift --file docker-voting.yml convert
WARN [worker] Service cannot be created because of missing port.
INFO OpenShift file "vote-service.yaml" created             
INFO OpenShift file "db-service.yaml" created               
INFO OpenShift file "redis-service.yaml" created            
INFO OpenShift file "result-service.yaml" created           
INFO OpenShift file "vote-deploymentconfig.yaml" created    
INFO OpenShift file "vote-imagestream.yaml" created         
INFO OpenShift file "worker-deploymentconfig.yaml" created  
INFO OpenShift file "worker-imagestream.yaml" created       
INFO OpenShift file "db-deploymentconfig.yaml" created      
INFO OpenShift file "db-imagestream.yaml" created           
INFO OpenShift file "redis-deploymentconfig.yaml" created   
INFO OpenShift file "redis-imagestream.yaml" created        
INFO OpenShift file "result-deploymentconfig.yaml" created  
INFO OpenShift file "result-imagestream.yaml" created  

Також підтримує створення buildconfig для директиви build в сервісі. Стандартно використовується віддалений репозиторій для поточної гілки git як джерело репозиторію, та поточну гілку як гілку джерела для збірки. Ви можете вказати інше джерело репозиторію та гілку джерела, використовуючи опції --build-repo та --build-branch відповідно.

kompose --provider openshift --file buildconfig/docker-compose.yml convert
WARN [foo] Service cannot be created because of missing port.
INFO OpenShift Buildconfig using git@github.com:rtnpro/kompose.git::master as source.
INFO OpenShift file "foo-deploymentconfig.yaml" created     
INFO OpenShift file "foo-imagestream.yaml" created          
INFO OpenShift file "foo-buildconfig.yaml" created

Альтернативні конвертації

Типово kompose перетворює файли у форматі yaml на обʼєкти Kubernetes Deployments та Services. У вас є альтернативна опція для генерації json за допомогою -j. Також, ви можете альтернативно згенерувати обʼєкти Replication Controllers, Daemon Sets, або Helm чарти.

kompose convert -j
INFO Kubernetes file "redis-svc.json" created
INFO Kubernetes file "web-svc.json" created
INFO Kubernetes file "redis-deployment.json" created
INFO Kubernetes file "web-deployment.json" created

Файли *-deployment.json містять обʼєкти Deployment.

kompose convert --replication-controller
INFO Kubernetes file "redis-svc.yaml" created
INFO Kubernetes file "web-svc.yaml" created
INFO Kubernetes file "redis-replicationcontroller.yaml" created
INFO Kubernetes file "web-replicationcontroller.yaml" created

Файли *-replicationcontroller.yaml містять обʼєкти Replication Controller. Якщо ви хочете вказати кількість реплік (стандартно 1), використовуйте прапорець --replicas: kompose convert --replication-controller --replicas 3.

kompose convert --daemon-set
INFO Kubernetes file "redis-svc.yaml" created
INFO Kubernetes file "web-svc.yaml" created
INFO Kubernetes file "redis-daemonset.yaml" created
INFO Kubernetes file "web-daemonset.yaml" created

Файли *-daemonset.yaml містять обʼєкти DaemonSet.

Якщо ви хочете згенерувати чарт для використання з Helm, виконайте:

kompose convert -c
INFO Kubernetes file "web-svc.yaml" created
INFO Kubernetes file "redis-svc.yaml" created
INFO Kubernetes file "web-deployment.yaml" created
INFO Kubernetes file "redis-deployment.yaml" created
chart created in "./docker-compose/"
tree docker-compose/
docker-compose
├── Chart.yaml
├── README.md
└── templates
    ├── redis-deployment.yaml
    ├── redis-svc.yaml
    ├── web-deployment.yaml
    └── web-svc.yaml

Структура чарту спрямована на надання каркаса для створення ваших чартів Helm.

Мітки

kompose підтримує специфічні для Kompose мітки в файлі docker-compose.yml, щоб явно визначити поведінку сервісу при конвертації.

  • kompose.service.type визначає тип сервісу, який потрібно створити.

    Наприклад:

    version: "2"
    services:
      nginx:
        image: nginx
        dockerfile: foobar
        build: ./foobar
        cap_add:
          - ALL
        container_name: foobar
        labels:
          kompose.service.type: nodeport
    
  • kompose.service.expose визначає, чи потрібно сервісу бути доступним ззовні кластера чи ні. Якщо значення встановлено на "true", постачальник автоматично встановлює точку доступу, і для будь-якого іншого значення, значення встановлюється як імʼя хосту. Якщо в сервісі визначено кілька портів, вибирається перший.

    • Для постачальника Kubernetes створюється ресурс Ingress, припускається, що контролер Ingress вже налаштований.
    • Для постачальника OpenShift створюється маршрут.

    Наприклад:

    version: "2"
    services:
      web:
        image: tuna/docker-counter23
        ports:
        - "5000:5000"
        links:
        - redis
        labels:
          kompose.service.expose: "counter.example.com"
      redis:
        image: redis:3.0
        ports:
        - "6379"
    

Наразі підтримуються наступні варіанти:

КлючЗначення
kompose.service.typenodeport / clusterip / loadbalancer
kompose.service.exposetrue / hostname

Перезапуск

Якщо ви хочете створити звичайні Podʼи без контролерів, ви можете використовувати конструкцію restart у docker-compose, щоб визначити це. Дивіться таблицю нижче, щоб побачити, що відбувається при значенні restart.

docker-compose restartстворений обʼєктrestartPolicy Podʼа
""обʼєкт контролераAlways
alwaysобʼєкт контролераAlways
on-failureКапсулаOnFailure
noКапсулаNever

Наприклад, сервіс pival стане Podʼом нижче. Цей контейнер обчислює значення pi.

version: '2'

services:
  pival:
    image: perl
    command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
    restart: "on-failure"

Попередження про конфігурації Deployment

Якщо в Docker Compose файлі вказано том для сервісу, стратегія Deployment (Kubernetes) або DeploymentConfig (OpenShift) змінюється на "Recreate" замість "RollingUpdate" (типово). Це робиться для того, щоб уникнути одночасного доступу кількох екземплярів сервісу до тому.

Якщо в Docker Compose файлі імʼя сервісу містить _ (наприклад, web_service), то воно буде замінено на -, і імʼя сервісу буде перейменовано відповідно (наприклад, web-service). Kompose робить це, оскільки "Kubernetes" не дозволяє _ в імені обʼєкта.

Зверніть увагу, що зміна назви сервісу може зіпсувати деякі файли docker-compose.

Версії Docker Compose

Kompose підтримує версії Docker Compose: 1, 2 та 3. Ми маємо обмежену підтримку версій 2.1 та 3.2 через їх експериментальний характер.

Повний список сумісності між усіма трьома версіями перераховано у нашому документі з конвертації, включаючи список всіх несумісних ключів Docker Compose.

4.3.26 - Забезпечення стандартів безпеки Podʼів шляхом конфігурування вбудованого контролера допуску

Kubernetes надає вбудований контролер допуску, щоб забезпечити дотримання стандартів безпеки Podʼів. Ви можете налаштувати цей контролер допуску, щоб встановити глобальні стандартні значення та винятки.

Перш ніж ви розпочнете

Після альфа-релізу в Kubernetes v1.22, Pod Security Admission став стандартно доступним в Kubernetes v1.23, у вигляді бета. Починаючи з версії 1.25, Pod Security Admissio доступний загалом.

Для перевірки версії введіть kubectl version.

Якщо у вас не запущено Kubernetes 1.31, ви можете перемикнутися на перегляд цієї сторінки в документації для версії Kubernetes, яку ви використовуєте.

Налаштування контролера допуску

apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: PodSecurity
  configuration:
    apiVersion: pod-security.admission.config.k8s.io/v1 # див. примітку про сумісність
    kind: PodSecurityConfiguration
    # Стандартні значення, які застосовуються, коли мітка режиму не встановлена.
    #
    # Значення мітки рівня повинні бути одним з:
    # - "privileged" (станадртно)
    # - "baseline"
    # - "restricted"
    #
    # Значення мітки версії повинні бути одним з:
    # - "latest" (станадртно) 
    # - конкретна версія, наприклад "v1.31"
    defaults:
      enforce: "privileged"
      enforce-version: "latest"
      audit: "privileged"
      audit-version: "latest"
      warn: "privileged"
      warn-version: "latest"
    exemptions:
      # Масив імен користувачів для виключення.
      usernames: []
      # Масив імен класів виконання для виключення.
      runtimeClasses: []
      # Масив просторів імен для виключення.
      namespaces: []

4.3.27 - Забезпечення стандартів безпеки Podʼів за допомогою міток простору імен

Простори імен можуть бути позначені, щоб забезпечити стандарти безпеки Podʼів. Три політики privileged, baseline та restricted широко охоплюють спектр безпеки та реалізуються за допомогою контролера допуску безпеки Podʼа.

Перш ніж ви розпочнете

Pod Security Admission був доступний в Kubernetes v1.23, у вигляді бета. Починаючи з версії 1.25, Pod Security Admission доступний загалом.

Для перевірки версії введіть kubectl version.

Вимога стандарту безпеки Pod baseline за допомогою міток простору імен

Цей маніфест визначає Простір імен my-baseline-namespace, який:

  • Блокує будь-які Podʼи, які не відповідають вимогам політики baseline.
  • Генерує попередження для користувача та додає анотацію аудиту до будь-якого створеного Podʼа, який не відповідає вимогам політики restricted.
  • Фіксує версії політик baseline та restricted на v1.31.
apiVersion: v1
kind: Namespace
metadata:
  name: my-baseline-namespace
  labels:
    pod-security.kubernetes.io/enforce: baseline
    pod-security.kubernetes.io/enforce-version: v1.31

    # Ми встановлюємо ці рівні за нашим _бажаним_ `enforce` рівнем.
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/audit-version: v1.31
    pod-security.kubernetes.io/warn: restricted
    pod-security.kubernetes.io/warn-version: v1.31

Додавання міток до наявних просторів імен за допомогою kubectl label

Корисно застосувати прапорець --dry-run при початковому оцінюванні змін профілю безпеки для просторів імен. Перевірки стандарту безпеки Pod все ще будуть виконуватися в режимі dry run, що дозволяє отримати інформацію про те, як нова політика буде обробляти наявні Podʼи, без фактичного оновлення політики.

kubectl label --dry-run=server --overwrite ns --all \
    pod-security.kubernetes.io/enforce=baseline

Застосування до всіх просторів імен

Якщо ви тільки починаєте зі Pod Security Standards, відповідний перший крок — налаштувати всі простори імен з анотаціями аудиту для строгого рівня, такого як baseline:

kubectl label --overwrite ns --all \
  pod-security.kubernetes.io/audit=baseline \
  pod-security.kubernetes.io/warn=baseline

Зверніть увагу, що це не встановлює рівень примусового виконання, щоб можна було відрізняти простори імен, для яких не було явно встановлено рівень примусового виконання. Ви можете перелічити простори імен без явно встановленого рівня примусового виконання за допомогою цієї команди:

kubectl get namespaces --selector='!pod-security.kubernetes.io/enforce'

Застосування до конкретного простору імен

Ви також можете оновити конкретний простір імен. Ця команда додає політику enforce=restricted до простору імен my-existing-namespace, закріплюючи версію обмеженої політики на v1.31.

kubectl label --overwrite ns my-existing-namespace \
  pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/enforce-version=v1.31

4.3.28 - Міграція з PodSecurityPolicy до вбудованого контролера допуску PodSecurity

Ця сторінка описує процес міграції з PodSecurityPolicy до вбудованого контролера допуску PodSecurity. Це можна зробити ефективно за допомогою комбінації запуску dry-run та режимів audit та warn, хоча це стає складнішим, якщо використовуються мутуючі PSP.

Перш ніж ви розпочнете

Версія вашого Kubernetes сервера має бути не старішою ніж v1.22. Для перевірки версії введіть kubectl version.

Якщо ви використовуєте відмінну від 1.31 версію Kubernetes, вам можливо захочеться перейти до перегляду цієї сторінки у документації для версії Kubernetes, яку ви фактично використовуєте.

Ця сторінка передбачає, що ви вже знайомі з основними концепціями Pod Security Admission.

Загальний підхід

Існує кілька стратегій для міграції з PodSecurityPolicy до Pod Security Admission. Наведені нижче кроки — це один з можливих шляхів міграції, з метою мінімізації ризиків виробничої перерви та пробілів у безпеці.

  1. Вирішіть, чи Pod Security Admission відповідає вашому випадку використання.
  2. Перегляньте дозволи простору імен.
  3. Спростіть та стандартизуйте PodSecurityPolicies.
  4. Оновіть простори імен
    1. Визначте відповідний рівень безпеки Podʼа.
    2. Перевірте рівень безпеки Podʼів.
    3. Застосуйте рівень безпеки Podʼів.
    4. Оминіть PodSecurityPolicy.
  5. Перегляньте процеси створення просторів імен.
  6. Вимкніть PodSecurityPolicy.

0. Вирішіть, чи Pod Security Admission підходить для вас

Pod Security Admission був розроблений для задоволення найбільш поширених потреб у безпеці з коробки, а також для забезпечення стандартного набору рівнів безпеки у всіх кластерах. Однак він менш гнучкий, ніж PodSecurityPolicy. Зокрема, наступні функції підтримуються за допомогою PodSecurityPolicy, але не за допомогою Pod Security Admission:

  • Встановлення типових обмежень безпеки — Pod Security Admission є немутуючим контролером допуску, що означає, що він не буде змінювати Podʼи перед їх перевіркою. Якщо ви покладалися на цей аспект PodSecurityPolicy, вам доведеться або модифікувати ваші робочі навантаження, щоб вони відповідали обмеженням безпеки Podʼів, або використовувати Мутуючий вебхук допуску для внесення цих змін. Дивіться Спрощення та стандартизація PodSecurityPolicies нижче для детальнішої інформації.
  • Докладний контроль над визначенням політики — Pod Security Admission підтримує тільки 3 стандартні рівні. Якщо вам потрібно більше контролю над конкретними обмеженнями, вам доведеться використовувати Вебхук допуску з перевіркою для виконання цих політик.
  • Деталізація політики на рівні підпросторів імен — PodSecurityPolicy дозволяє вам призначати різні політики різним обліковим записам служб або користувачам, навіть в межах одного простору імен. Цей підхід має багато підводних каменів і не рекомендується, але якщо вам все одно потрібна ця функція, вам потрібно буде використовувати сторонній вебхук. Виняток становить випадок, коли вам потрібно повністю виключити певних користувачів або RuntimeClasses, у цьому випадку Pod Security Admission все ж надає деякі статичні конфігурації для виключень.

Навіть якщо Pod Security Admission не відповідає всім вашим потребам, він був розроблений для доповнення інших механізмів контролю політики, і може бути корисним допоміжним засобом, який працює нарівно з іншими вебхуками допуску.

1. Перегляньте дозволи простору імен

Pod Security Admission керується мітками в просторах імен. Це означає, що будь-хто, хто може оновлювати (або накладати патчі, або створювати) простір імен, також може змінювати рівень безпеки Podʼів для цього простору імен, що може бути використано для обходу більш обмеженої політики. Перш ніж продовжувати, переконайтеся, що ці дозволи на простір імен мають лише довірені, привілейовані користувачі. Не рекомендується надавати ці могутні дозволи користувачам, які не повинні мати підвищені привілеї, але якщо вам доведеться це зробити, вам потрібно буде використовувати вебхук допуску, щоб накласти додаткові обмеження на встановлення міток безпеки Podʼів на обʼєкти Namespace.

2. Спрощення та стандартизація PodSecurityPolicies

На цьому етапі зменште кількість мутуючих PodSecurityPolicies і видаліть параметри, що виходять за межі Pod Security Standards. Зміни, рекомендовані тут, слід внести в офлайн-копію оригіналу PodSecurityPolicy, який ви змінюєте. Клонована PSP повинна мати іншу назву, яка в алфавітному порядку стоїть перед оригінальною (наприклад, додайте 0 до її назви). Не створюйте нові політики в Kubernetes зараз — це буде розглянуто в розділі Впровадження оновлених політик нижче.

2.а. Видалення явно мутуючих полів

Якщо PodSecurityPolicy змінює Podʼи, то ви можете опинитись з Podʼами, які не відповідають вимогам рівня безпеки Podʼів, коли ви нарешті вимкнете PodSecurityPolicy. Щоб уникнути цього, вам слід усунути всі мутації PSP перед переходом. На жаль, PSP чітко не розділяє мутуючі та валідуючі поля, тому цей перехід не є простим.

Ви можете почати з видалення полів, які є явно мутуючими та не мають жодного впливу на політику валлідації. Ці поля (також перераховані в довіднику Перенесення PodSecurityPolicies у Pod Security Standards) включають:

  • .spec.defaultAllowPrivilegeEscalation
  • .spec.runtimeClass.defaultRuntimeClassName
  • .metadata.annotations['seccomp.security.alpha.kubernetes.io/defaultProfileName']
  • .metadata.annotations['apparmor.security.beta.kubernetes.io/defaultProfileName']
  • .spec.defaultAddCapabilities — хоча це технічно мутуюче і валідуюче поле, його слід обʼєднати з .spec.allowedCapabilities, яке виконує ту саму валідацію без мутації.

2.б. Вилучення параметрів, що не підпадають під Pod Security Standards

Існують кілька полів в PodSecurityPolicy, які не входять до складу Pod Security Standards. Якщо вам потрібно забезпечити ці опції, вам доведеться доповнити Pod Security Admission за допомогою вебхуків допуску, що не входить в рамки цього посібника.

Спочатку ви можете видалити явно валідуючі поля, які не охоплюються Pod Security Standards. Ці поля (також перераховані в довіднику Перенесення PodSecurityPolicies у Pod Security Standards з поміткою "no opinion") включають:

  • .spec.allowedHostPaths
  • .spec.allowedFlexVolumes
  • .spec.allowedCSIDrivers
  • .spec.forbiddenSysctls
  • .spec.runtimeClass

Ви також можете видалити наступні поля, які стосуються управління групами POSIX / UNIX.

  • .spec.runAsGroup
  • .spec.supplementalGroups
  • .spec.fsGroup

Залишені мутуючі поля потрібні для належної підтримки Pod Security Standards і будуть оброблені в окремому порядку:

  • .spec.requiredDropCapabilities — Потрібно видалити ALL щоб зробити профіль Restricted.
  • .spec.seLinux — (Тільки мутуюче з правилом MustRunAs) потрібно для забезпечення вимог SELinux для профілів Baseline & Restricted.
  • .spec.runAsUser — (Не мутує з правилом RunAsAny) потрібно для забезпечення RunAsNonRoot для профілю Restricted.
  • .spec.allowPrivilegeEscalation — (Тільки мутується, якщо встановлено false) потрібно для профілю Restricted.

2.в. Впровадження оновлених PSP

Далі ви можете впровадити оновлені політики у ваш кластер. Вам слід діяти обережно, оскільки видалення мутуючих опцій може призвести до того, що робочі навантаження пропустять необхідну конфігурацію.

Для кожної оновленої PodSecurityPolicy:

  1. Визначте, які Podʼи працюють під оригінальною PSP. Це можна зробити за допомогою анотації kubernetes.io/psp. Наприклад, використовуючи kubectl:

    PSP_NAME="original" # Встановіть назву PSP, яку ви перевіряєте
    kubectl get pods --all-namespaces -o jsonpath="{range .items[?(@.metadata.annotations.kubernetes\.io\/psp=='$PSP_NAME')]}{.metadata.namespace} {.metadata.name}{'\n'}{end}"
    
  2. Порівняйте ці робочі навантаження з оригінальною специфікацією Podаʼа, щоб визначити, чи змінила PodSecurityPolicy Pod. Для Podʼів, створених за ресурсами робочого навантаження, ви можете порівняти Pod з PodTemplate в ресурсі контролера. Якщо будь-які зміни виявлені, оригінальний Pod або PodTemplate слід оновити з необхідною конфігурацією. Поля для перегляду:

    • .metadata.annotations['container.apparmor.security.beta.kubernetes.io/*'] (замініть * на назву кожного контейнера)
    • .spec.runtimeClassName
    • .spec.securityContext.fsGroup
    • .spec.securityContext.seccompProfile
    • .spec.securityContext.seLinuxOptions
    • .spec.securityContext.supplementalGroups
    • У контейнерів, під .spec.containers[*] та .spec.initContainers[*]:
      • .securityContext.allowPrivilegeEscalation
      • .securityContext.capabilities.add
      • .securityContext.capabilities.drop
      • .securityContext.readOnlyRootFilesystem
      • .securityContext.runAsGroup
      • .securityContext.runAsNonRoot
      • .securityContext.runAsUser
      • .securityContext.seccompProfile
      • .securityContext.seLinuxOptions
  3. Створіть нові PodSecurityPolicies. Якщо будь-які Roles або ClusterRoles надають use на всі PSP, це може призвести до використання нових PSP замість їх мутуючих аналогів.

  4. Оновіть вашу авторизацію, щоб дозволити доступ до нових PSP. У RBAC це означає оновлення будь-яких Roles або ClusterRoles, які надають дозвіл use на оригінальну PSP, щоб також надати його оновленому PSP.

  5. Перевірте: після деякого часу повторно виконайте команду з кроку 1, щоб переглянути, чи використовуються будь-які Podʼи за оригінальними PSP. Зверніть увагу, що Podʼи повинні бути перестворені після того, як нові політики будуть впроваджені, перш ніж їх можна буде повністю перевірити.

  6. (опціонально) Після того, як ви перевірили, що оригінальні PSP більше не використовуються, ви можете їх видалити.

3. Оновлення просторів імен

Наступні кроки потрібно виконати для кожного простору імен у кластері. Команди, на які посилаються в цих кроках, використовують змінну $NAMESPACE для посилання на простір імен, який оновлюється.

3.а. Визначення відповідного рівня безпеки Podʼа

Почніть з ознайомлення зі Стандартами безпеки Podʼа та з трьома різними рівнями цих стандартів.

Існує кілька способів вибору рівня безпеки Podʼа для вашого простору імен:

  1. За вимогами безпеки для простору імен — Якщо ви знайомі з очікуваним рівнем доступу для простору імен, ви можете вибрати відповідний рівень, базуючись на цих вимогах, подібно до підходу, який можна застосувати в новому кластері.

  2. За поточними PodSecurityPolicies — Використовуючи довідник Перенесення PodSecurityPolicies у Pod Security Standards, ви можете віднести кожен PSP до рівня стандарту безпеки Podʼа. Якщо ваші PSP не базуються на Pod Security Standards, вам може знадобитися вирішити, обирати рівень, який є принаймні таким же дозвільним, як PSP, або рівень, який є принаймні таким же обмежувальним. Які PSP використовуються для Podʼів у даному просторі імен, ви можете побачити за допомогою цієї команди:

    kubectl get pods -n $NAMESPACE -o jsonpath="{.items[*].metadata.annotations.kubernetes\.io\/psp}" | tr " " "\n" | sort -u
    
  3. За поточними Podʼами — Використовуючи стратегії з розділу Перевірка рівня безпеки Podʼа, ви можете перевірити рівні Baseline і Restricted, щоб побачити, чи є вони достатньо дозвільними для наявних робочих навантажень, і вибрати найменш привілейований валідний рівень.

3.б. Перевірка рівня безпеки Podʼа

Після того як ви обрали рівень безпеки Podʼа для простору імен (або якщо ви пробуєте кілька), добре було б спершу його протестувати (цей крок можна пропустити, якщо використовується рівень Privileged). Безпека Podʼа включає кілька інструментів для тестування та безпечного впровадження профілів.

Спочатку ви можете виконати пробний запуск політики, який оцінить Podʼи, що вже працюють у просторі імен, відносно застосованої політики, не впроваджуючи нову політику в дію:

# $LEVEL - рівень для пробного запуску, або "baseline", або "restricted".
kubectl label --dry-run=server --overwrite ns $NAMESPACE pod-security.kubernetes.io/enforce=$LEVEL

Ця команда поверне попередження для будь-яких наявних Podʼів, які не відповідають запропонованому рівню.

Другий варіант краще підходить для виявлення робочих навантажень, які в цей момент не запущені: режим аудиту. Коли запущено в режимі аудиту (на відміну від примусового впровадження), Podʼи, які порушують рівень політики, реєструються у логах аудиту, які можна переглянути пізніше після деякого часу, але вони не заборонені. Режим попередження працює подібно, але надсилає попередження користувачу негайно. Ви можете встановити рівень аудиту для простору імен за допомогою цієї команди:

kubectl label --overwrite ns $NAMESPACE pod-security.kubernetes.io/audit=$LEVEL

Якщо будь-який з цих підходів призведе до несподіваних порушень, вам потрібно буде або оновити робочі навантаження, що їх спричиняють, щоб відповідати вимогам політики, або послабити рівень безпеки простору імен Pod.

3.в. Впровадження рівня безпеки Podʼа

Коли ви переконаєтеся, що обраний рівень може бути безпечно впроваджений для простору імен, ви можете оновити простір імен, щоб впровадити бажаний рівень:

kubectl label --overwrite ns $NAMESPACE pod-security.kubernetes.io/enforce=$LEVEL

3.г. Оминання політики безпеки Pod

Наостанок, ви можете ефективно оминути PodSecurityPolicy на рівні простору імен, привʼязавши повністю привілейовану PSP до всіх облікових записів служб у просторі імен.

# Наступні команди, які виконуються на рівні кластера, потрібні лише один раз.
kubectl apply -f privileged-psp.yaml
kubectl create clusterrole privileged-psp --verb use --resource podsecuritypolicies.policy --resource-name privileged

# Вимкнення на рівні простору імен
kubectl create -n $NAMESPACE rolebinding disable-psp --clusterrole privileged-psp --group system:serviceaccounts:$NAMESPACE

Оскільки привілейована PSP не є мутуючою, а контролер прийняття рішення PSP завжди віддає перевагу немутуючим PSP, це гарантує, що Podʼи в цьому просторі імен більше не змінюються або не обмежуються PodSecurityPolicy.

Перевага вимкнення PodSecurityPolicy на рівні простору імен полягає в тому, що у разі виникнення проблеми ви можете легко скасувати зміну, видаливши RoleBinding. Просто переконайтеся, що попередньо наявні PodSecurityPolicy все ще застосовуються!

# Скасування вимкнення PodSecurityPolicy.
kubectl delete -n $NAMESPACE rolebinding disable-psp

4. Перегляд процесів створення просторів імен

Тепер, коли поточні простори імен оновлено для забезпечення прийняття рішень щодо Pod Security Admission, вам слід переконатися, що ваші процеси та/або політики для створення нових просторів імен оновлено, щоб гарантувати застосування відповідного профілю безпеки Pod для нових просторів імен.

Ви також можете статично налаштувати контролер Pod Security Admission для встановлення типового рівня впровадження, аудиту та/або попередження для просторів імен без міток. Див. Налаштування контролера допуску для отримання додаткової інформації.

5. Вимкнення PodSecurityPolicy

Нарешті, ви готові вимкнути PodSecurityPolicy. Для цього вам потрібно змінити конфігурацію допуску сервера API: Як я можу вимкнути контролер допуску?.

Щоб перевірити, що контролер допуску PodSecurityPolicy більше не активний, ви можете вручну запустити тест, видаючи себе за користувача без доступу до будь-яких PodSecurityPolicies (див. приклад PodSecurityPolicy), або перевірити логи сервера API. При запуску сервер API виводить рядки логу, що перераховують завантажені втулки контролера допуску:

I0218 00:59:44.903329      13 plugins.go:158] Loaded 16 mutating admission controller(s) successfully in the following order: NamespaceLifecycle,LimitRanger,ServiceAccount,NodeRestriction,TaintNodesByCondition,Priority,DefaultTolerationSeconds,ExtendedResourceToleration,PersistentVolumeLabel,DefaultStorageClass,StorageObjectInUseProtection,RuntimeClass,DefaultIngressClass,MutatingAdmissionWebhook.
I0218 00:59:44.903350      13 plugins.go:161] Loaded 14 validating admission controller(s) successfully in the following order: LimitRanger,ServiceAccount,PodSecurity,Priority,PersistentVolumeClaimResize,RuntimeClass,CertificateApproval,CertificateSigning,CertificateSubjectRestriction,DenyServiceExternalIPs,ValidatingAdmissionWebhook,ResourceQuota.

Ви маєте побачити PodSecurity (у списку контролерів допуску для перевірки валідності), і жоден зі списків не повинен містити PodSecurityPolicy.

Після того, як ви впевнені, що контролер допуску PSP вимкнуто (і після достатнього часу, щоб бути впевненим, що вам не потрібно буде відкочувати зміни), ви вільні видалити ваші PodSecurityPolicies та будь-які повʼязані Roles, ClusterRoles, RoleBindings та ClusterRoleBindings (просто переконайтеся, що вони не надають будь-яких інших неповʼязаних дозволів).

4.4 - Моніторинг, логування та налагодження

Налаштуйте моніторинг та логування для розвʼязання проблем кластера або налагодження контейнеризованих застосунків.

Іноді речі йдуть не так. Цей посібник призначений для допомоги у виправленні помилок. Він має два розділи:

Вам також слід перевірити відомі проблеми для випуску, який ви використовуєте.

Отримання допомоги

Якщо вашу проблему не вдається вирішити жодною з інструкцій вище, існує ряд способів, як отримати допомогу від спільноти Kubernetes.

Питання

Документація на цьому сайті структурована таким чином, щоб надавати відповіді на широкий спектр питань. Концепції пояснюють архітектуру Kubernetes та роботу кожного компонента, в той час, як Налаштування надає практичні інструкції для початку роботи. Завдання показують, як виконати широке коло завдань, а Посібники — це більш комплексні огляди сценаріїв реального життя, специфічних для галузей або розробки з початку до кінця. Розділ Довідник надає детальну документацію з API Kubernetes та інтерфейсів командного рядка (CLI), таких як kubectl.

Допоможіть! Моє питання не розглянуто! Мені потрібна допомога зараз!

Stack Exchange, Stack Overflow або Server Fault

Якщо у вас є питання, повʼязане з розробкою програмного забезпечення для вашого контейнеризованого застосунку, ви можете задати його на Stack Overflow.

Якщо у вас є питання про Kubernetes, повʼязані з управлінням кластером або конфігурацією, ви можете задати їх на Server Fault.

Також існують кілька більш конкретних сайтів мережі Stack Exchange, які можуть бути відповідним місцем для питань про Kubernetes в таких областях, як DevOps, Software Engineering або InfoSec.

Хтось зі спільноти може вже ставив схоже питання або може допомогти з вашою проблемою.

Команда Kubernetes також слідкуватиме за постами з теґом Kubernetes. Якщо немає наявних питань, які можуть допомогти, будь ласка, переконайтеся, що ваше питання відповідає правилам Stack Overflow, Server Fault або сайту мережі Stack Exchange, на якому ви його ставите, і ознайомтеся з інструкцією як поставити нове питання, перед тим як задавати нове!

Slack

Багато людей зі спільноти Kubernetes збираються у Kubernetes Slack в каналі #kubernetes-users. Slack вимагає реєстрації; ви можете запросити запрошення, і реєстрація відкрита для всіх). Запрошуємо приходити та ставити будь-які питання. Після реєстрації ви отримайте доступ до організації Kubernetes у Slack у вебоглядачі або в застосунку Slack.

Після реєстрації переглядайте список каналів для різних тем. Наприклад, люди, які тільки вчаться Kubernetes, також можуть приєднатися до каналу #kubernetes-novice. Як ще один приклад, розробникам корисно приєднатися до каналу #kubernetes-contributors.

Також існують багато каналів, специфічних для країн / мов. Запрошуємо приєднатися до цих каналів для локалізованої підтримки та інформації:

Країна / канал Slack
КраїнаКанали
Китай#cn-users, #cn-events
Фінляндія#fi-users
Франція#fr-users, #fr-events
Німеччина#de-users, #de-events
Індія#in-users, #in-events
Італія#it-users, #it-events
Японія#jp-users, #jp-events
Корея#kr-users
Нідерланди#nl-users
Норвегія#norw-users
Польща#pl-users
Росія#ru-users
Іспанія#es-users
Швеція#se-users
Туреччина#tr-users, #tr-events

Форум

Вас раді бачити на офіційному форумі Kubernetes: discuss.kubernetes.io.

Помилки та запитання щодо функціонала

Якщо у вас є ознаки помилки або ви хочете подати запит на новий функціонал, будь ласка, скористайтесь тікетами GitHub.

Перед тим як створити тікет, будь ласка, перегляньте наявні проблеми, щоб переконатися, чи є вже вирішення для вашої проблеми.

Якщо ви подаєте звіт про помилку, будь ласка, включіть детальні відомості про те, як відтворити проблему, таку як:

  • Версія Kubernetes: kubectl version
  • Хмарний провайдер, дистрибутив ОС, конфігурація мережі та версія оточення виконання контейнерів
  • Кроки для відтворення проблеми

4.4.1 - Налагодження застосунків

Виправлення загальних проблем з контейнеризованими застосунками.

Цей розділ містить набір ресурсів для виправлення проблем з контейнеризованими застосунками. Він охоплює такі речі, як загальні проблеми з ресурсами Kubernetes (наприклад, Pods, Services або StatefulSets), поради щодо розуміння повідомлень про припинення роботи контейнера та способи налагодження запущених контейнерів.

4.4.1.1 - Налагодження Podʼів

Цей посібник допоможе користувачам налагодити програми, які розгорнуті у Kubernetes та які поводяться некоректно. Це не настанова для людей, які хочуть налагоджувати свій кластер. Для цього вам слід ознайомитися з цим посібником.

Діагностика проблеми

Перший крок у розвʼязанні проблем — сортування. Що сталося? Проблема у ваших Podʼах, Контролері Реплікацій чи Service?

Налагодження Podʼів

Перший крок у налагоджені Podʼа — це його перевірка. Перевірте поточний стан Podʼа та останні події за допомогою наступної команди:

kubectl describe pods ${POD_NAME}

Огляньте стан контейнерів у Podʼі. Чи всі вони Running (працюють)? Чи були нещодавні перезапуски?

Продовжуйте налагодження, виходячи зі стану Podʼів.

Мій Pod залишається в стані Pending

Якщо Pod застряг у стані Pending, це означає, що його не можна запланувати на вузол. Зазвичай це відбувається через недостатні ресурси одного типу чи іншого, які заважають плануванню. Подивіться на вивід команди kubectl describe ... вище. Там мають бути повідомлення від планувальника про причини, чому він не може запланувати ваш Pod. Причини включають:

  • У вас недостатньо ресурсів: Можливо, ви вичерпали запас CPU або памʼяті у вашому кластері, у цьому випадку вам потрібно видалити Podʼи, налаштувати запити на ресурси, або додати нові вузли до вашого кластера. Дивіться документ про обчислювальні ресурси для отримання додаткової інформації.

  • Ви використовуєте hostPort: Коли ви привʼязуєте Pod до hostPort, існує обмежена кількість місць, де можна запланувати цей Pod. У більшості випадків, hostPort не є необхідним, спробуйте використати обʼєкт Service для відкриття доступу вашому Podʼу. Якщо вам все ж потрібен hostPort, то ви можете запланувати лише стільки Podʼів, скільки у вас вузлів у кластері Kubernetes.

Мій Pod залишається у стані Waiting

Якщо Pod застряг у стані Waiting, то він був запланований на робочий вузол, але не може працювати на цій машині. Знову ж таки, вивід команди kubectl describe ... має бути інформативним. Найпоширенішою причиною Podʼів у стані Waiting є неможливість завантаження образу. Тут є три речі, які потрібно перевірити:

  • Переконайтеся, що ви правильно вказали імʼя образу.
  • Чи ви завантажили образ у реєстр?
  • Спробуйте вручну завантажити образ, щоб перевірити, чи можна його завантажити. Наприклад, якщо ви використовуєте Docker на вашому ПК, виконайте docker pull <image>.

Мій Pod залишається у стані Terminating

Якщо Pod застряг у стані Terminating (завершення), це означає, що було видано наказ про видалення Podʼа, але планпанель управління не може видалити обʼєкт Pod.

Це зазвичай відбувається, якщо у Podʼа є завершувач та встановлений вубхук допуску у кластері, який перешкоджає панелі управління видалити завершувач.

Щоб виявити цей сценарій, перевірте, чи у вашому кластері є вебхуки ValidatingWebhookConfiguration або MutatingWebhookConfiguration, які спрямовані на операції UPDATE для ресурсів pods.

Якщо вебхук надається стороннім вендором:

  • Переконайтеся, що ви використовуєте останню версію.
  • Вимкніть вебхук для операцій UPDATE.
  • Повідомте про проблему відповідного постачальника.

Якщо ви є автором вебхуку:

  • Для мутуючого вебхуку переконайтеся, що він ніколи не змінює незмінні поля під час операцій UPDATE. Наприклад, зміни контейнерів зазвичай не дозволяються.
  • Для перевірки вебхуку переконайтеся, що ваші політики валідації застосовуються лише до нових змін. Іншими словами, ви повинні дозволяти Podʼам з наявними порушеннями пройти валідацію. Це дозволяє Podʼам, які були створені до встановлення вебхуку валідації, продовжувати працювати.

Мій Pod виходить з ладу або несправний іншим чином

Як тільки ваш Pod був запланований, методи, описані в Налагодження Запущених Подів, доступні для налагодження.

Мій Pod працює, але не робить те, що я йому сказав робити

Якщо ваш Pod не поводиться так, як ви очікували, це може бути повʼязано з помилкою у вашому описі Podʼа (наприклад, файл mypod.yaml на вашому локальному компʼютері), і цю помилку було мовчки проігноровано під час створення Podʼа. Часто розділ опису Podʼа вкладено неправильно, або імʼя ключа набрано неправильно, і тому ключ ігнорується. Наприклад, якщо ви помилилися в написанні command як commnd, тоді Pod буде створено, але не використовуватиме командний рядок, який ви планували.

Перша річ, яку варто зробити, — видалити свій Pod і спробувати створити його знову з опцією --validate. Наприклад, виконайте kubectl apply --validate -f mypod.yaml. Якщо ви помилилися в написанні command як commnd, то отримаєте помилку на кшталт цієї:

I0805 10:43:25.129850   46757 schema.go:126] unknown field: commnd
I0805 10:43:25.129973   46757 schema.go:129] this may be a false alarm, see https://github.com/kubernetes/kubernetes/issues/6842
pods/mypod

Наступне, що варто перевірити, — чи відповідає Pod на апісервері Podʼу, який ви збиралися створити (наприклад, у файлі YAML на вашому локальному компʼютері). Наприклад, виконайте kubectl get pods/mypod -o yaml > mypod-on-apiserver.yaml а потім вручну порівняйте оригінальний опис Podʼа, mypod.yaml, з тим, який ви отримали з апісервера, mypod-on-apiserver.yaml. Зазвичай деякі рядки в версії "апісервера" відсутні в оригінальній версії. Це очікувано. Однак, якщо є рядки в оригінальному описі, яких немає в версії апісервера, то це може свідчити про проблему з вашими специфікаціями Podʼа.

Налагодження Контролерів Реплікацій

Контролери реплікацій досить прості. Вони можуть або створювати Podʼи, або не можуть. Якщо вони не можуть створювати Podʼи, будь ласка, зверніться до інструкцій вище, щоб налагодити ваші Podʼи.

Ви також можете використовувати kubectl describe rc ${CONTROLLER_NAME} для вивчення подій, що стосуються контролера реплікацій.

Налагодження Serviceʼів

Serviceʼи забезпечують балансування навантаження між набором Podʼів. Є кілька загальних проблем, які можуть призвести до неправильної роботи Serviceʼів. Наступні інструкції допоможуть дослідити проблеми з Serviceʼами.

Спочатку перевірте, що для Service є точки доступу. Для кожного обʼєкта Service апісервер робить ресурс endpoints доступним.

Ви можете переглянути цей ресурс за допомогою:

kubectl get endpoints ${SERVICE_NAME}

Переконайтеся, що точки доступу відповідають кількості Podʼів, які ви очікуєте бачити в складі вашого Service. Наприклад, якщо ваш Service для контейнера nginx має 3 репліки, ви очікуєте побачити три різних IP-адреси у точках доступу Serviceʼу.

Мій Service відсутні точки доступу

Якщо вам не вистачає точок доступу, спробуйте передивитись перелік Podʼів за допомогою міток, які використовує Service. Уявіть, що у вас є Service, де є такі мітки:

...
spec:
  - selector:
     name: nginx
     type: frontend

Ви можете використовувати:

kubectl get pods --selector=name=nginx,type=frontend

щоб отримати перелік Podʼів, які відповідають цьому селектору. Перевірте, чи список відповідає Podʼам, які ви очікуєте бачити у вашому Service. Перевірте, чи containerPort Podʼа відповідає targetPort Serviceʼа.

Мережевий трафік не переспрямовується

Будь ласка, див. налагодження Service для отримання додаткової інформації.

Що далі

Якщо жоден із вищезазначених методів не розвʼязує вашу проблему, слідкуйте інструкціям у документі про налагодження Serviceʼу щоб переконатися, що ваш Service працює, має Endpoints, і ваші Podʼи фактично обслуговуються; DNS працює, встановлені правила iptables, і kube-proxy поводиться відповідно.

Ви також можете відвідати документ про налагодження для отримання додаткової інформації.

4.4.1.2 - Налагодження Service

Досить часто виникає проблема в нових інсталяціях Kubernetes, коли Service не працює належним чином. Ви запустили свої Podʼи за допомогою Deployment (або іншого контролера робочих навантажень) і створили Service, але не отримуєте відповіді при спробі отримати до нього доступ. Цей документ, сподіваємось, допоможе вам зрозуміти, що йде не так.

Виконання команд у Podʼі

Для багатьох кроків ви захочете побачити, що бачить Pod, який працює в кластері. Найпростіший спосіб зробити це — запустити інтерактивний Pod busybox:

kubectl run -it --rm --restart=Never busybox --image=gcr.io/google-containers/busybox sh

Якщо у вас вже є Pod, який ви хочете використовувати для цього, ви можете виконати команду у ньому за допомогою:

kubectl exec <ІМ'Я-ПОДА> -c <ІМ'Я-КОНТЕЙНЕРА> -- <КОМАНДА>

Підготовка

Для цілей цього огляду запустімо кілька Podʼів. Оскільки ви, швидше за все, налагоджуєте власний Service, ви можете використати свої власні дані, або ви можете слідувати разом із нами та отримати інші дані.

kubectl create deployment hostnames --image=registry.k8s.io/serve_hostname
deployment.apps/hostnames created

Команди kubectl будуть виводити тип та імʼя створеного або зміненого ресурсу, які потім можна використовувати в наступних командах.

Масштабуймо Deployment до 3 реплік.

kubectl scale deployment hostnames --replicas=3
deployment.apps/hostnames scaled

Зверніть увагу, що це так само, якби ви запустили Deployment за допомогою наступного YAML:

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: hostnames
  name: hostnames
spec:
  selector:
    matchLabels:
      app: hostnames
  replicas: 3
  template:
    metadata:
      labels:
        app: hostnames
    spec:
      containers:
      - name: hostnames
        image: registry.k8s.io/serve_hostname

За допомогою kubectl create deployment в значення мітки "app" автоматично встановлюється імʼя Deployment.

Ви можете підтвердити, що ваші Podʼи працюють:

kubectl get pods -l app=hostnames
NAME                        READY     STATUS    RESTARTS   AGE
hostnames-632524106-bbpiw   1/1       Running   0          2m
hostnames-632524106-ly40y   1/1       Running   0          2m
hostnames-632524106-tlaok   1/1       Running   0          2m

Ви також можете підтвердити, що ваші Podʼи обслуговуються. Ви можете отримати список IP-адрес Podʼів та протестувати їх безпосередньо.

kubectl get pods -l app=hostnames \
    -o go-template='{{range .items}}{{.status.podIP}}{{"\n"}}{{end}}'
10.244.0.5
10.244.0.6
10.244.0.7

Приклад контейнера, використаного для цього огляду, обслуговує своє власне імʼя хосту через HTTP на порті 9376, але якщо ви налагоджуєте свій власний застосунок, вам потрібно буде використовувати номер порту, на якому слухають ваші Podʼи.

З середини Podʼа:

for ep in 10.244.0.5:9376 10.244.0.6:9376 10.244.0.7:9376; do
    wget -qO- $ep
done

Ви маєте отримати щось на зразок:

hostnames-632524106-bbpiw
hostnames-632524106-ly40y
hostnames-632524106-tlaok

Якщо ви не отримуєте очікувані відповіді на цьому етапі, ваші Pod\и можуть бути несправними або можуть не прослуховувати порт, який ви вважаєте. Можливо, kubectl logs буде корисним для перегляду того, що відбувається, або, можливо, вам потрібно буде виконати kubectl exec безпосередньо у вашому Podʼі та робити налагодження звідти.

Якщо все пройшло згідно з планом до цього моменту, ви можете почати розслідування того, чому ваш Service не працює.

Чи Service існує?

Уважний читач може зауважити, що ви фактично ще не створили Service — це навмисно. Це крок, який іноді забувають, і це перше, що треба перевірити.

Що станеться, якщо ви спробуєте отримати доступ до Service, що не існує? Якщо у вас є інший Pod, який використовує цей Service за іменем, ви отримаєте щось на зразок:

wget -O- hostnames
Resolving hostnames (hostnames)... failed: Name or service not known.
wget: unable to resolve host address 'hostnames'

Перше, що треба перевірити — це чи насправді існує цей Service:

kubectl get svc hostnames
No resources found.
Error from server (NotFound): services "hostnames" not found

Створімо Service. Як і раніше, це для цього огляду — ви можете використовувати свої власні дані Service тут.

kubectl expose deployment hostnames --port=80 --target-port=9376
service/hostnames exposed

І перевіримо:

kubectl get svc hostnames
NAME        TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
hostnames   ClusterIP   10.0.1.175   <none>        80/TCP    5s

Тепер ви знаєте, що Service існує.

Як і раніше, це те саме, якби ви запустили Service за допомогою YAML:

apiVersion: v1
kind: Service
metadata:
  labels:
    app: hostnames
  name: hostnames
spec:
  selector:
    app: hostnames
  ports:
  - name: default
    protocol: TCP
    port: 80
    targetPort: 9376

Щоб підкреслити повний спектр налаштувань, Service, який ви створили тут, використовує інший номер порту, ніж Podʼи. Для багатьох реальних Serviceʼів ці значення можуть бути однаковими.

Чи впливають будь-які правила Network Policy Ingress на цільові Podʼи?

Якщо ви розгорнули будь-які правила Network Policy Ingress, які можуть вплинути на вхідний трафік до hostnames-* Pod, їх потрібно переглянути.

Будь ласка, зверніться до Мережевих політик для отримання додаткових відомостей.

Чи працює Service за DNS-іменем?

Один із найпоширеніших способів, яким клієнти використовують Service, — це через DNS-імʼя.

З Podʼа в тому ж Namespace:

nslookup hostnames
Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local

Name:      hostnames
Address 1: 10.0.1.175 hostnames.default.svc.cluster.local

Якщо це не вдається, можливо, ваш Pod і Service знаходяться в різних Namespace, спробуйте використати імʼя з Namespace (знову ж таки, зсередини Podʼа):

nslookup hostnames.default
Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local

Name:      hostnames.default
Address 1: 10.0.1.175 hostnames.default.svc.cluster.local

Якщо це працює, вам потрібно налаштувати свій застосунок на використання імені, яке входить у Namespace, або запустіть ваш застосунок та Service в тому ж Namespace. Якщо це все ще не працює, спробуйте повне імʼя:

nslookup hostnames.default.svc.cluster.local
Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local

Name:      hostnames.default.svc.cluster.local
Address 1: 10.0.1.175 hostnames.default.svc.cluster.local

Зверніть увагу на суфікс тут: "default.svc.cluster.local". "default" — це Namespace, в якому ви працюєте. "svc" позначає, що це Service. "cluster.local" — це ваш домен кластера, який МОЖЕ відрізнятися у вашому власному кластері.

Ви також можете спробувати це з вузла в кластері:

nslookup hostnames.default.svc.cluster.local 10.0.0.10
Server:         10.0.0.10
Address:        10.0.0.10#53

Name:   hostnames.default.svc.cluster.local
Address: 10.0.1.175

Якщо ви можете зробити пошук повного імені, але не відноснлшл, вам потрібно перевірити, чи правильний ваш файл /etc/resolv.conf в Podʼі. Зсередини Podʼа:

cat /etc/resolv.conf

Ви повинні побачити щось на зразок:

nameserver 10.0.0.10
search default.svc.cluster.local svc.cluster.local cluster.local example.com
options ndots:5

Рядок nameserver повинен вказувати на Service DNS вашого кластера. Це передається в kubelet з прапорцем --cluster-dns.

Рядок search повинен включати відповідний суфікс, щоб ви змогли знайти імʼя Serviceʼу. У цьому випадку він шукає Serviceʼи в локальному Namespace ("default.svc.cluster.local"), Serviceʼи у всіх Namespace ("svc.cluster.local"), і наостанок для імен в кластері ("cluster.local"). Залежно від вашого власного налаштування, у вас можуть бути додаткові записи після цього (до 6 загалом). Суфікс кластера передається в kubelet з прапорцем --cluster-domain. У цьому документі передбачається, що суфікс кластера — "cluster.local". У ваших власних кластерах це може бути налаштовано по-іншому, у такому випадку вам слід змінити це в усіх попередніх командах.

Чи працює будь-який Service за допомогою DNS-імені?

Якщо вищезазначене все ще не працює, DNS-запити не працюють для вашого Service. Ви можете зробити крок назад і побачити, що ще не працює. Service майстра Kubernetes повинен завжди працювати. Зсередини Podʼа:

nslookup kubernetes.default
Server:    10.0.0.10
Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local

Name:      kubernetes.default
Address 1: 10.0.0.1 kubernetes.default.svc.cluster.local

Якщо це не вдається, будь ласка, перегляньте розділ kube-proxy цього документа, або навіть поверніться до початку цього документа і почніть знову, але замість налагодження вашого власного Service, спробуйте Service DNS.

Чи працює Service за IP?

Припускаючи, що ви підтвердили, що DNS працює, наступне, що варто перевірити, — це чи ваш Service працює за його IP-адресою. З Podʼа в вашому кластері, зверніться до IP-адреси Service (з вищезазначеного виводу kubectl get).

for i in $(seq 1 3); do 
    wget -qO- 10.0.1.175:80
done

Це має видати щось подібне:

hostnames-632524106-bbpiw
hostnames-632524106-ly40y
hostnames-632524106-tlaok

Якщо ваш Service працює, ви повинні отримати правильні відповіді. Якщо ні, існує кілька можливих причин, через які це може не працювати. Дивіться далі.

Чи правильно визначений Service?

Це може звучати дивно, але ви справді повинні подеколи перевірити, що ваш Service вірний і відповідає порту вашого Podʼа. Перегляньте свій Service і перевірте його:

kubectl get service hostnames -o json
{
    "kind": "Service",
    "apiVersion": "v1",
    "metadata": {
        "name": "hostnames",
        "namespace": "default",
        "uid": "428c8b6c-24bc-11e5-936d-42010af0a9bc",
        "resourceVersion": "347189",
        "creationTimestamp": "2015-07-07T15:24:29Z",
        "labels": {
            "app": "hostnames"
        }
    },
    "spec": {
        "ports": [
            {
                "name": "default",
                "protocol": "TCP",
                "port": 80,
                "targetPort": 9376,
                "nodePort": 0
            }
        ],
        "selector": {
            "app": "hostnames"
        },
        "clusterIP": "10.0.1.175",
        "type": "ClusterIP",
        "sessionAffinity": "None"
    },
    "status": {
        "loadBalancer": {}
    }
}
  • Чи вказано порт Serviceʼу, який ви намагаєтеся отримати доступ в spec.ports[]?
  • Чи правильний targetPort для ваших Podʼів (деякі Podʼи використовують інший порт, ніж Service)?
  • Якщо ви мали на увазі використання числового порту, це число (9376) чи рядок "9376"?
  • Якщо ви мали на увазі використання порту за іменем, чи ваші Podʼи використовують порт з тим самим імʼям?
  • Чи правильний протокол порту для ваших Podʼів?

Чи має Service будь-які Endpoints?

Якщо ви дійшли до цього пункту, ви підтвердили, що ваш Service правильно визначений і його можна знайти через DNS. Тепер перевірмо, що Podʼи, які ви запустили, фактично вибираються Serviceʼом.

Раніше ви бачили, що Podʼи працюють. Ви можете перевірити це ще раз:

kubectl get pods -l app=hostnames
NAME                        READY     STATUS    RESTARTS   AGE
hostnames-632524106-bbpiw   1/1       Running   0          1h
hostnames-632524106-ly40y   1/1       Running   0          1h
hostnames-632524106-tlaok   1/1       Running   0          1h

Аргумент -l app=hostnames — це селектор міток, налаштований у Service.

Стовпець "AGE" вказує, що ці Podʼи працюють добре і не мали збоїв.

Стовпець "RESTARTS" вказує, що ці Podʼи не часто мають збої або не перезавантажуються. Часті перезапуски можуть призвести до періодичних проблем зі зʼєднанням. Якщо кількість перезапусків висока, прочитайте більше про те, як налагоджувати Podʼи.

У межах системи Kubernetes є цикл керування, який оцінює селектор кожного Service і зберігає результати відповідно до обʼєкта Endpoints.

kubectl get endpoints hostnames

NAME        ENDPOINTS
hostnames   10.244.0.5:9376,10.244.0.6:9376,10.244.0.7:9376

Це підтверджує, що контролер Endpoints знайшов правильні Podʼи для вашого Service. Якщо стовпець ENDPOINTS має значення <none>, вам слід перевірити, що поле spec.selector вашого Service дійсно вибирає значення metadata.labels у ваших Podʼах. Частою помилкою є наявність хибодруку або іншої помилки, наприклад, Service вибирає app=hostnames, але Deployment вказує run=hostnames, як у версіях до 1.18, де команда kubectl run також могла бути використана для створення Deployment.

Чи працюють Podʼи?

На цьому етапі ви знаєте, що ваш Service існує і вибрав ваші Podʼи. На початку цього кроку ви перевірили самі Podʼи. Давайте ще раз перевіримо, що Podʼи дійсно працюють — ви можете оминути механізм Service і звернутися безпосередньо до Podʼів, які вказані в Endpoints вище.

З середини Podʼа:

for ep in 10.244.0.5:9376 10.244.0.6:9376 10.244.0.7:9376; do
    wget -qO- $ep
done

Це повинно показати щось на зразок:

hostnames-632524106-bbpiw
hostnames-632524106-ly40y
hostnames-632524106-tlaok

Ви очікуєте, що кожний Pod в списку Endpoints поверне свій власний hostname. Якщо це не те, що відбувається (або будь-яка інша правильна поведінка для ваших власних Podʼів), вам слід дослідити, що відбувається там.

Чи працює kube-proxy?

Якщо ви дісталися до цього моменту, ваш Service працює, має Endpoints, і ваші Podʼи фактично обслуговують запити. На цьому етапі увесь механізм проксі Service під підозрою. Підтвердьмо це крок за кроком.

Стандартна реалізація Service, і та, яка використовується в більшості кластерів, — це kube-proxy. Це програма, яка працює на кожному вузлі і конфігурує один з невеликого набору механізмів для надання абстракції Service. Якщо ваш кластер не використовує kube-proxy, наступні розділи не застосовуються, і вам доведеться дослідити будь-яку реалізацію Service, яку ви використовуєте.

Чи запущено kube-proxy?

Підтвердіть, що kube-proxy працює на ваших Вузлах. Запустіть команду безпосередньо на Вузлі, і ви повинні побачити щось на зразок такого:

ps auxw | grep kube-proxy
root  4194  0.4  0.1 101864 17696 ?    Sl Jul04  25:43 /usr/local/bin/kube-proxy --master=https://kubernetes-master --kubeconfig=/var/lib/kube-proxy/kubeconfig --v=2

Далі переконайтесь, що він не має явних проблем, таких як неможливість звʼязатися з майстром. Для цього вам доведеться переглянути логи. Доступ до логів залежить від вашої ОС Вузла. На деяких ОС це файл, наприклад /var/log/kube-proxy.log, тоді як на інших ОС використовується journalctl для доступу до логів. Ви повинні побачити щось на зразок:

I1027 22:14:53.995134    5063 server.go:200] Running in resource-only container "/kube-proxy"
I1027 22:14:53.998163    5063 server.go:247] Using iptables Proxier.
I1027 22:14:54.038140    5063 proxier.go:352] Setting endpoints for "kube-system/kube-dns:dns-tcp" to [10.244.1.3:53]
I1027 22:14:54.038164    5063 proxier.go:352] Setting endpoints for "kube-system/kube-dns:dns" to [10.244.1.3:53]
I1027 22:14:54.038209    5063 proxier.go:352] Setting endpoints for "default/kubernetes:https" to [10.240.0.2:443]
I1027 22:14:54.038238    5063 proxier.go:429] Not syncing iptables until Services and Endpoints have been received from master
I1027 22:14:54.040048    5063 proxier.go:294] Adding new service "default/kubernetes:https" at 10.0.0.1:443/TCP
I1027 22:14:54.040154    5063 proxier.go:294] Adding new service "kube-system/kube-dns:dns" at 10.0.0.10:53/UDP
I1027 22:14:54.040223    5063 proxier.go:294] Adding new service "kube-system/kube-dns:dns-tcp" at 10.0.0.10:53/TCP

Якщо ви бачите повідомлення про помилки щодо неможливості звʼязатися з майстром, вам слід перевірити конфігурацію і кроки інсталяції вашого Вузла.

Одна з можливих причин невдачі коректної роботи kube-proxy — неможливість знайти необхідний бінарний файл conntrack. Це може статися на деяких Linux-системах, залежно від того, як ви встановлюєте кластер, наприклад, якщо ви встановлюєте Kubernetes з нуля. У цьому випадку вам потрібно вручну встановити пакунок conntrack (наприклад, sudo apt install conntrack на Ubuntu), а потім спробувати ще раз.

Kube-proxy може працювати в одному з декількох режимів. У вищенаведеному журналі рядок Using iptables Proxier вказує на те, що kube-proxy працює в режимі "iptables". Ще один поширений режим — "ipvs".

Режим iptables

У режимі "iptables" ви повинні побачити щось на зразок наступного на Вузлі:

iptables-save | grep hostnames
-A KUBE-SEP-57KPRZ3JQVENLNBR -s 10.244.3.6/32 -m comment --comment "default/hostnames:" -j MARK --set-xmark 0x00004000/0x00004000
-A KUBE-SEP-57KPRZ3JQVENLNBR -p tcp -m comment --comment "default/hostnames:" -m tcp -j DNAT --to-destination 10.244.3.6:9376
-A KUBE-SEP-WNBA2IHDGP2BOBGZ -s 10.244.1.7/32 -m comment --comment "default/hostnames:" -j MARK --set-xmark 0x00004000/0x00004000
-A KUBE-SEP-WNBA2IHDGP2BOBGZ -p tcp -m comment --comment "default/hostnames:" -m tcp -j DNAT --to-destination 10.244.1.7:9376
-A KUBE-SEP-X3P2623AGDH6CDF3 -s 10.244.2.3/32 -m comment --comment "default/hostnames:" -j MARK --set-xmark 0x00004000/0x00004000
-A KUBE-SEP-X3P2623AGDH6CDF3 -p tcp -m comment --comment "default/hostnames:" -m tcp -j DNAT --to-destination 10.244.2.3:9376
-A KUBE-SERVICES -d 10.0.1.175/32 -p tcp -m comment --comment "default/hostnames: cluster IP" -m tcp --dport 80 -j KUBE-SVC-NWV5X2332I4OT4T3
-A KUBE-SVC-NWV5X2332I4OT4T3 -m comment --comment "default/hostnames:" -m statistic --mode random --probability 0.33332999982 -j KUBE-SEP-WNBA2IHDGP2BOBGZ
-A KUBE-SVC-NWV5X2332I4OT4T3 -m comment --comment "default/hostnames:" -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-X3P2623AGDH6CDF3
-A KUBE-SVC-NWV5X2332I4OT4T3 -m comment --comment "default/hostnames:" -j KUBE-SEP-57KPRZ3JQVENLNBR

Для кожного порту кожного Service повинно бути 1 правило у KUBE-SERVICES і один ланцюжок KUBE-SVC-<хеш>. Для кожного endpoint Podʼа повинна бути невелика кількість правил у цьому KUBE-SVC-<хеш> і один ланцюжок KUBE-SEP-<хеш> з невеликою кількістю правил. Точні правила будуть варіюватися залежно від вашої конфігурації (включаючи порти вузлів та балансувальники навантаження).

Режим IPVS

У режимі "ipvs" ви повинні побачити щось на зразок наступного на Вузлі:

ipvsadm -ln
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
...
TCP  10.0.1.175:80 rr
  -> 10.244.0.5:9376               Masq    1      0          0
  -> 10.244.0.6:9376               Masq    1      0          0
  -> 10.244.0.7:9376               Masq    1      0          0
...

Для кожного порту кожного Service, плюс будь-які NodePorts, зовнішні IP-адреси та IP-адреси балансувальника навантаження, kube-proxy створить віртуальний сервер. Для кожного endpoint Podʼа він створить відповідні реальні сервери. У цьому прикладі служба hostnames(10.0.1.175:80) має 3 endpoint (10.244.0.5:9376, 10.244.0.6:9376, 10.244.0.7:9376).

Чи kube-proxy керує трафіком?

Якщо ви бачите один із вищезазначених випадків, спробуйте ще раз отримати доступ до вашого Service за допомогою IP з одного з ваших Вузлів:

curl 10.0.1.175:80
hostnames-632524106-bbpiw

Якщо це все ще не вдається, перегляньте логи kube-proxy на наявність конкретних рядків, подібних до:

Setting endpoints for default/hostnames:default to [10.244.0.5:9376 10.244.0.6:9376 10.244.0.7:9376]

Якщо ви не бачите цього, спробуйте перезапустити kube-proxy з прапорцем -v, встановленим на 4, і потім знову перегляньте логи.

Крайній випадок: Pod не може звернутися до себе за допомогою IP-адреси Service

Це може здатися малоймовірним, але це може трапитися і має працювати.

Це може статися, коли мережа не належним чином налаштована для "зачісування" трафіку, зазвичай коли kube-proxy працює в режимі iptables, а Podʼи підключені за допомогою мережі bridge. Kubelet надає прапорець hairpin-mode, який дозволяє точкам доступу Service балансувати навантаження поверненням до себе, якщо вони намагаються отримати доступ до своєї власної VIP-адреси Service. Прапорець hairpin-mode має бути встановлено на значення hairpin-veth або promiscuous-bridge.

Загальні кроки для розвʼязання цього випадку мають бути такими:

  • Підтвердіть, що hairpin-mode встановлено у значення hairpin-veth або promiscuous-bridge. Можливий вигляд нижченаведеного. У наступному прикладі hairpin-mode встановлено на promiscuous-bridge.
ps auxw | grep kubelet
root      3392  1.1  0.8 186804 65208 ?        Sl   00:51  11:11 /usr/local/bin/kubelet --enable-debugging-handlers=true --config=/etc/kubernetes/manifests --allow-privileged=True --v=4 --cluster-dns=10.0.0.10 --cluster-domain=cluster.local --configure-cbr0=true --cgroup-root=/ --system-cgroups=/system --hairpin-mode=promiscuous-bridge --runtime-cgroups=/docker-daemon --kubelet-cgroups=/kubelet --babysit-daemons=true --max-pods=110 --serialize-image-pulls=false --outofdisk-transition-frequency=0
  • Підтвердіть поточний hairpin-mode. Для цього вам потрібно переглянути логи kubelet. Доступ до логів залежить від вашої операційної системи. На деяких ОС це файл, наприклад /var/log/kubelet.log, тоді як на інших ОС використовується journalctl для доступу до логів. Зверніть увагу, що поточний режим hairpin може не відповідати прапорцю --hairpin-mode через сумісність. Перевірте, чи є будь-які рядки в лозі з ключовим словом hairpin в kubelet.log. Повинні бути рядки в лозі, які показують поточний режим hairpin, схожі на наступне:
I0629 00:51:43.648698    3252 kubelet.go:380] Hairpin mode set to "promiscuous-bridge"
  • Якщо поточний режим hairpin — hairpin-veth, переконайтеся, що Kubelet має дозвіл на роботу в /sys на вузлі. Якщо все працює належним чином, ви побачите щось на зразок:
for intf in /sys/devices/virtual/net/cbr0/brif/*; do cat $intf/hairpin_mode; done
1
1
1
1
  • Якщо поточний режим hairpin — promiscuous-bridge, переконайтеся, що Kubelet має дозвіл на маніпулювання bridge в Linux на вузлі. Якщо bridge cbr0 використовується і налаштований належним чином, ви побачите:
ifconfig cbr0 |grep PROMISC
UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1460  Metric:1
  • Зверніться за допомогою, якщо жоден з вищезазначених методів не працює.

Пошук допомоги

Якщо ви дійшли до цього моменту, відбувається щось дуже дивне. Ваш Service працює, має точки доступу, і ваші Podʼи насправді обслуговують запити. DNS працює, і kube-proxy схоже не діє неправильно. Проте ваш Service не працює. Будь ласка, дайте нам знати, що відбувається, щоб ми могли допомогти вам розслідувати цю проблему!

Звертайтеся до нас у Slack або на Форум чи у GitHub.

Що далі

Відвідайте документ про загальні відомості про усунення несправностей для отримання додаткової інформації.

4.4.1.3 - Налагодження StatefulSet

Ця задача показує, як усувати несправності у StatefulSet.

Перш ніж ви розпочнете

  • Вам потрібен кластер Kubernetes, та інструмент командного рядка kubectl повинен бути налаштований на звʼязок з вашим кластером.
  • Ви повинні мати запущений StatefulSet, який ви хочете дослідити.

Усунення несправностей у StatefulSet

Для того, щоб переглянути всі Podʼи, які належать до StatefulSet і мають мітку app.kubernetes.io/name=MyApp на них, ви можете використовувати наступне:

kubectl get pods -l app.kubernetes.io/name=MyApp

Якщо ви помітили, що будь-які Podʼи вказані у стані Unknown або Terminating протягом тривалого періоду часу, зверніться до завдання Видалення Podʼів StatefulSet за інструкціями щодо дії з ними. Ви можете усувати несправності окремих Podʼів у StatefulSet, використовуючи Посібник з усунення несправностей Podʼів.

Що далі

Дізнайтеся більше про усунення несправностей контейнера ініціалізації.

4.4.1.4 - Визначення причини збою Podʼа

Ця сторінка показує, як записувати та читати повідомлення про припинення роботи контейнера.

Повідомлення про припинення роботи надають можливість контейнерам записувати інформацію про фатальні події у місце, звідки її можна легко витягти та показувати за допомогою інструментів, таких як інформаційні панелі та програмне забезпечення моніторингу. У більшості випадків інформацію, яку ви вводите у повідомлення про припинення роботи, також слід записати в логи Kubernetes.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Запис та читання повідомлення про припинення роботи

У цьому завданні ви створюєте Pod, який запускає один контейнер. У маніфесті для цього Podʼа вказано команду, яка виконується при запуску контейнера:

apiVersion: v1
kind: Pod
metadata:
  name: termination-demo
spec:
  containers:
  - name: termination-demo-container
    image: debian
    command: ["/bin/sh"]
    args: ["-c", "sleep 10 && echo Sleep expired > /dev/termination-log"]
  1. Створіть Pod на основі конфігураційного файлу YAML:

    kubectl apply -f https://k8s.io/examples/debug/termination.yaml
    

    У файлі YAML у полях command та args ви можете побачити, що контейнер перебуває в стані очікування (спить) протягом 10 секунд, а потім записує "Sleep expired" у файл /dev/termination-log. Після того, як контейнер записує повідомлення "Sleep expired", він завершує роботу.

  2. Покажіть інформацію про Pod:

    kubectl get pod termination-demo
    

    Повторіть попередню команду, доки Pod більше не буде запущений.

  3. Покажіть детальну інформацію про Pod:

    kubectl get pod termination-demo --output=yaml
    

    Вивід містить повідомлення "Sleep expired":

    apiVersion: v1
    kind: Pod
    ...
        lastState:
          terminated:
            containerID: ...
            exitCode: 0
            finishedAt: ...
            message: |
              Sleep expired          
            ...
    
  4. Використовуйте шаблон Go для фільтрування виводу так, щоб він містив лише повідомлення про припинення роботи контейнера:

    kubectl get pod termination-demo -o go-template="{{range .status.containerStatuses}}{{.lastState.terminated.message}}{{end}}"
    

Якщо у вас працює багатоконтейнерний Pod, ви можете використовувати шаблон Go, щоб включити імʼя контейнера. Таким чином, ви можете визначити, який з контейнерів несправний:

kubectl get pod multi-container-pod -o go-template='{{range .status.containerStatuses}}{{printf "%s:\n%s\n\n" .name .lastState.terminated.message}}{{end}}'

Налаштування повідомлення про припинення роботи

Kubernetes отримує повідомлення про припинення роботи з файлу повідомлення, вказаного в полі terminationMessagePath контейнера, яке має стандартне значення /dev/termination-log. Налаштувавши це поле, ви можете сказати Kubernetes використовувати інший файл. Kubernetes використовує вміст зазначеного файлу для заповнення повідомлення про стан контейнера як у випадку успіху, так і невдачі.

Повідомлення про припинення має бути коротким остаточним статусом, таким як повідомлення про помилку твердження. Kubelet обрізає повідомлення, які довше 4096 байтів.

Загальна довжина повідомлення по всіх контейнерах обмежена 12KiB і рівномірно розподілена між всіма контейнерами. Наприклад, якщо є 12 контейнерів (initContainers або containers), кожен має 1024 байти доступного простору для повідомлень про припинення роботи.

Стандартний шлях для повідомлення про припинення роботи — /dev/termination-log. Ви не можете встановити шлях повідомлення про припинення роботи після запуску Podʼа.

У наступному прикладі контейнер записує повідомлення про завершення в /tmp/my-log для отримання Kubernetes:

apiVersion: v1
kind: Pod
metadata:
  name: msg-path-demo
spec:
  containers:
  - name: msg-path-demo-container
    image: debian
    terminationMessagePath: "/tmp/my-log"

Крім того, користувачі можуть налаштувати поле terminationMessagePolicy контейнера для подальшої настройки. Типово це поле встановлене на "File", що означає, що повідомлення про припинення роботи отримуються лише з файлу повідомлення про припинення роботи. Встановивши terminationMessagePolicy на "FallbackToLogsOnError", ви можете вказати Kubernetes використовувати останній фрагмент виводу контейнера, якщо файл повідомлення про припинення роботи порожній, і контейнер завершився з помилкою. Вивід логу обмежується 2048 байтами або 80 рядками, якщо вибірка менша.

Що далі

4.4.1.5 - Налагодження контейнерів ініціалізації

Ця сторінка показує, як розвʼязувати проблеми, повʼязані з запуском контейнерів ініціалізації. Приклади команд нижче вказують на Pod як <pod-name> та на контейнери ініціалізації як <init-container-1> та <init-container-2>.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Для перевірки версії введіть kubectl version.

Перевірка стану контейнерів ініціалізації

Показ статусу вашого Podʼа:

kubectl get pod <pod-name>

Наприклад, статус Init:1/2 вказує на те, що один з двох контейнерів ініціалізації успішно завершено:

NAME         READY     STATUS     RESTARTS   AGE
<pod-name>   0/1       Init:1/2   0          7s

Дивіться Розуміння статусів Podʼа для отримання прикладів значень статусу та їх значень.

Отримання деталей про контейнери ініціалізації

Показ більш детальної інформації про виконання контейнерів ініціалізації:

kubectl describe pod <pod-name>

Наприклад, Pod з двома контейнерами ініціалізації може показати наступне:

Init Containers:
  <init-container-1>:
    Container ID:    ...
    ...
    State:           Terminated
      Reason:        Completed
      Exit Code:     0
      Started:       ...
      Finished:      ...
    Ready:           True
    Restart Count:   0
    ...
  <init-container-2>:
    Container ID:    ...
    ...
    State:           Waiting
      Reason:        CrashLoopBackOff
    Last State:      Terminated
      Reason:        Error
      Exit Code:     1
      Started:       ...
      Finished:      ...
    Ready:           False
    Restart Count:   3
    ...

Ви також можете отримувати доступ до статусів контейнерів ініціалізації програмно, читаючи поле status.initContainerStatuses у Pod Spec:

kubectl get pod nginx --template '{{.status.initContainerStatuses}}'

Ця команда поверне ту саму інформацію, що і вище у форматі JSON.

Отримання логів з контейнерів ініціалізації

Вкажіть імʼя контейнера ініціалізації разом з імʼям Podʼа, щоб отримати його логи.

kubectl logs <pod-name> -c <init-container-2>

Контейнери ініціалізації, що виконують скрипт оболонки, друкують команди в міру їх виконання. Наприклад, це можна зробити в Bash, запустивши set -x на початку скрипта.

Розуміння статусів Podʼа

Статус Podʼа, що починається з Init:, узагальнює стан виконання контейнерів ініціалізації. У таблиці нижче наведено деякі приклади значень статусу, які ви можете бачити під час налагодження контейнерів ініціалізації.

СтатусЗначення
Init:N/MPod має M контейнерів ініціалізації, і N вже завершено.
Init:ErrorКонтейнер ініціалізації не вдалося виконати.
Init:CrashLoopBackOffКонтейнер ініціалізації неперервно виходить з ладу.
PendingPod ще не розпочав виконувати контейнер ініціалізації.
PodInitializing або RunningPod вже завершив виконання контейнерів ініціалізації.

4.4.1.6 - Налагодження запущених Podʼів

Ця сторінка пояснює, як налагоджувати Podʼи, що запущені (або зазнають збою) на вузлі.

Перш ніж ви розпочнете

  • Ваш Pod вже повинен бути запланований та запущений. Якщо ваш Pod ще не запущений, почніть з Налагодження Podʼів.
  • Для деяких з розширених кроків налагодження вам потрібно знати, на якому вузлі запущений Pod, і мати доступ до оболонки для виконання команд на цьому вузлі. Вам не потрібен такий доступ для виконання стандартних кроків налагодження, що використовують kubectl.

Використання kubectl describe pod для отримання деталей про Podʼи

Для цього прикладу ми використовуватимемо Deployment для створення двох Podʼів, схожих на попередній приклад.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        resources:
          limits:
            memory: "128Mi"
            cpu: "500m"
        ports:
        - containerPort: 80

Створіть Deployment, запустивши наступну команду:

kubectl apply -f https://k8s.io/examples/application/nginx-with-request.yaml
deployment.apps/nginx-deployment created

Перевірте статус Podʼа за допомогою наступної команди:

kubectl get pods
NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-67d4bdd6f5-cx2nz   1/1     Running   0          13s
nginx-deployment-67d4bdd6f5-w6kd7   1/1     Running   0          13s

Ми можемо отримати більше інформації про кожен з цих Podʼів, використовуючи kubectl describe pod. Наприклад:

kubectl describe pod nginx-deployment-67d4bdd6f5-w6kd7
Name:         nginx-deployment-67d4bdd6f5-w6kd7
Namespace:    default
Priority:     0
Node:         kube-worker-1/192.168.0.113
Start Time:   Thu, 17 Feb 2022 16:51:01 -0500
Labels:       app=nginx
              pod-template-hash=67d4bdd6f5
Annotations:  <none>
Status:       Running
IP:           10.88.0.3
IPs:
  IP:           10.88.0.3
  IP:           2001:db8::1
Controlled By:  ReplicaSet/nginx-deployment-67d4bdd6f5
Containers:
  nginx:
    Container ID:   containerd://5403af59a2b46ee5a23fb0ae4b1e077f7ca5c5fb7af16e1ab21c00e0e616462a
    Image:          nginx
    Image ID:       docker.io/library/nginx@sha256:2834dc507516af02784808c5f48b7cbe38b8ed5d0f4837f16e78d00deb7e7767
    Port:           80/TCP
    Host Port:      0/TCP
    State:          Running
      Started:      Thu, 17 Feb 2022 16:51:05 -0500
    Ready:          True
    Restart Count:  0
    Limits:
      cpu:     500m
      memory:  128Mi
    Requests:
      cpu:        500m
      memory:     128Mi
    Environment:  <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-bgsgp (ro)
Conditions:
  Type              Status
  Initialized       True 
  Ready             True 
  ContainersReady   True 
  PodScheduled      True 
Volumes:
  kube-api-access-bgsgp:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       <nil>
    DownwardAPI:             true
QoS Class:                   Guaranteed
Node-Selectors:              <none>
Tolerations:                 node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type    Reason     Age   From               Message
  ----    ------     ----  ----               -------
  Normal  Scheduled  34s   default-scheduler  Successfully assigned default/nginx-deployment-67d4bdd6f5-w6kd7 to kube-worker-1
  Normal  Pulling    31s   kubelet            Pulling image "nginx"
  Normal  Pulled     30s   kubelet            Successfully pulled image "nginx" in 1.146417389s
  Normal  Created    30s   kubelet            Created container nginx
  Normal  Started    30s   kubelet            Started container nginx

Тут ви можете побачити інформацію про конфігурацію контейнерів та Podʼа (мітки, вимоги до ресурсів і т. д.), а також інформацію про статус контейнерів та Podʼа (стан, готовність, кількість перезапусків, події й т.д.).

Стан контейнера може бути Waiting (очікування), Running (виконання) або Terminated (завершено). Залежно від стану, буде надано додаткову інформацію — наприклад, ви можете побачити, коли контейнер був запущений, якщо він перебуває в стані Running.

Ready показує, чи пройшов контейнер останню пробу готовності. (У цьому випадку контейнер не має налаштованої проби готовності; вважається, що контейнер готовий, якщо проба готовності не налаштована.)

Restart Count показує, скільки разів контейнер був перезапущений; ця інформація може бути корисною для виявлення циклів аварійного перезапуску в контейнерах, які налаштовані на перезапуск завжди ('always').

Наразі єдина умова, повʼязана з Podʼом, — це бінарна умова Ready, яка вказує, що Pod може обслуговувати запити та повинен бути доданий до пулів балансування навантаження всіх відповідних Serviceʼів.

Нарешті, ви бачите логи недавніх подій, що стосуються вашого Podʼа. "From" вказує на компонент, який реєструє подію. "Reason" та "Message" розповідають вам, що сталося.

Приклад: налагодження Podʼів у стані Pending

Одна з поширених ситуацій, яку ви можете виявити за допомогою подій, — це коли ви створили Pod, який не може бути розміщений на жодному вузлі. Наприклад, Pod може вимагати більше ресурсів, ніж вільно на будь-якому вузлі, або він може вказати селектор міток, який не відповідає жодному вузлу. Скажімо, ми створили Deployment з 5 репліками (замість 2) і вимагаємо 600 міліядер замість 500, на чотирьох вузловому кластері, де кожна (віртуальна) машина має 1 ЦП. У цьому випадку один з Podʼів не зможе бути запланованим. (Зауважте, що через надбудови кластера, такі як fluentd, skydns тощо, які працюють на кожному вузлі, якби ми запросили 1000 міліядер, то жоден з Podʼів не міг би бути запланованим.)

kubectl get pods
NAME                                READY     STATUS    RESTARTS   AGE
nginx-deployment-1006230814-6winp   1/1       Running   0          7m
nginx-deployment-1006230814-fmgu3   1/1       Running   0          7m
nginx-deployment-1370807587-6ekbw   1/1       Running   0          1m
nginx-deployment-1370807587-fg172   0/1       Pending   0          1m
nginx-deployment-1370807587-fz9sd   0/1       Pending   0          1m

Щоб дізнатися, чому Pod nginx-deployment-1370807587-fz9sd не працює, ми можемо використовувати kubectl describe pod у Podʼі у стані Pending та переглянути його події:

kubectl describe pod nginx-deployment-1370807587-fz9sd
  Name:		nginx-deployment-1370807587-fz9sd
  Namespace:	default
  Node:		/
  Labels:		app=nginx,pod-template-hash=1370807587
  Status:		Pending
  IP:
  Controllers:	ReplicaSet/nginx-deployment-1370807587
  Containers:
    nginx:
      Image:	nginx
      Port:	80/TCP
      QoS Tier:
        memory:	Guaranteed
        cpu:	Guaranteed
      Limits:
        cpu:	1
        memory:	128Mi
      Requests:
        cpu:	1
        memory:	128Mi
      Environment Variables:
  Volumes:
    default-token-4bcbi:
      Type:	Secret (a volume populated by a Secret)
      SecretName:	default-token-4bcbi
  Events:
    FirstSeen	LastSeen	Count	From			        SubobjectPath	Type		Reason			    Message
    ---------	--------	-----	----			        -------------	--------	------			    -------
    1m		    48s		    7	    {default-scheduler }			        Warning		FailedScheduling	pod (nginx-deployment-1370807587-fz9sd) failed to fit in any node
  fit failure on node (kubernetes-node-6ta5): Node didn't have enough resource: CPU, requested: 1000, used: 1420, capacity: 2000
  fit failure on node (kubernetes-node-wul5): Node didn't have enough resource: CPU, requested: 1000, used: 1100, capacity: 2000

Тут ви можете побачити подію, створену планувальником, яка говорить, що Pod не вдалося запланувати з причиною FailedScheduling (і, можливо, інші). Повідомлення говорить нам, що на будь-якому з вузлів не було достатньо ресурсів для Podʼа.

Для виправлення цієї ситуації ви можете використовувати kubectl scale, щоб оновити ваш Deployment та вказати чотири або менше реплік. (Або ви можете залишити один Pod у стані Pending, що нешкідливо.)

Події, такі як ті, які ви бачили в кінці kubectl describe pod, зберігаються в etcd та надають високорівневу інформацію про те, що відбувається в кластері. Щоб переглянути всі події, ви можете використовувати

kubectl get events

але вам потрібно памʼятати, що події належать до простору імен. Це означає, що якщо вас цікавлять події для обʼєкта з простором імен (наприклад, що сталося з Podʼами в просторі імен my-namespace), вам потрібно явно вказати простір імен для команди:

kubectl get events --namespace=my-namespace

Щоб побачити події з усіх просторів імен, ви можете використовувати аргумент --all-namespaces.

Крім команди kubectl describe pod, інший спосіб отримати додаткову інформацію про Pod (поза тим, що надає kubectl get pod) — це передати прапорець формату виводу -o yaml команді kubectl get pod. Це надасть вам, у форматі YAML, ще більше інформації, ніж kubectl describe pod — фактично всю інформацію, яку система має про Pod. Тут ви побачите такі речі, як анотації (це метадані ключ-значення без обмежень міток, які використовуються внутрішньо компонентами системи Kubernetes), політику перезапуску, порти та томи.

kubectl get pod nginx-deployment-1006230814-6winp -o yaml
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: "2022-02-17T21:51:01Z"
  generateName: nginx-deployment-67d4bdd6f5-
  labels:
    app: nginx
    pod-template-hash: 67d4bdd6f5
  name: nginx-deployment-67d4bdd6f5-w6kd7
  namespace: default
  ownerReferences:
  - apiVersion: apps/v1
    blockOwnerDeletion: true
    controller: true
    kind: ReplicaSet
    name: nginx-deployment-67d4bdd6f5
    uid: 7d41dfd4-84c0-4be4-88ab-cedbe626ad82
  resourceVersion: "1364"
  uid: a6501da1-0447-4262-98eb-c03d4002222e
spec:
  containers:
  - image: nginx
    imagePullPolicy: Always
    name: nginx
    ports:
    - containerPort: 80
      protocol: TCP
    resources:
      limits:
        cpu: 500m
        memory: 128Mi
      requests:
        cpu: 500m
        memory: 128Mi
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    volumeMounts:
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: kube-api-access-bgsgp
      readOnly: true
  dnsPolicy: ClusterFirst
  enableServiceLinks: true
  nodeName: kube-worker-1
  preemptionPolicy: PreemptLowerPriority
  priority: 0
  restartPolicy: Always
  schedulerName: default-scheduler
  securityContext: {}
  serviceAccount: default
  serviceAccountName: default
  terminationGracePeriodSeconds: 30
  tolerations:
  - effect: NoExecute
    key: node.kubernetes.io/not-ready
    operator: Exists
    tolerationSeconds: 300
  - effect: NoExecute
    key: node.kubernetes.io/unreachable
    operator: Exists
    tolerationSeconds: 300
  volumes:
  - name: kube-api-access-bgsgp
    projected:
      defaultMode: 420
      sources:
      - serviceAccountToken:
          expirationSeconds: 3607
          path: token
      - configMap:
          items:
          - key: ca.crt
            path: ca.crt
          name: kube-root-ca.crt
      - downwardAPI:
          items:
          - fieldRef:
              apiVersion: v1
              fieldPath: metadata.namespace
            path: namespace
status:
  conditions:
  - lastProbeTime: null
    lastTransitionTime: "2022-02-17T21:51:01Z"
    status: "True"
    type: Initialized
  - lastProbeTime: null
    lastTransitionTime: "2022-02-17T21:51:06Z"
    status: "True"
    type: Ready
  - lastProbeTime: null
    lastTransitionTime: "2022-02-17T21:51:06Z"
    status: "True"
    type: ContainersReady
  - lastProbeTime: null
    lastTransitionTime: "2022-02-17T21:51:01Z"
    status: "True"
    type: PodScheduled
  containerStatuses:
  - containerID: containerd://5403af59a2b46ee5a23fb0ae4b1e077f7ca5c5fb7af16e1ab21c00e0e616462a
    image: docker.io/library/nginx:latest
    imageID: docker.io/library/nginx@sha256:2834dc507516af02784808c5f48b7cbe38b8ed5d0f4837f16e78d00deb7e7767
    lastState: {}
    name: nginx
    ready: true
    restartCount: 0
    started: true
    state:
      running:
        startedAt: "2022-02-17T21:51:05Z"
  hostIP: 192.168.0.113
  phase: Running
  podIP: 10.88.0.3
  podIPs:
  - ip: 10.88.0.3
  - ip: 2001:db8::1
  qosClass: Guaranteed
  startTime: "2022-02-17T21:51:01Z"

Перегляд логі Podʼа

Спочатку перегляньте журнали ураженого контейнера:

kubectl logs ${POD_NAME} ${CONTAINER_NAME}

Якщо ваш контейнер раніше впав, ви можете отримати доступ до попереднього логу аварії контейнера за допомогою:

kubectl logs --previous ${POD_NAME} ${CONTAINER_NAME}

Налагодження за допомогою виконання команд у контейнері

Якщо образ контейнера містить утиліти для налагодження, як це трапляється в образах, побудованих на основі базових образів операційних систем Linux і Windows, ви можете виконати команди всередині конкретного контейнера за допомогою kubectl exec:

kubectl exec ${POD_NAME} -c ${CONTAINER_NAME} -- ${CMD} ${ARG1} ${ARG2} ... ${ARGN}

Наприклад, щоб переглянути логи з робочого Podʼа Cassandra, ви можете виконати

kubectl exec cassandra -- cat /var/log/cassandra/system.log

Ви можете запустити оболонку, яка підключена до вашого термінала, використовуючи аргументи -i і -t для kubectl exec, наприклад:

kubectl exec -it cassandra -- sh

Для отримання додаткових відомостей дивіться Отримання оболонки до запущеного контейнера.

Налагодження за допомогою ефемерного контейнера

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.25 [stable]

Ефемерні контейнери корисні для інтерактивного усунення несправностей, коли kubectl exec недостатній через аварію контейнера або те, що образ контейнера не містить утиліт для налагодження, наприклад, в образах distroless.

Приклад налагодження за допомогою ефемерних контейнерів

Ви можете використовувати команду kubectl debug, щоб додати ефемерні контейнери до запущеного Podʼа. Спочатку створіть Pod для прикладу:

kubectl run ephemeral-demo --image=registry.k8s.io/pause:3.1 --restart=Never

У цьому розділі приклади використовують образ контейнера pause, оскільки він не містить утиліт для налагодження, але цей метод працює з будь-якими образом контейнера.

Якщо ви спробуєте використати kubectl exec для створення оболонки, ви побачите помилку, оскільки в цьому образі контейнера немає оболонки.

kubectl exec -it ephemeral-demo -- sh
OCI runtime exec failed: exec failed: container_linux.go:346: starting container process caused "exec: \"sh\": executable file not found in $PATH": unknown

Замість цього ви можете додати контейнер для налагодження за допомогою kubectl debug. Якщо ви вказуєте аргумент -i/--interactive, kubectl автоматично приєднується до консолі ефемерного контейнера.

kubectl debug -it ephemeral-demo --image=busybox:1.28 --target=ephemeral-demo
Defaulting debug container name to debugger-8xzrl.
If you don't see a command prompt, try pressing enter.
/ #

Ця команда додає новий контейнер busybox і приєднується до нього. Параметр --target спрямовує простір імен процесу до іншого контейнера. Це необхідно тут, оскільки kubectl run не ввімкнув процес спільного використання простору імен у Pod, який він створює.

Ви можете переглянути стан нового ефемерного контейнера, використовуючи kubectl describe:

kubectl describe pod ephemeral-demo
...
Ephemeral Containers:
  debugger-8xzrl:
    Container ID:   docker://b888f9adfd15bd5739fefaa39e1df4dd3c617b9902082b1cfdc29c4028ffb2eb
    Image:          busybox
    Image ID:       docker-pullable://busybox@sha256:1828edd60c5efd34b2bf5dd3282ec0cc04d47b2ff9caa0b6d4f07a21d1c08084
    Port:           <none>
    Host Port:      <none>
    State:          Running
      Started:      Wed, 12 Feb 2020 14:25:42 +0100
    Ready:          False
    Restart Count:  0
    Environment:    <none>
    Mounts:         <none>
...

Використовуйте kubectl delete, щоб видалити Pod, коли ви закінчите:

kubectl delete pod ephemeral-demo

Налагодження за допомогою копії Podʼа

Іноді параметри конфігурації Podʼа ускладнюють усунення несправностей у певних ситуаціях. Наприклад, ви не можете виконувати kubectl exec, щоб усунути несправності у вашому контейнері, якщо ваш образ контейнера не містить оболонки або якщо ваш застосунок аварійно завершується при запуску. У цих ситуаціях ви можете використовувати kubectl debug, щоб створити копію Podʼа зі зміненими значеннями конфігурації для полегшення налагодження.

Копіювання Podʼа з додаванням нового контейнера

Додавання нового контейнера може бути корисним, коли ваш застосунок працює, але не так, як ви очікували, і ви хочете додати додаткові засоби усунення несправностей до Podʼа.

Наприклад, можливо, образ контейнера вашого застосунку збудований на основі busybox, але вам потрібні засоби для налагодження, які не включені в busybox. Ви можете симулювати цей сценарій за допомогою kubectl run:

kubectl run myapp --image=busybox:1.28 --restart=Never -- sleep 1d

Виконайте цю команду, щоб створити копію myapp з назвою myapp-debug, яка додає новий контейнер Ubuntu для налагодження:

kubectl debug myapp -it --image=ubuntu --share-processes --copy-to=myapp-debug
Defaulting debug container name to debugger-w7xmf.
If you don't see a command prompt, try pressing enter.
root@myapp-debug:/#

Не забудьте прибрати Pod для налагодження, коли ви закінчите:

kubectl delete pod myapp myapp-debug

Копіювання Podʼа зі зміною його команди

Іноді корисно змінити команду для контейнера, наприклад, щоб додати прапорець для налагодження або через те, що застосунок аварійно завершується.

Щоб симулювати аварійне завершення застосунку, використайте kubectl run, щоб створити контейнер, який негайно завершується:

kubectl run --image=busybox:1.28 myapp -- false

Ви можете побачити за допомогою kubectl describe pod myapp, що цей контейнер аварійно завершується:

Containers:
  myapp:
    Image:         busybox
    ...
    Args:
      false
    State:          Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       Error
      Exit Code:    1

Ви можете використовувати kubectl debug, щоб створити копію цього Podʼа з командою зміненою на інтерактивну оболонку:

kubectl debug myapp -it --copy-to=myapp-debug --container=myapp -- sh
If you don't see a command prompt, try pressing enter.
/ #

Тепер у вас є інтерактивна оболонка, яку ви можете використовувати для виконання завдань, таких як перевірка шляхів файлової системи або виконання команди контейнера вручну.

Не забудьте прибрати Pod для налагодження, коли ви закінчите:

kubectl delete pod myapp myapp-debug

Копіювання Podʼа з заміною образів контейнерів

Іноді вам може знадобитися змінити образ Podʼа, який поводитися неналежним чином, зі звичайного образу, що використовується в операційній діяльності, на образ, що містить збірку для налагодження або додаткові утиліти.

Наприклад, створіть Pod за допомогою kubectl run:

kubectl run myapp --image=busybox:1.28 --restart=Never -- sleep 1d

Тепер використовуйте kubectl debug, щоб створити копію та змінити його образ контейнера на ubuntu:

kubectl debug myapp --copy-to=myapp-debug --set-image=*=ubuntu

Синтаксис --set-image використовує ту ж синтаксис container_name=image, що й kubectl set image. *=ubuntu означає зміну образу всіх контейнерів на ubuntu.

Не забудьте прибрати Pod для налагодження, коли ви закінчите:

kubectl delete pod myapp myapp-debug

Налагодження через оболонку на вузлі

Якщо жоден з цих підходів не працює, ви можете знайти вузол, на якому працює Pod, і створити Pod, який буде виконуватися на цьому вузлі. Щоб створити інтерактивну оболонку на вузлі за допомогою kubectl debug, виконайте:

kubectl debug node/mynode -it --image=ubuntu
Creating debugging pod node-debugger-mynode-pdx84 with container debugger on node mynode.
If you don't see a command prompt, try pressing enter.
root@ek8s:/#

При створенні сесії налагодження на вузлі майте на увазі, що:

  • kubectl debug автоматично генерує назву нового Podʼа на основі назви вузла.
  • Коренева файлова система вузла буде змонтована в /host.
  • Контейнер працює у просторах імен IPC, мережі та PID вузла, хоча Pod не є привілейованим, тому читання деякої інформації про процеси може не вдатися, і chroot /host може не спрацювати.
  • Якщо вам потрібен привілейований Pod, створіть його вручну або використовуйте прапорець --profile=sysadmin

Не забудьте прибрати Pod для налагодження, коли ви закінчите з ним:

kubectl delete pod node-debugger-mynode-pdx84

Профілі налагодження

Коли ви використовуєте kubectl debug для налагодження вузла за допомогою Podʼа налагодження, Pod за ефемерним контейнером або скопійованого Pod, ви можете застосувати до них профіль налагодження за допомогою прапорця --profile. Застосовуючи профіль, встановлюються конкретні властивості, такі як securityContext, що дозволяє адаптуватися до різних сценаріїв.

Доступні наступні профілі:

ПрофільОпис
legacyНабір властивостей для зворотної сумісності з поведінкою 1.22
generalРозумний набір загальних властивостей для кожного завдання налагодження
baselineНабір властивостей, сумісних з Політикою базової безпеки PodSecurityStandard
restrictedНабір властивостей, сумісних з Політикою обмеженої безпеки PodSecurityStandard
netadminНабір властивостей, включаючи привілеї адміністратора мережі
sysadminНабір властивостей, включаючи привілеї системного адміністратора (root)

Припустимо, що ви створюєте Pod і налагоджуєте його. Спочатку створіть Pod з назвою myapp, наприклад:

kubectl run myapp --image=busybox:1.28 --restart=Never -- sleep 1d

Потім, перевірте Pod за допомогою ефемерного контейнера. Якщо ефемерному контейнеру потрібно мати привілеї, ви можете використовувати профіль sysadmin:

kubectl debug -it myapp --image=busybox:1.28 --target=myapp --profile=sysadmin
Targeting container "myapp". If you don't see processes from this container it may be because the container runtime doesn't support this feature.
Defaulting debug container name to debugger-6kg4x.
If you don't see a command prompt, try pressing enter.
/ #

Перевірте можливості процесу ефемерного контейнера, виконавши наступну команду всередині контейнера:

/ # grep Cap /proc/$$/status
...
CapPrm:	000001ffffffffff
CapEff:	000001ffffffffff
...

Це означає, що процес контейнера наділений усіма можливостями як привілейований контейнер завдяки застосуванню профілю sysadmin. Дивіться більше деталей про можливості.

Ви також можете перевірити, що ефемерний контейнер був створений як привілейований контейнер:

kubectl get pod myapp -o jsonpath='{.spec.ephemeralContainers[0].securityContext}'
{"privileged":true}

Очистіть Pod, коли ви закінчите з ним:

kubectl delete pod myapp

4.4.1.7 - Отримання доступу до оболонки запущеного контейнера

Ця сторінка показує, як використовувати kubectl exec для отримання доступу до оболонки запущеного контейнера.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Отримання доступу до оболонки контейнера

У цьому завданні ви створите Pod, який має один контейнер. Контейнер виконує образ nginx. Ось файл конфігурації для Podʼа:

apiVersion: v1
kind: Pod
metadata:
  name: shell-demo
spec:
  volumes:
  - name: shared-data
    emptyDir: {}
  containers:
  - name: nginx
    image: nginx
    volumeMounts:
    - name: shared-data
      mountPath: /usr/share/nginx/html
  hostNetwork: true
  dnsPolicy: Default

Створіть Pod:

kubectl apply -f https://k8s.io/examples/application/shell-demo.yaml

Перевірте, що контейнер працює:

kubectl get pod shell-demo

Отримайте доступ до оболонки запущеного контейнера:

kubectl exec --stdin --tty shell-demo -- /bin/bash

У своїй оболонці виведіть список кореневої теки:

# Виконайте це всередині контейнера
ls /

У своїй оболонці експериментуйте з іншими командами. Ось деякі приклади:

# Ви можете виконати ці приклади команд всередині контейнера
ls /
cat /proc/mounts
cat /proc/1/maps
apt-get update
apt-get install -y tcpdump
tcpdump
apt-get install -y lsof
lsof
apt-get install -y procps
ps aux
ps aux | grep nginx

Редагування головної сторінки nginx

Знову перегляньте файл конфігурації вашого Podʼа. Pod має том emptyDir, і контейнер монтує цей том в /usr/share/nginx/html.

У своїй оболонці створіть файл index.html у теці /usr/share/nginx/html:

# Виконайте це всередині контейнера
echo 'Hello shell demo' > /usr/share/nginx/html/index.html

У своїй оболонці надішліть GET-запит до сервера nginx:

# Виконайте це в оболонці всередині вашого контейнера
apt-get update
apt-get install curl
curl http://localhost/

Результат покаже текст, який ви написали в файл index.html:

Hello shell demo

Коли ви закінчите з вашою оболонкою, введіть exit.

exit # Щоб вийти з оболонки в контейнері

Виконання окремих команд в контейнері

У звичайному вікні команд виведіть змінні оточення в запущеному контейнері:

kubectl exec shell-demo -- env

Експериментуйте з виконанням інших команд. Ось деякі приклади:

kubectl exec shell-demo -- ps aux
kubectl exec shell-demo -- ls /
kubectl exec shell-demo -- cat /proc/1/mounts

Відкриття оболонки, коли в Podʼі є більше одного контейнера

Якщо в Podʼі є більше одного контейнера, використовуйте --container або -c для зазначення контейнера в команді kubectl exec. Наприклад, припустимо, у вас є Pod на ім’я my-pod, і в Podʼі є два контейнери з іменами main-app та helper-app. Наступна команда відкриє оболонку до контейнера main-app.

kubectl exec -i -t my-pod --container main-app -- /bin/bash

Що далі

4.4.2 - Налагодження кластера

Виправлення загальних проблем з кластером Kubernetes.

Цей документ присвячений усуненню несправностей в кластері; ми передбачаємо, що ви вже виключили свій застосунок з переліку причин проблеми, з якою ви стикаєтеся. Дивіться посібник Налагодження застосунку для порад з перевірки застосунків. Ви також можете звернутися до загального документа з усунення несправностей для отримання додаткової інформації.

Щодо усунення несправностей інструменту kubectl, звертайтеся до Посібника з усунення несправностей kubectl.

Виведення інформації про кластер

Перша річ, яку потрібно дослідити у кластері — це переконатися, що всі ваші вузли зареєстровані правильно.

Виконайте наступну команду:

kubectl get nodes

Перевірте, що всі вузли, які ви очікуєте бачити, присутні, і що всі вони перебувають у стані Ready.

Щоб отримати детальну інформацію про загальний стан вашого кластера, ви можете виконати:

kubectl cluster-info dump

Приклад: налагодження вимкненого/недоступного вузла

Іноді при налагодженні може бути корисно переглянути стан вузла, наприклад, через те, що ви помітили дивну поведінку Podʼа, який працює на вузлі, або щоб дізнатися, чому Pod не може розміститися на вузлі. Так само як і з Podʼами, ви можете використовувати kubectl describe node та kubectl get node -o yaml, щоб отримати детальну інформацію про вузли. Наприклад, ось що ви побачите, якщо вузол вимкнено (відключено від мережі, або kubelet припинив роботу і не може перезапуститися і т. д.). Зверніть увагу на події, які показують, що вузол не готовий, і також зверніть увагу, що Podʼи більше не працюють (їх буде виселено після пʼяти хвилин стану NotReady).

kubectl get nodes
NAME                     STATUS       ROLES     AGE     VERSION
kube-worker-1            NotReady     <none>    1h      v1.23.3
kubernetes-node-bols     Ready        <none>    1h      v1.23.3
kubernetes-node-st6x     Ready        <none>    1h      v1.23.3
kubernetes-node-unaj     Ready        <none>    1h      v1.23.3
kubectl describe node kube-worker-1
Name:               kube-worker-1
Roles:              <none>
Labels:             beta.kubernetes.io/arch=amd64
                    beta.kubernetes.io/os=linux
                    kubernetes.io/arch=amd64
                    kubernetes.io/hostname=kube-worker-1
                    kubernetes.io/os=linux
Annotations:        kubeadm.alpha.kubernetes.io/cri-socket: /run/containerd/containerd.sock
                    node.alpha.kubernetes.io/ttl: 0
                    volumes.kubernetes.io/controller-managed-attach-detach: true
CreationTimestamp:  Thu, 17 Feb 2022 16:46:30 -0500
Taints:             node.kubernetes.io/unreachable:NoExecute
                    node.kubernetes.io/unreachable:NoSchedule
Unschedulable:      false
Lease:
  HolderIdentity:  kube-worker-1
  AcquireTime:     <unset>
  RenewTime:       Thu, 17 Feb 2022 17:13:09 -0500
Conditions:
  Type                 Status    LastHeartbeatTime                 LastTransitionTime                Reason              Message
  ----                 ------    -----------------                 ------------------                ------              -------
  NetworkUnavailable   False     Thu, 17 Feb 2022 17:09:13 -0500   Thu, 17 Feb 2022 17:09:13 -0500   WeaveIsUp           Weave pod has set this
  MemoryPressure       Unknown   Thu, 17 Feb 2022 17:12:40 -0500   Thu, 17 Feb 2022 17:13:52 -0500   NodeStatusUnknown   Kubelet stopped posting node status.
  DiskPressure         Unknown   Thu, 17 Feb 2022 17:12:40 -0500   Thu, 17 Feb 2022 17:13:52 -0500   NodeStatusUnknown   Kubelet stopped posting node status.
  PIDPressure          Unknown   Thu, 17 Feb 2022 17:12:40 -0500   Thu, 17 Feb 2022 17:13:52 -0500   NodeStatusUnknown   Kubelet stopped posting node status.
  Ready                Unknown   Thu, 17 Feb 2022 17:12:40 -0500   Thu, 17 Feb 2022 17:13:52 -0500   NodeStatusUnknown   Kubelet stopped posting node status.
Addresses:
  InternalIP:  192.168.0.113
  Hostname:    kube-worker-1
Capacity:
  cpu:                2
  ephemeral-storage:  15372232Ki
  hugepages-2Mi:      0
  memory:             2025188Ki
  pods:               110
Allocatable:
  cpu:                2
  ephemeral-storage:  14167048988
  hugepages-2Mi:      0
  memory:             1922788Ki
  pods:               110
System Info:
  Machine ID:                 9384e2927f544209b5d7b67474bbf92b
  System UUID:                aa829ca9-73d7-064d-9019-df07404ad448
  Boot ID:                    5a295a03-aaca-4340-af20-1327fa5dab5c
  Kernel Version:             5.13.0-28-generic
  OS Image:                   Ubuntu 21.10
  Operating System:           linux
  Architecture:               amd64
  Container Runtime Version:  containerd://1.5.9
  Kubelet Version:            v1.23.3
  Kube-Proxy Version:         v1.23.3
Non-terminated Pods:          (4 in total)
  Namespace                   Name                                 CPU Requests  CPU Limits  Memory Requests  Memory Limits  Age
  ---------                   ----                                 ------------  ----------  ---------------  -------------  ---
  default                     nginx-deployment-67d4bdd6f5-cx2nz    500m (25%)    500m (25%)  128Mi (6%)       128Mi (6%)     23m
  default                     nginx-deployment-67d4bdd6f5-w6kd7    500m (25%)    500m (25%)  128Mi (6%)       128Mi (6%)     23m
  kube-system                 kube-proxy-dnxbz                     0 (0%)        0 (0%)      0 (0%)           0 (0%)         28m
  kube-system                 weave-net-gjxxp                      100m (5%)     0 (0%)      200Mi (10%)      0 (0%)         28m
Allocated resources:
  (Total limits may be over 100 percent, i.e., overcommitted.)
  Resource           Requests     Limits
  --------           --------     ------
  cpu                1100m (55%)  1 (50%)
  memory             456Mi (24%)  256Mi (13%)
  ephemeral-storage  0 (0%)       0 (0%)
  hugepages-2Mi      0 (0%)       0 (0%)
Events:
...
kubectl get node kube-worker-1 -o yaml
apiVersion: v1
kind: Node
metadata:
  annotations:
    kubeadm.alpha.kubernetes.io/cri-socket: /run/containerd/containerd.sock
    node.alpha.kubernetes.io/ttl: "0"
    volumes.kubernetes.io/controller-managed-attach-detach: "true"
  creationTimestamp: "2022-02-17T21:46:30Z"
  labels:
    beta.kubernetes.io/arch: amd64
    beta.kubernetes.io/os: linux
    kubernetes.io/arch: amd64
    kubernetes.io/hostname: kube-worker-1
    kubernetes.io/os: linux
  name: kube-worker-1
  resourceVersion: "4026"
  uid: 98efe7cb-2978-4a0b-842a-1a7bf12c05f8
spec: {}
status:
  addresses:
  - address: 192.168.0.113
    type: InternalIP
  - address: kube-worker-1
    type: Hostname
  allocatable:
    cpu: "2"
    ephemeral-storage: "14167048988"
    hugepages-2Mi: "0"
    memory: 1922788Ki
    pods: "110"
  capacity:
    cpu: "2"
    ephemeral-storage: 15372232Ki
    hugepages-2Mi: "0"
    memory: 2025188Ki
    pods: "110"
  conditions:
  - lastHeartbeatTime: "2022-02-17T22:20:32Z"
    lastTransitionTime: "2022-02-17T22:20:32Z"
    message: Weave pod has set this
    reason: WeaveIsUp
    status: "False"
    type: NetworkUnavailable
  - lastHeartbeatTime: "2022-02-17T22:20:15Z"
    lastTransitionTime: "2022-02-17T22:13:25Z"
    message: kubelet has sufficient memory available
    reason: KubeletHasSufficientMemory
    status: "False"
    type: MemoryPressure
  - lastHeartbeatTime: "2022-02-17T22:20:15Z"
    lastTransitionTime: "2022-02-17T22:13:25Z"
    message: kubelet has no disk pressure
    reason: KubeletHasNoDiskPressure
    status: "False"
    type: DiskPressure
  - lastHeartbeatTime: "2022-02-17T22:20:15Z"
    lastTransitionTime: "2022-02-17T22:13:25Z"
    message: kubelet has sufficient PID available
    reason: KubeletHasSufficientPID
    status: "False"
    type: PIDPressure
  - lastHeartbeatTime: "2022-02-17T22:20:15Z"
    lastTransitionTime: "2022-02-17T22:15:15Z"
    message: kubelet is posting ready status. AppArmor enabled
    reason: KubeletReady
    status: "True"
    type: Ready
  daemonEndpoints:
    kubeletEndpoint:
      Port: 10250
  nodeInfo:
    architecture: amd64
    bootID: 22333234-7a6b-44d4-9ce1-67e31dc7e369
    containerRuntimeVersion: containerd://1.5.9
    kernelVersion: 5.13.0-28-generic
    kubeProxyVersion: v1.23.3
    kubeletVersion: v1.23.3
    machineID: 9384e2927f544209b5d7b67474bbf92b
    operatingSystem: linux
    osImage: Ubuntu 21.10
    systemUUID: aa829ca9-73d7-064d-9019-df07404ad448

Аналіз логів

Тепер для докладнішого вивчення кластера потрібно увійти на відповідні машини. Ось розташування відповідних файлів журналу. На системах, що використовують systemd, може знадобитися використання journalctl замість перегляду файлів журналу.

Вузли панелі управління

  • /var/log/kube-apiserver.log — Сервер API, відповідальний за обслуговування API
  • /var/log/kube-scheduler.log — Планувальник, відповідальний за прийняття рішень щодо планування
  • /var/log/kube-controller-manager.log — Компонент, який виконує більшість вбудованих контролерів Kubernetes, за винятком планування (за це відповідає планувальник kube-scheduler).

Робочі вузли

  • /var/log/kubelet.log — логи kubelet, відповідального за запуск контейнерів на вузлі
  • /var/log/kube-proxy.log — логи kube-proxy, відповідального за направлення трафіку на Service endpoints.

Режими відмови кластера

Це неповний перелік того, що може піти не так, та як виправити вашу конфігурацію кластера для помʼякшення проблем.

Причини відмов

  • Вимкнення віртуальних машин(и)
  • Розділ мережі в межах кластера чи між кластером та користувачами
  • Крах програмного забезпечення Kubernetes
  • Втрата даних або недоступність постійного сховища (наприклад, GCE PD або томів AWS EBS)
  • Помилка оператора, наприклад, неправильно налаштоване програмне забезпечення Kubernetes або застосунку

Конкретні сценарії

  • Вимкнення віртуальної машини або аварійне вимикання apiserver
    • Результати
      • не можна зупинити, оновити чи запустити нові Podʼи, Services, контролер реплікацій
      • наявні Podʼи та Services мають продовжувати нормальну роботу, якщо вони не залежать від API Kubernetes
  • Втрата даних, на яких ґрунтується API сервер
    • Результати
      • компонент kube-apiserver не може успішно стартувати та стати спроможним обслуговувати запити
      • kubelet не зможе досягти його, але продовжить виконувати ті самі Podʼи та забезпечувати той самий сервіс проксі
      • необхідне ручне відновлення або відновлення стану apiserver перед його перезапуском
  • Припинення роботи служб підтримки (контролер вузлів, менеджер контролера реплікацій, планувальник і т. д.) або їх крах
    • наразі вони розміщені разом з apiserver, і їхня недоступність має схожі наслідки, що й в apiserver
    • у майбутньому ці служби також будуть репліковані та не можуть бути розміщені в одному місці
    • вони не мають власного постійного стану
  • Вимкнення окремого вузла (віртуальна машина або фізична машина)
    • Результати
      • Podʼи на цьому вузлі перестають працювати
  • Розрив мережі
    • Результати
      • розділ A вважає, що вузли в розділі B вимкнені; розділ B вважає, що apiserver вимкнений. (Якщо майстер-вузол опиниться в розділі A.)
  • Збій програмного забезпечення kubelet
    • Результати
      • аварійно вимкнений kubelet не може стартувати нові Podʼи на вузлі
      • kubelet може видаляти Podʼи або ні
      • вузол позначений як неспроможний
      • контролери реплікацій стартують нові Podʼи в іншому місці
  • Помилка оператора кластера
    • Результати
      • втрата Podʼів, Services і т. ін.
      • втрата сховища даних для apiserver
      • користувачі не можуть читати API
      • і т.д.

Помʼякшення

  • Дія: Використовуйте функцію автоматичного перезапуску віртуальних машин IaaS для віртуальних машин IaaS

    • Помʼякшує: Вимкнення віртуальної машини або аварійне вимикання apiserver
    • Помʼякшує: Вимкнення служб підтримки або їх краху
  • Дія: Використовуйте надійне сховище IaaS (наприклад, GCE PD або том AWS EBS) для віртуальних машин з apiserver+etcd

    • Помʼякшує: Втрата даних, на яких ґрунтується API сервер
  • Дія: Використовуйте конфігурацію високої доступності

    • Помʼякшує: Вимкнення вузла керування або аварійне завершення роботи компонентів управління керуванням (планувальник, API сервер, менеджер контролера)
      • Витримає одне або кілька одночасних відмов вузлів або компонентів
    • Помʼякшує: Втрата сховища даних для API сервера (тобто каталог даних etcd)
      • Передбачає конфігурацію HA (highly-available) etcd
  • Дія: Регулярно створюйте знімки віртуальних машин або томів PD/EBS, які використовуються apiserver

    • Помʼякшує: Втрата сховища даних для API сервера
    • Помʼякшує: Деякі випадки помилок оператора
    • Помʼякшує: Деякі випадки несправності програмного забезпечення Kubernetes
  • Дія: Використовуйте контролер реплікацій та служби перед Podʼами

    • Помʼякшує: Вимкнення вузла
    • Помʼякшує: Збій програмного забезпечення kubelet
  • Дія: Застосунки (контейнери), призначені для того, щоб витримувати неочікувані перезапуски

    • Помʼякшує: Вимкнення вузла
    • Помʼякшує: Збій програмного забезпечення kubelet

Що далі

4.4.2.1 - Усунення несправностей kubectl

Ця документація присвячена дослідженню та діагностиці повʼязаних проблем kubectl. Якщо ви зіткнулися з проблемами доступу до kubectl або зʼєднанням з вашим кластером, цей документ окреслює різні загальні сценарії та потенційні рішення, які допоможуть виявити та усунути ймовірну причину.

Перш ніж ви розпочнете

Перевірка налаштувань kubectl

Переконайтеся, що ви правильно встановили та налаштували kubectl на вашому локальному компʼютері. Перевірте версію kubectl, щоб впевнитися, що вона актуальна та сумісна з вашим кластером.

Перевірка версії kubectl:

kubectl version

Ви побачите подібний вивід:

Client Version: version.Info{Major:"1", Minor:"27", GitVersion:"v1.27.4",GitCommit:"fa3d7990104d7c1f16943a67f11b154b71f6a132", GitTreeState:"clean",BuildDate:"2023-07-19T12:20:54Z", GoVersion:"go1.20.6", Compiler:"gc", Platform:"linux/amd64"}
Kustomize Version: v5.0.1
Server Version: version.Info{Major:"1", Minor:"27", GitVersion:"v1.27.3",GitCommit:"25b4e43193bcda6c7328a6d147b1fb73a33f1598", GitTreeState:"clean",BuildDate:"2023-06-14T09:47:40Z", GoVersion:"go1.20.5", Compiler:"gc", Platform:"linux/amd64"}

Якщо замість Server Version ви бачите Unable to connect to the server: dial tcp <server-ip>:8443: i/o timeout, вам потрібно дослідити проблеми зʼєднання kubectl з вашим кластером.

Переконайтеся, що ви встановили kubectl, слідуючи офіційній документації з встановлення kubectl, і правильно налаштували змінну середовища $PATH.

Перевірка kubeconfig

kubectl вимагає файл kubeconfig для зʼєднання з Kubernetes кластером. Файл kubeconfig зазвичай знаходиться в теці ~/.kube/config. Переконайтеся, що у вас є валідний файл kubeconfig. Якщо у вас немає файлу kubeconfig, ви можете отримати його у вашого адміністратора Kubernetes, або ви можете скопіювати його з теки /etc/kubernetes/admin.conf вашої панелі управління Kubernetes. Якщо ви розгортали ваш Kubernetes кластер на хмарній платформі та втратили ваш файл kubeconfig, ви можете згенерувати його знову за допомогою інструментів вашого хмарного провайдера. Дивіться документацію хмарного провайдера щодо генерації файлу kubeconfig.

Перевірте, чи правильно налаштовано змінну середовища $KUBECONFIG. Ви можете встановити змінну середовища $KUBECONFIG або використовувати параметр --kubeconfig з kubectl, щоб вказати теку файлу kubeconfig.

Перевірка VPN зʼєднання

Якщо ви використовуєте Віртуальну Приватну Мережу (VPN) для доступу до вашого Kubernetes кластеру, переконайтеся, що ваше VPN зʼєднання активне і стабільне. Іноді, перебої у зʼєднанні VPN можуть призвести до проблем зі зʼєднанням з кластером. Підʼєднайтеся до VPN знову і спробуйте отримати доступ до кластера знову.

Автентифікація та авторизація

Якщо ви використовуєте автентифікацію на базі токенів і kubectl повертає помилку щодо автентифікаційного токена або адреси сервера автентифікації, перевірте, що токен автентифікації Kubernetes та адреса сервера автентифікації налаштовані правильно.

Якщо kubectl повертає помилку щодо авторизації, переконайтеся, що ви використовуєте дійсні дані користувача. Та маєте дозвіл на доступ до ресурсу, який ви запросили.

Перевірка контекстів

Kubernetes підтримує роботу з кількома кластерами та контекстами. Переконайтеся, що ви використовуєте правильний контекст для взаємодії з вашим кластером.

Перелік доступних контекстів:

kubectl config get-contexts

Перемикання на відповідний контекст:

kubectl config use-context <context-name>

API сервер та балансувальник навантаження

kube-apiserver є центральним компонентом кластера Kubernetes. Якщо сервер API або балансувальник навантаження, який працює перед вашими серверами API, не доступний або не реагує, ви не зможете взаємодіяти з кластером.

Перевірте, чи доступний хост сервера API, використовуючи команду ping. Перевірте мережеве зʼєднання кластера та файервол. Якщо ви використовуєте хмарного провайдера для розгортання кластера, перевірте стан проб справності вашого хмарного провайдера для сервера API кластера.

Перевірте стан балансувальника навантаження (якщо використовується), щоб переконатися, що він справний і передає трафік на сервер API.

Проблеми з TLS

  • Потрібні додаткові інструменти — base64 та openssl версії 3.0 або вище.

Сервер API Kubernetes типово обслуговує лише HTTPS запити. У цьому випадку можуть виникнути проблеми з TLS з різних причин, таких як закінчення строку дії сертифіката або дійсність ланцюга довіри.

Ви можете знайти TLS сертифікат у файлі kubeconfig, який знаходиться у теці ~/.kube/config. Атрибут certificate-authority містить сертифікат ЦА, а атрибут client-certificate містить клієнтський сертифікат.

Перевірте строк дії цих сертифікатів:

kubectl config view --flatten --output 'jsonpath={.clusters[0].cluster.certificate-authority-data}' | base64 -d | openssl x509 -noout -dates

вивід:

notBefore=Feb 13 05:57:47 2024 GMT
notAfter=Feb 10 06:02:47 2034 GMT
kubectl config view --flatten --output 'jsonpath={.users[0].user.client-certificate-data}'| base64 -d | openssl x509 -noout -dates

вивід:

notBefore=Feb 13 05:57:47 2024 GMT
notAfter=Feb 12 06:02:50 2025 GMT

Перевірка допоміжних інструментів kubectl

Деякі допоміжні інструменти kubectl забезпечують легкий доступ до кластерів Kubernetes. Якщо ви використовували такі інструменти та стикаєтеся з проблемами зʼєднання, переконайтеся, що необхідні налаштування все ще присутні.

Перевірте конфігурацію kubectl для отримання інформації про автентифікацію:

kubectl config view

Якщо раніше ви використовували допоміжний інструмент (наприклад, kubectl-oidc-login), переконайтеся, що він все ще встановлений і правильно налаштований.

4.4.2.2 - Конвеєер метрик ресурсів

Для Kubernetes Metrics API пропонує базовий набір метрик для підтримки автоматичного масштабування та подібних випадків використання. Це API робить доступною інформацію про використання ресурсів для вузла та Podʼа, включаючи метрики для CPU та памʼяті. Якщо ви розгортаєте Metrics API у своєму кластері, клієнти API Kubernetes можуть запитувати цю інформацію, і ви можете використовувати механізми контролю доступу Kubernetes для управління дозволами на це.

HorizontalPodAutoscaler (HPA) та VerticalPodAutoscaler (VPA) використовують дані з API метрик для налаштування реплік робочого навантаження та ресурсів для задоволення вимог користувачів.

Ви також можете переглядати метрики ресурсів, використовуючи команду kubectl top.

Схема 1 ілюструє архітектуру конвеєра метрик ресурсів.

flowchart RL subgraph cluster[Кластер] direction RL S[

] A[Сервер-
метрик] subgraph B[Вузли] direction TB D[cAdvisor] --> C[kubelet] E[Середовище
виконання
контейнерів] --> D E1[Середовище
виконання
контейнерів] --> D P[Дані Podʼа] -.- C end L[API-сервер] W[HPA] C ---->|метрики ресурсів
на рівні вузла| A -->|Metrics
API| L --> W end L ---> K[kubectl
top] classDef box fill:#fff,stroke:#000,stroke-width:1px,color:#000; class W,B,P,K,cluster,D,E,E1 box classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000 class S spacewhite classDef k8s fill:#326ce5,stroke:#fff,stroke-width:1px,color:#fff; class A,L,C k8s

Схема 1. Конвеєр метрик ресурсів

Компоненти архітектури, справа наліво на схемі, включають наступне:

  • cAdvisor: Демон для збору, агрегування та викладання метрик контейнера, включених в Kubelet.

  • kubelet: Агент вузла для управління ресурсами контейнера. Метрики ресурсів доступні за допомогою точок доступу API kubelet /metrics/resource та /stats.

  • метрики ресурсів на рівні вузла: API, наданий kubelet для виявлення та отримання підсумкових статистичних даних на рівні вузла, доступних через точку доступу /metrics/resource.

  • сервер метрик: Компонент надбудови кластера, який збирає та агрегує метрики ресурсів, витягнуті з кожного kubelet. Сервер API надає API метрик для використання HPA, VPA та команди kubectl top. Сервер метрик є посиланням на реалізацію Metrics API.

  • Metrics API: API Kubernetes, що підтримує доступ до CPU та памʼяті, використаних для автоматичного масштабування робочого навантаження. Щоб це працювало у вашому кластері, вам потрібен сервер розширення API, який надає API метрик.

Metrics API

СТАН ФУНКЦІОНАЛУ: Kubernetes 1.8 [beta]

Metrics-server реалізує Metrics API. Це API дозволяє отримувати доступ до використання CPU та памʼяті для вузлів та Podʼів у вашому кластері. Його основна роль — надавати метрики використання ресурсів компонентам автомасштабування K8s.

Ось приклад запиту до Metrics API для вузла minikube, обробленого через jq для зручного перегляду:

kubectl get --raw "/apis/metrics.k8s.io/v1beta1/nodes/minikube" | jq '.'

Той же самий виклик API, використовуючи curl:

curl http://localhost:8080/apis/metrics.k8s.io/v1beta1/nodes/minikube

Приклад відповіді:

{
  "kind": "NodeMetrics",
  "apiVersion": "metrics.k8s.io/v1beta1",
  "metadata": {
    "name": "minikube",
    "selfLink": "/apis/metrics.k8s.io/v1beta1/nodes/minikube",
    "creationTimestamp": "2022-01-27T18:48:43Z"
  },
  "timestamp": "2022-01-27T18:48:33Z",
  "window": "30s",
  "usage": {
    "cpu": "487558164n",
    "memory": "732212Ki"
  }
}

Ось приклад запиту до Metrics API для Podʼа kube-scheduler-minikube, що міститься в просторі імен kube-system, оброблений через jq для зручного перегляду:

kubectl get --raw "/apis/metrics.k8s.io/v1beta1/namespaces/kube-system/pods/kube-scheduler-minikube" | jq '.'

Той же самий виклик API, використовуючи curl:

curl http://localhost:8080/apis/metrics.k8s.io/v1beta1/namespaces/kube-system/pods/kube-scheduler-minikube

Приклад відповіді:

{
  "kind": "PodMetrics",
  "apiVersion": "metrics.k8s.io/v1beta1",
  "metadata": {
    "name": "kube-scheduler-minikube",
    "namespace": "kube-system",
    "selfLink": "/apis/metrics.k8s.io/v1beta1/namespaces/kube-system/pods/kube-scheduler-minikube",
    "creationTimestamp": "2022-01-27T19:25:00Z"
  },
  "timestamp": "2022-01-27T19:24:31Z",
  "window": "30s",
  "containers": [
    {
      "name": "kube-scheduler",
      "usage": {
        "cpu": "9559630n",
        "memory": "22244Ki"
      }
    }
  ]
}

Metrics API визначено в репозиторії k8s.io/metrics. Вам потрібно увімкнути шар агрегації API та зареєструвати APIService для API metrics.k8s.io.

Щоб дізнатися більше про Metrics API, див. дизайн API метрик ресурсів, репозиторій metrics-server та API метрик ресурсів.

Вимірювання використання ресурсів

ЦП

Відомості про CPU показуються як середнє значення використання ядра, виміряне в одиницях процесорного часу. Один CPU, у Kubernetes, еквівалентний 1 віртуальному процесору/ядру для хмарних постачальників, і 1 гіперпотоку на процесорах Intel для bare-metal конфігурацій.

Це значення обчислюється шляхом взяття швидкості над кумулятивним лічильником CPU, який надається ядром (як для Linux, так і для Windows ядер). Вікно часу, яке використовується для обчислення CPU, показано у полі window в Metrics API.

Щоб дізнатися більше про те, як Kubernetes розподіляє та вимірює ресурси CPU, див. значення CPU.

Памʼять

Відомості про памʼять показуються як обсяг робочого набору, виміряний в байтах, в момент збору метрики.

У ідеальному світі "робочий набір" — це обсяг памʼяті, що використовується, який не може бути звільнений під час тиску на памʼять. Однак розрахунок робочого набору варіюється залежно від операційної системи хосту і, як правило, інтенсивно використовує евристики для оцінки.

Модель Kubernetes для робочого набору контейнера передбачає, що робочий набір контейнера, що розглядається, підраховується відносно анонімної памʼяті, повʼязаної з цим контейнером. Зазвичай метрика робочого набору також включає деяку кешовану (файлоподібну) памʼять, оскільки операційна система хосту не завжди може повторно використовувати сторінки.

Щоб дізнатися більше про те, як Kubernetes розподіляє та вимірює ресурси памʼяті, див. значення памʼяті.

Metrics Server

Metrics-server витягує метрики ресурсів з kubeletʼів і надає їх в API-серверу Kubernetes через Metrics API для використання HPA та VPA. Ви також можете переглядати ці метрики за допомогою команди kubectl top.

Metrics-server використовує API Kubernetes для відстеження вузлів та Podʼів у вашому кластері. Metrics-server запитує кожний вузол через HTTP, щоб отримати метрики. Metrics-server також створює внутрішнє представлення метаданих про Pod та зберігає кеш стану справності Podʼа. Ця кешована інформація про стан справності Podʼів доступна через розширення API, яке надає metrics-server.

Наприклад, при запиті HPA metrics-server повинен визначити, які Podʼи відповідають селекторам міток у Deployment.

Metrics-server викликає API kubelet для збору метрик з кожного вузла. Залежно від версії metrics-server використовується:

  • Точка доступу ресурсів метрик /metrics/resource у версії v0.6.0+ або
  • Точка доступу Summary API /stats/summary у старших версіях

Що далі

Щоб дізнатися більше про metrics-server, перегляньте репозиторій metrics-server.

Також ви можете перевірити наступне:

Щоб дізнатися про те, як kubelet надає метрики вузла, і як ви можете отримати до них доступ через API Kubernetes, прочитайте Дані метрик вузлів.

4.4.2.3 - Інструменти для моніторингу ресурсів

Щоб масштабувати застосунок і надавати надійні послуги, вам потрібно розуміти, як застосунок працює при його розгортанні. Ви можете аналізувати продуктивність застосунку в кластері Kubernetes, перевіряючи контейнери, Podʼи, Serviceʼи та загальні характеристики кластера. Kubernetes надає докладну інформацію про використання ресурсів застосункам на кожному з цих рівнів. Ця інформація дозволяє оцінити продуктивність вашого застосунку та визначити місця, де можна видалити перешкоди, щоб покращити загальну продуктивність.

У Kubernetes моніторинг застосунків не залежить від єдиного рішення для моніторингу. На нових кластерах ви можете використовувати конвеєри метрик ресурсів або повні метрики, щоб збирати статистику для моніторингу.

Конвеєр метрик ресурсів

Конвеєр метрик ресурсів надає обмежений набір метрик, повʼязаних з компонентами кластера, такими як контролер Горизонтального автомасштабування Podʼів та утилітою kubectl top. Ці метрики збираються легким, тимчасовим, розташованим в памʼяті metrics-server та експонується через API metrics.k8s.io.

Metrics-server виявляє всі вузли в кластері та запитує kubelet кожного вузла для визначення використання центрального процесора та памʼяті. Kubelet виступає як міст між майстром Kubernetes та вузлами, керуючи Podʼами та контейнерами, що працюють на машині. Kubelet перетворює кожний Pod у його складові контейнери та отримує статистику використання кожного контейнера через інтерфейс середовища виконання контейнерів. Якщо ви використовуєте середовище виконання контейнерів, яке використовує Linux cgroups та простори імен для роботи контейнерів, і середовище виконання контейнерів не публікує статистику використання, тоді kubelet може отримувати ці статистичні дані безпосередньо (використовуючи код з cAdvisor). Незалежно від того, як надходять ці статистичні дані, kubelet після цього використовує агреговану статистику використання ресурсів Podʼів через metrics-server Resource Metrics API. Цей API надається за адресою /metrics/resource/v1beta1 на автентифікованих та портах kublet, доступних тільки для читання.

Конвеєр повних метрик

Конвеєр повних метрик дає вам доступ до більш розширених метрик. Kubernetes може відповідати на ці метрики, автоматично масштабуючи або адаптуючи кластер на основі його поточного стану за допомогою механізмів, таких як Горизонтальне автомасштабування Podʼів. Конвеєр моніторингу витягує метрики з kubelet та експонує їх в Kubernetes через адаптер, реалізуючи API custom.metrics.k8s.io або external.metrics.k8s.io.

Kubernetes розроблено для роботи з OpenMetrics, який є одним із проєктів моніторингу CNCF, побудованим на основі формату експонування метрик Prometheus та розширюючи його майже у 100% сумісний спосіб.

Якщо ви переглянете CNCF Landscape, ви побачите ряд проєктів моніторингу, які можуть працювати з Kubernetes, витягуючи дані метрик та використовуючи їх, щоб допомоги вам спостерігати за вашим кластером. Вам слід вибрати інструмент або інструменти, які відповідають вашим потребам. Ландшафт CNCF для спостереження та аналізу включає комбінацію вільного програмного забезпечення, платного програмного забезпечення-як-сервісу та інших комерційних продуктів.

При проєктуванні та реалізації конвеєра повних метрик ви можете зробити ці моніторингові дані доступні зворотньо у Kubernetes. Наприклад, HorizontalPodAutoscaler може використовувати оброблені метрики для розрахунку кількості Podʼів, які потрібно запустити як складову вашого навантаження.

Інтеграція конвеєра повних у вашу реалізацію Kubernetes знаходиться поза межами документації Kubernetes через дуже широкий спектр можливих рішень.

Вибір моніторингової платформи значно залежить від ваших потреб, бюджету та технічних ресурсів. Kubernetes не надає жодних переваг щодо конкретних конвеєрів метрик; існує багато варіантів. Ваша система моніторингу повинна бути здатна обробляти стандарт передачі метрик OpenMetrics і має бути обрана так, щоб найкраще вписуватися в вашу загальну концепцію та розгортання інфраструктури.

Що далі

Дізнайтеся про додаткові інструменти для налагодження, включаючи:

4.4.2.4 - Відстеження стану вузлів

Node Problem Detector — це служба для моніторингу та звітування про стан вузла. Ви можете запустити Node Problem Detector як DaemonSet або окремий демон. Node Problem Detector збирає інформацію про проблеми вузла з різних демонів і повідомляє їх на сервер API як стан вузла або як події.

Для отримання інформації щодо встановлення та використання Node Problem Detector, див. Документацію проєкту Node Problem Detector.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Обмеження

Увімкнення Node Problem Detector

Деякі хмарні постачальники увімкнуть Node Problem Detector як надбудову. Ви також можете увімкнути Node Problem Detector за допомогою kubectl або створити Addon DaemonSet.

Використання kubectl для увімкнення Node Problem Detector

kubectl надає найбільш гнучке керування Node Problem Detector. Ви можете перезаписати типову конфігурацію, щоб вона відповідала вашому середовищу або виявляла спеціалізовані проблеми вузла. Наприклад:

  1. Створіть конфігурацію Node Problem Detector, аналогічну node-problem-detector.yaml:

    apiVersion: apps/v1
    kind: DaemonSet
    metadata:
      name: node-problem-detector-v0.1
      namespace: kube-system
      labels:
        k8s-app: node-problem-detector
        version: v0.1
        kubernetes.io/cluster-service: "true"
    spec:
      selector:
        matchLabels:
          k8s-app: node-problem-detector  
          version: v0.1
          kubernetes.io/cluster-service: "true"
      template:
        metadata:
          labels:
            k8s-app: node-problem-detector
            version: v0.1
            kubernetes.io/cluster-service: "true"
        spec:
          hostNetwork: true
          containers:
          - name: node-problem-detector
            image: registry.k8s.io/node-problem-detector:v0.1
            securityContext:
              privileged: true
            resources:
              limits:
                cpu: "200m"
                memory: "100Mi"
              requests:
                cpu: "20m"
                memory: "20Mi"
            volumeMounts:
            - name: log
              mountPath: /log
              readOnly: true
          volumes:
          - name: log
            hostPath:
              path: /var/log/
  2. Запустіть Node Problem Detector за допомогою kubectl:

    kubectl apply -f https://k8s.io/examples/debug/node-problem-detector.yaml
    

Використання Podʼа надбудови для увімкнення Node Problem Detector

Якщо ви використовуєте власне рішення для ініціалізації кластера та не потребуєте перезапису типової конфігурації, ви можете скористатися Podʼом надбудови, щоб автоматизувати розгортання.

Створіть node-problem-detector.yaml та збережіть конфігурацію в теці Podʼа надбудови /etc/kubernetes/addons/node-problem-detector на вузлі панелі управління.

Перезапис конфігурації

Типова конфігурація вбудована під час збирання Docker-образу Node Problem Detector.

Однак ви можете використовувати ConfigMap для перезапису конфігурації:

  1. Змініть файли конфігурації в config/.

  2. Створіть ConfigMap node-problem-detector-config:

    kubectl create configmap node-problem-detector-config --from-file=config/
    
  3. Змініть node-problem-detector.yaml, щоб використовувати ConfigMap:

    apiVersion: apps/v1
    kind: DaemonSet
    metadata:
      name: node-problem-detector-v0.1
      namespace: kube-system
      labels:
        k8s-app: node-problem-detector
        version: v0.1
        kubernetes.io/cluster-service: "true"
    spec:
      selector:
        matchLabels:
          k8s-app: node-problem-detector  
          version: v0.1
          kubernetes.io/cluster-service: "true"
      template:
        metadata:
          labels:
            k8s-app: node-problem-detector
            version: v0.1
            kubernetes.io/cluster-service: "true"
        spec:
          hostNetwork: true
          containers:
          - name: node-problem-detector
            image: registry.k8s.io/node-problem-detector:v0.1
            securityContext:
              privileged: true
            resources:
              limits:
                cpu: "200m"
                memory: "100Mi"
              requests:
                cpu: "20m"
                memory: "20Mi"
            volumeMounts:
            - name: log
              mountPath: /log
              readOnly: true
            - name: config # Overwrite the config/ directory with ConfigMap volume
              mountPath: /config
              readOnly: true
          volumes:
          - name: log
            hostPath:
              path: /var/log/
          - name: config # Define ConfigMap volume
            configMap:
              name: node-problem-detector-config
  4. Перестворіть Node Problem Detector з новим файлом конфігурації:

    # Якщо у вас вже працює Node Problem Detector, видаліть перед перстворенням
    kubectl delete -f https://k8s.io/examples/debug/node-problem-detector.yaml
    kubectl apply -f https://k8s.io/examples/debug/node-problem-detector-configmap.yaml
    

Перезапис конфігурації не підтримується, якщо Node Problem Detector працює як надбудова кластера. Менеджер надбудов не підтримує ConfigMap.

Демони проблем

Демон проблем — це піддемон Node Problem Detector. Він моніторить певні види проблем вузла та повідомляє про них Node Problem Detector. Існує кілька типів підтримуваних демонів проблем.

  • Тип демона SystemLogMonitor моніторить системні логи та повідомляє про проблеми та метрики згідно з попередньо визначеними правилами. Ви можете настроїти конфігурації для різних джерел логів таких як filelog, kmsg, kernel, abrt, та systemd.

  • Тип демона SystemStatsMonitor збирає різноманітні статистичні дані системи, повʼязані зі справністю, як метрики. Ви можете настроїти його поведінку, оновивши його файл конфігурації.

  • Тип демона CustomPluginMonitor викликає та перевіряє різні проблеми вузла, запускаючи сценарії, визначені користувачем. Ви можете використовувати різні власні втулки для моніторингу різних проблем і настроювати поведінку демона, оновивши файл конфігурації.

  • Тип демона HealthChecker перевіряє стан kubelet та контейнерного середовища на вузлі.

Додавання підтримки для іншого формату логів

Монітор системного логу наразі підтримує файлові логи, journald та kmsg. Додаткові джерела можна додати, реалізувавши новий спостерігач за логами.

Додавання власних втулків моніторингу

Ви можете розширити Node Problem Detector для виконання будь-яких сценаріїв моніторингу, написаних будь-якою мовою програмування, розробивши власний втулок. Сценарії моніторингу повинні відповідати протоколу втулка щодо коду виходу та стандартного виводу. Для отримання додаткової інформації див. пропозицію інтерфейсу втулка.

Експортер

Експортер повідомляє про проблеми та/або метрики вузлів до певних бекендів. Підтримуються наступні експортери:

  • Експортер Kubernetes: цей експортер повідомляє про проблеми вузлів на сервер API Kubernetes. Тимчасові проблеми повідомляються як Події, а постійні проблеми — як Стан вузла.

  • Експортер Prometheus: цей експортер локально повідомляє про проблеми вузлів та метрики у форматі Prometheus (або OpenMetrics). Ви можете вказати IP-адресу та порт для експортера, використовуючи аргументи командного рядка.

  • Експортер Stackdriver: цей експортер повідомляє про проблеми вузлів та метрики в службу моніторингу Stackdriver. Поведінку експорту можна налаштувати, використовуючи файл конфігурації.

Рекомендації та обмеження

Рекомендується запускати Node Problem Detector в вашому кластері для моніторингу стану вузлів. При запуску Node Problem Detector можна очікувати додаткове навантаження ресурсів на кожному вузлі. Зазвичай це прийнятно, оскільки:

  • Лог ядра росте відносно повільно.
  • Для Node Problem Detector встановлено обмеження ресурсів.
  • Навіть при великому навантаженні використання ресурсів прийнятне. Докладніше див. результати бенчмарків Node Problem Detector.

4.4.2.5 - Налагодження вузлів Kubernetes за допомогою crictl

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.11 [stable]

crictl — це інтерфейс командного рядка для сумісних з CRI контейнерних середовищ. Ви можете використовувати його для огляду та налагодження контейнерних середовищ та застосунків на вузлі Kubernetes. crictl та його вихідний код розміщені у репозиторії cri-tools.

Перш ніж ви розпочнете

Для роботи crictl потрібна операційна система Linux з CRI середовищем.

Встановлення crictl

Ви можете завантажити архів crictl зі сторінки релізів у репозиторії cri-tools release page, для різних архітектур. Завантажте версію, яка відповідає вашій версії Kubernetes. Розпакуйте її та перемістіть у розташування у вашому системному шляху, наприклад, /usr/local/bin/.

Використання

Команда crictl має кілька підкоманд та прапорців для використання. Використовуйте crictl help або crictl <підкоманда> help для отримання більш детальної інформації.

Ви можете встановити точку доступу для crictl, виконавши одну з наступних дій:

  • Встановіть прапорці --runtime-endpoint та --image-endpoint.
  • Встановіть змінні середовища CONTAINER_RUNTIME_ENDPOINT та IMAGE_SERVICE_ENDPOINT.
  • Встановіть точку доступу в файлі конфігурації /etc/crictl.yaml. Щоб вказати інший файл, використовуйте прапорець --config=ШЛЯХ_ДО_ФАЙЛУ під час запуску crictl.

Ви також можете вказати значення тайм-ауту при підключенні до сервера та увімкнути або вимкнути налагодження, вказавши значення timeout або debug в файлі конфігурації або використовуючи прапорці командного рядка --timeout та --debug.

Щоб переглянути або змінити поточну конфігурацію, перегляньте або відредагуйте вміст /etc/crictl.yaml. Наприклад, конфігурація при використанні виконавчого середовища containerd буде схожа на цю:

runtime-endpoint: unix:///var/run/containerd/containerd.sock
image-endpoint: unix:///var/run/containerd/containerd.sock
timeout: 10
debug: true

Щоб дізнатися більше про crictl, зверніться до документації crictl.

Приклади команд crictl

Нижче наведено деякі приклади команд crictl та їх вивід.

Отримання переліку Podʼів

Вивести перелік усіх Podʼів:

crictl pods

Вихідний результат схожий на такий:

POD ID              CREATED              STATE               NAME                         NAMESPACE           ATTEMPT
926f1b5a1d33a       About a minute ago   Ready               sh-84d7dcf559-4r2gq          default             0
4dccb216c4adb       About a minute ago   Ready               nginx-65899c769f-wv2gp       default             0
a86316e96fa89       17 hours ago         Ready               kube-proxy-gblk4             kube-system         0
919630b8f81f1       17 hours ago         Ready               nvidia-device-plugin-zgbbv   kube-system         0

Список Podʼів за назвою:

crictl pods --name nginx-65899c769f-wv2gp

Вихідний результат схожий на такий:

POD ID              CREATED             STATE               NAME                     NAMESPACE           ATTEMPT
4dccb216c4adb       2 minutes ago       Ready               nginx-65899c769f-wv2gp   default             0

Список Podʼів за мітками:

crictl pods --label run=nginx

Вихідний результат схожий на такий:

POD ID              CREATED             STATE               NAME                     NAMESPACE           ATTEMPT
4dccb216c4adb       2 minutes ago       Ready               nginx-65899c769f-wv2gp   default             0

Отримання переліку образів

Вивести всі образи:

crictl images

Вихідний результат схожий на такий:

IMAGE                                     TAG                 IMAGE ID            SIZE
busybox                                   latest              8c811b4aec35f       1.15MB
k8s.gcr.io/hyperkube-amd64                v1.10.3             e179bbfe5d238       665MB
k8s.gcr.io/pause                          3.1                 da86e6ba6ca19       742kB
nginx                                     latest              cd5239a0906a6       109MB

Список образів за репозиторієм:

crictl images nginx

Вихідний результат схожий на такий:

IMAGE               TAG                 IMAGE ID            SIZE
nginx               latest              cd5239a0906a6       109MB

Вивести лише ідентифікатори образів:

crictl images -q

Вихідний результат схожий на такий:

sha256:8c811b4aec35f259572d0f79207bc0678df4c736eeec50bc9fec37ed936a472a
sha256:e179bbfe5d238de6069f3b03fccbecc3fb4f2019af741bfff1233c4d7b2970c5
sha256:da86e6ba6ca197bf6bc5e9d900febd906b133eaa4750e6bed647b0fbe50ed43e
sha256:cd5239a0906a6ccf0562354852fae04bc5b52d72a2aff9a871ddb6bd57553569

Отримання переліку контейнерів

Вивести всі контейнери:

crictl ps -a

Вихідний результат схожий на такий:

CONTAINER ID        IMAGE                                                                                                             CREATED             STATE               NAME                       ATTEMPT
1f73f2d81bf98       busybox@sha256:141c253bc4c3fd0a201d32dc1f493bcf3fff003b6df416dea4f41046e0f37d47                                   7 хвилин тому       Running             sh                         1
9c5951df22c78       busybox@sha256:141c253bc4c3fd0a201d32dc1f493bcf3fff003b6df416dea4f41046e0f37d47                                   8 хвилин тому       Exited              sh                         0
87d3992f84f74       nginx@sha256:d0a8828cccb73397acb0073bf34f4d7d8aa315263f1e7806bf8c55d8ac139d5f                                     8 хвилин тому       Running             nginx                      0
1941fb4da154f       k8s-gcrio.azureedge.net/hyperkube-amd64@sha256:00d814b1f7763f4ab5be80c58e98140dfc69df107f253d7fdd714b30a714260a   18 годин тому        Running             kube-proxy                 0

Вивести працюючі контейнери:

crictl ps

Вихідний результат схожий на такий:

CONTAINER ID        IMAGE                                                                                                             CREATED             STATE               NAME                       ATTEMPT
1f73f2d81bf98       busybox@sha256:141c253bc4c3fd0a201d32dc1f493bcf3fff003b6df416dea4f41046e0f37d47                                   6 хвилин тому       Running             sh                         1
87d3992f84f74       nginx@sha256:d0a8828cccb73397acb0073bf34f4d7d8aa315263f1e7806bf8c55d8ac139d5f                                     7 хвилин тому       Running             nginx                      0
1941fb4da154f       k8s-gcrio.azureedge.net/hyperkube-amd64@sha256:00d814b1f7763f4ab5be80c58e98140dfc69df107f253d7fdd714b30a714260a   17 годин тому        Running             kube-proxy                 0

Виконання команди у працюючому контейнері

crictl exec -i -t 1f73f2d81bf98 ls

Вихідний результат схожий на такий:

bin   dev   etc   home  proc  root  sys   tmp   usr   var

Отримання логів контейнерів

Отримати всі логи контейнера:

crictl logs 87d3992f84f74

Вихідний результат схожий на такий:

10.240.0.96 - - [06/Jun/2018:02:45:49 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.47.0" "-"
10.240.0.96 - - [06/Jun/2018:02:45:50 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.47.0" "-"
10.240.0.96 - - [06/Jun/2018:02:45:51 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.47.0" "-"

Отримати лише останні N рядків логів:

crictl logs --tail=1 87d3992f84f74

Вихідний результат схожий на такий:

10.240.0.96 - - [06/Jun/2018:02:45:51 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.47.0" "-"

Що далі

4.4.2.6 - Аудит

Аудит Kubernetes забезпечує безпеку шляхом створення хронологічного набору записів, які документують послідовність дій у кластері. Кластер аудитує дії, що генеруються користувачами, застосунками, які використовують API Kubernetes, а також самою панеллю управління.

Аудит дозволяє адміністраторам кластера відповісти на такі питання:

  • що сталося?
  • коли це сталося?
  • хто це ініціював?
  • на чому це сталося?
  • де це було помічено?
  • звідки це було ініційовано?
  • куди це направлялося?

Записи аудиту починають свій життєвий цикл всередині компонента kube-apiserver. Кожен запит на кожному етапі його виконання генерує подію аудиту, яка потім передається до попередньої обробки відповідно до певної політики та записується в бекенд. Політика визначає, що буде записано, а бекенд зберігає записи. Поточні реалізації бекендів включають файли логів та вебхуки.

Кожний запит може бути записаний з асоційованим stage. Визначені етапи:

  • RequestReceived — Етап для подій, що генеруються, як тільки обробник аудиту отримує запит, і до того, як він передає його вниз по ланцюжку обробників.
  • ResponseStarted — Після надсилання заголовків відповіді, але перед відправленням тіла відповіді. Цей етап генерується лише для тривалих запитів (наприклад, watch).
  • ResponseComplete — Тіло відповіді завершено і більше байтів не буде відправлено.
  • Panic — Події, що генеруються при виникненні паніки.

Функція логування аудиту збільшує витрати памʼяті сервера API, оскільки для кожного запиту зберігається певний контекст, необхідний для аудитування. Витрати памʼяті залежать від конфігурації логування аудиту.

Політика аудиту

Політика аудиту визначає правила того, які події повинні бути записані та які дані вони повинні містити. Структура обʼєкта політики аудиту визначена в групі API audit.k8s.io. Коли подія обробляється, її порівнюють зі списком прав по черзі. Перший збіг прав встановлює рівень аудиту події. Визначені рівні аудиту:

  • None — не записувати події, які відповідають цьому правилу.
  • Metadata — записувати метадані запиту (користувач, часова відмітка, ресурс, дія тощо), але не тіло запиту чи відповіді.
  • Request — записувати метадані події та тіло запиту, але не тіло відповіді. Це не застосовується до запитів на ресурси.
  • RequestResponse — записувати метадані події, тіло запиту та відповіді. Це не застосовується до запитів на ресурси.

Ви можете передати файл з політикою до kube-apiserver, використовуючи прапорець --audit-policy-file. Якщо прапорець пропущено, жодні події не записуються. Зверніть увагу, що поле rules обовʼязково повинно бути вказано у файлі політики аудиту. Політика з нульовою кількістю (0) прав вважається неприпустимою.

Нижче наведено приклад файлу політики аудиту:

apiVersion: audit.k8s.io/v1 # Це обовʼязково.
kind: Policy
# Не генерувати події аудиту для всіх запитів на етапі RequestReceived.
omitStages:
  - "RequestReceived"
rules:
  # Логувати зміни у вузлах на рівні RequestResponse
  - level: RequestResponse
    resources:
    - group: ""
      # Ресурс "pods" не відповідає запитам на будь-який підресурс вузлів,
      # що відповідає політиці RBAC.
      resources: ["pods"]
  # Логувати "pods/log", "pods/status" на рівні Metadata
  - level: Metadata
    resources:
    - group: ""
      resources: ["pods/log", "pods/status"]

  # Не логувати запити на configmap під назвою "controller-leader"
  - level: None
    resources:
    - group: ""
      resources: ["configmaps"]
      resourceNames: ["controller-leader"]

  # Не логувати watch-запити "system:kube-proxy" на endpoints або services
  - level: None
    users: ["system:kube-proxy"]
    verbs: ["watch"]
    resources:
    - group: "" # Основна група API
      resources: ["endpoints", "services"]

  # Не логувати автентифіковані запити до певних URL-шляхів, що не є ресурсами.
  - level: None
    userGroups: ["system:authenticated"]
    nonResourceURLs:
    - "/api*" # Зіставлення з шаблоном.
    - "/version"

  # Логувати тіло запиту на зміни configmap у kube-system.
  - level: Request
    resources:
    - group: "" # Основна група API
      resources: ["configmaps"]
    # Це правило застосовується тільки до ресурсів в просторі імен "kube-system".
    # Порожній рядок "" можна використовувати для вибору ресурсів без простору імен.
    namespaces: ["kube-system"]

  # Логувати зміни configmap і secret у всіх інших просторах імен на рівні Metadata.
  - level: Metadata
    resources:
    - group: "" # Основна група API
      resources: ["secrets", "configmaps"]

  # Логувати всі інші ресурси в основній і розширюваній групах на рівні Request.
  - level: Request
    resources:
    - group: "" # Основна група API
    - group: "extensions" # Версія групи НЕ повинна включатися.

  # Загальне правило для логування всіх інших запитів на рівні Metadata.
  - level: Metadata
    # Довгострокові запити, такі як watches, які підпадають під це правило,
    # не генерують подію аудиту на етапі RequestReceived.
    omitStages:
      - "RequestReceived"

Ви можете використовувати мінімальну політику аудиту для логування всіх запитів на рівні Metadata:

# Записати всі запити на рівні Metadata.
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: Metadata

Якщо ви створюєте власний профіль аудиту, ви можете скористатися профілем аудиту для Google Container-Optimized OS як вихідною точкою. Ви можете перевірити сценарій configure-helper.sh, який генерує файл політики аудиту. Більшість файлу політики аудиту можна побачити, дивлячись безпосередньо на цей сценарій.

Ви також можете звернутися до посилання на конфігурацію Policy для отримання деталей про визначені поля.

Бекенди аудиту

Події аудиту зберігаються в зовнішньому сховищі за допомогою бекендів аудиту. Стандартно kube-apiserver надає два бекенди:

  • Файловий бекенд, який записує події у файлову систему.
  • Бекенд Webhook, який відправляє події на зовнішній HTTP API.

У всіх випадках події аудиту слідують структурі, визначеній API Kubernetes в групі API audit.k8s.io.

Бекенд логів

Бекенд логів записує події аудиту у файл у форматі JSONlines. Ви можете налаштувати бекенд логів за допомогою наступних прапорців kube-apiserver:

  • --audit-log-path вказує шлях до файлу логу, який бекенд логів використовує для запису подій аудиту. Відсутність цього прапорця вимикає бекенд логів; - означає стандартний вивід
  • --audit-log-maxage визначає максимальну кількість днів для зберігання старих файлів логів аудиту
  • --audit-log-maxbackup визначає максимальну кількість файлів логів аудиту для зберігання
  • --audit-log-maxsize визначає максимальний розмір в мегабайтах файлу логів аудиту до його ротації

Якщо панель управління вашого кластера працює з kube-apiserver як з Pod, не забудьте змонтувати hostPath до місця розташування файлу політики та файлу логів, щоб записи аудиту були збережені. Наприклад:

  - --audit-policy-file=/etc/kubernetes/audit-policy.yaml
  - --audit-log-path=/var/log/kubernetes/audit/audit.log

потім змонтуйте томи:

...
volumeMounts:
  - mountPath: /etc/kubernetes/audit-policy.yaml
    name: audit
    readOnly: true
  - mountPath: /var/log/kubernetes/audit/
    name: audit-log
    readOnly: false

і нарешті налаштуйте hostPath:

...
volumes:
- name: audit
  hostPath:
    path: /etc/kubernetes/audit-policy.yaml
    type: File

- name: audit-log
  hostPath:
    path: /var/log/kubernetes/audit/
    type: DirectoryOrCreate

Бекенд Webhook

Бекенд аудиту webhook надсилає події аудиту до віддаленого веб-API, яке вважається формою Kubernetes API, включаючи засоби автентифікації. Ви можете налаштувати бекенд webhook за допомогою наступних прапорців kube-apiserver:

  • --audit-webhook-config-file вказує шлях до файлу з конфігурацією webhook. Конфігурація webhook фактично є спеціалізованим kubeconfig.
  • --audit-webhook-initial-backoff вказує час очікування після першого невдалого запиту перед повторною спробою. Наступні запити повторюються з експоненційною затримкою.

Файл конфігурації webhook використовує формат kubeconfig для вказування віддаленої адреси служби та облікових даних, які використовуються для підключення до неї.

Пакетна обробка подій

Обидва типи бекенд систем, як логів, так і webhook, підтримують пакетну обробку. Використаємо webhook як приклад, ось перелік доступних прапорців. Щоб отримати такий же прапорець для логів, замініть webhook на log у назві прапорця. Стандартно пакетна обробка увімкнена для webhook і вимкнена для log. Так само, типово, обмеження пропускної здатності увімкнено в webhook і вимкнене в log.

  • --audit-webhook-mode визначає стратегію буферизації. Одна з наступних:
    • batch — буферизувати події та асинхронно обробляти їх пакетами. Це стандартне значення.
    • blocking — блокувати відповіді сервера API на обробці кожної окремої події.
    • blocking-strict — те саме, що й blocking, але коли відбувається збій під час логування аудиту на етапі RequestReceived, весь запит до kube-apiserver зазнає збою.

Наступні прапорці використовуються тільки в режимі batch:

  • --audit-webhook-batch-buffer-size визначає кількість подій для буферизації перед пакетною обробкою. Якщо швидкість надходження подій переповнює буфер, події відкидаються.
  • --audit-webhook-batch-max-size визначає максимальну кількість подій в одному пакеті.
  • --audit-webhook-batch-max-wait визначає максимальний час очікування перед безумовною буферизацією подій у черзі.
  • --audit-webhook-batch-throttle-qps визначає максимальну середню кількість пакетів, що генеруються за секунду.
  • --audit-webhook-batch-throttle-burst визначає максимальну кількість пакетів, які генеруються в той же момент, якщо дозволений QPS раніше не використовувався повністю.

Налаштування параметрів

Параметри повинні бути встановлені з урахуванням навантаження на API-сервер.

Наприклад, якщо kube-apiserver отримує 100 запитів кожну секунду, і кожен запит проходить аудит лише на етапах ResponseStarted та ResponseComplete, вам слід розрахувати приблизно 200 подій аудиту, які генеруються кожну секунду. Припускаючи, що в пакеті може бути до 100 подій, вам слід встановити рівень обмеження принаймні у 2 запити на секунду. Припускаючи, що система може потребувати до 5 секунд для запису подій, вам слід встановити розмір буфера для зберігання подій протягом до 5 секунд; це означає: 10 пакетів або 1000 подій.

Проте в більшості випадків стандартні значення параметрів повинні бути достатніми, і вам не потрібно хвилюватися про їх ручне встановлення. Ви можете переглянути наступні метрики Prometheus, які експонує kube-apiserver, а також логи, щоб контролювати стан підсистеми аудиту.

  • Метрика apiserver_audit_event_total містить загальну кількість експортованих подій аудиту.
  • Метрика apiserver_audit_error_total містить загальну кількість подій, які були втрачені через помилку під час експортування.

Обмеження розміру запису в лозі

Обидва бекенди і логів, і webhook підтримують обмеження розміру подій, які записуються. Наприклад, ось список прапорців, доступних для бекенду логів:

  • audit-log-truncate-enabled визначає, чи ввімкнене обрізання подій та пакетів.
  • audit-log-truncate-max-batch-size максимальний розмір у байтах пакета, який надсилається до бекенду.
  • audit-log-truncate-max-event-size максимальний розмір у байтах аудитивної події, яка надсилається до бекенду.

Типово обрізання вимкнено як у webhook, так і у log. Адміністратор кластера повинен встановити audit-log-truncate-enabled або audit-webhook-truncate-enabled, щоб увімкнути цю функцію.

Що далі

4.4.2.7 - Налагодження вузлів Kubernetes за допомогою kubectl

Ця сторінка показує, як налагоджувати вузол на кластері Kubernetes за допомогою команди kubectl debug.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Версія вашого Kubernetes сервера має бути не старішою ніж 1.2. Для перевірки версії введіть kubectl version.

Вам потрібно мати дозвіл на створення Podʼів та призначення їх новим Вузлам. Також вам потрібно мати дозвіл на створення Podʼів, які мають доступ до файлових систем з хосту.

Налагодження вузла за допомогою kubectl debug node

Використовуйте команду kubectl debug node, щоб розмістити Pod на Вузлі, який ви хочете налагодити. Ця команда корисна в сценаріях, коли ви не можете отримати доступ до свого Вузла за допомогою зʼєднання SSH. Після створення Podʼа, відкривається інтерактивний інтерфейс оболонки на Вузлі. Щоб створити інтерактивну оболонку на Вузлі з назвою “mynode”, виконайте:

kubectl debug node/mynode -it --image=ubuntu
Creating debugging pod node-debugger-mynode-pdx84 with container debugger on node mynode.
If you don't see a command prompt, try pressing enter.
root@mynode:/#

Команда налагоджування допомагає збирати інформацію та розвʼязувати проблеми. Команди, які ви можете використовувати, включають ip, ifconfig, nc, ping, ps тощо. Ви також можете встановити інші інструменти, такі як mtr, tcpdump та curl, з відповідного менеджера пакунків.

Pod налагодження може отримувати доступ до кореневої файлової системи Вузла, підключеної за адресою /host в Podʼі. Якщо ви використовуєте kubelet у просторі імен файлової системи, Pod налагодження бачить корінь для цього простору імен, а не всього Вузла. Для типового вузла Linux ви можете переглянути наступні шляхи для пошуку відповідних логів:

/host/var/log/kubelet.log
Логи kubelet, який відповідає за запуск контейнерів на вузлі.
/host/var/log/kube-proxy.log
Логи kube-proxy, який відповідає за направлення трафіку на точки доступу Service.
/host/var/log/containerd.log
Логи процесу containerd, який працює на вузлі.
/host/var/log/syslog
Показує загальні повідомлення та інформацію щодо системи.
/host/var/log/kern.log
Показує логи ядра.

При створенні сеансу налагодження на Вузлі майте на увазі, що:

  • kubectl debug автоматично генерує імʼя нового контейнера на основі імені вузла.
  • Коренева файлова система Вузла буде змонтована за адресою /host.
  • Хоча контейнер працює у просторі імен IPC, мережі та PID хосту, Pod не є привілейованим. Це означає, що читання деякої інформації про процес може бути неможливим, оскільки доступ до цієї інформації мають тільки суперкористувачі. Наприклад, chroot /host буде невдалим. Якщо вам потрібен привілейований контейнер, створіть його вручну або використовуйте прапорець --profile=sysadmin.
  • Застосовуючи профілі налагодження, ви можете встановити конкретні властивості, такі як securityContext до Podʼу налагодження.

Очищення

Коли ви закінчите використання Podʼа налагодження, видаліть його:

kubectl get pods
NAME                          READY   STATUS       RESTARTS   AGE
node-debugger-mynode-pdx84    0/1     Completed    0          8m1s
# Змініть імʼя контейнера відповідно
kubectl delete pod node-debugger-mynode-pdx84 --now
pod "node-debugger-mynode-pdx84" deleted

4.4.2.8 - Розробка та налагодження сервісів локально за допомогою telepresence

Зазвичай застосунки Kubernetes складаються з кількох окремих сервісів, кожен з яких працює у своєму власному контейнері. Розробка та налагодження цих сервісів на віддаленому кластері Kubernetes може бути незручною, оскільки ви змушені отримати оболонку в робочому контейнері для запуску інструментів налагодження.

telepresence — це інструмент, який полегшує процес розробки та налагодження сервісів локально, прокидаючи проксі для сервісу на віддаленому кластері Kubernetes. Використання telepresence дозволяє використовувати власні інструменти, такі як налагоджувач та IDE, для локального сервісу та забезпечує повний доступ до ConfigMap, Secret та Service, що працюють на віддаленому кластері.

У цьому документі описано використання telepresence для розробки та налагодження сервісів локально, які працюють на віддаленому кластері.

Перш ніж ви розпочнете

  • Встановлений кластер Kubernetes
  • Налаштований kubectl для звʼязку з кластером
  • Telepresence вже встановлено

Підʼєднання вашого локального компʼютера до віддаленого кластера Kubernetes

Після встановлення telepresence запустіть telepresence connect, щоб запустити його Демона та підʼєднати ваш робочий компʼютер до кластера.

$ telepresence connect

Launching Telepresence Daemon
...
Connected to context default (https://<cluster public IP>)

Ви можете використовувати команду curl для отримання доступу до сервісів за синтаксисом Kubernetes, наприклад, curl -ik https://kubernetes.default.

Розробка або налагодження наявного сервісу

При розробці застосунку у Kubernetes ви зазвичай програмуєте або налагоджувати один сервіс. Цей сервіс може потребувати доступу до інших сервісів для тестування та налагодження. Один із варіантів — використання конвеєра постійного розгортання (continuous deployment pipeline), але навіть найшвидший конвеєр розгортання додає затримку в цикл програмування або налагодження.

Використовуйте команду telepresence intercept $SERVICE_NAME --port $LOCAL_PORT:$REMOTE_PORT для створення "перехоплення" для перенаправлення трафіку віддаленого сервісу.

Де:

  • $SERVICE_NAME — це назва вашого локального сервісу
  • $LOCAL_PORT — це порт, на якому працює ваш сервіс на вашому локальному робочому місці
  • $REMOTE_PORT — це порт, на який ваш сервіс слухає в кластері

Виконавши цю команду, Telepresence каже перенаправляти віддалений трафік на ваш локальний сервіс замість сервісу в віддаленому кластері Kubernetes. Вносьте зміни до вихідного коду вашого сервісу локально, зберігайте та переглядайте відповідні зміни, коли ви отримуєте доступ до вашого віддаленого застосунку, ефект буде відразу. Ви також можете запустити ваш локальний сервіс, використовуючи налагоджувач або будь-який інший локальний інструмент розробки.

Як працює Telepresence?

Telepresence встановлює агента перенаправлення трафіку поряд із контейнером вашого наявного застосунку, який працює в віддаленому кластері. Він перехоплює всі запити на трафік, що надходять до Podʼа, і замість того, щоб пересилати це до застосунку у віддаленому кластері, він маршрутизує весь трафік (коли ви створюєте глобальне перехоплення або підмножину трафіку (коли ви створюєте персональне перехоплення) до вашого локального середовища розробки.

Що далі

Якщо вас цікавить практичний посібник, перегляньте ось цей посібник, в якому покроково описано розробку програми Guestbook локально на Google Kubernetes Engine.

Також читання відвідайте вебсайт Telepresence.

4.4.2.9 - Поради щодо налагодження Windows

Розвʼязання проблем на рівні вузла

  1. Мої Podʼи застрягли на "Container Creating" або постійно перезавантажуються.

    Переконайтеся, що ваш образ pause відповідає версії вашої операційної системи Windows. Див. Контейнер pause для перегляду останнього/рекомендованого образу pause та/або отримання додаткової інформації.

  2. Мої Podʼи показують статус як ErrImgPull або ImagePullBackOff.

    Переконайтеся, що ваш Pod планується на сумісний вузол Windows.

    Додаткову інформацію про те, як вказати сумісний вузол для вашого Podʼа, можна знайти в цьому посібнику.

Розвʼязання проблем мережі

  1. Мої Podʼи Windows не мають підключення до мережі.

    Якщо ви використовуєте віртуальні машини, переконайтеся, що MAC spoofing увімкнено на всіх адаптерах мережі віртуальних машин.

  2. Мої Podʼи Windows не можуть пінгувати зовнішні ресурси.

    Podʼи Windows не мають правил для вихідного трафіку, програмованих для протоколу ICMP. Однак, підтримується TCP/UDP. При спробі продемонструвати підключення до ресурсів за межами кластера, замініть ping <IP> відповідними командами curl <IP>.

    Якщо у вас все ще виникають проблеми, ймовірно, ваша мережева конфігурація в cni.conf потребує додаткової уваги. Ви завжди можете редагувати цей статичний файл. Оновлення конфігурації буде застосовано до будь-яких нових ресурсів Kubernetes.

    Одним із вимог мережі Kubernetes (див. Модель Kubernetes) є внутрішнє звʼязування кластера без NAT всередині. Щоб відповідати цій вимозі, існує ExceptionList для всього трафіку, де ви не хочете, щоб відбувалось використання NAT назовні. Однак, це також означає, що вам потрібно виключити зовнішню IP-адресу, яку ви намагаєтесь запитати з ExceptionList. Тільки тоді трафік, який походить з вашого Podʼа Windows, буде коректно SNAT'ed для отримання відповіді зі світу. З цього погляду ваш ExceptionList у cni.conf повинен виглядати так:

    "ExceptionList": [
                    "10.244.0.0/16",  # Підмережа кластера
                    "10.96.0.0/12",   # Підмережа служби
                    "10.127.130.0/24" # Управління (хост) підмережа
                ]
    
  3. Мій вузол Windows не може отримати доступ до служб типу NodePort.

    Доступ до локального NodePort з самого вузла не вдається. Це відоме обмеження. Доступ до NodePort працює з інших вузлів або зовнішніх клієнтів.

  4. vNICs та HNS точки доступу контейнерів видаляються.

    Цю проблему може викликати відмова в передачі параметра hostname-override до kube-proxy. Щоб вирішити це, користувачі повинні передавати імʼя хосту kube-proxy наступним чином:

    C:\k\kube-proxy.exe --hostname-override=$(hostname)
    
  5. Мій вузол Windows не може отримати доступ до моїх Service за допомогою IP-адреси Service

    Це відоме обмеження стека мережі на Windows. Однак, Podʼи Windows можуть отримувати доступ до IP-адреси Service.

  6. Під час запуску kubelet не знайдено мережевого адаптера.

    Для правильної роботи мережі Windows потрібен віртуальний адаптер. Якщо наступні команди не повертають результатів (в оболонці адміністратора), створення віртуальної мережі, необхідна передумова для роботи kubelet, не вдалося:

    Get-HnsNetwork | ? Name -ieq "cbr0"
    Get-NetAdapter | ? Name -Like "vEthernet (Ethernet*"
    

    Часто варто змінити параметр InterfaceName у скрипті start.ps1, в разі, якщо мережевий адаптер хосту не є "Ethernet". В іншому випадку зверніться до виводу скрипту start-kubelet.ps1, щоб побачити, чи є помилки під час створення віртуальної мережі.

  7. DNS-перетворення не працює належним чином.

    Перевірте обмеження DNS для Windows у цьому розділі.

  8. kubectl port-forward видає помилку "unable to do port forwarding: wincat not found"

    Це було реалізовано в Kubernetes 1.15, включивши wincat.exe в інфраструктурний контейнер pause mcr.microsoft.com/oss/kubernetes/pause:3.6. Будьте впевнені, що використовуєте підтримувану версію Kubernetes. Якщо ви хочете побудувати власний контейнер інфраструктури pause, обовʼязково додайте wincat.

  9. Моє встановлення Kubernetes падає, тому що мій вузол сервера Windows знаходиться за проксі

    Якщо ви перебуваєте за проксі, наступні змінні середовища PowerShell повинні бути визначені:

    [Environment]::SetEnvironmentVariable("HTTP_PROXY", "http://proxy.example.com:80/", [EnvironmentVariableTarget]::Machine)
    [Environment]::SetEnvironmentVariable("HTTPS_PROXY", "http://proxy.example.com:443/", [EnvironmentVariableTarget]::Machine)
    

Розвʼязання проблем Flannel

  1. З Flannel мої вузли мають проблеми після повторного приєднання до кластера.

    Кожного разу, коли раніше видалений вузол повторно приєднується до кластера, flannelD намагається призначити нову підмережу Podʼа вузлу. Користувачі повинні видалити старі файли конфігурації підмережі Podʼа за наступними шляхами:

    Remove-Item C:\k\SourceVip.json
    Remove-Item C:\k\SourceVipRequest.json
    
  2. Flanneld застрягає в "Waiting for the Network to be created"

    Є численні звіти про цю проблему; ймовірно, це проблема з часом встановлення управлінської IP-адреси мережі flannel. Обхідним рішенням є перезапуск start.ps1 або перезапуск його вручну так:

    [Environment]::SetEnvironmentVariable("NODE_NAME", "<Windows_Worker_Hostname>")
    C:\flannel\flanneld.exe --kubeconfig-file=c:\k\config --iface=<Windows_Worker_Node_IP> --ip-masq=1 --kube-subnet-mgr=1
    
  3. Мої Podʼи Windows не можуть запуститися через відсутність /run/flannel/subnet.env.

    Це вказує на те, що Flannel не запустився правильно. Ви можете спробувати перезапустити flanneld.exe або вручну скопіювати файли з /run/flannel/subnet.env на майстрі Kubernetes в C:\run\flannel\subnet.env на робочий вузол Windows та змінити рядок FLANNEL_SUBNET на інший номер. Наприклад, якщо підмережа вузла 10.244.4.1/24 бажана:

    FLANNEL_NETWORK=10.244.0.0/16
    FLANNEL_SUBNET=10.244.4.1/24
    FLANNEL_MTU=1500
    FLANNEL_IPMASQ=true
    

Подальші дослідження

Якщо ці кроки не розвʼязують вашої проблеми, ви можете отримати допомогу у запуску контейнерів Windows на вузлах Windows у Kubernetes у наступних ресурсах:

4.5 - Керування обʼєктами Kubernetes

Декларативні та імперативні парадигми взаємодії з API Kubernetes.

4.5.1 - Декларативне керування обʼєктами Kubernetes з використанням конфігураційних файлів

Обʼєкти Kubernetes можна створювати, оновлювати та видаляти, зберігаючи декілька файлів конфігурації обʼєктів у теці та використовувати kubectl apply для рекурсивного створення та оновлення цих обʼєктів за потреби. Цей метод зберігає записи, зроблені у поточних обʼєктах, без злиття змін до файлів конфігурації обʼєкта. За допомогою kubectl diff також можна переглянути зміни, які буде внесено командою apply.

Перш ніж ви розпочнете

Встановіть kubectl.

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Для перевірки версії введіть kubectl version.

Компроміси

Інструмент kubectl підтримує три види управління обʼєктами:

  • Імперативні команди
  • Імперативне конфігурування обʼєктів
  • Декларативне конфігурування обʼєктів

Див. Управління обʼєктами Kubernetes для обговорення переваг та недоліків кожного виду управління обʼєктами.

Огляд

Декларативна конфігурація обʼєктів потребує чіткого розуміння визначень та конфігурації обʼєктів Kubernetes. Прочитайте наступні документи, якщо ви ще цього не зробили:

Нижче подано визначення термінів, використаних у цьому документі:

  • файл конфігурації обʼєкта / файл конфігурації: Файл, який визначає конфігурацію для обʼєкта Kubernetes. Ця тема показує, як передавати файли конфігурації до kubectl apply. Файли конфігурації зазвичай зберігаються у системі контролю версій, такі як Git.
  • поточна конфігурація обʼєкта / поточна конфігурація: Поточні значення конфігурації обʼєкта, які використовуються кластером Kubernetes. Їх зберігають у сховищі кластера Kubernetes, зазвичай etcd.
  • декларативний записувач конфігурації / декларативний письменник: Особа або компонент програмного забезпечення, який вносить оновлення до поточного обʼєкта. Поточні записувачі, на які посилається ця тема, вносять зміни до файлів конфігурації обʼєктів та запускають kubectl apply для запису змін.

Як створити обʼєкти

Використовуйте kubectl apply, щоб створити всі обʼєкти, за винятком тих, що вже існують, які визначені у конфігураційних файлах у вказаній теці:

kubectl apply -f <тека>

Це встановлює анотацію kubectl.kubernetes.io/last-applied-configuration: '{...}' для кожного обʼєкта. Анотація містить вміст файлу конфігурації обʼєкта, який був використаний для створення обʼєкта.

Ось приклад файлу конфігурації обʼєкта:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  minReadySeconds: 5
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

Запустіть kubectl diff, щоб показати обʼєкт, який буде створено:

kubectl diff -f https://k8s.io/examples/application/simple_deployment.yaml

Створіть обʼєкт за допомогою kubectl apply:

kubectl apply -f https://k8s.io/examples/application/simple_deployment.yaml

Виведіть поточну конфігурацію за допомогою kubectl get:

kubectl get -f https://k8s.io/examples/application/simple_deployment.yaml -o yaml

Вивід показує, що анотація kubectl.kubernetes.io/last-applied-configuration була записана до поточної конфігурації та відповідає конфігураційному файлу:

kind: Deployment
metadata:
  annotations:
    # ...
    # Це json-представлення simple_deployment.yaml
    # Воно було створено за допомогою kubectl apply під час створення обʼєкта
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"apps/v1","kind":"Deployment",
      "metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
      "spec":{"minReadySeconds":5,"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}},
      "spec":{"containers":[{"image":"nginx:1.14.2","name":"nginx",
      "ports":[{"containerPort":80}]}]}}}}      
  # ...
spec:
  # ...
  minReadySeconds: 5
  selector:
    matchLabels:
      # ...
      app: nginx
  template:
    metadata:
      # ...
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:1.14.2
        # ...
        name: nginx
        ports:
        - containerPort: 80
        # ...
      # ...
    # ...
  # ...

Як оновити обʼєкти

Ви також можете використовувати kubectl apply, щоб оновити всі обʼєкти, визначені у теці, навіть якщо ці обʼєкти вже існують. Цей підхід виконує наступне:

  1. Встановлює поля, що зʼявляються у файлі конфігурації, у поточній конфігурації.
  2. Очищає поля, які були видалені з файлу конфігурації, у поточній конфігурації.
kubectl diff -f <тека>
kubectl apply -f <тека>

Ось приклад конфігураційного файлу:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  minReadySeconds: 5
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

Створіть обʼєкт за допомогою kubectl apply:

kubectl apply -f https://k8s.io/examples/application/simple_deployment.yaml

Виведіть поточну конфігурацію за допомогою kubectl get:

kubectl get -f https://k8s.io/examples/application/simple_deployment.yaml -o yaml

Вивід показує, що анотація kubectl.kubernetes.io/last-applied-configuration була записана до поточної конфігурації та відповідає конфігураційному файлу:

kind: Deployment
metadata:
  annotations:
    # ...
    # Це json-представлення simple_deployment.yaml
    # Воно було створено за допомогою kubectl apply під час створення обʼєкта
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"apps/v1","kind":"Deployment",
      "metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
      "spec":{"minReadySeconds":5,"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}},
      "spec":{"containers":[{"image":"nginx:1.14.2","name":"nginx",
      "ports":[{"containerPort":80}]}]}}}}      
  # ...
spec:
  # ...
  minReadySeconds: 5
  selector:
    matchLabels:
      # ...
      app: nginx
  template:
    metadata:
      # ...
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:1.14.2
        # ...
        name: nginx
        ports:
        - containerPort: 80
        # ...
      # ...
    # ...
  # ...

Напряму оновіть поле replicas у поточній конфігурації за допомогою kubectl scale. Для цього не використовується kubectl apply:

kubectl scale deployment/nginx-deployment --replicas=2

Виведіть поточну конфігурацію за допомогою kubectl get:

kubectl get deployment nginx-deployment -o yaml

Вивід показує, що поле replicas встановлено на 2, і анотація last-applied-configuration не містить поле replicas:

apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    # ...
    # Зверніть увагу, що анотація не містить replicas
    # тому що воно не було оновлено через apply
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"apps/v1","kind":"Deployment",
      "metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
      "spec":{"minReadySeconds":5,"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}},
      "spec":{"containers":[{"image":"nginx:1.14.2","name":"nginx",
      "ports":[{"containerPort":80}]}]}}}}      
  # ...
spec:
  replicas: 2 # Встановлено за допомогою `kubectl scale`. Ігнорується `kubectl apply`.
  # ...
  minReadySeconds: 5
  selector:
    matchLabels:
      # ...
      app: nginx
  template:
    metadata:
      # ...
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:1.14.2 # Встановлено за допомогою `kubectl apply`
        # ...
        name: nginx
        ports:
        - containerPort: 80
      # ...
    # ...
  # ...

Оновіть конфігураційний файл simple_deployment.yaml, щоб змінити образ з nginx:1.14.2 на nginx:1.16.1 та видалити поле minReadySeconds:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.16.1 # оновіть образ
        ports:
        - containerPort: 80

Застосуйте зміни, внесені до конфігураційного файлу:

kubectl diff -f https://k8s.io/examples/application/update_deployment.yaml
kubectl apply -f https://k8s.io/examples/application/update_deployment.yaml

Виведіть поточну конфігурацію за допомогою kubectl get:

kubectl get -f https://k8s.io/examples/application/update_deployment.yaml -o yaml

Вивід показує наступні зміни в поточній конфігурації:

  • Поле replicas зберігає значення 2, встановлене за допомогою kubectl scale. Це можливо через його відсутність у конфігураційному файлі.
  • Поле image було оновлено на nginx:1.16.1 з nginx:1.14.2.
  • Анотація last-applied-configuration була оновлена новим образом.
  • Поле minReadySeconds було очищено.
  • Анотація last-applied-configuration більше не містить поле minReadySeconds.
apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    # ...
    # Анотація містить оновлений образ nginx 1.16.1,
    # але не містить оновлення копій на 2
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"apps/v1","kind":"Deployment",
      "metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
      "spec":{"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}},
      "spec":{"containers":[{"image":"nginx:1.16.1","name":"nginx",
      "ports":[{"containerPort":80}]}]}}}}      
    # ...
spec:
  replicas: 2 # Встановлено за допомогою `kubectl scale`. Ігнорується `kubectl apply`.
  # minReadySeconds очищено за допомогою `kubectl apply`
  # ...
  selector:
    matchLabels:
      # ...
      app: nginx
  template:
    metadata:
      # ...
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:1.16.1 # Встановлено за допомогою `kubectl apply`
        # ...
        name: nginx
        ports:
        - containerPort: 80
      # ...
    # ...
  # ...

Як видалити обʼєкти

Існують два підходи до видалення обʼєктів, керованих за допомогою kubectl apply.

Ручне видалення обʼєктів за допомогою імперативної команди є рекомендованим підходом, оскільки він більш явно вказує на те, що видаляється, і менш ймовірно призводить до випадкового видалення чогось:

kubectl delete -f <filename>

Альтернатива: kubectl apply -f <directory> --prune

Як альтернативу kubectl delete, ви можете використовувати kubectl apply для ідентифікації обʼєктів, які мають бути видалені після видалення їх маніфестів з теки у локальній файловій системі.

У Kubernetes 1.31, доступні два режими очищення в kubectl apply:

  • Очищення на основі allowlist: Цей режим існує з моменту kubectl v1.5, але все ще знаходиться на етапі альфа-тестування через проблеми з використанням, коректністю і продуктивністю його дизайну. Режим на основі ApplySet призначений для заміни його.
  • Очищення на основі ApplySet: apply set — це обʼєкт на стороні сервера (типово, Secret), який kubectl може використовувати для точного та ефективного відстеження членства в наборі під час операцій apply. Цей режим був введений у альфа-версії в kubectl v1.27 як заміна очищенню на основі allowlist.

<div class="feature-state-notice feature-alpha">
  <span class="feature-state-name">СТАН ФУНКЦІОНАЛУ:</span> 
  <code>Kubernetes v1.5 [alpha]</code>
</div>

Щоб використовувати очищення на основі allowlist, додайте наступні прапорці до свого виклику kubectl apply:

  • --prune: Видалити попередньо застосовані обʼєкти, які не є у наборі, що передані поточному виклику.
  • --prune-allowlist: Список груп-версій-типів (GVK, group-version-kind), які розглядаються для очищення. Цей прапорець є необовʼязковим, але настійно рекомендується, оскільки його стандартне значення є частковим списком обʼєктів з просторами імен та областями застосування, що може призвести до несподіваних результатів.
  • --selector/-l: Використовуйте селектор міток для обмеження набору обʼєктів, обраних для очищення. Цей прапорець є необовʼязковим, але настійно рекомендується.
  • --all: використовуйте замість --selector/-l, щоб явно вибрати всі попередньо застосовані обʼєкти відповідних типів, які знаходяться у списку дозволених.

Очищення на основі allowlist запитує API-сервер щодо всіх обʼєктів затверджених GVK, які відповідають заданим міткам (якщо є), і намагається зіставити конфігурації активних обʼєктів, отриманих в результаті, з файлами маніфестів обʼєктів. Якщо обʼєкт відповідає запиту і він не має маніфесту в теці, і має анотацію kubectl.kubernetes.io/last-applied-configuration, він видаляється.

kubectl apply -f <directory> --prune -l <labels> --prune-allowlist=<gvk-list>

<div class="feature-state-notice feature-alpha">
  <span class="feature-state-name">СТАН ФУНКЦІОНАЛУ:</span> 
  <code>Kubernetes v1.27 [alpha]</code>
</div>

Для використання очищення на основі ApplySet встановіть змінну середовища KUBECTL_APPLYSET=true, і додайте наступні прапорці до свого виклику kubectl apply:

  • --prune: Видалити попередньо застосовані обʼєкти, які не є у наборі, що передані поточному виклику.
  • --applyset: Назва обʼєкта, який kubectl може використовувати для точного та ефективного відстеження членства в наборі під час операцій apply.
KUBECTL_APPLYSET=true kubectl apply -f <directory> --prune --applyset=<name>

Типово тип батьківського обʼєкта ApplySet, що використовується, — Secret. Однак також можуть бути використані ConfigMaps у форматі: --applyset=configmaps/<name>. При використанні Secret або ConfigMap, kubectl створить обʼєкт, якщо він ще не існує.

Також можливе використання власних ресурсів як батьківських обʼєктів ApplySet. Для цього позначте міткою Custom Resource Definition (CRD), що визначає ресурс, який ви хочете використовувати з наступним: applyset.kubernetes.io/is-parent-type: true. Потім створіть обʼєкт, який ви хочете використовувати як батьківський обʼєкт ApplySet (kubectl цього не робить автоматично для Custom Resource). Нарешті, посилайтеся на цей обʼєкт у прапорці applyset таким чином: --applyset=<resource>.<group>/<name> (наприклад, widgets.custom.example.com/widget-name).

Під час очищення на основі ApplySet kubectl додає мітку applyset.kubernetes.io/part-of=<parentID> до кожного обʼєкта в наборі, перш ніж вони будуть надіслані на сервер. З метою продуктивності він також збирає список типів ресурсів і просторів імен, які включаються у набір, і додає ці дані в анотації поточного батьківського обʼєкта. В кінеці операції apply, він запитує API-сервер щодо обʼєктів цих типів в цих просторах імен (або в областях кластера, якщо це доречно), які належать до набору, визначеного міткою applyset.kubernetes.io/part-of=<parentID>.

Застереження та обмеження:

  • Кожен обʼєкт може бути членом не більше одного набору.
  • Прапорець --namespace є обовʼязковим при використанні будь-якого обʼєкта з простором імен, включаючи типово Secret. Це означає, що ApplySets, які охоплюють кілька просторів імен, повинні використовувати кластерний обʼєкт з кореневою текою.
  • Щоб безпечно використовувати очищення на основі ApplySet з декількома теками, використовуйте унікальне імʼя ApplySet для кожного.

Як переглянути обʼєкт

Ви можете використовувати kubectl get з -o yaml, щоб переглянути конфігурацію поточного обʼєкта:

kubectl get -f <filename|url> -o yaml

Як apply обчислює різницю та обʼєднує зміни

Коли kubectl apply оновлює поточну конфігурацію обʼєкта, він робить це, надсилаючи запит на патч до API-сервера. Патч визначає оновлення для конкретних полів конфігурації живого обʼєкта. Команда kubectl apply обчислює цей запит на патч за допомогою файлу конфігурації, поточної конфігурації та анотації last-applied-configuration, збереженої в поточній конфігурації.

Обчислення злиття патчів

Команда kubectl apply записує вміст файлу конфігурації до анотації kubectl.kubernetes.io/last-applied-configuration. Вона використовується для ідентифікації полів, які були видалені з файлу конфігурації та які потрібно видалити з поточної конфігурації. Ось кроки, які використовуються для обчислення того, які поля потрібно видалити або встановити:

  1. Обчислити поля для видалення. Це поля, які присутні в last-applied-configuration та відсутні в файлі конфігурації.
  2. Обчислити поля для додавання або встановлення. Це поля, які присутні в файлі конфігурації, значення яких не відповідають поточній конфігурації.

Ось приклад. Припустимо, що це файл конфігурації для обʼєкта типу Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.16.1 # оновіть образ
        ports:
        - containerPort: 80

Також, припустимо, що це поточна конфігурація для того самого обʼєкта типу Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    # ...
    # Зауважте, що анотація не містить поля replicas,
    # оскільки воно не було оновлено через apply
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"apps/v1","kind":"Deployment",
      "metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
      "spec":{"minReadySeconds":5,"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}},
      "spec":{"containers":[{"image":"nginx:1.14.2","name":"nginx",
      "ports":[{"containerPort":80}]}]}}}}      
  # ...
spec:
  replicas: 2 # вказано через scale
  # ...
  minReadySeconds: 5
  selector:
    matchLabels:
      # ...
      app: nginx
  template:
    metadata:
      # ...
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:1.14.2
        # ...
        name: nginx
        ports:
        - containerPort: 80
      # ...

Ось обчислення злиття, які виконає kubectl apply:

  1. Обчислення полів для видалення, отримуючи значення з last-applied-configuration і порівнюючи їх зі значеннями у файлі конфігурації. Очищення полів, які явно встановлені ​​на null у локальному файлі конфігурації обʼєкта, незалежно від того, чи вони зʼявляються в анотації last-applied-configuration. У цьому прикладі minReadySeconds зʼявляється в анотації last-applied-configuration, але не зʼявляється у файлі конфігурації. Дія: Прибрати minReadySeconds з поточної конфігурації.
  2. Обчислення полів для встановлення, отримуючи значення з файлу конфігурації та порівнюючи їх зі значеннями у поточній конфігурації. У цьому прикладі значення image у файлі конфігурації не відповідає значенню у поточній конфігурації. Дія: Встановити значення image у поточній конфігурації.
  3. Встановити анотацію last-applied-configuration, щоб вона відповідала значенню файлу конфігурації.
  4. Обʼєднати результати з 1, 2, 3 у єдиний запит на патч до API-сервера.

Ось поточна конфігурація, яка є результатом злиття:

apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    # ...
    # Анотація містить оновлений образ nginx 1.16.1,
    # але не містить оновлення реплік до 2
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"apps/v1","kind":"Deployment",
      "metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
      "spec":{"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}},
      "spec":{"containers":[{"image":"nginx:1.16.1","name":"nginx",
      "ports":[{"containerPort":80}]}]}}}}      
    # ...
spec:
  selector:
    matchLabels:
      # ...
      app: nginx
  replicas: 2 # Встановлено за допомогою `kubectl scale`.  Ігнорується `kubectl apply`.
  # minReadySeconds очищено за допомогою `kubectl apply`
  # ...
  template:
    metadata:
      # ...
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:1.16.1 # Встановлено за допомогою `kubectl apply`
        # ...
        name: nginx
        ports:
        - containerPort: 80
        # ...
      # ...
    # ...
  # ...

Як зливаються поля різних типів

Як певне поле в конфігураційному файлі зливається з поточною конфігурацією залежить від типу поля. Існують кілька типів полів:

  • primitive: Поле типу рядок, ціле число або логічне значення. Наприклад, image та replicas є полями примітивів. Дія: Замінити.

  • map, також відомий як object: Поле типу map або комплексний тип, який містить підполя. Наприклад, labels, annotations, spec та metadata — це всі map. Дія: Злити елементи або підполя.

  • list: Поле, яке містить список елементів, які можуть бути або типами primitive, або map. Наприклад, containers, ports та args є списками. Дія: Варіюється.

Коли kubectl apply оновлює map або list, він зазвичай не замінює все поле цілком, а замість цього оновлює окремі піделементи. Наприклад, при злитті spec в Deployment, весь spec не замінюється. Замість цього порівнюються та зливаються підполя spec, такі як replicas.

Злиття змін для полів типу primitive

Поля primitive замінюються або очищаються.

Поле в конфігураційному файлі обʼєктаПоле в поточній конфігурації обʼєктаПоле в останній застосованій конфігураціїДія
ТакТак-Встановити поточне значення з конфігураційного файлу.
ТакНі-Встановити поточне значення з локального конфігураційного файлу.
Ні-ТакОчистити з поточної конфігурації.
Ні-НіНічого не робити. Зберегти значення поточного обʼєкта.

Злиття змін у полях типу map

Поля, які є map, зливаються шляхом порівняння кожного з підполів або елементів map:

Ключ в конфігураційному файлі обʼєктаКлюч у поточній конфігурації обʼєктаПоле в останній застосованій конфігураціїДія
ТакТак-Порівняти значення підполів.
ТакНі-Встановити поточне значення з локального конфігураційного файлу.
Ні-ТакВидалити з поточної конфігурації.
Ні-НіНічого не робити. Зберігти значення поточного обʼєкта.

Злиття змін для полів типу list

Злиття змін у list використовує одну з трьох стратегій:

  • Заміна list, якщо всі його елементи є primitive.
  • Злиття окремих елементів у списку комплексних елементів.
  • Злиття list елементів primitive.

Вибір стратегії залежить від конкретного поля.

Заміна list, якщо всі його елементи є primitive

Такий список трактується так само як і поле primitive. Замініть або видаліть весь список. Це зберігає порядок.

Приклад: Використовуйте kubectl apply, щоб оновити поле args контейнера в Podʼі. Це встановлює значення args в поточній конфігурації на значення у файлі конфігурації. Будь-які елементи args, які раніше були додані до поточної конфігурації, втрачаються. Порядок елементів args, визначених у файлі конфігурації, зберігається у поточній конфігурації.

# Значення last-applied-configuration
    args: ["a", "b"]

# Значення файлу конфігурації
    args: ["a", "c"]

# Поточна конфігурація
    args: ["a", "b", "d"]

# Результат після злиття
    args: ["a", "c"]

Пояснення: Злиття використовує значення файлу конфігурації як нове значення списку.

Злиття окремих елементів списку комлексних елементів:

Трактуйте список як map, а конкретне поле кожного елемента як ключ. Додавайте, видаляйте або оновлюйте окремі елементи. Це не зберігає порядок.

Ця стратегія злиття використовує спеціальний теґ на кожному полі, який називається patchMergeKey. patchMergeKey визначено для кожного поля в коді Kubernetes: types.go При злитті списку map, поле, вказане як patchMergeKey для певного елемента, використовується як ключ map для цього елемента.

Приклад: Використайте kubectl apply, щоб оновити поле containers у PodSpec. Це злиття списку, ніби він був map, де кожен елемент має ключ name.

# Значення last-applied-configuration
    containers:
    - name: nginx
      image: nginx:1.16
    - name: nginx-helper-a # ключ: nginx-helper-a; буде видалено у результаті
      image: helper:1.3
    - name: nginx-helper-b # ключ: nginx-helper-b; буде збережено
      image: helper:1.3

# Значення файлу конфігурації
    containers:
    - name: nginx
      image: nginx:1.16
    - name: nginx-helper-b
      image: helper:1.3
    - name: nginx-helper-c # ключ: nginx-helper-c; буде додано у результаті
      image: helper:1.3

# Поточна конфігурація
    containers:
    - name: nginx
      image: nginx:1.16
    - name: nginx-helper-a
      image: helper:1.3
    - name: nginx-helper-b
      image: helper:1.3
      args: ["run"] # Поле буде збережено
    - name: nginx-helper-d # ключ: nginx-helper-d; буде збережено
      image: helper:1.3

# Результат після злиття
    containers:
    - name: nginx
      image: nginx:1.16
      # Елемент nginx-helper-a був видалений
    - name: nginx-helper-b
      image: helper:1.3
      args: ["run"] # Поле було збережено
    - name: nginx-helper-c # Елемент був доданий
      image: helper:1.3
    - name: nginx-helper-d # Елемент був ігнорований
      image: helper:1.3

Пояснення:

  • Контейнер з імʼям "nginx-helper-a" був видалений, оскільки жодного контейнера з іменем "nginx-helper-a" не знайдено у файлі конфігурації.
  • Контейнер з імʼям "nginx-helper-b" зберіг зміни у args в поточній конфігурації. kubectl apply зміг ідентифікувати, що "nginx-helper-b" у поточній конфігурації був тим самим "nginx-helper-b", що й у файлі конфігурації, навіть якщо їхні поля мали різні значення (немає args у файлі конфігурації). Це тому, що значення поля patchMergeKey (name) було ідентичним у обох.
  • Контейнер з імʼям "nginx-helper-c" був доданий, оскільки жодного контейнера з таким імʼям не було у поточній конфігурації, але один з таким імʼям був у файлі конфігурації.
  • Контейнер з імʼям "nginx-helper-d" був збережений, оскільки жодного елемента з таким імʼям не було в last-applied-configuration.

Злиття списку елементів типу primitive

Зараз, починаючи з Kubernetes 1.5, злиття списків елементів типу primitive не підтримується.

Стандартні значення полів

Сервер API встановлює в певні поля станадартні значення у поточній конфігурації, якщо вони не вказані при створенні обʼєкта.

Ось файл конфігурації для обʼєкта Deployment. У файлі не вказано strategy:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  minReadySeconds: 5
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

Створіть обʼєкт, використовуючи kubectl apply:

kubectl apply -f https://k8s.io/examples/application/simple_deployment.yaml

Виведіть поточну конфігурацію, використовуючи kubectl get:

kubectl get -f https://k8s.io/examples/application/simple_deployment.yaml -o yaml

Вивід показує, що сервер API встановив в деякі поля стандартні значення у поточній конфігурації. Ці поля не були вказані в файлі конфігурації.

apiVersion: apps/v1
kind: Deployment
# ...
spec:
  selector:
    matchLabels:
      app: nginx
  minReadySeconds: 5
  replicas: 1 # станадратне значення додане apiserver
  strategy:
    rollingUpdate: # станадратне значення додане apiserver - походить з strategy.type
      maxSurge: 1
      maxUnavailable: 1
    type: RollingUpdate # станадратне значення додане apiserver
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:1.14.2
        imagePullPolicy: IfNotPresent # станадратне значення додане apiserver
        name: nginx
        ports:
        - containerPort: 80
          protocol: TCP # станадратне значення додане apiserver
        resources: {} # станадратне значення додане apiserver
        terminationMessagePath: /dev/termination-log # станадратне значення додане apiserver
      dnsPolicy: ClusterFirst # станадратне значення додане apiserver
      restartPolicy: Always # станадратне значення додане apiserver
      securityContext: {} # станадратне значення додане apiserver
      terminationGracePeriodSeconds: 30 # станадратне значення додане apiserver
# ...

У запиті на патч, поля, які мають станаддартні значення, не перезаписуються, якщо вони явно не очищені як частина запиту на патч. Це може призвести до неочікуваної поведінки для полів, які мають стнадартні значення на основі значень інших полів. Після зміни інших полів значення, які мають стандартні значення з них, не будуть оновлені, якщо їх не явно очищено.

З цієї причини рекомендується, щоб певні поля, стандартні значення яких встановлює сервер, були явно визначені в файлі конфігурації обʼєкта, навіть якщо бажані значення відповідають станадартним значенням сервера. Це полегшить розпізнавання суперечливих значень, які не будуть перезаписані сервером на станадартні значення.

Приклад:

# last-applied-configuration
spec:
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

# конфігураційний файл
spec:
  strategy:
    type: Recreate # оновленне значення
  template:
    metadata:
      labels:
        app:

 nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

# поточна конфігурація
spec:
  strategy:
    type: RollingUpdate # встановлене типове значення
    rollingUpdate: # встановлене типове значення отримане з type
      maxSurge : 1
      maxUnavailable: 1
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

# результат після злиття - ПОМИЛКА!
spec:
  strategy:
    type: Recreate # оновленне значення: несумісне з rollingUpdate
    rollingUpdate: # встановлене типове значення: несумісне з "type: Recreate"
      maxSurge : 1
      maxUnavailable: 1
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

Пояснення:

  1. Користувач створює Deployment без визначення strategy.type.
  2. Сервер встановлює станадартне значення для strategy.type на RollingUpdate тв стандартне значення для strategy.rollingUpdate.
  3. Користувач змінює strategy.type на Recreate. Значення strategy.rollingUpdate залишаються стандартними значеннями, хоча сервер очікує, що вони будуть очищені. Якщо значення strategy.rollingUpdate були визначені спочатку в файлі конфігурації, було б більш зрозуміло, що їх потрібно було б видалити.
  4. Оновлення не вдається через те, що strategy.rollingUpdate не очищено. Поле strategy.rollingupdate не може бути визначено з strategy.type Recreate.

Рекомендація: Ці поля слід явно визначити в файлі конфігурації обʼєкта:

  • Селектори та мітки PodTemplate для робочих навантажень, таких як Deployment, StatefulSet, Job, DaemonSet, ReplicaSet та ReplicationController.
  • Стратегія розгортання Deployment.

Як очистити стандартні поля встановлені сервером або поля, встановлені іншими записувачами

Поля, які не зʼявляються у файлі конфігурації, можна очистити, встановивши їх значення в null, а потім застосувати файл конфігурації. Для полів, стандартні значення яких встановлено сервером, це спричинить перезапис цих значень.

Як змінити власника поля між файлом конфігурації та прямими імперативними записувачами

Ці методи — єдиний вірний спосіб змінювати окреме поле обʼєкта:

  • Використовуйте kubectl apply.
  • Пишіть безпосередньо в поточну конфігурацію без змін файлу конфігурації: наприклад, використовуйте kubectl scale.

Зміна власника з прямого імперативного записувача на файл конфігурації

Додайте поле до файлу конфігурації. Для цього поля припиніть прямі оновлення поточної конфігурації, які не проходять через kubectl apply.

Зміна власника з файлу конфігурації на безпосереднього імперативного записувача

Починаючи з Kubernetes 1.5, зміна власника поля з файлу конфігурації на імперативного запусувача вимагає виконання наступних кроків:

  • Видаліть поле з файлу конфігурації.
  • Видаліть поле з анотації kubectl.kubernetes.io/last-applied-configuration на поточному обʼєкті.

Зміна методів управління

Обʼєктами Kubernetes слід керувати за допомогою лише одного методу одночасно. Перехід з одного методу на інший можливий, але це вимагає ручної обробки.

Міграція з управління імперативними командами до декларативної конфігурації обʼєктів

Міграція з управління імперативними командами до декларативної конфігурації обʼєктів включає кілька ручних кроків:

  1. Експортуйте поточний обʼєкт у локальний файл конфігурації:

    kubectl get <kind>/<name> -o yaml > <kind>_<name>.yaml
    
  2. Видаліть вручну поле status з файлу конфігурації.

  3. Встановіть анотацію kubectl.kubernetes.io/last-applied-configuration на обʼєкті:

    kubectl replace --save-config -f <kind>_<name>.yaml
    
  4. Змініть процеси так, щоб вони використовували виключно kubectl apply для керування обʼєктом.

Міграція з імперативної конфігурації обʼєктів до декларативної конфігурації обʼєктів

  1. Встановіть анотацію kubectl.kubernetes.io/last-applied-configuration на обʼєкті:

    kubectl replace --save-config -f <kind>_<name>.yaml
    
  2. Змініть процеси так, щоб використовували kubectl apply виключно для керування обʼєктом.

Визначення селекторів контролера та міток PodTemplate

Рекомендований підхід — це визначення єдиного, незмінного підпису PodTemplate, який використовується тільки селектором контролера без іншого семантичного значення.

Приклад:

selector:
  matchLabels:
      controller-selector: "apps/v1/deployment/nginx"
template:
  metadata:
    labels:
      controller-selector: "apps/v1/deployment/nginx"

Що далі

4.5.2 - Декларативне керування обʼєктами Kubernetes за допомогою Kustomize

Kustomize — це окремий інструмент для налаштування обʼєктів Kubernetes за допомогою файлу кастомізації.

Починаючи з версії 1.14, Kubectl також підтримує керування обʼєктами Kubernetes за допомогою файлу кастомізації. Для перегляду ресурсів, знайдених у теці, що містить файл кастомізації, виконайте наступну команду:

kubectl kustomize <kustomization_directory>

Щоб застосувати ці ресурси, запустіть kubectl apply з прапорцем --kustomize або -k:

kubectl apply -k <kustomization_directory>

Перш ніж ви розпочнете

Встановіть kubectl.

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Для перевірки версії введіть kubectl version.

Огляд Kustomize

Kustomize — це інструмент для налаштування конфігурацій Kubernetes. Він має наступні функції для керування файлами конфігурації застосунків:

  • генерація ресурсів з інших джерел
  • встановлення наскрізних полів для ресурсів
  • складання та налаштування колекцій ресурсів

Генерування ресурсів

ConfigMaps та Secrets зберігають конфігураційні або конфіденційні дані, які використовуються іншими обʼєктами Kubernetes, наприклад, Podʼами. Джерело істини для ConfigMaps або Secrets є зазвичай зовнішнім до кластера, наприклад як файл .properties або файл ключів SSH. Kustomize має secretGenerator та configMapGenerator, які створюють Secret та ConfigMap з файлів або літералів.

configMapGenerator

Щоб створити ConfigMap з файлу, додайте запис до списку files в configMapGenerator. Ось приклад створення ConfigMap з елементом даних з файлу .properties:

# Створіть файл application.properties
cat <<EOF >application.properties
FOO=Bar
EOF

cat <<EOF >./kustomization.yaml
configMapGenerator:
- name: example-configmap-1
  files:
  - application.properties
EOF

Згенерований ConfigMap можна переглянути за допомогою наступної команди:

kubectl kustomize ./

Згенерований ConfigMap виглядає так:

apiVersion: v1
data:
  application.properties: |
    FOO=Bar    
kind: ConfigMap
metadata:
  name: example-configmap-1-8mbdf7882g

Щоб створити ConfigMap з файлу оточення (env), додайте запис до списку envs в configMapGenerator. Ось приклад створення ConfigMap з елементом даних з файлу .env:

# Створіть файл .env
cat <<EOF >.env
FOO=Bar
EOF

cat <<EOF >./kustomization.yaml
configMapGenerator:
- name: example-configmap-1
  envs:
  - .env
EOF

Згенерований ConfigMap можна переглянути за допомогою наступної команди:

kubectl kustomize ./

Згенерований ConfigMap виглядає так:

apiVersion: v1
data:
  FOO: Bar
kind: ConfigMap
metadata:
  name: example-configmap-1-42cfbf598f

ConfigMaps також можна створювати з літеральних пар ключ-значення. Щоб створити ConfigMap з літеральною парою ключ-значення, додайте запис до списку literals в configMapGenerator. Ось приклад створення ConfigMap з елементом даних з пари ключ-значення:

cat <<EOF >./kustomization.yaml
configMapGenerator:
- name: example-configmap-2
  literals:
  - FOO=Bar
EOF

Згенерований ConfigMap можна перевірити за допомогою наступної команди:

kubectl kustomize ./

Згенерований ConfigMap виглядає так:

apiVersion: v1
data:
  FOO: Bar
kind: ConfigMap
metadata:
  name: example-configmap-2-g2hdhfc6tk

Щоб використовувати згенерований ConfigMap у Deployment, посилайтеся на нього за іменем configMapGenerator. Kustomize автоматично замінить це імʼя згенерованим.

Ось приклад Deployment, що використовує згенерований ConfigMap:

# Створіть файл application.properties
cat <<EOF >application.properties
FOO=Bar
EOF

cat <<EOF >deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  labels:
    app: my-app
spec:
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: app
        image: my-app
        volumeMounts:
        - name: config
          mountPath: /config
      volumes:
      - name: config
        configMap:
          name: example-configmap-1
EOF

cat <<EOF >./kustomization.yaml
resources:
- deployment.yaml
configMapGenerator:
- name: example-configmap-1
  files:
  - application.properties
EOF

Згенеруйте ConfigMap та Deployment:

kubectl kustomize ./

Згенерований Deployment буде посилатися на згенерований ConfigMap за іменем:

apiVersion: v1
data:
  application.properties: |
    FOO=Bar    
kind: ConfigMap
metadata:
  name: example-configmap-1-g4hk9g2ff8
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: my-app
  name: my-app
spec:
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - image: my-app
        name: app
        volumeMounts:
        - mountPath: /config
          name: config
      volumes:
      - configMap:
          name: example-configmap-1-g4hk9g2ff8
        name: config

secretGenerator

Ви можете створювати Secrets з файлів або літеральних пар ключ-значення. Щоб створити Secret з файлу, додайте запис до списку files в secretGenerator. Ось приклад створення Secret з елементом даних з файлу:

# Створіть файл password.txt
cat <<EOF >./password.txt
username=admin
password=secret
EOF

cat <<EOF >./kustomization.yaml
secretGenerator:
- name: example-secret-1
  files:
  - password.txt
EOF

Згенерований Secret має наступний вигляд:

apiVersion: v1
data:
  password.txt: dXNlcm5hbWU9YWRtaW4KcGFzc3dvcmQ9c2VjcmV0Cg==
kind: Secret
metadata:
  name: example-secret-1-t2kt65hgtb
type: Opaque

Щоб створити Secret з літеральною парою ключ-значення, додайте запис до списку literals в secretGenerator. Ось приклад створення Secret з елементом даних з пари ключ-значення:

cat <<EOF >./kustomization.yaml
secretGenerator:
- name: example-secret-2
  literals:
  - username=admin
  - password=secret
EOF

Згенерований Secret має наступний вигляд:

apiVersion: v1
data:
  password: c2VjcmV0
  username: YWRtaW4=
kind: Secret
metadata:
  name: example-secret-2-t52t6g96d8
type: Opaque

Podʼібно до ConfigMaps, створені Secrets можна використовувати у Deployment, посилаючись на імʼя secretGenerator:

# Створіть файл password.txt
cat <<EOF >./password.txt
username=admin
password=secret
EOF

cat <<EOF >deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  labels:
    app: my-app
spec:
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: app
        image: my-app
        volumeMounts:
        - name: password
          mountPath: /secrets
      volumes:
      - name: password
        secret:
          secretName: example-secret-1
EOF

cat <<EOF >./kustomization.yaml
resources:
- deployment.yaml
secretGenerator:
- name: example-secret-1
  files:
  - password.txt
EOF

generatorOptions

Згенеровані ConfigMaps та Secrets мають суфікс хешу вмісту, що додається. Це забезпечує створення нового ConfigMap або Secret при зміні вмісту. Щоб вимкнути поведінку додавання суфікса, можна використовувати generatorOptions. Крім того, також можливо вказати загальні опції для згенерованих ConfigMaps та Secrets.

cat <<EOF >./kustomization.yaml
configMapGenerator:
- name: example-configmap-3
  literals:
  - FOO=Bar
generatorOptions:
  disableNameSuffixHash: true
  labels:
    type: generated
  annotations:
    note: generated
EOF

Виконайте kubectl kustomize ./, щоб переглянути згенерований ConfigMap:

apiVersion: v1
data:
  FOO: Bar
kind: ConfigMap
metadata:
  annotations:
    note: generated
  labels:
    type: generated
  name: example-configmap-3

Встановлення загальних наскрізних полів

Досить поширене явище — встановлення загальних наскрізних полів для всіх ресурсів Kubernetes у проєкті. Деякі випадки встановлення загальних полів:

  • встановлення одного й того ж простору імен для всіх ресурсів
  • додавання одного й того ж префікса чи суфікса до імені
  • додавання одного й того ж набору міток
  • додавання одного й того ж набору анотацій

Ось приклад:

# Створіть deployment.yaml
cat <<EOF >./deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
EOF

cat <<EOF >./kustomization.yaml
namespace: my-namespace
namePrefix: dev-
nameSuffix: "-001"
commonLabels:
  app: bingo
commonAnnotations:
  oncallPager: 800-555-1212
resources:
- deployment.yaml
EOF

Виконайте kubectl kustomize ./, щоб переглянути, як ці поля встановлені у ресурсі Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    oncallPager: 800-555-1212
  labels:
    app: bingo
  name: dev-nginx-deployment-001
  namespace: my-namespace
spec:
  selector:
    matchLabels:
      app: bingo
  template:
    metadata:
      annotations:
        oncallPager: 800-555-1212
      labels:
        app: bingo
    spec:
      containers:
      - image: nginx
        name: nginx

Компонування та кастомізація ресурсів

Часто в проєкті складають набір Ресурсів та керують ними всередині одного файлу чи теки. Kustomize пропонує компонування Ресурсів з різних файлів та застосування патчів чи інших налаштувань до них.

Компонування

Kustomize підтримує компонування різних ресурсів. Поле resources у файлі kustomization.yaml визначає список ресурсів, які слід включити в конфігурацію. Встановіть шлях до файлу конфігурації ресурсу у списку resources. Ось приклад додавання до конфігурації застосунку NGINX, що складається з Deployment та Service:

# Створіть файл deployment.yaml
cat <<EOF > deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
spec:
  selector:
    matchLabels:
      run: my-nginx
  replicas: 2
  template:
    metadata:
      labels:
        run: my-nginx
    spec:
      containers:
      - name: my-nginx
        image: nginx
        ports:
        - containerPort: 80
EOF

# Створіть файл service.yaml
cat <<EOF > service.yaml
apiVersion: v1
kind: Service
metadata:
  name: my-nginx
  labels:
    run: my-nginx
spec:
  ports:
  - port: 80
    protocol: TCP
  selector:
    run: my-nginx
EOF

# Створіть файл kustomization.yaml та скомпонуйте їх
cat <<EOF >./kustomization.yaml
resources:
- deployment.yaml
- service.yaml
EOF

Ресурси з kubectl kustomize ./ містять обʼєкти як Deployment, так і Service.

Кастомізація

Патчі можуть бути використані для застосування різних кастомізацій до Ресурсів. Kustomize підтримує різні механізми патчінгу через patchesStrategicMerge та patchesJson6902. patchesStrategicMerge — це список шляхів до файлів. Кожен файл повинен бути розвʼязаний до стратегічного обʼєднання патчів. Імена всередині патчів повинні відповідати іменам Ресурсів, які вже завантажені. Рекомендується використовувати невеликі патчі, які виконують одну задачу. Наприклад, створіть один патч для збільшення кількості реплік у Deployment та інший патч для встановлення обмеження памʼяті.

# Створіть файл deployment.yaml
cat <<EOF > deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
spec:
  selector:
    matchLabels:
      run: my-nginx
  replicas: 2
  template:
    metadata:
      labels:
        run: my-nginx
    spec:
      containers:
      - name: my-nginx
        image: nginx
        ports:
        - containerPort: 80
EOF

# Створіть патч increase_replicas.yaml
cat <<EOF > increase_replicas.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
spec:
  replicas: 3
EOF

# Створіть інший патч set_memory.yaml
cat <<EOF > set_memory.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
spec:
  template:
    spec:
      containers:
      - name: my-nginx
        resources:
          limits:
            memory: 512Mi
EOF

cat <<EOF >./kustomization.yaml
resources:
- deployment.yaml
patchesStrategicMerge:
- increase_replicas.yaml
- set_memory.yaml
EOF

Виконайте kubectl kustomize ./, щоб переглянути Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      run: my-nginx
  template:
    metadata:
      labels:
        run: my-nginx
    spec:
      containers:
      - image: nginx
        name: my-nginx
        ports:
        - containerPort: 80
        resources:
          limits:
            memory: 512Mi

Не всі Ресурси чи поля підтримують стратегічні обʼєднувальні патчі. Для підтримки зміни довільних полів у довільних Ресурсах, Kustomize пропонує застосування JSON патчів через patchesJson6902. Для знаходження правильного Ресурсу для Json патчу, потрібно вказати групу, версію, тип та імʼя цього Ресурсу у kustomization.yaml. Наприклад, збільшення кількості реплік у обʼєкті Deployment також можна зробити через patchesJson6902.

# Створіть файл deployment.yaml
cat <<EOF > deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
spec:
  selector:
    matchLabels:
      run: my-nginx
  replicas: 2
  template:
    metadata:
      labels:
        run: my-nginx
    spec:
      containers:
      - name: my-nginx
        image: nginx
        ports:
        - containerPort: 80
EOF

# Створіть json патч
cat <<EOF > patch.yaml
- op: replace
  path: /spec/replicas
  value: 3
EOF

# Створіть kustomization.yaml
cat <<EOF >./kustomization.yaml
resources:
- deployment.yaml

patchesJson6902:
- target:
    group: apps
    version: v1
    kind: Deployment
    name: my-nginx
  path: patch.yaml
EOF

Виконайте kubectl kustomize ./, щоб побачити, що поле replicas оновлене:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      run: my-nginx
  template:
    metadata:
      labels:
        run: my-nginx
    spec:
      containers:
      - image: nginx
        name: my-nginx
        ports:
        - containerPort: 80

Крім патчів, Kustomize також пропонує налаштування контейнерних образів або введення значень полів з інших обʼєктів в контейнери без створення патчів. Наприклад, ви можете змінити використаний образ усередині контейнерів, вказавши новий образ у полі images у kustomization.yaml.

cat <<EOF > deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
spec:
  selector:
    matchLabels:
      run: my-nginx
  replicas: 2
  template:
    metadata:
      labels:
        run: my-nginx
    spec:
      containers:
      - name: my-nginx
        image: nginx
        ports:
        - containerPort: 80
EOF

cat <<EOF >./kustomization.yaml
resources:
- deployment.yaml
images:
- name: nginx
  newName: my.image.registry/nginx
  newTag: 1.4.0
EOF

Виконайте kubectl kustomize ./, щоб переглянути, що використовується оновлений образ:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      run: my-nginx
  template:
    metadata:
      labels:
        run: my-nginx
    spec:
      containers:
      - image: my.image.registry/nginx:1.4.0
        name: my-nginx
        ports:
        - containerPort: 80

Іноді застосунок, що працює у Podʼі, може потребувати використання значень конфігурації з інших обʼєктів. Наприклад, Pod з обʼєкту Deployment повинен читати відповідне імʼя Service з Env або як аргумент команди. Оскільки імʼя Service може змінюватися через namePrefix або nameSuffix, додавання імені Service у командний аргумент не рекомендується. Для цього використовується Kustomize, що вводить імʼя Service в контейнери через vars.

# Створіть файл deployment.yaml (взявши в лапки роздільник документа)
cat <<'EOF' > deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
spec:
  selector:
    matchLabels:
      run: my-nginx
  replicas: 2
  template:
    metadata:
      labels:
        run: my-nginx
    spec:
      containers:
      - name: my-nginx
        image: nginx
        command: ["start", "--host", "$(MY_SERVICE_NAME)"]
EOF

# Створіть файл service.yaml
cat <<EOF > service.yaml
apiVersion: v1
kind: Service
metadata:
  name: my-nginx
  labels:
    run: my-nginx
spec:
  ports:
  - port: 80
    protocol: TCP
  selector:
    run: my-nginx
EOF

cat <<EOF >./kustomization.yaml
namePrefix: dev-
nameSuffix: "-001"

resources:
- deployment.yaml
- service.yaml

vars:
- name: MY_SERVICE_NAME
  objref:
    kind: Service
    name: my-nginx
    apiVersion: v1
EOF

Виконайте kubectl kustomize ./, щоб побачити, що імʼя Service, введене у контейнери, — це dev-my-nginx-001:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: dev-my-nginx-001
spec:
  replicas: 2
  selector:
    matchLabels:
      run: my-nginx
  template:
    metadata:
      labels:
        run: my-nginx
    spec:
      containers:
      - command:
        - start
        - --host
        - dev-my-nginx-001
        image: nginx
        name: my-nginx

Base та Overlay

У Kustomize існують концепції base та overlay. Base — це тека з файлом kustomization.yaml, яка містить набір ресурсів та повʼязані налаштування. Base може бути як локальною текою, так і текою з віддаленого репозиторію, якщо присутній файл kustomization.yaml. Overlay — це тека з файлом kustomization.yaml, яка посилається на інші теки з налаштуваннями як на свої base компоненти. Base не знає про overlay і може використовуватися в кількох overlay. Overlay може мати кілька base та компонувати всі ресурси з base, а також мати власні налаштування поверх.

Ось приклад base:

# Створіть теку для зберігання base
mkdir base
# Створіть файл base/deployment.yaml
cat <<EOF > base/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
spec:
  selector:
    matchLabels:
      run: my-nginx
  replicas: 2
  template:
    metadata:
      labels:
        run: my-nginx
    spec:
      containers:
      - name: my-nginx
        image: nginx
EOF

# Створіть файл base/service.yaml
cat <<EOF > base/service.yaml
apiVersion: v1
kind: Service
metadata:
  name: my-nginx
  labels:
    run: my-nginx
spec:
  ports:
  - port: 80
    protocol: TCP
  selector:
    run: my-nginx
EOF
# Створіть файл base/kustomization.yaml
cat <<EOF > base/kustomization.yaml
resources:
- deployment.yaml
- service.yaml
EOF

Цю базу можна використовувати в кількох overlay. Ви можете додавати різний namePrefix або інші загальні поля у різних overlay. Ось два overlay, які використовують один і той же base.

mkdir dev
cat <<EOF > dev/kustomization.yaml
resources:
- ../base
namePrefix: dev-
EOF

mkdir prod
cat <<EOF > prod/kustomization.yaml
resources:
- ../base
namePrefix: prod-
EOF

Як застосувати/переглядати/видаляти обʼєкти використовуючи Kustomize

Використовуйте --kustomize або -k у командах kubectl, щоб визначити Ресурси, які керуються kustomization.yaml. Зверніть увагу, що -k повинен посилатися на теку з налаштуваннями kustomization, наприклад,

kubectl apply -k <тека kustomization>/

Враховуючи наступний kustomization.yaml,

# Створіть файл deployment.yaml
cat <<EOF > deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
spec:
  selector:
    matchLabels:
      run: my-nginx
  replicas: 2
  template:
    metadata:
      labels:
        run: my-nginx
    spec:
      containers:
      - name: my-nginx
        image: nginx
        ports:
        - containerPort: 80
EOF

# Створіть файл kustomization.yaml
cat <<EOF >./kustomization.yaml
namePrefix: dev-
commonLabels:
  app: my-nginx
resources:
- deployment.yaml
EOF

Виконайте наступну команду, щоб застосувати обʼєкт Deployment dev-my-nginx:

> kubectl apply -k ./
deployment.apps/dev-my-nginx створено

Виконайте одну з наступних команд, щоб переглянути обʼєкт Deployment dev-my-nginx:

kubectl get -k ./
kubectl describe -k ./

Виконайте наступну команду, щоб порівняти обʼєкт Deployment dev-my-nginx зі станом, в якому буде кластер, якщо маніфест буде застосований:

kubectl diff -k ./

Виконайте наступну команду, щоб видалити обʼєкт Deployment dev-my-nginx:

> kubectl delete -k ./
deployment.apps "dev-my-nginx" deleted

Перелік елементів Kustomize

ПолеТипПояснення
namespacestringдодає простір імен до всіх ресурсів
namePrefixstringце значення додається до імен всіх ресурсів
nameSuffixstringце значення додається до кінця імен всіх ресурсів
commonLabelsmap[string]stringмітки, що додаються до всіх ресурсів і селекторів
commonAnnotationsmap[string]stringанотації, що додаються до всіх ресурсів
resources[]stringкожний елемент цього списку повинен посилатися на наявний файл конфігурації ресурсів
configMapGenerator[]ConfigMapArgsКожний елемент цього списку генерує ConfigMap
secretGenerator[]SecretArgsКожний елемент цього списку генерує Secret
generatorOptionsGeneratorOptionsМодифікує поведінку всіх генераторів ConfigMap і Secret
bases[]stringКожний елемент цього списку повинен посилатися на теку, що містить файл kustomization.yaml
patchesStrategicMerge[]stringКожний елемент цього списку повинен посилатися на стратегічне патч злиття обʼєкта Kubernetes
patchesJson6902[]PatchКожний елемент цього списку повинен посилатися на обʼєкт Kubernetes та Json Patch
vars[]VarКожний елемент призначений для отримання тексту з поля одного ресурсу
images[]ImageКожний елемент призначений для зміни імені, тегів і/або дайджесту для одного образу без створення патчів
configurations[]stringКожний елемент цього списку повинен посилатися на файл, що містить конфігурації перетворювача Kustomize
crds[]stringКожний елемент цього списку повинен посилатися на файл визначення OpenAPI для типів Kubernetes

Що далі

4.5.3 - Керування обʼєктами Kubernetes за допомогою імперативних команд

Обʼєкти Kubernetes можна швидко створювати, оновлювати та видаляти безпосередньо за допомогою імперативних команд, вбудованих в інструмент командного рядка kubectl. Цей документ пояснює, як організовано ці команди та як їх використовувати для керування поточними обʼєктами.

Перш ніж ви розпочнете

Встановіть kubectl.

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Для перевірки версії введіть kubectl version.

Компроміси

Інструмент kubectl підтримує три види управління обʼєктами:

  • Імперативні команди
  • Імперативне конфігурування обʼєктів
  • Декларативне конфігурування обʼєктів

Див. Управління обʼєктами Kubernetes для обговорення переваг та недоліків кожного виду управління обʼєктами.

Як створювати обʼєкти

Інструмент kubectl підтримує команди, що базуються на дії, для створення деяких найпоширеніших типів обʼєктів. Команди названі так, щоб їх можна було впізнати користувачам, що не знайомі з типами обʼєктів Kubernetes.

  • run: Створює новий Pod для запуску контейнера.
  • expose: Створює новий обʼєкт Service для балансування трафіку між Pod.
  • autoscale: Створює новий обʼєкт Autoscaler для автоматичного горизонтального масштабування контролера, наприклад, Deployment.

Інструмент kubectl також підтримує команди створення, що базуються на типі обʼєкта. Ці команди підтримують більше типів обʼєктів і більш явно вказують на їх наміри, але вимагають, щоб користувачі знали типи обʼєктів, які вони мають намір створити.

  • create <типобʼєкта> [<підтип>] <імʼяекземпляра>

Деякі типи обʼєктів мають підтипи, які можна вказати в команді create. Наприклад, обʼєкт Service має кілька підтипів, включаючи ClusterIP, LoadBalancer та NodePort. Ось приклад створення Service з підтипом NodePort:

kubectl create service nodeport <myservicename>

У попередньому прикладі команда create service nodeport викликається як підкоманда команди create service.

Ви можете використовувати прапорець -h, щоб знайти аргументи та прапорці, які підтримуються підкомандою:

kubectl create service nodeport -h

Як оновлювати обʼєкти

Команда kubectl підтримує команди, що базуються на дії, для деяких загальних операцій оновлення. Ці команди названі так, щоб користувачі, які не знайомі з обʼєктами Kubernetes, могли виконувати оновлення, не знаючи конкретних полів, які потрібно встановити:

  • scale: Горизонтально масштабувати контролер для додавання або видалення Podʼів шляхом оновлення кількості реплік контролера.
  • annotate: Додати або видалити анотацію з обʼєкта.
  • label: Додати або видалити мітку з обʼєкта.

Команда kubectl також підтримує команди оновлення, що базуються на аспекті обʼєкта. Встановлення цього аспекту може встановлювати різні поля для різних типів обʼєктів:

  • set <поле>: Встановити аспект обʼєкта.

Інструмент kubectl підтримує ці додаткові способи оновлення поточного обʼєкта безпосередньо, однак вони вимагають кращого розуміння схеми обʼєктів Kubernetes.

  • edit: Безпосередньо редагувати сирі конфігурації поточного обʼєкта, відкриваючи його конфігурацію в редакторі.
  • patch: Безпосередньо модифікувати конкретні поля поточного обʼєкта, використовуючи рядок патча. Докладніше про рядки патча див. розділ патча в Конвенціях API.

Як видаляти обʼєкти

Ви можете використовувати команду delete, щоб видалити обʼєкт з кластера:

  • delete <тип>/<імʼя>
kubectl delete deployment/nginx

Як переглянути обʼєкт

Існують кілька команд для виведення інформації про обʼєкт:

  • get: Виводить базову інформацію про відповідні обʼєкти. Використовуйте get -h, щоб побачити список опцій.
  • describe: Виводить агреговану детальну інформацію про відповідні обʼєкти.
  • logs: Виводить stdout та stderr для контейнера, що працює в Pod.

Використання команд set для модифікації обʼєктів перед створенням

Є деякі поля обʼєктів, для яких не існує прапорця, який можна використовувати в команді create. У деяких з цих випадків ви можете використовувати комбінацію set та create, щоб вказати значення для поля перед створенням обʼєкта. Це робиться за допомогою перенаправлення виводу команди create на команду set, а потім назад на команду create. Ось приклад:

kubectl create service clusterip my-svc --clusterip="None" -o yaml --dry-run=client | kubectl set selector --local -f - 'environment=qa' -o yaml | kubectl create -f -
  1. Команда kubectl create service -o yaml --dry-run=client створює конфігурацію для Service, але виводить її на stdout у форматі YAML замість надсилання до сервера API Kubernetes.
  2. Команда kubectl set selector --local -f - -o yaml читає конфігурацію з stdin і записує оновлену конфігурацію на stdout у форматі YAML.
  3. Команда kubectl create -f - створює обʼєкт, використовуючи надану конфігурацію через stdin.

Використання --edit для модифікації обʼєктів перед створенням

Можна використовувати kubectl create --edit, щоб зробити довільні зміни обʼєкта перед його створенням. Ось приклад:

kubectl create service clusterip my-svc --clusterip="None" -o yaml --dry-run=client > /tmp/srv.yaml
kubectl create --edit -f /tmp/srv.yaml
  1. Команда kubectl create service створює конфігурацію для Service та зберігає її у /tmp/srv.yaml.
  2. Команда kubectl create --edit відкриває файл конфігурації для редагування перед створенням обʼєкта.

Що далі

4.5.4 - Імперативне керування обʼєктами Kubernetes за допомогою файлів конфігурації

Обʼєкти Kubernetes можна створювати, оновлювати та видаляти за допомогою інструменту командного рядка kubectl разом із файлом конфігурації обʼєкта, написаним у форматі YAML або JSON. У цьому документі пояснюється, як визначати та керувати обʼєктами за допомогою файлів конфігурації.

Перш ніж ви розпочнете

Встановіть kubectl.

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Для перевірки версії введіть kubectl version.

Компроміси

Інструмент kubectl підтримує три види управління обʼєктами:

  • Імперативні команди
  • Імперативне конфігурування обʼєктів
  • Декларативне конфігурування обʼєктів

Див. Управління обʼєктами Kubernetes для обговорення переваг та недоліків кожного виду управління обʼєктами.

Як створювати обʼєкти

Ви можете використовувати kubectl create -f для створення обʼєкта з файлу конфігурації. Дивіться Довідник API Kubernetes для отримання деталей.

  • kubectl create -f <filename|url>

Як оновити обʼєкти

Ви можете використовувати kubectl replace -f для оновлення поточного обʼєкта згідно з файлом конфігурації.

  • kubectl replace -f <filename|url>

Як видалити обʼєкти

Ви можете використовувати kubectl delete -f для видалення обʼєкта, який описаний у файлі конфігурації.

  • kubectl delete -f <filename|url>

Як переглянути обʼєкт

Ви можете використовувати kubectl get -f, щоб переглянути інформацію про обʼєкт, що описаний у файлі конфігурації.

  • kubectl get -f <filename|url> -o yaml

Прапорець -o yaml вказує, що повна конфігурація обʼєкта виводиться. Використовуйте kubectl get -h, щоб побачити список опцій.

Обмеження

Команди create, replace та delete працюють добре, коли кожна конфігурація обʼєкта повністю визначена і записана у своєму файлі конфігурації. Однак, коли поточний обʼєкт оновлюється, і оновлення не обʼєднуються в його файл конфігурації, оновлення будуть втрачені після наступного виконання replace. Це може статися, якщо контролер, такий як HorizontalPodAutoscaler, вносить оновлення безпосередньо до поточного обʼєкта. Ось приклад:

  1. Ви створюєте обʼєкт з файлу конфігурації.
  2. Інше джерело оновлює обʼєкт, змінюючи якесь поле.
  3. Ви замінюєте обʼєкт з файлу конфігурації. Зміни, внесені іншим джерелом на кроці 2, втрачені.

Якщо вам потрібна підтримка кількох записувачів для одного обʼєкта, ви можете використовувати kubectl apply для керування обʼєктом.

Створення та редагування обʼєкта за URL без зберігання конфігурації

Припустимо, що у вас є URL файлу конфігурації обʼєкта. Ви можете використовувати kubectl create --edit для внесення змін до конфігурації перед створенням обʼєкта. Це особливо корисно для підручників та завдань, які вказують на файл конфігурації, який може бути змінений читачем.

kubectl create -f <url> --edit

Міграція від імперативних команд до імперативного конфігурування обʼєктів

Міграція від імперативних команд до імперативної конфігурації обʼєктів включає декілька кроків, які потрібно виконати вручну.

  1. Експортуйте поточний обʼєкт у локальний файл конфігурації обʼєкта:

    kubectl get <kind>/<name> -o yaml > <kind>_<name>.yaml
    
  2. Ручне видалення поля стану з файлу конфігурації обʼєкта.

  3. Для подальшого керування обʼєктом виключно використовуйте replace.

    kubectl replace -f <kind>_<name>.yaml
    

Визначення селекторів контролерів та міток PodTemplate

Рекомендований підхід — визначити одну незмінну мітку PodTemplate, яка використовується тільки селектором контролера без іншого семантичного значення.

Приклад мітки:

selector:
  matchLabels:
      controller-selector: "apps/v1/deployment/nginx"
template:
  metadata:
    labels:
      controller-selector: "apps/v1/deployment/nginx"

Що далі

4.5.5 - Оновлення обʼєктів API на місці за допомогою kubectl patch

Використовуйте kubectl patch для оновлення обʼєктів Kubernetes API на місці. Виконайте стратегічний патч злиття або патч злиття JSON.

Це завдання показує, як використовувати kubectl patch для оновлення обʼєкта API на місці. Вправи в цьому завданні демонструють стратегічний патч злиття та патч злиття JSON.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Для перевірки версії введіть kubectl version.

Використання стратегічного патчу злиття для оновлення Deployment

Ось файл конфігурації для Deployment, що має дві репліки. Кожна репліка є Podʼом, який має один контейнер:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: patch-demo
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: patch-demo-ctr
        image: nginx
      tolerations:
      - effect: NoSchedule
        key: dedicated
        value: test-team

Створіть Deployment:

kubectl apply -f https://k8s.io/examples/application/deployment-patch.yaml

Перегляньте Podʼи, повʼязані з вашим Deployment:

kubectl get pods

Вивід показує, що Deployment має два Podʼи. 1/1 вказує на те, що кожен Pod має один контейнер:

NAME                        READY     STATUS    RESTARTS   AGE
patch-demo-28633765-670qr   1/1       Running   0          23s
patch-demo-28633765-j5qs3   1/1       Running   0          23s

Зробіть позначку про імена працюючих Podʼів. Пізніше ви побачите, що ці Podʼи будуть завершені та замінені новими.

На цей момент кожен Pod має один контейнер, який запускає образ nginx. Тепер, здавалося б, вам потрібно, щоб кожен Pod мав два контейнери: один, який запускає nginx, і один, який запускає redis.

Створіть файл з іменем patch-file.yaml, який має такий вміст:

spec:
  template:
    spec:
      containers:
      - name: patch-demo-ctr-2
        image: redis

Застосуйте патч до вашого Deployment:

kubectl patch deployment patch-demo --patch-file patch-file.yaml

Перегляньте Deployment після накладання патчу:

kubectl get deployment patch-demo --output yaml

Вивід показує, що PodSpec у Deployment має ддва контейнери

containers:
- image: redis
  imagePullPolicy: Always
  name: patch-demo-ctr-2
  ...
- image: nginx
  imagePullPolicy: Always
  name: patch-demo-ctr
  ...

Перегляньте Podʼи, повʼязані з вашим Deployment після накладання патчу:

kubectl get pods

Вивід показує, що працюючі Podʼи мають різні імена Podʼів, у порівнняні з тими що працювали раніше. Deployment припинив роботу старих Podʼів та створив два нові Podʼи, які відповідають оновленій специфікації Deployment. 2/2 вказує на те, що кожен Pod має два контейнера:

NAME                          READY     STATUS    RESTARTS   AGE
patch-demo-1081991389-2wrn5   2/2       Running   0          1m
patch-demo-1081991389-jmg7b   2/2       Running   0          1m

Придивіться уважніше до одного з Podʼів patch-demo:

kubectl get pod <your-pod-name> --output yaml

Вивід показує, що Pod має два контейнери: один, який запускає nginx, і один, який запускає redis:

containers:
- image: redis
  ...
- image: nginx
  ...

Примітки щодо стратегічного патчу злиття

Патч, який ви виконали у попередній вправі, називається стратегічним патчем злиття. Зверніть увагу, що патч не замінив список containers. Замість цього він додав новий контейнер до списку. Іншими словами, список у патчі був обʼєднаний з поточним списком. Це не завжди трапляється, коли ви використовуєте стратегічний патч злиття для списку. У деяких випадках список замінюється, а не обʼєднується.

За допомогою стратегічних патчів злиття список або замінюється, або обʼєднується залежно від його стратегії патча. Стратегія патча вказується значенням ключа patchStrategy у мітці поля в вихідному коді Kubernetes. Наприклад, поле Containers структури PodSpec має patchStrategy рівне merge:

type PodSpec struct {
  ...
  Containers []Container `json:"containers" patchStrategy:"merge" patchMergeKey:"name" ...`
  ...
}

Ви також можете побачити стратегію патча в специфікації OpenApi:

"io.k8s.api.core.v1.PodSpec": {
    ...,
    "containers": {
        "description": "List of containers belonging to the pod.  ...."
    },
    "x-kubernetes-patch-merge-key": "name",
    "x-kubernetes-patch-strategy": "merge"
}

І ви можете побачити стратегію патча в документації Kubernetes API.

Створіть файл з іменем patch-file-tolerations.yaml із таким вмістом:

spec:
  template:
    spec:
      tolerations:
      - effect: NoSchedule
        key: disktype
        value: ssd

Застосуйте патч до вашого Deployment:

kubectl patch deployment patch-demo --patch-file patch-file-tolerations.yaml

Перегляньте Deployment після накладання патчу:

kubectl get deployment patch-demo --output yaml

Відвід показує, що у PodSpec у Deployment є лише один Toleration:

tolerations:
- effect: NoSchedule
  key: disktype
  value: ssd

Зверніть увагу, що список tolerations в PodSpec був замінений, а не обʼєднаний. Це тому, що поле Tolerations структури PodSpec не має ключа patchStrategy у своїй мітці поля. Тому стратегія патча, що використовується стандартно, дорівнює replace.

type PodSpec struct {
  ...
  Tolerations []Toleration `json:"tolerations,omitempty" protobuf:"bytes,22,opt,name=tolerations"`
  ...
}

Використання патчу злиття JSON для оновлення Deployment

Стратегічне патч злиття відрізняється від JSON merge patch. З JSON merge patch, якщо вам потрібно оновити список, вам потрібно вказати цілий новий список. І новий список повністю замінює поточний список.

Команда kubectl patch має параметр type, який ви можете встановити на одне з цих значень:

Значення параметраТип злиття
jsonJSON Patch, RFC 6902
mergeJSON Merge Patch, RFC 7386
strategicСтратегічне патч злиття

Для порівняння JSON patch та JSON merge patch, див. JSON Patch та JSON Merge Patch.

Стандартне значення для параметра type є strategic. Таким чином, у попередній вправі ви виконали стратегічний патч злиття.

Далі виконайте JSON merge patch на вашому Deployment. Створіть файл з іменем patch-file-2.yaml із таким вмістом:

spec:
  template:
    spec:
      containers:
      - name: patch-demo-ctr-3
        image: gcr.io/google-samples/hello-app:2.0

У вашій команді патча встановіть type на merge:

kubectl patch deployment patch-demo --type merge --patch-file patch-file-2.yaml

Перегляньте Deployment після накладання патчу:

kubectl get deployment patch-demo --output yaml

Список containers, який ви вказали у патчі, має лише один контейнер. Вивід показує, що ваш список з одним контейнером замінив наявний список containers.

spec:
  containers:
  - image: gcr.io/google-samples/hello-app:2.0
    ...
    name: patch-demo-ctr-3

Перегляньте Podʼи:

kubectl get pods

У виводі ви можете побачити, що наявні Podʼи були завершені, а нові Podʼи — створені. 1/1 вказує на те, що кожен новий Pod працює лише з одним контейнером.

NAME                          READY     STATUS    RESTARTS   AGE
patch-demo-1307768864-69308   1/1       Running   0          1m
patch-demo-1307768864-c86dc   1/1       Running   0          1m

Використання стратегічного патча злиття для оновлення Deployment з використанням стратегії retainKeys

Ось файл конфігурації для Deployment, що використовує стратегію RollingUpdate:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: retainkeys-demo
spec:
  selector:
    matchLabels:
      app: nginx
  strategy:
    rollingUpdate:
      maxSurge: 30%
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: retainkeys-demo-ctr
        image: nginx

Створіть Deployment:

kubectl apply -f https://k8s.io/examples/application/deployment-retainkeys.yaml

На цей момент Deployment створено і використовує стратегію RollingUpdate.

Створіть файл з іменем patch-file-no-retainkeys.yaml з таким вмістом:

spec:
  strategy:
    type: Recreate

Застосуйте патч до вашого Deployment:

kubectl patch deployment retainkeys-demo --type strategic --patch-file patch-file-no-retainkeys.yaml

У виводі ви побачите, що неможливо встановити type як Recreate, коли значення визначено для spec.strategy.rollingUpdate:

The Deployment "retainkeys-demo" is invalid: spec.strategy.rollingUpdate: Forbidden: may not be specified when strategy `type` is 'Recreate'

Способом видалити значення для spec.strategy.rollingUpdate під час оновлення значення для type є використання стратегії retainKeys для стратегічного злиття.

Створіть ще один файл з іменем patch-file-retainkeys.yaml з таким вмістом:

spec:
  strategy:
    $retainKeys:
    - type
    type: Recreate

З цим патчем ми вказуємо, що ми хочемо зберегти лише ключ type обʼєкта strategy. Таким чином, під час операції патча значення rollingUpdate буде видалено.

Знову застосуйте патч до вашого Deployment з цим новим патчем:

kubectl patch deployment retainkeys-demo --type strategic --patch-file patch-file-retainkeys.yaml

Дослідіть вміст Deployment:

kubectl get deployment retainkeys-demo --output yaml

У виводі показано, що обʼєкт стратегії в Deployment більше не містить ключа rollingUpdate:

spec:
  strategy:
    type: Recreate
  template:

Примітки щодо стратегічного патчу злиття з використанням стратегії retainKeys

Патч, який ви виконали в попередній вправі, називається стратегічним патчем злиття з використанням стратегії retainKeys. Цей метод вводить нову директиву $retainKeys, яка має наступні стратегії:

  • Вона містить список рядків.
  • Усі поля, які потрібно зберегти, повинні бути присутні в списку $retainKeys.
  • Поля, які присутні, будуть обʼєднані з поточним обʼєктом.
  • Всі відсутні поля будуть очищені під час застосування патча.
  • Усі поля у списку $retainKeys повинні бути надмножиною або такими ж, як і поля, що присутні в патчі.

Стратегія retainKeys не працює для всіх обʼєктів. Вона працює лише тоді, коли значення ключа patchStrategy у мітці поля в вихідному коді Kubernetes містить retainKeys. Наприклад, поле Strategy структури DeploymentSpec має patchStrategy рівне retainKeys:

type DeploymentSpec struct {
  ...
  // +patchStrategy=retainKeys
  Strategy DeploymentStrategy `json:"strategy,omitempty" patchStrategy:"retainKeys" ...`
  ...
}

Ви також можете побачити стратегію retainKeys в специфікації OpenApi:

"io.k8s.api.apps.v1.DeploymentSpec": {
    ...,
    "strategy": {
        "$ref": "#/definitions/io.k8s.api.apps.v1.DeploymentStrategy",
        "description": "The deployment strategy to use to replace existing pods with new ones.",
        "x-kubernetes-patch-strategy": "retainKeys"
    },
    ....
}

І ви можете дізнатись більше про стратегію retainKeys в документації Kubernetes API.

Альтернативні форми команди kubectl patch

Команда kubectl patch приймає YAML або JSON. Вона може приймати патч як файл або безпосередньо в командному рядку.

Створіть файл з іменем patch-file.json з таким вмістом:

{
   "spec": {
      "template": {
         "spec": {
            "containers": [
               {
                  "name": "patch-demo-ctr-2",
                  "image": "redis"
               }
            ]
         }
      }
   }
}

Наступні команди є еквівалентними:

kubectl patch deployment patch-demo --patch-file patch-file.yaml
kubectl patch deployment patch-demo --patch 'spec:\n template:\n  spec:\n   containers:\n   - name: patch-demo-ctr-2\n     image: redis'

kubectl patch deployment patch-demo --patch-file patch-file.json
kubectl patch deployment patch-demo --patch '{"spec": {"template": {"spec": {"containers": [{"name": "patch-demo-ctr-2","image": "redis"}]}}}}'

Оновлення кількості реплік обʼєкта за допомогою kubectl patch з --subresource

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.24 [alpha]

Прапорець --subresource=[імʼя-субресурсу] використовується з командами kubectl, такими як get, patch, edit і replace, для отримання та оновлення субресурсів status та scale ресурсів (застосовується для версії kubectl v1.24 або новішої). Цей прапорець використовується з усіма ресурсами API (вбудованими та CR), які мають субресурси status або scale. Deployment — один з прикладів, які підтримують ці субресурси.

Ось маніфест для Deployment, що має дві репліки:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2 # вказує Deployment запустити 2 Podʼи, що відповідають шаблону
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

Створіть Deployment:

kubectl apply -f https://k8s.io/examples/application/deployment.yaml

Перегляньте Podʼи, повʼязані з вашим Deployment:

kubectl get pods -l app=nginx

У виводі ви можете побачити, що у Deployment є дві Podʼи. Наприклад:

NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-7fb96c846b-22567   1/1     Running   0          47s
nginx-deployment-7fb96c846b-mlgns   1/1     Running   0          47s

Тепер застосуйте патч до Deployment з прапорцем --subresource=[імʼя-субресурсу]:

kubectl patch deployment nginx-deployment --subresource='scale' --type='merge' -p '{"spec":{"replicas":3}}'

Вивід:

scale.autoscaling/nginx-deployment patched

Перегляньте Podʼи, повʼязані з вашим Deployment після патчу:

kubectl get pods -l app=nginx

У виводі ви можете побачити, що було створено один новий Pod, тепер у вас є 3 запущені Podʼи.

NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-7fb96c846b-22567   1/1     Running   0          107s
nginx-deployment-7fb96c846b-lxfr2   1/1     Running   0          14s
nginx-deployment-7fb96c846b-mlgns   1/1     Running   0          107s

Перегляньте Deployment після патчу:

kubectl get deployment nginx-deployment -o yaml
...
spec:
  replicas: 3
  ...
status:
  ...
  availableReplicas: 3
  readyReplicas: 3
  replicas: 3

Підсумки

У цій вправі ви використали kubectl patch, щоб змінити поточну конфігурацію обʼєкта Deployment. Ви не змінювали файл конфігурації, який ви спочатку використовували для створення обʼєкта Deployment. Інші команди для оновлення обʼєктів API включають kubectl annotate, kubectl edit, kubectl replace, kubectl scale, та kubectl apply.

Що далі

4.5.6 - Міграція обʼєктів Kubernetes за допомогою міграції версій сховища

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.30 [alpha]

Kubernetes покладається на активне переписування даних API, щоб підтримувати деякі дії обслуговування, повʼязані зі збереженням у спокої. Два видатні приклади цього — це версійна схема збережених ресурсів (тобто зміна перевіреної схеми збереження від v1 до v2 для певного ресурсу) та шифрування у спокої (тобто перезапис старих даних на основі зміни у способі шифрування даних).

Перш ніж ви розпочнете

Встановіть kubectl.

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Версія вашого Kubernetes сервера має бути не старішою ніж v1.30. Для перевірки версії введіть kubectl version.

Переконайтеся, що у вашому кластері увімкнено функціональні можливості StorageVersionMigrator та InformerResourceVersion. Для внесення цих змін вам знадобиться доступ адміністратора панелі управління.

Увімкніть REST API для міграції версій сховища, встановивши параметр конфігурації storagemigration.k8s.io/v1alpha1 на true для API-сервера. Для отримання додаткової інформації про те, як це зробити, прочитайте увімкнення або вимкнення API Kubernetes.

Перешифрування Secret Kubernetes за допомогою міграції версій сховища

  • Для початку, налаштуйте постачальника KMS для шифрування даних у спокої в etcd, використовуючи наступну конфігурацію шифрування.

    kind: EncryptionConfiguration
    apiVersion: apiserver.config.k8s.io/v1
    resources:
    - resources:
      - secrets
      providers:
      - aescbc:
        keys:
        - name: key1
          secret: c2VjcmV0IGlzIHNlY3VyZQ==
    

    Переконайтеся, що автоматичне перезавантаження конфігурації шифрування встановлено на значення true, встановивши --encryption-provider-config-automatic-reload.

  • Створіть Secret за допомогою kubectl.

    kubectl create secret generic my-secret --from-literal=key1=supersecret
    
  • Перевірте серіалізовані дані для цього обʼєкта Secret, що починаються з k8s:enc:aescbc:v1:key1.

  • Оновіть файл конфігурації шифрування наступним чином, щоб виконати ротацію ключа шифрування.

    kind: EncryptionConfiguration
    apiVersion: apiserver.config.k8s.io/v1
    resources:
    - resources:
      - secrets
      providers:
      - aescbc:
        keys:
        - name: key2
          secret: c2VjcmV0IGlzIHNlY3VyZSwgaXMgaXQ/
      - aescbc:
        keys:
        - name: key1
          secret: c2VjcmV0IGlzIHNlY3VyZQ==
    
  • Щоб переконатися, що раніше створений секрет my-secret зашифровано новим ключем key2, ви будете використовувати Storage Version Migration.

  • Створіть маніфест StorageVersionMigration з назвою migrate-secret.yaml, наступного змісту:

    kind: StorageVersionMigration
    apiVersion: storagemigration.k8s.io/v1alpha1
    metadata:
      name: secrets-migration
    spec:
      resource:
        group: ""
        version: v1
        resource: secrets
    

    Створіть обʼєкт за допомогою kubectl наступним чином:

    kubectl apply -f migrate-secret.yaml
    
  • Спостерігайте за міграцією Secret, перевіряючи .status обʼєкта StorageVersionMigration. Успішна міграція повинна мати умову Succeeded встановлену на true. Отримайте обʼєкт StorageVersionMigration наступним чином:

    kubectl get storageversionmigration.storagemigration.k8s.io/secrets-migration -o yaml
    

    Вивід буде подібним до:

    kind: StorageVersionMigration
    apiVersion: storagemigration.k8s.io/v1alpha1
    metadata:
      name: secrets-migration
      uid: 628f6922-a9cb-4514-b076-12d3c178967c
      resourceVersion: "90"
      creationTimestamp: "2024-03-12T20:29:45Z"
    spec:
      resource:
        group: ""
        version: v1
        resource: secrets
    status:
      conditions:
      - type: Running
        status: "False"
        lastUpdateTime: "2024-03-12T20:29:46Z"
        reason: StorageVersionMigrationInProgress
      - type: Succeeded
        status: "True"
        lastUpdateTime: "2024-03-12T20:29:46Z"
        reason: StorageVersionMigrationSucceeded
      resourceVersion: "84"
    
  • Перевірте збережений Secret тепер починається з k8s:enc:aescbc:v1:key2.

Оновлення бажаної схеми зберігання CRD

Розгляньте сценарій, де створено CustomResourceDefinition (CRD), щоб обслуговувати власні ресурси (CR), і встановлено як бажана схема сховища. Коли настане час ввести v2 CRD, його можна додати для обслуговування лише з вебхуком. Це дозволяє плавний перехід, де користувачі можуть створювати CR за допомогою схеми v1 або v2, з вкбхуком, що виконує необхідну конвертацію схеми між ними. Перш ніж встановити v2 як бажану версію схеми сховища, важливо переконатися, що всі наявні CR, збережені як v1, мігрували на v2. Ця міграція може бути досягнута через Storage Version Migration для міграції всіх CR від v1 до v2.

  • Створіть маніфест для CRD з назвою test-crd.yaml, наступного змісту:

    apiVersion: apiextensions.k8s.io/v1
    kind: CustomResourceDefinition
    metadata:
      name: selfierequests.stable.example.com
    spec:
      group: stable.example.com
      names:
        plural: SelfieRequests
        singular: SelfieRequest
        kind: SelfieRequest
        listKind: SelfieRequestList
      scope: Namespaced
      versions:
      - name: v1
        served: true
        storage: true
        schema:
          openAPIV3Schema:
            type: object
            properties:
              hostPort:
                type: string
      conversion:
        strategy: Webhook
        webhook:
          clientConfig:
            url: "https://127.0.0.1:9443/crdconvert"
            caBundle: <Інформація про CA Bundle>
        conversionReviewVersions:
        - v1
        - v2
    

    Створіть CRD за допомогою kubectl:

    kubectl apply -f test-crd.yaml
    
  • Створіть маніфест для прикладу testcrd. Назва маніфесту — cr1.yaml, з наступним змістом:

    apiVersion: stable.example.com/v1
    kind: SelfieRequest
    metadata:
      name: cr1
      namespace: default
    

    Створіть CR за допомогою kubectl:

    kubectl apply -f cr1.yaml
    
  • Перевірте, що CR записано і збережено як v1, отримавши обʼєкт з etcd.

    ETCDCTL_API=3 etcdctl get /kubernetes.io/stable.example.com/testcrds/default/cr1 [...] | hexdump -C
    

    де [...] містить додаткові аргументи для підключення до сервера etcd.

  • Оновіть CRD test-crd.yaml, щоб додати версію v2 для обслуговування і сховища, а також v1 як обслуговування тільки, наступним чином:

    apiVersion: apiextensions.k8s.io/v1
    kind: CustomResourceDefinition
    metadata:
    name: selfierequests.stable.example.com
    spec:
      group: stable.example.com
      names:
        plural: SelfieRequests
        singular: SelfieRequest
        kind: SelfieRequest
        listKind: SelfieRequestList
      scope: Namespaced
      versions:
        - name: v2
          served: true
          storage: true
          schema:
            openAPIV3Schema:
              type: object
              properties:
                host:
                  type: string
                port:
                  type: string
        - name: v1
          served: true
          storage: false
          schema:
            openAPIV3Schema:
              type: object
              properties:
                hostPort:
                  type: string
      conversion:
        strategy: Webhook
        webhook:
          clientConfig:
            url: "https://127.0.0.1:9443/crdconvert"
            caBundle: <Інформація про CA Bundle>
          conversionReviewVersions:
            - v1
            - v2
    

    Оновіть CRD за допомогою kubectl:

    kubectl apply -f test-crd.yaml
    
  • Створіть файл ресурсу CR з назвою cr2.yaml наступного змісту:

    apiVersion: stable.example.com/v2
    kind: SelfieRequest
    metadata:
      name: cr2
      namespace: default
    
  • Створіть CR за допомогою kubectl:

    kubectl apply -f cr2.yaml
    
  • Перевірте, що CR записано і збережено як v2, отримавши обʼєкт з etcd.

    ETCDCTL_API=3 etcdctl get /kubernetes.io/stable.example.com/testcrds/default/cr2 [...] | hexdump -C
    

    де [...] містить додаткові аргументи для підключення до сервера etcd.

  • Створіть маніфест міграції версії сховища з назвою migrate-crd.yaml, з наступним

змістом:

kind: StorageVersionMigration
apiVersion: storagemigration.k8s.io/v1alpha1
metadata:
  name: crdsvm
spec:
  resource:
    group: stable.example.com
    version: v1
    resource: SelfieRequest

Створіть обʼєкт за допомогою kubectl наступним чином:

kubectl apply -f migrate-crd.yaml
  • Спостерігайте за міграцією Secretʼів, використовуючи статус. Успішна міграція повинна мати умову Succeeded, встановлену на "True" у полі статусу. Отримайте ресурс міграції наступним чином:

    kubectl get storageversionmigration.storagemigration.k8s.io/crdsvm -o yaml
    

    Виведення буде подібним до:

    kind: StorageVersionMigration
    apiVersion: storagemigration.k8s.io/v1alpha1
    metadata:
      name: crdsvm
      uid: 13062fe4-32d7-47cc-9528-5067fa0c6ac8
      resourceVersion: "111"
      creationTimestamp: "2024-03-12T22:40:01Z"
    spec:
      resource:
        group: stable.example.com
        version: v1
        resource: testcrds
    status:
      conditions:
        - type: Running
          status: "False"
          lastUpdateTime: "2024-03-12T22:40:03Z"
          reason: StorageVersionMigrationInProgress
        - type: Succeeded
          status: "True"
          lastUpdateTime: "2024-03-12T22:40:03Z"
          reason: StorageVersionMigrationSucceeded
      resourceVersion: "106"
    
  • Перевірте, що раніше створений cr1 тепер записано і збережено як v2, отримавши обʼєкт з etcd.

    ETCDCTL_API=3 etcdctl get /kubernetes.io/stable.example.com/testcrds/default/cr1 [...] | hexdump -C
    

    де [...] містить додаткові аргументи для підключення до сервера etcd.

4.6 - Керування Secret

Керування конфіденційними налаштуваннями за допомогою Secret.

4.6.1 - Керування Secret за допомогою kubectl

Створення обʼєктів Secret за допомогою інструменту командного рядка kubectl.

На цій сторінці ви дізнаєтесь, як створювати, редагувати, керувати та видаляти Secret Kubernetes за допомогою інструменту командного рядка kubectl.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Створення Secret

Обʼєкт Secret зберігає конфіденційні дані, такі як облікові дані, які використовуються потоками для доступу до служб. Наприклад, вам може знадобитися Secret для зберігання імені користувача та пароля, необхідних для доступу до бази даних.

Ви можете створити Secret, передаючи необроблену інформацію у команді, або зберігаючи облікові дані у файлах, які ви передаєте в команді. Наступні команди створюють Secret, який зберігає імʼя користувача admin та пароль S!B\*d$zDsb=.

Використання необробленої інформації

Виконайте наступну команду:

kubectl create secret generic db-user-pass \
    --from-literal=username=admin \
    --from-literal=password='S!B\*d$zDsb='

Вам потрібно використовувати одинарні лапки '', щоб екранувати спеціальні символи, такі як $, \, *, =, і ! у вашому рядку. Якщо ви цього не зробите, ваша оболонка буде інтерпретувати ці символи відповідним чином.

Використання сирцевих файлів

  1. Збережіть облікові дані у файлах:

    echo -n 'admin' > ./username.txt
    echo -n 'S!B\*d$zDsb=' > ./password.txt
    

    Прапорець -n гарантує, що згенеровані файли не матимуть додаткового символу нового рядка в кінці тексту. Це важливо, оскільки коли kubectl зчитує файл і кодує вміст у рядок base64, додатковий символ нового рядка також буде закодований. Вам не потрібно екранувати спеціальні символи у рядках, які ви включаєте в файл.

  2. Передайте шляхи до файлів у команду kubectl:

    kubectl create secret generic db-user-pass \
        --from-file=./username.txt \
        --from-file=./password.txt
    

    Стандартне імʼя ключа — це назва файлу. За потреби ви можете встановити імʼя ключа за допомогою --from-file=[key=]source. Наприклад:

    kubectl create secret generic db-user-pass \
        --from-file=username=./username.txt \
        --from-file=password=./password.txt
    

Не важливо який метод буде використаний вивід буде подібний до:

secret/db-user-pass created

Перевірка Secret

Перевірте, що Secret був створений:

kubectl get secrets

Вивід буде подібний до:

NAME              TYPE       DATA      AGE
db-user-pass      Opaque     2         51s

Перегляньте деталі Secret:

kubectl describe secret db-user-pass

Вивід буде подібний до:

Name:            db-user-pass
Namespace:       default
Labels:          <none>
Annotations:     <none>

Type:            Opaque

Data
====
password:    12 bytes
username:    5 bytes

Команди kubectl get та kubectl describe стандартно уникають показу вмісту Secret. Це зроблено для захисту Secret від випадкового розкриття або збереження в журналі термінала.

Розкодування Secret

  1. Перегляньте вміст створеного вами Secret:

    kubectl get secret db-user-pass -o jsonpath='{.data}'
    

    Вивід буде подібний до:

    { "password": "UyFCXCpkJHpEc2I9", "username": "YWRtaW4=" }
    
  2. Розкодуйте дані password:

    echo 'UyFCXCpkJHpEc2I9' | base64 --decode
    

    Вивід буде подібний до:

    S!B\*d$zDsb=
    
    kubectl get secret db-user-pass -o jsonpath='{.data.password}' | base64 --decode
    

Редагування Secret

Ви можете редагувати наявний обʼєкт Secret, якщо він не є незмінним. Щоб редагувати Secret, виконайте наступну команду:

kubectl edit secrets <secret-name>

Це відкриває ваш стандартний редактор і дозволяє оновити значення Secret, закодовані в base64, у полі data, як у наступному прикладі:

# Будь ласка, відредагуйте обʼєкт нижче. Рядки, що починаються з '#', будуть ігноруватися,
# і порожній файл припинить редагування. Якщо виникне помилка під час збереження цього файлу, він буде
# знову відкритий з відповідними збоями.
#
apiVersion: v1
data:
  password: UyFCXCpkJHpEc2I9
  username: YWRtaW4=
kind: Secret
metadata:
  creationTimestamp: "2022-06-28T17:44:13Z"
  name: db-user-pass
  namespace: default
  resourceVersion: "12708504"
  uid: 91becd59-78fa-4c85-823f-6d44436242ac
type: Opaque

Прибирання

Щоб видалити Secret, виконайте наступну команду:

kubectl delete secret db-user-pass

Що далі

4.6.2 - Керування Secret за допомогою конфігураційного файлу

Створення обʼєктів Secret за допомогою конфігураційного файлу ресурсів.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Створення Secret

Ви можете спочатку визначити обʼєкт Secret у форматі JSON або YAML у маніфесті, а потім створити цей обʼєкт. Ресурс Secret містить два словники: data та stringData. Поле data використовується для зберігання довільних даних, закодованих за допомогою base64. Поле stringData надається для зручності, і воно дозволяє вам надавати ті самі дані у вигляді незакодованих рядків. Ключі data та stringData повинні складатися з буквено-цифрових символів, -, _ або ..

Наведений нижче приклад зберігає два рядки у Secret, використовуючи поле data.

  1. Конвертуйте рядки в base64:

    echo -n 'admin' | base64
    echo -n '1f2d1e2e67df' | base64
    

    Вивід буде подібний до:

    YWRtaW4=
    MWYyZDFlMmU2N2Rm
    
  2. Створіть маніфест:

    apiVersion: v1
    kind: Secret
    metadata:
      name: mysecret
    type: Opaque
    data:
      username: YWRtaW4=
      password: MWYyZDFlMmU2N2Rm
    

    Зверніть увагу, що імʼя обʼєкта Secret повинно бути дійсним піддоменом DNS.

  3. Створіть Secret, використовуючи kubectl apply:

    kubectl apply -f ./secret.yaml
    

    Вивід буде подібний до:

    secret/mysecret created
    

Щоб перевірити, що Secret був створений та щоб розкодувати дані Secret, див. Керування Secret за допомогою kubectl.

Вказання незакодованих даних під час створення Secret

Для певних сценаріїв можливо вам захочеться використовувати поле stringData. Це поле дозволяє вам розміщувати незакодований рядок безпосередньо у Secret, і цей рядок буде закодований за вас при створенні або оновленні Secret.

Практичний приклад цього може бути там, де ви розгортаєте застосунок, що використовує Secret для зберігання файлу конфігурації, і ви хочете заповнити частини цього файлу конфігурації під час процесу розгортання.

Наприклад, якщо ваш застосунок використовує такий файл конфігурації:

apiUrl: "https://my.api.com/api/v1"
username: "<user>"
password: "<password>"

Ви можете зберегти це в Secret, використовуючи таке визначення:

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
stringData:
  config.yaml: |
    apiUrl: "https://my.api.com/api/v1"
    username: <user>
    password: <password>    

При отриманні даних Secret, команда повертає закодовані значення, а не текстові значення, які ви вказали у stringData.

Наприклад, якщо ви виконаєте наступну команду:

kubectl get secret mysecret -o yaml

Вивід буде подібний до:

apiVersion: v1
data:
  config.yaml: YXBpVXJsOiAiaHR0cHM6Ly9teS5hcGkuY29tL2FwaS92MSIKdXNlcm5hbWU6IHt7dXNlcm5hbWV9fQpwYXNzd29yZDoge3twYXNzd29yZH19
kind: Secret
metadata:
  creationTimestamp: 2018-11-15T20:40:59Z
  name: mysecret
  namespace: default
  resourceVersion: "7225"
  uid: c280ad2e-e916-11e8-98f2-025000000001
type: Opaque

Вказання як data, так і stringData

Якщо ви вказали поле як у data, так і у stringData, буде використано значення з stringData.

Наприклад, якщо ви визначите наступний секрет:

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  username: YWRtaW4=
stringData:
  username: administrator

Обʼєкт Secret буде створено так:

apiVersion: v1
data:
  username: YWRtaW5pc3RyYXRvcg==
kind: Secret
metadata:
  creationTimestamp: 2018-11-15T20:46:46Z
  name: mysecret
  namespace: default
  resourceVersion: "7579"
  uid: 91460ecb-e917-11e8-98f2-025000000001
type: Opaque

YWRtaW5pc3RyYXRvcg== декодується у administrator.

Редагування Secret

Щоб редагувати дані у Secret, створеному за допомогою маніфесту, змініть поле data або stringData у вашому маніфесті та застосуйте файл у вашому кластері. Ви можете редагувати наявний обʼєкт Secret, за винятком випадку, коли він є незмінним.

Наприклад, якщо ви хочете змінити пароль з попереднього прикладу на birdsarentreal, виконайте наступне:

  1. Закодуйте новий рядок пароля:

    echo -n 'birdsarentreal' | base64
    

    Вивід буде подібний до:

    YmlyZHNhcmVudHJlYWw=
    
  2. Оновіть поле data із вашим новим рядком пароля:

    apiVersion: v1
    kind: Secret
    metadata:
      name: mysecret
    type: Opaque
    data:
      username: YWRtaW4=
      password: YmlyZHNhcmVudHJlYWw=
    
  3. Застосуйте маніфест у вашому кластері:

    kubectl apply -f ./secret.yaml
    

    Вивід буде подібний до:

    secret/mysecret configured
    

Kubernetes оновлює наявний обʼєкт Secret. Докладно, інструмент kubectl помічає, що є обʼєкт Secret з тим самим імʼям. kubectl отримує поточний обʼєкт, планує зміни в ньому і надсилає змінений обʼєкт Secret до панелі управління кластера.

Якщо ви вказали kubectl apply --server-side, kubectl використовує застосування на боці сервера замість цього.

Прибирання

Щоб видалити створений вами Secret:

kubectl delete secret mysecret

Що далі

4.6.3 - Керування Secret за допомогою Kustomize

Створення обʼєктів Secret за допомогою файлу kustomization.yaml.

kubectl підтримує використання інструменту керування обʼєктами Kustomize для керування Secret та ConfigMap. Ви можете створити генератор ресурсів за допомогою Kustomize, який створює Secret, який ви можете застосувати до сервера API за допомогою kubectl.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Створення Secret

Ви можете створити Secret, визначивши secretGenerator у файлі kustomization.yaml, який посилається на інші наявні файли, файли .env або літеральні значення. Наприклад, наведені нижче інструкції створюють файл конфігурації kustomization для імені користувача admin та пароля 1f2d1e2e67df.

Створення файлу kustomization


secretGenerator:
- name: database-creds
  literals:
  - username=admin
  - password=1f2d1e2e67df

  1. Збережіть дані доступу у файлах. Назви файлів є ключами секрету:

    echo -n 'admin' > ./username.txt
    echo -n '1f2d1e2e67df' > ./password.txt
    

    Прапорець -n забезпечує відсутність символу нового рядка в кінці ваших файлів.

  2. Створіть файл kustomization.yaml:

    secretGenerator:
    - name: database-creds
      files:
      - username.txt
      - password.txt
    

Ви також можете визначити secretGenerator у файлі kustomization.yaml, надаючи файли .env. Наприклад, наступний файл kustomization.yaml використовує дані з файлу .env.secret:

secretGenerator:
- name: db-user-pass
  envs:
  - .env.secret

У всіх випадках вам не потрібно кодувати значення base64. Імʼя YAML файлу має бути kustomization.yaml або kustomization.yml.

Застосування файлу kustomization

Для створення Secret застосуйте теку, який містить файл kustomization:

kubectl apply -k <directory-path>

Вивід буде подібний до:

secret/database-creds-5hdh7hhgfk created

Коли Secret генерується, імʼя Secret створюється шляхом хешування даних Secret і додавання до нього значення хешу. Це забезпечує, що при зміні даних генерується новий Secret.

Щоб перевірити, що Secret був створений та розкодувати дані Secret,

kubectl get -k <directory-path> -o jsonpath='{.data}' 

Вивід буде подібний до:

{ "password": "MWYyZDFlMmU2N2Rm", "username": "YWRtaW4=" }
echo 'MWYyZDFlMmU2N2Rm' | base64 --decode

Вивід буде подібний до:

1f2d1e2e67df

Для отримання додаткової інформації див. Керування Secret за допомогою kubectl та Декларативне керування обʼєктами Kubernetes за допомогою Kustomize.

Редагування Secret

  1. У вашому файлі kustomization.yaml змініть дані, наприклад, password.

  2. Застосуйте теку, який містить файл kustomization:

    kubectl apply -k <directory-path>
    

    Вивід буде подібний до:

    secret/db-user-pass-6f24b56cc8 created
    

Змінений Secret створюється як новий обʼєкт Secret, а не оновлюється наявний обʼєкт Secret. Можливо, вам знадобиться оновити посилання на Secret у ваших контейнерах.

Прибирання

Для видалення Secret використовуйте kubectl:

kubectl delete secret db-user-pass

Що далі

4.7 - Введення даних у застосунки

Визначення конфігурації та інших даних для Podʼів, на яких працює ваше навантаження.

4.7.1 - Визначення команд та аргументів для контейнера

Ця сторінка показує, як визначати команди та аргументи при запуску контейнера в Pod.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Для перевірки версії введіть kubectl version.

Визначення команди та аргументів при створенні Podʼа

При створенні Podʼа ви можете визначити команду та аргументи для контейнерів, які працюють в Podʼі. Щоб визначити команду, включіть поле command у файл конфігурації. Щоб визначити аргументи для команди, включіть поле args у файл конфігурації. Команду та аргументи, які ви визначаєте, не можна змінити після створення Podʼа.

Команда та аргументи, які ви визначаєте у файлі конфігурації, перевизначають станадртну команду та аргументи, надані образом контейнера. Якщо ви визначаєте аргументи, але не визначаєте команду, використовується стандартна команда з вашими новими аргументами.

У цьому завданні ви створюєте Pod, який запускає один контейнер. Файл конфігурації для Podʼа визначає команду та два аргументи:

apiVersion: v1
kind: Pod
metadata:
  name: command-demo
  labels:
    purpose: demonstrate-command
spec:
  containers:
  - name: command-demo-container
    image: debian
    command: ["printenv"]
    args: ["HOSTNAME", "KUBERNETES_PORT"]
  restartPolicy: OnFailure
  1. Створіть Podʼ на основі файлу конфігурації YAML:

    kubectl apply -f https://k8s.io/examples/pods/commands.yaml
    
  2. Перегляньте список запущених Podʼів:

    kubectl get pods
    

    Вивід показує, що контейнер, який працював у Podʼі command-demo, завершився.

  3. Щоб побачити вивід команди, яка запустилася в контейнері, перегляньте логи з Podʼа:

    kubectl logs command-demo
    

    Вивід показує значення змінних середовища HOSTNAME та KUBERNETES_PORT:

    command-demo
    tcp://10.3.240.1:443
    

Використання змінних середовища для визначення аргументів

У попередньому прикладі ви визначили аргументи безпосередньо, надавши їх. Як альтернативу наданню рядків безпосередньо, ви можете визначати аргументи, використовуючи змінні середовища:

env:
- name: MESSAGE
  value: "hello world"
command: ["/bin/echo"]
args: ["$(MESSAGE)"]

Це означає, що ви можете визначити аргумент для Podʼа, використовуючи будь-які з технік доступних для визначення змінних середовища, включаючи ConfigMap та Secret.

Виконання команди в оболонці

У деяких випадках вам потрібно, щоб ваша команда запускалася в оболонці. Наприклад, ваша команда може складатися з кількох команд, обʼєднаних в конвеєр, або це може бути сценарій оболонки. Щоб запустити вашу команду в оболонці, оберніть її так:

command: ["/bin/sh"]
args: ["-c", "while true; do echo hello; sleep 10;done"]

Що далі

4.7.2 - Визначення залежних змінних середовища

Ця сторінка показує, як визначати залежні змінні середовища для контейнера у Podʼі Kubernetes.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Визначення змінної залежної від середовища для контейнера

При створенні Podʼа ви можете встановлювати залежні змінні середовища для контейнерів, які працюють в Podʼі. Для встановлення залежних змінних середовища ви можете використовувати $(VAR_NAME) у value env у файлі конфігурації.

У цьому завданні ви створюєте Pod, який запускає один контейнер. Файл конфігурації для Podʼа визначає залежну змінну середовища з визначеним загальним використанням. Ось маніфест конфігурації для Podʼа:

apiVersion: v1
kind: Pod
metadata:
  name: dependent-envars-demo
spec:
  containers:
    - name: dependent-envars-demo
      args:
        - while true; do echo -en '\n'; printf UNCHANGED_REFERENCE=$UNCHANGED_REFERENCE'\n'; printf SERVICE_ADDRESS=$SERVICE_ADDRESS'\n';printf ESCAPED_REFERENCE=$ESCAPED_REFERENCE'\n'; sleep 30; done;
      command:
        - sh
        - -c
      image: busybox:1.28
      env:
        - name: SERVICE_PORT
          value: "80"
        - name: SERVICE_IP
          value: "172.17.0.1"
        - name: UNCHANGED_REFERENCE
          value: "$(PROTOCOL)://$(SERVICE_IP):$(SERVICE_PORT)"
        - name: PROTOCOL
          value: "https"
        - name: SERVICE_ADDRESS
          value: "$(PROTOCOL)://$(SERVICE_IP):$(SERVICE_PORT)"
        - name: ESCAPED_REFERENCE
          value: "$$(PROTOCOL)://$(SERVICE_IP):$(SERVICE_PORT)"
  1. Створіть Podʼ на основі цього маніфесту:

    kubectl apply -f https://k8s.io/examples/pods/inject/dependent-envars.yaml
    
    pod/dependent-envars-demo created
    
  2. Перегляньте список запущених Podʼів:

    kubectl get pods dependent-envars-demo
    
    NAME                      READY     STATUS    RESTARTS   AGE
    dependent-envars-demo     1/1       Running   0          9s
    
  3. Перевірте лог контейнера, що працює у вашому Podʼі:

    kubectl logs pod/dependent-envars-demo
    
    UNCHANGED_REFERENCE=$(PROTOCOL)://172.17.0.1:80
    SERVICE_ADDRESS=https://172.17.0.1:80
    ESCAPED_REFERENCE=$(PROTOCOL)://172.17.0.1:80
    

Як показано вище, ви визначили правильне посилання на залежність SERVICE_ADDRESS, неправильне посилання на залежність UNCHANGED_REFERENCE і пропустили залежні посилання на залежність ESCAPED_REFERENCE.

Коли змінна середовища вже визначена при посиланні, посилання може бути правильно розгорнуте, як у випадку з SERVICE_ADDRESS.

Зверніть увагу, що порядок має значення у списку env. Змінна середовища не вважається "визначеною", якщо вона вказана далі в списку. Тому UNCHANGED_REFERENCE не вдається розгорнути $(PROTOCOL) у прикладі вище.

Коли змінна середовища невизначена або містить лише деякі змінні, невизначена змінна середовища трактується як звичайний рядок, як у випадку з UNCHANGED_REFERENCE. Зверніть увагу, що неправильно опрацьовані змінні середовища, як правило, не блокують запуск контейнера.

Синтаксис $(VAR_NAME) може бути екранований подвійним $, тобто: $$(VAR_NAME). Екрановані посилання ніколи не розгортаються, незалежно від того, чи визначена посилана змінна, чи ні. Це можна побачити у випадку з ESCAPED_REFERENCE вище.

Що далі

4.7.3 - Визначення змінних середовища для контейнера

Ця сторінка показує, як визначити змінні середовища для контейнера у Kubernetes Pod.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Визначення змінної середовища для контейнера

При створенні Pod ви можете задати змінні середовища для контейнерів, які запускаються в Pod. Щоб задати змінні середовища, включіть поле env або envFrom у файлі конфігурації.

Поля env та envFrom мають різний ефект.

env
дозволяє вам задати змінні середовища для контейнера, вказуючи значення безпосередньо для кожної змінної, яку ви називаєте.
envFrom
дозволяє вам задати змінні середовища для контейнера, посилаючись на ConfigMap або Secret. Коли ви використовуєте envFrom, всі пари ключ-значення у зазначеному ConfigMap або Secret встановлюються як змінні середовища для контейнера. Ви також можете вказати спільний префіксовий рядок.

Докладніше про ConfigMap та Secret.

Ця сторінка пояснює, як використовувати env.

У цьому завданні ви створюєте Pod, який запускає один контейнер. Конфігураційний файл для Pod визначає змінну середовища з імʼям DEMO_GREETING та значенням "Привіт із середовища". Ось маніфест конфігурації для Pod:

apiVersion: v1
kind: Pod
metadata:
  name: envar-demo
  labels:
    purpose: demonstrate-envars
spec:
  containers:
  - name: envar-demo-container
    image: gcr.io/google-samples/hello-app:2.0
    env:
    - name: DEMO_GREETING
      value: "Hello from the environment"
    - name: DEMO_FAREWELL
      value: "Such a sweet sorrow"
  1. Створіть Pod на основі цього маніфесту:

    kubectl apply -f https://k8s.io/examples/pods/inject/envars.yaml
    
  2. Перегляньте перелік запущених Podʼів:

    kubectl get pods -l purpose=demonstrate-envars
    

    Вивід буде подібний до:

    NAME            READY     STATUS    RESTARTS   AGE
    envar-demo      1/1       Running   0          9s
    
  3. Перегляньте змінні середовища контейнера Pod:

    kubectl exec envar-demo -- printenv
    

    Вивід буде подібний до такого:

    NODE_VERSION=4.4.2
    EXAMPLE_SERVICE_PORT_8080_TCP_ADDR=10.3.245.237
    HOSTNAME=envar-demo
    ...
    DEMO_GREETING=Привіт із середовища
    DEMO_FAREWELL=Такий солодкий прощальний слова
    

Використання змінних середовища у вашій конфігурації

Змінні середовища, які ви визначаєте у конфігурації Pod у .spec.containers[*].env[*], можна використовувати в інших частинах конфігурації, наприклад, у командах та аргументах, які ви задаєте для контейнерів Pod. У наступній конфігурації прикладу, змінні середовища GREETING, HONORIFIC та NAME встановлені на Warm greetings to, The Most Honorable та Kubernetes відповідно. Змінна середовища MESSAGE комбінує набір усіх цих змінних середовища, а потім використовує їх як аргумент командного рядка, переданий контейнеру env-print-demo.

Імена змінних середовища складаються з літер, цифр, підкреслення, крапок або дефісів, але перший символ не може бути цифрою. Якщо ввімкнуто функціональну можливість RelaxedEnvironmentVariableValidation, можна використовувати всі друковані символи ASCII, окрім "=" для імен змінних середовища.

apiVersion: v1
kind: Pod
metadata:
  name: print-greeting
spec:
  containers:
  - name: env-print-demo
    image: bash
    env:
    - name: GREETING
      value: "Warm greetings to"
    - name: HONORIFIC
      value: "The Most Honorable"
    - name: NAME
      value: "Kubernetes"
    - name: MESSAGE
      value: "$(GREETING) $(HONORIFIC) $(NAME)"
    command: ["echo"]
    args: ["$(MESSAGE)"]

Після створення команда echo Warm greetings to The Most Honorable Kubernetes виконується в контейнері.

Що далі

4.7.4 - Використання змінних середовища для передачі контейнерам інформації про Pod

Ця сторінка показує, як Pod може використовувати змінні середовища для передачі інформації про себе контейнерам, які працюють в Pod, використовуючи downward API. Ви можете використовувати змінні середовища для експозиції полів Pod, полів контейнера або обох.

У Kubernetes є два способи експозиції полів Pod та контейнера для запущеного контейнера:

  • Змінні середовища, як пояснено в цьому завданні
  • Файли томів

Разом ці два способи експозиції полів Pod та контейнера називаються downward API.

Оскільки Service є основним засобом взаємодії між контейнеризованими застосунками, якими керує Kubernetes, корисно мати можливість виявляти їх під час виконання.

Дізнайтеся більше про доступ до Сервісів тут.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Використання полів Pod як значень для змінних середовища

У цій частині завдання ви створюєте Pod з одним контейнером, і ви спроєцюєте поля рівня Pod у працюючий контейнер у вигляді змінних середовища.

apiVersion: v1
kind: Pod
metadata:
  name: dapi-envars-fieldref
spec:
  containers:
    - name: test-container
      image: registry.k8s.io/busybox
      command: [ "sh", "-c"]
      args:
      - while true; do
          echo -en '\n';
          printenv MY_NODE_NAME MY_POD_NAME MY_POD_NAMESPACE;
          printenv MY_POD_IP MY_POD_SERVICE_ACCOUNT;
          sleep 10;
        done;
      env:
        - name: MY_NODE_NAME
          valueFrom:
            fieldRef:
              fieldPath: spec.nodeName
        - name: MY_POD_NAME
          valueFrom:
            fieldRef:
              fieldPath: metadata.name
        - name: MY_POD_NAMESPACE
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace
        - name: MY_POD_IP
          valueFrom:
            fieldRef:
              fieldPath: status.podIP
        - name: MY_POD_SERVICE_ACCOUNT
          valueFrom:
            fieldRef:
              fieldPath: spec.serviceAccountName
  restartPolicy: Never

У цьому маніфесті ви бачите пʼять змінних середовища. Поле env є масивом визначень змінних середовища. Перший елемент у масиві вказує, що змінна середовища MY_NODE_NAME отримує своє значення з поля spec.nodeName Pod. Аналогічно, інші змінні середовища отримують свої назви з полів Pod.

Створіть Pod:

kubectl apply -f https://k8s.io/examples/pods/inject/dapi-envars-pod.yaml

Перевірте, що контейнер в Pod працює:

# Якщо новий Pod ще не став доступним, кілька разів перезапустіть цю команду.
kubectl get pods

Перегляньте лог контейнера:

kubectl logs dapi-envars-fieldref

Вивід показує значення вибраних змінних середовища:

minikube
dapi-envars-fieldref
default
172.17.0.4
default

Щоб побачити, чому ці значення є в лозі, подивіться на поля command та args у файлі конфігурації. При запуску контейнера він записує значення пʼяти змінних середовища у stdout. Він повторює це кожні десять секунд.

Далі, отримайте оболонку в контейнер, який працює в вашому Pod:

kubectl exec -it dapi-envars-fieldref -- sh

У вашій оболонці перегляньте змінні середовища:

# Виконайте це в оболонці всередині контейнера
printenv

Вивід показує, що деякі змінні середовища мають призначені значення полів Pod:

MY_POD_SERVICE_ACCOUNT=default
...
MY_POD_NAMESPACE=default
MY_POD_IP=172.17.0.4
...
MY_NODE_NAME=minikube
...
MY_POD_NAME=dapi-envars-fieldref

Використання полів контейнера як значень для змінних середовища

У попередньому завданні ви використовували інформацію з полів рівня Pod як значення для змінних середовища. У наступному завданні ви плануєте передати поля, які є частиною визначення Pod, але взяті з конкретного контейнера замість всього Pod загалом.

Ось маніфест для іншого Pod, який знову має лише один контейнер:

apiVersion: v1
kind: Pod
metadata:
  name: dapi-envars-resourcefieldref
spec:
  containers:
    - name: test-container
      image: registry.k8s.io/busybox:1.24
      command: [ "sh", "-c"]
      args:
      - while true; do
          echo -en '\n';
          printenv MY_CPU_REQUEST MY_CPU_LIMIT;
          printenv MY_MEM_REQUEST MY_MEM_LIMIT;
          sleep 10;
        done;
      resources:
        requests:
          memory: "32Mi"
          cpu: "125m"
        limits:
          memory: "64Mi"
          cpu: "250m"
      env:
        - name: MY_CPU_REQUEST
          valueFrom:
            resourceFieldRef:
              containerName: test-container
              resource: requests.cpu
        - name: MY_CPU_LIMIT
          valueFrom:
            resourceFieldRef:
              containerName: test-container
              resource: limits.cpu
        - name: MY_MEM_REQUEST
          valueFrom:
            resourceFieldRef:
              containerName: test-container
              resource: requests.memory
        - name: MY_MEM_LIMIT
          valueFrom:
            resourceFieldRef:
              containerName: test-container
              resource: limits.memory
  restartPolicy: Never

У цьому маніфесті ви бачите чотири змінні середовища. Поле env є масивом визначень змінних середовища. Перший елемент у масиві вказує, що змінна середовища MY_CPU_REQUEST отримує своє значення з поля requests.cpu контейнера з іменем test-container. Аналогічно, інші змінні середовища отримують свої значення з полів, що є специфічними для цього контейнера.

Створіть Pod:

kubectl apply -f https://k8s.io/examples/pods/inject/dapi-envars-container.yaml

Перевірте, що контейнер в Pod працює:

# Якщо новий Pod ще не став доступним, кілька разів перезапустіть цю команду.
kubectl get pods

Перегляньте лог контейнера:

kubectl logs dapi-envars-resourcefieldref

Вивід показує значення вибраних змінних середовища:

1
1
33554432
67108864

Що далі

Дізнайтеся про Pod, контейнери та змінні середовища в легасі довідці API:

4.7.5 - Передача інформації про Pod контейнерам через файли

Ця сторінка показує, як Pod може використовувати volumeDownwardAPI, щоб передати інформацію про себе контейнерам, які працюють в Pod. volumeDownwardAPI може викривати поля Pod та контейнера.

У Kubernetes є два способи експозиції полів Pod та контейнера для запущеного контейнера:

Разом ці два способи експозиції полів Pod та контейнера називаються downward API.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Зберігання полів Pod

У цій частині завдання ви створюєте Pod з одним контейнером, і ви проєцюєте поля рівня Pod у працюючий контейнер як файли. Ось маніфест для Pod:

apiVersion: v1
kind: Pod
metadata:
  name: kubernetes-downwardapi-volume-example
  labels:
    zone: us-est-coast
    cluster: test-cluster1
    rack: rack-22
  annotations:
    build: two
    builder: john-doe
spec:
  containers:
    - name: client-container
      image: registry.k8s.io/busybox
      command: ["sh", "-c"]
      args:
      - while true; do
          if [[ -e /etc/podinfo/labels ]]; then
            echo -en '\n\n'; cat /etc/podinfo/labels; fi;
          if [[ -e /etc/podinfo/annotations ]]; then
            echo -en '\n\n'; cat /etc/podinfo/annotations; fi;
          sleep 5;
        done;
      volumeMounts:
        - name: podinfo
          mountPath: /etc/podinfo
  volumes:
    - name: podinfo
      downwardAPI:
        items:
          - path: "labels"
            fieldRef:
              fieldPath: metadata.labels
          - path: "annotations"
            fieldRef:
              fieldPath: metadata.annotations

У маніфесті ви бачите, що у Pod є volumeDownwardAPI, і контейнер монтує том за шляхом /etc/podinfo.

Подивіться на масив items під downwardAPI. Кожен елемент масиву визначає volumeDownwardAPI. Перший елемент вказує, що значення поля metadata.labels Pod має бути збережене в файлі з назвою labels. Другий елемент вказує, що значення поля annotations Pod має бути збережене в файлі з назвою annotations.

Створіть Pod:

kubectl apply -f https://k8s.io/examples/pods/inject/dapi-volume.yaml

Перевірте, що контейнер в Pod працює:

kubectl get pods

Перегляньте логи контейнера:

kubectl logs kubernetes-downwardapi-volume-example

Вивід показує вміст файлів labels та annotations:

cluster="test-cluster1"
rack="rack-22"
zone="us-est-coast"

build="two"
builder="john-doe"

Отримайте доступ до оболонки в контейнері, який працює в вашому Pod:

kubectl exec -it kubernetes-downwardapi-volume-example -- sh

У вашій оболонці перегляньте файл labels:

/# cat /etc/podinfo/labels

Вивід показує, що всі мітки Pod були записані у файл labels:

cluster="test-cluster1"
rack="rack-22"
zone="us-est-coast"

Аналогічно, перегляньте файл annotations:

/# cat /etc/podinfo/annotations

Перегляньте файли у теці /etc/podinfo:

/# ls -laR /etc/podinfo

У виводі ви побачите, що файли labels та annotations знаходяться в тимчасовій підтеці: у цьому прикладі, ..2982_06_02_21_47_53.299460680. У теці /etc/podinfo, ..data є символічним посиланням на тимчасову підтеку. Також у теці /etc/podinfo, labels та annotations є символічними посиланнями.

drwxr-xr-x  ... Feb 6 21:47 ..2982_06_02_21_47_53.299460680
lrwxrwxrwx  ... Feb 6 21:47 ..data -> ..2982_06_02_21_47_53.299460680
lrwxrwxrwx  ... Feb 6 21:47 annotations -> ..data/annotations
lrwxrwxrwx  ... Feb 6 21:47 labels -> ..data/labels

/etc/..2982_06_02_21_47_53.299460680:
total 8
-rw-r--r--  ... Feb  6 21:47 annotations
-rw-r--r--  ... Feb  6 21:47 labels

Використання символічних посилань дозволяє динамічне атомарне оновлення метаданих; оновлення записуються у новий тимчасову теку, а символічне посилання ..data оновлюється атомарно за допомогою rename(2).

Вийдіть з оболонки:

/# exit

Зберігання полів контейнера

У попередньому завданні ви зробили поля Pod доступними за допомогою Downward API. У наступній вправі ви передаєте поля, які є частиною визначення Pod, але беруться з конкретного контейнера скоріше, ніж з Pod загалом. Ось маніфест для Pod, що має лише один контейнер:

apiVersion: v1
kind: Pod
metadata:
  name: kubernetes-downwardapi-volume-example-2
spec:
  containers:
    - name: client-container
      image: registry.k8s.io/busybox:1.24
      command: ["sh", "-c"]
      args:
      - while true; do
          echo -en '\n';
          if [[ -e /etc/podinfo/cpu_limit ]]; then
            echo -en '\n'; cat /etc/podinfo/cpu_limit; fi;
          if [[ -e /etc/podinfo/cpu_request ]]; then
            echo -en '\n'; cat /etc/podinfo/cpu_request; fi;
          if [[ -e /etc/podinfo/mem_limit ]]; then
            echo -en '\n'; cat /etc/podinfo/mem_limit; fi;
          if [[ -e /etc/podinfo/mem_request ]]; then
            echo -en '\n'; cat /etc/podinfo/mem_request; fi;
          sleep 5;
        done;
      resources:
        requests:
          memory: "32Mi"
          cpu: "125m"
        limits:
          memory: "64Mi"
          cpu: "250m"
      volumeMounts:
        - name: podinfo
          mountPath: /etc/podinfo
  volumes:
    - name: podinfo
      downwardAPI:
        items:
          - path: "cpu_limit"
            resourceFieldRef:
              containerName: client-container
              resource: limits.cpu
              divisor: 1m
          - path: "cpu_request"
            resourceFieldRef:
              containerName: client-container
              resource: requests.cpu
              divisor: 1m
          - path: "mem_limit"
            resourceFieldRef:
              containerName: client-container
              resource: limits.memory
              divisor: 1Mi
          - path: "mem_request"
            resourceFieldRef:
              containerName: client-container
              resource: requests.memory
              divisor: 1Mi

У маніфесті ви бачите, що у Pod є volumeDownwardAPI, і що контейнер у цьому Pod монтує том за шляхом /etc/podinfo.

Подивіться на масив items під downwardAPI. Кожен елемент масиву визначає файл у томі downward API.

Перший елемент вказує, що в контейнері з назвою client-container, значення поля limits.cpu у форматі, вказаному як 1m, має бути опубліковане як файл з назвою cpu_limit. Поле divisor є необовʼязковим і має стандартне значення 1. Дільник 1 означає ядра для ресурсів cpu, або байти для ресурсів memory.

Створіть Pod:

kubectl apply -f https://k8s.io/examples/pods/inject/dapi-volume-resources.yaml

Отримайте доступ до оболонки в контейнері, який працює в вашому Pod:

kubectl exec -it kubernetes-downwardapi-volume-example-2 -- sh

У вашій оболонці перегляньте файл cpu_limit:

# Виконайте це в оболонці всередині контейнера
cat /etc/podinfo/cpu_limit

Ви можете використовувати подібні команди, щоб переглянути файли cpu_request, mem_limit та mem_request.

Проєцювання ключів на конкретні шляхи та дозволи на файли

Ви можете проєціювати ключі на конкретні шляхи та конкретні дозволи на файл на основі файлу. Для отримання додаткової інформації дивіться Secret.

Що далі

  • Прочитайте spec API-визначення для Pod. Специфікація включає визначення Контейнера (частина Pod).
  • Прочитайте список доступних полів, які ви можете викрити за допомогою downward API.

Дізнайтеся про томи в легасі довідці API:

  • Перегляньте Volume API-визначення, яке визначає загальний том у Pod для доступу контейнерів.
  • Перегляньте DownwardAPIVolumeSource API-визначення, яке визначає том, який містить інформацію Downward API.
  • Перегляньте DownwardAPIVolumeFile API-визначення, яке містить посилання на обʼєкт або поля ресурсу для заповнення файлу у томі Downward API.
  • Перегляньте ResourceFieldSelector API-визначення, яке вказує ресурси контейнера та їх формат виведення.

4.7.6 - Розповсюдження облікових даних з використанням Secret

Ця сторінка показує, як безпечно передати чутливі дані, такі як паролі та ключі шифрування, у Podʼи.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Перетворення ваших секретних даних у base64

Припустимо, ви хочете мати дві частини секретних даних: імʼя користувача my-app та пароль 39528$vdg7Jb. Спочатку використайте інструмент кодування base64, щоб перетворити ваше імʼя користувача та пароль на base64. Ось приклад використання загальнодоступної програми base64:

echo -n 'my-app' | base64
echo -n '39528$vdg7Jb' | base64

Вивід показує, що base64 варіант вашого імені користувача — bXktYXBw, а base64 вашого пароля — Mzk1MjgkdmRnN0pi.

Створіть Secret

Ось файл конфігурації, який ви можете використати для створення Secret, що містить ваше імʼя користувача та пароль:

apiVersion: v1
kind: Secret
metadata:
  name: test-secret
data:
  username: bXktYXBw
  password: Mzk1MjgkdmRnN0pi
  1. Створіть Secret

    kubectl apply -f https://k8s.io/examples/pods/inject/secret.yaml
    
  2. Перегляньте інформацію про Secret:

    kubectl get secret test-secret
    

    Вивід:

    NAME          TYPE      DATA      AGE
    test-secret   Opaque    2         1m
    
  3. Перегляньте більш детальну інформацію про Secret:

    kubectl describe secret test-secret
    

    Вивід:

    Name:       test-secret
    Namespace:  default
    Labels:     <none>
    Annotations:    <none>
    
    Type:   Opaque
    
    Data
    ====
    password:   13 bytes
    username:   7 bytes
    

Створіть Secret безпосередньо за допомогою kubectl

Якщо ви хочете пропустити крок кодування Base64, ви можете створити такий самий Secret, використовуючи команду kubectl create secret. Наприклад:

kubectl create secret generic test-secret --from-literal='username=my-app' --from-literal='password=39528$vdg7Jb'

Це зручніше. Детальний підхід, показаний раніше, розглядає кожен крок явно, щоб продемонструвати, що відбувається.

Створіть Pod, який має доступ до секретних даних через Том

Ось файл конфігурації, який ви можете використати для створення Podʼа:

apiVersion: v1
kind: Pod
metadata:
  name: secret-test-pod
spec:
  containers:
    - name: test-container
      image: nginx
      volumeMounts:
        # ім'я повинно відповідати імені тома нижче
        - name: secret-volume
          mountPath: /etc/secret-volume
          readOnly: true
  # Дані секрету доступні контейнерам у Podʼі через том.
  volumes:
    - name: secret-volume
      secret:
        secretName: test-secret
  1. Створіть Pod:

    kubectl apply -f https://k8s.io/examples/pods/inject/secret-pod.yaml
    
  2. Перевірте, що ваш Pod працює:

    kubectl get pod secret-test-pod
    

    Вивід:

    NAME              READY     STATUS    RESTARTS   AGE
    secret-test-pod   1/1       Running   0          42m
    
  3. Отримайте доступ до оболонки в контейнері, що працює у вашому Podʼі:

    kubectl exec -i -t secret-test-pod -- /bin/bash
    
  4. Секретні дані доступні контейнеру через Том, змонтований у /etc/secret-volume.

    У вашій оболонці перегляньте файли у теці /etc/secret-volume:

    # Виконайте це в оболонці всередині контейнера
    ls /etc/secret-volume
    

    Вивід показує два файли, один для кожної частини секретних даних:

    password username
    
  5. У вашій оболонці gthtukzymnt вміст файлів username та password:

    # Виконайте це в оболонці всередині контейнера
    echo "$( cat /etc/secret-volume/username )"
    echo "$( cat /etc/secret-volume/password )"
    

    Вивід — ваше імʼя користувача та пароль:

    my-app
    39528$vdg7Jb
    

Змініть ваш образ або командний рядок так, щоб програма шукала файли у теці mountPath. Кожен ключ у масиві data Secretʼу стає імʼям файлу у цій теці.

Спроєцюйте ключі Secret на конкретні шляхи файлів

Ви також можете контролювати шляхи в томі, куди проєцюються ключі Secret. Використовуйте поле .spec.volumes[].secret.items, щоб змінити шлях для кожного ключа:

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mypod
    image: redis
    volumeMounts:
    - name: foo
      mountPath: "/etc/foo"
      readOnly: true
  volumes:
  - name: foo
    secret:
      secretName: mysecret
      items:
      - key: username
        path: my-group/my-username

При розгортанні цього Podʼа відбувається наступне:

  • Ключ username з mysecret доступний контейнеру за шляхом /etc/foo/my-group/my-username замість /etc/foo/username.
  • Ключ password з цього Secret не проєцюється.

Якщо ви отримуєте перелік ключів явно за допомогою .spec.volumes[].secret.items, розгляньте наступне:

  • Проєцюються тільки ключі, вказані у items.
  • Щоб використовувати всі ключі з Secret, всі вони повинні бути перераховані у полі items.
  • Усі перераховані ключі повинні існувати у відповідному Secret. Інакше Том не створюється.

Встановіть POSIX-права доступу до ключів Secret

Ви можете встановити POSIX права доступу до файлів для окремого ключа Secret. Якщо ви не вказали жодних дозволів, стандартно використовується 0644. Ви також можете встановити стандартно режим файлу POSIX для всього тому Secret, і ви можете перевизначити його за потреби для кожного ключа.

Наприклад, ви можете вказати режим стандартно так:

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mypod
    image: redis
    volumeMounts:
    - name: foo
      mountPath: "/etc/foo"
  volumes:
  - name: foo
    secret:
      secretName: mysecret
      defaultMode: 0400

Секрет Secret у /etc/foo; всі файли, створені томом секрету, мають дозволи 0400.

Визначте змінні середовища контейнера, використовуючи дані з Secret

Ви можете використовувати дані у Secret як змінні середовища у ваших контейнерах.

Якщо контейнер вже використовує Secret у змінній середовища, оновлення Secret не буде видно контейнеру, якщо він не буде перезапущений. Існують сторонні рішення для виклику перезавантажень, коли змінюються Secret.

Визначення змінної середовища контейнера з даними з одного Secret

  • Визначте змінну середовища як пару ключ-значення в Secret:

    kubectl create secret generic backend-user --from-literal=backend-username='backend-admin'
    
  • Призначте значення backend-username, визначене у Secret, змінній середовища SECRET_USERNAME у специфікації Podʼа.

    apiVersion: v1
    kind: Pod
    metadata:
      name: env-single-secret
    spec:
      containers:
      - name: envars-test-container
        image: nginx
        env:
        - name: SECRET_USERNAME
          valueFrom:
            secretKeyRef:
              name: backend-user
              key: backend-username
    
  • Створіть Pod:

    kubectl create -f https://k8s.io/examples/pods/inject/pod-single-secret-env-variable.yaml
    
  • У вашій оболонці покажіть вміст змінної середовища контейнера SECRET_USERNAME.

    kubectl exec -i -t env-single-secret -- /bin/sh -c 'echo $SECRET_USERNAME'
    

    Вивід схожий на:

    backend-admin
    

Визначення змінних середовища контейнера з даними з декількох Secret

  • Як і у попередньому прикладі, спочатку створіть Secretʼи.

    kubectl create secret generic backend-user --from-literal=backend-username='backend-admin'
    kubectl create secret generic db-user --from-literal=db-username='db-admin'
    
  • Визначте змінні середовища у специфікації Podʼа.

    apiVersion: v1
    kind: Pod
    metadata:
      name: envvars-multiple-secrets
    spec:
      containers:
      - name: envars-test-container
        image: nginx
        env:
        - name: BACKEND_USERNAME
          valueFrom:
            secretKeyRef:
              name: backend-user
              key: backend-username
        - name: DB_USERNAME
          valueFrom:
            secretKeyRef:
              name: db-user
              key: db-username
    
  • Створіть Pod:

    kubectl create -f https://k8s.io/examples/pods/inject/pod-multiple-secret-env-variable.yaml
    
  • У вашій оболонці покажіть змінні середовища контейнера.

    kubectl exec -i -t envvars-multiple-secrets -- /bin/sh -c 'env | grep _USERNAME'
    

    Вивід схожий на:

    DB_USERNAME=db-admin
    BACKEND_USERNAME=backend-admin
    

налаштування всіх пар ключ-значення в Secret як змінних середовища контейнера

  • Створіть Secret, що містить декілька пар ключ-значення

    kubectl create secret generic test-secret --from-literal=username='my-app' --from-literal=password='39528$vdg7Jb'
    
  • Використовуйте envFrom, щоб визначити всі дані Secret як змінні середовища контейнера. Ключ з Secret стає імʼям змінної середовища у Pod.

    apiVersion: v1
    kind: Pod
    metadata:
      name: envfrom-secret
    spec:
      containers:
      - name: envars-test-container
        image: nginx
        envFrom:
        - secretRef:
            name: test-secret
    
  • Створіть Pod:

    kubectl create -f https://k8s.io/examples/pods/inject/pod-secret-envFrom.yaml
    
  • У вашій оболонці покажіть змінні середовища контейнера username та password.

    kubectl exec -i -t envfrom-secret -- /bin/sh -c 'echo "username: $username\npassword: $password\n"'
    

    Вивід схожий на:

    username: my-app
    password: 39528$vdg7Jb
    

Приклад: Надавання операційних/тестових облікових даних Podʼам за допомогою Secret

У цьому прикладі показано Pod, який використовує Secret, що містить облікові дані операційного середовища, і ще один Pod, який використовує Secret з обліковими даними тестового середовища.

  1. Створіть Secret для облікових даних операційного середовища:

    kubectl create secret generic prod-db-secret --from-literal=username=produser --from-literal=password=Y4nys7f11
    

    Вивід схожий на:

    secret "prod-db-secret" created
    
  2. Створіть Secret для облікових даних тестового середовища.

    kubectl create secret generic test-db-secret --from-literal=username=testuser --from-literal=password=iluvtests
    

    Вивід схожий на:

    secret "test-db-secret" created
    
  3. Створіть маніфести Podʼів:

    cat <<EOF > pod.yaml
    apiVersion: v1
    kind: List
    items:
    - kind: Pod
      apiVersion: v1
      metadata:
        name: prod-db-pod
      spec:
        containers:
        - name: prod-db-container
          image: mysql
          env:
          - name: MYSQL_ROOT_PASSWORD
            valueFrom:
              secretKeyRef:
                name: prod-db-secret
                key: password
          - name: MYSQL_DATABASE
            value: mydatabase
          - name: MYSQL_USER
            valueFrom:
              secretKeyRef:
                name: prod-db-secret
                key: username
    - kind: Pod
      apiVersion: v1
      metadata:
        name: test-db-pod
      spec:
        containers:
        - name: test-db-container
          image: mysql
          env:
          - name: MYSQL_ROOT_PASSWORD
            valueFrom:
              secretKeyRef:
                name: test-db-secret
                key: password
          - name: MYSQL_DATABASE
            value: mydatabase
          - name: MYSQL_USER
            valueFrom:
              secretKeyRef:
                name: test-db-secret
                key: username
    EOF
    
  4. Застосуйте всі ці обʼєкти на сервер API, виконавши:

    kubectl create -f pod.yaml
    

Обидва контейнери матимуть у своїх файлових системах наступні файли зі значеннями для кожного середовища контейнера:

/etc/secret-volume/username
/etc/secret-volume/password

Ви також можете подальшим спрощенням базової специфікації Podʼа використовуючи два службові облікові записи:

  1. prod-user з prod-db-secret
  2. test-user з test-db-secret

Специфікація Podʼа скорочується до:

apiVersion: v1
kind: Pod
metadata:
  name: prod-db-client-pod
  labels:
    name: prod-db-client
spec:
  serviceAccount: prod-db-client
  containers:
  - name: db-client-container
    image: myClientImage

Довідка

Що далі

  • Дізнайтеся більше про Secret.
  • Дізнайтеся про Томи.

4.8 - Запуск застосунків

Запуск та керування застосунками зі збереженням стану так і без збереження стану"

4.8.1 - Запуск застосунку без збереження стану за допомогою Deployment

Ця сторінка показує, як запустити застосунок за допомогою обʼєкта Deployment в Kubernetes.

Цілі

  • Створити розгортання nginx.
  • Використання kubectl для виведення інформації про розгортання.
  • Оновити розгортання.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Версія вашого Kubernetes сервера має бути не старішою ніж v1.9. Для перевірки версії введіть kubectl version.

Створення та дослідження розгортання nginx

Ви можете запустити застосунок, створивши обʼєкт Kubernetes Deployment, і ви можете описати Deployment у файлі YAML. Наприклад, цей файл YAML описує Deployment, який використовує образ Docker nginx:1.14.2:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2 # вказує Deployment запустити 2 Podʼи, що відповідають шаблону
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80
  1. Створіть Deployment на основі файлу YAML:

    kubectl apply -f https://k8s.io/examples/application/deployment.yaml
    
  2. Виведіть інформацію про Deployment:

    kubectl describe deployment nginx-deployment
    

    Вивід схожий на:

    Name:     nginx-deployment
    Namespace:    default
    CreationTimestamp:  Tue, 30 Aug 2016 18:11:37 -0700
    Labels:     app=nginx
    Annotations:    deployment.kubernetes.io/revision=1
    Selector:   app=nginx
    Replicas:   2 desired | 2 updated | 2 total | 2 available | 0 unavailable
    StrategyType:   RollingUpdate
    MinReadySeconds:  0
    RollingUpdateStrategy:  1 max unavailable, 1 max surge
    Pod Template:
      Labels:       app=nginx
      Containers:
        nginx:
        Image:              nginx:1.14.2
        Port:               80/TCP
        Environment:        <none>
        Mounts:             <none>
      Volumes:              <none>
    Conditions:
      Type          Status  Reason
      ----          ------  ------
      Available     True    MinimumReplicasAvailable
      Progressing   True    NewReplicaSetAvailable
    OldReplicaSets:   <none>
    NewReplicaSet:    nginx-deployment-1771418926 (2/2 replicas created)
    No events.
    
  3. Перегляньте Podʼи, створені розгортанням:

    kubectl get pods -l app=nginx
    

    Вивід схожий на:

    NAME                                READY     STATUS    RESTARTS   AGE
    nginx-deployment-1771418926-7o5ns   1/1       Running   0          16h
    nginx-deployment-1771418926-r18az   1/1       Running   0          16h
    
  4. Виведіть інформацію про Pod:

    kubectl describe pod <pod-name>
    

    де <pod-name> — це імʼя одного з ваших Podʼів.

Оновлення розгортання

Ви можете оновити розгортання, застосувавши новий файл YAML. Цей файл YAML вказує, що розгортання повинне бути оновлене до nginx 1.16.1.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.16.1 # Оновлення версії nginx з 1.14.2 до 1.16.1
        ports:
        - containerPort: 80
  1. Застосуйте новий файл YAML:

    kubectl apply -f https://k8s.io/examples/application/deployment-update.yaml
    
  2. Спостерігайте, як розгортання створює Podʼи з новими іменами і видаляє старі Podʼи:

    kubectl get pods -l app=nginx
    

Масштабування застосунку шляхом збільшення кількості реплік

Ви можете збільшити кількість Podʼів у вашому Deployment, застосувавши новий YAML файл. Цей файл YAML встановлює replicas на 4, що вказує, що Deployment повиннен мати чотири Podʼи:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 4 # Update the replicas from 2 to 4
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.16.1
        ports:
        - containerPort: 80
  1. Застосуйте новий файл YAML:

    kubectl apply -f https://k8s.io/examples/application/deployment-scale.yaml
    
  2. Перевірте, що Deployment має чотири Podʼи:

    kubectl get pods -l app=nginx
    

    Вивід схожий на:

    NAME                               READY     STATUS    RESTARTS   AGE
    nginx-deployment-148880595-4zdqq   1/1       Running   0          25s
    nginx-deployment-148880595-6zgi1   1/1       Running   0          25s
    nginx-deployment-148880595-fxcez   1/1       Running   0          2m
    nginx-deployment-148880595-rwovn   1/1       Running   0          2m
    

Видалення Deployment

Видаліть Deployment за іменем:

kubectl delete deployment nginx-deployment

ReplicationControllers — Старий спосіб

Перевагою створення реплікованих застосунків є використання Deployment, який своєю чергою використовує ReplicaSet. До того, як в Kubernetes були додані Deployment та ReplicaSet, репліковані застосунки конфігурувалися за допомогою ReplicationController.

Що далі

4.8.2 - Запуск одноекземплярного застосунку зі збереженням стану

На цій сторінці показано, як запустити одноекземплярний застосунок зі збереженням стану (Stateful) в Kubernetes, використовуючи PersistentVolume та Deployment. Застосунок — MySQL.

Цілі

  • Створити PersistentVolume, посилаючись на диск у вашому середовищі.
  • Створити Deployment MySQL.
  • Використання MySQL для інших Podʼів в кластері за відомим DNS-імʼям.

Перш ніж ви розпочнете

  • Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

    Для перевірки версії введіть kubectl version.

  • Вам потрібно мати або динамічний провізор PersistentVolume з типовим StorageClass, або статично надавати PersistentVolume самостійно, щоб задовольнити PersistentVolumeClaims, що використовується тут.

Розгортання MySQL

Ви можете запустити stateful застосунок, створивши Deployment Kubernetes та підʼєднавши його до наявного PersistentVolume за допомогою PersistentVolumeClaim. Наприклад, цей файл YAML описує Deployment, що запускає MySQL та посилається на PersistentVolumeClaim. Файл визначає монтування тому для /var/lib/mysql, а потім створює PersistentVolumeClaim, який шукає том 20G. Ця заявка виконується будь-яким наявним томом, який відповідає вимогам, або за допомогою динамічного провізора.

Примітка: пароль визначений в файлі конфігурації yaml, і це не є безпечним. Див. Kubernetes Secrets для безпечнішого рішення.

apiVersion: v1
kind: Service
metadata:
  name: mysql
spec:
  ports:
  - port: 3306
  selector:
    app: mysql
  clusterIP: None
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mysql
spec:
  selector:
    matchLabels:
      app: mysql
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - image: mysql:5.6
        name: mysql
        env:
          # Використання secret у реальному використанні
        - name: MYSQL_ROOT_PASSWORD
          value: password
        ports:
        - containerPort: 3306
          name: mysql
        volumeMounts:
        - name: mysql-persistent-storage
          mountPath: /var/lib/mysql
      volumes:
      - name: mysql-persistent-storage
        persistentVolumeClaim:
          claimName: mysql-pv-claim
apiVersion: v1
kind: PersistentVolume
metadata:
  name: mysql-pv-volume
  labels:
    type: local
spec:
  storageClassName: manual
  capacity:
    storage: 20Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/mnt/data"
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-pv-claim
spec:
  storageClassName: manual
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi
  1. Розгорніть PV та PVC з файлу YAML:

    kubectl apply -f https://k8s.io/examples/application/mysql/mysql-pv.yaml
    
  2. Розгорніть вміст файлу YAML:

    kubectl apply -f https://k8s.io/examples/application/mysql/mysql-deployment.yaml
    
  3. Показати інформацію про Deployment:

    kubectl describe deployment mysql
    

    Вивід схожий на:

    Name:                 mysql
    Namespace:            default
    CreationTimestamp:    Tue, 01 Nov 2016 11:18:45 -0700
    Labels:               app=mysql
    Annotations:          deployment.kubernetes.io/revision=1
    Selector:             app=mysql
    Replicas:             1 desired | 1 updated | 1 total | 0 available | 1 unavailable
    StrategyType:         Recreate
    MinReadySeconds:      0
    Pod Template:
      Labels:       app=mysql
      Containers:
        mysql:
        Image:      mysql:5.6
        Port:       3306/TCP
        Environment:
          MYSQL_ROOT_PASSWORD:      password
        Mounts:
          /var/lib/mysql from mysql-persistent-storage (rw)
      Volumes:
        mysql-persistent-storage:
        Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
        ClaimName:  mysql-pv-claim
        ReadOnly:   false
    Conditions:
      Type          Status  Reason
      ----          ------  ------
      Available     False   MinimumReplicasUnavailable
      Progressing   True    ReplicaSetUpdated
    OldReplicaSets:       <none>
    NewReplicaSet:        mysql-63082529 (1/1 replicas created)
    Events:
      FirstSeen    LastSeen    Count    From                SubobjectPath    Type        Reason            Message
      ---------    --------    -----    ----                -------------    --------    ------            -------
      33s          33s         1        {deployment-controller }             Normal      ScalingReplicaSet Scaled up replica set mysql-63082529 to 1
    
  4. Перегляньте Podʼи, створені Deployment:

    kubectl get pods -l app=mysql
    

    Вивід схожий на:

    NAME                   READY     STATUS    RESTARTS   AGE
    mysql-63082529-2z3ki   1/1       Running   0          3m
    
  5. Перевірка PersistentVolumeClaim:

    kubectl describe pvc mysql-pv-claim
    

    Вивід схожий на:

    Name:         mysql-pv-claim
    Namespace:    default
    StorageClass:
    Status:       Bound
    Volume:       mysql-pv-volume
    Labels:       <none>
    Annotations:    pv.kubernetes.io/bind-completed=yes
                    pv.kubernetes.io/bound-by-controller=yes
    Capacity:     20Gi
    Access Modes: RWO
    Events:       <none>
    

Доступ до екземпляра MySQL

Попередній YAML-файл створює Service, який дозволяє іншим Podʼам в кластері отримувати доступ до бази даних. Опція Service clusterIP: None дозволяє імені DNS Serviceʼа безпосередньо посилатись на IP-адресу Podʼа. Це оптимально, коли у вас є лише один Pod за Service і ви не маєте наміру збільшувати кількість Podʼів.

Запустіть клієнта MySQL, щоб підʼєднатися до сервера:

kubectl run -it --rm --image=mysql:5.6 --restart=Never mysql-client -- mysql -h mysql -ppassword

Ця команда створює новий Pod у кластері, що виконує клієнта MySQL та підʼєднується до сервера через Service. Якщо підʼєднання вдалося, ви знаєте, що ваша stateful база даних MySQL працює.

Waiting for pod default/mysql-client-274442439-zyp6i to be running, status is Pending, pod ready: false
If you don't see a command prompt, try pressing enter.

mysql>

Оновлення

Образ або будь-яку іншу частину Deployment можна оновити як зазвичай за допомогою команди kubectl apply. Ось деякі заходи обережності, які специфічні для застосунків зі збереженням стану:

  • Не масштабуйте застосунок. Цей варіант призначений лише для застосунків з одним екземпляром. Основний PersistentVolume можна примонтувати лише до одного Podʼа. Для кластеризованих застосунків зі збереженням стану див. документацію StatefulSet.
  • Використовуйте strategy: type: Recreate в файлі конфігурації YAML Deployment. Це вказує Kubernetes не використовувати постійні (rolling) оновлення. Такі оновлення не працюватимуть, оскільки ви не можете мати більше одного Podʼа, що працює одночасно. Стратегія Recreate зупинить перший Pod перед створенням нового з оновленою конфігурацією.

Видалення Deployment

Видаліть розгорнуті обʼєкти за іменем:

kubectl delete deployment,svc mysql
kubectl delete pvc mysql-pv-claim
kubectl delete pv mysql-pv-volume

Якщо ви вручну вказували PersistentVolume, вам також потрібно вручну видалити його, а також звільнити основний ресурс. Якщо ви використовували динамічного провізора, він автоматично видаляє PersistentVolume, коли бачить, що ви видалили PersistentVolumeClaim. Деякі динамічні провізори (наприклад, ті, що стосуються EBS та PD) також звільняють основний ресурс після видалення PersistentVolume.

Що далі

4.8.3 - Запуск реплікованого застосунку зі збереженням стану

Ця сторінка показує, як запустити реплікований застосунок зі збереженням стану (StatefulSet). Цей застосунок — реплікована база даних MySQL. У топології цього прикладу є один головний сервер і кілька реплік, що використовують асинхронну реплікацію на основі рядків.

Перш ніж ви розпочнете

  • Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

  • Вам потрібно мати або динамічний провізор PersistentVolume з типовим StorageClass, або статично надавати PersistentVolume самостійно, щоб задовольнити PersistentVolumeClaims, що використовується тут.

  • Це завдання передбачає, що ви знаєте про Постійні томи та StatefulSets,а також інші основні поняття, такі як Pod, Service та ConfigMap.
  • Трохи знань MySQL корисні, але цей посібник має на меті представити загальні патерни, які можуть бути корисними для інших систем.
  • Ви використовуєте простір імен default або інший простір імен, в якому відсутні обʼєкти, що конфліктують.

Цілі

  • Розгорнути репліковану топологію MySQL за допомогою StatefulSet.
  • Направити трафік від клієнта MySQL.
  • Спостерігати стійкість до перерв у роботі.
  • Масштабувати StatefulSet вгору та вниз.

Розгортання MySQL

Приклад розгортання складається з ConfigMap, двох Service та StatefulSet.

Створення ConfigMap

Створіть ConfigMap із наступного файлу конфігурації YAML:

apiVersion: v1
kind: ConfigMap
metadata:
  name: mysql
  labels:
    app: mysql
    app.kubernetes.io/name: mysql
data:
  primary.cnf: |
    # Застосовує цю конфігурацію до primary.
    [mysqld]
    log-bin    
  replica.cnf: |
    # Застосовує цю конфігурацію до реплік.
    [mysqld]
    super-read-only    

kubectl apply -f https://k8s.io/examples/application/mysql/mysql-configmap.yaml

Цей ConfigMap надає перевизначення для my.cnf, що дозволяє вам незалежно керувати конфігурацією на головному сервері MySQL та його репліках. У цьому випадку ви хочете, щоб головний сервер міг обслуговувати логи реплікацій реплік, а репліки відхиляли будь-які записи, які надходять не через реплікацію.

Немає нічого особливого у самому ConfigMap, що зумовлює застосування різних частин до різних Podʼів. Кожен Pod вирішує, яку частину дивитися при ініціалізації, на основі інформації, що надає контролер StatefulSet.

Створення Service

Створіть Service із наступного файлу конфігурації YAML:

# Service headless для стабільних записів DNS членів StatefulSet.
apiVersion: v1
kind: Service
metadata:
  name: mysql
  labels:
    app: mysql
    app.kubernetes.io/name: mysql
spec:
  ports:
  - name: mysql
    port: 3306
  clusterIP: None
  selector:
    app: mysql
---
# Service клієнт для підʼєднання до екземпляру MySQL для читання.
# Для запису ви повинні підключитися до основного: mysql-0.mysql.
apiVersion: v1
kind: Service
metadata:
  name: mysql-read
  labels:
    app: mysql
    app.kubernetes.io/name: mysql
    readonly: "true"
spec:
  ports:
  - name: mysql
    port: 3306
  selector:
    app: mysql
kubectl apply -f https://k8s.io/examples/application/mysql/mysql-services.yaml

Service headless надає місце для DNS-записів, які контролери StatefulSet створюють для кожного Podʼа, що є частиною набору. Оскільки headless Service називається mysql, Podʼи доступні за допомогою зіставлення <pod-name>.mysql з будь-якого іншого Podʼа в тому ж Kubernetes кластері та просторі імен.

Клієнтський Service, з назвою mysql-read, є звичайним Service з власним кластерним IP, який розподіляє підключення між всіма Podʼами MySQL, які повідомляють про готовність. Набір потенційних точок доступу включає головний сервер MySQL та всі репліки.

Зверніть увагу, що лише запити на читання можуть використовувати балансувальник Service. Оскільки існує лише один головний сервер MySQL, клієнти повинні підключатися безпосередньо до головного Podʼа MySQL (через його DNS-запис у головному Service) для виконання записів.

Створення StatefulSet

Наостанок, створіть StatefulSet із наступного файлу конфігурації YAML:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql
spec:
  selector:
    matchLabels:
      app: mysql
      app.kubernetes.io/name: mysql
  serviceName: mysql
  replicas: 3
  template:
    metadata:
      labels:
        app: mysql
        app.kubernetes.io/name: mysql
    spec:
      initContainers:
      - name: init-mysql
        image: mysql:5.7
        command:
        - bash
        - "-c"
        - |
          set -ex
          # Generate mysql server-id from pod ordinal index.
          [[ $HOSTNAME =~ -([0-9]+)$ ]] || exit 1
          ordinal=${BASH_REMATCH[1]}
          echo [mysqld] > /mnt/conf.d/server-id.cnf
          # Add an offset to avoid reserved server-id=0 value.
          echo server-id=$((100 + $ordinal)) >> /mnt/conf.d/server-id.cnf
          # Copy appropriate conf.d files from config-map to emptyDir.
          if [[ $ordinal -eq 0 ]]; then
            cp /mnt/config-map/primary.cnf /mnt/conf.d/
          else
            cp /mnt/config-map/replica.cnf /mnt/conf.d/
          fi          
        volumeMounts:
        - name: conf
          mountPath: /mnt/conf.d
        - name: config-map
          mountPath: /mnt/config-map
      - name: clone-mysql
        image: gcr.io/google-samples/xtrabackup:1.0
        command:
        - bash
        - "-c"
        - |
          set -ex
          # Skip the clone if data already exists.
          [[ -d /var/lib/mysql/mysql ]] && exit 0
          # Skip the clone on primary (ordinal index 0).
          [[ `hostname` =~ -([0-9]+)$ ]] || exit 1
          ordinal=${BASH_REMATCH[1]}
          [[ $ordinal -eq 0 ]] && exit 0
          # Clone data from previous peer.
          ncat --recv-only mysql-$(($ordinal-1)).mysql 3307 | xbstream -x -C /var/lib/mysql
          # Prepare the backup.
          xtrabackup --prepare --target-dir=/var/lib/mysql          
        volumeMounts:
        - name: data
          mountPath: /var/lib/mysql
          subPath: mysql
        - name: conf
          mountPath: /etc/mysql/conf.d
      containers:
      - name: mysql
        image: mysql:5.7
        env:
        - name: MYSQL_ALLOW_EMPTY_PASSWORD
          value: "1"
        ports:
        - name: mysql
          containerPort: 3306
        volumeMounts:
        - name: data
          mountPath: /var/lib/mysql
          subPath: mysql
        - name: conf
          mountPath: /etc/mysql/conf.d
        resources:
          requests:
            cpu: 500m
            memory: 1Gi
        livenessProbe:
          exec:
            command: ["mysqladmin", "ping"]
          initialDelaySeconds: 30
          periodSeconds: 10
          timeoutSeconds: 5
        readinessProbe:
          exec:
            # Перевіряє, чи можемо ми виконувати запити через TCP (skip-networking вимкнено).
            command: ["mysql", "-h", "127.0.0.1", "-e", "SELECT 1"]
          initialDelaySeconds: 5
          periodSeconds: 2
          timeoutSeconds: 1
      - name: xtrabackup
        image: gcr.io/google-samples/xtrabackup:1.0
        ports:
        - name: xtrabackup
          containerPort: 3307
        command:
        - bash
        - "-c"
        - |
          set -ex
          cd /var/lib/mysql

          # Determine binlog position of cloned data, if any.
          if [[ -f xtrabackup_slave_info && "x$(<xtrabackup_slave_info)" != "x" ]]; then
            # XtraBackup already generated a partial "CHANGE MASTER TO" query
            # because we're cloning from an existing replica. (Need to remove the tailing semicolon!)
            cat xtrabackup_slave_info | sed -E 's/;$//g' > change_master_to.sql.in
            # Ignore xtrabackup_binlog_info in this case (it's useless).
            rm -f xtrabackup_slave_info xtrabackup_binlog_info
          elif [[ -f xtrabackup_binlog_info ]]; then
            # We're cloning directly from primary. Parse binlog position.
            [[ `cat xtrabackup_binlog_info` =~ ^(.*?)[[:space:]]+(.*?)$ ]] || exit 1
            rm -f xtrabackup_binlog_info xtrabackup_slave_info
            echo "CHANGE MASTER TO MASTER_LOG_FILE='${BASH_REMATCH[1]}',\
                  MASTER_LOG_POS=${BASH_REMATCH[2]}" > change_master_to.sql.in
          fi

          # Check if we need to complete a clone by starting replication.
          if [[ -f change_master_to.sql.in ]]; then
            echo "Waiting for mysqld to be ready (accepting connections)"
            until mysql -h 127.0.0.1 -e "SELECT 1"; do sleep 1; done

            echo "Initializing replication from clone position"
            mysql -h 127.0.0.1 \
                  -e "$(<change_master_to.sql.in), \
                          MASTER_HOST='mysql-0.mysql', \
                          MASTER_USER='root', \
                          MASTER_PASSWORD='', \
                          MASTER_CONNECT_RETRY=10; \
                        START SLAVE;" || exit 1
            # In case of container restart, attempt this at-most-once.
            mv change_master_to.sql.in change_master_to.sql.orig
          fi

          # Start a server to send backups when requested by peers.
          exec ncat --listen --keep-open --send-only --max-conns=1 3307 -c \
            "xtrabackup --backup --slave-info --stream=xbstream --host=127.0.0.1 --user=root"          
        volumeMounts:
        - name: data
          mountPath: /var/lib/mysql
          subPath: mysql
        - name: conf
          mountPath: /etc/mysql/conf.d
        resources:
          requests:
            cpu: 100m
            memory: 100Mi
      volumes:
      - name: conf
        emptyDir: {}
      - name: config-map
        configMap:
          name: mysql
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      accessModes: ["ReadWriteOnce"]
      resources:
        requests:
          storage: 10Gi
kubectl apply -f https://k8s.io/examples/application/mysql/mysql-statefulset.yaml

Ви можете спостерігати за процесом запуску, виконавши:

kubectl get pods -l app=mysql --watch

Через деякий час ви повинні побачити, що всі 3 Podʼи стануть Running:

NAME      READY     STATUS    RESTARTS   AGE
mysql-0   2/2       Running   0          2m
mysql-1   2/2       Running   0          1m
mysql-2   2/2       Running   0          1m

Натисніть Ctrl+C, щоб скасувати перегляд.

Цей маніфест використовує різноманітні техніки для керування Podʼами як частиною StatefulSet. У наступному розділі підкреслено деякі з цих технік, щоб пояснити, що відбувається під час створення Podʼів StatefulSet.

Розуміння ініціалізації Podʼа зі збереженням стану

Контролер StatefulSet запускає Podʼи по одному, в порядку їх індексів. Він чекає, доки кожен Pod не повідомить про готовність, перш ніж запустити наступний.

Крім того, контролер призначає кожному Podʼу унікальне, стабільне імʼя у формі <statefulset-name>-<ordinal-index>, в результаті отримуємо Podʼи з іменами mysql-0, mysql-1 та mysql-2.

Шаблон Podʼа у вищенаведеному маніфесті StatefulSet використовує ці властивості, щоб здійснити впорядкований запуск реплікації MySQL.

Створення конфігурації

Перед запуском будь-яких контейнерів у специфікації Podʼа, спочатку Pod запускає будь-які контейнери ініціалізації у визначеному порядку.

Перший контейнер ініціалізації, init-mysql, генерує спеціальні конфігураційні файли MySQL на основі порядкового індексу.

Скрипт визначає свій власний порядковий індекс, витягуючи його з кінця імені Podʼа, яке повертається командою hostname. Потім він зберігає порядковий індекс (з числовим зміщенням для уникнення зарезервованих значень) у файлі з назвою server-id.cnf в теці conf.d MySQL. Це перетворює унікальний, стабільний ідентифікатор, наданий StatefulSet, у домен ідентифікаторів серверів MySQL, які вимагають таких же властивостей.

Скрипт у контейнері init-mysql також застосовує або primary.cnf, або replica.cnf з ConfigMap, копіюючи вміст у conf.d. Оскільки у топології цього прикладу є лише один головний сервер MySQL та будь-яка кількість реплік, скрипт призначає порядковий індекс 0 головному серверу, а всі інші — репліками. Разом з гарантією контролера StatefulSet щодо порядку розгортання, це забезпечує готовність головного сервера MySQL перед створенням реплік, щоб вони могли почати реплікацію.

Клонування наявних даних

Загалом, коли новий Pod приєднується до набору як репліка, він повинен припускати, що головний сервер MySQL може вже містити дані. Також він повинен припускати, що логи реплікації можуть не бути повністю отримані з самого початку. Ці консервативні припущення є ключем до можливості запуску робочого StatefulSet масштабуватися вгору та вниз з часом, а не залишатися фіксованим на своєму початковому розмірі.

Другий контейнер ініціалізації, з назвою clone-mysql, виконує операцію клонування на реплікаційному Podʼі першого разу, коли він запускається на порожньому PersistentVolume. Це означає, що він копіює всі наявні дані з іншого працюючого Podʼа, таким чином, його локальний стан є достатньо консистентним для початку реплікації з головного сервера.

MySQL сам по собі не надає механізму для цього, тому приклад використовує популярний відкритий інструмент — Percona XtraBackup. Під час клонування MySQL сервер може мати знижену продуктивність. Щоб мінімізувати вплив на головний сервер MySQL, скрипт вказує кожному Podʼу отримувати дані з Podʼа, чий порядковий індекс на одиницю менший. Це працює через те, що контролер StatefulSet завжди гарантує, що Pod N є готовим перед запуском Podʼа N+1.

Початок реплікації

Після успішного завершення контейнерів ініціалізації запускаються звичайні контейнери. Podʼи MySQL складаються з контейнера mysql, в якому працює фактичний сервер mysqld, та контейнера xtrabackup, який діє як sidecar.

Sidecar xtrabackup переглядає клоновані файли даних і визначає, чи необхідно ініціалізувати реплікацію MySQL на репліці. У цьому випадку він чекає, доки mysqld буде готовий, а потім виконує команди CHANGE MASTER TO та START SLAVE з параметрами реплікації, отриманими з клонованих файлів XtraBackup.

Після того як репліка починає реплікацію, вона запамʼятовує свій головний сервер MySQL і автоматично підʼєднується, якщо сервер перезавантажується або зʼєднання втрачається. Також, оскільки репліки шукають головний сервер за його стабільним DNS-імʼям (mysql-0.mysql), вони автоматично знаходять головний сервер навіть якщо він отримує новий IP Podʼа через перепланування.

Нарешті, після початку реплікації, контейнер xtrabackup слухає зʼєднання з інших Podʼів, які запитують клон даних. Цей сервер залишається активним нескінченно довго в разі, якщо StatefulSet масштабується вгору, або якщо наступний Pod втрачає свій PersistentVolumeClaim і потрібно повторно виконати клонування.

Надсилання клієнтського трафіку

Ви можете надіслати тестові запити до головного сервера MySQL (хост mysql-0.mysql) запустивши тимчасовий контейнер з образом mysql:5.7 і використовуючи бінарний файл клієнта mysql.

kubectl run mysql-client --image=mysql:5.7 -i --rm --restart=Never --\
  mysql -h mysql-0.mysql <<EOF
CREATE DATABASE test;
CREATE TABLE test.messages (message VARCHAR(250));
INSERT INTO test.messages VALUES ('hello');
EOF

Використовуйте хост mysql-read, щоб надіслати тестові запити до будь-якого сервера, який повідомляє про готовність:

kubectl run mysql-client --image=mysql:5.7 -i -t --rm --restart=Never --\
  mysql -h mysql-read -e "SELECT * FROM test.messages"

Ви повинні отримати вивід схожий на цей:

Waiting for pod default/mysql-client to be running, status is Pending, pod ready: false
+---------+
| message |
+---------+
| hello   |
+---------+
pod "mysql-client" deleted

Щоб продемонструвати, що Service mysql-read розподіляє підключення між серверами, ви можете запустити SELECT @@server_id у циклі:

kubectl run mysql-client-loop --image=mysql:5.7 -i -t --rm --restart=Never --\
  bash -ic "while sleep 1; do mysql -h mysql-read -e 'SELECT @@server_id,NOW()'; done"

Ви повинні бачити, що @@server_id змінюється випадковим чином, оскільки може бути вибрана інша точка доступу при кожній спробі підключення:

+-------------+---------------------+
| @@server_id | NOW()               |
+-------------+---------------------+
|         100 | 2006-01-02 15:04:05 |
+-------------+---------------------+
+-------------+---------------------+
| @@server_id | NOW()               |
+-------------+---------------------+
|         102 | 2006-01-02 15:04:06 |
+-------------+---------------------+
+-------------+---------------------+
| @@server_id | NOW()               |
+-------------+---------------------+
|         101 | 2006-01-02 15:04:07 |
+-------------+---------------------+

Ви можете натиснути Ctrl+C, коли захочете зупинити цикл, але цікаво тримати його запущеним в іншому вікні, щоб бачити ефект від наступних кроків.

Симуляція відмови Podʼа та Вузла

Щоб продемонструвати підвищену доступність читання з пулу реплік замість одного сервера, залиште цикл SELECT @@server_id, запущений вище, активним, тоді як ви змушуєте Pod вийти зі стану Ready.

Збій проби готовності

Проба готовності для контейнера mysql виконує команду mysql -h 127.0.0.1 -e 'SELECT 1', щоб переконатися, що сервер запущений і може виконувати запити.

Одним зі способів змусити цю пробу готовності збоїти — це пошкодити цю команду:

kubectl exec mysql-2 -c mysql -- mv /usr/bin/mysql /usr/bin/mysql.off

Ця дія втручається у файлову систему контейнера Podʼа mysql-2 і перейменовує команду mysql, щоб проба готовності не могла її знайти. Через кілька секунд Pod повинен повідомити про один зі своїх контейнерів як неготовий, що можна перевірити за допомогою:

kubectl get pod mysql-2

Перевірте значення 1/2 у стовпці READY:

NAME      READY     STATUS    RESTARTS   AGE
mysql-2   1/2       Running   0          3m

На цьому етапі ви повинні бачити продовження роботи вашого циклу SELECT @@server_id, хоча він більше не повідомляє про 102. Нагадаємо, що скрипт init-mysql визначив server-id як 100 + $ordinal, тож ідентифікатор сервера 102 відповідає Поду mysql-2.

Тепер відновіть Pod і він повинен знову зʼявитися у виводі циклу через кілька секунд:

kubectl exec mysql-2 -c mysql -- mv /usr/bin/mysql.off /usr/bin/mysql

Видалення Podʼів

Контролер StatefulSet також створює Podʼи знову, якщо вони видалені, подібно до того, як це робить ReplicaSet для Podʼів без збереження стану.

kubectl delete pod mysql-2

Контролер StatefulSet помічає, що Podʼа mysql-2 більше не існує, і створює новий з тією ж назвою та повʼязаний з тим самим PersistentVolumeClaim. Ви повинні побачити, що ідентифікатор сервера 102 зникне з виводу циклу протягом певного часу і потім повернеться самостійно.

Виведення вузла з експлуатації

Якщо у вашому кластері Kubernetes є кілька вузлів, ви можете симулювати відмову вузла(наприклад, під час оновлення вузлів) за допомогою команди drain.

Спочатку визначте, на якому вузлі знаходиться один із Podʼів MySQL:

kubectl get pod mysql-2 -o wide

Назва вузла повинна зʼявитися у останньому стовпчику:

NAME      READY     STATUS    RESTARTS   AGE       IP            NODE
mysql-2   2/2       Running   0          15m       10.244.5.27   kubernetes-node-9l2t

Потім виведіть вузол з експлуатації, виконавши наступну команду, яка забороняє новим Podʼам запускатися на цьому вузлі та видаляє будь-які існуючі Podʼи. Замість <node-name> підставте назву вузла, яку ви знайшли на попередньому кроці.

# Дивіться вище поради щодо впливу на інші завдання
kubectl drain <node-name> --force --delete-emptydir-data --ignore-daemonsets

Тепер ви можете спостерігати, як Pod переплановується на іншому вузлі:

kubectl get pod mysql-2 -o wide --watch

Це має виглядати приблизно так:

NAME      READY   STATUS          RESTARTS   AGE       IP            NODE
mysql-2   2/2     Terminating     0          15m       10.244.1.56   kubernetes-node-9l2t
[...]
mysql-2   0/2     Pending         0          0s        <none>        kubernetes-node-fjlm
mysql-2   0/2     Init:0/2        0          0s        <none>        kubernetes-node-fjlm
mysql-2   0/2     Init:1/2        0          20s       10.244.5.32   kubernetes-node-fjlm
mysql-2   0/2     PodInitializing 0          21s       10.244.5.32   kubernetes-node-fjlm
mysql-2   1/2     Running         0          22s       10.244.5.32   kubernetes-node-fjlm
mysql-2   2/2     Running         0          30s       10.244.5.32   kubernetes-node-fjlm

І знову, ви повинні побачити, що ідентифікатор сервера 102 зник з виводу циклу SELECT @@server_id протягом певного часу, а потім повернувся.

Тепер знову дозвольте вузлу приймати навантаження:

kubectl uncordon <node-name>

Масштабування кількості реплік

Коли ви використовуєте реплікацію MySQL, ви можете збільшувати кількість запитів на читання, додаючи репліки. Для StatefulSet це можна зробити однією командою:

kubectl scale statefulset mysql --replicas=5

Спостерігайте, як нові Podʼи запускаються, виконавши:

kubectl get pods -l app=mysql --watch

Коли вони будуть готові, ви побачите, що ідентифікатори серверів 103 та 104 починають зʼявлятися у виводі циклу SELECT @@server_id.

Ви також можете перевірити, що ці нові сервери мають дані, які ви додали до них до того, як вони існували:

kubectl run mysql-client --image=mysql:5.7 -i -t --rm --restart=Never --\
  mysql -h mysql-3.mysql -e "SELECT * FROM test.messages"
Waiting for pod default/mysql-client to be running, status is Pending, pod ready: false
+---------+
| message |
+---------+
| hello   |
+---------+
pod "mysql-client" deleted

Зменшити кількість реплік також можна однією командою:

kubectl scale statefulset mysql --replicas=3

Ви можете перевірити це, виконавши:

kubectl get pvc -l app=mysql

Це покаже, що всі 5 PVC все ще існують, попри те, що StatefulSet був зменшений до 3:

NAME           STATUS    VOLUME                                     CAPACITY   ACCESSMODES   AGE
data-mysql-0   Bound     pvc-8acbf5dc-b103-11e6-93fa-42010a800002   10Gi       RWO           20m
data-mysql-1   Bound     pvc-8ad39820-b103-11e6-93fa-42010a800002   10Gi       RWO           20m
data-mysql-2   Bound     pvc-8ad69a6d-b103-11e6-93fa-42010a800002   10Gi       RWO           20m
data-mysql-3   Bound     pvc-50043c45-b1c5-11e6-93fa-42010a800002   10Gi       RWO           2m
data-mysql-4   Bound     pvc-500a9957-b1c5-11e6-93fa-42010a800002   10Gi       RWO           2m

Якщо ви не збираєтеся повторно використовувати додаткові PVC, ви можете їх видалити:

kubectl delete pvc data-mysql-3
kubectl delete pvc data-mysql-4

Очищення

  1. Припинить цикл SELECT @@server_id, натиснувши Ctrl+C в його терміналі або виконавши наступне з іншого терміналу:

    kubectl delete pod mysql-client-loop --now
    
  2. Видаліть StatefulSet. Це також розпочне завершення Podʼів.

    kubectl delete statefulset mysql
    
  3. Перевірте, що Podʼи зникають. Вони можуть зайняти деякий час для завершення роботи.

    kubectl get pods -l app=mysql
    

    Ви будете знати, що Podʼи завершилися, коли вищезазначена команда поверне:

    No resources found.
    
  4. Видаліть ConfigMap, Services та PersistentVolumeClaims.

    kubectl delete configmap,service,pvc -l app=mysql
    
  5. Якщо ви вручну створювали PersistentVolumes, вам також потрібно вручну видалити їх, а також звільнити відповідні ресурси. Якщо ви використовували динамічний провізор, він автоматично видаляє PersistentVolumes, коли бачить, що ви видалили PersistentVolumeClaims. Деякі динамічні провізори (такі як ті, що стосуються EBS та PD) також звільняють відповідні ресурси при видаленні PersistentVolumes.

Що далі

4.8.4 - Масштабування StatefulSet

Це завдання показує, як масштабувати StatefulSet. Масштабування StatefulSet означає збільшення або зменшення кількості реплік.

Перш ніж ви розпочнете

  • StatefulSets доступні тільки в версії Kubernetes 1.5 або пізніше. Щоб перевірити вашу версію Kubernetes, виконайте kubectl version.

  • Не всі застосунки зі збереженням стану гарно масштабуються. Якщо ви не впевнені, чи масштабувати ваші StatefulSets, див. Концепції StatefulSet або Посібник StatefulSet для отримання додаткової інформації.

  • Ви повинні виконувати масштабування лише тоді, коли ви впевнені, що ваш кластер застосунку зі збереженням стану є повністю справним.

Масштабування StatefulSets

Використання kubectl для масштабування StatefulSets

Спочатку знайдіть StatefulSet, який ви хочете масштабувати.

kubectl get statefulsets <назва-stateful-set>

Змініть кількість реплік вашого StatefulSet:

kubectl scale statefulsets <назва-stateful-set> --replicas=<нові-репліки>

Виконання оновлень на місці для вашого StatefulSets

Альтернативно, ви можете виконати оновлення на місці для ваших StatefulSets.

Якщо ваш StatefulSet спочатку був створений за допомогою kubectl apply, оновіть .spec.replicas маніфестів StatefulSet, а потім виконайте kubectl apply:

kubectl apply -f <stateful-set-file-updated>

Інакше, відредагуйте це поле за допомогою kubectl edit:

kubectl edit statefulsets <stateful-set-name>

Або використовуйте kubectl patch:

kubectl patch statefulsets <назва-stateful-set> -p '{"spec":{"replicas":<нові-репліки>}}'

Усунення несправностей

Масштабування вниз не працює правильно

Ви не можете зменшити масштаб StatefulSet, коли будь-який з Stateful Podʼів, яким він керує, є нездоровим. Масштабування відбувається лише після того, як ці Stateful Podʼи стають запущеними та готовими.

Якщо spec.replicas > 1, Kubernetes не може визначити причину несправності Podʼа. Це може бути наслідком постійного збою або тимчасового збою. Тимчасовий збій може бути викликаний перезапуском, необхідним для оновлення або обслуговування.

Якщо Pod несправний через постійний збій, масштабування без виправлення дефекту може призвести до стану, коли кількість членів StatefulSet опускається нижче певної мінімальної кількості реплік, необхідних для правильної роботи це може призвести до недоступності вашого StatefulSet.

Якщо Pod несправний через тимчасовий збій і Pod може стати доступним знову, тимчасова помилка може перешкоджати вашій операції масштабування вгору або вниз. Деякі розподілені бази даних мають проблеми, коли вузли приєднуються та відключаються одночасно. Краще розуміти операції масштабування на рівні застосунків у таких випадках і виконувати масштабування лише тоді, коли ви впевнені, що ваш кластер застосунку зі збереженням стану є цілком справним.

Що далі

4.8.5 - Видалення StatefulSet

Це завдання показує, як видалити StatefulSet.

Перш ніж ви розпочнете

  • Це завдання передбачає, що у вас є застосунок, який працює на вашому кластері та представлений StatefulSet.

Видалення StatefulSet

Ви можете видалити StatefulSet так само як і інші ресурси в Kubernetes: використовуйте команду kubectl delete та вкажіть StatefulSet або файлом, або імʼям.

kubectl delete -f <file.yaml>
kubectl delete statefulsets <statefulset-name>

Після видалення StatefulSet може знадобитися окремо видалити повʼязаний headless service.

kubectl delete service <імʼя-сервісу>

Під час видалення StatefulSet через kubectl, StatefulSet масштабується до 0. Всі Podʼи, які є частиною цього робочого навантаження, також видаляються. Якщо ви хочете видалити лише StatefulSet і не Podʼи, використовуйте --cascade=orphan. Наприклад:

kubectl delete -f <файл.yaml> --cascade=orphan

Передачею --cascade=orphan до kubectl delete Podʼи, що керуються StatefulSet залишаються після того, як обʼєкт StatefulSet сам по собі буде видалений. Якщо Podʼи мають мітку app.kubernetes.io/name=MyApp, ви можете видалити їх наступним чином:

kubectl delete pods -l app.kubernetes.io/name=MyApp

Постійні томи

Видалення Podʼів у StatefulSet не призведе до видалення повʼязаних томів. Це зроблено для того, щоб ви мали можливість скопіювати дані з тому перед його видаленням. Видалення PVC після завершення роботи Podʼів може спричинити видалення зазначених постійних томів залежно від класу сховища та політики повторного використання. Ніколи не припускайте можливість доступу до тому після видалення заявки.

Повне видалення StatefulSet

Щоб видалити все у StatefulSet, включаючи повʼязані Podʼи, ви можете виконати серію команд, схожих на наступні:

grace=$(kubectl get pods <под-stateful-set> --template '{{.spec.terminationGracePeriodSeconds}}')
kubectl delete statefulset -l app.kubernetes.io/name=MyApp
sleep $grace
kubectl delete pvc -l app.kubernetes.io/name=MyApp

У вище наведеному прикладі Podʼи мають мітку app.kubernetes.io/name=MyApp; підставте вашу власну мітку за потреби.

Примусове видалення Podʼів StatefulSet

Якщо ви помітите, що деякі Podʼи у вашому StatefulSet застрягли у стані 'Terminating' або 'Unknown' протягом тривалого періоду часу, вам може знадобитися втрутитися вручну, щоб примусово видалити Podʼи з apiserverʼа. Це потенційно небезпечне завдання. Див. Примусове видалення Podʼів StatefulSet для отримання детальної інформації.

Що далі

Дізнайтеся більше про примусове видалення Podʼів StatefulSet.

4.8.6 - Примусове видалення Podʼів StatefulSet

Ця сторінка показує, як видаляти Podʼи, які є частиною StatefulSet, та пояснює важливі моменти, які слід враховувати під час цього.

Перш ніж ви розпочнете

  • Це досить високорівневе завдання і може порушити деякі властивості, притаманні StatefulSet.
  • Перед продовженням ознайомтеся з розглянутими нижче моментами.

Міркування про StatefulSet

При нормальному функціонуванні StatefulSet ніколи немає потреби у примусовому видаленні Podʼів StatefulSet. Контролер StatefulSet відповідає за створення, масштабування та видалення членів StatefulSet. Він намагається забезпечити, щоб зазначена кількість Podʼів від ordinal 0 до N-1 були справними та готовими. StatefulSet забезпечує те, що в будь-який момент часу в кластері працює не більше одного Podʼа з заданою ідентичністю. Це називається семантикою як максимум один, яку забезпечує StatefulSet.

Примусове видалення слід виконувати з обережністю, оскільки воно може порушити семантику "як максимум один", притаманну StatefulSet. StatefulSet можуть використовуватися для запуску розподілених і кластерних застосунків, які потребують стабільної мережевої ідентичності та стабільного сховища. Ці застосунки часто мають конфігурацію, яка ґрунтується на ансамблі фіксованої кількості членів з фіксованими ідентичностями. Наявність декількох членів із тією самою ідентичністю може бути руйнівною і може призвести до втрати даних (наприклад, у випадку "розщеплення мозку" в системах на основі кворуму).

Видалення Podʼів

Ви можете виконати коректне видалення Podʼа за допомогою наступної команди:

kubectl delete pods <pod>

Щоб таке видалення призвело до коректного завершення, необхідно вказати pod.Spec.TerminationGracePeriodSeconds більше 0. Практика встановлення pod.Spec.TerminationGracePeriodSeconds на 0 секунд є небезпечною та категорично не рекомендується для Podʼів StatefulSet. Коректне видалення є безпечним і забезпечить, що Pod коректно завершить роботу перед тим, як kubelet видалить імʼя з apiserver.

Pod не видаляється автоматично, коли вузол недоступний. Podʼи, які працюють на недоступному вузлі, потрапляють у стан 'Terminating' або 'Unknown' після тайм-ауту. Podʼи також можуть потрапляти в ці стани, коли користувач спробує коректне видалення Podʼа на недоступному вузлі. Єдині способи, якими Pod у такому стані може бути видалено з apiserver, наступні:

  • Обʼєкт Node видаляється (або вами, або Контролером Вузлів).
  • kubelet на недоступному Вузлі починає відповідати, припиняє роботу Pod та видаляє запис з apiserver.
  • Примусове видалення Podʼа користувачем.

Рекомендована практика — використовувати перший або другий підхід. Якщо вузол підтверджено є несправним (наприклад, постійно відключений від мережі, вимкнений тощо), то видаліть обʼєкт Node. Якщо вузол страждає від розділення мережі, то спробуйте вирішити це або зачекайте на його вирішення. Коли розділення мережі виправляється, kubelet завершить видалення Podʼа та звільнить його імʼя в apiserver.

Зазвичай система завершує видалення, як тільки Pod більше не працює на Вузлі, або Вузол видаляється адміністратором. Ви можете перевизначити це за допомогою примусового видалення Podʼа.

Примусове видалення

Примусові видалення не чекають підтвердження від kubelet про те, що Pod було завершено. Незалежно від того, чи успішно примусове завершення Podʼа припиняє його роботу чи ні, воно негайно звільняє імʼя з apiserverʼа. Це дозволить контролеру StatefulSet створити новий Pod з тією самою ідентичністю; це може призвести до дублювання все ще працюючого Podʼа, і якщо цей Pod все ще може спілкуватися з іншими членами StatefulSet, це порушить семантику "як максимум один", яку StatefulSet має гарантувати.

Коли ви примусово видаляєте Pod StatefulSet, ви стверджуєте, що цей Pod більше ніколи не буде знову взаємодіяти з іншими Podʼами StatefulSet, і його імʼя може бути безпечно звільнено для створення заміни.

Якщо ви хочете примусово видалити Pod за допомогою kubectl версії >= 1.5, виконайте наступне:

kubectl delete pods <pod> --grace-period=0 --force

Якщо ви використовуєте будь-яку версію kubectl <= 1.4, ви повинні пропустити параметр --force і використовувати:

kubectl delete pods <pod> --grace-period=0

Якщо навіть після цих команд Pod застряг у стані Unknown, використайте наступну команду для видалення Podʼа з кластера:

kubectl patch pod <pod> -p '{"metadata":{"finalizers":null}}'

Завжди виконуйте примусове видалення Podʼів StatefulSet обережно та з повним розумінням ризиків, повʼязаних із цим.

Що далі

Дізнайтеся більше про налагодження StatefulSet.

4.8.7 - Горизонтальне автомасштабування Podʼів

У Kubernetes HorizontalPodAutoscaler автоматично оновлює ресурс навантаження (наприклад, Deployment або StatefulSet), з метою автоматичного масштабування робочого навантаження у відповідь на попит.

Горизонтальне масштабування означає, що реакція на збільшення навантаження полягає у розгортанні додаткових Podʼів. Це відрізняється від вертикального масштабування, що для Kubernetes означає призначення додаткових ресурсів (наприклад, памʼяті або CPU) для уже запущених Podʼів робочого навантаження.

Якщо навантаження зменшується, а кількість Podʼів перевищує налаштований мінімум, HorizontalPodAutoscaler інструктує ресурс навантаження (Deployment, StatefulSet або інший схожий ресурс) масштабуватися вниз.

Горизонтальне автоматичне масштабування Podʼів не застосовується до обʼєктів, які не можна масштабувати (наприклад, DaemonSet).

HorizontalPodAutoscaler реалізований як ресурс API Kubernetes та контролер. Ресурс визначає поведінку контролера. Контролер горизонтального автоматичного масштабування Podʼів, який працює в панелі управління Kubernetes, періодично коригує бажану шкалу своєї цілі (наприклад, Deployment), щоб відповідати спостережуваним метрикам, таким як середнє використання CPU, середня використання памʼяті або будь-яка інша метрика, яку ви вказуєте.

Ось приклад використання горизонтального автоматичного масштабування Podʼів.

Як працює HorizontalPodAutoscaler?

graph BT hpa[Horizontal Pod Autoscaler] --> scale[Scale] subgraph rc[RC / Deployment] scale end scale -.-> pod1[Pod 1] scale -.-> pod2[Pod 2] scale -.-> pod3[Pod N] classDef hpa fill:#D5A6BD,stroke:#1E1E1D,stroke-width:1px,color:#1E1E1D; classDef rc fill:#F9CB9C,stroke:#1E1E1D,stroke-width:1px,color:#1E1E1D; classDef scale fill:#B6D7A8,stroke:#1E1E1D,stroke-width:1px,color:#1E1E1D; classDef pod fill:#9FC5E8,stroke:#1E1E1D,stroke-width:1px,color:#1E1E1D; class hpa hpa; class rc rc; class scale scale; class pod1,pod2,pod3 pod

Схема 1. HorizontalPodAutoscaler керує масштабуванням Deployment та його ReplicaSet

У Kubernetes горизонтальне автоматичне масштабування Podʼів реалізовано як цикл керування, що працює інтервально (це не постійний процес). Інтервал встановлюється параметром --horizontal-pod-autoscaler-sync-period для kube-controller-manager (а стандартне значення — 15 секунд).

Один раз протягом кожного періоду менеджер контролера запитує використання ресурсів відповідно до метрик, вказаних у визначенні кожного HorizontalPodAutoscaler. Менеджер контролера знаходить цільовий ресурс, визначений за допомогою scaleTargetRef, потім вибирає Podʼи на основі міток .spec.selector цільового ресурсу та отримує метрики зі специфічних метрик ресурсів API (для метрик ресурсів на кожен Pod) або API власних метрик (для всіх інших метрик).

  • Для метрик ресурсів на кожен Pod (наприклад, CPU) контролер отримує метрики з API метрик ресурсів для кожного Pod, на який впливає HorizontalPodAutoscaler. Потім, якщо встановлено значення цільового використання, контролер обчислює значення використання як відсоток еквівалентного ресурсного запиту на контейнери в кожному Pod. Якщо встановлено сирцеве цільове значення, використовуються сирі (необроблені) значення метрик. Потім контролер бере середнє значення використання або сире значення (залежно від типу вказаної цілі) для всіх цільових Podʼів і створює співвідношення, яке використовується для масштабування кількості бажаних реплік.

    Зверніть увагу, що якщо деякі контейнери Podʼів не мають відповідного ресурсного запиту, використання CPU для Pod не буде визначене, і автоматичний масштабувальник не буде виконувати жодних дій для цієї метрики. Дивіться розділ подробиці алгоритму нижче для отримання додаткової інформації про те, як працює алгоритм автомасштабування.

  • Для власних метрик на кожен Pod контролер працює аналогічно метрикам ресурсів на кожен Pod, за винятком того, що він працює з сирцевими значеннями, а не значеннями використання.

  • Для метрик обʼєктів та зовнішніх метрик витягується одна метрика, яка описує обʼєкт. Цю метрику порівнюють з цільовим значенням, щоб отримати співвідношення, як вище. У версії API autoscaling/v2 це значення можна за необхідності розділити на кількість Podʼів до порівняння.

Звичайне використання HorizontalPodAutoscaler — налаштувати його на витягування метрик з агрегованих API (metrics.k8s.io, custom.metrics.k8s.io або external.metrics.k8s.io). API metrics.k8s.io зазвичай надається Metrics Server, який потрібно запустити окремо. Для отримання додаткової інформації про метрики ресурсів див. Metrics Server.

Підтримка API метрик пояснює гарантії стабільності та статус підтримки цих різних API.

Контролер HorizontalPodAutoscaler має доступ до відповідних ресурсів робочого навантаження, які підтримують масштабування (такі як Deployment та StatefulSet). Ці ресурси мають субресурс з назвою scale, інтерфейс, який дозволяє динамічно встановлювати кількість реплік і переглядати поточний стан кожного з них. Для загальної інформації про субресурси в API Kubernetes див. Поняття API Kubernetes.

Алгоритм

По простому, контролер HorizontalPodAutoscaler працює зі співвідношенням між бажаним значенням метрики та поточним значенням метрики:

бажаніРепліки = ceil[поточніРепліки * ( поточнеЗначенняМетрики / бажанеЗначенняМетрики )]

Наприклад, якщо поточне значення метрики — 200м, а бажане значення — 100м, кількість реплік буде подвоєна, оскільки 200,0 / 100,0 == 2,0. Якщо поточне значення замість цього — 50м, кількість реплік буде зменшена вдвічі, оскільки 50,0 / 100,0 == 0,5. Панель управління пропускає будь-яку дію масштабування, якщо співвідношення достатньо близьке до 1,0 (в межах глобально налаштованої допустимості, типово 0.1).

Якщо вказано targetAverageValue або targetAverageUtilization, поточне значення метрики обчислюється шляхом визначення середнього значення вказаної метрики для всіх Podʼів у цільовому масштабі HorizontalPodAutoscaler.

Перед перевіркою допустимості та визначенням кінцевих значень панель управління також розглядає, чи є відсутні будь-які метрики, і скільки Podʼів є Ready. Всі Podʼи зі встановленим відбитками часу видалення (обʼєкти з відбитками часу видалення перебувають у процесі завершення роботи/видалення) ігноруються, а всі збійні Podʼи не враховуються.

Якщо конкретний Pod не маж метрики, його відкладено на потім; Podʼи з відсутніми метриками будуть використані для коригування кінцевої кількості масштабування.

При масштабуванні за CPU, якщо будь-який pod ще не став готовим (він все ще ініціалізується, або можливо, несправний) або остання точка метрики для Pod була до того, як він став готовим, цей Pod також відкладено.

Через технічні обмеження, контролер HorizontalPodAutoscaler не може точно визначити перший раз, коли Pod стає готовим при визначенні, чи відкласти певні метрики CPU. Замість цього вважається, що Pod "ще не готовий", якщо він ще не готовий і перейшов у готовий стан протягом короткого, налаштованого вікна часу з моменту початку. Це значення налаштоване за допомогою прапорця --horizontal-pod-autoscaler-initial-readiness-delay, і типово воно складає 30 секунд. Як тільки Pod став готовим, будь-який перехід в готовий стан вважається першим, якщо це сталося протягом довшого, налаштованого часу від початку. Це значення налаштоване за допомогою прапорця --horizontal-pod-autoscaler-cpu-initialization-period, і його стандартне значення — 5 хвилин.

Базове співвідношення масштабу currentMetricValue / desiredMetricValue потім обчислюється залишковими Podʼами, які не були відкладені або відкинуті вище.

Якщо були відсутні метрики, панель управління перераховує середнє значення більш консервативно, припускаючи, що ці Podʼи споживають 100% бажаного значення у випадку масштабування вниз і 0% у випадку масштабування вгору. Це зменшує величину можливого масштабу.

Крім того, якщо присутні будь-які ще не готові Podʼи, і робоче навантаження мало б масштабуватися вгору без врахування відсутніх метрик або ще не готових Podʼів, контролер консервативно припускає, що ще не готові Podʼи споживають 0% бажаної метрики, зменшуючи величини масштабу.

Після врахування ще не готових Podʼів та відсутніх метрик контролер повторно обчислює відношення використання. Якщо нове співвідношення змінює напрямок масштабування або знаходиться в межах допустимості, контролер не вживає жодних дій щодо масштабування. У інших випадках нове співвідношення використовується для прийняття будь-яких змін кількості Podʼів.

Зверніть увагу, що початкове значення для середнього використання повертається через статус HorizontalPodAutoscaler, без врахування ще не готових Podʼів або відсутніх метрик, навіть коли використовується нове відношення використання.

Якщо в HorizontalPodAutoscaler вказано кілька метрик, цей розрахунок виконується для кожної метрики, а потім обирається найбільше з бажаних кількостей реплік. Якщо будь-яка з цих метрик не може бути переведена у бажану кількість реплік (наприклад, через помилку отримання метрик з API метрик) і запропоновано масштабування вниз за метриками, які можна витягнути, масштабування пропускається. Це означає, що HPA все ще може масштабуватися вгору, якщо одна або декілька метрик дають значення desiredReplicas, більше, ніж поточне значення.

Нарешті, прямо перед тим, як HPA масштабує ціль, рекомендація масштабування записується. Контролер розглядає всі рекомендації в налаштованому вікні та обирає найвищу рекомендацію в межах цього вікна. Це значення можна налаштувати за допомогою прапорця --horizontal-pod-autoscaler-downscale-stabilization, який стандартно складає 5 хвилин. Це означає, що зменшення масштабу відбуватиметься поступово, згладжуючи вплив метрик, що швидко змінюються.

Обʼєкт API

Horizontal Pod Autoscaler є ресурсом API в групі API Kubernetes autoscaling. Поточна стабільна версія знаходиться в версії API autoscaling/v2, яка включає підтримку масштабування за памʼяттю та власними метриками. Нові поля, введені в autoscaling/v2, зберігаються як анотації при роботі з autoscaling/v1.

При створенні обʼєкта API HorizontalPodAutoscaler переконайтеся, що вказане імʼя є дійсним піддоменом DNS. Більше деталей про обʼєкт API можна знайти на сторінці Обʼєкт HorizontalPodAutoscaler.

Стабільність масштабування робочого навантаження

При керуванні масштабом групи реплік за допомогою HorizontalPodAutoscaler можливі часті коливання кількості реплік через динамічний характер оцінюваних метрик. Це іноді називають коливанням, або flapping. Це схоже на концепцію гістерезису в кібернетиці.

Масштабування під час поступового оновлення

Kubernetes дозволяє виконувати поступове оновлення для Deployment. У цьому випадку Deployment керує підлеглими ReplicaSets за вас. Коли ви налаштовуєте автомасштабування для Deployment, ви звʼязуєте HorizontalPodAutoscaler з одним Deployment. HorizontalPodAutoscaler керує полем replicas Deployment. Контролер розгортання відповідає за встановлення replicas підлеглих ReplicaSets так, щоб вони складали відповідну кількість під час розгортання, а також після його завершення.

Якщо ви виконуєте поступове оновлення StatefulSet, у якого є автомасштабована кількість реплік, StatefulSet безпосередньо керує своїм набором Podʼів (немає проміжного ресурсу, аналогічного ReplicaSet).

Підтримка метрик ресурсів

Будь-який обʼєкт HPA може бути масштабований на основі використання ресурсів у Podʼах цільового масштабування. При визначенні специфікації Podʼа повинні бути вказані запити ресурсів, такі як cpu та memory. Це використовується для визначення використання ресурсів і використовується контролером HPA для масштабування цілі вгору або вниз. Щоб використовувати масштабування на основі використання ресурсів, вкажіть джерело метрики так:

type: Resource
resource:
  name: cpu
  target:
    type: Utilization
    averageUtilization: 60

З цією метрикою контролер HPA буде підтримувати середнє використання ресурсів у Podʼах цільового масштабування на рівні 60%. Використання — це співвідношення між поточним використанням ресурсу та запитаними ресурсами Podʼа. Дивіться Алгоритм для отримання додаткової інформації про те, як обчислюється та усереднюється використання.

Метрики ресурсів контейнера

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.30 [stable]

API HorizontalPodAutoscaler також підтримує джерело метрик контейнера, де HPA може відстежувати використання ресурсів окремих контейнерів у наборі Podʼів, щоб масштабувати цільовий ресурс. Це дозволяє налаштовувати пороги масштабування для контейнерів, які мають найбільше значення в конкретному Pod. Наприклад, якщо у вас є вебзастосунок і контейнер допоміжного сервісу (sidecar), який надає логування, ви можете масштабувати на основі використання ресурсів вебзастосунка, ігноруючи контейнер допоміжного сервісу (sidecar) та його використання ресурсів.

Якщо ви переглянете цільовий ресурс, щоб мати нову специфікацію Pod з іншим набором контейнерів, ви повинні відредагувати специфікацію HPA, якщо цей ново доданий контейнер також має бути використаний для масштабування. Якщо вказаний контейнер у джерелі метрики відсутній або присутній лише в підмножині Podʼів, то ці Podʼи ігноруються, і рекомендація перераховується. Дивіться Алгоритм для отримання додаткової інформації про обчислення. Щоб використовувати ресурси контейнера для автомасштабування, визначте джерело метрики таким чином:

type: ContainerResource
containerResource:
  name: cpu
  container: application
  target:
    type: Utilization
    averageUtilization: 60

У вищенаведеному прикладі контролер HPA масштабує ціль так, що середнє використання cpu у контейнері application у всіх подах становить 60%.

Масштабування на основі власних метрик

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.23 [stable]

(версія API autoscaling/v2beta2 раніше надавала цю можливість як бета-функцію)

За умови використання версії API autoscaling/v2 ви можете налаштувати HorizontalPodAutoscaler на масштабування на основі власної метрики (яка не є вбудованою в Kubernetes або будь-який компонент Kubernetes). Потім контролер HorizontalPodAutoscaler запитує ці власні метрики з Kubernetes API.

Дивіться Підтримка API метрик для вимог.

Масштабування на основі декількох метрик

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.23 [stable]

(версія API autoscaling/v2beta2 раніше надавала цю можливість як бета-функцію)

За умови використання версії API autoscaling/v2 ви можете вказати декілька метрик для HorizontalPodAutoscaler для масштабування на їх основі. Потім контролер HorizontalPodAutoscaler оцінює кожну метрику і пропонує новий масштаб на основі цієї метрики. HorizontalPodAutoscaler бере максимальний масштаб, рекомендований для кожної метрики, і встановлює робоче навантаження на такий розмір (за умови, що це не більше загального максимуму, який ви налаштували).

Підтримка API метрик

Стандартно контролер HorizontalPodAutoscaler отримує метрики з низки API. Для того щоб мати доступ до цих API, адміністратори кластера повинні забезпечити:

  • Увімкнути шар агрегації API.

  • Відповідні API мають бути зареєстровані:

    • Для метрик ресурсі це metrics.k8s.io API, яке зазвичай надає metrics-server. Це може бути запущено як надбудова кластера.

    • Для власних метрик це custom.metrics.k8s.io API. Його надають сервери API "адаптера", які надають постачальники рішень метрик. Перевірте у своєї системи метрик, чи доступний адаптер метрик Kubernetes.

    • Для зовнішніх метрик це external.metrics.k8s.io API. Він може бути наданий адаптерами власних метрик, які наведено вище.

Для отримання додаткової інформації про ці різні шляхи метрик та їх відмінності дивіться відповідні пропозиції дизайну для HPA V2, custom.metrics.k8s.io та external.metrics.k8s.io.

Для прикладів використання дивіться посібник з використання власних метрик та посібник з використання зовнішніх метрик.

Налаштований механізм масштабування

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.23 [stable]

(версія API autoscaling/v2beta2 раніше надавала цю можливість як бета-функцію)

Якщо ви використовуєте API HorizontalPodAutoscaler v2, ви можете використовувати поле behavior (див. довідку API) для налаштування окремих поведінок масштабування вгору та вниз. Ви вказуєте ці поведінки, встановлюючи scaleUp та/або scaleDown у полі behavior.

Ви можете вказати вікно стабілізації, яке запобігає коливанню кількості реплік для цільового масштабування. Політики масштабування також дозволяють контролювати швидкість зміни реплік під час масштабування.

Політики масштабування

Одну або декілька політик масштабування можна вказати у розділі behavior специфікації. Коли вказано кілька політик, політика, яка дозволяє найбільше змін, є політикою, яка типово вибирається. Наступний приклад показує цю поведінку під час зменшення масштабу:

behavior:
  scaleDown:
    policies:
    - type: Pods
      value: 4
      periodSeconds: 60
    - type: Percent
      value: 10
      periodSeconds: 60

periodSeconds вказує на проміжок часу в минулому, протягом якого політика має бути істинною. Максимальне значення, яке можна встановити для periodSeconds, — 1800 (пів години). Перша політика (Pods) дозволяє зменшення максимум до 4 репліки протягом однієї хвилини. Друга політика (Percent) дозволяє зменшити максимум 10% поточних реплік протягом однієї хвилини.

Оскільки стандартно вибирається політика, яка дозволяє найбільше змін, друга політика буде використовуватися лише тоді, коли кількість реплік буде більше ніж 40. З 40 або менше реплік, буде застосована перша політика. Наприклад, якщо є 80 реплік, і ціль — зменшити масштаб до 10 реплік тоді під час першого кроку буде скорочено 8 реплік. На наступній ітерації, коли кількість реплік становить 72, 10% від реплік — 7,2, але число заокруглюється вгору до 8. На кожному кроці контролера автомасштабування перераховується кількість реплік, які мають бути змінені, на основі кількості поточних реплік. Коли кількість реплік падає нижче 40, застосовується перша політика (Pods) і зменшується по 4 репліки за раз.

Вибір політики можна змінити, вказавши поле selectPolicy для напрямку масштабування. Встановлення значення Min вибере політику, яка дозволяє найменшу зміну кількості реплік. Встановлення значення Disabled повністю вимикає масштабування в даному напрямку.

Вікно стабілізації

Вікно стабілізації використовується для обмеження перепадів кількості реплік, коли метрики, які використовуються для масштабування, постійно коливаються. Алгоритм автоматичного масштабування використовує це вікно, щоб виявити попередній бажаний стан та уникнути непотрібних змін у масштабі навантаження.

Наприклад, у наступному виразі фрагменту коду вказано вікно стабілізації для scaleDown.

behavior:
  scaleDown:
    stabilizationWindowSeconds: 300

Коли метрики показують, що потрібно зменшити ціль, алгоритм дивиться на раніше розраховані бажані стани і використовує найвище значення з вказаного інтервалу. У вищезазначеному прикладі всі попередні бажані стани за останні 5 хвилин будуть враховані.

Це наближається до ковзного максимуму і уникає ситуації, коли алгоритм масштабування часто видаляє Podʼи лише для того, щоб викликати повторне створення еквівалентного Podʼа за мить.

Стандартна поведінка

Для використання власного масштабування не всі поля повинні бути вказані. Можна вказати лише значення, які потрібно налаштувати. Ці власні значення злиті зі стандартними значеннями. Стандартні значення відповідають існуючій поведінці в алгоритмі HPA.

behavior:
  scaleDown:
    stabilizationWindowSeconds: 300
    policies:
    - type: Percent
      value: 100
      periodSeconds: 15
  scaleUp:
    stabilizationWindowSeconds: 0
    policies:
    - type: Percent
      value: 100
      periodSeconds: 15
    - type: Pods
      value: 4
      periodSeconds: 15
    selectPolicy: Max

Для зменшення масштабу вікно стабілізації становить 300 секунд (або значення параметра --horizontal-pod-autoscaler-downscale-stabilization, якщо воно вказане). Є лише одна політика для зменшення масштабу, яка дозволяє видалити 100% поточно запущених реплік, що означає, що ціль масштабування може бути зменшена до мінімально допустимих реплік. Для збільшення масштабу вікно стабілізації відсутнє. Коли метрики показують, що ціль повинна бути збільшена, ціль збільшується негайно. Є 2 політики, за якими кожні 15 секунд можна додати не більше 4 Podʼів або 100% поточно запущених реплік до тих пір, поки HPA не досягне стабільного стану.

Приклад: зміна вікна стабілізації для зменшення масштабу

Щоб вказати власне значення вікна стабілізації для зменшення масштабу тривалістю в 1 хвилину, в HPA буде додано наступну поведінку:

behavior:
  scaleDown:
    stabilizationWindowSeconds: 60

Приклад: обмеження коєфіцієнту зменшення масштабу

Щоб обмежити коєфіцієнт, з яким Podʼи видаляються HPA, до 10% за хвилину, до HPA додається наступна поведінка:

behavior:
  scaleDown:
    policies:
    - type: Percent
      value: 10
      periodSeconds: 60

Щоб переконатися, що за хвилину видаляється не більше 5 Podʼів, можна додати другу політику зменшення масштабу з фіксованим розміром 5 та встановити selectPolicy на значення Min. Встановлення selectPolicy на Min означає, що автомасштабувальник вибирає політику, яка впливає на найменшу кількість Podʼів:

behavior:
  scaleDown:
    policies:
    - type: Percent
      value: 10
      periodSeconds: 60
    - type: Pods
      value: 5
      periodSeconds: 60
    selectPolicy: Min

Приклад: вимкнення зменшення масштабу

Значення selectPolicy Disabled вимикає масштабування вказаного напрямку. Щоб запобігти зменшенню масштабу, буде використана наступна політика:

behavior:
  scaleDown:
    selectPolicy: Disabled

Підтримка HorizontalPodAutoscaler в kubectl

HorizontalPodAutoscaler, як і кожний ресурс API, підтримується стандартним чином у kubectl. Ви можете створити новий автомасштабувальник за допомогою команди kubectl create. Ви можете переглянути список автомасштабувальників за допомогою kubectl get hpa або отримати детальний опис за допомогою kubectl describe hpa. Нарешті, ви можете видалити автомасштабувальник за допомогою kubectl delete hpa.

Крім того, є спеціальна команда kubectl autoscale для створення обʼєкта HorizontalPodAutoscaler. Наприклад, виконання kubectl autoscale rs foo --min=2 --max=5 --cpu-percent=80 створить автомасштабувальник для ReplicaSet foo, з цільовим використанням процесора, встановленим на 80% і кількістю реплік від 2 до 5.

Неявне деактивування режиму підтримки

Ви можете неявно деактивувати HPA для цільового обʼєкта без необхідності змінювати конфігурацію HPA самостійно. Якщо бажана кількість реплік цільового обʼєкта встановлена на 0, а мінімальна кількість реплік HPA більше 0, HPA припиняє коригування цільового обʼєкта (і встановлює умову ScalingActive на собі в false) до тих пір, поки ви не активуєте його вручну, змінивши бажану кількість реплік цільового обʼєкта або мінімальну кількість реплік HPA.

Перехід Deployment та StatefulSet на горизонтальне масштабування

При увімкненні HPA рекомендується видалити значення spec.replicas з Deployment та/або StatefulSet в їхніх маніфестах. Якщо цього не зроблено, будь-яка зміна в цьому обʼєкті, наприклад за допомогою kubectl apply -f deployment.yaml, буде інструкцією Kubernetes масштабувати поточну кількість Podʼів до значення ключа spec.replicas. Це може бути небажаним і призводити до проблем, коли HPA активно працює.

Майте на увазі, що видалення spec.replicas може спричинити одноразове зниження кількості Podʼів, оскільки стандартне значення цього ключа — 1 (див. Репліки Deployment). Після оновлення всі Podʼи, крім одного, розпочнуть процедури їхнього завершення. Після цього будь-яке подальше розгортання застосунку буде працювати як звичайно і буде дотримуватися конфігурації плавного оновлення за бажанням. Ви можете уникнути цього зниження, обравши один із двох наступних методів в залежності від того, як ви модифікуєте свої розгортання:

  1. kubectl apply edit-last-applied deployment/<deployment_name>
  2. У редакторі видаліть spec.replicas. Після збереження та виходу з редактора, kubectl застосовує оновлення. На цьому етапі не відбувається змін кількості Podʼів.
  3. Тепер ви можете видалити spec.replicas з маніфеста. Якщо ви використовуєте систему управління вихідним кодом, також зафіксуйте ваші зміни або виконайте будь-які інші кроки для перегляду вихідного коду, які відповідають вашому способу відстеження оновлень.
  4. Відтепер ви можете запускати kubectl apply -f deployment.yaml

При використанні Server-Side Apply ви можете дотримуватися вказівок щодо передачі власності, які охоплюють цей саме випадок використання.

Що далі

Якщо ви налаштовуєте автомасштабування у вашому кластері, вам також може бути корисно розглянути використання автомасштабування кластера для забезпечення того, що ви запускаєте правильну кількість вузлів.

Для отримання додаткової інформації про HorizontalPodAutoscaler:

  • Прочитайте приклад для автоматичного горизонтального масштабування Podʼів.
  • Прочитайте документацію для kubectl autoscale.
  • Якщо ви бажаєте написати власний адаптер для власних метрик, перегляньте початковий код, щоб почати.
  • Ознайомтесь з Довідкою API для HorizontalPodAutoscaler.

4.8.8 - Покрокове керівництво HorizontalPodAutoscaler

HorizontalPodAutoscaler (HPA) автоматично оновлює ресурс робочого навантаження (наприклад, Deployment або StatefulSet), з метою автоматичного масштабування робочого навантаження, щоб відповідати попиту.

Горизонтальне масштабування означає, що відповідь на збільшене навантаження полягає в розгортанні додаткових Podʼів. Це відрізняється від вертикального масштабування, що для Kubernetes означає призначення додаткових ресурсів (наприклад: памʼять або CPU) для Podʼів, які вже працюють для робочого навантаження.

Якщо навантаження зменшується, а кількість Podʼів перевищує налаштований мінімум, HorizontalPodAutoscaler інструктує ресурс робочого навантаження (Deployment, StatefulSet або інший схожий ресурс) зменшити масштаб.

Цей документ детально розглядає приклад увімкнення HorizontalPodAutoscaler для автоматичного управління масштабуванням для прикладу вебзастосунку. Це приклад навантаження — Apache httpd, що виконує деякий код PHP.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Версія вашого Kubernetes сервера має бути не старішою ніж 1.23. Для перевірки версії введіть kubectl version. Якщо ви використовуєте старі версії Kubernetes, зверніться до документації для цієї версії (див. доступні версії документації).

Для виконання рекомендацій цього посібника, вам також потрібно використовувати кластер, в якому розгорнутий і налаштований Metrics Server. Сервер метрик Kubernetes збирає метрики ресурсів з kubelets у вашому кластері та використовує ці метрики через Kubernetes API, використовуючи APIService, щоб додати нові види ресурсів, які представляють метричні показники.

Щоб дізнатися, як розгорнути Metrics Server, див. документацію metrics-server.

Якщо ви використовуєте Minikube, виконайте наступну команду для ввімкнення metrics-server:

minikube addons enable metrics-server

Запустіть та надайте доступ до сервера php-apache

Для демонстрації HorizontalPodAutoscaler ви спочатку запустите Deployment, який запускає контейнер за допомогою образу hpa-example, та експонуєте його як Service за допомогою наступного маніфесту:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: php-apache
spec:
  selector:
    matchLabels:
      run: php-apache
  template:
    metadata:
      labels:
        run: php-apache
    spec:
      containers:
      - name: php-apache
        image: registry.k8s.io/hpa-example
        ports:
        - containerPort: 80
        resources:
          limits:
            cpu: 500m
          requests:
            cpu: 200m
---
apiVersion: v1
kind: Service
metadata:
  name: php-apache
  labels:
    run: php-apache
spec:
  ports:
  - port: 80
  selector:
    run: php-apache

Для цього виконайте наступну команду:

kubectl apply -f https://k8s.io/examples/application/php-apache.yaml
deployment.apps/php-apache створено
service/php-apache створено

Створіть HorizontalPodAutoscaler

Тепер, коли сервер працює, створіть автомасштабувальник за допомогою kubectl. Підкоманда kubectl autoscale, частина kubectl, допоможе зробити це.

За мить ви виконаєте команду, яка створить HorizontalPodAutoscaler, що підтримує від 1 до 10 реплік контрольованих Podʼів за допомогою Deployment php-apache, який ви створили на першому етапі цих інструкцій.

Грубо кажучи, контролер контролер HPA збільшує або зменшує кількість реплік (шляхом оновлення Deployment) для підтримки середнього використання процесора на рівні 50% по всіх Podʼах. Deployment потім оновлює ReplicaSet — це частина всіх Deployment у Kubernetes — і потім ReplicaSet додає або видаляє Podʼи на основі змін у його .spec.

Оскільки кожен Pod запитує 200 мілі-ядер за допомогою kubectl run, це означає середнє використання процесора 100 мілі-ядер. Див. Деталі алгоритму для отримання додаткової інформації щодо алгоритму.

Створіть HorizontalPodAutoscaler:

kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10
horizontalpodautoscaler.autoscaling/php-apache масштабовано

Ви можете перевірити поточний стан нового HorizontalPodAutoscaler, виконавши:

# Ви можете використовувати "hpa" або "horizontalpodautoscaler"; обидва імені працюють добре.
kubectl get hpa

Вивід схожий на:

NAME         REFERENCE                     TARGET    MINPODS   MAXPODS   REPLICAS   AGE
php-apache   Deployment/php-apache/scale   0% / 50%  1         10        1          18s

(якщо ви бачите інші HorizontalPodAutoscalers з різними іменами, це означає, що вони вже існували, і це зазвичай не проблема).

Зверніть увагу, що поточне використання ЦП становить 0%, оскільки немає клієнтів, що відправляють запити на сервер (стовпець «TARGET» показує середнє значення по всіх Podʼах, що контролюються відповідним розгортанням).

Збільшення навантаження

Далі перегляньте, як автомасштабувальник реагує на збільшене навантаження. Для цього ви запустите інший Pod, який буде виступати в ролі клієнта. Контейнер всередині Podʼа клієнта працює у нескінченному циклі, надсилаючи запити до служби php-apache.

# Виконайте це в окремому терміналі,
# щоб навантаження продовжувалося, і ви могли продовжити роботу з рештою кроків
kubectl run -i --tty load-generator --rm --image=busybox:1.28 --restart=Never -- /bin/sh -c "while sleep 0.01; do wget -q -O- http://php-apache; done"

Тепер виконайте:

# натисніть Ctrl+C, щоб припинити перегляд, коли будете готові
kubectl get hpa php-apache --watch

Протягом хвилини ви повинні побачити вище навантаження процесора; наприклад:

NAME         REFERENCE                     TARGET      MINPODS   MAXPODS   REPLICAS   AGE
php-apache   Deployment/php-apache/scale   305% / 50%  1         10        1          3m

а потім більше реплік. Наприклад:

NAME         REFERENCE                     TARGET      MINPODS   MAXPODS   REPLICAS   AGE
php-apache   Deployment/php-apache/scale   305% / 50%  1         10        7          3m

Тут споживання ЦП збільшилося до 305% від запиту. В результаті Deployment був змінений до 7 реплік:

kubectl get deployment php-apache

Ви повинні побачити, що кількість реплік відповідає цифрі з HorizontalPodAutoscaler

NAME         READY   UP-TO-DATE   AVAILABLE   AGE
php-apache   7/7      7           7           19m

Зупиніть генерування навантаження

Для завершення прикладу припиніть надсилання навантаження.

У терміналі, де ви створили Pod, який працює з образом busybox, зупиніть генерування навантаження, натиснувши <Ctrl> + C.

Потім перевірте результат (через хвилину чи так):

# натисніть Ctrl+C, щоб припинити перегляд, коли будете готові
kubectl get hpa php-apache --watch

Вивід схожий на:

NAME         REFERENCE                     TARGET       MINPODS   MAXPODS   REPLICAS   AGE
php-apache   Deployment/php-apache/scale   0% / 50%     1         10        1          11m

і Deployment також показує, що він зменшився:

kubectl get deployment php-apache
NAME         READY   UP-TO-DATE   AVAILABLE   AGE
php-apache   1/1     1            1           27m

Як тільки використання CPU знизилося до 0, HPA автоматично зменшив кількість реплік до 1.

Автоматичне масштабування реплік може зайняти кілька хвилин.

Автомасштабування за допомогою кількох метрик та власних метрик

Ви можете вводити додаткові метрики для використання при автомасштабуванні Deployment php-apache, використовуючи версію API autoscaling/v2.

Спочатку отримайте YAML вашого HorizontalPodAutoscaler у формі autoscaling/v2:

kubectl get hpa php-apache -o yaml > /tmp/hpa-v2.yaml

Відкрийте файл /tmp/hpa-v2.yaml у редакторі, і ви побачите YAML, що виглядає наступним чином:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: php-apache
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: php-apache
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50
status:
  observedGeneration: 1
  lastScaleTime: <some-time>
  currentReplicas: 1
  desiredReplicas: 1
  currentMetrics:
  - type: Resource
    resource:
      name: cpu
    current:
      averageUtilization: 0
      averageValue: 0

Зверніть увагу, що поле targetCPUUtilizationPercentage було замінено масивом під назвою metrics. Метрика використання ЦП є ресурсною метрикою, оскільки вона представлена як відсоток ресурсу, вказаного в контейнерах Podʼа. Зверніть увагу, що ви можете вказати інші ресурсні метрики крім ЦП. Стандартно, єдиним іншим підтримуваним типом ресурсної метрики є memory. Ці ресурси не змінюють назви з кластера на кластер і завжди повинні бути доступними, поки API metrics.k8s.io доступне.

Ви також можете вказати ресурсні метрики у вигляді безпосередніх значень, а не як відсотки від запитаного значення, використовуючи target.type AverageValue замість Utilization, і встановлюючи відповідне поле target.averageValue замість target.averageUtilization.

  metrics:
  - type: Resource
    resource:
      name: memory
      target:
        type: AverageValue
        averageValue: 500Mi

Є ще два інші типи метрик, які обидва вважаються власними метриками: метрики Podʼів і метрики обʼєктів. Ці метрики можуть мати назви, які специфічні для кластера, і вимагають більш розширеної настройки моніторингу кластера.

Перший з цих альтернативних типів метрик — це метрики Podʼів. Ці метрики описують Podʼи і вони усереднюються разом по Podʼах і порівнюються з цільовим значенням для визначення кількості реплік. Вони працюють так само як ресурсні метрики, за винятком того, що вони тільки підтримують тип target AverageValue.

Метрики Podʼів вказуються за допомогою блоку метрики, подібного до цього:

type: Pods
pods:
  metric:
    name: packets-per-second
  target:
    type: AverageValue
    averageValue: 1k

Другий альтернативний тип метрики — це метрики обʼєктів. Ці метрики описують інший обʼєкт в тому ж просторі імен, замість опису Podʼів. Метрики не обовʼязково отримуються з обʼєкта; вони лише описують його. Метрики обʼєктів підтримують типи target як Value і AverageValue. З Value ціль порівнюється безпосередньо з метрикою отриманою з API. З AverageValue значення, повернене з API власних метрик, ділиться на кількість Podʼів перед порівнянням з цільовим значенням. Ось приклад YAML представлення метрики requests-per-second.

type: Object
object:
  metric:
    name: requests-per-second
  describedObject:
    apiVersion: networking.k8s.io/v1
    kind: Ingress
    name: main-route
  target:
    type: Value
    value: 2k

Якщо ви надаєте кілька таких блоків метрик, HorizontalPodAutoscaler буде розглядати кожну метрику по черзі. HorizontalPodAutoscaler розраховуватиме запропоновані кількості реплік для кожної метрики, а потім вибере той, який має найбільшу кількість реплік.

Наприклад, якщо ваша система моніторингу збирає метрики про мережевий трафік, ви можете оновити визначення вище за допомогою kubectl edit так, щоб воно виглядало наступним чином:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: php-apache
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: php-apache
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50
  - type: Pods
    pods:
      metric:
        name: packets-per-second
      target:
        type: AverageValue
        averageValue: 1k
  - type: Object
    object:
      metric:
        name: requests-per-second
      describedObject:
        apiVersion: networking.k8s.io/v1
        kind: Ingress
        name: main-route
      target:
        type: Value
        value: 10k
status:
  observedGeneration: 1
  lastScaleTime: <some-time>
  currentReplicas: 1
  desiredReplicas: 1
  currentMetrics:
  - type: Resource
    resource:
      name: cpu
    current:
      averageUtilization: 0
      averageValue: 0
  - type: Object
    object:
      metric:
        name: requests-per-second
      describedObject:
        apiVersion: networking.k8s.io/v1
        kind: Ingress
        name: main-route
      current:
        value: 10k

Тоді ваш HorizontalPodAutoscaler намагатиметься забезпечити, щоб кожен Pod витрачав приблизно 50% від своєї запитаної CPU, обслуговував 1000 пакетів за секунду та всі Podʼи за головним маршрутом Ingress обслуговували в загальному 10000 запитів за секунду.

Автомасштабування за більш конкретними метриками

Багато систем метрик дозволяють описувати метрики або за назвою, або за набором додаткових описів, які називаються мітками (labels). Для всіх типів метрик, крім ресурсних (Podʼів, обʼєктів і зовнішніх, описаних нижче), ви можете вказати додатковий селектор міток, який передається вашій системі метрик. Наприклад, якщо ви збираєте метрику http_requests з міткою verb, ви можете вказати наступний блок метрики, щоб масштабувати тільки на запити GET:

type: Object
object:
  metric:
    name: http_requests
    selector: {matchLabels: {verb: GET}}

Цей селектор використовує такий же синтаксис, як і повні селектори міток Kubernetes. Система моніторингу визначає, як зведені кілька серій в одне значення, якщо імʼя та селектор відповідають кільком серіям. Селектор є додатковим, і не може вибирати метрики, що описують обʼєкти, які не є цільовим обʼєктом (цільові Podʼи у випадку типу Pods, та описаний обʼєкт у випадку типу Object).

Застосунки, які працюють на Kubernetes, можуть потребувати автоматичного масштабування на основі метрик, які не мають очевидного стосунку до будь-якого обʼєкта в кластері Kubernetes, наприклад, метрики, що описують хостову службу з жодною прямою кореляцією з просторами імен Kubernetes. У Kubernetes 1.10 і пізніших версіях ви можете вирішити цей випадок використовуючи зовнішні метрики.

Для використання зовнішніх метрик потрібно знання вашої системи моніторингу; налаштування аналогічно необхідному при використанні власних метрик. Зовнішні метрики дозволяють автоматично масштабувати ваш кластер на основі будь-якої метрики, доступної в вашій системі моніторингу. Надайте блок metric з name та selector, як вище, і використовуйте тип метрики External замість Object. Якщо кілька часових рядів відповідають metricSelector, то сума їх значень використовується HorizontalPodAutoscaler. Зовнішні метрики підтримують як типи цілей Value, так і AverageValue, які працюють точно так само, як коли ви використовуєте тип Object.

Наприклад, якщо ваш додаток обробляє завдання з хостової служби черги, ви можете додати наступний розділ до вашого маніфесту HorizontalPodAutoscaler, щоб вказати, що вам потрібен один робочий процес на кожні 30 невиконаних завдань.

- type: External
  external:
    metric:
      name: queue_messages_ready
      selector:
        matchLabels:
          queue: "worker_tasks"
    target:
      type: AverageValue
      averageValue: 30

Коли це можливо, краще використовувати типи цілей власних метрик замість зовнішніх метрик, оскільки для адміністраторів кластера легше захистити API власних метрик. Зовнішнє API метрик потенційно дозволяє доступ до будь-якої метрики, тому адміністратори кластера повинні бути обережні при його використанні.

Додаток: Умови стану горизонтального автомасштабування Podʼів

При використанні форми autoscaling/v2 HorizontalPodAutoscaler ви зможете бачити умови стану, встановлені Kubernetes на HorizontalPodAutoscaler. Ці умови стану вказують, чи може або не може HorizontalPodAutoscaler масштабуватися, а також чи є в цей час будь-які обмеження.

Умови зʼявляються у полі status.conditions. Щоб побачити умови, які впливають на HorizontalPodAutoscaler, ми можемо використати kubectl describe hpa:

kubectl describe hpa cm-test
Name:                           cm-test
Namespace:                      prom
Labels:                         <none>
Annotations:                    <none>
CreationTimestamp:              Fri, 16 Jun 2017 18:09:22 +0000
Reference:                      ReplicationController/cm-test
Metrics:                        ( current / target )
  "http_requests" on pods:      66m / 500m
Min replicas:                   1
Max replicas:                   4
ReplicationController pods:     1 current / 1 desired
Conditions:
  Type                  Status  Reason                  Message
  ----                  ------  ------                  -------
  AbleToScale           True    ReadyForNewScale        the last scale time was sufficiently old as to warrant a new scale
  ScalingActive         True    ValidMetricFound        the HPA was able to successfully calculate a replica count from pods metric http_requests
  ScalingLimited        False   DesiredWithinRange      the desired replica count is within the acceptable range
Events:

Для цього HorizontalPodAutoscaler ви можете побачити кілька умов у справному стані. Перше, AbleToScale, вказує, чи може або не може HPA отримувати та оновлювати масштаби, а також чи будь-які умови затримки повʼязані з масштабуванням. Друге, ScalingActive, вказує, чи увімкнений HPA (тобто кількість реплік цілі не дорівнює нулю) та чи може розраховувати потрібні масштаби. Якщо це False, це, як правило, вказує на проблеми з отриманням метрик. Нарешті, остання умова, ScalingLimited, вказує на те, що потрібний масштаб був обмежений максимальним або мінімальним значенням HorizontalPodAutoscaler. Це свідчить про те, що ви можливо захочете збільшити або зменшити мінімальну або максимальну кількість реплік на вашому HorizontalPodAutoscaler.

Кількості

Усі метрики в HorizontalPodAutoscaler та API метрик вказуються за спеціальною цільною числовою нотацією, відомою в Kubernetes як кількість. Наприклад, кількість 10500m буде записана як 10.5 у десятковій нотації. API метрик повертатимуть цілі числа без суфікса, якщо це можливо, і зазвичай повертають кількості в міліодиницях у протилежному випадку. Це означає, що ви можете бачити зміну вашого значення метрики між 1 і 1500m, або між 1 і 1.5, коли воно записане в десятковій нотації.

Інші можливі сценарії

Створення автомасштабування декларативно

Замість використання команди kubectl autoscale для створення HorizontalPodAutoscaler імперативно, ми можемо використати наступний маніфест, щоб створити його декларативно:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: php-apache
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: php-apache
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

Потім створіть автомасштабування, виконавши наступну команду:

kubectl create -f https://k8s.io/examples/application/hpa/php-apache.yaml
horizontalpodautoscaler.autoscaling/php-apache created

4.8.9 - Вказання бюджету розладів для вашого застосунку

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.21 [stable]

На цій сторінці показано, як обмежити кількість одночасних розладів, які очікує ваш застосунок, що дозволяє підвищити доступність і дозволяє адміністратору кластера управляти вузлами кластера.

Перш ніж ви розпочнете

Версія вашого Kubernetes сервера має бути не старішою ніж v1.21. Для перевірки версії введіть kubectl version.

Захист застосунку за допомогою PodDisruptionBudget

  1. Визначте, який застосунок ви хочете захистити за допомогою PodDisruptionBudget (PDB).
  2. Подумайте про те, як ваш застосунок реагує на розлади.
  3. Створіть визначення PDB у вигляді файлу YAML.
  4. Створіть обʼєкт PDB з файлу YAML.

Визначення застосунку для захисту

Найбільш поширене використання полягає в захисті застосунку, який визначено одним із вбудованих контролерів Kubernetes:

  • Deployment (Розгортання)
  • ReplicationController (Контролер Реплікації)
  • ReplicaSet (Набір Реплік)
  • StatefulSet (Набір зі Станом)

У цьому випадку обовʼязково відзначте .spec.selector контролера; той самий селектор використовується в .spec.selector PDBs.

Починаючи з версії 1.15, PDB підтримують власні контролери, де включено субресурс масштабування.

Також можна використовувати PDB зі сторонніми Podʼами, які не контролюються одним із вищевказаних контролерів, або з довільними групами Podʼів, але є деякі обмеження, описані у Довільні робочі навантаження та довільні селектори.

Подумайте про реакцію вашого застосунку на відключення

Вирішіть, скільки екземплярів може бути вимкнено одночасно на короткий період часу через добровільні відключення.

  • Фронтенди без збереження стану:
    • Застереження: не зменшуйте потужність обслуговування більш ніж на 10%.
      • Рішення: використовуйте PDB з minAvailable 90%, наприклад.
  • Одноекземплярний застосунок зі збереженням стану:
    • Застереження: не закривайте цей застосунок без спілкування зі мною.
      • Можливе рішення 1: Не використовуйте PDB і терпіть випадковий простій.
      • Можливе рішення 2: Встановіть PDB з maxUnavailable=0. Маючи розуміння (поза Kubernetes), що оператор кластера повинен звʼязатися з вами перед закриттям. Коли оператор кластера звертається до вас, готуйтеся до простою, а потім видаліть PDB, щоб показати готовність до відключення. Після цього створіть новий.
  • Багатоекземплярний застосунок зі збереженням стану, такий як Consul, ZooKeeper або etcd:
    • Застереження: не зменшуйте кількість екземплярів нижче кворуму, в іншому випадку записи будуть невдалі.
      • Можливе рішення 1: встановіть maxUnavailable на рівень 1 (працює з різними масштабами застосунку).
      • Можливе рішення 2: встановіть minAvailable рівним розміру кворуму (наприклад, 3 при масштабуванні 5). (Дозволяє більше відключень одночасно).
  • Пакетне завдання (Job) з перезапуском:
    • Застереження: завдання повинно завершитися у разі добровільного відключення.
      • Можливе рішення: Не створюйте PDB. Контролер завдань створить Pod на заміну.

Логіка округлення при вказанні відсотків

Значення для minAvailable або maxUnavailable можуть бути виражені як цілі числа або як відсотки.

  • Коли ви вказуєте ціле число, воно представляє кількість Podʼів. Наприклад, якщо ви встановите minAvailable на 10, то завжди повинно бути доступно 10 Podʼів, навіть під час відключення.
  • Коли ви вказуєте відсоток, встановивши значення як рядкове представлення відсотка (наприклад, "50%"), воно представляє відсоток від загальної кількості Podʼів. Наприклад, якщо ви встановите minAvailable на "50%", то принаймні 50% Podʼів залишаться доступними під час відключення.

Коли ви вказуєте значення як відсоток, це може не відповідати точній кількості Podʼів. Наприклад, якщо у вас є 7 Podʼів і ви встановите minAvailable на "50%", то не зразу очевидно, чи має це означати, що повинно бути доступно 3 або 4 Podʼи. Kubernetes округлює до найближчого цілого числа, тому в цьому випадку повинно бути доступно 4 Podʼи. Коли ви вказуєте значення maxUnavailable як відсоток, Kubernetes округлює кількість Podʼів, які можуть бути відключені. Таким чином, відключення може перевищувати ваш визначений відсоток maxUnavailable. Ви можете ознайомитися з кодом, який керує такою поведінкою.

Вказання PodDisruptionBudget

PodDisruptionBudget має три поля:

  • Селектор міток .spec.selector, щоб вказати набір Podʼів, до яких він застосовується. Це поле обовʼязкове.
  • .spec.minAvailable — це опис кількості Podʼів з цього набору, які повинні залишитися доступними після відключення, навіть у відсутності відключеного Podʼа. minAvailable може бути абсолютним числом або відсотком.
  • .spec.maxUnavailable (доступний у Kubernetes 1.7 та вище) — це опис кількості Podʼів з цього набору, які можуть бути недоступними після відключення. Це також може бути абсолютним числом або відсотком.

Ви можете вказати лише один із maxUnavailable або minAvailable в одному PodDisruptionBudget. maxUnavailable може бути використаний лише для контролю відключення Podʼів, які мають повʼязаний контролер, який керує ними. У наведених нижче прикладах, "бажані репліки" — це масштаб контролера, що керує Podʼами, які вибрані PodDisruptionBudget.

Приклад 1: З minAvailable 5, відключення дозволяються, поки залишаються 5 або більше справних Podʼів серед тих, які вибрані селектором PodDisruptionBudget.

Приклад 2: З minAvailable 30%, відключення дозволяються, якщо принаймні 30% від кількості бажаних реплік є справними.

Приклад 3: З maxUnavailable 5, відключення дозволяються, поки є не більше 5 несправних реплік серед загальної кількості бажаних реплік.

Приклад 4: З maxUnavailable 30%, відключення дозволяються, якщо кількість несправних реплік не перевищує 30% від загальної кількості бажаних реплік, округленої до найближчого цілого числа. Якщо загальна кількість бажаних реплік — лише одна, ця єдина репліка все ще допускається до відключення, що призводить до ефективної недоступності на 100%.

У типовому використанні один бюджет використовуватиметься для збірки Podʼів, керованих контролером — наприклад, Podʼів у одному ReplicaSet або StatefulSet.

Якщо ви встановите maxUnavailable на 0% або 0, або ви встановите minAvailable на 100% або рівну кількості реплік, ви вимагаєте нульових добровільних виселень. Коли ви встановлюєте нульові добровільні відключення для робочого навантаження, такого як ReplicaSet, тоді ви не зможете успішно вивести з експлуатації вузол, на якому працює один з цих Podʼів. Якщо ви намагаєтеся вивести з експлуатації вузол, де працює невиселяємий Pod, відключення ніколи не завершиться. Це допускається згідно з семантикою PodDisruptionBudget.

Ви можете знайти приклади визначення бюджетів відключення Podʼів нижче. Вони відповідають Podʼам з міткою app: zookeeper.

Приклад PDB з використанням minAvailable:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: zk-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: zookeeper

Приклад PDB з використанням maxUnavailable:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: zk-pdb
spec:
  maxUnavailable: 1
  selector:
    matchLabels:
      app: zookeeper

Наприклад, якщо вищезгаданий обʼєкт zk-pdb вибирає Podʼи з StatefulSet розміром 3, обидві специфікації мають точно таке ж значення. Рекомендується використання maxUnavailable, оскільки він автоматично реагує на зміни кількості реплік відповідного контролера.

Створення обʼєкта PodDisruptionBudget

Для створення або оновлення обʼєкта PDB використовуйте наступну команду kubectl:

kubectl apply -f mypdb.yaml

Перевірка статусу обʼєкта PodDisruptionBudget

Щоб перевірити статус обʼєкта PDB, скористайтеся наступною командою kubectl.

Якщо в вашому просторі імен відсутні Podʼи, що відповідають мітці app: zookeeper, ви побачите щось подібне:

kubectl get poddisruptionbudgets
NAME     MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
zk-pdb   2               N/A               0                     7s

Якщо є Podʼи, які відповідають умовам (скажімо, 3), то ви побачите щось на кшталт:

kubectl get poddisruptionbudgets
NAME     MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
zk-pdb   2               N/A               1                     7s

Ненульове значення для ALLOWED DISRUPTIONS означає, що контролер відключення Podʼів бачив Podʼи, підрахував відповідні Podʼи і оновив статус PDB.

Ви можете отримати більше інформації про статус PDB за допомогою цієї команди:

kubectl get poddisruptionbudgets zk-pdb -o yaml
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  annotations:

  creationTimestamp: "2020-03-04T04:22:56Z"
  generation: 1
  name: zk-pdb

status:
  currentHealthy: 3
  desiredHealthy: 2
  disruptionsAllowed: 1
  expectedPods: 3
  observedGeneration: 1

Справність Pod

Поточна реалізація вважає Podʼи справними, якщо вони мають елемент .status.conditions з type="Ready" і status="True". Ці Podʼи відстежуються через поле .status.currentHealthy в статусі PDB.

Політика виселення несправних Podʼів

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.31 [stable]

PodDisruptionBudget, який охороняє застосунок, забезпечує, що кількість Podʼів зі статусом .status.currentHealthy не опуститься нижче, ніж кількість, вказана у .status.desiredHealthy, не дозволяючи видалення справних Podʼів. Використовуючи .spec.unhealthyPodEvictionPolicy, ви також можете визначити критерії, коли несправні Podʼи повинні розглядатися для видалення. Стандартна поведінка, коли політика не вказана, відповідає політиці IfHealthyBudget.

Політики:

IfHealthyBudget
Запущені Podʼи (.status.phase="Running"), але ще не справні, можуть бути виселені тільки якщо охоронюваний застосунок не відключений (.status.currentHealthy щонайменше дорівнює .status.desiredHealthy).

Ця політика забезпечує, що запущені Podʼи вже відключеного застосунку мають кращі шанси стати справними. Це має негативні наслідки для виведення вузлів з експлуатації, які можуть бути заблоковані неправильно працюючими застосунками, які охороняються PDB. Зокрема, застосунки з Podʼами у стані CrashLoopBackOff (через помилку або неправильну конфігурацію), або Podʼи, яким просто не вдається повідомити умову Ready.

AlwaysAllow
Запущені Podʼи (.status.phase="Running"), але ще не справні вважаються відключеними та можуть бути видалені незалежно від того, чи виконуються критерії в PDB.

Це означає, що майбутні запущені Podʼи відключеного застосунку можуть не мати можливості стати справними. Використовуючи цю політику, менеджери кластера можуть легко вивести з експлуатації неправильно працюючі застосунки, які охороняються PDB. Зокрема, застосунки з Podʼами у стані CrashLoopBackOff (через помилку або неправильну конфігурацію), або Podʼи, які просто не вдаються відправити умову Ready.

Довільні робочі навантаження та селектори

Ви можете пропустити цей розділ, якщо ви використовуєте PDB лише зі вбудованими ресурсами навантаження (Deployment, ReplicaSet, StatefulSet та ReplicationController) або з власними ресурсами, які реалізують субресурс scale, і де селектор PDB точно відповідає селектору власного ресурсу Podʼа.

Ви можете використовувати PDB з підпроцесами, керованими іншим ресурсом, "оператором" або голими підпроцесами, але з такими обмеженнями:

  • можна використовувати лише .spec.minAvailable, а не .spec.maxUnavailable.
  • можна використовувати лише ціле значення з .spec.minAvailable, а не відсоток.

Неможливо використовувати інші конфігурації доступності, оскільки Kubernetes не може вивести загальну кількість Podʼів без підтримуваного власного ресурсу.

Ви можете використовувати селектор, який вибирає підмножину або надмножину Podʼів, що належать ресурсу навантаження. Eviction API не дозволить виселення будь-якого Podʼа, покритого кількома PDB, тому більшість користувачів захочуть уникати перетинаючих селекторів. Одним розумним використанням перетинаючих PDB є перехід Podʼів з одного PDB до іншого.

4.8.10 - Отримання доступу до API Kubernetes з Pod

Цей посібник демонструє, як отримати доступ до API Kubernetes з середини Pod.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Отримання доступу до API з середини Pod

При доступі до API з середини Pod, пошук та автентифікація до сервера API відрізняються трохи від зовнішнього клієнта.

Найпростіший спосіб використовувати API Kubernetes з Pod — використовувати одну з офіційних клієнтських бібліотек. Ці бібліотеки можуть автоматично визначати сервер API та автентифікувати.

Використання офіційних клієнтських бібліотек

З середини Pod рекомендовані способи підключення до API Kubernetes:

У кожному випадку облікові дані облікового службово запису Pod використовуються для забезпечення безпечного звʼязку з сервером API.

Прямий доступ до REST API

Під час роботи в Pod ваш контейнер може створити HTTPS URL для сервера API Kubernetes, отримавши змінні середовища KUBERNETES_SERVICE_HOST та KUBERNETES_SERVICE_PORT_HTTPS. Внутрішня адреса сервера API також публікується для Service з іменем kubernetes в просторі імен default, щоб Pod можна було використовувати kubernetes.default.svc як DNS-імʼя для локального сервера API.

Рекомендований спосіб автентифікації на сервері API — за допомогою облікового службового запису. Стандартно, Pod повʼязаний з обліковим службовим записом, і обліковий запис (токен) для цього облікового службового запису розміщується в дереві файлової системи кожного контейнера в цьому Pod, у /var/run/secrets/kubernetes.io/serviceaccount/token.

Якщо доступно, пакет сертифікатів розміщується в дереві файлової системи кожного контейнера за адресою /var/run/secrets/kubernetes.io/serviceaccount/ca.crt, і його слід використовувати для перевірки сертифіката сервера API.

Нарешті, простір імен default для операцій з просторовими іменами API розміщується в файлі у /var/run/secrets/kubernetes.io/serviceaccount/namespace в кожному контейнері.

Використання kubectl proxy

Якщо ви хочете запитувати API без офіційної клієнтської бібліотеки, ви можете запустити kubectl proxy як команду нового контейнера sidecar в Pod. Таким чином, kubectl proxy буде автентифікуватися до API та викладати його на інтерфейс localhost Pod, щоб інші контейнери в Pod могли використовувати його безпосередньо.

Без використання проксі

Можливо уникнути використання kubectl proxy, передаючи токен автентифікації прямо на сервер API. Внутрішній сертифікат забезпечує зʼєднання.

# Вказати імʼя хоста внутрішнього API-сервера
APISERVER=https://kubernetes.default.svc

# Шлях до токена ServiceAccount
SERVICEACCOUNT=/var/run/secrets/kubernetes.io/serviceaccount

# Прочитати простір імен цього Pod
NAMESPACE=$(cat ${SERVICEACCOUNT}/namespace)

# Прочитати токен облікового службового запису
TOKEN=$(cat ${SERVICEACCOUNT}/token)

# Звертатися до внутрішнього центру сертифікації (CA)
CACERT=${SERVICEACCOUNT}/ca.crt

# Досліджувати API за допомогою TOKEN
curl --cacert ${CACERT} --header "Authorization: Bearer ${TOKEN}" -X GET ${APISERVER}/api

Вивід буде подібний до цього:

{
  "kind": "APIVersions",
  "versions": ["v1"],
  "serverAddressByClientCIDRs": [
    {
      "clientCIDR": "0.0.0.0/0",
      "serverAddress": "10.0.1.149:443"
    }
  ]
}

4.9 - Запуск Job

Запуск Job з використанням паралельної обробки.

4.9.1 - Виконання автоматизованих завдань за допомогою CronJob

Ця сторінка показує, як виконувати автоматизовані завдання за допомогою обʼєкта Kubernetes CronJob.

Перш ніж ви розпочнете

  • Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Створення CronJob

Для роботи з CronJob потрібен файл конфігурації. Нижче подано маніфест для CronJob, який запускає просте демонстраційне завдання кожну хвилину:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "* * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox:1.28
            imagePullPolicy: IfNotPresent
            command:
            - /bin/sh
            - -c
            - date; echo Hello from the Kubernetes cluster
          restartPolicy: OnFailure

Запустіть приклад CronJob за допомогою цієї команди:

kubectl create -f https://k8s.io/examples/application/job/cronjob.yaml

Вивід буде подібний до цього:

cronjob.batch/hello created

Після створення CronJob отримайте його статус за допомогою цієї команди:

kubectl get cronjob hello

Вивід буде подібний до цього:

NAME    SCHEDULE      SUSPEND   ACTIVE   LAST SCHEDULE   AGE
hello   */1 * * * *   False     0        <none>          10s

Як видно з результатів команди, CronJob ще не планував або не запускав жодних завдань. Спостерігайте (watch) за створенням завдання протягом хвилини:

kubectl get jobs --watch

Вивід буде подібний до цього:

NAME               COMPLETIONS   DURATION   AGE
hello-4111706356   0/1                      0s
hello-4111706356   0/1           0s         0s
hello-4111706356   1/1           5s         5s

Тепер ви бачите одне запущене завдання, заплановане cron job "hello". Ви можете припинити спостереження за завданням і переглянути cron job ще раз, щоб побачити, що він запланував завдання:

kubectl get cronjob hello

Вивід буде подібний до цього:

NAME    SCHEDULE      SUSPEND   ACTIVE   LAST SCHEDULE   AGE
hello   */1 * * * *   False     0        50s             75s

Ви повинні побачити, що cron job hello успішно запланував завдання в час, вказаний у LAST SCHEDULE. Наразі немає активних завдань, що означає, що завдання завершилось або зазнало невдачі.

Тепер знайдіть Podʼи, які створило останнє заплановане завдання, та перегляньте стандартний вивід одного з них.

# Замініть "hello-4111706356" на назву завдання у вашій системі
pods=$(kubectl get pods --selector=job-name=hello-4111706356 --output=jsonpath={.items[*].metadata.name})

Покажіть лог Pod:

kubectl logs $pods

Вивід буде подібний до цього:

Fri Feb 22 11:02:09 UTC 2019
Hello from the Kubernetes cluster

Видалення CronJob

Коли вам більше не потрібно cron job, видаліть його за допомогою kubectl delete cronjob <cronjob name>:

kubectl delete cronjob hello

Видалення cron job призводить до видалення всіх створених ним завдань і Podʼів і припинення створення додаткових завдань. Докладніше про видалення завдань читайте в збиранні сміття.

4.9.2 - Груба паралельна обробка за допомогою черги роботи

У цьому прикладі ви запустите Job Kubernetes з кількома паралельними робочими процесами.

У цьому прикладі, при створенні кожного Pod, він бере одиницю роботи з черги завдань, завершує її, видаляє її з черги та завершує роботу.

Ось огляд кроків у цьому прикладі:

  1. Запустіть службу черги повідомлень. У цьому прикладі ви використовуєте RabbitMQ, але ви можете використовувати іншу. На практиці ви налаштовували б службу черги повідомлень один раз і використовували б її для багатьох робочих завдань.
  2. Створіть чергу та заповніть її повідомленнями. Кожне повідомлення являє собою одне завдання для виконання. У цьому прикладі повідомлення — це ціле число, на якому ми будемо виконувати тривалі обчислення.
  3. Запустіть Job, що працює над завданнями з черги. Job створює декілька Podʼів. Кожен Pod бере одне завдання з черги повідомлень, обробляє його та завершує роботу.

Перш ніж ви розпочнете

Ви вже маєте бути знайомі з основним, не-паралельним використанням Job.

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Вам знадобиться реєстр образів контейнерів, куди ви можете завантажувати образи для запуску у своєму кластері.

Цей приклад завдання також передбачає, що у вас вже встановлений Docker локально.

Запуск служби черги повідомлень

У цьому прикладі використовується RabbitMQ, проте ви можете адаптувати приклад для використання іншої служби повідомлень типу AMQP.

На практиці ви можете налаштувати службу черги повідомлень один раз у кластері та використовувати її для багатьох завдань, а також для служб з тривалим виконанням.

Запустіть RabbitMQ таким чином:

# Створіть Service для використання StatefulSet
kubectl create -f https://kubernetes.io/examples/application/job/rabbitmq/rabbitmq-service.yaml
service "rabbitmq-service" created
kubectl create -f https://kubernetes.io/examples/application/job/rabbitmq/rabbitmq-statefulset.yaml
statefulset "rabbitmq" created

Тестування служби черги повідомлень

Тепер ми можемо спробувати доступ до черги повідомлень. Ми створимо тимчасовий інтерактивний Pod, встановимо деякі інструменти на ньому, і спробуємо працювати з чергами.

Спочатку створіть тимчасовий інтерактивний Pod.

# Створіть тимчасовий інтерактивний контейнер
kubectl run -i --tty temp --image ubuntu:22.04
Waiting for pod default/temp-loe07 to be running, status is Pending, pod ready: false
... [ previous line repeats several times .. hit return when it stops ] ...

Зверніть увагу, що ваше імʼя Pod та запрошення командного рядка будуть відрізнятися.

Далі встановіть amqp-tools, щоб працювати з чергами повідомлень. Наступні команди показують, що вам потрібно запустити в середовищі інтерактивної оболонки у цьому Pod:

apt-get update && apt-get install -y curl ca-certificates amqp-tools python3 dnsutils

Пізніше ви створите образ контейнера, який включає ці пакети.

Далі перевірте, що ви можете виявити Service для RabbitMQ:

# Виконайте ці команди всередині Pod
# Зауважте, що для служби rabbitmq-service існує DNS-ім\я, яке надається Kubernetes:
nslookup rabbitmq-service
Server:        10.0.0.10
Address:    10.0.0.10#53

Name:    rabbitmq-service.default.svc.cluster.local
Address: 10.0.147.152

(адреси IP будуть відрізнятися)

Якщо надбудова kube-dns не налаштована правильно, попередній крок може не працювати для вас. Ви також можете знайти IP-адресу для цього Service у змінній середовища:

# виконайте цю перевірку всередині Pod
env | grep RABBITMQ_SERVICE | grep HOST
RABBITMQ_SERVICE_SERVICE_HOST=10.0.147.152

(IP-адреса буде відрізнятися)

Далі перевірте, що ви можете створити чергу, і публікувати та отримувати повідомлення.

# Виконайте ці команди всередині Pod
# У наступному рядку rabbitmq-service - це імʼя хоста, за яким можна звертатися до rabbitmq-service.
# 5672 - це стандартний порт для rabbitmq.
export BROKER_URL=amqp://guest:guest@rabbitmq-service:5672
# Якщо ви не могли отримати доступ до "rabbitmq-service" на попередньому кроці,
# використовуйте цю команду натомість:
BROKER_URL=amqp://guest:guest@$RABBITMQ_SERVICE_SERVICE_HOST:5672

# Тепер створіть чергу:

/usr/bin/amqp-declare-queue --url=$BROKER_URL -q foo -d
foo

Опублікуйте одне повідомлення в черзі:

/usr/bin/amqp-publish --url=$BROKER_URL -r foo -p -b Hello

# І отримайте його назад.

/usr/bin/amqp-consume --url=$BROKER_URL -q foo -c 1 cat && echo 1>&2
Hello

У останній команді інструмент amqp-consume взяв одне повідомлення (-c 1) з черги, і передав це повідомлення на стандартний ввід довільної команди. У цьому випадку програма cat виводить символи, зчитані зі стандартного вводу, а echo додає символ нового рядка, щоб приклад був читабельним.

Заповнення черги завданнями

Тепер заповніть чергу деякими симульованими завданнями. У цьому прикладі завдання — це рядки, які потрібно надрукувати.

На практиці вміст повідомлень може бути таким:

  • назви файлів, які потрібно обробити
  • додаткові прапорці для програми
  • діапазони ключів у таблиці бази даних
  • параметри конфігурації для симуляції
  • номери кадрів сцени для рендерингу

Якщо є великі дані, які потрібно лише для читання всіма Podʼами Job, зазвичай це розміщують на спільній файловій системі, наприклад NFS, і монтується це на всі Podʼи тільки для читання, або напишіть програму в Pod так, щоб вона могла нативно читати дані з кластерної файлової системи (наприклад: HDFS).

У цьому прикладі ви створите чергу та заповните її, використовуючи інструменти командного рядка AMQP. На практиці ви можете написати програму для заповнення черги, використовуючи бібліотеку клієнтів AMQP.

# Виконайте це на вашому компʼютері, а не в Pod
/usr/bin/amqp-declare-queue --url=$BROKER_URL -q job1  -d
job1

Додайте елементи до черги:

for f in apple banana cherry date fig grape lemon melon
do
  /usr/bin/amqp-publish --url=$BROKER_URL -r job1 -p -b $f
done

Ви додали 8 повідомлень у чергу.

Створення образу контейнера

Тепер ви готові створити образ, який ви будете запускати як Job.

Job буде використовувати утиліту amqp-consume для читання повідомлення з черги та виконання реальної роботи. Ось дуже простий приклад програми:

#!/usr/bin/env python

# Просто виводить стандартний вивід і очікує протягом 10 секунд.
import sys
import time
print("Processing " + sys.stdin.readlines()[0])
time.sleep(10)

Дайте скрипту дозвіл на виконання:

chmod +x worker.py

Тепер створіть образ. Створіть тимчасову теку, перейдіть в неї, завантажте Dockerfile, і worker.py. У будь-якому випадку, створіть образ за допомогою цієї команди:

docker build -t job-wq-1 .

Для Docker Hub позначте ваш образ застосунка вашим імʼям користувача і завантажте його на Hub за допомогою таких команд. Замініть <username> на ваше імʼя користувача Hub.

docker tag job-wq-1 <username>/job-wq-1
docker push <username>/job-wq-1

Якщо ви використовуєте альтернативний реєстр образів контейнерів, позначте образ і завантажте його туди замість цього.

Визначення Job

Ось маніфест для Job. Вам потрібно зробити копію маніфеста Job (назвіть його ./job.yaml), і змініть імʼя образу контейнера, щоб відповідало імені, яке ви використовували.

apiVersion: batch/v1
kind: Job
metadata:
  name: job-wq-1
spec:
  completions: 8
  parallelism: 2
  template:
    metadata:
      name: job-wq-1
    spec:
      containers:
      - name: c
        image: gcr.io/<project>/job-wq-1
        env:
        - name: BROKER_URL
          value: amqp://guest:guest@rabbitmq-service:5672
        - name: QUEUE
          value: job1
      restartPolicy: OnFailure

У цьому прикладі кожен Pod працює над одним елементом з черги, а потім виходить. Таким чином, кількість завершень завдання відповідає кількості виконаних робочих елементів. Тому у прикладі маніфесту .spec.completions встановлено на 8.

Запуск Job

Тепер запустіть завдання:

# це передбачає, що ви вже завантажили та відредагували маніфест
kubectl apply -f ./job.yaml

Ви можете зачекати, доки завдання успішно виконається, використовуючи тайм-аут:

# Перевірка для умови що імена нечутливі до регістру
kubectl wait --for=condition=complete --timeout=300s job/job-wq-1

Далі перевірте стан завдання:

kubectl describe jobs/job-wq-1
Name:             job-wq-1
Namespace:        default
Selector:         controller-uid=41d75705-92df-11e7-b85e-fa163ee3c11f
Labels:           controller-uid=41d75705-92df-11e7-b85e-fa163ee3c11f
                  job-name=job-wq-1
Annotations:      <none>
Parallelism:      2
Completions:      8
Start Time:       Wed, 06 Sep 2022 16:42:02 +0000
Pods Statuses:    0 Running / 8 Succeeded / 0 Failed
Pod Template:
  Labels:       controller-uid=41d75705-92df-11e7-b85e-fa163ee3c11f
                job-name=job-wq-1
  Containers:
   c:
    Image:      container-registry.example/causal-jigsaw-637/job-wq-1
    Port:
    Environment:
      BROKER_URL:       amqp://guest:guest@rabbitmq-service:5672
      QUEUE:            job1
    Mounts:             <none>
  Volumes:              <none>
Events:
  FirstSeen  LastSeen   Count    From    SubobjectPath    Type      Reason              Message
  ─────────  ────────   ─────    ────    ─────────────    ──────    ──────              ───────
  27s        27s        1        {job }                   Normal    SuccessfulCreate    Created pod: job-wq-1-hcobb
  27s        27s        1        {job }                   Normal    SuccessfulCreate    Created pod: job-wq-1-weytj
  27s        27s        1        {job }                   Normal    SuccessfulCreate    Created pod: job-wq-1-qaam5
  27s        27s        1        {job }                   Normal    SuccessfulCreate    Created pod: job-wq-1-b67sr
  26s        26s        1        {job }                   Normal    SuccessfulCreate    Created pod: job-wq-1-xe5hj
  15s        15s        1        {job }                   Normal    SuccessfulCreate    Created pod: job-wq-1-w2zqe
  14s        14s        1        {job }                   Normal    SuccessfulCreate    Created pod: job-wq-1-d6ppa
  14s        14s        1        {job }                   Normal    SuccessfulCreate    Created pod: job-wq-1-p17e0

Усі Podʼи для цього завдання успішно виконалися! У вас вийшло.

Альтернативи

Цей підхід має перевагу у тому, що вам не потрібно змінювати вашу "робочу" програму, щоб вона була обізнана, що є черга роботи. Ви можете включити незмінену робочу програму у свій контейнерний образ.

Використання цього підходу передбачає запуск сервісу черги повідомлень. Якщо запуск сервісу черги є не зручним, ви можете розглянути один з інших шаблонів завдань.

Цей підхід створює Pod для кожного робочого елемента. Якщо ваші робочі елементи займають лише декілька секунд, створення Podʼа для кожного робочого елемента може додати багато накладних витрат. Розгляньте інший дизайн, наприклад, у прикладі тонкої паралельної черги робочих елементів, що виконує кілька робочих елементів на кожному Pod.

У цьому прикладі ви використовували утиліту amqp-consume для читання повідомлення з черги та запуску реальної програми. Це має перевагу у тому, що вам не потрібно модифікувати свою програму, щоб вона була обізнана про існування черги. У прикладі тонкої паралельної черги робочих елементів показано, як спілкуватися з чергою робочих елементів за допомогою клієнтської бібліотеки.

Обмеження

Якщо кількість завершень встановлена меншою, ніж кількість елементів у черзі, то не всі елементи будуть оброблені.

Якщо кількість завершень встановлена більшою, ніж кількість елементів у черзі, то завдання не буде здаватися завершеним, навіть якщо всі елементи у черзі були оброблені. Воно буде запускати додаткові Podʼи, які будуть блокуватися, чекаючи на повідомлення. Вам потрібно буде створити свій власний механізм для виявлення наявності роботи для виконання і вимірювати розмір черги, встановлюючи кількість завершень відповідно.

Існують малоймовірні перегони для цього патерну. Якщо контейнер був завершений між часом, коли повідомлення було підтверджено командою amqp-consume, і часом, коли контейнер вийшов з успішним завершенням, або якщо вузол зазнає збою, перш ніж kubelet зможе розмістити успіх Podʼа назад до сервера API, то завдання не буде здаватися завершеним, навіть якщо всі елементи у черзі були оброблені.

4.9.3 - Тонка паралельна обробка за допомогою черги роботи

In цьому прикладі ви запустите Job Kubernetes, яке виконує декілька паралельних завдань як робочі процеси, кожен з яких працює як окремий Pod.

У цьому прикладі, при створенні кожного Podʼа, він бере одиницю роботи з черги завдань, обробляє її та повторює цей процес до досягнення кінця черги.

Ось загальний огляд кроків у цьому прикладі:

  1. Запустіть службу зберігання, щоб зберігати чергу завдань. У цьому прикладі ви використаєте Redis для зберігання робочих елементів. У попередньому прикладі, ви використали RabbitMQ. У цьому прикладі ви будете використовувати Redis та власну бібліотеку клієнтів черг завдань; це тому, що AMQP не надає зручний спосіб клієнтам виявити, коли скінчиться черга робочих елементів з обмеженою довжиною. На практиці ви налаштуєте сховище, таке як Redis, один раз і повторно використовуватимете його для черг робочих завдань багатьох завдань та іншого.
  2. Створіть чергу та заповніть її повідомленнями. Кожне повідомлення представляє одне завдання, яке потрібно виконати. У цьому прикладі повідомленням є ціле число, над яким ми виконаємо тривалі обчислення.
  3. Запустіть завдання, яке працює над завданнями з черги. Завдання запускає декілька Podʼів. Кожний Pod бере одне завдання з черги повідомлень, обробляє його та повторює цей процес до досягнення кінця черги.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Вам знадобиться реєстр контейнерних образів, де ви можете завантажувати образи для запуску у вашому кластері. У прикладі використовується Docker Hub, але ви можете адаптувати його до іншого реєстру контейнерних образів.

Цей приклад передбачає, що у вас встановлено Docker локально. Ви будете використовувати Docker для створення контейнерних образів.

Ви маєти бути знайомі з базовим, не-паралельним використанням Job.

Запуск Redis

У цьому прикладі, для спрощення, ви запустите один екземпляр Redis. Дивіться Приклад Redis для прикладу розгортання Redis масштабовано та надійно.

Ви також можете завантажити наступні файли безпосередньо:

Для запуску одного екземпляра Redis вам потрібно створити Pod Redis та Service Redis:

kubectl apply -f https://k8s.io/examples/application/job/redis/redis-pod.yaml
kubectl apply -f https://k8s.io/examples/application/job/redis/redis-service.yaml

Заповнення черги завданнями

Тепер заповнімо чергу деякими "задачами". У цьому прикладі завданнями є рядки, які потрібно вивести.

Запустіть тимчасовий інтерактивний Pod для використання Redis CLI.

kubectl run -i --tty temp --image redis --command "/bin/sh"
Waiting for pod default/redis2-c7h78 to be running, status is Pending, pod ready: false
Hit enter for command prompt

Тепер натисніть Enter, запустіть Redis CLI та створіть список з деякими елементами роботи в ньому.

redis-cli -h redis
redis:6379> rpush job2 "apple"
(integer) 1
redis:6379> rpush job2 "banana"
(integer) 2
redis:6379> rpush job2 "cherry"
(integer) 3
redis:6379> rpush job2 "date"
(integer) 4
redis:6379> rpush job2 "fig"
(integer) 5
redis:6379> rpush job2 "grape"
(integer) 6
redis:6379> rpush job2 "lemon"
(integer) 7
redis:6379> rpush job2 "melon"
(integer) 8
redis:6379> rpush job2 "orange"
(integer) 9
redis:6379> lrange job2 0 -1
1) "apple"
2) "banana"
3) "cherry"
4) "date"
5) "fig"
6) "grape"
7) "lemon"
8) "melon"
9) "orange"

Отже, список з ключем job2 буде чергою роботи.

Примітка: якщо у вас неправильно налаштовано Kube DNS, вам може знадобитися змінити перший крок вищезазначеного блоку на redis-cli -h $REDIS_SERVICE_HOST.

Створення образу контейнера

Тепер ви готові створити образ, який буде обробляти завдання в цій черзі.

Ви будете використовувати робочу програму на Python з клієнтом Redis для читання повідомлень з черги повідомлень.

Надається проста бібліотека клієнтів черги роботи Redis, яка називається rediswq.py (Завантажити).

Програма "робітник" в кожному Pod Job використовує бібліотеку клієнтів черги роботи, щоб отримати роботу. Ось вона:

#!/usr/bin/env python

import time
import rediswq

host="redis"
# Якщо у вас немає працюючого Kube-DNS, розкоментуйте наступні два рядки.
# import os
# host = os.getenv("REDIS_SERVICE_HOST")

q = rediswq.RedisWQ(name="job2", host=host)
print("Worker with sessionID: " +  q.sessionID())
print("Initial queue state: empty=" + str(q.empty()))
while not q.empty():
  item = q.lease(lease_secs=10, block=True, timeout=2) 
  if item is not None:
    itemstr = item.decode("utf-8")
    print("Working on " + itemstr)
    time.sleep(10) # Put your actual work here instead of sleep.
    q.complete(item)
  else:
    print("Waiting for work")
print("Queue empty, exiting")

Ви також можете завантажити файли worker.py, rediswq.py та Dockerfile, а потім побудувати контейнерний образ. Ось приклад використання Docker для побудови образу:

docker build -t job-wq-2 .

Збереження образу в реєстрі

Для Docker Hub, позначте свій образ програми імʼям користувача та завантажте його до Hub за допомогою наступних команд. Замість <username> вкажіть своє імʼя користувача Hub.

docker tag job-wq-2 <username>/job-wq-2
docker push <username>/job-wq-2

Вам потрібно завантажити в публічний репозиторій або налаштувати кластер для доступу до вашого приватного репозиторію.

Визначення завдання

Ось маніфест для створення Job:

apiVersion: batch/v1
kind: Job
metadata:
  name: job-wq-2
spec:
  parallelism: 2
  template:
    metadata:
      name: job-wq-2
    spec:
      containers:
      - name: c
        image: gcr.io/myproject/job-wq-2
      restartPolicy: OnFailure

У цьому прикладі кожний Pod працює з кількома елементами черги, а потім виходить, коли елементи закінчуються. Оскільки самі робочі процеси виявляють порожнечу робочої черги, а контролер завдань не володіє інформацією про робочу чергу, він покладається на робочі процеси, щоб сигналізувати, коли вони закінчили роботу. Робочі процеси сигналізують, що черга порожня, вийшовши з успіхом. Таким чином, як тільки будь-який робочий процес виходить з успіхом, контролер знає, що робота виконана, і що Podʼи скоро вийдуть. Тому вам потрібно залишити лічильник завершення завдання невизначеним. Контролер завдань зачекає, доки інші Podʼи завершаться також.

Запуск завдання

Отже, зараз запустіть завдання:

# передбачається, що ви вже завантажили та відредагували маніфест
kubectl apply -f ./job.yaml

Тепер зачекайте трохи, а потім перевірте стан завдання:

kubectl describe jobs/job-wq-2
Name:             job-wq-2
Namespace:        default
Selector:         controller-uid=b1c7e4e3-92e1-11e7-b85e-fa163ee3c11f
Labels:           controller-uid=b1c7e4e3-92e1-11e7-b85e-fa163ee3c11f
                  job-name=job-wq-2
Annotations:      <none>
Parallelism:      2
Completions:      <unset>
Start Time:       Mon, 11 Jan 2022 17:07:59 +0000
Pods Statuses:    1 Running / 0 Succeeded / 0 Failed
Pod Template:
  Labels:       controller-uid=b1c7e4e3-92e1-11e7-b85e-fa163ee3c11f
                job-name=job-wq-2
  Containers:
   c:
    Image:              container-registry.example/exampleproject/job-wq-2
    Port:
    Environment:        <none>
    Mounts:             <none>
  Volumes:              <none>
Events:
  FirstSeen    LastSeen    Count    From            SubobjectPath    Type        Reason            Message
  ---------    --------    -----    ----            -------------    --------    ------            -------
  33s          33s         1        {job-controller }                Normal      SuccessfulCreate  Created pod: job-wq-2-lglf8

Ви можете зачекати, поки завдання завершиться успішно, з тайм-аутом:

# Перевірка умови назви нечутлива до регістру
kubectl wait --for=condition=complete --timeout=300s job/job-wq-2
kubectl logs pods/job-wq-2-7r7b2
Worker with sessionID: bbd72d0a-9e5c-4dd6-abf6-416cc267991f
Initial queue state: empty=False
Working on banana
Working on date
Working on lemon

Як бачите, один з Podʼів для цього завдання працював над кількома робочими одиницями.

Альтернативи

Якщо запуск служби черги або модифікація ваших контейнерів для використання робочої черги є незручними, ви можете розглянути один з інших шаблонів завдань.

Якщо у вас є постійний потік фонової обробки, яку потрібно виконувати, то розгляньте запуск ваших фонових робітників за допомогою ReplicaSet, і розгляньте використання бібліотеки фонової обробки, такої як https://github.com/resque/resque.

4.9.4 - Індексоване завдання (Job) для паралельної обробки з фіксованим призначенням роботи

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.24 [stable]

У цьому прикладі ви запустите Job Kubernetes, яке використовує кілька паралельних робочих процесів. Кожен робочий процес — це різний контейнер, що працює у власному Podʼі. Podʼи мають індексний номер, який автоматично встановлює панель управління, що дозволяє кожному Podʼу визначити, над якою частиною загального завдання працювати.

Індекс Podʼа доступний в анотації batch.kubernetes.io/job-completion-index у вигляді рядка, який представляє його десяткове значення. Щоб контейнеризований процес завдання отримав цей індекс, можна опублікувати значення анотації за допомогою механізму downward API. Для зручності панель управління автоматично встановлює downward API для експонування індексу в змінну середовища JOB_COMPLETION_INDEX.

Нижче наведено огляд кроків у цьому прикладі:

  1. Визначте маніфест завдання з використанням індексованого завершення. Downward API дозволяє передавати індекс Podʼа як змінну середовища або файл до контейнера.
  2. Запустіть Indexed завдання на основі цього маніфесту.

Перш ніж ви розпочнете

Ви маєти бути знайомі з базовим, не-паралельним використанням Job.

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Версія вашого Kubernetes сервера має бути не старішою ніж v1.21. Для перевірки версії введіть kubectl version.

Оберіть підхід

Щоб отримати доступ до робочого елемента з програми робочого процесу, у вас є кілька варіантів:

  1. Прочитайте змінну середовища JOB_COMPLETION_INDEX. Job контролер автоматично повʼязує цю змінну з анотацією, що містить індекс завершення.
  2. Прочитайте файл, який містить індекс завершення.
  3. Припускаючи, що ви не можете змінити програму, ви можете обгорнути її сценарієм, який читає індекс за допомогою будь-якого з методів вище і перетворює його в щось, що програма може використовувати як вхід.

У цьому прикладі уявіть, що ви вибрали третій варіант, і ви хочете запустити rev утиліту. Ця програма приймає файл як аргумент і виводить зміст у зворотньому порядку.

rev data.txt

Ви будете використовувати інструмент rev з контейнерного образу busybox.

Оскільки це лише приклад, кожен Pod робить лише невеликий шматок роботи (реверсування короткого рядка). У реальному навантаженні ви, наприклад, можете створити Job, що представляє задачу рендерингу 60 секунд відео на основі даних про сцену. Кожен робочий елемент в завданні відеорендерингу буде створювати певний кадр цього відеокліпу. Індексоване завершення означатиме, що кожен Pod у Job знає, який кадр рендерити та опублікувати, рахуючи кадри від початку кліпу.

Визначте Indexed Job

Ось приклад маніфесту Job, який використовує режим завершення Indexed:

apiVersion: batch/v1
kind: Job
metadata:
  name: 'indexed-job'
spec:
  completions: 5
  parallelism: 3
  completionMode: Indexed
  template:
    spec:
      restartPolicy: Never
      initContainers:
      - name: 'input'
        image: 'docker.io/library/bash'
        command:
        - "bash"
        - "-c"
        - |
          items=(foo bar baz qux xyz)
          echo ${items[$JOB_COMPLETION_INDEX]} > /input/data.txt          
        volumeMounts:
        - mountPath: /input
          name: input
      containers:
      - name: 'worker'
        image: 'docker.io/library/busybox'
        command:
        - "rev"
        - "/input/data.txt"
        volumeMounts:
        - mountPath: /input
          name: input
      volumes:
      - name: input
        emptyDir: {}

У вищенаведеному прикладі ви використовуєте вбудовану змінну середовища JOB_COMPLETION_INDEX, яку встановлює контролер завдань для всіх контейнерів. Контейнер ініціалізації відображає індекс на статичне значення та записує його в файл, який спільно використовується з контейнером, що виконує робочий процес через том emptyDir. Додатково ви можете визначити свою власну змінну середовища через downward API для публікації індексу в контейнерах. Ви також можете вибрати завантаження списку значень з ConfigMap як змінної середовища або файлу.

У іншому варіанті ви можете безпосередньо використовувати downward API для передачі значення анотації як файлу тому, як показано у наступному прикладі:

apiVersion: batch/v1
kind: Job
metadata:
  name: 'indexed-job'
spec:
  completions: 5
  parallelism: 3
  completionMode: Indexed
  template:
    spec:
      restartPolicy: Never
      containers:
      - name: 'worker'
        image: 'docker.io/library/busybox'
        command:
        - "rev"
        - "/input/data.txt"
        volumeMounts:
        - mountPath: /input
          name: input
      volumes:
      - name: input
        downwardAPI:
          items:
          - path: "data.txt"
            fieldRef:
              fieldPath: metadata.annotations['batch.kubernetes.io/job-completion-index']

Запуск Job

Тепер запустіть Job:

# Це використовує перший підхід (покладаючись на $JOB_COMPLETION_INDEX)
kubectl apply -f https://kubernetes.io/examples/application/job/indexed-job.yaml

При створенні цього Завдання панель управління створює серію Podʼів, по одному для кожного вказаного індексу. Значення .spec.parallelism визначає, скільки може працювати одночасно, в той час, як .spec.completions визначає, скільки Podʼів створює Job в цілому.

Оскільки .spec.parallelism менше, ніж .spec.completions, панель управління чекає, поки деякі з перших Podʼів завершаться, перш ніж запустити ще.

Ви можете зачекати, поки Завдання завершиться успішно, з тайм-аутом:

# Перевірка умови назви нечутлива до регістру
kubectl wait --for=condition=complete --timeout=300s job/indexed-job

Тепер опишіть Завдання та переконайтеся, що воно виконалося успішно.

kubectl describe jobs/indexed-job

Вивід схожий на:

Name:              indexed-job
Namespace:         default
Selector:          controller-uid=bf865e04-0b67-483b-9a90-74cfc4c3e756
Labels:            controller-uid=bf865e04-0b67-483b-9a90-74cfc4c3e756
                   job-name=indexed-job
Annotations:       <none>
Parallelism:       3
Completions:       5
Start Time:        Thu, 11 Mar 2021 15:47:34 +0000
Pods Statuses:     2 Running / 3 Succeeded / 0 Failed
Completed Indexes: 0-2
Pod Template:
  Labels:  controller-uid=bf865e04-0b67-483b-9a90-74cfc4c3e756
           job-name=indexed-job
  Init Containers:
   input:
    Image:      docker.io/library/bash
    Port:       <none>
    Host Port:  <none>
    Command:
      bash
      -c
      items=(foo bar baz qux xyz)
      echo ${items[$JOB_COMPLETION_INDEX]} > /input/data.txt

    Environment:  <none>
    Mounts:
      /input from input (rw)
  Containers:
   worker:
    Image:      docker.io/library/busybox
    Port:       <none>
    Host Port:  <none>
    Command:
      rev
      /input/data.txt
    Environment:  <none>
    Mounts:
      /input from input (rw)
  Volumes:
   input:
    Type:       EmptyDir (тимчасова тека, яка поділяє життя Podʼа)
    Medium:
    SizeLimit:  <unset>
Events:
  Type    Reason            Age   From            Message
  ----    ------            ----  ----            -------
  Normal  SuccessfulCreate  4s    job-controller  Created pod: indexed-job-njkjj
  Normal  SuccessfulCreate  4s    job-controller  Created pod: indexed-job-9kd4h
  Normal  SuccessfulCreate  4s    job-controller  Created pod: indexed-job-qjwsz
  Normal  SuccessfulCreate  1s    job-controller  Created pod: indexed-job-fdhq5
  Normal  SuccessfulCreate  1s    job-controller  Created pod: indexed-job-ncslj

У цьому прикладі ви запускаєте Job з власними значеннями для кожного індексу. Ви можете оглянути вивід одного з Podʼів:

kubectl logs indexed-job-fdhq5 # Змініть це, щоб відповідати імені Podʼа з цього Завдання ```

Вивід схожий на:

xuq

4.9.5 - Завдання (Job) з комунікацією Pod-Pod

У цьому прикладі ви запустите Job в Indexed completion mode, налаштований таким чином, щоб Podʼи, створені Job, могли комунікувати один з одним, використовуючи назви хостів Podʼів, а не IP-адреси Podʼів.

Podʼи в межах Job можуть потребувати комунікації між собою. Робоче навантаження користувача, що виконується в кожному Podʼі, може звертатися до сервера API Kubernetes для отримання IP-адрес інших Podʼів, але набагато простіше покладатися на вбудований DNS-резолвер Kubernetes.

Job в Indexed completion mode автоматично встановлюють назви хостів Podʼів у форматі ${jobName}-${completionIndex}. Ви можете використовувати цей формат для детермінованого створення назв хостів Podʼів та забезпечення комунікації між Podʼами без необхідності створювати клієнтське з’єднання з панеллю управління Kubernetes для отримання назв хостів/IP-адрес Podʼів через API-запити.

Ця конфігурація корисна для випадків, коли необхідна мережева взаємодія Podʼів, але ви не хочете залежати від мережевого з’єднання з сервером API Kubernetes.

Перш ніж ви розпочнете

Ви повинні вже бути знайомі з основами використання Job.

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Версія вашого Kubernetes сервера має бути не старішою ніж v1.21. Для перевірки версії введіть kubectl version.

Запуск роботи з комунікацією між Podʼами

Щоб увімкнути комунікацію між Podʼами з використанням назв хостів Podʼів у Job, ви повинні зробити наступне:

  1. Налаштуйте headless Service з дійсним селектором міток для Podʼів, створених вашим Job. Headless Service має бути в тому ж просторі імен, що й Job. Один із простих способів зробити це — використати селектор job-name: <your-job-name>, оскільки мітка job-name буде додана Kubernetes автоматично. Ця конфігурація активує систему DNS для створення записів назв хостів Podʼів, що виконують ваш обʼєкт Job.

  2. Налаштуйте headless Service як піддомен для Podʼів Job, включивши наступне значення у ваш шаблон специфікації Job:

    subdomain: <headless-svc-name>
    

Приклад

Нижче наведено робочий приклад Job з увімкненою комунікацією між Podʼами через назви хостів Podʼів. Job завершується лише після того, як усі Podʼи успішно пінгують один одного за допомогою назв хостів.


apiVersion: v1
kind: Service
metadata:
  name: headless-svc
spec:
  clusterIP: None # clusterIP має бути None для створення headless service
  selector:
    job-name: example-job # має відповідати імені Job
---
apiVersion: batch/v1
kind: Job
metadata:
  name: example-job
spec:
  completions: 3
  parallelism: 3
  completionMode: Indexed
  template:
    spec:
      subdomain: headless-svc # має відповідати імені Service
      restartPolicy: Never
      containers:
      - name: example-workload
        image: bash:latest
        command:
        - bash
        - -c
        - |
          for i in 0 1 2
          do
            gotStatus="-1"
            wantStatus="0"             
            while [ $gotStatus -ne $wantStatus ]
            do                                       
              ping -c 1 example-job-${i}.headless-svc > /dev/null 2>&1
              gotStatus=$?                
              if [ $gotStatus -ne $wantStatus ]; then
                echo "Failed to ping pod example-job-${i}.headless-svc, retrying in 1 second..."
                sleep 1
              fi
            done                                                         
            echo "Successfully pinged pod: example-job-${i}.headless-svc"
          done          

Після застосування наведеного вище прикладу, Podʼи зможуть звертатись один до одного в мережі, використовуючи: <pod-hostname>.<headless-service-name>. Ви повинні побачити вихідні дані, подібні до наступних:

kubectl logs example-job-0-qws42
Failed to ping pod example-job-0.headless-svc, retrying in 1 second...
Successfully pinged pod: example-job-0.headless-svc
Successfully pinged pod: example-job-1.headless-svc
Successfully pinged pod: example-job-2.headless-svc

4.9.6 - Паралельна обробка з розширенням

Це завдання демонструє запуск кількох Jobs на основі загального шаблону. Ви можете використовувати цей підхід для обробки пакетних завдань паралельно.

У цьому прикладі є лише три елементи: apple, banana та cherry. Приклади Job обробляють кожен елемент, виводячи рядок, а потім очікуючи дії користувача.

Див. використання Job у реальних навантаженнях, щоб дізнатися, як цей підхід вписується у більш реалістичні випадки використання.

Перш ніж ви розпочнете

Вам слід бути знайомим з базовим, не-паралельним використанням Job.

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Для базового шаблонування вам потрібна утиліта командного рядка sed.

Для виконання розширеного прикладу шаблонування вам потрібен встановлений Python та бібліотека шаблонів Jinja2 для Python.

Після налаштування Python ви можете встановити Jinja2, виконавши:

pip install --user jinja2

Створення Job на основі шаблону

Спочатку завантажте наступний шаблон Job у файл з назвою job-tmpl.yaml. Ось що ви завантажите:

apiVersion: batch/v1
kind: Job
metadata:
  name: process-item-$ITEM
  labels:
    jobgroup: jobexample
spec:
  template:
    metadata:
      name: jobexample
      labels:
        jobgroup: jobexample
    spec:
      containers:
      - name: c
        image: busybox:1.28
        command: ["sh", "-c", "echo Processing item $ITEM && sleep 5"]
      restartPolicy: Never
# Використайте curl для завантаження job-tmpl.yaml
curl -L -s -O https://k8s.io/examples/application/job/job-tmpl.yaml

Завантажений вами файл ще не є валідним маніфестом Kubernetes. Замість цього цей шаблон є YAML-представленням об’єкта Job з деякими заповнювачами, які потрібно замінити перед використанням. Синтаксис $ITEM не має значення для Kubernetes.

Створення маніфестів з шаблону

Наступний код використовує sed для заміни $ITEM на значення змінної з циклу, зберігаючи результат в тимчасову теку jobs:

# Розмноження шаблону на кілька файлів, по одному для коженого процесу
mkdir -p ./jobs
for item in apple banana cherry
do
  cat job-tmpl.yaml | sed "s/\$ITEM/$i/g" > ./jobs/job-$i.yaml
done

На виході ви маєте отримати три файли:

job-apple.yaml
job-banana.yaml
job-cherry.yaml

Створення Завдань (Job) з маніфестів

Далі, створіть всі три Job, використовуючи файли, які ви створили:

kubectl apply -f ./jobs

Вивід буде подібний до цього:

job.batch/process-item-apple created
job.batch/process-item-banana created
job.batch/process-item-cherry created

Тепер ви можете перевірити стан Job:

kubectl get jobs -l jobgroup=jobexample

Вивід буде подібний до цього:

NAME                  COMPLETIONS   DURATION   AGE
process-item-apple    1/1           14s        22s
process-item-banana   1/1           12s        21s
process-item-cherry   1/1           12s        20s

Використання опції -l для kubectl вибирає лише Job, які є частиною цієї групи Job (в системі можуть бути інші не Завдання (Job)).

Ви також можете перевірити стан Podʼів, використовуючи той самий селектор міток:

kubectl get pods -l jobgroup=jobexample

Вивід буде подібний до цього:

NAME                        READY     STATUS      RESTARTS   AGE
process-item-apple-kixwv    0/1       Completed   0          4m
process-item-banana-wrsf7   0/1       Completed   0          4m
process-item-cherry-dnfu9   0/1       Completed   0          4m

Ви можете використати цю одну команду для перевірки виводу всіх Job одночасно:

kubectl logs -f -l jobgroup=jobexample

Вивід має бути таким:

Processing item apple
Processing item banana
Processing item cherry

Очищення

# Видаліть створені Job
# Ваш кластер автомтично видаляє пов’язані з Job Pod
kubectl delete jobs -l jobgroup=jobexample

Використання розширених параметрів шаблонів

В першому прикладі, кожен екземпляр шаблону мав один параметр, цей параметр тако використовувався в назві Job. Однак, назви обмежені набором символів, які можна використовувати.

Ось трохи складніший шаблон Jinja, для створення маніфестів та обʼєктів на їх основі, з кількома параметрами для кожного Завдання (Job).

В першій частині завдання скористайтесь однорядковим скриптом Python для перетворення шаблонів в набір маніфестів.

Спочатку скопіюйте та вставте наступний шаблон обʼєкта Job у файл з назвою job.yaml.jinja2:

{% set params = [{ "name": "apple", "url": "http://dbpedia.org/resource/Apple", },
                  { "name": "banana", "url": "http://dbpedia.org/resource/Banana", },
                  { "name": "cherry", "url": "http://dbpedia.org/resource/Cherry" }]
%}
{% for p in params %}
{% set name = p["name"] %}
{% set url = p["url"] %}
---
apiVersion: batch/v1
kind: Job
metadata:
  name: jobexample-{{ name }}
  labels:
    jobgroup: jobexample
spec:
  template:
    metadata:
      name: jobexample
      labels:
        jobgroup: jobexample
    spec:
      containers:
      - name: c
        image: busybox:1.28
        command: ["sh", "-c", "echo Processing URL {{ url }} && sleep 5"]
      restartPolicy: Never
{% endfor %}

Наведений шаблон визначає два параметри для кожного обʼєкта Job за допомогою списку словників Python (рядки 1-4). Цикл for генерує один маніфест Job для кожного набору параметрів (інші рядки).

Цей приклад використовує можливості YAML. Один файл YAML може містити кілька документів (у цьому випадку маніфестів Kubernetes), розділених рядком ---.

Ви можете передати вивід безпосередньо до kubectl, щоб створити Jobs.

Далі використовуйте цю однорядковий скрипт Python для розширення шаблону:

alias render_template='python -c "from jinja2 import Template; import sys; print(Template(sys.stdin.read()).render());"'

Використовуйте render_template для конвертації параметрів та шаблону в один файл YAML, що містить маніфести Kubernetes:

# Це вимагає визначеного раніше аліасу
cat job.yaml.jinja2 | render_template > jobs.yaml

Ви можете переглянути jobs.yaml, щоб переконатися, що скрипт render_template працює правильно.

Коли ви переконаєтесь, що render_template працює так, як ви задумали, ви можете передати його вивід до kubectl:

cat job.yaml.jinja2 | render_template | kubectl apply -f -

Kubernetes прийме та запустить створені вами Jobs.

Очищення

# Видалення створених вами Jobs
# Ваш кластер автоматично очищає їхні Pods
kubectl delete job -l jobgroup=jobexample

Використання Jobs у реальних робочих навантаженнях

У реальному випадку використання кожен Job виконує деяку суттєву обчислювальну задачу, наприклад, рендеринг кадру фільму або обробку діапазону рядків у базі даних. Якщо ви рендерите відео, ви будете встановлювати $ITEM на номер кадру. Якщо ви обробляєте рядки з таблиці бази даних, ви будете встановлювати $ITEM для представлення діапазону рядків бази даних, які потрібно обробити.

У завданні ви виконували команду для збирання виводу з Podʼів, отримуючи їхні логи. У реальному випадку використання кожен Pod для Job записує свій вивід у надійне сховище перед завершенням. Ви можете використовувати PersistentVolume для кожного Job або зовнішню службу зберігання даних. Наприклад, якщо ви рендерите кадри для відео, використовуйте HTTP PUT щоб включити дані обробленого кадру до URL, використовуючи різні URL для кожного кадру.

Мітки на Job та Podʼах

Після створення Job, Kubernetes автоматично додає додаткові мітки, які вирізняють Podʼи одного Job від Podʼів іншого Job.

У цьому прикладі кожен Job та його шаблон Pod мають мітку: jobgroup=jobexample.

Сам Kubernetes не звертає уваги на мітки з іменем jobgroup. Встановлення мітки для всіх Job, які ви створюєте за шаблоном, робить зручним керування всіма цими Jobs одночасно. У першому прикладі ви використовували шаблон для створення кількох Job. Шаблон гарантує, що кожен Pod також отримує ту саму мітку, тому ви можете перевірити всі Podʼи для цих шаблонних Job за допомогою однієї команди.

Альтернативи

Якщо ви плануєте створити велику кількість обʼєктів Job, ви можете виявити, що:

  • Навіть використовуючи мітки, керування такою кількістю Job є громіздким.
  • Якщо ви створюєте багато Job одночасно, ви можете створити високе навантаження на панель управління Kubernetes. Крім того, сервер API Kubernetes може обмежити швидкість запитів, тимчасово відхиляючи ваші запити зі статусом 429.
  • Ви обмежені квотою ресурсів на Job: сервер API постійно відхиляє деякі ваші запити, коли ви створюєте велику кількість роботи за один раз.

Існують інші шаблони роботи з Job, які ви можете використовувати для обробки значного обсягу роботи без створення великої кількості обʼєктів Job.

Ви також можете розглянути можливість написання власного контролера, щоб автоматично керувати обʼєктами Job.

4.9.7 - Обробка повторюваних і неповторюваних помилок Pod за допомогою політики збоїв Pod

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.31 [stable]

Цей документ показує, як використовувати політику збоїв Pod, у поєднанні з типовою політикою відмови Podʼа, для покращення контролю над обробкою збоїв на рівні контейнера або Pod у Job.

Визначення політики збоїв Pod може допомогти вам:

Перш ніж ви розпочнете

Ви повинні вже бути знайомі з основним використанням Job.

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Версія вашого Kubernetes сервера має бути не старішою ніж v1.25. Для перевірки версії введіть kubectl version.

Використання політики збоїв Pod для уникнення непотрібних повторних запусків Pod

В наступному прикладі ви можете навчитися використовувати політику збоїв Pod, щоб уникати непотрібних перезапусків Pod, коли збій Pod вказує на неповторювану помилку програмного забезпечення.

Спочатку створіть Job на основі конфігурації:

apiVersion: batch/v1
kind: Job
metadata:
  name: job-pod-failure-policy-failjob
spec:
  completions: 8
  parallelism: 2
  template:
    spec:
      restartPolicy: Never
      containers:
      - name: main
        image: docker.io/library/bash:5
        command: ["bash"]
        args:
        - -c
        - echo "Hello world! I'm going to exit with 42 to simulate a software bug." && sleep 30 && exit 42
  backoffLimit: 6
  podFailurePolicy:
    rules:
    - action: FailJob
      onExitCodes:
        containerName: main
        operator: In
        values: [42]

виконавши команду:

kubectl create -f job-pod-failure-policy-failjob.yaml

Через приблизно 30 секунд весь Job повинен завершитися. Перевірте статус Job, виконавши команду:

kubectl get jobs -l job-name=job-pod-failure-policy-failjob -o yaml

У статусі Job відображаються такі умови:

  • Умова FailureTarget: має поле reason, встановлене в PodFailurePolicy, і поле message з додатковою інформацією про завершення, наприклад, Container main for pod default/job-pod-failure-policy-failjob-8ckj8 failed with exit code 42 matching FailJob rule at index 0. Контролер Job додає цю умову, як тільки Job вважається невдалим. Для отримання деталей дивіться Завершення Job Podʼів.
  • Умова Failed: те ж саме значення для reason і message, що й в умови FailureTarget. Контролер Job додає цю умову після того, як усі Podʼи Job завершено.

Для порівняння, якщо політика збоїв Pod була вимкнена, це б зайняло 6 спроб повторного запуску Pod, на що треба щонайменше 2 хвилини.

Прибирання

Видаліть створений Job:

kubectl delete jobs/job-pod-failure-policy-failjob

Кластер автоматично очищає Pod.

Використання політики збоїв Pod для ігнорування розладів Pod

На наступному прикладі ви можете навчитися використовувати політику збоїв Pod, щоб ігнорувати розлади Pod, які збільшують лічильник повторних спроб Pod до межі .spec.backoffLimit.

  1. Створіть Job на основі конфігурації:

    apiVersion: batch/v1
    kind: Job
    metadata:
      name: job-pod-failure-policy-ignore
    spec:
      completions: 4
      parallelism: 2
      template:
        spec:
          restartPolicy: Never
          containers:
          - name: main
            image: docker.io/library/bash:5
            command: ["bash"]
            args:
            - -c
            - echo "Hello world! I'm going to exit with 0 (success)." && sleep 90 && exit 0
      backoffLimit: 0
      podFailurePolicy:
        rules:
        - action: Ignore
          onPodConditions:
          - type: DisruptionTarget
    

    виконавши команду:

    kubectl create -f job-pod-failure-policy-ignore.yaml
    
  2. Виконайте цю команду, щоб перевірити nodeName, на якому розміщено Pod:

    nodeName=$(kubectl get pods -l job-name=job-pod-failure-policy-ignore -o jsonpath='{.items[0].spec.nodeName}')
    
  3. Запустить очищення вузла, щоб виселити Pod до завершення його роботи (протягом 90 секунд):

    kubectl drain nodes/$nodeName --ignore-daemonsets --grace-period=0
    
  4. Перевірте .status.failed, щоб переконатися, що лічильник для Job не збільшено:

    kubectl get jobs -l job-name=job-pod-failure-policy-ignore -o yaml
    
  5. Зніміть блокування з вузла:

    kubectl uncordon nodes/$nodeName
    

Job відновиться і завершиться успішно.

Для порівняння, якщо політика збоїв Pod була вимкнена, розлад Pod призведе до завершення всього Job (оскільки .spec.backoffLimit встановлено на 0).

Прибирання

Видаліть створений Job:

kubectl delete jobs/job-pod-failure-policy-ignore

Кластер автоматично очищає Pod.

Використання політики збоїв Pod для уникнення непотрібних повторних запусків Pod на основі власних умов Pod

В наступному прикладі ви можете навчитися використовувати політику збоїв Pod, щоб уникати непотрібних перезапусків Pod на основі власних умов Pod.

  1. Спочатку створіть Job на основі конфігурації:

    apiVersion: batch/v1
    kind: Job
    metadata:
      name: job-pod-failure-policy-config-issue
    spec:
      completions: 8
      parallelism: 2
      template:
        spec:
          restartPolicy: Never
          containers:
          - name: main
            image: "non-existing-repo/non-existing-image:example"
      backoffLimit: 6
      podFailurePolicy:
        rules:
        - action: FailJob
          onPodConditions:
          - type: ConfigIssue
    

    виконавши команду:

    kubectl create -f job-pod-failure-policy-config-issue.yaml
    

    Зверніть увагу, що образ налаштоване неправильно, оскільки його не існує.

  2. Перевірте статус Pod Job, виконавши команду:

    kubectl get pods -l job-name=job-pod-failure-policy-config-issue -o yaml
    

    Ви побачите результат, подібний до цього:

    containerStatuses:
    - image: non-existing-repo/non-existing-image:example
       ...
       state:
       waiting:
          message: Back-off pulling image "non-existing-repo/non-existing-image:example"
          reason: ImagePullBackOff
          ...
    phase: Pending
    

    Зверніть увагу, що Pod залишається у фазі Pending, оскільки йому не вдається завантажити неправильно налаштований образ. Це, в принципі, може бути тимчасовою проблемою, і образ може бути завантажений. Однак у цьому випадку образу не існує, тому ми вказуємо на цей факт за допомогою власної умови.

  3. Додайте власну умову. Спочатку підготуйте патч, виконавши команду:

    cat <<EOF > patch.yaml
    status:
      conditions:
      - type: ConfigIssue
        status: "True"
        reason: "NonExistingImage"
        lastTransitionTime: "$(date -u +"%Y-%m-%dT%H:%M:%SZ")"
    EOF
    

    По-друге, виберіть один із Pod, створених Job, виконавши команду:

    podName=$(kubectl get pods -l job-name=job-pod-failure-policy-config-issue -o jsonpath='{.items[0].metadata.name}')
    

    Потім застосуйте патч до одного з Pod, виконавши наступну команду:

    kubectl patch pod $podName --subresource=status --patch-file=patch.yaml
    

    Якщо патч успішно застосовано, ви отримаєте повідомлення такого типу:

    pod/job-pod-failure-policy-config-issue-k6pvp patched
    
  4. Видаліть Pod для переходу його до фази Failed, виконавши команду:

    kubectl delete pods/$podName
    
  5. Перевірте статус Job, виконавши:

    kubectl get jobs -l job-name=job-pod-failure-policy-config-issue -o yaml
    

    У статусі Job перегляньте умову Failed з полем reason, рівним PodFailurePolicy. Додатково, поле message містить більш детальну інформацію про завершення завдання, таку як: Pod default/job-pod-failure-policy-config-issue-k6pvp має умову ConfigIssue, яка відповідає правилу FailJob за індексом 0.

Очищення

Видаліть створене вами завдання:

kubectl delete jobs/job-pod-failure-policy-config-issue

Кластер автоматично очищує поди.

Альтернативи

Ви можете покладатись виключно на політику відмови Pod backoff, вказавши поле .spec.backoffLimit завдання. Однак у багатьох ситуаціях важко знайти баланс між встановленням низького значення для .spec.backoffLimit для уникнення непотрібних повторних спроб виконання Podʼів, але достатньо великого, щоб забезпечити, що Job не буде припинено через втручання у роботу Podʼів.

4.10 - Доступ до застосунків у кластері

Налаштування балансування навантаження, перенаправлення портів або налаштування фаєрволу або DNS-конфігурацій для доступу до застосунків у кластері.

4.10.1 - Розгортання та доступ до Інфопанелі Kubernetes

Розгорніть вебінтерфейс (Kubernetes Dashboard) та отримайте до нього доступ.

Інфопанель Kubernetes — це вебінтерфейс для кластерів Kubernetes. Ви можете використовувати Інфопанель для розгортання контейнерізованих застосунків в кластері Kubernetes, керувати ресурсами кластера, відстежувати та виправляти проблеми в роботі застосунків. Ви можете використовувати Інфопанель для перегляду роботи застосунків у вашому кластері, створення або зміни ресурсів Kubernetes (таких як Deployment, Job, DaemonSet та інші). Наприклад, ви можете масштабувати Deployment, ініціювати поступове оновлення, перезапустити Pod чи розгорнути новий застосунок за допомоги помічника з розгортання.

Інфопанель також надає інформацію про стан ресурсів Kubernetes у вашому кластері та про помилки, що можуть виникати.

Kubernetes Dashboard UI

Розгортання Dashboard UI

Стандартно Інфопанель не встановлена в кластері Kubernetes. Щоб розгорнути Інфопанель, ви повинні виконати наступну команду:

# Додайте репозиторій kubernetes-dashboard
helm repo add kubernetes-dashboard https://kubernetes.github.io/dashboard/
# Розгорніть Helm Release з назвою "kubectl-dashboard" скориставшись чартом kubernetes-dashboard
helm upgrade \
    --install \
      kubernetes-dashboard \
      kubernetes-dashboard/kubernetes-dashboard \
    --create-namespace \
    --namespace kubernetes-dashboard

Отримання доступу до Dashboard UI

Для захисту даних вашого кластера, Dashboard типово розгортається з мінімальною конфігурацією RBAC. Наразі Dashboard підтримує лише вхід за допомогою токену на предʼявника (Bearer Token). Для створення токена для цього демо ви можете скористатися нашим посібником зі створення користувача.

Проксі з командного рядка

Ви можете увімкнути доступ до Dashboard за допомогою інструменту командного рядка kubectl, виконавши наступну команду:

kubectl proxy

Kubectl зробить Dashboard доступним за адресою http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/.

Інтерфейс можна лише відкрити з машини, на якій виконується команда. Дивіться kubectl proxy --help для отримання додаткових опцій.

Вітальна сторінка

Коли ви отримуєте доступ до Інфопанелі в порожньому кластері, ви побачите вітальну сторінку. Ця сторінка містить посилання на цей документ, а також кнопку для розгортання вашого першого застосунку. Крім того, ви можете побачити, які системні застосунки запускаються стандартно у просторі імен kube-system вашого кластера, наприклад, сама Інфопанель.

Вітальна сторінка Kubernetes Dashboard

Розгортання контейнеризованих застосунків

Dashboard дозволяє створювати та розгортати контейнеризований застосунок як Deployment та необов’язковий Service за допомогою простого майстра. Ви можете або вручну вказати деталі застосунку, або завантажити YAML або JSON файл маніфесту, що містить конфігурацію застосунку.

Натисніть кнопку CREATE у верхньому правому куті будь-якої сторінки, щоб розпочати.

Встановлення параметрів застосунку

Майстер розгортання очікує, що ви надасте наступну інформацію:

  • Назва застосунку (обов’язково): Назва вашого застосунку. Мітка з цією назвою буде додана до Deployment та Service (якщо є), які будуть розгорнуті.

    Назва застосунку повинна бути унікальною в межах вибраного простору імен Kubernetes. Вона повинна починатися з малої літери та закінчуватися малою літерою або цифрою, і містити лише малі літери, цифри та дефіси (-). Обмеження на довжину становить 24 символи. Початкові та кінцеві пробіли ігноруються.

  • Образ контейнера (обов’язково): URL публічного Docker образу контейнера у будь-якому реєстрі, або приватного образу (зазвичай розміщеного в Google Container Registry або Docker Hub). Специфікація образу контейнера повинна закінчуватися двокрапкою.

  • Кількість Podʼів (обов’язково): Кількість Podʼів, з використанням яких ви хочете розгорнути свій застосунок. Значення повинно бути позитивним цілим числом.

    Буде створено Deployment, щоб підтримувати потрібну кількість Podʼів у вашому кластері.

  • Service (необов’язково): Для деяких частин вашого застосунку (наприклад, фронтендів) ви можете захотіти експонувати Service на зовнішню, можливо, публічну IP-адресу за межами вашого кластера (зовнішній Service).

    Інші Service, які видно тільки всередині кластера, називаються внутрішніми Service.

    Незалежно від типу Service, якщо ви вирішите створити Service і ваш контейнер слухає на порту (вхідному), вам потрібно вказати два порти. Service буде створено, шляхом зіставлення порту (вхідного) на цільовий порт, який бачить контейнер. Цей Service буде переспрямовувати трафік на ваші розгорнуті Podʼи. Підтримувані протоколи — TCP та UDP. Внутрішнє DNS-імʼя для цього Service буде значенням, яке ви вказали як назву застосунку вище.

Якщо необхідно, ви можете розгорнути розділ Advanced options, де можна вказати більше налаштувань:

  • Опис: Текст, який ви введете тут, буде додано як анотацію до Deployment та відображатиметься в деталях застосунку.

  • Мітки: Стандартні мітки, що використовуються для вашого застосунку, - це назва застосунку та версія. Ви можете вказати додаткові мітки, які будуть застосовані до Deployment, Service (якщо є) та Podʼів, такі як release, environment, tier, partition та release track.

    Приклад:

    release=1.0
    tier=frontend
    environment=pod
    track=stable
    
  • Простір імен: Kubernetes підтримує кілька віртуальних кластерів, що працюють поверх одного фізичного кластера. Ці віртуальні кластери називаються просторами імен. Вони дозволяють розділити ресурси на логічно названі групи.

    Dashboard пропонує всі доступні простори імен у розгортаючомуся списку та дозволяє створити новий простір імен. Назва простору імен може містити максимум 63 алфавітно-цифрових символи та дефіси (-), але не може містити великі літери. Назви просторів імен не повинні складатися лише з цифр. Якщо назва встановлена як число, наприклад 10, Pod буде розміщений у просторі імен default.

    У разі успішного створення простору імен він обирається стандартним. Якщо створення не вдається, вибирається перший простір імен.

  • Secret завантаження образу: У випадку, якщо вказаний Docker образ контейнера є приватним, він може вимагати облікові дані Secret завантаження.

    Dashboard пропонує всі доступні Secret у розгортаючомуся списку та дозволяє створити новий. Назва Secret повинна відповідати синтаксису доменного імені DNS, наприклад new.image-pull.secret. Вміст Secret повинен бути закодований у base64 і вказаний у файлі .dockercfg. Назва Secret може складатися максимум з 253 символів.

    У разі успішного створення Secret завантаження образу він обирається стандартним. Якщо створення не вдається, жоден Secret не застосовується.

  • Вимога до процесора (ядра) та Вимога до памʼяті (MiB): Ви можете вказати мінімальні обмеження ресурсів для контейнера. Стандартно Podʼи працюють без обмежень на процесор і памʼять.

  • Команда запуску та Аргументи команди запуску: Стандартно ваші контейнери виконують вказану Docker образом контейнера команду запуску. Ви можете використовувати опції команд і аргументів для перевизначення стандартної команди.

  • Запуск у привілейованому режимі: Це налаштування визначає, чи є процеси в привілейованих контейнерах еквівалентними процесам, що виконуються з правами root на хості. Привілейовані контейнери можуть використовувати можливості, такі як маніпулювання мережею та доступ до пристроїв.

  • Змінні середовища: Kubernetes експонує Service через змінні середовища. Ви можете складати змінні середовища або передавати аргументи до ваших команд, використовуючи значення змінних середовища. Вони можуть використовуватися в застосунках для пошуку Service. Значення можуть посилатися на інші змінні за допомогою синтаксису $(VAR_NAME).

Завантаження YAML або JSON файлу

Kubernetes підтримує декларативну конфігурацію. У цьому стилі всі конфігурації зберігаються в маніфестах (конфігураційних файлах YAML або JSON). Маніфести використовують схеми ресурсів API Kubernetes.

Як альтернатива вказанню деталей застосунку в майстрі розгортання, ви можете визначити ваш застосунок в одному або декількох маніфестах та завантажити файли за допомогою Dashboard.

Використання Dashboard

Наступні розділи описують вигляди інтерфейсу користувача Dashboard Kubernetes; що вони забезпечують і як їх можна використовувати.

Коли у кластері визначено обʼєкти Kubernetes, Dashboard показує їх у початковому вигляді. Типово показуються лише обʼєкти з простору імен default, це можна змінити за допомогою селектора простору імен, розташованого в меню навігації.

Dashboard показує більшість типів обʼєктів Kubernetes та групує їх у кілька категорій меню.

Огляд адміністратора

Для адміністраторів кластерів та просторів імен Dashboard перелічує вузли (Nodes), простори імен (Namespaces) та постійні томи (PersistentVolumes) і має детальні елементи для них. Список вузлів містить метрики використання ЦП та памʼяті, агреговані по всіх вузлах. Детальний вигляд показує метрики для вузла, його специфікацію, стан, виділені ресурси, події та Podʼи, що працюють на вузлі.

Навантаження

Показує всі застосунки, що працюють у вибраному просторі імен. Елемент перераховує застосунки за типом навантаження (наприклад: Deployments, ReplicaSets, StatefulSets). Кожен тип навантаження можна переглядати окремо. Списки узагальнюють корисну інформацію про навантаження, таку як кількість готових Podʼів для ReplicaSet або поточне використання памʼяті для Pod.

Детальні панелі для навантажень показують інформацію про стан та специфікацію і показують звʼязки між обʼєктами. Наприклад, Podʼи, які контролює ReplicaSet, або нові ReplicaSets та HorizontalPodAutoscalers для Deployments.

Services

Показує ресурси Kubernetes, які дозволяють експонувати Service для зовнішнього світу та виявляти їх всередині кластеру. З цієї причини, панелі Service та Ingress показують Podʼи, на які вони спрямовані, внутрішні точки доступу для мережевих зʼєднань в кластері та зовнішні точки доступу для зовнішніх користувачів.

Сховище

Панель сховища показує ресурси PersistentVolumeClaim, які використовуються застосунками для зберігання даних.

ConfigMaps та Secrets

Показує всі ресурси Kubernetes, які використовуються для поточної конфігурації застосунків, що працюють у кластерах. Панель дозволяє редагувати та керувати обʼєктами конфігурації та показує Secret, які є типово прихованими.

Переглядач логів

Списки Podʼів та детальні сторінки мають посилання на переглядача логів, вбудованого у Dashboard. Переглядач дозволяє переглядати логи з контейнерів, що належать окремому Podʼу.

Переглядач логів

Що далі

Для отримання додаткової інформації дивіться сторінку проєкту Kubernetes Dashboard.

4.10.2 - Доступ до кластерів

В цій темі обговорюється кілька способів взаємодії з кластерами.

Перший доступ з kubectl

При першому доступі до Kubernetes API ми пропонуємо використовувати Kubernetes CLI, kubectl.

Щоб отримати доступ до кластера, вам потрібно знати розташування кластера та мати облікові дані для доступу до нього. Зазвичай це налаштовується автоматично, коли ви проходите Посібник Початок роботи, або хтось інший налаштував кластер і надав вам облікові дані та його розташування.

Перевірте розташування та облікові дані, про які знає kubectl, за допомогою цієї команди:

kubectl config view

Багато з прикладів надають введення до використання kubectl, а повна документація знаходиться у довіднику kubectl.

Прямий доступ до REST API

Kubectl опрацьовує розташування та автентифікацію до apiserver. Якщо ви хочете безпосередньо звертатися до REST API за допомогою http-клієнта, такого як curl або wget, або вебоглядача, існує кілька способів знайти розташування та автентифікуватись:

  • Запустіть kubectl в режимі проксі.
    • Рекомендований підхід.
    • Використовує збережене розташування apiserver.
    • Перевіряє особу apiserver за допомогою самопідписного сертифікату. Немає можливості MITM.
    • Виконує автентифікацію на apiserver.
    • У майбутньому може здійснювати інтелектуальне балансування навантаження та відмовостійкість на стороні клієнта.
  • Надайте розташування та облікові дані безпосередньо http-клієнту.
    • Альтернативний підхід.
    • Працює з деякими типами клієнтського коду, які не працюють з проксі.
    • Потрібно імпортувати кореневий сертифікат у ваш оглядач для захисту від MITM.

Використання kubectl proxy

Наступна команда запускає kubectl в режимі, де він діє як зворотний проксі. Вона обробляє розташування apiserver та автентифікацію. Запустіть її так:

kubectl proxy --port=8080

Дивіться опис kubectl proxy для отримання додаткової інформації.

Після цього ви можете досліджувати API за допомогою curl, wget або оглядача, замінюючи localhost на [::1] для IPv6, ось так:

curl http://localhost:8080/api/

Вихід буде схожий на це:

{
  "kind": "APIVersions",
  "versions": [
    "v1"
  ],
  "serverAddressByClientCIDRs": [
    {
      "clientCIDR": "0.0.0.0/0",
      "serverAddress": "10.0.1.149:443"
    }
  ]
}

Без kubectl proxy

Використовуйте kubectl apply і kubectl describe secret... для створення токена для стандартного облікового запису за допомогою grep/cut:

Спочатку створіть Secret, запитуючи токен для облікового запису стандартного ServiceAccount:

kubectl apply -f - <<EOF
apiVersion: v1
kind: Secret
metadata:
  name: default-token
  annotations:
    kubernetes.io/service-account.name: default
type: kubernetes.io/service-account-token
EOF

Далі, зачекайте, поки контролер токенів не заповнить Secret токеном:

while ! kubectl describe secret default-token | grep -E '^token' >/dev/null; do
  echo "waiting for token..." >&2
  sleep 1
done

Отримайте і використовуйте згенерований токен:

APISERVER=$(kubectl config view --minify | grep server | cut -f 2- -d ":" | tr -d " ")
TOKEN=$(kubectl describe secret default-token | grep -E '^token' | cut -f2 -d':' | tr -d " ")

curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure

Вихід буде схожий на це:

{
  "kind": "APIVersions",
  "versions": [
    "v1"
  ],
  "serverAddressByClientCIDRs": [
    {
      "clientCIDR": "0.0.0.0/0",
      "serverAddress": "10.0.1.149:443"
    }
  ]
}

Використовуючи jsonpath:

APISERVER=$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}')
TOKEN=$(kubectl get secret default-token -o jsonpath='{.data.token}' | base64 --decode)

curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure

Вихід буде схожий на це:

{
  "kind": "APIVersions",
  "versions": [
    "v1"
  ],
  "serverAddressByClientCIDRs": [
    {
      "clientCIDR": "0.0.0.0/0",
      "serverAddress": "10.0.1.149:443"
    }
  ]
}

Вищенаведені приклади використовують прапорець --insecure. Це залишає їх вразливими до атак MITM. Коли kubectl отримує доступ до кластера, він використовує збережений кореневий сертифікат та клієнтські сертифікати для доступу до сервера. (Вони встановлюються в теку ~/.kube). Оскільки сертифікати кластера зазвичай самопідписні, це може вимагати спеціальної конфігурації, щоб змусити вашого http-клієнта використовувати кореневий сертифікат.

У деяких кластерах apiserver не вимагає автентифікації; він може працювати на localhost або бути захищеним файрволом. Для цього немає стандарту. Контроль доступу до API описує, як адміністратор кластера може це налаштувати.

Програмний доступ до API

Kubernetes офіційно підтримує клієнтські бібліотеки для Go та Python.

Клієнт Go

  • Щоб отримати бібліотеку, виконайте наступну команду: go get k8s.io/client-go@kubernetes-<kubernetes-version-number>, дивіться INSTALL.md для детальних інструкцій з встановлення. Дивіться https://github.com/kubernetes/client-go щоб дізнатися, які версії підтримуються.
  • Напишіть додаток на основі клієнтів client-go. Зверніть увагу, що client-go визначає свої власні API обʼєкти, тому, якщо необхідно, будь ласка, імпортуйте визначення API з client-go, а не з основного репозиторію, наприклад, import "k8s.io/client-go/kubernetes" є правильним.

Go клієнт може використовувати той же файл kubeconfig, що й CLI kubectl для знаходження та автентифікації до apiserver. Дивіться цей приклад.

Якщо застосунок розгорнуто як Pod у кластері, будь ласка, зверніться до наступного розділу.

Клієнт Python

Щоб використовувати клієнта Python, виконайте наступну команду: pip install kubernetes. Дивіться сторінку Python Client Library для інших варіантів встановлення.

Клієнт Python може використовувати той же файл kubeconfig, що й CLI kubectl для знаходження та автентифікації до apiserver. Дивіться цей приклад.

Інші мови

Існують клієнтські бібліотеки для доступу до API з інших мов. Дивіться документацію для інших бібліотек щодо того, як вони автентифікуються.

Доступ до API з Pod

При доступі до API з Pod, розташування та автентифікація на API сервері дещо відрізняються.

Будь ласка, перевірте Доступ до API з Pod для отримання додаткової інформації.

Доступ до сервісів, що працюють на кластері

Попередній розділ описує, як підʼєднатися до API сервера Kubernetes. Для інформації про підключення до інших сервісів, що працюють на кластері Kubernetes, дивіться Доступ до сервісів кластера.

Запит перенаправлення

Можливості перенаправлення були визнані застарілими та видалені. Будь ласка, використовуйте проксі (дивіться нижче) замість цього.

Так багато проксі

Існує кілька різних проксі, які ви можете зустріти при використанні Kubernetes:

  1. kubectl proxy:

    • працює на десктопі користувача або в Pod
    • проксі з локальної адреси до Kubernetes apiserver
    • клієнт проксі використовує HTTP
    • проксі apiserver використовує HTTPS
    • знаходить apiserver
    • додає заголовки автентифікації
  2. apiserver proxy:

    • є бастіоном, вбудованим у apiserver
    • зʼєднує користувача ззовні кластера з IP-адресами кластера, які інакше можуть бути недосяжні
    • працює в процесах apiserver
    • клієнт проксі використовує HTTPS (або http, якщо apiserver налаштований відповідним чином)
    • проксі може використовувати HTTP або HTTPS, як обрано проксі, використовуючи доступну інформацію
    • може використовуватися для доступу до Node, Pod або Service
    • забезпечує балансування навантаження при використанні для доступу до Service
  3. kube proxy:

    • працює на кожному вузлі
    • проксі UDP та TCP
    • не розуміє HTTP
    • забезпечує балансування навантаження
    • використовується лише для доступу до Service
  4. Проксі/Балансувальник навантаження перед apiserver(ами):

    • існування та реалізація варіюється від кластера до кластера (наприклад, nginx)
    • знаходиться між усіма клієнтами та одним або декількома apiserver
    • діє як балансувальник навантаження, якщо є кілька apiserver.
  5. Хмарні балансувальники навантаження на зовнішніх сервісах:

    • надаються деякими постачальниками хмарних послуг (наприклад, AWS ELB, Google Cloud Load Balancer)
    • створюються автоматично, коли сервіс Kubernetes має тип LoadBalancer
    • використовують лише UDP/TCP
    • реалізація варіюється серед постачальників хмарних послуг.

Користувачі Kubernetes зазвичай не повинні турбуватися про будь-що, крім перших двох типів. Адміністратор кластера зазвичай забезпечить правильне налаштування останніх типів.

4.10.3 - Налаштування доступу до декількох кластерів

Ця сторінка показує, як налаштувати доступ до декількох кластерів за допомогою конфігураційних файлів. Після того, як ваші кластери, користувачі та контексти визначені в одному або декількох конфігураційних файлах, ви можете швидко перемикатися між кластерами, використовуючи команду kubectl config use-context.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Щоб перевірити, чи встановлений kubectl, виконайте команду kubectl version --client. Версія kubectl повинна бути в межах однієї мінорної версії API сервера вашого кластера.

Визначення кластерів, користувачів і контекстів

Припустимо, у вас є два кластери: один для розробки, а інший для тестування. У кластері development ваші фронтенд розробники працюють в просторі імен frontend, а розробники, які опікуються зберіганням даних працюють в просторі імен storage. У кластері test розробники працюють в стандартному просторі імен default або створюють додаткові простори імен за потреби. Доступ до кластера розробки вимагає автентифікації за сертифікатом. Доступ до тестового кластера вимагає автентифікації за іменем користувача та паролем.

Створіть теку з назвою config-exercise. У вашій теці config-exercise створіть файл з назвою config-demo з наступним вмістом:

apiVersion: v1
kind: Config
preferences: {}

clusters:
- cluster:
  name: development
- cluster:
  name: test

users:
- name: developer
- name: experimenter

contexts:
- context:
  name: dev-frontend
- context:
  name: dev-storage
- context:
  name: exp-test

Конфігураційний файл описує кластери, користувачів і контексти. Ваш файл config-demo має структуру для опису двох кластерів, двох користувачів і трьох контекстів.

Перейдіть до теки config-exercise. Виконайте ці команди, щоб додати деталі кластера до вашого конфігураційного файлу:

kubectl config --kubeconfig=config-demo set-cluster development --server=https://1.2.3.4 --certificate-authority=fake-ca-file
kubectl config --kubeconfig=config-demo set-cluster test --server=https://5.6.7.8 --insecure-skip-tls-verify

Додайте відомості про користувачів до вашого конфігураційного файлу:

kubectl config --kubeconfig=config-demo set-credentials developer --client-certificate=fake-cert-file --client-key=fake-key-file
kubectl config --kubeconfig=config-demo set-credentials experimenter --username=exp --password=some-password

Додайте деталі контексту до вашого конфігураційного файлу:

kubectl config --kubeconfig=config-demo set-context dev-frontend --cluster=development --namespace=frontend --user=developer
kubectl config --kubeconfig=config-demo set-context dev-storage --cluster=development --namespace=storage --user=developer
kubectl config --kubeconfig=config-demo set-context exp-test --cluster=test --namespace=default --user=experimenter

Відкрийте ваш файл config-demo, щоб побачити додані деталі. Як альтернативу відкриттю файлу config-demo, можна використовувати команду config view.

kubectl config --kubeconfig=config-demo view

Вивід показує два кластери, двох користувачів і три контексти:

apiVersion: v1
clusters:
- cluster:
    certificate-authority: fake-ca-file
    server: https://1.2.3.4
  name: development
- cluster:
    insecure-skip-tls-verify: true
    server: https://5.6.7.8
  name: test
contexts:
- context:
    cluster: development
    namespace: frontend
    user: developer
  name: dev-frontend
- context:
    cluster: development
    namespace: storage
    user: developer
  name: dev-storage
- context:
    cluster: test
    namespace: default
    user: experimenter
  name: exp-test
current-context: ""
kind: Config
preferences: {}
users:
- name: developer
  user:
    client-certificate: fake-cert-file
    client-key: fake-key-file
- name: experimenter
  user:
    # Примітка до документації (цей коментар НЕ є частиною виводу команди).
    # Зберігання паролів у конфігурації клієнта Kubernetes є ризикованим.
    # Кращою альтернативою буде використання втулка облікових даних
    # і зберігати облікові дані окремо.
    # Див. https://kubernetes.io/docs/reference/access-authn-authz/authentication/client-go-credential-plugins
    password: some-password
    username: exp

Файли fake-ca-file, fake-cert-file та fake-key-file вище є заповнювачами для шляхів до сертифікатів. Вам потрібно замінити їх на реальні шляхи до сертифікатів у вашому середовищі.

Іноді ви можете захотіти використовувати дані у форматі Base64 замість окремих файлів сертифікатів; у такому випадку вам потрібно додати суфікс -data до ключів, наприклад, certificate-authority-data, client-certificate-data, client-key-data.

Кожен контекст є трійкою (кластер, користувач, простір імен). Наприклад, контекст dev-frontend означає: "Використовувати облікові дані користувача developer для доступу до простору імен frontend у кластері development".

Встановіть поточний контекст:

kubectl config --kubeconfig=config-demo use-context dev-frontend

Тепер, коли ви введете команду kubectl, дія буде застосовуватися до кластера і простору імен, вказаних у контексті dev-frontend. І команда буде використовувати облікові дані користувача, вказаного у контексті dev-frontend.

Щоб побачити лише інформацію про конфігурацію, повʼязану з поточним контекстом, використовуйте прапорець --minify.

kubectl config --kubeconfig=config-demo view --minify

Вивід показує інформацію про конфігурацію, повʼязану з контекстом dev-frontend:

api

Version: v1
clusters:
- cluster:
    certificate-authority: fake-ca-file
    server: https://1.2.3.4
  name: development
contexts:
- context:
    cluster: development
    namespace: frontend
    user: developer
  name: dev-frontend
current-context: dev-frontend
kind: Config
preferences: {}
users:
- name: developer
  user:
    client-certificate: fake-cert-file
    client-key: fake-key-file

Тепер припустимо, що ви хочете попрацювати деякий час у тестовому кластері.

Змініть поточний контекст на exp-test:

kubectl config --kubeconfig=config-demo use-context exp-test

Тепер будь-яка команда kubectl, яку ви введете, буде застосовуватися до стандартного простору імен default кластера test. І команда буде використовувати облікові дані користувача, вказаного у контексті exp-test.

Перегляньте конфігурацію, повʼязану з новим поточним контекстом exp-test.

kubectl config --kubeconfig=config-demo view --minify

Нарешті, припустимо, що ви хочете попрацювати деякий час у просторі імен storage кластера development.

Змініть поточний контекст на dev-storage:

kubectl config --kubeconfig=config-demo use-context dev-storage

Перегляньте конфігурацію, повʼязану з новим поточним контекстом dev-storage.

kubectl config --kubeconfig=config-demo view --minify

Створення другого конфігураційного файлу

У вашій теці config-exercise створіть файл з назвою config-demo-2 з наступним вмістом:

apiVersion: v1
kind: Config
preferences: {}

contexts:
- context:
    cluster: development
    namespace: ramp
    user: developer
  name: dev-ramp-up

Вищезазначений конфігураційний файл визначає новий контекст з назвою dev-ramp-up.

Встановіть змінну середовища KUBECONFIG

Перевірте, чи є у вас змінна середовища з назвою KUBECONFIG. Якщо так, збережіть поточне значення вашої змінної середовища KUBECONFIG, щоб ви могли відновити її пізніше. Наприклад:

Linux

export KUBECONFIG_SAVED="$KUBECONFIG"

Windows PowerShell

$Env:KUBECONFIG_SAVED=$ENV:KUBECONFIG

Змінна середовища KUBECONFIG є списком шляхів до конфігураційних файлів. Список розділяється двокрапкою для Linux і Mac та крапкою з комою для Windows. Якщо у вас є змінна середовища KUBECONFIG, ознайомтеся з конфігураційними файлами у списку.

Тимчасово додайте два шляхи до вашої змінної середовища KUBECONFIG. Наприклад:

Linux

export KUBECONFIG="${KUBECONFIG}:config-demo:config-demo-2"

Windows PowerShell

$Env:KUBECONFIG=("config-demo;config-demo-2")

У вашій теці config-exercise виконайте цю команду:

kubectl config view

Вивід показує обʼєднану інформацію з усіх файлів, зазначених у вашій змінній середовища KUBECONFIG. Зокрема, зверніть увагу, що обʼєднана інформація містить контекст dev-ramp-up з файлу config-demo-2 і три контексти з файлу config-demo:

contexts:
- context:
    cluster: development
    namespace: frontend
    user: developer
  name: dev-frontend
- context:
    cluster: development
    namespace: ramp
    user: developer
  name: dev-ramp-up
- context:
    cluster: development
    namespace: storage
    user: developer
  name: dev-storage
- context:
    cluster: test
    namespace: default
    user: experimenter
  name: exp-test

Для отримання додаткової інформації про те, як обʼєднуються файли kubeconfig, дивіться Організація доступу до кластерів за допомогою файлів kubeconfig.

Ознайомтеся з текою $HOME/.kube

Якщо у вас вже є кластер і ви можете використовувати kubectl для взаємодії з кластером, то, ймовірно, у вас є файл з назвою config у теці $HOME/.kube.

Перейдіть до теки $HOME/.kube і перегляньте, які файли там знаходяться. Зазвичай, там є файл з назвою config. Також можуть бути інші конфігураційні файли у цій теці. Ознайомтеся зі змістом цих файлів.

Додайте $HOME/.kube/config до вашої змінної середовища KUBECONFIG

Якщо у вас є файл $HOME/.kube/config і він ще не зазначений у вашій змінній середовища KUBECONFIG, додайте його до вашої змінної середовища KUBECONFIG зараз. Наприклад:

Linux

export KUBECONFIG="${KUBECONFIG}:${HOME}/.kube/config"

Windows PowerShell

$Env:KUBECONFIG="$Env:KUBECONFIG;$HOME\.kube\config"

Перегляньте інформацію про конфігурацію, обʼєднану з усіх файлів, які зараз зазначені у вашій змінній середовища KUBECONFIG. У вашій теці config-exercise введіть:

kubectl config view

Очищення

Поверніть вашу змінну середовища KUBECONFIG до її оригінального значення. Наприклад:

Linux

export KUBECONFIG="$KUBECONFIG_SAVED"

Windows PowerShell

$Env:KUBECONFIG=$ENV:KUBECONFIG_SAVED

Перевірте субʼєкт, представлений kubeconfig

Не завжди очевидно, які атрибути (імʼя користувача, групи) ви отримаєте після автентифікації в кластері. Це може бути ще складніше, якщо ви керуєте більше ніж одним кластером одночасно.

Існує підкоманда kubectl для перевірки атрибутів субʼєкта, таких як імʼя користувача, для вашого вибраного контексту клієнта Kubernetes: kubectl auth whoami.

Детальніше читайте у Доступ до інформації автентифікації клієнта через API.

Що далі

4.10.4 - Використання перенаправлення портів для доступу до застосунків у кластері

Ця сторінка показує, як використовувати kubectl port-forward для підключення до сервера MongoDB, який працює у кластері Kubernetes. Такий тип підключення може бути корисним для налагодження бази даних.

Перш ніж ви розпочнете

  • Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

    Версія вашого Kubernetes сервера має бути не старішою ніж v1.10. Для перевірки версії введіть kubectl version.
  • Встановіть MongoDB Shell.

Створення розгортання та сервісу MongoDB

  1. Створіть Deployment, що запускає MongoDB:

    kubectl apply -f https://k8s.io/examples/application/mongodb/mongo-deployment.yaml
    

    Вивід успішної команди підтверджує, що Deployment створено:

    deployment.apps/mongo created
    

    Перегляньте стан Podʼа, щоб переконатися, що він готовий:

    kubectl get pods
    

    Вивід відображає показує Pod:

    NAME                     READY   STATUS    RESTARTS   AGE
    mongo-75f59d57f4-4nd6q   1/1     Running   0          2m4s
    

    Перегляньте стан Deployment:

    kubectl get deployment
    

    Вивід відображає, що Deployment було створено:

    NAME    READY   UP-TO-DATE   AVAILABLE   AGE
    mongo   1/1     1            1           2m21s
    

    Deployment автоматично керує ReplicaSet. Перегляньте стан ReplicaSet, використовуючи:

    kubectl get replicaset
    

    Вивід показує, що ReplicaSet був створений:

    NAME               DESIRED   CURRENT   READY   AGE
    mongo-75f59d57f4   1         1         1       3m12s
    
  2. Створіть Service для доступу до MongoDB в мережі:

    kubectl apply -f https://k8s.io/examples/application/mongodb/mongo-service.yaml
    

    Вивід успішної команди підтверджує, що Service був створений:

    service/mongo created
    

    Перевірте створений Service:

    kubectl get service mongo
    

    Вивід показує створений Service:

    NAME    TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)     AGE
    mongo   ClusterIP   10.96.41.183   <none>        27017/TCP   11s
    
  3. Переконайтеся, що сервер MongoDB працює у Pod та слухає на порту 27017:

    # Замініть mongo-75f59d57f4-4nd6q на імʼя Pod
    kubectl get pod mongo-75f59d57f4-4nd6q --template='{{(index (index .spec.containers 0).ports 0).containerPort}}{{"\n"}}'
    

    Вивід показує порт для MongoDB у цьому Pod:

    27017
    

    27017 є офіційним TCP портом для MongoDB.

Перенаправлення локального порту на порт Pod

  1. kubectl port-forward дозволяє використовувати імʼя ресурсу, такого як імʼя Podʼа, для вибору відповідного Podʼа для перенаправлення портів.

    # Замініть mongo-75f59d57f4-4nd6q на імʼя Pod
    kubectl port-forward mongo-75f59d57f4-4nd6q 28015:27017
    

    що те саме, що і

    kubectl port-forward pods/mongo-75f59d57f4-4nd6q 28015:27017
    

    або

    kubectl port-forward deployment/mongo 28015:27017
    

    або

    kubectl port-forward replicaset/mongo-75f59d57f4 28015:27017
    

    або

    kubectl port-forward service/mongo 28015:27017
    

    Будь-яка з наведених вище команд працює. Вивід схожий на це:

    Forwarding from 127.0.0.1:28015 -> 27017
    Forwarding from [::1]:28015 -> 27017
    
  2. Запустіть інтерфейс командного рядка MongoDB:

    mongosh --port 28015
    
  3. На командному рядку MongoDB введіть команду ping:

    db.runCommand( { ping: 1 } )
    

    Успішний запит ping повертає:

    { ok: 1 }
    

Дозвольте kubectl вибрати локальний порт

Якщо вам не потрібен конкретний локальний порт, ви можете дозволити kubectl вибрати та призначити локальний порт і таким чином позбавити себе від необхідності керувати конфліктами локальних портів, з дещо простішим синтаксисом:

kubectl port-forward deployment/mongo :27017

Інструмент kubectl знаходить номер локального порту, який не використовується (уникаючи низьких номерів портів, оскільки вони можуть використовуватися іншими застосунками). Вивід схожий на:

Forwarding from 127.0.0.1:63753 -> 27017
Forwarding from [::1]:63753 -> 27017

Обговорення

Підключення до локального порту 28015 пересилаються на порт 27017 Podʼа, який запускає сервер MongoDB. З цим підключенням ви можете використовувати свій локальний робочий компʼютер для налагодження бази даних, яка працює у Pod.

Що далі

Дізнайтеся більше про kubectl port-forward.

4.10.5 - Використання Service для доступу до застосунку у кластері

Ця сторінка показує, як створити обʼєкт Service в Kubernetes, який зовнішні клієнти можуть використовувати для доступу до застосунку, що працює у кластері. Service забезпечує балансування навантаження для застосунку, який має два запущені екземпляри.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Цілі

  • Запустити два екземпляри застосунку Hello World.
  • Створити обʼєкт Service, який експонує порт вузла.
  • Використовувати обʼєкт Service для доступу до запущеного застосунку.

Створення Service для застосунку, який працює у двох Podʼах

Ось конфігураційний файл для Deployment застосунку:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-world
spec:
  selector:
    matchLabels:
      run: load-balancer-example
  replicas: 2
  template:
    metadata:
      labels:
        run: load-balancer-example
    spec:
      containers:
        - name: hello-world
          image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:2.0
          ports:
            - containerPort: 8080
              protocol: TCP
  1. Запустіть застосунок Hello World у вашому кластері: Створіть Deployment застосунку, використовуючи файл вище:

    kubectl apply -f https://k8s.io/examples/service/access/hello-application.yaml
    

    Попередня команда створює Deployment та повʼязаний з ним ReplicaSet. ReplicaSet має два Podʼи кожен з яких запускає застосунок Hello World.

  2. Перегляньте інформацію про Deployment:

    kubectl get deployments hello-world
    kubectl describe deployments hello-world
    
  3. Перегляньте інформацію про ваші обʼєкти ReplicaSet:

    kubectl get replicasets
    kubectl describe replicasets
    
  4. Створіть обʼєкт Service, який експонує Deployment:

    kubectl expose deployment hello-world --type=NodePort --name=example-service
    
  5. Перегляньте інформацію про Service:

    kubectl describe services example-service
    

    Вивід буде схожий на цей:

    Name:                   example-service
    Namespace:              default
    Labels:                 run=load-balancer-example
    Annotations:            <none>
    Selector:               run=load-balancer-example
    Type:                   NodePort
    IP:                     10.32.0.16
    Port:                   <unset> 8080/TCP
    TargetPort:             8080/TCP
    NodePort:               <unset> 31496/TCP
    Endpoints:              10.200.1.4:8080, 10.200.2.5:8080
    Session Affinity:       None
    Events:                 <none>
    

    Занотуйте значення NodePort для Service. Наприклад, у попередньому виводі значення NodePort становить 31496.

  6. Перегляньте Podʼи, що запускають застосунок Hello World:

    kubectl get pods --selector="run=load-balancer-example" --output=wide
    

    Вивід буде схожий на цей:

    NAME                           READY   STATUS    ...  IP           NODE
    hello-world-2895499144-bsbk5   1/1     Running   ...  10.200.1.4   worker1
    hello-world-2895499144-m1pwt   1/1     Running   ...  10.200.2.5   worker2
    
  7. Отримайте публічну IP-адресу одного з ваших вузлів, що запускає Pod Hello World. Як ви отримаєте цю адресу залежить від того, як ви налаштували свій кластер. Наприклад, якщо ви використовуєте Minikube, ви можете побачити адресу вузла, виконавши команду kubectl cluster-info. Якщо ви використовуєте trptvgkzhb Google Compute Engine, ви можете використати команду gcloud compute instances list для перегляду публічних адрес ваших вузлів.

  8. На обраному вами вузлі створіть правило брандмауера, яке дозволяє TCP-трафік на вашому порту вузла. Наприклад, якщо ваш Service має значення NodePort 31568, створіть правило брандмауера, яке дозволяє TCP-трафік на порт 31568. Різні постачальники хмарних послуг пропонують різні способи налаштування правил брандмауера.

  9. Використовуйте адресу вузла та порт вузла для доступу до застосунку Hello World:

    curl http://<public-node-ip>:<node-port>
    

    де <public-node-ip> — це публічна IP-адреса вашого вузла, а <node-port> — це значення NodePort для вашого Service. Відповідь на успішний запит буде повідомленням з привітанням:

    Hello, world!
    Version: 2.0.0
    Hostname: hello-world-cdd4458f4-m47c8
    

Використання конфігураційного файлу Service

Як альтернатива використанню kubectl expose, ви можете використовувати конфігураційний файл Service для створення Service.

Очищення

Щоб видалити Service, введіть цю команду:

kubectl delete services example-service

Щоб видалити Deployment, ReplicaSet та Podʼи, що запускають застосунок Hello World, введіть цю команду:

 kubectl delete deployment hello-world

Що далі

Ознайомтесь з посібником Підключення застосунків за допомогою Service.

4.10.6 - Зʼєднання фронтенду з бекендом за допомогою Service

Це завдання показує, як створити мікросервіси frontend та backend. Мікросервіс бекенд є сервісом для привітання. Фронтенд експонує backend за допомогою nginx та обʼєкта Kubernetes Service.

Цілі

  • Створити та запустити зразок мікросервісу бекенд hello за допомогою обʼєкта Deployment.
  • Використовувати обʼєкт Service для надсилання трафіку до кількох реплік мікросервісу бекенд.
  • Створити та запустити мікросервіс фронтенд nginx, також використовуючи обʼєкт Deployment.
  • Налаштувати мікросервіс фронтенд для надсилання трафіку до мікросервісу бекенд.
  • Використовувати обʼєкт Service типу LoadBalancer для експонування мікросервісу фронтенд назовні кластера.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Для перевірки версії введіть kubectl version.

Це завдання використовує Service з зовнішніми балансувальниками навантаження, які вимагають підтримуваного середовища. Якщо ваше середовище не підтримує це, ви можете використовувати Service типу NodePort.

Створення бекенд за допомогою Deployment

Бекенд — це простий мікросервіс для привітань. Ось конфігураційний файл для розгортання:

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: backend
spec:
  selector:
    matchLabels:
      app: hello
      tier: backend
      track: stable
  replicas: 3
  template:
    metadata:
      labels:
        app: hello
        tier: backend
        track: stable
    spec:
      containers:
        - name: hello
          image: "gcr.io/google-samples/hello-go-gke:1.0"
          ports:
            - name: http
              containerPort: 80
...

Створіть Deployment для бекенду:

kubectl apply -f https://k8s.io/examples/service/access/backend-deployment.yaml

Перегляньте інформацію про Deployment:

kubectl describe deployment backend

Вивід буде схожий на цей:

Name:                           backend
Namespace:                      default
CreationTimestamp:              Mon, 24 Oct 2016 14:21:02 -0700
Labels:                         app=hello
                                tier=backend
                                track=stable
Annotations:                    deployment.kubernetes.io/revision=1
Selector:                       app=hello,tier=backend,track=stable
Replicas:                       3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType:                   RollingUpdate
MinReadySeconds:                0
RollingUpdateStrategy:          1 max unavailable, 1 max surge
Pod Template:
  Labels:       app=hello
                tier=backend
                track=stable
  Containers:
   hello:
    Image:              "gcr.io/google-samples/hello-go-gke:1.0"
    Port:               80/TCP
    Environment:        <none>
    Mounts:             <none>
  Volumes:              <none>
Conditions:
  Type          Status  Reason
  ----          ------  ------
  Available     True    MinimumReplicasAvailable
  Progressing   True    NewReplicaSetAvailable
OldReplicaSets:                 <none>
NewReplicaSet:                  hello-3621623197 (3/3 replicas created)
Events:
...

Створення обʼєкта Service hello

Ключовим елементом для надсилання запитів з фронтенду до бекенду є бекенд Service. Service створює постійну IP-адресу та запис DNS, так що мікросервіс бекенд завжди може бути доступним. Service використовує селектори, щоб знайти Podʼи, до яких треба спрямувати трафік.

Спочатку ознайомтеся з конфігураційним файлом Service:

---
apiVersion: v1
kind: Service
metadata:
  name: hello
spec:
  selector:
    app: hello
    tier: backend
  ports:
  - protocol: TCP
    port: 80
    targetPort: http
...

У конфігураційному файлі можна побачити, що Service з назвою hello маршрутизує трафік до Podʼів з мітками app: hello та tier: backend.

Створіть Service для бекенду:

kubectl apply -f https://k8s.io/examples/service/access/backend-service.yaml

На цьому етапі у вас є Deployment backend, що виконує три репліки вашого hello застосунку, та Service, який може маршрутизувати трафік до них. Проте цей Service не є доступним та не може бути доступний за межами кластера.

Створення frontend

Тепер, коли ваш бекенд запущено, ви можете створити frontend, який буде доступним за межами кластера та підключатиметься до backend, проксуючи запити до нього.

Фронтенд надсилає запити до Podʼів backend, використовуючи DNS-імʼя, надане Serviceʼу бекенд. DNS-імʼя — це hello, яке є значенням поля name у конфігураційному файлі examples/service/access/backend-service.yaml.

Podʼи у Deployment фронтенд запускають образ nginx, налаштований для проксіювання запитів до Service бекенда hello. Ось конфігураційний файл nginx:

# The identifier Backend is internal to nginx, and used to name this specific upstream
upstream Backend {
    # hello is the internal DNS name used by the backend Service inside Kubernetes
    server hello;
}

server { listen 80;

location / {
    # The following statement will proxy traffic to the upstream named Backend
    proxy_pass http://Backend;
}

}

Подібно до бекенду, фронтенд має Deployment та Service. Важливою відмінністю між Serviceʼами бекендаа та фронтенда є те, що конфігурація для Service фронтенда має type: LoadBalancer, що означає, що Service використовує балансувальник навантаження, який надається вашим хмарним провайдером, і буде доступним за межами кластеру.

---
apiVersion: v1
kind: Service
metadata:
  name: frontend
spec:
  selector:
    app: hello
    tier: frontend
  ports:
  - protocol: "TCP"
    port: 80
    targetPort: 80
  type: LoadBalancer
...
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: frontend
spec:
  selector:
    matchLabels:
      app: hello
      tier: frontend
      track: stable
  replicas: 1
  template:
    metadata:
      labels:
        app: hello
        tier: frontend
        track: stable
    spec:
      containers:
        - name: nginx
          image: "gcr.io/google-samples/hello-frontend:1.0"
          lifecycle:
            preStop:
              exec:
                command: ["/usr/sbin/nginx","-s","quit"]
...

Створіть Deployment та Service фронтенд:

kubectl apply -f https://k8s.io/examples/service/access/frontend-deployment.yaml
kubectl apply -f https://k8s.io/examples/service/access/frontend-service.yaml

Вивід підтверджує, що обидва ресурси створено:

deployment.apps/frontend created
service/frontend created

Взаємодія з Service фронтенду

Після створення Service типу LoadBalancer, ви можете використати цю команду, щоб знайти зовнішню IP-адресу:

kubectl get service frontend --watch

Вивід показує конфігурацію Service frontend та спостерігає за змінами. Спочатку зовнішня IP-адреса вказана як <pending>:

NAME       TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)  AGE
frontend   LoadBalancer   10.51.252.116   <pending>     80/TCP   10s

Як тільки зовнішня IP-адреса буде надана, конфігурація оновлюється і включає нову IP-адресу під заголовком EXTERNAL-IP:

NAME       TYPE           CLUSTER-IP      EXTERNAL-IP        PORT(S)  AGE
frontend   LoadBalancer   10.51.252.116   XXX.XXX.XXX.XXX    80/TCP   1m

Цю IP-адресу тепер можна використовувати для взаємодії з Service frontend ззовні кластера.

Надсилання трафіку через фронтенд

Тепер фронтенд та бекенд зʼєднані. Ви можете звернутися до точки доступу використовуючи команду curl з зовнішньою IP-адресою вашого Service фронтенду.

curl http://${EXTERNAL_IP} # замініть це на EXTERNAL-IP, який ви бачили раніше

Вивід показує повідомлення, згенероване бекендом:

{"message":"Hello"}

Очищення

Щоб видалити Serviceʼи, введіть цю команду:

kubectl delete services frontend backend

Щоб видалити Deploymentʼи, ReplicaSet та Podʼи, які запускають бекенд та фронтенд застосунки, введіть цю команду:

kubectl delete deployment frontend backend

Що далі

4.10.7 - Створення зовнішнього балансувальника навантаження

Ця сторінка показує, як створити зовнішній балансувальник навантаження.

Під час створення Service ви маєте можливість автоматично створити балансувальник навантаження в хмарі. Він забезпечує доступну назовні IP-адресу, яка надсилає трафік на відповідний порт ваших вузлів кластера, за умови, що ваш кластер працює в підтримуваному середовищі та налаштований з відповідним пакетом постачальника хмарного балансувальника навантаження.

Ви також можете використовувати Ingress замість Service. Для отримання додаткової інформації ознайомтеся з документацією Ingress.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Ваш кластер має працювати в хмарі або іншому середовищі, яке вже підтримує налаштування зовнішніх балансувальників навантаження.

Створення Service

Створення Service з маніфесту

Щоб створити зовнішній балансувальник навантаження, додайте до специфікації вашого маніфесту Service наступний рядок :

    type: LoadBalancer

Ваш маніфест може виглядати так:

apiVersion: v1
kind: Service
metadata:
  name: example-service
spec:
  selector:
    app: example
  ports:
    - port: 8765
      targetPort: 9376
  type: LoadBalancer

Створення Service за допомогою kubectl

Ви можете також створити Service за допомогою команди kubectl expose та її прапорця --type=LoadBalancer:

kubectl expose deployment example --port=8765 --target-port=9376 \
        --name=example-service --type=LoadBalancer

Ця команда створює новий Service, використовуючи ті ж селектори, що й вказаний ресурс (у випадку наведеного прикладу — Deployment під назвою example).

Для отримання додаткової інформації, включаючи необовʼязкові прапорці, зверніться до довідника команди kubectl expose.

Пошук вашої IP-адреси

Ви можете знайти IP-адресу, створену для вашого Service, отримавши інформацію про Service через kubectl:

kubectl describe services example-service

що повинно дати результат, схожий на цей:

Name:                     example-service
Namespace:                default
Labels:                   app=example
Annotations:              <none>
Selector:                 app=example
Type:                     LoadBalancer
IP Families:              <none>
IP:                       10.3.22.96
IPs:                      10.3.22.96
LoadBalancer Ingress:     192.0.2.89
Port:                     <unset>  8765/TCP
TargetPort:               9376/TCP
NodePort:                 <unset>  30593/TCP
Endpoints:                172.17.0.3:9376
Session Affinity:         None
External Traffic Policy:  Cluster
Events:                   <none>

IP-адреса балансувальника навантаження вказана поруч з LoadBalancer Ingress.

Збереження вихідної IP-адреси клієнта

Типово, вихідна IP-адреса, яку бачить цільовий контейнер, не є оригінальною вихідною IP-адресою клієнта. Щоб увімкнути збереження IP-адреси клієнта, можна налаштувати наступні поля в .spec Service:

  • .spec.externalTrafficPolicy — вказує, чи бажає цей Service маршрутизувати зовнішній трафік до вузлів локально або по всьому кластеру. Є два доступні варіанти: Cluster (стандартно) і Local. Cluster приховує вихідну IP-адресу клієнта та може спричинити другий перехід на інший вузол, але має гарне загальне розподілення навантаження. Local зберігає вихідну IP-адресу клієнта та уникає другого переходу для сервісів типу LoadBalancer та NodePort, але є ризик потенційно нерівномірного розподілення трафіку.
  • .spec.healthCheckNodePort — вказує порт для перевірки стану вузлів (числовий номер порту) для Service. Якщо ви не вкажете healthCheckNodePort, контролер Service виділить порт з діапазону NodePort вашого кластера. Ви можете налаштувати цей діапазон, встановивши параметр командного рядка API-сервера --service-node-port-range. Service використовуватиме значення healthCheckNodePort, якщо ви його вкажете, за умови, що type Service встановлено як LoadBalancer і externalTrafficPolicy встановлено як Local.

Встановлення externalTrafficPolicy на Local у маніфесті Service активує цю функцію. Наприклад:

apiVersion: v1
kind: Service
metadata:
  name: example-service
spec:
  selector:
    app: example
  ports:
    - port: 8765
      targetPort: 9376
  externalTrafficPolicy: Local
  type: LoadBalancer

Застереження та обмеження при збереженні вихідних IP-адрес

Сервіси балансування навантаження деяких хмарних провайдерів не дозволяють налаштувати різну вагу для кожної цілі.

Коли кожна ціль має однакову вагу для надсилання трафіку на вузли, зовнішній трафік нерівномірно розподіляється між різними Podʼами. Зовнішній балансувальник навантаження не знає кількість Podʼів на кожному вузлі, які використовуються як ціль.

Якщо NumServicePods << NumNodes або NumServicePods >> NumNodes, спостерігається майже рівномірний розподіл, навіть без коефіцієнтів.

Внутрішній трафік між Podʼами повинен поводитися подібно до Service типу ClusterIP, з рівною ймовірністю для всіх Podʼів.

Балансувальники для збору сміття

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.17 [stable]

У звичайному випадку, відповідні ресурси балансувальника навантаження у хмарного провайдера повинні бути видалені незабаром після видалення Service типу LoadBalancer. Але відомо, що є різні крайні випадки, коли хмарні ресурси залишаються після видалення асоційованого Service. Для запобігання цьому було введено захист за допомогою завершувачів для Service LoadBalancers. Використовуючи завершувачі, ресурс Service ніколи не буде видалено, поки відповідні ресурси балансувальника навантаження також не будуть видалені.

Зокрема, якщо Service має type LoadBalancer, контролер Service додасть завершувач з назвою service.kubernetes.io/load-balancer-cleanup. Завершувач буде видалений тільки після видалення ресурсу балансувальника навантаження. Це запобігає залишенню ресурсів балансувальника навантаження навіть у крайніх випадках, таких як падіння контролера сервісу.

Постачальники зовнішніх балансувальників навантаження

Важливо зазначити, що шлях даних для цієї функціональності забезпечується зовнішнім для кластера Kubernetes балансувальником навантаження.

Коли type Service встановлено як LoadBalancer, Kubernetes забезпечує функціональність, еквівалентну type ClusterIP для Podʼів у кластері, і розширює її, програмуючи (зовнішній для Kubernetes) балансувальник навантаження з записами для вузлів, що є місцем розташування відповідних Podʼів Kubernetes. Панель управління Kubernetes автоматизує створення зовнішнього балансувальника навантаження, перевірки стану (якщо необхідно), і правила фільтрації пакетів (якщо необхідно). Після того як хмарний провайдер виділить IP-адресу для балансувальника навантаження, панель управління знаходить цю зовнішню IP-адресу та вносить її в обʼєкт Service.

Що далі

4.10.8 - Отримання переліку всіх образів контейнерів, що працюють у кластері

Ця сторінка показує, як використовувати kubectl для отримання переліку всіх образів контейнерів для Podʼів, що працюють у кластері.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Для перевірки версії введіть kubectl version.

У цьому завданні ви використовуватимете kubectl для отримання всіх Podʼів, що працюють у кластері, і форматування виводу для отримання списку контейнерів для кожного з них.

Перелік всіх образів контейнерів у всіх просторах імен

  • Отримайте всі Podʼи у всіх просторах імен за допомогою kubectl get pods --all-namespaces.
  • Форматуйте вивід для включення лише списку імен образів контейнерів, використовуючи -o jsonpath={.items[*].spec['initContainers', 'containers'][*].image}. Це рекурсивно розбирає поле image з отриманого JSON.
  • Форматуйте вивід за допомогою стандартних інструментів: tr, sort, uniq.
    • Використовуйте tr для заміни пробілів на нові рядки.
    • Використовуйте sort для сортування результатів.
    • Використовуйте uniq для агрегування кількості образів.
kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec['initContainers', 'containers'][*].image}" |\
tr -s '[[:space:]]' '\n' |\
sort |\
uniq -c

Jsonpath інтерпретується наступним чином:

  • .items[*]: для кожного отриманого значення.
  • .spec: отримати spec.
  • ['initContainers', 'containers'][*]: для кожного контейнера.
  • .image: отримати образ.

Отримання переліку образів контейнерів в розрізі Podʼів

Форматування може бути додатково налаштоване за допомогою операції range для ітерації по елементах індивідуально.

kubectl get pods --all-namespaces -o jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\
sort

Отримання переліку образів контейнерів за мітками Podʼів

Щоб опрацьовувати лише Podʼи, які відповідають конкретній мітці, використовуйте прапорець -l. Наступне відповідає збігам лише для Podʼів з мітками, що відповідають app=nginx.

kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}" -l app=nginx

Отримання переліку образів контейнерів в розрізі просторів імен Podʼів

Щоб опрацьовувати лише Podʼи в конкретному просторі імен, використовуйте прапорець namespace. Наступне відповідає збігам лише для Podʼів у просторі імен kube-system.

kubectl get pods --namespace kube-system -o jsonpath="{.items[*].spec.containers[*].image}"

Отримання переліку образів контейнерів з використанням go-template замість jsonpath

Як альтернативу jsonpath, Kubectl підтримує використання go-templates для форматування виходу:

kubectl get pods --all-namespaces -o go-template --template="{{range .items}}{{range .spec.containers}}{{.image}} {{end}}{{end}}"

Що далі

Довідники

4.10.9 - Налаштування Ingress у Minikube з використанням NGINX Ingress Controller

Ingress — це API-обʼєкт, який визначає правила, що дозволяють зовнішній доступ до Serviceʼів у кластері. Ingress-контролер виконує правила, встановлені в Ingress.

Ця сторінка показує, як налаштувати простий Ingress, який маршрутизує запити до Service 'web' або 'web2' залежно від HTTP URI.

Перш ніж ви розпочнете

Це завдання передбачає, що ви використовуєте minikube для запуску локального Kubernetes кластера. Відвідайте сторінкуВстановлення інструментів, щоб дізнатися, як встановити minikube.

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Версія вашого Kubernetes сервера має бути не старішою ніж 1.19. Для перевірки версії введіть kubectl version. Якщо ви використовуєте старішу версію Kubernetes, використовуйте документацію для цієї версії.

Створіть кластер minikube

Якщо ви ще не налаштували кластер локально, виконайте minikube start, щоб створити кластер.

Увімкніть Ingress-контролер

  1. Для увімкнення NGINX Ingress Controller, виконайте наступну команду:

    minikube addons enable ingress
    
  2. Переконайтеся, що NGINX Ingress Controller працює:

    kubectl get pods -n ingress-nginx
    

    Вивід подібний до:

    NAME                                        READY   STATUS      RESTARTS    AGE
    ingress-nginx-admission-create-g9g49        0/1     Completed   0          11m
    ingress-nginx-admission-patch-rqp78         0/1     Completed   1          11m
    ingress-nginx-controller-59b45fb494-26npt   1/1     Running     0          11m
    

Розгорніть застосунок hello world

  1. Створіть Deployment за допомогою наступної команди:

    kubectl create deployment web --image=gcr.io/google-samples/hello-app:1.0
    

    Вивід має бути:

    deployment.apps/web created
    

    Переконайтеся, що Deployment перебуває у стані Ready:

    kubectl get deployment web 
    

    Вивід має бути подібний до:

    NAME   READY   UP-TO-DATE   AVAILABLE   AGE
    web    1/1     1            1           53s
    
  2. Опублікуйте Deployment:

    kubectl expose deployment web --type=NodePort --port=8080
    

    Вивід має бути:

    service/web exposed
    
  3. Переконайтеся, що Service створено і він доступний на порті вузла:

    kubectl get service web
    

    Вивід подібний до:

    NAME      TYPE       CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
    web       NodePort   10.104.133.249   <none>        8080:31637/TCP   12m
    
  4. Відвідайте Service через NodePort, використовуючи команду minikube service. Дотримуйтесь інструкцій для вашої платформи:

    minikube service web --url
    

    Вивід подібний до:

    http://172.17.0.15:31637
    

    Виконайте запит до URL, отриманого у попередньому кроці:

    curl http://172.17.0.15:31637 
    

    # Команду потрібно виконати в окремому терміналі.
    minikube service web --url 
    

    Вивід подібний до:

    http://127.0.0.1:62445
    ! Оскільки ви використовуєте драйвер Docker на darwin, термінал має бути відкритий для його запуску.
    

    В іншому терміналі виконайте запит до URL, отриманого у попередньому кроці:

    curl http://127.0.0.1:62445 
    

    Вивід подібний до:

    Hello, world!
    Version: 1.0.0
    Hostname: web-55b8c6998d-8k564
    

    Тепер ви можете отримати доступ до застосунку прикладу через IP-адресу Minikube і NodePort. Наступний крок дозволяє отримати доступ до застосунку, використовуючи ресурс Ingress.

Створіть Ingress

Наступний маніфест визначає Ingress, який надсилає трафік до вашого Service через hello-world.example.

  1. Створіть файл example-ingress.yaml з наступним вмістом:

    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: example-ingress
    spec:
      ingressClassName: nginx
      rules:
        - host: hello-world.example
          http:
            paths:
              - path: /
                pathType: Prefix
                backend:
                  service:
                    name: web
                    port:
                      number: 8080
  2. Створіть обʼєкт Ingress, виконавши наступну команду:

    kubectl apply -f https://k8s.io/examples/service/networking/example-ingress.yaml
    

    Вивід має бути:

    ingress.networking.k8s.io/example-ingress created
    
  3. Переконайтеся, що IP-адреса встановлена:

    kubectl get ingress
    

    Ви повинні побачити IPv4-адресу у стовпці ADDRESS; наприклад:

    NAME              CLASS   HOSTS                 ADDRESS        PORTS   AGE
    example-ingress   nginx   hello-world.example   172.17.0.15    80      38s
    
  4. Перевірте, що Ingress-контролер спрямовує трафік, дотримуючись інструкцій для вашої платформи:

    curl --resolve "hello-world.example:80:$( minikube ip )" -i http://hello-world.example
    

    minikube tunnel
    

    Вивід подібний до:

    Tunnel successfully started
    
    NOTE: Please do not close this terminal as this process must stay alive for the tunnel to be accessible ...
    
    The service/ingress example-ingress requires privileged ports to be exposed: [80 443]
    sudo permission will be asked for it.
    Starting tunnel for service example-ingress.
    

    В іншому терміналі виконайте наступну команду:

    curl --resolve "hello-world.example:80:127.0.0.1" -i http://hello-world.example
    

    Ви повинні побачити:
    Hello, world!
    Version: 1.0.0
    Hostname: web-55b8c6998d-8k564
    
  5. За бажанням ви також можете відвідати hello-world.example зі свого оглядача.

    Додайте рядок у кінець файлу /etc/hosts на вашому компʼютері (потрібні права адміністратора):

    Знайдіть зовнішню IP-адресу, як вказано у звіті minikube

      minikube ip 
    

      172.17.0.15 hello-world.example
    

    127.0.0.1 hello-world.example
    

    Після цього ваш вебоглядач надсилатиме запити на URL-адреси hello-world.example до Minikube.

Створіть другий Deployment

  1. Створіть інший Deployment, виконавши наступну команду:

    kubectl create deployment web2 --image=gcr.io/google-samples/hello-app:2.0
    

    Вивід має бути:

    deployment.apps/web2 created
    

    Переконайтеся, що Deployment перебуває у стані Ready:

    kubectl get deployment web2 
    

    Вихід має бути подібний до:

    NAME   READY   UP-TO-DATE   AVAILABLE   AGE
    web2   1/1     1            1           16s
    
  2. Опублікуйте другий Deployment:

    kubectl expose deployment web2 --port=8080 --type=NodePort
    

    Вивід має бути:

    service/web2 exposed
    

Редагування поточного Ingress

  1. Відредагуйте поточний маніфест example-ingress.yaml та додайте наступні рядки в кінці:

    - path: /v2
      pathType: Prefix
      backend:
        service:
          name: web2
          port:
            number: 8080
    
  2. Застосуйте зміни:

    kubectl apply -f example-ingress.yaml
    

    Ви маєте побачити:

    ingress.networking/example-ingress configured
    

Перевірка вашого Ingress

  1. Отримайте доступ до першої версії застосунку Hello World.

    curl --resolve "hello-world.example:80:$( minikube ip )" -i http://hello-world.example
    

    minikube tunnel
    

    Вивід подібний до:

    Tunnel successfully started
    
    NOTE: Please do not close this terminal as this process must stay alive for the tunnel to be accessible ...
    
    The service/ingress example-ingress requires privileged ports to be exposed: [80 443]
    sudo permission will be asked for it.
    Starting tunnel for service example-ingress.
    

    В іншому терміналі виконайте наступну команду:

    curl --resolve "hello-world.example:80:127.0.0.1" -i http://hello-world.example
    

    Вивід подібний до:

    Hello, world!
    Version: 1.0.0
    Hostname: web-55b8c6998d-8k564
    
  2. Отримайте доступ до другої версії застосунку Hello World.

    curl --resolve "hello-world.example:80:$( minikube ip )" -i http://hello-world.example/v2
    

    minikube tunnel
    

    Вивід подібний до:

    Tunnel successfully started
    
    NOTE: Please do not close this terminal as this process must stay alive for the tunnel to be accessible ...
    
    The service/ingress example-ingress requires privileged ports to be exposed: [80 443]
    sudo permission will be asked for it.
    Starting tunnel for service example-ingress.
    

    В іншому терміналі виконайте наступну команду:

    curl --resolve "hello-world.example:80:127.0.0.1" -i http://hello-world.example/v2
    

    Вивід подібний до:

    Hello, world!
    Version: 2.0.0
    Hostname: web2-75cd47646f-t8cjk
    

Що далі

4.10.10 - Спілкування між контейнерами в одному Podʼі за допомогою спільного тому

Ця сторінка показує, як використовувати Том для спілкування між двома контейнерами, що працюють в одному Podʼі. Також дивіться, як дозволити процесам спілкуватися між контейнерами через спільний простір процесів.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Для перевірки версії введіть kubectl version.

Створення Pod, що запускає два контейнери

У цьому завданні ви створите Pod, який запускає два контейнери. Ці два контейнери спільно використовують Том, який вони можуть використовувати для спілкування. Ось конфігураційний файл для Podʼа:

apiVersion: v1
kind: Pod
metadata:
  name: two-containers
spec:

  restartPolicy: Never

  volumes:
  - name: shared-data
    emptyDir: {}

  containers:

  - name: nginx-container
    image: nginx
    volumeMounts:
    - name: shared-data
      mountPath: /usr/share/nginx/html

  - name: debian-container
    image: debian
    volumeMounts:
    - name: shared-data
      mountPath: /pod-data
    command: ["/bin/sh"]
    args: ["-c", "echo Hello from the debian container > /pod-data/index.html"]

У конфігураційному файлі видно, що Pod має Том з назвою shared-data.

Перший контейнер, зазначений у конфігураційному файлі, запускає сервер nginx. Шлях монтування для спільного тому — /usr/share/nginx/html. Другий контейнер базується на образі debian і має шлях монтування /pod-data. Другий контейнер виконує наступну команду і потім завершується.

echo Hello from the debian container > /pod-data/index.html

Зверніть увагу, що другий контейнер записує файл index.html в кореневу теку сервера nginx.

Створіть Pod і два контейнери:

kubectl apply -f https://k8s.io/examples/pods/two-container-pod.yaml

Перегляньте інформацію про Pod та контейнери:

kubectl get pod two-containers --output=yaml

Ось частина вихідних даних:

apiVersion: v1
kind: Pod
metadata:
    ...
    name: two-containers
    namespace: default
    ...
spec:
    ...
    containerStatuses:

    - containerID: docker://c1d8abd1 ...
    image: debian
    ...
    lastState:
        terminated:
        ...
    name: debian-container
    ...

    - containerID: docker://96c1ff2c5bb ...
    image: nginx
    ...
    name: nginx-container
    ...
    state:
        running:
    ...

Ви бачите, що контейнер debian завершив роботу, а контейнер nginx все ще працює.

Отримайте доступ до shell контейнера nginx:

kubectl exec -it two-containers -c nginx-container -- /bin/bash

У вашому shell перевірте, що nginx працює:

root@two-containers:/# apt-get update
root@two-containers:/# apt-get install curl procps
root@two-containers:/# ps aux

Вихідні дані схожі на це:

USER       PID  ...  STAT START   TIME COMMAND
root         1  ...  Ss   21:12   0:00 nginx: master process nginx -g daemon off;

Згадайте, що контейнер debian створив файл index.html в кореневій теці nginx. Використовуйте curl, щоб надіслати GET запит на сервер nginx:

root@two-containers:/# curl localhost

Вихідні дані показують, що nginx обслуговує вебсторінку, написану контейнером debian:

Hello from the debian container

Обговорення

Основна причина, через яку Podʼи можуть мати кілька контейнерів, полягає у підтримці допоміжних застосунків, що допомагають основному застосунку. Типові приклади допоміжних застосунків включають інструменти для завантаження, надсилання даних та проксі. Допоміжні та основні застосунки часто потребують спілкування між собою. Зазвичай це робиться через спільну файлову систему, як показано в цій вправі, або через інтерфейс локальної мережі, localhost. Прикладом цього шаблону є вебсервер разом із допоміжним застосунком, яка перевіряє репозиторій Git на наявність нових оновлень.

Том у цьому завданні надає спосіб спілкування контейнерів під час життя Pod. Якщо Pod видалено та створено знову, всі дані, збережені в спільному томі, будуть втрачені.

Що далі

4.10.11 - Налаштування DNS для кластера

Kubernetes пропонує надбудову DNS для кластера, яку типово увімкнено у більшості підтримуваних середовищ. У Kubernetes версії 1.11 і пізніших версіях рекомендовано використовувати CoreDNS, який стандартно встановлюється з kubeadm.

Для отримання додаткової інформації про налаштування CoreDNS для кластера Kubernetes дивіться Налаштування DNS-сервісу. Приклад, який демонструє, як використовувати Kubernetes DNS з kube-dns, дивіться у прикладі втулка Kubernetes DNS.

4.10.12 - Доступ до Service, що працюють в кластерах

Ця сторінка показує, як підʼєднатись до Serviceʼів, що працюють у кластері Kubernetes.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Для перевірки версії введіть kubectl version.

Доступ до Serviceʼів, що працюють у кластері

У Kubernetes Вузли, Podʼи та Serviceʼи мають власні IP-адреси. У багатьох випадках IP-адреси вузлів, Podʼів та деякі IP-адреси Service у кластері не можуть бути маршрутизовані, тому вони не будуть досяжними з машини за межами кластера, такої як ваш настільний компʼютер.

Способи приєднання

Ви маєте кілька варіантів приєднання до вузлів, Podʼів та Serviceʼів ззовні кластера:

  • Доступ до Servicʼів через публічні IP-адреси.
    • Використовуйте Service з типом NodePort або LoadBalancer, щоб зробити Service доступним ззовні кластера. Дивіться документацію Service та kubectl expose.
    • Залежно від середовища вашого кластера, це може тільки відкрити Service для вашої корпоративної мережі, або ж зробити його доступним в інтернеті. Подумайте, чи є Service безпечним для відкриття. Чи має він власну автентифікацію?
    • Розміщуйте Podʼи за Serviceʼами. Щоб отримати доступ до одного конкретного Pod з набору реплік, наприклад, для налагодження, додайте унікальну мітку до Podʼа і створіть новий Service, який обирає цю мітку.
    • У більшості випадків розробнику застосунків не потрібно безпосередньо звертатися до вузлів за їх IP-адресами.
  • Доступ до Serviceʼів, вузлів або Podʼів за допомогою проксі-дієслова (Proxy Verb).
    • Виконує автентифікацію та авторизацію на api-сервері перед доступом до віддаленого Service. Використовуйте це, якщо Service недостатньо безпечні для відкриття в інтернеті, або для доступу до портів на IP-адресі вузла, або для налагодження.
    • Проксі можуть викликати проблеми для деяких вебзастосунків.
    • Працює тільки для HTTP/HTTPS.
    • Описано тут.
  • Доступ з вузла або Podʼа в кластері.
    • Запустіть Pod та отримайте доступ до shell у ньому за допомогою kubectl exec. Підʼєднуйтесь до інших вузлів, Podʼів та Serviceʼів з цього shell.
    • Деякі кластери можуть дозволити вам підʼєднатись по SSH до вузла в кластері. Звідти ви можете отримати доступ до Serviceʼів кластера. Це нестандартний метод і працюватиме на одних кластерах, але на інших — ні. Оглядачі та інші інструменти можуть бути встановлені або не встановлені. DNS кластера може не працювати.

Виявлення вбудованих Service

Зазвичай у кластері є кілька Serviceʼів, які запускаються у просторі імен kube-system. Отримайте їх список за допомогою команди kubectl cluster-info:

kubectl cluster-info

Вихідні дані подібні до цього:

Kubernetes master is running at https://192.0.2.1
elasticsearch-logging is running at https://192.0.2.1/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy
kibana-logging is running at https://192.0.2.1/api/v1/namespaces/kube-system/services/kibana-logging/proxy
kube-dns is running at https://192.0.2.1/api/v1/namespaces/kube-system/services/kube-dns/proxy
grafana is running at https://192.0.2.1/api/v1/namespaces/kube-system/services/monitoring-grafana/proxy
heapster is running at https://192.0.2.1/api/v1/namespaces/kube-system/services/monitoring-heapster/proxy

Це показує URL з проксі-дієсловом для доступу до кожного Service. Наприклад, у цьому кластері ввімкнено кластерне логування (з використанням Elasticsearch), до якого можна звернутися за адресою https://192.0.2.1/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/ за умови наявності відповідних облікових даних або через проксі kubectl за адресою: http://localhost:8080/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/.

Ручне створення URL-адрес проксі api-сервера

Як згадувалося вище, ви використовуєте команду kubectl cluster-info, щоб отримати URL проксі для Service. Щоб створити URL-адреси проксі, що включають точки доступу Service, суфікси та параметри, додайте до URL проксі Serviceʼу: http://kubernetes_master_address/api/v1/namespaces/namespace_name/services/[https:]service_name[:port_name]/proxy

Якщо ви не задали імʼя для вашого порту, вам не потрібно вказувати port_name в URL. Ви також можете використовувати номер порту замість port_name для іменованих та неіменованих портів.

Стандартно апі-сервер проксює до вашого Serviceʼу за допомогою HTTP. Щоб використовувати HTTPS, додайте префікс до імені Serviceʼу https:: http://<kubernetes_master_address>/api/v1/namespaces/<namespace_name>/services/<service_name>/proxy.

Підтримувані формати для сегмента <service_name> URL-адреси:

  • <service_name> — проксює до стандартного порту або до неіменованого порту за допомогою http
  • <service_name>:<port_name> — проксює до вказаного імені порту або номера порту за допомогою http
  • https:<service_name>: — проксює до стандартного порту або до неіменованого порту за допомогою https (зверніть увагу на кінцеву двокрапку)
  • https:<service_name>:<port_name> — проксює до вказаного імені порту або номера порту за допомогою https
Приклади
  • Для доступу до точки доступу сервісу Elasticsearch _search?q=user:kimchy, використовуйте:

    http://192.0.2.1/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_search?q=user:kimchy
    
  • Для доступу до інформації про стан кластера Elasticsearch _cluster/health?pretty=true, використовуйте:

    https://192.0.2.1/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_cluster/health?pretty=true
    

    Інформація про стан подібна до цієї:

    {
      "cluster_name" : "kubernetes_logging",
      "status" : "yellow",
      "timed_out" : false,
      "number_of_nodes" : 1,
      "number_of_data_nodes" : 1,
      "active_primary_shards" : 5,
      "active_shards" : 5,
      "relocating_shards" : 0,
      "initializing_shards" : 0,
      "unassigned_shards" : 5
    }
    
  • Для доступу до https інформації про стан кластера Elasticsearch _cluster/health?pretty=true, використовуйте:

    https://192.0.2.1/api/v1/namespaces/kube-system/services/https:elasticsearch-logging:/proxy/_cluster/health?pretty=true
    

Використання вебоглядачів для доступу до Serviceʼів, що працюють у кластері

Ви можете вставити URL-адресу проксі api-сервера у адресний рядок оглядача. Однак:

  • Вебоглядачі зазвичай не можуть передавати токени, тому вам може доведеться використовувати базову автентифікацію (пароль). Api-сервер можна налаштувати для роботи з базовою автентифікацією, але ваш кластер може бути не налаштований для цього.
  • Деякі вебзастосунки можуть не працювати, особливо ті, що використовують клієнтський javascript для створення URL-адрес, не знаючи про префікс шляху проксі.

4.11 - Розширення Kubernetes

Розуміння розширених способів адаптації кластера Kubernetes до потреб вашого робочого середовища.

4.11.1 - Використання власних ресурсів

4.11.1.1 - Розширення API Kubernetes за допомогою CustomResourceDefinitions

Ця сторінка показує, як встановити власний ресурс у API Kubernetes, створивши CustomResourceDefinition.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Версія вашого Kubernetes сервера має бути не старішою ніж 1.16. Для перевірки версії введіть kubectl version. Якщо ви використовуєте старішу версію Kubernetes, яка все ще підтримується, використовуйте документацію для цієї версії, щоб отримати поради, які є відповідними для вашого кластера.

Створення CustomResourceDefinition

При створенні нового CustomResourceDefinition (CRD) сервер API Kubernetes створює новий RESTful ресурсний шлях для кожної версії, яку ви вказуєте. Власний ресурс, створений з обʼєкта CRD, може бути або просторово обмеженим за іменем, або обмеженим на рівні кластера, як вказано в полі spec.scope CRD. Як і з наявними вбудованими обʼєктами, видалення простору імен видаляє всі власні обʼєкти в цьому просторі імен. CustomResourceDefinition самі за собою не мають простору імен і доступні для всіх просторів імен.

Наприклад, якщо ви збережете наступне визначення CustomResourceDefinition у resourcedefinition.yaml:

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  # назва повинна відповідати полям специфікації нижче, і мати формат: <plural>.<group>
  name: crontabs.stable.example.com
spec:
  # назва групи, яка буде використана для REST API: /apis/<group>/<version>
  group: stable.example.com
  # список версій, підтримуваних цим визначенням власних ресурсів
  versions:
    - name: v1
      # Кожну версію можна ввімкнути/вимкнути за допомогою прапорця Served.
      served: true
      # Одна і лише одна версія повинна бути позначена як версія зберігання.
      storage: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                cronSpec:
                  type: string
                image:
                  type: string
                replicas:
                  type: integer
  # або просторово обмежений за іменем, або на рівні кластера
  scope: Namespaced
  names:
    # назва множини, яка буде використана в URL: /apis/<group>/<version>/<plural>
    plural: crontabs
    # назва однини, яка буде використана як псевдонім у CLI та для показу
    singular: crontab
    # вид - зазвичай це тип у форматі CamelCased однини. Ваші маніфести ресурсів використовують це.
    kind: CronTab
    # короткі назви дозволяють мати збіг для скорочених рядків з вашим ресурсом у CLI
    shortNames:
    - ct

та створите його:

kubectl apply -f resourcedefinition.yaml

Тоді буде створено новий просторово обмежений RESTful API шлях за адресою:

/apis/stable.example.com/v1/namespaces/*/crontabs/...

Цю URL-адресу шляху можна буде використовувати для створення та управління власними обʼєктами. kind цих обʼєктів буде CronTab зі специфікації обʼєкта CustomResourceDefinition, який ви створили вище.

Може знадобитися кілька секунд, щоб створити точку доступу. Ви можете спостерігати, що умова Established вашого CustomResourceDefinition стає true або спостерігати інформацію про відкриття сервера API для вашого ресурсу, щоб він зʼявився.

Створення власних обʼєктів

Після створення обʼєкта CustomResourceDefinition ви можете створювати власні обʼєкти. Власні обʼєкти можуть містити власні поля. Ці поля можуть містити довільний JSON. У наступному прикладі поля cronSpec та image встановлені у власний обʼєкт типу CronTab. Тип CronTab походить зі специфікації обʼєкта CustomResourceDefinition, який ви створили вище.

Якщо ви збережете наступний YAML у my-crontab.yaml:

apiVersion: "stable.example.com/v1"
kind: CronTab
metadata:
  name: my-new-cron-object
spec:
  cronSpec: "* * * * */5"
  image: my-awesome-cron-image

і створите його:

kubectl apply -f my-crontab.yaml

Потім ви можете управляти вашими обʼєктами CronTab за допомогою kubectl. Наприклад:

kubectl get crontab

Повинен вивести список, подібний до такого:

NAME                 AGE
my-new-cron-object   6s

Назви ресурсів нечутливі до регістру при використанні kubectl, і ви можете використовувати як однину, так і множину, визначені в CRD, а також будь-які короткі назви.

Ви також можете переглянути дані YAML:

kubectl get ct -o yaml

Ви повинні побачити, що він містить власні поля cronSpec та image з YAML, який ви використовували для його створення:

apiVersion: v1
items:
- apiVersion: stable.example.com/v1
  kind: CronTab
  metadata:
    annotations:
      kubectl.kubernetes.io/last-applied-configuration: |
        {"apiVersion":"stable.example.com/v1","kind":"CronTab","metadata":{"annotations":{},"name":"my-new-cron-object","namespace":"default"},"spec":{"cronSpec":"* * * * */5","image":"my-awesome-cron-image"}}        
    creationTimestamp: "2021-06-20T07:35:27Z"
    generation: 1
    name: my-new-cron-object
    namespace: default
    resourceVersion: "1326"
    uid: 9aab1d66-628e-41bb-a422-57b8b3b1f5a9
  spec:
    cronSpec: '* * * * */5'
    image: my-awesome-cron-image
kind: List
metadata:
  resourceVersion: ""
  selfLink: ""

Видалення CustomResourceDefinition

Коли ви видаляєте CustomResourceDefinition, сервер деінсталює RESTful API шлях та видаляє всі власні обʼєкти, збережені в ньому.

kubectl delete -f resourcedefinition.yaml
kubectl get crontabs
Error from server (NotFound): Unable to list {"stable.example.com" "v1" "crontabs"}: the server could not
find the requested resource (get crontabs.stable.example.com)

Якщо ви пізніше створите те саме CustomResourceDefinition, воно буде порожнім з початку.

Визначення структурної схеми

CustomResources зберігають структуровані дані у власних полях (разом з вбудованими полями apiVersion, kind та metadata, які сервер API перевіряє неявно). З валідацією OpenAPI v3.0 можна вказати схему, яка перевіряється під час створення та оновлення. Подивіться нижче для деталей та обмежень такої схеми.

З apiextensions.k8s.io/v1 визначення структурної схеми є обовʼязковим для визначення власних ресурсів. У бета-версії CustomResourceDefinition структурна схема була необовʼязковою.

Структурна схема — це схема валідації OpenAPI v3.0, яка:

  1. вказує непорожній тип (за допомогою type в OpenAPI) для кореня, для кожного вказаного поля вузла обʼєкта (за допомогою properties або additionalProperties в OpenAPI) та для кожного елемента вузла масиву (за допомогою items в OpenAPI), за винятком:
    • вузла з x-kubernetes-int-or-string: true
    • вузла з x-kubernetes-preserve-unknown-fields: true
  2. для кожного поля в обʼєкті та кожного елемента в масиві, які вказані всередині будь-якого з allOf, anyOf, oneOf або not, схема також вказує поле/елемент поза цими логічними виразами (порівняйте приклад 1 та 2).
  3. не встановлює description, type, default, additionalProperties, nullable всередині allOf, anyOf, oneOf або not, за винятком двох шаблонів для x-kubernetes-int-or-string: true (див. нижче).
  4. якщо вказано metadata, то дозволяються обмеження тільки на metadata.name та metadata.generateName.

Неструктурний приклад 1:

allOf:
- properties:
    foo:
      ...

суперечить правилу 2. Наступне було б правильним:

properties:
  foo:
    ...
allOf:
- properties:
    foo:
      ...

Неструктурний приклад 2:

allOf:
- items:
    properties:
      foo:
        ...

суперечить правилу 2. Наступне було б правильним:

items:
  properties:
    foo:
      ...
allOf:
- items:
    properties:
      foo:
        ...

Неструктурний приклад 3:

properties:
  foo:
    pattern: "abc"
  metadata:
    type: object
    properties:
      name:
        type: string
        pattern: "^a"
      finalizers:
        type: array
        items:
          type: string
          pattern: "my-finalizer"
anyOf:
- properties:
    bar:
      type: integer
      minimum: 42
  required: ["bar"]
  description: "foo bar object"

не є структурною схемою через наступні порушення:

  • тип у корені відсутній (правило 1).
  • тип foo відсутній (правило 1).
  • bar всередині anyOf не вказаний зовні (правило 2).
  • тип bar в anyOf (правило 3).
  • опис встановлено в anyOf (правило 3).
  • metadata.finalizers можуть бути не обмежені (правило 4).

Натомість наступна відповідна схема є структурною:

type: object
description: "foo bar object"
properties:
  foo:
    type: string
    pattern: "abc"
  bar:
    type: integer
  metadata:
    type: object
    properties:
      name:
        type: string
        pattern: "^a"
anyOf:
- properties:
    bar:
      minimum: 42
  required: ["bar"]

Порушення правил структурної схеми повідомляються в умові NonStructural у CustomResourceDefinition.

Обрізка полів

CustomResourceDefinitions зберігають перевірені дані ресурсів у сховищі постійного зберігання кластера, etcd.Так само як і з вбудованими ресурсами Kubernetes, такими як ConfigMap, якщо ви вказуєте поле, яке сервер API не впізнає, невідоме поле обрізається (видаляється) перед зберіганням.

CRD, перетворені з apiextensions.k8s.io/v1beta1 на apiextensions.k8s.io/v1, можуть бути позбавлені структурних схем, і spec.preserveUnknownFields може бути встановлено в true.

Для застарілих обʼєктів власного визначення ресурсів, створених як apiextensions.k8s.io/v1beta1 з spec.preserveUnknownFields встановленим в true, також вірно наступне:

  • Обрізка не ввімкнена.
  • Ви можете зберігати довільні дані.

Для сумісності з apiextensions.k8s.io/v1 оновіть визначення своїх власних ресурсів:

  1. Використовуйте структурну схему OpenAPI.
  2. Встановіть spec.preserveUnknownFields в false.

Якщо ви збережете наступний YAML у my-crontab.yaml:

apiVersion: "stable.example.com/v1"
kind: CronTab
metadata:
  name: my-new-cron-object
spec:
  cronSpec: "* * * * */5"
  image: my-awesome-cron-image
  someRandomField: 42

і створите його:

kubectl create --validate=false -f my-crontab.yaml -o yaml

Ваш вивід буде подібним до:

apiVersion: stable.example.com/v1
kind: CronTab
metadata:
  creationTimestamp: 2017-05-31T12:56:35Z
  generation: 1
  name: my-new-cron-object
  namespace: default
  resourceVersion: "285"
  uid: 9423255b-4600-11e7-af6a-28d2447dc82b
spec:
  cronSpec: '* * * * */5'
  image: my-awesome-cron-image

Зверніть увагу, що поле someRandomField було обрізано.

У цьому прикладі вимкнено перевірку на клієнтському боці, щоб показати поведінку сервера API, додавши параметр командного рядка --validate=false. Оскільки схеми валідації OpenAPI також публікуються для клієнтів, kubectl також перевіряє невідомі поля та відхиляє ці обʼєкти задовго до їх надсилання на сервер API.

Контроль обрізки полів

Типово усі невизначені поля власного ресурсу, у всіх версіях, обрізаються. Однак можна відмовитися від цього для певних піддерев полів, додавши x-kubernetes-preserve-unknown-fields: true у структурну схему валідації OpenAPI v3.

Наприклад:

type: object
properties:
  json:
    x-kubernetes-preserve-unknown-fields: true

Поле json може зберігати будь-яке значення JSON, без обрізки.

Ви також можете частково вказати допустимий JSON; наприклад:

type: object
properties:
  json:
    x-kubernetes-preserve-unknown-fields: true
    type: object
    description: this is arbitrary JSON

З цим дозволяються тільки значення типу object.

Обрізка знову ввімкнена для кожного вказаного властивості (або additionalProperties):

type: object
properties:
  json:
    x-kubernetes-preserve-unknown-fields: true
    type: object
    properties:
      spec:
        type: object
        properties:
          foo:
            type: string
          bar:
            type: string

З цим значення:

json:
  spec:
    foo: abc
    bar: def
    something: x
  status:
    something: x

обрізається до:

json:
  spec:
    foo: abc
    bar: def
  status:
    something: x

Це означає, що поле something у вказаному обʼєкті spec обрізається, але все поза цим обʼєктом — ні.

IntOrString

Вузли в схемі з x-kubernetes-int-or-string: true виключаються з правила 1, таким чином наступна схема є структурною:

type: object
properties:
  foo:
    x-kubernetes-int-or-string: true

Також ці вузли частково виключаються з правила 3 у тому сенсі, що дозволяються наступні два шаблони (саме ці, без варіацій в порядку або додаткових полів):

x-kubernetes-int-or-string: true
anyOf:
  - type: integer
  - type: string
...

та

x-kubernetes-int-or-string: true
allOf:
  - anyOf:
      - type: integer
      - type: string
  - ... # нуль або більше
...

З однією з цих специфікацій, як ціле число, так і рядок будуть валідними.

У розділі Публікація схеми валідації, x-kubernetes-int-or-string: true розгортається до одного з двох показаних вище шаблонів.

RawExtension

RawExtensions (як у runtime.RawExtension) містять повні обʼєкти Kubernetes, тобто з полями apiVersion і kind.

Можна задати ці вбудовані обʼєкти (як повністю без обмежень, так і частково задані), встановивши x-kubernetes-embedded-resource: true. Наприклад:

type: object
properties:
  foo:
    x-kubernetes-embedded-resource: true
    x-kubernetes-preserve-unknown-fields: true

Тут поле foo містить повний обʼєкт, наприклад:

foo:
  apiVersion: v1
  kind: Pod
  spec:
    ...

Оскільки поруч вказано x-kubernetes-preserve-unknown-fields: true, нічого не обрізається. Використання x-kubernetes-preserve-unknown-fields: true є опціональним.

З x-kubernetes-embedded-resource: true поля apiVersion, kind і metadata неявно задаються та перевіряються на валідність.

Обслуговування декількох версій CRD

Дивіться версіювання визначення власних ресурсів для отримання додаткової інформації про обслуговування декількох версій вашого CustomResourceDefinition і міграцію ваших обʼєктів з однієї версії на іншу.

Розширені теми

Завершувачі

Завершувачі дозволяють контролерам реалізовувати асинхронні гаки перед видаленням. Власні обʼєкти підтримують завершувачі, аналогічні вбудованим обʼєктам.

Ви можете додати завершувач до власного обʼєкта ось так:

apiVersion: "stable.example.com/v1"
kind: CronTab
metadata:
  finalizers:
  - stable.example.com/finalizer

Ідентифікатори власних завершувачів складаються з імені домену, косої риски та назви завершувача. Будь-який контролер може додати завершувач до списку завершувачів будь-якого обʼєкта.

Перший запит на видалення обʼєкта з завершувачами встановлює значення для поля metadata.deletionTimestamp, але не видаляє його. Після встановлення цього значення можна лише видаляти записи у списку finalizers. Поки залишаються будь-які завершувачі, неможливо примусово видалити обʼєкт.

Коли поле metadata.deletionTimestamp встановлене, контролери, які стежать за обʼєктом, виконують будь-які завершувачі, які вони обробляють, і видаляють завершувач зі списку після завершення. Відповідальність за видалення свого завершувача зі списку лежить на кожному контролері.

Значення поля metadata.deletionGracePeriodSeconds контролює інтервал між оновленнями опитування.

Після того, як список завершувачів стане порожнім, тобто всі завершувачі будуть виконані, ресурс буде видалено Kubernetes.

Валідація

Власні ресурси перевіряються за допомогою схем OpenAPI v3, за допомогою x-kubernetes-validations, коли функція Правил валідації ввімкнена, і ви можете додати додаткову валідацію за допомогою вебхуків допуску.

Крім того, до схеми застосовуються такі обмеження:

  • Ці поля не можна встановлювати:

    • definitions,
    • dependencies,
    • deprecated,
    • discriminator,
    • id,
    • patternProperties,
    • readOnly,
    • writeOnly,
    • xml,
    • $ref.
  • Поле uniqueItems не можна встановлювати в true.

  • Поле additionalProperties не можна встановлювати в false.

  • Поле additionalProperties є взаємозаперечним із properties.

Розширення x-kubernetes-validations можна використовувати для перевірки власних ресурсів за допомогою виразів загальної мови виразів (CEL), коли функція правил валідації увімкнена, а схема CustomResourceDefinition є структурною схемою.

Зверніться до розділу структурних схем для інших обмежень та функцій CustomResourceDefinition.

Схема визначається у CustomResourceDefinition. У наведеному нижче прикладі CustomResourceDefinition застосовує такі перевірки до власного обʼєкта:

  • spec.cronSpec повинен бути рядком і відповідати формі, описаній регулярним виразом.
  • spec.replicas повинен бути цілим числом і мати мінімальне значення 1 та максимальне значення 10.

Збережіть CustomResourceDefinition у файл resourcedefinition.yaml:

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: crontabs.stable.example.com
spec:
  group: stable.example.com
  versions:
    - name: v1
      served: true
      storage: true
      schema:
        # openAPIV3Schema - це схема для перевірки власних обʼєктів.
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                cronSpec:
                  type: string
                  pattern: '^(\d+|\*)(/\д+)?(\s+(\d+|\*)(/\д+)?){4}$'
                image:
                  type: string
                replicas:
                  type: integer
                  minimum: 1
                  maximum: 10
  scope: Namespaced
  names:
    plural: crontabs
    singular: crontab
    kind: CronTab
    shortNames:
    - ct

і створіть його:

kubectl apply -f resourcedefinition.yaml

Запит на створення власного обʼєкта типу CronTab буде відхилено, якщо поля містять недійсні значення. У наведеному нижче прикладі власний обʼєкт містить поля з недійсними значеннями:

  • spec.cronSpec не відповідає регулярному виразу.
  • spec.replicas більше 10.

Якщо ви збережете наступний YAML у файл my-crontab.yaml:

apiVersion: "stable.example.com/v1"
kind: CronTab
metadata:
  name: my-new-cron-object
spec:
  cronSpec: "* * * *"
  image: my-awesome-cron-image
  replicas: 15

і спробуєте створити його:

kubectl apply -f my-crontab.yaml

то отримаєте помилку:

The CronTab "my-new-cron-object" is invalid: []: Invalid value: map[string]interface {}{"apiVersion":"stable.example.com/v1", "kind":"CronTab", "metadata":map[string]interface {}{"name":"my-new-cron-object", "namespace":"default", "deletionTimestamp":interface {}(nil), "deletionGracePeriodSeconds":(*int64)(nil), "creationTimestamp":"2017-09-05T05:20:07Z", "uid":"e14d79e7-91f9-11e7-a598-f0761cb232d1", "clusterName":""}, "spec":map[string]interface {}{"cronSpec":"* * * *", "image":"my-awesome-cron-image", "replicas":15}}:
validation failure list:
spec.cronSpec in body should match '^(\d+|\*)(/\д+)?(\с+(\д+|\*)(/\д+)?){4}$'
spec.replicas in body should be less than or equal to 10

Якщо поля містять дійсні значення, запит на створення обʼєкта буде прийнято.

Збережіть наступний YAML у файл my-crontab.yaml:

apiVersion: "stable.example.com/v1"
kind: CronTab
metadata:
  name: my-new-cron-object
spec:
  cronSpec: "* * * * */5"
  image: my-awesome-cron-image
  replicas: 5

І створіть його:

kubectl apply -f my-crontab.yaml
crontab "my-new-cron-object" created

Проковзування валідації

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.30 [beta]

Якщо ви використовуєте версію Kubernetes старше v1.30, вам потрібно явно ввімкнути функціональну можливість CRDValidationRatcheting, щоб використовувати цю поведінку, яка потім застосовується до всіх CustomResourceDefinitions у вашому кластері.

За умови увімкнення функціональної можливості, Kubernetes реалізує проковзування валідації для CustomResourceDefinitions. API сервер готовий прийняти оновлення ресурсів, які є недійсними після оновлення, за умови, що кожна частина ресурсу, яка не пройшла валідацію, не була змінена операцією оновлення. Іншими словами, будь-яка недійсна частина ресурсу, яка залишається недійсною, вже повинна була бути неправильною. Ви не можете використовувати цей механізм для оновлення дійсного ресурсу, щоб він став недійсним.

Ця функція дозволяє авторам CRD впевнено додавати нові перевірки до схеми OpenAPIV3 за певних умов. Користувачі можуть безпечно оновлюватися до нової схеми без зміни версії обʼєкта або порушення робочих процесів.

Хоча більшість перевірок, розміщених у схемі OpenAPIV3 CRD, підтримують обмеження, є кілька винятків. Наступні перевірки схеми OpenAPIV3 не підтримуються обмеженнями у реалізації в Kubernetes 1.31 і якщо порушені, продовжуватимуть видавати помилку як зазвичай:

  • Квантори

    • allOf
    • oneOf
    • anyOf
    • not
    • будь-які перевірки в нащадках одного з цих полів
  • x-kubernetes-validations Для Kubernetes 1.28, правила валідації CRD ігноруються обмеженнями. Починаючи з Alpha 2 у Kubernetes 1.29, x-kubernetes-validations обмежуються лише, якщо вони не посилаються на oldSelf.

    Перехідні правила ніколи не обмежуються: лише помилки, які виникають через правила, які не використовують oldSelf, автоматично обмежуються, якщо їх значення не змінені.

    Щоб написати власну логіку обмеження для виразів CEL, перегляньте optionalOldSelf.

  • x-kubernetes-list-type Помилки, що виникають через зміну типу списку у підсхемі, не будуть обмежені. Наприклад, додавання set до списку з дублікатів завжди призведе до помилки.

  • x-kubernetes-map-keys Помилки, що виникають через зміну ключів карти у схемі списку, не будуть обмежені.

  • required Помилки, що виникають через зміну списку обовʼязкових полів, не будуть обмежені.

  • properties Додавання/видалення/модифікація імен властивостей не обмежуються, але зміни до перевірок у схемах та підсхемах властивостей можуть бути обмежені, якщо імʼя властивості залишається незмінним.

  • additionalProperties Видалення раніше вказаної валідації additionalProperties не буде обмежено.

  • metadata Помилки, що виникають через вбудовану валідацію обʼєкта metadata у Kubernetes, не будуть обмежені (наприклад, імʼя обʼєкта або символи у значенні мітки). Якщо ви вказуєте свої власні додаткові правила для метаданих власного ресурсу, ця додаткова валідація буде обмежена.

Правила валідації

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.29 [stable]

Правила валідації використовують Common Expression Language (CEL) для валідації значень власних ресурсів. Правила валідації включаються в схеми CustomResourceDefinition за допомогою розширення x-kubernetes-validations.

Правило обмежується місцем знаходження розширення x-kubernetes-validations у схемі. Змінна self у виразі CEL привʼязана до значення, що перевіряється.

Всі правила валідації обмежені поточним обʼєктом: ніякі міжобʼєктні або stateful правила валідації не підтримуються.

Наприклад:

  ...
  openAPIV3Schema:
    type: object
    properties:
      spec:
        type: object
        x-kubernetes-validations:
          - rule: "self.minReplicas <= self.replicas"
            message: "replicas should be greater than or equal to minReplicas."
          - rule: "self.replicas <= self.maxReplicas"
            message: "replicas should be smaller than or equal to maxReplicas."
        properties:
          ...
          minReplicas:
            type: integer
          replicas:
            type: integer
          maxReplicas:
            type: integer
        required:
          - minReplicas
          - replicas
          - maxReplicas

відхилить запит на створення цього власного ресурсу:

apiVersion: "stable.example.com/v1"
kind: CronTab
metadata:
  name: my-new-cron-object
spec:
  minReplicas: 0
  replicas: 20
  maxReplicas: 10

з відповіддю:

The CronTab "my-new-cron-object" is invalid:
* spec: Invalid value: map[string]interface {}{"maxReplicas":10, "minReplicas":0, "replicas":20}: replicas should be smaller than or equal to maxReplicas.

x-kubernetes-validations може містити декілька правил. rule під x-kubernetes-validations представляє вираз, який буде оцінюватися CEL. message представляє повідомлення, що показується при невдачі валідації. Якщо повідомлення не встановлено, відповідь буде такою:

The CronTab "my-new-cron-object" is invalid:
* spec: Invalid value: map[string]interface {}{"maxReplicas":10, "minReplicas":0, "replicas":20}: failed rule: self.replicas <= self.maxReplicas

Правила валідації компілюються при створенні/оновленні CRD. Запит на створення/оновлення CRD буде відхилено, якщо компіляція правил валідації зазнає невдачі. Процес компіляції включає перевірку типів.

Помилки компіляції:

  • no_matching_overload: ця функція не має перевантаження для типів аргументів.

    Наприклад, правило self == true для поля типу integer призведе до помилки:

    Invalid value: apiextensions.ValidationRule{Rule:"self == true", Message:""}: compilation failed: ERROR: \<input>:1:6: found no matching overload for '_==_' applied to '(int, bool)'
    
  • no_such_field: не містить бажаного поля.

    Наприклад, правило self.nonExistingField > 0 для неіснуючого поля поверне наступну помилку:

    Invalid value: apiextensions.ValidationRule{Rule:"self.nonExistingField > 0", Message:""}: compilation failed: ERROR: \<input>:1:5: undefined field 'nonExistingField'
    
  • invalid argument: недійсний аргумент для макросів.

    Наприклад, правило has(self) поверне помилку:

    Invalid value: apiextensions.ValidationRule{Rule:"has(self)", Message:""}: compilation failed: ERROR: <input>:1:4: invalid argument to has() macro
    

Приклади правил валідації:

ПравилоПризначення
self.minReplicas <= self.replicas && self.replicas <= self.maxReplicasПеревірка, що три поля, які визначають репліки, впорядковані належним чином
'Available' in self.stateCountsПеревірка наявності запису з ключем 'Available' у map
(size(self.list1) == 0) != (size(self.list2) == 0)Перевірка, що один з двох списків не порожній, але не обидва
!('MY_KEY' in self.map1) || self['MY_KEY'].matches('^[a-zA-Z]*$')Перевірка значення map для конкретного ключа, якщо він у мапі
self.envars.filter(e, e.name == 'MY_ENV').all(e, e.value.matches('^[a-zA-Z]*$')Перевірка поля 'value' у списку map, де ключове поле 'name' дорівнює 'MY_ENV'
has(self.expired) && self.created + self.ttl < self.expiredПеревірка, що дата 'expired' після дати 'create' плюс тривалість 'ttl'
self.health.startsWith('ok')Перевірка, що рядкове поле 'health' починається з префіксу 'ok'
self.widgets.exists(w, w.key == 'x' && w.foo < 10)Перевірка, що властивість 'foo' елемента списку map з ключем 'x' менше 10
type(self) == string ? self == '100%' : self == 1000Перевірка поля int-or-string для обох випадків int і string
self.metadata.name.startsWith(self.prefix)Перевірка, що імʼя обʼєкта має префікс іншого поля значення
self.set1.all(e, !(e in self.set2))Перевірка, що два списки множин не перетинаються
size(self.names) == size(self.details) && self.names.all(n, n in self.details)Перевірка, що мапа 'details' має ключі з елементів списку множин 'names'
size(self.clusters.filter(c, c.name == self.primary)) == 1Перевірка, що властивість 'primary' має лише одну появу у списку мап 'clusters'

Посилання: Supported evaluation on CEL

  • Якщо правило обмежене коренем ресурсу, воно може вибирати поля з будь-яких полів, оголошених у схемі OpenAPIv3 CRD, а також apiVersion, kind, metadata.name та metadata.generateName. Це включає вибір полів як у spec, так і в status в одному виразі:

      ...
      openAPIV3Schema:
        type: object
        x-kubernetes-validations:
          - rule: "self.status.availableReplicas >= self.spec.minReplicas"
        properties:
            spec:
              type: object
              properties:
                minReplicas:
                  type: integer
                ...
            status:
              type: object
              properties:
                availableReplicas:
                  type: integer
    
  • Якщо Rule обмежене обʼєктом з властивостями, доступні властивості обʼєкта можна вибирати за допомогою self.field, а наявність поля можна перевірити за допомогою has(self.field). Поля зі значенням null трактуються як відсутні поля у виразах CEL.

      ...
      openAPIV3Schema:
        type: object
        properties:
          spec:
            type: object
            x-kubernetes-validations:
              - rule: "has(self.foo)"
            properties:
              ...
              foo:
                type: integer
    
  • Якщо Rule обмежене обʼєктом з додатковими властивостями (тобто map), значення map доступні через self[mapKey], наявність map можна перевірити за допомогою mapKey in self, а всі записи з map доступні за допомогою макросів і функцій CEL, таких як self.all(...).

      ...
      openAPIV3Schema:
        type: object
        properties:
          spec:
            type: object
            x-kubernetes-validations:
              - rule: "self['xyz'].foo > 0"
            additionalProperties:
              ...
              type: object
              properties:
                foo:
                  type: integer
    
  • Якщо правило обмежене масивом, елементи масиву доступні через self[i] та також за допомогою макросів і функцій.

      ...
      openAPIV3Schema:
        type: object
        properties:
          ...
          foo:
            type: array
            x-kubernetes-validations:
              - rule: "size(self) == 1"
            items:
              type: string
    
  • Якщо правило обмежене скаляром, self привʼязується до значення скаляра.

      ...
      openAPIV3Schema:
        type: object
        properties:
          spec:
            type: object
            properties:
              ...
              foo:
                type: integer
                x-kubernetes-validations:
                - rule: "self > 0"
    

Приклади:

тип поля, для якого обмежено правилоПриклад правила
кореневий обʼєктself.status.actual <= self.spec.maxDesired
map обʼєктівself.components['Widget'].priority < 10
список цілих чиселself.values.all(value, value >= 0 && value < 100)
рядокself.startsWith('kube')

apiVersion, kind, metadata.name та metadata.generateName завжди доступні з кореня обʼєкта та з будь-яких обʼєктів з анотацією x-kubernetes-embedded-resource. Інші властивості метаданих недоступні.

Невідомі дані, збережені у власниї ресурсах за допомогою x-kubernetes-preserve-unknown-fields, не доступні у виразах CEL. Це включає:

  • Невідомі значення полів, які зберігаються у схемах обʼєктів з x-kubernetes-preserve-unknown-fields.

  • Властивості обʼєктів, де схема властивостей має "unknown type". "Unknown type" визначається рекурсивно як:

    • Схема без типу і з встановленим x-kubernetes-preserve-unknown-fields
    • Масив, де схема елементів має "unknown type"
    • Обʼєкт, де схема additionalProperties має "unknown type"

Доступні лише назви властивостей форми [a-zA-Z_.-/][a-zA-Z0-9_.-/]*. Доступні назви властивостей екрануються за наступними правилами при доступі у виразі:

послідовність екрануванняеквівалент назви властивості
__underscores____
__dot__.
__dash__-
__slash__/
__{keyword}__CEL RESERVED keyword

Примітка: зарезервоване ключове слово CEL повинно точно збігатися з назвою властивості, щоб бути екранованим (наприклад, int у слові sprint не буде екрановано).

Приклади екранування:

назва властивостіправило з екранованою назвою властивості
namespaceself.__namespace__ > 0
x-propself.x__dash__prop > 0
redact__dself.redact__underscores__d > 0
stringself.startsWith('kube')

Рівність масивів з x-kubernetes-list-type типу set або map ігнорує порядок елементів, тобто [1, 2] == [2, 1]. Конкатенація масивів з x-kubernetes-list-type використовує семантику типу списку:

  • set: X + Y виконує обʼєднання, де зберігаються позиції елементів у X, а непересічні елементи у Y додаються, зберігаючи їх частковий порядок.

  • map: X + Y виконує злиття, де зберігаються позиції всіх ключів у X, але значення перезаписуються значеннями у Y, коли ключі X та Y перетинаються. Елементи у Y з непересічними ключами додаються, зберігаючи їх частковий порядок.

Ось відповідність типів між OpenAPIv3 та CEL:

Тип OpenAPIv3Тип CEL
'object' з Propertiesobject / "message type"
'object' з AdditionalPropertiesmap
'object' з x-kubernetes-embedded-typeobject / "message type", 'apiVersion', 'kind', 'metadata.name' та 'metadata.generateName' неявно включені у схему
'object' з x-kubernetes-preserve-unknown-fieldsobject / "message type", невідомі поля НЕ доступні у виразі CEL
x-kubernetes-int-or-stringдинамічний обʼєкт, який може бути або int, або string, type(value) можна використовувати для перевірки типу
'arraylist
'array' з x-kubernetes-list-type=maplist з порівнянням на основі map та гарантіями унікальності ключів
'array' з x-kubernetes-list-type=setlist з порівнянням на основі множини та гарантіями унікальності елементів
'boolean'boolean
'number' (всі формати)double
'integer' (всі формати)int (64)
'null'null_type
'string'string
'string' з format=byte (base64 encoded)bytes
'string' з format=datetimestamp (google.protobuf.Timestamp)
'string' з format=datetimetimestamp (google.protobuf.Timestamp)
'string' з format=durationduration (google.protobuf.Duration)

посилання: CEL types, OpenAPI types, Структурні схемм Kubernetes.

Поле messageExpression

Поле messageExpression, аналогічно до поля message, визначає рядок, яким буде повідомлено про негативний результат правила валідації. Однак messageExpression дозволяє використовувати вираз CEL для побудови повідомлення, що дозволяє вставляти більш описову інформацію в повідомлення про невдачу валідації. messageExpression має оцінюватися як рядок і може використовувати ті ж змінні, що і поле rule. Наприклад:

x-kubernetes-validations:
- rule: "self.x <= self.maxLimit"
  messageExpression: '"x перевищує максимальний ліміт " + string(self.maxLimit)'

Майте на увазі, що конкатенація рядків CEL (оператор +) автоматично не призводить до перетворення в рядок. Якщо у вас є скаляр, який не є рядком, використовуйте функцію string(<значення>) для перетворення скаляра в рядок, як показано в прикладі вище.

messageExpression повинен оцінюватися як рядок, і це перевіряється при створенні CRD. Зауважте, що можна встановити як message, так і messageExpression для одного правила, і якщо обидва присутні, буде використовуватися messageExpression. Однак, якщо messageExpression оцінюється як помилка, буде використовуватися рядок, визначений у message, і помилка messageExpression буде зафіксована. Це повернення до попереднього стану також відбудеться, якщо вираз CEL, визначений у messageExpression, генерує порожній рядок або рядок, що містить розриви рядків.

Якщо одна з вищезазначених умов виконується і message не було встановлено, то буде використовуватися стандартне повідомлення про негативний результат валідації.

messageExpression є виразом CEL, тому обмеження, зазначені в розділі Використання ресурсів функціями валідації, застосовуються. Якщо оцінка зупиняється через обмеження ресурсів під час виконання messageExpression, жодні подальші правила валідації не будуть виконуватися.

Встановлення messageExpression є необовʼязковим.

Поле message

Якщо ви хочете встановити статичне повідомлення, ви можете передати message замість messageExpression. Значення message використовується як непрозорий рядок помилки, якщо перевірка не пройшла успішно.

Встановлення message є необовʼязковим.

Поле reason

Ви можете додати машинно-читаєму причину негативного результату перевірки в межах validation, щоб повертати її, коли запит не відповідає цьому правилу перевірки.

Наприклад:

x-kubernetes-validations:
- rule: "self.x <= self.maxLimit"
  reason: "FieldValueInvalid"

Код стану HTTP, повернутий абоненту, буде відповідати причині першої невдачі перевірки. Наразі підтримуються такі причини: "FieldValueInvalid", "FieldValueForbidden", "FieldValueRequired", "FieldValueDuplicate". Якщо причини не встановлені або невідомі, типово використовується "FieldValueInvalid".

Встановлення reason є необовʼязковим.

Поле fieldPath

Ви можете вказати шлях поля, який повертається, коли перевірка завершується негативним результатом.

Наприклад:

x-kubernetes-validations:
- rule: "self.foo.test.x <= self.maxLimit"
  fieldPath: ".foo.test.x"

У вищенаведеному прикладі перевіряється значення поля x, яке повинно бути менше значення maxLimit. Якщо не вказано fieldPath, коли результат перевірки негативний , fieldPath буде типово відповідати місцю розташування self. З вказаним fieldPath повернена помилка буде мати fieldPath, який належним чином посилатиметься на місце поля x.

Значення fieldPath повинно бути відносним шляхом JSON, що обмежений місцем цього розширення x-kubernetes-validations у схемі. Крім того, воно повинно посилатися на існуюче поле в межах схеми. Наприклад, коли перевірка перевіряє, чи є певний атрибут foo у map testMap, ви можете встановити fieldPath на ".testMap.foo" або .testMap['foo']'. Якщо для перевірки потрібно перевірити унікальні атрибути у двох списках, fieldPath можна встановити для будь-якого зі списків. Наприклад, його можна встановити на .testList1 або .testList2. Наразі підтримується дочірня операція для посилання на існуюче поле. Для отримання додаткової інформації див. Підтримка JSONPath у Kubernetes. Поле fieldPath не підтримує індексування масивів числовими значеннями.

Встановлення fieldPath є необовʼязковим.

Поле optionalOldSelf

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.30 [beta]

Якщо у вашому кластері не включено проковзування перевірки CRD, API визначення власного ресурсу не містить цього поля, і спроба встановити його може призвести до помилки.

Поле optionalOldSelf є булевим полем, яке змінює поведінку Правил переходу, описаних нижче. Зазвичай правило переходу не оцінюється, якщо oldSelf не може бути визначено: під час створення обʼєкта або коли нове значення вводиться під час оновлення.

Якщо optionalOldSelf встановлено в true, тоді правила переходу завжди будуть оцінюватися, і тип oldSelf буде змінено на тип CEL Optional.

optionalOldSelf корисно в тих випадках, коли автори схеми хочуть мати більше інструментів керування ніж надається за стандартно на основі рівності, щоб ввести нові, зазвичай строгіші обмеження на нові значення, зазвичай більш жорсткі для нових значень, але все ще дозволяючи те, що старі значення можуть бути пропущені з використанням старих правил.

Example Usage:

CELОпис
self.foo == "foo" || (oldSelf.hasValue() && oldSelf.value().foo != "foo")Проковзування правила. Якщо значення має значення «foo», воно повинно залишатися foo. Але якщо воно існувало до того, як було введено обмеження «foo», воно може використовувати будь-яке значення
[oldSelf.orValue(""), self].all(x, ["OldCase1", "OldCase2"].exists(case, x == case)) || ["NewCase1", "NewCase2"].exists(case, self == case) || ["NewCase"].has(self)"Перевірка для вилучених випадків перерахування, якщо oldSelf використовував їх"
oldSelf.optMap(o, o.size()).orValue(0) < 4 || self.size() >= 4Перевірка нещодавно збільшеного мінімального розміру map або списку з проковзуванням

Функції перевірки

Доступні функції включають:

Правила переходу

Правило, яке містить вираз з посиланням на ідентифікатор oldSelf, неявно вважається правилом переходу. Правила переходу дозволяють авторам схеми запобігати певним переходам між двома в іншому випадку допустимими станами. Наприклад:

type: string
enum: ["low", "medium", "high"]
x-kubernetes-validations:
- rule: "!(self == 'high' && oldSelf == 'low') && !(self == 'low' && oldSelf == 'high')"
  message: не можна переходити безпосередньо між 'low' та 'high'

На відміну від інших правил, правила переходу застосовуються тільки до операцій, що відповідають наступним критеріям:

  • Операція оновлює існуючий обʼєкт. Правила переходу ніколи не застосовуються до операцій створення.

  • Існують як старе, так і нове значення. Залишається можливим перевірити, чи було додано або вилучено значення, розмістивши правило переходу на батьківському вузлі. Правила переходу ніколи не застосовуються до створення власних ресурсів. Якщо вони розміщені в необовʼязковому полі, правило переходу не буде застосовуватися до операцій оновлення, які встановлюють або прибирають поле.

  • Шлях до вузла схеми, який перевіряється правилом переходу, повинен розподілятися на вузол, який може порівнюватися між старим обʼєктом і новим обʼєктом. Наприклад, елементи списку та їх нащадки (spec.foo[10].bar) не обовʼязково будуть кореліювати між існуючим обʼєктом та пізнішим оновленням того ж обʼєкта.

Помилки будуть генеруватися при записі CRD, якщо вузол схеми містить правило переходу, яке ніколи не може бути застосоване, наприклад "oldSelf не може бути використано на некорельованій частині схеми у межах path".

Правила переходу дозволені тільки для корелятивних частин схеми. Частина схеми є корелятивною, якщо всі батьківські схеми масиву мають тип x-kubernetes-list-type=map; будь-які батьківські схеми масиву типу set чи atomic роблять неможливим однозначне корелювання між self та oldSelf.

Нижче наведено кілька прикладів правил переходу:

Приклади правил переходу
ВикористанняПравило
Незмінністьself.foo == oldSelf.foo
Запобігання модифікації/видаленню після присвоєнняoldSelf != 'bar' || self == 'bar' або !has(oldSelf.field) || has(self.field)
Тільки додавання до множиниself.all(element, element in oldSelf)
Якщо попереднє значення було X, нове значення може бути лише A або B, не Y або ZoldSelf != 'X' || self in ['A', 'B']
Монотонні (незменшувані) лічільникиself >= oldSelf

Використання ресурсів функціями перевірки

Коли ви створюєте або оновлюєте CustomResourceDefinition, що використовує правила перевірки, API сервер перевіряє можливий вплив виконання цих правил перевірки. Якщо правило оцінюється як надмірно витратне у виконанні, API сервер відхиляє операцію створення або оновлення та повертає повідомлення про помилку. Подібна система використовується під час виконання, яка спостерігає за діями інтерпретатора. Якщо інтерпретатор виконує занадто багато інструкцій, виконання правила буде припинено, і виникне помилка. Кожен CustomResourceDefinition також має певний ліміт ресурсів для завершення виконання всіх своїх правил перевірки. Якщо сумарна оцінка всіх правил перевищує цей ліміт під час створення, то також виникне помилка перевірки.

Ймовірність виникнення проблем з ресурсним бюджетом перевірки низька, якщо ви лише зазначаєте правила, які завжди займають однакову кількість часу незалежно від розміру вхідних даних. Наприклад, правило, яке стверджує, що self.foo == 1, само по собі не має ризику відхилення через ресурсний бюджет перевірки. Але якщо foo є рядком і ви визначаєте правило перевірки self.foo.contains("someString"), то це правило займає довше часу на виконання в залежності від довжини foo. Інший приклад: якщо foo є масивом, і ви вказали правило перевірки self.foo.all(x, x > 5). Система оцінки завжди припускає найгірший сценарій, якщо не вказано ліміт на довжину foo, і це буде стосуватися будь-якого обʼєкта, який можна ітерувати (списки, мапи тощо).

Через це, вважається найкращою практикою встановлювати ліміт через maxItems, maxProperties і maxLength для будь-якого обʼєкта, який обробляється в правилі перевірки, щоб уникнути помилок перевірки під час оцінки витрат. Наприклад, якщо є наступна схема з одним правилом:

openAPIV3Schema:
  type: object
  properties:
    foo:
      type: array
      items:
        type: string
      x-kubernetes-validations:
        - rule: "self.all(x, x.contains('a string'))"

то API сервер відхилить це правило через бюджет перевірки з помилкою:

spec.validation.openAPIV3Schema.properties[spec].properties[foo].x-kubernetes-validations[0].rule: Forbidden:
CEL rule exceeded budget by more than 100x (try simplifying the rule, or adding maxItems, maxProperties, and
maxLength where arrays, maps, and strings are used)

Відхилення відбувається тому, що self.all передбачає виклик contains() для кожного рядка у foo, що в свою чергу перевіряє, чи містить даний рядок 'a string'. Без обмежень, це дуже витратне правило.

Якщо ви не вказуєте жодного ліміту перевірки, оцінена вартість цього правила перевищить ліміт вартості для одного правила. Але якщо додати обмеження в потрібні місця, правило буде дозволено:

openAPIV3Schema:
  type: object
  properties:
    foo:
      type: array
      maxItems: 25
      items:
        type: string
        maxLength: 10
      x-kubernetes-validations:
        - rule: "self.all(x, x.contains('a string'))"

Система оцінки витрат враховує кількість разів, коли правило буде виконане, крім оціненої вартості самого правила. Наприклад, наступне правило матиме таку ж оцінену вартість, як і попередній приклад (незважаючи на те, що правило тепер визначено для окремих елементів масиву):

openAPIV3Schema:
  type: object
  properties:
    foo:
      type: array
      maxItems: 25
      items:
        type: string
        x-kubernetes-validations:
          - rule: "self.contains('a string'))"
        maxLength: 10

Якщо у списку всередині іншого списку є правило перевірки, яке використовує self.all, це значно дорожче, ніж правило для не вкладеного списку. Правило, яке було б дозволено для не вкладеного списку, може потребувати нижчих обмежень для обох вкладених списків, щоб бути дозволеним. Наприклад, навіть без встановлення обмежень, наступне правило дозволено:

openAPIV3Schema:
  type: object
  properties:
    foo:
      type: array
      items:
        type: integer
    x-kubernetes-validations:
      - rule: "self.all(x, x == 5)"

Але те саме правило для наступної схеми (з доданим вкладеним масивом) викликає помилку перевірки:

openAPIV3Schema:
  type: object
  properties:
    foo:
      type: array
      items:
        type: array
        items:
          type: integer
        x-kubernetes-validations:
          - rule: "self.all(x, x == 5)"

Це тому, що кожен елемент foo сам є масивом, і кожен підмасив викликає self.all. Уникайте вкладених списків і map, якщо це можливо, де використовуються правила перевірки.

Встановлення станадартних значень

Встановлення стандартних значень дозволяє вказати такі значення у схемі перевірки OpenAPI v3:

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: crontabs.stable.example.com
spec:
  group: stable.example.com
  versions:
    - name: v1
      served: true
      storage: true
      schema:
        # openAPIV3Schema це схема для перевірки власних обʼєктів.
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                cronSpec:
                  type: string
                  pattern: '^(\d+|\*)(/\d+)?(\s+(\d+|\*)(/\д+)?){4}$'
                  default: "5 0 * * *"
                image:
                  type: string
                replicas:
                  type: integer
                  minimum: 1
                  maximum: 10
                  default: 1
  scope: Namespaced
  names:
    plural: crontabs
    singular: crontab
    kind: CronTab
    shortNames:
    - ct

Таким чином, і cronSpec, і replicas будуть мати стандартні значення:

apiVersion: "stable.example.com/v1"
kind: CronTab
metadata:
  name: my-new-cron-object
spec:
  image: my-awesome-cron-image

приводить до

apiVersion: "stable.example.com/v1"
kind: CronTab
metadata:
  name: my-new-cron-object
spec:
  cronSpec: "5 0 * * *"
  image: my-awesome-cron-image
  replicas: 1

Встановлення стандартних значень відбувається на обʼєкті

  • в запиті до API сервера з використанням стандартних значень версії запиту,
  • під час читання з etcd з використанням стандартних значень версії зберігання,
  • після втулків для мутаційного допуску з невипадковими змінами з використанням стандартних значень версії веб-хука допуску.

Стандартне значення, застосовані під час читання даних з etcd, автоматично не записуються назад у etcd. Потрібен запит на оновлення через API для збереження цих стандартних значень у etcd.

Стандартні значення мають бути обрізані (за винятком стандартних значень полів metadata) та відповідати схемі перевірки.

Стандартні значення полів metadata вузлів x-kubernetes-embedded-resources: true (або частин типових значень з metadata) не будуть обрізані під час створення CustomResourceDefinition, але будуть обрізані під час оброки запитів.

Стандартні значення та nullable

Значення null для полів, які або не вказують прапорець nullable, або задають його значення як false, будуть видалені до того, як буде застосовано стандартне значення. Якщо стандартне значення присутнє, воно буде застосоване. Коли nullable дорівнює true, значення null будуть збережені і не будуть змінені на стандартні значення.

Наприклад, розглянемо наступну схему OpenAPI:

type: object
properties:
  spec:
    type: object
    properties:
      foo:
        type: string
        nullable: false
        default: "default"
      bar:
        type: string
        nullable: true
      baz:
        type: string

створення обʼєкта зі значеннями null для foo, bar і baz:

spec:
  foo: null
  bar: null
  baz: null

призведе до

spec:
  foo: "default"
  bar: null

де foo буде обрізане та встановлене стандартне значення, оскільки поле є ненульовим, bar залишиться зі значенням null через nullable: true, а baz буде видалено, оскільки поле є ненульовим і не має стандартного значення.

Публікація схеми валідації в OpenAPI

Схеми валідації OpenAPI v3 CustomResourceDefinition, які є структурованими та дозволяють обрізку, публікуються як OpenAPI v3 та OpenAPI v2 з сервера API Kubernetes. Рекомендується використовувати документ OpenAPI v3, оскільки він є представленням схеми валідації OpenAPI v3 для CustomResourceDefinition без втрат, тоді як OpenAPI v2 представляє перетворення з втратами.

Kubectl використовує опубліковану схему для виконання клієнтської валідації (kubectl create та kubectl apply), пояснення схеми (kubectl explain) для власних ресурсів. Опублікована схема також може бути використана для інших цілей, таких як генерація клієнтів або документації.

Сумісність з OpenAPI V2

Для сумісності з OpenAPI V2, схема валідації OpenAPI v3 виконує перетворення з втратамиу схему OpenAPI v2. Схема зʼявляється в полях definitions та paths у специфікації OpenAPI v2.

Під час перетворення застосовуються наступні зміни для збереження зворотної сумісності з kubectl версії 1.13. Ці зміни запобігають занадто строгій роботі kubectl та відхиленню дійсних схем OpenAPI, які він не розуміє. Перетворення не змінює схему валідації, визначену в CRD, і тому не впливає на валідацію на сервері API.

  1. Наступні поля видаляються, оскільки вони не підтримуються OpenAPI v2:

    • Поля allOf, anyOf, oneOf та not видаляються
  2. Якщо встановлено nullable: true, ми видаляємо type, nullable, items та properties, оскільки OpenAPI v2 не може відобразити nullable. Це необхідно для того, щоб kubectl не відхиляв правильні обʼєкти.

Додаткові колонки виводу

Інструмент kubectl покладається на форматування виводу на стороні сервера. Сервер API вашого кластера вирішує, які колонки показуються командою kubectl get. Ви можете налаштувати ці колонки для CustomResourceDefinition. Наступний приклад додає колонки Spec, Replicas та Age.

Збережіть CustomResourceDefinition у файл resourcedefinition.yaml:

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: crontabs.stable.example.com
spec:
  group: stable.example.com
  scope: Namespaced
  names:
    plural: crontabs
    singular: crontab
    kind: CronTab
    shortNames:
    - ct
  versions:
  - name: v1
    served: true
    storage: true
    schema:
      openAPIV3Schema:
        type: object
        properties:
          spec:
            type: object
            properties:
              cronSpec:
                type: string
              image:
                type: string
              replicas:
                type: integer
    additionalPrinterColumns:
    - name: Spec
      type: string
      description: The cron spec defining the interval a CronJob is run
      jsonPath: .spec.cronSpec
    - name: Replicas
      type: integer
      description: The number of jobs launched by the CronJob
      jsonPath: .spec.replicas
    - name: Age
      type: date
      jsonPath: .metadata.creationTimestamp

Створіть CustomResourceDefinition:

kubectl apply -f resourcedefinition.yaml

Створіть екземпляр, використовуючи my-crontab.yaml з попереднього розділу.

Викличте вивід на стороні сервера:

kubectl get crontab my-new-cron-object

Зверніть увагу на колонки NAME, SPEC, REPLICAS та AGE у виводі:

NAME                 SPEC        REPLICAS   AGE
my-new-cron-object   * * * * *   1          7s

Пріоритет

Кожна колонка включає поле priority. Наразі пріоритет розрізняє стовпці, що показуються у стандартному вигляді або в розгорнутому (за допомогою прапорця -o wide).

  • Колонки з пріоритетом 0 показані у стандартному вигляді.
  • Колонки з пріоритетом більшим за 0 показані тільки у широкому (wide) вигляді.

Тип

Поле type колонки може бути одним з наступних (порівняйте OpenAPI v3 data types):

  • integer — цілі числа без плаваючої точки
  • number — числа з плаваючою точкою
  • string — строки
  • boolean — true або false
  • date — виводиться диференційовано як час, що минув від цієї мітки.

Якщо значення всередині CustomResource не відповідає типу, зазначеному для колонки, значення буде пропущено. Використовуйте валідацію CustomResource, щоб переконатися, що типи значень правильні.

Формат

Поле format колонки може бути одним з наступних:

  • int32
  • int64
  • float
  • double
  • byte
  • date
  • date-time
  • password

Поле format колонки контролює стиль, який використовується при виводі значення за допомогою kubectl.

Селектори полів

Селектори полів дозволяють клієнтам вибирати власні ресурси на основі значення одного або декількох полів ресурсу.

Усі власні ресурси підтримують вибір полів metadata.name та metadata.namespace.

Поля, оголошені в CustomResourceDefinition, також можуть бути використані з селектором полів, коли вони включені в поле spec.versions[*].selectableFields CustomResourceDefinition.

Поля селекторів власних ресурсів

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.31 [beta]

Для Kubernetes 1.31 можливість визначати селектори полів для власних ресурсів доступна стандартно (стандартно увімкнена з Kubernetes v1.31); ви можете вимкнути цю функцію для вашого кластера, відключивши функціональну можливість CustomResourceFieldSelectors. Поле spec.versions[*].selectableFields у CustomResourceDefinition може бути використане для оголошення, які інші поля у власному ресурсі можуть бути використані у селекторах полів з функціональною можливісюь CustomResourceFieldSelectors (Ця функція є стандартно увімкненою з Kubernetes v1.31). Ось приклад, який додає поля .spec.color та .spec.size як доступні для вибору.

Збережіть CustomResourceDefinition у файл shirt-resource-definition.yaml:

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: shirts.stable.example.com
spec:
  group: stable.example.com
  scope: Namespaced
  names:
    plural: shirts
    singular: shirt
    kind: Shirt
  versions:
  - name: v1
    served: true
    storage: true
    schema:
      openAPIV3Schema:
        type: object
        properties:
          spec:
            type: object
            properties:
              color:
                type: string
              size:
                type: string
    selectableFields:
    - jsonPath: .spec.color
    - jsonPath: .spec.size
    additionalPrinterColumns:
    - jsonPath: .spec.color
      name: Color
      type: string
    - jsonPath: .spec.size
      name: Size
      type: string

Створіть CustomResourceDefinition:

kubectl apply -f shirt-resource-definition.yaml

Визначте деякі сорочки (Shirts), редагуючи файл shirt-resources.yaml; наприклад:

---
apiVersion: stable.example.com/v1
kind: Shirt
metadata:
  name: example1
spec:
  color: blue
  size: S
---
apiVersion: stable.example.com/v1
kind: Shirt
metadata:
  name: example2
spec:
  color: blue
  size: M
---
apiVersion: stable.example.com/v1
kind: Shirt
metadata:
  name: example3
spec:
  color: green
  size: M

Створіть власні ресурси:

kubectl apply -f shirt-resources.yaml

Отримайте всі ресурси:

kubectl get shirts.stable.example.com

Вивід буде:

NAME       COLOR  SIZE
example1   blue   S
example2   blue   M
example3   green  M

Отримайте сорочки синього кольору (отримайте сорочки у яких color має значення blue):

kubectl get shirts.stable.example.com --field-selector spec.color=blue

Повинен зʼявитися такий вивід:

NAME       COLOR  SIZE
example1   blue   S
example2   blue   M

Отримайте лише ресурси з кольором green та розміром M:

kubectl get shirts.stable.example.com --field-selector spec.color=green,spec.size=M

Повинен зʼявитися такий вивід:

NAME       COLOR  SIZE
example2   blue   M

Субресурси

Власні ресурси підтримують субресурси /status та /scale.

Субресурси status та scale можна опціонально увімкнути, визначивши їх у CustomResourceDefinition.

Субресурс Status

Коли субресурс статусу увімкнено, субресурс /status для власного ресурсу буде доступним.

  • Стани status та spec представлені відповідно за допомогою JSONPath .status та .spec всередині власного ресурсу.

  • Запити PUT до субресурсу /status приймають обʼєкт власного ресурсу і ігнорують зміни до будь-чого, крім стану status.

  • Запити PUT до субресурсу /status лише перевіряють стан status власного ресурсу.

  • Запити PUT/POST/PATCH до власного ресурсу ігнорують зміни до стану status.

  • Значення .metadata.generation збільшується для всіх змін, за винятком змін у .metadata або .status.

  • У корені схеми валідації OpenAPI CRD дозволяються тільки такі конструкції:

    • description
    • example
    • exclusiveMaximum
    • exclusiveMinimum
    • externalDocs
    • format
    • items
    • maximum
    • maxItems
    • maxLength
    • minimum
    • minItems
    • minLength
    • multipleOf
    • pattern
    • properties
    • required
    • title
    • type
    • uniqueItems

Субресурс Scale

Коли субресурс масштабу увімкнено, субресурс /scale для власного ресурсу буде доступним. Обʼєкт autoscaling/v1.Scale надсилається як навантаження для /scale.

Для увімкнення субресурсу масштабу наступні поля визначаються в CustomResourceDefinition.

  • specReplicasPath визначає JSONPath всередині власного ресурсу, що відповідає scale.spec.replicas.

    • Це обовʼязкове значення.
    • Дозволяються тільки JSONPath під .spec і з позначенням через крапку.
    • Якщо у власному ресурсі немає значення під specReplicasPath, субресурс /scale поверне помилку при GET запиті.
  • statusReplicasPath визначає JSONPath всередині власного ресурсу, що відповідає scale.status.replicas.

    • Це обовʼязкове значення.
    • Дозволяються тільки JSONPath під .status і з позначенням через крапку.
    • Якщо у власному ресурсі немає значення під statusReplicasPath, значення репліки статусу у субресурсі /scale за замовчуванням дорівнюватиме 0.
  • labelSelectorPath визначає JSONPath всередині власного ресурсу, що відповідає Scale.Status.Selector.

    • Це необовʼязкове значення.
    • Воно повинно бути встановлено для роботи з HPA та VPA.
    • Дозволяються тільки JSONPath під .status або .spec і з позначенням через крапку.
    • Якщо у власному ресурсі немає значення під labelSelectorPath, значення селектора статусу у субресурсі /scale за замовчуванням буде порожнім рядком.
    • Поле, на яке вказує цей JSONPath, повинно бути рядковим полем (не комплексним селектором), що містить серіалізований селектор міток у вигляді рядка.

У наступному прикладі увімкнено обидва субресурси: статусу та масштабу.

Збережіть CustomResourceDefinition у файл resourcedefinition.yaml:

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: crontabs.stable.example.com
spec:
  group: stable.example.com
  versions:
    - name: v1
      served: true
      storage: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                cronSpec:
                  type: string
                image:
                  type: string
                replicas:
                  type: integer
            status:
              type: object
              properties:
                replicas:
                  type: integer
                labelSelector:
                  type: string
      # subresources описує субресурси для власних ресурсів.
      subresources:
        # status увімкнення субресурсу статусу.
        status: {}
        # scale увімкнення субресурсу масштабу.
        scale:
          # specReplicasPath визначає JSONPath всередині власного ресурсу, що відповідає Scale.Spec.Replicas.
          specReplicasPath: .spec.replicas
          # statusReplicasPath визначає JSONPath всередині власного ресурсу, що відповідає Scale.Status.Replicas.
          statusReplicasPath: .status.replicas
          # labelSelectorPath визначає JSONPath всередині власного ресурсу, що відповідає Scale.Status.Selector.
          labelSelectorPath: .status.labelSelector
  scope: Namespaced
  names:
    plural: crontabs
    singular: crontab
    kind: CronTab
    shortNames:
    - ct

І створіть його:

kubectl apply -f resourcedefinition.yaml

Після створення обʼєкта CustomResourceDefinition, ви можете створювати власні обʼєкти.

Якщо ви збережете наступний YAML у файл my-crontab.yaml:

apiVersion: "stable.example.com/v1"
kind: CronTab
metadata:
  name: my-new-cron-object
spec:
  cronSpec: "* * * * */5"
  image: my-awesome-cron-image
  replicas: 3

і створите його:

kubectl apply -f my-crontab.yaml

Тоді будуть створені нові RESTful API точки доступу на рівні простору імен:

/apis/stable.example.com/v1/namespaces/*/crontabs/status

та

/apis/stable.example.com/v1/namespaces/*/crontabs/scale

Власний ресурс можна масштабувати за допомогою команди kubectl scale. Наприклад, наступна команда встановлює .spec.replicas власного ресурсу, створеного вище, до 5:

kubectl scale --replicas=5 crontabs/my-new-cron-object
crontabs "my-new-cron-object" scaled

kubectl get crontabs my-new-cron-object -o jsonpath='{.spec.replicas}'
5

Ви можете використовувати PodDisruptionBudget, щоб захистити власні ресурси, які мають увімкнений субресурс масштабу.

Категорії

Категорії — це список групованих ресурсів, до яких належить власний ресурс (наприклад, all). Ви можете використовувати kubectl get <category-name>, щоб вивести список ресурсів, що належать до категорії.

Наступний приклад додає all у список категорій у CustomResourceDefinition та ілюструє, як вивести власний ресурс за допомогою kubectl get all.

Збережіть наступний CustomResourceDefinition у файл resourcedefinition.yaml:

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: crontabs.stable.example.com
spec:
  group: stable.example.com
  versions:
    - name: v1
      served: true
      storage: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                cronSpec:
                  type: string
                image:
                  type: string
                replicas:
                  type: integer
  scope: Namespaced
  names:
    plural: crontabs
    singular: crontab
    kind: CronTab
    shortNames:
    - ct
    # categories - це список групованих ресурсів, до яких належить власний ресурс.
    categories:
    - all

і створіть його:

kubectl apply -f resourcedefinition.yaml

Після створення обʼєкта CustomResourceDefinition, ви можете створювати власні обʼєкти.

Збережіть наступний YAML у файл

my-crontab.yaml:

apiVersion: "stable.example.com/v1"
kind: CronTab
metadata:
  name: my-new-cron-object
spec:
  cronSpec: "* * * * */5"
  image: my-awesome-cron-image

і створіть його:

kubectl apply -f my-crontab.yaml

Ви можете вказати категорію при використанні kubectl get:

kubectl get all

і це включатиме власні ресурси типу CronTab:

NAME                          AGE
crontabs/my-new-cron-object   3s

Що далі

4.11.1.2 - Версії у CustomResourceDefinitions

Ця сторінка пояснює, як додати інформацію про версії до CustomResourceDefinitions, щоб вказати рівень стабільності ваших CustomResourceDefinitions або перейти на нову версію з конвертацією між представленнями API. Також описується, як оновити обʼєкт з однієї версії до іншої.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Ви вже повинні розуміти що таке власні ресурси.

Версія вашого Kubernetes сервера має бути не старішою ніж v1.16. Для перевірки версії введіть kubectl version.

Огляд

API CustomResourceDefinition надає робочий процес для впровадження та оновлення нових версій CustomResourceDefinition.

Коли створюється CustomResourceDefinition, перша версія встановлюється в списку spec.versions CustomResourceDefinition на відповідний рівень стабільності та номер версії. Наприклад, v1beta1 буде вказувати, що перша версія ще не стабільна. Всі обʼєкти власних ресурсів спочатку будуть зберігатися в цій версії.

Після створення CustomResourceDefinition, клієнти можуть почати використовувати API v1beta1.

Пізніше може знадобитися додати нову версію, наприклад v1.

Додавання нової версії:

  1. Виберіть стратегію конвертації. Оскільки обʼєкти власних ресурсів повинні мати можливість обслуговуватися в обох версіях, це означає, що вони іноді будуть обслуговуватися у версії, відмінній від тієї, в якій зберігаються. Для цього іноді потрібно конвертувати обʼєкти власних ресурсів між версією, в якій вони зберігаються, та версією, в якій вони обслуговуються. Якщо конвертація передбачає зміни схеми та вимагає власної логіки, слід використовувати конвертаційний webhook. Якщо змін схеми немає, можна використовувати стратегію конвертації None, і при обслуговуванні різних версій буде змінено лише поле apiVersion.
  2. Якщо використовуються конвертаційні webhook'и, створіть і розгорніть конвертаційний webhook. Див. Конвертація через webhook для отримання більш детальної інформації.
  3. Оновіть CustomResourceDefinition, включивши нову версію в список spec.versions з served:true. Також встановіть поле spec.conversion на вибрану стратегію конвертації. Якщо використовується конвертаційний webhook, налаштуйте поле spec.conversion.webhookClientConfig для виклику webhook.

Після додавання нової версії клієнти можуть поступово перейти на нову версію. Цілком безпечно для деяких клієнтів використовувати стару версію, тоді як інші використовують нову версію.

Міграція збережених обʼєктів до нової версії:

  1. Див. розділ оновлення наявних обʼєктів до нової збереженої версії.

Клієнти можуть безпечно використовувати як стару, так і нову версію до, під час і після оновлення обʼєктів до нової збереженої версії.

Видалення старої версії:

  1. Переконайтеся, що всі клієнти повністю перейшли на нову версію. Логи kube-apiserver можна переглянути для виявлення клієнтів, які все ще використовують стару версію.
  2. Встановіть served на false для старої версії в списку spec.versions. Якщо якісь клієнти все ще несподівано використовують стару версію, вони можуть почати повідомляти про помилки при спробі доступу до обʼєктів власних ресурсів у старій версії. У такому випадку поверніться до використання served:true на старій версії, мігруйте залишкових клієнтів на нову версію та повторіть цей крок.
  3. Переконайтеся, що крок оновлення поточних обʼєктів до нової збереженої версії завершено.
    1. Перевірте, що storage встановлено на true для нової версії в списку spec.versions в CustomResourceDefinition.
    2. Перевірте, що стара версія більше не згадується в status.storedVersions CustomResourceDefinition.
  4. Видаліть стару версію зі списку spec.versions CustomResourceDefinition.
  5. Припиніть підтримку конвертації для старої версії в конвертаційних webhook'ах.

Зазначення кількох версій

Поле versions в CustomResourceDefinition API може бути використане для підтримки кількох версій розроблених вами власних ресурсів. Версії можуть мати різні схеми, а конвертаційні webhook'и можуть конвертувати власні ресурси між версіями. Конвертації через webhook повинні дотримуватися конвенцій Kubernetes API в тих випадках, де це застосовується. Зокрема, дивіться документацію по змінах API для набору корисних порад та рекомендацій.

У цьому прикладі показано CustomResourceDefinition з двома версіями. У першому прикладі припускається, що всі версії мають однакову схему без конвертації між ними. У YAML-файлах наведено коментарі, які надають додатковий контекст.

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  # назва повинна відповідати полям spec нижче, і бути у формі: <plural>.<group>
  name: crontabs.example.com
spec:
  # імʼя групи, яке буде використовуватися для REST API: /apis/<group>/<version>
  group: example.com
  # список версій, підтримуваних цим CustomResourceDefinition
  versions:
  - name: v1beta1
    # Кожна версія може бути увімкнена/вимкнена прапорцем Served.
    served: true
    # Лише одна версія повинна бути позначена як версія зберігання.
    storage: true
    # Схема обовʼязкова
    schema:
      openAPIV3Schema:
        type: object
        properties:
          host:
            type: string
          port:
            type: string
  - name: v1
    served: true
    storage: false
    schema:
      openAPIV3Schema:
        type: object
        properties:
          host:
            type: string
          port:
            type: string
  # Секція конвертації була введена в Kubernetes 1.13+ зі стандартним значенням
  # конвертації None (стратегії встановленя субполів None).
  conversion:
    # Конвертація None передбачає ту ж саму схему для всіх версій, і лише встановлює apiVersion
    # поле власних ресрів у відповідне значення
    strategy: None
  # або Namespaced або Cluster
  scope: Namespaced
  names:
    # plural, назва ресрусу в що використовується в URL: /apis/<group>/<version>/<plural>
    plural: crontabs
    # singular, назва ресурсу в що буде використовуватись як аліас в CLI та у виводі
    singular: crontab
    # kind, зазвичай тип в однині в CamelCase. Ваші маніфести будуть використовувати це.
    kind: CronTab
    # shortNames, дозволяють коротше звертатися до ресурсу в CLI
    shortNames:
    - ct

# Застаріло у версії v1.16 на користь apiextensions.k8s.io/v1
apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  # імʼя має збігатися з полями spec нижче і бути у формі: <plural>.<group>
  name: crontabs.example.com
spec:
  # імʼя групи для використання в REST API: /apis/<group>/<version>
  group: example.com
  # список версій, які підтримуються цим CustomResourceDefinition
  versions:
  - name: v1beta1
    # Кожна версія може бути увімкненна/вимкнена за допомогою прапорця Served.
    served: true
    # Лише одна версія повинна бути позначена як версія зберігання.
    storage: true
  - name: v1
    served: true
    storage: false
  validation:
    openAPIV3Schema:
      type: object
      properties:
        host:
          type: string
        port:
          type: string
  # Розділ конвертації введений у Kubernetes 1.13+ зі стандартним значенням конвертації
  # None (підполе strategy встановлено на None).
  conversion:
    # None конфертація передбачає однакову схему для всіх версій і лише встановлює поле apiVersion
    # власних ресурсів у правильне значення
    strategy: None
  # або Namespaced, або Cluster
  scope: Namespaced
  names:
    # plural, назва ресрусу в що використовується в URL: /apis/<group>/<version>/<plural>
    plural: crontabs
    # singular, назва ресурсу в що буде використовуватись як аліас в CLI та у виводі
    singular: crontab
    # kind, зазвичай тип в однині в PascalCased. Ваші маніфести будуть використовувати це.
    kind: CronTab
    # shortNames, дозволяють коротше звертатися до ресурсу в CLI
    shortNames:
    - ct

Ви можете зберегти CustomResourceDefinition у YAML-файлі, а потім використати kubectl apply, щоб створити його.

kubectl apply -f my-versioned-crontab.yaml

Після створення API-сервер починає обслуговувати кожну включену версію за HTTP REST-точкою доступу. У наведеному вище прикладі, версії API доступні за адресами /apis/example.com/v1beta1 та /apis/example.com/v1.

Пріоритет версії

Незалежно від порядку, в якому версії визначені в CustomResourceDefinition, версія з найвищим пріоритетом використовується kubectl як стандартна версія для доступу до обʼєктів. Пріоритет визначається шляхом аналізу поля name для визначення номера версії, стабільності (GA, Beta або Alpha) та послідовності в межах цього рівня стабільності.

Алгоритм, який використовується для сортування версій, розроблений для сортування версій таким же чином, як проєкт Kubernetes сортує версії Kubernetes. Версії починаються з v, за яким слідує число, опціональне позначення beta або alpha, та опціональна додаткова числова інформація про версію. В загальному вигляді рядок версії може виглядати як v2 або v2beta1. Версії сортуються за таким алгоритмом:

  • Записи, що відповідають шаблонам версій Kubernetes, сортуються перед тими, що не відповідають шаблонам.
  • Для записів, що відповідають шаблонам версій Kubernetes, числові частини рядка версії сортуються від більшого до меншого.
  • Якщо після першої числової частини йдуть рядки beta або alpha, вони сортуються в такому порядку після еквівалентного рядка без суфікса beta або alpha (який вважається GA версією).
  • Якщо після beta або alpha йде ще одне число, ці числа також сортуються від більшого до меншого.
  • Рядки, що не відповідають зазначеному формату, сортуються за алфавітом, і числові частини не мають спеціального порядку. Зауважте, що в наведеному нижче прикладі foo1 сортується вище за foo10. Це відрізняється від сортування числових частин записів, що відповідають шаблонам версій Kubernetes.

Це може бути зрозуміло, якщо подивитися на наступний відсортований список версій:

- v10
- v2
- v1
- v11beta2
- v10beta3
- v3beta1
- v12alpha1
- v11alpha2
- foo1
- foo10

Для прикладу у розділі Зазначення кількох версій, порядок сортування версій — v1, за яким слідує v1beta1. Це змушує команду kubectl використовувати v1 як стандартну версію, якщо у наданому обʼєкті не вказано версію.

Застарівання версій

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.19 [stable]

Починаючи з версії v1.19, CustomResourceDefinition може вказувати, що певна версія ресурсу, який він визначає, є застарілою. Коли API-запити до застарілої версії цього ресурсу здійснюються, у відповідь API повертається попереджувальне повідомлення в заголовку. Попереджувальне повідомлення для кожної застарілої версії ресурсу можна налаштувати за бажанням.

Налаштоване попереджувальне повідомлення повинно вказувати застарілу API-групу, версію та тип (kind), і, якщо це можливо, вказувати, яку API-групу, версію та тип слід використовувати замість цього.

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
  name: crontabs.example.com
spec:
  group: example.com
  names:
    plural: crontabs
    singular: crontab
    kind: CronTab
  scope: Namespaced
  versions:
  - name: v1alpha1
    served: true
    storage: false
    # Це вказує, що версія v1alpha1 власного ресурсу є застарілою.
    # API-запити до цієї версії отримують попереджувальний заголовок у відповіді сервера.
    deprecated: true
    # Це перевизначає стандартне попереджувальне повідомлення, яке повертається клієнтам API, що здійснюють запити до v1alpha1.
    deprecationWarning: "example.com/v1alpha1 CronTab застарілий; див. http://example.com/v1alpha1-v1 для інструкцій щодо переходу на example.com/v1 CronTab"

    schema: ...
  - name: v1beta1
    served: true
    # Це вказує, що версія v1beta1 власного ресурсу є застарілою.
    # API-запити до цієї версії отримують попереджувальний заголовок у відповіді сервера.
    # Стандартне попереджувальне повідомлення повертається для цієї версії.
    deprecated: true
    schema: ...
  - name: v1
    served: true
    storage: true
    schema: ...

# Застаріло у v1.16 на користь apiextensions.k8s.io/v1
apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  name: crontabs.example.com
spec:
  group: example.com
  names:
    plural: crontabs
    singular: crontab
    kind: CronTab
  scope: Namespaced
  validation: ...
  versions:
  - name: v1alpha1
    served: true
    storage: false
    # Це вказує, що версія v1alpha1 власного ресурсу є застарілою.
    # API-запити до цієї версії отримують попереджувальний заголовок у відповіді сервера.
    deprecated: true
    # Це перевизначає стандартне попереджувальне повідомлення, яке повертається клієнтам API, що здійснюють запити до v1alpha1.
    deprecationWarning: "example.com/v1alpha1 CronTab застарілий; див. http://example.com/v1alpha1-v1 для інструкцій щодо переходу на example.com/v1 CronTab"
  - name: v1beta1
    served: true
    # Це вказує, що версія v1beta1 власного ресурсу є застарілою.
    # API-запити до цієї версії отримують попереджувальний заголовок у відповіді сервера.
    # Стандартне попереджувальне повідомлення повертається для цієї версії.
    deprecated: true
  - name: v1
    served: true
    storage: true

Видалення версії

Стара версія API не може бути видалена з маніфесту CustomResourceDefinition, доки наявні збережені дані не будуть мігровані до новішої версії API для всіх кластерів, які обслуговували стару версію власного ресурсу, та поки стара версія не буде видалена зі списку status.storedVersions у CustomResourceDefinition.

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
  name: crontabs.example.com
spec:
  group: example.com
  names:
    plural: crontabs
    singular: crontab
    kind: CronTab
  scope: Namespaced
  versions:
  - name: v1beta1
    # Це вказує, що версія v1beta1 власного ресурсу більше не обслуговується.
    # API-запити до цієї версії отримують помилку "не знайдено" у відповіді сервера.
    served: false
    schema: ...
  - name: v1
    served: true
    # Нова версія, що обслуговується повинна бути встановлена як версія зберігання
    storage: true
    schema: ...

Конвертація за допомогою вебхука

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.16 [stable]

Наведений вище приклад має None-конвертацію між версіями, яка лише встановлює поле apiVersion під час конвертації та не змінює решту обʼєкта. API-сервер також підтримує конвертації за допомогою вебхука, які викликають зовнішній сервіс у випадку, коли потрібна конвертація. Наприклад, коли:

  • власний ресурс запитується у версії, яка відрізняється від збереженої версії.
  • створюється спостереження (Watch) в одній версії, але змінений обʼєкт зберігається в іншій версії.
  • запит на PUT для власного ресурсу здійснюється в іншій версії, ніж версія зберігання.

Щоб охопити всі ці випадки та оптимізувати конвертацію за допомогою API-сервера, запити на конвертацію можуть містити кілька обʼєктів з метою мінімізації зовнішніх викликів. Вебхук повинен виконувати ці конвертації незалежно.

Написання сервера для конвертації за допомогою вебхука

Будь ласка, зверніться до реалізації сервера вебхука для конвертації власних ресурсів, який проходить перевірку в e2e тесті Kubernetes. Вебхук обробляє запити ConversionReview, що надсилаються API-серверами, і надсилає назад результати конвертації, загорнуті в ConversionResponse. Зверніть увагу, що запит містить список власних ресурсів, які потрібно конвертувати незалежно, не змінюючи порядок обʼєктів. Приклад сервера організований таким чином, щоб його можна було повторно використовувати для інших конвертацій. Більшість загального коду знаходиться у файлі фреймворку, залишаючи лише одну функцію для реалізації різних конвертацій.

Допустимі зміни

Вебхук для конвертації не повинен змінювати нічого в полі metadata обʼєкта, окрім labels та annotations. Спроби змінити name, UID та namespace відхиляються і призводять до помилки запиту, що спричинив конвертацію. Усі інші зміни ігноруються.

Розгортання сервера вебхука для конвертації

Документація для розгортання вебхука для конвертації аналогічна документації для прикладу сервісу вебхука для допуску. Наступні секції передбачають, що сервер вебхука для конвертації розгорнутий як сервіс з іменем example-conversion-webhook-server у просторі імен default та обслуговує трафік за шляхом /crdconvert.

Налаштування CustomResourceDefinition для використання вебхуків конвертації

Приклад None конвертації можна розширити для використання вебхука конвертації, змінивши розділ conversion в розділі spec:

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  # імʼя повинно відповідати полям spec нижче, і мати форму: <plural>.<group>
  name: crontabs.example.com
spec:
  # назва групи, яку використовувати для REST API: /apis/<group>/<version>
  group: example.com
  # список версій, які підтримуються цим CustomResourceDefinition
  versions:
  - name: v1beta1
    # Кожну версію можна увімкнути/вимкнути за допомогою прапорця Served.
    served: true
    # Одна і тільки одна версія повинна бути позначена як версія для зберігання.
    storage: true
    # Кожна версія може визначити свою власну схему, коли немає визначеної схеми верхнього рівня.
    schema:
      openAPIV3Schema:
        type: object
        properties:
          hostPort:
            type: string
  - name: v1
    served: true
    storage: false
    schema:
      openAPIV3Schema:
        type: object
        properties:
          host:
            type: string
          port:
            type: string
  conversion:
    # стратегія Webhook інструктує сервер API викликати зовнішній вебхук для будь-якої конвертації між власними ресурсами.
    strategy: Webhook
    # вебхук необхідний, коли стратегія - `Webhook`, і він налаштовує точку доступу вебхука для виклику сервером API.
    webhook:
      # conversionReviewVersions вказує, які версії ConversionReview розуміються/надається  перевага вебхуком.
      # Перша версія у списку, яку розуміє сервер API, надсилається до вебхуку.
      # Вебхук повинен відповісти обʼєктом ConversionReview в тій самій версії, що й отримана.
      conversionReviewVersions: ["v1","v1beta1"]
      clientConfig:
        service:
          namespace: default
          name: example-conversion-webhook-server
          path: /crdconvert
        caBundle: "Ci0tLS0tQk...<base64-encoded PEM bundle>...tLS0K"
  # або Namespaced, або Cluster
  scope: Namespaced
  names:
    # plural, назва ресурсу в що використовується в URL: /apis/<group>/<version>/<plural>
    plural: crontabs
    # singular, назва ресурсу в що буде використовуватись як аліас в CLI та у виводі
    singular: crontab
    # kind, зазвичай тип в однині в CamelCased. Ваші маніфести будуть використовувати це.
    kind: CronTab
    # shortNames, дозволяють коротше звертатися до ресурсу в CLI
    shortNames:
    - ct

# Застаріло у v1.16 на користь apiextensions.k8s.io/v1
apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  # імʼя повинно відповідати полям spec нижче, і мати форму: <plural>.<group>
  name: crontabs.example.com
spec:
  # назва групи, яку використовувати для REST API: /apis/<group>/<version>
  group: example.com
  # обрізає поля обʼєктів, які не вказані у схемах OpenAPI нижче.
  preserveUnknownFields: false
  # список версій, які підтримуються цим CustomResourceDefinition
  versions:
  - name: v1beta1
    # Кожну версію можна включити/вимкнути за допомогою прапорця Served.
    served: true
    # Одна і тільки одна версія повинна бути позначена як версія зберігання.
    storage: true
    # Кожна версія може визначити свою власну схему, коли немає визначеної схеми верхнього рівня.
    schema:
      openAPIV3Schema:
        type: object
        properties:
          hostPort:
            type: string
  - name: v1
    served: true
    storage: false
    schema:
      openAPIV3Schema:
        type: object
        properties:
          host:
            type: string
          port:
            type: string
  conversion:
    # стратегія Webhook інструктує сервер API викликати зовнішній вебхук для будь-якої конвертації між власними ресурсами.
    strategy: Webhook
    # webhookClientConfig необхідний, коли стратегія - `Webhook`, і він налаштовує точку доступу вебхука для виклику сервером API.
    webhookClientConfig:
      service:
        namespace: default
        name: example-conversion-webhook-server
        path: /crdconvert
      caBundle: "Ci0tLS0tQk...<base64-encoded PEM bundle>...tLS0K"
  # або Namespaced, або Cluster
  scope: Namespaced
  names:
    # plural, назва ресурсу в що використовується в URL: /apis/<group>/<version>/<plural>
    plural: crontabs
    # singular, назва ресурсу в що буде використовуватись як аліас в CLI та у виводі
    singular: crontab
    # kind, зазвичай тип в однині в CamelCased. Ваші маніфести будуть використовувати це.
    kind: CronTab
    # shortNames, дозволяють коротше звертатися до ресурсу в CLI
    shortNames:
    - ct

Ви можете зберегти опис CustomResourceDefinition у файлі YAML, а потім використовувати kubectl apply, щоб застосувати його.

kubectl apply -f мій-версійний-crontab-з-конвертацією.yaml

Переконайтеся, що сервіс конвертації працює, перш ніж застосовувати нові зміни.

Звʼязок з вебхуком

Після того, як сервер API визначив, що запит потрібно надіслати до вебхуку конвертації, йому потрібно знати, як звʼязатися з вебхуком. Це вказується в розділі webhookClientConfig конфігурації вебхука.

Вебхуки конвертації можуть бути викликані або через URL, або через посилання на сервіс, і можуть додатково містити власний пакет CA для перевірки TLS-зʼєднання.

URL

url вказує знаходження вебхука, у стандартній формі URL (scheme://host:port/path).

host не повинен посилатися на сервіс, що працює в кластері; використовуйте посилання на сервіс, вказавши замість цього поле service. Хост може бути вирішений через зовнішній DNS в деяких apiserver-ах (тобто kube-apiserver не може виконувати внутрішній DNS, оскільки це було б порушенням рівня). host також може бути IP-адресою.

Зверніть увагу, що використання localhost або 127.0.0.1 як host є ризикованим, якщо ви не приділяєте велику увагу тому, щоб запустити цей вебхук на всіх хостах, на яких працює apiserver, який може потребувати звернень до цього вебхука. Такі установки, швидше за все, не будуть переносними або не можуть бути легко запущені в новому кластері.

Схема повинна бути "https"; URL повинен починатися з "https://".

Спроба використання автентифікації користувача або базової автентифікації (наприклад, "user:password@") заборонена. Фрагменти ("#...") та параметри запиту ("?...") також не дозволені.

Ось приклад вебхука конвертації, налаштованого на виклик URL (і очікується, що сертифікат TLS буде перевірений за допомогою коренів довіри системи, тому не вказується caBundle):

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
...
spec:
  ...
  conversion:
    strategy: Webhook
    webhook:
      clientConfig:
        url: "https://my-webhook.example.com:9443/my-webhook-path"
...

# Застаріло у v1.16 на користь apiextensions.k8s.io/v1
apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
...
spec:
  ...
  conversion:
    strategy: Webhook
    webhookClientConfig:
      url: "https://my-webhook.example.com:9443/my-webhook-path"
...

Посилання на сервіс

Розділ service всередині webhookClientConfig є посиланням на сервіс для вебхука конвертації. Якщо вебхук працює всередині кластера, то ви повинні використовувати service замість url. Простір імен та імʼя сервісу є обовʼязковими. Порт є необовʼязковим і типово дорівнює 443. Шлях є необовʼязковим і типово дорівнює "/".

Ось приклад вебхука, який налаштований на виклик сервісу на порту "1234" з шляхом "/my-path", і для перевірки TLS-зʼєднання на ServerName my-service-name.my-service-namespace.svc з використанням власного пакету CA.

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
...
spec:
  ...
  conversion:
    strategy: Webhook
    webhook:
      clientConfig:
        service:
          namespace: my-service-namespace
          name: my-service-name
          path: /my-path
          port: 1234
        caBundle: "Ci0tLS0tQk...<base64-encoded PEM bundle>...tLS0K"
...

# Застаріло у v1.16 на користь apiextensions.k8s.io/v1
apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
...
spec:
  ...
  conversion:
    strategy: Webhook
    webhookClientConfig:
      service:
        namespace: my-service-namespace
        name: my-service-name
        path: /my-path
        port: 1234
      caBundle: "Ci0tLS0tQk...<base64-encoded PEM bundle>...tLS0K"
...

Запити та відповіді вебхуків

Запит

Вебхуки надсилають POST-запит з Content-Type: application/json, з обʼєктом API ConversionReview з API-групи apiextensions.k8s.io, який серіалізується в JSON як тіло запиту.

Вебхуки можуть вказати, які версії обʼєктів ConversionReview вони приймають, за допомогою поля conversionReviewVersions у своїй CustomResourceDefinition:

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
...
spec:
  ...
  conversion:
    strategy: Webhook
    webhook:
      conversionReviewVersions: ["v1", "v1beta1"]
      ...

Поле conversionReviewVersions є обовʼязковим при створенні custom resource definitions apiextensions.k8s.io/v1. Вебхуки повинні підтримувати принаймні одну версію ConversionReview, яку розуміє поточний та попередній API сервер.

# Застаріло у v1.16 на користь apiextensions.k8s.io/v1
apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
...
spec:
  ...
  conversion:
    strategy: Webhook
    conversionReviewVersions: ["v1", "v1beta1"]
    ...

Якщо conversionReviewVersions не вказано, стандартно при створенні custom resource definitions apiextensions.k8s.io/v1beta1 використовується v1beta1.

API сервери надсилають першу версію ConversionReview у списку conversionReviewVersions, яку вони підтримують. Якщо жодна з версій у списку не підтримується API сервером, створення custom resource definition не буде дозволено. Якщо API сервер зустрічає конфігурацію вебхука конвертації, яка була створена раніше і не підтримує жодної з версій ConversionReview, які сервер може надіслати, спроби виклику вебхука завершаться невдачею.

Цей приклад показує дані, що містяться в обʼєкті ConversionReview для запиту на конверсію обʼєктів CronTab до example.com/v1:

{
  "apiVersion": "apiextensions.k8s.io/v1",
  "kind": "ConversionReview",
  "request": {
    # Випадковий uid, який унікально ідентифікує цей виклик конвертації
    "uid": "705ab4f5-6393-11e8-b7cc-42010a800002",
    
    # API група та версія, до якої повинні бути конвертовані обʼєкти
    "desiredAPIVersion": "example.com/v1",
    
    # Список обʼєктів для конвертації.
    # Може містити один або більше обʼєктів, у одній або більше версіях.
    "objects": [
      {
        "kind": "CronTab",
        "apiVersion": "example.com/v1beta1",
        "metadata": {
          "creationTimestamp": "2019-09-04T14:03:02Z",
          "name": "local-crontab",
          "namespace": "default",
          "resourceVersion": "143",
          "uid": "3415a7fc-162b-4300-b5da-fd6083580d66"
        },
        "hostPort": "localhost:1234"
      },
      {
        "kind": "CronTab",
        "apiVersion": "example.com/v1beta1",
        "metadata": {
          "creationTimestamp": "2019-09-03T13:02:01Z",
          "name": "remote-crontab",
          "resourceVersion": "12893",
          "uid": "359a83ec-b575-460d-b553-d859cedde8a0"
        },
        "hostPort": "example.com:2345"
      }
    ]
  }
}

{
  # Застаріло у v1.16 на користь apiextensions.k8s.io/v1
  "apiVersion": "apiextensions.k8s.io/v1beta1",
  "kind": "ConversionReview",
  "request": {
    # Випадковий uid, який унікально ідентифікує цей виклик конвертації
    "uid": "705ab4f5-6393-11e8-b7cc-42010a800002",
    
    # API група та версія, до якої повинні бути конвертовані обʼєкти
    "desiredAPIVersion": "example.com/v1",
    
    # Список обʼєктів для конвертації.
    # Може містити один або більше обʼєктів, у одній або більше версіях.
    "objects": [
      {
        "kind": "CronTab",
        "apiVersion": "example.com/v1beta1",
        "metadata": {
          "creationTimestamp": "2019-09-04T14:03:02Z",
          "name": "local-crontab",
          "namespace": "default",
          "resourceVersion": "143",
          "uid": "3415a7fc-162b-4300-b5da-fd6083580d66"
        },
        "hostPort": "localhost:1234"
      },
      {
        "kind": "CronTab",
        "apiVersion": "example.com/v1beta1",
        "metadata": {
          "creationTimestamp": "2019-09-03T13:02:01Z",
          "name": "remote-crontab",
          "resourceVersion": "12893",
          "uid": "359a83ec-b575-460d-b553-d859cedde8a0"
        },
        "hostPort": "example.com:2345"
      }
    ]
  }
}

Відповідь

Вебхуки відповідають зі статусом HTTP 200, Content-Type: application/json та тілом, що містить обʼєкт ConversionReview (у тій самій версії, у якій вони були надіслані), з заповненим розділом response, серіалізованим у JSON.

Якщо конвертація успішна, вебхук має повернути розділ response, що містить наступні поля:

  • uid, скопійований з request.uid, надісланого до вебхука
  • result, встановлений на {"status":"Success"}
  • convertedObjects, що містить всі обʼєкти з request.objects, конвертовані до request.desiredAPIVersion

Приклад мінімально успішної відповіді від вебхука:

{
  "apiVersion": "apiextensions.k8s.io/v1",
  "kind": "ConversionReview",
  "response": {
    # має збігатись з <request.uid>
    "uid": "705ab4f5-6393-11e8-b7cc-42010a800002",
    "result": {
      "status": "Success"
    },
    # Обʼєкти мають відповідати порядку request.objects та мати apiVersion, встановлений у <request.desiredAPIVersion>.
    # поля kind, metadata.uid, metadata.name та metadata.namespace не повинні змінюватися вебхуком.
    # поля metadata.labels та metadata.annotations можуть бути змінені вебхуком.
    # всі інші зміни полів metadata, зроблені вебхуком, ігноруються.
    "convertedObjects": [
      {
        "kind": "CronTab",
        "apiVersion": "example.com/v1",
        "metadata": {
          "creationTimestamp": "2019-09-04T14:03:02Z",
          "name": "local-crontab",
          "namespace": "default",
          "resourceVersion": "143",
          "uid": "3415a7fc-162b-4300-б5da-fd6083580d66"
        },
        "host": "localhost",
        "port": "1234"
      },
      {
        "kind": "CronTab",
        "apiVersion": "example.com/v1",
        "metadata": {
          "creationTimestamp": "2019-09-03T13:02:01Z",
          "name": "remote-crontab",
          "resourceVersion": "12893",
          "uid": "359a83ec-b575-460d-б553-d859cedde8a0"
        },
        "host": "example.com",
        "port": "2345"
      }
    ]
  }
}

{
  # Застаріло у версії v1.16 на користь apiextensions.k8s.io/v1
  "apiVersion": "apiextensions.k8s.io/v1beta1",
  "kind": "ConversionReview",
  "response": {
    # має відповідати <request.uid>
    "uid": "705ab4f5-6393-11e8-б7cc-42010a800002",
    "result": {
      "status": "Failed"
    },
    # Обʼєкти мають відповідати порядку request.objects та мати apiVersion, встановлений у <request.desiredAPIVersion>.
    # поля kind, metadata.uid, metadata.name та metadata.namespace не повинні змінюватися вебхуком.
    # поля metadata.labels та metadata.annotations можуть бути змінені вебхуком.
    # всі інші зміни полів metadata, зроблені вебхуком, ігноруються.
    "convertedObjects": [
      {
        "kind": "CronTab",
        "apiVersion": "example.com/v1",
        "metadata": {
          "creationTimestamp": "2019-09-04T14:03:02Z",
          "name": "local-crontab",
          "namespace": "default",
          "resourceVersion": "143",
          "uid": "3415a7fc-162b-4300-б5da-fd6083580d66"
        },
        "host": "localhost",
        "port": "1234"
      },
      {
        "kind": "CronTab",
        "apiVersion": "example.com/v1",
        "metadata": {
          "creationTimestamp": "2019-09-03T13:02:01Z",
          "name": "remote-crontab",
          "resourceVersion": "12893",
          "uid": "359a83ec-б575-460d-б553-d859cedde8a0"
        },
        "host": "example.com",
        "port": "2345"
      }
    ]
  }
}

Якщо конвертація не вдалася, вебхук має повернути розділ response, що містить наступні поля:

  • uid, скопійований з request.uid, надісланого до вебхуку
  • result, встановлений на {"status":"Failed"}

Приклад відповіді від вебхуку, що вказує на невдачу запиту конвертації, з додатковим повідомленням:

{
  "apiVersion": "apiextensions.k8s.io/v1",
  "kind": "ConversionReview",
  "response": {
    "uid": "<значення з request.uid>",
    "result": {
      "status": "Failed",
      "message": "hostPort не вдалося розділити на окремі host та port"
    }
  }
}

{
  # Застаріло у версії v1.16 на користь apiextensions.k8s.io/v1
  "apiVersion": "apiextensions.k8s.io/v1beta1",
  "kind": "ConversionReview",
  "response": {
    "uid": "<значення з request.uid>",
    "result": {
      "status": "Failed",
      "message": "hostPort не вдалося розділити на окремі host та port"
    }
  }
}

Запис, читання та оновлення обʼєктів CustomResourceDefinition з версіями

Коли обʼєкт записується, він зберігається у версії, визначеній як версія зберігання на момент запису. Якщо версія зберігання змінюється, наявні обʼєкти ніколи не конвертуються автоматично. Проте новостворені або оновлені обʼєкти записуються у новій версії зберігання. Можливо, що обʼєкт було записано у версії, яка більше не обслуговується.

Коли ви зчитуєте обʼєкт, ви вказуєте версію як частину шляху. Ви можете запитати обʼєкт у будь-якій версії, яка наразі обслуговується. Якщо ви вказуєте версію, яка відрізняється від версії, у якій зберігається обʼєкт, Kubernetes повертає вам обʼєкт у запитуваній версії, але збережений обʼєкт не змінюється на диску.

Що відбувається з обʼєктом, який повертається під час обслуговування запиту на читання, залежить від того, що вказано у spec.conversion CRD:

  • Якщо вказано стандартне значення стратегії None, єдині зміни обʼєкта — це зміна рядка apiVersion і, можливо, обрізання невідомих полів (залежно від конфігурації). Зазначимо, що це навряд чи призведе до хороших результатів, якщо схеми відрізняються між версіями зберігання та запитуваною версією. Зокрема, не слід використовувати цю стратегію, якщо ті самі дані представлені у різних полях між версіями.
  • Якщо вказано конвретацію за допомогою вебхуку, тоді цей механізм контролює конверсію.

Якщо ви оновлюєте існуючий обʼєкт, він перезаписується у версії, яка наразі є версією зберігання. Це єдиний спосіб, за допомогою якого обʼєкти можуть змінюватися з однієї версії на іншу.

Щоб проілюструвати це, розглянемо наступну гіпотетичну послідовність подій:

  1. Версія зберігання — v1beta1. Ви створюєте обʼєкт. Він зберігається у версії v1beta1.
  2. Ви додаєте версію v1 до вашого CustomResourceDefinition і призначаєте її версією зберігання. Схеми для v1 та v1beta1 є ідентичними, що зазвичай має місце під час підвищення API до стабільного стану в екосистемі Kubernetes.
  3. Ви читаєте свій обʼєкт у версії v1beta1, потім читаєте обʼєкт знову у версії v1. Обидва отримані обʼєкти є ідентичними, за винятком поля apiVersion.
  4. Ви створюєте новий обʼєкт. Він зберігається у версії v1. Тепер у вас є два обʼєкти: один у версії v1beta1, інший у версії v1.
  5. Ви оновлюєте перший обʼєкт. Тепер він зберігається у версії v1, оскільки це поточна версія зберігання.

Попередні версії зберігання

API сервер записує кожну версію, яка коли-небудь була позначена як версія зберігання у полі статусу storedVersions. Обʼєкти можуть бути збережені у будь-якій версії, яка коли-небудь була визначена як версія зберігання. Ніякі обʼєкти не можуть існувати у зберіганні у версії, яка ніколи не була версією зберігання.

Оновлення існуючих обʼєктів до нової версії зберігання

При застаріванні версій та припиненні підтримки виберіть процедуру оновлення зберігання.

Варіант 1: Використання Storage Version Migrator

  1. Запустіть Storage Version Migrator.
  2. Видаліть стару версію з поля status.storedVersions CustomResourceDefinition.

Варіант 2: Ручне оновлення наявних обʼєктів до нової версії зберігання

Наведено приклад процедури оновлення з v1beta1 до v1.

  1. Встановіть v1 як версію зберігання у файлі CustomResourceDefinition та застосуйте це за допомогою kubectl. Тепер storedVersions містить v1beta1, v1.
  2. Напишіть процедуру оновлення для отримання всіх наявних обʼєктів і запишіть їх з тим самим вмістом. Це змушує бекенд записувати обʼєкти у поточній версії зберігання, якою є v1.
  3. Видаліть v1beta1 з поля status.storedVersions CustomResourceDefinition.

4.11.2 - Налаштування шару агрегації

Налаштування шару агрегації дозволяє розширити apiserver Kubernetes додатковими API, які не є частиною основних API Kubernetes.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Для перевірки версії введіть kubectl version.

Потоки автентифікації

На відміну від Custom Resource Definitions (CRDs), API агрегації включає ще один сервер, ваш apiserver розширення, крім стандартного apiserver Kubernetes. Kubernetes apiserver повинен взаємодіяти з вашим apiserver розширення, а ваш apiserver розширення повинен взаємодіяти з Kubernetes apiserver. Щоб ця взаємодія була захищеною, Kubernetes apiserver використовує x509 сертифікати для автентифікації себе перед apiserver розширення.

У цьому розділі описано, як працюють потоки автентифікації та авторизації та як їх налаштувати.

Основний потік виглядає наступним чином:

  1. Kubernetes apiserver: автентифікація користувача, що запитує, та авторизація його прав на запитаний API шлях.
  2. Kubernetes apiserver: проксіювання запиту до apiserverʼа розширення.
  3. apiserver розширення: автентифікація запиту від Kubernetes apiserver.
  4. apiserver розширення: авторизація запиту від початкового користувача.
  5. apiserver розширення: виконання.

У решті цього розділу описуються ці кроки детально.

Потік можна побачити на наступній діаграмі.

aggregation auth flows

Джерело для вищезазначених потоків можна знайти у вихідному коді цього документа.

Автентифікація та авторизація Kubernetes Apiserver

Запит до API шляху, який обслуговується apiserver розширення, починається так само, як і всі API запити: з комунікації з Kubernetes apiserver. Цей шлях вже був зареєстрований з Kubernetes apiserver apiserver розширення.

Користувач взаємодіє з Kubernetes apiserver, запитуючи доступ до шляху. Kubernetes apiserver використовує стандартну автентифікацію та авторизацію, налаштовану в Kubernetes apiserver, для автентифікації користувача та авторизації доступу до конкретного шляху.

Для загального огляду автентифікації в кластері Kubernetes див. "Автентифікація в кластері". Для загального огляду авторизації доступу до ресурсів кластера Kubernetes див. "Огляд авторизації".

Все до цього моменту було стандартними запитами API Kubernetes, автентифікацією та авторизацією.

Kubernetes apiserver тепер готовий відправити запит до apiserverʼа розширення.

Проксіювання запиту Kubernetes Apiserver

Kubernetes apiserver тепер відправить або проксує запит до apiserverʼа розширення, який зареєстрований для обробки цього запиту. Для цього потрібно знати кілька речей:

  1. Як Kubernetes apiserver повинен автентифікуватися у apiserver розширення, інформуючи його, що запит, який надходить мережею, надходить від дійсного Kubernetes apiserver?
  2. Як Kubernetes apiserver повинен інформувати apiserver розширення про імʼя користувача та групу, з якими оригінальний запит був автентифікований?

Щоб забезпечити ці два аспекти, ви повинні налаштувати Kubernetes apiserver, використовуючи кілька прапорців.

Автентифікація клієнта Kubernetes Apiserver

Kubernetes apiserver підключається до apiserverʼа розширення через TLS, автентифікується за допомогою клієнтського сертифіката. Ви повинні надати наступне для Kubernetes apiserver при запуску, використовуючи вказані параметри:

  • файл приватного ключа через --proxy-client-key-file
  • підписаний файл клієнтського сертифіката через --proxy-client-cert-file
  • сертифікат CA, який підписав файл клієнтського сертифіката через --requestheader-client-ca-file
  • дійсні значення загального імені (CN) в підписаному клієнтському сертифікаті через --requestheader-allowed-names

Kubernetes apiserver використовуватиме файли, вказані --proxy-client-*-file, щоб автентифікуватися у apiserver розширення. Щоб запит був вважався дійсним відповідно до стандартів apiserverʼа розширення, мають виконуватися наступні умови:

  1. Підключення має бути виконане за допомогою клієнтського сертифіката, який підписаний CA, сертифікат якого знаходиться в --requestheader-client-ca-file.
  2. Підключення має бути виконане за допомогою клієнтського сертифіката, CN якого знаходиться в одному з тих, що перелічені в --requestheader-allowed-names.

Після запуску з цими параметрами Kubernetes apiserver:

  1. Використовуватиме їх для автентифікації у apiserver розширення.
  2. Створить ConfigMap у просторі імен kube-system з назвою extension-apiserver-authentication, в який він помістить сертифікат CA та дозволені CN. Ці дані можна отримати apiserverʼа розширенняs для перевірки запитів.

Зверніть увагу, що той самий клієнтський сертифікат використовується Kubernetes apiserver для автентифікації для усіх apiserverʼів розширень. Він не створює окремий клієнтський сертифікат для кожного apiserverʼа розширення, а лише один, щоб автентифікуватися як Kubernetes apiserver. Цей самий сертифікат використовується для всіх запитів apiserverʼа розширення.

Імʼя користувача та група оригінального запиту

Коли Kubernetes apiserver проксіює запит до apiserverʼа розширення, він повідомляє apiserver розширення імʼя користувача та групу, з якими успішно був автентифікований початковий запит. Він надає це у http заголовках свого проксі-запиту. Ви повинні повідомити Kubernetes apiserver назви заголовків, які слід використовувати.

  • заголовок, в якому зберігати імʼя користувача через --requestheader-username-headers
  • заголовок, в якому зберігати групу через --requestheader-group-headers
  • префікс для всіх додаткових заголовків через --requestheader-extra-headers-prefix

Ці назви заголовків також поміщаються в ConfigMap extension-apiserver-authentication, так що їх можна отримати та використати apiserverʼа розширенняs.

Apiserver розширення автентифікує запит

apiserver розширення, отримавши проксі-запит від Kubernetes apiserver, повинен перевірити, що запит дійсно надійшов від дійсного автентифікуючого проксі, роль якого виконує Kubernetes apiserver. apiserver розширення перевіряє його за допомогою:

  1. Отримання наступного з ConfigMap в kube-system, як описано вище:
    • Сертифікат CA клієнта
    • Список дозволених імен (CN)
    • Назви заголовків для імені користувача, групи та додаткової інформації
  2. Перевірте, що TLS-зʼєднання було автентифіковано за допомогою сертифіката клієнта, який:
    • Був підписаний CA, чий сертифікат відповідає отриманому сертифікату CA.
    • Має CN у списку дозволених CN, якщо список не порожній, в іншому випадку дозволяються всі CN.
    • Витягу імені користувача та групи з відповідних заголовків.

Якщо вище зазначене пройшло, тоді запит є дійсним проксійним запитом від законного проксі автентифікації, у цьому випадку — apiserver Kubernetes.

Зверніть увагу, що відповідальність за надання вищезазначеного лежить на реалізації apiserverʼа розширення. Більшість роблять це стандартно, використовуючи пакет k8s.io/apiserver/. Інші можуть надати опції для зміни цього за допомогою параметрів командного рядка.

Для того, щоб мати дозвіл на отримання конфігураційного файлу, apiserver розширення потребує відповідної ролі. Існує стандартна роль з назвою extension-apiserver-authentication-reader в просторі імен kube-system, яка може бути призначена.

Apiserver розширення авторизує запит

Тепер apiserver розширення може перевірити, що користувач/група, отримані з заголовків, мають дозвіл на виконання даного запиту. Він робить це, надсилаючи стандартний запит SubjectAccessReview до apiserver Kubernetes.

Для того, щоб apiserver розширення мав право на надсилання запиту SubjectAccessReview до apiserver Kubernetes, йому потрібні відповідні дозволи. Kubernetes включає стандартну ClusterRole з назвою system:auth-delegator, яка має необхідні дозволи. Її можна надати обліковому запису служби apiserverʼа розширенняа.

Виконання Apiserver розширення

Якщо перевірка SubjectAccessReview пройде успішно, apiserver розширення виконує запит.

Увімкнення прапорців Apiserver Kubernetes

Увімкніть агрегаційний шар за допомогою наступних прапорців kube-apiserver. Вони можуть вже бути налаштовані вашим постачальником.

--requestheader-client-ca-file=<шлях до сертифікату CA агрегатора>
--requestheader-allowed-names=front-proxy-client
--requestheader-extra-headers-prefix=X-Remote-Extra-
--requestheader-group-headers=X-Remote-Group
--requestheader-username-headers=X-Remote-User
--proxy-client-cert-file=<шлях до сертифікату проксі-клієнта агрегатора>
--proxy-client-key-file=<шлях до ключа проксі-клієнта агрегатора>

Повторне використання та конфлікти сертифікатів CA

У Kubernetes apiserver є два параметри CA клієнта:

  • --client-ca-file
  • --requestheader-client-ca-file

Кожен з цих параметрів працює незалежно і може конфліктувати один з одним, якщо їх не використовувати належним чином.

  • --client-ca-file: Коли запит надходить на Kubernetes apiserver, якщо цей параметр увімкнено, Kubernetes apiserver перевіряє сертифікат запиту. Якщо він підписаний одним з сертифікатів CA в файлі, на який вказує --client-ca-file, то запит вважається законним, а користувач — значенням загального імені CN=, а група — організацією O=. Див. документацію з автентифікації TLS.
  • --requestheader-client-ca-file: Коли запит надходить на Kubernetes apiserver, якщо цей параметр увімкнено, Kubernetes apiserver перевіряє сертифікат запиту. Якщо він підписаний одним із сертифікатів CA у файлі, на який вказує --requestheader-client-ca-file, то запит вважається потенційно законним. Потім Kubernetes apiserver перевіряє, чи є загальне імʼя CN= одним з імен у списку, наданому параметром --requestheader-allowed-names. Якщо імʼя дозволене, запит схвалюється; якщо ні, запит відхиляється.

Якщо обидва параметри --client-ca-file та --requestheader-client-ca-file надані, то спочатку запит перевіряє CA --requestheader-client-ca-file, а потім --client-ca-file. Зазвичай для кожного з цих параметрів використовуються різні сертифікати CA, або кореневі CA, або проміжні CA; звичайні клієнтські запити відповідають --client-ca-file, тоді як агрегаційні запити відповідають --requestheader-client-ca-file. Однак, якщо обидва використовують той самий CA, то звичайні клієнтські запити, які зазвичай пройшли б через --client-ca-file, не пройдуть, оскільки CA буде відповідати CA в --requestheader-client-ca-file, але загальне імʼя CN= не буде відповідати одному з припустимих загальних імен в --requestheader-allowed-names. Це може призвести до того, що kublete та інші компоненти панелі управління, так само як і інші клієнти, не зможуть автентифікуватись на Kubernetes apiserver.

З цієї причини використовуйте різні сертифікати CA для опції --client-ca-file, щоб авторизувати компоненти панелі управління та кінцевих користувачів, і опції --requestheader-client-ca-file, щоб авторизувати запити apiserverʼа агрегації.

Якщо ви не запускаєте kube-proxy на хості, на якому працює API-сервер, вам потрібно впевнитися, що система ввімкнена з наступним прапорцем kube-apiserver:

--enable-aggregator-routing=true

Реєстрація обʼєктів APIService

Ви можете динамічно налаштувати, які клієнтські запити будуть проксійовані до apiserverʼа розширення. Нижче наведено приклад реєстрації:


apiVersion: apiregistration.k8s.io/v1
kind: APIService
metadata:
  name: <імʼя обʼєкта реєстрації>
spec:
  group: <назва групи API, яку обслуговує цей apiserver розширення>
  version: <версія API, яку обслуговує цей apiserver розширення>
  groupPriorityMinimum: <пріоритет цього APIService для цієї групи, див. документацію API>
  versionPriority: <пріоритет упорядкування цієї версії у межах групи, див. документацію API>
  service:
    namespace: <простір імен сервісу apiserverʼа розширення>
    name: <імʼя сервісу apiserverʼа розширення>
  caBundle: <pem-кодований ca-сертифікат, який підписує сертифікат сервера, який використовується вебзапитом>

Імʼя обʼєкта APIService повинно бути дійсним імʼям сегмента шляху.

Звертання до apiserverʼа розширення

Після того, як Kubernetes apiserver вирішив, що запит потрібно надіслати до apiserverʼа розширення, він повинен знати, як з ним звʼязатися.

Блок service — це посилання на сервіс для apiserverʼа розширення. Простір імен та імʼя сервісу обовʼязкові. Порт є необовʼязковим і типово дорівнює 443.

Ось приклад apiserverʼа розширення, який налаштований для виклику на порті "1234" та перевірки зʼєднання TLS проти ServerName my-service-name.my-service-namespace.svc, використовуючи власний пакет CA.

apiVersion: apiregistration.k8s.io/v1
kind: APIService
...
spec:
  ...
  service:
    namespace: my-service-namespace
    name: my-service-name
    port: 1234
  caBundle: "Ci0tLS0tQk...<base64-кодований PEM пакет>...tLS0K"
...

Що далі

4.11.3 - Налаштування API сервера розширення

Налаштування API сервера розширення для роботи з шаром агрегації дозволяє розширювати apiserver Kubernetes додатковими API, які не є частиною основних API Kubernetes.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Для перевірки версії введіть kubectl version.

Налаштування API сервера розширення для роботи з шаром агрегації

Наступні кроки описують налаштування apiserverʼа розширення на високому рівні. Ці кроки застосовуються незалежно від того, чи використовуєте ви YAML конфігурації, чи API. Робиться спроба конкретно визначити будь-які відмінності між цими двома підходами. Для конкретного прикладу їх реалізації за допомогою YAML конфігурацій, ви можете ознайомитися з sample-apiserver у репозиторії Kubernetes.

Альтернативно, ви можете використовувати наявне стороннє рішення, таке як apiserver-builder, яке має згенерувати кістяк та автоматизувати всі наступні кроки для вас.

  1. Переконайтеся, що APIService API увімкнено (перевірте --runtime-config). Воно має бути типово увімкнене, якщо воно не було свідомо вимкнено у вашому кластері.
  2. Можливо, вам потрібно створити правило RBAC, яке дозволяє додавати обʼєкти APIService, або попросити адміністратора вашого кластера створити його. (Оскільки розширення API впливають на весь кластер, не рекомендується проводити тестування/розробку/налагодження розширення API у робочому кластері.)
  3. Створіть простір імен Kubernetes, у якому ви хочете запустити свій api-сервер розширення.
  4. Отримайте сертифікат CA, який буде використовуватися для підпису сертифіката сервера, що використовує api-сервер розширення для HTTPS.
  5. Створіть серверний сертифікат/ключ для api-сервера, який буде використовуватися для HTTPS. Цей сертифікат повинен бути підписаний вище згаданим CA. Він також повинен мати CN у вигляді імені Kube DNS. Це імʼя формується на основі сервісу Kubernetes і має вигляд <service name>.<service name namespace>.svc.
  6. Створіть Secret Kubernetes з серверним сертифікатом/ключем у вашому просторі імен.
  7. Створіть Deployment Kubernetes для api-сервера розширення і переконайтеся, що ви завантажуєте Secret як том. Він повинен містити посилання на робочий образ вашого api-сервера розширення. Deployment також повинен бути у вашому просторі імен.
  8. Переконайтеся, що ваш api-сервер розширення завантажує ці сертифікати з того тому і що вони використовуються в процесі рукостискання (handshake) HTTPS.
  9. Створіть службовий обліковий запис (service account) Kubernetes у вашому просторі імен.
  10. Створіть кластерну роль Kubernetes для операцій, які ви хочете дозволити над вашими ресурсами.
  11. Створіть привʼязку кластерної ролі до службового облікового запису (service account) у вашому просторі імен до створеної кластерної ролі.
  12. Створіть привʼязку кластерної ролі до службового облікового запису (service account) у вашому просторі імен до кластерної ролі system:auth-delegator для делегування рішень щодо автентифікації на основному API серверу Kubernetes.
  13. Створіть привʼязку службового облікового запису (service account) у вашому просторі імен до ролі extension-apiserver-authentication-reader. Це дозволяє вашому api-серверу розширення отримувати доступ до ConfigMap extension-apiserver-authentication.
  14. Створіть apiservice Kubernetes. CA сертифікат повинен бути закодований в base64, не містити позбавлений нових рядків і використаний як spec.caBundle в apiservice. Він не повинен бути привʼязаний до простору імен. Якщо ви використовуєте kube-aggregator API, передайте лише PEM-кодований CA bundle, оскільки кодування в base64 виконується за вас.
  15. Використовуйте kubectl для отримання вашого ресурсу. Під час запуску kubectl повинен повернути "No resources found.". Це повідомлення вказує на те, що все спрацювало, але наразі у вас немає створених обʼєктів цього типу ресурсу.

Що далі

4.11.4 - Налаштування кількох планувальників

Kubernetes постачається зі стандартним планувальником. Якщо стандартний планувальник не підходить для ваших потреб, ви можете реалізувати власний. До того, ви можете одночасно запускати кілька планувальників поряд зі стандартним планувальником і вказувати Kubernetes, який планувальник використовувати для кожного з ваших Podʼів. Тепер навчимося запускати кілька планувальників в Kubernetes на прикладі.

Детальний опис того, як реалізувати планувальник, виходить за рамки цього документа. Будь ласка, зверніться до реалізації kube-scheduler в pkg/scheduler в теці вихідних кодів Kubernetes для канонічного прикладу.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Для перевірки версії введіть kubectl version.

Упакування планувальника

Упакуйте ваш планувальник у контейнерний образ. Для цілей цього прикладу ви можете використовувати стандартний планувальник (kube-scheduler) як ваш другий планувальник. Клонуйте вихідний код Kubernetes з GitHub і зберіть планувальник з сирців.

git clone https://github.com/kubernetes/kubernetes.git
cd kubernetes
make

Створіть контейнерний образ, що містить виконавчий файл kube-scheduler. Ось Dockerfile для створення образу:

FROM busybox
ADD ./_output/local/bin/linux/amd64/kube-scheduler /usr/local/bin/kube-scheduler

Збережіть файл як Dockerfile, зберіть образ і завантажте його до реєстру. У цьому прикладі образ завантажується до Google Container Registry (GCR). Для отримання додаткової інформації, будь ласка, прочитайте документацію GCR. Як альтернативу ви також можете використовувати docker hub. Для отримання додаткової інформації зверніться до документації docker hub.

docker build -t gcr.io/my-gcp-project/my-kube-scheduler:1.0 .     # Назва образу та репозиторію
gcloud docker -- push gcr.io/my-gcp-project/my-kube-scheduler:1.0 # тут є лише прикладом

Визначення розгортання Kubernetes для планувальника

Тепер, коли ви маєте ваш планувальник у контейнерному образі, створіть конфігурацію Podʼа для нього і запустіть його у вашому кластері Kubernetes. Але замість того, щоб створювати Pod безпосередньо в кластері, ви можете використовувати Deployment для цього прикладу. Deployment керує Replica Set, який, своєю чергою, керує Podʼами, забезпечуючи стійкість планувальника до збоїв. Ось конфігурація розгортання. Збережіть її як my-scheduler.yaml:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-scheduler
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: my-scheduler-as-kube-scheduler
subjects:
- kind: ServiceAccount
  name: my-scheduler
  namespace: kube-system
roleRef:
  kind: ClusterRole
  name: system:kube-scheduler
  apiGroup: rbac.authorization.k8s.io
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: my-scheduler-as-volume-scheduler
subjects:
- kind: ServiceAccount
  name: my-scheduler
  namespace: kube-system
roleRef:
  kind: ClusterRole
  name: system:volume-scheduler
  apiGroup: rbac.authorization.k8s.io
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: my-scheduler-extension-apiserver-authentication-reader
  namespace: kube-system
roleRef:
  kind: Role
  name: extension-apiserver-authentication-reader
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: ServiceAccount
  name: my-scheduler
  namespace: kube-system
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: my-scheduler-config
  namespace: kube-system
data:
  my-scheduler-config.yaml: |
    apiVersion: kubescheduler.config.k8s.io/v1beta2
    kind: KubeSchedulerConfiguration
    profiles:
      - schedulerName: my-scheduler
    leaderElection:
      leaderElect: false    
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    component: scheduler
    tier: control-plane
  name: my-scheduler
  namespace: kube-system
spec:
  selector:
    matchLabels:
      component: scheduler
      tier: control-plane
  replicas: 1
  template:
    metadata:
      labels:
        component: scheduler
        tier: control-plane
        version: second
    spec:
      serviceAccountName: my-scheduler
      containers:
      - command:
        - /usr/local/bin/kube-scheduler
        - --config=/etc/kubernetes/my-scheduler/my-scheduler-config.yaml
        image: gcr.io/my-gcp-project/my-kube-scheduler:1.0
        livenessProbe:
          httpGet:
            path: /healthz
            port: 10259
            scheme: HTTPS
          initialDelaySeconds: 15
        name: kube-second-scheduler
        readinessProbe:
          httpGet:
            path: /healthz
            port: 10259
            scheme: HTTPS
        resources:
          requests:
            cpu: '0.1'
        securityContext:
          privileged: false
        volumeMounts:
          - name: config-volume
            mountPath: /etc/kubernetes/my-scheduler
      hostNetwork: false
      hostPID: false
      volumes:
        - name: config-volume
          configMap:
            name: my-scheduler-config

У наведеному вище маніфесті ви використовуєте KubeSchedulerConfiguration для налаштування поведінки вашої реалізації планувальника. Ця конфігурація була передана kube-scheduler під час ініціалізації за допомогою параметра --config. Конфігураційний файл зберігається у ConfigMap my-scheduler-config. Pod Deployment my-scheduler монтує ConfigMap my-scheduler-config як том.

У вищезгаданій конфігурації планувальника ваша реалізація планувальника представлена за допомогою KubeSchedulerProfile.

Також зверніть увагу, що ви створюєте окремий службовий обліковий запис my-scheduler і привʼязуєте до нього кластерну роль system:kube-scheduler, щоб він міг отримати ті ж привілеї, що й kube-scheduler.

Будь ласка, зверніться до документації kube-scheduler для детального опису інших параметрів командного рядка та довідкової інформації щодо конфігурації планувальника для детального опису інших налаштовуваних конфігурацій kube-scheduler.

Запуск другого планувальника в кластері

Щоб запустити ваш планувальник у кластері Kubernetes, створіть Deployment вказаний у конфігурації вище у кластері Kubernetes:

kubectl create -f my-scheduler.yaml

Переконайтеся, що Pod планувальника працює:

kubectl get pods --namespace=kube-system
NAME                                           READY     STATUS    RESTARTS   AGE
....
my-scheduler-lnf4s-4744f                       1/1       Running   0          2m
...

У цьому списку ви повинні побачити Pod "Running" my-scheduler, на додачу до стандартного планувальника kube-scheduler.

Увімкнення обрання лідера

Щоб запустити кілька планувальників з увімкненим обранням лідера, ви повинні зробити наступне:

Оновіть наступні поля для KubeSchedulerConfiguration у ConfigMap my-scheduler-config у вашому YAML файлі:

  • leaderElection.leaderElect до true
  • leaderElection.resourceNamespace до <lock-object-namespace>
  • leaderElection.resourceName до <lock-object-name>

Якщо у вашому кластері увімкнено RBAC, ви повинні оновити кластерну роль system:kube-scheduler. Додайте імʼя вашого планувальника до імен ресурсів у правилі, яке застосовується до ресурсів endpoints та leases, як у наступному прикладі:

kubectl edit clusterrole system:kube-scheduler
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  labels:
    kubernetes.io/bootstrapping: rbac-defaults
  name: system:kube-scheduler
rules:
  - apiGroups:
      - coordination.k8s.io
    resources:
      - leases
    verbs:
      - create
  - apiGroups:
      - coordination.k8s.io
    resourceNames:
      - kube-scheduler
      - my-scheduler
    resources:
      - leases
    verbs:
      - get
      - update
  - apiGroups:
      - ""
    resourceNames:
      - kube-scheduler
      - my-scheduler
    resources:
      - endpoints
    verbs:
      - delete
      - get
      - patch
      - update

Вказання планувальників для Podʼів

Тепер, коли ваш другий планувальник працює, створіть кілька Podʼів і вкажіть, щоб вони планувалися або стандартним планувальником, або тим, який ви розгорнули. Щоб запланувати Pod за допомогою конкретного планувальника, вкажіть імʼя планувальника у специфікації Podʼа. Розгляньмо три приклади.

  • Специфікація Podʼа без вказаного імені планувальника

    apiVersion: v1
    kind: Pod
    metadata:
      name: no-annotation
      labels:
        name: multischeduler-example
    spec:
      containers:
      - name: pod-with-no-annotation-container
        image: registry.k8s.io/pause:2.0

    Коли імʼя планувальника не вказано, Pod автоматично планується за допомогою стандартного планувальника.

    Збережіть цей файл як pod1.yaml і надішліть його до кластера Kubernetes.

    kubectl create -f pod1.yaml
    
  • Специфікація Podʼа з default-scheduler

    apiVersion: v1
    kind: Pod
    metadata:
      name: annotation-default-scheduler
      labels:
        name: multischeduler-example
    spec:
      schedulerName: default-scheduler
      containers:
      - name: pod-with-default-annotation-container
        image: registry.k8s.io/pause:2.0
    

    Планувальник вказується шляхом надання його імені як значення для spec.schedulerName. У цьому випадку ми надаємо імʼя стандартного планувальника, яке є default-scheduler.

    Збережіть цей файл як pod2.yaml і надішліть його до кластера Kubernetes.

    kubectl create -f pod2.yaml
    
  • Специфікація Podʼа з my-scheduler

    apiVersion: v1
    kind: Pod
    metadata:
      name: annotation-second-scheduler
      labels:
        name: multischeduler-example
    spec:
      schedulerName: my-scheduler
      containers:
      - name: pod-with-second-annotation-container
        image: registry.k8s.io/pause:2.0
    

    У цьому випадку ми вказуємо, що цей Pod має бути запланований за допомогою планувальника, який ми розгорнули — my-scheduler. Зверніть увагу, що значення spec.schedulerName повинно відповідати імені, яке було надано планувальнику в полі schedulerName профілю KubeSchedulerProfile.

    Збережіть цей файл як pod3.yaml і надішліть його до кластера Kubernetes.

    kubectl create -f pod3.yaml
    

    Переконайтеся, що всі три Podʼи працюють.

    kubectl get pods
    

Перевірка, що Podʼи були заплановані за допомогою бажаних планувальників

Для спрощення роботи з цими прикладами ми не перевірили, що Podʼи дійсно були заплановані за допомогою бажаних планувальників. Ми можемо перевірити це, змінивши порядок подання конфігурацій Podʼів і розгортання вище. Якщо ми передамо всі конфігурації Podʼів до кластера Kubernetes перед передачею конфігурації розгортання планувальника, ми побачимо, що Pod annotation-second-scheduler залишається в стані "Pending" назавжди, тоді як інші два Podʼи заплановані. Після надсилання конфігурації розгортання планувальника і запуску нашого нового планувальника, Pod annotation-second-scheduler також запланується.

Як альтернативу, ви можете переглянути записи "Scheduled" у лозі подій, щоб перевірити, що Podʼи були заплановані бажаними планувальниками.

kubectl get events

Ви також можете використовувати власну конфігурацію планувальника або власний контейнерний образ для основного планувальника кластера, змінивши його статичний маніфест Podʼа на відповідних вузлах панелі управління.

4.11.5 - Використання HTTP-проксі для доступу до Kubernetes API

Ця сторінка показує, як використовувати HTTP-проксі для доступу до Kubernetes API.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Для перевірки версії введіть kubectl version.

Якщо у вас ще немає застосунку, що працює у вашому кластері, запустіть застосунок Hello world, скориставшись:

kubectl create deployment hello-app --image=gcr.io/google-samples/hello-app:2.0 --port=8080

Використання kubectl для запуску проксі-сервера

Ця команда запускає проксі до сервера Kubernetes API:

kubectl proxy --port=8080

Дослідження Kubernetes API

Коли проксі-сервер працює, ви можете досліджувати API за допомогою curl, wget або оглядача.

Отримання версій API:

curl http://localhost:8080/api/

Вихідні дані повинні виглядати приблизно так:

{
  "kind": "APIVersions",
  "versions": [
    "v1"
  ],
  "serverAddressByClientCIDRs": [
    {
      "clientCIDR": "0.0.0.0/0",
      "serverAddress": "10.0.2.15:8443"
    }
  ]
}

Отримання списку Podʼів:

curl http://localhost:8080/api/v1/namespaces/default/pods

Вихідні дані повинні виглядати приблизно так:

{
  "kind": "PodList",
  "apiVersion": "v1",
  "metadata": {
    "resourceVersion": "33074"
  },
  "items": [
    {
      "metadata": {
        "name": "kubernetes-bootcamp-2321272333-ix8pt",
        "generateName": "kubernetes-bootcamp-2321272333-",
        "namespace": "default",
        "uid": "ba21457c-6b1d-11e6-85f7-1ef9f1dab92b",
        "resourceVersion": "33003",
        "creationTimestamp": "2016-08-25T23:43:30Z",
        "labels": {
          "pod-template-hash": "2321272333",
          "run": "kubernetes-bootcamp"
        },
        ...

Що далі

Дізнайтеся більше про kubectl proxy.

4.11.6 - Використання SOCKS5-проксі для доступу до Kubernetes API

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.24 [stable]

Ця сторінка показує, як використовувати SOCKS5-проксі для доступу до API віддаленого кластера Kubernetes. Це корисно, коли кластер, до якого ви хочете отримати доступ, не відкриває свій API безпосередньо в інтернет.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Версія вашого Kubernetes сервера має бути не старішою ніж v1.24. Для перевірки версії введіть kubectl version.

Вам потрібне програмне забезпечення для SSH-клієнта (інструмент ssh) і сервіс SSH, що працює на віддаленому сервері. Ви повинні мати можливість увійти до сервісу SSH на віддаленому сервері.

Контекст завдання

На схемі 1 представлено, що ви збираєтесь досягти в цьому завданні.

  • У вас є компʼютер-клієнт, який називається локальним у подальших кроках, з якого ви будете створювати запити для спілкування з Kubernetes API.
  • Сервер Kubernetes/API розміщений на віддаленому сервері.
  • Ви будете використовувати програмне забезпечення SSH-клієнта і сервера для створення безпечного SOCKS5-тунелю між локальним і віддаленим сервером. HTTPS-трафік між клієнтом і Kubernetes API буде проходити через SOCKS5-тунель, який сам тунелюється через SSH.

graph LR; subgraph local[Локальний клієнтський компʼютер] client([клієнт])-. локальний
трафік .-> local_ssh[Локальний SSH
SOCKS5 проксі]; end local_ssh[SSH
SOCKS5
проксі]-- SSH-тунель -->sshd subgraph remote[Віддалений сервер] sshd[SSH
сервер]-- локальний трафік -->service1; end client([клієнт])-. проксійований HTTPS-трафік
проходить через проксі .->service1[Kubernetes API]; classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000; classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5; class ingress,service1,service2,pod1,pod2,pod3,pod4 k8s; class client plain; class cluster cluster;
Схема 1. Компоненти уроку про SOCKS5

Використання ssh для створення SOCKS5-проксі

Наступна команда запускає SOCKS5-проксі між вашим клієнтським компʼютером і віддаленим SOCKS-сервером:

# SSH-тунель продовжує працювати у фоновому режимі після виконання цієї команди
ssh -D 1080 -q -N username@kubernetes-remote-server.example

SOCKS5-проксі дозволяє вам підключатися до сервера API вашого кластера на основі наступної конфігурації:

  • -D 1080: відкриває SOCKS-проксі на локальному порту :1080.
  • -q: тихий режим. Приглушує більшість попереджень і діагностичних повідомлень.
  • -N: не виконувати віддалені команди. Корисно для простого пересилання портів.
  • username@kubernetes-remote-server.example: віддалений SSH-сервер, за яким працює кластер Kubernetes (наприклад, bastion host).

Конфігурація клієнта

Щоб отримати доступ до сервера Kubernetes API через проксі, вам потрібно вказати kubectl надсилати запити через створений раніше SOCKS проксі. Зробіть це або налаштуванням відповідної змінної середовища, або через атрибут proxy-url у файлі kubeconfig. Використання змінної середовища:

export HTTPS_PROXY=socks5://localhost:1080

Щоб завжди використовувати це налаштування в конкретному контексті kubectl, вкажіть атрибут proxy-url у відповідному записі cluster у файлі ~/.kube/config. Наприклад:

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: LRMEMMW2 # скорочено для читабельності
    server: https://<API_SERVER_IP_ADDRESS>:6443  # сервер "Kubernetes API", тобто IP-адреса kubernetes-remote-server.example
    proxy-url: socks5://localhost:1080   # "SSH SOCKS5 проксі" на діаграмі вище
  name: default
contexts:
- context:
    cluster: default
    user: default
  name: default
current-context: default
kind: Config
preferences: {}
users:
- name: default
  user:
    client-certificate-data: LS0tLS1CR== # скорочено для читабельності
    client-key-data: LS0tLS1CRUdJT=      # скорочено для читабельності

Після створення тунелю через команду ssh, зазначену вище, і визначення змінної середовища або атрибуту proxy-url, ви можете взаємодіяти з вашим кластером через цей проксі. Наприклад:

kubectl get pods
NAMESPACE     NAME                                     READY   STATUS      RESTARTS   AGE
kube-system   coredns-85cb69466-klwq8                  1/1     Running     0          5m46s

Очищення

Зупиніть процес пересилання портів ssh, натиснувши CTRL+C у терміналі, де він працює.

Введіть unset https_proxy у терміналі, щоб припинити пересилання HTTP-трафіку через проксі.

Додаткові матеріали

4.11.7 - Налаштування служби Konnectivity

Служба Konnectivity надає проксі на рівні TCP для комунікації між панеллю управління та кластером.

Перш ніж ви розпочнете

Вам потрібно мати кластер Kubernetes, а також інструмент командного рядка kubectl повинен бути налаштований на звʼязок з вашим кластером. Рекомендується виконувати цей посібник на кластері з щонайменше двома вузлами, які не є хостами панелі управління. Якщо у вас ще немає кластера, ви можете створити його за допомогою minikube.

Налаштування служби Konnectivity

Для виконання наступних кроків потрібна конфігурація egress, наприклад:

apiVersion: apiserver.k8s.io/v1beta1
kind: EgressSelectorConfiguration
egressSelections:
# Оскільки ми хочемо контролювати вихідний трафік з кластеру, ми використовуємо
# "cluster" як назву. Інші підтримувані значення: "etcd" та "controlplane".
- name: cluster
  connection:
    # Це керує протоколом між API-сервером та сервером Konnectivity.
    # Підтримувані значення: "GRPC" та "HTTPConnect". Між двома режимами
    # немає відмінностей для кінцевого користувача. Вам потрібно встановити
    # сервер Konnectivity в тому ж режимі.
    proxyProtocol: GRPC
    transport:
      # Це керує транспортом, який використовує API-сервер для спілкування з
      # сервером Konnectivity. Якщо сервер Konnectivity розташований на тому ж
      # компʼютері, рекомендується використовувати UDS. Вам потрібно налаштувати
      # сервер Konnectivity на прослуховування того самого UDS-сокету.
      # Інший підтримуваний транспорт - "tcp". Вам потрібно налаштувати TLS-конфігурацію
      # для захисту TCP-транспорту.
      uds:
        udsName: /etc/kubernetes/konnectivity-server/konnectivity-server.socket

Вам потрібно налаштувати API-сервер для використання служби Konnectivity та направлення мережевого трафіку на вузли кластера:

  1. Переконайтеся, що функція Проєкція токенів службових облікових записів увімкенна у вашому кластері. Вона є типово увімкненою з версії Kubernetes v1.20.

  2. Створіть файл конфігурації egress, наприклад admin/konnectivity/egress-selector-configuration.yaml.

  3. Встановіть прапорець --egress-selector-config-file API-сервера на шлях до файлу конфігурації виходу API-сервера.

  4. Якщо ви використовуєте з'ʼєднання UDS, додайте конфігурацію томів до kube-apiserver:

    spec:
      containers:
        volumeMounts:
        - name: konnectivity-uds
          mountPath: /etc/kubernetes/konnectivity-server
          readOnly: false
      volumes:
      - name: konnectivity-uds
        hostPath:
          path: /etc/kubernetes/konnectivity-server
          type: DirectoryOrCreate
    

Згенеруйте або отримайте сертифікат та kubeconfig для konnectivity-server. Наприклад, ви можете використовувати інструмент командного рядка OpenSSL для створення сертифіката X.509, використовуючи сертифікат CA кластера /etc/kubernetes/pki/ca.crt з хосту панелі управління.

openssl req -subj "/CN=system:konnectivity-server" -new -newkey rsa:2048 -nodes -out konnectivity.csr -keyout konnectivity.key
openssl x509 -req -in konnectivity.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out konnectivity.crt -days 375 -sha256
SERVER=$(kubectl config view -o jsonpath='{.clusters..server}')
kubectl --kubeconfig /etc/kubernetes/konnectivity-server.conf config set-credentials system:konnectivity-server --client-certificate konnectivity.crt --client-key konnectivity.key --embed-certs=true
kubectl --kubeconfig /etc/kubernetes/konnectivity-server.conf config set-cluster kubernetes --server "$SERVER" --certificate-authority /etc/kubernetes/pki/ca.crt --embed-certs=true
kubectl --kubeconfig /etc/kubernetes/konnectivity-server.conf config set-context system:konnectivity-server@kubernetes --cluster kubernetes --user system:konnectivity-server
kubectl --kubeconfig /etc/kubernetes/konnectivity-server.conf config use-context system:konnectivity-server@kubernetes
rm -f konnectivity.crt konnectivity.key konnectivity.csr

Потім вам потрібно розгорнути сервер Konnectivity та агентів. kubernetes-sigs/apiserver-network-proxy є посиланням на референсну реалізацію.

Розгорніть сервер Konnectivity на ваших вузлах панелі управління. Наданий маніфест konnectivity-server.yaml передбачає, що компоненти Kubernetes розгорнуті як статичний Pod у вашому кластері. Якщо ні, ви можете розгорнути сервер Konnectivity як DaemonSet.

apiVersion: v1
kind: Pod
metadata:
  name: konnectivity-server
  namespace: kube-system
spec:
  priorityClassName: system-cluster-critical
  hostNetwork: true
  containers:
  - name: konnectivity-server-container
    image: registry.k8s.io/kas-network-proxy/proxy-server:v0.0.37
    command: ["/proxy-server"]
    args: [
            "--logtostderr=true",
            # Це повинно збігатися зі значенням, встановленим у egressSelectorConfiguration.
            "--uds-name=/etc/kubernetes/konnectivity-server/konnectivity-server.socket",
            "--delete-existing-uds-file",
            # Наступні два рядки передбачають, що сервер Konnectivity
            # розгорнуто на тому ж компʼютері, що й apiserver, і сертифікати та
            # ключ API-сервера знаходяться за вказаною шляхом.
            "--cluster-cert=/etc/kubernetes/pki/apiserver.crt",
            "--cluster-key=/etc/kubernetes/pki/apiserver.key",
            # Це повинно збігатися зі значенням, встановленим у egressSelectorConfiguration.
            "--mode=grpc",
            "--server-port=0",
            "--agent-port=8132",
            "--admin-port=8133",
            "--health-port=8134",
            "--agent-namespace=kube-system",
            "--agent-service-account=konnectivity-agent",
            "--kubeconfig=/etc/kubernetes/konnectivity-server.conf",
            "--authentication-audience=system:konnectivity-server"
            ]
    livenessProbe:
      httpGet:
        scheme: HTTP
        host: 127.0.0.1
        port: 8134
        path: /healthz
      initialDelaySeconds: 30
      timeoutSeconds: 60
    ports:
    - name: agentport
      containerPort: 8132
      hostPort: 8132
    - name: adminport
      containerPort: 8133
      hostPort: 8133
    - name: healthport
      containerPort: 8134
      hostPort: 8134
    volumeMounts:
    - name: k8s-certs
      mountPath: /etc/kubernetes/pki
      readOnly: true
    - name: kubeconfig
      mountPath: /etc/kubernetes/konnectivity-server.conf
      readOnly: true
    - name: konnectivity-uds
      mountPath: /etc/kubernetes/konnectivity-server
      readOnly: false
  volumes:
  - name: k8s-certs
    hostPath:
      path: /etc/kubernetes/pki
  - name: kubeconfig
    hostPath:
      path: /etc/kubernetes/konnectivity-server.conf
      type: FileOrCreate
  - name: konnectivity-uds
    hostPath:
      path: /etc/kubernetes/konnectivity-server
      type: DirectoryOrCreate

Потім розгорніть агентів Konnectivity у вашому кластері:

apiVersion: apps/v1
# Instead of this, you can deploy agents as Deployments. It is not necessary to have an agent on each node.
kind: DaemonSet
metadata:
  labels:
    addonmanager.kubernetes.io/mode: Reconcile
    k8s-app: konnectivity-agent
  namespace: kube-system
  name: konnectivity-agent
spec:
  selector:
    matchLabels:
      k8s-app: konnectivity-agent
  template:
    metadata:
      labels:
        k8s-app: konnectivity-agent
    spec:
      priorityClassName: system-cluster-critical
      tolerations:
        - key: "CriticalAddonsOnly"
          operator: "Exists"
      containers:
        - image: us.gcr.io/k8s-artifacts-prod/kas-network-proxy/proxy-agent:v0.0.37
          name: konnectivity-agent
          command: ["/proxy-agent"]
          args: [
                  "--logtostderr=true",
                  "--ca-cert=/var/run/secrets/kubernetes.io/serviceaccount/ca.crt",
                  # Оскільки сервер konnectivity працює з hostNetwork=true,
                  # це є IP-адреса машини-майстра.
                  "--proxy-server-host=35.225.206.7",
                  "--proxy-server-port=8132",
                  "--admin-server-port=8133",
                  "--health-server-port=8134",
                  "--service-account-token-path=/var/run/secrets/tokens/konnectivity-agent-token"
                  ]
          volumeMounts:
            - mountPath: /var/run/secrets/tokens
              name: konnectivity-agent-token
          livenessProbe:
            httpGet:
              port: 8134
              path: /healthz
            initialDelaySeconds: 15
            timeoutSeconds: 15
      serviceAccountName: konnectivity-agent
      volumes:
        - name: konnectivity-agent-token
          projected:
            sources:
              - serviceAccountToken:
                  path: konnectivity-agent-token
                  audience: system:konnectivity-server

Нарешті, якщо RBAC включено у вашому кластері, створіть відповідні правила RBAC:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: system:konnectivity-server
  labels:
    kubernetes.io/cluster-service: "true"
    addonmanager.kubernetes.io/mode: Reconcile
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:auth-delegator
subjects:
  - apiGroup: rbac.authorization.k8s.io
    kind: User
    name: system:konnectivity-server
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: konnectivity-agent
  namespace: kube-system
  labels:
    kubernetes.io/cluster-service: "true"
    addonmanager.kubernetes.io/mode: Reconcile

4.12 - TLS

Дізнайтесь, як захистити трафік у вашому кластері за допомогою TLS (Transport Layer Security).

4.12.1 - Налаштування ротації сертифікатів для Kubelet

Ця сторінка показує, як увімкнути та налаштувати ротацію сертифікатів для kubelet.

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.19 [stable]

Перш ніж ви розпочнете

  • Потрібна версія Kubernetes 1.8.0 або пізніша

Огляд

Kubelet використовує сертифікати для автентифікації в Kubernetes API. Типово ці сертифікати створюються з терміном дії один рік, щоб їх не потрібно було оновлювати занадто часто.

Kubernetes містить ротацію сертифікатів kubelet, яка автоматично генерує новий ключ і запитує новий сертифікат від Kubernetes API, коли поточний сертифікат наближається до закінчення терміну дії. Коли новий сертифікат стає доступним, він буде використовуватись для автентифікації зʼєднань з Kubernetes API.

Увімкнення ротації клієнтських сертифікатів

Процес kubelet приймає аргумент --rotate-certificates, який контролює, чи буде kubelet автоматично запитувати новий сертифікат, коли наближається термін дії поточного сертифіката.

Процес kube-controller-manager приймає аргумент --cluster-signing-duration (--experimental-cluster-signing-duration до версії 1.19), який контролює, на який термін будуть випускатись сертифікати.

Розуміння налаштувань ротації сертифікатів

Коли kubelet запускається, якщо він налаштований для початкового завантаження (використовуючи прапорець --bootstrap-kubeconfig), він використовуватиме свій початковий сертифікат для підключення до Kubernetes API та надсилатиме запит на підписання сертифіката. Ви можете переглянути статус запитів на підписання сертифікатів за допомогою:

kubectl get csr

Спочатку запит на підписання сертифіката від kubelet на вузлі матиме статус Pending. Якщо запит на підписання сертифіката відповідає певним критеріям, він буде автоматично схвалений менеджером контролерів, після чого він матиме статус Approved. Далі, менеджер контролерів підпише сертифікат, виданий на термін, вказаний параметром --cluster-signing-duration, і підписаний сертифікат буде прикріплений до запиту на підписання сертифіката.

Kubelet отримає підписаний сертифікат від Kubernetes API та запише його на диск у місці, вказаному параметром --cert-dir. Потім kubelet використовуватиме новий сертифікат для приєднання до Kubernetes API.

Коли наближається закінчення терміну дії підписаного сертифіката, kubelet автоматично надішле новий запит на підписання сертифіката, використовуючи Kubernetes API. Це може статись у будь-який момент між 30% та 10% залишкового часу дії сертифіката. Знову ж таки, менеджер контролерів автоматично схвалить запит на сертифікат і прикріпить підписаний сертифікат до запиту на підписання сертифіката. Kubelet отримає новий підписаний сертифікат від Kubernetes API та запише його на диск. Потім він оновить зʼєднання з Kubernetes API, щоб приєднатись за допомогою нового сертифіката.

4.12.2 - Ручна ротація сертифікатів центру сертифікації (CA)

Ця сторінка показує, як робити вручну ротацію сертифікатів центру сертифікації (CA).

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

  • Для отримання додаткової інформації про автентифікацію в Kubernetes, див. Автентифікація.
  • Для отримання додаткової інформації про найкращі практики для сертифікатів CA, див. Один кореневий CA.

Ручна ротація сертифікатів CA

  1. Розподіліть нові сертифікати CA та приватні ключі (наприклад: ca.crt, ca.key, front-proxy-ca.crt і front-proxy-ca.key) на всі вузли вашої панелі управління у теці сертифікатів Kubernetes.

  2. Оновіть прапорець --root-ca-file для kube-controller-manager, щоб включити як старий, так і новий CA, після чого перезавантажте kube-controller-manager.

    Будь-який ServiceAccount, створений після цього, отримає Secretʼи, що містять як старий, так і новий CA.

  3. Зачекайте, поки менеджер контролерів оновить ca.crt у Secretʼах облікових записів сервісів, щоб включити як старі, так і нові сертифікати CA.

    Якщо будь-які Podʼи були запущені до того, як новий CA буде використаний серверами API, нові Podʼи отримають це оновлення та будуть довіряти як старим, так і новим CA.

  4. Перезавантажте всі Podʼи, що використовують внутрішні конфігурації (наприклад: kube-proxy, CoreDNS тощо), щоб вони могли використовувати оновлені дані сертифікату центру сертифікації із Secretʼів, що повʼязані з ServiceAccounts.

    • Переконайтеся, що CoreDNS, kube-proxy та інші Podʼи, що використовують внутрішні конфігурації, працюють належним чином.
  5. Додайте як старий, так і новий CA до файлу, зазначеного у прапорці --client-ca-file та --kubelet-certificate-authority в конфігурації kube-apiserver.

  6. Додайте як старий, так і новий CA до файлу, зазначеного у прапорці --client-ca-file в конфігурації kube-scheduler.

  7. Оновіть сертифікати для облікових записів користувачів, замінивши вміст client-certificate-data та client-key-data.

    Для отримання інформації про створення сертифікатів для індивідуальних облікових записів користувачів, див. Налаштування сертифікатів для облікових записів користувачів.

    Крім того, оновіть розділ certificate-authority-data у kubeconfig файлах, відповідно до закодованих у Base64 даних старого та нового центру сертифікації.

  8. Оновіть прапорець --root-ca-file для Cloud Controller Manager, щоб включити як старий, так і новий CA, після чого перезавантажте cloud-controller-manager.

  9. Виконайте наступні кроки поступово.

    1. Перезавантажте будь-які інші агреговані сервери API або обробники вебхуків, щоб довіряти новим сертифікатам CA.

    2. Перезавантажте kubelet, оновивши файл, зазначений у clientCAFile в конфігурації kubelet, та certificate-authority-data у kubelet.conf, щоб використовувати як старий, так і новий CA на всіх вузлах.

      Якщо ваш kubelet не використовує ротацію клієнтських сертифікатів, оновіть client-certificate-data та client-key-data у kubelet.conf на всіх вузлах разом із файлом клієнтського сертифіката kubelet, зазвичай розташованим у /var/lib/kubelet/pki.

    3. Перезавантажте сервери API із сертифікатами (apiserver.crt, apiserver-kubelet-client.crt та front-proxy-client.crt), підписаними новим CA. Ви можете використовувати наявні приватні ключі або нові приватні ключі. Якщо ви змінили приватні ключі, то також оновіть їх у теці сертифікатів Kubernetes.

      Оскільки Podʼи у вашому кластері довіряють як старим, так і новим CA, буде короткочасне відключення, після чого клієнти Kubernetes у Podʼах переприєднаються до нового сервера API. Новий сервер API використовує сертифікат, підписаний новим CA.

      • Перезавантажте kube-scheduler, щоб використовувати та довіряти новим CA.
      • Переконайтеся, що логи компонентів панелі управління не містять помилок TLS.
    4. Анотуйте будь-які DaemonSets та Deployments, щоб викликати заміну Podʼів у більш безпечний спосіб.

      for namespace in $(kubectl get namespace -o jsonpath='{.items[*].metadata.name}'); do
          for name in $(kubectl get deployments -n $namespace -o jsonpath='{.items[*].metadata.name}'); do
              kubectl patch deployment -n ${namespace} ${name} -p '{"spec":{"template":{"metadata":{"annotations":{"ca-rotation": "1"}}}}}';
          done
          for name in $(kubectl get daemonset -n $namespace -o jsonpath='{.items[*].metadata.name}'); do
              kubectl patch daemonset -n ${namespace} ${name} -p '{"spec":{"template":{"metadata":{"annotations":{"ca-rotation": "1"}}}}}';
          done
      done
      

      Залежно від того, як ви використовуєте StatefulSets, вам також може знадобитися виконати подібну поступову заміну.

  10. Якщо ваш кластер використовує токени для початкового завантаження для приєднання вузлів, оновіть ConfigMap cluster-info в просторі імен kube-public з новим CA.

    base64_encoded_ca="$(base64 -w0 /etc/kubernetes/pki/ca.crt)"
    
    kubectl get cm/cluster-info --namespace kube-public -o yaml | \
        /bin/sed "s/\(certificate-authority-data:\).*/\1 ${base64_encoded_ca}/" | \
        kubectl apply -f -
    
  11. Перевірте функціональність кластера.

    1. Перевірте логи компонентів панелі управління, а також kubelet та kube-proxy. Переконайтеся, що ці компоненти не повідомляють про помилки TLS; див. перегляд журналів для отримання додаткових деталей.

    2. Перевірте логи будь-яких агрегованих серверів API та Podʼів, що використовують внутрішню конфігурацію.

  12. Після успішної перевірки функціональності кластера:

    1. Оновіть всі токени службових облікових записів, щоб включити лише новий сертифікат CA.

      • Всі Podʼи, що використовують внутрішній kubeconfig, згодом потрібно буде перезапустити, щоб отримати новий Secret, щоб жоден Pod не залежав від старого CA кластера.
    2. Перезавантажте компоненти панелі управління, видаливши старий CA з kubeconfig файлів та файлів, зазначених у прапорцях --client-ca-file та --root-ca-file.

    3. На кожному вузлі перезавантажте kubelet, видаливши старий CA з файлу, зазначеного у прапорі clientCAFile, та з файлу kubeconfig для kubelet. Ви повинні виконати це як поступове оновлення.

      Якщо ваш кластер дозволяє вам внести цю зміну, ви також можете здійснити це шляхом заміни вузлів, а не їх переконфігурування.

4.12.3 - Управління TLS сертифікатами в кластері

Kubernetes надає API certificates.k8s.io, який дозволяє вам отримувати TLS сертифікати, підписані Центром Сертифікації (CA), який ви контролюєте. Ці CA та сертифікати можуть використовуватися вашими робочими навантаженнями для встановлення довіри.

API certificates.k8s.io використовує протокол, подібний до чернетки ACME.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Вам потрібен інструмент cfssl. Ви можете завантажити cfssl з https://github.com/cloudflare/cfssl/releases.

Деякі кроки на цій сторінці використовують інструмент jq. Якщо у вас його немає, ви можете встановити його через джерела програмного забезпечення вашої операційної системи або завантажити з https://jqlang.github.io/jq/.

Довіра до TLS в кластері

Довіра до власного CA з боку застосунків, що працюють як Podʼи, зазвичай вимагає додаткової конфігурації. Вам потрібно додати пакет сертифікатів CA до списку сертифікатів CA, яким довіряє TLS клієнт або сервер. Наприклад, ви можете зробити це за допомогою налаштування TLS в Golang, проаналізувавши ланцюжок сертифікатів і додавши проаналізовані сертифікати до поля RootCAs в структурі tls.Config.

Запит сертифіката

Наступний розділ демонструє, як створити TLS сертифікат для Kubernetes сервісу, до якого звертаються через DNS.

Створення запиту на підписання сертифіката

Згенеруйте приватний ключ і запит на підписання сертифіката (або CSR), виконавши наступну команду:

cat <<EOF | cfssl genkey - | cfssljson -bare server
{
  "hosts": [
    "my-svc.my-namespace.svc.cluster.local",
    "my-pod.my-namespace.pod.cluster.local",
    "192.0.2.24",
    "10.0.34.2"
  ],
  "CN": "my-pod.my-namespace.pod.cluster.local",
  "key": {
    "algo": "ecdsa",
    "size": 256
  }
}
EOF

Де 192.0.2.24 — це кластерний IP Serviceʼу, my-svc.my-namespace.svc.cluster.local — це DNS-імʼя Serviceʼу, 10.0.34.2 —це IP Podʼа, а my-pod.my-namespace.pod.cluster.local — це DNS-імʼя Podʼа. Ви повинні побачити вивід подібний до:

2022/02/01 11:45:32 [INFO] generate received request
2022/02/01 11:45:32 [INFO] received CSR
2022/02/01 11:45:32 [INFO] generating key: ecdsa-256
2022/02/01 11:45:32 [INFO] encoded CSR

Ця команда генерує два файли; server.csr, що містить PEM закодований PKCS#10 запит на сертифікат, і server-key.pem, що містить PEM закодований ключ до сертифіката, який ще потрібно створити.

Створення обʼєкта CertificateSigningRequest для надсилання до Kubernetes API

Згенеруйте маніфест CSR (у форматі YAML) і надішліть його на сервер API. Ви можете зробити це, виконавши наступну команду:

cat <<EOF | kubectl apply -f -
apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: my-svc.my-namespace
spec:
  request: $(cat server.csr | base64 | tr -d '\n')
  signerName: example.com/serving
  usages:
  - digital signature
  - key encipherment
  - server auth
EOF

Зверніть увагу, що файл server.csr, створений на кроці 1, кодується base64 та зберігається в полі .spec.request. Ви також запитуєте сертифікат з використанням ключів "digital signature", "key encipherment" і "server auth", підписаний підписувачем example.com/serving. Повинен бути запитаний конкретний signerName. Перегляньте документацію для підтримуваних імен підписувачів для отримання додаткової інформації.

CSR тепер має бути видимий з API у стані Pending. Ви можете побачити це, виконавши:

kubectl describe csr my-svc.my-namespace
Name:                   my-svc.my-namespace
Labels:                 <none>
Annotations:            <none>
CreationTimestamp:      Tue, 01 Feb 2022 11:49:15 -0500
Requesting User:        yourname@example.com
Signer:                 example.com/serving
Status:                 Pending
Subject:
        Common Name:    my-pod.my-namespace.pod.cluster.local
        Serial Number:
Subject Alternative Names:
        DNS Names:      my-pod.my-namespace.pod.cluster.local
                        my-svc.my-namespace.svc.cluster.local
        IP Addresses:   192.0.2.24
                        10.0.34.2
Events: <none>

Отримання схвалення CertificateSigningRequest

Схвалення запиту на підписання сертифіката виконується або автоматичною процедурою схвалення, або одноразово адміністратором кластера. Якщо у вас є дозвіл на схвалення запиту на сертифікат, ви можете зробити це вручну за допомогою kubectl; наприклад:

kubectl certificate approve my-svc.my-namespace
certificatesigningrequest.certificates.k8s.io/my-svc.my-namespace approved

Ви тепер повинні побачити наступне:

kubectl get csr
NAME                  AGE   SIGNERNAME            REQUEST

OR              REQUESTEDDURATION   CONDITION
my-svc.my-namespace   10m   example.com/serving   yourname@example.com   <none>              Approved

Це означає, що запит на сертифікат був схвалений і чекає на підписання запрошеним підписувачем.

Підписання CertificateSigningRequest

Далі ви зіграєте роль підписувача сертифікатів, видасте сертифікат і завантажите його в API.

Підписувач зазвичай спостерігає за API CertificateSigningRequest для обʼєктів з його signerName, перевіряє, що вони були схвалені, підписує сертифікати для цих запитів, і оновлює статус обʼєкта API з виданим сертифікатом.

Створення Центру Сертифікації

Вам потрібен центр сертифікації, щоб забезпечити цифровий підпис нового сертифікату.

Спочатку створіть підписний сертифікат, виконавши наступне:

cat <<EOF | cfssl gencert -initca - | cfssljson -bare ca
{
  "CN": "My Example Signer",
  "key": {
    "algo": "rsa",
    "size": 2048
  }
}
EOF

Ви повинні побачити вивід подібний до:

2022/02/01 11:50:39 [INFO] generating a new CA key and certificate from CSR
2022/02/01 11:50:39 [INFO] generate received request
2022/02/01 11:50:39 [INFO] received CSR
2022/02/01 11:50:39 [INFO] generating key: rsa-2048
2022/02/01 11:50:39 [INFO] encoded CSR
2022/02/01 11:50:39 [INFO] signed certificate with serial number 263983151013686720899716354349605500797834580472

Це створює файл ключа центру сертифікації (ca-key.pem) і сертифікат (ca.pem).

Видача сертифіката

{
    "signing": {
        "default": {
            "usages": [
                "digital signature",
                "key encipherment",
                "server auth"
            ],
            "expiry": "876000h",
            "ca_constraint": {
                "is_ca": false
            }
        }
    }
}

Використовуйте конфігурацію для підпису server-signing-config.json та файл ключа центру сертифікації та сертифікат для підпису запиту на сертифікат:

kubectl get csr my-svc.my-namespace -o jsonpath='{.spec.request}' | \
  base64 --decode | \
  cfssl sign -ca ca.pem -ca-key ca-key.pem -config server-signing-config.json - | \
  cfssljson -bare ca-signed-server

Ви повинні побачити вивід подібний до:

2022/02/01 11:52:26 [INFO] signed certificate with serial number 576048928624926584381415936700914530534472870337

Це створює файл підписаного серверного сертифіката, ca-signed-server.pem.

Завантаження підписаного сертифіката

Нарешті, вкажіть підписаний сертифікат у статусі обʼєкта API:

kubectl get csr my-svc.my-namespace -o json | \
  jq '.status.certificate = "'$(base64 ca-signed-server.pem | tr -d '\n')'"' | \
  kubectl replace --raw /apis/certificates.k8s.io/v1/certificatesigningrequests/my-svc.my-namespace/status -f -

Після схвалення CSR і завантаження підписаного сертифіката, виконайте:

kubectl get csr

Вивід буде подібним до:

NAME                  AGE   SIGNERNAME            REQUESTOR              REQUESTEDDURATION   CONDITION
my-svc.my-namespace   20m   example.com/serving   yourname@example.com   <none>              Approved,Issued

Завантаження сертифіката та його використання

Тепер, як запитувач, ви можете завантажити виданий сертифікат і зберегти його у файл server.crt, виконавши наступне:

kubectl get csr my-svc.my-namespace -o jsonpath='{.status.certificate}' \
    | base64 --decode > server.crt

Тепер ви можете заповнити server.crt і server-key.pem у Секрет, який ви можете пізніше монтувати в Pod (наприклад, для використання з вебсервером, який обслуговує HTTPS).

kubectl create secret tls server --cert server.crt --key server-key.pem
secret/server created

Нарешті, ви можете заповнити ca.pem у ConfigMap і використовувати його як кореневий довірчий сертифікат для перевірки серверного сертифіката:

kubectl create configmap example-serving-ca --from-file ca.crt=ca.pem
configmap/example-serving-ca created

Схвалення CertificateSigningRequests

Адміністратор Kubernetes (з відповідними дозволами) може вручну схвалювати (або відхиляти) CertificateSigningRequests за допомогою команд kubectl certificate approve та kubectl certificate deny. Однак, якщо ви плануєте активно використовувати цей API, варто розглянути можливість написання автоматизованого контролера сертифікатів.

Чи це буде машина або людина, яка використовує kubectl, роль схвалювача полягає у перевірці, що CSR відповідає двом вимогам:

  1. Субʼєкт CSR контролює приватний ключ, який використовується для підписання CSR. Це зменшує ризик того, що є третя сторона, яка видає себе за авторизованого субʼєкта. У вищезазначеному прикладі цей крок передбачає перевірку того, що Pod контролює приватний ключ, який використовується для створення CSR.
  2. Субʼєкт CSR має право діяти в запитуваному контексті. Це зменшує ризик появи небажаного субʼєкта, який приєднується до кластера. У вищезазначеному прикладі цей крок передбачає перевірку того, що Pod має дозвіл на участь у запитуваному сервісі.

Якщо і тільки якщо ці дві вимоги виконані, схвалювач повинен схвалити CSR інакше він повинен відхилити CSR.

Для отримання додаткової інформації про схвалення сертифікатів та контроль доступу, прочитайте сторінку довідника Запити на підписання сертифікатів.

Налаштування вашого кластера для виконання накладання підписів

Ця сторінка припускає, що підписувач налаштований для обслуговування API сертифікатів. Менеджер контролерів Kubernetes надає стандартну реалізацію підписувача. Щоб увімкнути його, передайте параметри --cluster-signing-cert-file та --cluster-signing-key-file до менеджера контролерів з шляхами до пари ключів вашого центру сертифікації.

4.13 - Керування фоновими процесами кластера

Виконуйте загальні завдання для керування DaemonSet, такі як виконання поступового оновлення.

4.13.1 - Виконання поетапного оновлення DaemonSet

Ця сторінка показує, як виконати поетапне оновлення (rolling update) DaemonSet.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Стратегія оновлення DaemonSet

DaemonSet має два типи стратегій оновлення:

  • OnDelete: Зі стратегією оновлення OnDelete, після оновлення шаблону DaemonSet нові Podʼи DaemonSet будуть створюватися лише після вручну видалених старих Podʼів DaemonSet. Це та ж поведінка, що й у версії Kubernetes 1.5 або раніше.
  • RollingUpdate: Це стандартна стратегія оновлення. Зі стратегією оновлення RollingUpdate, після оновлення шаблону DaemonSet старі Podʼи DaemonSet будуть видалені, і нові Podʼи DaemonSet будуть створені автоматично, у контрольованому режимі. Під час усього процесу оновлення на кожному вузлі працюватиме максимум один Pod DaemonSet.

Виконання поетапного оновлення

Щоб увімкнути функцію поетапного оновлення DaemonSet, необхідно встановити .spec.updateStrategy.type на RollingUpdate.

Ви можете також встановити значення .spec.updateStrategy.rollingUpdate.maxUnavailable (типово 1), .spec.minReadySeconds (типово 0) та .spec.updateStrategy.rollingUpdate.maxSurge (типово 0).

Створення DaemonSet зі стратегією оновлення RollingUpdate

Цей YAML файл задає DaemonSet зі стратегією оновлення RollingUpdate:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd-elasticsearch
  namespace: kube-system
  labels:
    k8s-app: fluentd-logging
spec:
  selector:
    matchLabels:
      name: fluentd-elasticsearch
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
  template:
    metadata:
      labels:
        name: fluentd-elasticsearch
    spec:
      tolerations:
      # ці tolerations дозволяють запускати DaemonSet на вузлах панелі управління
      # видаліть їх, якщо ваші вузли панелі управління не повинні запускати Podʼи
      - key: node-role.kubernetes.io/control-plane
        operator: Exists
        effect: NoSchedule
      - key: node-role.kubernetes.io/master
        operator: Exists
        effect: NoSchedule
      containers:
      - name: fluentd-elasticsearch
        image: quay.io/fluentd_elasticsearch/fluentd:v2.5.2
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        - name: varlibdockercontainers
          mountPath: /var/lib/docker/containers
          readOnly: true
      terminationGracePeriodSeconds: 30
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
      - name: varlibdockercontainers
        hostPath:
          path: /var/lib/docker/containers

Після перевірки стратегії оновлення в маніфесті DaemonSet, створіть DaemonSet:

kubectl create -f https://k8s.io/examples/controllers/fluentd-daemonset.yaml

Або скористайтесь командою kubectl apply, щоб створити той самий DaemonSet, якщо ви плануєте оновлювати DaemonSet за допомогою kubectl apply.

kubectl apply -f https://k8s.io/examples/controllers/fluentd-daemonset.yaml

Перевірка стратегії оновлення RollingUpdate у DaemonSet

Перевірте стратегію оновлення вашого DaemonSet і переконайтесь, що вона встановлена на RollingUpdate:

kubectl get ds/fluentd-elasticsearch -o go-template='{{.spec.updateStrategy.type}}{{"\n"}}' -n kube-system

Якщо ви ще не створили DaemonSet у системі, перевірте ваш маніфест DaemonSet за допомогою наступної команди:

kubectl apply -f https://k8s.io/examples/controllers/fluentd-daemonset.yaml --dry-run=client -o go-template='{{.spec.updateStrategy.type}}{{"\n"}}'

Вивід обох команд повинен бути таким:

RollingUpdate

Якщо вивід не RollingUpdate, поверніться назад і змініть обʼєкт DaemonSet або його маніфест відповідно.

Оновлення шаблону DaemonSet

Будь-які оновлення до .spec.template RollingUpdate DaemonSet викличуть поетапне оновлення. Оновімо DaemonSet, застосувавши новий YAML файл. Це можна зробити за допомогою кількох різних команд kubectl.

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd-elasticsearch
  namespace: kube-system
  labels:
    k8s-app: fluentd-logging
spec:
  selector:
    matchLabels:
      name: fluentd-elasticsearch
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
  template:
    metadata:
      labels:
        name: fluentd-elasticsearch
    spec:
      tolerations:
      # ці tolerations дозволяють запускати DaemonSet на вузлах панелі управління
      # видаліть їх, якщо ваші вузли панелі управління не повинні запускати Podʼи
      - key: node-role.kubernetes.io/control-plane
        operator: Exists
        effect: NoSchedule
      - key: node-role.kubernetes.io/master
        operator: Exists
        effect: NoSchedule
      containers:
      - name: fluentd-elasticsearch
        image: quay.io/fluentd_elasticsearch/fluentd:v2.5.2
        resources:
          limits:
            memory: 200Mi
          requests:
            cpu: 100m
            memory: 200Mi
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        - name: varlibdockercontainers
          mountPath: /var/lib/docker/containers
          readOnly: true
      terminationGracePeriodSeconds: 30
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
      - name: varlibdockercontainers
        hostPath:
          path: /var/lib/docker/containers

Декларативні команди

Якщо ви оновлюєте DaemonSets за допомогою конфігураційних файлів, використовуйте kubectl apply:

kubectl apply -f https://k8s.io/examples/controllers/fluentd-daemonset-update.yaml

Імперативні команди

Якщо ви оновлюєте DaemonSets за допомогою імперативних команд, використовуйте kubectl edit :

kubectl edit ds/fluentd-elasticsearch -n kube-system
Оновлення лише образу контейнера

Якщо вам потрібно оновити лише образ контейнера у шаблоні DaemonSet, тобто .spec.template.spec.containers[*].image, використовуйте kubectl set image:

kubectl set image ds/fluentd-elasticsearch fluentd-elasticsearch=quay.io/fluentd_elasticsearch/fluentd:v2.6.0 -n kube-system

Спостереження за станом поетапного оновлення

Нарешті, спостерігайте за станом останнього поетапного оновлення DaemonSet:

kubectl rollout status ds/fluentd-elasticsearch -n kube-system

Коли оновлення завершиться, вивід буде подібний до цього:

daemonset "fluentd-elasticsearch" successfully rolled out

Усунення несправностей

Поетапне оновлення DaemonSet застрягло

Іноді поетапне оновлення DaemonSet може застрягнути. Ось деякі можливі причини:

Деякі вузли вичерпали ресурси

Оновлення застрягло, оскільки нові Podʼи DaemonSet не можуть бути заплановані на принаймні один вузол. Це можливо, коли вузол вичерпує ресурси.

Коли це трапляється, знайдіть вузли, на яких не заплановані Podʼи DaemonSet, порівнявши вихід kubectl get nodes з виходом:

kubectl get pods -l name=fluentd-elasticsearch -o wide -n kube-system

Після того, як ви знайдете ці вузли, видаліть деякі не-DaemonSet Podʼи з вузла, щоб звільнити місце для нових Podʼіів DaemonSet.

Неправильне оновлення

Якщо недавнє оновлення шаблону DaemonSet є неправильним, наприклад, контейнер зациклюється або образ контейнера не існує (часто через помилку у назві), поетапне оновлення DaemonSet не просуватиметься.

Щоб виправити це, оновіть шаблон DaemonSet ще раз. Нове оновлення не буде блокуватися попередніми несправними оновленнями.

Невідповідність годинників

Якщо у DaemonSet задано значення .spec.minReadySeconds, невідповідність годинників між мастером та вузлами зробить DaemonSet нездатним визначити правильний прогрес оновлення.

Очищення

Видаліть DaemonSet з простору імен:

kubectl delete ds fluentd-elasticsearch -n kube-system

Що далі

4.13.2 - Виконання відкату DaemonSet

Ця сторінка показує, як виконати відкат на DaemonSet.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Версія вашого Kubernetes сервера має бути не старішою ніж 1.7. Для перевірки версії введіть kubectl version.

Ви повинні вже знати, як виконати поетапне оновлення на DaemonSet.

Виконання відкату на DaemonSet

Крок 1: Знайдіть ревізію DaemonSet, до якої ви хочете повернутися

Цей крок можна пропустити, якщо ви хочете повернутися до останньої ревізії.

Перегляньте всі ревізії DaemonSet:

kubectl rollout history daemonset <daemonset-name>

Це поверне список ревізій DaemonSet:

daemonsets "<daemonset-name>"
REVISION        CHANGE-CAUSE
1               ...
2               ...
...
  • Причина зміни копіюється з анотації DaemonSet kubernetes.io/change-cause до його ревізій під час створення. Ви можете вказати --record=true в kubectl, щоб записати команду, виконану в анотації причини зміни.

Щоб переглянути деталі конкретної ревізії:

kubectl rollout history daemonset <daemonset-name> --revision=1

Це поверне деталі цієї ревізії:

daemonsets "<daemonset-name>" with revision #1
Pod Template:
Labels:       foo=bar
Containers:
app:
 Image:        ...
 Port:         ...
 Environment:  ...
 Mounts:       ...
Volumes:      ...

Крок 2: Поверніться до конкретної ревізії DaemonSet

# Вкажіть номер ревізії, отриманий на кроці 1, у --to-revision
kubectl rollout undo daemonset <daemonset-name> --to-revision=<revision>

Якщо команда успішна, вона поверне:

daemonset "<daemonset-name>" rolled back

Крок 3: Спостерігайте за процесом відкату DaemonSet

kubectl rollout undo daemonset вказує серверу почати відкочування DaemonSet. Реальний відкат виконується асинхронно всередині панелі управління кластера.

Щоб спостерігати за процесом відкату:

kubectl rollout status ds/<daemonset-name>

Коли відкочування завершиться, вивід буде подібним до цього:

daemonset "<daemonset-name>" successfully rolled out

Розуміння ревізій DaemonSet

У попередньому кроці kubectl rollout history ви отримали список ревізій DaemonSet. Кожна ревізія зберігається в ресурсі під назвою ControllerRevision.

Щоб побачити, що зберігається в кожній ревізії, знайдіть сирцеві ресурси ревізії DaemonSet:

kubectl get controllerrevision -l <daemonset-selector-key>=<daemonset-selector-value>

Це поверне список ControllerRevisions:

NAME                               CONTROLLER                     REVISION   AGE
<daemonset-name>-<revision-hash>   DaemonSet/<daemonset-name>     1          1h
<daemonset-name>-<revision-hash>   DaemonSet/<daemonset-name>     2          1h

Кожен ControllerRevision зберігає анотації та шаблон ревізії DaemonSet.

kubectl rollout undo бере конкретний ControllerRevision і замінює шаблон DaemonSet на шаблон, збережений у ControllerRevision. kubectl rollout undo еквівалентний оновленню шаблону DaemonSet до попередньої ревізії за допомогою інших команд, таких як kubectl edit або kubectl apply.

Усунення несправностей

4.13.3 - Запуск Podʼів лише на деяких вузлах

Ця сторінка демонструє, як можна запускати Podʼи лише на деяких вузлах як частину DaemonSet

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Запуск Pod лише на деяких вузлах

Уявімо, що ви хочете запустити DaemonSet, але вам потрібно запускати ці Pod демонів лише на вузлах, які мають локальне SSD-сховище. Наприклад, Pod може надавати кеш-сервіс для вузла, і кеш корисний тільки тоді, коли доступне локальне сховище з низькою затримкою.

Крок 1: Додайте мітки до ваших вузлів

Додайте мітку ssd=true до вузлів, які мають SSD.

kubectl label nodes example-node-1 example-node-2 ssd=true

Крок 2: Створіть маніфест

Створімо DaemonSet, який буде запускати Podʼи демонів тільки на вузлах з міткою SSD.

Використайте nodeSelector, щоб забезпечити, що DaemonSet буде запускати Pod лише на вузлах з міткою ssd, значення якої дорівнює "true".

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: ssd-driver
  labels:
    app: nginx
spec:
  selector:
    matchLabels:
      app: ssd-driver-pod
  template:
    metadata:
      labels:
        app: ssd-driver-pod
    spec:
      nodeSelector:
        ssd: "true"
      containers:
        - name: example-container
          image: example-image

Крок 3: Створіть DaemonSet

Створіть DaemonSet з маніфесту, використовуючи kubectl create або kubectl apply.

Додамо мітку ще одному вузлу ssd=true.

kubectl label nodes example-node-3 ssd=true

Додавання мітки вузлу автоматично запускає панель управління (конкретно, контролер DaemonSet), щоб запустити новий Pod для демона на цьому вузлі.

kubectl get pods -o wide

Вивід буде схожим на:

NAME                              READY     STATUS    RESTARTS   AGE    IP      NODE
<daemonset-name><some-hash-01>    1/1       Running   0          13s    .....   example-node-1
<daemonset-name><some-hash-02>    1/1       Running   0          13s    .....   example-node-2
<daemonset-name><some-hash-03>    1/1       Running   0          5s     .....   example-node-3

4.14 - Мережа

Дізнайтесь, як налаштувати мережу для вашого кластера Kubernetes.

4.14.1 - Додавання записів до файлу /etc/hosts у Pod за допомогою HostAliases

Додавання записів до файлу /etc/hosts у Pod надає можливість перевизначення розподілу імен на рівні Pod, коли DNS та інші параметри не застосовуються. Ви можете додавати ці власні записи за допомогою поля HostAliases у PodSpec.

Не рекомендується вносити зміни без використання HostAliases, оскільки файл керується kubelet і може бути перезаписаний під час створення/перезапуску Pod.

Типовий вміст файлу hosts

Запустіть Pod з Nginx, який має призначену IP-адресу Podʼа:

kubectl run nginx --image nginx
pod/nginx created

Перевірте IP-адресу Podʼа:

kubectl get pods --output=wide
NAME     READY     STATUS    RESTARTS   AGE    IP           NODE
nginx    1/1       Running   0          13s    10.200.0.4   worker0

Вміст файлу hosts буде виглядати так:

kubectl exec nginx -- cat /etc/hosts
# Kubernetes-managed hosts file.
127.0.0.1	localhost
::1	localhost ip6-localhost ip6-loopback
fe00::0	ip6-localnet
fe00::0	ip6-mcastprefix
fe00::1	ip6-allnodes
fe00::2	ip6-allrouters
10.200.0.4	nginx

Типово файл hosts містить тільки шаблони IPv4 та IPv6, такі як localhost та власне імʼя хосту.

Додавання додаткових записів за допомогою hostAliases

Крім стандартних шаблонів, ви можете додати додаткові записи до файлу hosts. Наприклад: щоб перевести foo.local, bar.local в 127.0.0.1 та foo.remote, bar.remote в 10.1.2.3, ви можете налаштувати HostAliases для Pod в підполі .spec.hostAliases:

apiVersion: v1
kind: Pod
metadata:
  name: hostaliases-pod
spec:
  restartPolicy: Never
  hostAliases:
  - ip: "127.0.0.1"
    hostnames:
    - "foo.local"
    - "bar.local"
  - ip: "10.1.2.3"
    hostnames:
    - "foo.remote"
    - "bar.remote"
  containers:
  - name: cat-hosts
    image: busybox:1.28
    command:
    - cat
    args:
    - "/etc/hosts"

Ви можете запустити Pod з такою конфігурацією, виконавши:

kubectl apply -f https://k8s.io/examples/service/networking/hostaliases-pod.yaml
pod/hostaliases-pod created

Перевірте деталі Pod, щоб побачити його IPv4-адресу та статус:

kubectl get pod --output=wide
NAME                           READY     STATUS      RESTARTS   AGE       IP              NODE
hostaliases-pod                0/1       Completed   0          6s        10.200.0.5      worker0

Вміст файлу hosts виглядає так:

kubectl logs hostaliases-pod
# Kubernetes-managed hosts file.
127.0.0.1	localhost
::1	localhost ip6-localhost ip6-loopback
fe00::0	ip6-localnet
fe00::0	ip6-mcastprefix
fe00::1	ip6-allnodes
fe00::2	ip6-allrouters
10.200.0.5	hostaliases-pod

# Entries added by HostAliases.
127.0.0.1	foo.local	bar.local
10.1.2.3	foo.remote	bar.remote

з додатковими записами, вказаними внизу.

Чому kubelet керує файлом hosts?

kubelet керує файлом hosts для кожного контейнера Podʼа, щоб запобігти модифікації файлу контейнерним середовищем після того, як контейнери вже були запущені. Історично Kubernetes завжди використовував Docker Engine як своє контейнерне середовище, і Docker Engine модифікував файл /etc/hosts після запуску кожного контейнера.

Поточна версія Kubernetes може використовувати різні контейнерні середовища; проте, kubelet керує файлом hosts у кожному контейнері, щоб результат був таким, як очікувалося, незалежно від використаного контейнерного середовища.

4.14.2 - Розширення діапазонів IP Service

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.31 [beta]

У цьому документі описано, як розширити наявний діапазон IP-адрес, призначених Serviceʼу в кластері.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Версія вашого Kubernetes сервера має бути не старішою ніж v1.29. Для перевірки версії введіть kubectl version.

API

Кластери Kubernetes з kube-apiservers, у яких увімкнено функціональну можливість MultiCIDRServiceAllocator та API networking.k8s.io/v1alpha1, створюватимуть новий обʼєкт ServiceCIDR, який має відоме імʼя kubernetes, та використовуватимуть діапазон IP-адрес, заснований на значенні аргументу командного рядка --service-cluster-ip-range для kube-apiserver.

kubectl get servicecidr
NAME         CIDRS          AGE
kubernetes   10.96.0.0/28   17d

Відомий сервіс kubernetes, який використовується для відкриття точки доступу kube-apiserver для Podʼів, обчислює першу IP-адресу зі стандартного діапазону ServiceCIDR та використовує цю IP-адресу як свою кластерну IP-адресу.

kubectl get service kubernetes
NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   10.96.0.1    <none>        443/TCP   17d

Стандартний Service у цьому випадку використовує ClusterIP 10.96.0.1, що має відповідний обʼєкт IPAddress.

kubectl get ipaddress 10.96.0.1
NAME        PARENTREF
10.96.0.1   services/default/kubernetes

ServiceCIDRs захищені за допомогою завершувачів, щоб уникнути залишання Service ClusterIPs сиріт; завершувач видаляється лише в разі, якщо існує інша підмережа, яка містить наявні IP-адреси або немає IP-адрес, що належать до підмережі.

Розширення кількості доступних IP для Service

Існують випадки, коли користувачам потрібно збільшити кількість доступних адрес для Serviceʼів; раніше, збільшення діапазону Service було руйнівною операцією, яка також може призвести до втрати даних. З цією новою функцією користувачам потрібно лише додати новий ServiceCIDR, щоб збільшити кількість доступних адрес.

Додавання нового ServiceCIDR

У кластері з діапазоном 10.96.0.0/28 для Serviceʼів доступно лише 2^(32-28) - 2 = 14 IP-адрес. Service kubernetes.default завжди створюється; для цього прикладу у вас залишається лише 13 можливих Serviceʼів.

for i in $(seq 1 13); do kubectl create service clusterip "test-$i" --tcp 80 -o json | jq -r .spec.clusterIP; done
10.96.0.11
10.96.0.5
10.96.0.12
10.96.0.13
10.96.0.14
10.96.0.2
10.96.0.3
10.96.0.4
10.96.0.6
10.96.0.7
10.96.0.8
10.96.0.9
error: failed to create ClusterIP service: Internal error occurred: failed to allocate a serviceIP: range is full

Ви можете збільшити кількість IP-адрес, доступних для Serviceʼів, створивши новий ServiceCIDR, який розширює або додає нові діапазони IP-адрес.

cat <EOF | kubectl apply -f -
apiVersion: networking.k8s.io/v1alpha1
kind: ServiceCIDR
metadata:
  name: newcidr1
spec:
  cidrs:
  - 10.96.0.0/24
EOF
servicecidr.networking.k8s.io/newcidr1 created

це дозволить вам створювати нові Service з ClusterIP, які будуть вибрані з цього нового діапазону.

for i in $(seq 13 16); do kubectl create service clusterip "test-$i" --tcp 80 -o json | jq -r .spec.clusterIP; done
10.96.0.48
10.96.0.200
10.96.0.121
10.96.0.144

Видалення ServiceCIDR

Ви не можете видалити ServiceCIDR, якщо існують IP-адреси, які залежать від ServiceCIDR.

kubectl delete servicecidr newcidr1
servicecidr.networking.k8s.io "newcidr1" deleted

Kubernetes використовує завершувач на ServiceCIDR для відстеження цього залежного відношення.

kubectl get servicecidr newcidr1 -o yaml
apiVersion: networking.k8s.io/v1alpha1
kind: ServiceCIDR
metadata:
  creationTimestamp: "2023-10-12T15:11:07Z"
  deletionGracePeriodSeconds: 0
  deletionTimestamp: "2023-10-12T15:12:45Z"
  finalizers:
  - networking.k8s.io/service-cidr-finalizer
  name: newcidr1
  resourceVersion: "1133"
  uid: 5ffd8afe-c78f-4e60-ae76-cec448a8af40
spec:
  cidrs:
  - 10.96.0.0/24
status:
  conditions:
  - lastTransitionTime: "2023-10-12T15:12:45Z"
    message: There are still IPAddresses referencing the ServiceCIDR, please remove
      them or create a new ServiceCIDR
    reason: OrphanIPAddress
    status: "False"
    type: Ready

Видаляючи Serviceʼи, що містять IP-адреси, які блокують видалення ServiceCIDR

for i in $(seq 13 16); do kubectl delete service "test-$i" ; done
service "test-13" deleted
service "test-14" deleted
service "test-15" deleted
service "test-16" deleted

панель управління помічає видалення. Панель управління потім видаляє свій завершувач, так що ServiceCIDR, який був у черзі на видалення, фактично буде видалено.

kubectl get servicecidr newcidr1
Error from server (NotFound): servicecidrs.networking.k8s.io "newcidr1" not found

4.14.3 - Перевірка наявності підтримки подвійного стеку IPv4/IPv6

Цей документ розповідає, як перевірити підтримку dual-stack IPv4/IPv6 в увімкнених кластерах Kubernetes.

Перш ніж ви розпочнете

  • Підтримка постачальника для мереж з підтримкою подвійного стека (постачальник хмарних послуг або інший постачальник повинен забезпечити вузлам Kubernetes мережеві інтерфейси з маршрутними IPv4/IPv6)
  • Втулок мережі, який підтримує dual-stack мережу.
  • Увімкнений подвійний стек кластер
Версія вашого Kubernetes сервера має бути не старішою ніж v1.23. Для перевірки версії введіть kubectl version.

Перевірка адресації

Перевірка адресування вузлів

Кожен вузол з подвійним стеком має мати виділені один блок IPv4 та один блок IPv6. Перевірте, що діапазони адрес IPv4/IPv6 для Pod налаштовані за допомогою наступної команди. Замініть імʼя вузла з прикладу на наявний вузол з подвійним стеком у вашому кластері. У цьому прикладі імʼя вузла — k8s-linuxpool1-34450317-0:

kubectl get nodes k8s-linuxpool1-34450317-0 -o go-template --template='{{range .spec.podCIDRs}}{{printf "%s\n" .}}{{end}}'
10.244.1.0/24
2001:db8::/64

Має бути виділено один блок IPv4 та один блок IPv6.

Перевірте, що на вузлі виявлено інтерфейс IPv4 та IPv6. Замініть імʼя вузла на дійсний вузол з кластера. У цьому прикладі імʼя вузла - k8s-linuxpool1-34450317-0:

kubectl get nodes k8s-linuxpool1-34450317-0 -o go-template --template='{{range .status.addresses}}{{printf "%s: %s\n" .type .address}}{{end}}'
Hostname: k8s-linuxpool1-34450317-0
InternalIP: 10.0.0.5
InternalIP: 2001:db8:10::5

Перевірка адресації Pod

Перевірте, що у Pod є призначена адреса IPv4 та IPv6. Замініть імʼя Pod на наявний Pod у вашому кластері. У цьому прикладі імʼя Pod - pod01:

kubectl get pods pod01 -o go-template --template='{{range .status.podIPs}}{{printf "%s\n" .ip}}{{end}}'
10.244.1.4
2001:db8::4

Ви також можете перевірити IP-адреси Pod за допомогою Downward API через поле .status.podIPs. Наступний уривок показує, як ви можете використовувати IP-адреси Pod через змінну середовища з назвою MY_POD_IPS всередині контейнера.

        env:
        - name: MY_POD_IPS
          valueFrom:
            fieldRef:
              fieldPath: status.podIPs

Наступна команда виводить значення змінної середовища MY_POD_IPS всередині контейнера. Значення — це кома, що розділяє список, який відповідає IPv4 та IPv6 адресам Pod.

kubectl exec -it pod01 -- set | grep MY_POD_IPS
MY_POD_IPS=10.244.1.4,2001:db8::4

IP-адреси Pod також будуть записані в /etc/hosts всередині контейнера. Наступна команда виконує cat на /etc/hosts в Podʼі з подвійним стеком. З виводу ви можете перевірити як IPv4, так і IPv6 IP-адресу для Pod.

kubectl exec -it pod01 -- cat /etc/hosts
# Kubernetes-managed hosts file.
127.0.0.1    localhost
::1    localhost ip6-localhost ip6-loopback
fe00::0    ip6-localnet
fe00::0    ip6-mcastprefix
fe00::1    ip6-allnodes
fe00::2    ip6-allrouters
10.244.1.4    pod01
2001:db8::4    pod01

Перевірка Serviceʼів

Створіть наступний Service, який не визначає явно .spec.ipFamilyPolicy. Kubernetes призначить кластерний IP для Service з першого налаштованого service-cluster-ip-range і встановить .spec.ipFamilyPolicy на SingleStack.

apiVersion: v1
kind: Service
metadata:
  name: my-service
  labels:
    app.kubernetes.io/name: MyApp
spec:
  selector:
    app.kubernetes.io/name: MyApp
  ports:
    - protocol: TCP
      port: 80

Використовуйте kubectl, щоб переглянути YAML для Service.

kubectl get svc my-service -o yaml

У Service .spec.ipFamilyPolicy встановлено на SingleStack, а .spec.clusterIP встановлено на IPv4-адрес з першого налаштованого діапазону, встановленого за допомогою прапорця --service-cluster-ip-range на kube-controller-manager.

apiVersion: v1
kind: Service
metadata:
  name: my-service
  namespace: default
spec:
  clusterIP: 10.0.217.164
  clusterIPs:
  - 10.0.217.164
  ipFamilies:
  - IPv4
  ipFamilyPolicy: SingleStack
  ports:
  - port: 80
    protocol: TCP
    targetPort: 9376
  selector:
    app.kubernetes.io/name: MyApp
  sessionAffinity: None
  type: ClusterIP
status:
  loadBalancer: {}

Створіть наступний Service, який явно визначає IPv6 як перший елемент масиву в .spec.ipFamilies. Kubernetes призначить кластерний IP для Service з діапазону IPv6, налаштованого в service-cluster-ip-range, і встановить .spec.ipFamilyPolicy на SingleStack.

apiVersion: v1
kind: Service
metadata:
  name: my-service
  labels:
    app.kubernetes.io/name: MyApp
spec:
  ipFamilies:
  - IPv6
  selector:
    app.kubernetes.io/name: MyApp
  ports:
    - protocol: TCP
      port: 80

Використовуйте kubectl, щоб переглянути YAML для Service.

kubectl get svc my-service -o yaml

У Service .spec.ipFamilyPolicy встановлено на SingleStack, а .spec.clusterIP встановлено на IPv6-адрес з діапазону IPv6, налаштованого за допомогою прапорця --service-cluster-ip-range у kube-controller-manager.

apiVersion: v1
kind: Service
metadata:
  labels:
    app.kubernetes.io/name: MyApp
  name: my-service
spec:
  clusterIP: 2001:db8:fd00::5118
  clusterIPs:
  - 2001:db8:fd00::5118
  ipFamilies:
  - IPv6
  ipFamilyPolicy: SingleStack
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app.kubernetes.io/name: MyApp
  sessionAffinity: None
  type: ClusterIP
status:
  loadBalancer: {}

Створіть наступний Service, який явно визначає PreferDualStack в .spec.ipFamilyPolicy. Kubernetes призначить як IPv4, так і IPv6 адреси кластера (оскільки в цьому кластері ввімкнено подвійний стек) і вибере .spec.ClusterIP зі списку .spec.ClusterIPs на основі сімʼї адрес, що вказана в першому елементі масиву .spec.ipFamilies.

apiVersion: v1
kind: Service
metadata:
  name: my-service
  labels:
    app.kubernetes.io/name: MyApp
spec:
  ipFamilyPolicy: PreferDualStack
  selector:
    app.kubernetes.io/name: MyApp
  ports:
    - protocol: TCP
      port: 80

Перевірте, що Service отримує кластерні IP з діапазонів IPv4 та IPv6, використовуючи kubectl describe. Потім ви можете перевірити доступ до Service за допомогою IP та портів.

kubectl describe svc -l app.kubernetes.io/name=MyApp
Name:              my-service
Namespace:         default
Labels:            app.kubernetes.io/name=MyApp
Annotations:       <none>
Selector:          app.kubernetes.io/name=MyApp
Type:              ClusterIP
IP Family Policy:  PreferDualStack
IP Families:       IPv4,IPv6
IP:                10.0.216.242
IPs:               10.0.216.242,2001:db8:fd00::af55
Port:              <unset>  80/TCP
TargetPort:        9376/TCP
Endpoints:         <none>
Session Affinity:  None
Events:            <none>

Створення Service з подвійним стеком для балансування навантаження

Якщо постачальник хмарних послуг підтримує надання зовнішніх балансувальників навантаження з підтримкою IPv6, створіть наступний Service з PreferDualStack в .spec.ipFamilyPolicy, IPv6 як перший елемент масиву .spec.ipFamilies, а також встановіть поле type на LoadBalancer.

apiVersion: v1
kind: Service
metadata:
  name: my-service
  labels:
    app.kubernetes.io/name: MyApp
spec:
  ipFamilyPolicy: PreferDualStack
  ipFamilies:
  - IPv6
  type: LoadBalancer
  selector:
    app.kubernetes.io/name: MyApp
  ports:
    - protocol: TCP
      port: 80

Перевірка Service:

kubectl get svc -l app.kubernetes.io/name=MyApp

Перевірте, що Service отримує CLUSTER-IP адресу з блоку адрес IPv6 разом із EXTERNAL-IP. Потім ви можете перевірити доступ до Service за допомогою IP та портів.

NAME         TYPE           CLUSTER-IP            EXTERNAL-IP        PORT(S)        AGE
my-service   LoadBalancer   2001:db8:fd00::7ebc   2603:1030:805::5   80:30790/TCP   35s

4.15 - Розширення kubectl за допомогою втулків

Дізнайтеся, як розширити kubectl за допомогою втулків.

Цей посібник демонструє, як встановлювати та створювати розширення для kubectl. Вважаючи основні команди kubectl основними будівельними блоками для взаємодії з кластером Kubernetes, адміністратор кластера може розглядати втулки як засіб використання цих будівельних блоків для створення складнішої поведінки. Втулки розширюють kubectl новими підкомандами, що дозволяє використовувати нові та власні функції, які не входять до основного дистрибутиву kubectl.

Перш ніж ви розпочнете

Вам потрібно мати встановлений працюючий бінарний файл kubectl.

Встановлення втулків для kubectl

Втулок — це автономний виконуваний файл, назва якого починається з kubectl-. Для встановлення втулка перемістіть його виконуваний файл до будь-якої теки, що знаходиться в вашому PATH.

Ви також можете знайти та встановити втулки для kubectl, наявні у відкритому доступі, за допомогою Krew. Krew — це менеджер втулків, підтримуваний спільнотою Kubernetes SIG CLI.

Пошук втулків

kubectl надає команду kubectl plugin list, яка оглядає ваш PATH для відповідних виконуваних файлів втулків. Виконання цієї команди призводить до огляду всіх файлів у вашому PATH. Будь-які файли, які є виконуваними та починаються з kubectl-, зʼявляться в порядку їх розташування в вашому PATH у виводі цієї команди. Для будь-яких файлів, що починаються з kubectl- та не є виконуваними, буде додано попередження. Також буде додане попередження для будь-яких вірних файлів втулків, назви яких перекриваються.

Ви можете використовувати Krew, щоб шукати та встановлювати втулки для kubectl з індексу втулків, який підтримується спільнотою.

Обмеження

Зараз неможливо створити втулки, які перезаписують чинні команди kubectl. Наприклад, створення втулка kubectl-version призведе до того, що цей втулок ніколи не буде виконаний, оскільки наявна команда kubectl version завжди матиме пріоритет. За цим обмеженням також не можна використовувати втулки для додавання нових підкоманд до наявних команд kubectl. Наприклад, додавання підкоманди kubectl create foo, назвавши свій втулок kubectl-create-foo, призведе до його ігнорування.

kubectl plugin list виводить попередження для будь-яких вірних втулків, які намагаються це зробити.

Написання втулків для kubectl

Ви можете написати втулок будь-якою мовою програмування або скриптом, який дозволяє вам створювати команди для командного рядка.

Для втулків не потрібно жодної установки чи попереднього завантаження. Виконувані файли втулків успадковують середовище від бінарного файлу kubectl. Втулок визначає, який шлях команди він бажає реалізувати на основі свого імені. Наприклад, втулок з іменем kubectl-foo надає команду kubectl foo. Вам потрібно встановити виконуваний файл втулка десь у вашому PATH.

Приклад втулка

#!/bin/bash

# optional argument handling
if [[ "$1" == "version" ]]
then
    echo "1.0.0"
    exit 0
fi

# optional argument handling
if [[ "$1" == "config" ]]
then
    echo "$KUBECONFIG"
    exit 0
fi

echo "I am a plugin named kubectl-foo"

Користування втулком {#using-a-plugin

Для використання втулка зробіть його виконуваним:

sudo chmod +x ./kubectl-foo

та помістіть його в теку, яка знаходиться в вашому PATH:

sudo mv ./kubectl-foo /usr/local/bin

Тепер ви можете викликати втулок, використовуючи kubectl foo:

kubectl foo
I am a plugin named kubectl-foo

Всі аргументи та прапорці, передаються втулку як-вони-є для виконання:

kubectl foo version
1.0.0

Всі змінні оточення також передається у вигляді як-вони-є:

export KUBECONFIG=~/.kube/config
kubectl foo config
/home/<user>/.kube/config
KUBECONFIG=/etc/kube/config kubectl foo config
/etc/kube/config

Крім того, перший аргумент, який передається втуку, завжди буде повним шляхом до місця, де його було викликано ($0 буде дорівнювати /usr/local/bin/kubectl-foo в прикладі вище).

Іменування втулків

Як видно в прикладі вище, втулок визначає шлях команди, яку він буде реалізовувати, на основі свого імені файлу. Кожна підкоманда в шляху, для якої використовується втулок, розділена дефісом (-). Наприклад, втулок, який бажає запускатись, коли користувач викликає команду kubectl foo bar baz, матиме імʼя файлу kubectl-foo-bar-baz.

Обробка прапорців та аргументів

Втулки kubectl повинні розбирати та перевіряти всі передані їм аргументи. Див. використання пакета command line runtime для отримання відомостей про бібліотеку Go, призначену на авторів втулків.

Нижче наведено кілька додаткових випадків, коли користувачі викликають ваш втулок, надаючи додаткові прапорці та аргументи. Розберемо це на прикладі втулка kubectl-foo-bar-baz з вищезазначеного сценарію.

Якщо ви виконуєте kubectl foo bar baz arg1 --flag=value arg2, механізм втулків kubectl спочатку намагатиметься знайти втулок з найдовшим можливим імʼям, що в цьому випадку буде kubectl-foo-bar-baz-arg1. Не знайшовши цього втулка, kubectl тоді розглядає останнє значення, розділене дефісами, як аргумент (тут arg1) та намагається знайти наступне найдовше можливе імʼя, kubectl-foo-bar-baz. Знайшовши втулок з таким імʼям, kubectl викликає цей втулок, передаючи всі аргументи та прапорці після імені втулка як аргументи для процесу втулка.

Приклад:

# створимо втулок
echo -e '#!/bin/bash\n\necho "My first command-line argument was $1"' > kubectl-foo-bar-baz
sudo chmod +x ./kubectl-foo-bar-baz

# "iвстановимо" ваш втулок перемістивши його у теку з $PATH
sudo mv ./kubectl-foo-bar-baz /usr/local/bin

# перевіримо, що kubectl розпізнав ваш втулок
kubectl plugin list
The following kubectl-compatible plugins are available:

/usr/local/bin/kubectl-foo-bar-baz
# перевірте, що виклик вашого втулка через команду "kubectl" працює
# навіть тоді, коли користувач передає додаткові аргументи та прапорці
# до виконуваного користувачем виконуваного файлу вашого втулка.

kubectl foo bar baz arg1 --meaningless-flag=true
My first command-line argument was arg1

Як бачите, ваш втулок було знайдено на основі команди kubectl, вказаної користувачем, і всі додаткові аргументи та прапорці були передані як є до виконуваного файлу втулка після того, як його було знайдено.

Назви з дефісами та підкреслюваннями

Хоча механізм втулків kubectl використовує дефіси (-) у іменах файлів втулків для розділення послідовності підкоманд, оброблених втулком, все ж можна створити втулок з іменем, що містить дефіс в його виклику з командного рядка, використовуючи підкреслення (_) у його імені файлу.

Приклад:

# створимо втулок, що містить підкреслення в назві файлу
echo -e '#!/bin/bash\n\necho "I am a plugin with a dash in my name"' > ./kubectl-foo_bar
sudo chmod +x ./kubectl-foo_bar

# перемістимо втулок у теку з $PATH
sudo mv ./kubectl-foo_bar /usr/local/bin

# тепер ви можете викликати ваш втулок через kubectl:
kubectl foo-bar
I am a plugin with a dash in my name

Зауважте, що додавання підкреслення в імʼя файлу втулка не заважає створенню команд, таких як kubectl foo_bar. Команду з прикладу вище можна викликати як з дефісом (-), так і з підкресленням (_):

# Ви можете викликати вашу власну команду з дефісом
kubectl foo-bar
I am a plugin with a dash in my name
# Ви ткаож можете викликати свою власну команду з підкресленнями
kubectl foo_bar
I am a plugin with a dash in my name

Конфлікти імен та затьмарення

Можливе існування кількох втулків з однаковою назвою файлу в різних розташуваннях у вашому PATH. Наприклад, при наступному значенні PATH: PATH=/usr/local/bin/plugins:/usr/local/bin/moreplugins, копія втулка kubectl-foo може існувати в /usr/local/bin/plugins та /usr/local/bin/moreplugins, так що результат виклику команди kubectl plugin list буде наступним:

PATH=/usr/local/bin/plugins:/usr/local/bin/moreplugins kubectl plugin list
The following kubectl-compatible plugins are available:

/usr/local/bin/plugins/kubectl-foo
/usr/local/bin/moreplugins/kubectl-foo
  - warning: /usr/local/bin/moreplugins/kubectl-foo is overshadowed by a similarly named plugin: /usr/local/bin/plugins/kubectl-foo

error: one plugin warning was found

У вказаному вище сценарії попередження під /usr/local/bin/moreplugins/kubectl-foo говорить вам, що цей втулок ніколи не буде виконано. Замість цього виконується файл, який зʼявляється першим у вашому PATH, /usr/local/bin/plugins/kubectl-foo, завдяки механізму втулків kubectl.

Спосіб розвʼязання цієї проблеми — переконатися, що розташування втулка, яким ви хочете скористатися з kubectl, завжди стоїть на першому місці в вашому PATH. Наприклад, якщо ви хочете завжди використовувати /usr/local/bin/moreplugins/kubectl-foo в будь-який раз, коли викликається команда kubectl foo, змініть значення вашого PATH на /usr/local/bin/moreplugins:/usr/local/bin/plugins.

Виклик найдовшого імені виконуваного файлу

Є ще один вид перекриття, який може виникнути з іменами втулків. Допустимо, є два втулки у шляху користувача: kubectl-foo-bar та kubectl-foo-bar-baz. Механізм втулків kubectl завжди вибиратиме найдовше можливе імʼя втулка для заданої команди користувача. Нижче наведено деякі приклади, які докладніше пояснюють це:

# для заданої команди `kubectl` завжди буде вибиратися втулок з найдовшим можливим іменем файла
kubectl foo bar baz
Plugin kubectl-foo-bar-baz is executed
kubectl foo bar
Plugin kubectl-foo-bar is executed
kubectl foo bar baz buz
Plugin kubectl-foo-bar-baz is executed, with "buz" as its first argument
kubectl foo bar buz
Plugin kubectl-foo-bar is executed, with "buz" as its first argument

Цей вибір дизайну гарантує, що підкоманди втулків можуть бути реалізовані у кількох файлах, якщо це необхідно, і що ці підкоманди можуть бути вкладені під "батьківською" командою втулка:

ls ./plugin_command_tree
kubectl-parent
kubectl-parent-subcommand
kubectl-parent-subcommand-subsubcommand

Перевірка на наявність попереджень втулків

Ви можете скористатися вищезазначеною командою kubectl plugin list, щоб переконатися, що ваш втулок можна викликати за допомогою kubectl, та перевірити, чи немає попереджень, які перешкоджають його виклику як команди kubectl.

kubectl plugin list
The following kubectl-compatible plugins are available:

test/fixtures/pkg/kubectl/plugins/kubectl-foo
/usr/local/bin/kubectl-foo
  - warning: /usr/local/bin/kubectl-foo is overshadowed by a similarly named plugin: test/fixtures/pkg/kubectl/plugins/kubectl-foo
plugins/kubectl-invalid
  - warning: plugins/kubectl-invalid identified as a kubectl plugin, but it is not executable

error: 2 plugin warnings were found

Використання пакунка виконання командного рядка

Якщо ви пишете втулку для kubectl і використовуєте Go, ви можете скористатися cli-runtime бібліотеками.

Ці бібліотеки надають помічників для парсингу або оновлення файлу kubeconfig користувача, для виконання запитів REST до API-сервера або звʼязування прапорців повʼязаних з конфігурацією та друком.

Перегляньте Sample CLI Plugin для прикладу використання інструментів, які надаються у репозиторії CLI Runtime.

Розповсюдження втулків для kubectl

Якщо ви розробили втулок для того, щоб інші користувачі могли його використовувати, вам слід розглянути, як ви його пакуєте, розповсюджуєте і надаєте оновлення для користувачів.

Krew

Krew пропонує крос-платформний спосіб пакування та розповсюдження ваших втулків. Таким чином, ви використовуєте єдиний формат пакування для всіх цільових платформ (Linux, Windows, macOS і т.д.) і надаєте оновлення користувачам. Krew також підтримує індекс втулків, щоб інші люди могли знайти ваш втулок та встановлювати його.

Нативне / платформозалежне керування пакетами

З іншого боку, ви можете використовувати традиційні системи керування пакунками, такі як apt або yum в Linux, Chocolatey в Windows і Homebrew в macOS. Будь-який менеджер пакунків підійде, якщо він може розмістити нові виконувані файли в каталозі PATH користувача. Як автор втулка, якщо ви обираєте цей варіант, вам також слід покласти на себе тягар оновлення пакунка для розповсюдження ваших втулків для kubectl для кожного релізу на кожній платформі.

Сирці

Ви можете публікувати сирці, наприклад, як Git-репозиторій. Якщо ви обираєте цей варіант, той, хто хоче використовувати цей втулок, повинен витягти код, налаштувати середовище збірки (якщо він потребує компіляції) та використовувати втулок. Якщо ви також надаєте доступні скомпільовані пакунки або використовуєте Krew, це спростить процес встановлення.

Що далі

  • Перегляньте репозиторій Sample CLI Plugin для детального прикладу втулка, написаного на Go.
  • У разі будь-яких питань, не соромтеся звертатися до команди SIG CLI.
  • Дізнайтеся більше про Krew, менеджер пакунків для втулків kubectl.

4.16 - Керування HugePages

Налаштування та керування великими сторінками як запланованим ресурсом в кластері.
СТАН ФУНКЦІОНАЛУ: Kubernetes v1.14 [stable]

Kubernetes підтримує виділення та використання заздалегідь розміщених великих сторінок (huge pages) застосунками в Podʼі. Ця сторінка описує, як користувачі можуть використовувати великі сторінки.

Перш ніж ви розпочнете

На вузлах Kubernetes необхідно перед використанням резервувати місце під великі сторінки, щоб вузол зміг вказати свою ємність для великих сторінок.

Вузол може резервувати великі сторінки різних розмірів, наприклад, наступний рядок у файлі /etc/default/grub резервує 2*1 ГБ памʼяті для сторінок розміром 1 ГБ і 512*2 МБ для сторінок розміром 2 МБ:

GRUB_CMDLINE_LINUX="hugepagesz=1G hugepages=2 hugepagesz=2M hugepages=512"

Вузли автоматично виявлять та повідомлять про всі великі сторінки як планові ресурси.

Під час опису вузла ви повинні побачити щось подібне до наступного у розділах Capacity та Allocatable:

Capacity:
  cpu:                ...
  ephemeral-storage:  ...
  hugepages-1Gi:      2Gi
  hugepages-2Mi:      1Gi
  memory:             ...
  pods:               ...
Allocatable:
  cpu:                ...
  ephemeral-storage:  ...
  hugepages-1Gi:      2Gi
  hugepages-2Mi:      1Gi
  memory:             ...
  pods:               ...

API

Великі сторінки можна використовувати за допомогою вимог до ресурсів на рівні контейнера з використанням імені ресурсу hugepages-<size>, де <size> — це найбільш компактне двійкове позначення з використанням цілочисельних значень, які підтримуються на певному вузлі. Наприклад, якщо вузол підтримує розміри сторінок 2048KiB та 1048576KiB, він буде показувати розміри hugepages-2Mi та hugepages-1Gi. На відміну від CPU або памʼяті, великі сторінки не підтримують перевищення. Зверніть увагу, що при запиті ресурсів великих сторінок також потрібно вказувати ресурси памʼяті або CPU.

Pod може мати різні розміри великих сторінок в одній специфікації Podʼа. У цьому випадку для всіх точок монтування томів вона повинна використовувати нотацію medium: HugePages-<hugepagesize>.

apiVersion: v1
kind: Pod
metadata:
  name: huge-pages-example
spec:
  containers:
  - name: example
    image: fedora:latest
    command:
    - sleep
    - inf
    volumeMounts:
    - mountPath: /hugepages-2Mi
      name: hugepage-2mi
    - mountPath: /hugepages-1Gi
      name: hugepage-1gi
    resources:
      limits:
        hugepages-2Mi: 100Mi
        hugepages-1Gi: 2Gi
        memory: 100Mi
      requests:
        memory: 100Mi
  volumes:
  - name: hugepage-2mi
    emptyDir:
      medium: HugePages-2Mi
  - name: hugepage-1gi
    emptyDir:
      medium: HugePages-1Gi

Pod може використовувати medium: HugePages лише у випадку, якщо він запитує великі сторінки лише одного розміру.

apiVersion: v1
kind: Pod
metadata:
  name: huge-pages-example
spec:
  containers:
  - name: example
    image: fedora:latest
    command:
    - sleep
    - inf
    volumeMounts:
    - mountPath: /hugepages
      name: hugepage
    resources:
      limits:
        hugepages-2Mi: 100Mi
        memory: 100Mi
      requests:
        memory: 100Mi
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages
  • Запити великих сторінок повинні дорівнювати лімітам. Це є стандартним, якщо ліміти вказані, а запити — ні.
  • Великі сторінки ізольовані на рівні контейнера, тому кожен контейнер має власний ліміт, як вказано у специфікації контейнера.
  • Томи EmptyDir, що підтримуються великими сторінками, не можуть споживати більше памʼяті великих сторінок, ніж запитується для Podʼа.
  • Застосунки, які використовують великі сторінки за допомогою shmget() з SHM_HUGETLB, повинні працювати з допоміжною групою, яка відповідає за proc/sys/vm/hugetlb_shm_group.
  • Використанням великих сторінок у просторі імен можливо керувати за допомогою ResourceQuota, подібно іншим обчислювальним ресурсам, таким як cpu або memory, використовуючи токен hugepages-<size>.

4.17 - Планування GPU

Налаштування та планування GPU для використання як ресурсу вузлів у кластері.
СТАН ФУНКЦІОНАЛУ: Kubernetes v1.26 [stable]

Kubernetes має стабільну підтримку для управління графічними обчислювальними пристроями (GPU) від AMD та NVIDIA на різних вузлах вашого кластера, використовуючи втулки пристроїв.

На цій сторінці описано, як користувачі можуть використовувати GPU і наведені деякі обмеження в реалізації.

Використання втулків пристроїв

Kubernetes використовує втулки пристроїв, щоб дозволити Podʼам отримувати доступ до спеціалізованих апаратних можливостей, таких як GPU.

Як адміністратору, вам потрібно встановити драйвери GPU від відповідного виробника обладнання на вузлах і запустити відповідний втулок пристрою від виробника GPU. Ось кілька посилань на інструкції від виробників:

Після встановлення втулка ваш кластер використовує власний ресурс планування, такий як amd.com/gpu або nvidia.com/gpu.

Ви можете використовувати ці GPU у ваших контейнерах, запитуючи власний ресурс GPU,, так само як ви запитуєте cpu чи memory. Однак є обмеження у специфікації вимог до ресурсів для власних пристроїв.

GPU повинні бути вказані тільки в розділі limits, що означає:

  • Ви можете вказати limits для GPU без вказівки requests, оскільки Kubernetes за стандартно використовує ліміт як значення запиту.
  • Ви можете вказати GPU як в limits, так і в requests, але ці два значення повинні бути рівними.
  • Ви не можете вказати requests для GPU без вказівки limits.

Ось приклад маніфесту для Podʼі, який запитує GPU:

apiVersion: v1
kind: Pod
metadata:
  name: example-vector-add
spec:
  restartPolicy: OnFailure
  containers:
    - name: example-vector-add
      image: "registry.example/example-vector-add:v42"
      resources:
        limits:
          gpu-vendor.example/example-gpu: 1 # запит на 1 GPU

Керуйте кластерами з різними типами GPU

Якщо в різних вузлах вашого кластера є різні типи GPU, то ви можете використовувати мітки вузлів і селектори вузлів для планування Podʼів на відповідних вузлах.

Наприклад:

# Позначте свої вузли з типом прискорювача, яким вони володіють.
kubectl label nodes node1 accelerator=example-gpu-x100
kubectl label nodes node2 accelerator=other-gpu-k915

Ця мітка ключа accelerator лише приклад; ви можете використовувати інший ключ мітки, якщо це зручніше.

Автоматичне позначення вузлів

Як адміністратор, ви можете автоматично виявляти та мітити всі ваши вузли з підтримкою GPU, розгорнувши Виявлення функцій вузлів Kubernetes (NFD). NFD виявляє апаратні функції, які доступні на кожному вузлі в кластері Kubernetes. Зазвичай NFD налаштовується таким чином, щоб оголошувати ці функції як мітки вузла, але NFD також може додавати розширені ресурси, анотації та заплямування вузла (node taints). NFD сумісний з усіма підтримуваними версіями Kubernetes. Типово NFD створює мітки функцій для виявлених функцій. Адміністратори можуть використовувати NFD, щоб також мітити вузли конкретними функціями, щоб на них можна було планувати лише Podʼи, які запитують ці функції.

Вам також потрібен втулок для NFD, який додає відповідні мітки до ваших вузлів; це можуть бути загальні мітки або вони можуть бути вендор-специфічними. Ваш вендор GPU може надати втулок від третіх сторін для NFD; перевірте їх документацію для отримання додаткової інформації.

apiVersion: v1
kind: Pod
metadata:
  name: example-vector-add
spec:
  # Виможете використовувати Kubernetes node affinity для планування цього Podʼа на вузол
  # який надає kind типу GPU, який потрібе його контейнеру для роботи
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: "gpu.gpu-vendor.example/installed-memory"
            operator: Gt # (greater than)
            values: ["40535"]
          - key: "feature.node.kubernetes.io/pci-10.present" # NFD Feature label
            values: ["true"] # (optional) only schedule on nodes with PCI device 10
  restartPolicy: OnFailure
  containers:
    - name: example-vector-add
      image: "registry.example/example-vector-add:v42"
      resources:
        limits:
          gpu-vendor.example/example-gpu: 1 # запит 1 GPU

Вендори GPU

5 - Посібники

Цей розділ документації Kubernetes містить посібники. Посібник показує, як досягти мети, яка більша за одне завдання. Зазвичай посібник має кілька розділів, кожен з яких має послідовність кроків. Перед тим, як пройти кожен посібник, ви можете додати сторінку глосарія до закладок для подальших посилань.

Основи

Налаштування

Створення Podʼів

Stateless-застосунки

Stateful-застосунки

Сервіси (Services)

Безпека

Що далі

Якщо ви хочете написати посібник, див. Типи сторінок для отримання інформації про типи сторінок посібника.

5.1 - Привіт Minikube

Цей посібник покаже вам, як запустити простий кластер Kubernetes використовуючи minikube. Посібник надає образ контейнера, який використовує NGINX для відклику на всі запити.

Цілі

  • Розгортання тестового застосунку в minikube.
  • Запуск застосунку.
  • Перегляд логів застосунку.

Перш ніж ви розпочнете

Цей застосунок передбачає, що у вас вже є встановлений minikube. Дивіться Крок 1 в minikube start для інструкцій щодо встановлення.

Вам також потрібно встановити kubectl. Дивіться Встановлення інструментів для інструкцій щодо встановлення.

Створення кластера minikube

minikube start

Відкрийте інформаційну панель

Відкрийте інформаційну панель Kubernetes. Це можна зробити двома різними способами:

Відкрийте новий термінал та виконайте команду:

# Запустіть новий термінал та залиште його працювати.
minikube dashboard

Тепер поверніться до термінала, де ви запустили minikube start.

Якщо ви не хочете, щоб minikube відкривав вебоглядач для вас, запустіть підкоманду dashboard з прапорцем --url. minikube виводить URL-адресу, яку ви можете відкрити у вибраному вами вебоглядачі.

Відкрийте новий термінал та виконайте команду:

# Запустіть новий термінал та залиште його працювати.
minikube dashboard --url

Тепер поверніться до термінала, де ви запустили minikube start.

Створення Deployment

Pod в Kubernetes — це група з одного або більше контейнерів, які повʼязуються один з одним для керування та використання мережевих ресурсів. Pod в цьому посібнику містить тільки один контейнер. Kubernetes Deployment перевіряє життєздатність вашого Podʼа та, якщо він виходить з ладу, перезапускає його. Deployment є рекомендованим способом створення та масштабування Podʼів.

  1. Скористайтесь командою kubectl create для створення Deployment, що буде керувати Podʼом. Pod виконує контейнер, який міститься в образі Docker.

    # Запустіть тестовий образ контейнера, який містить вебсервер
    kubectl create deployment hello-node --image=registry.k8s.io/e2e-test-images/agnhost:2.39 -- /agnhost netexec --http-port=8080
    
  2. Перевірте, чи створено Deployment.

    kubectl get deployments
    

    Ви маєте отримати вивід, подібний до такого:

    NAME         READY   UP-TO-DATE   AVAILABLE   AGE
    hello-node   1/1     1            1           1m
    

    (Зачекайте деякий час, поки Pod стане доступним. Якщо ви бачите "0/1", спробуйте ще раз через кілька секунд.)

  3. Перевірте, чи створено Pod.

    kubectl get pods
    

    Ви маєте отримати вивід, подібний до такого:

    NAME                          READY   STATUS    RESTARTS   AGE
    hello-node--5f76cf6ccf-br9b5  1/1     Running   0          1m
    
  4. Перегляд подій кластера:

    kubectl get events
    
  5. Перегляд конфігурації kubectl:

    kubectl config view
    
  6. Перегляд логів застосунку з контейнера в Podʼі (замініть назву Podʼа на ту, яку ви отримали з kubectl get pods).

    kubectl logs hello-node-5f76cf6ccf-br9b5
    

    Вивід має бути подібним до такого:

    I0911 09:19:26.677397       1 log.go:195] Started HTTP server on port 8080
    I0911 09:19:26.677586       1 log.go:195] Started UDP server on port  8081
    

Створення Service

Стандартно, Pod доступний лише за його внутрішньою IP-адресою в межах Kubernetes-кластера. Щоб зробити контейнер hello-node доступним назовні віртуальної мережі Kubernetes, вам потрібно подати Pod як Service Kubernetes.

  1. Скористайтесь командою kubectl expose для експонування Podʼа:

    kubectl expose deployment hello-node --type=LoadBalancer --port=8080
    

    Прапорець --type=LoadBalancer вказує, що ви хочете надати доступ до вашого Serviceʼу назовні кластера.

    Код застосунку всередині тестового образу контейнера тільки прослуховує порт 8080. Якщо ви використовуєте інший порт в kubectl expose, клієнти не зможуть отримати доступ до вашого застосунку.

  2. Перевірте, чи створено Service:

    kubectl get services
    

    Ви маєте отримати вивід, подібний до такого:

    NAME         TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
    hello-node   LoadBalancer   10.108.144.78   <pending>     8080:30369/TCP   21s
    kubernetes   ClusterIP      10.96.0.1       <none>        443/TCP          23m
    

    Хмарні провайдери, які підтримують балансувальники навантаження, зовнішні IP-адреси можуть надаватись для доступу до Serviceʼу. В minikube LoadBalancer створює Service, доступний через команду minikube service.

  3. Виконайте наступну команду:

    minikube service hello-node
    

    Це відкриє вікно вебоглядача, що показує відповідь застосунку.

Увімкнення надбудов

Інструменти minikube містять набір вбудованих надбудов, які можна увімкнути, вимкнути та відкрити в локальному оточені Kubernetes.

  1. Перегляньте список доступних надбудов:

    minikube addons list
    

    Ви маєте отримати вивід, подібний до такого:

    addon-manager: enabled
    dashboard: enabled
    default-storageclass: enabled
    efk: disabled
    freshpod: disabled
    gvisor: disabled
    helm-tiller: disabled
    ingress: disabled
    ingress-dns: disabled
    logviewer: disabled
    metrics-server: disabled
    nvidia-driver-installer: disabled
    nvidia-gpu-device-plugin: disabled
    registry: disabled
    registry-creds: disabled
    storage-provisioner: enabled
    storage-provisioner-gluster: disabled
    
  2. Увімкніть надбудову, наприклад, metrics-server:

    minikube addons enable metrics-server
    

    Ви маєте отримати вивід, подібний до такого:

    The 'metrics-server' addon is enabled
    
  3. Перегляньте Podʼи та Serviceʼи, які щойно було створено:

    kubectl get pod,svc -n kube-system
    

    Вивід має бути подібним до такого:

    NAME                                        READY     STATUS    RESTARTS   AGE
    pod/coredns-5644d7b6d9-mh9ll                1/1       Running   0          34m
    pod/coredns-5644d7b6d9-pqd2t                1/1       Running   0          34m
    pod/metrics-server-67fb648c5                1/1       Running   0          26s
    pod/etcd-minikube                           1/1       Running   0          34m
    pod/influxdb-grafana-b29w8                  2/2       Running   0          26s
    pod/kube-addon-manager-minikube             1/1       Running   0          34m
    pod/kube-apiserver-minikube                 1/1       Running   0          34m
    pod/kube-controller-manager-minikube        1/1       Running   0          34m
    pod/kube-proxy-rnlps                        1/1       Running   0          34m
    pod/kube-scheduler-minikube                 1/1       Running   0          34m
    pod/storage-provisioner                     1/1       Running   0          34m
    
    NAME                           TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)             AGE
    service/metrics-server         ClusterIP   10.96.241.45    <none>        80/TCP              26s
    service/kube-dns               ClusterIP   10.96.0.10      <none>        53/UDP,53/TCP       34m
    service/monitoring-grafana     NodePort    10.99.24.54     <none>        80:30002/TCP        26s
    service/monitoring-influxdb    ClusterIP   10.111.169.94   <none>        8083/TCP,8086/TCP   26s
    
  4. Перевірте вивід з metrics-server:

    kubectl top pods
    

    Ви маєте отримати вивід, подібний до такого:

    NAME                         CPU(cores)   MEMORY(bytes)   
    hello-node-ccf4b9788-4jn97   1m           6Mi             
    

    Якщо ви бачите наступне повідомлення, почекайте та спробуйте ще раз:

    error: Metrics API not available
    
  5. Вимкніть metrics-server:

    metrics-server was successfully disabled
    

Видалення кластера minikube

Тепер ви можете видалити ресурси, які ви створили в кластері:

kubectl delete service hello-node
kubectl delete deployment hello-node

Зупиніть кластер minikube:

minikube stop

Необовʼязково, ви можете видалити кластер minikube:

minikube delete

Якщо ви бажаєте використовувати minikube знову для продовження вивчення Kubernetes, ви можете не видаляти його.

Підсумки

Ця сторінка містить базові аспекти використання minikube для розгортання простого кластера Kubernetes та запуску тестового застосунку. Тепер ви готові до розгортання власних застосунків.

Що далі

5.2 - Ознайомлення з основами Kubernetes

Основи Kubernetes

Цей посібник надає інструкції з основ системи оркестрування кластерів Kubernetes. Кожний модуль містить деяку вступну інформацію про основні функції та концепції Kubernetes, а також практичний посібник, за яким ви можете вчитися.

За допомогою цих посібників ви дізнаєтесь:

  • як розгорнути контейнеризований застосунок в кластері.
  • як масштабувати Deployment.
  • як розгорнути нову версію контейнеризованого застосунку.
  • як налагодити контейнеризований застосунок.

Чим Kubernetes може бути корисний для вас?

З сучасними вебсервісами користувачі очікують доступності застосунків 24/7, а розробники прагнуть розгортати нові версії цих застосунків кілька разів на день. Контейнеризація допомагає упаковувати програмне забезпечення для досягнення цих цілей, дозволяючи випускати оновлення застосунків без перерви в роботі. Kubernetes допомагає забезпечити те, що контейнеризовані застосунки працюватимуть там і тоді, де це потрібно, та надає їм необхідні ресурси та інструменти для ефективної роботи. Kubernetes — це готова до використання, відкрита платформа, розроблена на основі здобутого Google досвіду в оркеструванні контейнерів, поєднаного з найкращими ідеями та практиками спільноти.


5.2.1 - Створення кластера

Дізнайтесь про кластери Kubernetes та створіть простий кластер за допомогою Minikube.

5.2.1.1 - Використання Minikube для створення кластера

Дізнайтесь, що таке Kubernetes кластер. Дізнайтесь, що таке Minikube. Запустіть кластер Kubernetes.

Мета

  • Дізнатись, що таке кластер Kubernetes.
  • Дізнатись, що таке Minikube.
  • Запустити Kubernetes кластер на вашому компʼютері.

Kubernetes кластери

Kubernetes організовує високодоступний кластер компʼютерів, які взаємодіють, працюючи як єдиний блок. Абстракції в Kubernetes дозволяють розгортати контейнеризовані застосунки в кластері, не привʼязуючи їх специфічно до окремих машин. Щоб скористатися цією новою моделлю розгортання, застосунки повинні бути упаковані таким чином, що відділяє їх від конкретних хостів: вони повинні бути контейнеризовані. Контейнеризовані застосунки є більш гнучкими та доступними, ніж у минулих моделях розгортання, коли застосунки встановлювалися безпосередньо на конкретні машини як пакунки, глибоко інтегровані в хост. Kubernetes автоматизує розподіл та планування контейнерів застосунків у кластері більш ефективним способом. Kubernetes є платформою з відкритим кодом і готовою до операційного використання.

Кластер Kubernetes складається з двох типів ресурсів:

  • Панелі управління (Control Plane), що координує роботу кластера
  • Вузлів (Nodes) — робочіх машин, на яких запущені застосунки

Зміст:

  • Кластер Kubernetes
  • Minikube

Kubernetes — це платформа з відкритим кодом промислового класу, яка оркеструє розташування (планування) та виконання контейнерів застосунків в межах та поміж компʼютерними кластерами.


Схема кластера


Панель управління (Control Plane) відповідає за керування кластером. Вона координує всі процеси у вашому кластері, такі як запуск застосунків, підтримка їх бажаного стану, масштабування застосунків та розгортання оновлень.

Вузол (Node) — це ВМ або фізичний компʼютер, що виступає у ролі робочої машини в кластері Kubernetes. Кожен вузол має kubelet — агента для управління вузлом та обміну даними з панеллю управління Kubernetes. Також на вузлі мають бути встановлені інструменти для виконання операцій з контейнерами, такі як containerd або CRI-O. Кластер Kubernetes, що обслуговує операційний трафік має складатися як мінімум із трьох вузлів. Якщо один вузол вийде з ладу обидва члени etcd та панель управління будуть втрачені, а надмірність буде порушена. Ви можете зменшити ризик додаванням більше одного вузла з панеллю управління.

Панелі управління керують кластером, а вузли призначені для запуску застосунків.

Коли ви розгортаєте застосунки у Kubernetes, ви наказуєте панелі управління запустити контейнери застосунку. Панель управління розподіляє (планує) контейнери для запуску на вузлах кластера. Компоненти на рівні вузла, такі, як kubelet, спілкуються з панеллю управління за допомогою API Kubernetes, який надається панеллю управління. Кінцеві користувачі також можуть використовувати API Kubernetes для взаємодії з кластером.

Кластер Kubernetes можна розгорнути як на фізичних, так й на віртуальних машинах. Щоб розпочати розробку під Kubernetes, ви можете скористатися Minikube — спрощеною реалізацією Kubernetes. Minikube створює на вашому локальному компʼютері ВМ, на якій розгортає простий кластер з одного вузла. Існують версії Minikube для операційних систем Linux, macOS та Windows. Minikube CLI надає основні операції для роботи з вашим кластером, такі як start, stop, status та delete.

Тепер ви знаєте, що таке Kubernetes. Тож відвідаємо сторінку Привіт Minikube та спробуємо його на вашому компʼютері.

5.2.2 - Розгортання застосунку

5.2.2.1 - Використання kubectl для створення Deploymentʼа

Дізнайтесь, що таке Deployment застосунків. Розгорніть свій перший застосунок у Kubernetes за допомогою kubectl.

Мета

  • Дізнатися, що таке Deployment застосунків.
  • Розгорнути свій перший застосунок у Kubernetes за допомогою kubectl.

Процеси Kubernetes Deployment

Після створення працюючого кластера Kubernetes ви можете розгортати свої контейнеризовані застосунки на його основі. Для цього створіть розгортання (Deployment) Kubernetes. Deployment вказує Kubernetes, як створювати та оновлювати екземпляри вашого застосунку. Після створення Deployment панель управління Kubernetes розподіляє екземпляри застосунків, що включені в цей Deployment, для запуску на окремих вузлах в кластері.

Коли екземпляри застосунків створені, контролер розгортання Kubernetes безперервно відстежує їх стан. Якщо вузол, на якому запущено екземпляр, вимикається або видаляється, контролер розгортання замінює екземпляр новим на іншому вузлі в кластері. Це забезпечує механізм самовідновлення для розвʼязання проблем з відмовою або обслуговуванням вузлів.

У світі до-оркестрування часто використовувалися скрипти встановлення для запуску застосунків, але вони не дозволяли відновлення після відмови вузла. Шляхом як створення екземплярів застосунків, так і утримання їх в робочому стані на різних вузлах, розгортання Kubernetes забезпечує фундаментально відмінний підхід до управління застосунками.

Зміст:

  • Deployment'и
  • Kubectl

Deployment відповідає за створення та оновлення Podʼів для вашого застосунку


Розгортання вашого першого застосунку в Kubernetes


Ви можете створювати та управляти розгортанням (Deployment) за допомогою інтерфейсу командного рядка Kubernetes, kubectl. Kubectl використовує API Kubernetes для взаємодії з кластером. У цьому модулі ви вивчите найпоширеніші команди kubectl, які потрібні для створення розгортань та запуску застосунків в кластері Kubernetes.

Коли ви створюєте Deployment, вам необхідно вказати образ контейнера вашого застосунку та скільки його реплік ви бажаєте запустити. Згодом цю інформацію можна змінити, оновивши Deployment. В навчальних модулях 5 і 6 йдеться про те, як масштабувати і оновлювати Deployment'и.

Для того, щоб розгортати застосунки в Kubernetes, їх потрібно упакувати в один із підтримуваних форматів контейнерів

Для вашого першого розгортання ви будете використовувати застосунок hello-node, який упакований в Docker-контейнер і використовує NGINX для відгуку на всі запити. (Якщо ви ще не пробували створити застосунок hello-node та розгортати його за допомогою контейнера, ви можете це зробити, слідуючи інструкціям з посібника Привіт Minikube).

Вам також потрібно мати `kubectl`. Якщо ви ще не встановили його, відвідайте встановлення інструментів.

Тепер ви знаєте, що таке Deployment. Тож розгорнемо ваш перший застосунок!


Основи kubectl

Загальний формат команди kubectl: kubectl дія ресурс

Тут виконується вказана дія (наприклад, create, describe або delete) для вказаного ресурсу (наприклад, node або deployment). Ви можете використовувати --help після команд для отримання додаткової інформації про можливі параметри (наприклад, kubectl get nodes --help).

Перевірте, що kubectl налаштовано для роботи з вашим кластером, виконавши команду kubectl version.

Перевірте, що kubectl встановлено і ви можете бачити як версію клієнта, так і версію сервера.

Щоб переглянути вузли в кластері, виконайте команду kubectl get nodes.

Ви побачите доступні вузли. Пізніше Kubernetes вибере, де розгорнути наш застосунок на основі ресурсів, доступних на вузлах.

Розгортання застосунку

Розгорнімо наш перший застосунок на Kubernetes за допомогою команди kubectl create deployment. Ми повинні вказати назву розгортання та розташування образу застосунку (вкажіть повну URL-адресу репозиторію образів, розміщених за межами Docker Hub).

kubectl create deployment kubernetes-bootcamp --image=gcr.io/google-samples/kubernetes-bootcamp:v1

Відмінно! Ви щойно розгорнули свій перший застосунок, створивши Deployment. Це призвело до виконання для вас кількох дій:

  • пошук відповідного вузла, де може бути запущений екземпляр застосунку (у нас доступний лише 1 вузол)
  • планування запуску застосунку на цьому вузлі
  • налаштування кластера для перепланування екземпляра на новому вузлі за необхідності

Щоб переглянути ваші розгортання, використовуйте команду kubectl get deployments:

kubectl get deployments

Ми бачимо, що є 1 розгортання, яке запускає один екземпляр вашого застосунку. Екземпляр працює в контейнері на вашому вузлі.

Перегляд застосунку

Podʼи, які працюють всередині Kubernetes, запущені в ізольованій приватній мережі. Типово вони видимі з інших Podʼів та служб всередині того ж самого кластера Kubernetes, але не за межами цієї мережі. Коли ми використовуємо kubectl, ми взаємодіємо через точку доступу API для спілкування з нашим застосунком.

Розглянемо інші варіанти того, як вивести наш застосунок за межі кластера Kubernetes пізніше, в Модулі 4. Також, як у базовому посібнику, тут ми не пояснюємо докладно, що таке Podʼи, це буде розглянуто в подальших темах.

Команда kubectl proxy може створити проксі, який буде пересилати дані в мережу, що охоплює весь кластер. Роботу проксі можна завершити, натиснувши control-C, і він не виводитиме жодного результату під час роботи.

Вам потрібно відкрити друге вікно термінала для запуску проксі.

kubectl proxy

Тепер у нас є зʼєднання між вашим хостом (терміналом) та кластером Kubernetes. Проксі дозволяє безпосередній доступ до API з цих терміналів.

Ви можете побачити всі ці API, розміщені через проксі-endpoint. Наприклад, ми можемо запитати версію напряму через API, використовуючи команду curl:

curl http://localhost:8001/version

Сервер API автоматично створює точку доступу для кожного Podʼа на основі імені Podʼа, яка також доступна через проксі.

Спочатку нам потрібно отримати імʼя Podʼа, і ми збережемо його в змінну оточення POD_NAME:

export POD_NAME=$(kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}')
echo Name of the Pod: $POD_NAME

Ви можете отримати доступ до Podʼа через проксі-API, запустивши:

curl http://localhost:8001/api/v1/namespaces/default/pods/$POD_NAME:8080/proxy/

Для того, щоб нове розгортання було доступним без використання проксі, потрібен сервіс, про що буде розказано в Модулі 4.

Якщо ви готові, перейдіть до Перегляд Podʼів та Nodeʼів.

5.2.3 - Дослідження застосунку

5.2.3.1 - Перегляд Podʼів та вузлів (Node)

Дізнайтесь, як розвʼязувати проблеми з розгорнутими застосунками, використовуючи kubectl get, kubectl describe, kubectl logs та kubectl exec.

Мета

  • Дізнатися, що таке Podʼи Kubernetes.
  • Дізнатися, що таке вузли Kubernetes.
  • Діагностика розгорнутих застосунків.

Podʼи Kubernetes

Коли ви створили Deployment у модулі 2, Kubernetes створив Pod, щоб розмістити ваш застосунок. Pod — це абстракція в Kubernetes, що являє собою групу з одного або декількох контейнерів застосунку (таких як Docker) та ресурсів, спільних для цих контейнерів. До цих ресурсів належать:

  • Спільні сховища даних, або Volumes
  • Мережа, адже кожен Pod у кластері має унікальну IP-адресу
  • Інформація про запуск кожного контейнера, така як версія образу контейнера або використання певних портів

Pod моделює специфічний для даного застосунку "логічний хост" та може містити різні, але доволі щільно звʼязані один з одним контейнери. Наприклад, в одному Podʼі може бути контейнер з вашим Node.js застосунком та інший контейнер, що передає дані для публікації Node.js вебсерверу. Контейнери в межах Podʼа мають спільну IP-адресу та порти, завжди є сполученими, плануються для запуску разом та запускаються у спільному контексті на одному вузлі.

Pod є неподільною одиницею платформи Kubernetes. Коли ви створюєте Deployment у Kubernetes, цей Deployment створює Podʼи вже з контейнерами всередині, на відміну від створення контейнерів окремо. Кожен Pod привʼязаний до вузла, до якого його було розподілено, і лишається на ньому до припинення роботи (згідно з політикою перезапуску) або видалення. У разі відмови вузла ідентичні Podʼи розподіляються по інших доступних вузлах кластера.

Зміст:

  • Podʼи
  • Вузли
  • Основні команди kubectl

Pod — це група з одного або декількох контейнерів (таких як Docker), що має спільне сховище даних (volumes), унікальну IP-адресу і містить інформацію про те, як їх запустити.


Узагальнена схема Podʼів


Вузли

Pod завжди запускається на вузлі. Вузол — це робоча машина в Kubernetes, віртуальна або фізична, залежно від кластера. Функціонування кожного вузла контролюється панеллю управління. Вузол може мати декілька Podʼів, а панель управління автоматично призначає Podʼи вузлам в кластері. Панель управління Kubernetes автоматично розподіляє Podʼи по вузлах кластера з урахуванням ресурсів, наявних на кожному вузлі.

На кожному вузлі Kubernetes запущені як мінімум:

  • Kubelet — процес, що забезпечує обмін даними між панеллю управління Kubernetes та робочим вузлом; kubelet керує Podʼами та контейнерами, запущеним на машині.
  • Оточення для запуску контейнерів (таке як Docker) забезпечує завантаження образу контейнера з реєстру, розпакування контейнера та запуск застосунку.

Контейнери повинні бути разом в одному Podʼі, лише якщо вони щільно звʼязані і мають спільні ресурси, такі як диск.


Узагальнена схема вузлів


Виправлення проблем за допомогою kubectl

У модулі 2 ви використовували інтерфейс командного рядка kubectl. Ви будете продовжувати його використовувати в модулі 3 для отримання інформації про розгорнуті застосунки та їхні середовища. За допомогою наступних підкоманд kubectl можна виконати найбільш поширені операції:

  • kubectl get — показати перелік ресурсів
  • kubectl describe — виведення детальної інформації про ресурс
  • kubectl logs — виведення логів контейнера в Podʼі
  • kubectl exec — виконання команди в контейнері в Podʼі

Ви можете використовувати ці команди, щоб переглядати інформацію про те, коли були розгорнуті застосунки, який їхній поточний статус, де вони запущені та які їхні конфігурації.

Тепер, коли ми більше знаємо про компоненти нашого кластера та командний рядок, дослідімо наш застосунок.

Вузол — це робоча машина в Kubernetes і може бути віртуальною машиною або фізичною машиною залежно від кластера. На одному вузлі може працювати кілька Podʼів.

Перевірка конфігурації застосунку

Перевірмо, чи працює застосунок, який ми розгорнули в попередньому сценарії. Ми використаємо команду kubectl get і подивимося на наявні Podʼи:

kubectl get pods

Якщо Podʼи не запущені, зачекайте кілька секунд і знову спробуйте вивести список Podʼів. Ви можете продовжити, якщо ви бачите, що працює один Pod.

Далі, щоб переглянути, які контейнери є всередині цього Podʼа і які образи використовуються для створення цих контейнерів, ми використовуємо команду kubectl describe pods:

kubectl describe pods

Тут ми бачимо деталі про контейнер Podʼа: IP-адресу, порти та список подій, повʼязаних з життєвим циклом Podʼа.

Вивід підкоманди describe є розлогим і охоплює деякі концепції, які ми ще не пояснили, але не хвилюйтеся, вони стануть зрозумілими до кінця цього курсу.

Примітка: підкоманду describe можна використовувати для отримання детальної інформації про більшість примітивів Kubernetes, включаючи вузли, Podʼи та Deployment. Вивід команди describe призначений для сприйняття людиною, а не для сценаріїв.

Показати застосунок у терміналі

Пригадайте, що Podʼи працюють в ізольованій, приватній мережі — тому нам потрібно налаштувати проксі-доступ до них для налагодження та взаємодії з ними. Для цього ми використовуємо команду kubectl proxy для запуску проксі в іншому терміналі. Відкрийте нове вікно термінала і введіть у цьому новому терміналі:

kubectl proxy

Тепер ми знову отримаємо імʼя Podʼа та будемо звертатись до цього Podʼа безпосередньо через проксі. Щоб отримати імʼя Podʼа та зберегти його в змінну середовища POD_NAME:

export POD_NAME="$(kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}')"
echo Name of the Pod: $POD_NAME

Щоб переглянути вивід нашого застосунку, виконайте запит curl:

curl http://localhost:8001/api/v1/namespaces/default/pods/$POD_NAME:8080/proxy/

URL — це шлях до API Podʼа.

Перегляд логів контейнера

Все, що застосунок зазвичай виводить на стандартний вивід, стає логами контейнера всередині Podʼа. Ми можемо отримати ці логи, використовуючи команду kubectl logs:

kubectl logs "$POD_NAME"

Примітка: Нам не потрібно вказувати імʼя контейнера, оскільки у нас є лише один контейнер всередині Podʼа.

Виконання команди в контейнері

Ми можемо виконувати команди безпосередньо в контейнері після того, як Pod буде запущено та він працюватиме. Для цього ми використовуємо підкоманду exec і вказуємо імʼя Podʼа як параметр. Перегляньмо змінні середовища:

kubectl exec "$POD_NAME" -- env

Знову варто зазначити, що можна пропустити імʼя самого контейнера, оскільки у нас є лише один контейнер в Podʼі.

Далі розпочнім сеанс bash в контейнері Podʼа:

kubectl exec -ti $POD_NAME -- bash

Тепер у нас є відкрита консоль в контейнері, де запущений наш застосунок NodeJS. Вихідний код застосунку знаходиться у файлі server.js:

cat server.js

Ви можете перевірити, чи застосунок запущено, виконавши команду curl:

curl http://localhost:8080

Примітка: тут ми використовували localhost, оскільки ми виконали команду всередині Podʼа NodeJS. Якщо ви не можете підʼєднатися до localhost:8080, перевірте, чи ви виконали команду kubectl exec і запускаєте команду зсередини Podʼа

Щоб закрити підключення до контейнера, введіть exit.

Як тільки ви будете готові, переходьте до Використання Service для надання доступу до вашого застосунку.

5.2.4 - Доступ до застосунку зовні

5.2.4.1 - Використання Service для доступу до застосунку

Дізнайтесь про Service у Kubernetes. Ознайомтесь з тим, як мітки та селектори повʼязані з Service. Відкрийте доступ до застосунку по за межами Kubernetes кластера.

Мета

  • Дізнатись про Service у Kubernetes.
  • Ознайомитись з тим, як мітки та селектори повʼязані з Service.
  • Відкрити доступ до застосунку по за межами Kubernetes кластера.

Огляд Сервісів в Kubernetes

Існування Podʼів в Kubernetes є обмеженими за часом, також вони мають свій життєвий цикл. Коли робочий вузол припиняє існування, також втрачаються Podʼи, які виконуються на цьому вузлі. ReplicaSet може динамічно приводити кластер до бажаного стану шляхом створення нових Podʼів, щоб ваш застосунок продовжував працювати. Наприклад, розгляньмо обробник зображень, що має 3 копії. Ці копії (репліки) можуть бути взаємозамінні; система форонтенду не повинна перейматися репліками бекенду або навіть тим, чи Pod втрачено та створено наново. Проте кожен Pod в кластері Kubernetes має унікальну IP-адресу, навіть Podʼи на одному вузлі, тому потрібно мати спосіб автоматичного узгодження змін серед Podʼів, щоб ваші застосунки продовжували працювати.

Service в Kubernetes є абстракцією, яка визначає логічний набір Podʼів та політику доступу до них. Serviceʼи забезпечують слабку звʼязаність між залежними Podʼами. Service визначається за допомогою YAML або JSON, так само як і всі обʼєкти Kubernetes. Набір Podʼів, на які призначений Service, зазвичай визначається селектором міток (label selector) (див. нижче, чому selector іноді не включають у специфікацію Service).

Хоча кожний Pod має унікальну IP-адресу, ці IP не доступні за межі кластера без використання Service. Serviceʼи уможливлюють надходження трафіку до ваших застосунків. Serviceʼи можуть бути оприлюднені у різний спосіб, за допомогою type у spec Service:

  • ClusterIP (типове значення) — відкриває доступ до внутрішнього IP Service в кластері. Цей тип робить Service доступним лише зсередини кластера.
  • NodePort — відкриває доступ до Service на тому ж порті кожного обраного вузла в кластері за допомогою NAT. Робить Service доступним ззовні кластера за допомогою <NodeIP>:<NodePort>. Є надмножиною відносно ClusterIP.
  • LoadBalancer — створює зовнішній балансувальник навантаження в поточному хмарному середовищі (якщо підтримується) та призначає фіксовану зовнішню IP-адресу для Service. Є надмножиною відносно NodePort.
  • ExternalName — звʼязує Service з вмістом поля externalName (наприклад, foo.bar.example.com), повертаючи запис CNAME із його значенням. Не встановлюється жодного проксі. Цей тип вимагає v1.7 або вище kube-dns або CoreDNS версії 0.0.8 або вище.

Додаткову інформацію про різновиди Service можна знайти у посібнику Використання IP-адреси джерела. Дивіться також Підключення застосунків за допомогою Service.

Крім того, слід зауважити, що існують випадки використання Service, при яких не визначається selector у специфікації. Service, створений без selector, також не створить відповідний обʼєкт Endpoints. Це дозволяє користувачам вручну відкривати доступ Service на конкретні точки доступу. Ще одна можливість, чому може бути відсутній селектор — використання виключно type: ExternalName.

Зміст

  • Відкриття Podʼів для зовнішнього трафіка
  • Балансування навантаження трафіку між Podʼами
  • Використання міток

Service в Kubernetes – це рівень абстракції, який визначає логічний набір Podʼів і дозволяє експонування зовнішнього трафіку, балансування навантаження та виявлення служб для цих Podʼів.


Services та мітки (Labels)

Service маршрутизує трафік набору Podʼів. Service є абстракцією, яка дозволяє Podʼам зникати та реплікуватися в Kubernetes, не впливаючи на ваш застосунок. Виявлення та маршрутизація серед залежних Podʼів (таких як компоненти frontend та backend у застосунку) обробляються Serviceʼами Kubernetes.

Service визначають набір Podʼів за допомогою міток та селекторів, примітиву гуртування, який дозволяє логічно взаємодіяти з обʼєктами в Kubernetes. Мітки — це пари ключ/значення, призначені обʼєктам та можуть бути використані різними способами:

  • Призначення обʼєктів до оточення розробки, тестування та експлуатації
  • Вбудовування теґів версій
  • Класифікація обʼєкта за допомогою теґів


Мітки можна прикріплювати до обʼєктів при їх створенні або пізніше. Їх можна змінювати в будь-який час. Давайте зараз використаємо Service для надання доступу до нашого застосунку та застосуємо деякі мітки.

Крок 1: Створення нового Service

Перевіримо, що наш застосунок працює. Ми використовуватимемо команду kubectl get та переглядатимемо наявні Podʼи:

kubectl get pods

Якщо Podʼи не запущені, це означає, що обʼєкти з попередніх кроків були видалені. У цьому випадку поверніться та створіть Deployment з посібника Використання kubectl для створення Deployment. Зачекайте кілька секунд та перегляньте список Podʼів знову. Ви можете продовжити, як тільки побачите, що один Pod працює.

Далі виведемо список наявних Serviceʼів у нашому кластері:

kubectl get services

У нас є Service з назвою kubernetes, яка створюється стандартно, коли minikube запускає кластер. Щоб створити новий Service та зробити зовнішній трафік доступним для нього, ми використовуватимемо команду expose з параметром NodePort.

kubectl expose deployment/kubernetes-bootcamp --type="NodePort" --port 8080

Давайте знову запустимо команду get services:

kubectl get services

Тепер у нас є робочий Service з назвою kubernetes-bootcamp. Тут ми бачимо, що Service отримав унікальний IP в кластері, внутрішній порт та зовнішній IP (IP вузла).

Щоб дізнатися, який порт був відкритий ззовні (для Serviceʼу з type: NodePort), ми запустимо команду describe service:

kubectl describe services/kubernetes-bootcamp

Створимо змінну середовища з назвою NODE_PORT, яка матиме значення порту вузла:

export NODE_PORT="$(kubectl get services/kubernetes-bootcamp -o go-template='{{(index .spec.ports 0).nodePort}}')"
echo "NODE_PORT=$NODE_PORT"

Тепер ми можемо перевірити, що застосунок отримав доступ за межі кластера, використовуючи curl, IP-адресу вузла та зовнішній порт:

curl http://"$(minikube ip):$NODE_PORT"

І, ми отримуємо відповідь від сервера. Service — працює.

Крок 2: Використання міток

Deployment автоматично створив мітку для нашого Podʼа. За допомогою команди describe deployment ви можете побачити імʼя (ключ) цієї мітки:

kubectl describe deployment

Використаємо цю мітку для отримання списку наших Podʼів. Ми використовуватимемо команду kubectl get pods з -l як параметр, за яким слідують значення мітки:

kubectl get pods -l app=kubernetes-bootcamp

Ви можете зробити те саме, щоб вивести список поточних служб:

kubectl get services -l app=kubernetes-bootcamp

Отримайте назву Podʼа та збережіть її в змінній середовища POD_NAME:

export POD_NAME="$(kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}')"
echo "Name of the Pod: $POD_NAME"

Для застосування нової мітки ми використовуємо команду label за якою слідує тип обʼєкта, назва обʼєкта та нова мітка:

kubectl label pods "$POD_NAME" version=v1

Це додасть нову мітку до нашого Podʼа (ми закріпили версію програми для Podʼа), і ми можемо перевірити це за допомогою команди describe pod:

kubectl describe pods "$POD_NAME"

Тут ми бачимо, що мітка тепер прикріплена до нашого Podʼа. І тепер ми можемо отримати список Podʼів, використовуючи нову мітку:

kubectl get pods -l version=v1

І, ми бачимо Pod.

Крок 3: Видалення Service

Для видалення Service ви можете використовувати команду delete service. Тут також можна використовувати мітки:

kubectl delete service -l app=kubernetes-bootcamp

Переконайтеся, що Service видалено:

kubectl get services

Це підтверджує, що наш Service видалено. Щоб переконатися, що маршрут більше не відкритий, ви можете перевірити раніше відкриті IP та порт за допомогою curl:

curl http://"$(minikube ip):$NODE_PORT"

Це доводить, що застосунок більше не доступний ззовні кластера. Ви можете переконатись, що застосунок все ще працює за допомогою curl зсередини Podʼа:

kubectl exec -ti $POD_NAME -- curl http://localhost:8080

Тут ми бачимо, що застосунок працює. Це тому, що Deployment управляє застосунком. Для припинення роботи застосунку вам слід видалити також й Deployment.

Одразу, як тільки ви будете готові, переходьте до Запуску кількох екземплярів вашого застосунку.

5.2.5 - Масштабування застосунку

5.2.5.1 - Запуск кількох екземплярів вашого застосунку

Масштабування застосунку вручну за допомогою kubectl.

Мета

  • Масштабування застосунку за допомогою kubectl.

Масштабування Застосунку

Раніше ми створили Deployment, а потім робили його загальнодоступним за допомогою Service. Deployment створив лише один Pod для запуску нашого pfcnjceyre. Зі збільшенням трафіку, нам потрібно масштабувати застосунок, щоб відповідати зростаючим вимогам користувачів.

Якщо ви ще не працювали над попередніми розділами, почніть з Використання minikube для створення кластера.

Масштабування досягається зміною кількості реплік в Deployment.


Зміст:

  • Масштабування Deployment

Ви можете створити Deployment з початку з декількома екземплярами, використовуючи параметр --replicas для команди створення Deployment kubectl

Огляд масштабування


Масштабування Deployment гарантує створення нових Podʼів і їх призначення на Вузли з вільними ресурсами. Масштабування збільшить кількість Podʼів до нового бажаного стану. Kubernetes також підтримує автоматичне масштабування Podʼів, але це виходить за рамки цього посібника. Також можливе масштабування до нуля, і це призведе до завершення всіх Podʼів вказаного Deployment.

Запуск кількох екземплярів застосунку вимагає засобів для розподілу трафіку між ними. У Service є вбудований балансер навантаження, який розподілить мережевий трафік на всі Podʼи, що виставлені Deployment. Service будуть постійно відстежувати робочі Podʼи, використовуючи точки доступу, щоб гарантувати, що трафік направляється лише на доступні Podʼи.

Масштабування досягається зміною кількості реплік в Deployment.


Якщо у вас є кілька екземплярів застосунку, ви зможете робити оновлення без перерв. Ми розглянемо це в наступному розділі посібника. Тепер перейдемо до термінала та масштабуємо наш застосунок.

Масштабування Deployment

Щоб переглянути свій Deployment, використовуйте команду get deployments:

kubectl get deployments

Вивід повинен бути схожий на:

    NAME                  READY   UP-TO-DATE   AVAILABLE   AGE
    kubernetes-bootcamp   1/1     1            1           11m
    

Маємо 1 Pod. Якщо цього немає, виконайте команду ще раз. Тут маємо:

  • NAME — назви Deployment в кластері.
  • READY — показує співвідношення поточних/бажаних реплік
  • UP-TO-DATE — показує кількість реплік, які були оновлені для досягнення бажаного стану.
  • AVAILABLE — показує, скільки реплік застосунку доступні користувачам.
  • AGE — показує час, протягом якого застосунок працює.

Щоб переглянути ReplicaSet, створений Deployment, виконайте:

kubectl get rs

Зверніть увагу, що назва ReplicaSet завжди форматується як [DEPLOYMENT-NAME]-[ВИПАДКОВИЙ-РЯДОК]. Випадковий рядок генерується випадковим чином та використовує pod-template-hash як основу для створеня.

Два важливі стовпці цього виводу:

  • DESIRED — показує бажану кількість реплік застосунку, яку ви визначаєте під час створення Deployment. Це бажаний стан.
  • CURRENT — показує, скільки реплік в цей час працюють.

Далі масштабуймо Deployment до 4 реплік. Ми використаємо команду kubectl scale, за якою слідує тип Deployment, назва та бажана кількість екземплярів:

kubectl scale deployments/kubernetes-bootcamp --replicas=4

Щоб знову переглянути свої Deployment, використовуйте get deployments:

kubectl get deployments

Зміни були застосовані, і у нас є 4 екземпляри застосунку. Далі перевірмо, чи змінилася кількість Podʼів:

kubectl get pods -o wide

Тепер є 4 Podʼа з різними IP-адресами. Зміна була зареєстрована в журналі подій Deployment. Щоб перевірити це, використовуйте команду describe:

kubectl describe deployments/kubernetes-bootcamp

Ви також можете побачити, що у виводі цієї команди тепер є 4 репліки.

Балансування навантаження

Перевіримо, чи Service балансує трафік. Щоб дізнатися зовнішній IP та порт, ми можемо використовувати команду describe, як ми дізнались в попередній частині посібника:

kubectl describe services/kubernetes-bootcamp

Створіть змінну середовища з іменем NODE_PORT, яка має значення як порт Вузла:

export NODE_PORT="$(kubectl get services/kubernetes-bootcamp -o go-template='{{(index .spec.ports 0).nodePort}}')"

echo NODE_PORT=$NODE_PORT

Далі ми запустимо curl з зовнішньою IP-адресою та портом. Виконайте команду кілька разів:

curl http://"$(minikube ip):$NODE_PORT"

Ми потрапляємо на різні Podʼи при кожному запиті. Це демонструє, що балансування навантаження працює.

Зменшення розгортання

Щоб зменшити Deployment до 2 реплік, знову запустіть команду scale:

kubectl scale deployments/kubernetes-bootcamp --replicas=2

Перевірте Deployment, щоб переконатися, що зміни були застосовані, за допомогою команди get deployments:

kubectl get deployments

Кількість реплік зменшилася до 2. Перегляньте кількість Podʼів за допомогою get pods:

kubectl get pods -o wide

Це підтверджує, що роботу двох Podʼів було завершено.

Якщо ви готові, переходьте до Виконання поступового оновлення.

5.2.6 - Оновлення застосунку

5.2.6.1 - Виконання поступового оновлення

Виконання поетапного оновлення застосунку (rolling update) за допомогою kubectl.

Мета

  • Виконати розгортання з оновленням за допомогою kubectl.

Оновлення застосунку

Користувачі очікують, що застосунки будуть доступні цілодобово, і очікується, що розробники розгортатимуть нові версії кілька разів на день. У Kubernetes це робиться за допомогою розгортань з поступовим оновленням. Поступове оновлення (rolling update) дозволяє виконати оновлення Deployment без перерви в роботі застосунку. Це досягається поетапною заміною поточних Podʼів новими. Нові Podʼи призначаються вузлам з вільними ресурсами, а Kubernetes чекає, доки ці нові Podʼи не почнуть працювати, перш ніж вилучити старі Podʼи.

У попередньому розділі ми масштабували наш застосунок для запуску кількох екземплярів. Це є вимогою для виконання оновлень без впливу на доступність застосунку. Стандартно максимальна кількість Podʼів, які можуть бути недоступні під час оновлення, та максимальна кількість нових Podʼів, які можуть бути створені, дорівнює одному. Обидві опції можуть бути налаштовані як у вигляді точної кількості, так і у відсотках (від усіх Podʼів). У Kubernetes оновлення мають версії, і будь-яке оновлення Deployment може бути повернуте до попередньої (стабільної) версії.

Зміст:

  • Оновлення застосунку

Поступові оновлення дозволяють виконувати оновлення Deployment без зупинки роботи застосунку за допомогою поетапного оновлення екземплярів Podʼів.


Огляд поступового оновлення


Аналогічно масштабуванню застосунку, якщо Deployment є публічно доступним, Service буде балансувати трафік лише на доступні Podʼи під час оновлення. Доступний Pod — це екземпляр, який доступний користувачам застосунку.

Поступові оновлення дозволяють виконувати наступні дії:

  • Просування застосунку з одного середовища в інше (за допомогою оновлень образів контейнерів)
  • Відкат до попередніх версій
  • Неперервна інтеграція та постійна доставка застосунків без перерви в роботі

Якщо Deployment публічно доступний, Service буде балансувати трафік лише на доступні Podʼи під час оновлення.


У наступному інтерактивному практикумі ми оновимо наш застосунок до нової версії та виконаємо відкат.


Оновлення версії застосунку

Для виведення списку Deploymentʼів виконайте команду get deployments: kubectl get deployments

Для виведення списку запущених Podʼів виконайте команду get pods:

kubectl get pods

Для перегляду поточної версії образу застосунку виконайте команду describe pods та шукайте поле Image:

kubectl describe pods

Для оновлення образу застосунку до версії 2 використовуйте команду set image, за якою йде назва Deployment та нова версія образу:

kubectl set image deployments/kubernetes-bootcamp kubernetes-bootcamp=docker.io/jocatalin/kubernetes-bootcamp:v2

Команда повідомляє Deployment про використання іншого образу для вашого застосунку та запускає поступове оновлення. Перевірте стан нових Podʼів та перегляньте той, що відключається, використовуючи команду get pods:

kubectl get pods

Перевірка оновлення

Спочатку перевірте, чи Service працює, бо ви могли його видалити його на попередньому кроці, виконайте kubectl describe services/kubernetes-bootcamp. Якщо його немає, створіть його знов:

kubectl expose deployment/kubernetes-bootcamp --type="NodePort" --port 8080

Створіть змінну середовища з іменем NODE_PORT зі значенням призначеного порту вузла:

export NODE_PORT="$(kubectl get services/kubernetes-bootcamp -o go-template='{{(index .spec.ports 0).nodePort}}')"
echo "NODE_PORT=$NODE_PORT"

Потім виконайте curl з зовнішньою IP-адресою та портом:

curl http://"$(minikube ip):$NODE_PORT"

Кожен раз, коли ви виконуєте команду curl, ви попадете на різні Podʼи. Зверніть увагу, що всі Podʼи зараз працюють на останній версії (v2).

Ви також можете підтвердити оновлення, використовуючи команду rollout status:

kubectl rollout status deployments/kubernetes-bootcamp

Для перегляду поточної версії образу застосунку виконайте команду describe pods:

kubectl describe pods

У полі Image перевірите, що ви використовуєте останню версію образу (v2).

Відкат оновлення

Виконаймо ще одне оновлення та спробуємо розгорнути образ з теґом v10:

kubectl set image deployments/kubernetes-bootcamp kubernetes-bootcamp=gcr.io/google-samples/kubernetes-bootcamp:v10

Використовуйте get deployments, щоб переглянути стан розгортання:

kubectl get deployments

Зверніть увагу, що вивід не вказує бажану кількість доступних Podʼів. Використайте команду get pods, щоб вивести список всіх Podʼів:

kubectl get pods

Зверніть увагу, що деякі Podʼи мають статус ImagePullBackOff.

Щоб отримати більше відомостей про проблему, використовуйте команду describe pods:

kubectl describe pods

У розділі Events виводу для проблемних Podʼів, зверніть увагу, що версії образу v10 немає в репозиторії.

Щоб відкотити розгортання до попередньої робочої версії, використовуйте команду rollout undo:

kubectl rollout undo deployments/kubernetes-bootcamp

Команда rollout undo повертає розгортання до попередньо відомого стану (v2 образу). Оновлення мають версії, і ви можете повернутися до будь-якого раніше відомого стану розгортання.

Використайте команду get pods, щоб знову вивести список Podʼів:

kubectl get pods

Чотири Podʼи працюють. Щоб перевірити образ, розгорнутий на цих Podʼах, використайте команду describe pods:

kubectl describe pods

Розгортання знову використовує стабільну версію застосунку (v2). Відкат був успішним.

Не забудьте очистити свій локальний кластер

kubectl delete deployments/kubernetes-bootcamp services/kubernetes-bootcamp

5.3 - Налаштування

5.3.1 - Приклад: Налаштування мікросервісу на Java

5.3.1.1 - Зовнішня конфігурація за допомогою MicroProfile, ConfigMaps та Secrets

У цьому посібнику ви дізнаєтеся, як і чому варто зовнішньо налаштовувати конфігурацію вашого мікросервісу. Зокрема, ви дізнаєтеся, як використовувати Kubernetes ConfigMaps і Secrets для встановлення змінних середовища та їх подальшого використання за допомогою MicroProfile Config.

Перш ніж ви розпочнете

Створення Kubernetes ConfigMaps та Secrets

Існує кілька способів встановлення змінних середовища для Docker-контейнера в Kubernetes, зокрема: Dockerfile, kubernetes.yml, Kubernetes ConfigMap та Kubernetes Secret. У цьому посібнику ви дізнаєтеся, як використовувати останні два для встановлення змінних середовища, значення яких будуть впроваджені у ваші мікросервіси. Однією з переваг використання ConfigMap та Secret є те, що вони можуть повторно використовуватися у кількох контейнерах, включаючи можливість призначення різним змінним середовища для різних контейнерів.

ConfigMap — це обʼєкти API, які зберігають неконфіденційні пари "ключ-значення". У інтерактивному посібнику ви дізнаєтеся, як використовувати ConfigMap для зберігання імені програми. Більше інформації про ConfigMap ви можете знайти у документації.

Хоча Secret також використовуються для зберігання пар "ключ-значення", вони відрізняються від ConfigMap тим, що призначені для конфіденційної/чутливої інформації та зберігаються за допомогою кодування Base64. Це робить Secret відповідним вибором для зберігання таких речей, як облікові дані, ключі та токени, що ви й зробите в інтерактивному завданні. Більше інформації про Secret ви можете знайти у документації.

Зовнішня конфігурація з коду

Зовнішня конфігурація застосунків корисна, оскільки конфігурація зазвичай змінюється залежно від вашого середовища. Для цього ми будемо використовувати Java Contexts and Dependency Injection (CDI) та MicroProfile Config. MicroProfile Config — це функція MicroProfile, набору відкритих Java-технологій для розробки та розгортання хмаро-орієнтованих мікросервісів.

CDI надає стандартну можливість впровадження залежностей, що дозволяє створювати застосунок з працюючих разом, слабо звʼязаних частин. MicroProfile Config надає застосункам та мікросервісам стандартний спосіб отримання конфігураційних властивостей з різних джерел, включаючи застосунок, середовище виконання та оточення. Відповідно до визначеного пріоритету джерела, властивості автоматично комбінуються в єдиний набір властивостей, до якого застосунок може отримати доступ через API. Разом, CDI та MicroProfile будуть використані в інтерактивному посібнику для отримання зовнішньо наданих властивостей з Kubernetes ConfigMap та Secret і їх додавання у ваш код застосунку.

Багато відкритих фреймворків та середовищ виконання реалізують і підтримують MicroProfile Config. Протягом інтерактивного уроку ви будете використовувати Open Liberty, гнучке відкрите середовище виконання Java для створення та запуску хмаро-орієнтованих застосунків та мікросервісів. Однак замість нього можна використовувати будь-яке сумісне з MicroProfile середовище.

Цілі

  • Створити Kubernetes ConfigMap та Secret
  • Встановити конфігурацію мікросервісу за допомогою MicroProfile Config

Приклад: Зовнішня конфігурація за допомогою MicroProfile, ConfigMap та Secret

Почати інтерактивний урок

5.3.2 - Оновлення конфігурації за допомогою ConfigMap

Ця сторінка містить покроковий приклад оновлення конфігурації всередині Pod за допомогою ConfigMap і базується на завданні Налаштування Pod для використання ConfigMap. Наприкінці цього посібника ви зрозумієте, як змінити конфігурацію для запущеного застосунку. Цей посібник використовує образи alpine та nginx як приклади.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Вам потрібно мати інструмент командного рядка curl для виконання HTTP-запитів з термінала або командного рядка. Якщо у вас немає curl, ви можете його встановити. Ознайомтеся з документацією для вашої операційної системи.

Цілі

  • Оновлення конфігурації через ConfigMap, змонтованого як том
  • Оновлення змінних середовища Pod за допомогою ConfigMap
  • Оновлення конфігурації через ConfigMap в багатоконтейнерному Pod
  • Оновлення конфігурації через ConfigMap у Pod, що містить контейнер Sidecar

Оновлення конфігурації через ConfigMap, змонтовану як том

Використовуйте команду kubectl create configmap для створення ConfigMap з літеральних значень:

kubectl create configmap sport --from-literal=sport=football

Нижче наведено приклад маніфесту Deployment з ConfigMap sport, змонтованим як том у єдиний контейнер Pod.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: configmap-volume
  labels:
    app.kubernetes.io/name: configmap-volume
spec:
  replicas: 3
  selector:
    matchLabels:
      app.kubernetes.io/name: configmap-volume
  template:
    metadata:
      labels:
        app.kubernetes.io/name: configmap-volume
    spec:
      containers:
        - name: alpine
          image: alpine:3
          command:
            - /bin/sh
            - -c
            - while true; do echo "$(date) My preferred sport is $(cat /etc/config/sport)";
              sleep 10; done;
          ports:
            - containerPort: 80
          volumeMounts:
            - name: config-volume
              mountPath: /etc/config
      volumes:
        - name: config-volume
          configMap:
            name: sport

Створіть Deployment:

kubectl apply -f https://k8s.io/examples/deployments/deployment-with-configmap-as-volume.yaml

Перевірте Podʼи цього Deployment, щоб переконатися, що вони готові (відповідно до селектору):

kubectl get pods --selector=app.kubernetes.io/name=configmap-volume

Ви повинні побачити подібний вивід:

NAME                                READY   STATUS    RESTARTS   AGE
configmap-volume-6b976dfdcf-qxvbm   1/1     Running   0          72s
configmap-volume-6b976dfdcf-skpvm   1/1     Running   0          72s
configmap-volume-6b976dfdcf-tbc6r   1/1     Running   0          72s

На кожному вузлі, де працює один із цих Pod, kubelet отримує дані для цього ConfigMap і перетворює їх на файли у локальному томі. Потім kubelet монтує цей том у контейнер, як зазначено у шаблоні Pod. Код, що виконується у цьому контейнері, завантажує інформацію з файлу та використовує її для друку звіту на stdout. Ви можете перевірити цей звіт, переглянувши логи одного з Pod у цьому Deployment:

# Виберіть один Pod, що належить до Deployment, і перегляньте його логи
kubectl logs deployments/configmap-volume

Ви повинні побачити подібний вивід:

Found 3 pods, using pod/configmap-volume-76d9c5678f-x5rgj
Thu Jan  4 14:06:46 UTC 2024 My preferred sport is football
Thu Jan  4 14:06:56 UTC 2024 My preferred sport is football
Thu Jan  4 14:07:06 UTC 2024 My preferred sport is football
Thu Jan  4 14:07:16 UTC 2024 My preferred sport is football
Thu Jan  4 14:07:26 UTC 2024 My preferred sport is football

Відредагуйте ConfigMap:

kubectl edit configmap sport

В редакторі, що з’явиться, змініть значення ключа sport з football на cricket. Збережіть зміни. Інструмент kubectl відповідним чином оновлює ConfigMap (якщо виникне помилка, спробуйте ще раз).

Ось приклад того, як може виглядати маніфест після редагування:

apiVersion: v1
data:
  sport: cricket
kind: ConfigMap
# Наявні метадані можна залишити без змін.
# Значення, які ви побачите, не будуть точно відповідати цим.
metadata:
  creationTimestamp: "2024-01-04T14:05:06Z"
  name: sport
  namespace: default
  resourceVersion: "1743935"
  uid: 024ee001-fe72-487e-872e-34d6464a8a23

Ви повинні побачити наступний вивід:

configmap/sport edited

Відстежуйте (слідкуйте за останніми записами в) логах одного з Pod, що належить до цього Deployment:

kubectl logs deployments/configmap-volume --follow

Через кілька секунд ви повинні побачити зміну виводу логів:

Thu Jan  4 14:11:36 UTC 2024 My preferred sport is football
Thu Jan  4 14:11:46 UTC 2024 My preferred sport is football
Thu Jan  4 14:11:56 UTC 2024 My preferred sport is football
Thu Jan  4 14:12:06 UTC 2024 My preferred sport is cricket
Thu Jan  4 14:12:16 UTC 2024 My preferred sport is cricket

Коли у вас є ConfigMap, змонтований у працюючий Pod, використовуючи або том configMap, або projected том, і ви оновлюєте цей ConfigMap, працюючий Pod майже миттєво бачить це оновлення. Однак ваш застосунок бачить зміни лише в тому випадку, якщо він запрограмований опитувати зміни або стежити за оновленнями файлів. Застосунок, що завантажує свою конфігурацію лише під час запуску, не помітить змін.

Оновлення змінних середовища Pod за допомогою ConfigMap

Використовуйте команду kubectl create configmap для створення ConfigMap з літеральних значень:

kubectl create configmap fruits --from-literal=fruits=apples

Нижче наведено приклад маніфесту Deployment з налаштуванням змінної середовища через ConfigMap fruits.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: configmap-env-var
  labels:
    app.kubernetes.io/name: configmap-env-var
spec:
  replicas: 3
  selector:
    matchLabels:
      app.kubernetes.io/name: configmap-env-var
  template:
    metadata:
      labels:
        app.kubernetes.io/name: configmap-env-var
    spec:
      containers:
        - name: alpine
          image: alpine:3
          env:
            - name: FRUITS
              valueFrom:
                configMapKeyRef:
                  key: fruits
                  name: fruits
          command:
            - /bin/sh
            - -c
            - while true; do echo "$(date) The basket is full of $FRUITS";
                sleep 10; done;
          ports:
            - containerPort: 80

Створіть Deployment:

kubectl apply -f https://k8s.io/examples/deployments/deployment-with-configmap-as-envvar.yaml

Перевірте Pod цього Deployment, щоб переконатися, що вони готові (збігаються з селектором):

kubectl get pods --selector=app.kubernetes.io/name=configmap-env-var

Ви повинні побачити подібний вивід:

NAME                                 READY   STATUS    RESTARTS   AGE
configmap-env-var-59cfc64f7d-74d7z   1/1     Running   0          46s
configmap-env-var-59cfc64f7d-c4wmj   1/1     Running   0          46s
configmap-env-var-59cfc64f7d-dpr98   1/1     Running   0          46s

Ключ-значення у ConfigMap налаштовано як змінну середовища в контейнері Pod. Перевірте це, переглянувши логи одного Pod, що належить до Deployment.

kubectl logs deployment/configmap-env-var

Ви повинні побачити подібний вивід:

Found 3 pods, using pod/configmap-env-var-7c994f7769-l74nq
Thu Jan  4 16:07:06 UTC 2024 The basket is full of apples
Thu Jan  4 16:07:16 UTC 2024 The basket is full of apples
Thu Jan  4 16:07:26 UTC 2024 The basket is full of apples

Відредагуйте ConfigMap:

kubectl edit configmap fruits

В редакторі, що зʼявиться, змініть значення ключа fruits з apples на mangoes. Збережіть зміни. Інструмент kubectl відповідним чином оновлює ConfigMap (якщо виникне помилка, спробуйте ще раз).

Ось приклад того, як може виглядати маніфест після редагування:

apiVersion: v1
data:
  fruits: mangoes
kind: ConfigMap
# Наявні метадані можна залишити без змін.
# Значення, які ви побачите, не будуть точно відповідати цим.
metadata:
  creationTimestamp: "2024-01-04T16:04:19Z"
  name: fruits
  namespace: default
  resourceVersion: "1749472"

Ви повинні побачити наступний вивід:

configmap/fruits edited

Відстежуйте логи Deployment та спостерігайте за виводом протягом кількох секунд:

# Як пояснюється у тексті, вивід НЕ змінюється
kubectl logs deployments/configmap-env-var --follow

Зверніть увагу, що вивід залишається незмінним, навіть якщо ви редагували ConfigMap:

Thu Jan  4 16:12:56 UTC 2024 The basket is full of apples
Thu Jan  4 16:13:06 UTC 2024 The basket is full of apples
Thu Jan  4 16:13:16 UTC 2024 The basket is full of apples
Thu Jan  4 16:13:26 UTC 2024 The basket is full of apples

Ви можете ініціювати таку заміну. Виконайте розгортання для Deployment, використовуючи kubectl rollout:

# Запустіть розгортання
kubectl rollout restart deployment configmap-env-var

# Дочекайтеся завершення розгортання
kubectl rollout status deployment configmap-env-var --watch=true

Далі перевірте Deployment:

kubectl get deployment configmap-env-var

Ви повинні побачити подібний вивід:

NAME                READY   UP-TO-DATE   AVAILABLE   AGE
configmap-env-var   3/3     3            3           12m

Перевірте Podʼи:

kubectl get pods --selector=app.kubernetes.io/name=configmap-env-var

Розгортання змушує Kubernetes створити новий ReplicaSet для Deployment; це означає, що наявні Podʼи з часом завершуються, а нові створюються. Через кілька секунд ви повинні побачити подібний вивід:

NAME                                 READY   STATUS        RESTARTS   AGE
configmap-env-var-6d94d89bf5-2ph2l   1/1     Running       0          13s
configmap-env-var-6d94d89bf5-74twx   1/1     Running       0          8s
configmap-env-var-6d94d89bf5-d5vx8   1/1     Running       0          11s

Перегляньте логи для одного з Podʼів у цьому Deployment:

# Виберіть один Pod, що належить до Deployment, і перегляньте його логи
kubectl logs deployment/configmap-env-var

Ви повинні побачити подібний вивід:

Found 3 pods, using pod/configmap-env-var-6d9ff89fb6-bzcf6
Thu Jan  4 16:30:35 UTC 2024 The basket is full of mangoes
Thu Jan  4 16:30:45 UTC 2024 The basket is full of mangoes
Thu Jan  4 16:30:55 UTC 2024 The basket is full of mangoes

Це демонструє сценарій оновлення змінних середовища у Podʼі, що отримані з ConfigMap. Зміни до значень ConfigMap застосовуються до Pod під час наступного розгортання. Якщо Pod створюються з іншої причини, наприклад, при масштабуванні Deployment, тоді нові Pod також використовують останні значення конфігурації; якщо ви не ініціюєте розгортання, то ви можете виявити, що ваш застосунок працює зі змішаними старими та новими значеннями змінних середовища.

Оновлення конфігурації через ConfigMap у багатоконтейнерному Поді

Використовуйте команду kubectl create configmap, щоб створити ConfigMap з літеральних значень:

kubectl create configmap color --from-literal=color=red

Нижче подано приклад маніфесту для Deployment, що керує набором Podʼів, кожен з двома контейнерами. Два контейнери спільно використовують том emptyDir, який вони використовують для звʼязку. Перший контейнер працює як вебсервер (nginx). Шлях монтування для спільного тому в контейнері вебсервера — /usr/share/nginx/html. Другий допоміжний контейнер базується на alpine, і для цього контейнера том emptyDir монтується у /pod-data. Допоміжний контейнер записує файл у HTML, чий вміст залежить від ConfigMap. Контейнер вебсервера обслуговує HTML за допомогою HTTP.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: configmap-two-containers
  labels:
    app.kubernetes.io/name: configmap-two-containers
spec:
  replicas: 3
  selector:
    matchLabels:
      app.kubernetes.io/name: configmap-two-containers
  template:
    metadata:
      labels:
        app.kubernetes.io/name: configmap-two-containers
    spec:
      volumes:
        - name: shared-data
          emptyDir: {}
        - name: config-volume
          configMap:
            name: color
      containers:
        - name: nginx
          image: nginx
          volumeMounts:
            - name: shared-data
              mountPath: /usr/share/nginx/html
        - name: alpine
          image: alpine:3
          volumeMounts:
            - name: shared-data
              mountPath: /pod-data
            - name: config-volume
              mountPath: /etc/config
          command:
            - /bin/sh
            - -c
            - while true; do echo "$(date) My preferred color is $(cat /etc/config/color)" > /pod-data/index.html;
              sleep 10; done;

Створіть Deployment:

kubectl apply -f https://k8s.io/examples/deployments/deployment-with-configmap-two-containers.yaml

Перевірте Podʼи для цього Deployment, щоб переконатися, що вони готові (збігаються з селектором):

kubectl get pods --selector=app.kubernetes.io/name=configmap-two-containers

Ви повинні побачити вивід, схожий на:

NAME                                        READY   STATUS    RESTARTS   AGE
configmap-two-containers-565fb6d4f4-2xhxf   2/2     Running   0          20s
configmap-two-containers-565fb6d4f4-g5v4j   2/2     Running   0          20s
configmap-two-containers-565fb6d4f4-mzsmf   2/2     Running   0          20s

Надайте доступ до Deployment (інструмент kubectl створює Service для вас):

kubectl expose deployment configmap-two-containers --name=configmap-service --port=8080 --target-port=80

Використайте kubectl, щоб перенаправити порт:

kubectl port-forward service/configmap-service 8080:8080 & # це залишається запущеним у фоновому режимі

Отримайте доступ до Service.

curl http://localhost:8080

Ви повинні побачити вивід, схожий на:

Fri Jan  5 08:08:22 UTC 2024 My preferred color is red

Відредагуйте ConfigMap:

kubectl edit configmap color

У відкритому редакторі, змініть значення ключа color з red на blue. Збережіть свої зміни. Інструмент kubectl оновлює ConfigMap відповідно (якщо ви побачите помилку, спробуйте ще раз).

Ось приклад того, як може виглядати цей маніфест після редагування:

apiVersion: v1
data:
  color: blue
kind: ConfigMap
# Ви можете залишити наявні метадані такими, які вони є.
# Значення, які ви побачите, не збігатимуться з цими.
metadata:
  creationTimestamp: "2024-01-05T08:12:05Z"
  name: color
  namespace: configmap
  resourceVersion: "1801272"
  uid: 80d33e4a-cbb4-4bc9-ba8c-544c68e425d6

Затримайтесь на URL сервісу протягом кількох секунд.

# Скасуйте це, коли будете задоволені (Ctrl-C)
while true; do curl --connect-timeout 7.5 http://localhost:8080; sleep 10; done

Ви повинні побачити, що виведення змінюється наступним чином:

Fri Jan  5 08:14:00 UTC 2024 My preferred color is red
Fri Jan  5 08:14:02 UTC 2024 My preferred color is red
Fri Jan  5 08:14:20 UTC 2024 My preferred color is red
Fri Jan  5 08:14:22 UTC 2024 My preferred color is red
Fri Jan  5 08:14:32 UTC 2024 My preferred color is blue
Fri Jan  5 08:14:43 UTC 2024 My preferred color is blue
Fri Jan  5 08:15:00 UTC 2024 My preferred color is blue

Оновлення конфігурації через ConfigMap у Поді з контейнером sidecar

Вищевказаний сценарій можна відтворити за допомогою контейнера sidecar як допоміжного контейнера для запису HTML-файлу. Оскільки контейнер sidecar концептуально є контейнером ініціалізації, гарантується, що він запускається перед головним контейнером вебсервера. Це забезпечує, що файл HTML завжди доступний, коли вебсервер буде готовий його обслуговувати. Будь ласка, дивіться Увімкнення контейнерів sidecar, щоб скористатися цією функцією.

Якщо ви продовжуєте з попереднього сценарію, ви можете використати знову ConfigMap з імʼям color для цього сценарію. Якщо ви виконуєте цей сценарій самостійно, використовуйте команду kubectl create configmap, щоб створити ConfigMap з літеральних значень:

kubectl create configmap color --from-literal=color=blue

Нижче наведено приклад маніфесту для Deployment, що керує набором Podʼів, кожен з головним контейнером і контейнером sidecar. Обидва контейнери використовують спільний том emptyDir для звʼязку. Головний контейнер працює як вебсервер (NGINX). Шлях монтування для спільного тому в контейнері вебсервера — /usr/share/nginx/html. Другий контейнер є контейнером sidecar, який базується на Alpine Linux і діє як допоміжний контейнер. Для цього контейнера том emptyDir монтується у /pod-data. Контейнер sidecar записує файл у HTML, чий вміст залежить від ConfigMap. Контейнер вебсервера обслуговує HTML через HTTP.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: configmap-sidecar-container
  labels:
    app.kubernetes.io/name: configmap-sidecar-container
spec:
  replicas: 3
  selector:
    matchLabels:
      app.kubernetes.io/name: configmap-sidecar-container
  template:
    metadata:
      labels:
        app.kubernetes.io/name: configmap-sidecar-container
    spec:
      volumes:
        - name: shared-data
          emptyDir: {}
        - name: config-volume
          configMap:
            name: color
      containers:
        - name: nginx
          image: nginx
          volumeMounts:
            - name: shared-data
              mountPath: /usr/share/nginx/html
      initContainers:
        - name: alpine
          image: alpine:3
          restartPolicy: Always
          volumeMounts:
            - name: shared-data
              mountPath: /pod-data
            - name: config-volume
              mountPath: /etc/config
          command:
            - /bin/sh
            - -c
            - while true; do echo "$(date) My preferred color is $(cat /etc/config/color)" > /pod-data/index.html;
              sleep 10; done;

Створіть Deployment:

kubectl apply -f https://k8s.io/examples/deployments/deployment-with-configmap-and-sidecar-container.yaml

Перевірте Podʼи для цього Deployment, щоб переконатися, що вони готові (збігаються з селектором):

kubectl get pods --selector=app.kubernetes.io/name=configmap-sidecar-container

Ви повинні побачити вивід, схожий на:

NAME                                           READY   STATUS    RESTARTS   AGE
configmap-sidecar-container-5fb59f558b-87rp7   2/2     Running   0          94s
configmap-sidecar-container-5fb59f558b-ccs7s   2/2     Running   0          94s
configmap-sidecar-container-5fb59f558b-wnmgk   2/2     Running   0          94s

Надайте доступ до Deployment (інструмент kubectl створює Service для вас):

kubectl expose deployment configmap-sidecar-container --name=configmap-sidecar-service --port=8081 --target-port=80

Використайте kubectl, щоб перенаправити порт:

kubectl port-forward service/configmap-sidecar-service 8081:8081 & # це залишається запущеним у фоновому режимі

Отримайте доступ до Service.

curl http://localhost:8081

Ви повинні побачити вивід, схожий на:

Sat Feb 17 13:09:05 UTC 2024 My preferred color is blue

Відредагуйте ConfigMap:

kubectl edit configmap color

У відкритому редакторі змініть значення ключа color з blue на green. Збережіть свої зміни. Інструмент kubectl оновлює ConfigMap відповідно (якщо ви побачите помилку, спробуйте ще раз).

Ось приклад того, як може виглядати цей маніфест після редагування:

apiVersion: v1
data:
  color: green
kind: ConfigMap
# You can leave the existing metadata as they are.
# The values you'll see won't exactly match these.
metadata:
  creationTimestamp: "2024-02-17T12:20:30Z"
  name: color
  namespace: default
  resourceVersion: "1054"
  uid: e40bb34c-58df-4280-8bea-6ed16edccfaa

Затримайтесь на URL сервісу протягом кількох секунд.

# Скасуйте це, коли будете задоволені (Ctrl-C)
while true; do curl --connect-timeout 7.5 http://localhost:8081; sleep 10; done

Ви повинні побачити, що вивід змінюється наступним чином:

Sat Feb 17 13:12:35 UTC 2024 My preferred color is blue
Sat Feb 17 13:12:45 UTC 2024 My preferred color is blue
Sat Feb 17 13:12:55 UTC 2024 My preferred color is blue
Sat Feb 17 13:13:05 UTC 2024 My preferred color is blue
Sat Feb 17 13:13:15 UTC 2024 My preferred color is green
Sat Feb 17 13:13:25 UTC 2024 My preferred color is green
Sat Feb 17 13:13:35 UTC 2024 My preferred color is green

Оновлення конфігурації через незмінний ConfigMap, який монтується як том

Нижче наведено приклад маніфесту для незмінного ConfigMap.

apiVersion: v1
data:
  company_name: "ACME, Inc." # наявна вигадана назва компанії
kind: ConfigMap
immutable: true
metadata:
  name: company-name-20150801

Створіть незмінний ConfigMap:

kubectl apply -f https://k8s.io/examples/configmap/immutable-configmap.yaml

Нижче наведено приклад маніфесту Deployment з незмінним ConfigMap company-name-20150801, який монтується як том в єдиний контейнер Pod.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: immutable-configmap-volume
  labels:
    app.kubernetes.io/name: immutable-configmap-volume
spec:
  replicas: 3
  selector:
    matchLabels:
      app.kubernetes.io/name: immutable-configmap-volume
  template:
    metadata:
      labels:
        app.kubernetes.io/name: immutable-configmap-volume
    spec:
      containers:
        - name: alpine
          image: alpine:3
          command:
            - /bin/sh
            - -c
            - while true; do echo "$(date) The name of the company is $(cat /etc/config/company_name)";
              sleep 10; done;
          ports:
            - containerPort: 80
          volumeMounts:
            - name: config-volume
              mountPath: /etc/config
      volumes:
        - name: config-volume
          configMap:
            name: company-name-20150801

Створіть Deployment:

kubectl apply -f https://k8s.io/examples/deployments/deployment-with-immutable-configmap-as-volume.yaml

Перевірте Podʼи для цього Deployment, щоб переконатися, що вони готові (збігаються з селектором):

kubectl get pods --selector=app.kubernetes.io/name=immutable-configmap-volume

Ви повинні побачити вивід схожий на:

ІNAME                                          READY   STATUS    RESTARTS   AGE
immutable-configmap-volume-78b6fbff95-5gsfh   1/1     Running   0          62s
immutable-configmap-volume-78b6fbff95-7vcj4   1/1     Running   0          62s
immutable-configmap-volume-78b6fbff95-vdslm   1/1     Running   0          62s

Контейнер Podʼа посилається на дані, визначені в ConfigMap, і використовує їх для виводу звіту в stdout. Ви можете перевірити цей звіт, переглянувши логи для одного з Podʼів у цьому Deployment:

# Виберіть один Pod, який належить до Deployment, і перегляньте його логи
kubectl logs deployments/immutable-configmap-volume

Ви повинні побачити вивід, подібний до:

Found 3 pods, using pod/immutable-configmap-volume-78b6fbff95-5gsfh
Wed Mar 20 03:52:34 UTC 2024 The name of the company is ACME, Inc.
Wed Mar 20 03:52:44 UTC 2024 The name of the company is ACME, Inc.
Wed Mar 20 03:52:54 UTC 2024 The name of the company is ACME, Inc.

Створіть новий незмінний ConfigMap, використовуючи наведений нижче маніфест:

apiVersion: v1
data:
  company_name: "Fiktivesunternehmen GmbH" # нова вигадана назва компанії
kind: ConfigMap
immutable: true
metadata:
  name: company-name-20240312
kubectl apply -f https://k8s.io/examples/configmap/new-immutable-configmap.yaml

Ви повинні побачити вивід схожий на:

configmap/company-name-20240312 створено

Перевірте новостворений ConfigMap:

kubectl get configmap

Ви повинні побачити вивід, який відображає обидва? старий та новий ConfigMaps:

NAME                    DATA   AGE
company-name-20150801   1      22m
company-name-20240312   1      24s

Відредагуйте Deployment, щоб вказати новий ConfigMap

Редагування Deployment:

kubectl edit deployment immutable-configmap-volume

В редакторі, що зʼявиться, оновіть наявне визначення тому для використання нового ConfigMap.

volumes:
- configMap:
    defaultMode: 420
    name: company-name-20240312 # Оновіть це поле
  name: config-volume

Ви маєте побачити вивід, подібний до:

deployment.apps/immutable-configmap-volume edited

Це запустить розгортання. Почекайте поки всі раніше створені Podʼи завершаться, а нові Podʼи будуть в стані ready.

Відстежуйте стан Podʼів:

kubectl get pods --selector=app.kubernetes.io/name=immutable-configmap-volume
NAME                                          READY   STATUS        RESTARTS   AGE
immutable-configmap-volume-5fdb88fcc8-29v8n   1/1     Running       0          13s
immutable-configmap-volume-5fdb88fcc8-52ddd   1/1     Running       0          14s
immutable-configmap-volume-5fdb88fcc8-n5jx4   1/1     Running       0          15s
immutable-configmap-volume-78b6fbff95-5gsfh   1/1     Terminating   0          32m
immutable-configmap-volume-78b6fbff95-7vcj4   1/1     Terminating   0          32m
immutable-configmap-volume-78b6fbff95-vdslm   1/1     Terminating   0          32m

Ви нарешті побачите вивід, подібний до:

NAME                                          READY   STATUS    RESTARTS   AGE
immutable-configmap-volume-5fdb88fcc8-29v8n   1/1     Running   0          43s
immutable-configmap-volume-5fdb88fcc8-52ddd   1/1     Running   0          44s
immutable-configmap-volume-5fdb88fcc8-n5jx4   1/1     Running   0          45s

Перевірте логи для одного з Podʼів у цьому Deployment:

# Виберіть один Pod, який належить до Deployment, і перегляньте його логи
kubectl logs deployments/immutable-configmap-volume

Ви повинні побачити вивід, подібний до:

Found 3 pods, using pod/immutable-configmap-volume-5fdb88fcc8-n5jx4
Wed Mar 20 04:24:17 UTC 2024 The name of the company is Fiktivesunternehmen GmbH
Wed Mar 20 04:24:27 UTC 2024 The name of the company is Fiktivesunternehmen GmbH
Wed Mar 20 04:24:37 UTC 2024 The name of the company is Fiktivesunternehmen GmbH

Як тільки всі розгортання мігрують на використання нового незмінного ConfigMap, потрібно видалити старий ConfigMap:

kubectl delete configmap company-name-20150801

Підсумок

Зміни у ConfigMap, змонтованому як том у Pod, стають доступними безперешкодно після наступної синхронізації kubelet.

Зміни у ConfigMap, який налаштовує змінні середовища для Pod, стають доступними після наступного розгортання для цього Pod.

Після того як ConfigMap позначено як незмінний, неможливо скасувати цю зміну (ви не можете зробити незмінний ConfigMap змінним), і ви також не можете внести жодну зміну до вмісту поля data або binaryData. Ви можете видалити та створити ConfigMap заново, або можете створити новий відмінний ConfigMap. Коли ви видаляєте ConfigMap, запущені контейнери та їхні Podʼи зберігають точку монтування до будь-якого тому, який посилається на цей наявнийConfigMap.

Очищення

Завершіть команди kubectl port-forward, якщо вони виконуються.

Видаліть ресурси, створені під час навчання:

kubectl delete deployment configmap-volume configmap-env-var configmap-two-containers configmap-sidecar-container immutable-configmap-volume
kubectl delete service configmap-service configmap-sidecar-service
kubectl delete configmap sport fruits color company-name-20240312

kubectl delete configmap company-name-20150801 # У випадку, якщо він не був оброблений під час виконання завдання

5.3.3 - Конфігурування Redis за допомогою ConfigMap

Ця сторінка надає реальний приклад конфігурування Redis за допомогою ConfigMap і базується на завданні Конфігурування Pod для використання ConfigMap.

Цілі

  • Створити ConfigMap з конфігураційними значеннями Redis
  • Створити Pod з Redis, який монтує та використовує створений ConfigMap
  • Перевірити, що конфігурація була правильно застосована.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Для перевірки версії введіть kubectl version.

Реальний приклад: Конфігурування Redis за допомогою ConfigMap

Виконайте наведені нижче кроки для конфігурування кешу Redis за допомогою даних, збережених у ConfigMap.

Спершу створіть ConfigMap з порожнім блоком конфігурації:

cat <<EOF >./example-redis-config.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: example-redis-config
data:
  redis-config: ""
EOF

Застосуйте створений вище ConfigMap разом з маніфестом Podʼа Redis:

kubectl apply -f example-redis-config.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/pods/config/redis-pod.yaml

Перегляньте вміст маніфесту Podʼа Redis і зверніть увагу на наступне:

  • Том config створено за допомогою spec.volumes[1]
  • Пара key і path у spec.volumes[1].configMap.items[0] експонує ключ redis-config з example-redis-config ConfigMap як файл з назвою redis.conf у томі config.
  • Том config потім монтується в /redis-master за допомогою spec.containers[0].volumeMounts[1].

Це має загальний ефект експозиції даних з data.redis-config з example-redis-config ConfigMap як /redis-master/redis.conf всередині Pod.

apiVersion: v1
kind: Pod
metadata:
  name: redis
spec:
  containers:
  - name: redis
    image: redis:5.0.4
    command:
      - redis-server
      - "/redis-master/redis.conf"
    env:
    - name: MASTER
      value: "true"
    ports:
    - containerPort: 6379
    resources:
      limits:
        cpu: "0.1"
    volumeMounts:
    - mountPath: /redis-master-data
      name: data
    - mountPath: /redis-master
      name: config
  volumes:
    - name: data
      emptyDir: {}
    - name: config
      configMap:
        name: example-redis-config
        items:
        - key: redis-config
          path: redis.conf

Перегляньте створені обʼєкти:

kubectl get pod/redis configmap/example-redis-config 

Ви повинні побачити наступний вивід:

NAME        READY   STATUS    RESTARTS   AGE
pod/redis   1/1     Running   0          8s

NAME                             DATA   AGE
configmap/example-redis-config   1      14s

Нагадаємо, що ми залишили ключ redis-config у example-redis-config ConfigMap порожнім:

kubectl describe configmap/example-redis-config

Ви повинні побачити порожній ключ redis-config:

Name:         example-redis-config
Namespace:    default
Labels:       <none>
Annotations:  <none>

Data
====
redis-config:

Використовуйте kubectl exec, щоб увійти в Pod і запустити інструмент redis-cli, щоб перевірити поточну конфігурацію:

kubectl exec -it redis -- redis-cli

Перевірте maxmemory:

127.0.0.1:6379> CONFIG GET maxmemory

Він має показати типове значення 0:

1) "maxmemory"
2) "0"

Аналогічно, перевірте maxmemory-policy:

127.0.0.1:6379> CONFIG GET maxmemory-policy

Що також повинно показати типове значення noeviction:

1) "maxmemory-policy"
2) "noeviction"

Тепер додамо деякі конфігураційні значення до example-redis-config ConfigMap:

apiVersion: v1
kind: ConfigMap
metadata:
  name: example-redis-config
data:
  redis-config: |
    maxmemory 2mb
    maxmemory-policy allkeys-lru    

Застосуйте оновлений ConfigMap:

kubectl apply -f example-redis-config.yaml

Перевірте, що ConfigMap був оновлений:

kubectl describe configmap/example-redis-config

Ви повинні побачити конфігураційні значення, які ми щойно додали:

Name:         example-redis-config
Namespace:    default
Labels:       <none>
Annotations:  <none>

Data
====
redis-config:
----
maxmemory 2mb
maxmemory-policy allkeys-lru

Ще раз перевірте Pod Redis за допомогою redis-cli через kubectl exec, щоб побачити, чи конфігурація була застосована:

kubectl exec -it redis -- redis-cli

Перевірте maxmemory:

127.0.0.1:6379> CONFIG GET maxmemory

Він залишається з типовим значенням 0:

1) "maxmemory"
2) "0"

Аналогічно, maxmemory-policy залишається з типовими налаштуваннями noeviction:

127.0.0.1:6379> CONFIG GET maxmemory-policy

Повертає:

1) "maxmemory-policy"
2) "noeviction"

Конфігураційні значення не змінилися, оскільки Pod необхідно перезапустити, щоб отримати оновлені значення з асоційованих ConfigMap. Видалимо та заново створимо Pod:

kubectl delete pod redis
kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/pods/config/redis-pod.yaml

Тепер ще раз перевірте конфігураційні значення:

kubectl exec -it redis -- redis-cli

Перевірте maxmemory:

127.0.0.1:6379> CONFIG GET maxmemory

Тепер він має показати оновлене значення 2097152:

1) "maxmemory"
2) "2097152"

Аналогічно, maxmemory-policy також було оновлено:

127.0.0.1:6379> CONFIG GET maxmemory-policy

Він тепер показує бажане значення allkeys-lru:

1) "maxmemory-policy"
2) "allkeys-lru"

Очистіть свою роботу, видаливши створені ресурси:

kubectl delete pod/redis configmap/example-redis-config

Що далі

5.3.4 - Використання контейнерів sidecar

Цей розділ актуальний для людей, які впроваджують нову вбудовану функцію sidecar-контейнерів для своїх навантажень.

Sidecar-контейнери — це не нова концепція, про що було згадано в блог-пості ще у 2015 році. Kubernetes дозволяв запускати декілька контейнерів у Pod, щоб реалізувати цю концепцію. Однак запуск sidecar-контейнера як звичайного контейнера має багато обмежень, які вирішуються за допомогою нової підтримки вбудованих sidecar-контейнерів.

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.29 [beta]

Цілі

  • Зрозуміти необхідність використання sidecar-контейнерів.
  • Вміти розвʼязувати проблеми з sidecar-контейнерами.
  • Зрозуміти варіанти універсального "впровадження" sidecar-контейнерів у будь-яке навантаження.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Версія вашого Kubernetes сервера має бути не старішою ніж 1.29. Для перевірки версії введіть kubectl version.

Огляд sidecar-контейнерів

Sidecar-контейнери — це додаткові контейнери, які працюють разом з основним контейнером застосунку в межах одного Podʼа. Ці контейнери використовуються для покращення або розширення функціональності основного app-контейнера, надаючи додаткові послуги або функціональність, такі як логування, моніторинг, безпека або синхронізація даних, без прямого втручання в код основного застосунку. Детальніше можна прочитати на сторінці концепції Sidecar-контейнерів.

Концепція sidecar-контейнерів не є новою, і є багато її реалізацій. Як і sidecar-контейнери, які ви, як особа, що визначає Pod, хочете запустити, ви також можете побачити, що деякі надбудови змінюють Podʼи, до того, як Podʼи почнуть працювати, додаючи додаткові sidecar-контейнери. Механізми інʼєкцій цих додаткових sidecar-контейнерів часто використовують мутуючі вебхуки. Наприклад, надбудова service mesh може впроваджувати sidecar-контейнер, який налаштовує взаємний TLS і шифрування під час передачі між різними Podʼами.

Хоча концепція sidecar-контейнерів не є новою, вбудована реалізація цієї функції в Kubernetes, однак, нова. І як і з будь-якою новою функцією, впровадження цієї функції може викликати певні труднощі.

Цей навчальний посібник досліджує труднощі та рішення, з якими можуть зіткнутися кінцеві користувачі, а також автори sidecar-контейнерів.

Переваги вбудованих sidecar-контейнерів

Використання нативної підтримки sidecar-контейнерів у Kubernetes має кілька переваг:

  1. Ви можете налаштувати нативний sidecar-контейнер так, щоб він запускався перед init-контейнерами.
  2. Вбудовані sidecar-контейнери можна налаштувати так, щоб вони гарантовано завершувалися останніми. Sidecar-контейнери завершують роботу за допомогою сигналу SIGTERM, коли всі звичайні контейнери завершили роботу та завершилися. Якщо sidecar-контейнер не завершує роботу коректно, сигнал SIGKILL буде використано для його завершення.
  3. Для Jobs, коли restartPolicy: OnFailure або restartPolicy: Never, нативні sidecar-контейнери не блокують завершення Pod. Для старих sidecar-контейнерів потрібно було приділяти особливу увагу вирішенню цієї ситуації.
  4. Також для Jobs, вбудовані sidecar-контейнери будуть продовжувати перезапускатися після завершення, навіть якщо звичайні контейнери не будуть цього робити при restartPolicy: Never у Pod.

Впровадження вбудованих sidecar-контейнерів

Функціональна можливість SidecarContainers перебуває у стані бета-версії, починаючи з версії Kubernetes 1.29, і є стандартно увімкненою. Деякі кластери можуть мати цю функцію вимкненою або мати встановлене програмне забезпечення, яке не сумісне з цією функцією.

Коли це трапляється, Pod може бути відхилено або sidecar-контейнери можуть блокувати запуск Pod, роблячи Pod непридатним для використання. Цей стан легко виявити, оскільки Pod просто застряє на стадії ініціалізації. Однак рідко буває зрозуміло, що спричинило проблему.

Ось міркування та кроки з усунення несправностей, які можна виконати під час впровадження sidecar-контейнерів для свого навантаження.

Переконайтеся, що функціональну можливість увімкнено

Перш за все, переконайтеся, що як API-сервер, так і вузли мають версію Kubernetes v1.29 або пізнішу. Функція не працюватиме на кластерах, де вузли працюють на більш ранніх версіях, де вона не увімкнена.

Ви повинні переконатися, що функціональна можливість увімкнено як для API-сервера (серверів) у межах панелі управління, так і для всіх вузлів.

Одним зі способів перевірити увімкнення функціональної можливості є виконання команди:

  • Для API-сервера

    kubectl get --raw /metrics | grep kubernetes_feature_enabled | grep SidecarContainers

  • Для окремого вузла

    kubectl get --raw /api/v1/nodes/<node-name>/proxy/metrics | grep kubernetes_feature_enabled | grep SidecarContainers

Якщо ви бачите щось на кшталт: kubernetes_feature_enabled{name="SidecarContainers",stage="BETA"} 1, це означає, що функцію увімкнено.

Перевірка сторонніх інструментів і мутуючих вебхуків

Якщо у вас виникли проблеми під час перевірки функції, це може бути ознакою того, що один зі сторонніх інструментів або мутуючих вебхуків не працюють.

Коли функціональну можливість SidecarContainers увімкнено, Podʼи отримують нове поле в їхньому API. Деякі інструменти або мутуючі вебхуки могли бути створені на основі попередньої версії Kubernetes API.

Якщо інструменти передають невідомі поля як є, використовуючи різні стратегії виправлення для змінни об’єкта Pod, це не буде проблемою. Однак є інструменти, які видалять невідомі поля; якщо у вас є такі, їх потрібно буде перекомпілювати з v1.28+ версією клієнтського коду Kubernetes API.

Спосіб перевірки цього полягає у використанні команди kubectl describe pod для вашого Podʼа, який пройшов через мутуючий admission webhook. Якщо будь-які інструменти вилучили нове поле (restartPolicy: Always), ви не побачите його у виводі команди.

Якщо ви зіткнулися з такою проблемою, рекомендується повідомити автора інструментів або вебхуків, щоб вони використовували одну зі стратегій накладання патчів для модифікації обʼєктів замість їх повного оновлення.

Автоматичне встромляння sidecar-контейнерів

Якщо ви використовуєте програмне забезпечення, яке автоматично встромляє sidecar-контейнери, існує кілька можливих стратегій, які ви можете застосувати, щоб забезпечити можливість використання нативних sidecar-контейнерів. Усі ці стратегії загалом є варіантами вибору того, чи буде Pod, до якого встромляється sidecar, розміщений на вузлі, який підтримує цю функцію.

Наприклад, можна ознайомитися з цією дискусією в спільноті Istio, яка досліджує наведені нижче варіанти.

  1. Позначення Podʼів, що розміщуються на вузлах із підтримкою sidecars. Ви можете використовувати мітки вузлів і node affinity, щоб позначити вузли, які підтримують sidecar-контейнери, і забезпечити розміщення Pods на цих вузлах.
  2. Перевірка сумісності вузлів під час додавання контейнера. Під час впровадження sidecar-контейнерів можна використовувати такі стратегії перевірки сумісності вузлів:
    • Запитати версію вузла та припустити, що функціональну можливість увімкнено для версії 1.29+.
    • Запитати метрики Prometheus вузла та перевірити стан увімкнення функції.
    • Припустити, що вузли працюють із підтримуваною версійною розбіжністю від API-сервера.
    • Можуть існувати інші власні способи визначення сумісності вузлів.
  3. Розробка універсального інжектора sidecar-контейнерів. Ідея універсального sidecar-контейнера полягає в тому, щоб додати sidecar-контейнер як звичайний контейнер, а також як нативний sidecar-контейнер, і мати логіку на рівні виконання, яка визначить, який варіант працюватиме. Універсальний інжектор sidecar є ресурсозатратним, оскільки він враховуватиме запити двічі, але його можна розглядати як робоче рішення для особливих випадків.
    • Один зі способів полягає в тому, щоб під час запуску нативного sidecar-контейнера визначити версію вузла та завершити роботу негайно, якщо версія не підтримує функцію sidecar.
    • Розгляньте дизайн із виявленням функції під час виконання:
      • Визначте empty dir, щоб контейнери могли взаємодіяти один з одним.
      • Впровадьте init-контейнер, який назвемо NativeSidecar, з restartPolicy=Always.
      • NativeSidecar має записати файл в empty dir під час першого запуску та завершити роботу з кодом виходу 0.
      • NativeSidecar під час повторного запуску (коли нативні sidecar підтримуються) перевіряє, чи файл уже існує в empty dir, і змінює його, вказуючи, що вбудовані sidecar-контейнери підтримуються і працюють.
      • Впровадьте звичайний контейнер, який назвемо OldWaySidecar.
      • OldWaySidecar під час запуску перевіряє наявність файлу в empty dir.
      • Якщо файл вказує, що NativeSidecar не працює, він припускає, що функція sidecar не підтримується, і працює як sidecar.
      • Якщо файл вказує, що NativeSidecar працює, він або не робить нічого та спить назавжди (у випадку, коли Pod має restartPolicy=Always), або завершить роботу негайно з кодом виходу 0 (у випадку, коли Pod має restartPolicy!=Always).

Що далі

5.4 - Безпека

Безпека є важливою темою для більшості організацій та людей, які використовують кластери Kubernetes. Ви можете знайти базовий список перевірок безпеки в іншому місці документації Kubernetes.

Щоб дізнатися, як розгорнути та керувати аспектами безпеки Kubernetes, ви можете виконати практичні завдання в цьому розділі.

5.4.1 - Застосування стандартів безпеки Podʼів на рівні кластера

Безпека Pod покладається на контролер допуску, що виконує перевірки відповідно до Стандартів безпеки Podʼів в Kubernetes при створенні нових Podʼів. Це функція, має загальну доступність з випуску v1.25. Цей навчальний посібник показує, як застосувати стандарт безпеки baseline на рівні кластера, що застосовує стандартну конфігурацію для всіх просторів імен у кластері.

Для застосування стандартів безпеки Podʼів до певних просторів імен дивіться Застосування стандартів безпеки Podʼів на рівні простору імен.

Якщо ви працюєте з версією Kubernetes, відмінною від v1.31, перевірте документацію для вашої версії.

Перш ніж ви розпочнете

Встановіть на ваш компʼютер наступне:

Цей навчальний посібник показує, як ви можете налаштувати кластер Kubernetes, який ви повністю контролюєте. Якщо ви вивчаєте, як налаштувати Pod Security Admission для кластера, що надається постачальником послуг, де ви не можете налаштувати панель управління, прочитайте Застосування стандартів безпеки Podʼів на рівні простору імен.

Виберіть правильний стандарт безпеки Podʼів

Pod Security Admission дозволяє застосовувати вбудовані Стандарти безпеки Podʼів у режимах: enforce, audit та warn.

Щоб зібрати інформацію, яка допоможе вам вибрати стандарти безпеки Podʼів, які найбільш підходять для вашої конфігурації, виконайте наступне:

  1. Створіть кластер, в якому не застосовані стандарти безпеки Podʼів:

    kind create cluster --name psa-wo-cluster-pss
    

    Вивід подібний до:

    Creating cluster "psa-wo-cluster-pss" ...
    ✓ Ensuring node image (kindest/node:v1.31.0) 🖼
    ✓ Preparing nodes 📦
    ✓ Writing configuration 📜
    ✓ Starting control-plane 🕹️
    ✓ Installing CNI 🔌
    ✓ Installing StorageClass 💾
    Set kubectl context to "kind-psa-wo-cluster-pss"
    You can now use your cluster with:
    
    kubectl cluster-info --context kind-psa-wo-cluster-pss
    
    Thanks for using kind! 😊
    
  2. Встановіть контекст kubectl для нового кластера:

    kubectl cluster-info --context kind-psa-wo-cluster-pss
    

    Вивід подібний до цього:

    Kubernetes control plane is running at https://127.0.0.1:61350
    
    CoreDNS is running at https://127.0.0.1:61350/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
    
    To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
    
  3. Отримайте список просторів імен у кластері:

    kubectl get ns
    

    Вивід подібний до цього:

    NAME                 STATUS   AGE
    default              Active   9m30s
    kube-node-lease      Active   9m32s
    kube-public          Active   9m32s
    kube-system          Active   9m32s
    local-path-storage   Active   9m26s
    
  4. Використовуйте --dry-run=server, щоб зрозуміти, що відбувається при застосуванні різних стандартів безпеки Podʼів:

    1. Privileged

      kubectl label --dry-run=server --overwrite ns --all \
      pod-security.kubernetes.io/enforce=privileged
      

      Вивід подібний до:

      namespace/default labeled
      namespace/kube-node-lease labeled
      namespace/kube-public labeled
      namespace/kube-system labeled
      namespace/local-path-storage labeled
      
    2. Baseline

      kubectl label --dry-run=server --overwrite ns --all \
      pod-security.kubernetes.io/enforce=baseline
      

      Вивід подібний до:

      namespace/default labeled
      namespace/kube-node-lease labeled
      namespace/kube-public labeled
      Warning: existing pods in namespace "kube-system" violate the new PodSecurity enforce level "baseline:latest"
      Warning: etcd-psa-wo-cluster-pss-control-plane (and 3 other pods): host namespaces, hostPath volumes
      Warning: kindnet-vzj42: non-default capabilities, host namespaces, hostPath volumes
      Warning: kube-proxy-m6hwf: host namespaces, hostPath volumes, privileged
      namespace/kube-system labeled
      namespace/local-path-storage labeled
      
    3. Restricted

      kubectl label --dry-run=server --overwrite ns --all \
      pod-security.kubernetes.io/enforce=restricted
      

      Вивід подібний до:

      namespace/default labeled
      namespace/kube-node-lease labeled
      namespace/kube-public labeled
      Warning: existing pods in namespace "kube-system" violate the new PodSecurity enforce level "restricted:latest"
      Warning: coredns-7bb9c7b568-hsptc (and 1 other pod): unrestricted capabilities, runAsNonRoot != true, seccompProfile
      Warning: etcd-psa-wo-cluster-pss-control-plane (and 3 other pods): host namespaces, hostPath volumes, allowPrivilegeEscalation != false, unrestricted capabilities, restricted volume types, runAsNonRoot != true
      Warning: kindnet-vzj42: non-default capabilities, host namespaces, hostPath volumes, allowPrivilegeEscalation != false, unrestricted capabilities, restricted volume types, runAsNonRoot != true, seccompProfile
      Warning: kube-proxy-m6hwf: host namespaces, hostPath volumes, privileged, allowPrivilegeEscalation != false, unrestricted capabilities, restricted volume types, runAsNonRoot != true, seccompProfile
      namespace/kube-system labeled
      Warning: existing pods in namespace "local-path-storage" violate the new PodSecurity enforce level "restricted:latest"
      Warning: local-path-provisioner-d6d9f7ffc-lw9lh: allowPrivilegeEscalation != false, unrestricted capabilities, runAsNonRoot != true, seccompProfile
      namespace/local-path-storage labeled
      

З попередніх результатів ви можете помітити, що застосування стандарту безпеки privileged не показує жодних попереджень для жодного простору імен. Однак для стандартів baseline і restricted є попередження, зокрема для простору імен kube-system.

Встановлення режимів, версій та стандартів

У цьому розділі ви застосовуєте наступні Стандарти безпеки Pod до версії latest:

  • Стандарт baseline у режимі enforce.
  • Стандарт restricted у режимах warn та audit.

Стандарт безпеки Pod baseline надає зручний проміжний рівень, який дозволяє тримати список винятків коротким та запобігає відомим підвищенням привілеїв.

Додатково, для запобігання витоку підсистеми kube-system, ви виключите простір імен з застосуванням Стандартів безпеки Pod.

При впровадженні перевірки безпеки Pod у власному середовищі оберіть такі пункти:

  1. Враховуючи рівень ризику, застосований до кластера, строгий Стандарт безпеки Pod, наприклад restricted, може бути кращим вибором.

  2. Виключення простору імен kube-system дозволяє підсистемам працювати з підвищеними привілеями у цьому просторі імен. Для реального використання проєкт Kubernetes наполегливо рекомендує вам застосовувати строгі політики RBAC, які обмежують доступ до kube-system, слідуючи принципу найменших привілеїв. Для впровадження вищезазначених стандартів виконайте наступне:

  3. Створіть файл конфігурації, який може бути використаний Контролером допуску Стандартів безпеки Pod для застосування цих Стандартів безпеки Pod:

    mkdir -p /tmp/pss
    cat <<EOF > /tmp/pss/cluster-level-pss.yaml
    apiVersion: apiserver.config.k8s.io/v1
    kind: AdmissionConfiguration
    plugins:
    - name: PodSecurity
      configuration:
        apiVersion: pod-security.admission.config.k8s.io/v1
        kind: PodSecurityConfiguration
        defaults:
          enforce: "baseline"
          enforce-version: "latest"
          audit: "restricted"
          audit-version: "latest"
          warn: "restricted"
          warn-version: "latest"
        exemptions:
          usernames: []
          runtimeClasses: []
          namespaces: [kube-system]
    EOF
    
  4. Налаштуйте API-сервер для використання цього файлу під час створення кластера:

    cat <<EOF > /tmp/pss/cluster-config.yaml
    kind: Cluster
    apiVersion: kind.x-k8s.io/v1alpha4
    nodes:
    - role: control-plane
      kubeadmConfigPatches:
      - |
        kind: ClusterConfiguration
        apiServer:
            extraArgs:
              admission-control-config-file: /etc/config/cluster-level-pss.yaml
            extraVolumes:
              - name: accf
                hostPath: /etc/config
                mountPath: /etc/config
                readOnly: false
                pathType: "DirectoryOrCreate"
      extraMounts:
      - hostPath: /tmp/pss
        containerPath: /etc/config
        readOnly: false
        selinuxRelabel: false
        propagation: None
    EOF
    
  5. Створіть кластер, який використовує Pod Security Admission для застосування цих Стандартів безпеки Pod:

    kind create cluster --name psa-with-cluster-pss --config /tmp/pss/cluster-config.yaml
    

    Вивід буде подібним до цього:

    Creating cluster "psa-with-cluster-pss" ...
     ✓ Ensuring node image (kindest/node:v1.31.0) 🖼
     ✓ Preparing nodes 📦
     ✓ Writing configuration 📜
     ✓ Starting control-plane 🕹️
     ✓ Installing CNI 🔌
     ✓ Installing StorageClass 💾
    Set kubectl context to "kind-psa-with-cluster-pss"
    You can now use your cluster with:
    
    kubectl cluster-info --context kind-psa-with-cluster-pss
    
    Have a question, bug, or feature request? Let us know! https://kind.sigs.k8s.io/#community 🙂
    
  6. Вкажіт kubectl кластер:

    kubectl cluster-info --context kind-psa-with-cluster-pss
    

    Вивід буде схожий на цей:

    Kubernetes control plane is running at https://127.0.0.1:63855
    CoreDNS is running at https://127.0.0.1:63855/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
    
    To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
    
  7. Створіть Pod у просторі імен default:

    apiVersion: v1
     kind: Pod
     metadata:
       name: nginx
     spec:
       containers:
         - image: nginx
           name: nginx
           ports:
             - containerPort: 80
     
    kubectl apply -f https://k8s.io/examples/security/example-baseline-pod.yaml
    

    Pod запускається звичайно, але вивід містить попередження:

    Warning: would violate PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "nginx" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "nginx" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "nginx" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "nginx" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")
    pod/nginx created
    

Очищення

Тепер ви можете видалити кластери, які ви створили:

kind delete cluster --name psa-with-cluster-pss
kind delete cluster --name psa-wo-cluster-pss

Що далі

5.4.2 - Застосування Стандартів безпеки Pod на рівні простору імен

Pod Security Admission — це контролер допуску, який застосовує Стандарти безпеки Pod при створенні Podʼів. Це функція, яка є загально доступною з v1.25. У цьому посібнику ви будете застосовувати Стандарт безпеки Pod baseline, по одному простору імен за раз.

Ви також можете застосовувати Стандарти безпеки Pod до кількох просторів імен одночасно на рівні кластера. Щоб дізнатися більше, перейдіть за посиланням Застосування Стандартів безпеки Pod на рівні кластера.

Перш ніж ви розпочнете

Встановіть на ваш компʼютер наступне:

Створення кластера

  1. Створіть кластер kind наступним чином:

    kind create cluster --name psa-ns-level
    

    Вивід буде подібний до цього:

    Creating cluster "psa-ns-level" ...
     ✓ Ensuring node image (kindest/node:v1.31.0) 🖼 
     ✓ Preparing nodes 📦  
     ✓ Writing configuration 📜 
     ✓ Starting control-plane 🕹️ 
     ✓ Installing CNI 🔌 
     ✓ Installing StorageClass 💾 
    Set kubectl context to "kind-psa-ns-level"
    You can now use your cluster with:
    
    kubectl cluster-info --context kind-psa-ns-level
    
    Not sure what to do next? 😅  Check out https://kind.sigs.k8s.io/docs/user/quick-start/
    
  2. Встановіть контекст kubectl для нового кластера:

    kubectl cluster-info --context kind-psa-ns-level
    

    Вивід буде подібний до цього:

    Kubernetes control plane is running at https://127.0.0.1:50996
    CoreDNS is running at https://127.0.0.1:50996/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
    
    To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
    

Створення простору імен

Створіть новий простір імен з назвою example:

kubectl create ns example

Вивід буде подібний до цього:

namespace/example created

Увімкнення перевірки Стандартів безпеки Pod для цього простору імен

  1. Увімкніть Стандарти безпеки Pod на цьому просторі імен за допомогою підтримуваних міток, вбудованих в Pod Security Admission. На цьому кроці ви налаштуєте перевірку, щоб система попереджувала про Podʼи, які не відповідають останньої версії стандарту безпеки підсистеми baseline.

    kubectl label --overwrite ns example \
       pod-security.kubernetes.io/warn=baseline \
       pod-security.kubernetes.io/warn-version=latest
    
  2. Ви можете налаштувати кілька перевірок стандартів безпеки Podʼів для будь-якого простору імен за допомогою міток. Наступна команда буде застосовувати стандарт безпеки Pod baseline, але warn та audit для стандартів безпеки Pod restricted згідно з останньою версією (стандартне значення)

    kubectl label --overwrite ns example \
      pod-security.kubernetes.io/enforce=baseline \
      pod-security.kubernetes.io/enforce-version=latest \
      pod-security.kubernetes.io/warn=restricted \
      pod-security.kubernetes.io/warn-version=latest \
      pod-security.kubernetes.io/audit=restricted \
      pod-security.kubernetes.io/audit-version=latest
    

Перевірте дотримання стандарту безпеки Podʼів

  1. Створіть Pod з базовим стандартом в просторі імен example:

    kubectl apply -n example -f https://k8s.io/examples/security/example-baseline-pod.yaml
    

    Pod дійсно запускається; вивід містить попередження. Наприклад:

    Warning: would violate PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "nginx" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "nginx" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "nginx" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "nginx" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")
    pod/nginx created
    
  2. Створіть Pod з базовим стандартом у просторі імен default:

    kubectl apply -n default -f https://k8s.io/examples/security/example-baseline-pod.yaml
    

    Вивід буде подібний до такого:

    pod/nginx створено
    

Виконання стандартів безпеки Podʼів та налаштування попереджень було застосовано лише до простору імен example. Ви можете створити такий самий Pod в просторі імен default без будь-яких попереджень.

Очищення

Тепер видаліть кластер, який було створено:

kind delete cluster --name psa-ns-level

Що далі

5.4.3 - Обмежте доступ контейнера до ресурсів за допомогою AppArmor

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.31 [stable]

Ця сторінка показує, як завантажити профілі AppArmor на ваших вузлах та забезпечити їх виконання в Podʼах. Щоб дізнатися більше про те, як Kubernetes може обмежувати Podʼи за допомогою AppArmor, див. Обмеження безпеки ядра Linux для Podʼів та контейнерів.

Цілі

  • Ознайомитись з прикладом того, як завантажити профіль на Вузол
  • Дізнайтеся, як забезпечити виконання профілю в Podʼі
  • Дізнайтеся, як перевірити, що профіль завантажено
  • Побачте, що відбувається, коли умови профілю порушуються
  • Побачте, що відбувається, якщо профіль не може бути завантажено

Перш ніж ви розпочнете

AppArmor — це необовʼязковий модуль ядра та функція Kubernetes, тому переконайтеся, що він підтримується на ваших вузлах перед продовженням:

  1. Модуль ядра AppArmor увімкнено — для того, щоб ядро Linux застосовувало профіль AppArmor, модуль ядра AppArmor повинен бути встановлений та увімкнений. Декілька дистрибутивів стандартно вмикають модуль, такі як Ubuntu і SUSE, і багато інших надають опціональну підтримку. Щоб перевірити, чи модуль увімкнено, перевірте файл /sys/module/apparmor/parameters/enabled:

    cat /sys/module/apparmor/parameters/enabled
    Y
    

    Kubelet перевіряє, чи AppArmor увімкнено на хості, перед тим як допустити Pod з явно налаштованим AppArmor.

  2. Середовище виконання контейнерів підтримує AppArmor — всі загальні середовища виконання контейнерів, що підтримуються Kubernetes, мають підтримку AppArmor, включаючи containerd та CRI-O. Будь ласка, зверніться до відповідної документації середовища та перевірте, що кластер відповідає вимогам до використання AppArmor.

  3. Профіль завантажено — AppArmor застосовується до Podʼа, вказуючи профіль AppArmor, з яким кожен контейнер повинен працювати. Якщо будь-які вказані профілі не завантажені в ядро, Kubelet відхилить Pod. Ви можете переглянути завантажені профілі на вузлі, перевіривши файл /sys/kernel/security/apparmor/profiles. Наприклад:

    ssh gke-test-default-pool-239f5d02-gyn2 "sudo cat /sys/kernel/security/apparmor/profiles | sort"
    
    apparmor-test-deny-write (enforce)
    apparmor-test-audit-write (enforce)
    docker-default (enforce)
    k8s-nginx (enforce)
    

    Для отримання додаткової інформації щодо завантаження профілів на вузли, див. Налаштування вузлів з профілями.

Захист Podʼа

Профілі AppArmor можна вказати на рівні Podʼа або на рівні контейнера. Профіль AppArmor контейнера перевагу перед профілем Podʼа.

securityContext:
  appArmorProfile:
    type: <тип_профілю>

Де <тип_профілю> є одним з:

  • RuntimeDefault для використання типового профілю виконавчого середовища
  • Localhost для використання профілю, завантаженого на хост (див. нижче)
  • Unconfined для запуску без AppArmor

Для отримання повної інформації про API профілю AppArmor див. Вказівки щодо обмеження AppArmor.

Щоб перевірити, що профіль був застосований, ви можете перевірити, що кореневий процес контейнера працює з правильним профілем, переглянувши його атрибут proc:

kubectl exec <імʼя_пода> -- cat /proc/1/attr/current

Вивід повинен виглядати приблизно так:

cri-containerd.apparmor.d (enforce)

Приклад

Цей приклад передбачає, що ви вже налаштували кластер з підтримкою AppArmor.

Спочатку завантажте профіль, який ви хочете використовувати на вузлах. Цей профіль блокує всі операції запису файлів:

#include <tunables/global>

profile k8s-apparmor-example-deny-write flags=(attach_disconnected) {
  #include <abstractions/base>

  file,

   # Deny all file writes.
  deny /** w,
}

Профіль повинен бути завантажений на всі вузли, оскільки ви не знаєте, де буде заплановано Pod. Для цього прикладу ви можете використовувати SSH для встановлення профілів, але існують інші методи, які обговорюються в Налаштуваннях вузлів з профілями.

# Цей приклад передбачає, що імена вузлів відповідають іменам хостів і доступні через SSH.
NODES=($(kubectl get nodes -o name))

for NODE in ${NODES[*]}; do ssh $NODE 'sudo apparmor_parser -q <<EOF
#include <tunables/global>

profile k8s-apparmor-example-deny-write flags=(attach_disconnected) {
  #include <abstractions/base>

  file,

  # Заборонити всі записи файлів.
  deny /** w,
}
EOF'
done

Потім запустіть простий Pod "Hello AppArmor" з профілем deny-write:

apiVersion: v1
kind: Pod
metadata:
  name: hello-apparmor
spec:
  securityContext:
    appArmorProfile:
      type: Localhost
      localhostProfile: k8s-apparmor-example-deny-write
  containers:
  - name: hello
    image: busybox:1.28
    command: [ "sh", "-c", "echo 'Hello AppArmor!' && sleep 1h" ]
kubectl create -f hello-apparmor.yaml

Ви можете перевірити, що контейнер дійсно працює з тим профілем, перевіривши /proc/1/attr/current:

kubectl exec hello-apparmor -- cat /proc/1/attr/current

Вивід повинен бути:

k8s-apparmor-example-deny-write (enforce)

Нарешті, ви можете побачити, що відбудеться, якщо ви порушите профіль, здійснивши спробу зупису у файл:

kubectl exec hello-apparmor -- touch /tmp/test
touch: /tmp/test: Permission denied
error: error executing remote command: command terminated with non-zero exit code: Error executing in Docker Container: 1

Щоб завершити, подивіться, що станеться, якщо ви спробуєте вказати профіль, який не був завантажений:

kubectl create -f /dev/stdin <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: hello-apparmor-2
spec:
  securityContext:
    appArmorProfile:
      type: Localhost
      localhostProfile: k8s-apparmor-example-allow-write
  containers:
  - name: hello
    image: busybox:1.28
    command: [ "sh", "-c", "echo 'Hello AppArmor!' && sleep 1h" ]
EOF
pod/hello-apparmor-2 created

Хоча Pod було створено успішно, подальший огляд покаже, що він застряг в стані очікування:

kubectl describe pod hello-apparmor-2
Name:          hello-apparmor-2
Namespace:     default
Node:          gke-test-default-pool-239f5d02-x1kf/10.128.0.27
Start Time:    Tue, 30 Aug 2016 17:58:56 -0700
Labels:        <none>
Annotations:   container.apparmor.security.beta.kubernetes.io/hello=localhost/k8s-apparmor-example-allow-write
Status:        Pending
... 
Events:
  Type     Reason     Age              From               Message
  ----     ------     ----             ----               -------
  Normal   Scheduled  10s              default-scheduler  Successfully assigned default/hello-apparmor to gke-test-default-pool-239f5d02-x1kf
  Normal   Pulled     8s               kubelet            Successfully pulled image "busybox:1.28" in 370.157088ms (370.172701ms including waiting)
  Normal   Pulling    7s (x2 over 9s)  kubelet            Pulling image "busybox:1.28"
  Warning  Failed     7s (x2 over 8s)  kubelet            Error: failed to get container spec opts: failed to generate apparmor spec opts: apparmor profile not found k8s-apparmor-example-allow-write
  Normal   Pulled     7s               kubelet            Successfully pulled image "busybox:1.28" in 90.980331ms (91.005869ms including waiting)

Event надає повідомлення про помилку з причиною, конкретне формулювання залежить від виконавчого середовища:

  Warning  Failed     7s (x2 over 8s)  kubelet            Error: failed to get container spec opts: failed to generate apparmor spec opts: apparmor profile not found 

Адміністрування

Налаштування вузлів з профілями

Kubernetes 1.31 не надає вбудованих механізмів для завантаження профілів AppArmor на Вузли. Профілі можна завантажити через власну інфраструктуру або інструменти, такі як Оператор профілів безпеки Kubernetes.

Планувальник не знає, які профілі завантажені на який Вузол, тому повний набір профілів повинні бути завантажені на кожен Вузол. Альтернативним підходом є додавання мітки Вузла для кожного профілю (або клас профілів) на Вузлі та використання селектора вузла, щоб забезпечити виконання Podʼа на Вузлі з потрібним профілем.

Створення профілів

Встановлення правильних профілів AppArmor може бути складною справою. На щастя, існують деякі інструменти, що допомагають у цьому:

  • aa-genprof та aa-logprof генерують правила профілю, моніторячи діяльність програми та логи та дозволяючи дії, які вона виконує. Додаткові інструкції надаються у документації AppArmor.
  • bane — генератор профілів AppArmor для Docker, який використовує спрощену мову профілю.

Для дослідження проблем з AppArmor ви можете перевірити системні логи, щоб побачити, що саме було заборонено. AppArmor логує вичерпні повідомлення в dmesg, а помилки зазвичай можна знайти в системних логах або за допомогою journalctl. Більше інформації надається в розділі AppArmor failures.

Вказівки щодо обмеження AppArmor

Профіль AppArmor у контексті безпеки

Ви можете вказати appArmorProfile як у контексті безпеки контейнера, так і в контексті безпеки Podʼа. Якщо профіль встановлено на ні Podʼа, він буде використовуватися як стандартний профіль всіх контейнерів у Podʼі (включаючи контейнери ініціалізації, допоміжний та тимчасовий контейнери). Якщо вказані профілі Podʼа та контейнера, буде використано профіль контейнера.

Профіль AppArmor має 2 поля:

type (обовʼязково) — вказує, який тип профілю AppArmor буде застосований. Дійсні варіанти:

Localhost
профіль, завантажений на вузол (вказаний як localhostProfile).
RuntimeDefault
типовий профіль виконавчого середовища контейнера.
Unconfined
без застосування AppArmor.

localhostProfile — Назва профілю, завантаженого на вузол, який слід використовувати. Профіль повинен бути попередньо налаштований на вузлі, щоб працювати. Цей параметр потрібно вказувати лише в разі, якщо type — Localhost.

Що далі

Додаткові ресурси:

5.4.4 - Обмеження системних викликів контейнера за допомогою seccomp

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.19 [stable]

Seccomp походить від secure computing mode (безпечний режим обчислення) і є функцією ядра Linux з версії 2.6.12. Його можна використовувати для ізоляції привілеїв процесу, обмежуючи виклики, які він може здійснювати з простору користувача в ядро. Kubernetes дозволяє автоматично застосовувати профілі seccomp, завантажені на вузол, до ваших Podʼів та контейнерів.

Визначення необхідних привілеїв для ваших робочих навантажень може бути важким завданням. У цьому посібнику ви дізнаєтеся, як завантажувати профілі seccomp в локальний кластер Kubernetes, як застосовувати їх до Podʼа та як ви можете почати створювати профілі, які надають лише необхідні привілеї процесам вашого контейнера.

Цілі

  • Навчитися завантажувати профілі seccomp на вузол
  • Навчитися застосовувати профіль seccomp до контейнера
  • Спостерігати за аудитом системних викликів, здійснюваних процесом контейнера
  • Спостерігати поведінку при відсутності вказаного профілю
  • Спостерігати порушення профілю seccomp
  • Навчитися створювати деталізовані профілі seccomp
  • Навчитися застосовувати стандартний профіль seccomp для контейнера

Перш ніж ви розпочнете

Для завершення всіх кроків у цьому посібнику вам потрібно встановити kind та kubectl.

Команди, які використовуються в посібнику, передбачають, що ви використовуєте Docker як ваше середовище для виконання контейнерів. (Кластер, який створює kind, може використовувати інше контейнерне середовище також). Ви також можете використовувати Podman, але у цьому випадку вам доведеться дотримуватися відповідних інструкцій, щоб успішно виконати завдання.

У цьому посібнику показано деякі приклади, які є бета-версією (починаючи з v1.25) і інші, які використовують лише загальнодоступну функціональність seccomp. Вам слід переконатися, що ваш кластер правильно налаштований для версії, яку ви використовуєте.

У посібнику також використовується інструмент curl для завантаження прикладів на ваш компʼютер. Ви можете адаптувати кроки, щоб використовувати інший інструмент, якщо вам це зручно.

Завантаження прикладів профілів seccomp

Вміст цих профілів буде досліджено пізніше, але наразі продовжте та завантажте їх у каталог з назвою profiles/, щоб їх можна було завантажити в кластер.

{
    "defaultAction": "SCMP_ACT_LOG"
}

{
    "defaultAction": "SCMP_ACT_ERRNO"
}

{
    "defaultAction": "SCMP_ACT_ERRNO",
    "architectures": [
        "SCMP_ARCH_X86_64",
        "SCMP_ARCH_X86",
        "SCMP_ARCH_X32"
    ],
    "syscalls": [
        {
            "names": [
                "accept4",
                "epoll_wait",
                "pselect6",
                "futex",
                "madvise",
                "epoll_ctl",
                "getsockname",
                "setsockopt",
                "vfork",
                "mmap",
                "read",
                "write",
                "close",
                "arch_prctl",
                "sched_getaffinity",
                "munmap",
                "brk",
                "rt_sigaction",
                "rt_sigprocmask",
                "sigaltstack",
                "gettid",
                "clone",
                "bind",
                "socket",
                "openat",
                "readlinkat",
                "exit_group",
                "epoll_create1",
                "listen",
                "rt_sigreturn",
                "sched_yield",
                "clock_gettime",
                "connect",
                "dup2",
                "epoll_pwait",
                "execve",
                "exit",
                "fcntl",
                "getpid",
                "getuid",
                "ioctl",
                "mprotect",
                "nanosleep",
                "open",
                "poll",
                "recvfrom",
                "sendto",
                "set_tid_address",
                "setitimer",
                "writev",
                "fstatfs",
                "getdents64",
                "pipe2",
                "getrlimit"
            ],
            "action": "SCMP_ACT_ALLOW"
        }
    ]
}

Виконайте ці команди:

mkdir ./profiles
curl -L -o profiles/audit.json https://k8s.io/examples/pods/security/seccomp/profiles/audit.json
curl -L -o profiles/violation.json https://k8s.io/examples/pods/security/seccomp/profiles/violation.json
curl -L -o profiles/fine-grained.json https://k8s.io/examples/pods/security/seccomp/profiles/fine-grained.json
ls profiles

Ви повинні побачити три профілі, перераховані в кінці останнього кроку:

audit.json  fine-grained.json  violation.json

Створення локального кластера Kubernetes за допомогою kind

Для спрощення можна використовувати kind, щоб створити одновузловий кластер з завантаженими профілями seccomp. Kind запускає Kubernetes в Docker, тому кожен вузол кластера є контейнером. Це дозволяє монтувати файли в файлову систему кожного контейнера, схоже на завантаження файлів на вузол.

apiVersion: kind.x-k8s.io/v1alpha4
kind: Cluster
nodes:
- role: control-plane
  extraMounts:
  - hostPath: "./profiles"
    containerPath: "/var/lib/kubelet/seccomp/profiles"

Завантажте цей приклад конфігурації kind та збережіть його у файлі з назвою kind.yaml:

curl -L -O https://k8s.io/examples/pods/security/seccomp/kind.yaml

Ви можете встановити конкретну версію Kubernetes, встановивши образ контейнера вузла. Дивіться Вузли в документації kind щодо конфігурації для отримання більш детальної інформації з цього питання. Цей посібник передбачає, що ви використовуєте Kubernetes v1.31.

Як бета-функція, ви можете налаштувати Kubernetes на використання профілю, який обирає стандартне середовище виконання контейнерів, замість того, щоб використовувати Unconfined. Якщо ви хочете спробувати це, дивіться увімкнення використання RuntimeDefault як типового профілю за замовчуванням для всіх завдань перш ніж продовжувати.

Як тільки у вас буде конфігурація kind, створіть кластер kind з цією конфігурацією:

kind create cluster --config=kind.yaml

Після створення нового кластера Kubernetes ідентифікуйте контейнер Docker, що працює як одновузловий кластер:

docker ps

Ви повинні побачити вивід, який вказує на те, що контейнер працює з назвою kind-control-plane, подібний до:

CONTAINER ID        IMAGE                  COMMAND                  CREATED             STATUS              PORTS                       NAMES
6a96207fed4b        kindest/node:v1.18.2   "/usr/local/bin/entr…"   27 seconds ago      Up 24 seconds       127.0.0.1:42223->6443/tcp   kind-control-plane

Якщо спостерігати файлову систему цього контейнера, ви побачите, що тека profiles/ була успішно завантажена в стандартний шлях seccomp з kubelet. Використовуйте docker exec, щоб виконати команду в Podʼі:

# Змініть 6a96207fed4b на ідентифікатор контейнера, який ви знайдете в результаті "docker ps"
docker exec -it 6a96207fed4b ls /var/lib/kubelet/seccomp/profiles
audit.json  fine-grained.json  violation.json

Ви перевірили, що ці профілі seccomp доступні для kubelet, що працює всередині kind.

Створення Pod, що використовує стандартний профіль seccomp середовища виконання контейнерів

Більшість контейнерних середовищ надають типовий перелік системних викликів, які дозволені або заборонені. Ви можете використовувати ці стандартні налаштування для вашого робочого навантаження, встановивши тип seccomp у контексті безпеки Pod або контейнера на RuntimeDefault.

Ось маніфест Podʼа, який запитує профіль seccomp RuntimeDefault для всіх своїх контейнерів:

apiVersion: v1
kind: Pod
metadata:
  name: default-pod
  labels:
    app: default-pod
spec:
  securityContext:
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: test-container
    image: hashicorp/http-echo:1.0
    args:
    - "-text=just made some more syscalls!"
    securityContext:
      allowPrivilegeEscalation: false

Створіть цей Pod:

kubectl apply -f https://k8s.io/examples/pods/security/seccomp/ga/default-pod.yaml
kubectl get pod default-pod

Под повинен бути запущений успішно:

NAME        READY   STATUS    RESTARTS   AGE
default-pod 1/1     Running   0          20s

Видаліть Pod перед переходом до наступного розділу:

kubectl delete pod default-pod --wait --now

Створення Podʼа з профілем seccomp для аудиту системних викликів

Для початку, застосуйте профіль audit.json, який буде записувати всі системні виклики процесу, до нового Podʼа.

Ось маніфест для цього Podʼа:

apiVersion: v1
kind: Pod
metadata:
  name: audit-pod
  labels:
    app: audit-pod
spec:
  securityContext:
    seccompProfile:
      type: Localhost
      localhostProfile: profiles/audit.json
  containers:
  - name: test-container
    image: hashicorp/http-echo:1.0
    args:
    - "-text=just made some syscalls!"
    securityContext:
      allowPrivilegeEscalation: false

Створіть Pod у кластері:

kubectl apply -f https://k8s.io/examples/pods/security/seccomp/ga/audit-pod.yaml

Цей профіль не обмежує жодні системні виклики, тому Pod повинен успішно запуститися.

kubectl get pod audit-pod
NAME        READY   STATUS    RESTARTS   AGE
audit-pod   1/1     Running   0          30s

Щоб мати можливість взаємодіяти з цим точкою доступу, створіть Service NodePort, який дозволяє доступ до точки доступу зсередини контейнера панелі управління kind.

kubectl expose pod audit-pod --type NodePort --port 5678

Перевірте, який порт було призначено Service на вузлі.

kubectl get service audit-pod

Вивід буде схожим на:

NAME        TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
audit-pod   NodePort   10.111.36.142   <none>        5678:32373/TCP   72s

Тепер ви можете використовувати curl, щоб отримати доступ до цієї точки доступу зсередини контейнера панелі управління kind на порту, який було відкрито цим Service. Використовуйте docker exec, щоб виконати команду curl всередині контейнера панелі управління:

# Змініть 6a96207fed4b на ідентифікатор контейнера панелі управління та 32373 на номер порту, який ви побачили у "docker ps"
docker exec -it 6a96207fed4b curl localhost:32373
just made some syscalls!

Ви можете бачити, що процес працює, але які саме системні виклики він робить? Оскільки цей Pod працює у локальному кластері, ви повинні бачити їх у /var/log/syslog у вашій локальній системі. Відкрийте нове вікно термінала та використовуйте команду tail, щоб переглянути виклики від http-echo:

# Шлях до логу на вашому компʼютері може відрізнятися від "/var/log/syslog"
tail -f /var/log/syslog | grep 'http-echo'

Ви вже повинні бачити деякі логи системних викликів, зроблених http-echo, і якщо ви знову запустите curl всередині контейнера панелі управління, ви побачите більше записів у лозі.

Наприклад:

Jul  6 15:37:40 my-machine kernel: [369128.669452] audit: type=1326 audit(1594067860.484:14536): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=29064 comm="http-echo" exe="/http-echo" sig=0 arch=c000003e syscall=51 compat=0 ip=0x46fe1f code=0x7ffc0000
Jul  6 15:37:40 my-machine kernel: [369128.669453] audit: type=1326 audit(1594067860.484:14537): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=29064 comm="http-echo" exe="/http-echo" sig=0 arch=c000003e syscall=54 compat=0 ip=0x46fdba code=0x7ffc0000
Jul  6 15:37:40 my-machine kernel: [369128.669455] audit: type=1326 audit(1594067860.484:14538): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=29064 comm="http-echo" exe="/http-echo" sig=0 arch=c000003e syscall=202 compat=0 ip=0x455e53 code=0x7ffc0000
Jul  6 15:37:40 my-machine kernel: [369128.669456] audit: type=1326 audit(1594067860.484:14539): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=29064 comm="http-echo" exe="/http-echo" sig=0 arch=c000003e syscall=288 compat=0 ip=0x46fdba code=0x7ffc0000
Jul  6 15:37:40 my-machine kernel: [369128.669517] audit: type=1326 audit(1594067860.484:14540): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=29064 comm="http-echo" exe="/http-echo" sig=0 arch=c000003e syscall=0 compat=0 ip=0x46fd44 code=0x7ffc0000
Jul  6 15:37:40 my-machine kernel: [369128.669519] audit: type=1326 audit(1594067860.484:14541): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=29064 comm="http-echo" exe="/http-echo" sig=0 arch=c000003e syscall=270 compat=0 ip=0x4559b1 code=0x7ffc0000
Jul  6 15:38:40 my-machine kernel: [369188.671648] audit: type=1326 audit(1594067920.488:14559): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=29064 comm="http-echo" exe="/http-echo" sig=0 arch=c000003e syscall=270 compat=0 ip=0x4559b1 code=0x7ffc0000
Jul  6 15:38:40 my-machine kernel: [369188.671726] audit: type=1326 audit(1594067920.488:14560): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=29064 comm="http-echo" exe="/http-echo" sig=0 arch=c000003e syscall=202 compat=0 ip=0x455e53 code=0x7ffc0000

Ви можете почати розуміти системні виклики, необхідні для процесу http-echo, переглядаючи запис syscall= на кожному рядку. Хоча ці виклики навряд чи охоплюють усі системні виклики, які він використовує, це може слугувати основою для профілю seccomp для цього контейнера.

Видаліть Service та Pod перед переходом до наступного розділу:

kubectl delete service audit-pod --wait
kubectl delete pod audit-pod --wait --now

Створення Podʼа з профілем seccomp, що спричиняє порушення правил

Для демонстрації застосуйте до Podʼа профіль, який не дозволяє жодних системних викликів.

Ось маніфест для цієї демонстрації:

apiVersion: v1
kind: Pod
metadata:
  name: violation-pod
  labels:
    app: violation-pod
spec:
  securityContext:
    seccompProfile:
      type: Localhost
      localhostProfile: profiles/violation.json
  containers:
  - name: test-container
    image: hashicorp/http-echo:1.0
    args:
    - "-text=just made some syscalls!"
    securityContext:
      allowPrivilegeEscalation: false

Спробуйте створити Pod у кластері:

kubectl apply -f https://k8s.io/examples/pods/security/seccomp/ga/violation-pod.yaml

Pod буде створено, але виникне проблема. Якщо ви перевірите стан Podʼа, ви побачите, що його не вдалося запустити.

kubectl get pod violation-pod
NAME            READY   STATUS             RESTARTS   AGE
violation-pod   0/1     CrashLoopBackOff   1          6s

Як видно з попереднього прикладу, процес http-echo потребує досить багато системних викликів. У цьому випадку seccomp було налаштовано на помилку при будь-якому системному виклику, встановивши "defaultAction": "SCMP_ACT_ERRNO". Це надзвичайно безпечно, але робить неможливим виконання будь-яких значущих дій. Насправді ви хочете надати робочим навантаженням тільки ті привілеї, які їм потрібні.

Видаліть Pod перед переходом до наступного розділу:

kubectl delete pod violation-pod --wait --now

Створення Podʼа з профілем seccomp, що дозволяє лише необхідні системні виклики

Якщо ви подивитеся на профіль fine-grained.json, ви помітите деякі з системних викликів, які спостерігалися в syslog у першому прикладі, де профіль встановлював "defaultAction": "SCMP_ACT_LOG". Тепер профіль встановлює "defaultAction": "SCMP_ACT_ERRNO", але явно дозволяє набір системних викликів у блоці "action": "SCMP_ACT_ALLOW". Ідеально, якщо контейнер буде успішно працювати, і ви не побачите жодних повідомлень у syslog.

Маніфест для цього прикладу:

apiVersion: v1
kind: Pod
metadata:
  name: fine-pod
  labels:
    app: fine-pod
spec:
  securityContext:
    seccompProfile:
      type: Localhost
      localhostProfile: profiles/fine-grained.json
  containers:
  - name: test-container
    image: hashicorp/http-echo:1.0
    args:
    - "-text=just made some syscalls!"
    securityContext:
      allowPrivilegeEscalation: false

Створіть Pod у вашому кластері:

kubectl apply -f https://k8s.io/examples/pods/security/seccomp/ga/fine-pod.yaml
kubectl get pod fine-pod

Pod має успішно запуститися:

NAME        READY   STATUS    RESTARTS   AGE
fine-pod   1/1     Running   0          30s

Відкрийте нове вікно термінала і використовуйте tail для моніторингу записів лога, які згадують виклики від http-echo:

# Шлях до лога на вашому компʼютері може відрізнятися від "/var/log/syslog"
tail -f /var/log/syslog | grep 'http-echo'

Далі, опублікуйте Pod за допомогою Service NodePort:

kubectl expose pod fine-pod --type NodePort --port 5678

Перевірте, який порт було призначено для цього сервісу на вузлі:

kubectl get service fine-pod

Вихідні дані можуть виглядати приблизно так:

NAME        TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
fine-pod    NodePort   10.111.36.142   <none>        5678:32373/TCP   72s

Використовуйте curl для доступу до цієї точки доступу з контейнера панелі управління kind:

# Змініть 6a96207fed4b на ID контейнера панелі управління і 32373 на номер порту, який ви побачили у "docker ps"
docker exec -it 6a96207fed4b curl localhost:32373
just made some syscalls!

Ви не повинні побачити жодних записів у syslog. Це тому, що профіль дозволив усі необхідні системні виклики та вказав, що повинна статися помилка, якщо буде викликано виклик, який не входить до списку. Це ідеальна ситуація з погляду безпеки, але потребує певних зусиль для аналізу програми. Було б добре, якби існував простий спосіб наблизитися до такої безпеки без стількох зусиль.

Видаліть Service і Pod перед переходом до наступного розділу:

kubectl delete service fine-pod --wait
kubectl delete pod fine-pod --wait --now

Увімкнення використання RuntimeDefault як стандартного профілю seccomp для всіх робочих навантажень

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.27 [stable]

Для використання стандартного профілю seccomp, необхідно запустити kubelet з параметром командного рядка --seccomp-default увімкненим для кожного вузла, де ви хочете його використовувати.

Якщо ця функція увімкнена, kubelet буде використовувати як типовий профіль seccomp RuntimeDefault, який визначений середовищем виконання контейнерів, замість використання режиму Unconfined (seccomp вимкнений). Типові профілі прагнуть забезпечити сильний набір налаштувань безпеки, зберігаючи функціональність робочих навантажень. Можливо, типові профілі відрізняються між середовищами виконання контейнерів та їх версіями випуску, наприклад, порівнюючи профілів CRI-O та containerd.

Деякі робочі навантаження можуть вимагати меншої кількості обмежень системних викликів, ніж інші. Це означає, що вони можуть зазнати невдачі під час виконання навіть із профілем RuntimeDefault. Для помʼякшення таких невдач можна:

  • Запустити робоче навантаження явно як Unconfined.
  • Вимкнути функцію SeccompDefault для вузлів, забезпечуючи, щоб робочі навантаження виконувалися на вузлах, де ця функція вимкнена.
  • Створити власний профіль seccomp для робочого навантаження.

Якщо ви вводите цю функцію до кластера подібного до операційного, проєкт Kubernetes рекомендує увімкнути цю функцію на підмножині ваших вузлів та перевірити виконання робочих навантажень перед повсюдним впровадженням змін.

Детальнішу інформацію про можливу стратегію оновлення та відкату ви можете знайти в повʼязаній пропозиції щодо поліпшення Kubernetes (KEP): Увімкнення seccomp стандартно.

Kubernetes 1.31 дозволяє налаштувати профіль seccomp, який застосовується, коли специфікація для Podʼа не визначає конкретний профіль seccomp. Однак, вам все одно потрібно увімкнути це налаштування як типове для кожного вузла, де ви хочете його використовувати.

Якщо ви працюєте у кластері Kubernetes 1.31 і хочете увімкнути цю функцію, ви можете запустити kubelet з параметром командного рядка --seccomp-default або увімкнути її через файл конфігурації kubelet. Щоб увімкнути цю функцію у kind, переконайтеся, що kind забезпечує мінімально необхідну версію Kubernetes і вмикає функцію SeccompDefault у конфігурації kind:

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
  - role: control-plane
    image: kindest/node:v1.28.0@sha256:9f3ff58f19dcf1a0611d11e8ac989fdb30a28f40f236f59f0bea31fb956ccf5c
    kubeadmConfigPatches:
      - |
        kind: JoinConfiguration
        nodeRegistration:
          kubeletExtraArgs:
            seccomp-default: "true"        
  - role: worker
    image: kindest/node:v1.28.0@sha256:9f3ff58f19dcf1a0611d11e8ac989fdb30a28f40f236f59f0bea31fb956ccf5c
    kubeadmConfigPatches:
      - |
        kind: JoinConfiguration
        nodeRegistration:
          kubeletExtraArgs:
            seccomp-default: "true"        

Якщо кластер готовий, тоді запустіть Pod:

kubectl run --rm -it --restart=Never --image=alpine alpine -- sh

тепер він повинен мати прикріплений типовий профіль seccomp. Це можна перевірити, використовуючи docker exec для запуску crictl inspect для контейнера на вузлі kind:

docker exec -it kind-worker bash -c \
    'crictl inspect $(crictl ps --name=alpine -q) | jq .info.runtimeSpec.linux.seccomp'
{
  "defaultAction": "SCMP_ACT_ERRNO",
  "architectures": ["SCMP_ARCH_X86_64", "SCMP_ARCH_X86", "SCMP_ARCH_X32"],
  "syscalls": [
    {
      "names": ["..."]
    }
  ]
}

Що далі

Ви можете дізнатися більше про Linux seccomp:

5.5 - Stateless застосунки

5.5.1 - Відкриття зовнішньої IP-адреси для доступу до застосунку в кластері

Ця сторінка показує, як створити обʼєкт Kubernetes Service, який відкриває зовнішню IP-адресу.

Перш ніж ви розпочнете

  • Встановіть kubectl.
  • Використовуйте хмарного провайдера, такого як Google Kubernetes Engine або Amazon Web Services, щоб створити кластер Kubernetes. У цьому підручнику створюється зовнішній балансувальник навантаження, який вимагає хмарного провайдера.
  • Налаштуйте kubectl для спілкування з вашим API-сервером Kubernetes. Для інструкцій дивіться документацію вашого хмарного провайдера.

Цілі

  • Запустіть пʼять екземплярів застосунку Hello World.
  • Створіть обʼєкт Service, який відкриває зовнішню IP-адресу.
  • Використовуйте обʼєкт Service для доступу до запущеного застосунку.

Створення Service для застосунку, що працює в пʼяти Podʼах

  1. Запустіть застосунок Hello World у вашому кластері:

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      labels:
        app.kubernetes.io/name: load-balancer-example
      name: hello-world
    spec:
      replicas: 5
      selector:
        matchLabels:
          app.kubernetes.io/name: load-balancer-example
      template:
        metadata:
          labels:
            app.kubernetes.io/name: load-balancer-example
        spec:
          containers:
          - image: gcr.io/google-samples/hello-app:2.0
            name: hello-world
            ports:
            - containerPort: 8080
    
    kubectl apply -f https://k8s.io/examples/service/load-balancer-example.yaml
    

    Попередня команда створює Deployment і повʼязаний з ним ReplicaSet. ReplicaSet має пʼять Podʼів, кожен з яких запускає застосунок Hello World.

  2. Виведіть інформацію про Deployment:

    kubectl get deployments hello-world
    kubectl describe deployments hello-world
    
  3. Виведіть інформацію про обʼєкти ReplicaSet:

    kubectl get replicasets
    kubectl describe replicasets
    
  4. Створіть обʼєкт Service, який експонує Deployment:

    kubectl expose deployment hello-world --type=LoadBalancer --name=my-service
    
  5. Виведіть інформацію про Service:

    kubectl get services my-service
    

    Вивід буде подібний до:

    NAME         TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)    AGE
    my-service   LoadBalancer   10.3.245.137   104.198.205.71   8080/TCP   54s
    
  6. Виведіть детальну інформацію про Service:

    kubectl describe services my-service
    

    Вивід буде подібний до:

    Name:           my-service
    Namespace:      default
    Labels:         app.kubernetes.io/name=load-balancer-example
    Annotations:    <none>
    Selector:       app.kubernetes.io/name=load-balancer-example
    Type:           LoadBalancer
    IP:             10.3.245.137
    LoadBalancer Ingress:   104.198.205.71
    Port:           <unset> 8080/TCP
    NodePort:       <unset> 32377/TCP
    Endpoints:      10.0.0.6:8080,10.0.1.6:8080,10.0.1.7:8080 + 2 more...
    Session Affinity:   None
    Events:         <none>
    

    Занотуйте зовнішню IP-адресу (LoadBalancer Ingress), відкриту вашим сервісом. У цьому прикладі, зовнішня IP-адреса — 104.198.205.71. Також занотуйте значення Port і NodePort. У цьому прикладі, Port — 8080, а NodePort — 32377.

  7. У попередньому виводі ви можете побачити, що сервіс має кілька точок доступу: 10.0.0.6:8080, 10.0.1.6:8080, 10.0.1.7:8080 + ще 2. Це внутрішні адреси Podʼів, які запускають застосунок Hello World. Щоб переконатися, що це адреси Podʼів, введіть цю команду:

    kubectl get pods --output=wide
    

    Вивід буде подібний до:

    NAME                         ...  IP         NODE
    hello-world-2895499144-1jaz9 ...  10.0.1.6   gke-cluster-1-default-pool-e0b8d269-1afc
    hello-world-2895499144-2e5uh ...  10.0.1.8   gke-cluster-1-default-pool-e0b8d269-1afc
    hello-world-2895499144-9m4h1 ...  10.0.0.6   gke-cluster-1-default-pool-e0b8d269-5v7a
    hello-world-2895499144-o4z13 ...  10.0.1.7   gke-cluster-1-default-pool-e0b8d269-1afc
    hello-world-2895499144-segjf ...  10.0.2.5   gke-cluster-1-default-pool-e0b8d269-cpuc
    
  8. Використовуйте зовнішню IP-адресу (LoadBalancer Ingress) для доступу до застосунку Hello World:

    curl http://<external-ip>:<port>
    

    де <external-ip> — це зовнішня IP-адреса (LoadBalancer Ingress) вашого сервісу, а <port> — значення Port в описі вашого сервісу. Якщо ви використовуєте minikube, ввівши minikube service my-service автоматично відкриє застосунок Hello World в оглядачі.

    Відповідь на успішний запит — привітальне повідомлення:

    Hello, world!
    Version: 2.0.0
    Hostname: 0bd46b45f32f
    

Очищення

Щоб видалити Service, введіть цю команду:

kubectl delete services my-service

Щоб видалити Deployment, ReplicaSet і Podʼи, які запускають застосунок Hello World, введіть цю команду:

kubectl delete deployment hello-world

Що далі

Дізнайтеся більше про Підключення застосунків за допомогою Service.

5.5.2 - Приклад: Розгортання PHP застосунку гостьової книги з Redis

Цей посібник показує, як створити та розгорнути простий (але не готовий до промислового використання) багатошаровий вебзастосунок, використовуючи Kubernetes та Docker. Цей приклад складається з наступних компонентів:

  • Одно-екземплярний Redis для зберігання записів у гостьовій книзі
  • Кілька веб-фронтендів

Цілі

  • Запустити Redis-лідер.
  • Запустити двох Redis-фолловерів.
  • Запустити фронтенд гостьової книги.
  • Опублікувати та переглянути Frontend Service.
  • Виконати очищення.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Версія вашого Kubernetes сервера має бути не старішою ніж v1.14. Для перевірки версії введіть kubectl version.

Запуск бази даних Redis

Застосунок гостьової книги використовує Redis для зберігання своїх даних.

Створення Deployment Redis

Файл маніфесту, наведений нижче, визначає контролер Deployment, який запускає одну репліку Redis Pod.

# SOURCE: https://cloud.google.com/kubernetes-engine/docs/tutorials/guestbook
apiVersion: apps/v1
kind: Deployment
metadata:
  name: redis-leader
  labels:
    app: redis
    role: leader
    tier: backend
spec:
  replicas: 1
  selector:
    matchLabels:
      app: redis
  template:
    metadata:
      labels:
        app: redis
        role: leader
        tier: backend
    spec:
      containers:
      - name: leader
        image: "docker.io/redis:6.0.5"
        resources:
          requests:
            cpu: 100m
            memory: 100Mi
        ports:
        - containerPort: 6379
  1. Відкрийте вікно термінала в теці, куди ви завантажили файли маніфестів.

  2. Застосуйте Deployment Redis з файлу redis-leader-deployment.yaml:

    kubectl apply -f https://k8s.io/examples/application/guestbook/redis-leader-deployment.yaml
    
  3. Перевірте список Podʼів, щоб переконатися, що Pod Redis запущений:

    kubectl get pods
    

    Відповідь повинна бути схожою на цю:

    NAME                           READY   STATUS    RESTARTS   AGE
    redis-leader-fb76b4755-xjr2n   1/1     Running   0          13s
    
  4. Виконайте наступну команду, щоб переглянути лог з Podʼа Redis лідера:

    kubectl logs -f deployment/redis-leader
    

Створення Service Redis-лідера

Застосунок гостьової книги потребує звʼязку з Redis для запису своїх даних. Вам потрібно застосувати Service, щоб спрямовувати трафік до Pod Redis. Service визначає політику доступу до Podʼів.

# SOURCE: https://cloud.google.com/kubernetes-engine/docs/tutorials/guestbook
apiVersion: v1
kind: Service
metadata:
  name: redis-leader
  labels:
    app: redis
    role: leader
    tier: backend
spec:
  ports:
  - port: 6379
    targetPort: 6379
  selector:
    app: redis
    role: leader
    tier: backend
  1. Застосуйте Service Redis з файлу redis-leader-service.yaml:

    kubectl apply -f https://k8s.io/examples/application/guestbook/redis-leader-service.yaml
    
  2. Перевірте список Serviceʼів, щоб переконатися, що Service Redis запущений:

    kubectl get service
    

    Відповідь повинна бути схожою на цю:

    NAME           TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)    AGE
    kubernetes     ClusterIP   10.0.0.1     <none>        443/TCP    1m
    redis-leader   ClusterIP   10.103.78.24 <none>        6379/TCP   16s
    

Налаштування Redis-фолловерів

Хоча Redis-лідер є одним Pod, ви можете зробити його високо доступним і задовольняти потреби в трафіку, додавши кілька фолловерів Redis або реплік.

# SOURCE: https://cloud.google.com/kubernetes-engine/docs/tutorials/guestbook
apiVersion: apps/v1
kind: Deployment
metadata:
  name: redis-follower
  labels:
    app: redis
    role: follower
    tier: backend
spec:
  replicas: 2
  selector:
    matchLabels:
      app: redis
  template:
    metadata:
      labels:
        app: redis
        role: follower
        tier: backend
    spec:
      containers:
      - name: follower
        image: us-docker.pkg.dev/google-samples/containers/gke/gb-redis-follower:v2
        resources:
          requests:
            cpu: 100m
            memory: 100Mi
        ports:
        - containerPort: 6379
  1. Застосуйте Deployment Redis з файлу redis-follower-deployment.yaml:

    kubectl apply -f https://k8s.io/examples/application/guestbook/redis-follower-deployment.yaml
    
  2. Перевірте, що дві репліки Redis-фолловерів запущені, виконавши запит списку Podʼів:

    kubectl get pods
    

    Відповідь повинна бути схожою на цю:

    NAME                             READY   STATUS    RESTARTS   AGE
    redis-follower-dddfbdcc9-82sfr   1/1     Running   0          37s
    redis-follower-dddfbdcc9-qrt5k   1/1     Running   0          38s
    redis-leader-fb76b4755-xjr2n     1/1     Running   0          11m
    

Створення Service Redis-фолловера

Застосунок гостьової книги потребує зʼязку з фолловерами Redis для читання даних. Щоб зробити фолловерів Redis доступними, потрібно налаштувати інший Service.

# SOURCE: https://cloud.google.com/kubernetes-engine/docs/tutorials/guestbook
apiVersion: v1
kind: Service
metadata:
  name: redis-follower
  labels:
    app: redis
    role: follower
    tier: backend
spec:
  ports:
    # порт на якому повинен працювати цей Service
  - port: 6379
  selector:
    app: redis
    role: follower
    tier: backend
  1. Застосуйте сервіс Redis з файлу redis-follower-service.yaml:

    kubectl apply -f https://k8s.io/examples/application/guestbook/redis-follower-service.yaml
    
  2. Перевірте список Serviceʼів, щоб переконатися, що Service Redis запущений:

    kubectl get service
    

    Відповідь повинна бути схожою на цю:

    NAME             TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
    kubernetes       ClusterIP   10.96.0.1       <none>        443/TCP    3d19h
    redis-follower   ClusterIP   10.110.162.42   <none>        6379/TCP   9s
    redis-leader     ClusterIP   10.103.78.24    <none>        6379/TCP   6m10s
    

Налаштування та експонування фронтенда гостьової книги

Тепер, коли ви запустили сховище Redis для своєї гостьової книги, запустіть вебсервери фронтенду. Як і фолловери Redis, фронтенд розгортається за допомогою контролера Deployment Kubernetes.

Застосунок гостьової книги використовує PHP фронтенд. Він налаштований для звʼязку з Serviceʼами фолловера або лідера Redis, залежно від того, чи є запит читанням або записом. Фронтенд відкриває інтерфейс JSON та забезпечує UX на основі jQuery-Ajax.

Створення Deployment фронтенду гостьової книги

# SOURCE: https://cloud.google.com/kubernetes-engine/docs/tutorials/guestbook
apiVersion: apps/v1
kind: Deployment
metadata:
  name: frontend
spec:
  replicas: 3
  selector:
    matchLabels:
        app: guestbook
        tier: frontend
  template:
    metadata:
      labels:
        app: guestbook
        tier: frontend
    spec:
      containers:
      - name: php-redis
        image: us-docker.pkg.dev/google-samples/containers/gke/gb-frontend:v5
        env:
        - name: GET_HOSTS_FROM
          value: "dns"
        resources:
          requests:
            cpu: 100m
            memory: 100Mi
        ports:
        - containerPort: 80
  1. Застосуйте розгортання фронтенду з файлу frontend-deployment.yaml:

    kubectl apply -f https://k8s.io/examples/application/guestbook/frontend-deployment.yaml
    
  2. Перевірте список Podʼів, щоб переконатися, що три репліки фронтенду запущені:

    kubectl get pods -l app=guestbook -l tier=frontend
    

    Відповідь повинна бути схожою на цю:

    NAME                        READY   STATUS    RESTARTS   AGE
    frontend-85595f5bf9-5tqhb   1/1     Running   0          47s
    frontend-85595f5bf9-qbzwm   1/1     Running   0          47s
    frontend-85595f5bf9-zchwc   1/1     Running   0          47s
    

Створення Service для Фронтенду

Serviceʼи Redis, які ви створили, доступні тільки всередині кластера Kubernetes, оскільки типовий тип для Service — ClusterIP. ClusterIP надає одну IP-адресу для набору Podʼів, на які вказує Service. Ця IP-адреса доступна тільки всередині кластера.

Якщо ви хочете, щоб гості могли отримати доступ до вашої гостьової книги, ви повинні налаштувати Service фронтенду таким чином, щоб він був видимий зовні, щоб клієнт міг запитувати Service ззовні кластера Kubernetes. Проте користувачі Kubernetes можуть скористатися командою kubectl port-forward, щоб отримати доступ до Service, навіть якщо він використовує ClusterIP.

# SOURCE: https://cloud.google.com/kubernetes-engine/docs/tutorials/guestbook
apiVersion: v1
kind: Service
metadata:
  name: frontend
  labels:
    app: guestbook
    tier: frontend
spec:
  # якщо ваш кластер підтримує це, розкоментуйте наступне, щоб автоматично створити
  # зовнішню IP-адресу з балансуванням навантаження для служби frontend.
  # type: LoadBalancer
  #type: LoadBalancer
  ports:
    # порт на якому має працювати цей Service
  - port: 80
  selector:
    app: guestbook
    tier: frontend
  1. Застосуйте Service фронтенду з файлу frontend-service.yaml:

    kubectl apply -f https://k8s.io/examples/application/guestbook/frontend-service.yaml
    
  2. Виконайте запит для отримання списку Service, щоб переконатися, що Service фронтенду запущений:

    kubectl get services
    

    Відповідь повинна бути схожою на цю:

    NAME             TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
    frontend         ClusterIP   10.97.28.230    <none>        80/TCP     19s
    kubernetes       ClusterIP   10.96.0.1       <none>        443/TCP    3d19h
    redis-follower   ClusterIP   10.110.162.42   <none>        6379/TCP   5m48s
    redis-leader     ClusterIP   10.103.78.24    <none>        6379/TCP   11m
    

Перегляд Service Фронтенду через kubectl port-forward

  1. Виконайте наступну команду, щоб перенаправити порт 8080 на вашій локальній машині на порт 80 на сервісі.

    kubectl port-forward svc/frontend 8080:80
    

    Відповідь повинна бути схожою на цю:

    Forwarding from 127.0.0.1:8080 -> 80
    Forwarding from [::1]:8080 -> 80
    
  2. Завантажте сторінку http://localhost:8080 у вашому оглядачі, щоб переглянути вашу гостьову книгу.

Перегляд Service Фронтенду через LoadBalancer

Якщо ви розгорнули маніфест frontend-service.yaml з типом LoadBalancer, вам потрібно знайти IP-адресу, щоб переглянути вашу гостьову книгу.

  1. Виконайте наступну команду, щоб отримати IP-адресу для Service фронтенду.

    kubectl get service frontend
    

    Відповідь повинна бути схожою на цю:

    NAME       TYPE           CLUSTER-IP      EXTERNAL-IP        PORT(S)        AGE
    frontend   LoadBalancer   10.51.242.136   109.197.92.229     80:32372/TCP   1m
    
  2. Скопіюйте зовнішню IP-адресу та завантажте сторінку у вашому оглядачі, щоб переглянути вашу гостьову книгу.

Масштабування Веб-Фронтенду

Ви можете збільшувати або зменшувати кількість реплік за потребою, оскільки ваші сервери визначені як Service, що використовує контролер Deployment.

  1. Виконайте наступну команду, щоб збільшити кількість Podʼів фронтенду:

    kubectl scale deployment frontend --replicas=5
    
  2. Виконайте запит для отримання списку Podʼів, щоб перевірити кількість запущених Podʼів фронтенду:

    kubectl get pods
    

    Відповідь повинна виглядати приблизно так:

    NAME                             READY   STATUS    RESTARTS   AGE
    frontend-85595f5bf9-5df5m        1/1     Running   0          83s
    frontend-85595f5bf9-7zmg5        1/1     Running   0          83s
    frontend-85595f5bf9-cpskg        1/1     Running   0          15m
    frontend-85595f5bf9-l2l54        1/1     Running   0          14m
    frontend-85595f5bf9-l9c8z        1/1     Running   0          14m
    redis-follower-dddfbdcc9-82sfr   1/1     Running   0          97m
    redis-follower-dddfbdcc9-qrt5k   1/1     Running   0          97m
    redis-leader-fb76b4755-xjr2n     1/1     Running   0          108m
    
  3. Виконайте наступну команду, щоб зменшити кількість Pods фронтенду:

    kubectl scale deployment frontend --replicas=2
    
  4. Виконайте запит для отримання списку Podʼів, щоб перевірити кількість запущених Podʼів фронтенду:

    kubectl get pods
    

    Відповідь повинна виглядати приблизно так:

    NAME                             READY   STATUS    RESTARTS   AGE
    frontend-85595f5bf9-cpskg        1/1     Running   0          16m
    frontend-85595f5bf9-l9c8z        1/1     Running   0          15m
    redis-follower-dddfbdcc9-82sfr   1/1     Running   0          98m
    redis-follower-dddfbdcc9-qrt5k   1/1     Running   0          98m
    redis-leader-fb76b4755-xjr2n     1/1     Running   0          109m
    

Очищення

Видалення Deployment та Serviceʼів також видаляє всі запущені Podʼи. Використовуйте мітки для видалення кількох ресурсів однією командою.

  1. Виконайте наступні команди, щоб видалити всі Pods, Deployment і Serviceʼи.

    kubectl delete deployment -l app=redis
    kubectl delete service -l app=redis
    kubectl delete deployment frontend
    kubectl delete service frontend
    

    Відповідь повинна виглядати приблизно так:

    deployment.apps "redis-follower" deleted
    deployment.apps "redis-leader" deleted
    deployment.apps "frontend" deleted
    service "frontend" deleted
    
  2. Виконайте запит списку Podʼів, щоб переконатися, що жоден Pod не працює:

    kubectl get pods
    

    Відповідь повинна виглядати приблизно так:

    No resources found in default namespace.
    

Що далі

5.6 - Stateful застосунки

5.6.1 - Основи StatefulSet

Цей підручник надає вступ до управління застосунками за допомогою StatefulSets. Він демонструє, як створювати, видаляти, масштабувати та оновлювати Podʼи StatefulSets.

Перш ніж ви розпочнете

Перш ніж розпочати цей підручник, вам слід ознайомитися з наступними концепціями Kubernetes:

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Вам слід налаштувати kubectl для використання контексту, який використовує простір імен default. Якщо ви використовуєте наявний кластер, переконайтеся, що можна використовувати простір імен цього кластера для практики. Ідеальною буде практика в кластері, де не запущені реальні робочі навантаження.

Також корисно прочитати сторінку з концепціями про StatefulSets.

Цілі

StatefulSets призначені для використання з застосунками, які зберігаються свій стан, та розподіленими системами. Однак, адміністрування стану застосунків та розподілених систем у Kubernetes є широкою та складною темою. Щоб продемонструвати базові можливості StatefulSet і не змішувати першу тему з другою, ви розгорнете простий вебзастосунок за допомогою StatefulSet.

Після цього уроку ви будете знайомі з наступним.

  • Як створити StatefulSet
  • Як StatefulSet керує своїми Podʼами
  • Як видалити StatefulSet
  • Як масштабувати StatefulSet
  • Як оновлювати Podʼи StatefulSet

Створення StatefulSet

Почніть зі створення StatefulSet (і Service, на який він спирається) за допомогою наведеного нижче прикладу. Він схожий на приклад, наведений у концепції StatefulSets. Він створює headless Service, nginx, щоб опублікувати IP-адреси Podʼів у StatefulSet, web.

apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  serviceName: "nginx"
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: registry.k8s.io/nginx-slim:0.21
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 1Gi

Вам знадобляться принаймні два термінали. У першому терміналі використовуйте kubectl get для спостереження (watch) за створенням Podʼів StatefulSet.

# використовуйте цей термінал для виконання команд із зазначенням --watch
# завершіть цей watch, коли вам буде запропоновано розпочати новий watch
kubectl get pods --watch -l app=nginx

У другому терміналі використовуйте kubectl apply для створення headless Service та StatefulSet:

kubectl apply -f https://k8s.io/examples/application/web/web.yaml
service/nginx created
statefulset.apps/web created

Наведена вище команда створює два Podʼи, кожен з яких запускає вебсервер NGINX. Отримайте інформацію про nginx Service…

kubectl get service nginx
NAME      TYPE         CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
nginx     ClusterIP    None         <none>        80/TCP    12s

…потім отримайте інформацію про web StatefulSet, щоб переконатися, що обидва були створені успішно:

kubectl get statefulset web
NAME   READY   AGE
web    2/2     37s

Упорядковане створення Podʼів

Типово StatefulSet створює свої Podʼи в строгому порядку.

Для StatefulSet з n репліками, коли Podʼи розгортаються, вони створюються послідовно, впорядковані від {0..n-1}. Перегляньте вивід команди kubectl get у першому терміналі. Зрештою вивід буде виглядати як у наведеному нижче прикладі.

# Не починайте новий watch;
# це вже повинно працювати
kubectl get pods --watch -l app=nginx
NAME      READY     STATUS    RESTARTS   AGE
web-0     0/1       Pending   0          0s
web-0     0/1       Pending   0         0s
web-0     0/1       ContainerCreating   0         0s
web-0     1/1       Running   0         19s
web-1     0/1       Pending   0         0s
web-1     0/1       Pending   0         0s
web-1     0/1       ContainerCreating   0         0s
web-1     1/1       Running   0         18s

Зверніть увагу, що Pod web-1 не запускається, поки Pod web-0 не буде Running (див. Фази Pod) та Ready (див. type у Стани Pod).

Пізніше в цьому підручнику ви будете практикувати паралельний запуск.

Podʼи в StatefulSet

Podʼи в StatefulSet мають унікальний порядковий індекс та стабільну мережеву ідентичність.

Перевірка порядкового індексу Podʼів

Отримайте Podʼи StatefulSet:

kubectl get pods -l app=nginx
NAME      READY     STATUS    RESTARTS   AGE
web-0     1/1       Running   0          1m
web-1     1/1       Running   0          1m

Як зазначено в концепції StatefulSets, Podʼи в StatefulSet мають фіксовану, унікальну ідентичність. Ця ідентичність базується на унікальному порядковому індексі, який призначається кожному Podʼу контролером StatefulSet controller. Імена Podʼів приймають форму <імʼя statefulset>-<порядковий індекс>. Оскільки StatefulSet web має дві репліки, він створює два Podʼи, web-0 та web-1.

Використання стабільних мережевих ідентичностей

Кожен Pod має стабільне імʼя хосту на основі свого порядкового індексу. Використовуйте kubectl exec для виконання команди hostname в кожному Podʼі:

for i in 0 1; do kubectl exec "web-$i" -- sh -c 'hostname'; done
web-0
web-1

Використайте kubectl run для запуску контейнера, який надає команду nslookup з пакунка dnsutils. Використовуючи nslookup з іменами хостів Podʼів, ви можете переглянути їх внутрішні адреси DNS:

kubectl run -i --tty --image busybox:1.28 dns-test --restart=Never --rm

що запускає нову оболонку. У цій новій оболонці запустіть:

# Виконайте це в оболонці контейнера dns-test
nslookup web-0.nginx

Вивід схожий на:

Server:    10.0.0.10
Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local

Name:      web-0.nginx
Address 1: 10.244.1.6

nslookup web-1.nginx
Server:    10.0.0.10
Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local

Name:      web-1.nginx
Address 1: 10.244.2.6

(і тепер вийдіть з оболонки контейнера: exit)

CNAME headless сервісу вказує на SRV записи (один для кожного Podʼа, який виконується та готовий). SRV записи вказують на записи A, які містять IP-адреси Podʼів.

У одному терміналі спостерігайте за Podʼами StatefulSet:

# Розпочніть новий watch
# Завершіть цей watch, коли бачите, що видалення завершено
kubectl get pod --watch -l app=nginx

У другому терміналі використовуйте kubectl delete для видалення всіх Podʼів у StatefulSet:

kubectl delete pod -l app=nginx
Pod "web-0" видалено
Pod "web-1" видалено

Чекайте, поки StatefulSet перезапустить їх, і обидва Podʼи перейдуть до стану Running та Ready:

# Це вже має працювати
kubectl get pod --watch -l app=nginx
NAME      READY     STATUS              RESTARTS   AGE
web-0     0/1       ContainerCreating   0          0s
NAME      READY     STATUS    RESTARTS   AGE
web-0     1/1       Running   0          2s
web-1     0/1       Pending   0         0s
web-1     0/1       Pending   0         0s
web-1     0/1       ContainerCreating   0         0s
web-1     1/1       Running   0         34s

Використовуйте kubectl exec та kubectl run, щоб переглянути імена хостів Podʼів та внутрішні DNS-записи. Спочатку перегляньте імена хостів Podʼів:

for i in 0 1; do kubectl exec web-$i -- sh -c 'hostname'; done
web-0
web-1

потім, запустіть:

kubectl run -i --tty --image busybox:1.28 dns-test --restart=Never --rm

що запускає новиe оболонку. У цій новій оболонці запустіть:

# Виконайте це в оболонці контейнера dns-test
nslookup web-0.nginx

Вивід схожий на:

Server:    10.0.0.10
Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local

Name:      web-0.nginx
Address 1: 10.244.1.7

nslookup web-1.nginx
Server:    10.0.0.10
Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local

Name:      web-1.nginx
Address 1: 10.244.2.8

(і тепер вийдіть з оболонки контейнера: exit)

Порядкові номери, імена хостів Podʼів, SRV записи та імена записів A не змінилися, але IP-адреси, повʼязані з Podʼами, можуть змінюватися. У кластері, який використовується для цього навчального посібника, вони змінюються. Тому важливо не налаштовувати інші застосунки на підʼєднання до Podʼів у StatefulSet за IP-адресою конкретного Podʼа (можна підключатися до Podʼів, за їх іменем хосту).

Виявлення конкретних Podʼів у StatefulSet

Якщо вам потрібно знайти та підʼєднатись до активних учасників StatefulSet, вам слід запитувати CNAME headless Service (nginx.default.svc.cluster.local). SRV записи, повʼязані з CNAME, будуть містити лише Podʼ у StatefulSet, які виконуються та готові.

Якщо ваш застосунок вже реалізував логіку підʼєднання, яка перевіряє працездатність та готовність, ви можете використовувати SRV записи Podʼів (web-0.nginx.default.svc.cluster.local, web-1.nginx.default.svc.cluster.local), оскільки вони стабільні, і ваш застосунок зможе виявляти адреси Podʼів, коли вони переходять до стану Running та Ready.

Якщо ваш застосунок хоче знайти будь-який здоровий Pod у StatefulSet і, отже, не потрібно відстежувати кожний конкретний Pod, ви також можете підʼєднатись до IP-адреси type: ClusterIP сервісу, Podʼів в цьому StatefulSet. Ви можете використовувати той самий Service, який відстежує StatefulSet (вказаний у serviceName StatefulSet) або окремий Service, який вибирає відповідний набір Podʼів.

Запис у стійке сховище

Отримайте PersistentVolumeClaims для web-0 та web-1:

kubectl get pvc -l app=nginx

Вивід схожий на:

NAME        STATUS    VOLUME                                     CAPACITY   ACCESSMODES   AGE
www-web-0   Bound     pvc-15c268c7-b507-11e6-932f-42010a800002   1Gi        RWO           48s
www-web-1   Bound     pvc-15c79307-b507-11e6-932f-42010a800002   1Gi        RWO           48s

Контролер StatefulSet створив два PersistentVolumeClaims, які привʼязані до двох PersistentVolumes.

Оскільки кластер, використаний у цьому посібнику, налаштований на динамічну підготовку PersistentVolumes, PersistentVolumes були створені та привʼязані автоматично.

NGINX вебсервер типово обслуговує індексний файл із /usr/share/nginx/html/index.html. Поле volumeMounts в spec StatefulSet забезпечує, що тека /usr/share/nginx/html є зберігається у PersistentVolume.

Запишіть імена хостів Podʼів у їх файли index.html та перевірте, що вебсервери NGINX обслуговують імена хостів:

for i in 0 1; do kubectl exec "web-$i" -- sh -c 'echo "$(hostname)" > /usr/share/nginx/html/index.html'; done

for i in 0 1; do kubectl exec -i -t "web-$i" -- curl http://localhost/; done
web-0
web-1

У одному терміналі спостерігайте за Podʼами StatefulSet:

# Завершіть цей watch, коли ви дійдете до кінця розділу.
# На початку "Scaling a StatefulSet" ви розпочнете новий watch.
kubectl get pod --watch -l app=nginx

У другому терміналі видаліть всі Podʼи StatefulSet:

kubectl delete pod -l app=nginx
pod "web-0" deleted
pod "web-1" deleted

Дослідіть вивід команди kubectl get у першому терміналі та зачекайте, поки всі Podʼи перейдуть до стану Running та Ready.

# Це вже має працювати
kubectl get pod --watch -l app=nginx
NAME      READY     STATUS              RESTARTS   AGE
web-0     0/1       ContainerCreating   0          0s
NAME      READY     STATUS    RESTARTS   AGE
web-0     1/1       Running   0          2s
web-1     0/1       Pending   0         0s
web-1     0/1       Pending   0         0s
web-1     0/1       ContainerCreating   0         0s
web-1     1/1       Running   0         34s

Перевірте, чи продовжують вебсервери обслуговувати свої імена хостів:

for i in 0 1; do kubectl exec -i -t "web-$i" -- curl http://localhost/; done
web-0
web-1

Навіть якщо web-0 та web-1 переплановані, вони продовжують обслуговувати свої імена хостів, оскільки PersistentVolumes, повʼязані з їхніми PersistentVolumeClaims, знову монтується до їхніх volumeMounts. Незалежно від того, на якому вузлі заплановані web-0 та web-1, їхні PersistentVolumes будуть підключені до відповідних точок монтування.

Масштабування StatefulSet

Масштабування StatefulSet передбачає збільшення або зменшення кількості реплік (горизонтальне масштабування). Це досягається шляхом оновлення поля replicas. Ви можете використовувати або kubectl scale, або kubectl patch, щоб масштабувати StatefulSet.

Збільшення масштабу

Збільшення масштабу означає додавання додаткових реплік. Забезпечивши те, що ваш застосунок може розподіляти роботу між StatefulSet, новий більший набір Podʼів може виконувати більше цієї роботи.

У одному вікні термінала спостерігайте за Podʼами у StatefulSet:

# Якщо у вас вже запущений watch, ви можете продовжити його використовувати.
# В іншому випадку запустіть один.
# Закінчіть цей watch, коли для StatefulSet буде 5 справних Podʼів
kubectl get pods --watch -l app=nginx

У іншому вікні термінала використовуйте kubectl scale, щоб змінити кількість реплік на 5:

kubectl scale sts web --replicas=5
statefulset.apps/web scaled

Дослідіть вивід команди kubectl get у першому терміналі та зачекайте, доки три додаткові Podʼи перейдуть у стан Running та Ready.

# Це вже має працювати
kubectl get pod --watch -l app=nginx
NAME      READY     STATUS    RESTARTS   AGE
web-0     1/1       Running   0          2h
web-1     1/1       Running   0          2h
NAME      READY     STATUS    RESTARTS   AGE
web-2     0/1       Pending   0          0s
web-2     0/1       Pending   0         0s
web-2     0/1       ContainerCreating   0         0s
web-2     1/1       Running   0         19s
web-3     0/1       Pending   0         0s
web-3     0/1       Pending   0         0s
web-3     0/1       ContainerCreating   0         0s
web-3     1/1       Running   0         18s
web-4     0/1       Pending   0         0s
web-4     0/1       Pending   0         0s
web-4     0/1       ContainerCreating   0         0s
web-4     1/1       Running   0         19s

Контролер StatefulSet змінив кількість реплік. Як і при створенні StatefulSet, контролер StatefulSet створював кожен Pod послідовно з урахуванням його порядкового індексу, і чекав, доки попередній Pod перейде у стан Running та Ready перед запуском наступного Podʼа.

Зменшення масштабу

Зменшення масштабу означає зменшення кількості реплік. Наприклад, ви можете це зробити через те, що рівень трафіку до служби зменшився, і на поточному масштабі є ресурси, що простоюють.

У одному вікні термінала спостерігайте за Podʼами у StatefulSet:

# Закінчіть цей watch, коли лишиться лише 3 Podʼи для StatefulSet
kubectl get pod --watch -l app=nginx

У іншому вікні термінала використовуйте kubectl patch, щоб зменшити кількість реплік StatefulSet до трьох:

kubectl patch sts web -p '{"spec":{"replicas":3}}'
statefulset.apps/web patched

Зачекайте, доки web-4 і web-3 перейдуть у стан Terminating.

# Це вже має працювати
kubectl get pods --watch -l app=nginx
NAME      READY     STATUS              RESTARTS   AGE
web-0     1/1       Running             0          3h
web-1     1/1       Running             0          3h
web-2     1/1       Running             0          55s
web-3     1/1       Running             0          36s
web-4     0/1       ContainerCreating   0          18s
NAME      READY     STATUS    RESTARTS   AGE
web-4     1/1       Running   0          19s
web-4     1/1       Terminating   0         24s
web-4     1/1       Terminating   0         24s
web-3     1/1       Terminating   0         42s
web-3     1/1       Terminating   0         42s

Послідовне завершення Podʼів

Панель управління видаляє кожний Pod по одному, у зворотньому порядку щодо його порядкового індексу, і чекає, доки кожен Pod повністю не зупиниться перед видаленням наступного.

Отримайте PersistentVolumeClaims StatefulSet:

kubectl get pvc -l app=nginx
NAME        STATUS    VOLUME                                     CAPACITY   ACCESSMODES   AGE
www-web-0   Bound     pvc-15c268c7-b507-11e6-932f-42010a800002   1Gi        RWO           13h
www-web-1   Bound     pvc-15c79307-b507-11e6-932f-42010a800002   1Gi        RWO           13h
www-web-2   Bound     pvc-e1125b27-b508-11e6-932f-42010a800002   1Gi        RWO           13h
www-web-3   Bound     pvc-e1176df6-b508-11e6-932f-42010a800002   1Gi        RWO           13h
www-web-4   Bound     pvc-e11bb5f8-b508-11e6-932f-42010a800002   1Gi        RWO           13h

Ще існують пʼять PersistentVolumeClaims та пʼять PersistentVolumes. Під час дослідження стабільного сховища Podʼа, ви бачили, що PersistentVolumes, змонтовані у Podʼи StatefulSet, не видаляються, коли Podʼи StatefulSet видаляються. Це також вірно, коли видалення Podʼів викликано зменшенням масштабу StatefulSet.

Оновлення StatefulSets

Контролер StatefulSet підтримує автоматизоване оновлення. Стратегія, яка використовується, визначається полем spec.updateStrategy обʼєкта API StatefulSet. Ця функція може бути використана для оновлення образів контейнерів, запитів ресурсів та/або лімітів, міток та анотацій Podʼів у StatefulSet.

Існують дві стратегії оновлення: RollingUpdate (типово) та OnDelete.

RollingUpdate

Стратегія оновлення RollingUpdate оновлює всі Podʼи в StatefulSet у зворотньому порядку щодо їх порядкового індексу, з дотриманням гарантій StatefulSet.

Ви можете розділити оновлення StatefulSet, який використовує стратегію RollingUpdate, на партиції, вказавши .spec.updateStrategy.rollingUpdate.partition. Ви будете практикувати це пізніше у цьому посібнику.

Спочатку спробуйте просте поетапне оновлення.

В одному вікні термінала відредагуйте StatefulSet web, щоб знову змінити образ контейнера:

kubectl patch statefulset web --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"registry.k8s.io/nginx-slim:0.24"}]'
statefulset.apps/web patched

В іншому терміналі спостерігайте за Podʼами у StatefulSet:

# Закінчіть це спостереження, коли відбудеться розгортання
#
# Якщо ви не впевнені, залиште його ще на одну хвилину
kubectl get pod -l app=nginx --watch

Вивід буде подібний до:

NAME      READY     STATUS    RESTARTS   AGE
web-0     1/1       Running   0          7m
web-1     1/1       Running   0          7m
web-2     1/1       Running   0          8m
web-2     1/1       Terminating   0         8m
web-2     1/1       Terminating   0         8m
web-2     0/1       Terminating   0         8m
web-2     0/1       Terminating   0         8m
web-2     0/1       Terminating   0         8m
web-2     0/1       Terminating   0         8m
web-2     0/1       Pending   0         0s
web-2     0/1       Pending   0         0s
web-2     0/1       ContainerCreating   0         0s
web-2     1/1       Running   0         19s
web-1     1/1       Terminating   0         8m
web-1     0/1       Terminating   0         8m
web-1     0/1       Terminating   0         8m
web-1     0/1       Terminating   0         8m
web-1     0/1       Pending   0         0s
web-1     0/1       Pending   0         0s
web-1     0/1       ContainerCreating   0         0s
web-1     1/1       Running   0         6s
web-0     1/1       Terminating   0         7m
web-0     1/1       Terminating   0         7m
web-0     0/1       Terminating   0         7m
web-0     0/1       Terminating   0         7m
web-0     0/1       Terminating   0         7m
web-0     0/1       Terminating   0         7m
web-0     0/1       Pending   0         0s
web-0     0/1       Pending   0         0s
web-0     0/1       ContainerCreating   0         0s
web-0     1/1       Running   0         10s

Podʼи в StatefulSet оновлюються у зворотньому порядку щодо їх порядкового індексу. Контролер StatefulSet завершує кожен Pod і чекає, доки він не перейде в стан Running та Ready, перед тим як оновити наступний Pod. Зверніть увагу, що, навіть якщо контролер StatefulSet не продовжить оновлювати наступний Pod, поки його порядковий наступник не буде Running та Ready, він відновить будь-який Pod, який зазнав помилки під час оновлення до попередньої версії.

Podʼи, які вже отримали оновлення, будуть відновлені до оновленої версії, а Podʼи, які ще не отримали оновлення, будуть відновлені до попередньої версії. Таким чином, контролер намагається продовжувати забезпечувати працездатність застосунку та зберігати оновлення в однорідному стані при наявності тимчасових збоїв.

Отримайте Podʼи, щоб переглянути їх образи контейнерів:

for p in 0 1 2; do kubectl get pod "web-$p" --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'; echo; done
registry.k8s.io/nginx-slim:0.24
registry.k8s.io/nginx-slim:0.24
registry.k8s.io/nginx-slim:0.24

Всі Podʼи в StatefulSet зараз використовують попередній образ контейнера.

Підготовка оновлення

Ви можете розбити оновлення StatefulSet, який використовує стратегію RollingUpdate, на розділи, вказавши .spec.updateStrategy.rollingUpdate.partition.

Для отримання додаткового контексту ви можете прочитати Поточні оновлення частинами на сторінці концепції StatefulSet.

Ви можете підготувати оновлення StatefulSet, використовуючи поле partition всередині .spec.updateStrategy.rollingUpdate. Для цього оновлення ви залишите наявні Podʼи в StatefulSet без змін, поки змінюєте шаблон Podʼа для StatefulSet. Потім ви (або, це поза цим навчальним посібником, якась зовнішня автоматизація) можете запустити це підготовлене оновлення.

Спочатку виправте StatefulSet web, щоб додати розділ до поля updateStrategy:

# Значення "partition" визначає, до яких порядкових номерів застосовується зміна
# Переконайтеся, що використовуєте число, більше, ніж останній порядковий номер для
# StatefulSet
kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate","rollingUpdate":{"partition":3}}}}'
statefulset.apps/web patched

Знову виправте StatefulSet, щоб змінити образ контейнера, який використовує цей StatefulSet:

kubectl patch statefulset web --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"registry.k8s.io/nginx-slim:0.21"}]'
statefulset.apps/web patched

Видаліть Pod у StatefulSet:

kubectl delete pod web-2
pod "web-2" deleted

Зачекайте, поки замінений Pod web-2 буде запущений і готовий:

# Закінчіть перегляд, коли побачите, що web-2 справний
kubectl get pod -l app=nginx --watch
NAME      READY     STATUS              RESTARTS   AGE
web-0     1/1       Running             0          4m
web-1     1/1       Running             0          4m
web-2     0/1       ContainerCreating   0          11s
web-2     1/1       Running   0         18s

Отримайте образ контейнера Podʼа:

kubectl get pod web-2 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'
registry.k8s.io/nginx-slim:0.24

Зверніть увагу, що, навіть якщо стратегія оновлення — RollingUpdate, StatefulSet відновив Pod з початковим образом контейнера. Це тому, що порядковий номер Podʼа менше, ніж partition, вказаний у updateStrategy.

Канаркове оновлення

Тепер ви спробуєте канаркове оновлення цієї підготовленої зміни.

Ви можете виконати канаркове оновлення (для тестування зміненого шаблону) шляхом зменшення partition, який ви вказали вище.

Виправте StatefulSet, щоб зменшити розділ:

# Значення "partition" повинно відповідати найвищому існуючому порядковому номеру для
# StatefulSet
kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate","rollingUpdate":{"partition":2}}}}'
statefulset.apps/web patched

Панель управління спровокує заміну для web-2 (реалізовану через належне видалення, а потім створення нового Podʼа, як тільки видалення завершиться). Зачекайте, поки новий Pod web-2 буде запущений і готовий.

# Це вже має бути запущено
kubectl get pod -l app=nginx --watch
NAME      READY     STATUS              RESTARTS   AGE
web-0     1/1       Running             0          4m
web-1     1/1       Running             0          4m
web-2     0/1       ContainerCreating   0          11s
web-2     1/1       Running   0         18s

Отримайте інформацію про контейнер Podʼа:

kubectl get pod web-2 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'
registry.k8s.io/nginx-slim:0.21

Коли ви змінили partition, контролер StatefulSet автоматично оновив Pod web-2, оскільки порядковий номер Podʼа був більшим або рівним partition.

Видаліть Pod web-1:

kubectl delete pod web-1
pod "web-1" deleted

Зачекайте, поки Pod web-1 буде запущений і готовий.

# Це вже має бути запущено
kubectl get pod -l app=nginx --watch

Вивід подібний до:

NAME      READY     STATUS        RESTARTS   AGE
web-0     1/1       Running       0          6m
web-1     0/1       Terminating   0          6m
web-2     1/1       Running       0          2m
web-1     0/1       Terminating   0         6m
web-1     0/1       Terminating   0         6m
web-1     0/1       Terminating   0         6m
web-1     0/1       Pending   0         0s
web-1     0/1       Pending   0         0s
web-1     0/1       ContainerCreating   0         0s
web-1     1/1       Running   0         18s

Отримайте образ контейнера Podʼа web-1:

kubectl get pod web-1 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'
registry.k8s.io/nginx-slim:0.24

web-1 був відновлений до своєї початкової конфігурації, тому що порядковий номер Podʼа був меншим за partition. Коли вказано partition, всі Podʼи з порядковим номером, який більше або дорівнює partition, будуть оновлені, коли буде оновлено .spec.template StatefulSet. Якщо Pod з порядковим номером, який менший за partition, буде видалений або інакше припинений, він буде відновлено до початкової конфігурації.

Поступові оновлення

Ви можете виконати поступове оновлення (наприклад, лінійне, геометричне або експоненціальне оновлення) за допомогою розділеного оновлення з аналогічним методом до того, як ви впровадили канаркове оновлення. Щоб виконати поступове оновлення, встановіть partition на порядковий номер, на якому ви хочете, щоб контролер призупинив оновлення.

Розділ в цей момент встановлено на 2. Встановіть розділ на 0:

kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate","rollingUpdate":{"partition":0}}}}'
statefulset.apps/web patched

Зачекайте, поки всі Podʼи в StatefulSet стануть запущеними і готовими.

# Це вже має бути запущено
kubectl get pod -l app=nginx --watch

Вивід подібний до:

NAME      READY     STATUS              RESTARTS   AGE
web-0     1/1       Running             0          3m
web-1     0/1       ContainerCreating   0          11s
web-2     1/1       Running             0          2m
web-1     1/1       Running   0         18s
web-0     1/1       Terminating   0         3m
web-0     1/1       Terminating   0         3m
web-0     0/1       Terminating   0         3m
web-0     0/1       Terminating   0         3m
web-0     0/1       Terminating   0         3m
web-0     0/1       Terminating   0         3m
web-0     0/1       Pending   0         0s
web-0     0/1       Pending   0         0s
web-0     0/1       ContainerCreating   0         0s
web-0     1/1       Running   0         3s

Отримайте деталі образу контейнера для Podʼів у StatefulSet:

for p in 0 1 2; do kubectl get pod "web-$p" --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'; echo; done
registry.k8s.io/nginx-slim:0.21
registry.k8s.io/nginx-slim:0.21
registry.k8s.io/nginx-slim:0.21

Переміщуючи partition на 0, ви дозволили StatefulSet продовжити процес оновлення.

OnDelete

Ви обираєте цю стратегію оновлення для StatefulSet, встановивши .spec.template.updateStrategy.type на OnDelete.

Виправте StatefulSet web, щоб використовувати стратегію оновлення OnDelete:

kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"OnDelete"}}}'
statefulset.apps/web patched

Коли ви обираєте цю стратегію оновлення, контролер StatefulSet не автоматично оновлює Podʼи, коли вноситься зміна до поля .spec.template StatefulSet. Вам потрібно керувати оновленням самостійно — або вручну, або за допомогою окремої автоматизації.

Видалення StatefulSet

StatefulSet підтримує як не каскадне, так і каскадне видалення. При не каскадному видаленні Podʼи StatefulSet не видаляються при видаленні самого StatefulSet. При каскадному видаленні видаляються як StatefulSet, так і його Podʼи.

Прочитайте Використання каскадного видалення у кластері, щоб дізнатися про каскадне видалення загалом.

Некаскадне видалення

В одному вікні термінала спостерігайте за Podʼами у StatefulSet.

# Завершіть цей перегляд, коли не буде Podʼів для StatefulSet
kubectl get pods --watch -l app=nginx

Використовуйте kubectl delete, щоб видалити StatefulSet. Переконайтеся, що ви передали параметр --cascade=orphan до команди. Цей параметр повідомляє Kubernetes видаляти лише StatefulSet, і не видаляти жодного з його Podʼів.

kubectl delete statefulset web --cascade=orphan
statefulset.apps "web" deleted

Отримайте Podʼи, щоб перевірити їх статус:

kubectl get pods -l app=nginx
NAME      READY     STATUS    RESTARTS   AGE
web-0     1/1       Running   0          6m
web-1     1/1       Running   0          7m
web-2     1/1       Running   0          5m

Навіть якщо web був видалений, всі Podʼи все ще запущені і готові. Видаліть web-0:

kubectl delete pod web-0
pod "web-0" deleted

Отримайте Podʼи StatefulSet:

kubectl get pods -l app=nginx
NAME      READY     STATUS    RESTARTS   AGE
web-1     1/1       Running   0          10m
web-2     1/1       Running   0          7m

Оскільки StatefulSet web було видалено, web-0 не було перезапущено.

В одному терміналі спостерігайте за Podʼами StatefulSet.

# Залиште цей перегляд запущеним до наступного разу, коли ви почнете перегляд
kubectl get pods --watch -l app=nginx

У другому терміналі створіть знову StatefulSet. Зверніть увагу, якщо ви не видалили nginx Service (що ви не повинні були робити), ви побачите помилку, яка вказує, що Service вже існує.

kubectl apply -f https://k8s.io/examples/application/web/web.yaml
statefulset.apps/web created
service/nginx unchanged

Ігноруйте помилку. Вона лише вказує на те, що була спроба створити headless Service nginx, незважаючи на те, що цей Service вже існує.

Дослідіть вихідні дані команди kubectl get, яка працює у першому терміналі.

# Це вже має бути запущено
kubectl get pods --watch -l app=nginx
NAME      READY     STATUS    RESTARTS   AGE
web-1     1/1       Running   0          16m
web-2     1/1       Running   0          2m
NAME      READY     STATUS    RESTARTS   AGE
web-0     0/1       Pending   0          0s
web-0     0/1       Pending   0         0s
web-0     0/1       ContainerCreating   0         0s
web-0     1/1       Running   0         18s
web-2     1/1       Terminating   0         3m
web-2     0/1       Terminating   0         3m
web-2     0/1       Terminating   0         3m
web-2     0/1       Terminating   0         3m

Коли StatefulSet web був відновлений, він спочатку перезапустив web-0. Оскільки web-1 вже був запущений і готовий, коли web-0 перейшов до стану Running і Ready, він став резервним для цього Podʼа. Оскільки ви відновили StatefulSet з replicas рівним 2, як тільки web-0 був відновлений, і як тільки web-1 вже був визначений як Running і Ready, web-2 був закінчений.

Тепер ще раз розгляньте вміст файлу index.html, який обслуговують вебсервери Podʼів:

for i in 0 1; do kubectl exec -i -t "web-$i" -- curl http://localhost/; done
web-0
web-1

Навіть якщо ви видалили як StatefulSet, так і Pod web-0, він все ще обслуговує імʼя хоста, яке спочатку було введено в його файл index.html. Це тому, що StatefulSet ніколи не видаляє PersistentVolumes, повʼязані з Podʼом. Коли ви відновили StatefulSet і перезапустили web-0, його оригінальний PersistentVolume знову змонтувався.

Каскадне видалення

В одному вікні термінала спостерігайте за Podʼами у StatefulSet.

# Залиште це запущеним до наступного розділу сторінки
kubectl get pods --watch -l app=nginx

В іншому терміналі знову видаліть StatefulSet. Цього разу не використовуйте параметр --cascade=orphan.

kubectl delete statefulset web
statefulset.apps "web" deleted

Дослідіть вихідні дані команди kubectl get, яка працює у першому терміналі, і зачекайте, поки всі Podʼи перейдуть у стан Terminating.

# Це вже має бути запущено
kubectl get pods --watch -l app=nginx
NAME      READY     STATUS    RESTARTS   AGE
web-0     1/1       Running   0          11m
web-1     1/1       Running   0          27m
NAME      READY     STATUS        RESTARTS   AGE
web-0     1/1       Terminating   0          12m
web-1     1/1       Terminating   0         29m
web-0     0/1       Terminating   0         12m
web-0     0/1       Terminating   0         12m
web-0     0/1       Terminating   0         12m
web-1     0/1       Terminating   0         29m
web-1     0/1       Terminating   0         29m
web-1     0/1       Terminating   0         29m

Як ви бачили в розділі Зменшення мастабу, Podʼи видаляються по одному, з урахуванням зворотного порядку їх порядкових індексів. Перед видаленням Podʼа контролер StatefulSet чекає, поки Pod-наступник буде повністю видалено.

kubectl delete service nginx
service "nginx" deleted

Знову створіть StatefulSet і headless Service:

kubectl apply -f https://k8s.io/examples/application/web/web.yaml
service/nginx created
statefulset.apps/web created

Коли всі Podʼи StatefulSet перейдуть у стан Running і Ready, отримайте вміст їх файлів index.html:

for i in 0 1; do kubectl exec -i -t "web-$i" -- curl http://localhost/; done
web-0
web-1

Навіть якщо ви повністю видалили StatefulSet і всі його Podʼи, Podʼи перестворюються з монтуванням їх PersistentVolumes, і web-0 й web-1 продовжують обслуговувати свої імена хостів.

Нарешті, видаліть Service nginx

kubectl delete service nginx
service "nginx" deleted

…і StatefulSet web:

kubectl delete statefulset web
statefulset "web" deleted

Політика управління Podʼами

Для деяких розподілених систем порядок, гарантований StatefulSet, є непотрібним або небажаним. Ці системи потребують лише унікальності та ідентичності.

Ви можете вказати політику управління Podʼами, щоб уникнути цього строгого порядку; або OrderedReady (типово), або Parallel.

Політика управління Podʼами OrderedReady

Управління Podʼами OrderedReady є стандартним значенням для StatefulSet. Воно каже контролеру StatefulSet дотримуватися гарантій порядку, показаних вище.

Використовуйте цей параметр, коли ваш застосунок вимагає або очікує, що зміни, такі як запуск нової версії вашого застосунку, відбуваються у строгому порядку за порядковим номером (номером Pod), який надає StatefulSet. Іншими словами, якщо у вас є Podʼи app-0, app-1 та app-2, Kubernetes оновить app-0 першим і перевірить його. Якщо перевірка пройшла успішно, Kubernetes оновить app-1, а потім app-2.

Якщо ви додали ще два Podʼи, Kubernetes налаштує app-3 та почекає, доки він не стане справним, перед тим як розгорнути app-4.

Оскільки це стандартне налаштування, ви вже практикували його використання.

Політика управління Podʼами Parallel

Альтернатива, управління Podʼами Parallel, каже контролеру StatefulSet запускати або видаляти всі Podʼи паралельно, і не чекати, поки Podʼи не стануть Running і Ready або повністю видаленими перед запуском або видаленням іншого Podʼа.

Опція управління Podʼами Parallel впливає лише на поведінку при масштабуванні. Оновлення не піддаються впливу; Kubernetes все ще впроваджує зміни по черзі. Для цього навчального посібника застосунок дуже простий: вебсервер, який повідомляє вам його імʼя хосту (тому що це StatefulSet, імʼя хосту для кожного Podʼа є різним і передбачуваним).

apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  serviceName: "nginx"
  podManagementPolicy: "Parallel"
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: registry.k8s.io/nginx-slim:0.24
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 1Gi

Цей маніфест ідентичний тому, який ви завантажили вище, за винятком того, що .spec.podManagementPolicy StatefulSet web встановлено на Parallel.

В одному терміналі спостерігайте за Podʼами в StatefulSet.

# Залиште це запущеним до кінця розділу
kubectl get pod -l app=nginx --watch

В іншому терміналі змініть конфігурацію StatefulSet на управління Podʼами Parallel:

kubectl apply -f https://k8s.io/examples/application/web/web-parallel.yaml
service/nginx updated
statefulset.apps/web updated

Залиште відкритим термінал, де ви запустили спостереження. У іншому вікні терміналу масштабуйте StatefulSet:

kubectl scale statefulset/web --replicas=5
statefulset.apps/web scaled

Дослідіть вихідні дані терміналу, де запущена команда kubectl get. Вони можуть виглядати приблизно так

web-3     0/1       Pending   0         0s
web-3     0/1       Pending   0         0s
web-3     0/1       Pending   0         7s
web-3     0/1       ContainerCreating   0         7s
web-2     0/1       Pending   0         0s
web-4     0/1       Pending   0         0s
web-2     1/1       Running   0         8s
web-4     0/1       ContainerCreating   0         4s
web-3     1/1       Running   0         26s
web-4     1/1       Running   0         2s

StatefulSet запустив три нові Podʼи, і він не чекав, поки перший стане Running і Ready перед запуском другого і третього Podʼів.

Цей підхід є корисним, якщо ваше робоче навантаження зберігає стан або Podʼи мають можливість ідентифікувати один одного за передбачуваною назвою, особливо якщо вам іноді потрібно швидко надати більше потужності. Якщо цей простий вебсервіс для навчального посібника раптово отримав додаткові 1,000,000 запитів на хвилину, то ви хотіли б запустити додаткові Podʼи — але ви також не хотіли б чекати, поки кожен новий Pod буде запущений. Запуск додаткових Podʼів паралельно скорочує час між запитом на додаткову потужність і її доступністю для використання.

Очищення

У вас маєть бути два термінали, готові для запуску команд kubectl для проведення очищення.

kubectl delete sts web
# sts - скорочення для statefulset

Ви можете відстежувати виконання команди kubectl get, щоб переглянути видалення цих ресурсів.

# завершіть перегляд, коли побачите необхідне
kubectl get pod -l app=nginx --watch
web-3     1/1       Terminating   0         9m
web-2     1/1       Terminating   0         9m
web-3     1/1       Terminating   0         9m
web-2     1/1       Terminating   0         9m
web-1     1/1       Terminating   0         44m
web-0     1/1       Terminating   0         44m
web-0     0/1       Terminating   0         44m
web-3     0/1       Terminating   0         9m
web-2     0/1       Terminating   0         9m
web-1     0/1       Terminating   0         44m
web-0     0/1       Terminating   0         44m
web-2     0/1       Terminating   0         9m
web-2     0/1       Terminating   0         9m
web-2     0/1       Terminating   0         9m
web-1     0/1       Terminating   0         44m
web-1     0/1       Terminating   0         44m
web-1     0/1       Terminating   0         44m
web-0     0/1       Terminating   0         44m
web-0     0/1       Terminating   0         44m
web-0     0/1       Terminating   0         44m
web-3     0/1       Terminating   0         9m
web-3     0/1       Terminating   0         9m
web-3     0/1       Terminating   0         9m

Під час видалення StatefulSet видаляються всі Podʼи одночасно; не чекаючи завершення роботи наступного Podʼа у черзі.

Закрийте термінал, де виконується команда kubectl get, та видаліть Service nginx:

kubectl delete svc nginx

Видаліть носій постійного зберігання для PersistentVolumes, що використовувалися в цьому посібнику.

kubectl get pvc
NAME        STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
www-web-0   Bound    pvc-2bf00408-d366-4a12-bad0-1869c65d0bee   1Gi        RWO            standard       25m
www-web-1   Bound    pvc-ba3bfe9c-413e-4b95-a2c0-3ea8a54dbab4   1Gi        RWO            standard       24m
www-web-2   Bound    pvc-cba6cfa6-3a47-486b-a138-db5930207eaf   1Gi        RWO            standard       15m
www-web-3   Bound    pvc-0c04d7f0-787a-4977-8da3-d9d3a6d8d752   1Gi        RWO            standard       15m
www-web-4   Bound    pvc-b2c73489-e70b-4a4e-9ec1-9eab439aa43e   1Gi        RWO            standard       14m
kubectl get pv
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM               STORAGECLASS   REASON   AGE
pvc-0c04d7f0-787a-4977-8da3-d9d3a6d8d752   1Gi        RWO            Delete           Bound    default/www-web-3   standard                15m
pvc-2bf00408-d366-4a12-bad0-1869c65d0bee   1Gi        RWO            Delete           Bound    default/www-web-0   standard                25m
pvc-b2c73489-e70b-4a4e-9ec1-9eab439aa43e   1Gi        RWO            Delete           Bound    default/www-web-4   standard                14m
pvc-ba3bfe9c-413e-4b95-a2c0-3ea8a54dbab4   1Gi        RWO            Delete           Bound    default/www-web-1   standard                24m
pvc-cba6cfa6-3a47-486b-a138-db5930207eaf   1Gi        RWO            Delete           Bound    default/www-web-2   standard                15m
kubectl delete pvc www-web-0 www-web-1 www-web-2 www-web-3 www-web-4
persistentvolumeclaim "www-web-0" deleted
persistentvolumeclaim "www-web-1" deleted
persistentvolumeclaim "www-web-2" deleted
persistentvolumeclaim "www-web-3" deleted
persistentvolumeclaim "www-web-4" deleted
kubectl get pvc
No resources found in default namespace.

5.6.2 - Приклад: Розгортання WordPress та MySQL з постійними томами

У цьому посібнику ви дізнаєтеся, як розгорнути сайт WordPress та базу даних MySQL за допомогою Minikube. Обидва застосунки використовують PersistentVolumes та PersistentVolumeClaims для зберігання даних.

Постійні томи (PersistentVolume (PV)) — це частина системи зберігання в кластері, яку адміністратор вручну надав або яку Kubernetes автоматично надав за допомогою StorageClass. Запити на постійні томи (PersistentVolumeClaim (PVC)) — це запит на зберігання, який користувач може отримати через PV. PersistentVolumes та PersistentVolumeClaims незалежні від життєвого циклу Podʼів і зберігають дані під час перезапуску, перепланування та навіть видалення Podʼів.

Цілі

  • Створення PersistentVolumeClaims and PersistentVolumes
  • Створення kustomization.yaml з
    • генератором Secret
    • конфігураціями ресурсів MySQL
    • конфігураціями ресурсів WordPress
  • Застосування теки kustomization за допомогою kubectl apply -k ./
  • Очищення

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Для перевірки версії введіть kubectl version.

Наведений на цій сторінці приклад працює з kubectl версії 1.27 і вище.

Завантажте наступні конфігураційні файли:

  1. mysql-deployment.yaml

  2. wordpress-deployment.yaml

Створення запитів на постійні томи та постійних томів

Для зберігання даних MySQL та Wordpress кожному потрібен постійний том (PersistentVolume). Їх запити на постійні томи (PersistentVolumeClaim) будуть створені на етапі розгортання.

У багатьох середовищах кластера встановлено типовий StorageClass. Якщо StorageClass не вказано у запиті на постійний том (PersistentVolumeClaim), то використовується типовий StorageClass кластера.

Коли створюється запит на постійний том (PersistentVolumeClaim), постійний том (PersistentVolume) динамічно надається на основі конфігурації StorageClass.

Створення файлу kustomization.yaml

Додавання генератора Secret

Secret — це обʼєкт, який зберігає чутливі дані, такі як паролі або ключі. Починаючи з версії 1.14, kubectl підтримує керування обʼєктами Kubernetes за допомогою файлу kustomization. Ви можете створити Secret за допомогою генераторів у файлі kustomization.yaml.

Додайте генератор Secret у файл kustomization.yaml за допомогою наступної команди. Вам потрібно буде замінити YOUR_PASSWORD на пароль, який ви хочете використовувати.

cat <<EOF >./kustomization.yaml
secretGenerator:
- name: mysql-pass
  literals:
  - password=YOUR_PASSWORD
EOF

Додавання конфігурації ресурсів для MySQL та WordPress

Наступний маніфест описує Deployment одного екземпляра MySQL. Контейнер MySQL монтує PersistentVolume у /var/lib/mysql. Змінна оточення MYSQL_ROOT_PASSWORD встановлює пароль бази даних з Secret.

apiVersion: v1
kind: Service
metadata:
  name: wordpress-mysql
  labels:
    app: wordpress
spec:
  ports:
    - port: 3306
  selector:
    app: wordpress
    tier: mysql
  clusterIP: None
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-pv-claim
  labels:
    app: wordpress
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: wordpress-mysql
  labels:
    app: wordpress
spec:
  selector:
    matchLabels:
      app: wordpress
      tier: mysql
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: wordpress
        tier: mysql
    spec:
      containers:
      - image: mysql:8.0
        name: mysql
        env:
        - name: MYSQL_ROOT_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql-pass
              key: password
        - name: MYSQL_DATABASE
          value: wordpress
        - name: MYSQL_USER
          value: wordpress
        - name: MYSQL_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql-pass
              key: password
        ports:
        - containerPort: 3306
          name: mysql
        volumeMounts:
        - name: mysql-persistent-storage
          mountPath: /var/lib/mysql
      volumes:
      - name: mysql-persistent-storage
        persistentVolumeClaim:
          claimName: mysql-pv-claim

Наступний маніфест описує Deployment одного екземпляра WordPress. Контейнер WordPress монтує PersistentVolume у /var/www/html для файлів даних вебсайту. Змінна оточення WORDPRESS_DB_HOST встановлює імʼя служби MySQL, визначеної вище, і WordPress буде звертатися до бази даних через службу. Змінна оточення WORDPRESS_DB_PASSWORD встановлює пароль бази даних згенерованого kustomize Secret.

apiVersion: v1
kind: Service
metadata:
  name: wordpress
  labels:
    app: wordpress
spec:
  ports:
    - port: 80
  selector:
    app: wordpress
    tier: frontend
  type: LoadBalancer
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: wp-pv-claim
  labels:
    app: wordpress
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: wordpress
  labels:
    app: wordpress
spec:
  selector:
    matchLabels:
      app: wordpress
      tier: frontend
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: wordpress
        tier: frontend
    spec:
      containers:
      - image: wordpress:6.2.1-apache
        name: wordpress
        env:
        - name: WORDPRESS_DB_HOST
          value: wordpress-mysql
        - name: WORDPRESS_DB_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql-pass
              key: password
        - name: WORDPRESS_DB_USER
          value: wordpress
        ports:
        - containerPort: 80
          name: wordpress
        volumeMounts:
        - name: wordpress-persistent-storage
          mountPath: /var/www/html
      volumes:
      - name: wordpress-persistent-storage
        persistentVolumeClaim:
          claimName: wp-pv-claim
  1. Завантажте файл конфігурації розгортання MySQL.

    curl -LO https://k8s.io/examples/application/wordpress/mysql-deployment.yaml
    
  2. Завантажте файл конфігурації розгортання WordPress.

    curl -LO https://k8s.io/examples/application/wordpress/wordpress-deployment.yaml
    
  3. Додайте їх до файлу kustomization.yaml.

    cat <<EOF >>./kustomization.yaml
    resources:
      - mysql-deployment.yaml
      - wordpress-deployment.yaml
    EOF
    

Застосування та перевірка

Файл kustomization.yaml містить всі ресурси для розгортання сайту WordPress та бази даних MySQL. Ви можете застосувати цю теку командою

kubectl apply -k ./

Тепер перевірте, що всі обʼєкти існують.

  1. Перевірте, що Secret існує, виконавши наступну команду:

    kubectl get secrets
    

    Відповідь має бути подібною до цієї:

    NAME                    TYPE                                  DATA   AGE
    mysql-pass-c57bb4t7mf   Opaque                                1      9s
    
  2. Перевірте, що PersistentVolume був динамічно наданий.

    kubectl get pvc
    

    Відповідь має бути подібною до цієї:

    NAME             STATUS    VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS       AGE
    mysql-pv-claim   Bound     pvc-8cbd7b2e-4044-11e9-b2bb-42010a800002   20Gi       RWO            standard           77s
    wp-pv-claim      Bound     pvc-8cd0df54-4044-11e9-b2bb-42010a800002   20Gi       RWO            standard           77s
    
  3. Перевірте, що Pod працює, виконавши наступну команду:

    kubectl get pods
    

    Відповідь має бути подібною до цієї:

    NAME                               READY     STATUS    RESTARTS   AGE
    wordpress-mysql-1894417608-x5dzt   1/1       Running   0          40s
    
  4. Перевірте, що Service працює, виконавши наступну команду:

    kubectl get services wordpress
    

    Відповідь має бути подібною до цієї:

    NAME        TYPE            CLUSTER-IP   EXTERNAL-IP   PORT(S)        AGE
    wordpress   LoadBalancer    10.0.0.89    <pending>     80:32406/TCP   4m
    
  5. Виконайте наступну команду, щоб отримати IP-адресу для Service WordPress:

    minikube service wordpress --url
    

    Відповідь має бути подібною до цієї:

    http://1.2.3.4:32406
    
  6. Скопіюйте IP-адресу та завантажте сторінку у своєму оглядачі, щоб переглянути ваш сайт.

    Ви повинні побачити сторінку налаштування WordPress, схожу на знімок екрана нижче.

    wordpress-init

Очищення

  1. Виконайте наступну команду, щоб видалити ваш Secret, Deployments, Services та PersistentVolumeClaims:

    kubectl delete -k ./
    

Що далі

5.6.3 - Приклад: Розгортання Cassandra з використанням StatefulSet

Цей підручник покаже вам, як запустити Apache Cassandra у Kubernetes. Cassandra, база даних, потребує постійного сховища для забезпечення стійкості даних (стан застосунку). У цьому прикладі використовується власний постачальник насіння Cassandra, що дозволяє базі даних виявляти нові екземпляри Cassandra, коли вони приєднуються до кластера Cassandra.

StatefulSet полегшує розгортання стійких застосунків у вашому кластері Kubernetes. Для отримання додаткової інформації про використані у цьому підручнику функції дивіться StatefulSet.

Цілі

  • Створення та перевірка Cassandra headless Service.
  • Використання StatefulSet для створення кільця Cassandra.
  • Перевірка StatefulSet.
  • Зміна StatefulSet.
  • Видалення StatefulSet та його Podʼів.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Для роботи з цим посібником ви повинні вже мати базові знання про Podʼи, Сервіси, та StatefulSets.

Додаткові інструкції щодо налаштування Minikube

Створення headless Service для Cassandra

У Kubernetes Service описує набір Podʼів, які виконують одну й ту ж задачу.

Наступний Service використовується для DNS-пошуку між Podʼами Cassandra та клієнтами у вашому кластері:

apiVersion: v1
kind: Service
metadata:
  labels:
    app: cassandra
  name: cassandra
spec:
  clusterIP: None
  ports:
  - port: 9042
  selector:
    app: cassandra

Створіть Service для відстеження всіх членів StatefulSet Cassandra з файлу cassandra-service.yaml:

kubectl apply -f https://k8s.io/examples/application/cassandra/cassandra-service.yaml

Перевірка (необов’язково)

Отримайте інформацію про Cassandra Service.

kubectl get svc cassandra

Відповідь буде

NAME        TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)    AGE
cassandra   ClusterIP   None         <none>        9042/TCP   45s

Якщо ви не бачите Service з назвою cassandra, це означає, що його створення не вдалося. Прочитайте Налагодження Service, щоб отримати довідку з усунення загальних проблем.

Використання StatefulSet для створення кільця Cassandra

Маніфест StatefulSet, наведений нижче, створює кільце Cassandra, що складається з трьох Podʼів.

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: cassandra
  labels:
    app: cassandra
spec:
  serviceName: cassandra
  replicas: 3
  selector:
    matchLabels:
      app: cassandra
  template:
    metadata:
      labels:
        app: cassandra
    spec:
      terminationGracePeriodSeconds: 500
      containers:
      - name: cassandra
        image: gcr.io/google-samples/cassandra:v13
        imagePullPolicy: Always
        ports:
        - containerPort: 7000
          name: intra-node
        - containerPort: 7001
          name: tls-intra-node
        - containerPort: 7199
          name: jmx
        - containerPort: 9042
          name: cql
        resources:
          limits:
            cpu: "500m"
            memory: 1Gi
          requests:
            cpu: "500m"
            memory: 1Gi
        securityContext:
          capabilities:
            add:
              - IPC_LOCK
        lifecycle:
          preStop:
            exec:
              command: 
              - /bin/sh
              - -c
              - nodetool drain
        env:
          - name: MAX_HEAP_SIZE
            value: 512M
          - name: HEAP_NEWSIZE
            value: 100M
          - name: CASSANDRA_SEEDS
            value: "cassandra-0.cassandra.default.svc.cluster.local"
          - name: CASSANDRA_CLUSTER_NAME
            value: "K8Demo"
          - name: CASSANDRA_DC
            value: "DC1-K8Demo"
          - name: CASSANDRA_RACK
            value: "Rack1-K8Demo"
          - name: POD_IP
            valueFrom:
              fieldRef:
                fieldPath: status.podIP
        readinessProbe:
          exec:
            command:
            - /bin/bash
            - -c
            - /ready-probe.sh
          initialDelaySeconds: 15
          timeoutSeconds: 5
        # Ці точки монтування томів є постійними. Вони подібни до вбудованих заявок,
        # але не зовсіс, тому що імена повинні точно збігатись з одним з томів
        # томів Podʼів stateful.
        volumeMounts:
        - name: cassandra-data
          mountPath: /cassandra_data
  # Це перетворюється у заявки на томи контролером
  # та монтується в шлях, зазначений вище.
  # не використовуйте це в операційній діяльності, допоки тип ssd є GCEPersistentDisk чи інший ssd pd
  volumeClaimTemplates:
  - metadata:
      name: cassandra-data
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: fast
      resources:
        requests:
          storage: 1Gi
---
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: fast
provisioner: k8s.io/minikube-hostpath
parameters:
  type: pd-ssd

Створіть StatefulSet Cassandra з файлу cassandra-statefulset.yaml:

# Використовуйте це, якщо ви можете застосувати cassandra-statefulset.yaml без змін
kubectl apply -f https://k8s.io/examples/application/cassandra/cassandra-statefulset.yaml

Якщо вам потрібно змінити cassandra-statefulset.yaml для вашого кластера, завантажте https://k8s.io/examples/application/cassandra/cassandra-statefulset.yaml та застосуйте цей маніфест, з теки, в яку ви зберегли змінену версію:

# Використовуйте це, якщо ви змінили cassandra-statefulset.yaml локально
kubectl apply -f cassandra-statefulset.yaml

Перевірка StatefulSet Cassandra

  1. Отримайте StatefulSet Cassandra:

    kubectl get statefulset cassandra
    

    Відповідь буде схожа на:

    NAME        DESIRED   CURRENT   AGE
    cassandra   3         0         13s
    

    Ресурс StatefulSet розгортає Podʼи послідовно.

  2. Отримайте Podʼи, щоб побачити статус створення в зазначеному порядку:

    kubectl get pods -l="app=cassandra"
    

    Відповідь буде схожа на:

    NAME          READY     STATUS              RESTARTS   AGE
    cassandra-0   1/1       Running             0          1m
    cassandra-1   0/1       ContainerCreating   0          8s
    

    На створення всіх трьох Podʼів може піти декілька хвилин. Після їх розгортання ця ж команда повертає вихідні дані, схожі на:

    NAME          READY     STATUS    RESTARTS   AGE
    cassandra-0   1/1       Running   0          10m
    cassandra-1   1/1       Running   0          9m
    cassandra-2   1/1       Running   0          8m
    
  3. Виконайте інструмент nodetool Cassandra всередині першого Podʼа, щоб переглянути стан кільця.

    kubectl exec -it cassandra-0 -- nodetool status
    

    Відповідь буде схожою на:

    Datacenter: DC1-K8Demo
    ======================
    Status=Up/Down
    |/ State=Normal/Leaving/Joining/Moving
    --  Address     Load       Tokens       Owns (effective)  Host ID                               Rack
    UN  172.17.0.5  83.57 KiB  32           74.0%             e2dd09e6-d9d3-477e-96c5-45094c08db0f  Rack1-K8Demo
    UN  172.17.0.4  101.04 KiB  32           58.8%             f89d6835-3a42-4419-92b3-0e62cae1479c  Rack1-K8Demo
    UN  172.17.0.6  84.74 KiB  32           67.1%             a6a1e8c2-3dc5-4417-b1a0-26507af2aaad  Rack1-K8Demo
    

Зміна StatefulSet Cassandra

Використовуйте kubectl edit, щоб змінити розмір StatefulSet Cassandra.

  1. Виконайте наступну команду:

    kubectl edit statefulset cassandra
    

    Ця команда відкриває редактор у вашому терміналі. Рядок, який вам потрібно змінити, — це поле replicas. Наведений нижче приклад — це уривок з файлу StatefulSet:

    # Будь ласка, відредагуйте об’єкт нижче. Рядки, що починаються з '#', будуть проігноровані,
    # і пустий файл призведе до відмови редагування. Якщо під час збереження файлу виникне помилка,
    # цей файл буде знову відкритий із відповідними несправностями.
    #
    apiVersion: apps/v1
    kind: StatefulSet
    metadata:
      creationTimestamp: 2016-08-13T18:40:58Z
    
    
      generation: 1
      labels:
      app: cassandra
      name: cassandra
      namespace: default
      resourceVersion: "323"
      uid: 7a219483-6185-11e6-a910-42010a8a0fc0
    spec:
      replicas: 3
    
  2. Змініть кількість реплік на 4 і збережіть маніфест.

    Тепер StatefulSet масштабується для роботи з 4 Podʼами.

  3. Отримайте StatefulSet Cassandra, щоб перевірити зміни:

    kubectl get statefulset cassandra
    

    Відповідь буде схожа на:

    NAME        DESIRED   CURRENT   AGE
    cassandra   4         4         36m
    

Очищення

Видалення або зменшення масштабу StatefulSet не призводить до видалення томів, повʼязаних із StatefulSet. Це налаштування захищає вас, оскільки ваші дані цінніші, ніж автоматичне очищення всіх повʼязаних ресурсів StatefulSet.

  1. Виконайте наступні команди (послідовно обʼєднані в одну команду) для видалення всього в StatefulSet Cassandra:

    grace=$(kubectl get pod cassandra-0 -o=jsonpath='{.spec.terminationGracePeriodSeconds}') \
      && kubectl delete statefulset -l app=cassandra \
      && echo "Sleeping ${grace} seconds" 1>&2 \
      && sleep $grace \
      && kubectl delete persistentvolumeclaim -l app=cassandra
    
  2. Виконайте наступну команду для видалення Service, який ви налаштували для Cassandra:

    kubectl delete service -l app=cassandra
    

Змінні середовища контейнера Cassandra

Podʼи в цьому посібнику використовують образ gcr.io/google-samples/cassandra:v13 з реєстру контейнерів Google. Докер-образ вище базується на debian-base і містить OpenJDK 8.

Цей образ включає стандартну установку Cassandra з репозиторію Apache Debian. За допомогою змінних середовища ви можете змінити значення, які вставляються в cassandra.yaml.

Змінна середовищаСтандартне значенняанням
CASSANDRA_CLUSTER_NAME'Test Cluster'
CASSANDRA_NUM_TOKENS32
CASSANDRA_RPC_ADDRESS0.0.0.0

Що далі

5.6.4 - Запуск ZooKeeper, розподіленого системного координатора

Цей посібник демонструє як запускати Apache Zookeeper в Kubernetes, використовуючи StatefulSets, PodDisruptionBudgets, та PodAntiAffinity.

Перш ніж ви розпочнете

Перед тим як розпочати, переконайтеся, що ви маєте уявлення про:

Вам необхідно мати кластер із щонайменше чотирма вузлами, і кожен вузол повинен мати щонайменше 2 ЦП та 4 ГБ памʼяті. У цьому посібнику ви будете закривати (cordon) та очищувати для обслуговування (drain) вузли кластера. Це означає, що кластер припинить роботу та виселить всі Podʼи зі своїх вузлів, і вузли тимчасово стануть не придатними до розміщення Podʼів. Вам слід використовувати окремий кластер для цього посібника, або ви повинні забезпечити, що порушення, яке ви викличете, не нашкодить іншим мешканцям кластера.

У цьому посібнику передбачається, що ви налаштували свій кластер для динамічного надання постійних томів (PersistentVolumes). Якщо ваш кластер не налаштований на це, вам доведеться вручну створити три томи обсягом 20 ГБ перед початком виконання кроків цього посібника.

Цілі

Після проходження цього посібника ви будете знати, як:

  • Розгортати ансамбль Apache Zookeeper використовуючи StatefulSet.
  • Як надійно налаштовувати ансамбль.
  • Як поширювати розгортання серверів Zookeeper в ансамблі.
  • Як використовувати PodDisruptionBudgets для забезпечення високої доступності послуг під час запланованого обслуговування.

ZooKeeper

Apache ZooKeeper — це розподілена, відкрита координаційна служба для розподілених застосунків. ZooKeeper дозволяє читати, записувати та спостерігати за оновленнями даних. Дані організовані у вигляді ієрархії файлової системи та реплікуються на всі сервери ZooKeeper в ансамблі (набір серверів ZooKeeper). Всі операції з даними є атомарними та послідовно консистентними. ZooKeeper забезпечує це, використовуючи протокол консенсусу Zab для реплікації машини стану на всіх серверах в ансамблі.

Ансамбль використовує протокол Zab для вибору лідера, ансамбль не може записувати дані, поки цей вибір лідера не завершиться. Після його завершення ансамбль використовує Zab, щоб забезпечити реплікацію всіх записів до кворуму, перш ніж він підтверджує їх та робить їх видимими для клієнтів. Без зваженого кворуму, кворум — буде більшістю складових ансамблю, які містять поточного лідера. Наприклад, якщо в ансамблі є три сервери, компонент, який містить лідера і ще один сервер, становитимуть кворум. Якщо ансамбль не може досягти кворуму, він не може записувати дані.

Сервери ZooKeeper зберігають свою повну машину стану в памʼяті та записують кожну зміну до довгострокового WAL (Write Ahead Log) на носії інформації. Коли сервер аварійно завершує роботу, він може відновити свій попередній стан, відтворюючи WAL. Щоб запобігти безмежному зростанню WAL, сервери ZooKeeper періодично роблять знімки їхнього стану в памʼяті на носій інформації. Ці знімки можуть бути завантажені безпосередньо в памʼять, а всі записи WAL, які передували знімку, можуть бути видалені.

Створення ансамблю ZooKeeper

Маніфест нижче містить:

apiVersion: v1
kind: Service
metadata:
  name: zk-hs
  labels:
    app: zk
spec:
  ports:
  - port: 2888
    name: server
  - port: 3888
    name: leader-election
  clusterIP: None
  selector:
    app: zk
---
apiVersion: v1
kind: Service
metadata:
  name: zk-cs
  labels:
    app: zk
spec:
  ports:
  - port: 2181
    name: client
  selector:
    app: zk
---
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: zk-pdb
spec:
  selector:
    matchLabels:
      app: zk
  maxUnavailable: 1
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: zk
spec:
  selector:
    matchLabels:
      app: zk
  serviceName: zk-hs
  replicas: 3
  updateStrategy:
    type: RollingUpdate
  podManagementPolicy: OrderedReady
  template:
    metadata:
      labels:
        app: zk
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchExpressions:
                  - key: "app"
                    operator: In
                    values:
                    - zk
              topologyKey: "kubernetes.io/hostname"
      containers:
      - name: kubernetes-zookeeper
        imagePullPolicy: Always
        image: "registry.k8s.io/kubernetes-zookeeper:1.0-3.4.10"
        resources:
          requests:
            memory: "1Gi"
            cpu: "0.5"
        ports:
        - containerPort: 2181
          name: client
        - containerPort: 2888
          name: server
        - containerPort: 3888
          name: leader-election
        command:
        - sh
        - -c
        - "start-zookeeper \
          --servers=3 \
          --data_dir=/var/lib/zookeeper/data \
          --data_log_dir=/var/lib/zookeeper/data/log \
          --conf_dir=/opt/zookeeper/conf \
          --client_port=2181 \
          --election_port=3888 \
          --server_port=2888 \
          --tick_time=2000 \
          --init_limit=10 \
          --sync_limit=5 \
          --heap=512M \
          --max_client_cnxns=60 \
          --snap_retain_count=3 \
          --purge_interval=12 \
          --max_session_timeout=40000 \
          --min_session_timeout=4000 \
          --log_level=INFO"
        readinessProbe:
          exec:
            command:
            - sh
            - -c
            - "zookeeper-ready 2181"
          initialDelaySeconds: 10
          timeoutSeconds: 5
        livenessProbe:
          exec:
            command:
            - sh
            - -c
            - "zookeeper-ready 2181"
          initialDelaySeconds: 10
          timeoutSeconds: 5
        volumeMounts:
        - name: datadir
          mountPath: /var/lib/zookeeper
      securityContext:
        runAsUser: 1000
        fsGroup: 1000
  volumeClaimTemplates:
  - metadata:
      name: datadir
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 10Gi

Відкрийте термінал і скористайтеся командою kubectl apply, щоб створити маніфест.

kubectl apply -f https://k8s.io/examples/application/zookeeper/zookeeper.yaml

Це створить zk-hs Headless Service, zk-cs Service, zk-pdb PodDisruptionBudget та zk StatefulSet.

service/zk-hs створено
service/zk-cs створено
poddisruptionbudget.policy/zk-pdb створено
statefulset.apps/zk створено

Скористайтеся kubectl get, щоб спостерігати за створенням StatefulSet контролером Podʼів StatefulSet.

kubectl get pods -w -l app=zk

Коли Pod zk-2 в стані Running та Ready, скористайтеся CTRL-C, щоб припинити виконання kubectl.

NAME      READY     STATUS    RESTARTS   AGE
zk-0      0/1       Pending   0          0s
zk-0      0/1       Pending   0         0s
zk-0      0/1       ContainerCreating   0         0s
zk-0      0/1       Running   0         19s
zk-0      1/1       Running   0         40s
zk-1      0/1       Pending   0         0s
zk-1      0/1       Pending   0         0s
zk-1      0/1       ContainerCreating   0         0s
zk-1      0/1       Running   0         18s
zk-1      1/1       Running   0         40s
zk-2      0/1       Pending   0         0s
zk-2      0/1       Pending   0         0s
zk-2      0/1       ContainerCreating   0         0s
zk-2      0/1       Running   0         19s
zk-2      1/1       Running   0         40s

Контролер StatefulSet створює три Podʼи, і кожен Pod містить контейнер з сервером ZooKeeper.

Забезпечення виборів лідера

Оскільки в анонімній мережі немає алгоритму завершення для вибору лідера, Zab вимагає явної конфігурації членства для виконання виборів лідера. Кожен сервер в ансамблі повинен мати унікальний ідентифікатор, всі сервери повинні знати глобальний набір ідентифікаторів, і кожен ідентифікатор повинен бути повʼязаний з мережевою адресою.

Використовуйте kubectl exec, щоб отримати імена хостів Podʼів у StatefulSet zk.

for i in 0 1 2; do kubectl exec zk-$i -- hostname; done

Контролер StatefulSet надає кожному Podʼу унікальне імʼя хосту на основі його порядкового індексу. Імена хостів мають форму <імʼя statefulset>-<порядковий індекс>. Оскільки поле replicas StatefulSet zk встановлено на 3, контролер набору створює три Podʼа з іменами хостів zk-0, zk-1 і zk-2.

zk-0
zk-1
zk-2

Сервери в ансамблі ZooKeeper використовують натуральні числа як унікальні ідентифікатори, і зберігають ідентифікатор кожного сервера у файлі, який називається myid, в теці даних сервера.

Щоб переглянути вміст файлу myid для кожного сервера, скористайтеся такою командою.

for i in 0 1 2; do echo "myid zk-$i";kubectl exec zk-$i -- cat /var/lib/zookeeper/data/myid; done

Оскільки ідентифікатори є натуральними числами, а порядкові індекси є не відʼємними цілими числами, можна згенерувати ідентифікатор, додавши 1 до порядкового номера.

myid zk-0
1
myid zk-1
2
myid zk-2
3

Щоб отримати повне доменне імʼя (FQDN) кожного Podʼа у StatefulSet zk, використовуйте таку команду.

for i in 0 1 2; do kubectl exec zk-$i -- hostname -f; done

Service zk-hs створює домен для всіх Podʼів, zk-hs.default.svc.cluster.local.

zk-0.zk-hs.default.svc.cluster.local
zk-1.zk-hs.default.svc.cluster.local
zk-2.zk-hs.default.svc.cluster.local

Записи A в DNS Kubernetes перетворюють FQDN в IP-адреси Podʼів. Якщо Kubernetes переплановує Podʼи, він оновлює записи A із новими IP-адресами Podʼів, але імена записів A не змінюються.

ZooKeeper зберігає свою конфігурацію застосунку в файлі з іменем zoo.cfg. Використовуйте kubectl exec, щоб переглянути вміст файлу zoo.cfg у Поді zk-0.

kubectl exec zk-0 -- cat /opt/zookeeper/conf/zoo.cfg

У властивостях server.1, server.2 та server.3 внизу файлу, 1, 2 та 3 відповідають ідентифікаторам у файлах myid серверів ZooKeeper. Вони встановлені на FQDN для Podʼів у StatefulSet zk.

clientPort=2181
dataDir=/var/lib/zookeeper/data
dataLogDir=/var/lib/zookeeper/log
tickTime=2000
initLimit=10
syncLimit=2000
maxClientCnxns=60
minSessionTimeout= 4000
maxSessionTimeout= 40000
autopurge.snapRetainCount=3
autopurge.purgeInterval=0
server.1=zk-0.zk-hs.default.svc.cluster.local:2888:3888
server.2=zk-1.zk-hs.default.svc.cluster.local:2888:3888
server.3=zk-2.zk-hs.default.svc.cluster.local:2888:3888

Досягнення консенсусу

Протоколи консенсусу вимагають, щоб ідентифікатори кожного учасника були унікальними. Два учасники у протоколі Zab не повинні претендувати на той самий унікальний ідентифікатор. Це необхідно для того, щоб процеси в системі могли погодитися щодо того, які процеси затвердили які дані. Якщо запускаються два Podʼа з тим самим порядковим номером, два сервери ZooKeeper ідентифікуватимуть себе як один і той самий сервер.

kubectl get pods -w -l app=zk
NAME      READY     STATUS    RESTARTS   AGE
zk-0      0/1       Pending   0          0s
zk-0      0/1       Pending   0         0s
zk-0      0/1       ContainerCreating   0         0s
zk-0      0/1       Running   0         19s
zk-0      1/1       Running   0         40s
zk-1      0/1       Pending   0         0s
zk-1      0/1       Pending   0         0s
zk-1      0/1       ContainerCreating   0         0s
zk-1      0/1       Running   0         18s
zk-1      1/1       Running   0         40s
zk-2      0/1       Pending   0         0s
zk-2      0/1       Pending   0         0s
zk-2      0/1       ContainerCreating   0         0s
zk-2      0/1       Running   0         19s
zk-2      1/1       Running   0         40s

Записи A для кожного Pod вводяться, коли Pod стає готовим. Тому, FQDN серверів ZooKeeper посилається на єдину точку доступу, і ця точка доступу буде унікальним сервером ZooKeeper, який претендує на ідентифікацію, налаштовану в його файлі myid.

zk-0.zk-hs.default.svc.cluster.local
zk-1.zk-hs.default.svc.cluster.local
zk-2.zk-hs.default.svc.cluster.local

Це забезпечує, що властивості servers у файлах zoo.cfg ZooKeepers становлять собою правильно налаштований ансамбль.

server.1=zk-0.zk-hs.default.svc.cluster.local:2888:3888
server.2=zk-1.zk-hs.default.svc.cluster.local:2888:3888
server.3=zk-2.zk-hs.default.svc.cluster.local:2888:3888

Коли сервери використовують протокол Zab, щоб спробувати затвердити значення, вони або досягатимуть консенсусу і затверджуватимуть значення (якщо вибори лідера пройшли успішно і принаймні два Podʼа працюють та готові), або вони не зможуть цього зробити (якщо будь-яка з умов не виконується). Ні один стан не призведе до того, що один сервер підтверджує запис від імені іншого.

Перевірка адекватності ансамблю

Найбільш базове тестування на адекватність — це запис даних на один сервер ZooKeeper і читання даних з іншого.

Наведена нижче команда виконує скрипт zkCli.sh, щоб записати world в шлях /hello у Pod zk-0 в ансамблі.

kubectl exec zk-0 -- zkCli.sh create /hello world
WATCHER::

WatchedEvent state:SyncConnected type:None path:null
Created /hello

Щоб отримати дані з Podʼа zk-1, використовуйте таку команду.

kubectl exec zk-1 -- zkCli.sh get /hello

Дані, які ви створили на zk-0, доступні на всіх серверах в ансамблі.

WATCHER::

WatchedEvent state:SyncConnected type:None path:null
world
cZxid = 0x100000002
ctime = Thu Dec 08 15:13:30 UTC 2016
mZxid = 0x100000002
mtime = Thu Dec 08 15:13:30 UTC 2016
pZxid = 0x100000002
cversion = 0
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 5
numChildren = 0

Забезпечення стійкості зберігання

Як зазначено в розділі Основи ZooKeeper, ZooKeeper фіксує всі записи в стійкому журналі (WAL) та періодично записує знімки стану памʼяті на носії. Використання WAL для забезпечення стійкості є поширеною технікою для застосунків, які використовують протоколи консенсусу для досягнення реплікованої машини станів.

Використовуйте команду kubectl delete, щоб видалити обʼєкт StatefulSet zk.

kubectl delete statefulset zk
statefulset.apps "zk" deleted

Спостерігайте за завершенням роботи Podʼів у StatefulSet.

kubectl get pods -w -l app=zk

Коли zk-0 повністю завершить роботу, використовуйте CTRL-C, щоб завершити виконання kubectl.

zk-2      1/1       Terminating   0         9m
zk-0      1/1       Terminating   0         11m
zk-1      1/1       Terminating   0         10m
zk-2      0/1       Terminating   0         9m
zk-2      0/1       Terminating   0         9m
zk-2      0/1       Terminating   0         9m
zk-1      0/1       Terminating   0         10m
zk-1      0/1       Terminating   0         10m
zk-1      0/1       Terminating   0         10m
zk-0      0/1       Terminating   0         11m
zk-0      0/1       Terminating   0         11m
zk-0      0/1       Terminating   0         11m

Повторно застосуйте маніфест у файлі zookeeper.yaml.

kubectl apply -f https://k8s.io/examples/application/zookeeper/zookeeper.yaml

Це створює обʼєкт StatefulSet zk, але інші обʼєкти API у маніфесті не модифікуються, оскільки вони вже існують.

Спостерігайте, як контролер StatefulSet перестворює Podʼи StatefulSet.

kubectl get pods -w -l app=zk

Коли Pod zk-2 відзначається як Running і Ready, використовуйте CTRL-C, щоб завершити виконання kubectl.

NAME      READY     STATUS    RESTARTS   AGE
zk-0      0/1       Pending   0          0s
zk-0      0/1       Pending   0         0s
zk-0      0/1       ContainerCreating   0         0s
zk-0      0/1       Running   0         19s
zk-0      1/1       Running   0         40s
zk-1      0/1       Pending   0         0s
zk-1      0/1       Pending   0         0s
zk-1      0/1       ContainerCreating   0         0s
zk-1      0/1       Running   0         18s
zk-1      1/1       Running   0         40s
zk-2      0/1       Pending   0         0s
zk-2      0/1       Pending   0         0s
zk-2      0/1       ContainerCreating   0         0s
zk-2      0/1       Running   0         19s
zk-2      1/1       Running   0         40s

Використайте наведену нижче команду, щоб отримати значення, яке ви ввели під час тестування на адекватність, з Podʼа zk-2.

kubectl exec zk-2 zkCli.sh get /hello

Навіть якщо ви зупинили та знову створили всі Podʼи в StatefulSet zk, ансамбль все ще обслуговує початкове значення.

WATCHER::

WatchedEvent state:SyncConnected type:None path:null
world
cZxid = 0x100000002
ctime = Thu Dec 08 15:13:30 UTC 2016
mZxid = 0x100000002
mtime = Thu Dec 08 15:13:30 UTC 2016
pZxid = 0x100000002
cversion = 0
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 5
numChildren = 0

Секція volumeClaimTemplates поля spec обʼєкта zk StatefulSet вказує на PersistentVolume, який створюється для кожного Podʼа.

volumeClaimTemplates:
  - metadata:
      name: datadir
      annotations:
        volume.alpha.kubernetes.io/storage-class: anything
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 20Gi

Контролер StatefulSet генерує PersistentVolumeClaim для кожного Podʼа у StatefulSet.

Використайте наступну команду, щоб отримати PersistentVolumeClaims StatefulSet.

kubectl get pvc -l app=zk

Коли StatefulSet повторно створює Podʼи, він повторно монтує PersistentVolumes Podʼів.

NAME           STATUS    VOLUME                                     CAPACITY   ACCESSMODES   AGE
datadir-zk-0   Bound     pvc-bed742cd-bcb1-11e6-994f-42010a800002   20Gi       RWO           1h
datadir-zk-1   Bound     pvc-bedd27d2-bcb1-11e6-994f-42010a800002   20Gi       RWO           1h
datadir-zk-2   Bound     pvc-bee0817e-bcb1-11e6-994f-42010a800002   20Gi       RWO           1h

Розділ volumeMounts контейнера template StatefulSet монтує PersistentVolumes в теки даних серверів ZooKeeper.

volumeMounts:
- name: datadir
  mountPath: /var/lib/zookeeper

Коли Pod у zk StatefulSet (пере)планується, у нього завжди монтується той самий PersistentVolume у теку даних сервера ZooKeeper. Навіть коли Podʼи переплануються, всі записи, зроблені у логах WAL серверів ZooKeeper, та всі їх знімки залишаються стійкими.

Забезпечення однорідної конфігурації

Як вказано в розділах Забезпечення виборів лідера та Досягнення консенсусу, сервери в ансамблі ZooKeeper потребують однорідної конфігурації для вибору лідера та формування кворуму. Також потрібна однорідна конфігурація протоколу Zab для коректної роботи протоколу мережею. У нашому прикладі ми досягаємо однорідної конфігурації, вбудувавши конфігурацію безпосередньо у маніфест.

Отримайте zk StatefulSet.

kubectl get sts zk -o yaml

command:
      - sh
      - -c
      - "start-zookeeper \
        --servers=3 \
        --data_dir=/var/lib/zookeeper/data \
        --data_log_dir=/var/lib/zookeeper/data/log \
        --conf_dir=/opt/zookeeper/conf \
        --client_port=2181 \
        --election_port=3888 \
        --server_port=2888 \
        --tick_time=2000 \
        --init_limit=10 \
        --sync_limit=5 \
        --heap=512M \
        --max_client_cnxns=60 \
        --snap_retain_count=3 \
        --purge_interval=12 \
        --max_session_timeout=40000 \
        --min_session_timeout=4000 \
        --log_level=INFO"

Команда, яка використовується для запуску серверів ZooKeeper, передає конфігурацію як параметр командного рядка. Ви також можете використовувати змінні середовища для передачі конфігурації в ансамбль.

Налаштування системи логування

Один з файлів, що генерується сценарієм zkGenConfig.sh, керує логуванням ZooKeeper. ZooKeeper використовує Log4j, і типово він використовує інструмент постійного додавання, який покладається на час та розмір для конфігурації логування.

Використайте команду нижче, щоб отримати конфігурацію логування з одного з контейнерів у StatefulSet zk.

kubectl exec zk-0 cat /usr/etc/zookeeper/log4j.properties

Конфігурація логування нижче призведе до того, що процес ZooKeeper буде записувати всі свої логи у вихідний файловий потік стандартного виводу.

zookeeper.root.logger=CONSOLE
zookeeper.console.threshold=INFO
log4j.rootLogger=${zookeeper.root.logger}
log4j.appender.CONSOLE=org.apache.log4j.ConsoleAppender
log4j.appender.CONSOLE.Threshold=${zookeeper.console.threshold}
log4j.appender.CONSOLE.layout=org.apache.log4j.PatternLayout
log4j.appender.CONSOLE.layout.ConversionPattern=%d{ISO8601} [myid:%X{myid}] - %-5p [%t:%C{1}@%L] - %m%n

Це найпростіший спосіб безпечного логування всередині контейнера. Тому що програми записують логи у стандартний вивід, Kubernetes буде відповідальним за ротацію логів для вас. Kubernetes також реалізує розумну політику зберігання, яка гарантує, що логи застосунків, записані у потоки стандартного виводу та помилок, не виснажують локальні носії інформації.

Використайте kubectl logs, щоб отримати останні 20 рядків логів з одного з контейнерів.

kubectl logs zk-0 --tail 20

Ви можете переглядати логи застосунків, записані у стандартний вивід або стандартну помилку, використовуючи kubectl logs та з Kubernetes Dashboard.

2016-12-06 19:34:16,236 [myid:1] - INFO  [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@827] - Processing ruok command from /127.0.0.1:52740
2016-12-06 19:34:16,237 [myid:1] - INFO  [Thread-1136:NIOServerCnxn@1008] - Closed socket connection for client /127.0.0.1:52740 (no session established for client)
2016-12-06 19:34:26,155 [myid:1] - INFO  [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxnFactory@192] - Accepted socket connection from /127.0.0.1:52749
2016-12-06 19:34:26,155 [myid:1] - INFO  [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@827] - Processing ruok command from /127.0.0.1:52749
2016-12-06 19:34:26,156 [myid:1] - INFO  [Thread-1137:NIOServerCnxn@1008] - Closed socket connection for client /127.0.0.1:52749 (no session established for client)
2016-12-06 19:34:26,222 [myid:1] - INFO  [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxnFactory@192] - Accepted socket connection from /127.0.0.1:52750
2016-12-06 19:34:26,222 [myid:1] - INFO  [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@827] - Processing ruok command from /127.0.0.1:52750
2016-12-06 19:34:26,226 [myid:1] - INFO  [Thread-1138:NIOServerCnxn@1008] - Closed socket connection for client /127.0.0.1:52750 (no session established for client)
2016-12-06 19:34:36,151 [myid:1] - INFO  [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxnFactory@192] - Accepted socket connection from /127.0.0.1:52760
2016-12-06 19:34:36,152 [myid:1] - INFO  [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@827] - Processing ruok command from /127.0.0.1:52760
2016-12-06 19:34:36,152 [myid:1] - INFO  [Thread-1139:NIOServerCnxn@1008] - Closed socket connection for client /127.0.0.1:52760 (no session established for client)
2016-12-06 19:34:36,230 [myid:1] - INFO  [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxnFactory@192] - Accepted socket connection from /127.0.0.1:52761
2016-12-06 19:34:36,231 [myid:1] - INFO  [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@827] - Processing ruok command from /127.0.0.1:52761
2016-12-06 19:34:36,231 [myid:1] - INFO  [Thread-1140:NIOServerCnxn@1008] - Closed socket connection for client /127.0.0.1:52761 (no session established for client)
2016-12-06 19:34:46,149 [myid:1] - INFO  [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxnFactory@192] - Accepted socket connection from /127.0.0.1:52767
2016-12-06 19:34:46,149 [myid:1] - INFO  [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@827] - Processing ruok command from /127.0.0.1:52767
2016-12-06 19:34:46,149 [myid:1] - INFO  [Thread-1141:NIOServerCnxn@1008] - Closed socket connection for client /127.0.0.1:52767 (no session established for client)
2016-12-06 19:34:46,230 [myid:1] - INFO  [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxnFactory@192] - Accepted socket connection from /127.0.0.1:52768
2016-12-06 19:34:46,230 [myid:1] - INFO  [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@827] - Processing ruok command from /127.0.0.1:52768
2016-12-06 19:34:46,230 [myid:1] - INFO  [Thread-1142:NIOServerCnxn@1008] - Closed socket connection for client /127.0.0.1:52768 (no session established for client)

Kubernetes інтегрується з багатьма рішеннями для логування. Ви можете вибрати рішення для логування, яке найкраще підходить для вашого кластера та застосунків. Для логування та агрегації на рівні кластера розгляньте розгортання sidecar контейнера, для ротації та надсилання ваших логів.

Налаштування не привілейованого користувача

Найкращі практики дозволити застосунку працювати як привілейований користувач всередині контейнера — це предмет для обговорення. Якщо ваша організація вимагає, щоб застосунки працювали як непривілейований користувач, ви можете використовувати SecurityContext для контролю над користувачем, під яким запускається точка входу.

У template Podʼів StatefulSet zk є SecurityContext.

securityContext:
  runAsUser: 1000
  fsGroup: 1000

У контейнерах Podʼів, UID 1000 відповідає користувачеві zookeeper, а GID 1000 відповідає групі zookeeper.

Отримайте інформацію про процес ZooKeeper з Поду zk-0.

kubectl exec zk-0 -- ps -elf

Оскільки поле runAsUser обʼєкта securityContext встановлене на 1000, замість того, щоб запускатися як root, процес ZooKeeper запускається як користувач zookeeper.

F S UID        PID  PPID  C PRI  NI ADDR SZ WCHAN  STIME TTY          TIME CMD
4 S zookeep+     1     0  0  80   0 -  1127 -      20:46 ?        00:00:00 sh -c zkGenConfig.sh && zkServer.sh start-foreground
0 S zookeep+    27     1  0  80   0 - 1155556 -    20:46 ?        00:00:19 /usr/lib/jvm/java-8-openjdk-amd64/bin/java -Dzookeeper.log.dir=/var/log/zookeeper -Dzookeeper.root.logger=INFO,CONSOLE -cp /usr/bin/../build/classes:/usr/bin/../build/lib/*.jar:/usr/bin/../share/zookeeper/zookeeper-3.4.9.jar:/usr/bin/../share/zookeeper/slf4j-log4j12-1.6.1.jar:/usr/bin/../share/zookeeper/slf4j-api-1.6.1.jar:/usr/bin/../share/zookeeper/netty-3.10.5.Final.jar:/usr/bin/../share/zookeeper/log4j-1.2.16.jar:/usr/bin/../share/zookeeper/jline-0.9.94.jar:/usr/bin/../src/java/lib/*.jar:/usr/bin/../etc/zookeeper: -Xmx2G -Xms2G -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.local.only=false org.apache.zookeeper.server.quorum.QuorumPeerMain /usr/bin/../etc/zookeeper/zoo.cfg

Типово, коли PersistentVolumes Поду монтується в теку даних сервера ZooKeeper, він доступний тільки для користувача root. Ця конфігурація заважає процесу ZooKeeper записувати свій лог та зберігати свої знімки.

Використовуйте команду нижче, щоб отримати права доступу до файлу теки даних ZooKeeper на Поді zk-0.

kubectl exec -ti zk-0 -- ls -ld /var/lib/zookeeper/data

Оскільки поле fsGroup обʼєкта securityContext встановлене на 1000, власність PersistentVolumes Podʼів встановлюється на групу zookeeper, і процес ZooKeeper може читати та записувати свої дані.

drwxr-sr-x 3 zookeeper zookeeper 4096 Dec  5 20:45 /var/lib/zookeeper/data

Управління процесом ZooKeeper

В документації ZooKeeper зазначено, що "Вам захочеться мати наглядовий процес, який керує кожним з ваших процесів сервера ZooKeeper (JVM)." Використання watchdog (наглядового процесу) для перезапуску процесів, що зазнали збою, у розподіленій системі є загальним шаблоном. При розгортанні застосунку в Kubernetes, замість використання зовнішньої утиліти як наглядового процесу, ви повинні використовувати Kubernetes як watchdog для вашого застосунку.

Оновлення ансамблю

StatefulSet zk налаштований на використання стратегії оновлення RollingUpdate.

Ви можете використовувати kubectl patch, щоб оновити кількість cpus, виділених серверам.

kubectl patch sts zk --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/resources/requests/cpu", "value":"0.3"}]'
statefulset.apps/zk відредаговано

Використовуйте kubectl rollout status, щоб спостерігати за статусом оновлення.

kubectl rollout status sts/zk
waiting for statefulset rolling update to complete 0 pods at revision zk-5db4499664...
Waiting for 1 pods to be ready...
Waiting for 1 pods to be ready...
waiting for statefulset rolling update to complete 1 pods at revision zk-5db4499664...
Waiting for 1 pods to be ready...
Waiting for 1 pods to be ready...
waiting for statefulset rolling update to complete 2 pods at revision zk-5db4499664...
Waiting for 1 pods to be ready...
Waiting for 1 pods to be ready...
statefulset rolling update complete 3 pods at revision zk-5db4499664...

Це припиняє роботу Podʼів, по одному, у зворотному порядку, і перестворює їх з новою конфігурацією. Це забезпечує підтримку кворуму під час постійного оновлення.

Використовуйте команду kubectl rollout history, щоб переглянути історію або попередні конфігурації.

kubectl rollout history sts/zk

Вивід схожий на такий:

statefulsets "zk"
REVISION
1
2

Використовуйте команду kubectl rollout undo, щоб скасувати модифікацію.

kubectl rollout undo sts/zk

Вивід схожий на такий:

statefulset.apps/zk повернувся до попереднього стану

Обробка відмови процесу

Політики перезапуску контролюють, як Kubernetes обробляє відмови процесів для вхідної точки контейнера в Pod. Для Podʼів у StatefulSet єдине припустиме значення RestartPolicy — це Always, і це є стандартним значенням. Для StatefulSet застосунків ви ніколи не повинні змінювати стандартні значення.

Використовуйте наступну команду, щоб переглянути дерево процесів сервера ZooKeeper, який працює в поді zk-0.

kubectl exec zk-0 -- ps -ef

Команда, яка використовується як точка входу контейнера, має PID 1, а процес ZooKeeper, нащадок точки входу, має PID 27.

UID        PID  PPID  C STIME TTY          TIME CMD
zookeep+     1     0  0 15:03 ?        00:00:00 sh -c zkGenConfig.sh && zkServer.sh start-foreground
zookeep+    27     1  0 15:03 ?        00:00:03 /usr/lib/jvm/java-8-openjdk-amd64/bin/java -Dzookeeper.log.dir=/var/log/zookeeper -Dzookeeper.root.logger=INFO,CONSOLE -cp /usr/bin/../build/classes:/usr/bin/../build/lib/*.jar:/usr/bin/../share/zookeeper/zookeeper-3.4.9.jar:/usr/bin/../share/zookeeper/slf4j-log4j12-1.6.1.jar:/usr/bin/../share/zookeeper/slf4j-api-1.6.1.jar:/usr/bin/../share/zookeeper/netty-3.10.5.Final.jar:/usr/bin/../share/zookeeper/log4j-1.2.16.jar:/usr/bin/../share/zookeeper/jline-0.9.94.jar:/usr/bin/../src/java/lib/*.jar:/usr/bin/../etc/zookeeper: -Xmx2G -Xms2G -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.local.only=false org.apache.zookeeper.server.quorum.QuorumPeerMain /usr/bin/../etc/zookeeper/zoo.cfg

У іншому терміналі спостерігайте за Podʼами у StatefulSet zk за допомогою наступної команди.

kubectl get pod -w -l app=zk

У іншому терміналі завершіть процес ZooKeeper у поді zk-0 за допомогою наступної команди.

kubectl exec zk-0 -- pkill java

Завершення процесу ZooKeeper призвело до завершення його батьківського процесу. Оскільки RestartPolicy контейнера — завжди, він перезапустив батьківський процес.

NAME      READY     STATUS    RESTARTS   AGE
zk-0      1/1       Running   0          21m
zk-1      1/1       Running   0          20m
zk-2      1/1       Running   0          19m
NAME      READY     STATUS    RESTARTS   AGE
zk-0      0/1       Error     0          29m
zk-0      0/1       Running   1         29m
zk-0      1/1       Running   1         29m

Якщо ваш застосунок використовує сценарій (наприклад, zkServer.sh) для запуску процесу, який реалізує бізнес-логіку застосунку, сценарій повинен завершуватися разом з дочірнім процесом. Це забезпечує перезапуск контейнера застосунку, коли процес, що реалізує бізнес-логіку застосунку, зазнає збою.

Тестування на доступність

Налаштування вашого застосунку на перезапуск збійних процесів це ще не все, щоб забезпечити справність розподіленої системи. Існують сценарії, коли процеси системи можуть бути живими, але недоступними або інакше несправними. Вам слід використовувати проби на доступність, щоб повідомити Kubernetes про те, що процеси вашого застосунку є несправними, і його слід перезапустити.

Шаблон Pod для StatefulSet zk визначає пробу на доступність.

  livenessProbe:
    exec:
      command:
      - sh
      - -c
      - "zookeeper-ready 2181"
    initialDelaySeconds: 15
    timeoutSeconds: 5

Проба викликає скрипт bash, який використовує чотирилітерне слово ruok ZooKeeper для перевірки стану справності сервера.

OK=$(echo ruok | nc 127.0.0.1 $1)
if [ "$OK" == "imok" ]; then
    exit 0
else
    exit 1
fi

У одному вікні термінала використовуйте наступну команду, щоб спостерігати за подами у StatefulSet zk.

kubectl get pod -w -l app=zk

У іншому вікні, використовуйте наступну команду, щоб видалити скрипт zookeeper-ready з файлової системи Podʼа zk-0.

kubectl exec zk-0 -- rm /opt/zookeeper/bin/zookeeper-ready

Коли проба на доступність для процесу ZooKeeper невдала, Kubernetes автоматично перезапустить процес за вас, забезпечуючи тим самим перезапуск несправних процесів у наборі.

kubectl get pod -w -l app=zk
NAME      READY     STATUS    RESTARTS   AGE
zk-0      1/1       Running   0          1h
zk-1      1/1       Running   0          1h
zk-2      1/1       Running   0          1h
NAME      READY     STATUS    RESTARTS   AGE
zk-0      0/1       Running   0          1h
zk-0      0/1       Running   1         1h
zk-0      1/1       Running   1         1h

Тестування готовності

Готовність не те саме, що і доступність. Якщо процес живий, він запланований і справний. Якщо процес готовий, він може обробляти вхідні дані. Доступність є необхідною, але не достатньою, умовою для готовності. Є випадки, особливо під час ініціалізації та завершення, коли процес може бути доступним, але не готовим.

Якщо ви вказуєте пробу на готовність, Kubernetes буде переконуватися, що процеси вашого застосунку не отримуватимуть мережевого трафіку до тих пір, поки їхні перевірки готовності не пройдуть.

Для сервера ZooKeeper, доступність означає готовність. Тому проба готовності з маніфесту zookeeper.yaml ідентична пробі на доступність.

  readinessProbe:
    exec:
      command:
      - sh
      - -c
      - "zookeeper-ready 2181"
    initialDelaySeconds: 15
    timeoutSeconds: 5

Навіть якщо проби на доступність та готовність ідентичні, важливо вказати обидві. Це забезпечує, що мережевий трафік отримуватимуть лише справні сервери в ансамблі ZooKeeper.

Толерантність до відмов вузлів

Для успішного збереження змін даних ZooKeeper потрібен кворум серверів. Для ансамблю з трьох серверів, два сервери повинні бути справними, щоб записи вдалися. У системах на основі кворуму учасники розгорнені в областях відмов для забезпечення доступності. Щоб уникнути перебоїв через втрату окремої машини, найкращі практики виключають спільне розташування кількох екземплярів застосунку на одній машині.

Станадартно Kubernetes може розміщувати Podʼи в StatefulSet на тому ж вузлі. Для створеного вами ансамблю з трьох серверів, якщо два сервери знаходяться на тому ж вузлі, і цей вузол виходить з ладу, клієнти вашої служби ZooKeeper зазнають перебою, поки хоча б один з Podʼів не буде перепланований.

Ви завжди повинні надавати додаткові можливості для перепланування процесів критичних систем у разі відмови вузла. Якщо ви це зробите, перерва буде тривати лише до тих пір, поки планувальник Kubernetes перепланує один з серверів ZooKeeper. Однак, якщо ви хочете, щоб ваша служба терпіла відмови вузлів без перебою роботи, вам слід встановити podAntiAffinity.

Використовуйте наведену нижче команду, щоб отримати вузли для Podʼів у StatefulSet zk.

for i in 0 1 2; do kubectl get pod zk-$i --template={{.spec.nodeName}}; echo ""; done

Всі Podʼи у StatefulSet zk розгорнуті на різних вузлах.

kubernetes-node-cxpk
kubernetes-node-a5aq
kubernetes-node-2g2d

Це через те, що у Podʼах у StatefulSet zk вказано PodAntiAffinity.

affinity:
  podAntiAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
            - key: "app"
              operator: In
              values:
                - zk
        topologyKey: "kubernetes.io/hostname"

Поле requiredDuringSchedulingIgnoredDuringExecution говорить планувальнику Kubernetes, що він ніколи не повинен розміщувати два Podʼи з міткою app як zk у домені, визначеному за допомогою topologyKey. Ключ topologyKey kubernetes.io/hostname вказує, що домен — це окремий вузол. Використовуючи різні правила, мітки та селектори, ви можете розширити цей метод, щоб розподілити свій ансамбль на фізичні, мережеві та домени відмов.

Виживання під час обслуговування

У цьому розділі ви здійсните блокування та виведення вузлів для обслуговування. Якщо ви використовуєте цей посібник на спільному кластері, переконайтеся, що це не позначиться негативно на інших мешканцях.

Попередній розділ показав, як розподілити ваші Podʼи по вузлах, щоб вижити в разі непередбачуваних відмов вузлів, але вам також потрібно планувати тимчасові відмови вузлів, які виникають через заплановане обслуговування.

Використайте цю команду, щоб отримати вузли у вашому кластері.

kubectl get nodes

У цьому посібнику передбачається наявність кластера з щонайменше чотирма вузлами. Якщо в кластері є більше чотирьох вузлів, використовуйте kubectl cordon, щоб заборонити доступ до всіх вузлів, окрім чотирьох. Обмеження до чотирьох вузлів гарантуватиме, що Kubernetes врахує обмеження подібності та PodDisruptionBudget при плануванні Podʼів zookeeper у наступній симуляції обслуговування.

kubectl cordon <імʼя-вузла>

Використайте цю команду, щоб отримати zk-pdb PodDisruptionBudget.

kubectl get pdb zk-pdb

Поле max-unavailable показує Kubernetes, що в будь-який момент може бути недоступний найбільше один Pod з StatefulSet zk.

NAME      MIN-AVAILABLE   MAX-UNAVAILABLE   ALLOWED-DISRUPTIONS   AGE
zk-pdb    N/A             1                 1

У одному терміналі використовуйте цю команду, щоб переглядати Podʼи у StatefulSet zk.

kubectl get pods -w -l app=zk

У іншому терміналі використовуйте цю команду, щоб отримати вузли, на яких наразі заплановані Podʼи.

for i in 0 1 2; do kubectl get pod zk-$i --template {{.spec.nodeName}}; echo ""; done

Вихідна інформація подібна до наступної:

kubernetes-node-pb41
kubernetes-node-ixsl
kubernetes-node-i4c4

Використовуйте kubectl drain, щоб заблокувати та вивести з використання вузол, на якому запланований Pod zk-0.

kubectl drain $(kubectl get pod zk-0 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-emptydir-data

Вихідна інформація подібна до наступної:

node "kubernetes-node-pb41" cordoned

WARNING: Deleting pods not managed by ReplicationController, ReplicaSet, Job, or DaemonSet: fluentd-cloud-logging-kubernetes-node-pb41, kube-proxy-kubernetes-node-pb41; Ignoring DaemonSet-managed pods: node-problem-detector-v0.1-o5elz
pod "zk-0" deleted
node "kubernetes-node-pb41" drained

Оскільки у вашому кластері є чотири вузла, команда kubectl drain успішно виконується, і zk-0 перепланований на інший вузол.

NAME      READY     STATUS    RESTARTS   AGE
zk-0      1/1       Running   2          1h
zk-1      1/1       Running   0          1h
zk-2      1/1       Running   0          1h
NAME      READY     STATUS        RESTARTS   AGE
zk-0      1/1       Terminating   2          2h
zk-0      0/1       Terminating   2         2h
zk-0      0/1       Terminating   2         2h
zk-0      0/1       Terminating   2         2h
zk-0      0/1       Pending   0         0s
zk-0      0/1       Pending   0         0s
zk-0      0/1       ContainerCreating   0         0s
zk-0      0/1       Running   0         51s
zk-0      1/1       Running   0         1m

Продовжуйте слідкувати за Podʼами StatefulSet у першому терміналі і виведіть вузол, на якому запланований zk-1.

kubectl drain $(kubectl get pod zk-1 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-emptydir-data

Вихідна інформація подібна до наступної:

"kubernetes-node-ixsl" cordoned
WARNING: Deleting pods not managed by ReplicationController, ReplicaSet, Job, or DaemonSet: fluentd-cloud-logging-kubernetes-node-ixsl, kube-proxy-kubernetes-node-ixsl; Ignoring DaemonSet-managed pods: node-problem-detector-v0.1-voc74
pod "zk-1" deleted
node "kubernetes-node-ixsl" drained

Pod zk-1 не може бути перепланований, оскільки StatefulSet zk містить правило PodAntiAffinity, яке запобігає спільному розташуванню Podʼів, і так як доступні тільки два вузла, Pod залишиться в стані очікування.

kubectl get pods -w -l app=zk

Вихідна інформація подібна до наступної:

NAME      READY     STATUS    RESTARTS   AGE
zk-0      1/1       Running   2          1h
zk-1      1/1       Running   0          1h
zk-2      1/1       Running   0          1h
NAME      READY     STATUS        RESTARTS   AGE
zk-0      1/1       Terminating   2          2h
zk-0      0/1       Terminating   2         2h
zk-0      0/1       Terminating   2         2h
zk-0      0/1       Terminating   2         2h
zk-0      0/1       Pending   0         0s
zk-0      0/1       Pending   0         0s
zk-0      0/1       ContainerCreating   0         0s
zk-0      0/1       Running   0         51s
zk-0      1/1       Running   0         1m
zk-1      1/1       Terminating   0         2h
zk-1      0/1       Terminating   0         2h
zk-1      0/1       Terminating   0         2h
zk-1      0/1       Terminating   0         2h
zk-1      0/1       Pending   0         0s
zk-1      0/1       Pending   0         0s

Продовжуйте слідкувати за Podʼами StatefulSet, і виведіть з використання вузол, на якому запланований zk-2.

kubectl drain $(kubectl get pod zk-2 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-emptydir-data

Вихідна інформація подібна до наступної:

node "kubernetes-node-i4c4" cordoned

WARNING: Deleting pods not managed by ReplicationController, ReplicaSet, Job, or DaemonSet: fluentd-cloud-logging-kubernetes-node-i4c4, kube-proxy-kubernetes-node-i4c4; Ignoring DaemonSet-managed pods: node-problem-detector-v0.1-dyrog
WARNING: Ignoring DaemonSet-managed pods: node-problem-detector-v0.1-dyrog; Deleting pods not managed by ReplicationController, ReplicaSet, Job, or DaemonSet: fluentd-cloud-logging-kubernetes-node-i4c4, kube-proxy-kubernetes-node-i4c4
There are pending pods when an error occurred: Cannot evict pod as it would violate the pod's disruption budget.
pod/zk-2

Використовуйте CTRL-C для припинення роботи kubectl.

Ви не можете вивести з роботи третій вузол, оскільки zk-2 буде порушувати zk-budget. Однак, вузол залишатиметься заблокованим (cordoned).

Використовуйте zkCli.sh для отримання значень введених впродовж перевірки адекватності zk-0.

kubectl exec zk-0 zkCli.sh get /hello

Service все ще доступний, оскільки його PodDisruptionBudget не порушено.

WatchedEvent state:SyncConnected type:None path:null
world
cZxid = 0x200000002
ctime = Wed Dec 07 00:08:59 UTC 2016
mZxid = 0x200000002
mtime = Wed Dec 07 00:08:59 UTC 2016
pZxid = 0x200000002
cversion = 0
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 5
numChildren = 0

Використовуйте kubectl uncordon, щоб розблокувати вузол.

kubectl uncordon kubernetes-node-pb41

Вивід буде подібний до наступного:

node "kubernetes-node-pb41" uncordoned

zk-1 переплановано на цей вузол. Зачекайте доки zk-1 не буде Running та Ready.

kubectl get pods -w -l app=zk

Вивід буде подібний до наступного:

NAME      READY     STATUS    RESTARTS   AGE
zk-0      1/1       Running   2          1h
zk-1      1/1       Running   0          1h
zk-2      1/1       Running   0          1h
NAME      READY     STATUS        RESTARTS   AGE
zk-0      1/1       Terminating   2          2h
zk-0      0/1       Terminating   2         2h
zk-0      0/1       Terminating   2         2h
zk-0      0/1       Terminating   2         2h
zk-0      0/1       Pending   0         0s
zk-0      0/1       Pending   0         0s
zk-0      0/1       ContainerCreating   0         0s
zk-0      0/1       Running   0         51s
zk-0      1/1       Running   0         1m
zk-1      1/1       Terminating   0         2h
zk-1      0/1       Terminating   0         2h
zk-1      0/1       Terminating   0         2h
zk-1      0/1       Terminating   0         2h
zk-1      0/1       Pending   0         0s
zk-1      0/1       Pending   0         0s
zk-1      0/1       Pending   0         12m
zk-1      0/1       ContainerCreating   0         12m
zk-1      0/1       Running   0         13m
zk-1      1/1       Running   0         13m

Спробуйте вивести вузол з обслуговування на якмоу запланований zk-2.

kubectl drain $(kubectl get pod zk-2 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-emptydir-data

Вивід буде подібний до наступного:

node "kubernetes-node-i4c4" already cordoned
WARNING: Deleting pods not managed by ReplicationController, ReplicaSet, Job, or DaemonSet: fluentd-cloud-logging-kubernetes-node-i4c4, kube-proxy-kubernetes-node-i4c4; Ignoring DaemonSet-managed pods: node-problem-detector-v0.1-dyrog
pod "heapster-v1.2.0-2604621511-wht1r" deleted
pod "zk-2" deleted
node "kubernetes-node-i4c4" drained

На цей раз kubectl drain успішно виконується.

Розблокуйте другий вузол, щоб дозволити перепланування zk-2.

kubectl uncordon kubernetes-node-ixsl

Вивід буде подібний до наступного:

node "kubernetes-node-ixsl" uncordoned

Ви можете використовувати kubectl drain разом з PodDisruptionBudgets, щоб забезпечити доступність ваших служб під час обслуговування. Якщо drain використовується для блокування вузлів та видалення Podʼів до виключення вузла з експлуатації для обслуговування, служби, які виражають бюджет відмов, мають поважати цей бюджет . Ви завжди повинні виділяти додаткову потужність для критичних служб, щоб їх Podʼи могли негайно бути переплановані.

Очищення

  • Використайте kubectl uncordon, щоб розблокувати всі вузли у вашому кластері.
  • Ви повинні видалити носії постійного носія для PersistentVolumes, використаних у цьому посібнику. Дотримуйтеся необхідних кроків, залежно від вашого середовища, конфігурації зберігання та методу надання послуг, щоб переконатися, що всі збережені дані вилучено.

5.7 - Services

5.7.1 - Підключення застосунків за допомогою Service

Модель Kubernetes для підключення контейнерів

Тепер, коли у вас є постійно працюючий, реплікований застосунок, ви можете дати до нього доступ з мережі.

Kubernetes передбачає, що кожен з Podʼів може спілкуватися з іншими, незалежно від того, на якому хості вони опиняються. Kubernetes надає кожному Podʼу власну IP-адресу, що є приватною адресою кластера, тому вам не потрібно явно створювати посилання між Podʼами або перенаправляти порти контейнера на порти хосту. Це означає, що контейнери всередині Podʼів можуть звертатися до портів один одного на localhost, і всі Podʼи в кластері можуть бачити один одного без NAT. У решті цього документа розглянуто, як ви можете запустити надійні сервіси на такій мережевій моделі.

У цьому посібнику використовується простий вебсервер nginx для демонстрації концепції.

Експонування Podʼів в кластер

Ми робили це в попередньому прикладі, але зробимо це ще раз і зосередимося на перспективі мережі. Створіть Pod nginx, і зверніть увагу, що він має специфікацію порту контейнера:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
spec:
  selector:
    matchLabels:
      run: my-nginx
  replicas: 2
  template:
    metadata:
      labels:
        run: my-nginx
    spec:
      containers:
      - name: my-nginx
        image: nginx
        ports:
        - containerPort: 80

Це робить його доступним з будь-якого вузла у вашому кластері. Перевірте вузли, на яких працює Pod:

kubectl apply -f ./run-my-nginx.yaml
kubectl get pods -l run=my-nginx -o wide
NAME                        READY     STATUS    RESTARTS   AGE       IP            NODE
my-nginx-3800858182-jr4a2   1/1       Running   0          13s       10.244.3.4    kubernetes-minion-905m
my-nginx-3800858182-kna2y   1/1       Running   0          13s       10.244.2.5    kubernetes-minion-ljyd

Перевірте IP-адреси ваших Podʼів:

kubectl get pods -l run=my-nginx -o custom-columns=POD_IP:.status.podIPs
    POD_IP
    [map[ip:10.244.3.4]]
    [map[ip:10.244.2.5]]

Ви повинні мати можливість увійти у будь-який вузол у своєму кластері за допомогою SSH і використовувати інструмент, такий як curl, щоб робити запити до обох IP-адрес. Зверніть увагу, що контейнери не використовують порт 80 на вузлі, і немає жодних спеціальних правил NAT для маршрутизації трафіку до Podʼів. Це означає, що ви можете запустити кілька Podʼів nginx на одному й тому ж вузлі, використовуючи той же containerPort, і отримувати доступ до них з будь-якого іншого Podʼа або вузла у вашому кластері, використовуючи призначену IP адресу Podʼа. Якщо ви хочете організувати перенаправлення певного порту на хості Вузла на резервні Podʼи, ви можете це зробити — але модель мережі повинна передбачати, що вам не потрібно цього робити.

Ви можете прочитати більше про Модель мережі Kubernetes якщо вас це цікавить.

Створення Service

Отже, у нас є Podʼи, що працюють з nginx у плоскому адресному просторі, доступному для всього кластера. Теоретично, ви можете звертатися до цих Podʼів безпосередньо, але що станеться, коли вузол вийде з ладу? Podʼи загинуть разом з ним, і ReplicaSet всередині Deployment створить нові, з іншими IP-адресами. Це проблема, яку вирішує Service.

Service Kubernetes — це абстракція, яка визначає логічний набір Podʼів, що працюють десь у вашому кластері, і всі надають однакову функціональність. Коли створюється Service, йому призначається унікальна IP-адреса (яку називають clusterIP). Ця адреса привʼязана до тривалості життя Service і не змінюється, поки Service живий. Podʼи можуть бути налаштовані для звернення до Service і знати, що звʼязок з Service буде автоматично балансуватися на деякий Pod, що є членом Service.

Ви можете створити Service для ваших двох реплік nginx за допомогою kubectl expose:

kubectl expose deployment/my-nginx
service/my-nginx exposed

Це еквівалентно kubectl apply -f наступного yaml:

apiVersion: v1
kind: Service
metadata:
  name: my-nginx
  labels:
    run: my-nginx
spec:
  ports:
  - port: 80
    protocol: TCP
  selector:
    run: my-nginx

Ця специфікація створить Service, який буде спрямований на TCP порт 80 на будь-якому Podʼі з міткою run: my-nginx і відкриє його на абстрактному порті Service (targetPort: це порт, на якому контейнер приймає трафік, port — це абстрактний порт Service, який може бути будь-яким портом, що використовується іншими Podʼами для доступу до Service). Перегляньте Service API обʼєкт, щоб побачити список підтримуваних полів у визначенні Service. Перевірте ваш Service:

kubectl get svc my-nginx
NAME       TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE
my-nginx   ClusterIP   10.0.162.149   <none>        80/TCP    21s

Як згадувалося раніше, Service підтримується групою Podʼів. Ці Podʼи експонуються через EndpointSlices. Селектор Service буде оцінюватися безперервно, і результати будуть надсилатися у EndpointSlice, який підключений до Service за допомогою мітки. Коли Pod припиняє існування, він автоматично видаляється з EndpointSlices, який містить його як точку доступу. Нові Podʼи, що відповідають селектору Service, автоматично додаються до EndpointSlice для цього Service. Перевірте точки доступу та зауважте, що IP-адреси збігаються з Podʼами, створеними на першому кроці:

kubectl describe svc my-nginx
Name:                my-nginx
Namespace:           default
Labels:              run=my-nginx
Annotations:         <none>
Selector:            run=my-nginx
Type:                ClusterIP
IP Family Policy:    SingleStack
IP Families:         IPv4
IP:                  10.0.162.149
IPs:                 10.0.162.149
Port:                <unset> 80/TCP
TargetPort:          80/TCP
Endpoints:           10.244.2.5:80,10.244.3.4:80
Session Affinity:    None
Events:              <none>
kubectl get endpointslices -l kubernetes.io/service-name=my-nginx
NAME             ADDRESSTYPE   PORTS   ENDPOINTS               AGE
my-nginx-7vzhx   IPv4          80      10.244.2.5,10.244.3.4   21s

Тепер ви повинні бути в змозі звертатися до nginx Service на <CLUSTER-IP>:<PORT> з будь-якого вузла у вашому кластері. Зауважте, що IP-адреса Service є повністю віртуальною, вона ніколи не передається мережею. Якщо вам цікаво, як це працює, ви можете прочитати більше про сервіс-проксі.

Доступ до Service

Kubernetes підтримує два основні режими знаходження Service — змінні середовища та DNS. Перший режим працює "з коробки", тоді як другий вимагає додаткового модуля CoreDNS cluster addon.

Змінні середовища

Коли Pod запускається на вузлі, kubelet додає набір змінних середовища для кожного активного Service. Це створює проблему з порядком. Щоб зрозуміти чому, перевірте середовище вашого працюючого Pod nginx (назва вашого Pod буде іншою):

kubectl exec my-nginx-3800858182-jr4a2 -- printenv | grep SERVICE
KUBERNETES_SERVICE_HOST=10.0.0.1
KUBERNETES_SERVICE_PORT=443
KUBERNETES_SERVICE_PORT_HTTPS=443

Зверніть увагу, що ваш Service не згадується. Це тому, що ви створили репліки перед створенням Service. Іншим недоліком цього є те, що планувальник може розмістити обидва Podʼи на одній машині, що призведе до припинення роботи всього Service, якщо він вийде з ладу. Ми можемо зробити це прям зараз, видаливши 2 Podʼи та очікуючи, поки Deployment їх відновить. Цього разу Service існує до реплік. Це забезпечить рівномірний розподіл ваших Podʼів на рівні планувальника (за умови рівної потужності всіх вузлів), а також правильні змінні середовища:

kubectl scale deployment my-nginx --replicas=0; kubectl scale deployment my-nginx --replicas=2;

kubectl get pods -l run=my-nginx -o wide
NAME                        READY     STATUS    RESTARTS   AGE     IP            NODE
my-nginx-3800858182-e9ihh   1/1       Running   0          5s      10.244.2.7    kubernetes-minion-ljyd
my-nginx-3800858182-j4rm4   1/1       Running   0          5s      10.244.3.8    kubernetes-minion-905m

Ви можете помітити, що Podʼи мають різні імена, оскільки вони були видалені та відтворені.

kubectl exec my-nginx-3800858182-e9ihh -- printenv | grep SERVICE
KUBERNETES_SERVICE_PORT=443
MY_NGINX_SERVICE_HOST=10.0.162.149
KUBERNETES_SERVICE_HOST=10.0.0.1
MY_NGINX_SERVICE_PORT=80
KUBERNETES_SERVICE_PORT_HTTPS=443

DNS

Kubernetes пропонує DNS-сервіс, який автоматично призначає DNS-імена іншим Serviceʼам. Ви можете перевірити, чи він працює у вашому кластері:

kubectl get services kube-dns --namespace=kube-system
NAME       TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)         AGE
kube-dns   ClusterIP   10.0.0.10    <none>        53/UDP,53/TCP   8m

Далі в цьому розділі ми будемо вважати, що у вас є Service із довготривалою IP-адресою (my-nginx), і DNS-сервер, який присвоїв цій IP-адресі імʼя. Ми використовуємо надбудову CoreDNS (назва застосунку kube-dns), тому ви можете звертатися до Service з будь-якого Pod у вашому кластері, використовуючи стандартні методи (наприклад, gethostbyname()). Якщо CoreDNS не працює, ви можете увімкнути його, звірившись з README CoreDNS або інформацією з Встановлення CoreDNS. Запустімо ще один застосунок curl для перевірки цього:

kubectl run curl --image=radial/busyboxplus:curl -i --tty --rm
Waiting for pod default/curl-131556218-9fnch to be running, status is Pending, pod ready: false
Hit enter for command prompt

Потім натисніть Enter і запустіть nslookup my-nginx:

[ root@curl-131556218-9fnch:/ ]$ nslookup my-nginx
Server:    10.0.0.10
Address 1: 10.0.0.10

Name:      my-nginx
Address 1: 10.0.162.149

Захист Service

До цього моменту ми отримували доступ до сервера nginx лише всередині кластеру. Перед тим як виставити Service в Інтернет, вам потрібно переконатися, що канал звʼязку захищений. Для цього вам знадобиться:

  • Самопідписні сертифікати для https (якщо у вас немає ідентифікаційного сертифіката)
  • Сервер nginx, налаштований для використання сертифікатів
  • Secret, що робить сертифікати доступними для Pod

Ви можете отримати все це з прикладу nginx https. Це вимагає встановлення інструментів go та make. Якщо ви не хочете їх встановлювати, тоді дотримуйтесь ручних кроків, описаних нижче. Коротко:

make keys KEY=/tmp/nginx.key CERT=/tmp/nginx.crt
kubectl create secret tls nginxsecret --key /tmp/nginx.key --cert /tmp/nginx.crt
secret/nginxsecret created
kubectl get secrets
NAME                  TYPE                                  DATA      AGE
nginxsecret           kubernetes.io/tls                     2         1m

А також configmap:

kubectl create configmap nginxconfigmap --from-file=default.conf

Ви можете знайти приклад default.conf у репозиторії прикладів Kubernetes.

configmap/nginxconfigmap created
kubectl get configmaps
NAME             DATA   AGE
nginxconfigmap   1      114s

Ви можете переглянути деталі ConfigMap nginxconfigmap, використовуючи наступну команду:

kubectl describe configmap nginxconfigmap

Вихід буде схожим на:

Name:         nginxconfigmap
Namespace:    default
Labels:       <none>
Annotations:  <none>

Data
====
default.conf:
----
server {
        listen 80 default_server;
        listen [::]:80 default_server ipv6only=on;

        listen 443 ssl;

        root /usr/share/nginx/html;
        index index.html;

        server_name localhost;
        ssl_certificate /etc/nginx/ssl/tls.crt;
        ssl_certificate_key /etc/nginx/ssl/tls.key;

        location / {
                try_files $uri $uri/ =404;
        }
}

BinaryData
====

Events:  <none>

Ось ручні кроки, яких слід дотримуватись у випадку, якщо у вас виникли проблеми з запуском make (наприклад, у Windows):

# Створіть пару відкритий/закритий ключ
openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /d/tmp/nginx.key -out /d/tmp/nginx.crt -subj "/CN=my-nginx/O=my-nginx"
# Перетворіть ключі у кодування base64
cat /d/tmp/nginx.key | base64
cat /d/tmp/nginx.crt | base64

Скористайтесь виводом з попередньої команди для створення yaml-файлу. Закодовані у base64 значення мають бути в одному рядку.

apiVersion: "v1"
kind: "Secret"
metadata:
  name: "nginxsecret"
  namespace: "default"
type: kubernetes.io/tls
data:
  tls.crt: "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURIekNDQWdlZ0F3SUJBZ0lKQUp5M3lQK0pzMlpJTUEwR0NTcUdTSWIzRFFFQkJRVUFNQ1l4RVRBUEJnTlYKQkFNVENHNW5hVzU0YzNaak1SRXdEd1lEVlFRS0V3aHVaMmx1ZUhOMll6QWVGdzB4TnpFd01qWXdOekEzTVRKYQpGdzB4T0RFd01qWXdOekEzTVRKYU1DWXhFVEFQQmdOVkJBTVRDRzVuYVc1NGMzWmpNUkV3RHdZRFZRUUtFd2h1CloybHVlSE4yWXpDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBSjFxSU1SOVdWM0IKMlZIQlRMRmtobDRONXljMEJxYUhIQktMSnJMcy8vdzZhU3hRS29GbHlJSU94NGUrMlN5ajBFcndCLzlYTnBwbQppeW1CL3JkRldkOXg5UWhBQUxCZkVaTmNiV3NsTVFVcnhBZW50VWt1dk1vLzgvMHRpbGhjc3paenJEYVJ4NEo5Ci82UVRtVVI3a0ZTWUpOWTVQZkR3cGc3dlVvaDZmZ1Voam92VG42eHNVR0M2QURVODBpNXFlZWhNeVI1N2lmU2YKNHZpaXdIY3hnL3lZR1JBRS9mRTRqakxCdmdONjc2SU90S01rZXV3R0ljNDFhd05tNnNTSzRqYUNGeGpYSnZaZQp2by9kTlEybHhHWCtKT2l3SEhXbXNhdGp4WTRaNVk3R1ZoK0QrWnYvcW1mMFgvbVY0Rmo1NzV3ajFMWVBocWtsCmdhSXZYRyt4U1FVQ0F3RUFBYU5RTUU0d0hRWURWUjBPQkJZRUZPNG9OWkI3YXc1OUlsYkROMzhIYkduYnhFVjcKTUI4R0ExVWRJd1FZTUJhQUZPNG9OWkI3YXc1OUlsYkROMzhIYkduYnhFVjdNQXdHQTFVZEV3UUZNQU1CQWY4dwpEUVlKS29aSWh2Y05BUUVGQlFBRGdnRUJBRVhTMW9FU0lFaXdyMDhWcVA0K2NwTHI3TW5FMTducDBvMm14alFvCjRGb0RvRjdRZnZqeE04Tzd2TjB0clcxb2pGSW0vWDE4ZnZaL3k4ZzVaWG40Vm8zc3hKVmRBcStNZC9jTStzUGEKNmJjTkNUekZqeFpUV0UrKzE5NS9zb2dmOUZ3VDVDK3U2Q3B5N0M3MTZvUXRUakViV05VdEt4cXI0Nk1OZWNCMApwRFhWZmdWQTRadkR4NFo3S2RiZDY5eXM3OVFHYmg5ZW1PZ05NZFlsSUswSGt0ejF5WU4vbVpmK3FqTkJqbWZjCkNnMnlwbGQ0Wi8rUUNQZjl3SkoybFIrY2FnT0R4elBWcGxNSEcybzgvTHFDdnh6elZPUDUxeXdLZEtxaUMwSVEKQ0I5T2wwWW5scE9UNEh1b2hSUzBPOStlMm9KdFZsNUIyczRpbDlhZ3RTVXFxUlU9Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K"
  tls.key: "LS0tLS1CRUdJTiBQUklWQVRFIEtFWS0tLS0tCk1JSUV2UUlCQURBTkJna3Foa2lHOXcwQkFRRUZBQVNDQktjd2dnU2pBZ0VBQW9JQkFRQ2RhaURFZlZsZHdkbFIKd1V5eFpJWmVEZWNuTkFhbWh4d1NpeWF5N1AvOE9ta3NVQ3FCWmNpQ0RzZUh2dGtzbzlCSzhBZi9WemFhWm9zcApnZjYzUlZuZmNmVUlRQUN3WHhHVFhHMXJKVEVGSzhRSHA3VkpMcnpLUC9QOUxZcFlYTE0yYzZ3MmtjZUNmZitrCkU1bEVlNUJVbUNUV09UM3c4S1lPNzFLSWVuNEZJWTZMMDUrc2JGQmd1Z0ExUE5JdWFubm9UTWtlZTRuMG4rTDQKb3NCM01ZUDhtQmtRQlAzeE9JNHl3YjREZXUraURyU2pKSHJzQmlIT05Xc0RadXJFaXVJMmdoY1kxeWIyWHI2UAozVFVOcGNSbC9pVG9zQngxcHJHclk4V09HZVdPeGxZZmcvbWIvNnBuOUYvNWxlQlkrZStjSTlTMkQ0YXBKWUdpCkwxeHZzVWtGQWdNQkFBRUNnZ0VBZFhCK0xkbk8ySElOTGo5bWRsb25IUGlHWWVzZ294RGQwci9hQ1Zkank4dlEKTjIwL3FQWkUxek1yall6Ry9kVGhTMmMwc0QxaTBXSjdwR1lGb0xtdXlWTjltY0FXUTM5SjM0VHZaU2FFSWZWNgo5TE1jUHhNTmFsNjRLMFRVbUFQZytGam9QSFlhUUxLOERLOUtnNXNrSE5pOWNzMlY5ckd6VWlVZWtBL0RBUlBTClI3L2ZjUFBacDRuRWVBZmI3WTk1R1llb1p5V21SU3VKdlNyblBESGtUdW1vVlVWdkxMRHRzaG9reUxiTWVtN3oKMmJzVmpwSW1GTHJqbGtmQXlpNHg0WjJrV3YyMFRrdWtsZU1jaVlMbjk4QWxiRi9DSmRLM3QraTRoMTVlR2ZQegpoTnh3bk9QdlVTaDR2Q0o3c2Q5TmtEUGJvS2JneVVHOXBYamZhRGR2UVFLQmdRRFFLM01nUkhkQ1pKNVFqZWFKClFGdXF4cHdnNzhZTjQyL1NwenlUYmtGcVFoQWtyczJxWGx1MDZBRzhrZzIzQkswaHkzaE9zSGgxcXRVK3NHZVAKOWRERHBsUWV0ODZsY2FlR3hoc0V0L1R6cEdtNGFKSm5oNzVVaTVGZk9QTDhPTm1FZ3MxMVRhUldhNzZxelRyMgphRlpjQ2pWV1g0YnRSTHVwSkgrMjZnY0FhUUtCZ1FEQmxVSUUzTnNVOFBBZEYvL25sQVB5VWs1T3lDdWc3dmVyClUycXlrdXFzYnBkSi9hODViT1JhM05IVmpVM25uRGpHVHBWaE9JeXg5TEFrc2RwZEFjVmxvcG9HODhXYk9lMTAKMUdqbnkySmdDK3JVWUZiRGtpUGx1K09IYnRnOXFYcGJMSHBzUVpsMGhucDBYSFNYVm9CMUliQndnMGEyOFVadApCbFBtWmc2d1BRS0JnRHVIUVV2SDZHYTNDVUsxNFdmOFhIcFFnMU16M2VvWTBPQm5iSDRvZUZKZmcraEppSXlnCm9RN3hqWldVR3BIc3AyblRtcHErQWlSNzdyRVhsdlhtOElVU2FsbkNiRGlKY01Pc29RdFBZNS9NczJMRm5LQTQKaENmL0pWb2FtZm1nZEN0ZGtFMXNINE9MR2lJVHdEbTRpb0dWZGIwMllnbzFyb2htNUpLMUI3MkpBb0dBUW01UQpHNDhXOTVhL0w1eSt5dCsyZ3YvUHM2VnBvMjZlTzRNQ3lJazJVem9ZWE9IYnNkODJkaC8xT2sybGdHZlI2K3VuCnc1YytZUXRSTHlhQmd3MUtpbGhFZDBKTWU3cGpUSVpnQWJ0LzVPbnlDak9OVXN2aDJjS2lrQ1Z2dTZsZlBjNkQKckliT2ZIaHhxV0RZK2Q1TGN1YSt2NzJ0RkxhenJsSlBsRzlOZHhrQ2dZRUF5elIzT3UyMDNRVVV6bUlCRkwzZAp4Wm5XZ0JLSEo3TnNxcGFWb2RjL0d5aGVycjFDZzE2MmJaSjJDV2RsZkI0VEdtUjZZdmxTZEFOOFRwUWhFbUtKCnFBLzVzdHdxNWd0WGVLOVJmMWxXK29xNThRNTBxMmk1NVdUTThoSDZhTjlaMTltZ0FGdE5VdGNqQUx2dFYxdEYKWSs4WFJkSHJaRnBIWll2NWkwVW1VbGc9Ci0tLS0tRU5EIFBSSVZBVEUgS0VZLS0tLS0K"

Тепер створіть Secret, застосувавши файл:

kubectl apply -f nginxsecret.yaml
kubectl get secrets
NAME                  TYPE                                  DATA      AGE
nginxsecret           kubernetes.io/tls                     2         1m

Тепер змініть кількість реплік nginx для запуску сервера https використовуючи сертифікати з Secret та Service для експонування портів (80 та 443):

apiVersion: v1
kind: Service
metadata:
  name: my-nginx
  labels:
    run: my-nginx
spec:
  type: NodePort
  ports:
  - port: 8080
    targetPort: 80
    protocol: TCP
    name: http
  - port: 443
    protocol: TCP
    name: https
  selector:
    run: my-nginx
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
spec:
  selector:
    matchLabels:
      run: my-nginx
  replicas: 1
  template:
    metadata:
      labels:
        run: my-nginx
    spec:
      volumes:
      - name: secret-volume
        secret:
          secretName: nginxsecret
      - name: configmap-volume
        configMap:
          name: nginxconfigmap
      containers:
      - name: nginxhttps
        image: bprashanth/nginxhttps:1.0
        ports:
        - containerPort: 443
        - containerPort: 80
        volumeMounts:
        - mountPath: /etc/nginx/ssl
          name: secret-volume
        - mountPath: /etc/nginx/conf.d
          name: configmap-volume

Примітні моменти про маніфест nginx-secure-app:

  • Він містить як специфікацію Deployment, так і Service в одному файлі.
  • nginx сервер обслуговує HTTP трафік на порту 80 та HTTPS трафік на порту 443, і Service nginx відкриває доступ до обох портів.
  • Кожен контейнер має доступ до ключів через том, змонтовану в /etc/nginx/ssl. Це налаштовується до запуску nginx сервера.
kubectl delete deployments,svc my-nginx; kubectl create -f ./nginx-secure-app.yaml

На цьому етапі ви можете отримати доступ до nginx сервера з будь-якого вузла.

kubectl get pods -l run=my-nginx -o custom-columns=POD_IP:.status.podIPs
    POD_IP
    [map[ip:10.244.3.5]]
node $ curl -k https://10.244.3.5
...
<h1>Welcome to nginx!</h1>

Зверніть увагу, що ми використовували параметр -k для curl на останньому етапі, тому що ми нічого не знаємо про Podʼи, що виконують nginx під час генерації сертифіката, тому ми повинні сказати curl ігнорувати невідповідність CName. Створюючи Service, ми повʼязали CName, який використовується в сертифікаті, з фактичним DNS-імʼям, що використовується Podʼами під час пошуку Service. Перевірмо це з Podʼа (для простоти використовується той же Secret, Podʼу потрібен лише nginx.crt для доступу до Service):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: curl-deployment
spec:
  selector:
    matchLabels:
      app: curlpod
  replicas: 1
  template:
    metadata:
      labels:
        app: curlpod
    spec:
      volumes:
      - name: secret-volume
        secret:
          secretName: nginxsecret
      containers:
      - name: curlpod
        command:
        - sh
        - -c
        - while true; do sleep 1; done
        image: radial/busyboxplus:curl
        volumeMounts:
        - mountPath: /etc/nginx/ssl
          name: secret-volume
kubectl apply -f ./curlpod.yaml
kubectl get pods -l app=curlpod
NAME                               READY     STATUS    RESTARTS   AGE
curl-deployment-1515033274-1410r   1/1       Running   0          1m
kubectl exec curl-deployment-1515033274-1410r -- curl https://my-nginx --cacert /etc/nginx/ssl/tls.crt
...
<title>Welcome to nginx!</title>
...

Експонування Service

Для деяких частин ваших застосунків ви можете захотіти експонувати Service на зовнішню IP-адресу. Kubernetes підтримує два способи: NodePorts та LoadBalancers. Service, створений у попередньому розділі, вже використовував NodePort, тому ваша репліка nginx HTTPS готова обслуговувати трафік з інтернету, якщо ваш вузол має публічну IP-адресу.

kubectl get svc my-nginx -o yaml | grep nodePort -C 5
  uid: 07191fb3-f61a-11e5-8ae5-42010af00002
spec:
  clusterIP: 10.0.162.149
  ports:
  - name: http
    nodePort: 31704
    port: 8080
    protocol: TCP
    targetPort: 80
  - name: https
    nodePort: 32453
    port: 443
    protocol: TCP
    targetPort: 443
  selector:
    run: my-nginx
kubectl get nodes -o yaml | grep ExternalIP -C 1
    - address: 104.197.41.11
      type: ExternalIP
    allocatable:
--
    - address: 23.251.152.56
      type: ExternalIP
    allocatable:
...

$ curl https://<EXTERNAL-IP>:<NODE-PORT> -k
...
<h1>Welcome to nginx!</h1>

Тепер створімо Service знову, використовуючи хмарний балансувальник навантаження. Змініть Type Service my-nginx з NodePort на LoadBalancer:

kubectl edit svc my-nginx
kubectl get svc my-nginx
NAME       TYPE           CLUSTER-IP     EXTERNAL-IP        PORT(S)               AGE
my-nginx   LoadBalancer   10.0.162.149   xx.xxx.xxx.xxx     8080:30163/TCP        21s
curl https://<EXTERNAL-IP> -k
...
<title>Welcome to nginx!</title>

IP-адреса в колонці EXTERNAL-IP доступна в інтернеті. CLUSTER-IP доступна тільки всередині вашого кластера/приватної хмарної мережі.

Зверніть увагу, що у AWS тип LoadBalancer створює ELB, який використовує (довге) імʼя хосту, а не IP. Воно занадто довге, щоб поміститися в стандартному виводі kubectl get svc, тому вам потрібно виконати kubectl describe service my-nginx, щоб побачити його. Ви побачите щось на кшталт:

kubectl describe service my-nginx
...
LoadBalancer Ingress:   a320587ffd19711e5a37606cf4a74574-1142138393.us-east-1.elb.amazonaws.com
...

Що далі

5.7.2 - Використання Source IP

Застосунки, що працюють у кластері Kubernetes, знаходять і взаємодіють один з одним та з зовнішнім світом через абстракцію Service. У цьому документі пояснюється, що відбувається з Source IP пакетів, надісланих на різні типи Service, і як ви можете змінити цю поведінку відповідно до ваших потреб.

Перш ніж ви розпочнете

Терміни

У цьому документі використовуються наступні терміни:

NAT
Трансляція мережевих адрес
Source NAT
Заміна Source IP в пакеті; у цьому документі це зазвичай означає заміну на IP-адресу вузла.
Destination NAT
Заміна Destination IP в пакеті; у цьому документі це зазвичай означає заміну на IP-адресу Pod
VIP
Віртуальна IP-адреса, така як та, що призначається кожному Service у Kubernetes
kube-proxy
Мережевий демон, який оркеструє управління віртуальними IP Service на кожному вузлі

Необхідні умови

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

У прикладах використовується невеликий вебсервер nginx, який повертає Source IP запитів, які він отримує через HTTP-заголовок. Ви можете створити його наступним чином:

kubectl create deployment source-ip-app --image=registry.k8s.io/echoserver:1.10

Результат:

deployment.apps/source-ip-app created

Цілі

  • Експонувати простий застосунок через різні типи Serviceʼів
  • Зрозуміти, як кожен тип Services обробляє Source IP NAT
  • Зрозуміти компроміси, повʼязані зі збереженням Source IP

Source IP для Service з Type=ClusterIP

Пакети, надіслані на ClusterIP зсередини кластера, ніколи не обробляються Source NAT, якщо ви використовуєте kube-proxy в iptables mode, (станартно). Ви можете запитати режим kube-proxy, отримавши http://localhost:10249/proxyMode на вузлі, де працює kube-proxy.

kubectl get nodes

Результат схожий на цей:

NAME                           STATUS     ROLES    AGE     VERSION
kubernetes-node-6jst   Ready      <none>   2h      v1.13.0
kubernetes-node-cx31   Ready      <none>   2h      v1.13.0
kubernetes-node-jj1t   Ready      <none>   2h      v1.13.0

Отримати режим проксі на одному з вузлів (kube-proxy слухає на порту 10249):

# Запустіть це в оболонці на вузлі, який хочете запитати.
curl http://localhost:10249/proxyMode

Результат:

iptables

Ви можете протестувати збереження Source IP, створивши Service над source-ip застосунку:

kubectl expose deployment source-ip-app --name=clusterip --port=80 --target-port=8080

Результат:

service/clusterip exposed
kubectl get svc clusterip

Результат схожий на:

NAME         TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)   AGE
clusterip    ClusterIP   10.0.170.92   <none>        80/TCP    51s

І звернутися до ClusterIP з Pod в тому ж кластері:

kubectl run busybox -it --image=busybox:1.28 --restart=Never --rm

Результат схожий на цей:

Waiting for pod default/busybox to be running, status is Pending, pod ready: false
If you don't see a command prompt, try pressing enter.

Ви можете виконати команду всередині цього Pod:

# Запустіть це всередині терміналу "kubectl run"
ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1460 qdisc noqueue
    link/ether 0a:58:0a:f4:03:08 brd ff:ff:ff:ff:ff:ff
    inet 10.244.3.8/24 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::188a:84ff:feb0:26a5/64 scope link
       valid_lft forever preferred_lft forever

…потім використовувати wget для надсилання запиту до локального вебсервера

# Замініть "10.0.170.92" на IPv4-адресу сервісу "clusterip"
wget -qO - 10.0.170.92
CLIENT VALUES:
client_address=10.244.3.8
command=GET
...

client_address завжди є IP-адресою Podʼа-клієнта, незалежно від того, знаходяться Pod-клієнт і Pod-сервер на одному вузлі чи на різних вузлах.

Source IP для Service з Type=NodePort

Пакети, надіслані на Serviceʼи з Type=NodePort, типово обробляються Source NAT. Ви можете протестувати це, створивши Service NodePort:

kubectl expose deployment source-ip-app --name=nodeport --port=80 --target-port=8080 --type=NodePort

Результат:

service/nodeport exposed
NODEPORT=$(kubectl get -o jsonpath="{.spec.ports[0].nodePort}" services nodeport)
NODES=$(kubectl get nodes -o jsonpath='{ $.items[*].status.addresses[?(@.type=="InternalIP")].address }')

Якщо ви працюєте на хмарному провайдері, можливо, вам доведеться відкрити правило брандмауера для nodes:nodeport, зазначеного вище. Тепер ви можете спробувати звернутися до сервісу ззовні кластера через вказаний вище порт вузла.

for node in $NODES; do curl -s $node:$NODEPORT | grep -i client_address; done

Результат схожий на:

client_address=10.180.1.1
client_address=10.240.0.5
client_address=10.240.0.3

Зверніть увагу, що це не правильні IP клієнтів, це внутрішні IP кластера. Це відбувається так:

  • Клієнт надсилає пакет до node2:nodePort
  • node2 замінює Source IP-адресу (SNAT) у пакеті своєю власною IP-адресою
  • node2 замінює Destination IP-адресу пакета на IP Podʼа
  • пакет спрямовується до node 1, а потім до точки доступу
  • відповідь Podʼа спрямовується назад до node2
  • відповідь Podʼа надсилається клієнту

Візуально це виглядає так:

graph LR; client(client)-->node2[Node 2]; node2-->client; node2-. SNAT .->node1[Node 1]; node1-. SNAT .->node2; node1-->endpoint(Endpoint); classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000; classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; class node1,node2,endpoint k8s; class client plain;

Схема. Source IP Type=NodePort з використанням SNAT

Щоб уникнути цього, Kubernetes має функцію зберігати Source IP-адресу клієнта. Якщо ви встановите для service.spec.externalTrafficPolicy значення Local, kube-proxy надсилає проксі-запити лише до локальних точок доступу та не пересилає трафік до інших вузлів. Цей підхід зберігає Source IP-адресу. Якщо немає локальних точок доступу, пакети, надіслані до вузла, відкидаються, тому ви можете покладатися на правильну Source IP-адресу в будь-яких правилах обробки пакетів, які ви можете застосувати до пакета, який проходить до точки доступу.

Встановіть значення поля service.spec.externalTrafficPolicy наступним чином:

kubectl patch svc nodeport -p '{"spec":{"externalTrafficPolicy":"Local"}}'

Вивід має бути наступним:

service/nodeport patched

Повторіть тест:

for node in $NODES; do curl --connect-timeout 1 -s $node:$NODEPORT | grep -i client_address; done

Вивід подібний до:

client_address=198.51.100.79

Зауважте, що ви отримали лише одну відповідь із правильною IP-адресою клієнта від одного вузла, на якому працює Pod точки доступу.

Ось що відбувається:

  • клієнт надсилає пакет на node2:nodePort, який не має кінцевих точок
  • пакет відкидається
  • клієнт надсилає пакет на node1:nodePort, який має точки доступу
  • node1 направляє пакет до точки доступу з правильною Source IP-адресою

Візуально:

graph TD; client(client)-->node1[Node 1]; client(client)-->node2[Node 2]; node1-->endpoint(Endpoint); endpoint(Endpoint)-->node1; classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000; classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; class node1,node2,endpoint k8s; class client plain;
Схема. Source IP Type=NodePort зберігає Source IP клієнта

Source IP для Service з Type=LoadBalancer

Пакети, які надсилаються на Service з Type=LoadBalancer, стандартно мають Source NAT адресацію, оскільки всі можливі для планування вузли Kubernetes у стані Ready мають право на навантаження рівномірного розподілу трафіку. Якщо пакети надходять на вузол без точки доступу, система передає їх на вузол з точкою доступу, замінюючи адресу Source IP на пакеті на IP-адресу вузла (як описано у попередньому розділі).

Ви можете перевірити це, експонувавши застосунок source-ip-app через балансувальник навантаження:

kubectl expose deployment source-ip-app --name=loadbalancer --port=80 --target-port=8080 --type=LoadBalancer

Результат виглядає наступним чином:

service/loadbalancer exposed

Виведіть IP-адреси Service:

kubectl get svc loadbalancer

Вивід подібний наступному:

NAME           TYPE           CLUSTER-IP    EXTERNAL-IP       PORT(S)   AGE
loadbalancer   LoadBalancer   10.0.65.118   203.0.113.140     80/TCP    5m

Потім надішліть запит на зовнішню IP-адресу цього Service:

curl 203.0.113.140

Вивід подібний наступному:

CLIENT VALUES:
client_address=10.240.0.5
...

Однак, якщо ви працюєте на середовищі Google Kubernetes Engine/GCE, встановлення поля service.spec.externalTrafficPolicy на значення Local змушує вузли без точок доступу Service видаляти себе зі списку вузлів, які мають право на рівномірно розподілений трафік, шляхом умисної невдачі перевірок стану.

Візуально:

IP-адреса джерела з externalTrafficPolicy

Ви можете перевірити це, встановивши анотацію:

kubectl patch svc loadbalancer -p '{"spec":{"externalTrafficPolicy":"Local"}}'

Ви повинні негайно побачити, що поле service.spec.healthCheckNodePort виділене Kubernetes:

kubectl get svc loadbalancer -o yaml | grep -i healthCheckNodePort

Вивід подібний наступному:

  healthCheckNodePort: 32122

Поле service.spec.healthCheckNodePort вказує на порт на кожному вузлі, на якому надається перевірка стану за адресою /healthz. Ви можете перевірити це:

kubectl get pod -o wide -l app=source-ip-app

Вивід подібний наступному:

NAME                            READY     STATUS    RESTARTS   AGE       IP             NODE
source-ip-app-826191075-qehz4   1/1       Running   0          20h       10.180.1.136   kubernetes-node-6jst

Використовуйте curl, щоб отримати доступ до точки доступу /healthz на різних вузлах:

# Виконайте це локально на вузлі, який ви вибрали
curl localhost:32122/healthz
1 Service Endpoints found

На іншому вузлі ви можете отримати інший результат:

# Виконайте це локально на вузлі, який ви вибрали
curl localhost:32122/healthz
No Service Endpoints Found

Контролер, який працює на панелі управління відповідає за доступ до хмарного балансувальника навантаження. Той самий контролер також виділяє HTTP перевірки стану, що вказують на цей порт/шлях на кожному вузлі. Зачекайте приблизно 10 секунд, щоб вузли без точок доступу мають невдалі перевірки стану, а потім використовуйте curl, щоб запитати IPv4-адресу балансувальника навантаження:

curl 203.0.113.140

Вивід подібний наступному:

CLIENT VALUES:
client_address=198.51.100.79
...

Міжплатформна підтримка

Тільки деякі хмарні постачальники пропонують підтримку збереження Source IP-адреси через Serviceʼи з Type=LoadBalancer. Хмарний постачальник, на якому ви працюєте, може виконати запит на надання балансувальника навантаження кількома різними способами:

  1. З проксі, що завершує зʼєднання клієнта та відкриває нове зʼєднання з вашими вузлами/точками доступу. У таких випадках Source IP-адреса завжди буде адресою хмарного балансувальника, а не адресою клієнта.

  2. З сервісом пересилання пакетів (forwarder), таким чином, що запити від клієнта, надісліна до VIP балансувальника, потрапляють на вузол з Source IP-адресою клієнта, а не на проміжний проксі.

Балансувальники навантаження у першій категорії повинні використовувати узгоджений протокол між балансувальником навантаження та бекендом для передачі реальної IP-адреси клієнта, такі як HTTP Forwarded або X-FORWARDED-FOR заголовки, або протокол проксі. Балансувальники навантаження у другій категорії можуть використовувати функціонал, описаний вище, створюючи HTTP перевірку стану, що вказує на порт, збережений у полі service.spec.healthCheckNodePort Serviceʼа.

Очищення

Видаліть Serviceʼи:

kubectl delete svc -l app=source-ip-app

Видаліть Deployment, ReplicaSet та Pod:

kubectl delete deployment source-ip-app

Що далі

5.7.3 - Дослідження поведінки завершення роботи для Podʼів та їх точок доступу

Коли ви підʼєднали свій застосунок до Service, дотримуючись кроків, схожих на ті, що описані в Підключення застосунків за допомогою Service, у вас є постійно працюючий, реплікований застосунок, який викритий в мережі. Цей посібник допоможе вам розглянути процес завершення роботи для Podʼів та дослідити способи впровадження належного припинення зʼєднань.

Процес завершення роботи для Podʼів та їх точок доступу

Часто виникають випадки, коли потрібно завершити роботу Podʼа — чи то для оновлення, чи то для зменшення масштабу. Для поліпшення доступності застосунку може бути важливо реалізувати правильне завершення активних зʼєднань.

У цьому посібнику пояснюється процес завершення роботи для Podʼів у звʼязку з відповідним станом точки доступу та видаленням за допомогою простого вебсервера nginx для демонстрації концепції.

Приклад процесу з завершенням роботи точки доступу

Наведений нижче приклад показує описаний у документі Завершення роботи Podʼів процес.

Допустимо, у вас є Deployment, яка складається з одної репліки nginx (для демонстраційних цілей) та Service:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      terminationGracePeriodSeconds: 120 # extra long grace period
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80
        lifecycle:
          preStop:
            exec:
              # Real life termination may take any time up to terminationGracePeriodSeconds.
              # In this example - just hang around for at least the duration of terminationGracePeriodSeconds,
              # at 120 seconds container will be forcibly terminated.
              # Note, all this time nginx will keep processing requests.
              command: [
                "/bin/sh", "-c", "sleep 180"
              ]
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80

Тепер створіть Pod Deployment та Service, використовуючи вищезазначені файли:

kubectl apply -f pod-with-graceful-termination.yaml
kubectl apply -f explore-graceful-termination-nginx.yaml

Після запуску Podʼа та Service ви можете отримати імʼя будь-яких повʼязаних точок доступу:

kubectl get endpointslice

Вивід подібний до цього:

NAME                  ADDRESSTYPE   PORTS   ENDPOINTS                 AGE
nginx-service-6tjbr   IPv4          80      10.12.1.199,10.12.1.201   22m

Ви можете перевірити їх статус та підтвердити, що зареєстровано одну точку доступу:

kubectl get endpointslices -o json -l kubernetes.io/service-name=nginx-service

Вивід подібний до цього:

{
    "addressType": "IPv4",
    "apiVersion": "discovery.k8s.io/v1",
    "endpoints": [
        {
            "addresses": [
                "10.12.1.201"
            ],
            "conditions": {
                "ready": true,
                "serving": true,
                "terminating": false

Тепер завершімо роботу Podʼа та перевіримо, що Pod завершується, дотримуючись налаштувань відповідного періоду завершення роботи:

kubectl delete pod nginx-deployment-7768647bf9-b4b9s

Усі Podʼи:

kubectl get pods

Вивід подібний до цього:

NAME                                READY   STATUS        RESTARTS      AGE
nginx-deployment-7768647bf9-b4b9s   1/1     Terminating   0             4m1s
nginx-deployment-7768647bf9-rkxlw   1/1     Running       0             8s

Ви бачите, що новий Pod був запланований.

Поки створюється нова точка доступу для нового Podʼа, стара точка доступу все ще знаходиться у стані завершення:

kubectl get endpointslice -o json nginx-service-6tjbr

Вивід подібний до цього:

{
    "addressType": "IPv4",
    "apiVersion": "discovery.k8s.io/v1",
    "endpoints": [
        {
            "addresses": [
                "10.12.1.201"
            ],
            "conditions": {
                "ready": false,
                "serving": true,
                "terminating": true
            },
            "nodeName": "gke-main-default-pool-dca1511c-d17b",
            "targetRef": {
                "kind": "Pod",
                "name": "nginx-deployment-7768647bf9-b4b9s",
                "namespace": "default",
                "uid": "66fa831c-7eb2-407f-bd2c-f96dfe841478"
            },
            "zone": "us-central1-c"
        },
        {
            "addresses": [
                "10.12.1.202"
            ],
            "conditions": {
                "ready": true,
                "serving": true,
                "terminating": false
            },
            "nodeName": "gke-main-default-pool-dca1511c-d17b",
            "targetRef": {
                "kind": "Pod",
                "name": "nginx-deployment-7768647bf9-rkxlw",
                "namespace": "default",
                "uid": "722b1cbe-dcd7-4ed4-8928-4a4d0e2bbe35"
            },
            "zone": "us-central1-c"

Це дозволяє застосункам передавати свій стан під час завершення, а клієнтам (таким як балансувальники навантаження) реалізувати функціональність завершення зʼєднань. Ці клієнти можуть виявляти завершальні точки доступу та реалізувати спеціальну логіку для них.

У Kubernetes точки доступу, які завершуються, завжди мають свій статус ready встановлений як false. Це потрібно для забезпечення зворотної сумісності, щоб наявні балансувальники навантаження не використовували їх для звичайного трафіку. Якщо потрібно припинення обробки трафіку на Podʼі, що завершує роботу, фактична готовність може бути перевірені як умова serving.

Після видалення Podʼа, стару точку доступу також буде видалено.

Що далі

6 - Довідник

Цей розділ документації Kubernetes містить довідники.

Довідники API

Офіційно підтримувані клієнтські бібліотеки

Для надсилання викликів до API Kubernetes використовуючи одну з мов програмування ви можете використовувати клієнтські бібліотеки. Офіційно підтримуються наступні:

CLI

  • kubectl — Основний інструмент командного рядка для виконання команд та управління кластерами Kubernetes.
    • JSONPath — Посібник з синтаксису використання виразів JSONPath з kubectl.
  • kubeadm — Інструмент командного рядка для легкого налаштування захищеного кластера Kubernetes.

Компоненти

  • kubelet — Основний агент, який працює на кожному вузлі. Kubelet отримує набір PodSpecs і переконується, що описані контейнери працюють і є справними.

  • kube-apiserver — REST API, що перевіряє та налаштовує дані для обʼєктів API, таких як Podʼи, Serviceʼи, контролери реплікацій.

  • kube-controller-manager — Демон, який містить основні процеси управління, які постачаються з Kubernetes.

  • kube-proxy — Може виконувати просте перенаправлення потоку TCP/UDP або перенаправляти потік TCP/UDP методом "round-robin" через набір бекендів.

  • kube-scheduler — Планувальник, який керує доступністю, продуктивністю та місткістю.

  • Список портів та протоколів, які повинні бути відкриті на вузлах панелі управління та робочих вузлах.

Конфігураційні API

Цей розділ містить документацію для "неопублікованих" API, які використовуються для налаштування компонентів або інструментів Kubernetes. Більшість з цих API не експонуються через API-сервер у стилі REST, хоча вони є важливими для користувача чи оператора для використання або управління кластером.

Конфігураційні API kubeadm

Зовнішні API

Ці API, визначені проєктом Kubernetes, але не реалізовані в межах основного проєкту:

Документи проєктування

Архів документів проєктування функціонала Kubernetes. Ви можете розпочати з

6.1 - Глосарій

6.2 - Огляд API

Цей розділ містить довідкову інформацію про API Kubernetes.

REST API є фундаментальною основою Kubernetes. Усі операції та комунікації між компонентами та зовнішніми командами користувачів є викликами REST API, які обробляє API-сервер. Внаслідок цього все в Kubernetes обробляється як обʼєкти API та має відповідний запис в API.

Довідник API Kubernetes містить список API для версії Kubernetes v1.31.

Для отримання загальної інформації, читайте API Kubernetes. Керування доступом до API Kubernetes описує, як клієнти можуть автентифікуватися до сервера API Kubernetes, та як їхні запити авторизуються.

Версіювання API

Схеми серіалізації JSON та Protobuf слідують однаковими принципами для змін схеми. Наступні описи стосуються обох форматів.

Версіювання API та версіювання програмного забезпечення непрямо повʼязані. Пропозиція з версіювання API та релізів описує відносини між версіюванням API та версіюванням програмного забезпечення.

Різні версії API вказують на різні рівні стабільності та підтримки. Докладнішу інформацію про критерії кожного рівня можна знайти в документації API Changes.

Ось короткий огляд кожного рівня:

  • Alpha:

    • Назви версій містять alpha (наприклад, v1alpha1).
    • Вбудовані версії API рівня alpha типово вимкнені та повинні бути явно увімкнені в конфігурації kube-apiserver для використання.
    • Програмне забезпечення може містити помилки. Увімкнення функції може виявити помилки.
    • Підтримка alpha API може бути відключена в будь-який момент без попередження.
    • API може змінитися несумісним чином у подальших версіях програмного забезпечення без попередження.
    • Рекомендується використовувати програмне забезпечення тільки в тестових кластерах для короткочасного тестування через збільшений ризик помилок та відсутність довгострокової підтримки.
  • Beta:

    • Назви версій містять beta (наприклад, v2beta3).

    • Вбудовані версії API рівня beta типово вимкнені та повинні бути явно увімкнені в конфігурації kube-apiserver для використання (за винятком бета-версій API, представлених до Kubernetes 1.22, які були типово увімкнені).

    • Вбудовані версії API рівня beta мають максимальний термін служби 9 місяців або 3 мінорні випуски (в залежності, що довше), починаючи від введення до застаріння, і 9 місяців або 3 мінорні випуски (в залежності, що довше) від застаріння до вилучення.

    • Програмне забезпечення добре протестоване. Увімкнення функції вважається безпечним.

    • Підтримка функції не буде відключена, хоча можуть змінитися деталі.

    • Схема та/або семантика обʼєктів може змінюватися несумісним чином у подальших версіях API рівня beta або стабільного. Коли це відбувається, надаються інструкції з міграції. Адаптація до наступної версії API рівня beta або стабільного може вимагати редагування чи повторного створення обʼєктів API, і це може бути не простим. Міграція може вимагати перерви у роботі застосунків, які покладаються на цю функцію.

    • Програмне забезпечення не рекомендується для використання в промисловій експлуатації. Подальші випуски можуть вносити несумісні зміни. Використання версій API рівня beta обовʼязкове для переходу до наступних версій API рівня beta або стабільного, якщо версія API рівня beta застаріє та більше не буде обслуговуватися.

  • Stable:

    • Назва версії — vX, де X – це ціле число.
    • Стабільні версії API залишаються доступними для всіх майбутніх випусків в межах основної версії Kubernetes, і немає поточних планів щодо ревізії основної версії Kubernetes, що вилучає стабільні API.

Групи API

Групи API спрощують розширення API Kubernetes. Група API вказується в REST-шляху та в полі apiVersion серіалізованого обʼєкта.

У Kubernetes існує кілька груп API:

  • core (також називається legacy) група знаходиться за REST-шляхом /api/v1. Основна група не вказується як частина поля apiVersion, наприклад, apiVersion: v1.
  • Названі групи знаходяться за REST-шляхом /apis/$GROUP_NAME/$VERSION та використовують apiVersion: $GROUP_NAME/$VERSION (наприклад, apiVersion: batch/v1). Повний список підтримуваних груп API можна знайти в довіднику API Kubernetes.

Увімкнення чи вимкнення груп API

Деякі ресурси та групи API типово увімкнені. Ви можете увімкнути чи вимкнути їх, встановивши --runtime-config на API-сервері. Прапорець --runtime-config приймає розділені комами пари <key>[=<value>], що описують конфігурацію запуску API-сервера. Якщо частина =<value> пропущена, вона розглядається так, ніби вказано =true. Наприклад:

  • для вимкнення batch/v1 встановіть --runtime-config=batch/v1=false
  • для увімкнення batch/v2alpha1 встановіть --runtime-config=batch/v2alpha1
  • для увімкнення конкретної версії API, наприклад, storage.k8s.io/v1beta1/csistoragecapacities, встановіть --runtime-config=storage.k8s.io/v1beta1/csistoragecapacities

Збереження

Kubernetes зберігає свій серіалізований стан у термінах ресурсів API, записуючи їх в etcd.

Що далі

6.2.1 - Концепції API Kubernetes

API Kubernetes — це програмний інтерфейс на основі ресурсів (RESTful), який надається через HTTP. Він підтримує отримання, створення, оновлення та видалення основних ресурсів за допомогою стандартних HTTP-дієслів (POST, PUT, PATCH, DELETE, GET).

Для деяких ресурсів API включає додаткові субресурси, що дозволяють детальніше налаштовувати авторизацію (наприклад, окремі представлення для деталей Pod та отримання логів), і може приймати та надавати ці ресурси в різних форматах для зручності або ефективності.

Kubernetes підтримує ефективні сповіщення про зміни ресурсів за допомогою watches.

В API Kubernetes, watch це дієслово, яке використовується для відстеження змін обʼєкта в Kubernetes у вигляді потоку. Використовується для ефективного виявлення змін.

Kubernetes також забезпечує послідовні операції зі списками, щоб клієнти API могли ефективно кешувати, відстежувати та синхронізувати стан ресурсів.

Ви можете переглянути Довідник API онлайн або прочитати далі, щоб дізнатися про API загалом.

Терміни API Kubernetes

Kubernetes зазвичай використовує загальноприйняту термінологію RESTful для опису концепцій API:

  • Тип ресурсу — це назва, що використовується в URL (pods, namespaces, services)
  • Усі типи ресурсів мають конкретне представлення (їх схему обʼєкта), яке називається kind
  • Список екземплярів типу ресурсу називається колекцією
  • Окремий екземпляр типу ресурсу називається ресурсом і зазвичай представляє обʼєкт
  • Для деяких типів ресурсів API включає один або більше субресурсів, які представлені як URI-шляхи після назви ресурсу

Більшість типів ресурсів API Kubernetes є обʼєктами — вони представляють конкретний екземпляр концепції у кластері, як-от pod або namespace. Невелика кількість типів ресурсів API є віртуальними, оскільки вони часто представляють операції над обʼєктами, а не самі обʼєкти, такі як перевірка дозволів (використання POST із JSON-кодованим тілом SubjectAccessReview для ресурсу subjectaccessreviews), або субресурс eviction у Pod (використовується для запуску виселення, ініційованого API).

Імена обʼєктів

Усі обʼєкти, які ви можете створити через API, мають унікальне імʼя, що дозволяє ідемпотентне1 створення та отримання, за винятком віртуальних типів ресурсів, які можуть не мати унікальних імен, якщо вони не можуть бути отримані або не залежать від ідемпотентності. У межах простору імен може бути лише один обʼєкт з вказаним іменем для даного виду. Однак, якщо ви видалите обʼєкт, ви можете створити новий обʼєкт з тим самим іменем. Деякі обʼєкти не мають простору імен (наприклад: Nodes), тому їх імена повинні бути унікальними у всьому кластері.

Дієслова API

Майже всі типи ресурсів підтримують стандартні HTTP-дієслова — GET, POST, PUT, PATCH, та DELETE. Kubernetes також використовує власні дієслова, які часто пишуться малими літерами, щоб відрізняти їх від HTTP-дієслів.

Kubernetes використовує термін list для опису отримання колекції ресурсів, щоб відрізняти його від отримання одного ресурсу, яке зазвичай називається get. Якщо ви надішлете HTTP-запит GET із параметром ?watch, Kubernetes називає це watch, а не get (див. Ефективне виявлення змін для деталей).

Для запитів PUT Kubernetes внутрішньо класифікує їх як create або update залежно від стану наявного обʼєкта. Update відрізняється від patch; HTTP-дієслово для patch - PATCH.

URI ресурсів

Усі типи ресурсів або належать кластеру (/apis/GROUP/VERSION/*), або простору імен (/apis/GROUP/VERSION/namespaces/NAMESPACE/*). Тип ресурсу, що належить простору імен, буде видалений при видаленні простору імен, і доступ до цього типу ресурсу контролюється перевірками авторизації в межах простору імен.

Примітка: основні ресурси використовують /api замість /apis і пропускають сегмент GROUP.

Приклади:

  • /api/v1/namespaces
  • /api/v1/pods
  • /api/v1/namespaces/my-namespace/pods
  • /apis/apps/v1/deployments
  • /apis/apps/v1/namespaces/my-namespace/deployments
  • /apis/apps/v1/namespaces/my-namespace/deployments/my-deployment

Ви також можете отримати доступ до колекцій ресурсів (наприклад, переліку усіх Nodes). Наступні шляхи використовуються для отримання колекцій та ресурсів:

  • Ресурси кластерного рівня:

    • GET /apis/GROUP/VERSION/RESOURCETYPE — повертає колекцію ресурсів вказаного типу ресурсу
    • GET /apis/GROUP/VERSION/RESOURCETYPE/NAME — повертає ресурс з імʼям NAME вказаного типу ресурсу
  • Ресурси рівня простору імен:

    • GET /apis/GROUP/VERSION/RESOURCETYPE — повертає колекцію всіх екземплярів вказаного типу ресурсу в усіх просторах імен
    • GET /apis/GROUP/VERSION/namespaces/NAMESPACE/RESOURCETYPE — повертає колекцію всіх екземплярів вказаного типу ресурсу в просторі імен NAMESPACE
    • GET /apis/GROUP/VERSION/namespaces/NAMESPACE/RESOURCETYPE/NAME — повертає екземпляр вказаного типу ресурсу з імʼям NAME в просторі імен NAMESPACE

Оскільки простір імен є ресурсом кластерного рівня, ви можете отримати перелік (“колекцію”) всіх просторів імен за допомогою GET /api/v1/namespaces та деталі про конкретний простір імен за допомогою GET /api/v1/namespaces/NAME.

  • Субресурс кластерного рівня: GET /apis/GROUP/VERSION/RESOURCETYPE/NAME/SUBRESOURCE
  • Субресурс рівня простору імен: GET /apis/GROUP/VERSION/namespaces/NAMESPACE/RESOURCETYPE/NAME/SUBRESOURCE

Підтримувані дієслова для кожного субресурсу будуть відрізнятися залежно від обʼєкта — див. Довідник API для отримання додаткової інформації. Немає можливості отримати доступ до субресурсів через декілька ресурсів — зазвичай використовується новий віртуальний тип ресурсу, якщо це стає необхідним.

Ефективне виявлення змін

API Kubernetes дозволяє клієнтам зробити початковий запит на обʼєкт або колекцію, а потім відстежувати зміни з моменту цього запиту: це watch. Клієнти можуть відправити list або get і потім зробити наступний запит watch.

Для реалізації цього відстеження змін кожен обʼєкт Kubernetes має поле resourceVersion, яке представляє версію цього ресурсу, що зберігається в постійному шарі збереження. При отриманні колекції ресурсів (як простору імен, так і кластерного рівня), відповідь від сервера API містить значення resourceVersion. Клієнт може використовувати це значення resourceVersion для ініціювання watch проти сервера API.

Коли ви надсилаєте запит watch, сервер API відповідає потоком змін. Ці зміни перераховують результати операцій (таких як create, delete, та update), що відбулись після resourceVersion, значення якого було вказане як параметр до запиту watch. Загальний механізм watch дозволяє клієнту отримати поточний стан і потім підписатися на подальші зміни, не пропускаючи жодної події.

Якщо клієнт watch відʼєднується, тоді цей клієнт може розпочати новий сеанс watch з останнього повернутого resourceVersion; клієнт також може виконати новий запити get/list і розпочати знову. Див. Семантика версій ресурсів для отримання детальнішої інформації.

Наприклад:

  1. Отримання списку всіх Podʼів у вказаному просторі імен.

    GET /api/v1/namespaces/test/pods
    ---
    200 OK
    Content-Type: application/json
    
    {
      "kind": "PodList",
      "apiVersion": "v1",
      "metadata": {"resourceVersion":"10245"},
      "items": [...]
    }
    
  2. Починаючи з версії ресурсу 10245, отримуйте сповіщення про будь-які операції API (такі як create, delete, patch або update), що впливають на Podʼи у просторі імен test. Кожне сповіщення про зміну — це документ JSON. Тіло відповіді HTTP (надається як application/json) складається із серії документів JSON.

    GET /api/v1/namespaces/test/pods?watch=1&resourceVersion=10245
    ---
    200 OK
    Transfer-Encoding: chunked
    Content-Type: application/json
    
    {
      "type": "ADDED",
      "object": {"kind": "Pod", "apiVersion": "v1", "metadata": {"resourceVersion": "10596", ...}, ...}
    }
    {
      "type": "MODIFIED",
      "object": {"kind": "Pod", "apiVersion": "v1", "metadata": {"resourceVersion": "11020", ...}, ...}
    }
    ...
    

Сервер Kubernetes буде зберігати історичний запис змін лише протягом обмеженого часу. Кластери, що використовують etcd 3, стандартно зберігають зміни за останні 5 хвилин. Коли запитувані операції watch не вдаються через недоступність історичної версії цього ресурсу, клієнти повинні обробляти цей випадок, розпізнаючи код статусу 410 Gone, очищаючи свій локальний кеш, виконуючи новий get або list запит, і починаючи watch з resourceVersion, яке було повернуто.

Для підписки на колекції бібліотеки клієнтів Kubernetes зазвичай пропонують певну форму стандартного інструменту для логіки list-потім-watch. (У бібліотеці клієнтів Go це називається Reflector і знаходиться в пакеті k8s.io/client-go/tools/cache).

Закладки для Watch

Щоб зменшити вплив короткого вікна історії, API Kubernetes надає подію спостереження під назвою BOOKMARK. Це особливий вид події, що позначає, що всі зміни до вказаної клієнтом resourceVersion вже були надіслані. Документ, що представляє подію BOOKMARK, має тип який отримується запитом, але включає лише поле .metadata.resourceVersion. Наприклад:

GET /api/v1/namespaces/test/pods?watch=1&resourceVersion=10245&allowWatchBookmarks=true
---
200 OK
Transfer-Encoding: chunked
Content-Type: application/json

{
  "type": "ADDED",
  "object": {"kind": "Pod", "apiVersion": "v1", "metadata": {"resourceVersion": "10596", ...}, ...}
}
...
{
  "type": "BOOKMARK",
  "object": {"kind": "Pod", "apiVersion": "v1", "metadata": {"resourceVersion": "12746"} }
}

Як клієнт, ви можете запитувати події BOOKMARK, встановлюючи параметр запиту allowWatchBookmarks=true у запиті watch, але не слід припускати, що закладки будуть повертатися з певним інтервалом, і клієнти не можуть очікувати, що сервер API надішле будь-яку подію BOOKMARK, навіть якщо її було запитано.

Потокові списки

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.27 [alpha]

У великих кластерах отримання колекції деяких типів ресурсів може призвести до значного збільшення використання ресурсів (переважно RAM) панелі управління. Щоб зменшити цей вплив та спростити користування шаблоном list + watch, Kubernetes v1.27 вводить альфа-функцію підтримки запиту початкового стану (раніше запитуваного через запит list) як частини запиту watch.

За умови, що ввімкнено функціонал WatchList, це можна зробити, вказавши sendInitialEvents=true як параметр рядка запиту у запиті watch. Якщо встановлено, сервер API починає потік спостереження з синтетичних початкових подій (типу ADDED) для побудови всього стану всіх наявних обʼєктів, після чого йде подія BOOKMARK (якщо запитано через параметр allowWatchBookmarks=true). Подія закладки включає версію ресурсу, до якої його було синхронізовано. Після надсилання події закладки сервер API продовжує роботу як для будь-якого іншого запиту watch.

Коли ви встановлюєте sendInitialEvents=true у рядку запиту, Kubernetes також вимагає, щоб ви встановили resourceVersionMatch до значення NotOlderThan. Якщо ви вказали resourceVersion у рядку запиту без значення або не вказали його взагалі, це інтерпретується як запит на узгоджене читання (consistent read); подія закладки надсилається, коли стан синхронізовано щонайменше до моменту узгодженого читання з моменту, коли запит почав оброблятися. Якщо ви вказуєте resourceVersion (у рядку запиту), подія закладки надсилається, коли стан синхронізовано щонайменше до вказаної версії ресурсу.

Приклад

Приклад: ви хочете спостерігати за колекцією Podʼів. Для цієї колекції поточна версія ресурсу становить 10245, і є два Podʼи: foo та bar. Надсилання наступного запиту (який явно запитує узгоджене читання, встановлюючи порожню версію ресурсу за допомогою resourceVersion=) може призвести до наступної послідовності подій:

GET /api/v1/namespaces/test/pods?watch=1&sendInitialEvents=true&allowWatchBookmarks=true&resourceVersion=&resourceVersionMatch=NotOlderThan
---
200 OK
Transfer-Encoding: chunked
Content-Type: application/json

{
  "type": "ADDED",
  "object": {"kind": "Pod", "apiVersion": "v1", "metadata": {"resourceVersion": "8467", "name": "foo"}, ...}
}
{
  "type": "ADDED",
  "object": {"kind": "Pod", "apiVersion": "v1", "metadata": {"resourceVersion": "5726", "name": "bar"}, ...}
}
{
  "type": "BOOKMARK",
  "object": {"kind": "Pod", "apiVersion": "v1", "metadata": {"resourceVersion": "10245"} }
}
...
<далі йде звичайний потік спостереження, починаючи з resourceVersion="10245">

Стиснення відповідей

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.16 [beta]

Опція APIResponseCompression дозволяє серверу API стискати відповіді на запити get та list, зменшуючи використання мережевої пропускної здатності та покращуючи продуктивність у великих кластерах. Її стандартно увімкнено з Kubernetes 1.16 і її можна вимкнути додаванням APIResponseCompression=false у прапорець --feature-gates на сервері API.

Стиснення відповідей API може значно зменшити розмір відповіді, особливо для великих ресурсів або колекцій. Наприклад, запит list для Podʼів може повернути сотні кілобайт або навіть мегабайти даних, залежно від кількості Podʼів та їх атрибутів. Стиснення відповіді дозволяє зберегти мережеву пропускну здатність та зменшити затримки.

Щоб перевірити, чи працює APIResponseCompression, ви можете надіслати запит get або list на сервер API з заголовком Accept-Encoding та перевірити розмір відповіді та заголовки. Наприклад:

GET /api/v1/pods
Accept-Encoding: gzip
---
200 OK
Content-Type: application/json
content-encoding: gzip
...

Заголовок content-encoding вказує, що відповідь стиснута за допомогою gzip.

Отримання великих наборів результатів частинами

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.29 [stable]

У великих кластерах отримання колекції деяких типів ресурсів може призвести до дуже великих відповідей, що може вплинути на сервер та клієнта. Наприклад, у кластері може бути десятки тисяч Podʼів, кожен з яких еквівалентний приблизно 2 КіБ у форматі JSON. Отримання всіх Podʼів через всі простори імен може призвести до дуже великої відповіді (10-20 МБ) та спожити багато ресурсів сервера.

Сервер API Kubernetes підтримує можливість розбиття одного великого запиту на колекцію на багато менших частин, зберігаючи при цьому узгодженість загального запиту. Кожна частина може бути повернута послідовно, що зменшує загальний розмір запиту і дозволяє клієнтам, орієнтованим на користувачів, показувати результати поетапно для покращення швидкості реагування.

Ви можете запитувати сервер API для обробки list запиту, використовуючи сторінки (які Kubernetes називає chunks). Щоб отримати одну колекцію частинами, підтримуються два параметри запиту limit та continue у запитах до колекцій, і поле відповіді continue повертається з усіх операцій list у полі metadata колекції. Клієнт повинен вказати максимальну кількість результатів, яку він бажає отримати у кожній частині за допомогою limit, і сервер поверне кількість ресурсів у результаті не більше limit та включить значення continue, якщо у колекції є більше ресурсів.

Як клієнт API, ви можете передати це значення continue серверу API у наступному запиті, щоб вказати серверу повернути наступну сторінку (chunk) результатів. Продовжуючи до тих пір, поки сервер не поверне порожнє значення continue, ви можете отримати всю колекцію.

Як і у випадку з операцією watch, токен continue закінчується через короткий проміжок часу (стандартно 5 хвилин) і повертає 410 Gone, якщо більше результатів не може бути повернуто. У цьому випадку клієнт повинен буде почати з початку або опустити параметр limit.

Наприклад, якщо у кластері є 1,253 Podʼів і ви хочете отримувати частини по 500 Podʼів за раз, запитуйте ці частини наступним чином:

  1. Отримати всі Podʼи в кластері, отримуючи до 500 Podʼів за раз.

    GET /api/v1/pods?limit=500
    ---
    200 OK
    Content-Type: application/json
    
    {
      "kind": "PodList",
      "apiVersion": "v1",
      "metadata": {
        "resourceVersion":"10245",
        "continue": "ENCODED_CONTINUE_TOKEN",
        "remainingItemCount": 753,
        ...
      },
      "items": [...] // повертає Podʼи 1-500
    }
    
  2. Продовжити попередній запит, отримуючи наступний набір з 500 Podʼів.

    GET /api/v1/pods?limit=500&continue=ENCODED_CONTINUE_TOKEN
    ---
    200 OK
    Content-Type: application/json
    
    {
      "kind": "PodList",
      "apiVersion": "v1",
      "metadata": {
        "resourceVersion":"10245",
        "continue": "ENCODED_CONTINUE_TOKEN_2",
        "remainingItemCount": 253,
        ...
      },
      "items": [...] // повертає Podʼи 501-1000
    }
    
  3. Продовжити попередній запит, отримуючи останні 253 Podʼів.

    GET /api/v1/pods?limit=500&continue=ENCODED_CONTINUE_TOKEN_2
    ---
    200 OK
    Content-Type: application/json
    
    {
      "kind": "PodList",
      "apiVersion": "v1",
      "metadata": {
        "resourceVersion":"10245",
        "continue": "", // токен continue порожній, тому що ми досягли кінця списку
        ...
      },
      "items": [...] // повертає Podʼи 1001-1253
    }
    

Зверніть увагу, що resourceVersion колекції залишається постійним в кожному запиті, що вказує на те, що сервер показує вам узгоджену копію Podʼів. Podʼи, що створюються, оновлюються або видаляються після версії 10245, не будуть показані, якщо ви не зробите окремий запит list без токена continue. Це дозволяє вам розбивати великі запити на менші частини, а потім виконувати операцію watch на повному наборі, не пропускаючи жодного оновлення.

Поле remainingItemCount вказує кількість наступних елементів у колекції, які не включені у цю відповідь. Якщо запит list містив мітки або поля селектори, тоді кількість залишкових елементів невідома, і сервер API не включає поле remainingItemCount у свою відповідь. Якщо list запит завершено (або тому, що він не розбивається на частини, або тому, що це остання частина), то більше немає залишкових елементів, і сервер API не включає поле remainingItemCount у свою відповідь. Очікуване використання `remainingItemCount — оцінка розміру колекції.

Колекції

У термінології Kubernetes відповідь, яку ви отримуєте за допомогою list, є колекцією. Однак Kubernetes визначає конкретні види для колекцій різних типів ресурсів. Колекції мають вид, названий на честь виду ресурсу, з доданим List.

Коли ви надсилаєте запит API для певного типу, всі елементи, повернуті цим запитом, є цього типу. Наприклад, коли ви надсилаєте list Services, відповідь колекції має kind, встановлений на ServiceList; кожен елемент у цій колекції представляє один Service. Наприклад:

GET /api/v1/services
{
  "kind": "ServiceList",
  "apiVersion": "v1",
  "metadata": {
    "resourceVersion": "2947301"
  },
  "items": [
    {
      "metadata": {
        "name": "kubernetes",
        "namespace": "default",
...
      "metadata": {
        "name": "kube-dns",
        "namespace": "kube-system",
...

Є десятки типів колекцій (таких як PodList, ServiceList та NodeList), визначених в API Kubernetes. Ви можете отримати більше інформації про кожен тип колекції з довідника Kubernetes API.

Деякі інструменти, такі як kubectl, представляють механізм колекцій Kubernetes трохи інакше, ніж сам API Kubernetes. Оскільки вихідні дані kubectl можуть включати відповідь з декількох операцій list на рівні API, kubectl представляє список елементів, використовуючи kind: List. Наприклад:

kubectl get services -A -o yaml
apiVersion: v1
kind: List
metadata:
  resourceVersion: ""
  selfLink: ""
items:
- apiVersion: v1
  kind: Service
  metadata:
    creationTimestamp: "2021-06-03T14:54:12Z"
    labels:
      component: apiserver
      provider: kubernetes
    name: kubernetes
    namespace: default
...
- apiVersion: v1
  kind: Service
  metadata:
    annotations:
      prometheus.io/port: "9153"
      prometheus.io/scrape: "true"
    creationTimestamp: "2021-06-03T14:54:14Z"
    labels:
      k8s-app: kube-dns
      kubernetes.io/cluster-service: "true"
      kubernetes.io/name: CoreDNS
    name: kube-dns
    namespace: kube-system

Отримання ресурсів у вигляді таблиць

Коли ви запускаєте kubectl get, стандартний формат виводу є простою табличною репрезентацією одного або кількох екземплярів певного типу ресурсу. У минулому клієнти повинні були відтворювати табличний і описовий вивід, реалізований у kubectl, щоб виконувати прості списки обʼєктів. Деякі обмеження цього підходу включають нетривіальну логіку при роботі з певними обʼєктами. Крім того, типи, надані API агрегуванням або сторонніми ресурсами, не відомі під час компіляції. Це означає, що повинні бути реалізовані загальні механізми для типів, які не розпізнаються клієнтом.

Щоб уникнути можливих обмежень, описаних вище, клієнти можуть запитувати табличну репрезентацію обʼєктів, делегуючи серверу специфічні деталі виводу. API Kubernetes реалізує стандартні HTTP-узгодження щодо типу контенту: передача заголовка Accept, що містить значення application/json;as=Table;g=meta.k8s.io;v=v1 з запитом GET попросить сервер повернути обʼєкти у форматі таблиці.

Наприклад, список усіх Podʼів у кластері у форматі таблиці.

GET /api/v1/pods
Accept: application/json;as=Table;g=meta.k8s.io;v=v1
---
200 OK
Content-Type: application/json

{
    "kind": "Table",
    "apiVersion": "meta.k8s.io/v1",
    ...
    "columnDefinitions": [
        ...
    ]
}

Для типів ресурсів API, які не мають табличного визначення, відомого панелі управління, сервер API повертає стандартну таблицю, яка складається з полів name та creationTimestamp ресурсу.

GET /apis/crd.example.com/v1alpha1/namespaces/default/resources
---
200 OK
Content-Type: application/json
...

{
    "kind": "Table",
    "apiVersion": "meta.k8s.io/v1",
    ...
    "columnDefinitions": [
        {
            "name": "Name",
            "type": "string",
            ...
        },
        {
            "name": "Created At",
            "type": "date",
            ...
        }
    ]
}

Не всі типи ресурсів API підтримують табличну відповідь; наприклад, CustomResourceDefinitions можуть не визначати відповідність полів таблиці, а APIService, що розширює основний API Kubernetes може взагалі не обслуговувати табличні відповіді. Якщо ви створюєте клієнта, що використовує інформацію з таблиці та який повинен працювати з усіма типами ресурсів, включаючи розширення, ви повинні робити запити, які вказують кілька типів контенту у заголовку Accept. Наприклад:

Accept: application/json;as=Table;g=meta.k8s.io;v=v1, application/json

Альтернативні представлення ресурсів

Типово Kubernetes повертає обʼєкти, серіалізовані у форматі JSON з типом контенту application/json. Це станадртний формат серіалізації для API. Однак клієнти можуть запросити більш ефективне представлення у форматі Protobuf цих обʼєктів для покращення продуктивності в масштабі. API Kubernetes реалізує стандартні HTTP-узгодження щодо типу контенту: передача заголовка Accept з викликом GET запросить сервер повернути відповідь у вашому бажаному медіа-типі, тоді як надсилання обʼєкта у форматі Protobuf на сервер для виклику PUT або POST означає, що ви повинні відповідним чином встановити заголовок Content-Type.

Сервер поверне відповідь з заголовком Content-Type, якщо запитаний формат підтримується, або помилку 406 Not acceptable, якщо жоден з медіа-типів, які ви запросили, не підтримується. Усі вбудовані типи ресурсів підтримують медіа-тип application/json.

Дивіться довідник API Kubernetes для списку підтримуваних типів контенту для кожного API.

Наприклад:

  1. Список всіх Podʼів у кластері у форматі Protobuf.

    GET /api/v1/pods
    Accept: application/vnd.kubernetes.protobuf
    ---
    200 OK
    Content-Type: application/vnd.kubernetes.protobuf
    
    ... binary encoded PodList object
    
  2. Створення Podʼа, надсиланням даних у форматі Protobuf на сервер, але із запитом відповідіу форматі JSON.

    POST /api/v1/namespaces/test/pods
    Content-Type: application/vnd.kubernetes.protobuf
    Accept: application/json
    ... binary encoded Pod object
    ---
    200 OK
    Content-Type: application/json
    
    {
      "kind": "Pod",
      "apiVersion": "v1",
      ...
    }
    

Не всі типи ресурсів API підтримують Protobuf; зокрема, Protobuf недоступний для ресурсів, визначених як CustomResourceDefinitions або обслуговуються через шар агрегації. Як клієнт, який може працювати з розширеними типами, ви повинні вказати кілька типів контенту у заголовку запиту Accept для підтримки відкату до JSON. Наприклад:

Accept: application/vnd.kubernetes.protobuf, application/json

Кодування Protobuf у Kubernetes

Kubernetes використовує обгортку для кодування відповідей Protobuf. Ця обгортка починається з 4-байтового магічного числа для ідентифікації контенту на диску або в etcd як Protobuf (на відміну від JSON), а потім слідує Protobuf-кодована обгортка повідомлення, яка описує кодування і тип основного обʼєкта, а потім містить сам обʼєкт.

Формат обгортки виглядає так:

Чотирибайтовий префікс магічного числа:
  Байти 0-3: "k8s\x00" [0x6b, 0x38, 0x73, 0x00]

Кодоване повідомлення Protobuf з наступним IDL:
  message Unknown {
    // typeMeta повинен мати рядкові значення для "kind" та "apiVersion", встановлені на обʼєкті JSON
    optional TypeMeta typeMeta = 1;

    // raw буде містити повністю серіалізований обʼєкт у форматі Protobuf. Дивіться визначення Protobuf у клієнтських бібліотеках для певного kind.
    optional bytes raw = 2;

    // contentEncoding — це кодування, що використовується для raw даних. Відсутність означає відсутність кодування.
    optional string contentEncoding = 3;

    // contentType — це метод серіалізації, використаний для серіалізації 'raw'. Відсутність означає application/vnd.kubernetes.protobuf
    // і зазвичай опускається.
    optional string contentType = 4;
  }

  message TypeMeta {
    // apiVersion — це група/версія для цього типу
    optional string apiVersion = 1;
    // kind — це назва схеми обʼєкта. Визначення Protobuf повинно існувати для цього обʼєкта.
    optional string kind = 2;
  }

Видалення ресурсів

Коли ви видаляєте ресурс, цей процес проходить у два етапи:

  1. Завершення (finalization)
  2. Видалення (removal)
{
  "kind": "ConfigMap",
  "apiVersion": "v1",
  "metadata": {
    "finalizers": ["url.io/neat-finalization", "other-url.io/my-finalizer"],
    "deletionTimestamp": null,
  }
}

Коли клієнт вперше надсилає запит на видалення ресурсу, .metadata.deletionTimestamp встановлюється на поточний час. Після встановлення .metadata.deletionTimestamp, зовнішні контролери, які працюють з завершувачами (finalizers), можуть почати виконувати свою очистку в будь-який час, у будь-якому порядку.

Порядок не встановлюється примусово між завершувачами, оскільки це може призвести до значного ризику застрягання .metadata.finalizers.

Поле .metadata.finalizers є спільним: будь-який áктор з дозволом може змінювати його порядок. Якби список завершувачів оброблявся по порядку, це могло б призвести до ситуації, коли компонент, відповідальний за перший завершувач у списку, чекає на якийсь сигнал (значення поля, зовнішню систему або інше), що створюється компонентом, відповідальним за завершувач пізніше у списку, що призводить до застярягання всього списку.

Без примусового впорядкування завершувачі можуть вільно визначати свій власний порядок і не є вразливими до змін у списку.

Після видалення останнього завершувача ресурс фактично видаляється з etcd.

API для одного ресурсу

API Kubernetes з дієсловами get, create, update, patch, delete та proxy підтримують тільки одиничні ресурси. Ці дієслова з підтримкою одиничного ресурсу не підтримують надсилання кількох ресурсів разом в упорядкованому або неупорядкованому списку чи транзакції.

Коли клієнти (включаючи kubectl) виконують дії з набором ресурсів, клієнт робить серію одиничних API запитів до ресурсу, а потім, за потреби, агрегує відповіді.

На відміну від цього, API Kubernetes з дієсловами list і watch дозволяють отримувати кілька ресурсів, а deletecollection дозволяє видаляти кілька ресурсів.

Валідація полів

Kubernetes завжди перевіряє тип полів. Наприклад, якщо поле в API визначене як число, ви не можете встановити це поле в текстове значення. Якщо поле визначене як масив рядків, ви можете надати тільки масив. Деякі поля можна пропустити, інші поля є обовʼязковими. Пропуск обовʼязкового поля у запиті API є помилкою.

Якщо ви зробите запит з додатковим полем, яке не розпізнається панеллю управління кластера, тоді поведінка сервера API є складнішою.

Типово, сервер API видаляє поля, які він не розпізнає, з вхідних даних, які він отримує (наприклад, тіло JSON запиту PUT).

Є дві ситуації, коли сервер API видаляє поля, які ви надали у HTTP-запиті.

Ці ситуації такі:

  1. Поле не розпізнається, оскільки воно не входить до схеми OpenAPI ресурсу. (Одним винятком є CRDs, які явно обирають не обрізати невідомі поля через x-kubernetes-preserve-unknown-fields).
  2. Поле дублюється в обʼєкті.

Валідація для нерозпізнаних або дубльованих полів

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.27 [stable]

З версії 1.25 і далі, нерозпізнані або дубльовані поля в обʼєкті виявляються через валідацію на сервері при використанні HTTP-дієслів, які можуть надсилати дані (POST, PUT та PATCH). Можливі рівні валідації: Ignore, Warn (стандартно) та Strict.

Ignore
Сервер API успішно обробляє запит так, ніби у ньому немає неправильних полів, відкидаючи всі невідомі та дубльовані поля та не повідомляючи про це.
Warn
(Стандартно) Сервер API успішно обробляє запит і надсилає клієнту попередження. Попередження надсилається за допомогою заголовка відповіді Warning:, додаючи один елемент попередження для кожного невідомого або дубльованого поля. Для отримання додаткової інформації про попередження та API Kubernetes дивіться статтю блогу Warning: Helpful Warnings Ahead.
Strict
Сервер API відхиляє запит з помилкою 400 Bad Request, коли виявляє будь-які невідомі або дубльовані поля. Повідомлення відповіді від сервера API вказує всі невідомі або дубльовані поля, які сервер API виявив.

Рівень валідації полів встановлюється параметром запиту fieldValidation.

Інструменти, які надсилають запити на сервер (такі як kubectl), можуть встановлювати свої власні типові значення, які відрізняються від рівня валідації Warn, що стандартно використовується сервером API.

Інструмент kubectl використовує прапорець --validate для встановлення рівня валідації полів. Він приймає значення ignore, warn та strict, а також приймає значення true (еквівалентно strict) і false (еквівалентно ignore). Станадртне налаштування валідації для kubectl — це --validate=true, що означає сувору валідацію полів на стороні сервера.

Коли kubectl не може підключитися до сервера API з валідацією полів (сервери API до Kubernetes 1.27), він повернеться до використання валідації на стороні клієнта. Валідація на стороні клієнта буде повністю видалена у майбутній версії kubectl.

Dry-run

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.19 [stable]

При використанні HTTP-дієслів, які можуть змінювати ресурси (POST, PUT, PATCH і DELETE), ви можете надіслати свій запит у режимі dry run. Режим dry run допомагає оцінити запит через типові етапи обробки запиту (ланцюг допумків, валідацію, конфлікти злиття) аж до збереження обʼєктів у сховищі. Тіло відповіді на запит є максимально наближеним до відповіді у режимі non-dry-run. Kubernetes гарантує, що dry-run запити не будуть збережені в сховищі і не матимуть жодних інших побічних ефектів.

Виконання dry-run запиту

Dry-run активується встановленням параметра запиту dryRun. Цей параметр є рядковим, діє як перерахування, і єдині прийнятні значення:

[без значення]
Дозволити побічні ефекти. Ви запитуєте це за допомогою рядка запиту типу ?dryRun або ?dryRun&pretty=true. Відповідь є остаточним обʼєктом, який був би збережений, або помилкою, якщо запит не може бути виконаний.
All
Кожен етап виконується як зазвичай, за винятком кінцевого етапу збереження, де побічні ефекти запобігаються.

Коли ви встановлюєте ?dryRun=All, усі відповідні контролерів допуску виконуються, перевіряючи запит після зміни, злиття виконується для PATCH, поля заповнюються станадартними значеннями, і проводиться валідація схеми. Зміни не зберігаються в базовому сховищі, але остаточний обʼєкт, який був би збережений, все ще повертається користувачеві разом із звичайним кодом статусу.

Якщо версія запиту без dry-run викликала б контролер доступу, який має побічні ефекти, запит буде відхилений, щоб уникнути небажаних побічних ефектів. Усі вбудовані втулки контролю доступу підтримують dry-run. Додатково, admission webhooks можуть оголосити у своїй конфігураційній моделі, що вони не мають побічних ефектів, встановивши поле sideEffects на None.

Приклад dry-run запиту, який використовує ?dryRun=All:

POST /api/v1/namespaces/test/pods?dryRun=All
Content-Type: application/json
Accept: application/json

Відповідь буде виглядати так само, як для запиту без dry-run, але значення деяких згенерованих полів можуть відрізнятися.

Згенеровані значення

Деякі значення обʼєкта зазвичай генеруються перед його збереженням. Важливо не покладатися на значення цих полів, встановлених dry-run запитом, оскільки ці значення, ймовірно, будуть відрізнятися в dry-run режимі від реального запиту. Деякі з цих полів:

  • name: якщо встановлено generateName, name матиме унікальне випадкове імʼя
  • creationTimestamp / deletionTimestamp: фіксує час створення/видалення
  • UID: унікально ідентифікує обʼєкт і генерується випадково (недетерміновано)
  • resourceVersion: відстежує збережену версію обʼєкта
  • Будь-яке поле, встановлене мутаційним контролером допуску
  • Для ресурсу Service: Порти або IP-адреси, які kube-apiserver надає обʼєктам Service

Авторизація dry-run

Авторизація для dry-run і non-dry-run запитів ідентична. Таким чином, щоб виконати dry-run запит, ви повинні мати дозвіл на виконання non-dry-run запиту.

Наприклад, щоб виконати dry-run patch для Deployment, ви повинні мати дозвіл на виконання цього patch. Ось приклад правила для Kubernetes RBAC, що дозволяє робити patch для Deployment:

rules:
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["patch"]

Дивіться Огляд авторизації.

Оновлення наявних ресурсів

Kubernetes надає декілька способів оновлення наявних обʼєктів. Ви можете прочитати вибір механізму оновлення, щоб дізнатися, який підхід найкраще підходить для вашого випадку.

Ви можете перезаписати (оновити) наявний ресурс, наприклад, ConfigMap, використовуючи HTTP PUT. Для запиту PUT відповідальність за вказання resourceVersion (отриманого з обʼєкта, що оновлюється) лежить на клієнті. Kubernetes використовує інформацію resourceVersion, щоб сервер API міг виявити втрачені оновлення і відхилити запити від клієнта, який не актуальний для кластера. У разі зміни ресурсу (коли resourceVersion, надана клієнтом, застаріла), сервер API повертає відповідь з помилкою 409 Conflict.

Замість надсилання запиту PUT клієнт може надіслати інструкцію серверу API для накладання патчу до наявного ресурсу. Патч зазвичай підходить, якщо зміна, яку клієнт хоче внести, не залежить від наявних даних. Клієнти, яким потрібне ефективне виявлення втрачених оновлень, повинні розглянути можливість зробити свій запит умовним до існуючого resourceVersion (або HTTP PUT, або HTTP PATCH), а потім обробити будь-які повтори, які можуть знадобитися у разі конфлікту.

API Kubernetes підтримує чотири різні операції PATCH, які визначаються відповідним заголовком HTTP Content-Type:

application/apply-patch+yaml
Серверне застосування YAML (специфічне розширення Kubernetes, засноване на YAML). Всі документи JSON є дійсними в YAML, тому ви також можете надавати JSON, використовуючи цей тип медіа. Дивіться серіалізація для серверного застосування для отримання додаткової інформації. Для Kubernetes це операція створення, якщо обʼєкт не існує, або операція накладання патчу, якщо обʼєкт вже існує.
application/json-patch+json
JSON Patch, як визначено в RFC6902. JSON патч — це послідовність операцій, які виконуються з ресурсом; наприклад, {"op": "add", "path": "/a/b/c", "value": [ "foo", "bar" ]}. Для Kubernetes це операція накладання патчу. Патч з використанням application/json-patch+json може включати умови для перевірки консистентності, дозволяючи операції зазнати невдачі, якщо ці умови не виконуються (наприклад, щоб уникнути втрати оновлення).
application/merge-patch+json
JSON Merge Patch, як визначено в RFC7386. JSON Merge Patch фактично є частковим представленням ресурсу. Поданий JSON комбінується з поточним ресурсом для створення нового, а потім новий зберігається. Для Kubernetes це операція накладання патчу.
application/strategic-merge-patch+json
Strategic Merge Patch (специфічне розширення Kubernetes на основі JSON). Strategic Merge Patch — це власна реалізація JSON Merge Patch. Ви можете використовувати Strategic Merge Patch лише з вбудованими API або з агрегованими серверами API, які мають спеціальну підтримку для цього. Ви не можете використовувати application/strategic-merge-patch+json з будь-яким API, визначеним за допомогою CustomResourceDefinition.

Функція Серверного застосування Kubernetes дозволяє панелі управління відстежувати керовані поля для новостворених обʼєктів. SСерверне застосування забезпечує чітку схему для управління конфліктами полів, пропонує серверні операції apply і update, та замінює функціональність на стороні клієнта kubectl apply.

Для серверного застосування Kubernetes обробляє запит як створення, якщо обʼєкт ще не існує, і як патч в іншому випадку. Для інших запитів, які використовують PATCH на рівні HTTP, логічна операція Kubernetes завжди є патч.

Дивіться Серверне застосування для отримання додаткової інформації.

Вибір механізму оновлення

HTTP PUT для заміни наявного ресурсу

Операція оновлення (HTTP PUT) проста у виконанні та гнучка, але має недоліки:

  • Потрібно вирішувати конфлікти, де resourceVersion обʼєкта змінюється між моментом його читання клієнтом і спробою записувати назад. Kubernetes завжди виявляє конфлікт, але вам як авторові клієнта потрібно реалізувати повторні спроби.
  • Ви можете випадково видаляти поля, якщо декодуєте обʼєкт локально (наприклад, використовуючи client-go, ви можете отримати поля, які ваш клієнт не вміє обробляти, і потім видаляти їх під час оновлення).
  • Якщо на обʼєкт накладається багато конкурентних операцій (навіть на поле або набір полів, які ви не намагаєтеся редагувати), ви можете мати проблеми з надсиланням оновлення. Проблема гостріша для великих обʼєктів та для обʼєктів з багатьма полями.

HTTP PATCH з використанням JSON Patch

Оновлення патчем корисне через такі причини:

  • Оскільки ви надсилаєте лише різницю, ви маєте менше даних для надсилання у запиті PATCH.
  • Ви можете робити зміни, які ґрунтуються на наявних значеннях, наприклад, копіювати значення певного поля в анотацію.
  • На відміну від оновлення (HTTP PUT), ваші зміни можуть відбуватися відразу навіть при частих змінах не повʼязаних полів: зазвичай вам не потрібно повторювати спроби.
    • Вам все ще може знадобитися вказати resourceVersion (щоб відповідати існуючому обʼєкту), якщо ви хочете бути особливо обережними, щоб уникнути втрати оновлень.
    • Все ж це хороша практика написати деяку логіку повторної спроби у випадку помилок.
  • Ви можете використовувати тестові умови для обережного створення конкретних умов оновлення. Наприклад, ви можете збільшити лічильник без його читання, якщо існуюче значення відповідає вашим очікуванням. Ви можете це зробити без ризику втрати оновлення, навіть якщо обʼєкт змінився іншим чином з моменту вашого останнього запису до нього. (Якщо тестова умова не виконається, ви можете використовувати поточне значення і потім записати змінене число).

Проте:

  • Вам потрібна більша локальна (клієнтська) логіка для створення патчу; дуже корисно мати реалізацію бібліотеки JSON Patch або навіть створення JSON Patch специально для Kubernetes.
  • Як автору клієнтського програмного забезпечення, вам потрібно бути обережним при створенні патчу (тіла запиту HTTP), щоб не видаляти поля (порядок операцій має значення).

HTTP PATCH з використанням Server-Side Apply

Серверне застосування має чіткі переваги:

  • Одноразовий прохід веред-назад: зазвичай спочатку не потребує виконання GET запиту.
    • і ви все ще можете виявляти конфлікти для неочікуваних змін
    • у вас є можливість примусово перезаписати конфлікт, якщо це доцільно
  • Реалізація клієнта легка для створення
  • Ви отримуєте атомарну операцію створення або оновлення без додаткових зусиль (аналогічно UPSERT у деяких діалектах SQL).

Проте:

  • Серверне застосування зовсім не працює для змін полів, які залежать від поточного значення обʼєкта.
  • Ви можете застосовувати оновлення лише до обʼєктів. Деякі ресурси в HTTP API Kubernetes не є обʼєктами (вони не мають поля .metadata), а серверне застосування стосується лише обʼєктів Kubernetes.

Версії ресурсів

Версії ресурсів — це рядки, які ідентифікують внутрішню версію обʼєкта на сервері. Версії ресурсів можуть використовуватися клієнтами для визначення змін в обʼєктах або для зазначення вимог до консистентності даних при отриманні, переліку та перегляді ресурсів. Версії ресурсів повинні розглядатися клієнтами як непрозорі та передаватися без змін назад на сервер.

Не слід припускати, що версії ресурсів є числовими або можуть бути впорядковані. API-клієнти можуть порівнювати лише дві версії ресурсів на рівність (це означає, що ви не можете порівнювати версії ресурсів за відносними значеннями "більше" або "менше").

Поля resourceVersion в метаданих

Клієнти знаходять версії ресурсів в ресурсах, включаючи ресурси з потоку відповіді під час спостереження (watch) або при отримані переліку (list) ресурсів.

v1.meta/ObjectMeta — metadata.resourceVersion екземпляра ресурсу ідентифікує версію ресурсу, на якій останній раз він був змінений.

v1.meta/ListMeta — metadata.resourceVersion колекції ресурсів (відповідь на перелік (list)) ідентифікує версію ресурсу, на якій була створена колекція.

Параметри resourceVersion у рядках запитів

Операції отримання (get), переліку (list) та спостереження (watch) підтримують параметр resourceVersion. Починаючи з версії v1.19, сервери API Kubernetes також підтримують параметр resourceVersionMatch у запитах list.

Сервер API інтерпретує параметр resourceVersion по-різному, залежно від операції, яку ви запитуєте, та від значення resourceVersion. Якщо ви встановлюєте resourceVersionMatch, то це також впливає на спосіб порівняння.

Семантика для операцій get та list

Для операцій get та list, семантика параметра resourceVersion така:

get:

resourceVersion невстановленоresourceVersion="0"resourceVersion="{значення, відмінне від 0}"
НайновішийБудь-якеНе старше

list:

Починаючи з версії v1.19, сервери API Kubernetes підтримують параметр resourceVersionMatch у запитах list. Якщо ви встановлюєте як resourceVersion, так і resourceVersionMatch, то параметр resourceVersionMatch визначає, як сервер API інтерпретує resourceVersion.

Вам завжди слід встановлювати параметр resourceVersionMatch, коли ви встановлюєте resourceVersion у запиті list. Однак будьте готові обробляти випадок, де сервер API, що відповідає, не підтримує resourceVersionMatch та ігнорує його.

Крім випадків сильних вимог до консистентності, використання resourceVersionMatch=NotOlderThan та відомої resourceVersion є бажаним, оскільки це може забезпечити кращу продуктивність та масштабованість вашого кластеру, ніж залишати resourceVersion і resourceVersionMatch невстановленими, що вимагає отримання кворуму для обслуговування.

Встановлення параметра resourceVersionMatch без встановлення resourceVersion є недійсним.

Ця таблиця пояснює поведінку запитів list з різними комбінаціями resourceVersion та resourceVersionMatch:

Параметри resourceVersionMatch та розбиття на сторінки для list
Параметр resourceVersionMatchПараметри розбиття на сторінкиresourceVersion не встановленоresourceVersion="0"resourceVersion="{значення, відмінне від 0}"
не встановленоlimit не встановленоНайновішийAnyНе старше
не встановленоlimit=<n>, continue не встановленоНайновішийAnyТочно
не встановленоlimit=<n>, continue=<токен>Continue Token, ExactНедійсний, розглядається як Continue Token, ExactНедійсний, HTTP 400 Bad Request
resourceVersionMatch=Exactlimit не встановленоНедійснийНедійснийExact
resourceVersionMatch=Exactlimit=<n>, continue не встановленоНедійснийНедійснийExact
resourceVersionMatch=NotOlderThanlimit не встановленоНедійснийAnyNotOlderThan
resourceVersionMatch=NotOlderThanlimit=<n>, continue не встановленоНедійснийAnyNotOlderThan

Сенс семантики операцій get та list такий:

Any
Повернути дані на будь-якій версії ресурсу. Вибирається найновіша доступна версія ресурсу, але не потрібна сильна консистентність; дані на будь-якій версії ресурсу можуть бути обслуговані. Є можливість отримати дані на значно старішій версії ресурсу, яку клієнт раніше спостерігав, особливо в конфігураціях високої доступності через розділи або застарілі кеші. Клієнти, які не можуть терпіти це, не повинні використовувати цю семантику.
Найновіший
Повернути дані на найновішій версії ресурсу. Повернені дані повинні бути консистентними (детально: обслуговуються з etcd за допомогою кворумного читання). Для etcd версій v3.4.31+ та v3.5.13+ Kubernetes 1.31 обслуговує "найсвіжіші" читання з watch cache: внутрішнього, вбудованого в памʼять сховища всередині API сервера, що кешує та відображає стан даних, збережених у etcd. Kubernetes запитує сповіщення про прогрес, щоб підтримувати консистентність кешу з шаром збереження даних (persistence layer) у etcd. Версії Kubernetes з v1.28 до v1.30 також підтримували цю функцію, але як Alpha, вона не рекомендувалася для використання в операційному середовищі і не була стандартно увімкненою до випуску v1.31.
NotOlderThan
Повернути дані, які є принаймні так новими, як наданий resourceVersion. Вибирається найновіша доступна інформація, але будь-яка інформація, яка не старше наданої resourceVersion, може бути обслугована. Для запитів list до серверів, які підтримують параметр resourceVersionMatch, це гарантує, що .metadata.resourceVersion колекції не старше вказаної resourceVersion, але не надає гарантії щодо .metadata.resourceVersion будь-яких елементів у цій колекції.
Exact
Повернути дані на точній версії ресурсу, яка надана. Якщо надана resourceVersion недоступна, сервер відповідає HTTP 410 "Відсутній". Для запитів list до серверів, які підтримують параметр resourceVersionMatch, це гарантує, що .metadata.resourceVersion колекції співпадає з resourceVersion, яку ви запросили у рядку запиту. Ця гарантія не поширюється на .metadata.resourceVersion будь-яких елементів у цій колекції.
Continue Token, Exact
Повернути дані на версії ресурсу початкового виклику list розділеного на сторінки. Повернені продовження токенів відповідальні за відстеження початково наданої версії ресурсу для всіх викликів list розділених на сторінки після початкового виклику list.

При використанні resourceVersionMatch=Не старше та встановленому ліміті клієнти мають обробляти відповіді HTTP 410 "Gone". Наприклад, клієнт може повторно спробувати з новішою resourceVersion або використовувати resourceVersion="".

При використанні resourceVersionMatch=Точно та не встановленому ліміті, клієнти мають перевірити, що .metadata.resourceVersion колекції співпадає з запитаною resourceVersion, і обробити випадок, коли це не так. Наприклад, клієнт може використовувати запит з встановленим лімітом.

Семантика для операції watch

Для операцій watch, семантика параметра resourceVersion така:

watch:

resourceVersion для watch
resourceVersion невстановленоresourceVersion="0"resourceVersion="{значення, відмінне від 0}"
Отримати стан і почати з найновішогоОтримати стан і почати з будь-якогоПочати точно з

Сенс цієї семантики для watch такий:

Отримати стан і почати з будь-якого
Почати watch на будь-якій версії ресурсу; найбільш нова доступна версія є переважною, але не обовʼязковою. Дозволено будь-яку початкову версію ресурсу. Можливо, що watch почнеться на набагато старішій версії ресурсу, яку клієнт раніше спостерігав, особливо в конфігураціях високої доступності через розділи або застарілі кеші. Клієнти, які не можуть терпіти таке відмотування назад, не повинні починати watch з цією семантикою. Для встановлення початкового стану, watch починається з синтетичних подій "Added" для всіх екземплярів ресурсів, які існують на початковій версії ресурсу. Усі наступні події watch стосуються всіх змін, що сталися після початкової версії ресурсу, з якої почався watch.
Отримати стан і почати з найновішого
Почати watch на найбільш новій версії ресурсу, яка повинна бути консистентною (детально: обслуговується з etcd за допомогою отримання кворуму). Для встановлення початкового стану watch починається з синтетичних подій "Added" для всіх екземплярів ресурсів, які існують на початковій версії ресурсу. Усі наступні події watch стосуються всіх змін, що сталися після початкової версії ресурсу, з якої почався watch.
Почати точно з
Почати watch на точній версії ресурсу. Події watch стосуються всіх змін після наданої версії ресурсу. На відміну від "Отримати стан і почати з найновішого" та "Отримати стан і почати з будь-якого", watch не починається з синтетичних подій "Added" для наданої версії ресурсу. Вважається, що клієнт вже має початковий стан на стартовій версії ресурсу, оскільки клієнт надав цю версію ресурсу.

Відповіді "410 Gone"

Сервери не зобовʼязані зберігати всі старі версії ресурсів і можуть повернути код HTTP 410 (Gone), якщо клієнт запитує resourceVersion, який старіший, ніж версія, збережена сервером. Клієнти повинні бути готові обробляти відповіді 410 (Gone). Дивіться розділ Ефективне виявлення змін для отримання додаткової інформації про те, як обробляти відповіді 410 (Gone) при спостереженні за ресурсами.

Якщо ви запитуєте resourceVersion, який знаходиться за межами допустимого діапазону, то, залежно від того, чи обслуговується запит з кешу чи ні, API-сервер може відповісти HTTP-відповіддю 410 Gone.

Недоступні версії ресурсів

Сервери не зобовʼязані обслуговувати нерозпізнані версії ресурсів. Якщо ви запитуєте list або get для версії ресурсу, яку API-сервер не розпізнає, то API-сервер може або:

  • почекати трохи, поки версія ресурсу не стане доступною, а потім завершити з тайм-аутом і відповіддю 504 (Gateway Timeout), якщо надана версія ресурсу не стане доступною в розумний термін;
  • відповісти заголовком Retry-After, вказуючи, через скільки секунд клієнт повинен повторити запит.

Якщо ви запитуєте версію ресурсу, яку API-сервер не розпізнає, kube-apiserver додатково ідентифікує свої відповіді на помилки повідомленням "Too large resource version".

Якщо ви робите запит watch для нерозпізнаної версії ресурсу, API-сервер може чекати невизначений час (до тайм-ауту запиту), поки версія ресурсу не стане доступною.


  1. Ідемпотентність означає, що ви можете повторно виконати операцію без змін у стані системи. https://uk.wikipedia.org/wiki/Ідемпотентність ↩︎

6.2.2 - Server-Side Apply

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.22 [stable]

Kubernetes підтримує співпрацю кількох аплікаторів для керування полями одного обʼєкта.

Server-Side Apply (Серверне застосування) надає необовʼязковий механізм для контролера вашого кластера, щоб відстежувати зміни в полях обʼєкта. На рівні конкретного ресурсу, Server-Side Apply записує та відстежує інформацію про контроль над полями цього обʼєкта.

Server-Side Apply допомагає користувачам та контролерам керувати своїми ресурсами за допомогою декларативної конфігурації. Клієнти можуть створювати та змінювати обʼєкти декларативно, подаючи їх повністю визначений намір.

Повністю визначений намір — це частковий обʼєкт, який містить лише ті поля та значення, щодо яких у користувача є чітке уявлення. Цей намір або створює новий обʼєкт (використовуючи стандартні значення для невизначених полів), або обʼєднується з наявним обʼєктом через API сервер.

Порівняння з Client-Side Apply пояснює, як Server-Side Apply відрізняється від початкової реалізації kubectl apply на стороні клієнта.

Управління полями

Kubernetes API сервер відстежує керовані поля для всіх новостворених обʼєктів.

При спробі застосувати обʼєкт, поля, які мають інше значення і належать іншому менеджеру, спричинять конфлікт. Це зроблено для того, щоб сигналізувати, що операція може скасувати зміни іншого спільника. Записи до обʼєктів з керованими полями можуть бути примусовими, в такому випадку значення будь-якого конфліктного поля буде перезаписане, а право власності передане.

Кожного разу, коли значення поля змінюється, право власності переходить від поточного менеджера до менеджера, що здійснює зміну.

Операція застосування перевіряє, чи є інші менеджери полів, які також володіють полем. Якщо поле не належить жодному іншому менеджеру полів, це поле встановлюється на стандартне значення (якщо таке є), або видаляється з обʼєкта. Те саме правило застосовується до полів, які є списками, асоціативними списками або map.

Для того, щоб користувач міг керувати полем в контексті Server-Side Apply, він повинен покладатися на те, що значення поля не зміниться. Користувач, який останнім висловив свою думку щодо значення поля, буде записаний як поточний менеджер поля. Це можна зробити, змінивши дані менеджера поля явним чином за допомогою HTTP POST (створення), PUT (оновлення), або не-застосувального PATCH (патч). Ви також можете оголосити та записати менеджера поля, включивши значення для цього поля в операції Server-Side Apply.

Запит на патч в контексті Server-Side Apply вимагає від клієнта вказати свою ідентичність як менеджера поля. При використанні Server-Side Apply спроба змінити поле, що контролюється іншим менеджером, призведе до відхилення запиту, якщо клієнт не виконає примусове перевизначення. Для деталей щодо примусових перевизначень дивіться Конфлікти.

Коли два або більше аплікатора встановлюють поле на однакове значення, вони спільно володіють цим полем. Будь-яка спроба змінити значення спільного поля будь-ким з аплікаторів призведе до конфлікту. Спільні власники поля можуть відмовитися від права власності на поле, здійснивши запит на патч в контексті Server-Side Apply, який не включає це поле.

Деталі управління полями зберігаються в полі managedFields, яке є частиною metadata обʼєкта.

Якщо ви видалите поле з маніфесту і застосуєте цей маніфест, Server-Side Apply перевірить, чи є інші менеджери полів, які також володіють цим полем. Якщо поле не належить жодному іншому менеджеру полів, воно буде або видалене з поточного обʼєкта, або скинуте до стандартного значення, якщо таке є. Те саме правило застосовується до елементів асоціативного списку або map.

У порівнянні з (застарілою) kubectl.kubernetes.io/last-applied-configuration анотацією, яка управляється kubectl, Server-Side Apply використовує більш декларативний підхід, який відстежує управління полями користувача (або клієнта), а не останній застосований стан користувача. Побічним ефектом використання Server-Side Apply є також доступність інформації про те, який менеджер поля управляє кожним полем в обʼєкті.

Приклад

Простий приклад обʼєкта, створеного за допомогою Server-Side Apply, може виглядати так:

---
apiVersion: v1
kind: ConfigMap
metadata:
  name: test-cm
  namespace: default
  labels:
    test-label: test
  managedFields:
  - manager: kubectl
    operation: Apply # зверніть увагу на великі літери: "Apply" (або "Update")
    apiVersion: v1
    time: "2010-10-10T0:00:00Z"
    fieldsType: FieldsV1
    fieldsV1:
      f:metadata:
        f:labels:
          f:test-label: {}
      f:data:
        f:key: {}
data:
  key: some value

Цей приклад обʼєкта ConfigMap містить один запис про управління полями в .metadata.managedFields. Запис управління полями складається з основної інформації про саму сутність, що виконує управління, а також з деталей про поля, якими управляють, та відповідну операцію (Apply або Update). Якщо запит, що останнім змінив це поле, був патчем Server-Side Apply, тоді значення operation буде Apply; в іншому випадку, це буде Update.

Є ще один можливий результат. Клієнт може подати недійсний запит. Якщо повністю зазначений намір не створює дійсний обʼєкт, запит не вдасться виконати.

Однак, можливо змінити .metadata.managedFields за допомогою операції оновлення або патчу, які не використовують Server-Side Apply. Це наполегливо не рекомендується, але може бути доцільно спробувати, якщо, наприклад, .metadata.managedFields потрапить у неконсистентний стан (що не повинно відбуватися при нормальній роботі).

Формат managedFields описаний у довіднику API Kubernetes.

Конфлікти

Конфлікт — це спеціальна помилка статусу, яка виникає, коли операція Apply намагається змінити поле, на яке інший менеджер також заявляє права на керування. Це запобігає ненавмисному перезапису значення, встановленого іншим користувачем. У разі конфлікту аплікатор має 3 варіанти для вирішення конфліктів:

  • Перезаписати значення, стати єдиним менеджером: Якщо перезапис значення був навмисним (або якщо аплікатор є автоматичним процесом, таким як контролер), аплікатор повинен встановити параметр запиту force в true (для kubectl apply використовується параметр командного рядка --force-conflicts) і повторити запит. Це змусить операцію завершитись успішно, змінить значення поля та видалить це поле з усіх інших записів менеджерів у managedFields.

  • Не перезаписувати значення, відмовитися від права управління: Якщо аплікатор більше не піклується про значення поля, він може видалити його зі своєї локальної моделі ресурсу і зробити новий запит, виключивши це конкретне поле. Це залишить значення незмінним і видалить поле із запису аплікатора у managedFields.

  • Не перезаписувати значення, стати спільним менеджером: Якщо аплікатор все ще піклується про значення поля, але не хоче його перезаписувати, він може змінити значення цього поля у своїй локальній моделі ресурсу, щоб відповідати значенню обʼєкта на сервері, а потім зробити новий запит, враховуючи це локальне оновлення. Це залишить значення незмінним і зробить це поле керованим спільно аплікатором та всіма іншими менеджерами, які вже заявили про керування ним.

Менеджери полів

Менеджери визначають окремі робочі процеси, які змінюють обʼєкт (особливо корисно при конфліктах!), і можуть бути вказані через параметр запиту fieldManager як частина запиту на зміни. Коли ви застосовуєте зміни до ресурсу, параметр fieldManager є обовʼязковим. Для інших оновлень сервер API визначає ідентифікатор менеджера поля з заголовка HTTP "User-Agent:" (якщо він присутній).

Коли ви використовуєте інструмент kubectl для виконання операції Server-Side Apply, kubectl типово встановлює ідентифікатор менеджера в "kubectl".

Серіалізація

На рівні протоколу Kubernetes представляє тіла повідомлень Server-Side Apply у форматі YAML, з медіа типом application/apply-patch+yaml.

Серіалізація є такою ж, як для обʼєктів Kubernetes, за винятком того, що клієнти не зобовʼязані надсилати повний обʼєкт.

Ось приклад тіла повідомлення Server-Side Apply (повністю специфікований намір):

{
  "apiVersion": "v1",
  "kind": "ConfigMap"
}

(це зробить оновлення без змін, за умови, що це було надіслано як тіло patch запиту до дійсного ресурсу v1/configmaps, з відповідним заголовком запиту Content-Type).

Операції з області управління полями

Операції API Kubernetes, де враховується управління полями, включають:

  1. Server-Side Apply (HTTP PATCH, з типом контенту application/apply-patch+yaml)
  2. Заміна наявного обʼєкта (update для Kubernetes; PUT на рівні HTTP)

Обидві операції оновлюють .metadata.managedFields, але поводяться трохи по-різному.

Якщо не вказано примусове перезаписування, операція apply, що зустрічає конфлікти на рівні полів, завжди зазнає невдачі; у противагу, якщо зміну здійснено за допомогою update, що впливає на кероване поле, конфлікт ніколи не призводить до невдачі операції.

Усі запити Server-Side Apply patch повинні ідентифікувати себе, надаючи параметр запиту fieldManager, тоді як цей параметр запиту є необовʼязковим для операцій update. Нарешті, при використанні операції Apply ви не можете визначати managedFields у тілі запиту, який ви надсилаєте.

Приклад обʼєкта з декількома менеджерами може виглядати так:

---
apiVersion: v1
kind: ConfigMap
metadata:
  name: test-cm
  namespace: default
  labels:
    test-label: test
  managedFields:
  - manager: kubectl
    operation: Apply
    apiVersion: v1
    fields:
      f:metadata:
        f:labels:
          f:test-label: {}
  - manager: kube-controller-manager
    operation: Update
    apiVersion: v1
    time: '2019-03-30T16:00:00.000Z'
    fields:
      f:data:
        f:key: {}
data:
  key: new value

У цьому прикладі друга операція була виконана як update менеджером з назвою kube-controller-manager. Запит на оновлення був успішним і змінив значення в полі даних, що призвело до зміни управління цим полем на kube-controller-manager.

Якби була спроба застосувати це оновлення за допомогою Server-Side Apply, запит зазнав би невдачі через конфлікт управління.

Стратегія злиття

Стратегія злиття, реалізована в Server-Side Apply, забезпечує більш стабільний життєвий цикл обʼєкта. Server-Side Apply намагається обʼєднати поля на основі того, хто ними керує, замість того, щоб замінювати їх значення. Таким чином, кілька акторів можуть оновлювати один і той самий обʼєкт без несподіваних перешкод.

Коли користувач надсилає обʼєкт із повністю специфікованим наміром на точку доступу Server-Side Apply, сервер зʼєднує його з поточним обʼєктом, надаючи перевагу значенню з тіла запиту, якщо воно вказане в обох місцях. Якщо набір елементів, присутніх у застосованій конфігурації, не є надмножиною елементів, застосованих тим самим користувачем минулого разу, кожен відсутній елемент, яким не керують інші аплікатори, видаляється. Для отримання додаткової інформації про те, як схема обʼєкта використовується для прийняття рішень під час злиття, дивіться sigs.k8s.io/structured-merge-diff.

API Kubernetes (та код Go, який реалізує це API для Kubernetes) дозволяє визначати маркери стратегії злиття. Ці маркери описують підтримувану стратегію злиття для полів в обʼєктах Kubernetes. Для CustomResourceDefinition, ви можете встановити ці маркери під час визначення власного ресурсу.

Маркер GolangРозширення OpenAPIМожливі значенняОпис
//+listTypex-kubernetes-list-typeatomic/set/mapЗастосовується до списків. set застосовується до списків, які включають лише скалярні елементи. Ці елементи повинні бути унікальними. map застосовується до списків вкладених типів. Значення ключів (див. listMapKey) повинні бути унікальними в списку. atomic може застосовуватися до будь-якого списку. Якщо налаштовано як atomic, весь список замінюється під час злиття. У будь-який момент часу список належить одному менеджеру. Якщо set або map, різні менеджери можуть окремо керувати елементами.
//+listMapKeyx-kubernetes-list-map-keysСписок імен полів, наприклад, ["port", "protocol"]Застосовується лише при +listType=map. Список імен полів, значення яких унікально ідентифікують елементи у списку. Хоча ключів може бути багато, listMapKey є одниною, тому що ключі потрібно вказувати індивідуально в типі Go. Поля ключів повинні бути скалярами.
//+mapTypex-kubernetes-map-typeatomic/granularЗастосовується до map. atomic означає, що map можна замінити повністю тільки одним менеджером. granular означає, що map підтримує окремих менеджерів, які оновлюють окремі поля.
//+structTypex-kubernetes-map-typeatomic/granularЗастосовується до структур; інакше те ж використання та анотація OpenAPI, як //+mapType.

Якщо listType відсутній, сервер API інтерпретує patchStrategy=merge як listType=map і відповідний маркер patchMergeKey як listMapKey.

Тип списку atomic є рекурсивним.

(У коді Go для Kubernetes, ці маркери вказуються як коментарі, і авторам коду не потрібно повторювати їх як теґи полів).

Власні ресурси та Серверне застосування

Стандартно, Server-Side Apply обробляє власні ресурси користувачів як неструктуровані дані. Усі ключі розглядаються як поля структури, а всі списки вважаються атомарними.

Якщо у визначенні CustomResourceDefinition міститься схема, яка містить анотації, визначені у попередньому розділі Стратегія злиття, ці анотації будуть використовуватись під час злиття обʼєктів цього типу.

Сумісність при зміні топології

У рідкісних випадках автор CustomResourceDefinition (CRD) або вбудованого ресурсу може захотіти змінити специфічну топологію поля у своєму ресурсі, не збільшуючи його версію API. Зміна топології типів шляхом оновлення кластера або CRD має різні наслідки при оновленні наявних обʼєктів. Є дві категорії змін: коли поле переходить від map/set/granular до atomic і навпаки.

Коли listType, mapType або structType змінюються з map/set/granular на atomic, весь список, map або структура наявних обʼєктів будуть в підсумку належати акторам, які володіли елементом цих типів. Це означає, що будь-яка подальша зміна цих обʼєктів призведе до конфлікту.

Коли listType, mapType або structType змінюються з atomic на map/set/granular, сервер API не може визначити нову власність цих полів. Через це конфлікти не виникатимуть під час оновлення обʼєктів із цими полями. Тому не рекомендується змінювати тип із atomic на map/set/granular.

Візьмемо, наприклад, власний ресурс користувача ресурс:

---
apiVersion: example.com/v1
kind: Foo
metadata:
  name: foo-sample
  managedFields:
  - manager: "manager-one"
    operation: Apply
    apiVersion: example.com/v1
    fields:
      f:spec:
        f:data: {}
spec:
  data:
    key1: val1
    key2: val2

До того, як spec.data зміниться з atomic на granular, manager-one володіє полем spec.data і всіма полями в ньому (key1 та key2). Коли CRD змінюється, щоб зробити spec.data granular, manager-one продовжує володіти полем верхнього рівня spec.data (що означає, що жоден інший менеджер не може видалити map data без конфлікту), але він більше не володіє key1 та key2, тому інший менеджер може змінити або видалити ці поля без конфлікту.

Використання Server-Side Apply в контролер

Як розробник контролера, ви можете використовувати Server-Side Apply як спосіб спростити логіку оновлення вашого контролера. Основні відмінності від кead-modify-write та/або patch наступні:

  • застосований обʼєкт повинен містити всі поля, які цікавлять контролер.
  • немає способу видалити поля, які не були застосовані контролером раніше (контролер все ще може надіслати patch або update для цих випадків використання).
  • обʼєкт не обовʼязково має бути прочитаним перед тим; resourceVersion не потрібно вказувати.

Для контролерів рекомендується завжди застосовувати конфлікти на обʼєктах, якими вони володіють і керують, оскільки вони можуть не мати можливості розвʼязати або подіяти на ці конфлікти.

Передача власності

Окрім контролю конкурентності, забезпеченого вирішенням конфліктів, Server-Side Apply надає можливості для виконання координованих переходів власності полів від користувачів до контролерів.

Це найкраще пояснюється на прикладі. Розглянемо, як безпечно перевести власність поля replicas від користувача до контролера, дозволяючи автоматичне горизонтальне масштабування для Deployment, використовуючи ресурс HorizontalPodAutoscaler та його супровідний контролер.

Скажімо, користувач визначив Deployment з replicas, встановленим на бажане значення:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2

І користувач створив Deployment, використовуючи Server-Side Apply, наступним чином:

kubectl apply -f https://k8s.io/examples/application/ssa/nginx-deployment.yaml --server-side

Пізніше автоматичне масштабування увімкнено для Deployment; наприклад:

kubectl autoscale deployment nginx-deployment --cpu-percent=50 --min=1 --max=10

Тепер користувач хоче видалити replicas з конфігурації, щоб вони випадково не конфліктували з HorizontalPodAutoscaler (HPA) та його контролером. Однак виникають перегони: може пройти деякий час, перш ніж HPA вирішить змінити .spec.replicas; якщо користувач видаляє .spec.replicas перед тим, як HPA запише в поле і стане його власником, тоді API-сервер встановить .spec.replicas на 1 (стандартна кількість реплік для Deployment). Це не те, що хоче користувач, ще й тимчасово — це може погіршити робоче навантаження.

Є два рішення:

  • (базовий) Залиште replicas в конфігурації; коли HPA нарешті запише в це поле, система сповістить користувачу про конфлікт при спробі зробити це. На цьому етапі безпечно видалити його з конфігурації.

  • (більш розширений) Однак, якщо користувач не хоче чекати, наприклад, через те що вони хочуть, щоб кластер був зрозумілим для їх колег, тоді вони можуть виконати наступні кроки, щоб зробити видалення replicas з їх конфігурації безпечним:

Спочатку користувач визначає новий маніфест, що містить лише поле replicas:

# Збережіть цей файл як 'nginx-deployment-replicas-only.yaml'.
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3

Користувач застосовує цей маніфест, використовуючи приватне імʼя менеджера полів. У цьому прикладі користувач вибрав handover-to-hpa:

kubectl apply -f nginx-deployment-replicas-only.yaml \
  --server-side --field-manager=handover-to-hpa \
  --validate=false

Якщо застосування призводить до конфлікту з контролером HPA, тоді нічого не робіть. Конфлікт вказує на те, що контролер вже вимагає поле на цьому етапі.

На цьому етапі користувач може видалити поле replicas з маніфесту:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2

Зауважте, що кожного разу, коли контролер HPA встановлює значення поля replicas на нове значення, тимчасовий менеджер полів більше не володіє жодними полями й буде автоматично видалений. Додаткового прибирання не потрібно.

Передача власності між менеджерами

Менеджери полів можуть передавати власність поля між собою, встановлюючи значення поля в тому самому значенні в обох їх застосованих конфігураціях, що призводить до того, що вони спільно володіють полем. Після цього менеджери можуть відмовитися від володіння полям та завершити передачу іншому менеджеру поля, видаливши поле з їх застосованої конфігурації.

Порівняння з Client-Side Apply

Server-Side Apply призначений як для заміни початкової реалізації команди kubectl apply на стороні клієнта, так і для забезпечення простого та ефективного механізму для контролерів, щоб впроваджувати свої зміни.

Порівняно з анотацією last-applied, якою керує kubectl, Server-Side Apply використовує більш декларативний підхід, що відстежує управління полями обʼєкта, а не останній стан, застосований користувачем. Це означає, що як побічний ефект використання Server-Side Apply, стає доступною інформація про те, який менеджер полів керує кожним полем в обʼєкті.

Наслідком виявлення та вирішення конфліктів, реалізованих у Server-Side Apply, є те, що аплікатор завжди має актуальні значення полів у своєму локальному стані. Якщо ні, то він отримає конфлікт під час наступного застосування. Будь-який з трьох варіантів розвʼязання конфліктів призводить до того, що застосована конфігурація стає актуальною підмножиною полів обʼєкта на сервері.

Це відрізняється від Client-Side Apply, де застарілі значення, які були перезаписані іншими користувачами, залишаються в локальній конфігурації аплікатора. Ці значення стають точними лише тоді, коли користувач оновлює конкретне поле, якщо взагалі оновлює, і аплікатор не має способу дізнатися, чи наступне застосування перезапише зміни інших користувачів.

Ще однією відмінністю є те, що аплікатор, використовуючи Client-Side Apply, не може змінити версію API, яку він використовує, тоді як Server-Side Apply підтримує цей випадок використання.

Міграція між client-side і server-side apply

Перехід з client-side apply на server-side apply

Користувачі client-side apply, які керують ресурсом за допомогою kubectl apply, можуть почати використовувати server-side apply з наступним прапорцем.

kubectl apply --server-side [--dry-run=server]

Стандартно, управління полями обʼєкта переходить з client-side apply на kubectl server-side apply без виникнення конфліктів.

Ця поведінка стосується server-side apply з менеджером полів kubectl. Як виняток, ви можете відмовитися від цієї поведінки, вказавши іншого, не стандартного менеджера полів, як показано в наступному прикладі. Стандартним менеджером полів для kubectl server-side apply є kubectl.

kubectl apply --server-side --field-manager=my-manager [--dry-run=server]

Повернення з server-side apply на client-side apply

Якщо ви керуєте ресурсом за допомогою kubectl apply --server-side, ви можете перейти на client-side apply безпосередньо за допомогою kubectl apply.

Повернення працює тому, що kubectl Server-Side Apply тримає анотацію last-applied-configuration в актуальному стані, якщо ви використовуєте kubectl apply.

Ця поведінка стосується Server-Side Apply з менеджером полів kubectl. Як виняток, ви можете відмовитися від цієї поведінки, вказавши іншого, не стандартного менеджера полів, як показано в наступному прикладі. Стандартним менеджером полів для kubectl server-side apply є kubectl.

kubectl apply --server-side --field-manager=my-manager [--dry-run=server]

Реалізація API

Дієслово PATCH для ресурсу, який підтримує Server-Side Apply, може приймати неофіційний тип контенту application/apply-patch+yaml. Користувачі Server-Side Apply можуть надіслати частково специфіковані обʼєкти у вигляді YAML як тіло запиту PATCH до URI ресурсу. При застосуванні конфігурації слід завжди включати всі поля, які є важливими для результату (наприклад, бажаний стан), який ви хочете визначити.

Усі повідомлення в форматі JSON є дійсним YAML. Деякі клієнти вказують запити Server-Side Apply, використовуючи тіла запитів у форматі YAML, які також є дійсним JSON.

Контроль доступу і дозволи

Оскільки Server-Side Apply є типом PATCH, субʼєкт (такий як Роль для Kubernetes RBAC) потребує дозволу patch для редагування наявних ресурсів, а також дозволу на дієслово create для створення нових ресурсів за допомогою Server-Side Apply.

Очищення managedFields

Можливо видалити всі managedFields з обʼєкта, переписавши їх за допомогою patch (JSON Merge Patch, Strategic Merge Patch, JSON Patch) або через update (HTTP PUT); іншими словами, через будь-яку операцію запису, окрім apply. Це можна зробити, переписавши поле managedFields порожнім записом. Два приклади:

PATCH /api/v1/namespaces/default/configmaps/example-cm
Accept: application/json
Content-Type: application/merge-patch+json

{
  "metadata": {
    "managedFields": [
      {}
    ]
  }
}
PATCH /api/v1/namespaces/default/configmaps/example-cm
Accept: application/json
Content-Type: application/json-patch+json
If-Match: 1234567890123456789

[{"op": "replace", "path": "/metadata/managedFields", "value": [{}]}]

Це перепише managedFields списком, що містить один порожній запис, що в результаті повністю видалить managedFields з обʼєкта. Зверніть увагу, що встановлення managedFields як порожнього списку не скине це поле. Це зроблено спеціально, щоб managedFields ніколи не видалялися клієнтами, які не знають про це поле.

У випадках, коли операція скидання комбінується зі змінами інших полів, крім managedFields, це призведе до того, що спочатку managedFields буде скинуто, а інші зміни будуть оброблені пізніше. У результаті аплікатор бере на себе відповідальність за будь-які поля, оновлені в тому ж запиті.

Що далі

Ви можете прочитати про managedFields у довіднику API Kubernetes для верхнього рівня поля metadata.

6.2.3 - Бібліотеки клієнтів

Ця сторінка містить огляд бібліотек клієнтів для використання Kubernetes API різними мовами програмування.

Для написання застосунків, що використовують Kubernetes REST API, вам не потрібно самостійно реалізовувати виклики API та типи запитів/відповідей. Ви можете використовувати бібліотеку клієнтів для мови програмування, яку ви використовуєте.

Бібліотеки клієнтів часто виконують загальні завдання, такі як автентифікація. Більшість бібліотек клієнтів можуть знаходити та використовувати Kubernetes Service Account для автентифікації, якщо API клієнт працює всередині кластера Kubernetes, або можуть розуміти формат kubeconfig файлу для читання облікових даних та адреси API сервера.

Офіційно підтримувані бібліотеки клієнтів Kubernetes

Наступні бібліотеки клієнтів офіційно підтримуються Kubernetes SIG API Machinery.

МоваБібліотека клієнтівПриклад програм
Cgithub.com/kubernetes-client/cпереглянути
dotnetgithub.com/kubernetes-client/csharpпереглянути
Gogithub.com/kubernetes/client-go/переглянути
Haskellgithub.com/kubernetes-client/haskellпереглянути
Javagithub.com/kubernetes-client/javaпереглянути
JavaScriptgithub.com/kubernetes-client/javascriptпереглянути
Perlgithub.com/kubernetes-client/perl/переглянути
Pythongithub.com/kubernetes-client/python/переглянути
Rubygithub.com/kubernetes-client/ruby/переглянути

Бібліотеки клієнтів, що підтримуються спільнотою

Наступні бібліотеки клієнтів Kubernetes надаються і підтримуються їх авторами, а не командою Kubernetes.

МоваБібліотека клієнтів
Clojuregithub.com/yanatan16/clj-kubernetes-api
DotNetgithub.com/tonnyeremin/kubernetes_gen
DotNet (RestSharp)github.com/masroorhasan/Kubernetes.DotNet
Elixirgithub.com/obmarg/kazan
Elixirgithub.com/coryodaniel/k8s
Java (OSGi)bitbucket.org/amdatulabs/amdatu-kubernetes
Java (Fabric8, OSGi)github.com/fabric8io/kubernetes-client
Javagithub.com/manusa/yakc
Lispgithub.com/brendandburns/cl-k8s
Lispgithub.com/xh4/cube
Node.js (TypeScript)github.com/Goyoo/node-k8s-client
Node.jsgithub.com/ajpauwels/easy-k8s
Node.jsgithub.com/godaddy/kubernetes-client
Node.jsgithub.com/tenxcloud/node-kubernetes-client
Perlmetacpan.org/pod/Net::Kubernetes
PHPgithub.com/allansun/kubernetes-php-client
PHPgithub.com/maclof/kubernetes-client
PHPgithub.com/travisghansen/kubernetes-client-php
PHPgithub.com/renoki-co/php-k8s
Pythongithub.com/fiaas/k8s
Pythongithub.com/gtsystem/lightkube
Pythongithub.com/kr8s-org/kr8s
Pythongithub.com/mnubo/kubernetes-py
Pythongithub.com/tomplus/kubernetes_asyncio
Pythongithub.com/Frankkkkk/pykorm
Rubygithub.com/abonas/kubeclient
Rubygithub.com/k8s-ruby/k8s-ruby
Rubygithub.com/kontena/k8s-client
Rustgithub.com/kube-rs/kube
Rustgithub.com/ynqa/kubernetes-rust
Scalagithub.com/hagay3/skuber
Scalagithub.com/hnaderi/scala-k8s
Scalagithub.com/joan38/kubernetes-client
Swiftgithub.com/swiftkube/client

6.2.4 - Загальна мова виразів у Kubernetes

Загальна мова виразів (Common Expression Language, CEL) використовується в API Kubernetes для оголошення правил валідації, політик та інших обмежень чи умов.

Вирази CEL оцінюються безпосередньо на сервері API, що робить CEL зручним альтернативним рішенням для зовнішніх механізмів, таких як вебхуки, для багатьох випадків розширення функціональності. Ваші вирази CEL продовжують виконуватись, поки компонент сервера API у складі панелі управління залишається доступним.

Огляд мови

Мова CEL має простий синтаксис, який схожий на вирази в C, C++, Java, JavaScript і Go.

CEL була розроблена для вбудовування в застосунки. Кожна "програма" CEL — це один вираз, який обраховується до одного значення. Вирази CEL зазвичай короткі "одноразові", що добре вбудовуються в строкові поля ресурсів API Kubernetes.

Вхідні дані для програми CEL — це "змінні". Кожне поле API Kubernetes, яке містить CEL, декларує в документації API, які змінні доступні для використання для цього поля. Наприклад, у полі x-kubernetes-validations[i].rules у CustomResourceDefinitions доступні змінні self і oldSelf, що відносяться до попереднього та поточного стану даних власного ресурсу користувача, які потрібно перевірити за допомогою виразу CEL. Інші поля API Kubernetes можуть оголошувати різні змінні. Дивіться документацію API для полів API, щоб дізнатися, які змінні доступні для цього поля.

Приклади виразів CEL:

Приклади виразів CEL та їх призначення
ПравилоПризначення
self.minReplicas <= self.replicas && self.replicas <= self.maxReplicasПеревірити, що три поля, що визначають репліки, розташовані в правильному порядку
'Available' in self.stateCountsПеревірити, що в map існує запис з ключем 'Available'
(self.list1.size() == 0) != (self.list2.size() == 0)Перевірити, що один із двох списків не порожній, але не обидва одночасно
self.envars.filter(e, e.name = 'MY_ENV').all(e, e.value.matches('^[a-zA-Z]*$'))Перевірити поле 'value' у запису listMap, де поле ключа 'name' дорівнює 'MY_ENV'
has(self.expired) && self.created + self.ttl < self.expiredПеревірити, що дата 'expired' є пізніше дати 'created' плюс тривалість 'ttl'
self.health.startsWith('ok')Перевірити, що строкове поле 'health' має префікс 'ok'
self.widgets.exists(w, w.key == 'x' && w.foo < 10)Перевірити, що властивість 'foo' елемента listMap з ключем 'x' менше 10
type(self) == string ? self == '99%' : self == 42Перевірити поле типу int-або-string для обох випадків: int та string
self.metadata.name == 'singleton'Перевірити, що імʼя обʼєкта відповідає конкретному значенню (робить його унікальним)
self.set1.all(e, !(e in self.set2))Перевірити, що два списки (listSets) не перетинаються
self.names.size() == self.details.size() && self.names.all(n, n in self.details)Перевірити, що map 'details' має ключі, які відповідають елементам у списку 'names'
self.details.all(key, key.matches('^[a-zA-Z]*$'))Перевірити ключі map 'details'
self.details.all(key, self.details[key].matches('^[a-zA-Z]*$'))Перевірити значення map 'details'

Опції CEL, особливості мови та бібліотеки

CEL налаштовується з наступними опціями, бібліотеками та особливостями мови, введеними у зазначених версіях Kubernetes:

Опція, бібліотека або особливість мови CELВключеноДоступність
Стандартні макросиhas, all, exists, exists_one, map, filterУсі версії Kubernetes
Стандартні функціїДивіться офіційний список стандартних визначеньУсі версії Kubernetes
Однорідні агрегаційні літералиУсі версії Kubernetes
Часовий пояс UTC за замовчуваннямУсі версії Kubernetes
Рання перевірка деклараційУсі версії Kubernetes
бібліотека розширених рядків, Версія 1charAt, indexOf, lastIndexOf, lowerAscii, upperAscii, replace, split, join, substring, trimУсі версії Kubernetes
Бібліотека списків KubernetesДивіться бібліотеку списків KubernetesУсі версії Kubernetes
Бібліотека регулярних виразів KubernetesДивіться бібліотеку регулярних виразів KubernetesУсі версії Kubernetes
Бібліотека URL KubernetesДивіться бібліотеку URL KubernetesУсі версії Kubernetes
Бібліотека авторизації KubernetesДивіться бібліотеку авторизації KubernetesУсі версії Kubernetes
Бібліотека кількостей KubernetesДивіться бібліотеку кількостей KubernetesВерсії Kubernetes 1.29+
Опційні типи CELДивіться опційні типи CELВерсії Kubernetes 1.29+
Порівняння чисел різних типів CELДивіться порівняння чисел різних типів CELВерсії Kubernetes 1.29+

Функції CEL, особливості та налаштування мови підтримують відкат панелі управління Kubernetes. Наприклад, опційні значення CEL були введені у Kubernetes 1.29, і лише сервери API цієї версії або новіші прийматимуть запити на запис виразів CEL, які використовують опційні значення CEL. Однак, коли кластер відкочується до версії Kubernetes 1.28, вирази CEL, що використовують "опційні значення CEL", які вже збережені в ресурсах API, продовжуватимуть правильно оцінюватись.

Бібліотеки CEL Kubernetes

Крім спільнотних бібліотек CEL, Kubernetes включає бібліотеки CEL, які доступні у всіх місцях використання CEL в Kubernetes.

Бібліотека списків Kubernetes

Бібліотека списків включає indexOf та lastIndexOf, які працюють аналогічно функціям рядків з такими самими назвами. Ці функції повертають перший або останній індекс елемента у списку.

Бібліотека списків також включає min, max та sum. Сума підтримується для всіх типів чисел, а також для типу тривалості. Мінімум та максимум підтримуються для всіх типів, що можна порівняти.

Також надається функція isSorted для зручності та підтримується для всіх типів, які можна порівняти.

Приклади:

Приклади виразів CEL, що використовують функції бібліотеки списків
Вираз CELПризначення
names.isSorted()Перевірити, що список імен зберігається в алфавітному порядку
items.map(x, x.weight).sum() == 1.0Перевірити, що "ваги" списку обʼєктів дорівнюють 1.0
lowPriorities.map(x, x.priority).max() < highPriorities.map(x, x.priority).min()Перевірити, що два набори пріоритетів не перекриваються
names.indexOf('should-be-first') == 1Вимагати, щоб перше імʼя у списку було певним значенням

Для отримання додаткової інформації дивіться бібліотеку списків Kubernetes godoc.

Бібліотека регулярних виразів Kubernetes

Крім функції matches, наданої стандартною бібліотекою CEL, бібліотека регулярних виразів надає функції find та findAll, що дозволяють виконувати ширший спектр операцій з регулярними виразами.

Приклади:

Приклади виразів CEL, що використовують функції бібліотеки регулярних виразів
Вираз CELПризначення
"abc 123".find('[0-9]+')Знайти перше число у рядку
"1, 2, 3, 4".findAll('[0-9]+').map(x, int(x)).sum() < 100Перевірити, що сума чисел у рядку менше 100

Для отримання додаткової інформації дивіться бібліотеку регулярних виразів Kubernetes godoc.

Бібліотека URL Kubernetes

Для спрощення та безпечної обробки URL надані наступні функції:

  • isURL(string) перевіряє, чи є рядок рядком дійсним URL з пакетом Go net/url. Рядок повинен бути абсолютним URL.
  • url(string) URL конвертує рядок в URL або викликає помилку, якщо рядок не є дійсним URL.

Після розбору за допомогою функції url, отриманий обʼєкт URL має наступні методи доступу: getScheme, getHost, getHostname, getPort, getEscapedPath та getQuery.

Приклади:

Приклади виразів CEL, що використовують функції бібліотеки URL
Вираз CELПризначення
url('https://example.com:80/').getHost()Отримати частину хосту 'example.com:80' URL.
url('https://example.com/path with spaces/').getEscapedPath()Повертає '/path%20with%20spaces/'

Для отримання додаткової інформації дивіться бібліотеку URL Kubernetes godoc.

Бібліотека авторизатора Kubernetes

Для виразів CEL в API, де доступна змінна типу Authorizer, авторизатор може використовуватися для виконання перевірок авторизації для принципала (автентифікованого користувача) запиту.

Перевірки ресурсів API виконуються наступним чином:

  1. Вкажіть групу та ресурс для перевірки: Authorizer.group(string).resource(string) ResourceCheck.

  2. Опційно викличте будь-яку комбінацію наступних функцій побудови для подальшого обмеження перевірки авторизації. Зверніть увагу, що ці функції повертають тип отримувача та можуть бути зʼєднані ланцюгом:

    • ResourceCheck.subresource(string) ResourceCheck
    • ResourceCheck.namespace(string) ResourceCheck
    • ResourceCheck.name(string) ResourceCheck
  3. Викличте ResourceCheck.check(verb string) Decision, щоб виконати перевірку авторизації.

  4. Викличте allowed() bool або reason() string, щоб переглянути результат перевірки авторизації.

Не-ресурсна авторизація виконується так:

  1. Вкажіть лише шлях: Authorizer.path(string) PathCheck.
  2. Викличте PathCheck.check(httpVerb string) Decision, щоб виконати перевірку авторизації.
  3. Викличте allowed() bool або reason() string, щоб переглянути результат перевірки авторизації.

Для виконання перевірки авторизації для службового облікового запису:

  • Authorizer.serviceAccount(namespace string, name string) Authorizer
Приклади виразів CEL, що використовують функції бібліотеки авторизатора
Вираз CELПризначення
authorizer.group('').resource('pods').namespace('default').check('create').allowed()Повертає true, якщо принципалу (користувачу або службовому обліковому запису) дозволено створювати Podʼи у просторі імен 'default'.
authorizer.path('/healthz').check('get').allowed()Перевіряє, чи авторизований принципал (користувач або службовий обліковий запис) виконує HTTP GET-запити до шляху API /healthz.
authorizer.serviceAccount('default', 'myserviceaccount').resource('deployments').check('delete').allowed()Перевіряє, чи службовий обліковий запис має дозвіл на видалення deployments.
СТАН ФУНКЦІОНАЛУ: Kubernetes v1.31 [alpha]

З увімкненою альфа-функцією AuthorizeWithSelectors, до перевірок авторизації можна додавати селектори полів і міток.

Приклади CEL виразів із використанням функцій авторизації для селекторів
CEL виразПризначення
authorizer.group('').resource('pods').fieldSelector('spec.nodeName=mynode').check('list').allowed()Повертає true, якщо користувач або службовий обліковий запис має дозвіл на отримання списку Podʼів із селектором полів spec.nodeName=mynode.
authorizer.group('').resource('pods').labelSelector('example.com/mylabel=myvalue').check('list').allowed()Повертає true, якщо користувач або службовий обліковий запис має дозвіл на отримання списку Podʼів із селектором міток example.com/mylabel=myvalue.

Для отримання додаткової інформації дивіться бібліотеку Kubernetes Authz та бібліотеку Kubernetes AuthzSelectors godoc.

Бібліотека кількості Kubernetes

У Kubernetes 1.28 додана підтримка обробки рядків кількості (наприклад, 1,5G, 512k, 20Mi).

  • isQuantity(string) перевіряє, чи є рядок дійсною кількістю відповідно до Кількості ресурсів Kubernetes.
  • quantity(string) Quantity конвертує рядок у кількість або викликає помилку, якщо рядок не є дійсною кількістю.

Після розбору за допомогою функції quantity, отриманий обʼєкт кількості має наступний набір методів:

Набір доступних методів для кількості
МетодПовертає типОпис
isInteger()boolПовертає true, якщо asInteger може бути викликано без помилки.
asInteger()intПовертає представлення поточного значення як int64, якщо це можливо, або викликає помилку, якщо конвертація призводить до переповнення або втрати точності.
asApproximateFloat()floatПовертає представлення кількості як float64, що може втратити точність.
sign()intПовертає 1, якщо кількість додатня, -1, якщо вона відʼємна, або 0, якщо вона нуль.
add(<Quantity>)QuantityПовертає суму двох кількостей.
add(<int>)QuantityПовертає суму кількості та цілого числа.
sub(<Quantity>)QuantityПовертає різницю між двома кількостями.
sub(<int>)QuantityПовертає різницю між кількістю та цілим числом.
isLessThan(<Quantity>)boolПовертає true, якщо отримувач менше операнта.
isGreaterThan(<Quantity>)boolПовертає true, якщо отримувач більше операнта.
compareTo(<Quantity>)intПорівнює отримувача з операндом та повертає 0, якщо вони рівні, 1, якщо отримувач більший або -1, якщо отримувач менший за операнд.

Приклади:

Приклади виразів CEL, що використовують функції бібліотеки кількості
Вираз CELПризначення
quantity("500000G").isInteger()Перевірка, чи конвертація в ціле число викликає помилку.
quantity("50k").asInteger()Точна конвертація в ціле число.
quantity("9999999999999999999999999999999999999G").asApproximateFloat()Втратна конвертація в плаваючий рядок.
quantity("50k").add(quantity("20k"))Додати дві кількості.
quantity("50k").sub(20000)Відняти ціле число від кількості.
quantity("50k").add(20).sub(quantity("100k")).sub(-50000)Ланцюгове додавання та віднімання цілих чисел та кількостей.
quantity("200M").compareTo(quantity("0.2G"))Порівняти дві кількості.
quantity("150Mi").isGreaterThan(quantity("100Mi"))Перевірити, чи кількість більша за отримувача.
quantity("50M").isLessThan(quantity("100M"))Перевірити, чи кількість менша за отримувача.

Перевірка типів

CEL — це поступово типізована мова.

Деякі поля API Kubernetes містять повністю перевірені типи CEL-виразів. Наприклад, Правила валідації власних ресурсів повністю перевірені за типом.

Деякі поля API Kubernetes містять частково перевірені типи CEL-виразів. Частково перевірений вираз — це вираз, в якому деякі змінні статично типізовані, а інші — динамічно типізовані. Наприклад, в CEL-виразах ValidatingAdmissionPolicies, змінна request має тип, але змінна object динамічно типізована. У звʼязку з цим вираз, що містить request.namex, не пройде перевірку типів, оскільки поле namex не визначене. Однак object.namex пройде перевірку типів навіть тоді, коли поле namex не визначене для типів ресурсів, на які посилається object, оскільки object динамічно типізований.

Макрос has() в CEL можна використовувати у виразах CEL для перевірки доступності поля динамічно типізованої змінної перед спробою доступу до значення поля. Наприклад:

has(object.namex) ? object.namex == 'special' : request.name == 'special'

Інтеграція системи типів

Таблиця, що показує взаємозвʼязок між типами OpenAPIv3 та CEL
Тип OpenAPIv3Тип CEL
'object' з Propertiesobject / "тип повідомлення" (type(<object>) обчислюється як selfType<uniqueNumber>.path.to.object.from.self
'object' з AdditionalPropertiesmap
'object' з x-kubernetes-embedded-typeobject / "тип повідомлення", 'apiVersion', 'kind', 'metadata.name' і 'metadata.generateName' включені в схему
'object' з x-kubernetes-preserve-unknown-fieldsobject / "тип повідомлення", невідомі поля НЕ доступні у виразі CEL
x-kubernetes-int-or-stringобʼєднання int або string, self.intOrString < 100 || self.intOrString == '50%' обчислюється як true для 50 і "50%"
'array'list
'array' з x-kubernetes-list-type=maplist з базованими на map рівноправністю та унікальними ключами
'array' з x-kubernetes-list-type=setlist з базованими на set рівноправністю та унікальними елементами
'boolean'boolean
'number' (усі формати)double
'integer' (усі формати)int (64)
немає еквівалентаuint (64)
'null'null_type
'string'string
'string' з format=byte (base64 encoded)bytes
'string' з format=datetimestamp (google.protobuf.Timestamp)
'string' з format=datetimetimestamp (google.protobuf.Timestamp)
'string' з format=durationduration (google.protobuf.Duration)

Також дивіться: Типи CEL, Типи OpenAPI, Структурні схеми Kubernetes.

Порівняння рівності для масивів з x-kubernetes-list-type типу set або map ігнорує порядок елементів. Наприклад, [1, 2] == [2, 1] якщо масиви представляють значення Kubernetes set.

Конкатенація для масивів з x-kubernetes-list-type використовує семантику типу списку:

  • set: X + Y виконує обʼєднання, де позиції елементів у X зберігаються, а не перетинаючі елементи у Y додаються, зберігаючи їх частковий порядок.
  • map: X + Y виконує обʼєднання, де позиції ключів у X зберігаються, але значення перезаписуються значеннями у Y, коли ключові множини X і Y перетинаються. Елементи у Y з неперетинаючими ключами додаються, зберігаючи їх частковий порядок.

Екранування

Тільки імена властивостей ресурсів Kubernetes форми [a-zA-Z_.-/][a-zA-Z0-9_.-/]* доступні з CEL. Доступні імена властивостей екрануються згідно з наступними правилами при доступі у виразі:

Таблиця правил екранування ідентифікаторів CEL
екрануюча послідовністьеквівалент імені властивості
__underscores____
__dot__.
__dash__-
__slash__/
__{keyword}__ЗАРЕЗЕРВОВАНЕ ключове слово CEL

Коли ви екрануєте будь-яке з ЗАРЕЗЕРВОВАНИХ ключових слів CEL, збіг повинен точно відповідати імені властивості та використовувати екранування з підкресленням (наприклад, int у слові sprint не буде екрановано, і це не буде необхідно).

Приклади екранування:

Приклади екранованих ідентифікаторів CEL
імʼя властивостіправило з екранованим імʼям властивості
namespaceself.__namespace__ > 0
x-propself.x__dash__prop > 0
redact__dself.redact__underscores__d > 0
stringself.startsWith('kube')

Обмеження ресурсів

CEL не є повноцінною мовою Тюрінга і пропонує різноманітні засоби безпеки для обмеження часу виконання. Функції обмеження ресурсів CEL забезпечують зворотний звʼязок розробникам щодо складності виразів та допомагають захистити сервер API від надмірного споживання ресурсів під час оцінювання. Ці функції використовуються для запобігання надмірного споживання ресурсів сервера API під час виконання CEL.

Ключовим елементом функцій обмеження ресурсів є одиниця вартості, яку CEL визначає як спосіб відстеження використання ЦП. Одиниці вартості незалежні від системного навантаження та апаратного забезпечення. Одиниці вартості також є детермінованими; для будь-якого заданого виразу CEL та вхідних даних, оцінка виразу інтерпретатором CEL завжди призведе до однакової вартості.

Багато з основних операцій CEL мають фіксовані витрати. Найпростіші операції, такі як порівняння (наприклад, <), мають вартість 1. Деякі мають вищу фіксовану вартість, наприклад, оголошення літералів списку мають фіксовану базову вартість 40 одиниць вартості.

Виклики функцій, реалізованих у рідному коді, оцінюються на основі часової складності операції. Наприклад, операції, що використовують регулярні вирази, такі як match та find, оцінюються з використанням приблизної вартості length(regexString)*length(inputString). Приблизна вартість відображає найгірший випадок часової складності реалізації RE2 в Go.

Бюджет вартості під час виконання

Усі вирази CEL, які оцінюються Kubernetes, обмежені бюджетом вартості під час виконання. Бюджет вартості під час виконання — це оцінка фактичного використання ЦП, що обчислюється шляхом інкрементування лічильника одиниць вартості під час інтерпретації виразу CEL. Якщо інтерпретатор CEL виконає занадто багато інструкцій, бюджет вартості під час виконання буде перевищено, виконання виразу буде зупинено і результатом стане помилка.

Деякі ресурси Kubernetes визначають додатковий бюджет вартості під час виконання, який обмежує виконання декількох виразів. Якщо загальна вартість виразів перевищує бюджет, виконання виразів буде зупинено і результатом стане помилка. Наприклад, валідація власного ресурсу користувача має бюджет вартості під час виконання за одну валідацію для всіх Правил Валідації, які оцінюються для валідації власного ресурсу.

Оцінювані обмеження вартості

Для деяких ресурсів Kubernetes, сервер API також може перевірити, чи не буде найгірший випадок оціненого часу виконання виразів CEL надто дорогим для виконання. Якщо так, сервер API запобігає записуванню виразу CEL у ресурсі API, відхиляючи операції створення або оновлення, що містять вираз CEL у ресурсі API. Ця функція пропонує сильнішу гарантію, що вирази CEL, записані у ресурс API, будуть оцінені під час виконання без перевищення бюджету вартості під час виконання.

6.2.5 - Політика застарівання Kubernetes

Цей документ описує політику застарівання для різних аспектів системи.

Kubernetes — це велика система з багатьма компонентами та багатьма учасниками. Як і в будь-якому такому програмному забезпеченні, набір функцій природно розвивається з часом, і іноді функцію може знадобитися видалити. Це може включати API, прапорець або навіть всю функцію. Щоб уникнути порушення роботи наявних користувачів, Kubernetes дотримується політики застарівання для аспектів системи, які підлягають видаленню.

Застарівання частин API

Оскільки Kubernetes є системою, що керується API, API еволюціонував з часом, віддзеркалюючи постійно змінюване розуміння проблемної області. API Kubernetes фактично є набором API, які називаються "групами API", і кожна група API має свою незалежну версію. Версії API поділяються на 3 основні треки, кожен з яких має різні політики застарівання:

ПрикладТрек
v1GA (загальнодоступна, стабільна)
v1beta1Beta (попередній випуск, перед GA)
v1alpha1Alpha (експериментальна)

Конкретний випуск Kubernetes може підтримувати будь-яку кількість груп API та будь-яку кількість версій кожного з них.

Наступні правила регулюють застарівання елементів API. Це включає:

  • Ресурси REST (також відомі як обʼєкти API)
  • Поля ресурсів REST
  • Анотації на ресурсах REST, включаючи "бета" анотації, але не включаючи "альфа" анотації
  • Перелічувані або постійні значення
  • Структури конфігурації компонентів

Ці правила застосовуються між офіційними випусками, а не між довільними внесками коду в основну гілку або гілки випусків.

Правило №1: Елементи API можуть бути видалені лише шляхом інкрементування версії групи API.

Після того, як елемент API був доданий до групи API у певній версії, він не може бути видалений з цієї версії або суттєво змінений, незалежно від треку.

Правило №2: Обʼєкти API повинні мати можливість переходу між версіями API в даному випуску без втрати інформації, за винятком випадків, коли цілі ресурси REST не існують у деяких версіях.

Наприклад, обʼєкт може бути записаний як v1, потім прочитаний як v2 і перетворений на v1, і отриманий ресурс v1 буде ідентичний оригіналу. Представлення у v2 може відрізнятися від v1, але система повинна вміти конвертувати між ними в обидва боки. Крім того, будь-яке нове поле, додане у v2, повинно мати можливість обміну на v1 і назад, що означає, що v1 можливо доведеться додати еквівалентне поле або представити його як анотацію.

Правило №3: Версія API в даному треку не може бути застарілою на користь менш стабільної версії API.

  • GA версії API можуть замінювати бета та альфа версії API.
  • Бета версії API можуть замінювати попередні бета та альфа версії API, але не можуть замінювати GA версії API.
  • Альфа версії API можуть замінювати попередні альфа версії API, але не можуть замінювати GA або бета версії API.

Правило №4а: Тривалість життя API визначається рівнем стабільності API

  • GA версії API можуть бути позначені як застарілі, але не можуть бути видалені в межах основної версії Kubernetes
  • Бета версії API застарівають не раніше ніж через 9 місяців або 3 мінорних випуски після впровадження (що довше), і більше не обслуговуються через 9 місяців або 3 мінорних випуски після застарівання (що довше)
  • Альфа версії API можуть бути видалені в будь-якому випуску без попереднього повідомлення про застарівання

Це гарантує, що підтримка бета API охоплює максимальний підтримуваний розрив версій у 2 випуски, і що API не застоюються на нестабільних бета версіях, накопичуючи продуктивне використання, яке буде порушене, коли підтримка бета API закінчиться.

Правило №4б: "Бажана" версія API та "версія зберігання" для даної групи можуть не просуватися до того, як буде зроблено випуск, що підтримує як нову версію, так і попередню версію.

Користувачі повинні мати можливість оновитися до нової версії Kubernetes, а потім повернутися до попередньої версії, не конвертуючи нічого до нової версії API або уникаючи порушень (якщо вони явно не використовували функції, доступні лише в новішій версії). Це особливо очевидно у збереженому представленні обʼєктів.

Все це найкраще ілюструється прикладами. Уявіть собі випуск Kubernetes, версія X, який вводить нову групу API. Новий випуск Kubernetes виходить приблизно кожні 4 місяці (3 на рік). Наступна таблиця описує, які версії API підтримуються в ряді наступних випусків.

ВипускВерсії APIБажана/Версія зберіганняПримітки
Xv1alpha1v1alpha1
X+1v1alpha2v1alpha2
  • v1alpha1 видалено, "необхідна дія" інформація про випуск
X+2v1beta1v1beta1
  • v1alpha2 видалено, "необхідна дія" інформація про випуск
X+3v1beta2, v1beta1 (застар

іла)

v1beta1
  • v1beta1 застаріла, "необхідна дія" інформація про випуск
X+4v1beta2, v1beta1 (застаріла)v1beta2
X+5v1, v1beta1 (застаріла), v1beta2 (застаріла)v1beta2
  • v1beta2 застаріла, "необхідна дія" інформація про випуск
X+6v1, v1beta2 (застаріла)v1
  • v1beta1 видалено, "необхідна дія" інформація про випуск
X+7v1, v1beta2 (застаріла)v1
X+8v2alpha1, v1v1
  • v1beta2 видалено, "необхідна дія" інформація про випуск
X+9v2alpha2, v1v1
  • v2alpha1 видалено, "необхідна дія" інформація про випуск
X+10v2beta1, v1v1
  • v2alpha2 видалено, "необхідна дія" інформація про випуск
X+11v2beta2, v2beta1 (застаріла), v1v1
  • v2beta1 застаріла, "необхідна дія" інформація про випуск
X+12v2, v2beta2 (застаріла), v2beta1 (застаріла), v1 (застаріла)v1
  • v2beta2 застаріла, "необхідна дія" інформація про випуск
  • v1 застаріла на користь v2, але не буде видалена
X+13v2, v2beta1 (застаріла), v2beta2 (застаріла), v1 (застаріла)v2
X+14v2, v2beta2 (застаріла), v1 (застаріла)v2
  • v2beta1 видалено, "необхідна дія" інформація про випуск
X+15v2, v1 (застаріла)v2
  • v2beta2 видалено, "необхідна дія" інформація про випуск

REST ресурси (або обʼєкти API)

Розглянемо гіпотетичний REST ресурс з назвою Widget, який був присутній у версії API v1 у наведеній вище хронології і який потрібно визнати застарілим. Ми документуємо та оголошуємо про його застарівання синхронно з випуском X+1. Ресурс Widget все ще існує у версії API v1 (застарілий), але не у v2alpha1. Ресурс Widget продовжує існувати та функціонувати у випусках до, та включно з, X+8. Лише у випуску X+9, коли API v1 виходить з використання, ресурс Widget перестає існувати та його віповідна поведінка видаляється.

Починаючи з Kubernetes v1.19, виконання запиту до застарілої точки доступу REST API:

  1. Повертає заголовок Warning (як визначено у RFC7234, Розділ 5.5) у відповіді API.

  2. Додає "k8s.io/deprecated":"true" анотацію до події аудиту, зареєстрованої для запиту.

  3. Встановлює метрику apiserver_requested_deprecated_apis gauge у значення 1 у процесі kube-apiserver. Метрика має мітки group, version, resource, subresource, які можна поєднати з метрикою apiserver_request_total, і мітку removed_release, яка вказує випуск Kubernetes, в якому API більше не буде обслуговуватися. Наступний запит Prometheus повертає інформацію про запити, зроблені до застарілих API, які будуть видалені у версії v1.22:

    apiserver_requested_deprecated_apis{removed_release="1.22"} * on(group,version,resource,subresource) group_right() apiserver_request_total
    

Поля REST ресурсів

Як і REST ресурси в цілому, так і окреме поле, яке було присутнє у версії API v1, має існувати та функціонувати до видалення API v1. На відміну від ресурсів в цілому, API v2 можуть вибрати інше представлення для поля, допоки є можливість виконувати перехід між версіями в обидва боки. Наприклад, поле v1 з назвою "magnitude", яке було застарілим, може називатися "deprecatedMagnitude" в API v2. Коли v1 врешті буде видалено, застаріле поле може бути видалене з v2.

Перераховані або константні значення

Як і для REST ресурсу в цілому, так і його полів, константне значення, яке підтримувалося в API v1, має існувати та функціонувати до видалення API v1.

Структури конфігурацій компонентів

Конфігурації компонентів версіонуються та керуються аналогічно до REST ресурсів.

Майбутні роботи

З часом Kubernetes запровадить більш детальні версії API, і тоді ці правила будуть скориговані за потреби.

Застарівання прапорця або CLI

Система Kubernetes складається з кількох різних програм, які співпрацюють між собою. Іноді випуск Kubernetes може видаляти прапорці або команди CLI (загалом "елементи CLI") у цих програмах. Програми природно діляться на дві основні групи — програми для користувачів і програми для адміністраторів, які трохи відрізняються своїми політиками застарівання. Якщо прапорець явно не позначено або задокументовано як "alpha" або "beta", він вважається стабільним (GA).

Елементи CLI фактично є частиною API до системи, але оскільки вони не версіонуються так само, як REST API, правила застарівання наступні:

Правило №5а: Елементи CLI компонентів для користувачів (наприклад, kubectl) повинні функціонувати після оголошення їх застарівання не менше ніж:

  • GA: 12 місяців або 2 випуски (залежно від того, що довше)
  • Beta: 3 місяці або 1 випуск (залежно від того, що довше)
  • Alpha: 0 випусків

Правило №5б: Елементи CLI компонентів для адміністраторів (наприклад, kubelet) повинні функціонувати після оголошення їх застарівання не менше ніж:

  • GA: 6 місяців або 1 випуск (залежно від того, що довше)
  • Beta: 3 місяці або 1 випуск (залежно від того, що довше)
  • Alpha: 0 випусків

Правило №5в: Елементи командного інтерфейсу (CLI) не можуть бути застарілими на користь менш стабільних елементів CLI.

Схоже на Правило №3 для API, якщо елемент інтерфейсу командного рядка замінюється альтернативною реалізацією, наприклад, перейменуванням наявного елемента або переходом на використання конфігурації, отриманої з файлу, замість аргументу командного рядка, ця рекомендована альтернатива повинна мати той самий або вищий рівень стабільності.

Правило №6: Застарілі елементи CLI повинні видавати попередження (можливо, такі, що відключаються) при використанні.

Застарівання функціонала або поведінки

Час від часу випуск Kubernetes потребує визнання застарілим певного функціонала або поведінки системи, яка не контролюється API або CLI. У цьому випадку правила застарівання такі:

Правило №7: Застарілі функції повинні функціонувати не менше 1 року після оголошеного застарівання.

Якщо функцію або поведінку замінює альтернативна реалізація, яка вимагає роботи для переходу, повинні бути зусилля спростити перехід, якщо це можливо. Якщо альтернативна реалізація контролюється організацією Kubernetes, застосовуються наступні правила:

Правило №8: Функцію або поведінку не можна визнати застарілою на користь альтернативної реалізації, яка менш стабільна.

Наприклад, загальнодоступну функцію не можна визнати застарілою на користь бета-заміщення. Проєкт Kubernetes, однак, закликає користувачів переходити на альтернативні реалізації навіть до досягнення ними того самого рівня зрілості. Це особливо важливо для дослідження нових використань функції або отримання раннього зворотного звʼязку щодо заміщення.

Альтернативні реалізації іноді можуть бути зовнішніми інструментами або продуктами, наприклад, функція може перейти від kubelet до середовища виконання контейнерів, яке не контролюється проєктом Kubernetes. У таких випадках правило не може бути застосоване, але повинні бути зусилля, щоб забезпечити наявність шляху переходу, який не компрометує рівень зрілості компонентів. У прикладі з середовищами виконання контейнерів, зусилля можуть включати спроби забезпечити те, що популярні середовища виконання контейнерів мають версії, які пропонують такий самий рівень стабільності під час впровадження цієї заміни.

Правила застарівання для функцій та поведінки не означають, що всі зміни в системі керуються цією політикою. Ці правила застосовуються тільки до значних, видимих для користувача поведінок, які впливають на правильність роботи програм, що працюють на Kubernetes або впливають на адміністрування кластерів Kubernetes, і які повністю видаляються.

Виняток з вищезазначеного правила  — це функціональні можливості. Функціональні можливості — це пари ключ=значення, які дозволяють користувачам увімкнути/вимкнути експериментальні функції.

Функціональні можливості призначені для охоплення життєвого циклу розробки функції — вони не призначені для API, що мають існувати довгий час. Таким чином, очікується, що вони будуть застарілі та видалені після того, як функція стане GA або буде відкинута.

Під час руху функції через стадії, повʼязані функціональні можливості, змінюються. Життєвий цикл функції, збігається з їх відповідними функціональними можливостями, такий:

  • Alpha: функціональні можливості стандартно вимкнені та можуть бути увімкнені користувачем.
  • Beta: функціональні можливості стандартно увімкнені та можуть бути вимкнені користувачем.
  • GA: функціональні можливості застарілі (див. "Застарівання") і стають нечинними.
  • GA, вікно застарівання завершено: функціональні можливості видаляються, і виклики до них більше не приймаються.

Застарівання

Функції можуть бути видалені на будь-якому етапі життєвого циклу до GA. Коли функції видаляються перед виходом GA, їхні повʼязані функціональні можливості також застарівають.

Якщо виконується спроба вимкнути нечинні функціональні можливості, виклик не вдається, щоб уникнути непідтримуваних сценаріїв, які в іншому випадку можуть працювати мовчки.

У деяких випадках видалення функцій до виходу GA вимагає значного часу. Функціональні можливості можуть залишатися чинними до тих пір, поки повʼязана з ними функція не буде повністю видалена, після чого самі функціональні можливості можуть бути визнані застарілими.

Коли видалення функціональних можливостей для GA-функції також вимагає значного часу, виклики до функціональних можливостей можуть залишатися чинними, якщо функціональні можливості не впливають на функцію і не викликають помилок.

Функції, які мають бути вимкнені користувачами, повинні включати механізм для вимкнення функції в повʼязаних функціональних можливостях.

Версіонування для функціональних можливостей відрізняється від раніше обговорених компонентів, тому правила застарівання такі:

Правило №9: Функціональні можливості повинні бути визнані застарілими, коли відповідна функція, якою вони керують, переходить на етап життєвого циклу наступним чином. Функціональні можливості повинні функціонувати не менше ніж:

  • Від бета-функції до GA: 6 місяців або 2 випуски (залежно від того, що довше)
  • Від бета-функції до EOL: 3 місяці або 1 випуск (залежно від того, що довше)
  • Від альфа-функції до EOL: 0 випусків

Правило №10: Застарілі функціональні можливості повинні відповідати попередженням при використанні. Коли функціональні можливості застарівають, вони повинні бути задокументовані як в примітках про випуски, так і в відповідній довідці CLI. Як попередження, так і документація повинні вказувати, чи є функціональні можливості нечинними.

Застарівання метрики

Кожен компонент панелі управління Kubernetes використовує метрики (зазвичай за допомогою точки доступу /metrics), які зазвичай обробляються адміністраторами кластера. Не всі метрики однакові: деякі метрики широко використовуються як показники рівня сервісу (SLI) або для визначення SLO, тому вони мають більшу важливість. Інші метрики мають більш експериментальний характер або використовуються переважно у процесі розробки Kubernetes.

Відповідно, метрики поділяються на три класи стабільності (ALPHA, BETA, STABLE); це впливає на видалення метрики під час випуску Kubernetes. Ці класи визначаються важливістю метрики. Правила для застарівання та видалення метрики такі:

Правило №11а: Метрики для відповідного класу стабільності повинні функціонувати не менше ніж:

  • STABLE: 4 випуски або 12 місяців (що довше)
  • BETA: 2 випуски або 8 місяців (що довше)
  • ALPHA: 0 випусків

Правило №11б: Метрики, після їх оголошеного застарівання, повинні функціонувати не менше ніж:

  • STABLE: 3 випуски або 9 місяців (що довше)
  • BETA: 1 випуск або 4 місяці (що довше)
  • ALPHA: 0 випусків

Застарілі метрики будуть мати текст опису, у якому буде префікс з повідомленням про застарівання '(Застаріло з x.y)', і під час реєстрації метрики буде запис в лог з попередженням. Подібно до їх стабільних незастарілих аналогів, застарілі метрики будуть автоматично зареєстровані в точці доступу метрик і, отже, будуть видимими.

У наступному випуску (коли deprecatedVersion метрики дорівнює current_kubernetes_version - 3), застаріла метрика стане прихованою метрикою. На відміну від їх застарілих аналогів, приховані метрики більше не будуть автоматично реєструватися в точці доступу метрик (таким чином, вони будуть приховані). Однак їх можна буде явно увімкнути через прапорець командного рядка (--show-hidden-metrics-for-version=). Це надає адміністраторам кластера можливість виходу зі складностей з міграцією від застарілої метрики, якщо вони не змогли відреагувати на раніше надані попередження щодо застарівання. Приховані метрики повинні бути видалені після одного випуску.

Винятки

Жодна політика не може охопити кожну можливу ситуацію. Ця політика є живим документом і буде розвиватися з часом. На практиці будуть ситуації, які не підпадають під цю політику чітко або для яких ця політика стає серйозною перешкодою. Такі ситуації слід обговорювати з SIGs та керівниками проєкту, щоб знайти найкращі рішення для конкретних випадків, завжди памʼятаючи, що Kubernetes прагне бути стабільною системою, яка, наскільки це можливо, ніколи не підводить користувачів. Винятки завжди будуть оголошені в усіх відповідних повідомленням про випуски.

6.2.6 - Посібник з міграції від застарілих API

Під час еволюції API Kubernetes періодично переглядаються або оновлюються. Коли API розвиваються, старий API стає застарілим і, зрештою, вилучається. Ця сторінка містить інформацію, яку вам потрібно знати у випадку міграції від застарілих версій API на новіші та стабільніші версії API.

Вилучені API в розрізі версій

v1.32

У випуску v1.32 перестануть обслуговуватися наступні застарілі версії API:

Ресурси контролю потоку

Версія API flowcontrol.apiserver.k8s.io/v1beta3 FlowSchema та PriorityLevelConfiguration більше не буде обслуговуватися у v1.32.

  • Перенесіть маніфести та клієнти API на використання версії API flowcontrol.apiserver.k8s.io/v1, доступної з версії v1.29.
  • Усі наявні збережені обʼєкти доступні через новий API
  • Значні зміни у flowcontrol.apiserver.k8s.io/v1:
    • Поле spec.limited.nominalConcurrencyShares PriorityLevelConfiguration має стандартне значення 30, коли не вказане, і явне значення 0 не змінюється на 30.

v1.29

У випуску v1.29 перестали обслуговуватися наступні застарілі версії API:

Ресурси контролю потоку

Версія API flowcontrol.apiserver.k8s.io/v1beta2 FlowSchema та PriorityLevelConfiguration більше не обслуговується з версії v1.29.

  • Перенесіть маніфести та клієнти API на використання версії API flowcontrol.apiserver.k8s.io/v1, доступної з версії v1.29, або версії API flowcontrol.apiserver.k8s.io/v1beta3, доступної з версії v1.26.
  • Усі наявні збережені обʼєкти доступні через новий API
  • Значні зміни в flowcontrol.apiserver.k8s.io/v1:
    • Поле spec.limited.assuredConcurrencyShares PriorityLevelConfiguration перейменоване на spec.limited.nominalConcurrencyShares і має стандартне значення 30, коли не вказане, і явне значення 0 не змінюється на 30.
  • Значні зміни в flowcontrol.apiserver.k8s.io/v1beta3:
    • Поле spec.limited.assuredConcurrencyShares PriorityLevelConfiguration перейменоване на spec.limited.nominalConcurrencyShares

v1.27

Випуск v1.27 припинив обслуговування наступних застарілих версій API:

CSIStorageCapacity

Версія API CSIStorageCapacity storage.k8s.io/v1beta1 більше не обслуговується з версії v1.27.

  • Перенесіть маніфести та клієнти API на версію API storage.k8s.io/v1, доступну з версії v1.24.
  • Усі наявні обʼєкти, які зберігаються, доступні через новий API
  • Немає помітних змін

v1.26

Випуск v1.26 припинив обслуговування наступних застарілих версій API:

Ресурси керування потоком

Версія API FlowSchema та PriorityLevelConfiguration flowcontrol.apiserver.k8s.io/v1beta1 більше не обслуговується з версії v1.26.

  • Перенесіть маніфести та клієнти API на версію API flowcontrol.apiserver.k8s.io/v1beta2.
  • Усі наявні обʼєкти, які зберігаються, доступні через новий API
  • Немає помітних змін

HorizontalPodAutoscaler

Версія API HorizontalPodAutoscaler autoscaling/v2beta2 більше не обслуговується з версії v1.26.

v1.25

Випуск v1.25 припинив обслуговування наступних застарілих версій API:

CronJob

Версія API CronJob batch/v1beta1 більше не обслуговується з версії v1.25.

  • Перенесіть маніфести та клієнти API на версію API batch/v1, доступну з версії v1.21.
  • Усі наявні обʼєкти, які зберігаються, доступні через новий API
  • Немає помітних змін

EndpointSlice

Версія API EndpointSlice discovery.k8s.io/v1beta1 більше не обслуговується з версії v1.25.

  • Перенесіть маніфести та клієнти API на версію API discovery.k8s.io/v1, доступну з версії v1.21.
  • Усі наявні обʼєкти, які зберігаються, доступні через новий API
  • Помітні зміни в discovery.k8s.io/v1:
    • використовуйте поле nodeName для кожного Endpoint замість застарілого поля topology["kubernetes.io/hostname"]
    • використовуйте поле zone для кожного Endpoint замість застарілого поля topology["topology.kubernetes.io/zone"]
    • topology замінено полем deprecatedTopology, яке не доступне для запису у v1

Event

Версія API Event events.k8s.io/v1beta1 більше не обслуговується з версії v1.25.

  • Перенесіть маніфести та клієнти API на версію API events.k8s.io/v1, доступну з версії v1.19.
  • Усі наявні обʼєкти, які зберігаються, доступні через новий API
  • Помітні зміни в events.k8s.io/v1:
    • type обмежено до Normal та Warning
    • involvedObject перейменовано в regarding
    • action, reason, reportingController та reportingInstance є обовʼязковими при створенні нових events.k8s.io/v1 Events
    • використовуйте eventTime замість застарілого поля firstTimestamp (яке перейменовано в deprecatedFirstTimestamp та не допускається в нових events.k8s.io/v1 Events)
    • використовуйте series.lastObservedTime замість застарілого поля lastTimestamp (яке перейменовано в deprecatedLastTimestamp та не допускається в нових **events.k8ерсіях API events.k8s.io/v1 Events)
    • використовуйте series.count замість застарілого поля count (яке перейменовано в deprecatedCount та не допускається в нових events.k8s.io/v1 Events)
    • використовуйте reportingController замість застарілого поля source.component (яке перейменовано в deprecatedSource.component та не допускається в нових events.k8s.io/v1 Events)
    • використовуйте reportingInstance замість застарілого поля source.host (яке перейменовано в deprecatedSource.host та не допускається в нових events.k8s.io/v1 Events)

HorizontalPodAutoscaler

Версія API HorizontalPodAutoscaler autoscaling/v2beta1 більше не обслуговується з версії v1.25.

PodDisruptionBudget

Версія API PodDisruptionBudget policy/v1beta1 більше не обслуговується з версії v1.25.

  • Перенесіть маніфести та клієнти API на версію API policy/v1, доступну з версії v1.21.
  • Усі наявні обʼєкти, які зберігаються, доступні через новий API
  • Помітні зміни в policy/v1:
    • пустий spec.selector ({}), записаний до policy/v1 PodDisruptionBudget, вибирає всі теки в просторі імен (у policy/v1beta1 пустий spec.selector не вибирав жодні теки). Неустановлений spec.selector вибирає жодні теки в обох версіях API.

PodSecurityPolicy

PodSecurityPolicy в версії API policy/v1beta1 більше не обслуговується з версії v1.25, і контролер допуску PodSecurityPolicy буде видалено.

Перейдіть до Pod Security Admission або виклику стороннього вебхуку допуску. Для настанов з міграції, див. Міграція з PodSecurityPolicy до вбудованого контролера допуску PodSecurity Admission Controller. Для отримання додаткової інформації про застарілість, див. ВPodSecurityPolicy Deprecation: Past, Present, and Future.

RuntimeClass

RuntimeClass в версії API node.k8s.io/v1beta1 більше не обслуговується з версії v1.25.

  • Перенесіть маніфести та клієнти API на версію API node.k8s.io/v1, доступну з версії v1.20.
  • Усі наявні обʼєкти, які зберігаються, доступні через новий API
  • Немає помітних змін

v1.22

Випуск v1.22 припинив обслуговування наступних застарілих версій API:

Ресурси вебхуків

Версія API admissionregistration.k8s.io/v1beta1 для MutatingWebhookConfiguration та ValidatingWebhookConfiguration більше не обслуговується з версії v1.22.

  • Перенесіть маніфести та клієнти API на версію API admissionregistration.k8s.io/v1, доступну з версії v1.16.
  • Усі наявні обʼєкти, які зберігаються, доступні через нові API
  • Помітні зміни:
    • стандартно webhooks[*].failurePolicy змінено з Ignore на Fail для v1
    • стандартно webhooks[*].matchPolicy змінено з Exact на Equivalent для v1
    • стандартно webhooks[*].timeoutSeconds змінено з 30s на 10s для v1
    • поле webhooks[*].sideEffects стандартно видалено, і тепер воно обовʼязкове, і дозволяється лише None та NoneOnDryRun для v1
    • стандартно видалено значення поля webhooks[*].admissionReviewVersions та робиться обовʼязковим для v1 (підтримувані версії для AdmissionReview - v1 та v1beta1)
    • поле webhooks[*].name повинно бути унікальним в списку для обʼєктів, створених через admissionregistration.k8s.io/v1

CustomResourceDefinition

Версія API apiextensions.k8s.io/v1beta1 для CustomResourceDefinition більше не обслуговується з версії v1.22.

  • Перенесіть маніфести та клієнти API на версію API apiextensions.k8s.io/v1, доступну з версії v1.16.
  • Усі наявні обʼєкти, які зберігаються, доступні через новий API
  • Помітні зміни:
    • поле spec.scope тепер не має станадртного значення Namespaced і повинно бути явно вказано
    • поле spec.version вилучено в v1; використовуйте замість цього spec.versions
    • поле spec.validation вилучено в v1; використовуйте замість цього spec.versions[*].schema
    • поле spec.subresources вилучено в v1; використовуйте замість цього spec.versions[*].subresources
    • поле spec.additionalPrinterColumns вилучено в v1; використовуйте замість цього spec.versions[*].additionalPrinterColumns
    • spec.conversion.webhookClientConfig переміщено в spec.conversion.webhook.clientConfig в v1
    • spec.conversion.conversionReviewVersions переміщено в spec.conversion.webhook.conversionReviewVersions в v1
    • поле spec.versions[*].schema.openAPIV3Schema тепер обовʼязкове при створенні обʼєктів CustomResourceDefinition для v1, і повинно бути структурною схемою
    • spec.preserveUnknownFields: true заборонено при створенні обʼєктів CustomResourceDefinition для v1; воно повинно бути вказано у визначеннях схем як x-kubernetes-preserve-unknown-fields: true
    • В елементах additionalPrinterColumns поле JSONPath перейменовано в jsonPath в v1 (виправлення #66531)

APIService

Версія API apiregistration.k8s.io/v1beta1 для APIService більше не обслуговується з версії v1.22.

  • Перенесіть маніфести та клієнти API на версію API apiregistration.k8s.io/v1, доступну з версії v1.10.
  • Усі наявні обʼєкти, які зберігаються, доступні через новий API
  • Немає помітних змін

TokenReview

Версія API authentication.k8s.io/v1beta1 для TokenReview більше не обслуговується з версії v1.22.

  • Перенесіть маніфести та клієнти API на версію API authentication.k8s.io/v1, доступну з версії v1.6.
  • Немає помітних змін

Ресурси SubjectAccessReview

Версія API authorization.k8s.io/v1beta1 для LocalSubjectAccessReview, SelfSubjectAccessReview, SubjectAccessReview та SelfSubjectRulesReview більше не обслуговується з версії v1.22.

  • Перенесіть маніфести та клієнти API на версію API authorization.k8s.io/v1, доступну з версії v1.6.
  • Помітні зміни:
    • Поле spec.group перейменовано на spec.groups в v1 (виправляє #32709)

CertificateSigningRequest

Версія API certificates.k8s.io/v1beta1 для CertificateSigningRequest більше не обслуговується з версії v1.22.

  • Перенесіть маніфести та клієнти API на версію API certificates.k8s.io/v1, доступну з версії v1.19.
  • Усі наявні обʼєкти, які зберігаються, доступні через новий API
  • Помітні зміни в certificates.k8s.io/v1:
    • Для API-клієнтів, що запитують сертифікати:
      • Поле spec.signerName тепер обовʼязкове (див. відомі підписувачи Kubernetes), і запити на kubernetes.io/legacy-unknown не дозволяються бути створеними через API certificates.k8s.io/v1
      • Поле spec.usages тепер обовʼязкове, не може містити дубльованих значень та повинно містити лише відомі використання
    • Для API-клієнтів, що схвалюють або підписують сертифікати:
      • status.conditions не може містити дублюються типи
      • status.conditions[*].status тепер обовʼязкове
      • status.certificate повинно бути в кодуванні PEM та містити лише блоки CERTIFICATE

Lease

Версія API coordination.k8s.io/v1beta1 для Lease більше не обслуговується з версії v1.22.

  • Перенесіть маніфести та клієнти API на версію API coordination.k8s.io/v1, доступну з версії v1.14.
  • Усі наявні обʼєкти, які зберігаються, доступні через новий API
  • Немає помітних змін

Ingress

Версії API extensions/v1beta1 та networking.k8s.io/v1beta1 для Ingress більше не обслуговуються з версії v1.22.

  • Перенесіть маніфести та клієнти API на версію API networking.k8s.io/v1, доступну з версії v1.19.
  • Усі наявні обʼєкти, які зберігаються, доступні через новий API
  • Помітні зміни:
    • Поле spec.backend перейменовано на spec.defaultBackend
    • Поле serviceName бекенду перейменовано на service.name
    • Числові поля servicePort бекенду перейменовані на service.port.number
    • Рядкові поля servicePort бекенду перейменовані на service.port.name
    • pathType тепер обовʼязковий для кожного вказаного шляху. Варіанти — Prefix, Exact, та ImplementationSpecific. Для відповідності невизначеній поведінці v1beta1 використовуйте ImplementationSpecific.

IngressClass

Версія API networking.k8s.io/v1beta1 для IngressClass більше не обслуговується з версії v1.22.

  • Перенесіть маніфести та клієнти API на версію API networking.k8s.io/v1, доступну з версії v1.19.
  • Усі наявні обʼєкти, які зберігаються, доступні через новий API
  • Немає помітних змін

Ресурси RBAC

Версія API rbac.authorization.k8s.io/v1beta1 для ClusterRole, ClusterRoleBinding, Role та RoleBinding більше не обслуговується з версії v1.22.

  • Перенесіть маніфести та клієнти API на версію API rbac.authorization.k8s.io/v1, доступну з версії v1.8.
  • Усі наявні обʼєкти, які зберігаються, доступні через нові API
  • Немає помітних змін

PriorityClass

Версія API scheduling.k8s.io/v1beta1 для PriorityClass більше не обслуговується з версії v1.22.

  • Перенесіть маніфести та клієнти API на версію API scheduling.k8s.io/v1, доступну з версії v1.14.
  • Усі наявні обʼєкти, які зберігаються, доступні через новий API.
  • Немає помітних змін.

Ресурси зберігання

Версія API storage.k8s.io/v1beta1 для CSIDriver, CSINode, StorageClass та VolumeAttachment більше не обслуговується з версії v1.22.

  • Перенесіть маніфести та клієнти API на версію API storage.k8s.io/v1
    • CSIDriver доступний у storage.k8s.io/v1 починаючи з версії v1.19.
    • CSINode доступний у storage.k8s.io/v1 починаючи з версії v1.17.
    • StorageClass доступний у storage.k8s.io/v1 починаючи з версії v1.6.
    • VolumeAttachment доступний у storage.k8s.io/v1 з версії v1.13.
  • Усі наявні обʼєкти, які зберігаються, доступні через нові API.
  • Немає помітних змін.

v1.16

Випуск v1.16 припинив обслуговування наступних застарілих версій API:

Мережева політика

Версія API extensions/v1beta1 для NetworkPolicy більше не обслуговується з версії v1.16.

  • Перенесіть маніфести та клієнти API на версію API networking.k8s.io/v1, доступну з версії v1.8.
  • Усі наявні обʼєкти, які зберігаються, доступні через новий API.

DaemonSet

Версії API extensions/v1beta1 та apps/v1beta2 для DaemonSet більше не обслуговуються з версії v1.16.

  • Перенесіть маніфести та клієнти API на версію API apps/v1, доступну з версії v1.9.
  • Усі наявні обʼєкти, які зберігаються, доступні через новий API.
  • Помітні зміни:
    • spec.templateGeneration видалено.
    • spec.selector тепер є обовʼязковим і незмінним після створення; використовуйте наявні мітки шаблону як селектор для безшовного оновлення.
    • spec.updateStrategy.type тепер стандартно встановлено на RollingUpdate (стандартно в extensions/v1beta1 було OnDelete).

Deployment

Версії API extensions/v1beta1, apps/v1beta1 та apps/v1beta2 для Deployment більше не обслуговуються з версії v1.16.

  • Перенесіть маніфести та клієнти API на версію API apps/v1, доступну з версії v1.9.
  • Усі наявні обʼєкти, які зберігаються, доступні через новий API.
  • Помітні зміни:
    • spec.rollbackTo видалено.
    • spec.selector тепер є обовʼязковим і незмінним після створення; використовуйте наявні мітки шаблону як селектор для безшовного оновлення.
    • spec.progressDeadlineSeconds тепер стандартно встановлено на 600 секунд (стандартно в extensions/v1beta1 було без крайнього терміну).
    • spec.revisionHistoryLimit тепер стандартно встановлено на 10 (стандартно в apps/v1beta1 було 2, стандартно в extensions/v1beta1 було зберігати всі).
    • maxSurge та maxUnavailable тепер стандартно встановлено на 25% (стандартно в extensions/v1beta1 було 1).

StatefulSet

Версії API apps/v1beta1 та apps/v1beta2 для StatefulSet більше не обслуговуються з версії v1.16.

  • Перенесіть маніфести та клієнти API на версію API apps/v1, доступну з версії v1.9.
  • Усі наявні обʼєкти, які зберігаються, доступні через новий API.
  • Помітні зміни:
    • spec.selector тепер є обовʼязковим і незмінним після створення; використовуйте наявні мітки шаблону як селектор для безшовного оновлення.
    • spec.updateStrategy.type тепер за замовчуванням встановлено на RollingUpdate (стандартно в apps/v1beta1 було OnDelete).

ReplicaSet

Версії API extensions/v1beta1, apps/v1beta1 та apps/v1beta2 для ReplicaSet більше не обслуговуються з версії v1.16.

  • Перенесіть маніфести та клієнти API на версію API apps/v1, доступну з версії v1.9.
  • Усі наявні обʼєкти, які зберігаються, доступні через новий API.
  • Помітні зміни:
    • spec.selector тепер є обовʼязковим і незмінним після створення; використовуйте наявні мітки шаблону як селектор для безшовного оновлення.

PodSecurityPolicy

Версія API extensions/v1beta1 для PodSecurityPolicy більше не обслуговується з версії v1.16.

  • Перенесіть маніфести та клієнти API на версію API policy/v1beta1, доступну з версії v1.10.
  • Зауважте, що версія API policy/v1beta1 для PodSecurityPolicy буде видалена у версії v1.25.

Що робити

Тестування з вимкненими застарілими API

Ви можете протестувати свої кластери, запустивши API сервер зі конкретними вимкненими версіями API, щоб змоделювати майбутні видалення. Додайте наступний прапорець до аргументів запуску API сервера:

--runtime-config=<group>/<version>=false

Наприклад:

--runtime-config=admissionregistration.k8s.io/v1beta1=false,apiextensions.k8s.io/v1beta1,...

Пошук використання застарілих API

Використовуйте попередження клієнтів, метрики та інформацію аудиту, доступні в версії 1.19+ для визначення використання застарілих API.

Перехід на незастарілі API

  • Оновіть власні інтеграції та контролери, щоб викликати незастарілі API.

  • Змініть YAML файли, щоб вони посилалися на незастарілі API.

    Ви можете використовувати команду kubectl convert для автоматичного перетворення наявного обʼєкта:

    kubectl convert -f <file> --output-version <group>/<version>.

    Наприклад, щоб перетворити старий Deployment на apps/v1, ви можете виконати:

    kubectl convert -f ./my-deployment.yaml --output-version apps/v1

    Це перетворення може використовувати не ідеальні стандартні значення. Щоб дізнатися більше про конкретний ресурс, зверніться до довідника API Kubernetes.

6.2.7 - Точки доступу для моніторингу стану API Kubernetes

API сервер Kubernetes надає точки доступу API для індикації поточного стану API сервера. Ця сторінка описує ці точки доступу API та пояснює, як ви можете їх використовувати.

Точки доступу API для моніторингу стану

API сервер Kubernetes надає 3 точки доступу API (healthz, livez і readyz) для індикації поточного стану API сервера. Точка доступу healthz є застарілою (з Kubernetes v1.16), і ви повинні використовувати більш конкретні точки доступу livez та readyz. Точку доступу livez можна використовувати з прапорцем --livez-grace-period, щоб вказати тривалість запуску. Для належного завершення роботи ви можете вказати прапорець --shutdown-delay-duration з точкою доступу /readyz. Машини, що перевіряють healthz/livez/readyz API сервера, повинні покладатися на HTTP-код статусу. Код статусу 200 вказує, що API сервер є healthy/live/ready, залежно від викликаної точки доступу. Більш докладні опції, показані нижче, призначені для використання людьми-операторами для налагодження їх кластера або розуміння стану API сервера.

Наступні приклади покажуть, як ви можете взаємодіяти з точками доступу моніторингу стану API.

Для всіх точок доступу ви можете використовувати параметр verbose, щоб вивести перевірки та їхній стан. Це може бути корисно для оператора-людини для налагодження поточного стану API сервера, це не призначено для використання машинами:

curl -k https://localhost:6443/livez?verbose

або з віддаленого хосту з автентифікацією:

kubectl get --raw='/readyz?verbose'

Вивід буде виглядати наступним чином:

[+]ping ok
[+]log ok
[+]etcd ok
[+]poststarthook/start-kube-apiserver-admission-initializer ok
[+]poststarthook/generic-apiserver-start-informers ok
[+]poststarthook/start-apiextensions-informers ok
[+]poststarthook/start-apiextensions-controllers ok
[+]poststarthook/crd-informer-synced ok
[+]poststarthook/bootstrap-controller ok
[+]poststarthook/rbac/bootstrap-roles ok
[+]poststarthook/scheduling/bootstrap-system-priority-classes ok
[+]poststarthook/start-cluster-authentication-info-controller ok
[+]poststarthook/start-kube-aggregator-informers ok
[+]poststarthook/apiservice-registration-controller ok
[+]poststarthook/apiservice-status-available-controller ok
[+]poststarthook/kube-apiserver-autoregistration ok
[+]autoregister-completion ok
[+]poststarthook/apiservice-openapi-controller ok
healthz check passed

API сервер Kubernetes також підтримує виключення конкретних перевірок. Параметри запиту також можна комбінувати, як у цьому прикладі:

curl -k 'https://localhost:6443/readyz?verbose&exclude=etcd'

Вивід показує, що перевірка etcd виключено:

[+]ping ok
[+]log ok
[+]etcd excluded: ok
[+]poststarthook/start-kube-apiserver-admission-initializer ok
[+]poststarthook/generic-apiserver-start-informers ok
[+]poststarthook/start-apiextensions-informers ok
[+]poststarthook/start-apiextensions-controllers ok
[+]poststarthook/crd-informer-synced ok
[+]poststarthook/bootstrap-controller ok
[+]poststarthook/rbac/bootstrap-roles ok
[+]poststarthook/scheduling/bootstrap-system-priority-classes ok
[+]poststarthook/start-cluster-authentication-info-controller ok
[+]poststarthook/start-kube-aggregator-informers ok
[+]poststarthook/apiservice-registration-controller ok
[+]poststarthook/apiservice-status-available-controller ok
[+]poststarthook/kube-apiserver-autoregistration ok
[+]autoregister-completion ok
[+]poststarthook/apiservice-openapi-controller ok
[+]shutdown ok
healthz check passed

Індивідуальні перевірки стану

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.31 [alpha]

Кожна індивідуальна перевірка стану надає HTTP точку доступу і може бути перевірена індивідуально. Схема для індивідуальних перевірок стану — /livez/<healthcheck-name> або /readyz/<healthcheck-name>, де livez і readyz можуть бути використані для індикації, чи ви хочете перевірити liveness або readiness API сервера відповідно. Шлях <healthcheck-name> можна знайти, використовуючи прапорець verbose вище та шлях між [+] та ok. Ці індивідуальні перевірки стану не повинні використовуватися машинами, але можуть бути корисні для оператора-людини для налагодження системи:

curl -k https://localhost:6443/livez/etcd

6.3.1 - Автентифікація

Ця сторінка надає огляд автентифікації.

Користувачі в Kubernetes

У всіх кластерах Kubernetes є дві категорії користувачів: службові облікові записи, які керуються Kubernetes, і звичайні користувачі.

Припускається, що незалежна від кластера служба керує звичайними користувачами наступними способами:

  • адміністратор розповсюджує приватні ключі
  • сховище користувачів, таке як Keystone або Google Accounts
  • файл зі списком імен користувачів та паролів

У цьому відношенні Kubernetes не має обʼєктів, які представляють звичайні облікові записи користувачів. Звичайні користувачі не можуть бути додані до кластера через API виклик.

Хоча звичайного користувача не можна додати через API виклик, будь-який користувач, який предʼявляє дійсний сертифікат, підписаний центром сертифікації (CA) кластера, вважається автентифікованим. У цій конфігурації Kubernetes визначає імʼя користувача з поля загального імені (CN) у сертифікаті (наприклад, "/CN=bob"). Після цього підсистема контролю доступу на основі ролей (RBAC) визначає, чи авторизований користувач для виконання певної операції з ресурсом. Детальніше про це можна прочитати у темі про звичайних користувачів у запиті сертифікатів.

На відміну від цього, службові облікові записи є користувачами, якими керує Kubernetes API. Вони привʼязані до певних просторів імен і створюються автоматично API сервером або вручну через API виклики. Службові облікові записи привʼязані до набору облікових даних, збережених як Secrets, які монтуються в Podʼи, що дозволяє процесам всередині кластера взаємодіяти з Kubernetes API.

API запити привʼязані або до звичайного користувача, або до службово облікового запису, або обробляються як анонімні запити. Це означає, що кожен процес всередині або поза кластером, від користувача, який вводить kubectl на робочій станції, до kubelets на вузлах, до членів панелі управління, повинен автентифікуватися при виконанні запитів до API сервера, або бути обробленим як анонімний користувач.

Стратегії автентифікації

Kubernetes використовує клієнтські сертифікати, токени на предʼявника (bearer tokens) або проксі для автентифікації (authenticating proxy) для автентифікації API запитів через втулки автентифікації. Під час виконання HTTP запитів до API сервера втулки намагаються асоціювати наступні атрибути із запитом:

  • Імʼя користувача: рядок, який ідентифікує кінцевого користувача. Загальноприйняті значення можуть бути kube-admin або jane@example.com.
  • UID: рядок, який ідентифікує кінцевого користувача та намагається бути більш стабільним і унікальним, ніж імʼя користувача.
  • Групи: набір рядків, кожен з яких вказує на членство користувача в певній логічній групі користувачів. Загальноприйняті значення можуть бути system:masters або devops-team.
  • Додаткові поля: елемент map рядків для отримання переліку рядків, що містить додаткову інформацію, яку авторизатори можуть вважати корисною.

Усі значення є непрозорими для системи автентифікації та мають значення лише при інтерпретації авторизатором.

Ви можете одночасно ввімкнути кілька методів автентифікації. Зазвичай вам слід використовувати принаймні два методи:

  • токени службових облікових записів
  • принаймні один інший метод для автентифікації користувачів.

Коли увімкнено кілька модулів автентифікаторів, перший модуль, який успішно автентифікує запит, перериває подальшу оцінку. API сервер не гарантує порядок виконання автентифікаторів.

Група system:authenticated включена до списку груп для всіх автентифікованих користувачів.

Інтеграції з іншими протоколами автентифікації (LDAP, SAML, Kerberos, альтернативні схеми x509 тощо) можуть бути здійснені за допомогою проксі автентифікації або вебхука автентифікації.

X509 клієнтські сертифікати

Автентифікація за допомогою клієнтських сертифікатів увімкнена шляхом передачі опції --client-ca-file=SOMEFILE до API сервера. Вказаний файл повинен містити один або більше центрів сертифікації для використання у валідації клієнтських сертифікатів, представлених API серверу. Якщо представлено клієнтський сертифікат і він підтверджений, загальне імʼя субʼєкта використовується як імʼя користувача для запиту. Починаючи з Kubernetes 1.4, клієнтські сертифікати також можуть вказувати на членство користувача в групах, використовуючи поля організації сертифіката. Щоб включити кілька членств у групах для користувача, включіть кілька полів організації в сертифікат.

Наприклад, використовуючи командний рядок openssl для генерації запиту на підпис сертифіката:

openssl req -new -key jbeda.pem -out jbeda-csr.pem -subj "/CN=jbeda/O=app1/O=app2"

Це створить CSR для імені користувача "jbeda", який належить до двох груп, "app1" і "app2".

Дивіться Керування сертифікатами для отримання інформації про те, як створити клієнтський сертифікат.

Статичний файл токенів

API сервер читає токени на предʼявника (bearer tokens) з файлу при використанні опції --token-auth-file=SOMEFILE у командному рядку. Наразі токени діють безстроково, і список токенів не можна змінити без перезавантаження API сервера.

Файл токенів є csv-файлом з мінімум 3 стовпцями: токен, імʼя користувача, uid користувача, а також необовʼязкові імена груп.

Використання токена на предʼявника у запиті

При використанні автентифікації за допомогою токенів з HTTP клієнта, API сервер очікує заголовок Authorization зі значенням Bearer <token>. Маркер має бути послідовністю символів, яку можна помістити в значення HTTP заголовка, використовуючи лише можливості кодування та цитування HTTP. Наприклад, якщо токен — 31ada4fd-adec-460c-809a-9e56ceb75269, тоді він буде виглядати у заголовку HTTP, як показано нижче.

Authorization: Bearer 31ada4fd-adec-460c-809a-9e56ceb75269

Bootstrap токени

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.18 [stable]

Для спрощення початкового налаштування нових кластерів, Kubernetes включає тип токена на предʼявника (bearer token), який керується динамічно, так званий Bootstrap Token. Ці токени зберігаються як Secrets у просторі імен kube-system, де ними можна динамічно керувати та створювати. Менеджер контролерів містить контролер TokenCleaner, який видаляє bootstrap токени в міру їх завершення.

Токени мають форму [a-z0-9]{6}.[a-z0-9]{16}. Перший компонент є ID токена, а другий компонент є Secret токена. Ви вказуєте токен у HTTP заголовку наступним чином:

Authorization: Bearer 781292.db7bc3a58fc5f07e

Ви повинні увімкнути Bootstrap Token Authenticator з прапорцем --enable-bootstrap-token-auth на API сервері. Ви повинні увімкнути контролер TokenCleaner за допомогою прапорця --controllers у Controller Manager. Це робиться за допомогою чогось типу --controllers=*,tokencleaner. kubeadm зробить це за вас, якщо ви використовуєте його для початкового налаштування кластера.

Автентифікатор автентифікує як system:bootstrap:<Token ID>. Він включений у групу system:bootstrappers. Імена користувачів та групи навмисно обмежені, щоб перешкоджати користувачам використовувати ці токени після початкового налаштування. Імена користувачів та групи можна використовувати (і використовуються kubeadm) для створення відповідних політик авторизації для підтримки початкового налаштування кластера.

Детальнішу інформацію про автентифікатор Bootstrap Token та контролери, а також про керування цими токенами за допомогою kubeadm, дивіться у Bootstrap Tokens.

Токени службових облікових записів

Службовий обліковий запис є автоматично увімкненим автентифікатором, який використовує підписані токени на предʼявника (bearer tokens) для перевірки запитів. Втулок приймає два необовʼязкові прапорці:

  • --service-account-key-file Файл, що містить PEM-кодовані x509 RSA або ECDSA приватні або публічні ключі, що використовуються для перевірки токенів службових облікових записів. Вказаний файл може містити кілька ключів, і прапорець може бути вказаний кілька разів з різними файлами. Якщо не вказано, використовується --tls-private-key-file.
  • --service-account-lookup Якщо увімкнено, токени, які видаляються з API, будуть відкликані.

Службові облікові записи зазвичай створюються автоматично API сервером та асоціюються з Podʼами, які працюють у кластері через ServiceAccount Контролер допуску. Токени на предʼявника (bearer tokens) монтуються в Podʼи у відомих місцях, що дозволяє процесам всередині кластера взаємодіяти з API сервером. Облікові записи можуть бути явно асоційовані з Podʼами, використовуючи поле serviceAccountName у PodSpec.

apiVersion: apps/v1 # ця apiVersion актуальна станом з Kubernetes 1.9
kind: Deployment
metadata:
  name: nginx-deployment
  namespace: default
spec:
  replicas: 3
  template:
    metadata:
    # ...
    spec:
      serviceAccountName: bob-the-bot
      containers:
      - name: nginx
        image: nginx:1.14.2

Токени на предʼявника службових облікових записів (bearer tokens) є цілком дійсними для використання за межами кластера і можуть бути використані для створення ідентичностей для тривалих завдань, які бажають взаємодіяти з API Kubernetes. Щоб вручну створити службовий обліковий запис, використовуйте команду kubectl create serviceaccount (NAME). Це створює службовий обліковий запис у поточному просторі імен.

kubectl create serviceaccount jenkins
serviceaccount/jenkins created

Створіть асоційований токен:

kubectl create token jenkins
eyJhbGciOiJSUzI1NiIsImtp...

Створений токен є підписаним JSON Web Token (JWT).

Підписаний JWT може бути використаний як токен на предʼявника (bearer token) для автентифікації як вказаний службовий обліковий запис. Дивіться вище для інформації про те, як токен включається у запит. Зазвичай ці токени монтуються в Podʼи для доступу до API сервера всередині кластера, але можуть бути використані й ззовні кластера.

Службові облікові записи автентифікуються з імʼям користувача system:serviceaccount:(NAMESPACE):(SERVICEACCOUNT), і належать групам system:serviceaccounts та system:serviceaccounts:(NAMESPACE).

Токени OpenID Connect

OpenID Connect — це варіант OAuth2, підтримуваний деякими провайдерами OAuth2, зокрема Microsoft Entra ID, Salesforce та Google. Головне розширення протоколу OAuth2 полягає в додатковому полі, яке повертається разом із токеном доступу, називається ID Token. Цей токен є JSON Web Token (JWT) з добре відомими полями, такими як електронна пошта користувача, підписаними сервером.

Для ідентифікації користувача автентифікатор використовує id_token (а не access_token) з відповіді токена OAuth2 як токен носія. Дивіться вище для того, як токен включається у запит.

sequenceDiagram participant user as Користувач participant idp as Провайдер ідентичності participant kube as kubectl participant api as Сервер API user ->> idp: 1. Вхід до Провайдера ідентичності activate idp idp -->> user: 2. Надання access_token,
id_token та refresh_token deactivate idp activate user user ->> kube: 3. Виклик kubectl
з --token, що є id_token
АБО додавання токенів до .kube/config deactivate user activate kube kube ->> api: 4. Authorization: Bearer... deactivate kube activate api api ->> api: 5. Чи є підпис JWT дійсним? api ->> api: 6. Чи не минув термін дії JWT? (iat+exp) api ->> api: 7. Чи авторизований користувач? api -->> kube: 8. Авторизовано: Виконання
дії та повернення результату deactivate api activate kube kube --x user: 9. Повернення результату deactivate kube
  1. Увійдіть до свого провайдера ідентичності.

  2. Ваш провайдер ідентичності надасть вам access_token, id_token та refresh_token.

  3. Використовуючи kubectl, використовуйте свій id_token із прапорцем --token або додайте його безпосередньо до вашого kubeconfig.

  4. kubectl надсилає ваш id_token у заголовку Authorization до сервера API.

  5. Сервер API перевіряє, чи є підпис JWT дійсним.

  6. Перевіряє, чи не минув термін дії id_token.

    Виконує перевірку вимог та/або користувача, якщо з AuthenticationConfiguration налаштовані вирази CEL.

  7. Переконується, що користувач авторизований.

  8. Після авторизації сервер API повертає відповідь kubectl.

  9. kubectl надає зворотній звʼязок користувачу.

Оскільки всі дані, необхідні для верифікації вашої особи, містяться в id_token, Kubernetes не потрібно "дзвонити додому" до провайдера ідентичності. У моделі, де кожен запит є stateless, це забезпечує дуже масштабоване рішення для автентифікації. Це має кілька викликів:

  1. Kubernetes не має "вебінтерфейсу" для ініціювання процесу автентифікації. Немає оглядача або інтерфейсу для збору облікових даних, тому вам потрібно спочатку автентифікуватися у свого провайдера ідентичності.
  2. id_token не можна відкликати, він схожий на сертифікат, тому він повинен бути короткостроковим (лише кілька хвилин), що може бути дуже незручним, оскільки потрібно отримувати новий токен кожні кілька хвилин.
  3. Для автентифікації в панелі управління Kubernetes, ви повинні використовувати команду kubectl proxy або зворотний проксі, який вставляє id_token.

Налаштування сервера API

Використання прапорців

Щоб увімкнути втулок, налаштуйте наступні прапорці на сервері API:

ПараметрОписПрикладОбовʼязковий
--oidc-issuer-urlURL провайдера, який дозволяє серверу API знаходити публічні ключі підпису. Приймаються лише URL-адреси, що використовують схему https://. Це зазвичай URL виявлення провайдера, змінений на порожній шляхЯкщо URL виявлення OIDC провайдера https://accounts.provider.example/.well-known/openid-configuration, значення повинно бути https://accounts.provider.exampleТак
--oidc-client-idІдентифікатор клієнта, для якого мають бути видані всі токени.kubernetesТак
--oidc-username-claimJWT вимога для використання як імені користувача. Стандартно sub, яке очікується що має бути унікальним ідентифікатором кінцевого користувача. Адміністратори можуть вибрати інші вимоги, такі як email або name, залежно від свого провайдера. Однак, вимоги, відмінні від email, будуть мати префікс URL провайдера, щоб уникнути зіткнень назв з іншими втулками.subНі
--oidc-username-prefixПрефікс, доданий до вимог імені користувача, щоб уникнути зіткнень з наявними іменами (наприклад, користувачами system:). Наприклад, значення oidc: створить імена користувачів, такі як oidc:jane.doe. Якщо цей прапорець не вказано, і значення --oidc-username-claim відрізняється від email, стандартний префікс ( Issuer URL )#, де ( Issuer URL ) — це значення --oidc-issuer-url. Значення - можна використовувати для відключення всіх префіксів.oidc:Ні
--oidc-groups-claimJWT вимога для використання як групи користувача. Якщо вимога присутня, вона повинна бути масивом рядків.groupsНі
--oidc-groups-prefixПрефікс, доданий до вимог груп, щоб уникнути зіткнень з наявними назвами (наприклад, групами system:). Наприклад, значення oidc: створить назви груп, такі як oidc:engineering та oidc:infra.oidc:Ні
--oidc-required-claimПара ключ=значення, яка описує обовʼязкову вимогу в ID Token. Якщо встановлено, вимога перевіряється на наявність в ID Token з відповідним значенням. Повторіть цей прапорець, щоб вказати кілька вимог.claim=valueНі
--oidc-ca-fileШлях до сертифіката для ЦС, який підписав вебсертифікат вашого провайдера ідентичності. Стандартно використовується кореневий ЦС хосту./etc/kubernetes/ssl/kc-ca.pemНі
--oidc-signing-algsПрийняті алгоритми підпису. Стандартно "RS256".RS512Ні
Налаштування автентифікації з файлу
СТАН ФУНКЦІОНАЛУ: Kubernetes v1.30 [beta]

JWT Автентифікатор є автентифікатором для автентифікації користувачів Kubernetes за допомогою токенів, що відповідають стандарту JWT. Автентифікатор спробує розібрати необроблений ID токен, перевірити, чи він підписаний налаштованим видавцем. Публічний ключ для перевірки підпису перевіряється на публічній точці доступу видавця за допомогою OIDC discovery.

Мінімальний допустимий JWT повинен містити наступні твердження:

{
  "iss": "https://example.com",   // має збігатися з issuer.url
  "aud": ["my-app"],              // принаймні один з елементів в issuer.audiences повинен збігатися з твердженням "aud" в наданих JWT.
  "exp": 1234567890,              // закінчення терміну дії токена у вигляді часу Unix (кількість секунд, що минули з 1 січня 1970 року UTC)
  "<username-claim>": "user"      // це твердження для імені користувача, налаштоване в claimMappings.username.claim або claimMappings.username.expression
}

Підхід з використанням конфігураційного файлу дозволяє налаштовувати декілька JWT автентифікаторів, кожен з унікальними issuer.url та issuer.discoveryURL. Конфігураційний файл навіть дозволяє використовувати CEL вирази для зіставлення тверджень на атрибути користувача, а також для перевірки тверджень та інформації про користувача. API сервер також автоматично перезавантажує автентифікатори при зміні конфігураційного файлу. Ви можете використовувати метрику apiserver_authentication_config_controller_automatic_reload_last_timestamp_seconds для моніторингу часу останнього перезавантаження конфігурації сервером API.

Необхідно вказати шлях до конфігураційного файлу автентифікації за допомогою прапорця --authentication-config на сервері API. Якщо ви хочете використовувати командні прапорці замість конфігураційного файлу, вони продовжать працювати як раніше. Щоб отримати нові можливості, такі як налаштування декількох автентифікаторів, встановлення декількох аудиторій для одного видавця, перейдіть на використання конфігураційного файлу.

Для Kubernetes версії v1.31, формат файлу структурованої конфігурації автентифікації є на рівні бета-версії, і механізм використання цієї конфігурації також є на рівні бета-версії. За умови, що ви не вимкнули спеціально функційну можливість StructuredAuthenticationConfiguration для вашого кластера, ви можете увімкнути структуровану автентифікацію, вказавши аргумент командного рядка --authentication-config для kube-apiserver. Приклад файлу конфігурації структурованої автентифікації наведено нижче.

---
#
# УВАГА: це приклад конфігурації.
#        Не використовуйте це для вашого кластера!
#
apiVersion: apiserver.config.k8s.io/v1beta1
kind: AuthenticationConfiguration
# список автентифікаторів для автентифікації користувачів Kubernetes за допомогою токенів, що відповідають стандарту JWT.
# максимальна кількість дозволених автентифікаторів – 64.
jwt:
- issuer:
    # URL має бути унікальним для всіх автентифікаторів.
    # URL не повинен конфліктувати з видавцем, налаштованим у --service-account-issuer.
    url: https://example.com # Те ж саме, що і --oidc-issuer-url.
    # discoveryURL, якщо вказано, замінює URL, що використовується для отримання інформації про виявлення,
    # замість використання "{url}/.well-known/openid-configuration".
    # Точно вказане значення використовується, тому "/.well-known/openid-configuration"
    # має бути включено у discoveryURL, якщо це потрібно.
    #
    # Поле "issuer" у отриманій інформації про виявлення має збігатися з полем "issuer.url"
    # в AuthenticationConfiguration і буде використовуватися для перевірки твердження "iss" у наданих JWT.
    # Це для сценаріїв, коли точки доступу well-known та jwks розміщені в іншому
    # місці, ніж видавець (наприклад, локально в кластері).
    # discoveryURL має відрізнятися від URL, якщо вказано, і має бути унікальним для всіх автентифікаторів.
    discoveryURL: https://discovery.example.com/.well-known/openid-configuration
    # PEM-кодовані сертифікати CA, які використовуються для перевірки підключення при отриманні
    # інформації про виявлення. Якщо не вказано, буде використовуватися системний перевіряючий.
    # Те саме значення, що і вміст файлу, на який посилається прапорець --oidc-ca-file.
    certificateAuthority: <PEM-кодовані сертифікати CA>    
    # audiences – це набір прийнятних аудиторій, для яких повинен бути виданий JWT.
    # Принаймні один з елементів повинен збігатися з твердженням "aud" у наданих JWT.
    audiences:
    - my-app # Те ж саме, що і --oidc-client-id.
    - my-other-app
    # це повинно бути встановлено на "MatchAny", коли вказано кілька аудиторій.
    audienceMatchPolicy: MatchAny
  # правила, що застосовуються для перевірки тверджень токена для автентифікації користувачів.
  claimValidationRules:
    # Те ж саме, що і --oidc-required-claim key=value.
  - claim: hd
    requiredValue: example.com
    # Замість claim та requiredValue, ви можете використовувати expression для перевірки твердження.
    # expression – це вираз CEL, який оцінюється до булевого значення.
    # всі вирази повинні бути true для успішної перевірки.
  - expression: 'claims.hd == "example.com"'
    # Повідомлення налаштовує повідомлення про помилку, яке відображається в логах сервера API, коли перевірка не вдається.
    message: твердження hd повинно бути встановлено у example.com
  - expression: 'claims.exp - claims.nbf <= 86400'
    message: загальний час життя токена не повинен перевищувати 24 години
  claimMappings:
    # username представляє опцію для атрибута імені користувача.
    # Це єдиний обовʼязковий атрибут.
    username:
      # Те ж саме, що і --oidc-username-claim. Взаємовиключно з username.expression.
      claim: "sub"
      # Те ж саме, що і --oidc-username-prefix. Взаємовиключно з username.expression.
      # якщо username.claim встановлено, username.prefix обовʼязково має бути встановлено.
      # Встановіть значення "" явно, якщо префікс не потрібен.
      prefix: ""
      # Взаємовиключно з username.claim і username.prefix.
      # expression – це вираз CEL, який оцінюється як рядок.
      #
      # 1.  Якщо у виразі username.expression використовується 'claims.email', то 'claims.email_verified' має бути використано у
      # username.expression або extra[*].valueExpression або claimValidationRules[*].expression.
      # Приклад виразу правила валідації заявки, який автоматично збігається з валідацією
      # застосовується, коли username.claim має значення 'email' - 'claims.?email_verified.orValue(true)'.
      # 2.  Якщо імʼя користувача, що оцінюється на основі виразу username.expression, є порожнім рядком, запит на автентифікацію
      # запит не буде виконано.
      expression: 'claims.username + ":external-user"'
    # groups представляє опцію для атрибута групи.
    groups:
      # Те ж саме, що і --oidc-groups-claim. Взаємовиключно з groups.expression.
      claim: "sub"
      # Те ж саме, що і --oidc-groups-prefix. Взаємовиключно з groups.expression.
      # якщо groups.claim встановлено, groups.prefix обовʼязково має бути встановлено.
      # Встановіть значення "" явно, якщо префікс не потрібен.
      prefix: ""
      # Взаємовиключно з groups.claim і groups.prefix.
      # expression – це вираз CEL, який оцінюється як рядок або список рядків.
      expression: 'claims.roles.split(",")'
    # uid представляє опцію для атрибута унікального ідентифікатора.
    uid:
      # Взаємовиключно з uid.expression.
      claim: "sub"
      # Взаємовиключно з uid.claim.
      # expression – це вираз CEL, який оцінюється як рядок.
      expression: 'claims.uid'
    # екстра атрибути для додавання до обʼєктв UserInfo. Ключі мають бути у вигляді шляху з префіксом домену та бути унікальними.
    extra:
    - key: "example.com/tenant"
      # valueExpression – це вираз CEL, який оцінюється як рядок або список рядків.
      valueExpression: 'claims.tenant'
    # правила валідації, що застосовуються до фінального обʼєкта користувача.
    userValidationRules:
      #  expression – це вираз CEL, який оцінюється до булевого значення.
      # всі вирази повинні бути true для успішної перевірки.
    - expression: "!user.username.startsWith('system:')"
      # message налаштовує повідомлення про помилку, яке відображається в логах сервера API, коли перевірка не вдається.
      message: 'неможна використовувате це імʼя користувача, зарезервовано префіксом system:'
    - expression: "user.groups.all(group, !group.startsWith('system:'))"
      message: 'неможна використовувате цю назву групи, зарезервовано префіксом system:'
  • Вираз правил валідації твердження (claim)

    jwt.claimValidationRules[i].expression представляє вираз, який буде оцінений CEL. Вирази CEL мають доступ до вмісту корисного навантаження токена, організованого у змінну CEL claims. claims - це карта імен тверджень (як рядків) до значень тверджень (будь-якого типу).

  • Вираз правила валідації користувача

    jwt.userValidationRules[i].expression представляє вираз, який буде оцінений CEL. Вирази CEL мають доступ до вмісту userInfo, організованого у змінну CEL user. Зверніться до UserInfo API документації для отримання схеми user.

  • Вираз зіставлення твердження

    jwt.claimMappings.username.expression, jwt.claimMappings.groups.expression, jwt.claimMappings.uid.expression jwt.claimMappings.extra[i].valueExpression представляє вираз, який буде оцінений CEL. Вирази CEL мають доступ до вмісту корисного навантаження токена, організованого у змінну CEL claims. claims — зіствлення імен тверджень (як рядків) до значень тверджень (будь-якого типу).

    Щоб дізнатися більше, дивіться Документацію по CEL.

    Ось приклади AuthenticationConfiguration з різними корисними навантаженнями токена.

    apiVersion: apiserver.config.k8s.io/v1beta1
    kind: AuthenticationConfiguration
    jwt:
    - issuer:
        url: https://example.com
        audiences:
        - my-app
      claimMappings:
        username:
          expression: 'claims.username + ":external-user"'
        groups:
          expression: 'claims.roles.split(",")'
        uid:
          expression: 'claims.sub'
        extra:
        - key: 'example.com/tenant'
          valueExpression: 'claims.tenant'
      userValidationRules:
      - expression: "!user.username.startsWith('system:')" # вибарз буде оцінений як true, тоож валідація пройде успішно.
        message: 'username cannot used reserved system: prefix'
    
    TOKEN=eyJhbGciOiJSUzI1NiIsImtpZCI6ImY3dF9tOEROWmFTQk1oWGw5QXZTWGhBUC04Y0JmZ0JVbFVpTG5oQkgxdXMiLCJ0eXAiOiJKV1QifQ.eyJhdWQiOiJrdWJlcm5ldGVzIiwiZXhwIjoxNzAzMjMyOTQ5LCJpYXQiOjE3MDExMDcyMzMsImlzcyI6Imh0dHBzOi8vZXhhbXBsZS5jb20iLCJqdGkiOiI3YzMzNzk0MjgwN2U3M2NhYTJjMzBjODY4YWMwY2U5MTBiY2UwMmRkY2JmZWJlOGMyM2I4YjVmMjdhZDYyODczIiwibmJmIjoxNzAxMTA3MjMzLCJyb2xlcyI6InVzZXIsYWRtaW4iLCJzdWIiOiJhdXRoIiwidGVuYW50IjoiNzJmOTg4YmYtODZmMS00MWFmLTkxYWItMmQ3Y2QwMTFkYjRhIiwidXNlcm5hbWUiOiJmb28ifQ.TBWF2RkQHm4QQz85AYPcwLxSk-VLvQW-mNDHx7SEOSv9LVwcPYPuPajJpuQn9C_gKq1R94QKSQ5F6UgHMILz8OfmPKmX_00wpwwNVGeevJ79ieX2V-__W56iNR5gJ-i9nn6FYk5pwfVREB0l4HSlpTOmu80gbPWAXY5hLW0ZtcE1JTEEmefORHV2ge8e3jp1xGafNy6LdJWabYuKiw8d7Qga__HxtKB-t0kRMNzLRS7rka_SfQg0dSYektuxhLbiDkqhmRffGlQKXGVzUsuvFw7IGM5ZWnZgEMDzCI357obHeM3tRqpn5WRjtB8oM7JgnCymaJi-P3iCd88iu1xnzA
    

    де корисне навантаження токена:

      {
        "aud": "kubernetes",
        "exp": 1703232949,
        "iat": 1701107233,
        "iss": "https://example.com",
        "jti": "7c337942807e73caa2c30c868ac0ce910bce02ddcbfebe8c23b8b5f27ad62873",
        "nbf": 1701107233,
        "roles": "user,admin",
        "sub": "auth",
        "tenant": "72f988bf-86f1-41af-91ab-2d7cd011db4a",
        "username": "foo"
      }
    

    Токен із зазначеною вище AuthenticationConfiguration створить наступний об’єкт UserInfo і успішно автентифікує користувача.

    {
        "username": "foo:external-user",
        "uid": "auth",
        "groups": [
            "user",
            "admin"
        ],
        "extra": {
            "example.com/tenant": "72f988bf-86f1-41af-91ab-2d7cd011db4a"
        }
    }
    

    apiVersion: apiserver.config.k8s.io/v1beta1
    kind: AuthenticationConfiguration
    jwt:
    - issuer:
        url: https://example.com
        audiences:
        - my-app
      claimValidationRules:
      - expression: 'claims.hd == "example.com"' # маркер нижче не має цього твердження, тому перевірка не вдасться.
        message: the hd claim must be set to example.com
      claimMappings:
        username:
          expression: 'claims.username + ":external-user"'
        groups:
          expression: 'claims.roles.split(",")'
        uid:
          expression: 'claims.sub'
        extra:
        - key: 'example.com/tenant'
          valueExpression: 'claims.tenant'
      userValidationRules:
      - expression: "!user.username.startsWith('system:')" # tвибарз буде оцінений як true, тоож валідація пройде успішно.
        message: 'username cannot used reserved system: prefix'
    
    TOKEN=eyJhbGciOiJSUzI1NiIsImtpZCI6ImY3dF9tOEROWmFTQk1oWGw5QXZTWGhBUC04Y0JmZ0JVbFVpTG5oQkgxdXMiLCJ0eXAiOiJKV1QifQ.eyJhdWQiOiJrdWJlcm5ldGVzIiwiZXhwIjoxNzAzMjMyOTQ5LCJpYXQiOjE3MDExMDcyMzMsImlzcyI6Imh0dHBzOi8vZXhhbXBsZS5jb20iLCJqdGkiOiI3YzMzNzk0MjgwN2U3M2NhYTJjMzBjODY4YWMwY2U5MTBiY2UwMmRkY2JmZWJlOGMyM2I4YjVmMjdhZDYyODczIiwibmJmIjoxNzAxMTA3MjMzLCJyb2xlcyI6InVzZXIsYWRtaW4iLCJzdWIiOiJhdXRoIiwidGVuYW50IjoiNzJmOTg4YmYtODZmMS00MWFmLTkxYWItMmQ3Y2QwMTFkYjRhIiwidXNlcm5hbWUiOiJmb28ifQ.TBWF2RkQHm4QQz85AYPcwLxSk-VLvQW-mNDHx7SEOSv9LVwcPYPuPajJpuQn9C_gKq1R94QKSQ5F6UgHMILz8OfmPKmX_00wpwwNVGeevJ79ieX2V-__W56iNR5gJ-i9nn6FYk5pwfVREB0l4HSlpTOmu80gbPWAXY5hLW0ZtcE1JTEEmefORHV2ge8e3jp1xGafNy6LdJWabYuKiw8d7Qga__HxtKB-t0kRMNzLRS7rka_SfQg0dSYektuxhLbiDkqhmRffGlQKXGVzUsuvFw7IGM5ZWnZgEMDzCI357obHeM3tRqpn5WRjtB8oM7JgnCymaJi-P3iCd88iu1xnzA
    

    де корисне навантаження токена:

      {
        "aud": "kubernetes",
        "exp": 1703232949,
        "iat": 1701107233,
        "iss": "https://example.com",
        "jti": "7c337942807e73caa2c30c868ac0ce910bce02ddcbfebe8c23b8b5f27ad62873",
        "nbf": 1701107233,
        "roles": "user,admin",
        "sub": "auth",
        "tenant": "72f988bf-86f1-41af-91ab-2d7cd011db4a",
        "username": "foo"
      }
    

    Токен із зазначеною вище AuthenticationConfiguration не зможе автентифікуватись, оскільки твердження hd не має значення example.com. Сервер API поверне помилку 401 Unauthorized.

    apiVersion: apiserver.config.k8s.io/v1beta1
    kind: AuthenticationConfiguration
    jwt:
    - issuer:
        url: https://example.com
        audiences:
        - my-app
      claimValidationRules:
      - expression: 'claims.hd == "example.com"'
        message: the hd claim must be set to example.com
      claimMappings:
        username:
          expression: '"system:" + claims.username' # це призведе до додавання префіксу "system:" до імені користувача і не пройде перевірку.
        groups:
          expression: 'claims.roles.split(",")'
        uid:
          expression: 'claims.sub'
        extra:
        - key: 'example.com/tenant'
          valueExpression: 'claims.tenant'
      userValidationRules:
      - expression: "!user.username.startsWith('system:')" # імʼя користувача буде system:foo, а вираз матиме значення false, тому перевірка не вдасться.
        message: 'username cannot used reserved system: prefix'
    
    TOKEN=eyJhbGciOiJSUzI1NiIsImtpZCI6ImY3dF9tOEROWmFTQk1oWGw5QXZTWGhBUC04Y0JmZ0JVbFVpTG5oQkgxdXMiLCJ0eXAiOiJKV1QifQ.eyJhdWQiOiJrdWJlcm5ldGVzIiwiZXhwIjoxNzAzMjMyOTQ5LCJoZCI6ImV4YW1wbGUuY29tIiwiaWF0IjoxNzAxMTEzMTAxLCJpc3MiOiJodHRwczovL2V4YW1wbGUuY29tIiwianRpIjoiYjViMDY1MjM3MmNkMjBlMzQ1YjZmZGZmY2RjMjE4MWY0YWZkNmYyNTlhYWI0YjdlMzU4ODEyMzdkMjkyMjBiYyIsIm5iZiI6MTcwMTExMzEwMSwicm9sZXMiOiJ1c2VyLGFkbWluIiwic3ViIjoiYXV0aCIsInRlbmFudCI6IjcyZjk4OGJmLTg2ZjEtNDFhZi05MWFiLTJkN2NkMDExZGI0YSIsInVzZXJuYW1lIjoiZm9vIn0.FgPJBYLobo9jnbHreooBlvpgEcSPWnKfX6dc0IvdlRB-F0dCcgy91oCJeK_aBk-8zH5AKUXoFTlInfLCkPivMOJqMECA1YTrMUwt_IVqwb116AqihfByUYIIqzMjvUbthtbpIeHQm2fF0HbrUqa_Q0uaYwgy8mD807h7sBcUMjNd215ff_nFIHss-9zegH8GI1d9fiBf-g6zjkR1j987EP748khpQh9IxPjMJbSgG_uH5x80YFuqgEWwq-aYJPQxXX6FatP96a2EAn7wfPpGlPRt0HcBOvq5pCnudgCgfVgiOJiLr_7robQu4T1bis0W75VPEvwWtgFcLnvcQx0JWg
    

    де корисне навантаження токена:

      {
        "aud": "kubernetes",
        "exp": 1703232949,
        "hd": "example.com",
        "iat": 1701113101,
        "iss": "https://example.com",
        "jti": "b5b0652372cd20e345b6fdffcdc2181f4afd6f259aab4b7e35881237d29220bc",
        "nbf": 1701113101,
        "roles": "user,admin",
        "sub": "auth",
        "tenant": "72f988bf-86f1-41af-91ab-2d7cd011db4a",
        "username": "foo"
      }
    

    Токен із наведеною вище AuthenticationConfiguration створить такий обʼєкт UserInfo:

    {
        "username": "system:foo",
        "uid": "auth",
        "groups": [
            "user",
            "admin"
        ],
        "extra": {
            "example.com/tenant": "72f988bf-86f1-41af-91ab-2d7cd011db4a"
        }
    }
    

    який не пройде перевірку користувача, оскільки ім’я користувача починається з system:. Сервер API поверне помилку 401 Unauthorized.

Обмеження
  1. Розподілені твердження не працюють через вирази CEL.
  2. Конфігурація селектора вихідного трафіку не підтримується для викликів до issuer.url та issuer.discoveryURL.

Kubernetes не надає провайдера ідентифікації OpenID Connect. Ви можете використовувати наявного публічного провайдера ідентифікації OpenID Connect (наприклад, Google або інші). Або ж ви можете запустити власного провайдера ідентифікації, такого як dex, Keycloak, CloudFoundry UAA, або Tremolo Security's OpenUnison.

Для того, щоб провайдер ідентифікації працював з Kubernetes, він повинен:

  1. Підтримувати OpenID Connect discovery

    Публічний ключ для перевірки підпису отримується з публічної точки доступу видавця за допомогою OIDC discovery. Якщо ви використовуєте файл конфігурації автентифікації, провайдер ідентифікації не обовʼязково має публічно відкривати точку доступу discovery. Ви можете розмістити точку доступу discovery в іншому місці, ніж видавець (наприклад, локально в кластері) і вказати issuer.discoveryURL у файлі конфігурації.

  2. Працювати через TLS з не застарілими шифрами

  3. Мати сертифікат, підписаний ЦС (навіть якщо ЦС не комерційний або самопідписаний)

Примітка щодо вимоги №3 вище, що потреби в сертифікаті, підписаного ЦС. Якщо ви розгортаєте власного провайдера ідентифікації (на відміну від одного з хмарних провайдерів, таких як Google або Microsoft), ви ПОВИІННІ мати сертифікат вебсервера провайдера ідентифікації, підписаний сертифікатом з прапорцем CA, встановленим на TRUE, навіть якщо він самопідписаний. Це повʼязано з тим, що реалізація клієнта TLS в GoLang дуже сувора до стандартів перевірки сертифікатів. Якщо у вас немає під рукою ЦС, ви можете використовувати скрипт gencert від команди Dex для створення простого ЦС і пари підписаного сертифіката та ключа. Або ви можете використовувати цей подібний скрипт, який генерує сертифікати SHA256 з довшим терміном дії та більшим розміром ключа.

Інструкції з налаштування для конкретних систем:

Використання kubectl

Варіант 1 — Автентифікатор OIDC

Перший варіант — використання автентифікатора kubectl oidc, який встановлює id_token як токен на предʼявника для всіх запитів і оновлює токен після закінчення його терміну дії. Після того, як ви увійшли до свого провайдера, використовуйте kubectl, щоб додати ваші id_token, refresh_token, client_id та client_secret для налаштування втулка.

Провайдери, які не повертають id_token як частину відповіді на оновлення токена, не підтримуються цим втулком і повинні використовувати "Варіант 2" нижче.

kubectl config set-credentials USER_NAME \
   --auth-provider=oidc \
   --auth-provider-arg=idp-issuer-url=( issuer url ) \
   --auth-provider-arg=client-id=( your client id ) \
   --auth-provider-arg=client-secret=( your client secret ) \
   --auth-provider-arg=refresh-token=( your refresh token ) \
   --auth-provider-arg=idp-certificate-authority=( path to your ca certificate ) \
   --auth-provider-arg=id-token=( your id_token )

Як приклад, запустіть наведену нижче команду після автентифікації у постачальника ідентифікаційної інформації:

kubectl config set-credentials mmosley  \
        --auth-provider=oidc  \
        --auth-provider-arg=idp-issuer-url=https://oidcidp.tremolo.lan:8443/auth/idp/OidcIdP  \
        --auth-provider-arg=client-id=kubernetes  \
        --auth-provider-arg=client-secret=1db158f6-177d-4d9c-8a8b-d36869918ec5  \
        --auth-provider-arg=refresh-token=q1bKLFOyUiosTfawzA93TzZIDzH2TNa2SMm0zEiPKTUwME6BkEo6Sql5yUWVBSWpKUGphaWpxSVAfekBOZbBhaEW+VlFUeVRGcluyVF5JT4+haZmPsluFoFu5XkpXk5BXqHega4GAXlF+ma+vmYpFcHe5eZR+slBFpZKtQA= \
        --auth-provider-arg=idp-certificate-authority=/root/ca.pem \
        --auth-provider-arg=id-token=eyJraWQiOiJDTj1vaWRjaWRwLnRyZW1vbG8ubGFuLCBPVT1EZW1vLCBPPVRybWVvbG8gU2VjdXJpdHksIEw9QXJsaW5ndG9uLCBTVD1WaXJnaW5pYSwgQz1VUy1DTj1rdWJlLWNhLTEyMDIxNDc5MjEwMzYwNzMyMTUyIiwiYWxnIjoiUlMyNTYifQ.eyJpc3MiOiJodHRwczovL29pZGNpZHAudHJlbW9sby5sYW46ODQ0My9hdXRoL2lkcC9PaWRjSWRQIiwiYXVkIjoia3ViZXJuZXRlcyIsImV4cCI6MTQ4MzU0OTUxMSwianRpIjoiMm96US15TXdFcHV4WDlHZUhQdy1hZyIsImlhdCI6MTQ4MzU0OTQ1MSwibmJmIjoxNDgzNTQ5MzMxLCJzdWIiOiI0YWViMzdiYS1iNjQ1LTQ4ZmQtYWIzMC0xYTAxZWU0MWUyMTgifQ.w6p4J_6qQ1HzTG9nrEOrubxIMb9K5hzcMPxc9IxPx2K4xO9l-oFiUw93daH3m5pluP6K7eOE6txBuRVfEcpJSwlelsOsW8gb8VJcnzMS9EnZpeA0tW_p-mnkFc3VcfyXuhe5R3G7aa5d8uHv70yJ9Y3-UhjiN9EhpMdfPAoEB9fYKKkJRzF7utTTIPGrSaSU6d2pcpfYKaxIwePzEkT4DfcQthoZdy9ucNvvLoi1DIC-UocFD8HLs8LYKEqSxQvOcvnThbObJ9af71EwmuE21fO5KzMW20KtAeget1gnldOosPtz1G5EwvaQ401-RPQzPGMVBld0_zMCAwZttJ4knw

Що створить наведену нижче конфігурацію:

users:
- name: mmosley
  user:
    auth-provider:
      config:
        client-id: kubernetes
        client-secret: 1db158f6-177d-4d9c-8a8b-d36869918ec5
        id-token: eyJraWQiOiJDTj1vaWRjaWRwLnRyZW1vbG8ubGFuLCBPVT1EZW1vLCBPPVRybWVvbG8gU2VjdXJpdHksIEw9QXJsaW5ndG9uLCBTVD1WaXJnaW5pYSwgQz1VUy1DTj1rdWJlLWNhLTEyMDIxNDc5MjEwMzYwNzMyMTUyIiwiYWxnIjoiUlMyNTYifQ.eyJpc3MiOiJodHRwczovL29pZGNpZHAudHJlbW9sby5sYW46ODQ0My9hdXRoL2lkcC9PaWRjSWRQIiwiYXVkIjoia3ViZXJuZXRlcyIsImV4cCI6MTQ4MzU0OTUxMSwianRpIjoiMm96US15TXdFcHV4WDlHZUhQdy1hZyIsImlhdCI6MTQ4MzU0OTQ1MSwibmJmIjoxNDgzNTQ5MzMxLCJzdWIiOiI0YWViMzdiYS1iNjQ1LTQ4ZmQtYWIzMC0xYTAxZWU0MWUyMTgifQ.w6p4J_6qQ1HzTG9nrEOrubxIMb9K5hzcMPxc9IxPx2K4xO9l-oFiUw93daH3m5pluP6K7eOE6txBuRVfEcpJSwlelsOsW8gb8VJcnzMS9EnZpeA0tW_p-mnkFc3VcfyXuhe5R3G7aa5d8uHv70yJ9Y3-UhjiN9EhpMdfPAoEB9fYKKkJRzF7utTTIPGrSaSU6d2pcpfYKaxIwePzEkT4DfcQthoZdy9ucNvvLoi1DIC-UocFD8HLs8LYKEqSxQvOcvnThbObJ9af71EwmuE21fO5KzMW20KtAeget1gnldOosPtz1G5EwvaQ401-RPQzPGMVBld0_zMCAwZttJ4knw
        idp-certificate-authority: /root/ca.pem
        idp-issuer-url: https://oidcidp.tremolo.lan:8443/auth/idp/OidcIdP
        refresh-token: q1bKLFOyUiosTfawzA93TzZIDzH2TNa2SMm0zEiPKTUwME6BkEo6Sql5yUWVBSWpKUGphaWpxSVAfekBOZbBhaEW+VlFUeVRGcluyVF5JT4+haZmPsluFoFu5XkpXk5BXq
      name: oidc

Після закінчення терміну дії вашого id_token kubectl спробує оновити ваш id_token за допомогою ваших refresh_token і client_secret, зберігаючи нові значення для refresh_token і id_token у вашому .kube/config.

Варіант 2 — Використання опції --token

Команда kubectl дозволяє передати токен за допомогою параметра --token. Скопіюйте та вставте id_token у цей параметр:

kubectl --token=eyJhbGciOiJSUzI1NiJ9.eyJpc3MiOiJodHRwczovL21sYi50cmVtb2xvLmxhbjo4MDQzL2F1dGgvaWRwL29pZGMiLCJhdWQiOiJrdWJlcm5ldGVzIiwiZXhwIjoxNDc0NTk2NjY5LCJqdGkiOiI2RDUzNXoxUEpFNjJOR3QxaWVyYm9RIiwiaWF0IjoxNDc0NTk2MzY5LCJuYmYiOjE0NzQ1OTYyNDksInN1YiI6Im13aW5kdSIsInVzZXJfcm9sZSI6WyJ1c2VycyIsIm5ldy1uYW1lc3BhY2Utdmlld2VyIl0sImVtYWlsIjoibXdpbmR1QG5vbW9yZWplZGkuY29tIn0.f2As579n9VNoaKzoF-dOQGmXkFKf1FMyNV0-va_B63jn-_n9LGSCca_6IVMP8pO-Zb4KvRqGyTP0r3HkHxYy5c81AnIh8ijarruczl-TK_yF5akjSTHFZD-0gRzlevBDiH8Q79NAr-ky0P4iIXS8lY9Vnjch5MF74Zx0c3alKJHJUnnpjIACByfF2SCaYzbWFMUNat-K1PaUk5-ujMBG7yYnr95xD-63n8CO8teGUAAEMx6zRjzfhnhbzX-ajwZLGwGUBT4WqjMs70-6a7_8gZmLZb2az1cZynkFRj2BaCkVT3A2RrjeEwZEtGXlMqKJ1_I2ulrOVsYx01_yD35-rw get nodes

Автентифікація за допомогою вебхука

Автентифікація за допомогою вебхука — це механізм перевірки маркерів носіїв.

  • --authentication-token-webhook-config-file — файл конфігурації, який описує, як отримати доступ до віддаленого сервісу вебхука.
  • --authentication-token-webhook-cache-ttl — як довго кешувати рішення щодо автентифікації. Стандартно дві хвилини.
  • --authentication-token-webhook-version визначає, чи використовувати authentication.k8s.io/v1beta1 або authentication.k8s.io/v1 обʼєкти TokenReview для надсилання/отримання інформації від вебхука. Стандартно v1beta1.

Файл конфігурації використовує формат файлу kubeconfig. У файлі clusters посилається на віддалений сервіс, а users посилається на вебхук API-сервера. Приклад:

# Версія API Kubernetes
apiVersion: v1
# Тип обʼєкта API
kind: Config
# clusters посилається на віддалений сервіс.
clusters:
  - name: name-of-remote-authn-service
    cluster:
      certificate-authority: /path/to/ca.pem         # ЦС для перевірки віддаленого сервісу.
      server: https://authn.example.com/authenticate # URL віддаленого сервісу для запиту. 'https' рекомендовано для промислового застосування.

# users посилається на конфігурацію вебхука API-сервера.
users:
  - name: name-of-api-server
    user:
      client-certificate: /path/to/cert.pem # сертифікат для використання втулком вебхука
      client-key: /path/to/key.pem          # ключ, що відповідає сертифікату

# файли kubeconfig потребують контексту. Надати один для API-сервера.
current-context: webhook
contexts:
- context:
    cluster: name-of-remote-authn-service
    user: name-of-api-server
  name: webhook

Коли клієнт намагається автентифікуватись на API-сервері за допомогою токена на предʼявника, як розглядалось вище, вебхук автентифікації надсилає POST-запит з JSON-серіалізованим обʼєктом TokenReview, що містить токен для віддаленого сервісу.

Зверніть увагу, що обʼєкти API вебхука підпадають під ті ж правила сумісності версій, що й інші обʼєкти API Kubernetes. Виконавці повинні перевірити поле apiVersion запиту, щоб забезпечити правильну десеріалізацію, і повинні відповідати обʼєктом TokenReview тієї ж версії, що й запит.

{
  "apiVersion": "authentication.k8s.io/v1",
  "kind": "TokenReview",
  "spec": {
    # Непрозорий токен на прежʼявника носія, надісланий на API-сервер
    "token": "014fbff9a07c...",

    # Необовʼязковий список ідентифікаторів аудиторії для сервера, якому був представлений токен.
    # Автентифікатори токенів, що враховують аудиторію (наприклад, OIDC автентифікатори токенів)
    # повинні перевірити, що токен був призначений для принаймні однієї з аудиторій у цьому списку,
    # і повернути перетин цього списку та дійсних аудиторій для токена в статусі відповіді.
    # Це гарантує, що токен дійсний для автентифікації на сервері, якому він був представлений.
    # Якщо аудиторії не надані, токен повинен бути перевірений для автентифікації на API-сервері Kubernetes.
    "audiences": ["https://myserver.example.com", "https://myserver.internal.example.com"]
  }
}

{
  "apiVersion": "authentication.k8s.io/v1beta1",
  "kind": "TokenReview",
  "spec": {
    # Непрозорий токен на предʼявника, надісланий на API-сервер
    "token": "014fbff9a07c...",

    # Необовʼязковий список ідентифікаторів аудиторії для сервера, якому був представлений токен.
    # Автентифікатори токенів, що враховують аудиторію (наприклад, OIDC автентифікатори токенів)
    # повинні перевірити, що токен був призначений для принаймні однієї з аудиторій у цьому списку,
    # і повернути перетин цього списку та дійсних аудиторій для токена в статусі відповіді.
    # Це гарантує, що токен дійсний для автентифікації на сервері, якому він був представлений.
    # Якщо аудиторії не надані, токен повинен бути перевірений для автентифікації на API-сервері Kubernetes.
    "audiences": ["https://myserver.example.com", "https://myserver.internal.example.com"]
  }
}

Віддалений сервіс повинен заповнити поле status запиту, щоб вказати на успішність входу. Поле spec тіла відповіді ігнорується та може бути опущене. Віддалений сервіс повинен повернути відповідь, використовуючи ту ж версію API TokenReview, яку він отримав. Успішна перевірка маркера носія буде виглядати так:

{
  "apiVersion": "authentication.k8s.io/v1",
  "kind": "TokenReview",
  "status": {
    "authenticated": true,
    "user": {
      # Обовʼязково
      "username": "janedoe@example.com",
      # Необовʼязково
      "uid": "42",
      # Необовʼязкові членства у групах
      "groups": ["developers", "qa"],
      # Необовʼязкова додаткова інформація, надана автентифікатором.
      # Це не повинно містити конфіденційних даних, оскільки це може бути записано в логах
      # або обʼєктах API та доступно для вебхуків допуску.
      "extra": {
        "extrafield1": [
          "extravalue1",
          "extravalue2"
        ]
      }
    },
    # Необовʼязковий список, який можуть повернути автентифікатори токенів, що враховують аудиторію,
    # містить аудиторії зі списку `spec.audiences`, для яких токен був дійсним.
    # Якщо це опущено, токен вважається дійсним для автентифікації на API-сервері Kubernetes.
    "audiences": ["https://myserver.example.com"]
  }
}

{
  "apiVersion": "authentication.k8s.io/v1beta1",
  "kind": "TokenReview",
  "status": {
    "authenticated": true,
    "user": {
      # Обовʼязково
      "username": "janedoe@example.com",
      # Необовʼязково
      "uid": "42",
      # Необовʼязкові членства у групах
      "groups": ["developers", "qa"],
      # Необовʼязкова додаткова інформація, надана автентифікатором.
      # Це не повинно містити конфіденційних даних, оскільки це може бути записано в логах
      # або обʼєктах API та доступно для вебхуків допуску.
      "extra": {
        "extrafield1": [
          "extravalue1",
          "extravalue2"
        ]
      }
    },
    # Необовʼязковий список, який можуть повернути автентифікатори токенів, що враховують аудиторію,
    # містить аудиторії зі списку `spec.audiences`, для яких токен був дійсним.
    # Якщо це опущено, токен вважається дійсним для автентифікації на API-сервері Kubernetes.
    "audiences": ["https://myserver.example.com"]
  }
}

Невдала спроба запиту виглядатиме так:

{
  "apiVersion": "authentication.k8s.io/v1",
  "kind": "TokenReview",
  "status": {
    "authenticated": false,
    # Необовʼязково включати деталі, чому автентифікація не вдалася.
    # Якщо помилка не вказана, API поверне загальне повідомлення Unauthorized.
    # Поле error ігнорується, коли authenticated=true.
    "error": "Credentials are expired"
  }
}

{
  "apiVersion": "authentication.k8s.io/v1beta1",
  "kind": "TokenReview",
  "status": {
    "authenticated": false,
    # Необовʼязково включати деталі, чому автентифікація не вдалася.
    # Якщо помилка не вказана, API поверне загальне повідомлення Unauthorized.
    # Поле error ігнорується, коли authenticated=true.
    "error": "Credentials are expired"
  }
}

Проксі автентифікації

API-сервер може бути налаштований для ідентифікації користувачів на основі значень заголовків запиту, таких як X-Remote-User. Цей механізм призначений для використання в комбінації з проксі-сервером автентифікації, який встановлює значення заголовка запиту.

  • --requestheader-username-headers Обовʼязково, нечутливий до регістру. Імена заголовків для перевірки, у порядку, для ідентифікації користувача. Перший заголовок, який містить значення, використовується як імʼя користувача.
  • --requestheader-group-headers Версія 1.6+. Необовʼязково, нечутливий до регістру. Пропонується використовувати "X-Remote-Group". Імена заголовків для перевірки, у порядку, для визначення груп користувача. Усі значення в усіх зазначених заголовках використовуються як імена груп.
  • --requestheader-extra-headers-prefix Версія 1.6+. Необовʼязково, нечутливий до регістру. Пропонується використовувати "X-Remote-Extra-". Префікси заголовків для перевірки додаткової інформації про користувача (зазвичай використовується налаштованим втулком авторизації). У всіх заголовків, які починаються з будь-якого з зазначених префіксів, префікси вилучаються. Решта імені заголовка перетворюється на нижній регістр і декодується у відповідності з RFC 3986, і стає додатковим ключем, а значення заголовка — додатковим значенням.

Наприклад, з цією конфігурацією:

--requestheader-username-headers=X-Remote-User
--requestheader-group-headers=X-Remote-Group
--requestheader-extra-headers-prefix=X-Remote-Extra-

цей запит:

GET / HTTP/1.1
X-Remote-User: fido
X-Remote-Group: dogs
X-Remote-Group: dachshunds
X-Remote-Extra-Acme.com%2Fproject: some-project
X-Remote-Extra-Scopes: openid
X-Remote-Extra-Scopes: profile

призведе до такої інформації про користувача:

name: fido
groups:
- dogs
- dachshunds
extra:
  acme.com/project:
  - some-project
  scopes:
  - openid
  - profile

Для запобігання підробці заголовків, проксі-сервер автентифікації повинен представити дійсний клієнтський сертифікат на API-сервер для перевірки за допомогою вказаного CA перед тим, як заголовки запиту будуть перевірені. ПОПЕРЕДЖЕННЯ: не використовуйте CA, який використовується в іншому контексті, якщо ви не розумієте ризики та механізми захисту використання CA.

  • --requestheader-client-ca-file Обовʼязково. Файл з сертифікатами у форматі PEM. Дійсний клієнтський сертифікат повинен бути представлений і перевірений за допомогою сертифікатів у вказаному файлі перед перевіркою заголовків запиту для імен користувачів.
  • --requestheader-allowed-names Необовʼязково. Список значень Common Name (CN). Якщо встановлено, дійсний клієнтський сертифікат з CN з вказаного списку повинен бути представлений перед перевіркою заголовків запиту для імен користувачів. Якщо порожній, дозволений будь-який CN.

Анонімні запити

Коли увімкнено, запити, які не відхиляються іншими налаштованими методами автентифікації, розглядаються як анонімні запити та отримують імʼя користувача system:anonymous і групу system:unauthenticated.

Наприклад, на сервері з налаштованою автентифікацією за допомогою токенів та увімкненим анонімним доступом, запит із недійсним токеном автентифікації отримає помилку 401 Unauthorized. Запит без токена автентифікації буде розглядатися як анонімний запит.

У версіях 1.5.1-1.5.x анонімний доступ типово вимкнено і може бути увімкнено шляхом додавання опції --anonymous-auth=true до API-сервера.

У версіях 1.6+ анонімний доступ типово увімкнено, якщо використовується режим авторизації, відмінний від AlwaysAllow, і може бути вимкнено шляхом додавання опції --anonymous-auth=false до API-сервера. Починаючи з версії 1.6, авторизатори ABAC і RBAC вимагають явної авторизації користувача system:anonymous або групи system:unauthenticated, тому застарілі правила політики, які надають доступ користувачеві * або групі *, не включають анонімних користувачів.

Налаштування анонімної автентифікації

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.31 [alpha]

AuthenticationConfiguration можна використовувати для налаштування анонімного автентифікатора. Щоб увімкнути налаштування анонімної автентифікації через конфігураційний файл, потрібно увімкнути функціональну можливість AnonymousAuthConfigurableEndpoints. Коли ця функціональна можливість увімкнена, ви не можете встановити прапорець --anonymous-auth.

Основна перевага налаштування анонімного автентифікатора за допомогою конфігураційного файлу автентифікації полягає в тому, що, крім увімкнення та вимкнення анонімної автентифікації, ви також можете налаштувати, які точки доступу що підтримують анонімну автентифікацію.

Ось приклад конфігураційного файлу автентифікації:

---
#
# УВАГА: це приклад конфігурації.
#        Не використовуйте його для вашого власного кластера!
#
apiVersion: apiserver.config.k8s.io/v1beta1
kind: AuthenticationConfiguration
anonymous:
  enabled: true
  conditions:
  - path: /livez
  - path: /readyz
  - path: /healthz

У наведеній конфігурації лише точки доступу /livez, /readyz і /healthz доступні для анонімних запитів. Будь-які інші точки доступу будуть недоступні, навіть якщо це дозволено конфігурацією RBAC.

Імперсонізація користувачів

Користувач може діяти від імені іншого користувача через заголовки імперсонізації. Це дозволяє вручну перевизначити інформацію про користувача, який виконує запит. Наприклад, адміністратор може використовувати цю функцію для налагодження політики авторизації, тимчасово імперсонуючи іншого користувача та перевіряючи, чи запит відхилено.

Запити з імперсонізацією спочатку автентифікуються як запити від імені запитувача, потім переключаються на імперсоновану інформацію про користувача.

  • Користувач робить API-запит зі своїми обліковими даними і заголовками імперсонізації.
  • API-сервер автентифікує користувача.
  • API-сервер переконується, що автентифіковані користувачі мають права імперсонізації.
  • Інформація про користувача замінюється значеннями імперсонізації.
  • Запит оцінюється, авторизація діє на основі імперсонованої інформації про користувача.

Для здійснення запиту на імперсонізацію можна використовувати такі заголовки HTTP:

  • Impersonate-User: Імʼя користувача, від імені якого потрібно діяти.
  • Impersonate-Group: Імʼя групи, від імені якої потрібно діяти. Може надаватися кілька разів для встановлення кількох груп. Опціонально. Потрібен Impersonate-User.
  • Impersonate-Extra-( extra name ): Динамічний заголовок для звʼязування додаткових полів з користувачем. Опціонально. Потрібен Impersonate-User. Для збереження послідовності ( extra name ) повинно бути малими літерами, а будь-які символи, які не є допустимими в HTTP-заголовках, МАЮТЬ бути у форматі utf8 та процентно-кодовані.
  • Impersonate-Uid: Унікальний ідентифікатор, який представляє імперсонованого користувача. Опціонально. Потрібен Impersonate-User. Kubernetes не накладає жодних вимог щодо формату цього рядка.

Приклад заголовків імперсонізації при імперсонуванні користувача з групами:

Impersonate-User: jane.doe@example.com
Impersonate-Group: developers
Impersonate-Group: admins

Приклад заголовків імперсонізації при імперсонуванні користувача з UID та додатковими полями:

Impersonate-User: jane.doe@example.com
Impersonate-Extra-dn: cn=jane,ou=engineers,dc=example,dc=com
Impersonate-Extra-acme.com%2Fproject: some-project
Impersonate-Extra-scopes: view
Impersonate-Extra-scopes: development
Impersonate-Uid: 06f6ce97-e2c5-4ab8-7ba5-7654dd08d52b

Для використання kubectl встановіть прапорець --as для налаштування заголовка Impersonate-User, встановіть прапорець --as-group для налаштування заголовка Impersonate-Group.

kubectl drain mynode
Error from server (Forbidden): User "clark" cannot get nodes at the cluster scope. (get nodes mynode)

Встановіть прапорці --as і --as-group:

kubectl drain mynode --as=superman --as-group=system:masters
node/mynode cordoned
node/mynode drained

Для імперсонізації користувача, групи, ідентифікатора користувача (UID) або додаткових полів, користувач, який виконує імперсонізацію, повинен мати можливість виконувати дію "impersonate" з типом атрибута, який імперсонується ("user", "group", "uid" і т.д.). Для кластерів, що використовують втулок авторизації RBAC, наступна роль ClusterRole охоплює правила, необхідні для налаштування заголовків імперсонізації користувачів і груп:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: impersonator
rules:
- apiGroups: [""]
  resources: ["users", "groups", "serviceaccounts"]
  verbs: ["impersonate"]

Для імперсонізації, додаткові поля та імперсоновані UID належать до групи apiGroup "authentication.k8s.io". Додаткові поля оцінюються як субресурси ресурсу "userextras". Щоб дозволити користувачеві використовувати заголовки імперсонізації для додаткового поля "scopes" та для UID, користувачеві слід надати таку роль:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: scopes-and-uid-impersonator
rules:
# Може встановлювати заголовок "Impersonate-Extra-scopes" та заголовок "Impersonate-Uid".
- apiGroups: ["authentication.k8s.io"]
  resources: ["userextras/scopes", "uids"]
  verbs: ["impersonate"]

Значення заголовків імперсонізації також можна обмежити, обмеживши набір resourceNames, які ресурс може приймати.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: limited-impersonator
rules:
# Може імперсонувати користувача "jane.doe@example.com"
- apiGroups: [""]
  resources: ["users"]
  verbs: ["impersonate"]
  resourceNames: ["jane.doe@example.com"]

# Може імперсонувати групи "developers" та "admins"
- apiGroups: [""]
  resources: ["groups"]
  verbs: ["impersonate"]
  resourceNames: ["developers","admins"]

# Може імперсонувати додаткове поле "scopes" зі значеннями "view" і "development"
- apiGroups: ["authentication.k8s.io"]
  resources: ["userextras/scopes"]
  verbs: ["impersonate"]
  resourceNames: ["view", "development"]

# Може імперсонувати UID "06f6ce97-e2c5-4ab8-7ba5-7654dd08d52b"
- apiGroups: ["authentication.k8s.io"]
  resources: ["uids"]
  verbs: ["impersonate"]
  resourceNames: ["06f6ce97-e2c5-4ab8-7ba5-7654dd08d52b"]

Втулки облікових даних client-go

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.22 [stable]

k8s.io/client-go та інструменти, які використовують його, такі як kubectl та kubelet, можуть виконувати зовнішню команду для отримання облікових даних користувача.

Ця функція призначена для клієнтських інтеграцій з протоколами автентифікації, які не підтримуються на рівні k8s.io/client-go (LDAP, Kerberos, OAuth2, SAML та ін.). Вутулок реалізує логіку, специфічну для протоколу, а потім повертає непрозорі облікові дані для використання. Майже всі випадки використання втулків автентифікації потребують наявності компоненту на стороні сервера з підтримкою автентифікації токенів webhook, щоб інтерпретувати формат облікових даних, який генерується клієнтським втулком.

Приклад використання

У гіпотетичному сценарії використання організація запускає зовнішню службу, яка обмінює облікові дані LDAP на підписані токени, специфічні для користувача. Служба також може відповідати на запити автентифікатора токенів webhook, щоб перевірити токени. Користувачам буде потрібно встановити втулок автентифікації на своїй робочій станції.

Для автентифікації в API:

  • Користувач видає команду kubectl.
  • Вутулок облікових даних запитує користувача облікові дані LDAP, обмінює облікові дані зовнішньою службою на токен.
  • Вутулок облікових даних повертає токен client-go, який використовує його як токен власника на сервері API.
  • Сервер API використовує автентифікатор токенів webhook, щоб надіслати TokenReview зовнішній службі.
  • Зовнішня служба перевіряє підпис на токені та повертає імʼя користувача та групи.

Налаштування

Втулки облікових даних налаштовуються через файли конфігурації kubectl як частина полів користувача.

apiVersion: v1
kind: Config
users:
- name: my-user
  user:
    exec:
      # Команда для виконання. Обовʼязково.
      command: "example-client-go-exec-plugin"

      # Версія API, яку слід використовувати при декодуванні ресурсу ExecCredentials. Обовʼязково.
      #
      # Версія API, що повертається втулком, ПОВИННА відповідати версії, вказаній тут.
      #
      # Щоб інтегруватися з інструментами, які підтримують кілька версій (наприклад, client.authentication.k8s.io/v1beta1),
      # встановіть змінну середовища, передайте аргумент інструменту, що вказує, яку версію очікує втулка виконання,
      # або прочитайте версію з обʼєкта ExecCredential у змінній середовища KUBERNETES_EXEC_INFO.
      apiVersion: "client.authentication.k8s.io/v1"

      # Змінні середовища, що встановлюються під час виконання втулку. Необовʼязково.
      env:
      - name: "FOO"
        value: "bar"

      # Аргументи, які передаються під час виконання втулку. Необовʼязково.
      args:
      - "arg1"
      - "arg2"

      # Текст, який показуєтсья користувачу, коли виконуваний файл не знайдено. Необовʼязково.
      installHint: |
        example-client-go-exec-plugin потрібно для автентифікації
        в поточному кластері.  Його можна встановити:

        На macOS: brew install example-client-go-exec-plugin

        На Ubuntu: apt-get install example-client-go-exec-plugin

        На Fedora: dnf install example-client-go-exec-plugin

        ...        

      # Чи надавати інформацію про кластер, яка може містити
      # дуже великі дані сертифікату CA, цьому втулка виконання як частину KUBERNETES_EXEC_INFO
      # змінної середовища.
      provideClusterInfo: true

      # Угода між втулком виконання та стандартним введенням/виведенням. Якщо
      # угода не може бути виконана, цей втулок виконання не буде запущено, та буде
      # повернено помилку. Допустимі значення: "Never" (цей втулок виконання ніколи не використовує стандартний ввід),
      # "IfAvailable" (цей втулок виконання хоче використовувати стандартний ввід, якщо він доступний),
      # або "Always" (цей втулок виконання вимагає стандартний ввід для роботи). Обовʼязково.
      interactiveMode: Never
clusters:
- name: my-cluster
  cluster:
    server: "https://172.17.4.100:6443"
    certificate-authority: "/etc/kubernetes/ca.pem"
    extensions:
    - name: client.authentication.k8s.io/exec # зарезервоване імʼя розширення для кожної конфігурації виконання кластера
      extension:
        arbitrary: config
        this: може бути надано через змінну середовища KUBERNETES_EXEC_INFO при встановленні provideClusterInfo
        you: ["можете", "покласти", "будь-що", "тут"]
contexts:
- name: my-cluster
  context:
    cluster: my-cluster
    user: my-user
current-context: my-cluster

apiVersion: v1
kind: Config
users:
- name: my-user
  user:
    exec:
      # Команда для виконання. Обовʼязково.
      command: "example-client-go-exec-plugin"

      # Версія API, яку слід використовувати при декодуванні ресурсу ExecCredentials. Обовʼязково.
      #
      # Версія API, повернута втулком, ПОВИННА відповідати версії, вказаній тут.
      #
      # Щоб інтегруватися з інструментами, які підтримують кілька версій (наприклад, client.authentication.k8s.io/v1),
      # встановіть змінну середовища, перед ```yaml
      apiVersion: "client.authentication.k8s.io/v1beta1"

      # Змінні середовища, що встановлюються під час виконання втулку. Необовʼязково.
      env:
      - name: "FOO"
        value: "bar"

      # Аргументи, які передаються під час виконання втулку. Необовʼязково.
      args:
      - "arg1"
      - "arg2"

      # Текст, який показується користувачу, коли виконуваний файл не знайдено. Необовʼязково.
      installHint: |
        example-client-go-exec-plugin потрібно для автентифікації
        в поточному кластері.  Його можна встановити:

        На macOS: brew install example-client-go-exec-plugin

        На Ubuntu: apt-get install example-client-go-exec-plugin

        На Fedora: dnf install example-client-go-exec-plugin

        ...        

      # Чи надавати інформацію про кластер, яка може містити
      # дуже великі дані сертифікату CA, цьому втулку виконання як частину KUBERNETES_EXEC_INFO
      # змінної середовища.
      provideClusterInfo: true

      # Угода між втулком виконання та стандартним введенням/виведенням. Якщо
      # угода не може бути виконана, цей втулок виконання не буде запущено, а буде
      # повернено помилку. Допустимі значення: "Never" (цей втулок виконання ніколи не використовує стандартний ввід),
      # "IfAvailable" (цей втулок виконання хоче використовувати стандартний ввід, якщо він доступний),
      # або "Always" (цей втулок виконання вимагає стандартний ввід для роботи). Необовʼязково.
      # За замовчуванням - "IfAvailable".
      interactiveMode: Never
clusters:
- name: my-cluster
  cluster:
    server: "https://172.17.4.100:6443"
    certificate-authority: "/etc/kubernetes/ca.pem"
    extensions:
    - name: client.authentication.k8s.io/exec # зарезервоване імʼя розширення для кожної конфігурації виконання кластера
      extension:
        arbitrary: config
        this: може бути надано через змінну середовища KUBERNETES_EXEC_INFO при встановленні provideClusterInfo
        you: ["можете", "покласти", "будь-що", "тут"]
contexts:
- name: my-cluster
  context:
    cluster: my-cluster
    user: my-user
current-context: my-cluster

Відносні шляхи до команд інтерпретуються відносно теки файлу конфігурації. Якщо KUBECONFIG встановлено на /home/jane/kubeconfig, а команда виконання — ./bin/example-client-go-exec-plugin, то виконується бінарний файл /home/jane/bin/example-client-go-exec-plugin.

- name: my-user
  user:
    exec:
      # Шлях відносно теки kubeconfig
      command: "./bin/example-client-go-exec-plugin"
      apiVersion: "client.authentication.k8s.io/v1"
      interactiveMode: Never

Формати вводу та виводу

Виконана команда виводить обʼєкт ExecCredential у stdout. k8s.io/client-go автентифікується в Kubernetes API, використовуючи отримані облікові дані в status. Виконана команда отримує обʼєкт ExecCredential на вхід через змінну середовища KUBERNETES_EXEC_INFO. Цей вхід містить корисну інформацію, таку як очікувана версія API поверненого обʼєкта ExecCredential та чи може втулок використовувати stdin для взаємодії з користувачем.

Під час запуску з інтерактивної сесії (тобто термінал), stdin може бути наданий прямо втулку. Втулки повинні використовувати поле spec.interactive вхідного обʼєкта ExecCredential зі змінної середовища KUBERNETES_EXEC_INFO для визначення, чи був наданий stdin. Вимоги втулка до stdin (тобто чи stdin є необовʼязковим, строго обовʼязковим або ніколи не використовується для успішного запуску втулка) вказується за допомогою поля user.exec.interactiveMode у kubeconfig (див. таблицю нижче для дійсних значень). Поле user.exec.interactiveMode є необовʼязковим у client.authentication.k8s.io/v1beta1 і обовʼязковим у client.authentication.k8s.io/v1.

Значення interactiveMode
Значення interactiveModeЗначення
NeverЦей втулок виконання ніколи не потребує використання стандартного вводу, і тому втулок виконання буде запущений незалежно від того, чи доступний стандартний ввід для введення користувача.
IfAvailableЦей втулок виконання хоче використовувати стандартний ввід, якщо він доступний, але може працювати, якщо стандартний ввід недоступний. Тому втулок виконання буде запущений незалежно від наявності введення з стандартного вводу. Якщо стандартний ввід доступний для введення користувача, він буде наданий цьому втулку виконання.
AlwaysЦей втулок виконання потребує стандартний ввід для роботи, і тому втулок виконання буде запущений лише тоді, коли стандартний ввід доступний для введення користувача. Якщо стандартний ввід недоступний для введення користувача, втулок виконання не буде запущений, і виконавець втулку поверне помилку.

Для використання облікових даних токена власника, втулок повертає токен у статусі ExecCredential

{
  "apiVersion": "client.authentication.k8s.io/v1",
  "kind": "ExecCredential",
  "status": {
    "token": "my-bearer-token"
  }
}

{
  "apiVersion": "client.authentication.k8s.io/v1beta1",
  "kind": "ExecCredential",
  "status": {
    "token": "my-bearer-token"
  }
}

Альтративно, можна повернути PEM-кодований сертифікат клієнта та ключ для використання TLS-автентифікації клієнта. Якщо втулок повертає різний сертифікат та ключ при наступному виклику, k8s.io/client-go закриє існуючі зʼєднання з сервером, щоб змусити новий TLS-обмін.

Якщо вказано, що clientKeyData та clientCertificateData повинні бути присутніми.

clientCertificateData може містити додаткові проміжні сертифікати для відправки на сервер.

{
  "apiVersion": "client.authentication.k8s.io/v1",
  "kind": "ExecCredential",
  "status": {
    "clientCertificateData": "-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----",
    "clientKeyData": "-----BEGIN RSA PRIVATE KEY-----\n...\n-----END RSA PRIVATE KEY-----"
  }
}

{
  "apiVersion": "client.authentication.k8s.io/v1beta1",
  "kind": "ExecCredential",
  "status": {
    "clientCertificateData": "-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----",
    "clientKeyData": "-----BEGIN RSA PRIVATE KEY-----\n...\n-----END RSA PRIVATE KEY-----"
  }
}

Додатково відповідь може включати термін дії облікового запису, форматований як RFC 3339 мітка часу.

Наявність або відсутність терміну дії має такий вплив:

  • Якщо термін дії включений, токен власника та TLS-облікові дані кешуються до моменту закінчення строку дії, або якщо сервер відповідає з кодом стану HTTP 401, або при завершенні процесу.
  • Якщо термін дії відсутній, токен власника та TLS-облікові дані кешуються до моменту, коли сервер відповідає з кодом стану HTTP 401 або до моменту завершення процесу.

{
  "apiVersion": "client.authentication.k8s.io/v1",
  "kind": "ExecCredential",
  "status": {
    "token": "my-bearer-token",
    "expirationTimestamp": "2018-03-05T17:30:20-08:00"
  }
}

{
  "apiVersion": "client.authentication.k8s.io/v1beta1",
  "kind": "ExecCredential",
  "status": {
    "token": "my-bearer-token",
    "expirationTimestamp": "2018-03-05T17:30:20-08:00"
  }
}

Щоб дозволити втулку виконання отримувати інформацію, що специфічна для кластера, встановіть provideClusterInfo у поле user.exec в kubeconfig. Втулок потім отримає цю інформацію, специфічну для кластера, у змінній середовища KUBERNETES_EXEC_INFO. Інформацію з цієї змінної середовища можна використовувати для виконання логіки отримання облікових даних, специфічних для кластера. Наступний маніфест ExecCredential описує зразок інформації для кластера.

{
  "apiVersion": "client.authentication.k8s.io/v1",
  "kind": "ExecCredential",
  "spec": {
    "cluster": {
      "server": "https://172.17.4.100:6443",
      "certificate-authority-data": "LS0t...",
      "config": {
        "arbitrary": "config",
        "this": "can be provided via the KUBERNETES_EXEC_INFO environment variable upon setting provideClusterInfo",
        "you": ["can", "put", "anything here"]
    },
    "interactive": true
  }
}

{
  "apiVersion": "client.authentication.k8s.io/v1beta1",
  "kind": "ExecCredential",
  "spec": {
    "cluster": {
      "server": "https://172.17.4.100:6443",
      "certificate-authority-data": "LS0t...",
      "config": {
        "arbitrary": "config",
        "this": "can be provided via the KUBERNETES_EXEC_INFO environment variable upon setting provideClusterInfo",
        "you": ["can", "put", "anything", "here"]
      }
    },
    "interactive": true
  }
}

Доступ API до інформації про автентифікацію для клієнта

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.28 [stable]

Якщо ваш кластер має включений API, ви можете використовувати API SelfSubjectReview, щоб дізнатися, як ваш кластер Kubernetes показує вашу інформацію про автентифікацію, щоб ідентифікувати вас як клієнта. Це працює незалежно від того, чи автентифікуєтеся ви як користувач (зазвичай представляючи реальну особу), чи як обліковий запис ServiceAccount.

Обʼєкти SelfSubjectReview не мають полів, які конфігуруються. При отриманні запиту API-сервер Kubernetes заповнює статус атрибутами користувача та повертає його користувачеві.

Приклад запиту (тіло буде SelfSubjectReview):

POST /apis/authentication.k8s.io/v1/selfsubjectreviews
{
  "apiVersion": "authentication.k8s.io/v1",
  "kind": "SelfSubjectReview"
}

Приклад відповіді:

{
  "apiVersion": "authentication.k8s.io/v1",
  "kind": "SelfSubjectReview",
  "status": {
    "userInfo": {
      "name": "jane.doe",
      "uid": "b6c7cfd4-f166-11ec-8ea0-0242ac120002",
      "groups": [
        "viewers",
        "editors",
        "system:authenticated"
      ],
      "extra": {
        "provider_id": ["token.company.example"]
      }
    }
  }
}

Для зручності доступний також запит kubectl auth whoami. Виконання цієї команди призведе до наступного виводу (але різні атрибути користувача будуть показані):

  • Простий приклад виводу

    ATTRIBUTE         VALUE
    Username          jane.doe
    Groups            [system:authenticated]
    
  • Складний приклад, який включає додаткові атрибути

    ATTRIBUTE         VALUE
    Username          jane.doe
    UID               b79dbf30-0c6a-11ed-861d-0242ac120002
    Groups            [students teachers system:authenticated]
    Extra: skills     [reading learning]
    Extra: subjects   [math sports]
    

За допомогою прапорця виводу також можна надрукувати JSON- або YAML-представлення результату:

{
  "apiVersion": "authentication.k8s.io/v1",
  "kind": "SelfSubjectReview",
  "status": {
    "userInfo": {
      "username": "jane.doe",
      "uid": "b79dbf30-0c6a-11ed-861d-0242ac120002",
      "groups": [
        "students",
        "teachers",
        "system:authenticated"
      ],
      "extra": {
        "skills": [
          "reading",
          "learning"
        ],
        "subjects": [
          "math",
          "sports"
        ]
      }
    }
  }
}

apiVersion: authentication.k8s.io/v1
kind: SelfSubjectReview
status:
  userInfo:
    username: jane.doe
    uid: b79dbf30-0c6a-11ed-861d-0242ac120002
    groups:
    - students
    - teachers
    - system:authenticated
    extra:
      skills:
      - reading
      - learning
      subjects:
      - math
      - sports

Ця функція є дуже корисною, коли використовується складний потік автентифікації в кластері Kubernetes, наприклад, якщо ви використовуєте автентифікацію за допомогою токена через webhook або автентифікацію через проксі.

Стандартно всі автентифіковані користувачі можуть створювати обʼєкти SelfSubjectReview, коли функція APISelfSubjectReview включена. Це дозволено за допомогою кластерної ролі system:basic-user.

Що далі

6.3.2 - Автентифікація за допомогою Bootstrap-токенів

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.18 [stable]

Bootstrap-токени — це простий токен на предʼявника, який призначений для використання під час створення нових кластерів або приєднання нових вузлів до наявного кластера. Він був створений для підтримки kubeadm, але може використовуватися в інших контекстах для користувачів, які бажають створювати кластери без kubeadm. Також він призначений для роботи, через політику RBAC, з kubelet TLS Bootstrapping.

Огляд Bootstrap-токенів

Bootstrap-токени визначені як певний тип secretʼів (bootstrap.kubernetes.io/token), що знаходяться в просторі імен kube-system. Ці secret читаються Bootstrap Authenticator з API Server. Протерміновані токени видаляються контролером TokenCleaner у Controller Manager. Токени також використовуються для створення підпису для конкретного ConfigMap, який використовується у процесі "виявлення" через контролер BootstrapSigner.

Формат токена

Bootstrap-токени мають форму abcdef.0123456789abcdef. Більш формально, вони повинні відповідати регулярному виразу [a-z0-9]{6}\.[a-z0-9]{16}.

Перша частина токена — це "ID токена" і вважається публічною інформацією. Вона використовується, коли потрібно посилатися на токен без розкриття секретної частини, яка використовується для автентифікації. Друга частина — це "Секрет токена" і нею треба ділитися тільки з довіреними сторонами.

Увімкнення автентифікації за допомогою Bootstrap-токенів

Автентифікатор Bootstrap Token можна увімкнути за допомогою наступного прапорця на API-сервері:

--enable-bootstrap-token-auth

Після увімкнення, токени для завантаження можуть використовуватися як облікові дані токена на предʼявника для автентифікації запитів до API-сервера.

Authorization: Bearer 07401b.f395accd246ae52d

Токени автентифікуються як імʼя користувача system:bootstrap:<token id> і є членами групи system:bootstrappers. Додаткові групи можуть бути вказані в секреті токена.

Протерміновані токени можуть бути автоматично видалені шляхом увімкнення контролера tokencleaner у Controller Manager.

--controllers=*,tokencleaner

Формат Secretʼу Bootstrap-токена

Кожен дійсний токен підтримується секретом у просторі імен kube-system. Повний документ проєктування можна знайти тут.

Ось як виглядає цей Secret.

apiVersion: v1
kind: Secret
metadata:
  # Назва МАЄ бути у формі "bootstrap-token-<token id>"
  name: bootstrap-token-07401b
  namespace: kube-system

# Тип МАЄ бути 'bootstrap.kubernetes.io/token'
type: bootstrap.kubernetes.io/token
stringData:
  # Опис, зрозумілий людині. Необовʼязково.
  description: "Стандартний bootstrap-токен, згенерований 'kubeadm init'."

  # ID та секрет токена. Обовʼязково.
  token-id: 07401b
  token-secret: f395accd246ae52d

  # Термін дії. Необовʼязково.
  expiration: 2017-03-10T03:22:11Z

  # Дозволені використання.
  usage-bootstrap-authentication: "true"
  usage-bootstrap-signing: "true"

  # Додаткові групи для автентифікації токена. Мають починатися з "system:bootstrappers:"
  auth-extra-groups: system:bootstrappers:worker,system:bootstrappers:ingress

Тип секрету має бути bootstrap.kubernetes.io/token, а назва має бути bootstrap-token-<token id>. Він також повинен знаходитися в просторі імен kube-system.

Члени usage-bootstrap-* вказують, для чого цей секрет призначений. Значення має бути встановлено в true, щоб увімкнути відповідне використання.

  • usage-bootstrap-authentication вказує, що токен може використовуватися для автентифікації до API-сервера як токен-носій.
  • usage-bootstrap-signing вказує, що токен може використовуватися для підпису ConfigMap cluster-info, як описано нижче.

Поле expiration контролює термін дії токена. Протерміновані токени відхиляються при спробі автентифікації та ігноруються під час підпису ConfigMap. Значення терміну дії кодується як абсолютний UTC-час за стандартом RFC3339. Увімкніть контролер tokencleaner, щоб автоматично видаляти протерміновані токени.

Управління токенами за допомогою kubeadm

Ви можете використовувати інструмент kubeadm для управління токенами на запущеному кластері. Деталі дивіться в документації kubeadm token.

Підпис ConfigMap

Окрім автентифікації, токени можуть використовуватися для підпису ConfigMap. Це використовується на ранніх етапах процесу завантаження кластера до того, як клієнт довіряє API-серверу. Підписаний ConfigMap може бути автентифікований спільним токеном.

Увімкніть підпис ConfigMap, увімкнувши контролер bootstrapsigner у Controller Manager.

--controllers=*,bootstrapsigner

ConfigMap, який підписується, це cluster-info у просторі імен kube-public. Типовий процес полягає в тому, що клієнт читає цей ConfigMap без автентифікації та ігноруючи помилки TLS. Потім він перевіряє коректність ConfigMap, переглядаючи підпис, вбудований у ConfigMap.

ConfigMap може виглядати так:

apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-info
  namespace: kube-public
data:
  jws-kubeconfig-07401b: eyJhbGciOiJIUzI1NiIsImtpZCI6IjA3NDAxYiJ9..tYEfbo6zDNo40MQE07aZcQX2m3EB2rO3NuXtxVMYm9U
  kubeconfig: |
    apiVersion: v1
    clusters:
    - cluster:
        certificate-authority-data: <дуже довгі дані сертифіката>
        server: https://10.138.0.2:6443
      name: ""
    contexts: []
    current-context: ""
    kind: Config
    preferences: {}
    users: []    

Елемент kubeconfig у ConfigMap є конфігураційним файлом, який містить лише інформацію про кластер. Ключовим моментом, що передається, є certificate-authority-data. Це може бути розширено в майбутньому.

Підпис є підписом JWS, що використовує "відокремлений" режим. Щоб перевірити підпис, користувач має закодувати вміст kubeconfig відповідно до правил JWS (закодовано base64, відкидаючи будь-які кінцеві =). Цей закодований вміст потім використовується для формування повного JWS шляхом вставки його між 2 крапками. Ви можете перевірити JWS, використовуючи схему HS256 (HMAC-SHA256) з повним токеном (наприклад, 07401b.f395accd246ae52d) як спільний секрет. Користувачі повинні перевірити, що використовується HS256.

Додаткову інформацію можна знайти в розділі докладні відомості про реалізацію kubeadm.

6.3.3 - Авторизація

Деталі механізмів авторизації Kubernetes і підтримувані режими авторизації.

Авторизація в Kubernetes відбувається після автентифікації. Зазвичай клієнт, що робить запит, має бути автентифікований (увійти в систему), перш ніж його запит може бути дозволений; однак, Kubernetes також дозволяє анонімні запити за деяких обставин.

Для огляду того, як авторизація вписується в ширший контекст контролю доступу до API, читайте Контроль доступу до Kubernetes API.

Вердикти авторизації

Авторизація запитів до API в Kubernetes відбувається всередині API-сервера. API-сервер оцінює всі атрибути запиту щодо всіх політик, потенційно також звертаючись до зовнішніх сервісів, і потім дозволяє або відхиляє запит.

Усі частини запиту до API повинні бути дозволені деяким механізмом авторизації, щоб він міг продовжити виконання. Іншими словами: стандартно доступ заборонений.

Коли налаштовано кілька модулів авторизації, кожен перевіряється по черзі. Якщо будь-який авторизатор схвалює або відхиляє запит, це рішення негайно повертається і жоден інший авторизатор не перевіряється. Якщо всі модулі не мають думки щодо запиту, то запит відхиляється. Загальний вердикт "відхилено" означає, що API-сервер відхиляє запит і відповідає зі статусом HTTP 403 (Forbidden).

Атрибути запиту, що використовуються для авторизації

Kubernetes розглядає тільки наступні атрибути запиту до API:

  • user — Рядок user, наданий під час автентифікації.
  • group — Список імен груп, до яких належить автентифікований користувач.
  • extra — Map довільних рядкових ключів з рядковими значеннями, надана шаром автентифікації.
  • API — Вказує, чи є запит запитом на ресурс API.
  • Request path — Шлях до різних нересурсних точок доступу, таких як /api або /healthz.
  • API request verb — Дієслова API, такі як get, list, create, update, patch, watch, delete і deletecollection, використовуються для запитів до ресурсів. Щоб визначити дієслово запиту для точки доступу API ресурсу, дивіться дієслова запитів та авторизація.
  • HTTP request verb — Методи HTTP в нижньому регістрі, такі як get, post, put і delete, використовуються для нересурсних запитів.
  • Resource — Ідентифікатор або імʼя ресурсу, до якого здійснюється доступ (тільки для запитів до ресурсів). Для запитів до ресурсів, що використовують дієслова get, update, patch і delete, ви повинні надати імʼя ресурсу.
  • Subresource — Субесурс, до якого здійснюється доступ (тільки для запитів до ресурсів).
  • Namespace — Простір імен обʼєкта, до якого здійснюється доступ (тільки для запитів до ресурсів у просторі імен).
  • API group — Група API, до якої здійснюється доступ (тільки для запитів до ресурсів). Порожній рядок позначає основну групу API.

Дієслова запиту та авторизація

Нересурсні запити

Запити до точок доступу, відмінних від /api/v1/... або /apis/<group>/<version>/..., вважаються нересурсними запитами та використовують метод HTTP як дієслово в нижньому регістрі. Наприклад, виконання запиту GET за допомогою HTTP до точок доступу, таких як /api або /healthz, буде використовувати get як дієслово.

Ресурсні запити

Щоб визначити дієслово запиту для точки доступу API ресурсу, Kubernetes показує використаний HTTP метод і розглядає, чи діє запит на індивідуальний ресурс чи на колекцію ресурсів:

HTTP методдієслово запиту
POSTcreate
GET, HEADget (для індивідуальних ресурсів), list (для колекцій, включаючи повний вміст обʼєктів), watch (для спостереження за індивідуальним ресурсом або колекцією ресурсів)
PUTupdate
PATCHpatch
DELETEdelete (для індивідуальних ресурсів), deletecollection (для колекцій)

Іноді Kubernetes перевіряє авторизацію для додаткових дозволів, використовуючи спеціалізовані дієслова. Наприклад:

  • Особливі випадки автентифікації
    • Дієслово impersonate для users, groups, і serviceaccounts в основній групі API, та userextras у групі API authentication.k8s.io.
  • Авторизація CertificateSigningRequests
    • Дієслово approve для CertificateSigningRequests, та update для переглядів наявних схвалень
  • RBAC
    • Дієслова bind та escalate для ресурсів roles та clusterroles у групі API rbac.authorization.k8s.io.

Контекст авторизації

Kubernetes очікує атрибути, які є загальними для запитів до REST API. Це означає, що авторизація в Kubernetes працює з наявними системами контролю доступу на рівні організації або хмарного провайдера, які можуть обробляти інші API крім Kubernetes API.

Режими авторизації

API-сервер Kubernetes може авторизувати запит, використовуючи один з декількох режимів авторизації:

AlwaysAllow
Цей режим дозволяє всі запити, що несе ризики для безпеки. Використовуйте цей режим авторизації тільки якщо вам не потрібна авторизація для ваших запитів до API (наприклад, для тестування).
AlwaysDeny
Цей режим блокує всі запити. Використовуйте цей режим авторизації тільки для тестування.
ABAC (контроль доступу на основі атрибутів)
Режим ABAC в Kubernetes визначає парадигму управління доступом, згідно з якою права доступу надаються користувачам за допомогою політик, які обʼєднують атрибути разом. Політики можуть використовувати будь-який тип атрибутів (атрибути користувача, атрибути ресурсу, обʼєкта, середовища тощо).
RBAC (контроль доступу на основі ролей)
Kubernetes RBAC — це метод регулювання доступу до компʼютерних або мережевих ресурсів на основі ролей окремих користувачів в організації. У цьому контексті доступ — це можливість окремого користувача виконувати певне завдання, наприклад, переглядати, створювати або змінювати файл. В цьому режимі Kubernetes використовує групу API rbac.authorization.k8s.io для прийняття рішень щодо авторизації, що дозволяє вам динамічно налаштовувати політики дозволів через API Kubernetes.
Node
Спеціальний режим авторизації, який надає дозволи для kubeletʼів на основі запланованих до запуску Podʼів. Щоб дізнатися більше про режим авторизації вузла, див. Авторизація вузла.
Webhook
Kubernetes режим webhook для авторизації робить синхронний HTTP-виклик, блокуючи запит до тих пір, поки віддалений HTTP-сервіс не відповість на нього. Ви можете написати власне програмне забезпечення для обробки виклику або використовувати рішення з екосистеми.

Конфігурація режиму авторизації

Ви можете налаштувати ланцюжок авторизації API сервера Kubernetes, використовуючи або параметри командного рядка, або, як бета-функцію, використовуючи конфігураційний файл.

Ви повинні вибрати один з двох підходів до конфігурації: задати обидва шляхи --authorization-config і налаштувати вебхук авторизації за допомогою аргументів командного рядка --authorization-mode та --authorization-webhook-* не допускається. Якщо ви спробуєте це зробити, API сервер повідомить про помилку під час запуску та одразу завершить роботу.

Конфігурація режиму авторизації через командний рядок

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.8 [stable]

Ви можете використовувати наступні режими:

  • --authorization-mode=ABAC (режим контролю доступу на основі атрибутів)
  • --authorization-mode=RBAC (режим контролю доступу на основі ролей)
  • --authorization-mode=Node (авторизатор вузлів)
  • --authorization-mode=Webhook (режим авторизації вебхуком)
  • --authorization-mode=AlwaysAllow (завжди дозволяє запити; несе ризики безпеки)
  • --authorization-mode=AlwaysDeny (завжди відхиляє запити)

Ви можете вибрати більше одного режиму авторизації; наприклад: --authorization-mode=Node,Webhook

Kubernetes перевіряє модулі авторизації на основі порядку, який ви вказуєте в командному рядку API сервера, тому раніше зазначений модуль має вищий пріоритет для дозволу або відмови в запиті.

Ви не можете поєднувати аргумент командного рядка --authorization-mode з аргументом командного рядка --authorization-config, який використовується для налаштування авторизації за допомогою локального файлу.

Для отримання додаткової інформації про аргументи командного рядка для API сервера, читайте довідник по kube-apiserver.

Налаштування API сервера за допомогою конфігураційного файлу авторизації

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.30 [beta]

Як бета-функція, Kubernetes дозволяє налаштовувати ланцюжки авторизації, які можуть включати декілька вебхуків. Елементи авторизації в цьому ланцюжку можуть мати чітко визначені параметри, які перевіряють запити в певному порядку, пропонуючи вам тонке налаштування, наприклад, явну відмову при невдачах.

Підхід з використанням конфігураційного файлу навіть дозволяє вам вказувати правила CEL для попередньої фільтрації запитів перед їх відправленням до вебхуків, допомагаючи вам уникнути непотрібних викликів. API сервер також автоматично перезавантажує ланцюжок авторизатора при зміні конфігураційного файлу.

Ви вказуєте шлях до конфігурації авторизації за допомогою аргументу командного рядка --authorization-config.

Якщо ви хочете використовувати параметри командного рядка замість конфігураційного файлу, це також є дійсним і підтримуваним підходом. Деякі можливості авторизації (наприклад: кілька вебхуків, політика відмови вебхука та правила попередньої фільтрації) доступні тільки при використанні конфігураційного файлу авторизації.

Приклад конфігурації

---
#
# НЕ ВИКОРИСТОВУЙТЕ КОНФІГУРАЦІЮ ТАК, ЯК ВОНА Є. ЦЕ ПРИКЛАД.
#
apiVersion: apiserver.config.k8s.io/v1beta1
kind: AuthorizationConfiguration
authorizers:
  * type: Webhook
    # Назва, що використовується для опису авторизатора
    # Це явно використовується в механізмі моніторингу для метрик
    # Примітка:
    #   - Перевірка цього поля схожа на перевірку міток K8s на сьогодні.
    # Обовʼязково, немає стандартного значення
    name: webhook
    webhook:
      # Тривалість кешування відповідей 'authorized' від вебхука
      # авторизатора.
      # Те саме, що і встановлення прапорця `--authorization-webhook-cache-authorized-ttl`.
      # Стандартно: 5m0s
      authorizedTTL: 30s
      # Тривалість кешування відповідей 'unauthorized' від вебхука
      # авторизатора.
      # Те саме, що і встановлення прапорця `--authorization-webhook-cache-unauthorized-ttl`.
      # Стандартно: 30 с
      unauthorizedTTL: 30s
      # Тайм-аут для запиту вебхука
      # Максимально допустимий: 30 с
      # Обовʼязково, немає стандартного значення
      timeout: 3s
      # Версія API для SubjectAccessReview в authorization.k8s.io, яка
      # надсилається до вебхука та очікується від нього.
      # Те саме, що і встановлення прапорця `--authorization-webhook-version`.
      # Обовʼязково, немає стандартного значення
      # Допустимі значення: v1beta1, v1
      subjectAccessReviewVersion: v1
      # MatchConditionSubjectAccessReviewVersion визначає версію SubjectAccessReview
      # за якою оцінюються вирази CEL
      # Допустимі значення: v1
      # Обовʼязково, немає стандартного значення
      matchConditionSubjectAccessReviewVersion: v1
      # Керує рішенням авторизації, коли запит вебхука не вдалося
      # виконати або отримано некоректну відповідь або помилки під час оцінки
      # виразів matchConditions.
      # Допустимі значення:
      #   - NoOpinion: продовжувати до наступних авторизаторів, щоб перевірити, чи дозволяє один з них запит
      #   - Deny: відхиляти запит без консультації з наступними авторизаторами
      # Обовʼязково, немає стандартного значення
      failurePolicy: Deny
      connectionInfo:
        # Керує тим, як вебхук повинен спілкуватися з сервером.
        # Допустимі значення:
        # - KubeConfig: використовуйте файл, вказаний у kubeConfigFile для пошуку сервера.
        # - InClusterConfig: використовуйте конфігурацію внутрішнього кластера для виклику API SubjectAccessReview,
        #   що розміщується kube-apiserver. Цей режим не дозволяється для kube-apiserver.
        type: KubeConfig
        # Шлях до файлу KubeConfig для інформації про підключення
        # Обовʼязково, якщо connectionInfo.Type = KubeConfig
        kubeConfigFile: /kube-system-authz-webhook.yaml
        # matchConditions - це список умов, які повинні бути виконані для того, щоб запит було відправлено на цей
        # вебхук. Порожній список matchConditions підходить для всіх запитів.
        # Є максимально допустимі 64 умови відповідності.
        #
        # Логіка точного порівняння така (в порядку):
        #   1. Якщо принаймні одна matchCondition оцінюється як FALSE, тоді вебхук пропускається.
        #   2. Якщо ВСІ matchConditions оцінюються як TRUE, тоді вебхук викликається.
        #   3. Якщо принаймні одна matchCondition оцінюється як помилка (але ні одна не є FALSE):
        #      - Якщо failurePolicy=Deny, тоді вебхук відхиляє запит.
        #      - Якщо failurePolicy=NoOpinion, тоді помилка ігнорується, а вебхук пропускається.
      matchConditions:
      # expression - це вираз CEL, який оцінюється для кожного запиту. Повертає булеве значення.
      # CEL вираз має доступ до вмісту SubjectAccessReview у версії v1.
      # Якщо версія у SubjectAccessReview в запиті змінної є v1beta1, 
      # вміст буде конвертовано у v1 перед оцінкою виразу CEL.
      #
      # Документація CEL: https://kubernetes.io/docs/reference/using-api/cel/
      #
      # лише надсилати запити ресурсівв до вебхука
      * expression: has(request.resourceAttributes)
      # лише перехоплювати запити до kube-system
      * expression: request.resourceAttributes.namespace == 'kube-system'
      # не перехоплювати запити від облікових записів служб kube-system
      * expression: !('system:serviceaccounts:kube-system' in request.user.groups)
  * type: Node
    name: node
  * type: RBAC
    name: rbac
  * type: Webhook
    name: in-cluster-authorizer
    webhook:
      authorizedTTL: 5 хв
      unauthorizedTTL: 30 с
      timeout: 3 с
      subjectAccessReviewVersion: v1
      failurePolicy: NoOpinion
      connectionInfo:
        type: InClusterConfig

Під час налаштування ланцюжка авторизації за допомогою файлу конфігурації переконайтеся, що всі вузли панелі управління мають однаковий вміст файлу. Зверніть увагу на конфігурацію API сервера при оновленні / зниженні версії вашого кластера. Наприклад, якщо ви оновлюєтеся з Kubernetes 1.30 до Kubernetes 1.31, вам потрібно переконатися, що файл конфігурації має формат, який розуміє Kubernetes 1.31, перш ніж ви оновите кластер. Якщо ви знижуєте версію до 1.30, вам потрібно відповідно налаштувати конфігурацію.

Конфігурація авторизації та перезавантаження

Kubernetes перезавантажує файл конфігурації авторизації, коли API сервер виявляє зміну у файлі, а також за 60-секундним графіком, якщо події змін не спостерігаються.

Підвищення привілеїв через створення або редагування робочих навантажень

Користувачі, які можуть створювати/редагувати Podʼи в просторі імен, або безпосередньо, або через обʼєкт, що дозволяє опосередковане управління робочими навантаженнями, можуть мати можливість підвищити свої привілеї в цьому просторі імен. Потенційні шляхи до підвищення привілеїв включають розширення API Kubernetes та повʼязані з ними контролери.

Шляхи підвищення привілеїв

Існують різні способи, за якими зловмисник або ненадійний користувач може отримати додаткові привілеї в межах простору імен, якщо ви дозволяєте їм запускати довільні Podʼи в цьому просторі імен:

  • Монтування довільних Secretʼів в цьому просторі імен
    • Може бути використано для доступу до конфіденційної інформації, призначеної для інших робочих навантажень
    • Може бути використано для отримання токена службового облікового запису більш привілейованого ServiceAccount
  • Використання довільних службових облікових записів в цьому просторі імен
    • Може виконувати дії Kubernetes API як інше робоче навантаження (імперсонізація)
    • Може виконувати будь-які привілейовані дії, які має цей ServiceAccount
  • Монтування або використання ConfigMaps, призначених для інших робочих навантажень в цьому просторі імен
    • Може бути використано для отримання інформації, призначеної для інших робочих навантажень, таких як імена хостів баз даних.
  • Монтування томів, призначених для інших робочих навантажень в цьому просторі імен
    • Може бути використано для отримання інформації, призначеної для інших робочих навантажень, та її зміни.

Перевірка доступу до API

kubectl надає підкоманду auth can-i для швидкого запиту до рівня авторизації API. Команда використовує API SelfSubjectAccessReview, щоб визначити, чи може поточний користувач виконати вказану дію, і працює незалежно від режиму авторизації, який використовується.

kubectl auth can-i create deployments --namespace dev

Вивід подібний до цього:

yes
kubectl auth can-i create deployments --namespace prod

Вивід подібний до цього:

no

Адміністратори можуть поєднувати це з імперсонізацією користувача, щоб визначити, які дії можуть виконувати інші користувачі.

kubectl auth can-i list secrets --namespace dev --as dave

Вивід подібний до цього:

no

Так само, щоб перевірити, чи може ServiceAccount з іменем dev-sa в просторі імен dev отримати списки Podʼів в просторі імен target:

kubectl auth can-i list pods \
    --namespace target \
    --as system:serviceaccount:dev:dev-sa

Вивід подібний до цього:

no

SelfSubjectAccessReview є частиною групи API authorization.k8s.io, яка викладає авторизацію сервера API для зовнішніх служб. Інші ресурси у цій групі включають:

SubjectAccessReview
Перегляд доступу для будь-якого користувача, не лише поточного. Корисно для делегування рішень про авторизацію серверу API. Наприклад, kubelet та API розширень сервери використовують це для визначення доступу користувача до своїх власних API.
LocalSubjectAccessReview
Подібно до SubjectAccessReview, але обмежено для конкретного простору імен.
SelfSubjectRulesReview
Перегляд, який повертає набір дій, які користувач може виконати в межах простору імен. Корисно для користувачів для швидкого узагальнення їх власного доступу, або для інтерфейсів користувача для приховування/відображення дій.

Ці API можна опитати, створивши звичайні ресурси Kubernetes, де поле відповіді status поверненого обʼєкта є результатом запиту. Наприклад:

kubectl create -f - -o yaml << EOF
apiVersion: authorization.k8s.io/v1
kind: SelfSubjectAccessReview
spec:
  resourceAttributes:
    group: apps
    resource: deployments
    verb: create
    namespace: dev
EOF

Створений SelfSubjectAccessReview схожий на:

apiVersion: authorization.k8s.io/v1
kind: SelfSubjectAccessReview
metadata:
  creationTimestamp: null
spec:
  resourceAttributes:
    group: apps
    resource: deployments
    namespace: dev
    verb: create
status:
  allowed: true
  denied: false

Що далі

6.3.4 - Використання RBAC авторизації

Контроль доступу на основі ролей (RBAC) — це метод регулювання доступу до компʼютерних або мережевих ресурсів на основі ролей окремих користувачів у вашій організації.

RBAC авторизація використовує групу API rbac.authorization.k8s.io група API для прийняття рішень щодо авторизації, дозволяючи вам динамічно налаштовувати політики через Kubernetes API.

Щоб увімкнути RBAC, запустіть API сервер з прапорцем --authorization-mode, встановленим на список, розділений комами, що включає RBAC; наприклад:

kube-apiserver --authorization-mode=Example,RBAC --other-options --more-options

Обʼєкти API

RBAC API визначає чотири типи обʼєктів Kubernetes: Role, ClusterRole, RoleBinding та ClusterRoleBinding. Ви можете описувати або змінювати обʼєкти RBAC за допомогою таких інструментів, як kubectl, так само як і будь-який інший обʼєкт Kubernetes.

Role та ClusterRole

RBAC Role або ClusterRole містять правила, які представляють набір дозволів. Дозволи є виключно адитивними (немає правил "заборони").

Role завжди встановлює дозволи в межах певного простору імен; коли ви створюєте Role, ви повинні вказати простір імен, до якого вона належить.

ClusterRole, на відміну, є ресурсом, який не належить до простору імен. Ресурси мають різні назви (Role і ClusterRole), оскільки обʼєкт Kubernetes завжди повинен бути або привʼязаним до простору імен, або не привʼязаним до простору імен; він не може бути одночасно і тим, і іншим.

ClusterRole мають кілька використань. Ви можете використовувати ClusterRole для:

  1. визначення дозволів на ресурси, що належать до простору імен, і надання доступу в межах окремих просторів імен
  2. визначення дозволів на ресурси, що належать до простору імен, і надання доступу до всіх просторів імен
  3. визначення дозволів на ресурси, що належать до кластера

Якщо ви хочете визначити роль в межах простору імен, використовуйте Role; якщо ви хочете визначити роль для всього кластера, використовуйте ClusterRole.

Приклад Role

Ось приклад Role в просторі імен "default", яку можна використовувати для надання доступу на читання до Podʼів:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""] # "" означає основну групу API
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

Приклад ClusterRole

ClusterRole може бути використана для надання тих самих дозволів, що й Role. Оскільки ClusterRole стосуються всього кластера, ви також можете використовувати їх для надання доступу до:

  • ресурсів, що належать до кластера (наприклад, вузли)

  • точок доступу, що не є ресурсами (наприклад, /healthz)

  • ресурсів, що належать до простору імен (наприклад, контейнерів), в усіх просторах імен

    Наприклад: ви можете використовувати ClusterRole для дозволу конкретному користувачу виконувати kubectl get pods --all-namespaces.

Ось приклад ClusterRole, яку можна використовувати для надання доступу на читання Secretʼів в будь-якому просторі імен або в усіх просторах імен (залежно від того, як вона звʼязана):

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  # "namespace" пропущено, оскільки ClusterRole не привʼязані до простору імен
  name: secret-reader
rules:
- apiGroups: [""]
  #
  # на рівні HTTP, назва ресурсу для доступу до обʼєктів Secret
  # це "secrets"
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

Назва обʼєкта Role або ClusterRole повинна бути дійсною назвою сегмента шляху.

RoleBinding та ClusterRoleBinding

RoleBinding надає дозволи, визначені в ролі, користувачу або групі користувачів та містить список субʼєктів (користувачів, груп або облікових записів сервісів) і посилання на роль, що надається. RoleBinding надає дозволи в межах конкретного простору імен, тоді як ClusterRoleBinding надає доступ на рівні всього кластера.

RoleBinding може посилатися на будь-яку Role в тому ж просторі імен. Альтернативно, RoleBinding може посилатися на ClusterRole і звʼязувати цю ClusterRole з простором імен RoleBinding. Якщо ви хочете звʼязати ClusterRole з усіма просторами імен у вашому кластері, використовуйте ClusterRoleBinding.

Назва обʼєкта RoleBinding або ClusterRoleBinding повинна бути дійсною назвою сегмента шляху.

Приклади RoleBinding

Ось приклад RoleBinding, який надає роль "pod-reader" користувачу "jane" в межах простору імен "default". Це дозволяє "jane" читати Podʼи в просторі імен "default".

apiVersion: rbac.authorization.k8s.io/v1
# Це рольове звʼязування дозволяє "jane" читати Podʼи в просторі імен "default".
# Ви повинні вже мати роль з назвою "pod-reader" в цьому просторі імен.
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
# Ви можете вказати більше одного "субʼєкта"
- kind: User
  name: jane # "name" чутливе до регістру
  apiGroup: rbac.authorization.k8s.io
roleRef:
  # "roleRef" вказує на звʼязування з Role / ClusterRole
  kind: Role # має бути Role або ClusterRole
  name: pod-reader # має збігатися з назвою Role або ClusterRole, з якою ви хочете звʼязати
  apiGroup: rbac.authorization.k8s.io

RoleBinding також може посилатися на ClusterRole для надання дозволів, визначених у цій ClusterRole, на ресурси в межах простору імен RoleBinding. Такий вид посилання дозволяє визначати набір загальних ролей для всього вашого кластера, а потім використовувати їх у декількох просторах імен.

Наприклад, хоча наступний RoleBinding посилається на ClusterRole, "dave" (субʼєкт, чутливий до регістру) зможе читати Secretʼи лише в просторі імен "development", оскільки простір імен RoleBinding (у його метаданих) — "development".

apiVersion: rbac.authorization.k8s.io/v1
# Це рольове звʼязування дозволяє "dave" читати Secretʼи в просторі імен "development".
# Ви повинні вже мати ClusterRole з назвою "secret-reader".
kind: RoleBinding
metadata:
  name: read-secrets
  #
  # Простір імен RoleBinding визначає, де надаються дозволи.
  # Це надає дозволи лише в просторі імен "development".
  namespace: development
subjects:
- kind: User
  name: dave # Name чутливе до регістру
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

Приклад ClusterRoleBinding

Щоб надати дозволи на рівні всього кластера, ви можете використовувати ClusterRoleBinding. Наступний ClusterRoleBinding дозволяє будь-якому користувачу з групи "manager" читати Secretʼи в будь-якому просторі імен.

apiVersion: rbac.authorization.k8s.io/v1
# Це звʼязування кластерної ролі дозволяє будь-якому користувачу з групи "manager" читати Secretʼи в будь-якому просторі імен.
kind: ClusterRoleBinding
metadata:
  name: read-secrets-global
subjects:
- kind: Group
  name: manager # Name чутливе до регістру
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

Після створення звʼязування ви не можете змінити Role або ClusterRole, на які вони посилаються. Якщо ви спробуєте змінити roleRef звʼязування, ви отримаєте помилку валідації. Якщо ви дійсно хочете змінити roleRef для звʼязування, вам потрібно видалити обʼєкт звʼязування і створити новий.

Існує дві причини для цього обмеження:

  1. Роблячи roleRef незмінним, можна надати комусь дозвіл update на наявний обʼєкт звʼязування, щоб він міг керувати списком субʼєктів, без можливості змінити роль, яка надається цим субʼєктам.
  2. Звʼязування з іншою роллю є принципово іншим звʼязуванням. Вимога видалення/створення нового звʼязування для зміни roleRef гарантує, що весь список субʼєктів у звʼязуванні має намір отримати нову роль (на відміну від можливості випадково змінити лише roleRef без перевірки того, чи всі наявні субʼєкти повинні отримати дозволи нової ролі).

Команда kubectl auth reconcile створює або оновлює файл маніфесту, що містить обʼєкти RBAC, і обробляє видалення та відновлення обʼєктів звʼязування, якщо необхідно змінити роль, на яку вони посилаються. Дивіться використання команд та приклади для отримання додаткової інформації.

Посилання на ресурси

У Kubernetes API більшість ресурсів представлені та доступні за допомогою рядкового представлення їхнього імені обʼєкта, наприклад, pods для Pod. RBAC посилається на ресурси, використовуючи точно таку ж назву, яка зʼявляється в URL для відповідної точки доступу API. Деякі Kubernetes API включають субресурс, такий як логи для Pod. Запит на логи Pod виглядає так:

GET /api/v1/namespaces/{namespace}/pods/{name}/log

У цьому випадку pods є ресурсом простору імен для Pod, а log є субресурсом pods. Щоб представити це в ролі RBAC, використовуйте слеш (/) для розділення ресурсу та субресурсу. Щоб дозволити субʼєкту читати pods і також отримувати доступ до субресурсу log для кожного з цих Pod, напишіть:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-and-pod-logs-reader
rules:
- apiGroups: [""]
  resources: ["pods", "pods/log"]
  verbs: ["get", "list"]

Ви також можете посилатися на ресурси за назвою для певних запитів через список resourceNames. Коли зазначено, запити можуть бути обмежені окремими екземплярами ресурсу. Ось приклад, що обмежує субʼєкт лише до get або update ConfigMap з назвою my-configmap:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: configmap-updater
rules:
- apiGroups: [""]
  #
  # на рівні HTTP, назва ресурсу для доступу до обʼєктів ConfigMap є "configmaps"
  resources: ["configmaps"]
  resourceNames: ["my-configmap"]
  verbs: ["update", "get"]

Замість того, щоб посилатися на окремі resources, apiGroups і verbs, ви можете використовувати символ підстановки *, щоб посилатися на всі такі обʼєкти. Для nonResourceURLs ви можете використовувати символ підстановки * як суфікс для глобального збігу. Для resourceNames порожній набір означає, що все дозволено. Ось приклад, що дозволяє виконувати будь-яку поточну і майбутню дію для всіх поточних та майбутніх ресурсів в API групі example.com. Це схоже на вбудовану роль cluster-admin.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: example.com-superuser # НЕ ВИКОРИСТОВУЙТЕ ЦЮ РОЛЬ, ЦЕ ЛИШЕ ПРИКЛАД
rules:
- apiGroups: ["example.com"]
  resources: ["*"]
  verbs: ["*"]

Агреговані ClusterRole

Ви можете агрегувати декілька ClusterRole в одну комбіновану ClusterRole. Контролер, який працює як частина панелі управління кластера, слідкує за обʼєктами ClusterRole з встановленим aggregationRule. aggregationRule визначає мітку селектора, яку використовує контролер для вибору інших обʼєктів ClusterRole, що мають бути обʼєднані у поле rules цього обʼєкта.

Ось приклад агрегованої ClusterRole:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: monitoring
aggregationRule:
  clusterRoleSelectors:
  - matchLabels:
      rbac.example.com/aggregate-to-monitoring: "true"
rules: [] # Панель управління автоматично заповнює правила

Якщо ви створюєте нову ClusterRole, що відповідає селектору міток поточної агрегованої ClusterRole, це зміна ініціює додавання нових правил до агрегованої ClusterRole. Ось приклад, що додає правила до ClusterRole "monitoring" шляхом створення іншої ClusterRole з міткою rbac.example.com/aggregate-to-monitoring: true.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: monitoring-endpoints
  labels:
    rbac.example.com/aggregate-to-monitoring: "true"
# При створенні ClusterRole "monitoring-endpoints",
# правила нижче будуть додані до ClusterRole "monitoring".
rules:
- apiGroups: [""]
  resources: ["services", "endpointslices", "pods"]
  verbs: ["get", "list", "watch"]

Стандартні ролі для користувачів використовують агрегацію ClusterRole. Це дозволяє вам, як адміністратору кластера, включати правила для спеціальних ресурсів, таких як ті, що надаються CustomResourceDefinitions або агрегованими API серверами, щоб розширити стандартні ролі.

Наприклад: наступні ClusterRole дозволяють стандартним ролям "admin" і "edit" керувати спеціальним ресурсом з назвою CronTab, тоді як роль "view" може виконувати лише читання ресурсів CronTab. Ви можете припустити, що обʼєкти CronTab називаються "crontabs" в URL, як це бачить API сервер.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: aggregate-cron-tabs-edit
  labels:
    # Додайте ці дозволи до стандартних ролей "admin" і "edit".
    rbac.authorization.k8s.io/aggregate-to-admin: "true"
    rbac.authorization.k8s.io/aggregate-to-edit: "true"
rules:
- apiGroups: ["stable.example.com"]
  resources: ["crontabs"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: aggregate-cron-tabs-view
  labels:
    # Додайте ці дозволи до стандартної ролі "view".
    rbac.authorization.k8s.io/aggregate-to-view: "true"
rules:
- apiGroups: ["stable.example.com"]
  resources: ["crontabs"]
  verbs: ["get", "list", "watch"]

Приклади ролей

Наступні приклади є фрагментами обʼєктів Role або ClusterRole, що показують лише секцію rules.

Дозволити читання ресурсів "pods" у базовій API Group:

rules:
- apiGroups: [""]
  #
  # на рівні HTTP, назва ресурсу для доступу до обʼєктів Pod
  # є "pods"
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

Дозволити читання/запис обʼєктів Deployment (на рівні HTTP: обʼєкти з "deployments" у частині ресурсу їх URL) в групах API "apps":

rules:
- apiGroups: ["apps"]
  #
  # на рівні HTTP, назва ресурсу для доступу до обʼєктів Deployment
  # є "deployments"
  resources: ["deployments"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

Дозволити читання Podʼів у базовій групі API, а також читання або запис ресурсів Job у групі API "batch":

rules:
- apiGroups: [""]
  #
  # на рівні HTTP, назва ресурсу для доступу до обʼєктів Pod
  # є "pods"
  resources: ["pods"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["batch"]
  #
  # на рівні HTTP, назва ресурсу для доступу до обʼєктів Job
  # є "jobs"
  resources: ["jobs"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

Дозволити читання ConfigMap з назвою "my-config" (повинно бути повʼязано з RoleBinding, щоб обмежити до одного ConfigMap в одному просторі імен):

rules:
- apiGroups: [""]
  #
  # на рівні HTTP, назва ресурсу для доступу до обʼєктів ConfigMap
  # є "configmaps"
  resources: ["configmaps"]
  resourceNames: ["my-config"]
  verbs: ["get"]

Дозволити читання ресурсу "nodes" у базовій групі (оскільки Node є кластерним ресурсом, це повинно бути у ClusterRole, повʼязаної з ClusterRoleBinding, щоб бути ефективним):

rules:
- apiGroups: [""]
  #
  # на рівні HTTP, назва ресурсу для доступу до обʼєктів Node
  # є "nodes"
  resources: ["nodes"]
  verbs: ["get", "list", "watch"]

Дозволити GET і POST запити до не-ресурсної точки доступу /healthz та всіх субшляхів (повинно бути в ClusterRole, повʼязаній з ClusterRoleBinding, щоб бути ефективним):

rules:
- nonResourceURLs: ["/healthz", "/healthz/*"] # '*' у nonResourceURL є суфіксом для глобального збігу
  verbs: ["get", "post"]

Посилання на субʼєктів

RoleBinding або ClusterRoleBinding привʼязує роль до субʼєктів. Субʼєктами можуть бути групи, користувачі або ServiceAccounts.

Kubernetes представляє імена користувачів у вигляді рядків. Це можуть бути: звичайні імена, такі як "alice"; імена в стилі електронної пошти, як "bob@example.com"; або числові ідентифікатори користувачів, представлені у вигляді рядків. Вам, як адміністратору кластера, належить налаштувати модулі автентифікації, щоб автентифікація генерувала імена користувачів у бажаному форматі.

У Kubernetes модулі Автентифікатора надають інформацію про групи. Групи, як і користувачі, представлені у вигляді рядків, і цей рядок не має жодних вимог до формату, крім того, що префікс system: зарезервований.

ServiceAccounts мають імена з префіксом system:serviceaccount:, і належать до груп, що мають імена з префіксом system:serviceaccounts:.

Приклади RoleBinding

Наступні приклади є фрагментами RoleBinding, що показують лише секцію subjects.

Для користувача з імʼям alice@example.com:

subjects:
- kind: User
  name: "alice@example.com"
  apiGroup: rbac.authorization.k8s.io

Для групи з імʼям frontend-admins:

subjects:
- kind: Group
  name: "frontend-admins"
  apiGroup: rbac.authorization.k8s.io

Для стандартного службового облікового запису у просторі імен "kube-system":

subjects:
- kind: ServiceAccount
  name: default
  namespace: kube-system

Для всіх службових облікових записів у просторі імен "qa":

subjects:
- kind: Group
  name: system:serviceaccounts:qa
  apiGroup: rbac.authorization.k8s.io

Для всіх службових облікових записів у будь-якому просторі імен:

subjects:
- kind: Group
  name: system:serviceaccounts
  apiGroup: rbac.authorization.k8s.io

Для всіх автентифікованих користувачів:

subjects:
- kind: Group
  name: system:authenticated
  apiGroup: rbac.authorization.k8s.io

Для всіх неавтентифікованих користувачів:

subjects:
- kind: Group
  name: system:unauthenticated
  apiGroup: rbac.authorization.k8s.io

Для всіх користувачів:

subjects:
- kind: Group
  name: system:authenticated
  apiGroup: rbac.authorization.k8s.io
- kind: Group
  name: system:unauthenticated
  apiGroup: rbac.authorization.k8s.io

Стандартні ролі та привʼязки ролей

API-сервери створюють набір стандартних обʼєктів ClusterRole і ClusterRoleBinding. Багато з них мають префікс system:, що вказує на те, що ресурс безпосередньо керується панеллю управління кластера. Усі стандартні ролі та привʼязки ролей мають мітку kubernetes.io/bootstrapping=rbac-defaults.

Автоматичне узгодження

При кожному запуску API-сервер оновлює стандартні ролі кластера, додаючи будь-які відсутні дозволи, та оновлює стандартні привʼязки ролей, додаючи будь-які відсутні субʼєкти. Це дозволяє кластеру виправляти випадкові зміни та допомагає підтримувати ролі та привʼязки ролей в актуальному стані, оскільки дозволи та субʼєкти змінюються у нових випусках Kubernetes.

Щоб відмовитися від цього узгодження, встановіть анотацію rbac.authorization.kubernetes.io/autoupdate на стандартній кластерній ролі або стандартній RoleBinding у значення false. Зверніть увагу, що відсутність стандартних дозволів та субʼєктів може призвести до несправних кластерів.

Автоматичне узгодження стандартно увімкнено, якщо авторизатор RBAC активний.

Ролі виявлення API

Стандартні кластерні привʼязки ролей дозволяють неавторизованим і авторизованим користувачам читати інформацію про API, яка вважається безпечною для публічного доступу (включаючи CustomResourceDefinitions). Щоб вимкнути анонімний неавторизований доступ, додайте прапорець --anonymous-auth=false до конфігурації API-сервера.

Щоб переглянути конфігурацію цих ролей через kubectl, запустіть:

kubectl get clusterroles system:discovery -o yaml
Ролі виявлення API Kubernetes RBAC
Стандартна ClusterRoleСтандартна ClusterRoleBindingОпис
system:basic-userГрупа system:authenticatedДозволяє користувачеві доступ лише для читання базової інформації про себе. До v1.14 ця роль також була стандартно повʼязана з system:unauthenticated.
system:discoveryГрупа system:authenticatedДозволяє доступ лише для читання точок доступу виявлення API, необхідних для виявлення та узгодження рівня API. До v1.14 ця роль також була стандартно повʼязана з system:unauthenticated.
system:public-info-viewerГрупи system:authenticated і system:unauthenticatedДозволяє доступ лише для читання несекретної інформації про кластер. Представлено у Kubernetes v1.14.

Ролі для користувачів

Деякі зі стандартних ClusterRoles не мають префікса system:. Вони включають ролі суперкористувача (cluster-admin), ролі, призначені для надання у всьому кластері за допомогою ClusterRoleBindings, а також ролі, призначені для надання у певних просторах імен простору імен за допомогою RoleBindings (admin, edit, view).

Ролі для користувачів використовують агрегацію ClusterRole, щоб дозволити адміністраторам включати правила для спеціальних ресурсів у ці ClusterRole. Щоб додати правила до ролей admin, edit або view, створіть ClusterRole з однією або кількома з наступних міток:

metadata:
  labels:
    rbac.authorization.k8s.io/aggregate-to-admin: "true"
    rbac.authorization.k8s.io/aggregate-to-edit: "true"
    rbac.authorization.k8s.io/aggregate-to-view: "true"

Стандартна ClusterRoleСтандартна ClusterRoleBindingОпис
cluster-adminГрупа system:mastersДозволяє доступ суперкористувача для виконання будь-якої дії на будь-якому ресурсі. При використанні в ClusterRoleBinding, надає повний контроль над кожним ресурсом у кластері та у всіх просторах імен. При використанні в RoleBinding, надає повний контроль над кожним ресурсом у просторі імен, включаючи сам простір імен.
adminНемаєДозволяє доступ адміністратора, призначений для надання в межах простору імен за допомогою RoleBinding.

Якщо використовується в RoleBinding, дозволяє доступ для читання/запису до більшості ресурсів у просторі імен, включаючи можливість створювати ролі та привʼязки ролей у просторі імен. Ця роль не дозволяє доступу для запису до квоти ресурсів або до самого простору імен. Ця роль також не дозволяє доступу для запису до EndpointSlices (або Endpoints) у кластерах, створених за допомогою Kubernetes v1.22+. Більше інформації доступно у розділі "Достпу на запису у EndpointSlices та Endpoints".

editНемаєДозволяє доступ для читання/запису до більшості обʼєктів у просторі імен.

Ця роль не дозволяє переглядати або змінювати ролі або привʼязки ролей. Однак ця роль дозволяє доступ до Secretʼів і запуску Podʼів як будь-який ServiceAccount у просторі імен, тому вона може бути використана для отримання рівня доступу API будь-якого ServiceAccount у просторі імен. Ця роль також не дозволяє доступу для запису до EndpointSlices (або Endpoints) у кластерах, створених за допомогою Kubernetes v1.22+. Більше інформації доступно у розділі "Достпу на запису у EndpointSlices та Endpoints".

viewНемаєДозволяє доступ лише для читання до більшості обʼєктів у просторі імен. Ця роль не дозволяє переглядати ролі або привʼязки ролей. Ця роль не дозволяє переглядати Secretʼи, оскільки читання вмісту секретів дозволяє доступ до облікових даних ServiceAccount у просторі імен, що дозволило б доступ до API як будь-який ServiceAccount у просторі імен (форма ескалації привілеїв).

Ролі основних компонентів

Стандартна ClusterRoleСтандартна ClusterRoleBindingОпис
system:kube-schedulersystem:kube-scheduler користувачДозволяє доступ до ресурсів, необхідних компоненту планувальника.
system:volume-schedulersystem:kube-scheduler користувачДозволяє доступ до ресурсів обʼєму, необхідних компоненту kube-scheduler.
system:kube-controller-managersystem:kube-controller-manager користувачДозволяє доступ до ресурсів, необхідних компоненту менеджера контролерів. Дозволи, необхідні окремим контролерам, детально описані в ролях контролерів.
system:nodeНемаєДозволяє доступ до ресурсів, необхідних для kubelet, включаючи доступ на читання до всіх секретів та доступ на запис до всіх обʼєктів стану Podʼів.

Ви повинні використовувати Node authorizer та втулок допуску NodeRestriction замість ролі system:node та дозволяти надання доступу до API для kubelet на основі Podʼів, які заплановано для запуску на них.

Роль system:node існує лише для сумісності з кластерами Kubernetes, оновленими з версій до v1.8.

system:node-proxiersystem:kube-proxy користувачДозволяє доступ до ресурсів, необхідних компоненту kube-proxy.

Ролі інших компонентів

Стандартна ClusterRoleСтандартна ClusterRoleBindingОпис
system:auth-delegatorНемаєДозволяє делеговані перевірки автентифікації та авторизації. Це зазвичай використовується серверами надбудов API для уніфікованої автентифікації та авторизації.
system:heapsterНемаєРоль для компонента Heapster (застарілий).
system:kube-aggregatorНемаєРоль для компонента kube-aggregator.
system:kube-dnskube-dns службовий обліковий запис у просторі імен kube-systemРоль для компонента kube-dns.
system:kubelet-api-adminНемаєДозволяє повний доступ до API kubelet.
system:node-bootstrapperНемаєДозволяє доступ до ресурсів, необхідних для виконання початкового завантаження kubelet TLS.
system:node-problem-detectorНемаєРоль для компонента node-problem-detector.
system:persistent-volume-provisionerНемаєДозволяє доступ до ресурсів, необхідних для більшості динамічних провізорів томів.
system:monitoringsystem:monitoring групаДозволяє доступ на читання до точок доступу моніторингу панелі управління (тобто kube-apiserver точки доступу придатності та готовності (/healthz, /livez, /readyz), індивідуальні точки доступу перевірки стану (/healthz/*, /livez/*, /readyz/*) та /metrics). Зверніть увагу, що індивідуальні точки доступу перевірки стану та точка доступу метрик можуть розкривати конфіденційну інформацію.

Ролі для вбудованих контролерів

Менеджер контролерів Kubernetes запускає контролери, які вбудовані в панель управління Kubernetes. Коли його викликають з --use-service-account-credentials, kube-controller-manager запускає кожен контролер використовуючи окремий службовий обліковий запис. Для кожного вбудованого контролера існують відповідні ролі з префіксом system:controller:. Якщо менеджер контролерів не запускається з --use-service-account-credentials, він виконує всі контрольні цикли використовуючи власні облікові дані, які повинні мати всі відповідні ролі. Ці ролі включають:

  • system:controller:attachdetach-controller
  • system:controller:certificate-controller
  • system:controller:clusterrole-aggregation-controller
  • system:controller:cronjob-controller
  • system:controller:daemon-set-controller
  • system:controller:deployment-controller
  • system:controller:disruption-controller
  • system:controller:endpoint-controller
  • system:controller:expand-controller
  • system:controller:generic-garbage-collector
  • system:controller:horizontal-pod-autoscaler
  • system:controller:job-controller
  • system:controller:namespace-controller
  • system:controller:node-controller
  • system:controller:persistent-volume-binder
  • system:controller:pod-garbage-collector
  • system:controller:pv-protection-controller
  • system:controller:pvc-protection-controller
  • system:controller:replicaset-controller
  • system:controller:replication-controller
  • system:controller:resourcequota-controller
  • system:controller:root-ca-cert-publisher
  • system:controller:route-controller
  • system:controller:service-account-controller
  • system:controller:service-controller
  • system:controller:statefulset-controller
  • system:controller:ttl-controller

Запобігання ескалації привілеїв і початкове налаштування

API RBAC запобігає ескалації привілеїв користувачами шляхом редагування ролей або привʼязок ролей. Оскільки це реалізується на рівні API, це застосовується навіть коли авторизатор RBAC не використовується.

Обмеження на створення або оновлення ролей

Ви можете створити/оновити роль, тільки якщо виконується хоча б одна з наступних умов:

  1. Ви вже маєте всі дозволи, що містяться в ролі, в тій же області, що й обʼєкт, який модифікується (кластерний рівень для ClusterRole, у тому ж просторі імен або кластерний рівень для Role).
  2. Вам надано явний дозвіл виконувати дієслово escalate для ресурсу roles або clusterroles в групі API rbac.authorization.k8s.io.

Наприклад, якщо user-1 не має можливості отриамння переліку Secrets на кластерному рівні, він не може створити ClusterRole, що містить цей дозвіл. Щоб дозволити користувачу створювати/оновлювати ролі:

  1. Надайте йому роль, що дозволяє створювати/оновлювати обʼєкти Role або ClusterRole, те що треба.
  2. Надати йому дозвіл включати конкретні дозволи в ролі, які він створює/оновлює:
    • неявно, надаючи йому ці дозволи (якщо він спробує створити або модифікувати Role або ClusterRole з дозволами, які йому самому не надані, запит до API буде заборонений)
    • або явно дозволити вказувати будь-які дозволи в Role або ClusterRole, надаючи йому дозвіл виконувати дієслово escalate для ресурсів roles або clusterroles в групі API rbac.authorization.k8s.io.

Обмеження на створення або оновлення привʼязок ролей

Ви можете створити/оновити привʼязку ролі, тільки якщо вже маєте всі дозволи, що містяться в згаданій ролі (в тій же області, що й привʼязка ролі) або якщо вам надано дозвіл виконувати дієслово bind для згаданої ролі. Наприклад, якщо user-1 не має можливості отримувати перелік Secrets на кластерному рівні, він не може створити ClusterRoleBinding для ролі, яка надає цей дозвіл. Щоб дозволити користувачу створювати/оновлювати привʼязки ролей:

  1. Надати йому роль, що дозволяє створювати/оновлювати обʼєкти RoleBinding або ClusterRoleBinding, як необхідно.
  2. Надати йому дозволи, необхідні для привʼязки певної ролі:
    • неявно, надаючи йому дозволи, що м стяться в ролі.
    • явно, надаючи йому дозвіл виконувати дієслово bind для певної Role (або ClusterRole).

Наприклад, цей ClusterRole і RoleBinding дозволять user-1 надавати іншим користувачам ролі admin, edit і view у просторі імен user-1-namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: role-grantor
rules:
- apiGroups: ["rbac.authorization.k8s.io"]
  resources: ["rolebindings"]
  verbs: ["create"]
- apiGroups: ["rbac.authorization.k8s.io"]
  resources: ["clusterroles"]
  verbs: ["bind"]
  # пропустіть resourceNames, щоб дозволити привʼязку будь-якої ClusterRole
  resourceNames: ["admin","edit","view"] 
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: role-grantor-binding
  namespace: user-1-namespace
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: role-grantor
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: user-1

Коли початково налаштовуються перші ролі та привʼязки ролей, необхідно, щоб початковий користувач надав дозволи, які він ще не має. Щоб початково налаштувати ролі та привʼязки ролей:

  • Використовуйте облікові дані з групою "system:masters", яка стандартно привʼязана до ролі суперкористувача "cluster-admin".

Утиліти командного рядка

kubectl create role

Створює обʼєкт Role, що визначає дозволи в межах одного простору імен. Приклади:

  • Створити Role з назвою "pod-reader", яка дозволяє користувачам виконувати get, watch і list для pods:

    kubectl create role pod-reader --verb=get --verb=list --verb=watch --resource=pods
    
  • Створити Role з назвою "pod-reader" зі специфікованими resourceNames:

    kubectl create role pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod
    
  • Створити Role з назвою "foo" зі специфікованими apiGroups:

    kubectl create role foo --verb=get,list,watch --resource=replicasets.apps
    
  • Створити Role з назвою "foo" з дозволами на субресурси:

    kubectl create role foo --verb=get,list,watch --resource=pods,pods/status
    
  • Створити Role з назвою "my-component-lease-holder" з дозволами на отримання/оновлення ресурсу зі специфічною назвою:

    kubectl create role my-component-lease-holder --verb=get,list,watch,update --resource=lease --resource-name=my-component
    

kubectl create clusterrole

Створює ClusterRole. Приклади:

  • Створити ClusterRole з назвою "pod-reader", яка дозволяє користувачам виконувати get, watch і list для pods:

    kubectl create clusterrole pod-reader --verb=get,list,watch --resource=pods
    
  • Створити ClusterRole з назвою "pod-reader" зі специфікованими resourceNames:

    kubectl create clusterrole pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod
    
  • Створити ClusterRole з назвою "foo" зі специфікованими apiGroups:

    kubectl create clusterrole foo --verb=get,list,watch --resource=replicasets.apps
    
  • Створити ClusterRole з назвою "foo" з дозволами на субресурси:

    kubectl create clusterrole foo --verb=get,list,watch --resource=pods,pods/status
    
  • Створити ClusterRole з назвою "foo" зі специфікованими nonResourceURL:

    kubectl create clusterrole "foo" --verb=get --non-resource-url=/logs/*
    
  • Створити ClusterRole з назвою "monitoring" зі специфікованим aggregationRule:

    kubectl create clusterrole monitoring --aggregation-rule="rbac.example.com/aggregate-to-monitoring=true"
    

kubectl create rolebinding

Надає Role або ClusterRole в межах певного простору імен. Приклади:

  • В межах простору імен "acme" надати дозволи з ClusterRole "admin" користувачу з імʼям "bob":

    kubectl create rolebinding bob-admin-binding --clusterrole=admin --user=bob --namespace=acme
    
  • В межах простору імен "acme" надати дозволи з ClusterRole "view" службовому обліковому запису в просторі імен "acme" з імʼям "myapp":

    kubectl create rolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp --namespace=acme
    
  • В межах простору імен "acme" надати дозволи з ClusterRole "view" службовому обліковому запису в просторі імен "myappnamespace" з імʼям "myapp":

    kubectl create rolebinding myappnamespace-myapp-view-binding --clusterrole=view --serviceaccount=myappnamespace:myapp --namespace=acme
    

kubectl create clusterrolebinding

Надає ClusterRole в межах усього кластеру (всі простори імен). Приклади:

  • В межах усього кластеру надати дозволи з ClusterRole "cluster-admin" користувачу з імʼям "root":

    kubectl create clusterrolebinding root-cluster-admin-binding --clusterrole=cluster-admin --user=root
    
  • В межах усього кластеру надати дозволи з ClusterRole "system:node-proxier" користувачу з імʼям "system:kube-proxy":

    kubectl create clusterrolebinding kube-proxy-binding --clusterrole=system:node-proxier --user=system:kube-proxy
    
  • В межах усього кластеру надати дозволи з ClusterRole "view" службовому обліковому запису з імʼям "myapp" у просторі імен "acme":

    kubectl create clusterrolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp
    

kubectl auth reconcile

Створює або оновлює обʼєкти API rbac.authorization.k8s.io/v1 з файлу маніфесту.

Відсутні обʼєкти створюються, і простір імен для обʼєктів у просторі імен створюється за потреби.

Наявні ролі оновлюються, щоб включати дозволи з вхідних обʼєктів, і видаляти зайві дозволи, якщо вказано --remove-extra-permissions.

Наявні привʼязки оновлюються, щоб включати субʼєкти з вхідних обʼєктів, і видаляти зайві субʼєкти, якщо вказано --remove-extra-subjects.

Приклади:

  • Тестове застосування файлу маніфесту обʼєктів RBAC, відображаючи зміни, які будуть зроблені:

    kubectl auth reconcile -f my-rbac-rules.yaml --dry-run=client
    
  • Застосування файлу маніфесту обʼєктів RBAC, збереження будь-яких зайвих дозволів (в ролях) і зайвих субʼєктів (в привʼязках):

    kubectl auth reconcile -f my-rbac-rules.yaml
    
  • Застосування файлу маніфесту обʼєктів RBAC, видалення будь-яких зайвих дозволів (в ролях) і зайвих субʼєктів (в привʼязках):

    kubectl auth reconcile -f my-rbac-rules.yaml --remove-extra-subjects --remove-extra-permissions
    

Права доступу ServiceAccount

Типові політики RBAC надають обмежені права компонентам панелі управління, вузлам і контролерам, але не надають жодних дозволів службовим обліковим записам за межами простору імен kube-system (поза межами дозволів, наданих ролями виявлення API).

Це дозволяє надавати конкретні ролі конкретним ServiceAccounts за необхідності. Тонке налаштування привʼязок ролей забезпечує більшу безпеку, але вимагає більше зусиль для адміністрування. Ширші привʼязки можуть надати зайвий (і потенційно ескалуючий) доступ до API ServiceAccounts, але їх легше адмініструвати.

Підходи від найбезпечніших до найменш безпечних:

  1. Надання ролі для службового облікового запису для конкретного застосунку (найкращий варіант)

    Це вимагає від застосунку зазначення serviceAccountName в його специфікації Pod, і створення службового облікового запису (через API, маніфест програми, kubectl create serviceaccount, тощо).

    Наприклад, надати права лише на читання в межах "my-namespace" службовому обліковому запису "my-sa":

    kubectl create rolebinding my-sa-view \
      --clusterrole=view \
      --serviceaccount=my-namespace:my-sa \
      --namespace=my-namespace
    
  2. Надання ролі службовому обліковому запису "default" в просторі імен

    Якщо програма не зазначає serviceAccountName, вона використовує службовий обліковий запис "default".

    Наприклад, надати права лише на читання в межах "my-namespace" службовому обліковому запису "default":

    kubectl create rolebinding default-view \
      --clusterrole=view \
      --serviceaccount=my-namespace:default \
      --namespace=my-namespace
    

    Багато надбудов працюють від імені службового облікового запису "default" у просторі імен kube-system. Щоб дозволити цим надбудовам працювати з правами суперкористувача, надайте права cluster-admin службовому обліковому запису "default" у просторі імен kube-system.

    kubectl create clusterrolebinding add-on-cluster-admin \
      --clusterrole=cluster-admin \
      --serviceaccount=kube-system:default
    
  3. Надання ролі всім службовим обліковим записам у просторі імен

    Якщо ви хочете, щоб усі програми в просторі імен мали роль, незалежно від того, який службовий обліковий запис вони використовують, ви можете надати роль групі службових облікових записів для цього простору імен.

    Наприклад, надати права лише на читання в межах "my-namespace" усім службовим обліковим записам у цьому просторі імен:

    kubectl create rolebinding serviceaccounts-view \
      --clusterrole=view \
      --group=system:serviceaccounts:my-namespace \
      --namespace=my-namespace
    
  4. Надання обмеженої ролі всім службовим обліковим записам у кластері (не рекомендується)

    Якщо ви не хочете керувати дозволами по кожному простору імен, ви можете надати кластерну роль усім службовим обліковим записам у кластері.

    Наприклад, надати права лише на читання в усіх просторах імен усім службовим обліковим записам у кластері:

    kubectl create clusterrolebinding serviceaccounts-view \
      --clusterrole=view \
      --group=system:serviceaccounts
    
  5. Надання прав суперкористувача всім службовим обліковим записам у кластері (категорично не рекомендується)

    Якщо вам не важливо розподіляти дозволи взагалі, ви можете надати права суперкористувача всім службовим обліковим записам.

    kubectl create clusterrolebinding serviceaccounts-cluster-admin \
      --clusterrole=cluster-admin \
      --group=system:serviceaccounts
    

Права запису для EndpointSlices і Endpoints

Кластери Kubernetes, створені до версії Kubernetes v1.22, включають права запису для EndpointSlices (і Endpoints) у ролях "edit" і "admin". У рамках помʼякшення наслідків CVE-2021-25740, цей доступ не є частиною агрегованих ролей у кластерах, створених із використанням Kubernetes v1.22 або пізніших версій.

Кластери, які були оновлені до Kubernetes v1.22, не підпадають під цю зміну. Оголошення CVE включає вказівки щодо обмеження цього доступу в поточних кластерах.

Якщо ви хочете, щоб нові кластери зберігали цей рівень доступу в агрегованих ролях, ви можете створити наступну ClusterRole:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  annotations:
    kubernetes.io/description: |-
      Add endpoints write permissions to the edit and admin roles. This was
      removed by default in 1.22 because of CVE-2021-25740. See
      https://issue.k8s.io/103675. This can allow writers to direct LoadBalancer
      or Ingress implementations to expose backend IPs that would not otherwise
      be accessible, and can circumvent network policies or security controls
      intended to prevent/isolate access to those backends.
      EndpointSlices were never included in the edit or admin roles, so there
      is nothing to restore for the EndpointSlice API.      
  labels:
    rbac.authorization.k8s.io/aggregate-to-edit: "true"
  name: custom:aggregate-to-edit:endpoints # виможете змінити це поле, за бажанням
rules:
  - apiGroups: [""]
    resources: ["endpoints"]
    verbs: ["create", "delete", "deletecollection", "patch", "update"]

Оновлення з ABAC

Кластери, що спочатку працювали на старіших версіях Kubernetes, часто використовували дозвільні політики ABAC, включаючи надання повного доступу до API всім службовим обліковим записам.

Типові політики RBAC надають обмежені права компонентам панелі управління, вузлам і контролерам, але не надають жодних дозволів службовим обліковим записам за межами простору імен kube-system (поза межами дозволів, наданих ролями виявлення API).

Хоча це набагато безпечніше, це може бути руйнівним для поточних робочих навантажень, які очікують автоматичного отримання дозволів API. Ось два підходи для управління цим переходом:

Паралельні авторизатори

Запускайте як RBAC, так і ABAC авторизатори, і вкажіть файл політики, що містить стару політику ABAC:

--authorization-mode=...,RBAC,ABAC --authorization-policy-file=mypolicy.json

Щоб детально пояснити цей перший параметр командного рядка: якщо раніші авторизатори, такі як Node, відхиляють запит, тоді авторизатор RBAC намагається авторизувати запит до API. Якщо RBAC також відхиляє цей запит до API, тоді запускається авторизатор ABAC. Це означає, що будь-який запит, дозволений будь-якою політикою RBAC або ABAC, буде дозволений.

Коли kube-apiserver запускається з рівнем логування 5 або вище для компонента RBAC (--vmodule=rbac*=5 або --v=5), ви можете побачити відмови RBAC у лозі сервера API (позначені як RBAC). Ви можете використовувати цю інформацію для визначення, які ролі потрібно надати яким користувачам, групам або службовим обліковим записам.

Після того, як ви надали ролі службовим обліковим записам і робочі навантаження працюють без повідомлень про відмову RBAC у логах сервера, ви можете видалити авторизатор ABAC.

Дозвільні права RBAC

Ви можете відтворити дозвільну політику ABAC, використовуючи привʼязки ролей RBAC.

Після переходу на використання RBAC, ви повинні налаштувати контроль доступу для вашого кластера, щоб забезпечити відповідність вашим інформаційним вимогам безпеки.

6.3.5 - Використання авторизації вузлів

Авторизація вузлів — це режим авторизації спеціального призначення, який спеціально авторизує запити API, зроблені kubelet-ами.

Огляд

Авторизатор вузлів дозволяє kubelet-ам виконувати операції з API. Це включає:

Операції читання:

  • services
  • endpoints
  • nodes
  • pods
  • secrets, configmaps, persistent volume claims та persistent volumes, що стосуються Podʼів, привʼязаних до вузла kubelet-а
СТАН ФУНКЦІОНАЛУ: Kubernetes v1.31 [alpha]

Коли функціональну можливість AuthorizeNodeWithSelectors увімкнено (разом із передумовою AuthorizeWithSelectors), kubelets можуть читати лише власні обʼєкти Node і можуть читати лише Podʼи, привʼязані до їхнього вузла.

Операції запису:

  • вузли та статус вузлів (увімкніть втулок допуску NodeRestriction, щоб обмежити kubelet у зміні свого власного вузла)
  • поди та статус подів (увімкніть втулок допуску NodeRestriction, щоб обмежити kubelet у зміні подів, привʼязаних до себе)
  • події

Операції, повʼязані з авторизацією:

  • доступ на читання/запис API CertificateSigningRequests для TLS початкового запуску
  • можливість створювати TokenReview та SubjectAccessReview для делегованої автентифікації/авторизації

У майбутніх випусках авторизатор вузлів може додавати або видаляти дозволи, щоб забезпечити kubelet-и мінімальним набором дозволів, необхідних для правильної роботи.

Для того, щоб бути авторизованими авторизатором вузлів, kubelet-и повинні використовувати облікові дані, які ідентифікують їх як членів групи system:nodes, з іменем користувача system:node:<nodeName>. Цей формат групи та імені користувача відповідає ідентичності, створеній для кожного kubelet-а в рамках TLS початкового запуску kubelet-а.

Значення <nodeName> має точно відповідати імені вузла, як зареєстровано kubelet-ом. Стандартно це імʼя хосту, надане hostname, або замінене за допомогою опції kubelet --hostname-override. Однак, при використанні опції kubelet --cloud-provider, конкретне імʼя хосту може бути визначено постачальником хмарних послуг, ігноруючи локальний hostname та опцію --hostname-override. Для деталей щодо визначення імені хосту kubelet-ом, дивіться довідник з опцій kubelet.

Щоб увімкнути авторизатор вузлів, запустіть apiserver з --authorization-mode=Node.

Щоб обмежити обʼєкти API, які можуть писати kubelet-и, увімкніть втулок допуску NodeRestriction шляхом запуску apiserver з --enable-admission-plugins=...,NodeRestriction,....

Міркування щодо міграції

Kubelet-и поза групою system:nodes

Kubelet-и, що знаходяться поза групою system:nodes, не будуть авторизовані режимом авторизації Node, і їм потрібно буде продовжувати авторизацію через механізм, який їх наразі авторизує. Вутлок допуску вузлів не буде обмежувати запити від цих kubelet-ів.

Kubelet-и з недиференційованими іменами користувачів

У деяких розгортаннях kubelet-и мають облікові дані, що розміщують їх у групі system:nodes, але не ідентифікують конкретний вузол, з яким вони повʼязані, оскільки вони не мають імені користувача у форматі system:node:.... Ці kubelet-и не будуть авторизовані режимом авторизації Node, і їм потрібно буде продовжувати авторизацію через механізм, який їх наразі авторизує.

Втулок допуску NodeRestriction буде ігнорувати запити від цих kubelet-ів, оскільки стандартна реалізація ідентифікатора вузла не вважатиме це ідентичністю вузла.

6.3.6 - Режим Webhook

Webhook — це зворотний виклик HTTP: HTTP POST, який відбувається, коли щось стається; просте сповіщення про подію через HTTP POST. Вебзастосунок, що реалізує Webhook, буде надсилати POST повідомлення на URL, коли відбуваються певні події.

Коли вказано режим Webhook, Kubernetes звертається до зовнішнього REST сервісу для визначення привілеїв користувача.

Формат файлу конфігурації

Режим Webhook потребує файл для HTTP конфігурації, що вказується за допомогою прапорця --authorization-webhook-config-file=SOME_FILENAME.

Файл конфігурації використовує формат файлу kubeconfig. У файлі "users" стосується конфігурації webhook API сервера, а "clusters" — до віддаленого сервісу.

Приклад конфігурації, що використовує клієнтську автентифікацію HTTPS:

# Версія Kubernetes API
apiVersion: v1
# тип API обʼєкта
kind: Config
# кластери відносяться до віддаленого сервісу
clusters:
  - name: name-of-remote-authz-service
    cluster:
      # CA для перевірки віддаленого сервісу
      certificate-authority: /path/to/ca.pem
      # URL віддаленого сервісу для запитів. Має використовувати 'https'. Не може включати параметри.
      server: https://authz.example.com/authorize

# користувачі відносяться до конфігурації webhook API сервера
users:
  - name: name-of-api-server
    user:
      client-certificate: /path/to/cert.pem # сертифікат для використання webhook втулком
      client-key: /path/to/key.pem          # ключ, що відповідає сертифікату

# файли kubeconfig вимагають контекст. Вкажіть один для API сервера.
current-context: webhook
contexts:
- context:
    cluster: name-of-remote-authz-service
    user: name-of-api-server
  name: webhook

Запити корисного навантаження

При ухваленні рішення про авторизацію, API сервер надсилає JSON- серіалізований обʼєкт authorization.k8s.io/v1beta1 SubjectAccessReview, що описує дію. Цей обʼєкт містить поля, що описують користувача, який намагається зробити запит, та деталі про ресурс, до якого здійснюється доступ, або атрибути запиту.

Зверніть увагу, що обʼєкти API webhook підлягають тим самим правилам сумісності версій, що й інші обʼєкти API Kubernetes. Імплементатори повинні бути обізнані з менш суворими обіцянками сумісності для бета-обʼєктів і перевіряти поле "apiVersion" запиту для забезпечення правильної десеріалізації. Додатково, API сервер повинен увімкнути групу розширень API authorization.k8s.io/v1beta1 (--runtime-config=authorization.k8s.io/v1beta1=true).

Приклад тіла запиту:

{
  "apiVersion": "authorization.k8s.io/v1beta1",
  "kind": "SubjectAccessReview",
  "spec": {
    "resourceAttributes": {
      "namespace": "kittensandponies",
      "verb": "get",
      "group": "unicorn.example.org",
      "resource": "pods"
    },
    "user": "jane",
    "group": [
      "group1",
      "group2"
    ]
  }
}

Віддалений сервіс має заповнити поле status запиту і відповісти, дозволяючи або забороняючи доступ. Поле spec у відповіді ігнорується і може бути пропущене. Дозвільна відповідь виглядатиме так:

{
  "apiVersion": "authorization.k8s.io/v1beta1",
  "kind": "SubjectAccessReview",
  "status": {
    "allowed": true
  }
}

Для заборони доступу є два методи.

Перший метод є кращим у більшості випадків і вказує, що webhook авторизації не дозволяє або не має "думки" ("no opinion") щодо запиту, але якщо інші авторизатори налаштовані, вони отримують шанс дозволити запит. Якщо немає інших авторизаторів або жоден з них не дозволяє запит, запит забороняється. Webhook поверне:

{
  "apiVersion": "authorization.k8s.io/v1beta1",
  "kind": "SubjectAccessReview",
  "status": {
    "allowed": false,
    "reason": "user does not have read access to the namespace"
  }
}

Другий метод негайно відмовляє, перериваючи оцінку іншими налаштованими авторизаторами. Це слід використовувати лише вебхуками, які мають детальні знання про повну конфігурацію авторизатора кластера. Webhook поверне:

{
  "apiVersion": "authorization.k8s.io/v1beta1",
  "kind": "SubjectAccessReview",
  "status": {
    "allowed": false,
    "denied": true,
    "reason": "user does not have read access to the namespace"
  }
}

Доступ до нересурсних шляхів здійснюється як:

{
  "apiVersion": "authorization.k8s.io/v1beta1",
  "kind": "SubjectAccessReview",
  "spec": {
    "nonResourceAttributes": {
      "path": "/debug",
      "verb": "get"
    },
    "user": "jane",
    "group": [
      "group1",
      "group2"
    ]
  }
}
СТАН ФУНКЦІОНАЛУ: Kubernetes v1.31 [alpha]

З увімкненою функцією AuthorizeWithSelectors поля та мітки селекторів у запиті передаються до вебхуку авторизації. Вебхук може приймати рішення про авторизацію, орієнтуючися на обмежені селектори полів і міток, якщо бажає.

Документація API SubjectAccessReview надає вказівки щодо того, як ці поля мають інтерпретуватися і оброблятися вебхуками авторизації, зокрема використанням розібраних вимог замість сирих рядків селекторів та як безпечно обробляти невідомі оператори.

{
  "apiVersion": "authorization.k8s.io/v1beta1",
  "kind": "SubjectAccessReview",
  "spec": {
    "resourceAttributes": {
      "verb": "list",
      "group": "",
      "resource": "pods",
      "fieldSelector": {
        "requirements": [
          {"key":"spec.nodeName", "operator":"In", "values":["mynode"]}
        ]
      },
      "labelSelector": {
        "requirements": [
          {"key":"example.com/mykey", "operator":"In", "values":["myvalue"]}
        ]
      }
    },
    "user": "jane",
    "group": [
      "group1",
      "group2"
    ]
  }
}

Нересурсні шляхи включають: /api, /apis, /metrics, /logs, /debug, /healthz, /livez, /openapi/v2, /readyz та /version. Клієнти потребують доступу до /api, /api/*, /apis, /apis/*, та /version для визначення, які ресурси та версії присутні на сервері. Доступ до інших нересурсних шляхів може бути заборонений без обмеження доступу до REST API.

За подальшою інформацією звертайтеся до документації SubjectAccessReview API та імплементації webhook.go.

6.3.7 - Використання ABAC авторизації

Авторизація на основі атрибутів (ABAC) визначає парадигму контролю доступу, за якою права доступу надаються користувачам за допомогою політик, які комбінують атрибути.

Формат файлу політики

Для увімкнення режиму ABAC вказуйте --authorization-policy-file=SOME_FILENAME та --authorization-mode=ABAC при запуску.

Формат файлу — один обʼєкт JSON на рядок. Не повинно бути жодного вкладеного списку або map, тільки один map на рядок.

Кожний рядок — "обʼєкт політики", де такий обʼєкт є map із такими властивостями:

  • Властивості версіювання:
    • apiVersion, типу string; допустимі значення "abac.authorization.kubernetes.io/v1beta1". Дозволяє версіювання та конвертацію формату політики.
    • kind, типу string: допустимі значення "Policy". Дозволяє версіювання та конвертацію формату політики.
  • Властивість spec встановлена на мапу з такими властивостями:
    • Властивості зіставлення субʼєкта:
      • user, типу string; рядок користувача з --token-auth-file. Якщо ви вказуєте user, він повинен збігатися з імʼям користувача автентифікованого користувача.
      • group, типу string; якщо ви вказуєте group, він повинен збігатися з однією з груп автентифікованого користувача. system:authenticated збігається з усіма автентифікованими запитами. system:unauthenticated збігається з усіма неавтентифікованими запитами.
    • Властивості зіставлення ресурсу:
      • apiGroup, типу string; група API.
        • Наприклад: apps, networking.k8s.io
        • Маска: * збігається з усіма групами API.
      • namespace, типу string; простір імен.
        • Наприклад: kube-system
        • Маска: * збігається з усіма запитами ресурсів.
      • resource, типу string; тип ресурсу
        • Наприклад: pods, deployments
        • Маска: * збігається з усіма запитами ресурсів.
    • Властивості зіставлення нересурсів:
      • nonResourcePath, типу string; шляхи запитів нересурсів.
        • Наприклад: /version або /apis
        • Маска:
          • * збігається з усіма запитами нересурсів.
          • /foo/* збігається з усіма підшляхами /foo/.
    • readonly, типу boolean, якщо true, означає, що політика, що зіставляється з ресурсом, застосовується тільки до операцій get, list, та watch, а політика, що зіставляється з нересурсами, застосовується тільки до операції get.

Алгоритм авторизації

У запиту є атрибути, які відповідають властивостям обʼєкта політики.

Коли отримано запит, визначаються атрибути. Невідомі атрибути встановлюються на нульове значення свого типу (наприклад, порожній рядок, 0, false).

Властивість, встановлена на "*", буде збігатися з будь-яким значенням відповідного атрибута.

Кортеж атрибутів перевіряється на відповідність кожній політиці в файлі політики. Якщо принаймні один рядок відповідає атрибутам запиту, тоді запит авторизований (але може зазнати невдачі під час подальшої перевірки).

Щоб дозволити будь-якому автентифікованому користувачеві зробити щось, створіть політику з властивістю group, встановленою на "system:authenticated".

Щоб дозволити будь-якому неавтентифікованому користувачеві зробити щось, створіть політику з властивістю group, встановленою на "system:unauthenticated".

Щоб дозволити користувачеві зробити все, створіть політику з властивостями apiGroup, namespace, resource та nonResourcePath, встановленими на "*".

Kubectl

Kubectl використовує точки доступу /api та /apis apiserver для виявлення сервісів, які обслуговують типи ресурсів, і перевіряє обʼєкти, надіслані до API за допомогою операцій create/update, використовуючи інформацію про схему, розташовану в /openapi/v2.

При використанні авторизації на основі атрибутів, ці спеціальні ресурси мають бути явно відкриті за допомогою властивості nonResourcePath в політиці (див. приклади нижче):

  • /api, /api/*, /apis та /apis/* для вибору версії API.
  • /version для отримання версії сервера через kubectl version.
  • /swaggerapi/* для операцій create/update.

Щоб перевірити HTTP-виклики, повʼязані з певною операцією kubectl, ви можете збільшити рівень деталізації:

kubectl --v=8 version

Приклади

  1. Alice може робити все з усіма ресурсами:

    {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "alice", "namespace": "*", "resource": "*", "apiGroup": "*"}}
    
  2. Kubelet може читати будь-які Podʼи:

    {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "kubelet", "namespace": "*", "resource": "pods", "readonly": true}}
    
  3. Kubelet може читати та записувати події:

    {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "kubelet", "namespace": "*", "resource": "events"}}
    
  4. Bob може лише читати Podʼи в просторі імен "projectCaribou":

    {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "bob", "namespace": "projectCaribou", "resource": "pods", "readonly": true}}
    
  5. Будь-хто може робити запити тільки для читання на всі нересурсні шляхи:

    {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"group": "system:authenticated", "readonly": true, "nonResourcePath": "*"}}
     {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"group": "system:unauthenticated", "readonly": true, "nonResourcePath": "*"}}
    

Приклад повного файлу

Коротка нотатка про службові облікові записи

Кожен службовий обліковий запис має відповідне імʼя користувача ABAC, і імʼя цього службового облікового запису генерується згідно з конвенцією щодо найменування:

system:serviceaccount:<namespace>:<serviceaccountname>

Створюючи новий простір імен, створюється новий службовий обліковий запис у наступному форматі:

system:serviceaccount:<namespace>:default

Наприклад, якщо ви хочете надати стандартному службовому обліковому запису (у просторі імен kube-system) повні привілеї в API за допомогою ABAC, ви додаєте цей рядок до файлу політики:

{"apiVersion":"abac.authorization.kubernetes.io/v1beta1","kind":"Policy","spec":{"user":"system:serviceaccount:kube-system:default","namespace":"*","resource":"*","apiGroup":"*"}}

apiserver повинен бути перезапущений, щоб використати нові рядки.

6.3.8 - Контролери допуску

Ця сторінка надає огляд контролерів допуску.

Що це таке?

Контролер допуску — це фрагмент коду, який перехоплює запити до сервера API Kubernetes перед збереженням обʼєкта, але після того, як запит був автентифікований та авторизований.

Контролери допуску можуть бути валідаційними, модифікуючими або обома. Модифікуючі контролери можуть змінювати обʼєкти, повʼязані з запитами, які вони допускають; валідаційні контролери не можуть цього робити.

Контролери допуску обмежують запити на створення, видалення, зміну обʼєктів. Контролери допуску також можуть блокувати нестандартні дієслова, такі як запити на підключення до Podʼа через проксі сервера API. Контролери допуску не блокують (і не можуть) запити на читання (get, watch або list) обʼєктів.

Контролери допуску в Kubernetes 1.31 складаються зі списку нижче, вбудовані у двійковий файл kube-apiserver і можуть бути налаштовані тільки адміністратором кластера. У цьому списку є два спеціальні контролери: MutatingAdmissionWebhook і ValidatingAdmissionWebhook. Вони виконують модифікуючі та валідаційні (відповідно) вебхуки контролю допуску, які налаштовуються в API.

Етапи контролю допуску

Процес контролю допуску проходить у два етапи. На першому етапі виконуються модифікуючі контролери допуску. На другому етапі виконуються валідаційні контролери допуску. Знову ж таки, деякі контролери є обома.

Якщо будь-який з контролерів на будь-якому етапі відхиляє запит, весь запит негайно відхиляється, і користувачу повертається помилка.

Нарешті, окрім іноді модифікації обʼєкта, про який йдеться, контролери допуску можуть іноді мати побічні ефекти, тобто змінювати повʼязані ресурси в процесі обробки запиту. Збільшення використання квоти є класичним прикладом того, чому це необхідно. Будь-який такий побічний ефект потребує відповідного процесу рекламації або узгодження, оскільки даний контролер допуску не знає напевно, що даний запит пройде через всі інші контролери допуску.

Чому вони потрібні?

Кілька важливих функцій Kubernetes вимагають увімкнення контролера допуску для належної підтримки функції. Як результат, сервер API Kubernetes, який неправильно налаштований з необхідним набором контролерів допуску, є неповним сервером і не підтримуватиме всі функції, які ви очікуєте.

Як увімкнути контролер допуску?

Прапорець сервера API Kubernetes enable-admission-plugins приймає через кому список втулків контролю допуску, які слід викликати перед зміною обʼєктів у кластері. Наприклад, наступна команда увімкне втулки контролю допуску NamespaceLifecycle та LimitRanger:

kube-apiserver --enable-admission-plugins=NamespaceLifecycle,LimitRanger ...

Як вимкнути контролер допуску?

Прапорець сервера API Kubernetes disable-admission-plugins приймає через кому список втулків контролю допуску, які слід вимкнути, навіть якщо вони є у списку втулків, що є стандартно увімкненими.

kube-apiserver --disable-admission-plugins=PodNodeSelector,AlwaysDeny ...

Які втулки є стандартно увімкненими?

Щоб побачити, які втулки допуску увімкнені:

kube-apiserver -h | grep enable-admission-plugins

У Kubernetes 1.31 стандартно увімкнені такі втулки:

CertificateApproval, CertificateSigning, CertificateSubjectRestriction, DefaultIngressClass, DefaultStorageClass, DefaultTolerationSeconds, LimitRanger, MutatingAdmissionWebhook, NamespaceLifecycle, PersistentVolumeClaimResize, PodSecurity, Priority, ResourceQuota, RuntimeClass, ServiceAccount, StorageObjectInUseProtection, TaintNodesByCondition, ValidatingAdmissionPolicy, ValidatingAdmissionWebhook

Що робить кожен контролер допуску?

AlwaysAdmit

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.13 [deprecated]

Тип: Валідаційний.

Цей контролер допуску дозволяє запуск всіх Podʼів в кластер. Він застарілий, оскільки його поведінка така ж, якби не було ніякого контролера допуску взагалі.

AlwaysDeny

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.13 [deprecated]

Тип: Валідаційний.

Відхиляє всі запити. AlwaysDeny застарілий, оскільки не має реального значення.

AlwaysPullImages

Тип: Модифікуючий та Валідаційний.

Цей контролер допуску модифікує кожен новий Pod, щоб примусити використовувати політику завантаження образів Always. Це корисно в багатокористувацькому кластері, щоб користувачі могли бути впевнені, що їхні приватні образи можуть використовувати лише ті, хто має відповідні облікові дані для їх завантаження. Без цього контролера допуску, після того, як образи було завантажено на вузол, будь-який Pod будь-якого користувача може використовувати його, знаючи імʼя образу (за умови, що Pod розміщений на правильному вузлі), без жодної перевірки вторизації для образу. Коли цей контролер допуску увімкнений, образи завжди завантажуються перед запуском контейнерів, що означає, що потрібні дійсні облікові дані.

CertificateApproval

Тип: Валідаційний.

Цей контролер допуску спостерігає за запитами на затвердження ресурсів CertificateSigningRequest і виконує додаткові перевірки авторизації, щоб переконатися, що користувач, який затверджує, має дозвіл на затвердження запитів сертифікатів із запитаним spec.signerName у ресурсі CertificateSigningRequest.

Дивіться Запити на підписання сертифікатів для отримання додаткової інформації про дозволи, необхідні для виконання різних дій з ресурсами CertificateSigningRequest.

CertificateSigning

Тип: Валідаційний.

Цей контролер допуску спостерігає за оновленнями поля status.certificate ресурсів CertificateSigningRequest і виконує додаткові перевірки авторизації, щоб переконатися, що користувач, який підписує, має дозвіл на підписання запитів сертифікатів із запитаним spec.signerName у ресурсі CertificateSigningRequest.

Дивіться Запити на підписання сертифікатів для отримання додаткової інформації про дозволи, необхідні для виконання різних дій з ресурсами CertificateSigningRequest.

CertificateSubjectRestriction

Тип: Валідаційний.

Цей контролер допуску спостерігає за створенням ресурсів CertificateSigningRequest, які мають spec.signerName значення kubernetes.io/kube-apiserver-client. Він відхиляє будь-який запит, який вказує групу (або атрибут організації) system:masters.

DefaultIngressClass

Тип: Модифікуючий.

Цей контролер допуску спостерігає за створенням обʼєктів Ingress, які не запитують жодного конкретного класу ingress, і автоматично додає до них стандартний клас ingress. Таким чином, користувачі, які не запитують жодного спеціального класу ingress, не повинні про це турбуватися та отримають стандартний клас.

Цей контролер допуску нічого не робить, коли не налаштований жоден стандартний клас ingress. Коли більше одного класу ingress позначено як стандартний клас, він відхиляє будь-яке створення Ingress з помилкою, і адміністратор повинен переглянути свої обʼєкти IngressClass та позначити лише один як стандартний клас (з анотацією "ingressclass.kubernetes.io/is-default-class"). Цей контролер допуску ігнорує будь-які оновлення Ingress; він діє тільки при створенні.

Дивіться документацію Ingress для отримання додаткової інформації про класи ingress і як позначити один як стандартний клас.

DefaultStorageClass

Тип: Модифікуючий.

Цей контролер допуску спостерігає за створенням обʼєктів PersistentVolumeClaim, які не запитують жодного конкретного класу зберігання, і автоматично додає до них стандартний клас зберігання. Таким чином, користувачі, які не запитують жодного спеціального класу зберігання, не повинні про це турбуватися та отримають стандартний клас.

Цей контролер допуску нічого не робить, коли не налаштований жоден стандартний клас зберігання. Коли більше одного класу зберігання позначено як стандартний клас, він відхиляє будь-яке створення PersistentVolumeClaim з помилкою, і адміністратор повинен переглянути свої обʼєкти StorageClass і позначити лише один як стандартний клас. Цей контролер допуску ігнорує будь-які оновлення PersistentVolumeClaim; він діє тільки при створенні.

Дивіться документацію постійних томів про persistent volume claims та класи зберігання, а також як позначити клас зберігання як стандартний клас.

DefaultTolerationSeconds

Тип: Модифікуючий.

Цей контролер допуску встановлює стандартне значення толерантності для Podʼів, щоб терпіти taints notready:NoExecute та unreachable:NoExecute на основі параметрів введення k8s-apiserver default-not-ready-toleration-seconds та default-unreachable-toleration-seconds, якщо Podʼи ще не мають толерантності до taints node.kubernetes.io/not-ready:NoExecute або node.kubernetes.io/unreachable:NoExecute. Стандартне значення для default-not-ready-toleration-seconds та default-unreachable-toleration-seconds становить 5 хвилин.

DenyServiceExternalIPs

Тип: Валідаційний.

Цей контролер допуску відхиляє всі нові використання поля externalIPs у Service. Ця функція дуже потужна (дозволяє перехоплення мережевого трафіку) і не контролюється належним чином політиками. Коли цей контролер увімкнено, користувачі кластера не можуть створювати нові Serviceʼи, які використовують externalIPs, і не можуть додавати нові значення до externalIPs в поточних обʼєктах Service. Поточні використання externalIPs не зачіпаються, і користувачі можуть видаляти значення з externalIPs в наявних обʼєктах Service.

Більшість користувачів взагалі не потребує цієї функції, і адміністратори кластера повинні розглянути можливість її вимкнення. Кластери, які потребують цієї функції, повинні розглянути можливість використання власних політик для керування її використанням.

Цей контролер допуску стандартно вимкнено.

EventRateLimit

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.13 [alpha]

Тип: Валідаційний.

Цей контролер допуску зменшує проблему, коли API-сервер переповнюється запитами на зберігання нових подій (Events). Адміністратор кластера може вказати обмеження швидкості подій, виконавши такі кроки:

  • Увімкнути контролер допуску EventRateLimit;
  • Посилатися на конфігураційний файл EventRateLimit з файлу, наданого у командному рядку API-сервера з прапорцем --admission-control-config-file:
apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
  - name: EventRateLimit
    path: eventconfig.yaml
...

Є чотири типи обмежень, які можна вказати у конфігурації:

  • Server: Всі запити подій (створення або зміни), що отримує API-сервер, використовують один спільний кошик.
  • Namespace: Кожен простір імен має виділений кошик.
  • User: Кожен користувач отримує кошик.
  • SourceAndObject: Кошик призначається кожній комбінації джерела та обʼєкта події.

Нижче наведено приклад eventconfig.yaml для такої конфігурації:

apiVersion: eventratelimit.admission.k8s.io/v1alpha1
kind: Configuration
limits:
  - type: Namespace
    qps: 50
    burst: 100
    cacheSize: 2000
  - type: User
    qps: 10
    burst: 50

Дивіться API конфігурації EventRateLimit (v1alpha1) для отримання додаткових деталей.

Цей контролер допуску стандартно вимкнено.

ExtendedResourceToleration

Тип: Модифікуючий.

Цей втулок полегшує створення виділених вузлів з розширеними ресурсами. Якщо оператори хочуть створити виділені вузли з розширеними ресурсами (наприклад, GPU, FPGA тощо), вони повинні накладати taint на вузол з іменем розширеного ресурсу як ключем. Цей контролер допуску, якщо він увімкнений, автоматично додає толерантності до таких taint у Podʼи, які запитують розширені ресурси, тому користувачам не потрібно вручну додавати ці толерантності.

Цей контролер допуску стандартно вимкнено.

ImagePolicyWebhook

Тип: Валідаційний.

Контролер допуску ImagePolicyWebhook дозволяє бекенд-вебхуку приймати рішення про допуск.

Цей контролер допуску стандартно вимкнено.

Формат конфігураційного файлу

ImagePolicyWebhook використовує конфігураційний файл для налаштування поведінки бекенду. Цей файл може бути у форматі JSON або YAML і має наступний формат:

imagePolicy:
  kubeConfigFile: /path/to/kubeconfig/for/backend
  # час у секундах для кешування дозволу
  allowTTL: 50
  # час у секундах для кешування відмови
  denyTTL: 50
  # час у мілісекундах між спробами повтору
  retryBackoff: 500
  # визначає поведінку у разі відмови бекенда вебхука
  defaultAllow: true

Посилання на конфігураційний файл ImagePolicyWebhook повинно бути зазначене у файлі, який передається прапорцю командного рядка API-сервера --admission-control-config-file:

apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
  - name: ImagePolicyWebhook
    path: imagepolicyconfig.yaml
...

Альтернативно, ви можете вбудувати конфігурацію безпосередньо у файл:

apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
  - name: ImagePolicyWebhook
    configuration:
      imagePolicy:
        kubeConfigFile: <path-to-kubeconfig-file>
        allowTTL: 50
        denyTTL: 50
        retryBackoff: 500
        defaultAllow: true

Конфігураційний файл ImagePolicyWebhook повинен посилатися на файл у форматі kubeconfig, який налаштовує зʼєднання з бекендом. Бекенд повинен здійснювати комунікацію через TLS.

Поле cluster у файлі kubeconfig має посилатися на віддалений сервіс, а поле user повинно містити дані авторизації.

# clusters посилається на віддалений сервіс.
clusters:
  - name: name-of-remote-imagepolicy-service
    cluster:
      certificate-authority: /path/to/ca.pem    # CA для верифікації віддаленого сервісу.
      server: https://images.example.com/policy # URL віддаленого сервісу для запитів. Повинен використовувати 'https'.

# users посилається на конфігурацію вебхука API-сервера.
users:
  - name: name-of-api-server
    user:
      client-certificate: /path/to/cert.pem # сертифікат для використання контролером допуску вебхука
      client-key: /path/to/key.pem          # ключ, що відповідає сертифікату

Для додаткової конфігурації HTTP дивіться документацію kubeconfig.

Вміст запитів

Під час прийняття рішення про допуск, API-сервер надсилає POST-запит з серіалізованим у форматі JSON обʼєктом imagepolicy.k8s.io/v1alpha1 ImageReview, що описує дію. Цей обʼєкт містить поля, що описують контейнери, які підлягають допуску, а також будь-які анотації Podʼа, що відповідають *.image-policy.k8s.io/*.

Приклад тіла запиту:

{
  "apiVersion": "imagepolicy.k8s.io/v1alpha1",
  "kind": "ImageReview",
  "spec": {
    "containers": [
      {
        "image": "myrepo/myimage:v1"
      },
      {
        "image": "myrepo/myimage@sha256:beb6bd6a68f114c1dc2ea4b28db81bdf91de202a9014972bec5e4d9171d90ed"
      }
    ],
    "annotations": {
      "mycluster.image-policy.k8s.io/ticket-1234": "break-glass"
    },
    "namespace": "mynamespace"
  }
}

Віддалений сервіс повинен заповнити поле status запиту і відповісти з дозволом або відмовою доступу. Поле spec тіла відповіді ігнорується, і його можна не включати. Відповідь, яка дозволяє доступ, виглядатиме так:

{
  "apiVersion": "imagepolicy.k8s.io/v1alpha1",
  "kind": "ImageReview",
  "status": {
    "allowed": true
  }
}

Щоб відмовити у доступі, сервіс відповість так:

{
  "apiVersion": "imagepolicy.k8s.io/v1alpha1",
  "kind": "ImageReview",
  "status": {
    "allowed": false,
    "reason": "image currently blacklisted"
  }
}

Для додаткової документації дивіться API imagepolicy.v1alpha1.

Розширення за допомогою анотацій

Усі анотації на Podʼі, що відповідають *.image-policy.k8s.io/*, надсилаються до вебхука. Надсилання анотацій дозволяє користувачам, які знають про бекенд політики образів, надсилати додаткову інформацію до нього, а також дозволяє реалізаціям різних бекендів приймати різну інформацію.

Приклади інформації, яку ви можете тут розмістити:

  • запит на "пробиття" для обходу політики у разі надзвичайної ситуації;
  • номер квитка з системи квитків, що документує запит на "пробиття";
  • підказка серверу політики щодо imageID наданого образу для економії часу на пошук.

У будь-якому випадку, анотації надаються користувачем і не перевіряються Kubernetes будь-яким чином.

LimitPodHardAntiAffinityTopology

Тип: Валідаційний.

Цей контролер допуску забороняє будь-який Pod, який визначає ключ топології AntiAffinity відмінний від kubernetes.io/hostname у requiredDuringSchedulingRequiredDuringExecution.

Цей контролер допуску стандартно вимкнено.

LimitRanger

Тип: Модифікуючий та Валідаційний.

Цей контролер допуску спостерігає за вхідним запитом та забезпечує, щоб він не порушував жодних обмежень, перерахованих в обʼєкті LimitRange в Namespace. Якщо ви використовуєте обʼєкти LimitRange у своєму розгортанні Kubernetes, ви МАЄТЕ використовувати цей контролер допуску для забезпечення дотримання цих обмежень. LimitRanger також може використовуватися для застосування стандартних ресурсних запитів до Pod, які їх не вказують; наразі стандартний LimitRanger застосовує вимогу до 0.1 CPU до всіх Pod у default namespace.

Дивіться довідник LimitRange API та приклад LimitRange для отримання додаткової інформації.

MutatingAdmissionWebhook

Тип: Модифікуючий.

Цей контролер допуску викликає будь-які модифікуючі вебхуки, які відповідають запиту. Відповідні вебхуки викликаються послідовно; кожен з них може змінити обʼєкт, якщо це необхідно.

Цей контролер допуску (як випливає з назви) працює лише на етапі модифікації.

Якщо вебхук, викликаний цим контролером, має побічні ефекти (наприклад, зменшення квоти), він повинен мати систему узгодження, оскільки не гарантується, що наступні вебхуки або контролери допуску дозволять завершити запит.

Якщо ви вимкнете MutatingAdmissionWebhook, ви також повинні вимкнути обʼєкт MutatingWebhookConfiguration у групі/версії admissionregistration.k8s.io/v1 за допомогою прапорця --runtime-config, обидва стандартно увімкнені.

Будьте обережні при створенні та встановленні модифікуючих вебхуків

  • Користувачі можуть бути спантеличені, коли обʼєкти, які вони намагаються створити, відрізняються від того, що вони отримують назад.
  • Вбудовані контрольні цикли можуть зламатися, коли обʼєкти, які вони намагаються створити, відрізняються при зворотному читанні.
    • Встановлення спочатку незаданих полів менш ймовірно викличе проблеми, ніж переписування полів, встановлених у початковому запиті. Уникайте останнього.
  • Майбутні зміни в контрольних циклах для вбудованих або сторонніх ресурсів можуть зламати вебхуки, які добре працюють сьогодні. Навіть коли API вебхука для установки буде фіналізовано, не всі можливі поведінки вебхука будуть гарантовано підтримуватися нескінченно.

NamespaceAutoProvision

Тип: Модифікуючий.

Цей контролер допуску перевіряє всі вхідні запити на ресурси, що належать до namespace, і перевіряє чи існує зазначений namespace. Він створює namespace, якщо його не знайдено. Цей контролер допуску корисний у розгортаннях, які не хочуть обмежувати створення namespace до його використання.

NamespaceExists

Тип: Валідаційний.

Цей контролер допуску перевіряє всі запити на ресурси, що належать до namespace, крім самого Namespace. Якщо namespace, на який посилається запит, не існує, запит відхиляється.

NamespaceLifecycle

Тип: Валідаційний.

Цей контролер допуску забезпечує, що Namespace, який знаходиться в процесі завершення, не може мати нові обʼєкти, створені в ньому, і забезпечує відхилення запитів у неіснуючому Namespace. Цей контролер допуску також запобігає видаленню трьох системно зарезервованих namespaces: default, kube-system, kube-public.

Видалення Namespace запускає послідовність операцій, які видаляють усі обʼєкти (Pod, Service, тощо) у цьому namespace. Для забезпечення цілісності цього процесу, ми наполегливо рекомендуємо використовувати цей контролер допуску.

NodeRestriction

Тип: Валідаційний.

Цей контролер допуску обмежує обʼєкти Node і Pod, які kubelet може змінювати. Для того, щоб бути обмеженим цим контролером допуску, kubelets повинні використовувати облікові дані у групі system:nodes, з іменем користувача у формі system:node:<nodeName>. Такі kubelets будуть мати дозвіл лише змінювати свої власні обʼєкти API Node, і лише змінювати обʼєкти API Pod, які привʼязані до їх вузла. kubelets не мають права оновлювати або видаляти taint зі свого обʼєкта API Node.

Втулок допуску NodeRestriction перешкоджає kubelets видаляти їх обʼєкт API Node, і забезпечує оновлення kubeletʼом міток з префіксами kubernetes.io/ або k8s.io/ наступним чином:

  • Перешкоджає kubelets додавання/видалення/оновлення міток з префіксом node-restriction.kubernetes.io/. Цей префікс міток зарезервовано для адміністраторів для позначення мітками своїх обʼєктів Node з метою ізоляції робочих навантажень, і kubelets не буде дозволено змінювати мітки з цим префіксом.
  • Дозволяє kubelets додавати/видаляти/оновлювати ці мітки та префікси міток:
    • kubernetes.io/hostname
    • kubernetes.io/arch
    • kubernetes.io/os
    • beta.kubernetes.io/instance-type
    • node.kubernetes.io/instance-type
    • failure-domain.beta.kubernetes.io/region (застаріло)
    • failure-domain.beta.kubernetes.io/zone (застаріло)
    • topology.kubernetes.io/region
    • topology.kubernetes.io/zone
    • мітки з префіксом kubelet.kubernetes.io/
    • мітки з префіксом node.kubernetes.io/

Використання будь-яких інших міток під префіксами kubernetes.io або k8s.io kubelets зарезервовано, і може бути заборонено або дозволено втулком допуску NodeRestriction у майбутньому.

Майбутні версії можуть додати додаткові обмеження для забезпечення того, щоб kubelets мали мінімальний набір дозволів, необхідних для правильної роботи.

OwnerReferencesPermissionEnforcement

Тип: Валідаційний.

Цей контролер допуску захищає доступ до metadata.ownerReferences обʼєкта, так що тільки користувачі з правами delete у обʼєкта можуть його змінювати. Цей контролер допуску також захищає доступ до metadata.ownerReferences[x].blockOwnerDeletion обʼєкта, так що тільки користувачі з правами update у субресурсу finalizers посилального власника можуть його змінювати.

PersistentVolumeClaimResize

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.24 [stable]

Тип: Валідаційний.

Цей контролер допуску реалізує додаткові перевірки для перевірки вхідних запитів на зміну розміру PersistentVolumeClaim.

Рекомендується увімкнути контролер допуску PersistentVolumeClaimResize. Цей контролер допуску запобігає зміні розміру всіх вимог за замовчуванням, якщо тільки StorageClass вимоги явно не дозволяє зміну розміру, встановлюючи allowVolumeExpansion на true.

Наприклад: всі PersistentVolumeClaim, створені з наступного StorageClass, підтримують розширення тому:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: gluster-vol-default
provisioner: kubernetes.io/glusterfs
parameters:
  resturl: "http://192.168.10.100:8080"
  restuser: ""
  secretNamespace: ""
  secretName: ""
allowVolumeExpansion: true

Для отримання додаткової інформації про persistent volume claims, дивіться PersistentVolumeClaims.

PodNodeSelector

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.5 [alpha]

Тип: Валідаційний.

Цей контролер допуску задає та обмежує, які селектори вузлів можуть використовуватися в межах namespace, шляхом читання анотації namespace та глобальної конфігурації.

Цей контролер допуску стандартно вимкнено.

Формат конфігураційного файлу

PodNodeSelector використовує конфігураційний файл для налаштування параметрів поведінки бекенду. Зверніть увагу, що формат конфігураційного файлу буде змінено на версійований файл у майбутньому випуску. Цей файл може бути у форматі json або yaml і має наступний формат:

podNodeSelectorPluginConfig:
  clusterDefaultNodeSelector: name-of-node-selector
  namespace1: name-of-node-selector
  namespace2: name-of-node-selector

Зверніться до конфігураційного файлу PodNodeSelector з файлу, наданого прапорцем командного рядка API-сервера --admission-control-config-file:

apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: PodNodeSelector
  path: podnodeselector.yaml
...

Формат анотації конфігурації

PodNodeSelector використовує ключ анотації scheduler.alpha.kubernetes.io/node-selector для призначення селекторів вузлів до namespace.

apiVersion: v1
kind: Namespace
metadata:
  annotations:
    scheduler.alpha.kubernetes.io/node-selector: name-of-node-selector
  name: namespace3

Внутрішня поведінка

Цей контролер допуску має наступну поведінку:

  1. Якщо Namespace має анотацію з ключем scheduler.alpha.kubernetes.io/node-selector, використовуйте її значення як селектор вузлів.
  2. Якщо namespace не має такої анотації, використовуйте clusterDefaultNodeSelector, визначений у конфігураційному файлі втулка PodNodeSelector, як селектор вузлів.
  3. Оцініть селектор вузлів Podʼа щодо селектора вузлів namespace на предмет конфліктів. Конфлікти призводять до відхилення.
  4. Оцініть селектор вузлів Podʼа щодо дозволеного селектора, визначеного у конфігураційному файлі плагіну для конкретного namespace. Конфлікти призводять до відхилення.

PodSecurity

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.25 [stable]

Тип: Валідаційний.

Контролер допуску PodSecurity перевіряє нові Podʼи перед їх допуском і визначає, чи варто їх допускати на основі запитуваного контексту безпеки та обмежень щодо дозволених Стандартів безпеки для Podʼів для namespace, в якому буде знаходитися Pod.

Дивіться Pod Security Admission для отримання додаткової інформації.

PodSecurity замінив старіший контролер допуску під назвою PodSecurityPolicy.

PodTolerationRestriction

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.7 [alpha]

Тип: Модифікуючий та Валідаційний.

Контролер допуску PodTolerationRestriction перевіряє конфлікти між толерантностями Podʼа та толерантностями його namespace. Він відхиляє запит Podʼа у разі конфлікту. Потім він обʼєднує толерантності, анотовані на namespace, з толерантностями Podʼа. Отримані толерантності перевіряються щодо списку дозволених толерантностей, анотованих на namespace. Якщо перевірка пройде успішно, запит Podʼа допускається, інакше він відхиляється.

Якщо namespace Podʼа не має повʼязаних з ним стандартних толерантностей або дозволених толерантностей, анотованих, використовуються стандартні толерантності на рівні кластера або список дозволених толерантностей на рівні кластера, якщо вони зазначені.

Толерантності призначаються namespace за допомогою ключа анотації scheduler.alpha.kubernetes.io/defaultTolerations. Список дозволених толерантностей можна додати за допомогою ключа анотації scheduler.alpha.kubernetes.io/tolerationsWhitelist.

Приклад анотацій для namespace:

apiVersion: v1
kind: Namespace
metadata:
  name: apps-that-need-nodes-exclusively
  annotations:
    scheduler.alpha.kubernetes.io/defaultTolerations: '[{"operator": "Exists", "effect": "NoSchedule", "key": "dedicated-node"}]'
    scheduler.alpha.kubernetes.io/tolerationsWhitelist: '[{"operator": "Exists", "effect": "NoSchedule", "key": "dedicated-node"}]'

Цей контролер допуску стандатно вимкнено.

Priority

Тип: Модифікуючий та Валідаційний.

Контролер допуску Priority використовує поле priorityClassName і заповнює ціле значення пріоритету. Якщо клас пріоритету не знайдено, Pod відхиляється.

ResourceQuota

Тип: Валідаційний.

Цей контролер допуску спостерігає за вхідним запитом і гарантує, що він не порушує жодних обмежень, перерахованих у обʼєкті ResourceQuota у Namespace. Якщо ви використовуєте обʼєкти ResourceQuota у вашому розгортанні Kubernetes, ви МАЄТЕ використовувати цей контролер допуску для забезпечення дотримання квот.

Дивіться довідник ResourceQuota API та приклад Resource Quota для отримання додаткових деталей.

RuntimeClass

Тип: Модифікуючий та Валідаційний.

Якщо ви визначаєте RuntimeClass з налаштованими накладними витратами, повʼязаними з роботою Podʼів, цей контролер допуску перевіряє вхідні Podʼи. При увімкненні, цей контролер допуску відхиляє будь-які запити на створення Podʼів, які вже мають встановлений overhead. Для Podʼів, які мають налаштований і обраний у своєму .spec RuntimeClass, цей контролер допуску встановлює .spec.overhead у Pod на основі значення, визначеного у відповідному RuntimeClass.

Дивіться також Накладні витрати, повʼязані з роботою Podʼів для отримання додаткової інформації.

ServiceAccount

Тип: Модифікуючий та Валідаційний.

Цей контролер допуску реалізує автоматизацію для службових облікових записів. Проєкт Kubernetes наполегливо рекомендує увімкнути цей контролер допуску. Вам слід увімкнути цей контролер допуску, якщо ви маєте намір використовувати обʼєкти ServiceAccount в Kubernetes.

Щодо анотації kubernetes.io/enforce-mountable-secrets: Хоча назва анотації вказує, що вона стосується лише монтування Secrets, її застосування також поширюється на інші способи використання Secrets в контексті Pod. Тому важливо переконатися, що всі зазначені секрети правильно вказані в ServiceAccount.

StorageObjectInUseProtection

Тип: Модифікуючий.

Втулок StorageObjectInUseProtection додає завершувачі kubernetes.io/pvc-protection або kubernetes.io/pv-protection до новостворених Persistent Volume Claims (PVC) або Persistent Volumes (PV). У випадку видалення користувача PVC або PV PVC або PV не видаляється, поки завершувач не буде видалений з PVC або PV за допомогою контролера захисту PVC або PV. Дивіться Захист обʼєктів зберігання які використовуються для отримання детальнішої інформації.

TaintNodesByCondition

Тип: Модифікуючий.

Цей контролер допуску додає taint до новостворених вузлів таких як NotReady та NoSchedule. Це позначення доволє уникнути стану перегонів, який може призвести до того, що Podʼи будуть заплановані на нових вузлах до того, як їх taint будуть оновлені для точної відповідності їх звітніх умов.

ValidatingAdmissionPolicy

Тип: Валідаційний.

Цей контролер допуску реалізує перевірку CEL для вхідних запитів, що збігаються. Він увімкнений, коли увімкнені як функціональна можливість validatingadmissionpolicy, так і група/версія admissionregistration.k8s.io/v1alpha1. Якщо будь-яка з політик ValidatingAdmissionPolicy не вдасться, запит не вдасться.

ValidatingAdmissionWebhook

Тип: Валідаційний.

Цей контролер допуску викликає будь-які валідуючі вебхуки, які відповідають запиту. Валідуючі вебхуки викликаються паралельно; якщо будь-який з них відхиляє запит, запит не вдається. Цей контролер допуску працює лише на етапі валідації; вебхуки, які він викликає, не можуть змінювати обʼєкт, на відміну від вебхуків, які викликаються контролером допуску MutatingAdmissionWebhook.

Якщо вебхук який викликається цим контролером, має побічні ефекти (наприклад, зменшення квоти), то обовʼязково має бути система реконсіляції, оскільки не гарантується, що подальші вебхуки або інші валідаційні контролери допуску дозволять закінчити запит.

Якщо ви вимкнете ValidatingAdmissionWebhook, вам також слід вимкнути обʼєкт ValidatingWebhookConfiguration у групі/версії admissionregistration.k8s.io/v1 за допомогою прапорця --runtime-config.

Так. Рекомендовані контролери допуску стандартно увімкнені (дивіться тут), тому вам не потрібно явно вказувати їх. Ви можете увімкнути додаткові контролери допуску поза стандартним набором за допомогою прапорця --enable-admission-plugins (порядок не має значення).

6.3.9 - Динамічне керування допуском

Окрім вбудованих втулків допуску, втулки допуску можуть бути розроблені як розширення і виконуватися як вебхуки, налаштовані під час роботи. Ця сторінка описує, як будувати, налаштовувати, використовувати та контролювати вебхуки допуску.

Що таке вебхуки допуску?

Вебхуки допуску — це зворотні виклики HTTP, які отримують запити на допуск та роблять з ними щось. Ви можете визначити два типи вебхуків допуску, валідаційний вебхук допуску та модифікуючий вебхук допуску. Модифікуючі вебхуки допуску викликаються першими та можуть змінювати обʼєкти, які надсилаються на сервер API, щоб застосовувати власні стандартні значення. Після завершення всіх модифікацій обʼєктів і після того, як вхідний обʼєкт перевірений сервером API, викликаються валідаційні вебхуки допуску та можуть відхиляти запити для застосування власних політик.

Експерименти з вебхуками допуску

Вебхуки допуску фактично є частиною панелі управління кластера. Ви повинні писати та розгортати їх з великою обережністю. Будь ласка, прочитайте посібники користувача для інструкцій, якщо ви маєте намір писати/розгортати вебхуки допуску промислового рівня. Нижче ми описуємо, як швидко експериментувати з вебхуками допуску.

Передумови

  • Переконайтеся, що контролери допуску MutatingAdmissionWebhook та ValidatingAdmissionWebhook увімкнені. Тут є рекомендований набір контролерів допуску для загального увімкнення.

  • Переконайтеся, що API admissionregistration.k8s.io/v1 увімкнено.

Написання сервера вебхуків допуску

Будь ласка, зверніться до реалізації сервера вебхуків допуску, який перевірено в е2е-тесті Kubernetes. Сервер вебхуків обробляє запити AdmissionReview, надіслані серверами API, і повертає своє рішення як обʼєкт AdmissionReview в тій же версії, що й отримав.

Дивіться розділ запиту вебхуку для деталей щодо даних, надісланих до вебхуків.

Дивіться розділ відповіді вебхуку для деталей щодо даних, які очікуються від вебхуків.

Приклад сервера вебхуків допуску залишає поле ClientAuth порожнім, що типово дорівнює NoClientCert. Це означає, що сервер вебхуків не автентифікує ідентичність клієнтів, які, припускається, є серверами API. Якщо вам потрібен взаємний TLS або інші способи автентифікації клієнтів, дивіться як автентифікувати сервери API.

Розгортання служби вебхуків допуску

Сервер вебхуків у е2е-тесті розгортається в кластері Kubernetes за допомогою API deployment. Тест також створює службу як фронтенд сервера вебхуків. Дивіться код.

Ви також можете розгортати свої вебхуки поза кластером. Вам потрібно буде оновити відповідно ваші конфігурації вебхуків.

Налаштування вебхуків допуску на льоту

Ви можете динамічно налаштовувати, які ресурси підлягають обробки яким вебхукам допуску через ValidatingWebhookConfiguration або MutatingWebhookConfiguration.

Приклад ValidatingWebhookConfiguration, конфігурація модифікуючого вебхуку подібна. Дивіться розділ конфігурації вебхуку для деталей про кожне поле конфігурації.

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: "pod-policy.example.com"
webhooks:
- name: "pod-policy.example.com"
  rules:
  - apiGroups:   [""]
    apiVersions: ["v1"]
    operations:  ["CREATE"]
    resources:   ["pods"]
    scope:       "Namespaced"
  clientConfig:
    service:
      namespace: "example-namespace"
      name: "example-service"
    caBundle: <CA_BUNDLE>
  admissionReviewVersions: ["v1"]
  sideEffects: None
  timeoutSeconds: 5

Поле scope вказує, чи тільки ресурси з області кластера ("Cluster") або з області простору імен ("Namespaced") будуть відповідати цьому правилу. "∗" означає, що обмежень області немає.

Коли сервер API отримує запит, що відповідає одному з rules, сервер API надсилає запит admissionReview до вебхуку, як зазначено в clientConfig.

Після створення конфігурації вебхуку, системі знадобиться кілька секунд, щоб визнати нову конфігурацію.

Автентифікація серверів API

Якщо вашим вебхукам для допуску потрібна автентифікація, ви можете налаштувати сервери API для використання базової автентифікації, токенів на предʼявника (bearer token) або сертифікатів для автентифікації себе у вебхуках. Налаштування складається з трьох кроків.

  • Під час запуску сервера API вкажіть розташування файлу конфігурації керування допуском за допомогою прапорця --admission-control-config-file.

  • У файлі конфігурації керування допуском вкажіть, де контролери MutatingAdmissionWebhook та ValidatingAdmissionWebhook повинні читати облікові дані. Облікові дані зберігаються у файлах kubeConfig (так, це та сама схема, що використовується kubectl), тому назва поля — kubeConfigFile. Ось приклад файлу конфігурації керування допуском:

apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: ValidatingAdmissionWebhook
  configuration:
    apiVersion: apiserver.config.k8s.io/v1
    kind: WebhookAdmissionConfiguration
    kubeConfigFile: "<path-to-kubeconfig-file>"
- name: MutatingAdmissionWebhook
  configuration:
    apiVersion: apiserver.config.k8s.io/v1
    kind: WebhookAdmissionConfiguration
    kubeConfigFile: "<path-to-kubeconfig-file>"

# Застаріло у v1.17 на користь apiserver.config.k8s.io/v1
apiVersion: apiserver.k8s.io/v1alpha1
kind: AdmissionConfiguration
plugins:
- name: ValidatingAdmissionWebhook
  configuration:
    # Застаріло у v1.17 на користь apiserver.config.k8s.io/v1, kind=WebhookAdmissionConfiguration
    apiVersion: apiserver.config.k8s.io/v1alpha1
    kind: WebhookAdmission
    kubeConfigFile: "<path-to-kubeconfig-file>"
- name: MutatingAdmissionWebhook
  configuration:
    # Застаріло у v1.17 на користь apiserver.config.k8s.io/v1, kind=WebhookAdmissionConfiguration
    apiVersion: apiserver.config.k8s.io/v1alpha1
    kind: WebhookAdmission
    kubeConfigFile: "<path-to-kubeconfig-file>"

Для отримання додаткової інформації про AdmissionConfiguration, дивіться документацію по AdmissionConfiguration (v1). Дивіться розділ конфігурації вебхуку для деталей про кожне поле конфігурації.

У файлі kubeConfig вкажіть облікові дані:

apiVersion: v1
kind: Config
users:
# name повинно бути встановлено на DNS-імʼя служби або хост (включаючи порт) URL-адреси, з якою налаштовано взаємодію вебхуку.
# Якщо для служб використовується порт, відмінний від 443, його необхідно включити до імені під час налаштування серверів API версії 1.16+.
#
# Для вебхуку, налаштованого для взаємодії зі службою настандартному порті (443), вкажіть DNS-імʼя служби:
# - name: webhook1.ns1.svc
#   user: ...
#
# Для вебхуку, налаштованого для взаємодії зі службою на нестандартному порту (наприклад, 8443), вкажіть DNS-імʼя та порт служби у версії 1.16+:
# - name: webhook1.ns1.svc:8443
#   user: ...
# і, за бажанням, створіть другу секцію, використовуючи лише DNS-імʼя служби для сумісності з серверами API версії 1.15:
# - name: webhook1.ns1.svc
#   user: ...
#
# Для вебхуків, налаштованих для взаємодії з URL-адресою, вкажіть хост (і порт), вказані в URL-адресі вебхуку. Приклади:
# Вебхук з `url: https://www.example.com`:
# - name: www.example.com
#   user: ...
#
# Вебхук з `url: https://www.example.com:443`:
# - name: www.example.com:443
#   user: ...
#
# Вебхук з `url: https://www.example.com:8443`:
# - name: www.example.com:8443
#   user: ...
#
- name: 'webhook1.ns1.svc'
  user:
    client-certificate-data: "<pem encoded certificate>"
    client-key-data: "<pem encoded key>"
# Поле `name` підтримує використання * для підстановки сегментів префікса.
- name: '*.webhook-company.org'
  user:
    password: "<password>"
    username: "<name>"
# '*' є стандартним збігом.
- name: '*'
  user:
    token: "<token>"

Звичайно, вам потрібно налаштувати сервер вебхуків для обробки цих запитів на автентифікацію.

Запит і відповідь вебхука

Запит

Вебхуки надсилаються як POST-запити з Content-Type: application/json, з об’єктом API AdmissionReview в API-групі admission.k8s.io, серіалізованим у JSON як тіло запиту.

Вебхуки можуть вказувати, які версії об’єктів AdmissionReview вони приймають, використовуючи поле admissionReviewVersions у своїй конфігурації:

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
webhooks:
- name: my-webhook.example.com
  admissionReviewVersions: ["v1", "v1beta1"]

admissionReviewVersions є обов’язковим полем при створенні конфігурацій вебхуків. Вебхуки повинні підтримувати принаймні одну версію AdmissionReview, яка зрозуміла поточному та попередньому API-серверу.

API-сервери надсилають першу версію AdmissionReview зі списку admissionReviewVersions, яку вони підтримують. Якщо жодна з версій у списку не підтримується API-сервером, створення конфігурації не буде дозволено. Якщо API-сервер виявляє конфігурацію вебхука, яка була створена раніше і не підтримує жодної з версій AdmissionReview, які API-сервер може надсилати, спроби виклику вебхука будуть невдалими та підлягатимуть політиці відмови.

Цей приклад показує дані, що містяться в об’єкті AdmissionReview для запиту на оновлення субресурсу scale для Deployment з групи apps/v1:

apiVersion: admission.k8s.io/v1
kind: AdmissionReview
request:
  # Випадковий uid, що унікально ідентифікує цей виклик підтвердження
  uid: 705ab4f5-6393-11e8-b7cc-42010a800002

  # Повністю кваліфікована група/версія/тип вхідного об’єкта
  kind:
    group: autoscaling
    version: v1
    kind: Scale

  # Повністю кваліфікована група/версія/тип ресурсу, що змінюється
  resource:
    group: apps
    version: v1
    resource: deployments

  # субресурс, якщо запит стосується субресурсу
  subResource: scale

  # Повністю кваліфікована група/версія/тип вхідного об’єкта в початковому запиті до API-сервера.
  # Це відрізняється від `kind`, лише якщо вебхук вказав `matchPolicy: Equivalent` і початковий запит до API-сервера був конвертований у версію, для якої зареєстровано вебхук.
  requestKind:
    group: autoscaling
    version: v1
    kind: Scale

  # Повністю кваліфікована група/версія/тип ресурсу, що змінюється в початковому запиті до API-сервера.
  # Це відрізняється від `resource`, лише якщо вебхук вказав `matchPolicy: Equivalent` і початковий запит до API-сервера був конвертований у версію, для якої зареєстровано вебхук.
  requestResource:
    group: apps
    version: v1
    resource: deployments

  # субресурс, якщо запит стосується субресурсу
  # Це відрізняється від `subResource`, лише якщо вебхук вказав `matchPolicy: Equivalent` і початковий запит до API-сервера був конвертований у версію, для якої зареєстровано вебхук.
  requestSubResource: scale

  # Ім’я ресурсу, що змінюється
  name: my-deployment

  # Простір імен ресурсу, що змінюється, якщо ресурс має простір імен (або є об’єктом Namespace)
  namespace: my-namespace

  # операція може бути CREATE, UPDATE, DELETE або CONNECT
  operation: UPDATE

  userInfo:
    # Ім’я користувача автентифікованого користувача, що робить запит до API-сервера
    username: admin

    # UID автентифікованого користувача, що робить запит до API-сервера
    uid: 014fbff9a07c

    # Групові членства автентифікованого користувача, що робить запит до API-сервера
    groups:
      - system:authenticated
      - my-admin-group
    # Додаткова довільна інформація, пов’язана з користувачем, що робить запит до API-сервера.
    # Це заповнюється шаром автентифікації API-сервера і повинно бути включено,
    # якщо будь-які перевірки SubjectAccessReview виконуються вебхуком.
    extra:
      some-key:
        - some-value1
        - some-value2

  # object є новим об’єктом, що підлягає допуску.
  # Це null для операцій DELETE.
  object:
    apiVersion: autoscaling/v1
    kind: Scale

  # oldObject є існуючим об’єктом.
  # Це null для операцій CREATE та CONNECT.
  oldObject:
    apiVersion: autoscaling/v1
    kind: Scale

  # options містить параметри операції, що підлягає допуску, як-от meta.k8s.io/v1 CreateOptions, UpdateOptions або DeleteOptions.
  # Це null для операцій CONNECT.
  options:
    apiVersion: meta.k8s.io/v1
    kind: UpdateOptions

  # dryRun вказує, що API-запит виконується в режимі dry run і не буде збережений.
  # Вебхуки з побічними ефектами повинні уникати здійснення цих побічних ефектів, коли dryRun дорівнює true.
  # Див. http://k8s.io/docs/reference/using-api/api-concepts/#make-a-dry-run-request для додаткової інформації.
  dryRun: False

Відповідь

Вебхуки відповідають зі статус-кодом HTTP 200, Content-Type: application/json та тілом, що містить об’єкт AdmissionReview (у тій же версії, що була надіслана), з заповненою секцією response, серіалізованою у JSON.

Мінімум, секція response повинна містити такі поля:

  • uid, скопійований з request.uid, що був надісланий до вебхука
  • allowed, встановлений або в true, або в false

Приклад мінімальної відповіді від вебхука для дозволу запиту:

{
  "apiVersion": "admission.k8s.io/v1",
  "kind": "AdmissionReview",
  "response": {
    "uid": "<значення з request.uid>",
    "allowed": true
  }
}

Приклад мінімальної відповіді від вебхука для заборони запиту:

{
  "apiVersion": "admission.k8s.io/v1",
  "kind": "AdmissionReview",
  "response": {
    "uid": "<значення з request.uid>",
    "allowed": false
  }
}

При відхиленні запиту вебхук може налаштувати HTTP-код та повідомлення, яке повертається користувачеві, використовуючи поле status. Вказаний об’єкт статусу повертається користувачеві. Див. Довідник API для деталей про тип status. Приклад відповіді для заборони запиту з налаштуванням HTTP-коду та повідомлення, яке буде представлено користувачеві:

{
  "apiVersion": "admission.k8s.io/v1",
  "kind": "AdmissionReview",
  "response": {
    "uid": "<значення з request.uid>",
    "allowed": false,
    "status": {
      "code": 403,
      "message": "Ви не можете це зробити, тому що сьогодні вівторок і ваше ім’я починається з літери А"
    }
  }
}

При дозволі запиту, модифікуючий вебхук допуску може за бажанням модифікувати вхідний об’єкт. Це робиться за допомогою полів patch та patchType у відповіді. Єдиний підтримуваний тип patchType наразі — JSONPatch. Див. документацію JSON patch для додаткової інформації. Для patchType: JSONPatch, поле patch містить base64-кодований масив операцій JSON patch.

Як приклад, єдина операція patch, яка встановить spec.replicas, виглядає так: [{"op": "add", "path": "/spec/replicas", "value": 3}]

Base64-кодована, вона виглядатиме так: W3sib3AiOiAiYWRkIiwgInBhdGgiOiAiL3NwZWMvcmVwbGljYXMiLCAidmFsdWUiOiAzfV0=

Отже, відповідь вебхука для додавання цієї мітки буде такою:

{
  "apiVersion": "admission.k8s.io/v1",
  "kind": "AdmissionReview",
  "response": {
    "uid": "<значення з request.uid>",
    "allowed": true,
    "patchType": "JSONPatch",
    "patch": "W3sib3AiOiAiYWRkIiwgInBhdGgiOiAiL3NwZWMvcmVwbGljYXMiLCAidmFsdWUiOiAzfV0="
  }
}

Вебхуки допуску можуть за бажанням повертати попереджувальні повідомлення, які повертаються клієнту, що зробив запит, у HTTP-заголовках Warning з кодом попередження 299. Попередження можуть бути надіслані з дозволеними або відхиленими відповідями на допуск.

Якщо ви реалізуєте вебхук, що повертає попередження:

  • Не включайте префікс "Warning:" у повідомлення
  • Використовуйте попереджувальні повідомлення для опису проблем, які клієнт, що робить API-запит, має виправити або про які має знати
  • За можливості, обмежуйте попередження до 120 символів
{
  "apiVersion": "admission.k8s.io/v1",
  "kind": "AdmissionReview",
  "response": {
    "uid": "<значення з request.uid>",
    "allowed": true,
    "warnings": [
      "зазначено дублюючі записи envvar з іменем MY_ENV",
      "запит на пам’ять менший за 4 МБ зазначено для контейнера mycontainer, який не запуститься успішно"
    ]
  }
}

Конфігурація вебхука

Для реєстрації вебхуків допуску створіть об’єкти API MutatingWebhookConfiguration або ValidatingWebhookConfiguration. Назва об’єкта MutatingWebhookConfiguration або ValidatingWebhookConfiguration має бути дійсним DNS-імʼям субдомену.

Кожна конфігурація може містити один або кілька вебхуків. Якщо в одній конфігурації вказано кілька вебхуків, кожен з них повинен мати унікальну назву. Це необхідно для полегшення відповідності логів аудиту та метрик активних конфігурацій.

Кожен вебхук визначає наступні параметри.

Відповідність запитів: правила

Кожен вебхук має вказувати список правил, що використовуються для визначення, чи повинен запит до API-сервера бути надісланий до вебхука. Кожне правило вказує одну або кілька операцій, груп API, версій API та ресурсів, а також область ресурсу:

  • operations отримує перелік з однієї або кількох операцій для порівняння. Можливі значення: "CREATE", "UPDATE", "DELETE", "CONNECT" або "*" для збігу зі всіма операціям.

  • apiGroups отримує перелік з однієї або кількох груп API для порівняння. "" означає ядро групи API. "*" відповідає всім групам API.

  • apiVersions отримує перелік з однієї або кількох версій API для порівняння. "*" відповідає всім версіям API.

  • resources отримує перелік з одного або кількох ресурсів для порівняння.

    • "*" відповідає всім ресурсам, але не субресурсам.
    • "*/*" відповідає всім ресурсам і субресурсам.
    • "pods/*" відповідає всім субресурсам Podʼів.
    • "*/status" відповідає всім субресурсам статусу.
  • scope вказує область для порівняння. Допустимі значення: "Cluster", "Namespaced" та "*". Субресурси відповідають області їх батьківського ресурсу. Стандартно "*".

    • "Cluster" означає, що тільки ресурси з кластерною областю відповідатимуть цьому правилу (об’єкти Namespace мають кластерну область).
    • "Namespaced" означає, що тільки ресурси з простору імен відповідатимуть цьому правилу.
    • "*" означає, що немає обмежень щодо області.

Якщо вхідний запит відповідає одному з: operations, apiGroups, apiVersions, resources та scope для будь-якого з правил вебхука, запит надсилається до вебхука.

Ось інші приклади правил, які можуть бути використані для визначення, які ресурси слід перехоплювати.

Відповідність запитам CREATE або UPDATE до apps/v1 та apps/v1beta1 deployments і replicasets:

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
webhooks:
- name: my-webhook.example.com
  rules:
  - operations: ["CREATE", "UPDATE"]
    apiGroups: ["apps"]
    apiVersions: ["v1", "v1beta1"]
    resources: ["deployments", "replicasets"]
    scope: "Namespaced"
  ...

Відповідність запитам на створення для всіх ресурсів (але не субресурсів) у всіх групах і версіях API:

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
webhooks:
  - name: my-webhook.example.com
    rules:
      - operations: ["CREATE"]
        apiGroups: ["*"]
        apiVersions: ["*"]
        resources: ["*"]
        scope: "*"

Відповідність запитам на оновлення для всіх субресурсів status у всіх групах і версіях API:

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
webhooks:
  - name: my-webhook.example.com
    rules:
      - operations: ["UPDATE"]
        apiGroups: ["*"]
        apiVersions: ["*"]
        resources: ["*/status"]
        scope: "*"

Відповідність запитів: objectSelector

Вебхуки можуть за бажанням обмежувати, які запити перехоплюються, на основі міток обʼєктів, до яких вони будуть надіслані, вказуючи objectSelector. Якщо вказано, objectSelector оцінюється як для обʼєкта, так і для старого обʼєкта, які будуть надіслані до вебхука, і вважається відповідним, якщо будь-який з обʼєктів відповідає селектору.

Обʼєкт, що дорівнює null (oldObject у випадку створення або newObject у випадку видалення), або обʼєкт, який не може мати міток (наприклад, обʼєкт DeploymentRollback або PodProxyOptions), не вважається відповідним.

Використовуйте селектор обʼєктів тільки якщо вебхук є опціональним, тому що кінцеві користувачі можуть обійти вебхук допуску, встановлюючи мітки.

Цей приклад показує модифікуючий вебхук, який відповідатиме CREATE для будь-якого ресурсу (але не субресурсів) з міткою foo: bar:

apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
webhooks:
- name: my-webhook.example.com
  objectSelector:
    matchLabels:
      foo: bar
  rules:
  - operations: ["CREATE"]
    apiGroups: ["*"]
    apiVersions: ["*"]
    resources: ["*"]
    scope: "*"

Див. концепцію міток для більшої кількості прикладів селекторів міток.

Відповідність запитів: namespaceSelector

Вебхуки можуть за бажанням обмежувати, які запити на ресурси в межах простору імен перехоплюються, на основі міток простору імен, до якого вони належать, вказуючи namespaceSelector.

namespaceSelector вирішує, чи слід запускати вебхук для запиту на ресурс у межах простору імен (або обʼєкт Namespace), на основі того, чи відповідають мітки простору імен селектору. Якщо обʼєкт сам є простором імен, відповідність виконується за object.metadata.labels. Якщо обʼєкт є кластерним ресурсом, відмінним від Namespace, namespaceSelector не впливає.

Цей приклад показує модифікуючий вебхук, який відповідає CREATE для будь-якого ресурсу в межах простору імен, який не має мітки "runlevel" зі значенням "0" або "1":

apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
webhooks:
  - name: my-webhook.example.com
    namespaceSelector:
      matchExpressions:
        - key: runlevel
          operator: NotIn
          values: ["0","1"]
    rules:
      - operations: ["CREATE"]
        apiGroups: ["*"]
        apiVersions: ["*"]
        resources: ["*"]
        scope: "Namespaced"

Цей приклад показує валідаційний вебхук, який відповідає CREATE для будь-якого ресурсу в межах простору імен, асоційованого з "environment" зі значенням "prod" або "staging":

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
webhooks:
  - name: my-webhook.example.com
    namespaceSelector:
      matchExpressions:
        - key: environment
          operator: In
          values: ["prod","staging"]
    rules:
      - operations: ["CREATE"]
        apiGroups: ["*"]
        apiVersions: ["*"]
        resources: ["*"]
        scope: "Namespaced"

Див. концепцію міток для більшої кількості прикладів селекторів міток.

Відповідність запитів: matchPolicy

API сервери можуть робити обʼєкти доступними через кілька API груп або версій.

Наприклад, якщо вебхук визначає правило для певних API груп/версій (наприклад, apiGroups:["apps"], apiVersions:["v1","v1beta1"]), і запит робиться для зміни ресурсу через іншу API групу/версію (наприклад, extensions/v1beta1), запит не буде надіслано до вебхука.

matchPolicy дозволяє вебхуку визначити, як його rules використовуються для відповідності вхідним запитам. Допустимі значення — Exact або Equivalent.

  • Exact означає, що запит повинен бути перехоплений тільки в тому випадку, якщо він точно відповідає зазначеному правилу.
  • Equivalent означає, що запит повинен бути перехоплений, якщо він модифікує ресурс, зазначений в rules, навіть через іншу API групу або версію.

У наведеному вище прикладі, вебхук, зареєстрований тільки для apps/v1, може використовувати matchPolicy:

  • matchPolicy: Exact означає, що запит extensions/v1beta1 не буде надіслано до вебхука.
  • matchPolicy: Equivalent означає, що запит extensions/v1beta1 буде надіслано до вебхука (з обʼєктами, конвертованими до версії, яку вебхук визначив: apps/v1).

Вказування Equivalent рекомендовано і забезпечує, що вебхуки продовжують перехоплювати очікувані ресурси, коли оновлення включають нові версії ресурсу в API сервері.

Коли ресурс перестає обслуговуватись API сервером, він більше не вважається еквівалентним іншим версіям цього ресурсу, які все ще обслуговуються. Наприклад, extensions/v1beta1 розгортання були спочатку визнані застарілими, а потім видалені (у Kubernetes v1.16).

З моменту цього видалення, вебхук з правилом apiGroups:["extensions"], apiVersions:["v1beta1"], resources:["deployments"] не перехоплює розгортання, створені через API apps/v1. З цієї причини, вебхуки повинні віддавати перевагу реєстрації для стабільних версій ресурсів.

Цей приклад показує валідаційний вебхук, який перехоплює модифікації розгортань (незалежно від API групи або версії) і завжди отримує обʼєкт Deployment версії apps/v1:

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
webhooks:
- name: my-webhook.example.com
  matchPolicy: Equivalent
  rules:
  - operations: ["CREATE","UPDATE","DELETE"]
    apiGroups: ["apps"]
    apiVersions: ["v1"]
    resources: ["deployments"]
    scope: "Namespaced"

matchPolicy для вебхуків допуску за замовчуванням дорівнює Equivalent.

Відповідність запитів: matchConditions

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.30 [stable]

Ви можете визначити умови відповідності для вебхуків, якщо вам потрібна точніша фільтрація запитів. Ці умови корисні, якщо правила відповідності, objectSelectors та namespaceSelectors не надають необхідної фільтрації при викликах по HTTP. Умови відповідності є CEL виразами. Всі умови відповідності повинні оцінюватися як true для виклику вебхука.

Ось приклад, що ілюструє декілька різних способів використання умов відповідності:

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
webhooks:
  - name: my-webhook.example.com
    matchPolicy: Equivalent
    rules:
      - operations: ['CREATE','UPDATE']
        apiGroups: ['*']
        apiVersions: ['*']
        resources: ['*']
    failurePolicy: 'Ignore' # Fail-open (опційно)
    sideEffects: None
    clientConfig:
      service:
        namespace: my-namespace
        name: my-webhook
      caBundle: '<omitted>'
    # Ви можете мати до 64 умов відповідності на вебхук
    matchConditions:
      - name: 'exclude-leases' # Кожна умова відповідності повинна мати унікальне імʼя
        expression: '!(request.resource.group == "coordination.k8s.io" && request.resource.resource == "leases")' # Відповідність ресурсам, які не є lease.
      - name: 'exclude-kubelet-requests'
        expression: '!("system:nodes" in request.userInfo.groups)' # Відповідність запитам, зробленим не користувачами вузлів.
      - name: 'rbac' # Пропуск запитів RBAC, які обробляються другим вебхуком.
        expression: 'request.resource.group != "rbac.authorization.k8s.io"'
  
  # Цей приклад ілюструє використання 'authorizer'. Перевірка авторизації дорожча за простий вираз, тому в цьому прикладі вона обмежена лише запитами RBAC, використовуючи другий вебхук. Обидва вебхуки можуть обслуговуватись одним кінцевим пунктом.
  - name: rbac.my-webhook.example.com
    matchPolicy: Equivalent
    rules:
      - operations: ['CREATE','UPDATE']
        apiGroups: ['rbac.authorization.k8s.io']
        apiVersions: ['*']
        resources: ['*']
    failurePolicy: 'Fail' # Fail-closed (стандартно)
    sideEffects: None
    clientConfig:
      service:
        namespace: my-namespace
        name: my-webhook
      caBundle: '<omitted>'
    # Ви можете мати до 64 умов відповідності на вебхук
    matchConditions:
      - name: 'breakglass'
        # Пропуск запитів, зроблених користувачами, авторизованими для 'breakglass' на цьому вебхуку.
        # Дієслово API 'breakglass' не повинно існувати за межами цієї перевірки.
        expression: '!authorizer.group("admissionregistration.k8s.io").resource("validatingwebhookconfigurations").name("my-webhook.example.com").check("breakglass").allowed()'

Умови відповідності мають доступ до наступних CEL змінних:

  • object — Обʼєкт з вхідного запиту. Значення є null для DELETE запитів. Версія обʼєкта може бути конвертована на основі matchPolicy.
  • oldObject — Наявний обʼєкт. Значення є null для CREATE запитів.
  • request — Частина запиту AdmissionReview, виключаючи object та oldObject.
  • authorizer — CEL Authorizer. Може використовуватись для виконання перевірок авторизації для головного облікового запису (автентифікованого користувача) запиту. Дивіться Authz у документації бібліотеки Kubernetes CEL для додаткової інформації.
  • authorizer.requestResource — Скорочення для перевірки авторизації, налаштованої на ресурс запиту (група, ресурс, (субресурс), простір імен, імʼя).

Для отримання додаткової інформації про CEL вирази, зверніться до довідника Загальна мова виразів у Kubernetes.

У разі помилки оцінки умови відповідності вебхук ніколи не викликається. Чи відхилити запит визначається наступним чином:

  1. Якщо будь-яка умова відповідності оцінилася як false (незалежно від інших помилок), API сервер пропускає вебхук.
  2. Інакше:
    • для failurePolicy: Fail, запит відхиляється (без виклику вебхука).
    • для failurePolicy: Ignore, продовжити запит, але пропустити вебхук.

Звернення до вебхука

Коли сервер API визначає, що запит повинен бути надісланий до вебхука, йому потрібно знати, як звʼязатися з вебхуком. Це визначається в розділі clientConfig конфігурації вебхука.

Вебхуки можуть викликатися через URL або посилання на сервіс, і можуть за бажанням включати власний набір CA для використання для перевірки TLS-зʼєднання.

URL

Поле url вказує місцезнаходження вебхука у стандартній формі URL (scheme://host:port/path).

Поле host не повинно вказувати на сервіс, що працює в кластері; використовуйте посилання на сервіс, вказуючи поле service. Хост може бути вирішений через зовнішній DNS на деяких серверах API (наприклад, kube-apiserver не може вирішувати DNS всередині кластера, оскільки це буде порушенням шарів). host також може бути IP-адресою.

Зверніть увагу, що використання localhost або 127.0.0.1 як host є ризикованим, якщо ви не забезпечите запуск цього вебхука на всіх хостах, які запускають сервер API, який може потребувати викликів до цього вебхука. Такі інсталяції, ймовірно, будуть непереносними або не будуть легко запускатися в новому кластері.

Схема повинна бути "https"; URL повинен починатися з "https://".

Спроба використання користувача або базової автентифікації (наприклад, user:password@) не дозволена. Фрагменти (#...) та параметри запиту (?...) також не дозволені.

Ось приклад конфігурації модифікуючого вебхука для виклику URL (і очікується, що TLS-сертифікат буде перевірено за допомогою системних коренів довіри, тому не вказується caBundle):

apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
webhooks:
- name: my-webhook.example.com
  clientConfig:
    url: "https://my-webhook.example.com:9443/my-webhook-path"

Посилання на сервіс

Розділ service всередині clientConfig є посиланням на сервіс для цього вебхука. Якщо вебхук працює всередині кластера, вам слід використовувати service замість url. Необхідно вказати простір імен та імʼя сервісу. Порт є необовʼязковим і стандартно дорівнює 443. Шлях є необовʼязковим і стандартно дорівнює "/".

Ось приклад конфігурації модифікуючого вебхука для виклику сервісу на порту "1234" за підшляхом "/my-path", і для перевірки TLS-зʼєднання проти ServerName my-service-name.my-service-namespace.svc з використанням власного набору CA:

apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
webhooks:
- name: my-webhook.example.com
  clientConfig:
    caBundle: <CA_BUNDLE>
    service:
      namespace: my-service-namespace
      name: my-service-name
      path: /my-path
      port: 1234

Побічні ефекти

Вебхуки зазвичай працюють тільки з вмістом AdmissionReview, надісланого їм. Однак деякі вебхуки здійснюють зміни поза межами під час обробки запитів на допуск.

Вебхуки, які здійснюють зміни поза межами ("побічні ефекти"), повинні також мати механізм узгодження (наприклад, контролер), який періодично визначає фактичний стан системи та коригує дані поза межами, змінені вебхуком допуску, щоб відобразити реальність. Це тому, що виклик до вебхука допуску не гарантує, що прийнятий обʼєкт буде збережений таким, яким він є, або взагалі. Пізніші вебхуки можуть змінити вміст обʼєкта, може виникнути конфлікт під час запису в сховище, або сервер може вимкнутися до збереження обʼєкта.

Крім того, вебхуки з побічними ефектами повинні пропускати ці побічні ефекти, коли обробляються запити допуску з dryRun: true. Вебхук повинен явно вказати, що він не матиме побічних ефектів при запуску з dryRun, інакше запит dry-run не буде надіслано до вебхука, і API-запит замість цього не вдасться.

Вебхуки вказують, чи мають вони побічні ефекти, за допомогою поля sideEffects у конфігурації вебхука:

  • None: виклик вебхука не матиме побічних ефектів.
  • NoneOnDryRun: виклик вебхука може мати побічні ефекти, але якщо до вебхука надіслано запит з dryRun: true, вебхук придушить побічні ефекти (вебхук враховує dryRun).

Ось приклад конфігурації вебхука перевірки, який вказує, що він не має побічних ефектів при запитах з dryRun: true:

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
webhooks:
  - name: my-webhook.example.com
    sideEffects: NoneOnDryRun

Тайм-аути

Оскільки вебхуки додають затримку до запитів API, вони повинні оцінюватися якомога швидше. timeoutSeconds дозволяє налаштувати, скільки часу сервер API повинен чекати на відповідь вебхука, перш ніж розглядати виклик як невдалий.

Якщо тайм-аут закінчується до того, як вебхук відповість, виклик вебхука буде проігноровано або API-запит буде відхилено відповідно до політики помилок.

Значення тайм-ауту повинно бути між 1 і 30 секунд.

Ось приклад конфігурації вебхука перевірки з кастомним тайм-аутом у 2 секунди:

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
webhooks:
  - name: my-webhook.example.com
    timeoutSeconds: 2

Тайм-аут для вебхука допуску стандартно становить 10 секунд.

Політика повторного виклику

Одне впорядкування втулків модифікуючого допуску (включаючи вебхуки) не підходить для всіх випадків (див. приклад у https://issue.k8s.io/64333). Модифікуючий вебхук може додати нову підструктуру до обʼєкта (наприклад, додати container до pod), а інші модифікуючи втулки, які вже виконані, можуть мати вплив на ці нові структури (наприклад, встановити imagePullPolicy для всіх контейнерів).

Щоб дозволити втулкам модифікуючого допуску спостерігати за змінами, внесеними іншими втулками, вбудовані модифікуючи втулки допуску повторно запускаються, якщо модифікуючий вебхук змінює обʼєкт, і модифікуючи вебхуки можуть вказати reinvocationPolicy для контролю того, чи будуть вони повторно викликані.

reinvocationPolicy може бути встановлено на Never або IfNeeded. Стандартно встановлено у Never.

  • Never: вебхук не повинен викликатися більше одного разу в рамках однієї оцінки допуску.
  • IfNeeded: вебхук може бути викликаний знову в рамках оцінки допуску, якщо обʼєкт, що авторизується, змінюється іншими втулками допуску після початкового виклику вебхука.

Важливі моменти, на які слід звернути увагу:

  • Кількість додаткових викликів не гарантується як точно одна.
  • Якщо додаткові виклики призводять до подальших змін обʼєкта, не гарантується, що вебхуки будуть викликані знов.
  • Вебхуки, які використовують цей параметр, можуть бути переупорядковані для мінімізації кількості додаткових викликів.
  • Щоб перевірити обʼєкт після того, як всі модифікації гарантовано завершені, використовуйте вебхук допуску (рекомендується для вебхуків з побічними ефектами).

Ось приклад конфігурації модифікуючого вебхука, який вибирає повторний виклик, якщо пізніші втулки допуску змінюють обʼєкт:

apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
webhooks:
- name: my-webhook.example.com
  reinvocationPolicy: IfNeeded

Модифікуючи вебхуки повинні бути ідемпотентними, здатними успішно обробити обʼєкт, який вони вже авторизували і потенційно змінили. Це стосується всіх модифікуючих вебхуків допуску, оскільки будь-яка зміна, яку вони можуть внести в обʼєкт, вже могла існувати в обʼєкті, наданому користувачем, але це є особливо важливим для вебхуків, які вибирають повторний виклик.

Політика обробки помилок

failurePolicy визначає, як обробляються невизнані помилки та помилки тайм-ауту від вебхука допуску. Допустимі значення: Ignore або Fail.

  • Ignore означає, що помилка при виклику вебхука ігнорується, і запит API дозволяється продовжити.
  • Fail означає, що помилка при виклику вебхука призводить до невдачі допуску та відхилення запиту API.

Ось приклад конфігурації модифікуючого вебхука, налаштованого на відхилення запиту API, якщо виникають помилки під час виклику вебхука допуску:

apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
webhooks:
- name: my-webhook.example.com
  failurePolicy: Fail

Стандартна політика обробки помилок failurePolicy для вебхуків допуску Fail.

Моніторинг вебхуків авторизації

Сервер API надає способи моніторингу поведінки вебхуків допуску. Ці механізми моніторингу допомагають адміністраторам кластерів відповісти на запитання, як:

  1. Який модифікуючий вебхук змінив обʼєкт у запиті API?

  2. Яку зміну модифікуючий вебхук застосував до обʼєкта?

  3. Які вебхуки часто відхиляють запити API? Яка причина відхилення?

Анотації аудиту модифікуючих вебхуків

Іноді корисно знати, який модифікуючий вебхук змінив обʼєкт у запиті API, і яку зміну вебхук застосував.

Сервер API Kubernetes виконує аудит кожного виклику модифікуючого вебхука. Кожен виклик генерує анотацію аудиту, яка відображає, чи був обʼєкт запиту змінений викликом, і, за необхідності, генерує анотацію із застосованим патчем з відповіді вебхука допуску. Анотації встановлюються в подію аудиту для даного запиту на даній стадії його виконання, яка потім попередньо обробляється відповідно до певної політики та записується в бекенд.

Рівень аудиту події визначає, які анотації будуть записані:

  • На рівні аудиту Metadata або вище записується анотація з ключем mutation.webhook.admission.k8s.io/round_{round idx}_index_{order idx} з JSON-наватаженням, яке вказує, що вебхук був викликаний для даного запиту і чи змінив він обʼєкт чи ні.

    Наприклад, наступна анотація записується для вебхука, який повторно викликається. Вебхук є третім у ланцюгу модифікуючих вебхуків і не змінив обʼєкт запиту під час виклику.

    # записана подія аудиту
    {
        "kind": "Event",
        "apiVersion": "audit.k8s.io/v1",
        "annotations": {
            "mutation.webhook.admission.k8s.io/round_1_index_2": "{\"configuration\":\"my-mutating-webhook-configuration.example.com\",\"webhook\":\"my-webhook.example.com\",\"mutated\": false}"
            # інші анотації
            ...
        }
        # інші поля
        ...
    }
    
    # десеріалізоване значення анотації
    {
        "configuration": "my-mutating-webhook-configuration.example.com",
        "webhook": "my-webhook.example.com",
        "mutated": false
    }
    

    Наступна анотація записується для вебхука, який викликається на першій стадії. Вебхук є першим у ланцюгу модифікуючих вебхуків і змінив обʼєкт запиту під час виклику.

    # записана подія аудиту
    {
        "kind": "Event",
        "apiVersion": "audit.k8s.io/v1",
        "annotations": {
            "mutation.webhook.admission.k8s.io/round_0_index_0": "{\"configuration\":\"my-mutating-webhook-configuration.example.com\",\"webhook\":\"my-webhook-always-mutate.example.com\",\"mutated\": true}"
            # інші анотації
            ...
        }
        # інші поля
        ...
    }
    
    # десеріалізоване значення анотації
    {
        "configuration": "my-mutating-webhook-configuration.example.com",
        "webhook": "my-webhook-always-mutate.example.com",
        "mutated": true
    }
    
  • На рівні аудиту Request або вище записується анотація з ключем patch.webhook.admission.k8s.io/round_{round idx}_index_{order idx} з JSON-навантаженням, яке вказує, що вебхук був викликаний для даного запиту і який патч був застосований до обʼєкта запиту.

    Наприклад, наступна анотація записується для вебхука, який повторно викликається. Вебхук є четвертим у ланцюгу модифікуючих вебхуків і відповів JSON-патчем, який був застосований до обʼєкта запиту.

    # записана подія аудиту
    {
        "kind": "Event",
        "apiVersion": "audit.k8s.io/v1",
        "annotations": {
            "patch.webhook.admission.k8s.io/round_1_index_3": "{\"configuration\":\"my-other-mutating-webhook-configuration.example.com\",\"webhook\":\"my-webhook-always-mutate.example.com\",\"patch\":[{\"op\":\"add\",\"path\":\"/data/mutation-stage\",\"value\":\"yes\"}],\"patchType\":\"JSONPatch\"}"
            # інші анотації
            ...
        }
        # інші поля
        ...
    }
    
    # десеріалізоване значення анотації
    {
        "configuration": "my-other-mutating-webhook-configuration.example.com",
        "webhook": "my-webhook-always-mutate.example.com",
        "patchType": "JSONPatch",
        "patch": [
            {
                "op": "add",
                "path": "/data/mutation-stage",
                "value": "yes"
            }
        ]
    }
    

Метрики вебхуків допуску

Сервер API надає метрики Prometheus з точки доступу /metrics, які можна використовувати для моніторингу та діагностики стану сервера API. Наведені нижче метрики фіксують стан, повʼязаний з вебхуками допуску.

Лічильник відхилення запитів вебхука допуску сервера API

Іноді корисно знати, які вебхуки допуску часто відхиляють запити API, та причину відхилення.

Сервер API надає метрику лічильника Prometheus, яка фіксує відхилення вебхуків допуску. Метрики мають підписи, що ідентифікують причини відхилення запитів вебхуками:

  • name: назва вебхука, який відхилив запит.

  • operation: тип операції запиту, може бути одним із CREATE, UPDATE, DELETE та CONNECT.

  • type: тип вебхука допуску, може бути одним із admit та validating.

  • error_type: визначає, чи сталася помилка під час виклику вебхука, яка призвела до відхилення. Його значення може бути одним із:

    • calling_webhook_error: невизнані помилки або помилки тайм-ауту від вебхука допуску сталися, і політика помилки вебхука встановлена на Fail.
    • no_error: помилка не сталася. Вебхук відхилив запит з allowed: false у відповіді допуску. Підписи метрики rejection_code записують значення .status.code, встановлене в відповіді допуску.
    • apiserver_internal_error: сталася внутрішня помилка сервера API.
  • rejection_code: HTTP-код статусу, встановлений у відповіді допуску, коли вебхук відхилив запит.

Приклад метрик лічильника відхилення:

# HELP apiserver_admission_webhook_rejection_count [ALPHA] Лічильник відхилення вебхуків авторизації, ідентифікований за назвою та розділений для кожного типу авторизації (валідація чи допуск) та операції. Додаткові підписи вказують тип помилки (calling_webhook_error або apiserver_internal_error, якщо виникла помилка; no_error інакше) та, за потреби, ненульовий код відхилення, якщо вебхук відхилив запит із HTTP-кодом статусу (врахований сервером API, якщо код більший або рівний 400). Коди, більші за 600, обрізаються до 600, щоб обмежити кардинальність метрик.
# TYPE apiserver_admission_webhook_rejection_count counter
apiserver_admission_webhook_rejection_count{error_type="calling_webhook_error",name="always-timeout-webhook.example.com",operation="CREATE",rejection_code="0",type="validating"} 1
apiserver_admission_webhook_rejection_count{error_type="calling_webhook_error",name="invalid-admission-response-webhook.example.com",operation="CREATE",rejection_code="0",type="validating"} 1
apiserver_admission_webhook_rejection_count{error_type="no_error",name="deny-unwanted-configmap-data.example.com",operation="CREATE",rejection_code="400",type="validating"} 13

Найкращі практики та попередження

Ідемпотентність

Ідемпотентний вебхук допуску, що змінює дані, може успішно обробляти обʼєкт, який він вже допустив і, можливо, змінив. Допуск можна застосовувати кілька разів, не змінюючи результат поза початковою обробкою.

Приклади ідемпотентних модифікуючих вебхуків допуску:

  1. Для запиту CREATE Pod задайте поле .spec.securityContext.runAsNonRoot в значення true, щоб застосувати найкращі практики безпеки.

  2. Для запиту запиту CREATE Pod стандартно встановлюються обмеження ресурсів, якщо поле .spec.containers[].resources.limits контейнера не встановлено.

  3. Для запиту запиту CREATE Pod додається додатковий контейнер з імʼям foo-sidecar, якщо контейнер із імʼям foo-sidecar ще не існує.

У випадках, наведених вище, вебхук може безпечно повторно викликатися або допускати обʼєкт, у якого вже встановлені ці поля.

Приклади неідемпотентних модифікуючих вебхуків допуску:

  1. Для запиту CREATE Pod додається sidecar контейнер з імʼям foo-sidecar, суфіксований поточним часовим позначенням (наприклад, foo-sidecar-19700101-000000).

  2. Для CREATE/UPDATE Pod відхиляються запити, якщо позначка "env" установлена, в іншому випадку додається позначка "env": "prod".

  3. Для запиту CREATE Pod додається контейнер під назвою foo-sidecar без перевірки наявності контейнера foo-sidecar у специфікації Pod.

У першому випадку вебхук може додавати однаковий контейнер декілька разів до Pod, кожного разу з різним іменем контейнера. Аналогічно, вебхук може додавати дубльовані контейнери, якщо вони вже існують у Podʼах користувачів.

У другому випадку повторний виклик вебхука призведе до помилки вихідних даних вебхука.

У третьому випадку повторний виклик вебхука призведе до дублювання контейнерів у специфікації Pod, що робить запит недійсним та відхиленим сервером API.

Перехоплення всіх версій обʼєкта

Рекомендується, щоб вебхуки допуску завжди перехоплювали всі версії обʼєкта, встановлюючи .webhooks[].matchPolicy на Equivalent. Також рекомендується, щоб вебхуки допуску завжди реєструвалися для стабільних версій ресурсів. Невдала спроба перехопити всі версії обʼєкта може призвести до того, що політика допуску не буде застосовуватися до деяких версій запитів. Дивіться Відповідність запитів: matchPolicy для прикладів.

Доступність

Рекомендується, щоб вебхуки допуску оцінювалися якомога швидше (зазвичай за мілісекунди), оскільки вони збільшують затримку запиту API. Рекомендується використовувати невеликий таймаут для вебхуків. Дивіться Таймаути для докладнішої інформації.

Рекомендується, щоб вебхуки допуску використовували якусь форму балансування навантаження, щоб забезпечити високу доступність та вигоди в продуктивності. Якщо вебхук працює всередині кластера, ви можете запустити декілька вебхуків позаду служби, щоб скористатися балансуванням навантаження, яке підтримує ця служба.

Гарантування остаточного стану обʼєкта

Вебхуки допуску, які повинні гарантувати, що вони бачать остаточний стан обʼєкта, щоб застосовувати політику, повинні використовувати вебхук допуску для валідації, оскільки обʼєкти можуть бути змінені після перегляду модифікуючими вебхуками.

Наприклад, модифікуючий вебхук допуску налаштований на впровадження контейнера sidecar з імʼям "foo-sidecar" на кожний запит CREATE pod. Якщо необхідно, щоб контейнер був присутнім, також слід налаштувати вебхук допуску для перехоплення запитів CREATE pod, і перевірити, що контейнер з імʼям "foo-sidecar" з необхідною конфігурацією існує в обʼєкті, який має бути створений.

Уникнення блокування вебхуків у самостійно розміщених вебхуках

Вебхук, що працює всередині кластера, може призвести до блокування власного deployment, якщо він налаштований для перехоплення ресурсів, необхідних для запуску власних Podʼів.

Наприклад, модифікуючий вебхук допуску налаштований на допуск запитів на створення CREATE pod лише в тому випадку, якщо у pod встановлено певну мітку (наприклад, "env": "prod"). Сервер розгортання вебхука працює в deployment, яке не встановлює мітку "env". Коли вузол, на якому запущено Podʼи вебхука, стає непрацездатним, deployment вебхука спробує перепланувати Podʼи на інший вузол. Однак запити будуть відхилені існуючим сервером вебхука, оскільки мітка "env" не встановлена, і міграція не може відбутися.

Рекомендується виключати простір імен, де працює ваш вебхук, за допомогою namespaceSelector.

Побічні ефекти

Рекомендується, щоб вебхуки допуску уникати побічних ефектів, якщо це можливо, що означає, що вебхуки працюють тільки з вмістом AdmissionReview, надісланим до них, і не вносять зміни поза цими рамками. Поле .webhooks[].sideEffects має бути встановлене на None, якщо у вебхука немає жодних побічних ефектів.

Якщо побічні ефекти потрібні під час оцінки допуску, їх потрібно приглушити при обробці обʼєкта AdmissionReview з dryRun встановленим на true, і поле .webhooks[].sideEffects має бути встановлене на NoneOnDryRun. Дивіться Побічні ефекти для докладнішої інформації.

Уникнення операцій у просторі імен kube-system

Простір імен kube-system містить обʼєкти, створені компонентами панелі управління Kubernetes, наприклад, службові облікові записи для компонентів панелі управління, Podʼи такі як kube-dns. Ненавмисна зміна або відхилення запитів у просторі імен kube-system може призвести до того, що компоненти панелі управління перестануть працювати або будуть внесені невідомі зміни. Якщо ваші вебхуки допуску не мають на меті змінювати поведінку панелі управління Kubernetes, виключіть простір імен kube-system з перехоплення за допомогою namespaceSelector.

6.3.10 - Управління службовими обліковими записами

Службовий обліковий запис (ServiceAccount) надає ідентифікацію для процесів, що виконуються в Pod.

Процес всередині Pod може використовувати ідентифікацію свого повʼязаного службового облікового запису для автентифікації у API сервері кластера.

Для ознайомлення зі службовими обліковими записами, прочитайте про конфігурування службових облікових записів.

Цей посібник пояснює деякі концепції, повʼязані зі ServiceAccount. Також у посібнику розглядається, як отримати або відкликати токени, що представляють ServiceAccounts.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Щоб точно виконати ці кроки, переконайтеся, що у вас є простір імен під назвою examplens. Якщо ні, створіть його, виконавши команду:

kubectl create namespace examplens

Облікові записи користувачів та службові облікові записи

Kubernetes розрізняє поняття облікового запису користувача та службового облікового запису з кількох причин:

  • Облікові записи користувачів призначені для людей. Службові облікові записи призначені для процесів застосунків, які (для Kubernetes) виконуються в контейнерах, що є частиною Pod.
  • Облікові записи користувачів мають бути глобальними: імена повинні бути унікальними у всіх просторах імен кластера. Незалежно від того, який простір імен ви розглядаєте, певний обліковий запис користувача представляє того самого користувача. У Kubernetes службові облікові записи є привʼязаними до простору імен: два різні простори імен можуть містити ServiceAccountʼи з однаковими іменами.
  • Як правило, облікові записи користувачів кластера можуть синхронізуватися з корпоративною базою даних, де створення нового облікового запису користувача вимагає спеціальних привілеїв і повʼязане зі складними бізнес-процесами. Навпаки, створення службових облікових записів повинно бути легшим, дозволяючи користувачам кластера створювати службові облікові записи для конкретних завдань за запитом. Відділення створення ServiceAccount від кроків для реєстрації користувачів полегшує дотримання принципу найменших привілеїв для робочих навантажень.
  • Вимоги до аудиту для облікових записів користувачів (людей) та службових облікових записів можуть відрізнятися; розділення полегшує досягнення цих вимог.
  • Конфігураційний пакет для складної системи може містити визначення різних службових облікових записів для компонентів цієї системи. Оскільки службові облікові записи можуть створюватися без багатьох обмежень і мають імена, привʼязані до простору імен, така конфігурація зазвичай є переносимою.

Привʼязані токени службових облікових записів

Токени ServiceAccount можуть бути привʼязані до API обʼєктів, що існують у kube-apiserver. Їх можна використовувати для звʼязування дійсності токена з існуванням іншого API обʼєкта. Підтримувані типи обʼєктів наступні:

  • Pod (використовується для projected томів, див. нижче)
  • Secret (може використовуватися для відкликання токена шляхом видалення Secret)
  • Node (у версії v1.30 створення нових токенів, привʼязаних до вузлів, є альфа-функцією, використання наявних токенів, привʼязаних до вузлів, є бета-функцією)

Коли токен привʼязаний до обʼєкта, metadata.name і metadata.uid цього обʼєкта зберігаються як додаткові "приватні заявки" у виданому JWT.

Коли привʼязаний токен представляється kube-apiserver, автентифікатор службового облікового запису витягне і перевірить ці заявки. Якщо вказаний обʼєкт або ServiceAccount знаходяться в процесі видалення (наприклад, через завершувач), то протягом будь-якого моменту, через 60 секунд (або більше) після дати .metadata.deletionTimestamp, автентифікація з використанням цього токена буде неуспішною. Якщо обʼєкт, на який він посилається, більше не існує (або його metadata.uid не збігається), запит не буде автентифікований.

Додаткові метадані в токенах, повʼязаних з Pod

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.30 [beta]

Коли токен службового облікового запису привʼязаний до обʼєкта Pod, додаткові метадані також вбудовуються в токен, що вказує на значення поля spec.nodeName повʼязаного Pod і uid цього вузла, якщо це можливо.

Ця інформація про вузол не перевіряється kube-apiserver, коли токен використовується для автентифікації. Вона включена, щоб інтегратори не повинні були отримувати обʼєкти API Pod або Node для перевірки повʼязаного імені вузла та uid при інспекції JWT.

Перевірка та інспекція приватних заявок

API TokenReview може використовуватися для перевірки та вилучення приватних заявок з токена:

  1. Спочатку припустимо, що у вас є Pod з назвою test-pod і службовий обліковий запис з назвою my-sa.

  2. Створіть токен, привʼязаний до цього Pod:

    kubectl create token my-sa --bound-object-kind="Pod" --bound-object-name="test-pod"
    
  3. Скопіюйте цей токен у новий файл з назвою tokenreview.yaml:

    apiVersion: authentication.k8s.io/v1
    kind: TokenReview
    spec:
      token: <токен з кроку 2>
    
  4. Надішліть цей ресурс до apiserver для перевірки:

    kubectl create -o yaml -f tokenreview.yaml # ми використовуємо '-o yaml', щоб можна було перевірити вихідні дані
    

Ви повинні побачити вихідні дані, подібні до наведених нижче:

apiVersion: authentication.k8s.io/v1
kind: TokenReview
metadata:
  creationTimestamp: null
spec:
  token: <token>
status:
  audiences:
  - https://kubernetes.default.svc.cluster.local
  authenticated: true
  user:
    extra:
      authentication.kubernetes.io/credential-id:
      - JTI=7ee52be0-9045-4653-aa5e-0da57b8dccdc
      authentication.kubernetes.io/node-name:
      - kind-control-plane
      authentication.kubernetes.io/node-uid:
      - 497e9d9a-47aa-4930-b0f6-9f2fb574c8c6
      authentication.kubernetes.io/pod-name:
      - test-pod
      authentication.kubernetes.io/pod-uid:
      - e87dbbd6-3d7e-45db-aafb-72b24627dff5
    groups:
    - system:serviceaccounts
    - system:serviceaccounts:default
    - system:authenticated
    uid: f8b4161b-2e2b-11e9-86b7-2afc33b31a7e
    username: system:serviceaccount:default:my-sa

Механізм томів привʼязаного токена службового облікового запису

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.22 [stable]

Стандартно, панель управління Kubernetes (зокрема, ServiceAccount admission controller) додає projected том до Pod, і цей том містить токен для доступу до API Kubernetes.

Ось приклад, як це виглядає для запущеного Pod:

...
  - name: kube-api-access-<random-suffix>
    projected:
      sources:
        - serviceAccountToken:
            path: token # має збігатися з шляхом, який очікує застосунок
        - configMap:
            items:
              - key: ca.crt
                path: ca.crt
            name: kube-root-ca.crt
        - downwardAPI:
            items:
              - fieldRef:
                  apiVersion: v1
                  fieldPath: metadata.namespace
                path: namespace

Цей фрагмент маніфесту визначає projected том, що складається з трьох джерел. У цьому випадку, кожне джерело також представляє один шлях у цьому томі. Три джерела такі:

  1. Джерело serviceAccountToken, яке містить токен, який kubelet отримує з kube-apiserver. Kubelet отримує токени з обмеженим терміном дії за допомогою API TokenRequest. Токен, наданий для TokenRequest, закінчується або при видаленні Pod, або після визначеного терміну дії (стандартно, це 1 година). Kubelet також оновлює цей токен перед тим, як термін його дії закінчиться. Токен привʼязаний до конкретного Pod і має kube-apiserver як свою аудиторію. Цей механізм замінив попередній механізм, який додавав том на основі Secret, де Secret представляв ServiceAccount для Pod, але не мав терміну дії.
  2. Джерело configMap. ConfigMap містить набір даних центру сертифікації. Pod можуть використовувати ці сертифікати, щоб упевнитись, що вони підключаються до kube-apiserver вашого кластера (а не до проміжного блоку або випадково неправильно налаштованого колеги).
  3. Джерело downwardAPI, яке шукає імʼя простору імен, що містить Pod, і надає цю інформацію про імʼя для коду застосунку, що виконується всередині Pod.

Будь-який контейнер у Pod, який монтує цей том, може отримати доступ до вищевказаної інформації.

Ручне управління Secret для ServiceAccounts

Версії Kubernetes до v1.22 автоматично створювали облікові дані для доступу до API Kubernetes. Цей старіший механізм був заснований на створенні токенів Secret, які потім могли бути змонтовані в запущені Podʼи.

У новіших версіях, включаючи Kubernetes v1.31, API облікові дані отримуються безпосередньо за допомогою TokenRequest, і монтуються в Podʼи за допомогою projected тому. Токени, отримані за допомогою цього методу, мають обмежений термін дії та автоматично анулюються, коли Pod, в який вони змонтовані, видаляється.

Ви все ще можете створити вручну Secret для збереження токена службового облікового запису; наприклад, якщо вам потрібен токен, який ніколи не закінчується.

Після того, як ви вручну створите Secret і звʼяжете його зі службовим обліковим записом, панель управління Kubernetes автоматично заповнює токен у цьому Secret.

Автоматичне очищення застарілих токенів ServiceAccount

До версії 1.24 Kubernetes автоматично генерував токени на основі Secret для ServiceAccount. Щоб розрізнити автоматично згенеровані токени та створені вручну, Kubernetes перевіряє посилання з поля секретів ServiceAccount. Якщо Secret згадується в полі secrets, він вважається автоматично згенерованим застарілим токеном. В іншому випадку він вважається вручну створеним застарілим токеном. Наприклад:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: build-robot
  namespace: default
secrets:
  - name: build-robot-secret # зазвичай НЕ присутній для вручну створеного токена

Починаючи з версії 1.29, застарілі токени службових облікових записів, які були згенеровані автоматично, будуть позначені як недійсні, якщо вони залишатимуться невикористаними протягом певного періоду часу (стандартно один рік). Токени, які продовжують залишатися невикористаними протягом цього визначеного періоду (знову ж таки, стандартно один рік), будуть згодом видалені панеллю управління.

Якщо користувачі використовують анульований автоматично згенерований токен, валідатор токенів:

  1. додасть анотацію аудиту для пари ключ-значення authentication.k8s.io/legacy-token-invalidated: <secret name>/<namespace>,
  2. збільшить лічильник метрики invalid_legacy_auto_token_uses_total,
  3. оновить мітку Secret kubernetes.io/legacy-token-last-used з новою датою,
  4. поверне помилку, вказуючи, що токен був анульований.

При отриманні цієї помилки валідації користувачі можуть оновити Secret, щоб видалити мітку kubernetes.io/legacy-token-invalid-since, щоб тимчасово дозволити використання цього токена.

Ось приклад автоматично згенерованого застарілого токена, який був позначений мітками kubernetes.io/legacy-token-last-used і kubernetes.io/legacy-token-invalid-since:

apiVersion: v1
kind: Secret
metadata:
  name: build-robot-secret
  namespace: default
  labels:
    kubernetes.io/legacy-token-last-used: 2022-10-24
    kubernetes.io/legacy-token-invalid-since: 2023-10-25
  annotations:
    kubernetes.io/service-account.name: build-robot
type: kubernetes.io/service-account-token

Деталі панелі управління

Контролер ServiceAccount

Контролер ServiceAccount керує ServiceAccount всередині просторів імен та забезпечує наявність ServiceAccount з іменем "default" у кожному активному просторі імен.

Контролер токенів

Контролер токенів службових облікових записів працює як частина kube-controller-manager. Цей контролер діє асинхронно. Він:

  • відстежує видалення ServiceAccount та видаляє всі відповідні Secretʼи токенів ServiceAccount.
  • відстежує додавання Secretʼу токенів ServiceAccount та забезпечує наявність відповідного ServiceAccount, додає токен до Secretʼу за потреби.
  • відстежує видалення Secretʼу та видаляє посилання з відповідного ServiceAccount за потреби.

Необхідно передати файл приватного ключа службового облікового запису контролеру токенів у kube-controller-manager, використовуючи прапорець --service-account-private-key-file. Приватний ключ використовується для підпису згенерованих токенів службових облікових записів. Аналогічно, необхідно передати відповідний публічний ключ у kube-apiserver, використовуючи прапорець --service-account-key-file. Публічний ключ буде використовуватися для перевірки токенів під час автентифікації.

Контролер допуску ServiceAccount

Зміна Podʼів здійснюється через втулок, що викликається Контролером допуску. Він є частиною сервера API. Цей контролер допуску діє синхронно для зміни Podʼів під час їх створення. Коли цей втулок активний (а він є стандартно активним у більшості дистрибутивів), то під час створення Pod він виконує наступні дії:

  1. Якщо у Pod не встановлено значення .spec.serviceAccountName, контролер допуску встановлює імʼя ServiceAccount default для цього Pod.
  2. Контролер допуску забезпечує наявність ServiceAccount, на який посилається Pod. Якщо не існує ServiceAccount з відповідним імʼям, контролер допуску відхиляє Pod. Ця перевірка застосовується навіть для default ServiceAccount.
  3. Якщо поле automountServiceAccountToken у ServiceAccount або в Podʼі не встановлено в false:
    • контролер допуску змінює Pod, додаючи додатковий том, що містить токен для доступу до API.
    • контролер допуску додає volumeMount до кожного контейнера в Podʼі, пропускаючи контейнери, які вже мають визначений шлях для монтування тому /var/run/secrets/kubernetes.io/serviceaccount. Для Linux-контейнерів цей том монтується за адресою /var/run/secrets/kubernetes.io/serviceaccount; на Windows-вузлах монтування знаходиться ну еквівалентному шляху.
  4. Якщо в специфікації Pod не містяться жодні imagePullSecrets, контролер допуску додає imagePullSecrets, копіюючи їх з ServiceAccount.

Контролер відстеження токенів застарілих ServiceAccount

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.28 [stable]

Цей контролер створює ConfigMap з назвою kube-system/kube-apiserver-legacy-service-account-token-tracking у просторі імен kube-system. ConfigMap фіксує мітку часу, коли система почала відстежувати застарілі токени службових облікових записів.

Очищувач токенів застарілих ServiceAccount

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.30 [stable]

Очищувач токенів застарілих ServiceAccount працює як частина kube-controller-manager і перевіряє кожні 24 години, чи не використовувався будь-який автоматично згенерований застарілий токен службового облікового запису протягом визначеного часу. Якщо так, очищувач позначає ці токени як недійсні.

Очищувач працює, спершу перевіряючи ConfigMap, створений панеллю управління (за умови, що LegacyServiceAccountTokenTracking увімкнено). Якщо поточний час перевищує визначений час після дати в ConfigMap, очищувач переглядає список Secretʼів у кластері та оцінює кожен Secret, що має тип kubernetes.io/service-account-token.

Якщо Secret відповідає всім наступним умовам, очищувач позначає його як недійсний:

  • Secret створено автоматично, що означає що він двонаправлено згадується ServiceAccount.
  • Secret не змонтовано жодним Podʼом.
  • Secret не використовувався протягом визначеного часу з моменту створення або останнього використання.

Очищувач позначає Secret як недійсний, додаючи мітку kubernetes.io/legacy-token-invalid-since до Secret, з поточною датою. Якщо недійсний Secret не використовується протягом визначеного часу, очищувач видаляє його.

API TokenRequest

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.22 [stable]

Ви використовуєте субресур TokenRequest з ServiceAccount, щоб отримати токен з обмеженим часом дії для цього ServiceAccount. Вам не потрібно викликати його для отримання API-токена для використання в контейнері, оскільки kubelet налаштовує це для вас, використовуючи projected том.

Якщо ви хочете використовувати API TokenRequest через kubectl, див. Ручне створення API-токена для ServiceAccount.

Панель управління Kubernetes (зокрема, контролер допуску ServiceAccount) додає projected том до Podʼів, а kubelet забезпечує, що цей том містить токен, який дозволяє контейнерам автентифікуватися як відповідний ServiceAccount.

(Цей механізм замінив попередній механізм, який додавав том на основі Secret, де Secret представляв ServiceAccount для Pod, але не мав терміну дії.)

Ось приклад того, як це виглядає для запущеного Pod:

...
  - name: kube-api-access-<random-suffix>
    projected:
      defaultMode: 420 # десятичний еквівалент вісімкового 0644
      sources:
        - serviceAccountToken:
            expirationSeconds: 3607
            path: token
        - configMap:
            items:
              - key: ca.crt
                path: ca.crt
            name: kube-root-ca.crt
        - downwardAPI:
            items:
              - fieldRef:
                  apiVersion: v1
                  fieldPath: metadata.namespace
                path: namespace

Цей фрагмент маніфесту визначає projected том, який обʼєднує інформацію з трьох джерел:

  1. Джерело serviceAccountToken, що містить токен, який kubelet отримує від kube-apiserver. Kubelet отримує токени з обмеженим часом дії, використовуючи API TokenRequest. Токен, виданий для TokenRequest, спливає або коли Pod видаляється, або через визначений термін життя (стандартно — 1 година). Токен привʼязаний до конкретного Podʼа та має kube-apiserver як свою аудиторію.
  2. Джерело configMap. ConfigMap містить пакет даних сертифікаційного центру. Podʼи можуть використовувати ці сертифікати, щоб переконатися, що вони підключаються до kube-apiserver вашого кластера (а не до проміжного блоку або випадково неправильно налаштованого колеги).
  3. Джерело downwardAPI. Цей том downwardAPI робить імʼя простору імен, що містить Pod, доступним для коду програми, що працює всередині Podʼа.

Будь-який контейнер у Podʼі, що монтує цей том, може отримати доступ до вищезазначеної інформації.

Створення додаткових API токенів

Для створення постійного API токена для ServiceAccount, створіть Secret типу kubernetes.io/service-account-token з анотацією, що посилається на ServiceAccount. Панель управління потім генерує довгостроковий токен і оновлює цей Secret з даними згенерованого токена.

Ось приклад маніфесту для такого Secret:

apiVersion: v1
kind: Secret
type: kubernetes.io/service-account-token
metadata:
  name: mysecretname
  annotations:
    kubernetes.io/service-account.name: myserviceaccount

Для створення Secret на основі цього прикладу, виконайте:

kubectl -n examplens create -f https://k8s.io/examples/secret/serviceaccount/mysecretname.yaml

Для перегляду деталей цього Secret, виконайте:

kubectl -n examplens describe secret mysecretname

Результат буде подібним до:

Name:           mysecretname
Namespace:      examplens
Labels:         <none>
Annotations:    kubernetes.io/service-account.name=myserviceaccount
                kubernetes.io/service-account.uid=8a85c4c4-8483-11e9-bc42-526af7764f64

Type:   kubernetes.io/service-account-token

Data
====
ca.crt:         1362 bytes
namespace:      9 bytes
token:          ...

Якщо ви запустите новий Pod у просторі імен examplens, він може використовувати Secret токену службового облікового запису myserviceaccount, який ви щойно створили.

Видалення/деактивація токена ServiceAccount

Якщо ви знаєте назву Secret, що містить токен, який ви хочете видалити:

kubectl delete secret name-of-secret

Інакше спочатку знайдіть Secret для ServiceAccount.

# Це передбачає, що у вас вже є простір імен 'examplens'
kubectl -n examplens get serviceaccount/example-automated-thing -o yaml

Результат буде подібним до:

apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","kind":"ServiceAccount","metadata":{"annotations":{},"name":"example-automated-thing","namespace":"examplens"}}      
  creationTimestamp: "2019-07-21T07:07:07Z"
  name: example-automated-thing
  namespace: examplens
  resourceVersion: "777"
  selfLink: /api/v1/namespaces/examplens/serviceaccounts/example-automated-thing
  uid: f23fd170-66f2-4697-b049-e1e266b7f835
secrets:
  - name: example-automated-thing-token-zyxwv

Потім видаліть Secret, назву якого ви тепер знаєте:

kubectl -n examplens delete secret/example-automated-thing-token-zyxwv

Прибирання

Якщо ви створили простір імен examplens для експериментів, ви можете його видалити:

kubectl delete namespace examplens

Що далі

6.3.11 - Сертифікати та запити на їх підписування

API для сертифікатів та наборів довіри Kubernetes дозволяють автоматизувати створення облікових даних X.509, надаючи програмний інтерфейс для клієнтів API Kubernetes для запиту та отримання X.509 сертифікатів від Центру сертифікації (CA).

Також є експериментальна (альфа) підтримка розподілу наборів довіри.

Запити на підписання сертифікатів

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.19 [stable]

Ресурс CertificateSigningRequest (CSR) використовується для запиту підписання сертифіката від вказаного підписувача, після чого запит може бути схвалений або відхилений перед остаточним підписанням.

Процес підписання запиту

Ресурс типу CertificateSigningRequest дозволяє клієнту запросити видачу сертифіката X.509 на основі запиту на підписання. Обʼєкт CertificateSigningRequest містить PEM-кодований запит на підпис у форматі PKCS#10 у полі spec.request. CertificateSigningRequest вказує підписувача (одержувача, до якого робиться запит) за допомогою поля spec.signerName. Зверніть увагу, що після версії API certificates.k8s.io/v1 ключ spec.signerName є обовʼязковим. У Kubernetes v1.22 та пізніших версіях клієнти можуть за бажанням встановити поле spec.expirationSeconds, щоб запросити певний термін дії виданого сертифіката. Мінімальне допустиме значення для цього поля — 600, тобто десять хвилин.

Після створення CertificateSigningRequest його необхідно схвалити перед підписанням. Залежно від обраного підписувача, CertificateSigningRequest може бути автоматично схвалений контролером. В іншому випадку CertificateSigningRequest слід схвалити вручну через API REST (або client-go) або за допомогою команди kubectl certificate approve. Аналогічно CertificateSigningRequest також може бути відхилений, що повідомляє налаштованому підписувачу, що він не повинен підписати запит.

Для схвалених сертифікатів наступним кроком є підписання. Відповідний контролер підпису перевіряє, чи виконуються умови підписання, а потім створює сертифікат. Після цього контролер підпису оновлює CertificateSigningRequest, зберігаючи новий сертифікат у полі status.certificate наявного обʼєкта CertificateSigningRequest. Поле status.certificate CertificateSigningRequest може бути порожнім або містити сертифікат X.509, кодований у форматі PEM. Поле status.certificate CertificateSigningRequest залишається порожнім, доки підписувач не зробить це.

Після заповнення поля status.certificate запит вважається завершеним, і клієнти тепер можуть отримати PEM-дані підписаного сертифіката з ресурсу CertificateSigningRequest. Підписувачі також можуть відхилити підпис сертифіката, якщо умови схвалення не виконані.

Для зменшення кількості застарілих ресурсів CertificateSigningRequest в кластері періодично запускається контролер збору сміття. Він видаляє CertificateSigningRequests, які не змінювали стан протягом певного періоду:

  • Схвалені запити: автоматично видаляються після 1 години
  • Відхилені запити: автоматично видаляються після 1 години
  • Невдалі запити: автоматично видаляються після 1 години
  • Запити в очікуванні: автоматично видаляються після 24 годин
  • Усі запити: автоматично видаляються після того, як видача сертифіката закінчиться після спливання часу дії

Авторизація підпису сертифікатів

Для можливості створення запиту на підпис сертифіката та отримання будь-якого запиту на підпис сертифіката:

  • Дієслова: create, get, list, watch, група: certificates.k8s.io, ресурс: certificatesigningrequests

Наприклад:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: csr-creator
rules:
- apiGroups:
  - certificates.k8s.io
  resources:
  - certificatesigningrequests
  verbs:
  - create
  - get
  - list
  - watch

Для можливості схвалення запиту на підпис сертифіката:

  • Дієслова: get, list, watch, група: certificates.k8s.io, ресурс: certificatesigningrequests
  • Дієслова: update, група: certificates.k8s.io, ресурс: certificatesigningrequests/approval
  • Дієслова: approve, група: certificates.k8s.io, ресурс: signers, resourceName: <signerNameDomain>/<signerNamePath> або <signerNameDomain>/*

Наприклад:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: csr-approver
rules:
- apiGroups:
  - certificates.k8s.io
  resources:
  - certificatesigningrequests
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - certificates.k8s.io
  resources:
  - certificatesigningrequests/approval
  verbs:
  - update
- apiGroups:
  - certificates.k8s.io
  resources:
  - signers
  resourceNames:
  - example.com/my-signer-name # example.com/* може використовуватись для авторизації всіх підписувачів в домені 'example.com'
  verbs:
  - approve

Для можливості підписання запиту на підпис сертифіката:

  • Дієслова: get, list, watch, група: certificates.k8s.io, ресурс: certificatesigningrequests
  • Дієслова: update, група: certificates.k8s.io, ресурс: certificatesigningrequests/status
  • Дієслова: sign, група: certificates.k8s.io, ресурс: signers, resourceName: <signerNameDomain>/<signerNamePath> або <signerNameDomain>/*
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: csr-signer
rules:
- apiGroups:
  - certificates.k8s.io
  resources:
  - certificatesigningrequests
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - certificates.k8s.io
  resources:
  - certificatesigningrequests/status
  verbs:
  - update
- apiGroups:
  - certificates.k8s.io
  resources:
  - signers
  resourceNames:
  - example.com/my-signer-name # example.com/* може використовуватись для авторизації всіх підписувачів в домені 'example.com'
  verbs:
  - sign

Підписувачі

Підписувачі абстрактно представляють сутність або сутності, які можуть підписувати або вже підписали сертифікат.

Будь-який підписувач, який доступний за межами конкретного кластера, повинен надавати інформацію про те, як працює підписувач, щоб споживачі могли зрозуміти, що це означає для CertificateSigningRequests та (якщо це увімкнено) ClusterTrustBundles. Це охоплює:

  1. Розподіл довіри: як розподіляються якорі довіри (CA-сертифікати або набори сертифікатів).
  2. Дозволені субʼєкти: будь-які обмеження та поведінка, коли запитано недопустимий субʼєкт.
  3. Дозволені розширення x509: включаючи IP subjectAltNames, DNS subjectAltNames, Email subjectAltNames, URI subjectAltNames тощо, та поведінка, коли запитано недопустиме розширення.
  4. Дозволені використання ключів / розширені використання ключів: будь-які обмеження та поведінка, коли використання, відмінне від використання, визначеного підписувачем, вказане в CSR.
  5. Термін дії / термін життя сертифіката: чи він фіксується підписувачем, настроюваний адміністратором, визначений полем spec.expirationSeconds CSR тощо, та поведінка, коли термін дії, визначений підписувачем, відрізняється від поля spec.expirationSeconds CSR.
  6. Дозволені / заборонені прапорці CA: та поведінка, якщо CSR містить запит на отримання сертифіката CA, коли підписувач не пропускає його.

Зазвичай поле status.certificate обʼєкта CertificateSigningRequest містить один PEM-кодований сертифікат X.509, як тільки CSR схвалено, і сертифікат видається. Деякі підписувачі зберігають кілька сертифікатів у полі status.certificate. У цьому випадку документація для підписувача повинна вказувати значення додаткових сертифікатів; наприклад, це може бути сертифікат плюс проміжні сертифікати, які представляються під час рукостискання TLS.

Якщо ви хочете зробити якір довіри (кореневий сертифікат) доступним, це слід зробити окремо від CertificateSigningRequest та його поля status.certificate. Наприклад, ви можете використовувати ClusterTrustBundle.

Формат підпису PKCS#10 не має стандартного механізму для вказання терміну дії або терміну життя сертифіката. Термін дії або термін життя має бути встановлено через поле spec.expirationSeconds обʼєкта CSR. Вбудовані підписувачі використовують параметр конфігурації ClusterSigningDuration, який стандартно становить 1 рік, (прапорець командного рядка --cluster-signing-duration kube-controller-manager) в як стандартне значення, коли не вказано spec.expirationSeconds. Коли вказано spec.expirationSeconds, використовується мінімум з spec.expirationSeconds та ClusterSigningDuration.

Підписувачі Kubernetes

Kubernetes надає вбудовані підписувачі для підпису сертифікатів, кожен з яких має широко відоме імʼя підписувача signerName:

  1. kubernetes.io/kube-apiserver-client: підписує сертифікати, які мають вважатись сертифікатами клієнтів сервером API. Ніколи автоматично не затверджуються kube-controller-manager.

    1. Розподіл довіри: підписані сертифікати мають вважатись клієнтськими сертифікатами для доступу до API-сервера. Набір ЦС не поширюється жодним іншим способом.
    2. Дозволені субʼєкти: немає обмежень для субʼєктів, однак затверджувачі та підписувачі можуть відхилити запити на затвердження та підпис. Певні субʼєкти подібні до користувачів та груп на рівні кластера є різними поміж різними дистрибутивами, що вимагає додаткових перевірок перед затвердженням та підписуванням. Втулок допуску CertificateSubjectRestrictions є стандартно увімкненим для обмеження system:masters, але в кластері є не тільки субʼєкти рівня адміністраторів кластера.
    3. Дозволені розширення x509: враховують subjectAltNames та використання ключів, відкидаючи інші розширення.
    4. Використання дозволених ключів: мають включати ["client auth"]. Не мають містити використання ключів поза ["digital signature", "key encipherment", "client auth"].
    5. Термін дії / термін життя сертифіката: для реалізації підписувача kube-controller-manager, встановлюється у мінімальне значення з --cluster-signing-duration або, якщо вказано, поля spec.expirationSeconds обʼєкта CSR.
    6. Біт ЦС дозволено / заборонено: не дозволяється.
  2. kubernetes.io/kube-apiserver-client-kubelet: підписує сертифікати, які мають вважатись сертифікатами клієнтів сервером API. Можуть бути автоматично затверджені kube-controller-manager.

    1. Розподіл довіри: підписані сертифікати мають вважатись клієнтськими сертифікатами для доступу до API-сервера. Набір ЦС не поширюється жодним іншим способом.
    2. Дозволені субʼєкти: організації є безумовно ["system:nodes"], загальні імена — "system:node:${NODE_NAME}".
    3. Дозволені розширення x509: враховують розширення з використанням ключів, забороняють розширення subjectAltNames та відкидає інші розширення.
    4. Дозволені використання ключів: ["key encipherment", "digital signature", "client auth"] або ["digital signature", "client auth"].
    5. Термін дії / термін життя сертифіката: для реалізації підписувача kube-controller-manager, встановлюється у мінімальне значення з --cluster-signing-duration або, якщо вказано, поля spec.expirationSeconds обʼєкта CSR.
    6. Біт ЦС дозволено / заборонено: не дозволяється.
  3. kubernetes.io/kubelet-serving: підписує сертифікати, які мають вважатись сертифікатами, які обслуговуються kubelet, але не мають жодних гарантій. Ніколи автоматично не затверджуються kube-controller-manager.

    1. Розподіл довіри: підписані сертифікати мають вважатись API сервером дійсними для обробки зʼєднань з kubelet. Набір ЦС не поширюється жодним іншим способом.
    2. Дозволені субʼєкти: організації є безумовно ["system:nodes"], загальні імена  — "system:node:${NODE_NAME}".
    3. Дозволені розширення x509: враховують використання ключів та розширень DNSName/IPAddress subjectAltName extensions, забороняють розширення EmailAddress та URI subjectAltName, відкидають інші розширення. Принаймні один субʼєкт DNS чи IP повинен бути у subjectAltNames.
    4. Дозволені використання ключів: ["key encipherment", "digital signature", "server auth"] або ["digital signature", "server auth"].
    5. Термін дії / термін життя сертифіката: для реалізації підписувача kube-controller-manager, встановлюється у мінімальне значення з --cluster-signing-duration або, якщо вказано, поля spec.expirationSeconds обʼєкта CSR.
    6. Біт ЦС дозволено / заборонено: не дозволяється.
  4. kubernetes.io/legacy-unknown: не має гарантій довіри взагалі. Деякі сторонні дистрибутиви Kubernetes можуть використовувати сертифікати клієнтів, підписані ним. Стабільний API CertificateSigningRequest (версії certificates.k8s.io/v1 та пізніше) не дозволяють встановлювати signerName на kubernetes.io/legacy-unknown. Ніколи автоматично не затверджується kube-controller-manager.

    1. Розподіл довіри: Немає. Для цього підписувача не існує стандартної довіри або розподілу в кластері Kubernetes.
    2. Дозволені субʼєкти: будь-які
    3. Дозволені розширення x509: враховуються subjectAltNames та використання ключів, відкидаються інші розширення.
    4. Дозволені використання ключів: будь-які
    5. Термін дії / термін життя сертифіката: для реалізації підписувача kube-controller-manager, встановлюється у мінімальне значення з --cluster-signing-duration або, якщо вказано, поля spec.expirationSeconds обʼєкта CSR.
    6. Біт ЦС дозволено / заборонено: не дозволяється.

kube-controller-manager реалізує підписування панелю управління для кожного з вбудованих підписувачів. Збої для всіх цих операцій повідомляються лише в логах kube-controller-manager.

Розподіл довіри відбувається поза рамками для цих підписувачів. Будь-яка довіра за межами описаного вище є строго випадковою. Наприклад, деякі дистрибутиви можуть приймати kubernetes.io/legacy-unknown як клієнтські сертифікати для kube-apiserver, але це не є стандартом. Жодне з цих використань не повʼязане з токенами секретів ServiceAccount .data[ca.crt]. Цей пакет CA гарантовано лише для верифікації зʼєднання з API-сервером за допомогою стандартного Service (kubernetes.default.svc).

Власні підписувачі

Ви можете ввести власних підписувачів, які матимуть схожі імена з префіксами, але такі, що вказують на ваш власний домен. Наприклад, якщо ви є представником проєкту з відкритими сирцями, який використовує доменне імʼя open-fictional.example, тоді ви можете використовувати issuer.open-fictional.example/service-mesh як імʼя підписувача.

Власний підписувач використовує API Kubernetes для випуску сертифікатів. Дивіться підписувачі на основі API для деталей.

Підписування

Підписування панеллю управління

Панель управління Kubernetes реалізує кожного з підписувачів Kubernetes як частину kube-controller-manager.

Підписувачі на основі API

Користувачі REST API можуть підписувати CSRs, надсилаючи запит UPDATE до субресурсу status CSR, який потрібно підписати.

У рамках цього запиту поле status.certificate повинно бути встановлено, щоб містити підписаний сертифікат. Це поле містить один або більше сертифікатів, закодованих у форматі PEM.

Всі PEM блоки повинні мати мітку "CERTIFICATE", не містити заголовків, а закодовані дані повинні бути структурою сертифіката BER, закодованого в ASN.1, як описано в розділі 4 RFC5280.

Приклад вмісту сертифіката:

-----BEGIN CERTIFICATE-----
MIIDgjCCAmqgAwIBAgIUC1N1EJ4Qnsd322BhDPRwmg3b/oAwDQYJKoZIhvcNAQEL
BQAwXDELMAkGA1UEBhMCeHgxCjAIBgNVBAgMAXgxCjAIBgNVBAcMAXgxCjAIBgNV
BAoMAXgxCjAIBgNVBAsMAXgxCzAJBgNVBAMMAmNhMRAwDgYJKoZIhvcNAQkBFgF4
MB4XDTIwMDcwNjIyMDcwMFoXDTI1MDcwNTIyMDcwMFowNzEVMBMGA1UEChMMc3lz
dGVtOm5vZGVzMR4wHAYDVQQDExVzeXN0ZW06bm9kZToxMjcuMC4wLjEwggEiMA0G
CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDne5X2eQ1JcLZkKvhzCR4Hxl9+ZmU3
+e1zfOywLdoQxrPi+o4hVsUH3q0y52BMa7u1yehHDRSaq9u62cmi5ekgXhXHzGmm
kmW5n0itRECv3SFsSm2DSghRKf0mm6iTYHWDHzUXKdm9lPPWoSOxoR5oqOsm3JEh
Q7Et13wrvTJqBMJo1GTwQuF+HYOku0NF/DLqbZIcpI08yQKyrBgYz2uO51/oNp8a
sTCsV4OUfyHhx2BBLUo4g4SptHFySTBwlpRWBnSjZPOhmN74JcpTLB4J5f4iEeA7
2QytZfADckG4wVkhH3C2EJUmRtFIBVirwDn39GXkSGlnvnMgF3uLZ6zNAgMBAAGj
YTBfMA4GA1UdDwEB/wQEAwIFoDATBgNVHSUEDDAKBggrBgEFBQcDAjAMBgNVHRMB
Af8EAjAAMB0GA1UdDgQWBBTREl2hW54lkQBDeVCcd2f2VSlB1DALBgNVHREEBDAC
ggAwDQYJKoZIhvcNAQELBQADggEBABpZjuIKTq8pCaX8dMEGPWtAykgLsTcD2jYr
L0/TCrqmuaaliUa42jQTt2OVsVP/L8ofFunj/KjpQU0bvKJPLMRKtmxbhXuQCQi1
qCRkp8o93mHvEz3mTUN+D1cfQ2fpsBENLnpS0F4G/JyY2Vrh19/X8+mImMEK5eOy
o0BMby7byUj98WmcUvNCiXbC6F45QTmkwEhMqWns0JZQY+/XeDhEcg+lJvz9Eyo2
aGgPsye1o3DpyXnyfJWAWMhOz7cikS5X2adesbgI86PhEHBXPIJ1v13ZdfCExmdd
M1fLPhLyR54fGaY+7/X8P9AZzPefAkwizeXwe9ii6/a08vWoiE4=
-----END CERTIFICATE-----

Не-PEM вміст може зʼявлятися до або після блоків CERTIFICATE PEM і не перевіряється, щоб дозволити пояснювальний текст, як описано в розділі 5.2 RFC7468.

При кодуванні в JSON або YAML це поле закодоване в base-64. Запит на підпис сертифіката (CertificateSigningRequest), що містить приклад сертифіката вище, виглядатиме так:

apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
...
status:
  certificate: "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JS..."

Схвалення або відхилення

Перед тим, як підписувач видасть сертифікат на основі запиту на підписання сертифіката (CertificateSigningRequest), підписувач зазвичай перевіряє, що видача для цього CSR була схвалена.

Автоматичне схвалення панелі управління

kube-controller-manager поставляється з вбудованим схвалювачем для сертифікатів з іменем підписувача kubernetes.io/kube-apiserver-client-kubelet, який делегує різні дозволи на CSRs для облікових даних вузлів до авторизації. kube-controller-manager надсилає ресурси SubjectAccessReview до API-сервера для перевірки авторизації на схвалення сертифіката.

Схвалення або відхилення за допомогою kubectl

Адміністратор Kubernetes (з відповідними дозволами) може вручну схвалювати (або відхиляти) запити на підписання сертифікатів (CertificateSigningRequests) за допомогою команд kubectl certificate approve та kubectl certificate deny.

Щоб схвалити CSR за допомогою kubectl:

kubectl certificate approve <certificate-signing-request-name>

Аналогічно, щоб відхилити CSR:

kubectl certificate deny <certificate-signing-request-name>

Схвалення або відхилення за допомогою API Kubernetes

Користувачі REST API можуть схвалювати CSRs, надсилаючи запит UPDATE до субресурсу approval CSR, який потрібно схвалити. Наприклад, ви можете написати оператор, який слідкує за певним видом CSR, а потім надсилає UPDATE для їх схвалення.

Коли ви робите запит на схвалення або відхилення, встановіть або умову статусу Approved, або Denied залежно від визначеного стану:

Для схвалених CSR:

apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
...
status:
  conditions:
  - lastUpdateTime: "2020-02-08T11:37:35Z"
    lastTransitionTime: "2020-02-08T11:37:35Z"
    message: Approved by my custom approver controller
    reason: ApprovedByMyPolicy # Ви можете вказати тут будь-який рядок
    type: Approved

Для відхилених CSR:

apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
...
status:
  conditions:
  - lastUpdateTime: "2020-02-08T11:37:35Z"
    lastTransitionTime: "2020-02-08T11:37:35Z"
    message: Denied by my custom approver controller
    reason: DeniedByMyPolicy # Ви можете вказати тут будь-який рядок
    type: Denied

Зазвичай встановлюється в поле status.conditions.reason код причини, зручний для машинного зчитування, використовуючи TitleCase; це є умовністю, але ви можете встановити тут будь-яке значення. Якщо ви хочете додати примітку для читання людьми, використовуйте поле status.conditions.message.

Пакети довіри кластера

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.27 [alpha]

ClusterTrustBundles — це обʼєкт масштабу кластера для розподілу якорів довіри X.509 (кореневих сертифікатів) до робочих навантажень у кластері. Вони розроблені для гарної роботи з концепцією підписувача із запитів на підписання сертифікатів (CertificateSigningRequests).

ClusterTrustBundles можна використовувати у двох режимах: звʼязаний з підписувачем та незвʼязаний з підписувачем.

Загальні властивості та валідація

Усі обʼєкти ClusterTrustBundle мають сувору валідацію вмісту їхнього поля trustBundle. Це поле повинно містити один або більше сертифікатів X.509, серіалізованих у DER, кожен з яких обгорнутий у блок PEM CERTIFICATE. Сертифікати повинні аналізуватися як дійсні сертифікати X.509.

Езотеричні функції PEM, такі як дані між блоками та заголовки всередині блоків, або відхиляються під час валідації обʼєкта, або можуть ігноруватися споживачами обʼєкта. Крім того, споживачі можуть перевпорядковувати сертифікати в пакеті за своїм власним довільним, але стабільним порядком.

Обʼєкти ClusterTrustBundle слід вважати загальнодоступними в межах кластера. Якщо ваш кластер використовує авторизацію RBAC, усі ServiceAccounts стандартно мають дозволи get, list та watch для всіх обʼєктів ClusterTrustBundle. Якщо ви використовуєте власний механізм авторизації та ввімкнули ClusterTrustBundles у своєму кластері, вам слід налаштувати еквівалентне правило для того, щоб ці обʼєкти були загальнодоступними в межах кластера, щоб вони працювали належним чином.

Якщо ви не маєте стандартного дозволу для отримання переліку пакетів довіри кластера у вашому кластері, ви можете діяти від імені службового облікового запису, до якого у вас є доступ, щоб побачити доступні ClusterTrustBundles:

kubectl get clustertrustbundles --as='system:serviceaccount:mynamespace:default'

ClusterTrustBundles, звʼязані з підписувачем

ClusterTrustBundles, звʼязані з підписувачем, асоціюються з імʼям підписувача, як тут:

apiVersion: certificates.k8s.io/v1alpha1
kind: ClusterTrustBundle
metadata:
  name: example.com:mysigner:foo
spec:
  signerName: example.com/mysigner
  trustBundle: "<... PEM data ...>"

ClusterTrustBundles призначені для підтримки контролера, специфічного для підписувача в кластері, тому вони мають кілька функцій безпеки:

  • Щоб створити або оновити ClusterTrustBundle, звʼязаний з підписувачем, ви повинні мати дозвіл підтвердити підписувача (спеціальне дієслово авторизації attest, група API certificates.k8s.io; шлях ресурсу signers). Ви можете налаштувати авторизацію для конкретного імені ресурсу <signerNameDomain>/<signerNamePath> або відповідати шаблону, наприклад <signerNameDomain>/*.
  • ClusterTrustBundles, звʼязані з підписувачем, повинні бути названі з префіксом, отриманим з їхнього поля spec.signerName. Слеші (/) замінюються на двокрапки (:), а в кінці додається двокрапка. За цим слідує довільне імʼя. Наприклад, підписувач example.com/mysigner може бути звʼязаний з ClusterTrustBundle example.com:mysigner:<arbitrary-name>.

ClusterTrustBundles, звʼязані з підписувачем, зазвичай використовуються у робочих навантаженнях за допомогою комбінації селектора полів за іменем підписувача та окремого селектора міток.

ClusterTrustBundles, незвʼязані з підписувачем

ClusterTrustBundles, незвʼязані з підписувачем, мають порожнє поле spec.signerName, як це:

apiVersion: certificates.k8s.io/v1alpha1
kind: ClusterTrustBundle
metadata:
  name: foo
spec:
  # signerName не вказано, тому поле порожнє
  trustBundle: "<... PEM data ...>"

Вони призначені головним чином для випадків використання конфігурації кластера. Кожен ClusterTrustBundle, незвʼязаний з підписувачем, є незалежним обʼєктом, на відміну від звичайної групової поведінки ClusterTrustBundles, звʼязаних з підписувачем.

ClusterTrustBundles, незвʼязані з підписувачем, не мають вимоги щодо дієслова attest. Натомість, ви контролюєте доступ до них безпосередньо за допомогою звичайних механізмів, таких як контроль доступу на основі ролей.

Щоб відрізнити їх від ClusterTrustBundles, звʼязаних з підписувачем, назви ClusterTrustBundles, незвʼязаних з підписувачем, не повинні містити двокрапку (:).

Доступ до ClusterTrustBundles з Podʼів

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.29 [alpha]

Вміст ClusterTrustBundles може бути впроваджений у файлову систему контейнера, подібно до ConfigMaps та Secrets. Дивіться джерело projected томів clusterTrustBundle для отримання додаткової інформації.

Як видати сертифікат для користувача

Для того, щоб звичайний користувач міг автентифікуватися та викликати API, потрібно виконати кілька кроків. Спершу цей користувач повинен мати сертифікат, виданий кластером Kubernetes, а потім надати цей сертифікат API Kubernetes.

Створення приватного ключа

Наступні скрипти показують, як згенерувати приватний ключ PKI та CSR. Важливо встановити значення CN та O атрибута CSR. CN — це імʼя користувача, а O — це група, до якої належатиме цей користувач. Ви можете звернутися до RBAC по стандартні групи.

openssl genrsa -out myuser.key 2048
openssl req -new -key myuser.key -out myuser.csr -subj "/CN=myuser"

Створення запиту на підписання сертифікату

Створіть запит на підписання сертифікату (CertificateSigningRequest) і подайте його до кластера Kubernetes через kubectl. Нижче наведено скрипт для CertificateSigningRequest.

cat <<EOF | kubectl apply -f -
apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: myuser
spec:
  request: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURSBSRVFVRVNULS0tLS0KTUlJQ1ZqQ0NBVDRDQVFBd0VURVBNQTBHQTFVRUF3d0dZVzVuWld4aE1JSUJJakFOQmdrcWhraUc5dzBCQVFFRgpBQU9DQVE4QU1JSUJDZ0tDQVFFQTByczhJTHRHdTYxakx2dHhWTTJSVlRWMDNHWlJTWWw0dWluVWo4RElaWjBOCnR2MUZtRVFSd3VoaUZsOFEzcWl0Qm0wMUFSMkNJVXBGd2ZzSjZ4MXF3ckJzVkhZbGlBNVhwRVpZM3ExcGswSDQKM3Z3aGJlK1o2MVNrVHF5SVBYUUwrTWM5T1Nsbm0xb0R2N0NtSkZNMUlMRVI3QTVGZnZKOEdFRjJ6dHBoaUlFMwpub1dtdHNZb3JuT2wzc2lHQ2ZGZzR4Zmd4eW8ybmlneFNVekl1bXNnVm9PM2ttT0x1RVF6cXpkakJ3TFJXbWlECklmMXBMWnoyalVnald4UkhCM1gyWnVVV1d1T09PZnpXM01LaE8ybHEvZi9DdS8wYk83c0x0MCt3U2ZMSU91TFcKcW90blZtRmxMMytqTy82WDNDKzBERHk5aUtwbXJjVDBnWGZLemE1dHJRSURBUUFCb0FBd0RRWUpLb1pJaHZjTgpBUUVMQlFBRGdnRUJBR05WdmVIOGR4ZzNvK21VeVRkbmFjVmQ1N24zSkExdnZEU1JWREkyQTZ1eXN3ZFp1L1BVCkkwZXpZWFV0RVNnSk1IRmQycVVNMjNuNVJsSXJ3R0xuUXFISUh5VStWWHhsdnZsRnpNOVpEWllSTmU3QlJvYXgKQVlEdUI5STZXT3FYbkFvczFqRmxNUG5NbFpqdU5kSGxpT1BjTU1oNndLaTZzZFhpVStHYTJ2RUVLY01jSVUyRgpvU2djUWdMYTk0aEpacGk3ZnNMdm1OQUxoT045UHdNMGM1dVJVejV4T0dGMUtCbWRSeEgvbUNOS2JKYjFRQm1HCkkwYitEUEdaTktXTU0xMzhIQXdoV0tkNjVoVHdYOWl4V3ZHMkh4TG1WQzg0L1BHT0tWQW9FNkpsYWFHdTlQVmkKdjlOSjVaZlZrcXdCd0hKbzZXdk9xVlA3SVFjZmg3d0drWm89Ci0tLS0tRU5EIENFUlRJRklDQVRFIFJFUVVFU1QtLS0tLQo=
  signerName: kubernetes.io/kube-apiserver-client
  expirationSeconds: 86400  # один день
  usages:
  - client auth
EOF

Декілька моментів, на які варто звернути увагу:

  • usages має бути 'client auth'.
  • expirationSeconds можна зробити довшим (наприклад, 864000 для десяти днів) або коротшим (наприклад, 3600 для однієї години).
  • request — це base64-кодоване значення вмісту файлу CSR. Ви можете отримати цей вміст за допомогою такої команди:
cat myuser.csr | base64 | tr -d "\n"

Схвалення CertificateSigningRequest

Використовуйте kubectl, щоб створити CSR та схвалити його.

Отримайте список CSR:

kubectl get csr

Схваліть CSR:

kubectl certificate approve myuser

Отримання сертифіката

Отримайте сертифікат з CSR:

kubectl get csr/myuser -o yaml

Значення сертифіката знаходиться в форматі Base64-кодування в status.certificate.

Експортуйте виданий сертифікат з CertificateSigningRequest.

kubectl get csr myuser -o jsonpath='{.status.certificate}'| base64 -d > myuser.crt

Створення Role та RoleBinding

Зі створеним сертифікатом, час визначити Role та RoleBinding для цього користувача для доступу до ресурсів кластера Kubernetes.

Ось приклад команди для створення Role для цього нового користувача:

kubectl create role developer --verb=create --verb=get --verb=list --verb=update --verb=delete --resource=pods

Ось приклад команди для створення RoleBinding для цього нового користувача:

kubectl create rolebinding developer-binding-myuser --role=developer --user=myuser

Додавання до kubeconfig

Останній крок — додати цього користувача до файлу kubeconfig.

Спершу, вам потрібно додати нові облікові дані:

kubectl config set-credentials myuser --client-key=myuser.key --client-certificate=myuser.crt --embed-certs=true

Потім, вам потрібно додати контекст:

kubectl config set-context myuser --cluster=kubernetes --user=myuser

Для перевірки, змініть контекст на myuser:

kubectl config use-context myuser

Що далі

6.3.12 - Зіставлення PodSecurityPolicies зі стандартами безпеки Podʼів

Нижче наведено таблиці, що перераховують параметри конфігурації обʼєктів PodSecurityPolicy, чи поле змінює або перевіряє контейнери, та як значення конфігурації зіставляються з Стандартами безпеки Podʼів.

Для кожного параметра, до якого це застосовується, перераховані допустимі значення для Baseline та Restricted профілів. Все, що перебуває за межами допустимих значень для цих профілів, підпадає під Privileged профіль. "Немає думки" означає, що всі значення допустимі для всіх стандартів безпеки Podʼів.

Для покрокового керівництва міграції див. Міграція з PodSecurityPolicy до вбудованого контролера допуску PodSecurity.

Специфікація PodSecurityPolicy

Поля, перераховані в цій таблиці, є частиною PodSecurityPolicySpec, яка вказана в шляху поля .spec.

Зіставлення політики безпеки PodSecurityPolicySpec зі стандартами безпеки Podʼів
PodSecurityPolicySpecТипЕквівалент стандартів безпеки Podʼів
privilegedПеревіркаBaseline & Restricted: false / undefined / nil
defaultAddCapabilitiesЗміна & ПеревіркаВимоги відповідають allowedCapabilities нижче.
allowedCapabilitiesПеревірка

Baseline: підмножина

  • AUDIT_WRITE
  • CHOWN
  • DAC_OVERRIDE
  • FOWNER
  • FSETID
  • KILL
  • MKNOD
  • NET_BIND_SERVICE
  • SETFCAP
  • SETGID
  • SETPCAP
  • SETUID
  • SYS_CHROOT

Обмежений: пустий / undefined / nil АБО список, що містить тільки NET_BIND_SERVICE

requiredDropCapabilitiesЗміна & Перевірка

Baseline: немає думки

Baseline: повинен містити ALL

volumesПеревірка

Baseline: будь-що крім

  • hostPath
  • *

Restricted: підмножина

  • configMap
  • csi
  • downwardAPI
  • emptyDir
  • ephemeral
  • persistentVolumeClaim
  • projected
  • secret
hostNetworkПеревіркаBaseline & Restricted: false / undefined / nil
hostPortsПеревіркаBaseline & Restricted: undefined / nil / пустий
hostPIDПеревіркаBaseline & Restricted: false / undefined / nil
hostIPCПеревіркаBaseline & Restricted: false / undefined / nil
seLinuxЗміна & Перевірка

Baseline & Restricted: seLinux.rule is MustRunAs, з наступними options

  • user не встановлено ("" / undefined / nil)
  • role не встановлено ("" / undefined / nil)
  • type не встановлено або один із: container_t, container_init_t, container_kvm_t, container_engine_t
  • level є будь-чим
runAsUserЗміна & Перевірка

Baseline: Будь-що

Restricted: rule є MustRunAsNonRoot

runAsGroupЗміна (MustRunAs) & ПеревіркаНемає думки
supplementalGroupsЗміна & ПеревіркаНемає думки
fsGroupЗміна & ПеревіркаНемає думки
readOnlyRootFilesystemЗміна & ПеревіркаНемає думки
defaultAllowPrivilegeEscalationЗмінаНемає думки
allowPrivilegeEscalationЗміна & Перевірка

Лише зміна, якщо встановлено false

Baseline: Немає думки

Restricted: false

allowedHostPathsПеревіркаНемає думки (пріоритет мають volumes)
allowedFlexVolumesПеревіркаНемає думки (пріоритет мають volumes)
allowedCSIDriversПеревіркаНемає думки (пріоритет мають volumes)
allowedUnsafeSysctlsПеревіркаBaseline & Restricted: undefined / nil / empty
forbiddenSysctlsПеревіркаНемає думки
allowedProcMountTypes
(альфа-функція)
ПеревіркаBaseline & Restricted: ["Default"] АБО undefined / nil / empty
runtimeClass
 .defaultRuntimeClassName
ЗмінаНемає думки
runtimeClass
 .allowedRuntimeClassNames
ПеревіркаНемає думки

Анотації PodSecurityPolicy

Анотації, перераховані в цій таблиці, можуть бути вказані у .metadata.annotations обʼєкту PodSecurityPolicy.

Зіставлення анотацій PodSecurityPolicy зі стандартами безпеки Podʼів
Анотація PSPТипЕквівалент стандартів безпеки Podʼів
seccomp.security.alpha.kubernetes.io
/defaultProfileName
ЗмінаНемає думки
seccomp.security.alpha.kubernetes.io
/allowedProfileNames
Перевірка

Baseline: "runtime/default," (Кома в кінці, щоб встановити unset)

Restricted: "runtime/default" (Без коми в кінці)

Значення localhost/* також дозволені як для Baseline, так і для Restricted.

apparmor.security.beta.kubernetes.io
/defaultProfileName
ЗмінаНемає думки
apparmor.security.beta.kubernetes.io
/allowedProfileNames
Перевірка

Baseline: "runtime/default," (Кома в кінці, щоб встановити unset)

Restricted: "runtime/default" (Без коми в кінці)

Значення localhost/* також дозволені як для Baseline, так і для Restricted.

6.3.13 - Автентифікація/авторизація kubelet

Огляд

HTTP-запити до HTTPS-точки доступу kubelet надають доступ до даних різного рівня чутливості та дозволяють виконувати операції з різними рівнями повноважень на вузлі та в контейнерах.

У цьому документі описано, як автентифікувати та авторизувати доступ до HTTPS-точки доступу kubelet.

Автентифікація kubelet

Стандартно запити до HTTPS-точки доступу kubelet, які не відхилені іншими налаштованими методами автентифікації, розглядаються як анонімні запити та отримують імʼя користувача system:anonymous та групу system:unauthenticated.

Щоб вимкнути анонімний доступ та надсилати відповіді 401 Unauthorized на невідомі запити:

  • запустіть kubelet з прапорцем --anonymous-auth=false

Щоб увімкнути автентифікацію за допомогою клієнтських сертифікатів X509 до HTTPS-точки доступу kubelet:

  • запустіть kubelet з прапорцем --client-ca-file, надаючи набір кореневих сертифікатів для перевірки клієнтських сертифікатів
  • запустіть apiserver з прапорцями --kubelet-client-certificate та --kubelet-client-key
  • див. документацію з автентифікації apiserver для отримання додаткових відомостей

Щоб увімкнути використання API-токенів на предʼявника (включаючи токени службових облікових записів) для автентифікації до HTTPS-точки доступу kubelet:

  • переконайтеся, що група API authentication.k8s.io/v1beta1 ввімкнена в apiserver
  • запустіть kubelet з прапорцями --authentication-token-webhook та --kubeconfig
  • kubelet викликає API TokenReview на налаштованому apiserver, щоб визначити інформацію про користувача з токенів на предʼявника

Авторизація kubelet

Будь-який запит, який успішно автентифікується (включаючи анонімний запит), потім авторизується. Стандартний режим авторизації — AlwaysAllow, який дозволяє всі запити.

Є багато можливих причин для розподілу доступу до API kubelet:

  • ввімкнено анонімну автентифікацію, але потрібно обмежити можливості анонімних користувачів викликати API kubelet
  • ввімкнено автентифікацію з використанням токенів на предʼявника, але потрібно обмежити можливості довільних користувачів API (наприклад, службові облікові записи) викликати API kubelet
  • ввімкнено автентифікацію за допомогою клієнтських сертифікатів, але дозволено використовувати API kubelet тільки деяким сертифікатам клієнтів, які підписані налаштованим кореневим сертифікатом

Щоб розділити доступ до API kubelet, делегуйте авторизацію apiserver:

  • переконайтеся, що група API authorization.k8s.io/v1beta1 ввімкнена в apiserver
  • запустіть kubelet з прапорцями --authorization-mode=Webhook та --kubeconfig
  • kubelet викликає API SubjectAccessReview на налаштованому apiserver, щоб визначити, чи авторизований кожний запит

Kubelet авторизує запити до API, використовуючи той самий підхід до атрибутів запиту, що й apiserver.

Дієслово визначається з HTTP-дії вхідного запиту:

HTTP-діяДієслово запиту
POSTcreate
GET, HEADget
PUTupdate
PATCHpatch
DELETEdelete

Ресурс та субресурс визначаються з шляху вхідного запиту:

Kubelet APIРесурсСубресурс
/stats/*nodesstats
/metrics/*nodesmetrics
/logs/*nodeslog
/spec/*nodesspec
всі іншіnodesproxy

Атрибути простору імен та групи API завжди є порожніми рядками, а імʼя ресурсу завжди є імʼям обʼєкта Node kubelet.

При використанні цього режиму переконайтеся, що користувач, визначений прапорцями --kubelet-client-certificate та --kubelet-client-key, переданими до apiserver, має дозвіл наступних атрибутів:

  • verb=*, resource=nodes, subresource=proxy
  • verb=*, resource=nodes, subresource=stats
  • verb=*, resource=nodes, subresource=log
  • verb=*, resource=nodes, subresource=spec
  • verb=*, resource=nodes, subresource=metrics

6.3.14 - Початкове завантаження TLS

У кластері Kubernetes компоненти на вузлах робочих навантажень, kubelet та kube-proxy, повинні взаємодіяти з компонентами панелі управління Kubernetes, зокрема з kube-apiserver. Для забезпечення приватності комунікації, її невтручання та переконання, що кожен компонент кластера спілкується з іншим довіреним компонентом, ми наполегливо рекомендуємо використовувати TLS-сертифікати клієнтів на вузлах.

Звичайний процес ініціалізації цих компонентів, особливо робочих вузлів, які потребують сертифікати для безпечної комунікації з kube-apiserver, може бути складним, оскільки він часто виходить за межі Kubernetes і вимагає значної додаткової роботи. Це, своєю чергою, може ускладнити ініціалізацію або масштабування кластера.

З метою спрощення процесу, починаючи з версії 1.4, Kubernetes ввів API запиту та підпису сертифікатів. Пропозицію можна знайти тут.

У цьому документі описано процес ініціалізації вузла, спосіб налаштування початкового завантаження TLS-сертифікатів клієнтів для kubelet та його роботу.

Процес ініціалізації

Коли робочий вузол запускається, kubelet виконує наступне:

  1. Шукає свій файл kubeconfig.
  2. Отримує URL-адресу сервера API та облікові дані, зазвичай ключ TLS та підписаний сертифікат з файлу kubeconfig.
  3. Намагається спілкуватися з сервером API, використовуючи облікові дані.

Припускаючи, що kube-apiserver успішно перевіряє облікові дані kubelet, він буде вважати kubelet дійсним вузлом та почне призначати для нього Podʼи.

Зауважте, що вищевказаний процес залежить від:

  • Існування ключа та сертифіката на локальному хості у kubeconfig.
  • Підписання сертифіката центром сертифікації (CA), якому довіряє kube-apiserver.

Всі перелічені нижче обовʼязки покладаються на того, хто налаштовує та керує кластером:

  1. Створення ключа та сертифіката CA.
  2. Розповсюдження сертифіката CA на вузли панелі управління, де запущений kube-apiserver.
  3. Створення ключа та сертифіката для кожного kubelet; наполегливо рекомендується мати унікальний ключ з унікальним CN для кожного kubelet.
  4. Підписання сертифіката kubelet за допомогою ключа CA.
  5. Розповсюдження ключа та підписаного сертифіката kubelet на конкретний вузол, на якому працює kubelet.

Початкове завантаження TLS, описане у цьому документі, призначене спростити та частково або повністю автоматизувати кроки з 3 по 14, оскільки вони є найбільш поширеними при ініціалізації або масштабуванні кластера.

Ініціалізація початкового завантаження

Під час процесу ініціалізації початкового завантаження відбувається наступне:

  1. kubelet починає роботу.
  2. kubelet бачить, що у нього немає файлу kubeconfig.
  3. kubelet шукає та знаходить файл bootstrap-kubeconfig.
  4. kubelet читає свій файл ініціалізації початкового завантаження, отримуючи URL-адресу сервера API та обмежений "токен".
  5. kubelet підключається до сервера API, автентифікується за допомогою токена.
  6. у kubelet тепер є обмежені облікові дані для створення та отримання запиту на підпис сертифіката (CSR).
  7. kubelet створює CSR для себе з встановленим signerName kubernetes.io/kube-apiserver-client-kubelet.
  8. CSR затверджується одним з двох способів:
    • Якщо налаштовано, kube-controller-manager автоматично затверджує CSR.
    • Якщо налаштовано, зовнішній процес, можливо, людина, затверджує CSR за допомогою API Kubernetes або через kubectl.
  9. Сертифікат створюється для kubelet.
  10. Сертифікат видано для kubelet.
  11. kubelet отримує сертифікат.
  12. kubelet створює належний kubeconfig з ключем та підписаним сертифікатом.
  13. kubelet починає нормальну роботу.
  14. Опціонально: якщо налаштовано, kubelet автоматично запитує поновлення сертифіката, коли той наближається до закінчення строку дії.
  15. Поновлений сертифікат затверджується та видається, або автоматично, або вручну, залежно від налаштувань.

Усі інші розділи цього документу описують необхідні кроки для налаштування початкового завантаження TLS та його обмежень.

Налаштування

Для налаштування початкового завантаження TLS та опціонального автоматичного затвердження потрібно налаштувати параметри на наступних компонентах:

  • kube-apiserver
  • kube-controller-manager
  • kubelet
  • ресурси в кластері: ClusterRoleBinding та, можливо, ClusterRole

Крім того, вам потрібен ваш центр сертифікації Kubernetes (CA).

Центр сертифікації

Як і без початкового завантаження, вам знадобиться ключ та сертифікат центру сертифікації (CA). Як і раніше, вони будуть використовуватися для підпису сертифіката kubelet. Як і раніше, ваша відповідальність полягає в їх розповсюджені на вузли панелі управління.

Для цілей цього документу ми припускаємо, що вони розповсюджені на вузли панелі управління за шляхом /var/lib/kubernetes/ca.pem (сертифікат) та /var/lib/kubernetes/ca-key.pem (ключ). Ми будемо посилатися на них як "сертифікат та ключ CA Kubernetes".

Всі компоненти Kubernetes, які використовують ці сертифікати — kubelet, kube-apiserver, kube-controller-manager — припускають, що ключ та сертифікат закодовані у PEM-форматі.

Налаштування kube-apiserver

У kube-apiserver є кілька вимог для активації початкового завантаження TLS:

  • Визнання CA, який підписує сертифікат клієнта
  • Автентифікація початкового завантаження kubelet у групу system:bootstrappers
  • Авторизація початкового завантаження kubelet для створення запиту на підпис сертифіката (CSR)

Визнання сертифікатів клієнтів

Це є нормою для всієї автентифікації сертифікатів клієнтів. Якщо це ще не налаштовано, додайте прапорець --client-ca-file=ФАЙЛ до команди kube-apiserver, щоб активувати автентифікацію за сертифікатом клієнта, посилаючись на пакет сертифікатів центру сертифікації, наприклад --client-ca-file=/var/lib/kubernetes/ca.pem.

Початкова автентифікація початкового завантаження

Для того, щоб процес початкового завантаження kubelet міг підʼєднатися до kube-apiserver та запросити сертифікат, спочатку йому потрібно автентифікуватися на сервері. Ви можете використовувати будь-який автентифікатор, який може автентифікувати kubelet.

Хоча будь-яка стратегія автентифікації може бути використана для початкових облікових даних kubelet, рекомендується використовувати наступні два автентифікатори для полегшення надання прав.

  1. Токени початкового завантаження
  2. Файл автентифікації токенів

Використання токенів початкового завантаження є простішим та зручнішим способом автентифікації kubelet і не вимагає додаткових прапорів при запуску kube-apiserver.

Який би метод ви не обрали, вимога полягає в тому, щоб kubelet міг автентифікуватися як користувач з правами на:

  1. створення та отримання CSRs
  2. автоматичне затвердження запиту клієнтських сертифікатів вузлів, якщо увімкнено автоматичне затвердження.

Kubelet, який автентифікується за допомогою початкових токенів, автентифікується як користувач у групі system:bootstrappers, що є стандартним методом використання.

Оскільки ця функція вдосконалюється, вам слід переконатися, що токени привʼязані до політики управління доступом на основі ролей (RBAC), яка обмежує запити (використовуючи початковий токен) виключно клієнтськими запитами, повʼязаними з наданням сертифікатів. З RBAC можна гнучко налаштовувати обмеження для токенів за групами. Наприклад, ви можете вимкнути доступ певної початкової групи після завершення розгортання вузлів.

Токени початкового завантаження

Токени початкового завантаження докладно описані тут. Це токени, які зберігаються як секрети в кластері Kubernetes і потім видаються окремим kubelet. Ви можете використовувати один токен для всього кластера або видавати по одному на кожен робочий вузол.

Процес складається з двох етапів:

  1. Створити Secret Kubernetes з ідентифікатором токена, секретом і областю(ями).
  2. Видати токен kubelet.

З погляду kubelet, один токен такий самий, як інший і не має особливого значення. З погляду kube-apiserver, однак, початковий токен є особливим. Завдяки його type, namespace і name, kube-apiserver розпізнає його як спеціальний токен і надає будь-кому, хто автентифікується з цим токеном, особливі права початкового завантаження, зокрема, розглядаючи їх як члена групи system:bootstrappers. Це виконує основну вимогу для початкового завантаження TLS.

Деталі щодо створення секрету доступні тут.

Якщо ви хочете використовувати токени початкового завантаження, ви повинні увімкнути їх на kube-apiserver з прапорцем:

--enable-bootstrap-token-auth=true

Файл автентифікації токенів

kube-apiserver має можливість приймати токени для автентифікації. Ці токени можуть бути довільними, але повинні представляти щонайменше 128 біт ентропії, отриманих з надійного генератора випадкових чисел (наприклад, /dev/urandom у більшості сучасних Linux-систем). Є кілька способів генерації токена. Наприклад:

head -c 16 /dev/urandom | od -An -t x | tr -d ' '

Це згенерує токени, які виглядають так: 02b50b05283e98dd0fd71db496ef01e8.

Файл токенів повинен виглядати як у наступному прикладі, де перші три значення можуть бути будь-якими, а імʼя групи в лапках повинно бути таким, як показано:

02b50b05283e98dd0fd71db496ef01e8,kubelet-bootstrap,10001,"system:bootstrappers"

Додайте прапорець --token-auth-file=FILENAME до команди kube-apiserver (можливо, у вашому файлі systemd), щоб увімкнути файл токенів. Докладніше дивіться тут.

Авторизація kubelet на створення CSR

Тепер, коли вузол початкового завантаження автентифікований як частина групи system:bootstrappers, його потрібно авторизувати на створення запиту на підпис сертифіката (CSR), а також на його отримання після завершення. На щастя, Kubernetes постачається з ClusterRole, який має саме ці (і тільки ці) дозволи, system:node-bootstrapper.

Щоб зробити це, потрібно лише створити ClusterRoleBinding, що звʼязує групу system:bootstrappers з кластерною роллю system:node-bootstrapper.

# увімкнення створення CSR для вузлів початкового завантаження
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: create-csrs-for-bootstrapping
subjects:
- kind: Group
  name: system:bootstrappers
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: system:node-bootstrapper
  apiGroup: rbac.authorization.k8s.io

Налаштування kube-controller-manager

Поки apiserver отримує запити на сертифікати від kubelet і автентифікує ці запити, controller-manager відповідає за видачу фактичних підписаних сертифікатів.

Controller-manager виконує цю функцію через цикл управління видачею сертифікатів. Це реалізується у вигляді локального підписувача cfssl, який використовує активи на диску. Зараз всі видані сертифікати стандартно мають один рік дійсності та набір ключів для використання.

Для того, щоб controller-manager міг підписувати сертифікати, йому потрібно наступне:

  • доступ до "ключа та сертифіката Kubernetes CA", який ви створили та розповсюдили
  • увімкнення підписування CSR

Доступ до ключа та сертифіката

Як описано раніше, вам потрібно створити ключ і сертифікат Kubernetes CA і розповсюдити їх на вузли панелі управління. Ці сертифікати будуть використовуватися controller-manager для підписування сертифікатів kubelet.

Оскільки ці підписані сертифікати, своєю чергою, будуть використовуватися kubelet для автентифікації як звичайного kubelet до kube-apiserver, важливо, щоб CA, наданий controller-manager на цьому етапі, також був довірений kube-apiserver для автентифікації. Це надається kube-apiserver за допомогою прапорця --client-ca-file=FILENAME (наприклад, --client-ca-file=/var/lib/kubernetes/ca.pem), як описано в розділі конфігурації kube-apiserver.

Щоб надати ключ і сертифікат Kubernetes CA для kube-controller-manager, використовуйте наступні прапорці:

--cluster-signing-cert-file="/etc/path/to/kubernetes/ca/ca.crt" --cluster-signing-key-file="/etc/path/to/kubernetes/ca/ca.key"

Наприклад:

--cluster-signing-cert-file="/var/lib/kubernetes/ca.pem" --cluster-signing-key-file="/var/lib/kubernetes/ca-key.pem"

Тривалість дійсності підписаних сертифікатів можна налаштувати за допомогою прапорця:

--cluster-signing-duration

Затвердження

Щоб затвердити CSR, потрібно вказати controller-manager, що їх можна затверджувати. Це робиться шляхом надання прав доступу RBAC потрібній групі.

Існують два різні набори дозволів:

  • nodeclient: Якщо вузол створює новий сертифікат для вузла, тоді у нього ще немає сертифіката. Він автентифікується за допомогою одного з токенів, зазначених вище, і таким чином є частиною групи system:bootstrappers.
  • selfnodeclient: Якщо вузол оновлює свій сертифікат, тоді у нього вже є сертифікат (за визначенням), який він використовує для автентифікації як частина групи system:nodes.

Щоб дозволити kubelet запитувати та отримувати новий сертифікат, створіть ClusterRoleBinding, що звʼязує групу, в якій є членом вузол початкового завантаження, system:bootstrappers, з ClusterRole, що надає їй дозвіл, system:certificates.k8s.io:certificatesigningrequests:nodeclient:

# Затвердження всіх CSR для групи "system:bootstrappers"
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: auto-approve-csrs-for-group
subjects:
- kind: Group
  name: system:bootstrappers
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: system:certificates.k8s.io:certificatesigningrequests:nodeclient
  apiGroup: rbac.authorization.k8s.io

Щоб дозволити kubelet оновлювати власний клієнтський сертифікат, створіть ClusterRoleBinding, що звʼязує групу, в якій є членом повнофункціональний вузол, system:nodes, з ClusterRole, що надає їй дозвіл, system:certificates.k8s.io:certificatesigningrequests:selfnodeclient:

# Затвердження запитів на оновлення CSR для групи "system:nodes"
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: auto-approve-renewals-for-nodes
subjects:
- kind: Group
  name: system:nodes
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: system:certificates.k8s.io:certificatesigningrequests:selfnodeclient
  apiGroup: rbac.authorization.k8s.io

Контролер csrapproving, який постачається як частина kube-controller-manager, стандартно увімкнено. Контролер використовує API SubjectAccessReview для визначення, чи авторизований користувач для запиту CSR, а потім затверджує на основі результатів авторизації. Щоб уникнути конфліктів з іншими затверджувачами, вбудований затверджувач не відхиляє CSR явним чином. Він лише ігнорує неавторизовані запити. Контролер також видаляє прострочені сертифікати в рамках збору сміття.

Налаштування kubelet

Нарешті, з правильно налаштованими вузлами панелі управління та всією необхідною автентифікацією та авторизацією, ми можемо налаштувати kubelet.

Для початкового завантаження kubelet потрібна наступна конфігурація:

  • Шлях для зберігання ключа та сертифіката, які він генерує (опціонально, можна використовувати стандартні)
  • Шлях до файлу kubeconfig, який ще не існує; тут буде збережено конфігураційний файл після початкового завантаження
  • Шлях до початкового файлу kubeconfig, що містить URL сервера та початкові облікові дані, наприклад, початковий токен
  • Опціонально: інструкції щодо ротації сертифікатів

Початковий файл kubeconfig має бути в шляху, доступному для kubelet, наприклад /var/lib/kubelet/bootstrap-kubeconfig.

Його формат ідентичний звичайному файлу kubeconfig. Приклад файлу може виглядати наступним чином:

apiVersion: v1
kind: Config
clusters:
- cluster:
    certificate-authority: /var/lib/kubernetes/ca.pem
    server: https://my.server.example.com:6443
  name: bootstrap
contexts:
- context:
    cluster: bootstrap
    user: kubelet-bootstrap
  name: bootstrap
current-context: bootstrap
preferences: {}
users:
- name: kubelet-bootstrap
  user:
    token: 07401b.f395accd246ae52d

Важливі елементи:

  • certificate-authority: шлях до файлу CA, використовується для перевірки сертифіката сервера, представленого kube-apiserver
  • server: URL до kube-apiserver
  • token: токен для використання

Формат токена не має значення, головне, щоб він відповідав очікуванням kube-apiserver. У наведеному прикладі ми використали початковий токен. Як зазначалося раніше, будь-який дійсний метод автентифікації може бути використаний, а не тільки токени.

Оскільки початковий kubeconfig є стандартним kubeconfig, ви можете використовувати kubectl для його створення. Щоб створити вищезазначений приклад файлу:

kubectl config --kubeconfig=/var/lib/kubelet/bootstrap-kubeconfig set-cluster bootstrap --server='https://my.server.example.com:6443' --certificate-authority=/var/lib/kubernetes/ca.pem
kubectl config --kubeconfig=/var/lib/kubelet/bootstrap-kubeconfig set-credentials kubelet-bootstrap --token=07401b.f395accd246ae52d
kubectl config --kubeconfig=/var/lib/kubelet/bootstrap-kubeconfig set-context bootstrap --user=kubelet-bootstrap --cluster=bootstrap
kubectl config --kubeconfig=/var/lib/kubelet/bootstrap-kubeconfig use-context bootstrap

Щоб вказати kubelet використовувати початковий kubeconfig, використовуйте наступний прапорець:

--bootstrap-kubeconfig="/var/lib/kubelet/bootstrap-kubeconfig" --kubeconfig="/var/lib/kubelet/kubeconfig"

Під час запуску kubelet, якщо файл, вказаний через --kubeconfig, не існує, початковий kubeconfig, вказаний через --bootstrap-kubeconfig, використовується для запиту клієнтського сертифіката від API сервера. Після затвердження запиту на сертифікат і його отримання kubelet, конфігураційний файл kubeconfig, що посилається на згенерований ключ і отриманий сертифікат, буде записаний у шлях, вказаний за допомогою --kubeconfig. Файл сертифіката і ключа буде розміщено в теці, вказаній прапорцем --cert-dir.

Клієнтські та серверні сертифікати

Все вищезазначене стосується клієнтських сертифікатів kubelet, зокрема сертифікатів, які kubelet використовує для автентифікації до kube-apiserver.

kubelet також може використовувати серверні сертифікати. Сам kubelet відкриває https-точку доступу для певних функцій. Для їх захисту, kubelet може робити одне з наступного:

  • використовувати наданий ключ та сертифікат через прапорці --tls-private-key-file та --tls-cert-file
  • створити самопідписаний ключ та сертифікат, якщо ключ та сертифікат не надані
  • запитати серверні сертифікати у сервера кластера через API CSR

Клієнтський сертифікат, наданий під час початкового завантаження TLS, стандартно підписується лише для client auth і, отже, не може використовуватися як серверний сертифікат, або server auth.

Однак, ви можете увімкнути його серверний сертифікат, принаймні частково, через ротацію сертифікатів.

Ротація сертифікатів

З версії Kubernetes v1.8 та вище kubelet реалізує функції для увімкнення ротації його клієнтських і/або серверних сертифікатів. Зверніть увагу, що ротація серверного сертифіката є бета функцією та потребує функціональної можливості RotateKubeletServerCertificate на kubelet (стандартно увімкнено).

Ви можете налаштувати kubelet для ротації його клієнтських сертифікатів, створюючи нові CSRs при закінченні терміну дії його поточних облікових даних. Щоб увімкнути цю функцію, використовуйте поле rotateCertificates у файлі конфігурації kubelet або передайте наступний аргумент командного рядка kubelet (застаріло):

--rotate-certificates

Увімкнення RotateKubeletServerCertificate призводить до того, що kubelet одночасно запитує серверний сертифікат після початкового завантаження своїх клієнтських облікових даних і ротує цей сертифікат. Щоб увімкнути цю поведінку, використовуйте поле serverTLSBootstrap у файлі конфігурації kubelet або передайте наступний аргумент командного рядка kubelet (застаріло):

--rotate-server-certificates

Інші складові автентифікації

Усі процеси завантаження TLS, описані у цьому документі, стосуються kubelet. Однак інші компоненти можуть потребувати прямого звʼязку з kube-apiserver. Особливо важливим є kube-proxy, який є частиною компонентів вузла Kubernetes і запускається на кожному вузлі, але може також включати інші компоненти, такі як моніторинг чи роботу з мережею.

Подібно до kubelet, цим іншим компонентам також потрібен метод автентифікації у kube-apiserver. У вас є кілька варіантів для генерації цих облікових даних:

  • Традиційний спосіб: Створіть і розповсюдьте сертифікати так само як ви це робили для kubelet перед завантаженням TLS.
  • DaemonSet: Оскільки сам kubelet завантажується на кожний вузол і достатньо для запуску базових служб, ви можете запускати kube-proxy та інші служби, специфічні для вузла, не як самостійний процес, а як daemonset у просторі імен kube-system. Оскільки він буде в кластері, ви можете надати йому відповідний службовий обліковий запис з відповідними дозволами для виконання своїх дій. Це може бути найпростішим способом налаштування таких служб.

Затвердження за допомогою kubectl

Запити на сертифікати можна затвердити поза процесом затвердження, вбудованим у контролер керування.

Контролер підпису не негайно підписує всі запити на сертифікати. Замість цього він чекає, доки вони не будуть позначені статусом "Approved" відповіднbv привілейованим користувачем. Цей процес призначений для того, щоб дозволити автоматичне затвердження, яке обробляється зовнішнім контролером затвердження або controller-manager, реалізованим в основному controller-manager. Однак адміністратори кластера також можуть вручну затверджувати запити на сертифікати за допомогою kubectl. Адміністратор може отримати перелік CSRs за допомогою kubectl get csr та детально описати один з них за допомогою kubectl describe csr <name>. Адміністратор може затвердити або відхилити CSR за допомогою kubectl certificate approve <name> та kubectl certificate deny <name>.

6.3.15 - Правила перевірки допуску

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.30 [stable]

Ця сторінка надає огляд правил перевірки допуску.

Що таке правила перевірки допуску?

Правила перевірки допуску пропонують декларативну, вбудовану альтернативу веб-хукам перевірки допуску.

Правила перевірки допуску використовують мову загальних виразів (Common Expression Language, CEL). Правила перевірки допуску мають високу налаштовуваність, що дозволяє авторам визначати правила, які можуть бути параметризовані та обмежені ресурсами за необхідності адміністраторами кластера.

Які ресурси складають правила

Зазвичай правило складається з трьох ресурсів:

  • ValidatingAdmissionPolicy описує абстрактну логіку правил (наприклад: "ці праивла переконуються, що певна мітка встановлена у певне значення").

  • ValidatingAdmissionPolicyBinding повʼязує вищезазначені ресурси разом і надає обмеження області дії. Якщо вам потрібно вимагати встановлення мітки owner для Pods, привʼязка визначає, де ви будете вказувати це обмеження.

  • Ресурс параметра надає інформацію для ValidatingAdmissionPolicy, щоб зробити його конкретним висловленням (наприклад, "мітка owner повинна бути встановлена на щось, що закінчується на .company.com"). Вбудований тип, такий як ConfigMap або CRD, визначає схему ресурсу параметра. Обʼєкти ValidatingAdmissionPolicy вказують, який Kind вони очікують для свого ресурсу параметру.

Для того щоб правила мали ефект, обовʼязково повинні бути визначені принаймні ValidatingAdmissionPolicy та відповідне ValidatingAdmissionPolicyBinding.

Якщо ValidatingAdmissionPolicy не потребує налаштування через параметри, просто залиште spec.paramKind в ValidatingAdmissionPolicy не вказаним.

Початок роботи з правилами перевірки допуску

Правила перевірки допуску є частиною панелі управління кластера. Ви повинні писати та розгортати їх з великою обережністю. Нижче наведено інструкції щодо швидкого експерименту з правилами перевірки допуску.

Створення ValidatingAdmissionPolicy

Нижче наведено приклад ValidatingAdmissionPolicy.

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: "demo-policy.example.com"
spec:
  failurePolicy: Fail
  matchConstraints:
    resourceRules:
    - apiGroups:   ["apps"]
      apiVersions: ["v1"]
      operations:  ["CREATE", "UPDATE"]
      resources:   ["deployments"]
  validations:
    - expression: "object.spec.replicas <= 5"

spec.validations містить вирази CEL, які використовують Мову загальних виразів (CEL), щоб перевірити запит. Якщо вираз обчислюється як false, перевірка валідації застосовується згідно з полем spec.failurePolicy.

Для налаштування правил перевірки допуску для використання в кластері потрібна привʼязка. Нижче наведено приклад ValidatingAdmissionPolicyBinding.:

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicyBinding
metadata:
  name: "demo-binding-test.example.com"
spec:
  policyName: "demo-policy.example.com"
  validationActions: [Deny]
  matchResources:
    namespaceSelector:
      matchLabels:
        environment: test

Спробувавши створити Deployment з репліками, які не відповідають виразу валідації, буде повернута помилка з повідомленням:

ValidatingAdmissionPolicy 'demo-policy.example.com' with binding 'demo-binding-test.example.com' denied request: failed expression: object.spec.replicas <= 5

Вище наведено простий приклад використання ValidatingAdmissionPolicy без налаштованого параметра.

Дії валідації

Кожний ValidatingAdmissionPolicyBinding повинен вказати одну або декілька validationActions, щоб визначити, як validations правила будуть застосовані.

Підтримувані validationActions:

  • Deny: Невдалий результат валідації призводить до відхиленого запиту.
  • Warn: Невдалий результат валідації повідомляється клієнту запиту як попередження.
  • Audit: Невдалий результат валідації включається в подію аудиту для запиту до API.

Наприклад, щоб одночасно попереджувати клієнтів про невдалий результат валідації та аудитувати невдалий результат валідації, використовуйте:

validationActions: [Warn, Audit]

Deny та Warn не можуть бути використані разом, оскільки ця комбінація надмірно дублює невдалий результат валідації як у тілі відповіді API, так і в HTTP заголовках попередження.

validation, який оцінюється як false, завжди застосовується відповідно до цих дій. Невдачі, визначені полем failurePolicy, застосовуються відповідно до цих дій тільки у випадку, якщо failurePolicy встановлено на Fail (або не вказано), інакше невдачі ігноруються.

Див. Анотації аудиту: невдалий результат валідації для отримання додаткових відомостей щодо аудиту невдалих результатів валідації.

Ресурси параметрів

Ресурси параметрів дозволяють відокремити конфігурацію правил від їх визначення. Правило може визначити paramKind, який визначає GVK ресурсу параметра, а потім привʼязка правила повʼязує його за іменем (через policyName) з певним ресурсом параметра через paramRef.

Якщо потрібна конфігурація параметра, наведено приклад ValidatingAdmissionPolicy з конфігурацією параметра.

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: "replicalimit-policy.example.com"
spec:
  failurePolicy: Fail
  paramKind:
    apiVersion: rules.example.com/v1
    kind: ReplicaLimit
  matchConstraints:
    resourceRules:
    - apiGroups:   ["apps"]
      apiVersions: ["v1"]
      operations:  ["CREATE", "UPDATE"]
      resources:   ["deployments"]
  validations:
    - expression: "object.spec.replicas <= params.maxReplicas"
      reason: Invalid

Поле spec.paramKind ValidatingAdmissionPolicy вказує на вид використовуваних ресурсів для параметризації цього правила. У цьому прикладі це налаштовано за допомогою ресурсів ReplicaLimit. Зверніть увагу в цьому прикладі, як вираз CEL посилається на параметри через змінну CEL params, наприклад, params.maxReplicas. spec.matchConstraints вказує, для яких ресурсів ця правило призначена для валідації. Зверніть увагу, що як параметр можуть використовуватися і стандартні типи, такі як ConfigMap.

Поля spec.validations містять вирази CEL. Якщо вираз оцінюється як false, то валідаційна перевірка здійснюється відповідно до поля spec.failurePolicy.

Автор правил перевірки допуску відповідає за надання параметра CRD ReplicaLimit.

Для налаштування правил перевірки допуску для використання в кластері створюються привʼязка та ресурс параметра. Наведено приклад ValidatingAdmissionPolicyBinding який використовує кластерний параметр — той самий параметр буде використовуватися для валідації кожного запиту до ресурсу, який відповідає привʼязці:

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicyBinding
metadata:
  name: "replicalimit-binding-test.example.com"
spec:
  policyName: "replicalimit-policy.example.com"
  validationActions: [Deny]
  paramRef:
    name: "replica-limit-test.example.com"
    namespace: "default"
  matchResources:
    namespaceSelector:
      matchLabels:
        environment: test

Зверніть увагу, що ця привʼязка застосовує параметр до правил для всіх ресурсів, які знаходяться в середовищі test.

Ресурс параметра може мати наступний вигляд:

apiVersion: rules.example.com/v1
kind: ReplicaLimit
metadata:
  name: "replica-limit-test.example.com"
  namespace: "default"
maxReplicas: 3

Цей ресурс параметра правил обмежує Deployments до максимуму 3 репліки.

В правилі допуску може бути кілька привʼязок. Щоб привʼязати всі інші середовища до обмеження maxReplicas 100, створіть інший ValidatingAdmissionPolicyBinding:

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicyBinding
metadata:
  name: "replicalimit-binding-nontest"
spec:
  policyName: "replicalimit-policy.example.com"
  validationActions: [Deny]
  paramRef:
    name: "replica-limit-prod.example.com"
    namespace: "default"
  matchResources:
    namespaceSelector:
      matchExpressions:
      - key: environment
        operator: NotIn
        values:
        - test

Зверніть увагу, що ця привʼязка застосовує різний параметр до ресурсів, які не знаходяться в середовищі test.

Та має ресурс параметра:

apiVersion: rules.example.com/v1
kind: ReplicaLimit
metadata:
  name: "replica-limit-prod.example.com"
maxReplicas: 100

Для кожного запиту на допуск, сервер API оцінює вирази CEL кожної комбінації (правило, привʼязка, параметр), які відповідають запиту. Для того, щоб запит був прийнятий, він повинен пройти всі оцінки.

Якщо кілька привʼязок відповідають запиту, правило буде оцінено для кожної, і вони всі повинні пройти оцінку, щоб правило вважали пройденим.

Якщо кілька параметрів відповідають одній привʼязці, правила будуть оцінені для кожного параметра, і вони також повинні всі пройти, щоб привʼязка вважалася пройденою. Привʼязки можуть мати критерії відповідності, що перекриваються. Правило оцінюється для кожної відповідної комбінації привʼязка-параметр. Правило може бути оцінено навіть кілька разів, якщо йому відповідає кілька привʼязок, або одна привʼязка, яка відповідає кільком параметрам.

Обʼєкт params, який представляє ресурс параметра, не буде встановлений, якщо ресурс параметра не був привʼязаний, тому для правил, які потребують ресурсу параметра, може бути корисно додати перевірку, щоб забезпечити його привʼязку. Ресурс параметра не буде привʼязаний і params буде null, якщо paramKind правила або paramRef привʼязки не вказані.

Для випадків використання, що потребують конфігурації параметра, ми рекомендуємо додати перевірку параметра в spec.validations[0].expression:

- expression: "params != null"
  message: "params missing but required to bind to this policy"

Необовʼязкові параметри

Буває зручно мати можливість мати необовʼязкові параметри як частину ресурсу параметра і валідувати їх лише в разі їх присутності. У CEL є has(), який перевіряє, чи існує переданий ключ. Крім того, CEL реалізує булеве скорочення. Якщо перша половина логічного ОБО відноситься до true, то друга половина не оцінюється (оскільки результат усього ОБО буде true в будь-якому випадку).

Поєднуючи ці дві можливості, ми можемо забезпечити можливість валідації необовʼязкових параметрів:

!has(params.optionalNumber) || (params.optionalNumber >= 5 && params.optionalNumber <= 10)

Тут спочатку ми перевіряємо, що необовʼязковий параметр присутній за допомогою !has(params.optionalNumber).

  • Якщо optionalNumber не був визначений, то вираз скорочується, оскільки !has(params.optionalNumber) оцінюється як true.
  • Якщо optionalNumber був визначений, тоді друга половина CEL виразу буде оцінена, і optionalNumber буде перевірений, щоб забезпечити, що він містить значення від 5 до 10 включно.

Параметри на рівні простору імен

Як автор ValidatingAdmissionPolicy та його ValidatingAdmissionPolicyBinding, ви можете вибрати, чи вказувати параметри на рівні кластера або на рівні простору імен. Якщо ви вказуєте namespace для paramRef привʼязки, панель управління шукає параметри лише в цьому просторі імен.

Проте, якщо namespace не вказано в ValidatingAdmissionPolicyBinding, сервер API може шукати відповідні параметри в просторі імен, до якого відноситься запит. Наприклад, якщо ви робите запит на зміну ConfigMap у просторі імен default, і існує відповідна ValidatingAdmissionPolicyBinding без вказаного namespace, то сервер API шукає обʼєкт параметра в default. Цей дизайн дозволяє конфігурувати правило, що залежить від простору імен ресурсу, який обробляється, для отримання більш точного контролю.

Селектор параметрів

Крім вказання параметра у привʼязці за допомогою name, ви можете вибрати замість цього вказати селектор міток, таким чином, всі ресурси paramKind правила та namespace параметра (якщо застосовується), які відповідають селектору міток, вибираються для оцінки. Див. селектор для отримання додаткової інформації про те, як селектори міток відбирають ресурси.

Якщо умову виконується для декількох параметрів, правила оцінюються для кожного знайденого параметра, а результати будуть оцінені разом через логічне І (AND).

Якщо надано namespace, для вибору допускаються лише обʼєкти paramKind у вказаному просторі імен. В іншому випадку, коли namespace порожній, а paramKind обмежений простором імен, використовується namespace, використаний у запиті для допуску.

Перевірка авторизації

Ми ввели перевірку авторизації для ресурсів параметрів. Очікується, що користувач матиме доступ на читання до ресурсів, на які посилається paramKind у ValidatingAdmissionPolicy та paramRef у ValidatingAdmissionPolicyBinding.

Зверніть увагу, що якщо ресурс у paramKind не вдасться знайти через restmapper, потрібен доступ на читання до всіх ресурсів груп.

Правило помилок

failurePolicy визначає, як обробляються неправильні конфігурації та вирази CEL, що викликають помилку в правилах перевірки допуску. Допустимі значення: Ignore або Fail.

  • Ignore означає, що помилка під час виклику ValidatingAdmissionPolicy ігнорується, і запит API може продовжуватися.
  • Fail означає, що помилка під час виклику ValidatingAdmissionPolicy призводить до відмови в прийнятті та відхилення запиту API.

Зверніть увагу, що failurePolicy визначається всередині ValidatingAdmissionPolicy:

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
spec:
...
failurePolicy: Ignore # стандартно "Fail"
validations:
- expression: "object.spec.xyz == params.x"  

Вирази валідації

spec.validations[i].expression представляє вираз, який буде оцінений за допомогою CEL. Для отримання додаткової інформації див. Специфікацію мови CEL. Вирази CEL мають доступ до вмісту запиту/відповіді допуску, організованого в змінні CEL, а також деяких інших корисних змінних:

  • 'object' — Обʼєкт з вхідного запиту. Значення null для запитів DELETE.
  • 'oldObject' — Наявний обʼєкт. Значення null для запитів CREATE.
  • 'request' — Атрибути запиту допуску.
  • 'params' — Ресурс параметра, на який посилається привʼязка правила, яке оцінюється. Значення null, якщо ParamKind не вказано.
  • namespaceObject — Простір імен, як ресурс Kubernetes, до якого належить вхідний обʼєкт. Значення null, якщо вхідний обʼєкт має область видимості кластера.
  • authorizer — Авторизатор CEL. Може використовуватися для виконання перевірок авторизації для принципала (автентифікованого користувача) запиту. Див. AuthzSelectors та Authz в документації бібліотеки Kubernetes CEL для отримання додаткових відомостей.
  • authorizer.requestResource — Скорочення для перевірки авторизації, налаштоване з ресурсом запиту (група, ресурс, (субресурс), простір імен, імʼя).

apiVersion, kind, metadata.name і metadata.generateName завжди доступні з кореня обʼєкта. Інші властивості метаданих не доступні.

Рівність у масивах із типом списку 'set' або 'map' ігнорує порядок елементів, тобто [1, 2] == [2, 1]. Конкатенація у масивах з x-kubernetes-list-type використовує семантику типу списку:

  • 'set': X + Y виконує обʼєднання, де позиції масиву всіх елементів в X зберігаються, а неперетинаючися елементи в Y додаються, зберігаючи їх частковий порядок.
  • 'map': X + Y виконує злиття, де позиції масиву всіх ключів в X зберігаються, але значення перезаписуються значеннями в Y, коли множини ключів X і Y перетинаються. Елементи в Y з неперетинаючимися ключами додаються, зберігаючи їх частковий порядок.

Приклади виразів валідації

ВиразПризначення
object.minReplicas <= object.replicas && object.replicas <= object.maxReplicasПеревірка правильного порядку трьох полів, що визначають репліки
'Available' in object.stateCountsПеревірка наявності запису з ключем 'Available' в map
(size(object.list1) == 0) != (size(object.list2) == 0)Перевірка, що один із двох списків не порожній, але не обидва
!('MY_KEY' in object.map1) || object['MY_KEY'].matches('^[a-zA-Z]*$')Перевірка значення map для певного ключа, якщо він є в map
object.envars.filter(e, e.name == 'MY_ENV').all(e, e.value.matches('^[a-zA-Z]*$')Перевірка поля 'value' запису у listMap, де значення ключа 'name' - 'MY_ENV'
has(object.expired) && object.created + object.ttl < object.expiredПеревірка, що дата 'expired' пізніше дати 'create' плюс тривалість 'ttl'
object.health.startsWith('ok')Перевірка, що рядок 'health' починається з префікса 'ok'
object.widgets.exists(w, w.key == 'x' && w.foo < 10)Перевірка, що поле 'foo' запису у listMap з ключем 'x' менше 10
type(object) == string ? object == '100%' : object == 1000Перевірка поля типу int або string на значення int та string
object.metadata.name.startsWith(object.prefix)Перевірка, що імʼя обʼєкта має префікс значення іншого поля
object.set1.all(e, !(e in object.set2))Перевірка, що два listSet не перетинаються
size(object.names) == size(object.details) && object.names.all(n, n in object.details)Перевірка, що map 'details' має ключі, визначені елементами списку 'names'
size(object.clusters.filter(c, c.name == object.primary)) == 1Перевірка, що властивість 'primary' має лише один випадок в listMap 'clusters'

Для отримання додаткової інформації щодо правил CEL прочитайте Supported evaluation on CEL.

spec.validation[i].reason представляє машинночитаний опис причини невдачі цієї валідації. Якщо це перша валідація в списку, яка завершується невдачею, ця причина, а також відповідний код відповіді HTTP використовуються у відповіді HTTP клієнту. Підтримувані зараз причини: Unauthorized, Forbidden, Invalid, RequestEntityTooLarge. Якщо не встановлено, StatusReasonInvalid використовується у відповіді клієнту.

Відповідність запитів: matchConditions

Ви можете визначити умови відповідності для ValidatingAdmissionPolicy, якщо вам потрібно дотримуватися детального фільтрування запитів. Ці умови корисні, якщо ви виявите, що правила відповідності, objectSelectors та namespaceSelectors все ще не забезпечують потрібного фільтрування. Умови відповідності — це вирази CEL. Усі умови відповідності повинні оцінюватися як true для ресурсу, який має бути оцінений.

Нижче наведено приклад, що ілюструє кілька різних використань умов відповідності:

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: "demo-policy.example.com"
spec:
  failurePolicy: Fail
  matchConstraints:
    resourceRules:
      - apiGroups:   ["*"]
        apiVersions: ["*"]
        operations:  ["CREATE", "UPDATE"]
        resources:   ["*"]
  matchConditions:
    - name: 'exclude-leases' # Імʼя кожної умови має бути унікальним
      expression: '!(request.resource.group == "coordination.k8s.io" && request.resource.resource == "leases")' # Шукати збіг із запитами non-lease.
    - name: 'exclude-kubelet-requests'
      expression: '!("system:nodes" in request.userInfo.groups)' # Шукати збіг із запитами від користувачів, які не є користувачами вузла.
    - name: 'rbac' # Оминати запити RBAC.
      expression: 'request.resource.group != "rbac.authorization.k8s.io"'
  validations:
    - expression: "!object.metadata.name.contains('demo') || object.metadata.namespace == 'demo'"

Умови відповідності мають доступ до тих самих змінних CEL, що й вирази валідації.

У випадку помилки при оцінці умови відповідності правило не оцінюється. Рішення про відхилення запиту визначається наступним чином:

  1. Якщо будь-яка умова відповідності оцінюється як false (незалежно від інших помилок), сервер API пропускає політику.
  2. В іншому випадку:
    • для failurePolicy: Fail, відхилити запит (без оцінки правил).
    • для failurePolicy: Ignore, продовжити з запитом, але пропустити політику.

Анотації аудиту

auditAnnotations можна використовувати для включення анотацій аудиту в аудит-подію запиту API.

Наприклад, ось правила допуску з анотацією аудиту:

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: "demo-policy.example.com"
spec:
  failurePolicy: Fail
  matchConstraints:
    resourceRules:
    - apiGroups:   ["apps"]
      apiVersions: ["v1"]
      operations:  ["CREATE", "UPDATE"]
      resources:   ["deployments"]
  validations:
    - key: "high-replica-count"
      expression: "object.spec.replicas > 50"
      messageExpression: "'Deployment spec.replicas set to ' + string(object.spec.replicas)"

Коли запит API перевіряється за цим правилом допуску, отримана подія аудиту буде виглядати так:

# Записана подія аудиту
{
    "kind": "Event",
    "apiVersion": "audit.k8s.io/v1",
    "annotations": {
        "demo-policy.example.com/high-replica-count": "Deployment spec.replicas set to 128"
        # інші анотації
        ...
    }
    # інші поля
    ...
}

У цьому прикладі анотація буде включена лише тоді, коли spec.replicas у Deployment більше 50, в іншому випадку вираз CEL оцінюється як null, і анотація не буде включена.

Зверніть увагу, що ключі анотацій аудиту мають префікс з імʼям ValidatingAdmissionWebhook та /. Якщо інший контролер допуску, такий як вебхук допуску, використовує точно такий самий ключ анотації аудиту, то значення першого контролера допуску, який включає анотацію аудиту, буде включено в аудит-подію, а всі інші значення будуть ігноруватися.

Вираз повідомлення

Щоб повертати більш дружнє повідомлення, коли правило відхиляє запит, ми можемо використовувати вираз CEL для створення повідомлення з spec.validations[i].messageExpression. Подібно до виразу валідації, вираз повідомлення має доступ до object, oldObject, request, params та namespaceObject. На відміну від валідації, вираз повідомлення має повертати рядок.

Наприклад, щоб краще інформувати користувача про причину відхилення, коли правило посилається на параметр, ми можемо мати наступну валідацію:

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: "deploy-replica-policy.example.com"
spec:
  paramKind:
    apiVersion: rules.example.com/v1
    kind: ReplicaLimit
  matchConstraints:
    resourceRules:
    - apiGroups:   ["apps"]
      apiVersions: ["v1"]
      operations:  ["CREATE", "UPDATE"]
      resources:   ["deployments"]
  validations:
  - expression: "object.spec.replicas <= params.maxReplicas"
    messageExpression: "'object.spec.replicas must be no greater than ' + string(params.maxReplicas)"
    reason: Invalid

Після створення обʼєкту параметрів, який обмежує репліки до 3 та налаштування привʼязки, коли ми спробуємо створити Deployment з 5 репліками, ми отримаємо наступне повідомлення.

$ kubectl create deploy --image=nginx nginx --replicas=5
error: failed to create deployment: deployments.apps "nginx" is forbidden: ValidatingAdmissionPolicy 'deploy-replica-policy.example.com' with binding 'demo-binding-test.example.com' denied request: object.spec.replicas must be no greater than 3

Це більш інформативно, ніж статичне повідомлення "занадто багато реплік".

Вираз повідомлення має перевагу над статичним повідомленням, визначеним у spec.validations[i].message, якщо обидва визначені. Однак, якщо вираз повідомлення не вдається оцінити, буде використано статичне повідомлення. Крім того, якщо вираз повідомлення оцінюється як багаторядковий рядок, результат оцінки буде відкинутий, і використовуватиметься статичне повідомлення, якщо воно присутнє. Зауважте, що статичне повідомлення перевіряється на відповідність багаторядковим рядкам.

Перевірка типів

Під час створення або оновлення визначення правил валідації процес валідації аналізує вирази, які він містить, та повідомляє про будь-які синтаксичні помилки, відхиляючи визначення, якщо виявлено помилки. Потім перевіряються змінні, на які є посилання, на наявність помилок типів, включаючи відсутні поля та плутанину типів, відносно відповідних типів spec.matchConstraints. Результат перевірки типів можна отримати з status.typeChecking. Наявність status.typeChecking вказує на завершення перевірки типів, а порожнє status.typeChecking означає, що помилок не виявлено.

Наприклад, з наступним визначенням правил:

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: "deploy-replica-policy.example.com"
spec:
  matchConstraints:
    resourceRules:
    - apiGroups:   ["apps"]
      apiVersions: ["v1"]
      operations:  ["CREATE", "UPDATE"]
      resources:   ["deployments"]
  validations:
  - expression: "object.replicas > 1" # має бути "object.spec.replicas > 1"
    message: "must be replicated"
    reason: Invalid

Статус надасть таку інформацію:

status:
  typeChecking:
    expressionWarnings:
    - fieldRef: spec.validations[0].expression
      warning: |-
        apps/v1, Kind=Deployment: ERROR: <input>:1:7: undefined field 'replicas'
         | object.replicas > 1
         | ......^        

Якщо в spec.matchConstraints збігається кілька ресурсів, всі ресурси, які мають збіг, будуть перевірені. Наприклад, наступне визначення правил:

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: "replica-policy.example.com"
spec:
  matchConstraints:
    resourceRules:
    - apiGroups:   ["apps"]
      apiVersions: ["v1"]
      operations:  ["CREATE", "UPDATE"]
      resources:   ["deployments","replicasets"]
  validations:
  - expression: "object.replicas > 1" # має бути "object.spec.replicas > 1"
    message: "must be replicated"
    reason: Invalid

буде мати декілька типів та результат перевірки типів кожного типу у повідомленні про попередження.

status:
  typeChecking:
    expressionWarnings:
    - fieldRef: spec.validations[0].expression
      warning: |-
        apps/v1, Kind=Deployment: ERROR: <input>:1:7: undefined field 'replicas'
         | object.replicas > 1
         | ......^
        apps/v1, Kind=ReplicaSet: ERROR: <input>:1:7: undefined field 'replicas'
         | object.replicas > 1
         | ......^        

Перевірка типів має такі обмеження:

  • Відсутнє зіставлення за шаблоном. Якщо spec.matchConstraints.resourceRules містить "*" у будь-якому з apiGroups, apiVersions або resources, типи, які відповідають "*", не будуть перевірені.
  • Кількість збігів типів обмежена до 10. Це робиться для запобігання використанню правил, що вручну вказує занадто багато типів, що може споживати занадто багато обчислювальних ресурсів. Порядок спадання групи, версії, а потім ресурсу, 11-а комбінація та після буде ігноруватися.
  • Перевірка типів не впливає на поведінку правил жодним чином. Навіть якщо під час перевірки типів виявляються помилки, політика буде продовжувати оцінюватися. Якщо під час оцінки виникають помилки, політика вибере свій результат.
  • Перевірка типів не застосовується до CRD, включаючи відповідні типи CRD та посилання на paramKind. Підтримка CRD зʼявиться у майбутній версії.

Склад змінних

Якщо вираз стає занадто складним або частина виразу повторно використовується та має високі обчислювальні витрати, ви можете винести частину виразів у змінні. Змінна — це вираз з назвою, на який можна посилатися пізніше в variables в інших виразах.

spec:
  variables:
    - name: foo
      expression: "'foo' in object.spec.metadata.labels ? object.spec.metadata.labels['foo'] : 'default'"
  validations:
    - expression: variables.foo == 'bar'

Змінна оцінюється ліниво (lazily), під час першого посилання на неї. Про будь-яку помилку, що виникає під час оцінки, буде повідомлено під час оцінки вказаного виразу, на який посилається змінна. Як результат, так і можлива помилка запамʼятовуються і лише один раз враховуються при оцінці під час виконання.

Порядок змінних важливий, оскільки змінна може посилатися на інші змінні, які визначені перед нею. Це упорядкування запобігає циклічним посиланням.

Наведено більш складний приклад змінних, що забезпечує відповідність імен репозиторіїв образів середовищу, визначеному у просторі імен.

# Це правило забезпечує виконання умови, що всі контейнери deployment повинні мати збіг репозиторієв образів з міткою середовища його простору імен.
# За винятком deployment, позначених як "exempt", або будь-яких контейнерів, які не належать організації "example.com" (наприклад, загальні sidecar).
# Наприклад, якщо у просторі імен є мітка {"environment": "staging"}, всі контейнери повинні мати репозиторій, який є або staging.example.com/*
# або не містить "example.com" взагалі, якщо deployment має мітку {"exempt": "true"}.

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: "image-matches-namespace-environment.policy.example.com"
spec:
  failurePolicy: Fail
  matchConstraints:
    resourceRules:
    - apiGroups:   ["apps"]
      apiVersions: ["v1"]
      operations:  ["CREATE", "UPDATE"]
      resources:   ["deployments"]
  variables:
  - name: environment
    expression: "'environment' in namespaceObject.metadata.labels ? namespaceObject.metadata.labels['environment'] : 'prod'"
  - name: exempt
    expression: "'exempt' in object.metadata.labels && object.metadata.labels['exempt'] == 'true'"
  - name: containers
    expression: "object.spec.template.spec.containers"
  - name: containersToCheck
    expression: "variables.containers.filter(c, c.image.contains('example.com/'))"
  validations:
  - expression: "variables.exempt || variables.containersToCheck.all(c, c.image.startsWith(variables.environment + '.'))"
    messageExpression: "'only ' + variables.environment + ' images are allowed in namespace ' + namespaceObject.metadata.name"

З правилом, привʼязаним до простору імен default, який має мітку environment: prod, спроба створити Deployment буде відхилена.

kubectl create deploy --image=dev.example.com/nginx invalid

Повідомлення про помилку буде схоже на таке.

error: failed to create deployment: deployments.apps "invalid" is forbidden: ValidatingAdmissionPolicy 'image-matches-namespace-environment.policy.example.com' with binding 'demo-binding-test.example.com' denied request: only prod images are allowed in namespace default

6.4 - Відомі мітки, анотації та позначення

Kubernetes зберігає всі мітки та анотації в просторах імен kubernetes.io і k8s.io.

Цей документ одночасно є і довідником, і точкою для призначення значень.

Мітки, анотації та позначення, використані в обʼєктах API

apf.kubernetes.io/autoupdate-spec

Тип: Annotation

Приклад: apf.kubernetes.io/autoupdate-spec: "true"

Використовується для: Обʼєктів FlowSchema та PriorityLevelConfiguration

Якщо ця анотація встановлена в значення true для FlowSchema або PriorityLevelConfiguration, то spec для цього обʼєкта управляється kube-apiserver. Якщо сервер API не розпізнає обʼєкт APF, а ви анотуєте його для автоматичного оновлення, сервер API видаляє весь обʼєкт. У іншому випадку сервер API не управляє специфікацією обʼєкта. Докладніше читайте Обслуговування обовʼязкових та рекомендованих обʼєктів конфігурації.

app.kubernetes.io/component

Тип: Label

Приклад: app.kubernetes.io/component: "database"

Використовується для: Всі обʼєкти (зазвичай використовується на ресурсах робочого навантаження).

Компонент в архітектурі застосунку.

Одна з рекомендованих міток.

app.kubernetes.io/created-by (deprecated)

Тип: Label

Приклад: app.kubernetes.io/created-by: "controller-manager"

Використовується для: Всі обʼєкти (зазвичай використовується на ресурсах робочого навантаження).

Контролер/користувач, який створив цей ресурс.

app.kubernetes.io/instance

Тип: Label

Приклад: app.kubernetes.io/instance: "mysql-abcxyz"

Використовується для: Всі обʼєкти (зазвичай використовується на ресурсах робочого навантаження).

Унікальне імʼя, що ідентифікує екземпляр застосунку. Для призначення неунікального імені використовуйте app.kubernetes.io/name.

Одна з рекомендованих міток.

app.kubernetes.io/managed-by

Тип: Label

Приклад: app.kubernetes.io/managed-by: "helm"

Використовується для: Всі обʼєкти (зазвичай використовується на ресурсах робочого навантаження).

Інструмент, що використовується для управління роботою застосунку.

Одна з рекомендованих міток.

app.kubernetes.io/name

Тип: Label

Приклад: app.kubernetes.io/name: "mysql"

Використовується для: Всі обʼєкти (зазвичай використовується на ресурсах робочого навантаження).

Назва застосунку.

Одна з рекомендованих міток.

app.kubernetes.io/part-of

Тип: Label

Приклад: app.kubernetes.io/part-of: "wordpress"

Використовується для: Всі обʼєкти (зазвичай використовується на ресурсах робочого навантаження).

Назва застосунку вищого рівня, частиною якого є цей обʼєкт.

Одна з рекомендованих міток.

app.kubernetes.io/version

Тип: Label

Приклад: app.kubernetes.io/version: "5.7.21"

Використовується для: Всі обʼєкти (зазвичай використовується на ресурсах робочого навантаження).

Поточна версія застосунку.

Загальні форми значень включають:

Одна з рекомендованих міток.

applyset.kubernetes.io/additional-namespaces (alpha)

Тип: Annotation

Приклад: applyset.kubernetes.io/additional-namespaces: "namespace1,namespace2"

Використовується для: Обʼєкти, які використовуються як батьки ApplySet.

Використання цієї анотації є альфа-версією. Для Kubernetes версії 1.31 ви можете використовувати цю анотацію на Secrets, ConfigMaps або власних ресурсах, якщо CustomResourceDefinition, що їх визначає, має мітку applyset.kubernetes.io/is-parent-type.

Частина специфікації, яка використовується для реалізації обрізки на основі ApplySet в kubectl. Ця анотація застосовується до батьківського обʼєкта, який використовується для відстеження ApplySet для розширення області застосування ApplySet поза власним простором імен батьківського обʼєкта (якщо є). Значення — це розділені комами імена просторів імен, в яких знаходяться обʼєкти, відмінні від простору імен батьківського обʼєкта.

applyset.kubernetes.io/contains-group-kinds (alpha)

Тип: Annotation

Приклад: applyset.kubernetes.io/contains-group-kinds: "certificates.cert-manager.io,configmaps,deployments.apps,secrets,services"

Використовується для: Обʼєкти, які використовуються як батьки ApplySet.

Використання цієї анотації є альфа-версією. Для Kubernetes версії 1.31 ви можете використовувати цю анотацію на Secrets, ConfigMaps або власних ресурсах, якщо CustomResourceDefinition, що їх визначає, має мітку applyset.kubernetes.io/is-parent-type.

Частина специфікації, яка використовується для реалізації обрізки на основі ApplySet в kubectl. Ця анотація застосовується до батьківського об’єкта, який використовується для відстеження ApplySet для оптимізації списку об’єктів-членів ApplySet. Не є обовʼязковою у специфікації ApplySet, оскільки інструменти можуть виконувати виявлення або використовувати іншу оптимізацію. Однак, починаючи з версії Kubernetes 1.31, kubectl вимагає її наявності. Якщо присутнє, значення цієї анотації має бути розділеним комами списком типів груп у форматі повної назви, тобто. <resource>.<group>.

applyset.kubernetes.io/contains-group-resources (deprecated)

Тип: Annotation

Приклад: applyset.kubernetes.io/contains-group-resources: "certificates.cert-manager.io,configmaps,deployments.apps,secrets,services"

Використовується для: Обʼєкти, які використовуються як батьки ApplySet.

Для Kubernetes версії 1.31 ви можете використовувати цю анотацію на Secrets, ConfigMaps або власних ресурсах, якщо CustomResourceDefinition, що їх визначає, має мітку applyset.kubernetes.io/is-parent-type.

Частина специфікації, яка використовується для реалізації обрізки на основі ApplySet в kubectl. Ця анотація застосовується до батьківського об’єкта, який використовується для відстеження ApplySet для оптимізації списку об’єктів-членів ApplySet. Не є обовʼязковою у специфікації ApplySet, оскільки інструменти можуть виконувати виявлення або використовувати іншу оптимізацію. Однак, починаючи з версії Kubernetes 1.31, kubectl вимагає її наявності. Якщо присутнє, значення цієї анотації має бути розділеним комами списком типів груп у форматі повної назви, тобто. <resource>.<group>.

applyset.kubernetes.io/id (alpha)

Тип: Label

Приклад: applyset.kubernetes.io/id: "applyset-0eFHV8ySqp7XoShsGvyWFQD3s96yqwHmzc4e0HR1dsY-v1"

Використовується для: Обʼєкти, які використовуються як батьки ApplySet.

Використання цієї мітки є альфа-версією. Для Kubernetes версії 1.31 ви можете використовувати цю мітку на Secrets, ConfigMaps або власних ресурсах, якщо CustomResourceDefinition, що їх визначає, має мітку applyset.kubernetes.io/is-parent-type.

Частина специфікації, яка використовується для реалізації обрізки на основі ApplySet в kubectl. Ця мітка робить об’єкт батьківським об’єктом ApplySet. Його значенням є унікальний ідентифікатор ApplySet, який походить від ідентифікатора самого батьківського об’єкта. Цей ідентифікатор повинен бути кодуванням base64 (з використанням безпечного для URL кодування RFC4648) хешу group-kind-name-namespace обʼєкта, на якому він знаходиться, у вигляді: <base64(sha256(<name>.<namespace>.<kind>.<group>))>. Між значенням цієї мітки та UID обʼєкта немає звʼязку.

applyset.kubernetes.io/is-parent-type (alpha)

Тип: Label

Приклад: applyset.kubernetes.io/is-parent-type: "true"

Використовується для: Custom Resource Definition (CRD)

Використання цієї мітки є альфа-версією. Частина специфікації, яка використовується для реалізації обрізки на основі ApplySet в kubectl. Ви можете встановити цю мітку на CustomResourceDefinition (CRD), щоб ідентифікувати тип власного ресурсу, який він визначає (а не сам CRD) як дозволеного батька для ApplySet. Єдиним допустимим значенням для цієї мітки є "true"; якщо ви хочете позначити CRD як такий, що не є дійсним батьком для ApplySets, пропустіть цю мітку.

applyset.kubernetes.io/part-of (alpha)

Тип: Label

Приклад: applyset.kubernetes.io/part-of: "applyset-0eFHV8ySqp7XoShsGvyWFQD3s96yqwHmzc4e0HR1dsY-v1"

Використовується для: Всі обʼєкти.

Використання цієї мітки є альфа-версією. Частина специфікації, яка використовується для реалізації обрізки на основі ApplySet в kubectl. Ця мітка робить обʼєкт членом ApplySet. Значення мітки повинно збігатися зі значенням мітки applyset.kubernetes.io/id у батьківському обʼєкті.

applyset.kubernetes.io/tooling (alpha)

Тип: Annotation

Приклад: applyset.kubernetes.io/tooling: "kubectl/v1.31"

Використовується для: Обʼєкти, які використовуються як батьки ApplySet.

Використання цієї анотації є альфа-версією. Для Kubernetes версії 1.31 ви можете використовувати цю анотацію на Secrets, ConfigMaps або власних ресурсах, якщо CustomResourceDefinition, що їх визначає, має мітку applyset.kubernetes.io/is-parent-type.

Частина специфікації, яка використовується для реалізації обрізки на основі ApplySet в kubectl. Ця анотація застосовується до батьківського обʼєкта, який використовується для відстеження ApplySet, щоб вказати, який інструментарій керує цим ApplySet. Інструментарій повинен відмовлятися змінювати ApplySets, що належать іншим інструментам. Значення має бути у форматі <toolname>/<semver>.

apps.kubernetes.io/pod-index (beta)

Тип: Label

Приклад: apps.kubernetes.io/pod-index: "0"

Використовується для: Pod

Коли контролер StatefulSet створює Pod для StatefulSet, він встановлює цю мітку на Pod. Значення мітки є порядковим індексом створюваного Podʼа.

Дивіться Мітка індексу Podʼа в темі StatefulSet для отримання більш детальної інформації. Зверніть увагу на PodIndexLabel, має бути увімкнено, щоб цю мітку можна було додати до Podʼів.

cluster-autoscaler.kubernetes.io/safe-to-evict

Тип: Annotation

Приклад: cluster-autoscaler.kubernetes.io/safe-to-evict: "true"

Використовується для: Pod

Коли ця анотація має значення "true", автомасштабувальнику кластера дозволяється виселяти Pod навіть якщо інші правила зазвичай забороняють це робити. Автомасштабувальник кластера ніколи не виселяє Podʼи, для яких ця анотація явно встановлена у значення "false"; ви можете встановити це значення для важливого Podʼа, який ви хочете продовжувати виконувати. Якщо цю анотацію не задано, то автомасштабувальник кластера поводитиметься так, як він поводиться на рівні Podʼа.

config.kubernetes.io/local-config

Тип: Annotation

Приклад: config.kubernetes.io/local-config: "true"

Використовується для: Всі обʼєкти

Ця анотація використовується у маніфестах для позначення обʼєкта як локальної конфігурації, яку не слід передавати до API Kubernetes.

Значення "true" для цієї анотації вказує, що обʼєкт використовується лише клієнтськими інструментами і не повинен бути надісланий на сервер API.

Значення "false" може бути використане для вказівки, що обʼєкт повинен бути надісланий на сервер API, навіть якщо в іншому випадку він вважався б локальним.

Ця анотація є частиною специфікації функцій Kubernetes Resource Model (KRM), яка використовується Kustomize та подібними сторонніми інструментами. Наприклад, Kustomize видаляє обʼєкти з цією анотацією з кінцевого результату збирання коду.

container.apparmor.security.beta.kubernetes.io/* (beta)

Тип: Annotation

Приклад: container.apparmor.security.beta.kubernetes.io/my-container: my-custom-profile

Використовується для: Pods

Ця анотація дозволяє вам вказати профіль безпеки AppArmor для контейнера в межах Podʼа Kubernetes. Починаючи з версії Kubernetes 1.30, це слід налаштовувати за допомогою поля appArmorProfile. Щоб дізнатися більше, перегляньте підручник з AppArmor. У підручнику показано, як використовувати AppArmor для обмеження можливостей і доступу контейнера.

Вказаний профіль визначає набір правил і обмежень, яких повинен дотримуватися процес у контейнері. Це допомагає забезпечити дотримання політик безпеки та ізоляцію ваших контейнерів.

internal.config.kubernetes.io/* (reserved prefix)

Тип: Annotation

Використовується для: Всі обʼєкти

Цей префікс зарезервований для внутрішнього використання інструментами, які діють як оркестратори відповідно до специфікації функцій Моделі Ресурсів Kubernetes (KRM). Анотації з цим префіксом є внутрішніми для процесу оркестрування та не зберігаються в маніфестах у файловій системі. Іншими словами, інструмент-оркестратор повинен встановлювати ці анотації при зчитуванні файлів з локальної файлової системи та видаляти їх при записі результатів роботи функцій назад у файлову систему.

Функція KRM не повинна змінювати анотації з цим префіксом, якщо не зазначено інше для конкретної анотації. Це дозволяє інструментам оркестрування додавати додаткові внутрішні анотації без необхідності вносити зміни в існуючі функції.

internal.config.kubernetes.io/path

Тип: Annotation

Приклад: internal.config.kubernetes.io/path: "relative/file/path.yaml"

Використовується для: Всі обʼєкти

Ця анотація записує шлях до файлу маніфесту, з якого було завантажено обʼєкт, у вигляді розділеного слешами, незалежного від ОС, відносного шляху. Шлях є відносним до фіксованого розташування у файловій системі, визначеного інструментом-оркестратором.

Ця анотація є частиною специфікації функцій Моделі Ресурсів Kubernetes (KRM), яка використовується Kustomize та подібними сторонніми інструментами.

Функція KRM не повинна змінювати цю анотацію у вхідних обʼєктах, якщо вона не змінює файли, на які посилається. Функція KRM може включати цю анотацію у обʼєкти, які вона генерує.

internal.config.kubernetes.io/index

Тип: Annotation

Приклад: internal.config.kubernetes.io/index: "2"

Використовується для: Всі обʼєкти

Ця анотація записує позицію (нумерація з нуля) YAML-документа, який містить обʼєкт, у файлі маніфесту, з якого було завантажено обʼєкт. Зазначимо, що YAML-документи розділяються трьома тире (---) і кожен може містити один обʼєкт. Якщо ця анотація не вказана, мається на увазі значення 0.

Ця анотація є частиною специфікації функцій Моделі Ресурсів Kubernetes (KRM), яка використовується Kustomize та подібними сторонніми інструментами.

Функція KRM не повинна змінювати цю анотацію у вхідних обʼєктах, якщо вона не змінює файли, на які посилається. Функція KRM може включати цю анотацію в обʼєкти, які вона генерує.

kubernetes.io/arch

Тип: Label

Приклад: kubernetes.io/arch: "amd64"

Використовується для: Node

Kubelet заповнює це значення за допомогою runtime.GOARCH, як визначено в Go. Це може бути корисним, якщо ви використовуєте змішані вузли ARM і x86.

kubernetes.io/os

Тип: Label

Приклад: kubernetes.io/os: "linux"

Використовується для: Node, Pod

Для вузлів Kubelet заповнює це значення за допомогою runtime.GOOS, як визначено в Go. Це може бути корисним, якщо у вашому кластері використовуються різні операційні системи (наприклад, змішані вузли Linux і Windows).

Ви також можете встановити цю мітку на Pod. Kubernetes дозволяє встановлювати будь-яке значення для цієї мітки; якщо ви використовуєте цю мітку, ви все ж повинні встановити її на рядок Go runtime.GOOS для операційної системи, з якою працює цей Pod.

Якщо значення мітки kubernetes.io/os для Pod не відповідає значенню мітки на вузлі, Kubelet на цьому вузлі не прийме Pod. Проте це не враховується планувальником kube-scheduler. Крім того, Kubelet відмовляється запускати Pod, якщо ви вказали операційну систему Pod, яка не відповідає операційній системі вузла, на якому працює цей Kubelet. Більше деталей можна знайти в розділі Операційна система Podʼа.

kubernetes.io/metadata.name

Тип: Label

Приклад: kubernetes.io/metadata.name: "mynamespace"

Використовується для: Namespaces

API-сервер Kubernetes (частина панелі управління) встановлює цю мітку на всі простори імен. Значення мітки встановлюється на імʼя простору імен. Ви не можете змінити значення цієї мітки.

Це корисно, якщо ви хочете вказати конкретний простір імен за допомогою селектора міток selector.

kubernetes.io/limit-ranger

Тип: Annotation

Приклад: kubernetes.io/limit-ranger: "LimitRanger plugin set: cpu, memory request for container nginx; cpu, memory limit for container nginx"

Використовується для: Pod

Стандартно Kubernetes не надає жодних обмежень на ресурси, тобто, якщо ви явно не визначите обмеження, ваш контейнер може споживати необмежену кількість CPU та памʼяті. Ви можете визначити стандартний запит або обмеження для Podʼів. Це робиться шляхом створення LimitRange у відповідному просторі імен. Podʼи, розгорнуті після визначення LimitRange, матимуть ці обмеження, застосовані до них. Анотація kubernetes.io/limit-ranger фіксує, що стандартні ресурси були вказані для Pod і були успішно застосовані. Для детальнішої інформації читайте про LimitRanges.

kubernetes.io/config.hash

Тип: Annotation

Приклад: kubernetes.io/config.hash: "df7cc47f8477b6b1226d7d23a904867b"

Використовується для: Pod

Коли kubelet створює статичний Pod на основі заданого маніфесту, він додає цю анотацію до статичного Pod. Значення анотації — це UID Pod. Зверніть увагу, що kubelet також встановлює .spec.nodeName у поточне імʼя вузла, ніби Pod було заплановано на цей вузол.

kubernetes.io/config.mirror

Тип: Annotation

Приклад: kubernetes.io/config.mirror: "df7cc47f8477b6b1226d7d23a904867b"

Використовується для: Pod

Для статичного Pod, створеного kubelet на вузлі, на API-сервері створюється дзеркальний Pod. Kubelet додає анотацію, щоб позначити, що цей Pod фактично є дзеркальним Podʼом. Значення анотації копіюється з анотації kubernetes.io/config.hash, яка є UID Pod.

При оновленні Pod з цією встановленою анотацією анотацію не можна змінити або видалити. Якщо у Podʼа немає цієї анотації, її не можна додати під час оновлення Pod.

kubernetes.io/config.source

Тип: Annotation

Приклад: kubernetes.io/config.source: "file"

Використовується для: Pod

Ця анотація додається kubelet, щоб вказати звідки походить Pod. Для статичних Pod значення анотації може бути одним із file або http, залежно від того, де розташований маніфест Podʼа. Для Podʼа, створеного на API-сервері, а потім запланованого на поточний вузол, значення анотації — api.

kubernetes.io/config.seen

Тип: Annotation

Приклад: kubernetes.io/config.seen: "2023-10-27T04:04:56.011314488Z"

Використовується для: Pod

Коли kubelet вперше бачить Pod, він може додати цю анотацію до Pod зі значенням поточного часу у форматі RFC3339.

addonmanager.kubernetes.io/mode

Тип: Label

Приклад: addonmanager.kubernetes.io/mode: "Reconcile"

Використовується для: Всі обʼєкти

Для вказання того, як слід керувати надбудовою, ви можете використовувати мітку addonmanager.kubernetes.io/mode. Ця мітка може мати одне з трьох значень: Reconcile, EnsureExists або Ignore.

  • Reconcile: Ресурси надбудови періодично будуть зведені до очікуваного стану. Якщо є будь-які відмінності, менеджер надбудов буде переробляти, змінювати конфігурацію або видаляти ресурси за потреби. Цей режим є стандартним режимом, якщо мітка не вказана.
  • EnsureExists: Ресурси надбудов будуть перевірятися лише на наявність, але не будуть змінюватися після створення. Менеджер надбудов створить або переробить ресурси, коли відсутній жоден екземпляр ресурсу з таким імʼям.
  • Ignore: Ресурси надбудов будуть ігноруватися. Цей режим корисний для надбудов, які не сумісні з менеджером надбудов або керуються іншим контролером.

Для отримання докладнішої інформації див. Addon-manager.

beta.kubernetes.io/arch (deprecated)

Тип: Label

Ця мітка є застарілою. Використовуйте натомість kubernetes.io/arch.

beta.kubernetes.io/os (deprecated)

Тип: Label

Ця мітка є застарілою. Використовуйте натомість kubernetes.io/os.

kube-aggregator.kubernetes.io/automanaged

Тип: Label

Приклад: kube-aggregator.kubernetes.io/automanaged: "onstart"

Використовується для: APIService

kube-apiserver встановлює цю мітку для будь-якого обʼєкта APIService, який сервер API створив автоматично. Мітка позначає, як панель управління повинна керувати цим APIService. Ви не повинні додавати, змінювати або видаляти цю мітку самостійно.

Є два можливих значення:

  • onstart: APIService повинен бути зведений до очікуваного стану при старті сервера API, але не під час інших операцій.
  • true: Сервер API повинен безперервно зводити цей APIService до очікуваного стану.

service.alpha.kubernetes.io/tolerate-unready-endpoints (deprecated)

Тип: Annotation

Використовується для: StatefulSet

Ця анотація на Service вказує, чи повинен контролер точок доступу створювати точки доступу для неготових Podʼів. Точки доступу цих Service зберігають свої DNS-записи і продовжують отримувати трафік для Service з моменту, коли kubelet запускає всі контейнери у Pod і позначає його як Running, до моменту, коли kubelet зупиняє всі контейнери і видаляє Pod з сервера API.

kubernetes.io/hostname

Тип: Label

Приклад: kubernetes.io/hostname: "ip-172-20-114-199.ec2.internal"

Використовується для: Node

Kubelet заповнює цю мітку імʼям хоста вузла. Зверніть увагу, що імʼя хоста може бути змінене з "фактичного" імʼя хоста за допомогою прапорця --hostname-override для kubelet.

Ця мітка також використовується як частина ієрархії топології. Дивіться topology.kubernetes.io/zone для отримання додаткової інформації.

kubernetes.io/change-cause

Тип: Annotation

Приклад: kubernetes.io/change-cause: "kubectl edit --record deployment foo"

Використовується для: Всіх обʼєктів

Ця анотація є найкращою спробою пояснення причини зміни чого-небудь.

Вона заповнюється при додаванні параметру --record до команди kubectl, яка може змінити обʼєкт.

kubernetes.io/description

Тип: Annotation

Приклад: kubernetes.io/description: "Description of K8s object."

Використовується для: Всіх обʼєктів

Ця анотація використовується для опису конкретної поведінки вказаного обʼєкта.

kubernetes.io/enforce-mountable-secrets

Тип: Annotation

Приклад: kubernetes.io/enforce-mountable-secrets: "true"

Використовується для: ServiceAccount

Значення цієї анотації повинно бути true, щоб вона набула чинності. Коли ви встановлюєте цю анотацію у значення "true", Kubernetes застосовує наступні правила для Podʼів, що працюють з цим ServiceAccount:

  1. Secretʼи, змонтовані як томи, повинні бути перелічені в полі secrets ServiceAccount.
  2. Secretʼи, на які посилаються у полі envFrom для контейнерів (включаючи контейнери sidecar і контейнери ініціалізації), також повинні бути перелічені в полі secrets ServiceAccount. Якщо будь-який контейнер в Podʼі посилається на Secret, який не перелічений в полі secrets ServiceAccount (навіть якщо посилання позначене як optional), то Pod не запуститься, і буде згенеровано помилку, що вказує на невідповідне посилання на секрет.
  3. Secretʼи, на які посилається у полі imagePullSecrets Podʼа, повинні бути присутніми в полі imagePullSecrets ServiceAccount, Pod не запуститься, і буде згенеровано помилку, що вказує на невідповідне посилання на секрет для отримання образу.

Під час створення або оновлення Podʼа перевіряються ці правила. Якщо Pod не відповідає їм, він не запуститься, і ви побачите повідомлення про помилку. Якщо Pod уже працює, і ви змінюєте анотацію kubernetes.io/enforce-mountable-secrets на значення true, або ви редагуєте повʼязаний ServiceAccount для видалення посилання на Secret, який вже використовується Podʼом, Pod продовжить працювати.

node.kubernetes.io/exclude-from-external-load-balancers

Тип: Label

Приклад: node.kubernetes.io/exclude-from-external-load-balancers

Використовується для: Node

Ви можете додати мітки до певних робочих вузлів, щоб виключити їх зі списку серверів бекенда, які використовуються зовнішніми балансувальниками навантаження. Наступна команда може бути використана для виключення робочого вузла зі списку серверів бекенда у наборі серверів бекенда:

kubectl label nodes <node-name> node.kubernetes.io/exclude-from-external-load-balancers=true

controller.kubernetes.io/pod-deletion-cost

Тип: Annotation

Приклад: controller.kubernetes.io/pod-deletion-cost: "10"

Використовується для: Pod

Ця анотація використовується для встановлення Вартості видалення Podʼа, що дозволяє користувачам впливати на порядок зменшення масштабування ReplicaSet. Значення анотації аналізується як тип int32.

cluster-autoscaler.kubernetes.io/enable-ds-eviction

Тип: Annotation

Приклад: cluster-autoscaler.kubernetes.io/enable-ds-eviction: "true"

Використовується для: Pod

Ця анотація контролює, чи повинен бути виселений Pod DaemonSet за допомогою ClusterAutoscaler. Ця анотація повинна бути вказана на Pod DaemonSet у маніфесті DaemonSet. Коли ця анотація встановлена в значення "true", ClusterAutoscaler дозволяє виселити Pod DaemonSet, навіть якщо інші правила зазвичай цього уникнули б. Щоб заборонити ClusterAutoscaler виселяти Pod DaemonSet, ви можете встановити цю анотацію в значення "false" для важливих Pod DaemonSet. Якщо ця анотація не встановлена, тоді ClusterAutoscaler діє згідно своєї загальної поведінки (тобто виселяє Pod DaemonSets на основі своєї конфігурації).

kubernetes.io/ingress-bandwidth

Тип: Annotation

Приклад: kubernetes.io/ingress-bandwidth: 10M

Використовується для: Pod

Ви можете застосувати обмеження пропускної здатності відповідно для якості обслуговування до Pod щоб ефективно обмежити його доступну пропускну здатність. Вхідний трафік до Podʼа обробляється за допомогою упорядкованої черги пакетів для ефективного керування даними. Щоб обмежити пропускну здатність Podʼа, напишіть файл визначення обʼєкта JSON і вкажіть швидкість передачі даних за допомогою анотації kubernetes.io/ingress-bandwidth. Одиницею, яка використовується для вказівки швидкості вхідної передачі, є біти на секунду, в форматі Кількості. Наприклад, 10M означає 10 мегабіт на секунду.

kubernetes.io/egress-bandwidth

Тип: Annotation

Приклад: kubernetes.io/egress-bandwidth: 10M

Використовується для: Pod

Вихідний трафік з Podʼа обробляється за допомогою застосування політик, які просто відкидають пакети, що перевищують налаштовану швидкість. Обмеження, які ви встановлюєте на Pod, не впливають на пропускну здатність інших Podʼів. Щоб обмежити пропускну здатність Podʼа, напишіть файл визначення обʼєкта JSON і вкажіть швидкість передачі даних за допомогою анотації kubernetes.io/egress-bandwidth. Одиницею, яка використовується для вказівки швидкості вихідної передачі, є біти на секунду, в форматі Кількості. Наприклад, 10M означає 10 мегабіт на секунду.

beta.kubernetes.io/instance-type (deprecated)

Тип: Label

node.kubernetes.io/instance-type

Тип: Label

Приклад: node.kubernetes.io/instance-type: "m3.medium"

Використовується для: Node

Kubelet заповнює це значенням типу екземпляра, як визначено постачальником хмарних послуг. Це буде встановлено лише в разі використання постачальника хмарних послуг. Це налаштування є зручним, якщо ви хочете спрямувати певні робочі навантаження на певні типи екземплярів, але, як правило, ви хочете покладатися на планувальник Kubernetes для виконання планування на основі ресурсів. Ви повинні намагатися планувати на основі властивостей, а не на основі типів екземплярів (наприклад, потребувати GPU, замість потреби в g2.2xlarge).

failure-domain.beta.kubernetes.io/region (deprecated)

Тип: Label

failure-domain.beta.kubernetes.io/zone (deprecated)

Тип: Label

pv.kubernetes.io/bind-completed

Тип: Annotation

Приклад: pv.kubernetes.io/bind-completed: "yes"

Використовується для: PersistentVolumeClaim

Коли ця анотація встановлена на PersistentVolumeClaim (PVC), це вказує на те, що життєвий цикл PVC пройшов через початкове налаштування звʼязування. Коли вона присутня, ця інформація змінює те, як панель управління тлумачить стан обʼєктів PVC. Значення цієї анотації не має значення для Kubernetes.

pv.kubernetes.io/bound-by-controller

Тип: Annotation

Приклад: pv.kubernetes.io/bound-by-controller: "yes"

Використовується для: PersistentVolume, PersistentVolumeClaim

Якщо ця анотація встановлена на PersistentVolume або PersistentVolumeClaim, це вказує на те, що звʼязка зберігання (PersistentVolume → PersistentVolumeClaim або PersistentVolumeClaim → PersistentVolume) була встановлена контролером. Якщо анотація не встановлена, а звʼязка зберігання вже існує, відсутність цієї анотації означає, що звʼязка була встановлена вручну. Значення цієї анотації не має значення.

pv.kubernetes.io/provisioned-by

Тип: Annotation

Приклад: pv.kubernetes.io/provisioned-by: "kubernetes.io/rbd"

Використовується для: PersistentVolume

Ця анотація додається до PersistentVolume (PV), який був динамічно розподілений Kubernetes. Її значення — це імʼя втулка тому, який створив том. Вона служить як користувачам (щоб показати, звідки походить PV), так і Kubernetes (щоб визначити динамічно розподілені PV у своїх рішеннях).

pv.kubernetes.io/migrated-to

Тип: Annotation

Приклад: pv.kubernetes.io/migrated-to: pd.csi.storage.gke.io

Використовується для: PersistentVolume, PersistentVolumeClaim

Ця анотація додається до PersistentVolume (PV) та PersistentVolumeClaim (PVC), які мають бути динамічно розподілені або видалені відповідним драйвером CSI через власну функціональну можливість CSIMigration. Коли ця анотація встановлена, компоненти Kubernetes "припиняють боротьбу", і external-provisioner діятиме з обʼєктами.

statefulset.kubernetes.io/pod-name

Тип: Label

Приклад: statefulset.kubernetes.io/pod-name: "mystatefulset-7"

Використовується для: Pod

Коли контролер StatefulSet створює Pod для StatefulSet, панель управління встановлює цю мітку на Podʼі. Значення мітки — це імʼя створеного Podʼа.

Дивіться Мітка імені Podʼа у темі StatefulSet для отримання більш детальної інформації.

scheduler.alpha.kubernetes.io/node-selector

Тип: Annotation

Приклад: scheduler.alpha.kubernetes.io/node-selector: "name-of-node-selector"

Використовується для: Namespace

PodNodeSelector використовує цей ключ анотації для призначення селекторів вузла до Podʼів у просторах імен.

topology.kubernetes.io/region

Тип: Label

Приклад: topology.kubernetes.io/region: "us-east-1"

Використовується для: Node, PersistentVolume

Див. topology.kubernetes.io/zone.

topology.kubernetes.io/zone

Тип: Label

Приклад: topology.kubernetes.io/zone: "us-east-1c"

Використовується для: Node, PersistentVolume

На Node: kubelet або зовнішній cloud-controller-manager заповнюють мітку інформацією від постачальника хмарних послуг. Мітку буде встановлено лише в разі використання постачальника хмарних послуг. Однак ви можете розглянути можливість встановлення її на вузлах, якщо це має сенс у вашій топології.

На PersistentVolume: постачальники томів, що мають відомості про топологію, автоматично встановлюють обмеження на спорідненість вузла для PersistentVolume.

Зона представляє собою логічний домен невдачі. Для підвищення доступності звичайно, кластери Kubernetes охоплюють декілька зон. Хоча точне визначення зони залишається на вибір реалізацій інфраструктури, загальні властивості зон включають дуже низьку мережеву затримку всередині зони, відсутність вартості мережевого трафіку всередині зони та незалежність від невдач інших зон. Наприклад, вузли всередині зони можуть використовувати один мережевий комутатор, але вузли в різних зонах цього робити не повинні.

Регіон представляє собою більшу область, що складається з однієї або декількох зон. Кластери Kubernetes, що охоплюють декілька регіонів, є не звичайним явищем. Хоча точне визначення зони або регіону залишається на вибір реалізацій інфраструктури, загальні властивості регіону включають в себе вищу мережеву затримку між ними, ненульову вартість мережевого трафіку між ними та незалежність від невдач інших зон або регіонів. Наприклад, вузли всередині регіону можуть використовувати спільну інфраструктуру живлення (наприклад, джерело безперебійного живлення або генератор), але вузли в різних регіонах зазвичай ні.

Kubernetes робить кілька припущень щодо структури зон та регіонів:

  1. регіони та зони є ієрархічними: зони є строгими підмножинами регіонів, і жодна зона не може бути в двох регіонах;
  2. імена зон є унікальними у всіх регіонах; наприклад, регіон "africa-east-1" може складатися з зон "africa-east-1a" та "africa-east-1b".

Можна вважати за безпечне припущення, що мітки топології не змінюються. Навіть якщо мітки є строго змінюваними, споживачі можуть припускати, що данний вузол не буде переміщений між зонами без знищення та перестворення.

Kubernetes може використовувати цю інформацію різними способами. Наприклад, планувальник автоматично намагається розподілити Podʼи в ReplicaSet по вузлах в однозонному кластері (щоб зменшити вплив відмови вузла, див. kubernetes.io/hostname). З кластерами, які охоплюють кілька зон, ця поведінка розподілу також застосовується до зон (для зменшення впливу відмови зони). Це досягається за допомогою SelectorSpreadPriority.

SelectorSpreadPriority — це найкраще розміщення. Якщо зони у вашому кластері є гетерогенними (наприклад, різна кількість вузлів, різні типи вузлів або різні вимоги до ресурсів Podʼа), це розміщення може завадити рівномірному розподілу ваших Podʼів між зонами. Якщо це потрібно, ви можете використовувати однорідні зони (однакова кількість і типи вузлів), щоб зменшити ймовірність нерівномірного розподілу.

Планувальник (за допомогою предиката VolumeZonePredicate) також буде забезпечувати, що Podʼи, які вимагають певного тома, будуть розміщені лише в тій же зоні, що й цей том. Томи не можуть бути підключені в різних зонах.

Якщо PersistentVolumeLabel не підтримує автоматичне додавання міток до ваших PersistentVolume, варто розглянути можливість додавання міток вручну (або підтримку PersistentVolumeLabel). З PersistentVolumeLabel планувальник перешкоджає Podʼам монтувати томи в інших зонах. Якщо ваша інфраструктура не має цього обмеження, вам не потрібно додавати мітки зони до томів взагалі.

volume.beta.kubernetes.io/storage-provisioner (deprecated)

Тип: Annotation

Приклад: volume.beta.kubernetes.io/storage-provisioner: "k8s.io/minikube-hostpath"

Використовується для: PersistentVolumeClaim

Ця анотація застаріла починаючи з v1.23. Дивіться volume.kubernetes.io/storage-provisioner.

volume.beta.kubernetes.io/storage-class (deprecated)

Тип: Annotation

Приклад: volume.beta.kubernetes.io/storage-class: "example-class"

Використовується для: PersistentVolume, PersistentVolumeClaim

Ця анотація може використовуватися для PersistentVolume(PV) або PersistentVolumeClaim(PVC), щоб вказати імʼя StorageClass. Коли обидва атрибути storageClassName та анотація volume.beta.kubernetes.io/storage-class вказані, анотація volume.beta.kubernetes.io/storage-class має перевагу над атрибутом storageClassName.

Ця анотація застаріла. Замість цього встановіть поле storageClassName для PersistentVolumeClaim або PersistentVolume.

volume.beta.kubernetes.io/mount-options (deprecated)

Тип: Annotation

Example : volume.beta.kubernetes.io/mount-options: "ro,soft"

Використовується для: PersistentVolume

Адміністратор Kubernetes може вказати додаткові опції монтування для того, коли PersistentVolume монтується на вузлі.

volume.kubernetes.io/storage-provisioner

Тип: Annotation

Використовується для: PersistentVolumeClaim

Ця анотація додається до PVC, яка має бути динамічно наданою. Її значення — це імʼя втулка тому, який має надати том для цієї PVC.

volume.kubernetes.io/selected-node

Тип: Annotation

Використовується для: PersistentVolumeClaim

Ця анотація додається до PVC, яка активується планувальником для динамічного надання. Її значення — це імʼя вибраного вузла.

volumes.kubernetes.io/controller-managed-attach-detach

Тип: Annotation

Використовується для: Node

Якщо вузол має анотацію volumes.kubernetes.io/controller-managed-attach-detach, його операції прикріплення та відʼєднання зберігання керуються контролером прикріплення/відʼєднання тому.

Значення анотації не має значення.

node.kubernetes.io/windows-build

Тип: Label

Приклад: node.kubernetes.io/windows-build: "10.0.17763"

Використовується для: Node

Коли kubelet працює на операційній системі Microsoft Windows, він автоматично позначає міткою свій вузол, щоб зафіксувати версію Windows Server, що використовується.

Значення мітки має формат "MajorVersion.MinorVersion.BuildNumber".

storage.alpha.kubernetes.io/migrated-plugins

Тип: Annotation

Приклад:storage.alpha.kubernetes.io/migrated-plugins: "kubernetes.io/cinder"

Використовується для: CSINode (API розширення)

Цю анотацію буде автоматично додано до обʼєкта CSINode, який зіставляється з вузлом, на якому встановлено CSIDriver. Ця анотація показує назву вбудованого втулка, який було перенесено. Його значення залежить від вбудованого коду хмарного провайдера зберігання.

Наприклад, якщо тип зберігання вбудованого хмарного провайдера є CSIMigrationvSphere, обʼєкт CSINodes для вузла повинен бути оновлений наступним чином: storage.alpha.kubernetes.io/migrated-plugins: "kubernetes.io/vsphere-volume"

service.kubernetes.io/headless

Тип: Label

Приклад: service.kubernetes.io/headless: ""

Використовується для: Service

Панель управління додає цю мітку до об’єкта Endpoints, коли Service-власник є headless. Щоб дізнатися більше, прочитайте Headless Services.

service.kubernetes.io/topology-aware-hints (deprecated)

Приклад: service.kubernetes.io/topology-aware-hints: "Auto"

Використовується для: Service

Ця анотація використовувалася для увімкнення підказок про топологію на Serviceʼах. Підказки щодо топології з тих пір були перейменовані: концепцію зараз називають Маршрутизацією з урахуванням топології. Встановлення анотації на Auto для Service налаштовує панель управління Kubernetes додавати підказки про топологію на EndpointSlices, повʼязані з цим Service. Ви також можете явно встановити анотацію на Disabled.

Якщо ви використовуєте версію Kubernetes, старішу за 1.31, перевірте документацію для цієї версії Kubernetes, щоб побачити, як працює маршрутизація на основі топології в цьому випуску.

Інших дійсних значень для цієї анотації немає. Якщо вам не потрібні підказки щодо топології для Service, не додавайте цю анотацію.

service.kubernetes.io/topology-mode

Тип: Annotation

Приклад: service.kubernetes.io/topology-mode: Auto

Використовується для: Service

Ця анотація надає спосіб визначення того, як Serviceʼи обробляють топологію мережі; наприклад, ви можете налаштувати Service так, щоб Kubernetes віддавав перевагу збереженню трафіку між клієнтом і сервером в межах однієї топологічної зони. У деяких випадках це може допомогти зменшити витрати або покращити роботу мережі.

Дивіться Маршрутизація з урахуванням топології для отримання додаткових відомостей.

kubernetes.io/service-name

Тип: Label

Приклад: kubernetes.io/service-name: "my-website"

Використовується для: EndpointSlice

Kubernetes асоціює EndpointSlices з Services за допомогою цієї мітки.

Ця мітка записує імʼя Service, який підтримує EndpointSlice. Усі EndpointSlices повинні мати цю мітку встановлену на імʼя їх повʼязаного Service.

kubernetes.io/service-account.name

Тип: Annotation

Приклад: kubernetes.io/service-account.name: "sa-name"

Використовується для: Secret

Ця анотація записує імʼя ServiceAccount, яке представляє токен (збережений у Secret типу kubernetes.io/service-account-token).

kubernetes.io/service-account.uid

Тип: Annotation

Приклад: kubernetes.io/service-account.uid: da68f9c6-9d26-11e7-b84e-002dc52800da

Використовується для: Secret

Ця анотація записує унікальний ідентифікатор ServiceAccount, який представляє токен (збережений у Secret типу kubernetes.io/service-account-token).

kubernetes.io/legacy-token-last-used

Тип: Label

Приклад: kubernetes.io/legacy-token-last-used: 2022-10-24

Використовується для: Secret

Панель управління додає цю мітку лише до Secretʼів, які мають тип kubernetes.io/service-account-token. Значення цієї мітки записує дату (в форматі ISO 8601, в часовому поясі UTC), коли панель управління востаннє бачила запит, де клієнт автентифікувався за допомогою токена службового облікового запису.

Якщо легасі-токен використовувався останній раз до того, як кластер отримав цю функцію (додану у Kubernetes v1.26), то мітка не встановлена.

kubernetes.io/legacy-token-invalid-since

Тип: Label

Приклад: kubernetes.io/legacy-token-invalid-since: 2023-10-27

Використовується для: Secret

Панель управління автоматично додає цю мітку до автогенерованих Secretʼів з типом kubernetes.io/service-account-token, за умови, що у вас увімкнено функціональну можливість LegacyServiceAccountTokenCleanUp. У Kubernetes 1.31 ця поведінка включена стандартно. Ця мітка позначає токен на основі Secret як недійсний для автентифікації. Значення цієї мітки записує дату (в форматі ISO 8601, в часовому поясі UTC), коли панель управління виявляє, що автогенерований Secret не використовувався протягом вказаного періоду (стандартно, один рік).

endpointslice.kubernetes.io/managed-by

Тип: Label

Приклад: endpointslice.kubernetes.io/managed-by: endpointslice-controller.k8s.io

Використовується для: EndpointSlices

Ця мітка використовується для позначення контролера або сутності, яка керує EndpointSlice. Мета цієї мітки — забезпечити можливість керувати різними обʼєктами EndpointSlice різними контролерами або сутностями в межах одного та самого кластера.

endpointslice.kubernetes.io/skip-mirror

Тип: Label

Приклад: endpointslice.kubernetes.io/skip-mirror: "true"

Використовується для: Endpoints

Цю мітку можна встановити на значення "true" для ресурсу Endpoints, щоб позначити, що контролер EndpointSliceMirroring не повинен дублювати цей ресурс за допомогою EndpointSlices.

service.kubernetes.io/service-proxy-name

Тип: Label

Приклад: service.kubernetes.io/service-proxy-name: "foo-bar"

Використовується для: Service

У kube-proxy ця мітка використовується для власного проксі, який делегує керування сервісом до власного проксі.

experimental.windows.kubernetes.io/isolation-type (deprecated)

Тип: Annotation

Приклад: experimental.windows.kubernetes.io/isolation-type: "hyperv"

Використовується для: Pod

Ця анотація використовується для запуску контейнерів Windows з ізоляцією Hyper-V.

ingressclass.kubernetes.io/is-default-class

Тип: Annotation

Приклад: ingressclass.kubernetes.io/is-default-class: "true"

Використовується для: IngressClass

Якщо ресурс IngressClass має цю анотацію встановлену на значення "true", новий ресурс Ingress без вказаного класу буде призначено цей стандартний клас.

nginx.ingress.kubernetes.io/configuration-snippet

Тип: Annotation

Приклад: nginx.ingress.kubernetes.io/configuration-snippet: " more_set_headers \"Request-Id: $req_id\";\nmore_set_headers \"Example: 42\";\n"

Використовується для: Ingress

Ви можете використовувати цю анотацію для налаштування додаткових параметрів Ingress, що використовує NGINX Ingress Controller. Анотація configuration-snippet стандартно ігнорується, починаючи з версії 1.9.0 контролера ingress. Щоб використовувати цю анотацію, потрібно явно увімкнути налаштування контролера NGINX ingress allow-snippet-annotations. Увімкнення цієї анотації може бути небезпечним у кластері з декількома орендарями, оскільки це може дозволити людям з обмеженими правами доступу отримувати всі Secrets у кластері.

kubernetes.io/ingress.class (deprecated)

Тип: Annotation

Використовується для: Ingress

storageclass.kubernetes.io/is-default-class

Тип: Annotation

Приклад: storageclass.kubernetes.io/is-default-class: "true"

Використовується для: StorageClass

Якщо один ресурс StorageClass має цю анотацію встановлену на значення "true", новий ресурс PersistentVolumeClaim без вказаного класу буде призначено цей стандартний клас.

alpha.kubernetes.io/provided-node-ip (alpha)

Тип: Annotation

Приклад: alpha.kubernetes.io/provided-node-ip: "10.0.0.1"

Використовується для: Node

Kubelet може встановити цю анотацію на вузлі, щоб вказати його налаштовану адресу IPv4 та/або IPv6.

Коли kubelet запускається з прапорцем --cloud-provider, встановленим на будь-яке значення (включає як зовнішні, так і застарілі постачальники хмарних служб у вбудованому коді), він встановлює цю анотацію на вузлі, щоб вказати IP-адресу, встановлену з командного рядка за допомогою прапорця --node-ip. Цей IP перевіряється постачальником хмарних послуг на дійсність за допомогою cloud-controller-manager.

batch.kubernetes.io/job-completion-index

Тип: Annotation, Label

Приклад: batch.kubernetes.io/job-completion-index: "3"

Використовується для: Pod

Контролер Job у kube-controller-manager встановлює це як мітку та анотацію для Podʼів, створених з режимом завершення Indexed.

Зверніть увагу, що для того, щоб це було додано як мітку Podʼа, необхідно увімкнути функціональну можливість PodIndexLabel, інакше це буде просто анотацією.

batch.kubernetes.io/cronjob-scheduled-timestamp

Тип: Annotation

Приклад: batch.kubernetes.io/cronjob-scheduled-timestamp: "2016-05-19T03:00:00-07:00"

Використовується для: Jobs and Pods controlled by CronJobs

Ця анотація використовується для запису оригінального (очікуваного) часу створення для завдання, коли це завдання є частиною CronJob. Панель управління встановлює значення цього часового позначення у форматі RFC3339. Якщо завдання належить до CronJob з вказаною часовою зоною, тоді мітка часу знаходиться в цій часовій зоні. В іншому випадку мітка часу відображається в локальному часі controller-manager.

kubectl.kubernetes.io/default-container

Тип: Annotation

Приклад: kubectl.kubernetes.io/default-container: "front-end-app"

Значення анотації — це імʼя контейнера, яке є типовим для цього Podʼа. Наприклад, команди kubectl logs або kubectl exec без прапорця -c або --container використовуватимуть цей типовий контейнер.

kubectl.kubernetes.io/default-logs-container (deprecated)

Тип: Annotation

Приклад: kubectl.kubernetes.io/default-logs-container: "front-end-app"

Значення анотації — це імʼя контейнера, яке є типовим для логування для цього Podʼа. Наприклад, команда kubectl logs без прапорця -c або --container використовуватиме цей типовий контейнер.

kubectl.kubernetes.io/last-applied-configuration

Тип: Annotation

Приклад: дивіться наступний код

    kubectl.kubernetes.io/last-applied-configuration: >
      {"apiVersion":"apps/v1","kind":"Deployment","metadata":{"annotations":{},"name":"example","namespace":"default"},"spec":{"selector":{"matchLabels":{"app.kubernetes.io/name":foo}},"template":{"metadata":{"labels":{"app.kubernetes.io/name":"foo"}},"spec":{"containers":[{"image":"container-registry.example/foo-bar:1.42","name":"foo-bar","ports":[{"containerPort":42}]}]}}}}      

Використовується для: Всі обʼєкти

Командний рядок інструменту kubectl використовує цю анотацію як застарілий механізм для відстеження змін. Цей механізм був замінений на Server-Side Apply.

kubectl.kubernetes.io/restartedAt

Тип: Annotation

Приклад: kubectl.kubernetes.io/restartedAt: "2024-06-21T17:27:41Z"

Використовується для: Deployment, ReplicaSet, StatefulSet, DaemonSet, Pod

Ця анотація містить останній час перезапуску ресурсу (Deployment, ReplicaSet, StatefulSet або DaemonSet), під час якого kubectl запустив розгортання для примусового створення нових Podʼів. Команда kubectl rollout restart <RESOURCE> ініціює перезапуск шляхом виправлення шаблону метаданих усіх Podʼів ресурсу з цією анотацією. У наведеному вище прикладі останній час перезапуску показано як 21 червня 2024 року о 17:27:41 UTC.

Не слід вважати, що ця анотація відображає дату/час останнього оновлення; окремі зміни могли бути внесені з моменту останнього ручного розгортання.

Якщо ви вручну встановите цю анотацію на Pod, нічого не станеться. Побічний ефект перезапуску повʼязаний з тим, як працює управління робочим навантаженням і шаблонізацією Pod.

endpoints.kubernetes.io/over-capacity

Тип: Annotation

Приклад: endpoints.kubernetes.io/over-capacity:truncated

Використовується для: Endpoints

Панель управління додає цю анотацію до обʼєкта Endpoints, якщо повʼязаний Service має більше 1000 резервних точок доступу. Анотація вказує на те, що обʼєкт Endpoints перевищив потужність, і кількість точок доступу була скорочена до 1000.

Якщо кількість резервних точок доступу опускається нижче 1000, то панель управління видаляє цю анотацію.

endpoints.kubernetes.io/last-change-trigger-time

Тип: Annotation

Приклад: endpoints.kubernetes.io/last-change-trigger-time: "2023-07-20T04:45:21Z"

Використовується для: Endpoints

Ця анотація встановлює обʼєкт Endpoints, який представляє мітку часу (Мітка часу зберігається у форматі дата-часового рядка RFC 3339. Наприклад, '2018-10-22T19:32:52.1Z'). Це позначка часу останньої зміни в деякому обʼєкті Pod або Service, яка спричинила зміну в обʼєкті Endpoints.

control-plane.alpha.kubernetes.io/leader (deprecated)

Тип: Annotation

Приклад: control-plane.alpha.kubernetes.io/leader={"holderIdentity":"controller-0","leaseDurationSeconds":15,"acquireTime":"2023-01-19T13:12:57Z","renewTime":"2023-01-19T13:13:54Z","leaderTransitions":1}

Використовується для: Endpoints

Раніше панель управління встановлювала анотацію на обʼєкті Endpoints. Ця анотація містила наступну інформацію:

  • Хто є поточним лідером.
  • Час, коли було здобуто поточне лідерство.
  • Тривалість оренди (лідерства) у секундах.
  • Час, коли поточна оренда (поточне лідерство) повинна бути продовжена.
  • Кількість переходів лідерства, які сталися у минулому.

Тепер Kubernetes використовує Leases для керування призначенням лідера для панелі управління Kubernetes.

batch.kubernetes.io/job-tracking (deprecated)

Тип: Annotation

Приклад: batch.kubernetes.io/job-tracking: ""

Використовується для: Jobs

Раніше наявність цієї анотації на обʼєкті Job вказувала на те, що панель управління відстежує статус Job за допомогою завершувачів. Додавання або видалення цієї анотації більше не має впливу (з версії Kubernetes v1.27 і пізніше). Всі Jobs відстежуються за допомогою завершувачів.

job-name (deprecated)

Тип: Label

Приклад: job-name: "pi"

Використовується для: Jobs та Pods, що керуються через Jobs

controller-uid (deprecated)

Тип: Label

Приклад: controller-uid: "$UID"

Використовується для: Jobs та Pods, що керуються через Jobs

batch.kubernetes.io/job-name

Тип: Label

Приклад: batch.kubernetes.io/job-name: "pi"

Використовується для: Jobs та Pods, що керуються через Jobs

Ця мітка використовується як зручний спосіб для отримання Podʼів, що належать Job. Мітка job-name походить від імені Job і надає простий спосіб отримати Podʼи, що належать Job.

batch.kubernetes.io/controller-uid

Тип: Label

Приклад: batch.kubernetes.io/controller-uid: "$UID"

Використовується для: Jobs та Pods, що керуються через Jobs

Ця мітка використовується як програмний спосіб отримати всі Podʼи, що належать Job. controller-uid є унікальним ідентифікатором, який встановлюється в поле selector, щоб контролер Job міг отримати всі відповідні Podʼи.

scheduler.alpha.kubernetes.io/defaultTolerations

Тип: Annotation

Приклад: scheduler.alpha.kubernetes.io/defaultTolerations: '[{"operator": "Equal", "value": "value1", "effect": "NoSchedule", "key": "dedicated-node"}]'

Використовується для: Namespace

Ця анотація вимагає активування контролера допуску PodTolerationRestriction. Ключ цієї анотації дозволяє призначати толерантності для простору імен, і будь-які нові створені в цьому просторі імен Podʼи отримають ці толерантності.

scheduler.alpha.kubernetes.io/tolerationsWhitelist

Тип: Annotation

Приклад: scheduler.alpha.kubernetes.io/tolerationsWhitelist: '[{"operator": "Exists", "effect": "NoSchedule", "key": "dedicated-node"}]'

Використовується для: Namespace

Ця анотація корисна лише тоді, коли активований контролер допуску (Alpha) PodTolerationRestriction. Значення анотації — це JSON-документ, який визначає список допустимих толерантностей для простору імен, який анотується. Під час створення Pod або зміни його толерантностей, сервер API перевіряє толерантності, щоб переконатися, що вони згадуються у списку дозволених. Pod буде прийнятий лише у випадку успішної перевірки.

scheduler.alpha.kubernetes.io/preferAvoidPods (deprecated)

Тип: Annotation

Використовується для: Node

Ця анотація вимагає активації втулка планування NodePreferAvoidPods. Однак цей втулок застарів починаючи з Kubernetes 1.22. Замість цього використовуйте Позначення та толерантності.

node.kubernetes.io/not-ready

Тип: Taint

Приклад: node.kubernetes.io/not-ready: "NoExecute"

Використовується для: Node

Контролер Node визначає, чи готовий Node, відстежуючи стан його справності, і відповідно додає або видаляє це позначення.

node.kubernetes.io/unreachable

Тип: Taint

Приклад: node.kubernetes.io/unreachable: "NoExecute"

Використовується для: Node

Контролер Node додає позначення на Node відповідно до NodeCondition Ready, якщо воно має значення Unknown.

node.kubernetes.io/unschedulable

Тип: Taint

Приклад: node.kubernetes.io/unschedulable: "NoSchedule"

Використовується для: Node

Позначення буде додано до вузла під час його ініціалізації, щоб уникнути стану перегонів.

node.kubernetes.io/memory-pressure

Тип: Taint

Приклад: node.kubernetes.io/memory-pressure: "NoSchedule"

Використовується для: Node

Kubelet виявляє тиск на памʼять на основі значень memory.available і allocatableMemory.available, спостережуваних на вузлі. Потім спостережені значення порівнюються з відповідними пороговими значеннями, які можна встановити на kubelet, щоб визначити, чи потрібно додати / видалити умову вузла та позначення.

node.kubernetes.io/disk-pressure

Тип: Taint

Приклад: node.kubernetes.io/disk-pressure :"NoSchedule"

Використовується для: Node

Kubelet виявляє тиск на дискову памʼять на основі значень imagefs.available, imagefs.inodesFree, nodefs.available і nodefs.inodesFree (тільки для Linux), спостережуваних на вузлі. Потім спостережені значення порівнюються з відповідними пороговими значеннями, які можна встановити на kubelet, щоб визначити, чи потрібно додати / видалити умову вузла та позначення.

node.kubernetes.io/network-unavailable

Тип: Taint

Приклад: node.kubernetes.io/network-unavailable: "NoSchedule"

Використовується для: Node

Це спочатку встановлюється kubelet, коли використовуваний хмарний постачальник вказує на потребу в додатковій конфігурації мережі. Тільки коли маршрут на хмарі налаштований належним чином, хмарний постачальник видаляє позначення.

node.kubernetes.io/pid-pressure

Тип: Taint

Приклад: node.kubernetes.io/pid-pressure: "NoSchedule"

Використовується для: Node

Kubelet перевіряє D-значення розміру /proc/sys/kernel/pid_max та PID, використані Kubernetes на вузлі, щоб отримати кількість доступних PID, які вказуються метрикою pid.available. Потім цю метрику порівнюють з відповідним пороговим значенням, яке можна встановити на kubelet, щоб визначити, чи потрібно додати / видалити умову вузла та позначення.

node.kubernetes.io/out-of-service

Тип: Taint

Приклад: node.kubernetes.io/out-of-service:NoExecute

Використовується для: Node

Користувач може вручну додати позначення на вузол, відмітивши його як такий що вийшов з ладу. Якщо у kube-controller-manager увімкнути функціональну можливість NodeOutOfServiceVolumeDetach, і вузол позначений як такий, що вийшов з ладу з цим позначенням, то при відсутності відповідних толерантностей на ньому, Podʼи на вузлі будуть примусово видалені, і операції відʼєднання томів для Podʼів, які завершуються на вузлі, відбудуться негайно. Це дозволяє Podʼам, що є в стані виходу з ладу на одному вузлі швидко відновитися на іншому вузлі.

node.cloudprovider.kubernetes.io/uninitialized

Тип: Taint

Приклад: node.cloudprovider.kubernetes.io/uninitialized: "NoSchedule"

Використовується для: Node

Встановлює цю позначку на вузлі, щоб позначити його як непридатний для використання, коли kubelet запускається з "зовнішнім" хмарним постачальником, доки контролер з cloud-controller-manager ініціалізує цей вузол, а потім видаляє позначку.

node.cloudprovider.kubernetes.io/shutdown

Тип: Taint

Приклад: node.cloudprovider.kubernetes.io/shutdown: "NoSchedule"

Використовується для: Node

Якщо вузол перебуває у визначеному хмарним постачальником стані вимкнення, вузол отримує відповідну позначку з node.cloudprovider.kubernetes.io/shutdown і ефект позначки NoSchedule.

feature.node.kubernetes.io/*

Тип: Label

Приклад: feature.node.kubernetes.io/network-sriov.capable: "true"

Використовується для: Node

Ці мітки використовуються компонентом виявлення функцій вузла (NFD), щоб оголошувати функції на вузлі. Усі вбудовані мітки використовують простір імен мітки feature.node.kubernetes.io та мають формат feature.node.kubernetes.io/<назва-функції>: "true". NFD має багато точок розширення для створення міток, специфічних для постачальника або застосунку. Для отримання детальної інформації дивіться посібник з налаштування.

nfd.node.kubernetes.io/master.version

Тип: Annotation

Приклад: nfd.node.kubernetes.io/master.version: "v0.6.0"

Використовується для: Node

Для вузлів, на яких заплановано master виявлення функцій вузла (NFD) , ця анотація записує версію майстра NFD. Вона використовується лише для інформаційних цілей.

nfd.node.kubernetes.io/worker.version

Тип: Annotation

Приклад: nfd.node.kubernetes.io/worker.version: "v0.4.0"

Використовується для: Nodes

Антоація записує версію робочого процесу виявлення функцій вузла (NFD), якщо він працює на вузлі. Вона використовується лише для інформаційних цілей.

nfd.node.kubernetes.io/feature-labels

Тип: Annotation

Приклад: nfd.node.kubernetes.io/feature-labels: "cpu-cpuid.ADX,cpu-cpuid.AESNI,cpu-hardware_multithreading,kernel-version.full"

Використовується для: Nodes

Ця анотація записує список міток функцій вузла, розділених комами, керованих виявленням функцій вузла (NFD). NFD використовує це для внутрішнього механізму. Ви не повинні редагувати цю анотацію самостійно.

nfd.node.kubernetes.io/extended-resources

Тип: Annotation

Приклад: nfd.node.kubernetes.io/extended-resources: "accelerator.acme.example/q500,example.com/coprocessor-fx5"

Використовується для: Nodes

Ця анотація зберігає розділені комами список розширених ресурсів, керованих виявленням функцій вузла (NFD). NFD використовує це для внутрішнього механізму. Ви не повинні редагувати цю анотацію самостійно.

nfd.node.kubernetes.io/node-name

Тип: Label

Приклад: nfd.node.kubernetes.io/node-name: node-1

Використовується для: Nodes

Мітка вказує, який вузол націлений обʼєкт NodeFeature. Творці обʼєктів NodeFeature повинні встановлювати цю мітку, а споживачі обʼєктів повинні використовувати її для фільтрації особливостей, призначених для певного вузла.

service.beta.kubernetes.io/aws-load-balancer-access-log-emit-interval (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-access-log-emit-interval: "5"

Використовується для: Service

Інтеграція менеджера контролера хмарних служб з AWS Elastic Load Balancing налаштовує балансувальник навантаження для Service на основі цієї анотації. Значення визначає, як часто балансувальник навантаження записує записи логу. Наприклад, якщо ви встановите значення на 5, записи логу будуть відбуватися з інтервалом у 5 секунд.

service.beta.kubernetes.io/aws-load-balancer-access-log-enabled (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-access-log-enabled: "false"

Використовується для: Service

Інтеграція менеджера контролера хмарних служб з AWS Elastic Load Balancing налаштовує балансувальник навантаження для Service на основі цієї анотації. Ведення логу доступу активується, якщо ви встановите анотацію на значення "true".

service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-access-log-enabled: example

Використовується для: Service

Інтеграція менеджера контролера хмарних служб з AWS Elastic Load Balancing налаштовує балансувальник навантаження для Service на основі цієї анотації. Балансувальник навантаження записує логи до корзини S3 з іменем, яке ви вказуєте.

service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-access-log-enabled: "/example"

Використовується для: Service

Інтеграція менеджера контролера хмарних служб з AWS Elastic Load Balancing налаштовує балансувальник навантаження для Service на основі цієї анотації. Балансувальник навантаження записує обʼєкти журналів з префіксом, який ви вказуєте.

service.beta.kubernetes.io/aws-load-balancer-additional-resource-tags (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-additional-resource-tags: "Environment=demo,Project=example"

Використовується для: Service

Інтеграція менеджера контролера хмарних служб з AWS Elastic Load Balancing налаштовує теґи (концепція AWS) для балансувальника навантаження на основі розділених комами пар ключ/значення у значенні цієї анотації.

service.beta.kubernetes.io/aws-load-balancer-alpn-policy (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-alpn-policy: HTTP2Optional

Використовується для: Service

Контролер балансувальника навантаження AWS використовує цю анотацію. Дивіться анотації у документації контролера балансувальника навантаження AWS.

service.beta.kubernetes.io/aws-load-balancer-attributes (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-attributes: "deletion_protection.enabled=true"

Використовується для: Service

Контролер балансувальника навантаження AWS використовує цю анотацію. Для отримання додаткової інформації дивіться анотації у документації контролера балансувальника навантаження AWS.

service.beta.kubernetes.io/aws-load-balancer-backend-protocol (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-backend-protocol: tcp

Використовується для: Service

Інтеграція менеджера контролера хмарних служб з AWS Elastic Load Balancing налаштовує прослуховувач балансувальника навантаження на основі значення цієї анотації.

service.beta.kubernetes.io/aws-load-balancer-connection-draining-enabled (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-connection-draining-enabled: "false"

Використовується для: Service

Інтеграція менеджера контролера хмарних служб з AWS Elastic Load Balancing налаштовує балансувальник навантаження на основі цієї анотації. Налаштування затримки зʼєднання балансувальника навантаження залежить від значення, яке ви встановлюєте.

service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout: "60"

Використовується для: Service

Якщо ви налаштовуєте затримку зʼєднання для Service з type: LoadBalancer, і ви використовуєте хмару AWS, інтеграція налаштовує період затримки на основі цієї анотації. Значення, яке ви встановлюєте, визначає тайм-аут затримки у секундах.

service.beta.kubernetes.io/aws-load-balancer-ip-address-type (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-ip-address-type: ipv4

Використовується для: Service

Контролер балансувальника навантаження AWS використовує цю анотацію. Дивіться анотації у документації контролера балансувальника навантаження AWS.

service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout: "60"

Використовується для: Service

Інтеграція менеджера контролера хмарних служб з AWS Elastic Load Balancing налаштовує балансувальник навантаження на основі цієї анотації. Балансувальник має налаштований період тайм-ауту бездіяльності (у секундах), який застосовується до його зʼєднань. Якщо протягом періоду тайм-ауту бездіяльності не було відправлено або отримано жодних даних, балансувальник закриває зʼєднання.

service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled: "true"

Використовується для: Service

Інтеграція менеджера контролера хмарних служб з AWS Elastic Load Balancing налаштовує балансувальник навантаження на основі цієї анотації. Якщо ви встановите цю анотацію в значення "true", кожен вузол балансувальника навантаження розподіляє запити рівномірно серед зареєстрованих цілей у всіх увімкнених зонах доступності. Якщо ви вимкнете перехресне балансування зон, кожен вузол балансувальника навантаження розподіляє запити рівномірно серед зареєстрованих цілей лише у своїй зоні доступності.

service.beta.kubernetes.io/aws-load-balancer-eip-allocations (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-eip-allocations: "eipalloc-01bcdef23bcdef456,eipalloc-def1234abc4567890"

Використовується для: Service

Інтеграція менеджера контролера хмарних служб з AWS Elastic Load Balancing налаштовує балансувальник навантаження на основі цієї анотації. Значення є розділеним комами списком ідентифікаторів виділення еластичних IP-адрес.

Ця анотація має сенс тільки для Service з type: LoadBalancer, де балансувальник навантаження є мережевим балансувальником AWS.

service.beta.kubernetes.io/aws-load-balancer-extra-security-groups (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-extra-security-groups: "sg-12abcd3456,sg-34dcba6543"

Використовується для: Service

Інтеграція менеджера контролера хмарних служб з AWS Elastic Load Balancing налаштовує балансувальник навантаження на основі цієї анотації. Значення анотації є розділеним комами списком додаткових груп безпеки AWS VPC для налаштування балансувальника навантаження.

service.beta.kubernetes.io/aws-load-balancer-healthcheck-healthy-threshold (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-healthcheck-healthy-threshold: "3"

Використовується для: Service

Інтеграція менеджера контролера хмарних служб з AWS Elastic Load Balancing налаштовує балансувальник навантаження на основі цієї анотації. Значення анотації визначає кількість послідовних успішних перевірок стану для бекенду, щоб вважати його справним для передавання трафіку.

service.beta.kubernetes.io/aws-load-balancer-healthcheck-interval (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-healthcheck-interval: "30"

Використовується для: Service

Інтеграція менеджера контролера хмарних служб з AWS Elastic Load Balancing налаштовує балансувальник навантаження на основі цієї анотації. Значення анотації визначає інтервал, в секундах, між запитами перевірки стану, які виконує балансувальник навантаження.

service.beta.kubernetes.io/aws-load-balancer-healthcheck-path (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-healthcheck-path: /healthcheck

Використовується для: Service

Інтеграція менеджера контролера хмарних служб з AWS Elastic Load Balancing налаштовує балансувальник навантаження на основі цієї анотації. Значення анотації визначає частину шляху URL, яка використовується для HTTP перевірок стану.

service.beta.kubernetes.io/aws-load-balancer-healthcheck-port (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-healthcheck-port: "24"

Використовується для: Service

Інтеграція менеджера контролера хмарних служб з AWS Elastic Load Balancing налаштовує балансувальник навантаження на основі цієї анотації. Значення анотації визначає порт, до якого підключається балансувальник навантаження під час виконання перевірок стану.

service.beta.kubernetes.io/aws-load-balancer-healthcheck-protocol (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-healthcheck-protocol: TCP

Використовується для: Service

Інтеграція менеджера контролера хмарних служб з AWS Elastic Load Balancing налаштовує балансувальник навантаження на основі цієї анотації. Значення анотації визначає спосіб, яким балансувальник навантаження перевіряє стан бекендів.

service.beta.kubernetes.io/aws-load-balancer-healthcheck-timeout (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-healthcheck-timeout: "3"

Використовується для: Service

Інтеграція менеджера контролера хмарних служб з AWS Elastic Load Balancing налаштовує балансувальник навантаження на основі цієї анотації. Значення анотації вказує кількість секунд до того, як запит, який ще не вдався, автоматично вважається неуспішним.

service.beta.kubernetes.io/aws-load-balancer-healthcheck-unhealthy-threshold (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-healthcheck-unhealthy-threshold: "3"

Використовується для: Service

Інтеграція менеджера контролера хмарних служб з AWS Elastic Load Balancing налаштовує балансувальник навантаження на основі цієї анотації. Значення анотації визначає кількість послідовних невдалих перевірок стану, необхідних для того, щоб бекенд вважася несправним для передачі трафіку.

service.beta.kubernetes.io/aws-load-balancer-internal (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-internal: "true"

Використовується для: Service

Інтеграція менеджера контролера хмарних служб з AWS Elastic Load Balancing налаштовує балансувальник навантаження на основі цієї анотації. Коли ви встановлюєте цю анотацію у значення "true", інтеграція налаштовує внутрішній балансувальник навантаження.

Якщо ви використовуєте контролер балансувальника навантаження AWS, дивіться service.beta.kubernetes.io/aws-load-balancer-scheme.

service.beta.kubernetes.io/aws-load-balancer-manage-backend-security-group-rules (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-manage-backend-security-group-rules: "true"

Використовується для: Service

Контролер балансувальника навантаження AWS використовує цю анотацію. Дивіться анотації у документації контролера балансувальника навантаження AWS.

service.beta.kubernetes.io/aws-load-balancer-name (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-name: my-elb

Використовується для: Service

Якщо ви встановлюєте цю анотацію на Service, і також анотуєте цей Service з service.beta.kubernetes.io/aws-load-balancer-type: "external", і ви використовуєте контролер балансувальника навантаження AWS у вашому кластері, тоді контролер балансувальника навантаження AWS встановлює назву цього балансувальника на значення, яке ви встановлюєте для цієї анотації.

Дивіться анотації у документації контролера балансувальника навантаження AWS.

service.beta.kubernetes.io/aws-load-balancer-nlb-target-type (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: "true"

Використовується для: Service

Контролер балансувальника навантаження AWS використовує цю анотацію. Дивіться анотації у документації контролера балансувальника навантаження AWS.

service.beta.kubernetes.io/aws-load-balancer-private-ipv4-addresses (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-private-ipv4-addresses: "198.51.100.0,198.51.100.64"

Використовується для: Service

Контролер балансувальника навантаження AWS використовує цю анотацію. Дивіться анотації у документації контролера балансувальника навантаження AWS.

service.beta.kubernetes.io/aws-load-balancer-proxy-protocol (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-proxy-protocol: "*"

Використовується для: Service

Офіційна інтеграція Kubernetes з AWS Elastic Load Balancing налаштовує балансувальник навантаження на основі цієї анотації. Єдине допустиме значення — "*", що вказує на те, що балансувальник навантаження повинен обгортати TCP-зʼєднання до бекенду Pod за допомогою протоколу PROXY.

service.beta.kubernetes.io/aws-load-balancer-scheme (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-scheme: internal

Використовується для: Service

Контролер балансувальника навантаження AWS використовує цю анотацію. Дивіться анотації у документації контролера балансувальника навантаження AWS.

service.beta.kubernetes.io/aws-load-balancer-security-groups (deprecated)

Приклад: service.beta.kubernetes.io/aws-load-balancer-security-groups: "sg-53fae93f,sg-8725gr62r"

Використовується для: Service

Контролер балансувальника навантаження AWS використовує цю анотацію для вказівки розділеного комами списку груп безпеки, які ви хочете прикріпити до балансувальника навантаження AWS. Підтримуються як імʼя, так і ID груп безпеки, де імʼя відповідає тегу Name, а не атрибуту groupName.

Коли ця анотація додається до Service, контролер балансувальника навантаження прикріплює групи безпеки, на які вказує анотація, до балансувальника навантаження. Якщо ви пропускаєте цю анотацію, контролер балансувальника навантаження AWS автоматично створює нову групу безпеки і прикріплює її до балансувальника навантаження.

service.beta.kubernetes.io/load-balancer-source-ranges (deprecated)

Приклад: service.beta.kubernetes.io/load-balancer-source-ranges: "192.0.2.0/25"

Використовується для: Service

Контролер балансувальника навантаження AWS використовує цю анотацію. Вам слід встановити .spec.loadBalancerSourceRanges для Service замість цього.

service.beta.kubernetes.io/aws-load-balancer-ssl-cert (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-ssl-cert: "arn:aws:acm:us-east-1:123456789012:certificate/12345678-1234-1234-1234-123456789012"

Використовується для: Service

Офіційна інтеграція з AWS Elastic Load Balancing налаштовує TLS для Service з type: LoadBalancer на основі цієї анотації. Значення анотації — це імʼя ресурсу AWS (ARN) сертифіката X.509, який повинен використовувати прослуховувач балансувальника навантаження.

(Протокол TLS базується на старій технології, яка скорочується до SSL.)

service.beta.kubernetes.io/aws-load-balancer-ssl-negotiation-policy (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-ssl-negotiation-policy: ELBSecurityPolicy-TLS-1-2-2017-01

Офіційна інтеграція з AWS Elastic Load Balancing налаштовує TLS для Service з type: LoadBalancer на основі цієї анотації. Значення анотації — це імʼя політики AWS для взаємодії TLS з клієнтом.

service.beta.kubernetes.io/aws-load-balancer-ssl-ports (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-ssl-ports: "*"

Офіційна інтеграція з AWS Elastic Load Balancing налаштовує TLS для Service з type: LoadBalancer на основі цієї анотації. Значення анотації може бути або "*", що означає, що всі порти балансувальника навантаження повинні використовувати TLS, або це може бути розділений комами список номерів портів.

service.beta.kubernetes.io/aws-load-balancer-subnets (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-subnets: "private-a,private-b"

Офіційна інтеграція Kubernetes з AWS використовує цю анотацію для налаштування балансувальника навантаження та визначення, в яких зонах доступності AWS розгорнути керовану службу балансування навантаження. Значення може бути або розділений комами список імен підмереж, або розділений комами список ідентифікаторів підмереж.

service.beta.kubernetes.io/aws-load-balancer-target-group-attributes (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-target-group-attributes: "stickiness.enabled=true,stickiness.type=source_ip"

Використовується для: Service

Контролер балансувальника навантаження AWS використовує цю анотацію. Дивіться анотації у документації контролера балансувальника навантаження AWS.

service.beta.kubernetes.io/aws-load-balancer-target-node-labels (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-target-node-labels: "kubernetes.io/os=Linux,topology.kubernetes.io/region=us-east-2"

Офіційна інтеграція Kubernetes з AWS використовує цю анотацію для визначення, які вузли у вашому кластері повинні бути розглянуті як дійсні цілі для балансувальника навантаження.

service.beta.kubernetes.io/aws-load-balancer-type (beta)

Приклад: service.beta.kubernetes.io/aws-load-balancer-type: external

Офіційні інтеграції Kubernetes з AWS використовують цю анотацію для визначення того, чи має інтеграція з хмарним провайдером AWS керувати Service з type: LoadBalancer.

Є два допустимі значення:

nlb
менеджер контролера хмарних послуг налаштовує мережевий балансувальник навантаження
external
менеджер контролера хмарних послуг не налаштовує жодного балансувальника навантаження

Якщо ви розгортаєте Service з type: LoadBalancer на AWS і не встановлюєте жодної анотації service.beta.kubernetes.io/aws-load-balancer-type, інтеграція з AWS розгортатиме класичний балансувальник навантаження Elastic Load Balancer. Ця поведінка, коли анотація відсутня, є типовою, якщо ви не вказуєте інше.

Коли ви встановлюєте цю анотацію на значення external на Service з type: LoadBalancer, а у вашому кластері є працюючий deployment контролера балансувальника навантаження AWS, то контролер балансувальника навантаження AWS намагатиметься розгорнути балансувальник навантаження на основі специфікації Service.

service.beta.kubernetes.io/azure-load-balancer-disable-tcp-reset (deprecated)

Приклад: service.beta.kubernetes.io/azure-load-balancer-disable-tcp-reset: "false"

Використовується для: Service

Ця анотація працює лише для Service, підтримуваних стандартним балансувальником навантаження Azure. Вона використовується у Service для вказівки, чи слід вимикати або вмикати скидання TCP при бездіяльності. Якщо увімкнено, це допомагає застосункам працювати більш передбачувано, виявляти обриви зʼєднання, видаляти застарілі зʼєднання та ініціювати нові. Ви можете встановити значення як true або false.

Дивіться Скидання TCP балансувальника навантаження для отримання додаткової інформації.

pod-security.kubernetes.io/enforce

Тип: Label

Приклад: pod-security.kubernetes.io/enforce: "baseline"

Використовується для: Namespace

Значення обовʼязково повинно бути одним із privileged, baseline або restricted, що відповідає рівням стандарту безпеки для Podʼів. Зокрема, мітка enforce забороняє створення будь-якого Podʼа у позначеному просторі імен, який не відповідає вимогам, визначеним на вказаному рівні.

Для отримання додаткової інформації перегляньте Застосування безпеки Podʼів на рівні простору імен.

pod-security.kubernetes.io/enforce-version

Тип: Label

Приклад: pod-security.kubernetes.io/enforce-version: "1.31"

Використовується для: Namespace

Значення має бути latest або дійсна версія Kubernetes у форматі v<major>.<minor>. Це визначає версію політик стандарту безпеки для Podʼів, які застосовуються при перевірці Podʼа.

Для отримання додаткової інформації дивіться Застосування безпеки Podʼів на рівні простору імен.

pod-security.kubernetes.io/audit

Тип: Label

Приклад: pod-security.kubernetes.io/audit: "baseline"

Використовується для: Namespace

Значення має бути одним із privileged, baseline або restricted, що відповідають рівням стандарту безпеки для Podʼів. Зокрема, мітка audit не перешкоджає створенню Podʼа у позначеному просторі імен, який не відповідає вимогам, визначеним на вказаному рівні, але додає цю анотацію до Podʼа.

Для отримання додаткової інформації дивіться Застосування безпеки Podʼів на рівні простору імен.

pod-security.kubernetes.io/audit-version

Тип: Label

Приклад: pod-security.kubernetes.io/audit-version: "1.31"

Використовується для: Namespace

Значення повинно бути latest або дійсна версія Kubernetes у форматі v<major>.<minor>. Це визначає версію політик стандарту безпеки для Podʼів, які застосовуються під час перевірки Podʼа.

Для отримання додаткової інформації дивіться Застосування безпеки Podʼів на рівні простору імен.

pod-security.kubernetes.io/warn

Тип: Label

Приклад: pod-security.kubernetes.io/warn: "baseline"

Використовується для: Namespace

Значення має бути одним із privileged, baseline або restricted, що відповідають рівням стандарту безпеки для Podʼів. Зокрема, мітка warn не перешкоджає створенню Podʼа у позначеному просторі імен, який не відповідає вимогам, визначеним на вказаному рівні, але повертає попередження користувачу після цього.

Зверніть увагу, що попередження також відображаються при створенні або оновленні обʼєктів, які містять шаблони Podʼа, такі як Deployments, Jobs, StatefulSets тощо.

Для отримання додаткової інформації дивіться Застосування безпеки Podʼів на рівні простору імен.

pod-security.kubernetes.io/warn-version

Тип: Label

Приклад: pod-security.kubernetes.io/warn-version: "1.31"

Використовується для: Namespace

Значення повинно бути latest або дійсна версія Kubernetes у форматі v<основний>.<додатковий>. Це визначає версію політик стандарту безпеки для Podʼів, які застосовуються при перевірці поданих Podʼів. Зверніть увагу, що попередження також відображаються при створенні або оновленні обʼєктів, які містять шаблони Podʼа, такі як Deployments, Jobs, StatefulSets тощо.

Для отримання додаткової інформації дивіться Застосування безпеки Podʼів на рівні простору імен.

rbac.authorization.kubernetes.io/autoupdate

Тип: Annotation

Приклад: rbac.authorization.kubernetes.io/autoupdate: "false"

Використовується для: ClusterRole, ClusterRoleBinding, Role, RoleBinding

Коли ця анотація встановлена на стандартне значення "true" на обʼєктах RBAC, створених сервером API, вони автоматично оновлюються при запуску сервера для додавання відсутніх дозволів та субʼєктів (додаткові дозволи та субʼєкти залишаються на місці). Щоб запобігти автоматичному оновленню певної ролі або привʼязки ролі, встановіть цю анотацію у значення "false". Якщо ви створюєте власні обʼєкти RBAC і встановлюєте цю анотацію у значення "false", kubectl auth reconcile (який дозволяє узгоджувати довільні обʼєкти RBAC у маніфесті) враховує цю анотацію і автоматично не додає відсутні дозволи та субʼєкти.

kubernetes.io/psp (deprecated)

Тип: Annotation

Приклад: kubernetes.io/psp: restricted

Використовується для: Pod

Ця анотація була актуальною лише у випадку використання обʼєктів PodSecurityPolicy. Kubernetes v1.31 не підтримує API PodSecurityPolicy.

Коли контролер допуску PodSecurityPolicy дав дозвіл Podʼу, він модифікував Pod так, щоб мати цю анотацію. Значення анотації було імʼям PodSecurityPolicy, яке використовувалось для валідації.

seccomp.security.alpha.kubernetes.io/pod (non-functional)

Тип: Annotation

Використовується для: Pod

Кубернетес до версії 1.25 дозволяв вам налаштовувати поведінку seccomp за допомогою цієї анотації. Див. Обмеження системних викликів контейнера за допомогою seccomp, щоб дізнатися, як вказувати обмеження seccomp для Pod.

container.seccomp.security.alpha.kubernetes.io/[NAME] (non-functional)

Тип: Annotation

Використовується для: Pod

До версії 1.25 Kubernetes дозволяв налаштовувати поведінку seccomp за допомогою цієї анотації. Дивіться Обмеження системних викликів контейнера за допомогою seccomp, щоб дізнатися підтримуваний спосіб вказування обмежень seccomp для Pod.

snapshot.storage.kubernetes.io/allow-volume-mode-change

Тип: Annotation

Приклад: snapshot.storage.kubernetes.io/allow-volume-mode-change: "true"

Використовується для: VolumeSnapshotContent

Значення може бути або true, або false. Це визначає, чи може користувач змінювати режим джерельного тому при створенні PersistentVolumeClaim із VolumeSnapshot.

Зверніться до Зміна режиму тому знімка та Документації розробника Kubernetes CSI для отримання додаткової інформації.

scheduler.alpha.kubernetes.io/critical-pod (deprecated)

Тип: Annotation

Приклад: scheduler.alpha.kubernetes.io/critical-pod: ""

Використовується для: Pod

Ця анотація повідомляє панель управління Kubernetes, що Pod є критичним, щоб descheduler не видаляв цей Pod.

Анотації, що використовуються для аудиту

Дивіться більше деталей на сторінці Анотації аудиту.

kubeadm

kubeadm.alpha.kubernetes.io/cri-socket

Тип: Annotation

Приклад: kubeadm.alpha.kubernetes.io/cri-socket: unix:///run/containerd/container.sock

Використовується для: Node

Анотація, яку kubeadm використовує для збереження інформації про сокет CRI, наданої kubeadm під час init/join для подальшого використання. kubeadm додає цю інформацію як анотацію до обʼєкта Node. Ця анотація залишається "альфа", оскільки в ідеалі це має бути поле в KubeletConfiguration.

kubeadm.kubernetes.io/etcd.advertise-client-urls

Тип: Annotation

Приклад: kubeadm.kubernetes.io/etcd.advertise-client-urls: https://172.17.0.18:2379

Використовується для: Pod

Анотація, яку kubeadm додає до локально керованих Podʼів etcd для відстеження списку URL-адрес, до яких повинні підключатися клієнти etcd. Це використовується головним чином для перевірки стану справності кластера etcd.

kubeadm.kubernetes.io/kube-apiserver.advertise-address.endpoint

Тип: Annotation

Приклад: kubeadm.kubernetes.io/kube-apiserver.advertise-address.endpoint: https://172.17.0.18:6443

Використовується для: Pod

Анотація, яку kubeadm додає до локально керованих Podʼів kube-apiserver для відстеження оголошеної адреси/порту для цього екземпляра API-сервера.

kubeadm.kubernetes.io/component-config.hash

Тип: Annotation

Приклад: kubeadm.kubernetes.io/component-config.hash: 2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae

Використовується для: ConfigMap

Анотація, яку kubeadm додає до ConfigMapʼів, що ним керуються для налаштування компонентів. Вона містить хеш (SHA-256), який використовується для визначення, чи застосував користувач налаштування, відмінні від стандартних налаштувань для конкретного компонента.

node-role.kubernetes.io/control-plane

Тип: Label

Використовується для: Node

Мітка-маркер, що вказує, що вузол використовується для запуску компонентів панелі управління. Інструмент kubeadm застосовує цю мітку до вузлів панелі управління, якими він керує. Інші інструменти управління кластером зазвичай також встановлюють це позачення.

Ви можете позначити вузли панелі управління цією міткою, щоб спростити розміщення Podʼів лише на цих вузлах або уникнути запуску Podʼів на панелі управління. Якщо ця мітка встановлена, контролер EndpointSlice ігнорує цей вузол під час розрахунку підказок, що враховують топологію.

node-role.kubernetes.io/control-plane

Тип: Taint

Приклад: node-role.kubernetes.io/control-plane:NoSchedule

Використовується для: Node

Позначення, що kubeadm накладає на вузли панелі управління для обмеження розміщення Podʼів і дозволяє розміщувати на них лише певні Podʼи.

Якщо це позначення застосовано, вузли панелі управління дозволяють розміщувати у себе лише критичні навантаження. Ви можете видалити це позначення вручну за допомогою такої команди на відповідному вузлі.

kubectl taint nodes <node-name> node-role.kubernetes.io/control-plane:NoSchedule-

node-role.kubernetes.io/master (deprecated)

Тип: Taint

Використовується для: Node

Приклад: node-role.kubernetes.io/master:NoSchedule

Позначення, що раніше kubeadm застосовував на вузли панелі управління, щоб дозволити розміщувати на них лише критичні навантаження. Замінений позначенням node-role.kubernetes.io/control-plane. kubeadm більше не встановлює або не використовує це застаріле позначення.

6.4.1 - Анотації аудиту

Ця сторінка служить довідником по анотаціях аудиту простору імен kubernetes.io. Ці анотації застосовуються до обʼєктів Event з API-групи audit.k8s.io.

k8s.io/deprecated

Приклад: k8s.io/deprecated: "true"

Значення повинно бути "true" або "false". Значення "true" вказує на те, що в запит використовував застарілу версію API.

k8s.io/removed-release

Приклад: k8s.io/removed-release: "1.22"

Значення повинно бути у форматі ".". Встановлюється на цільовий випуск видалення на запити до застарілих версій API з цільовим випуском видалення.

pod-security.kubernetes.io/exempt

Приклад: pod-security.kubernetes.io/exempt: namespace

Значення повинно бути одним із user, namespace або runtimeClass, що відповідає вимогам виключень безпеки Pod. Ця анотація вказує на те, на чому засновано виключення з дотримання безпеки Pod.

pod-security.kubernetes.io/enforce-policy

Приклад: pod-security.kubernetes.io/enforce-policy: restricted:latest

Значення повинно бути privileged:<version>, baseline:<version>, restricted:<version>, що відповідає рівням стандарту безпеки Pod, супроводжуваних версією, яка повинна бути latest або дійсною версією Kubernetes у форматі v<MAJOR>.<MINOR>. Ця анотація надає інформацію про рівень виконання, який дозволив або відхилив Pod під час допуску PodSecurity.

Див. Стандарти безпеки Pod для отримання додаткової інформації.

pod-security.kubernetes.io/audit-violations

Приклад: pod-security.kubernetes.io/audit-violations: would violate PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "example" must set securityContext.allowPrivilegeEscalation=false), ...

Значення деталізує порушення аудиту політики, воно містить рівень стандарту безпеки Pod, який був порушений, а також конкретні політики з полів, які були порушені з дотримання безпеки Pod.

Див. Стандарти безпеки Pod для отримання додаткової інформації.

authorization.k8s.io/decision

Приклад: authorization.k8s.io/decision: "forbid"

Значення має бути forbid або allow. Ця анотація вказує на те, чи було дозволено запит у логах аудиту Kubernetes.

Див. Аудит для отримання додаткової інформації.

authorization.k8s.io/reason

Приклад: authorization.k8s.io/reason: "Людиночитана причина рішення"

Ця анотація вказує причину для рішення в логах аудиту Kubernetes.

Див. Аудит для отримання додаткової інформації.

missing-san.invalid-cert.kubernetes.io/$hostname

Приклад: missing-san.invalid-cert.kubernetes.io/example-svc.example-namespace.svc: "покладається на застаріле поле загального імені замість розширення SAN для перевірки субʼєкта"

Використовується у Kubernetes версії v1.24 та пізніше.

Ця анотація вказує, що вебхук або агрегований API-сервер використовує недійсний сертифікат, у якого відсутні subjectAltNames. Підтримка цих сертифікатів відключена у Kubernetes 1.19 та видалена у Kubernetes 1.23.

Запити до точок доступу, які використовують ці сертифікати, будуть невдалими. Serviceʼи, які використовують ці сертифікати, повинні замінити їх якомога швидше, щоб уникнути перерви у роботі при використанні середовищ Kubernetes 1.23+.

Додаткову інформацію можна знайти в документації Go: Відключення загального імені X.509.

insecure-sha1.invalid-cert.kubernetes.io/$hostname

Приклад: insecure-sha1.invalid-cert.kubernetes.io/example-svc.example-namespace.svc: "використовує небезпечний підпис SHA-1"

Використовується у Kubernetes версії v1.24 та пізніше.

Ця анотація вказує, що вебхук або агрегований API-сервер використовує недійсний сертифікат, підписаний небезпечним хешем SHA-1. Підтримка цих небезпечних сертифікатів відключена у Kubernetes 1.24 та буде видалена в майбутніх версіях.

Serviceʼи, які використовують ці сертифікати, повинні замінити їх якнайшвидше, щоб забезпечити належну безпеку зʼєднань та уникнути перебоїв у майбутніх випусках.

Додаткову інформацію можна знайти в документації Go: Відхилення сертифікатів SHA-1.

validation.policy.admission.k8s.io/validation_failure

Приклад: validation.policy.admission.k8s.io/validation_failure: '[{"message": "Недійсне значення", {"policy": "policy.example.com", {"binding": "policybinding.example.com", {"expressionIndex": "1", {"validationActions": ["Audit"]}]'

Використовується у Kubernetes версії v1.27 та пізніше.

Ця анотація вказує, що перевірка політики допуску не вдалася для запиту API або що перевірка призвела до помилки, коли політика була налаштована з failurePolicy: Fail.

Значення анотації є обʼєктом JSON. message у JSON надає повідомлення про невдачу перевірки.

policy, binding і expressionIndex в JSON ідентифікують імʼя ValidatingAdmissionPolicy, імʼя ValidatingAdmissionPolicyBinding та індекс у політиці validations виразів CEL, які не вдалося, відповідно.

validationActions показують, які дії були вжиті для цієї невдачі перевірки. Див. Політика валідації допуску для отримання додаткових відомостей щодо validationActions.

6.5 - API Kubernetes

API Kubernetes це застосунок, який обслуговує функціонал Kubernetes через RESTful інтерфейс та зберігає стан кластера.

Ресурси Kubernetes та "записи про наміри" зберігаються як обʼєкти API та модифікуються за допомогою RESTful викликів до API. API дозволяє керувати конфігурацією декларативним способом. Користувачі можуть взаємодіяти з API Kubernetes безпосередньо або за допомогою інструментів, таких як kubectl. Ядро API Kubernetes є гнучким та може бути розширено для підтримки власних ресурсів користувачів.

6.5.1 - Ресурси робочих навантажень

6.5.1.1 - Pod

Pod — це колекція контейнерів, які можуть запускатися на одному хості.

apiVersion: v1

import "k8s.io/api/core/v1"

Pod

Pod є колекцією контейнерів, які можуть працювати на одному хості. Цей ресурс створюється клієнтами та розміщується на хостах.


PodSpec

PodSpec — це опис Pod.


Контейнери

  • containers ([]Container), обовʼязково

    Patch strategy: злиття за ключем name

    Map: унікальні значення ключа name будуть збережені під час злиття

    Список контейнерів, що належать Podʼу. Зараз контейнери не можуть бути додані або видалені. В Podʼі повинен бути принаймні один контейнер. Не може бути оновлено.

  • initContainers ([]Container)

    Patch strategy: злиття за ключем name

    Map: унікальні значення ключа name будуть збережені під час злиття

    Список контейнерів ініціалізації, що належать Podʼу. Контейнери ініціалізації виконуються у визначеному порядку перед запуском звичайних контейнерів. Якщо будь-який контейнер ініціалізації зазнає збою, Pod вважається збійним та обробляється відповідно до restartPolicy. Імʼя контейнера ініціалізації або звичайного контейнера повинно бути унікальним серед усіх контейнерів. Контейнери ініціалізації не можуть мати дій Lifecycle, Readiness probes, Liveness probes, або Startup probes. resourceRequirements контейнера ініціалізації враховуються під час планування, знаходячи найбільше значення запиту/ліміту для кожного типу ресурсів, а потім використовуючи максимум цього значення або суму цих значень для звичайних контейнерів. Ліміти застосовуються до контейнерів ініціалізації аналогічним чином. Контейнери ініціалізації зараз не можуть бути додані або видалені. Не може бути оновлено. Докладніше: https://kubernetes.io/docs/concepts/workloads/pods/init-containers/

  • ephemeralContainers ([]EphemeralContainer)

    Patch strategy: злиття за ключем name

    Map: унікальні значення ключа name будуть збережені під час злиття

    Список ефемерних контейнерів, що запущені у цьому Pod. Ефемерні контейнери можуть бути запущені в наявному Podʼі для виконання дій, ініційованих користувачем, таких як налагодження. Цей список не може бути вказаний при створенні Podʼа, і його не можна змінити, оновивши специфікацію Podʼа. Щоб додати ефемерний контейнер до наявного Podʼа, використовуйте субресурс ефемерних контейнерів Podʼа.

  • imagePullSecrets ([]LocalObjectReference)

    Patch strategy: злиття за ключем name

    Map: унікальні значення ключа name будуть збережені під час злиття

    ImagePullSecrets — це необовʼязково список посилань на Secretʼи у тому ж просторі імен, які використовуються для отримання будь-яких образів, що використовуються у цьому PodSpec. Якщо вказано, ці Secretʼи будуть передані індивідуальним реалізаціям отримувачів для їх використання. Докладніше: https://kubernetes.io/docs/concepts/containers/images#specifying-imagepullsecrets-on-a-pod

  • enableServiceLinks (boolean)

    EnableServiceLinks вказує, чи слід впроваджувати інформацію про Serviceʼи у змінні середовища Pod, відповідно до синтаксису Docker посилань. Необовʼязково: стандартне значення — true.

  • os (PodOS)

    PodOS визначає параметри операційної системи Pod.

    Якщо в поле OS встановлено значення linux, наступні поля не повинні бути встановлені:

    • securityContext.windowsOptions

    Якщо в поле OS встановлено значення windows, наступні поля не повинні бути встановлені:

    • spec.hostPID
    • spec.hostIPC
    • spec.hostUsers
    • spec.securityContext.appArmorProfile
    • spec.securityContext.seLinuxOptions
    • spec.securityContext.seccompProfile
    • spec.securityContext.fsGroup
    • spec.securityContext.fsGroupChangePolicy
    • spec.securityContext.sysctls
    • spec.shareProcessNamespace
    • spec.securityContext.runAsUser
    • spec.securityContext.runAsGroup
    • spec.securityContext.supplementalGroups
    • spec.securityContext.supplementalGroupsPolicy
    • spec.containers[*].securityContext.appArmorProfile
    • spec.containers[*].securityContext.seLinuxOptions
    • spec.containers[*].securityContext.seccompProfile
    • spec.containers[*].securityContext.capabilities
    • spec.containers[*].securityContext.readOnlyRootFilesystem
    • spec.containers[*].securityContext.privileged
    • spec.containers[*].securityContext.allowPrivilegeEscalation
    • spec.containers[*].securityContext.procMount
    • spec.containers[*].securityContext.runAsUser
    • spec.containers[*].securityContext.runAsGroup

    PodOS визначає параметри операційної системи Pod.

    • os.name (string), обовʼязково

      Name — це назва операційної системи. Поточні підтримувані значення — linux і windows. Додаткове значення може бути визначено у майбутньому і може бути одним з: https://github.com/opencontainers/runtime-spec/blob/master/config.md#platform-specific-configuration. Клієнти повинні очікувати обробку додаткових значень і розглядати нерозпізнані значення у цьому полі як os: null.

Томи

  • volumes ([]Volume)

    Patch strategies: retainKeys, обʼєднання по ключу name

    Map: унікальні значення ключа name будуть збережені під час злиття

    Список томів, які можуть бути змонтовані контейнерами, що належать Podʼу. Докладніше: https://kubernetes.io/docs/concepts/storage/volumes

Планування

  • nodeSelector (map[string]string)

    NodeSelector — це селектор, який має бути істинним, щоб Pod підходив для вузла. Селектор, який має відповідати міткам вузла для планування Podʼа на цьому вузлі. Докладніше: https://kubernetes.io/docs/concepts/configuration/assign-pod-node/

  • nodeName (string)

    Поле NodeName вказує, на якому вузлі (node) заплановано запуск цього podʼа. Якщо це поле порожнє, pod є кандидатом для планування за допомогою планувальника, визначеного в полі schedulerName. Після того як це поле встановлено, kubelet цього вузла стає відповідальним за життєвий цикл podʼа. Це поле не слід використовувати для вираження бажання запустити pod на конкретному вузлі. Детальніше: https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#nodename

  • affinity (Affinity)

    Якщо вказано, це обмеження на планування Podʼа.

    Affinity — це група правил планування з урахуванням спорідненості.

    • affinity.nodeAffinity (NodeAffinity)

      Описує правила планування Podʼа з урахуванням спорідненості до вузла.

    • affinity.podAffinity (PodAffinity)

      Описує правила планування Podʼа з урахуванням спорідненості до інших Podʼів (наприклад, розташувати цей Pod на тому ж вузлі, у тій же зоні тощо, що й інші Podʼи).

    • affinity.podAntiAffinity (PodAntiAffinity)

      Описує правила планування Podʼа з урахуванням анти-спорідненості до інших Podʼів (наприклад, уникати розташування цього Podʼа на тому ж вузлі, у тій же зоні тощо, що й інші Podʼи).

  • tolerations ([]Toleration)

    Atomic: буде замінено під час злиття

    Якщо вказано, визначає толерантності Podʼа.

    Pod, до якого прикріплено цю толерантність, толерує будь-який taint, який відповідає трійці <key,value,effect> за допомогою оператора зіставлення .

    • tolerations.key (string)

      Ключ taint, до якого застосовується толерантність. Порожнє значення означає відповідність усім ключам taint. Якщо ключ порожній, оператор має бути Exists; ця комбінація означає відповідність усім значенням та ключам.

    • tolerations.operator (string)

      Оператор, що представляє стосунок ключа до значення. Допустимі оператори — Exists та Equal. Стандартне значення — Equal. Exists еквівалентний знаку підстановки для значення, щоб Pod міг толерувати всі taint певної категорії.

    • tolerations.value (string)

      Значення taint, до якого застосовується толерантність. Якщо оператор Exists, значення має бути порожнім, в іншому випадку — це звичайний рядок.

    • tolerations.effect (string)

      Ефект, до якого застосовується толерантність. Порожнє значення означає відповідність усім ефектам taint. Допустимі значення: NoSchedule, PreferNoSchedule та NoExecute.

    • tolerations.tolerationSeconds (int64)

      TolerationSeconds визначає період часу, протягом якого толерантність (яка має бути з ефектом NoExecute, інакше це поле ігнорується) толерує taint. Стандартно не встановлюється, що означає виконувати толерування taint назавжди (не видаляти). Нульові та відʼємні значення система обробляє як 0 (негайне видалення).

  • schedulerName (string)

    Якщо вказано, Pod буде оброблено вказаним планувальником. Якщо не вказано, Pod буде оброблено стандартним планувальником.

  • runtimeClassName (string)

    RuntimeClassName посилається на обʼєкт RuntimeClass у групі node.k8s.io, який повинен бути використаний для запуску цього Podʼа. Якщо жоден ресурс RuntimeClass не відповідає названому класу, Pod не буде запущено. Якщо не встановлено або порожнє, буде використано "старий" RuntimeClass, який є неявним класом з порожнім визначенням, що використовує стандартний обробник середовища. Детальніше: https://git.k8s.io/enhancements/keps/sig-node/585-runtime-class

  • priorityClassName (string)

    Якщо вказано, вказує на пріоритет Podʼа. "system-node-critical" та "system-cluster-critical" — це два спеціальні ключові слова, які вказують на найвищі пріоритети, причому перший має найвищий пріоритет. Будь-яке інше імʼя має бути визначене шляхом створення обʼєкта PriorityClass з цим імʼям. Якщо не вказано, пріоритет Podʼа буде стандартним або нульовим, якщо немає стандартного значення.

  • priority (int32)

    Значення пріоритету. Різні системні компоненти використовують це поле для визначення пріоритету Podʼа. Коли включено контролер доступу до пріоритетів (Priority Admission Controller), він не дозволяє користувачам встановлювати це поле. Контролер доступу заповнює це поле з PriorityClassName. Чим вище значення, тим вищий пріоритет.

  • preemptionPolicy (string)

    PreemptionPolicy — це політика випередження для Podʼів з нижчим пріоритетом. Одне з: Never чи PreemptLowerPriority. Стандартне значення — PreemptLowerPriority, якщо не встановлено.

  • topologySpreadConstraints ([]TopologySpreadConstraint)

    Patch strategy: об’єднання за ключем topologyKey

    Map: під час об’єднання будуть збережені унікальні значення за ключами topologyKey, whenUnsatisfiable

    TopologySpreadConstraints описує, як група Podʼів повинна розподілятися по топологічних доменах. Планувальник розміщуватиме Podʼи таким чином, щоб дотримуватися обмежень. Всі topologySpreadConstraints поєднуються логічним оператором AND.

    TopologySpreadConstraint визначає, як розподіляти відповідні Podʼи серед заданої топології.

    • topologySpreadConstraints.maxSkew (int32), обовʼязково

      MaxSkew описує ступінь нерівномірного розподілу Podʼів. Коли whenUnsatisfiable=DoNotSchedule, це максимальна допустима різниця між кількістю відповідних Podʼів у цільовій топології та глобальним мінімумом. Глобальний мінімум — це мінімальна кількість відповідних Podʼів у відповідному домені або нуль, якщо кількість відповідних доменів менша за MinDomains. Наприклад, у кластері з 3 зонами MaxSkew встановлено на 1, і Podʼи з однаковим labelSelector розподіляються як 2/2/1: У цьому випадку глобальний мінімум дорівнює 1.

      graph TD; subgraph zone3["zone 3"] P3_1("Pod") end subgraph zone2["zone 2"] P2_1("Pod") P2_2("Pod") end subgraph zone1["zone 1"] P1_1("Pod") P1_2("Pod") end classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000; classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5; class P1_1,P1_2,P2_1,P2_2,P3_1 k8s; class zone1,zone2,zone3 cluster;
      • якщо MaxSkew дорівнює 1, новий Pod може бути розміщений тільки в zone3, щоб стати 2/2/2; розміщення його в zone1 (zone2) призведе до порушення MaxSkew (1) через ActualSkew (3-1) в zone1 (zone2).
      • якщо MaxSkew дорівнює 2, новий Pod може бути розміщений у будь-якій зоні. Коли whenUnsatisfiable=ScheduleAnyway, це використовується для надання більшої переваги топологіям, які задовольняють цю умову. Це обовʼязкове поле. Стандартне значення — 1; 0 не допускається.
    • topologySpreadConstraints.topologyKey (string), обовʼязково

      TopologyKey — це ключ міток вузлів. Вузли, які мають мітку з цим ключем та ідентичними значеннями, вважаються такими, що належать до однієї топології. Ми розглядаємо кожен <key, value> як "кошик" і намагаємося розмістити збалансовану кількість Podʼів у кожному кошику. Ми визначаємо домен як конкретний екземпляр топології. Також ми визначаємо відповідний домен як домен, чиї вузли відповідають вимогам nodeAffinityPolicy та nodeTaintsPolicy. Наприклад, якщо TopologyKey — це "kubernetes.io/hostname", кожен вузол є доменом цієї топології. І, якщо TopologyKey — це "topology.kubernetes.io/zone", кожна зона є доменом цієї топології. Це обовʼязкове поле.

    • topologySpreadConstraints.whenUnsatisfiable (string), обовʼязково

      WhenUnsatisfiable вказує, як діяти з Podʼом, якщо він не відповідає умовам розподілу.

      • DoNotSchedule (стандартно) наказує планувальнику не розміщувати його.

      • ScheduleAnyway наказує планувальнику розмістити Pod у будь-якому місці, але з наданням більшої переваги топологіям, які допоможуть зменшити нерівномірність розподілу. Умова вважається "незадовільною" для вхідного Podʼа, якщо і тільки якщо кожне можливе призначення вузла для цього Podʼа порушуватиме "MaxSkew" у деякій топології. Наприклад, у кластері з 3 зонами MaxSkew встановлено на 1, і Podʼи з однаковим labelSelector розподіляються як 3/1/1:

        graph TD; subgraph zone3["zone 3"] P3_1("Pod") end subgraph zone2["zone 2"] P2_1("Pod") end subgraph zone1["zone 1"] P1_1("Pod") P1_2("Pod") P1_3("Pod") end classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000; classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5; class P1_1,P1_2,P1_3,P2_1,P3_1 k8s; class zone1,zone2,zone3 cluster;

        Якщо WhenUnsatisfiable встановлено на DoNotSchedule, новий Pod може бути розміщений тільки в zone2 (zone3), щоб стати 3/2/1 (3/1/2), оскільки ActualSkew (2-1) у zone2 (zone3) задовольняє MaxSkew (1). Іншими словами, кластер все ще може бути незбалансованим, але планувальник не зробить його більш незбалансованим. Це обовʼязкове поле.

    • topologySpreadConstraints.labelSelector (LabelSelector)

      LabelSelector використовується для знаходження відповідних Podʼів. Podʼи, які відповідають цьому label selector, враховуються для визначення кількості Podʼів у відповідному топологічному домені.

    • topologySpreadConstraints.matchLabelKeys ([]string)

      Atomic: буде замінено під час об’єднання

      MatchLabelKeys — це набір ключів міток Podʼа для вибору Podʼів, за якими буде розраховано розподіл. Ключі використовуються для пошуку значень у мітках вхідного Podʼа, ці ключ-значення міток поєднуються з labelSelector для вибору групи наявних Podʼів, за якими буде розраховано розподіл для вхідного Podʼа. Той самий ключ заборонено мати як у MatchLabelKeys, так і в LabelSelector. MatchLabelKeys не можна встановлювати, коли LabelSelector не встановлено. Ключі, які не існують у мітках вхідного Podʼа, будуть ігноруватися. Нульовий або порожній список означає збіг тільки з labelSelector.

      Це бета-поле і вимагає ввімкнення функції MatchLabelKeysInPodTopologySpread (типово увімкнено).

    • topologySpreadConstraints.minDomains (int32)

      MinDomains вказує мінімальну кількість відповідних доменів. Коли кількість відповідних доменів з відповідними топологічними ключами менша за minDomains, Pod Topology Spread трактує "глобальний мінімум" як 0, і потім виконується розрахунок Skew. І коли кількість відповідних доменів з відповідними топологічними ключами дорівнює або перевищує minDomains, це значення не впливає на розподіл. У результаті, коли кількість відповідних доменів менша за minDomains, планувальник не розміщуватиме більше maxSkew Podʼів у ці домени. Якщо значення дорівнює null, обмеження поводиться так, ніби MinDomains дорівнює 1. Допустимі значення — цілі числа, більші за 0. Коли значення не дорівнює null, WhenUnsatisfiable має бути DoNotSchedule.

      Наприклад, у кластері з 3 зонами MaxSkew встановлено на 2, MinDomains встановлено на 5, і Podʼи з однаковим labelSelector розподіляються як 2/2/2:

      graph TD; subgraph zone3["zone 3"] P3_1("Pod") P3_2("Pod") end subgraph zone2["zone 2"] P2_1("Pod") P2_2("Pod") end subgraph zone1["zone 1"] P1_1("Pod") P1_2("Pod") end classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000; classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5; class P1_1,P1_2,P2_1,P2_2,P3_1,P3_2 k8s; class zone1,zone2,zone3 cluster;

      Кількість доменів менша за 5 (MinDomains), тому "глобальний мінімум" трактуватиметься як 0. У цій ситуації новий Pod з тим самим labelSelector не може бути розміщений, оскільки обчислений skew буде 3 (3 - 0), якщо новий Pod буде розміщено в будь-якій з трьох зон, це порушить MaxSkew.

    • topologySpreadConstraints.nodeAffinityPolicy (string)

      NodeAffinityPolicy вказує, як ми будемо враховувати nodeAffinity/nodeSelector Podʼа при розрахунку перекосу розподілу топології Pod. Варіанти:

      • Honor: тільки вузли, що відповідають nodeAffinity/nodeSelector, включаються до розрахунків.
      • Ignore: nodeAffinity/nodeSelector ігноруються. Всі вузли включаються до розрахунків.

      Якщо це значення дорівнює null, поведінка еквівалентна полю Honor. Це функція на рівні бета, типово увімкнена за допомогою прапорця NodeInclusionPolicyInPodTopologySpread.

    • topologySpreadConstraints.nodeTaintsPolicy (string)

      NodeTaintsPolicy вказує, як ми будемо враховувати node taints при розрахунку перекосу розподілу топології Pod. Варіанти:

      • Honor: вузли без taints, разом з вузлами з taints, для яких вхідний Pod має толерантність, включаються.
      • Ignore: node taints ігноруються. Всі вузли включаються.

      Якщо це значення дорівнює null, поведінка еквівалентна полю Ignore. Це функція на рівні бета, типово увімкнена за допомогою прапорця NodeInclusionPolicyInPodTopologySpread.

  • overhead (map[string]Quantity)

    Overhead представляє ресурси, що представляють накладні витрати Podʼа для роботи з конкретним RuntimeClass. Це поле буде автоматично заповнене під час допуску контролером RuntimeClass. Якщо контролер допуску RuntimeClass увімкнено, overhead не повинен бути встановлений у запитах на створення Podʼа. Контролер допуску RuntimeClass відхилить запити на створення Podʼа, у яких overhead вже встановлений. Якщо RuntimeClass налаштований та обраний у PodSpec, Overhead буде встановлено на значення, визначене у відповідному RuntimeClass, в іншому випадку воно залишиться невстановленим та буде вважатися рівним нулю. Докладніше: https://git.k8s.io/enhancements/keps/sig-node/688-pod-overhead/README.md

Життєвий цикл

  • restartPolicy (string)

    Політика перезапуску для всіх контейнерів у Podʼі. Одне з Always, OnFailure, Never. В деяких контекстах може бути дозволений лише субнабір цих значень. Стандартне значення — Always. Докладніше: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy

  • terminationGracePeriodSeconds (int64)

    Необовʼязкова тривалість у секундах, необхідна для коректного завершення роботи Podʼа. Може бути зменшена у запиті на видалення. Значення повинно бути невідʼємним цілим числом. Значення нуль означає негайне припинення через сигнал kill (без можливості завершити роботу коректно). Якщо це значення є nil, буде використано стандартний період завершення. Період належного завершення — це тривалість у секундах після того, як процеси, що працюють у Podʼі, отримають сигнал про завершення, і до того, як вони будуть примусово зупинені сигналом kill. Встановіть це значення більше, ніж очікуваний час завершення вашого процесу. Стандартне значення — 30 секунд.

  • activeDeadlineSeconds (int64)

    Необовʼязкова тривалість у секундах, протягом якої Pod може бути активним на вузлі відносно StartTime, перш ніж система почне активно намагатися позначити його як несправний та припинити роботу повʼязаних контейнерів. Значення повинно бути додатним цілим числом.

  • readinessGates ([]PodReadinessGate)

    Atomic: буде замінено під час злиття

    Якщо вказано, всі readiness gates будуть оцінюватися для готовності Podʼа. Pod вважається готовим, коли всі його контейнери готові І всі умови, зазначені в readiness gates, мають статус "True". Докладніше: https://git.k8s.io/enhancements/keps/sig-network/580-pod-readiness-gates

    PodReadinessGate містить посилання на стан Podʼа

    • readinessGates.conditionType (string), обовʼязково

      ConditionType належить до стану у списку станів Podʼа з відповідним типом.

Імʼя хосту та розвʼязування імен

  • hostname (string)

    Вказує імʼя хосту Podʼа. Якщо не вказано, імʼя хосту Podʼа буде встановлено в значення визначене системою.

  • setHostnameAsFQDN (boolean)

    Якщо встановлено значення true, імʼя хосту Podʼа буде налаштоване як повне доменне імʼя (FQDN) Podʼа, а не просто коротке імʼя (стандартно). У Linux-контейнерах це означає встановлення FQDN в полі імʼя хосту ядра (поле nodename структури utsname). У Windows-контейнерах це означає встановлення значення реєстру імʼя хосту для ключа реєстру HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters на FQDN. Якщо Pod не має FQDN, це не має ефекту. Стандартне значення — false.

  • subdomain (string)

    Якщо вказано, повне кваліфіковане імʼя хосту Podʼа буде "<hostname>.<subdomain>.<pod namespace>.svc.<cluster domain>". Якщо не вказано, Pod не буде мати доменного імені взагалі.

  • hostAliases ([]HostAlias)

    Patch strategy: злиття за ключем ip

    Map: унікальні значення ключа ip будуть збережені під час злиття

    HostAliases є необовʼязковим списком хостів та IP, які будуть впроваджені у файл hosts Podʼа, якщо вказано.

    HostAlias містить зітсавлення між IP та іменами хостів, які будуть впроваджені як запис у файл hosts Podʼа.

    • hostAliases.ip (string), обовʼязково

      Запис IP-адреси у файлі hosts.

    • hostAliases.hostnames ([]string)

      Atomic: буде замінено під час злиття

      Імена хостів для вищевказаної IP-адреси.

  • dnsConfig (PodDNSConfig)

    Вказує параметри DNS Podʼа. Параметри, вказані тут, будуть обʼєднані зі згенерованою DNS-конфігурацією на основі DNSPolicy.

    PodDNSConfig визначає параметри DNS Podʼа на додаток до тих, що генеруються з DNSPolicy.

    • dnsConfig.nameservers ([]string)

      Atomic: буде замінено під час злиття

      Список IP-адрес DNS-серверів імен. Він буде доданий до основних серверів імен, згенерованих з DNSPolicy. Дубльовані сервери імен будуть видалені.

    • dnsConfig.options ([]PodDNSConfigOption)

      Atomic: буде замінено під час злиття

      Список опцій DNS-резолвера. Він буде обʼєднаний з основними опціями, згенерованими з DNSPolicy. Дубльовані записи будуть видалені. Опції розвʼязування імен, зазначені в Options, замінять ті, що зʼявляються в основній DNSPolicy.

      PodDNSConfigOption визначає опції DNS-резольвера Podʼа.

      • dnsConfig.options.name (string)

        Обовʼязкове.

      • dnsConfig.options.value (string)

    • dnsConfig.searches ([]string)

      Atomic: буде замінено під час злиття

      Список доменів пошуку DNS для пошуку імен хостів. Він буде доданий до основних шляхів пошуку, згенерованих з DNSPolicy. Дубльовані шляхи пошуку будуть видалені.

  • dnsPolicy (string)

    Встановлює політику DNS для Podʼа. Стандартне значеняя — "ClusterFirst". Допустимі значення: ʼClusterFirstWithHostNetʼ, ʼClusterFirstʼ, ʼDefaultʼ або ʼNoneʼ. Параметри DNS, задані в DNSConfig, будуть обʼєднані з політикою, вибраною за допомогою DNSPolicy. Щоб налаштувати опції DNS разом з hostNetwork, потрібно явно вказати політику DNS як ʼClusterFirstWithHostNetʼ.

Простори імен хоста

  • hostNetwork (boolean)

    Використання мережі хоста для цього Podʼа. Використовує простір імен мережі хоста. Якщо ця опція встановлена, необхідно вказати порти, які будуть використовуватися. Стандартне значення — false.

  • hostPID (boolean)

    Використання простору імен PID хоста. Необовʼязково: стандартне значення — false.

  • hostIPC (boolean)

    Використання простору імен IPC хоста. Необовʼязково: стандартне значення — false.

  • shareProcessNamespace (boolean)

    Спільний процесний простір імен між усіма контейнерами в Podʼі. Якщо це встановлено, контейнери зможуть бачити та надсилати сигнали процесам з інших контейнерів у тому ж Podʼі, і перший процес у кожному контейнері не буде мати PID 1. HostPID та ShareProcessNamespace не можуть бути встановлені одночасно. Необовʼязково: стандартне значення — false.

Службовий обліковий запис

  • serviceAccountName (string)

    ServiceAccountName — це імʼя службового облікового запису, який використовується для запуску цього Podʼа. Детальніше: https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/

  • automountServiceAccountToken (boolean)

    AutomountServiceAccountToken вказує, чи повинен токен службового облікового запису автоматично монтуватися.

Контекст безпеки

  • securityContext (PodSecurityContext)

    SecurityContext містить атрибути безпеки на рівні Podʼа та загальні налаштування контейнера. Необовʼязково: стандартне значення — порожньо. Див. опис типу для стандартних значень для кожного поля.

    PodSecurityContext містить атрибути безпеки на рівні Podʼа та загальні налаштування контейнера. Деякі поля також присутні у container.securityContext. Значення полів container.securityContext мають пріоритет над значеннями полів PodSecurityContext.

    • securityContext.appArmorProfile (AppArmorProfile)

      appArmorProfile — параметри AppArmor, які будуть використовуватися контейнерами у цьому pod'і. Зверніть увагу, що це поле не можна встановити, коли spec.os.name — windows.

      AppArmorProfile визначає налаштування AppArmor для контейнера або podʼа.

      • securityContext.appArmorProfile.type (string), обовʼязково

        Поле type вказує, який тип профілю AppArmor буде застосовано. Дійсні варіанти:

        • Localhost — профіль, попередньо завантажений на вузлі.
        • RuntimeDefault — стандартний профіль середовища виконання контейнрів.
        • Unconfined — без примусового виконання правил AppArmor.
      • securityContext.appArmorProfile.localhostProfile (string)

        localhostProfile вказує профіль, завантажений на вузлі, який слід використовувати. Профіль має бути попередньо налаштований на вузлі для коректної роботи. Назва профілю повинна відповідати завантаженій назві. Це поле повинно бути встановлене, якщо і тільки якщо тип дорівнює "Localhost".

    • securityContext.fsGroup (int64)

      Спеціальна додаткова група, яка застосовується до всіх контейнерів у Podʼі. Деякі типи томів дозволяють Kubelet змінювати право власності на цей том, щоб він належав Podʼу:

      1. GID власника буде FSGroup
      2. Встановлюється біт setgid (нові файли, створені в томі, будуть належати FSGroup)
      3. Біти дозволів обʼєднуються з rw-rw----

      Якщо не встановлено, Kubelet не змінює право власності та дозволи будь-якого тому. Зверніть увагу, що це поле не можна встановити, коли spec.os.name — windows.

    • securityContext.fsGroupChangePolicy (string)

      fsGroupChangePolicy визначає поведінку зміни прав власності та дозволів тому перед тим, як він буде доступний у Podʼі. Це поле застосовується лише до типів томів, які підтримують права власності на основі fsGroup (та дозволів). Це не впливає на ефемерні типи томів, такі як: secret, configmaps та emptydir. Дійсні значення: "OnRootMismatch" та "Always". Якщо не вказано, використовується "Always". Зверніть увагу, що це поле не можна встановити, коли spec.os.name — windows.

    • securityContext.runAsUser (int64)

      UID, з яким запускається початковий процес контейнера. Стандартно використовується користувач, вказаний у метаданих образу, якщо не вказано інше. Також може бути встановлено в PodSecurityContext. Якщо значення встановлено як у SecurityContext, так і в PodSecurityContext, пріоритет має значення, зазначене в SecurityContext. Зверніть увагу, що це поле не може бути встановлено, коли spec.os.name є windows.

    • securityContext.runAsNonRoot (boolean)

      Вказує, що контейнер повинен запускатися як користувач, який не є root. Якщо значення true, Kubelet перевірить образ під час виконання, щоб гарантувати, що він не запускається з UID 0 (root), і не запустить контейнер, якщо це не так. Якщо поле не встановлено або має значення false, така перевірка не виконується. Також може бути налаштовано в SecurityContext. Якщо значення встановлено як у SecurityContext, так і в PodSecurityContext, пріоритет має значення, вказане в SecurityContext.

    • securityContext.runAsGroup (int64)

      GID, під яким запускається початковий процес контейнера. Якщо не встановлено, використовується стандартне значення для середовища виконання. Також може бути вказано в SecurityContext. Якщо значення встановлено як у SecurityContext, так і в PodSecurityContext, пріоритет має значення, зазначене в SecurityContext для цього контейнера. Зверніть увагу, що це поле не можна встановити, коли spec.os.name — windows.

    • securityContext.seccompProfile (SeccompProfile)

      Параметри seccomp для використання контейнерами в цьому Podʼі. Зверніть увагу, що це поле не можна встановити, коли spec.os.name — windows.

      SeccompProfile визначає налаштування профілю seccomp для Podʼа/контейнера. Може бути встановлено лише одне джерело профілю.

      • securityContext.seccompProfile.type (string), обовʼязкове

        type вказує, який тип профілю seccomp буде застосовано. Допустимі варіанти:

        • Localhost — має бути використаний профіль, визначений у файлі на вузлі.
        • RuntimeDefault — має бути використаний стандартний профіль для середовища виконання контейнерів.
        • Unconfined — не застосовується жоден профіль.
      • securityContext.seccompProfile.localhostProfile (string)

        localhostProfile вказує, що має бути використаний профіль, визначений у файлі на вузлі. Профіль має бути попередньо налаштований на вузлі, щоб працювати. Має бути низхідний шлях, відносно до налаштованого розташування профілю seccomp kubelet. Має бути встановлено, якщо тип "Localhost". НЕ має бути встановлено для будь-якого іншого типу.

    • securityContext.seLinuxOptions (SELinuxOptions)

      Контекст SELinux, який буде застосовано до всіх контейнерів. Якщо не зазначено, середовище виконання контейнера виділить випадковий контекст SELinux для кожного контейнера. Також може бути встановлено в SecurityContext. Якщо встановлено і в SecurityContext, і в PodSecurityContext, то значення, зазначене в SecurityContext, має пріоритет для цього контейнера. Зверніть увагу, що це поле не можна встановити, коли spec.os.name — windows.

      SELinuxOptions — це мітки, які будуть застосовані до контейнера

      • securityContext.seLinuxOptions.level (string)

        Level — це мітка рівня SELinux, яка застосовується до контейнера.

      • securityContext.seLinuxOptions.role (string)

        Role — це мітка ролі SELinux, яка застосовується до контейнера.

      • securityContext.seLinuxOptions.type (string)

        Type — це мітка типу SELinux, яка застосовується до контейнера.

      • securityContext.seLinuxOptions.user (string)

        User — це мітка користувача SELinux, яка застосовується до контейнера.

    • securityContext.supplementalGroups ([]int64)

      Atomic: буде замінено під час злиття

      Список груп, які застосовуються до першого процесу, запущеного в кожному контейнері, на додачу до основного GID контейнера та fsGroup (якщо вказано). Якщо функція SupplementalGroupsPolicy увімкнена, поле supplementalGroupsPolicy визначає, чи будуть ці групи додані до вже визначених у контейнерному образі або замінять їх. Якщо не вказано, додаткові групи не додаються, хоча членство в групах, визначених в образі контейнера, може бути використане залежно від поля supplementalGroupsPolicy. Зверніть увагу, що це поле не можна встановити, коли spec.os.name — windows.

    • securityContext.supplementalGroupsPolicy (string)

      Визначає, як обчислюються додаткові групи для перших процесів контейнера. Дійсні значення: "Merge" і "Strict". Якщо не вказано, використовується значення "Merge". (Alpha) Використання цього поля вимагає ввімкненої функції SupplementalGroupsPolicy, і середовище виконання контейнерів повинно підтримувати цю функцію. Зверніть увагу, що це поле не можна встановити, коли spec.os.name — windows.

    • securityContext.sysctls ([]Sysctl)

      Atomic: буде замінено під час злиття

      Sysctls містять список sysctls з простором імен, що використовуються для Podʼа. Podʼи з непідтримуваними sysctl (середовищем виконання контейнера) можуть не запуститися. Зверніть увагу, що це поле не можна встановити, коли spec.os.name — windows.

      Sysctl визначає параметр ядра, який потрібно встановити

      • securityContext.sysctls.name (string), обовʼязкове

        Назва властивості

      • securityContext.sysctls.value (string), обовʼязкове

        Значення властивості

    • securityContext.windowsOptions (WindowsSecurityContextOptions)

      Параметри, специфічні для Windows, що застосовуються до всіх контейнерів. Якщо не зазначено, використовуються параметри у SecurityContext контейнера. Якщо встановлено і в SecurityContext, і в PodSecurityContext, то значення, зазначене в SecurityContext, має пріоритет. Зверніть увагу, що це поле не можна встановити, коли spec.os.name — linux.

      WindowsSecurityContextOptions містять параметри та облікові дані, специфічні для Windows.

      • securityContext.windowsOptions.gmsaCredentialSpec (string)

        GMSACredentialSpec — це місце, де веб-хук GMSA (https://github.com/kubernetes-sigs/windows-gmsa) вставляє вміст GMSA credential spec, зазначений у полі GMSACredentialSpecName.

      • securityContext.windowsOptions.gmsaCredentialSpecName (string)

        GMSACredentialSpecName — це ім’я специфікації облікових даних GMSA для використання.

      • securityContext.windowsOptions.hostProcess (boolean)

        HostProcess визначає, чи повинен контейнер запускатися як контейнер ʼHost Processʼ. Усі контейнери Podʼа повинні мати однакове ефективне значення HostProcess (не дозволяється змішування контейнерів HostProcess та не-HostProcess). Крім того, якщо HostProcess дорівнює true, то HostNetwork також має бути встановлено на true.

      • securityContext.windowsOptions.runAsUserName (string)

        Ім’я користувача в Windows для запуску точки входу процесу контейнера. Стандартно використовується користувач, вказаний у метаданих образу, якщо не вказано. Також можна встановити в PodSecurityContext. Якщо встановлено як у SecurityContext, так і в PodSecurityContext, значення, вказане в SecurityContext, має пріоритет.

Alpha рівень

  • hostUsers (boolean)

    Використання простору імен користувачів хоста. Необовʼязково: стандартне значення — true. Якщо встановлено true або не зазначено, Pod буде виконуватися в просторі імен користувачів хоста, корисно, коли Pod потребує функції, доступної лише в просторі імен користувачів хоста, такої як завантаження модуля ядра з CAP_SYS_MODULE. Коли встановлено false, створюється новий простір імен для користувачів для Podʼа. Встановлення значення false корисно для зниження ризику вразливостей виходу з контейнера, дозволяючи користувачам запускати контейнери з правами root без фактичних привілеїв root на хості. Це поле є рівнем alpha і враховується лише серверами, які включають функцію UserNamespacesSupport.

  • resourceClaims ([]PodResourceClaim)

    Patch strategy: retainKeys, обʼєднання за ключем name

    Map: унікальні значення за ключем name будуть збережені під час обʼєднання

    ResourceClaims визначає, які ResourceClaims повинні бути виділені та зарезервовані перед тим, як Podʼу буде дозволено почати роботу. Ресурси будуть доступні тим контейнерам, які споживають їх за іменем.

    Це поле є альфа-рівнем і вимагає увімкнення функції DynamicResourceAllocation.

    Це поле є незмінним.

    PodResourceClaim посилається на один конкретний ResourceClaim, або безпосередньо, або через вказання ResourceClaimTemplate, який потім перетворюється на ResourceClaim для podʼа.

    Він додає до нього імʼя, яке унікально ідентифікує ResourceClaim всередині podʼа. Контейнери, яким потрібен доступ до цього ResourceClaim, посилаються на нього за цим імʼям.

    • resourceClaims.name (string), обовʼязкове

      Імʼя унікально ідентифікує цей ресурсний запит всередині Podʼа. Це повинно бути DNS_LABEL.

    • resourceClaims.resourceClaimName (string)

      ResourceClaimName — це імʼя обʼєкта ResourceClaim у тому ж просторі імен, що і цей Pod.

      Має бути задано точно одне з ResourceClaimName та ResourceClaimTemplateName.

    • resourceClaims.resourceClaimTemplateName (string)

      ResourceClaimTemplateName — це імʼя обʼєкта ResourceClaimTemplate у тому ж просторі імен, що і цей Pod.

      Шаблон буде використаний для створення нового ResourceClaim, який буде привʼязаний до цього Podʼа. Коли цей Pod буде видалений, ResourceClaim також буде видалений. Імʼя Podʼа та імʼя ресурсу разом з згенерованим компонентом будуть використані для формування унікального імені для ResourceClaim, яке буде записано в pod.status.resourceClaimStatuses.

      Це поле є незмінним, і після створення ResourceClaim панель управління не вноситиме жодних змін до відповідного ResourceClaim.

      Має бути встановлено точно одне з полів ResourceClaimName або ResourceClaimTemplateName.

  • schedulingGates ([]PodSchedulingGate)

    Patch strategy: обʼєднання за ключем name

    Map: унікальні значення за ключем name будуть збережені під час обʼєднання

    SchedulingGates — це непрозорий список значень, які, якщо вказані, блокуватимуть планування Podʼа. Якщо schedulingGates не порожні, Pod залишатиметься в стані SchedulingGated, і планувальник не намагатиметься його розмістити.

    SchedulingGates можна встановити лише під час створення Podʼа і видаляти лише згодом.

    PodSchedulingGate повʼязаний з Podʼом для захисту його планування.

    • schedulingGates.name (string), обовʼязкове

      Імʼя шлюзу планування. Кожен шлюз планування повинен мати унікальне поле name.

Застаріле

  • serviceAccount (string)

    DeprecatedServiceAccount — це застарілий псевдонім для ServiceAccountName. Застаріле: використовуйте serviceAccountName замість цього.

Контейнер

Один контейнер застосунка, який ви хочете запустити в Podʼі.


  • name (string), обовʼязково

    Імʼя контейнера вказується як DNS_LABEL. Кожен контейнер в Podʼі повинен мати унікальне імʼя (DNS_LABEL). Не може бути оновлено.

Образ

  • image (string)

    Назва образу контейнера. Докладніше: https://kubernetes.io/docs/concepts/containers/images. Це поле є необовʼязковим для того, щоб дозволити більш високому рівню управління конфігурацією використовувати стандартний образ або перевизначити образ контейнера в контролері навантаження, такому як Deployments та StatefulSets.

  • imagePullPolicy (string)

    Політика отримання образу. Одне з значень: Always, Never, IfNotPresent. Стандартно — Always, якщо вказано теґ :latest, або IfNotPresent у іншому випадку. Не може бути оновлено. Докладніше: https://kubernetes.io/docs/concepts/containers/images#updating-images

Точка входу

  • command ([]string)

    Atomic: буде замінено під час злиття

    Масив точок входу. Виконується безпосередньо, не у середовищі оболонки. Якщо не надано, буде використано ENTRYPOINT образу контейнера. Змінні $(VAR_NAME) розширюються за допомогою середовища контейнера. Якщо змінну не вдасться розгорнути, посилання у вхідному рядку залишиться без змін. Подвійні $$ зменшуються до одного $, що дозволяє екранувати синтаксис $(VAR_NAME): наприклад, "$$(VAR_NAME)" виведе літеральний рядок "$(VAR_NAME)". Екрановані посилання ніколи не будуть розгортатися, незалежно від того, чи існує змінна, чи ні. Не може бути оновлено. Докладніше: https://kubernetes.io/docs/tasks/inject-data-application/define-command-argument-container/#running-a-command-in-a-shell

  • args ([]string)

    Atomic: буде замінено під час злиття

    Аргументи точки входу. Якщо не надано, буде використано CMD образу контейнера. Змінні $(VAR_NAME) розширюються за допомогою середовища контейнера. Якщо змінну не вдасться розгорнути, посилання у вхідному рядку залишиться без змін. Подвійні $$ зменшуються до одного $, що дозволяє екранувати синтаксис $(VAR_NAME): наприклад, "$$(VAR_NAME)" виведе літеральний рядок "$(VAR_NAME)". Екрановані посилання ніколи не будуть розгортатися, незалежно від того, чи існує змінна, чи ні. Не може бути оновлено. Докладніше: https://kubernetes.io/docs/tasks/inject-data-application/define-command-argument-container/#running-a-command-in-a-shell

  • workingDir (string)

    Робоча тека контейнера. Якщо не вказано, буде використано стандартне значення контейнера, яке може бути налаштоване в образі контейнера. Не може бути оновлено.

Порти

  • ports ([]ContainerPort)

    Patch strategy: обʼєднання за ключем containerPort

    Map: унікальні значення за ключами containerPort, protocol будуть збережені під час обʼєднання

    Список портів, які потрібно відкрити з контейнера. Не вказання порту тут НЕ ЗАПОБІГАЄ його відкриттю. Будь-який порт, який прослуховує стандартну адресу "0.0.0.0" всередині контейнера, буде доступний з мережі. Зміна цього масиву за допомогою стратегічного патча злиття може пошкодити дані. Для отримання додаткової інформації дивіться https://github.com/kubernetes/kubernetes/issues/108255. Не може бути оновлено.

    ContainerPort представляє мережевий порт в одному контейнері.

    • ports.containerPort (int32), обовʼязково

      Номер порту для відкриття на IP-адресі контейнера. Це повинен бути дійсний номер порту, 0 < x < 65536.

    • ports.hostIP (string)

      IP-адреса хоста, що звʼязується з зовнішнім портом.

    • ports.hostPort (int32)

      Номер порту для відкриття на хості. Якщо вказано, це повинен бути дійсний номер порту, 0 < x < 65536. Якщо вказано HostNetwork, це значення повинно збігатися з ContainerPort. Більшість контейнерів цього не потребують.

    • ports.name (string)

      Якщо вказано, це повинен бути IANA_SVC_NAME і єдиним в межах Podʼа. Кожен іменований порт в Podʼі повинен мати унікальне імʼя. Назва порту, на яку можна посилатися з Service.

    • ports.protocol (string)

      Протокол для порту. Повинен бути UDP, TCP або SCTP. Стандартне значення — "TCP".

Змінні середовища

  • env ([]EnvVar)

    Patch strategy: обʼєднання за ключем name

    Map: унікальні значення за ключем name будуть збережені під час обʼєднання

    Список змінних середовища для встановлення в контейнері. Не може бути оновлено.

    EnvVar представляє змінну середовища, присутню в контейнері.

    • env.name (string), обовʼязково

      Назва змінної середовища. Повинно бути C_IDENTIFIER.

    • env.value (string)

      Змінні посилання $(VAR_NAME) розгортаються за допомогою попередньо визначених змінних середовища в контейнері та будь-яких змінних середовища Service. Якщо змінну не вдається розʼязати, посилання відносно введеного рядка буде незмінним. Подвійний $$ зменшується до одного $, що дозволяє екранувати синтаксис $(VAR_NAME): тобто "$$(VAR_NAME)" буде створювати літеральний рядок "$(VAR_NAME)". Екрановані посилання ніколи не будуть розгорнуті, незалежно від того, чи існує змінна, чи ні. Стандартне значення — "".

    • env.valueFrom (EnvVarSource)

      Джерело значення змінної середовища. Не може бути використано, якщо значення не є пустим.

      EnvVarSource представляє джерело значення EnvVar.

      • env.valueFrom.configMapKeyRef (ConfigMapKeySelector)

        Вибирає ключ з ConfigMap.

        Вибирає ключ з ConfigMap.

        • env.valueFrom.configMapKeyRef.key (string), обовʼязково

          Ключ для вибору.

        • env.valueFrom.configMapKeyRef.name (string)

          Назва обʼєкта на який посилаються. Це поле фактично є обовʼязковим, але через забезпечення зворотної сумісності допускається залишати його порожнім. Екземпляри цього типу з порожнім значенням, ймовірно, є неправильними. Докладніше: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names

        • env.valueFrom.configMapKeyRef.optional (boolean)

          Вказує, чи має бути визначений ConfigMap або його ключ

      • env.valueFrom.fieldRef (ObjectFieldSelector)

        Вибирає поле Podʼа: підтримує metadata.name, metadata.namespace, metadata.labels['\<KEY>'], metadata.annotations['\<KEY>'], spec.nodeName, spec.serviceAccountName, status.hostIP, status.podIP, status.podIPs.

      • env.valueFrom.resourceFieldRef (ResourceFieldSelector)

        Вибирає ресурс контейнера: наразі підтримуються лише обмеження і запити ресурсів (limits.cpu, limits.memory, limits.ephemeral-storage, requests.cpu, requests.memory та requests.ephemeral-storage).

      • env.valueFrom.secretKeyRef (SecretKeySelector)

        Вибирає ключ Secretʼа в просторі імен Podʼа

        SecretKeySelector вибирає ключ Secretʼа.

        • env.valueFrom.secretKeyRef.key (string), обовʼязково

          Ключ Secretʼа для вибору. Повинен бути дійсним ключем Secretʼа.

        • env.valueFrom.secretKeyRef.name (string)

          Назва посилання. Це поле фактично є обовʼязковим, але через забезпечення зворотної сумісності допускається залишати його порожнім. Екземпляри цього типу з порожнім значенням, ймовірно, є неправильними. Докладніше: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names

        • env.valueFrom.secretKeyRef.optional (boolean)

          Зазначає, чи має бути визначений Secret або його ключ

  • envFrom ([]EnvFromSource)

    Atomic: буде замінено під час злиття

    Список джерел для заповнення змінних середовища в контейнері. Ключі, визначені в межах джерела, повинні бути C_IDENTIFIER. Усі хибні ключі будуть повідомлені як подія при запуску контейнера. Коли ключ існує в декількох джерелах, значення, що асоціюється з останнім джерелом, буде мати пріоритет. Значення, визначене за допомогою Env з дубльованим ключем, буде мати пріоритет. Не може бути оновлено.

    EnvFromSource представляє джерело набору ConfigMaps

    • envFrom.configMapRef (ConfigMapEnvSource)

      ConfigMap для вибору з

      ConfigMapEnvSource вибирає ConfigMap для заповнення змінними середовища.

      Зміст поля Data цільового ConfigMap буде представлено в парах ключ-значення як змінні середовища.

      • envFrom.configMapRef.name (string)

        Назва посилання. Це поле фактично є обовʼязковим, але через забезпечення зворотної сумісності допускається залишати його порожнім. Екземпляри цього типу з порожнім значенням, ймовірно, є неправильними/ Докладніше: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names

      • envFrom.configMapRef.optional (boolean)

        Вказує, чи має бути визначений ConfigMap

    • envFrom.prefix (string)

      Необовʼязково ідентифікатор для вставлення перед кожним ключем в ConfigMap. Повинен бути C_IDENTIFIER.

    • envFrom.secretRef (SecretEnvSource)

      Secret для вибору з

      SecretEnvSource вибирає Secret для заповнення змінними середовища.

      Зміст поля Data цільового Secret буде представлено в парах ключ-значення як змінні середовища.

      • envFrom.secretRef.name (string)

        Назва посилання. Це поле фактично є обовʼязковим, але через забезпечення зворотної сумісності допускається залишати його порожнім. Екземпляри цього типу з порожнім значенням, ймовірно, є неправильними. Докладніше: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names

      • envFrom.secretRef.optional (boolean)

        Вказує, чи має бути визначений Secret

Томи

  • volumeMounts ([]VolumeMount)

    Patch strategy: обʼєднання за ключем mountPath

    Map: унікальні значення за ключем mountPath будуть збережені під час обʼєднання

    Томи, які будуть змонтовані в файлову систему контейнера. Не може бути оновлено.

    VolumeMount описує монтування Тому всередині контейнера.

    • volumeMounts.mountPath (string), обовʼязково

      Шлях всередині контейнера, за яким повинен бути змонтований том. Не повинен містити ':'.

    • volumeMounts.name (string), обовʼязково

      Повинно відповідати імені Тому.

    • volumeMounts.mountPropagation (string)

      mountPropagation визначає, як монтування розповсюджуються від хоста до контейнера і навпаки. Коли не встановлено, використовується MountPropagationNone. Це поле є бета-версією в 1.10. Коли RecursiveReadOnly встановлено в IfPossible або Enabled, MountPropagation повинен бути None або не вказаним (стандартно None).

    • volumeMounts.readOnly (boolean)

      Змонтований як тільки для читання, якщо true, для читання/запису в іншому випадку (false або не вказано). Стандартне значення — false.

    • volumeMounts.recursiveReadOnly (string)

      RecursiveReadOnly вказує, чи слід обробляти монтування тільки для читання рекурсивно.

      Якщо ReadOnly встановлено в false, це поле не має значення і не має бути вказаним.

      Якщо ReadOnly дорівнює true, і це поле встановлено в Disabled, монтування не стає рекурсивним тільки для читання. Якщо це поле встановлено в IfPossible, монтування стає рекурсивним тільки для читання, якщо це підтримується середовищем виконання контейнерів. Якщо це поле встановлено в Enabled, монтування стає рекурсивним тільки для читання, якщо це підтримується середовищем виконання контейнерів; в іншому випадку, pod не буде запущено і буде згенеровано помилку, щоб вказати причину.

      Якщо це поле встановлено в IfPossible або Enabled, MountPropagation має бути встановлено в None (або бути не вказаним, що стандартно дорівнює None).

      Якщо це поле не вказано, воно вважається еквівалентом Disabled.

    • volumeMounts.subPath (string)

      Шлях всередині тому, з якого має бути змонтований том контейнера. Стандартне значення — "" (корінь тому).

    • volumeMounts.subPathExpr (string)

      Розгорнутий шлях всередині тому, з якого має бути змонтований том контейнера. Поводиться схоже до SubPath, але посилання на змінні середовища $(VAR_NAME) розгортаються за допомогою середовища контейнера. Стандартне значення — "" (корінь тому). SubPathExpr і SubPath є взаємовиключними.

  • volumeDevices ([]VolumeDevice)

    Patch strategy: обʼєднання за ключем devicePath

    Map: унікальні значення за ключем devicePath будуть збережені під час обʼєднання

    volumeDevices — це список блочних пристроїв, які будуть використані контейнером.

    volumeDevice описує зіставлення необробленого блочного пристрою всередині контейнера.

    • volumeDevices.devicePath (string), обовʼязково

      devicePath — це шлях всередині контейнера, на який буде зіставлено пристрій.

    • volumeDevices.name (string), обовʼязково

      name повинно відповідати імені persistentVolumeClaim в Podʼі.

Ресурси

  • resources (ResourceRequirements)

    Обчислювальні ресурси, необхідні для цього контейнера. Не може бути оновлено. Докладніше: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/

    ResourceRequirements описує вимоги до обчислювальних ресурсів.

    • resources.claims ([]ResourceClaim)

      Map: унікальні значення за ключем будуть збережені під час обʼєднання

      Claims містить назви ресурсів, визначених в spec.resourceClaims, які використовуються цим контейнером.

      Це поле альфа-версії і вимагає включення функціоналу DynamicResourceAllocation.

      Це поле є незмінним. Його можна встановити тільки для контейнерів.

      ResourceClaim посилається на один запис в PodSpec.ResourceClaims.

      • resources.claims.name (string), обовʼязково

        Імʼя повинно відповідати імені одного запису в pod.spec.resourceClaims Podʼа, де використовується це поле. Це робить цей ресурс доступним всередині контейнера.

      • resources.claims.request (string)

        Request — це імʼя, вибране для запиту в зазначеній заявці. Якщо поле порожнє, буде доступно все з заявки; в іншому випадку, доступний буде лише результат цього запиту.

    • resources.limits (map[string]Quantity)

      Limits визначає максимальну кількість обчислювальних ресурсів, дозволених. Докладніше: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/

    • resources.requests (map[string]Quantity)

      Requests описує мінімальну кількість обчислювальних ресурсів, що потрібна. Якщо Requests відсутній для контейнера, він стандартно встановлюється в Limits, якщо це явно вказано, інакше — у значення, визначеного реалізацією. Requests не може перевищувати Limits. Докладніше: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/

  • resizePolicy ([]ContainerResizePolicy)

    Atomic: буде замінено під час обʼєднання

    Політика зміни розміру ресурсів для контейнера.

    ContainerResizePolicy представляє політику зміни розміру ресурсів для контейнера.

    • resizePolicy.resourceName (string), обовʼязково

      Назва ресурсу, до якого застосовується ця політика зміни розміру ресурсу. Підтримувані значення: cpu, memory.

    • resizePolicy.restartPolicy (string), обовʼязково

      Політика перезапуску, яку застосовувати при зміні розміру вказаного ресурсу. Якщо не вказано, то стандартно встановлюється NotRequired.

Життєвий цикл

  • lifecycle (Lifecycle)

    Дії, які система управління повинна виконати у відповідь на події життєвого циклу контейнера. Не може бути оновлено.

    Lifecycle описує дії, які система управління повинна виконати у відповідь на події життєвого циклу контейнера. Для обробників життєвого циклу PostStart і PreStop управління контейнером блокується, поки дія не буде завершена, якщо процес контейнера виявляється несправним, тоді обробник переривається.

    • lifecycle.postStart (LifecycleHandler)

      PostStart викликається негайно після створення контейнера. Якщо обробник не вдалося виконати, контейнер буде завершено і перезапущено згідно зі своєю політикою перезапуску. Інше управління контейнером блокується, поки хук не завершиться. Докладніше: https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks

    • lifecycle.preStop (LifecycleHandler)

      PreStop викликається негайно перед тим, як контейнер буде завершено через запит API або подію управління, таку як невдача проби справності/запуску, випередження, скорочення ресурсів тощо. Обробник не викликається, якщо контейнер впаде або закінчить роботу. Період перебігу належного завершення підраховується до виконання хуку PreStop. Незалежно від результату обробника, контейнер в кінцевому підсумку завершиться протягом періоду належного завершення Pod (якщо він не буде затриманий завершенням залишкових операцій). Інше управління контейнером блокується, поки хук не завершиться або досягне періоду належного завершення. Докладніше: https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks

  • terminationMessagePath (string)

    Необовʼязково: Шлях, за яким файл, до якого буде записано повідомлення про завершення контейнера, буде вмонтовано в файлову систему контейнера. Записане повідомлення, призначено для короткого кінцевого статусу, наприклад, повідомлення про помилку виразу. Якщо воно більше 4096 байт, то вузол скоротить його. Загальна довжина повідомлення по всіх контейнерах буде обмежена 12 кб. Стандартне значення — /dev/termination-log. Не може бути оновлено.

  • terminationMessagePolicy (string)

    Вказує, як має бути заповнене повідомлення про завершення. File використовуватиме вміст terminationMessagePath для заповнення повідомлення про статус контейнера при успіху і невдачі. FallbackToLogsOnError використовуватиме останній шматок виводу логу контейнера, якщо файл повідомлення про завершення пустий і контейнер завершився з помилкою. Вивід логу обмежено 2048 байтами або 80 рядками, якщо це менше. Стандартне значення — File. Не може бути оновлено.

  • livenessProbe (Probe)

    Періодичне тестування життєздатності контейнера. Контейнер буде перезапущено, якщо тест не вдасться. Не може бути оновлено. Докладніше: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes

  • readinessProbe (Probe)

    Періодична перевірка готовності контейнера до обслуговування. Контейнер буде видалено з точок доступу Service, якщо проба зазнає невдачі. Неможливо оновити. Докладніше: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes

  • startupProbe (Probe)

    StartupProbe вказує, що Pod успішно ініціалізовано. Якщо вказано, інші проби не виконуються, поки ця не закінчиться успіхом. Якщо цей тест не вдасться, Pod буде перезапущено, так само, як і в разі невдачі livenessProbe. Це може бути використано для надання різних параметрів проби на початку життєвого циклу Podʼа, коли завантаження даних або оновлення кешу може займати довгий час, ніж під час регулярної роботи. Це не може бути оновлено. Докладніше: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes

  • restartPolicy (string)

    RestartPolicy визначає поведінку перезапуску окремих контейнерів у Podʼі. Це поле може бути встановлено тільки для контейнерів ініціалізації, і єдине допустиме значення — "Always". Для інших контейнерів, відмінних від контейнерів ініціалізації, або коли це поле не вказано, поведінка перезапуску визначається політикою перезапуску Podʼа і типом контейнера. Встановлення RestartPolicy як "Always" для контейнера ініціалізації матиме наступний ефект: цей контейнер ініціалізації буде постійно перезапускатися при виході, поки всі звичайні контейнери не завершаться. Як тільки всі звичайні контейнери завершаться, всі контейнери ініціалізації з RestartPolicy "Always" будуть вимкнені. Цей життєвий цикл відрізняється від звичайних контейнерів ініціалізації і часто називається "sidecar" контейнер. Хоча цей контейнер ініціалізації все ще запускається у послідовності контейнерів ініціалізації, він не чекає на завершення роботи контейнера, перш ніж переходити до наступного контейнера ініціалізації . Натомість, наступний контейнер ініціалізації запускається одразу після запуску цього контейнера ініціалізації або після успішного завершення будь-якого startupProbe.

Контекст безпеки

  • securityContext (SecurityContext)

    SecurityContext визначає параметри безпеки, з якими має працювати контейнер. Якщо встановлено, поля SecurityContext замінять відповідні поля PodSecurityContext. Докладніше: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/

    SecurityContext містить конфігурацію безпеки, яка буде застосована до контейнера. Деякі поля присутні як у SecurityContext, так і в PodSecurityContext. Якщо обидва встановлені, значення в SecurityContext мають пріоритет.

    • securityContext.allowPrivilegeEscalation (boolean)

      AllowPrivilegeEscalation контролює, чи може процес отримати більше привілеїв, ніж його батьківський процес. Цей булевий параметр безпосередньо контролює, чи буде встановлено прапоркць no_new_privs для процесу контейнера. AllowPrivilegeEscalation завжди має значення true, коли контейнер:

      1. Запускається з привілеями (Privileged)
      2. Має CAP_SYS_ADMIN

      Зверніть увагу, що це поле не може бути встановлене, коли spec.os.name дорівнює windows.

    • securityContext.appArmorProfile (AppArmorProfile)

      appArmorProfile — це параметри AppArmor, які використовуються цим контейнером. Якщо встановлено, цей профіль переважає профіль AppArmor podʼа. Зверніть увагу, що це поле не може бути встановлене, коли spec.os.name дорівнює windows.

      AppArmorProfile визначає налаштування AppArmor для podʼа або контейнера.

      • securityContext.appArmorProfile.type (string), обовʼязково

        Поле type вказує, який тип профілю AppArmor буде застосовано. Дійсні варіанти:

        • Localhost — профіль, попередньо завантажений на вузлі.
        • RuntimeDefault — стандартний профіль середовища виконання контейнерів.
        • Unconfined — без примусового виконання правил AppArmor.
      • securityContext.appArmorProfile.localhostProfile (string)

        localhostProfile вказує профіль, завантажений на вузлі, який слід використовувати. Профіль має бути попередньо налаштований на вузлі для коректної роботи. Назва профілю повинна відповідати завантаженій назві. Це поле повинно бути встановлене, якщо і тільки якщо тип дорівнює "Localhost".

    • securityContext.capabilities (Capabilities)

      Можливості для додавання/видалення під час запуску контейнерів. Стандарто використовується набір можливостей, наданих середовищем виконання контейнера. Зверніть увагу, що це поле не може бути встановлено, коли spec.os.name є windows.

      Додає та видаляє можливості POSIX з працюючих контейнерів.

      • securityContext.capabilities.add ([]string)

        Atomic: буде замінено під час обʼєднання

        Додані можливості.

      • securityContext.capabilities.drop ([]string)

        Atomic: буде замінено під час обʼєднання

        Видалені можливості.

    • securityContext.procMount (string)

      procMount вказує тип монтування файлової системи /proc, який слід використовувати для контейнерів. Стандартне значення — Default, що використовує стандартні налаштування середовища виконання контейнерів для шляхів тільки для читання та замаскованих шляхів. Це вимагає ввімкнення функціональної можливості ProcMountType. Зверніть увагу, що це поле не може бути встановлено, коли spec.os.name є windows.

    • securityContext.privileged (boolean)

      Запуск контейнера у привілейованому режимі. Процеси у привілейованих контейнерах по суті еквівалентні root на хості. Стандартно дорівнює false. Зверніть увагу, що це поле не може бути встановлено, коли spec.os.name є windows.

    • securityContext.readOnlyRootFilesystem (boolean)

      Чи має цей контейнер кореневу файлову систему тільки для читання. Стандартно дорівнює false. Зверніть увагу, що це поле не може бути встановлено, коли spec.os.name є windows.

    • securityContext.runAsUser (int64)

      UID, з яким запускається початковий процес контейнера. Стандартно використовується користувач, вказаний у метаданих образу, якщо не вказано інше. Також може бути встановлено в PodSecurityContext. Якщо значення встановлено як у SecurityContext, так і в PodSecurityContext, пріоритет має значення, зазначене в SecurityContext. Зверніть увагу, що це поле не може бути встановлено, коли spec.os.name є windows.

    • securityContext.runAsNonRoot (boolean)

      Вказує, що контейнер повинен запускатися як користувач, який не є root. Якщо значення true, Kubelet перевірить образ під час виконання, щоб гарантувати, що він не запускається з UID 0 (root), і не запустить контейнер, якщо це не так. Якщо поле не встановлено або має значення false, така перевірка не виконується. Також може бути налаштовано в SecurityContext. Якщо значення встановлено як у SecurityContext, так і в PodSecurityContext, пріоритет має значення, вказане в SecurityContext.

    • securityContext.runAsGroup (int64)

      GID, під яким запускається початковий процес контейнера. Якщо не встановлено, використовується стандартне значення для середовища виконання. Також може бути вказано в SecurityContext. Якщо значення встановлено як у SecurityContext, так і в PodSecurityContext, пріоритет має значення, зазначене в SecurityContext для цього контейнера. Зверніть увагу, що це поле не можна встановити, коли spec.os.name — windows.

    • securityContext.seLinuxOptions (SELinuxOptions)

      Контекст SELinux, який буде застосований до контейнера. Якщо не вказано, середовище виконання контейнера призначить випадковий контекст SELinux для кожного контейнера. Може також бути встановлено в PodSecurityContext. Якщо встановлено в обох SecurityContext і PodSecurityContext, пріоритет має значення, вказане в SecurityContext. Зверніть увагу, що це поле не може бути встановлено, коли spec.os.name є windows.

      SELinuxOptions — це мітки, що застосовуються до контейнера

      • securityContext.seLinuxOptions.level (string)

        Level є міткою рівня SELinux, що застосовується до контейнера.

      • securityContext.seLinuxOptions.role (string)

        Role є міткою ролі SELinux, що застосовується до контейнера.

      • securityContext.seLinuxOptions.type (string)

        Type є міткою типу SELinux, що застосовується до контейнера.

      • securityContext.seLinuxOptions.user (string)

        User є міткою користувача SELinux, що застосовується до контейнера.

    • securityContext.seccompProfile (SeccompProfile)

      Параметри seccomp для використання контейнерами в цьому Podʼі. Зверніть увагу, що це поле не можна встановити, коли spec.os.name — windows.

      SeccompProfile визначає налаштування профілю seccomp для Podʼа/контейнера. Може бути встановлено лише одне джерело профілю.

      • securityContext.seccompProfile.type (string), обовʼязкове

        type вказує, який тип профілю seccomp буде застосовано. Допустимі варіанти:

        • Localhost — має бути використаний профіль, визначений у файлі на вузлі.
        • RuntimeDefault — має бути використаний стандартний профіль для середовища виконання контейнерів.
        • Unconfined — не застосовується жоден профіль.
      • securityContext.seccompProfile.localhostProfile (string)

        localhostProfile вказує, що має бути використаний профіль, визначений у файлі на вузлі. Профіль має бути попередньо налаштований на вузлі, щоб працювати. Має бути низхідний шлях, відносно до налаштованого розташування профілю seccomp kubelet. Має бути встановлено, якщо тип "Localhost". НЕ має бути встановлено для будь-якого іншого типу.

    • securityContext.windowsOptions (WindowsSecurityContextOptions)

      Специфічні налаштування для Windows, які застосовуються до всіх контейнерів. Якщо не вказано, використовуються опції з PodSecurityContext. Якщо встановлено в обох SecurityContext і PodSecurityContext, пріоритет має значення, вказане в SecurityContext. Зверніть увагу, що це поле не може бути встановлено, коли spec.os.name є linux.

      WindowsSecurityContextOptions містять специфічні для Windows параметри та облікові дані.

      • securityContext.windowsOptions.gmsaCredentialSpec (string)

        GMSACredentialSpec — це місце, де вебхук GMSA (https://github.com/kubernetes-sigs/windows-gmsa) вставляє вміст специфікації облікових даних GMSA, названої полем GMSACredentialSpecName.

      • securityContext.windowsOptions.gmsaCredentialSpecName (string)

        GMSACredentialSpecName — це назва специфікації облікових даних GMSA, яка буде використана.

      • securityContext.windowsOptions.hostProcess (boolean)

        HostProcess визначає, чи слід запускати контейнер як контейнер ʼHost Processʼ. Усі контейнери Pod повинні мати однакове значення HostProcess (не дозволено мати суміш контейнерів HostProcess та не-HostProcess). Крім того, якщо HostProcess є true, то HostNetwork також повинен бути встановлений у true.

      • securityContext.windowsOptions.runAsUserName (string)

        Імʼя користувача в Windows для запуску точки входу процесу контейнера. Стандартно використовується користувач, вказаний у метаданих образу, якщо не вказано. Може також бути встановлено в PodSecurityContext. Якщо встановлено в обох SecurityContext і PodSecurityContext, пріоритет має значення, вказане в SecurityContext.

Налагодження

  • stdin (boolean)

    Чи повинен цей контейнер виділяти буфер для stdin у середовищі виконання контейнера. Якщо це не встановлено, читання з stdin у контейнері завжди буде призводити до EOF. Стандартно — false.

  • stdinOnce (boolean)

    Чи повинне середовище виконання контейнера закрити канал stdin після того, як він був відкритий одним підключенням. Коли stdin дорівнює true, потік stdin залишатиметься відкритим протягом декількох сеансів підключення. Якщо stdinOnce встановлено у true, stdin відкривається під час запуску контейнера, залишається порожнім до першого підключення клієнта до stdin, а потім залишається відкритим і приймає дані до відключення клієнта, після чого stdin закривається і залишається закритим до перезапуску контейнера. Якщо цей прапорець встановлено у false, процеси контейнера, що читають з stdin, ніколи не отримають EOF. Стандартно — false.

  • tty (boolean)

    Чи повинен цей контейнер виділяти для себе TTY, також вимагає, щоб 'stdin' був true. Стандартно — false.

Ефемерний контейнер

Ефемерний контейнер — це тимчасовий контейнер, який ви можете додати до існуючого Pod для ініційованих користувачем дій, таких як налагодження. Ефемерні контейнери не мають гарантій щодо ресурсів або планування, і вони не будуть перезапускатися після завершення роботи або при видаленні чи перезапуску Pod. Kubelet може виселити Pod, якщо ефемерний контейнер спричинить перевищення виділених ресурсів для Pod.

Щоб додати ефемерний контейнер, використовуйте субресурс ephemeralcontainers поточного Pod. Ефемерні контейнери не можуть бути видалені або перезапущені.


  • name (string), обовʼязкове

    Імʼя ефемерного контейнера, вказане як DNS_LABEL. Це імʼя повинно бути унікальним серед усіх контейнерів, контейнерів ініціалізації та ефемерних контейнерів.

  • targetContainerName (string)

    Якщо встановлено, імʼя контейнера з PodSpec, на який націлюється цей ефемерний контейнер. Ефемерний контейнер буде працювати в тих самих просторах імен (IPC, PID тощо), що і цей контейнер. Якщо не встановлено, то ефемерний контейнер використовує простори імен, налаштовані в специфікації Pod.

    Середовище виконання контейнера повинно підтримувати цю функцію. Якщо середовище виконання не підтримує націлювання простору імен, то результат налаштування цього поля є невизначеним.

Образ

Точка входу

  • command ([]string)

    Atomic: буде замінено під час злиття

    Масив команд для точки входу. Не виконується в оболонці. Використовується ENTRYPOINT образу, якщо це не задано. Змінні $(VAR_NAME) розширюються за допомогою середовища контейнера. Якщо змінну не вдасться розгорнути, посилання у вхідному рядку залишиться без змін. Подвійні $$ зменшуються до одного $, що дозволяє екранувати синтаксис $(VAR_NAME): наприклад, "$$(VAR_NAME)" виведе літеральний рядок "$(VAR_NAME)". Екрановані посилання ніколи не будуть розгортатися, незалежно від того, чи існує змінна, чи ні. Не може бути оновлено. Докладніше: https://kubernetes.io/docs/tasks/inject-data-application/define-command-argument-container/#running-a-command-in-a-shell

  • args ([]string)

    Atomic: буде замінено під час злиття

    Аргументи для точки входу. Якщо не надано, буде використано CMD образу контейнера. Змінні $(VAR_NAME) розширюються за допомогою середовища контейнера. Якщо змінну не вдасться розгорнути, посилання у вхідному рядку залишиться без змін. Подвійні $$ зменшуються до одного $, що дозволяє екранувати синтаксис $(VAR_NAME): наприклад, "$$(VAR_NAME)" виведе літеральний рядок "$(VAR_NAME)". Екрановані посилання ніколи не будуть розгортатися, незалежно від того, чи існує змінна, чи ні. Не може бути оновлено. Докладніше: https://kubernetes.io/docs/tasks/inject-data-application/define-command-argument-container/#running-a-command-in-a-shell

  • workingDir (string)

    Робоча тека контейнера. Якщо не вказано, буде використано стандартне значення контейнера, яке може бути налаштоване в образі контейнера. Не може бути оновлено.

Змінні середовища

  • env ([]EnvVar)

    Patch strategy: обʼєднання за ключем name

    Map: унікальні значення ключа name будуть збережені під час злиття

    Список змінних середовища для передачі в контейнер. Не може бути оновлено.

    EnvVar представляє змінну середовища, присутню в контейнері.

    • name (string), обовʼязково

      Назва змінної середовища. Повинно бути C_IDENTIFIER.

    • value (string)

      Змінні посилання $(VAR_NAME) розгортаються за допомогою попередньо визначених змінних середовища в контейнері та будь-яких змінних середовища Service. Якщо змінну не вдається розʼязати, посилання відносно введеного рядка буде незмінним. Подвійний $$ зменшується до одного $, що дозволяє екранувати синтаксис $(VAR_NAME): тобто "$$(VAR_NAME)" буде створювати літеральний рядок "$(VAR_NAME)". Екрановані посилання ніколи не будуть розгорнуті, незалежно від того, чи існує змінна, чи ні. Стандартне значення — "".

    • env.valueFrom (EnvVarSource)

      Джерело значення змінної середовища. Не може бути використано, якщо значення не є пустим.

      EnvVarSource представляє джерело значення EnvVar.

      • env.valueFrom.configMapKeyRef (ConfigMapKeySelector)

        Вибирає ключ з ConfigMap.

        Вибирає ключ з ConfigMap.

        • env.valueFrom.configMapKeyRef.key (string), обовʼязково

          Ключ для вибору.

        • env.valueFrom.configMapKeyRef.name (string), обовʼязково

          Назва обʼєкта на який посилаються. Це поле фактично є обов'язковим, але через зворотну сумісність допускається бути порожнім. Випадки цього типу з порожнім значенням тут майже напевно є помилковими. Докладніше: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names

        • env.valueFrom.configMapKeyRef.optional (boolean)

          Вказує, чи має бути визначений ConfigMap або його ключ

      • env.valueFrom.fieldRef (ObjectFieldSelector)

        Вибирає поле Podʼа: підтримує metadata.name, metadata.namespace, metadata.labels['\<KEY>'], metadata.annotations['\<KEY>'], spec.nodeName, spec.serviceAccountName, status.hostIP, status.podIP, status.podIPs.

      • env.valueFrom.resourceFieldRef (ResourceFieldSelector)

        Вибирає ресурс контейнера: наразі підтримуються лише обмеження і запити ресурсів (limits.cpu, limits.memory, limits.ephemeral-storage, requests.cpu, requests.memory та requests.ephemeral-storage).

      • env.valueFrom.secretKeyRef (SecretKeySelector)

        Вибирає ключ Secretʼа в просторі імен Podʼа

        SecretKeySelector вибирає ключ Secretʼа.

        • env.valueFrom.secretKeyRef.key (string), обовʼязково

          Ключ Secretʼа для вибору. Повинен бути дійсним ключем Secretʼа.

        • env.valueFrom.secretKeyRef.name (string)

          Назва посилання. Це поле фактично є обов'язковим, але через зворотну сумісність допускається бути порожнім. Випадки цього типу з порожнім значенням тут майже напевно є помилковими. Докладніше: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names

        • env.valueFrom.secretKeyRef.optional (boolean)

          Зазначає, чи має бути визначений Secret або його ключ

  • envFrom ([]EnvFromSource)

    Atomic: буде замінено під час злиття

    Список джерел для заповнення змінних середовища в контейнері. Ключі, визначені в межах джерела, повинні бути C_IDENTIFIER. Усі хибні ключі будуть повідомлені як подія при запуску контейнера. Коли ключ існує в декількох джерелах, значення, що асоціюється з останнім джерелом, буде мати пріоритет. Значення, визначене за допомогою Env з дубльованим ключем, буде мати пріоритет. Не може бути оновлено.

    EnvFromSource представляє джерело набору ConfigMaps

    • envFrom.configMapRef (ConfigMapEnvSource)

      ConfigMap для вибору з

      ConfigMapEnvSource вибирає ConfigMap для заповнення змінними середовища.

      Зміст поля Data цільового ConfigMap буде представлено в парах ключ-значення як змінні середовища.

      • envFrom.configMapRef.name (string)

        Назва посилання. Це поле фактично є обов'язковим, але через зворотну сумісність допускається бути порожнім. Випадки цього типу з порожнім значенням тут майже напевно є помилковими. Докладніше: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names

      • envFrom.configMapRef.optional (boolean)

        Вказує, чи має бути визначений ConfigMap

    • envFrom.prefix (string)

      Необовʼязково ідентифікатор для вставлення перед кожним ключем в ConfigMap. Повинен бути C_IDENTIFIER.

    • envFrom.secretRef (SecretEnvSource)

      Secret для вибору з

      SecretEnvSource вибирає Secret для заповнення змінними середовища.

      Зміст поля Data цільового Secret буде представлено в парах ключ-значення як змінні середовища.

      • envFrom.secretRef.name (string)

        Назва посилання. Це поле фактично є обов'язковим, але через зворотну сумісність допускається бути порожнім. Випадки цього типу з порожнім значенням тут майже напевно є помилковими. Докладніше: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names

      • envFrom.secretRef.optional (boolean)

        Вказує, чи має бути визначений Secret

Томи

  • volumeMounts ([]VolumeMount)

    Patch strategy: обʼєднання за ключем mountPath

    Map: унікальні значення ключа mountPath будуть збережені під час злиття

    Томи Podʼів для монтування у файлову систему контейнера. Субшляхи монтування в ефемерних контейнерах не дозволяються. Не може бути оновлено.

    VolumeMount описує монтування Тому всередині контейнера.

    • volumeMounts.mountPath (string), обовʼязково

      Шлях всередині контейнера, за яким повинен бути змонтований том. Не повинен містити ':'.

    • volumeMounts.name (string), обовʼязково

      Повинно відповідати імені Тому.

    • volumeMounts.mountPropagation (string)

      mountPropagation визначає, як монтування розповсюджуються від хоста до контейнера і навпаки. Коли не встановлено, використовується MountPropagationNone. Це поле є бета-версією в 1.10. Коли RecursiveReadOnly встановлено на IfPossible або Enabled, MountPropagation повинно бути None або невказаним (що стандартно дорівнює None).

    • volumeMounts.readOnly (boolean)

      Змонтований як тільки для читання, якщо true, для читання/запису в іншому випадку (false або не вказано). Стандартне значення — false.

    • volumeMounts.recursiveReadOnly (string)

      RecursiveReadOnly визначає, чи повинні змонтовані в режимі "тільки для читання" ресурси оброблятися рекурсивно.

      Якщо ReadOnly дорівнює false, це поле не має значення і не повинно бути вказаним. Якщо ReadOnly дорівнює true і це поле встановлено на Disabled, монтування не виконується рекурсивно в режимі "тільки для читання". Якщо це поле встановлено на IfPossible, монтування виконується рекурсивно в режимі "тільки для читання", якщо це підтримується контейнерним середовищем. Якщо це поле встановлено на Enabled, монтування виконується рекурсивно в режимі "тільки для читання", якщо це підтримується контейнерним середовищем, інакше pod не буде запущено, і буде згенеровано помилку з відповідною причиною.

      Якщо це поле встановлено на IfPossible або Enabled, значення MountPropagation повинно бути встановлено на None (або бути невказаним, що стандартно дорівнює None).

      Якщо це поле не вказано, воно вважається еквівалентним до Disabled.

    • volumeMounts.subPath (string)

      Шлях всередині тому, з якого має бути змонтований том контейнера. Стандартне значення — "" (корінь тому).

    • volumeMounts.subPathExpr (string)

      Розгорнутий шлях всередині тому, з якого має бути змонтований том контейнера. Поводиться схоже до SubPath, але посилання на змінні середовища $(VAR_NAME) розгортаються за допомогою середовища контейнера. Стандартне значення — "" (корінь тому). SubPathExpr і SubPath є взаємовиключними.

  • volumeDevices ([]VolumeDevice)

    Patch strategy: обʼєднання за ключем devicePath

    Map: унікальні значення ключа devicePath будуть збережені під час злиття

    volumeDevices — це список блочних пристроїв, які будуть використані контейнером.

    volumeDevice описує зіставлення необробленого блочного пристрою всередині контейнера.

    • volumeDevices.devicePath (string), обовʼязково

      devicePath — це шлях всередині контейнера, на який буде зіставлено пристрій.

    • volumeDevices.name (string), обовʼязково

      name повинно відповідати імені persistentVolumeClaim в Podʼі.

Ресурси

  • resizePolicy ([]ContainerResizePolicy)

    Atomic: буде замінено під час обʼєднання

    Політика зміни розміру ресурсів для контейнера.

    ContainerResizePolicy представляє політику зміни розміру ресурсів для контейнера.

    • resizePolicy.resourceName (string), обовʼязково

      Назва ресурсу, до якого застосовується ця політика зміни розміру ресурсу. Підтримувані значення: cpu, memory.

    • resizePolicy.restartPolicy (string), обовʼязково

      Політика перезапуску, яку застосовувати при зміні розміру вказаного ресурсу. Якщо не вказано, то стандартно встановлюється NotRequired.

Життєвий цикл

  • terminationMessagePath (string)

    Необовʼязково: Шлях, за яким файл, до якого буде записано повідомлення про завершення контейнера, буде вмонтовано в файлову систему контейнера. Записане повідомлення, призначено для короткого кінцевого статусу, наприклад, повідомлення про помилку виразу. Якщо воно більше 4096 байт, то вузол скоротить його. Загальна довжина повідомлення по всіх контейнерах буде обмежена 12 кб. Стандартне значення — /dev/termination-log. Не може бути оновлено.

  • terminationMessagePolicy (string)

    Вказує, як має бути заповнене повідомлення про завершення. File використовуватиме вміст terminationMessagePath для заповнення повідомлення про статус контейнера при успіху і невдачі. FallbackToLogsOnError використовуватиме останній шматок виводу логу контейнера, якщо файл повідомлення про завершення пустий і контейнер завершився з помилкою. Вивід логу обмежено 2048 байтами або 80 рядками, якщо це менше. Стандартне значення — File. Не може бути оновлено.

  • restartPolicy (string)

    RestartPolicy визначає поведінку перезапуску окремих контейнерів у Podʼі. Це поле може бути встановлено тільки для контейнерів ініціалізації. Ви не можете встановити це поле для ефемерних контейнерів.

Налагодження

  • stdin (boolean)

    Чи повинен цей контейнер виділяти буфер для stdin у середовищі виконання контейнера. Якщо це не встановлено, читання з stdin у контейнері завжди буде призводити до EOF. Стандартно — false.

  • stdinOnce (boolean)

    Чи повинне середовище виконання контейнера закрити канал stdin після того, як він був відкритий одним підключенням. Коли stdin дорівнює true, потік stdin залишатиметься відкритим протягом декількох сеансів підключення. Якщо stdinOnce встановлено у true, stdin відкривається під час запуску контейнера, залишається порожнім до першого підключення клієнта до stdin, а потім залишається відкритим і приймає дані до відключення клієнта, після чого stdin закривається і залишається закритим до перезапуску контейнера. Якщо цей прапорець встановлено у false, процеси контейнера, що читають з stdin, ніколи не отримають EOF. Стандартно — false.

  • tty (boolean)

    Чи повинен цей контейнер виділяти для себе TTY, також вимагає, щоб 'stdin' був true. Стандартно — false.

Контекс безпеки

  • securityContext (SecurityContext)

    SecurityContext визначає параметри безпеки, з якими має працювати контейнер. Якщо встановлено, поля SecurityContext замінять відповідні поля PodSecurityContext. Докладніше: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/

    SecurityContext містить конфігурацію безпеки, яка буде застосована до контейнера. Деякі поля присутні як у SecurityContext, так і в PodSecurityContext. Якщо обидва встановлені, значення в SecurityContext мають пріоритет.

    • securityContext.allowPrivilegeEscalation (boolean)

      AllowPrivilegeEscalation керує тим, чи може процес отримати більше привілеїв, ніж батьківський процес. Це булеве значення безпосередньо контролює, чи буде встановлений прапорець no_new_privs для процесу контейнера.

      AllowPrivilegeEscalation завжди має значення true за наступних умов:

      1. Контейнер запускається в привілейованому режимі (Privileged).
      2. Контейнер має CAP_SYS_ADMIN.

      Зверніть увагу, що це поле не можна встановити, якщо spec.os.name дорівнює windows.

    • securityContext.appArmorProfile (AppArmorProfile)

      appArmorProfile визначає параметри AppArmor, які використовуються для цього контейнера. Якщо встановлено, цей профіль замінює профіль AppArmor для всього podʼа. Зверніть увагу, що це поле не може бути встановлено, коли spec.os.name є windows.

      AppArmorProfile визначає налаштування AppArmor для podʼа або контейнера.

      • securityContext.appArmorProfile.type (string), обовʼязково

        Поле type вказує, який тип профілю AppArmor буде застосовано. Дійсні варіанти:

        • Localhost — профіль, попередньо завантажений на вузлі.
        • RuntimeDefault — стандартний профіль середовища виконання контейнерів.
        • Unconfined — без примусового виконання правил AppArmor.
      • securityContext.appArmorProfile.localhostProfile (string)

        localhostProfile вказує профіль, завантажений на вузлі, який слід використовувати. Профіль має бути попередньо налаштований на вузлі для коректної роботи. Назва профілю повинна відповідати завантаженій назві. Це поле повинно бути встановлене, якщо і тільки якщо тип дорівнює "Localhost".

    • securityContext.capabilities (Capabilities)

      Можливості для додавання/видалення під час запуску контейнерів. Стандарто використовується набір можливостей, наданих середовищем виконання контейнера. Зверніть увагу, що це поле не може бути встановлено, коли spec.os.name є windows.

      Додає та видаляє можливості POSIX з працюючих контейнерів.

      • securityContext.capabilities.add ([]string)

        Atomic: буде замінено під час злиття

        Додані можливості.

      • securityContext.capabilities.drop ([]string)

        Atomic: буде замінено під час злиття

        Видалені можливості.

    • securityContext.procMount (string)

      procMount позначає тип монтування proc, який слід використовувати для контейнерів. Стандартне значення — Default, яке використовує стандартні налаштування середовища виконання контейнера для шляхів тільки для читання та змаскованих шляхів. Це вимагає увімкнення прапорця функції ProcMountType. Зверніть увагу, що це поле не може бути встановлено, коли spec.os.name є windows.

    • securityContext.privileged (boolean)

      Запуск контейнера у привілейованому режимі. Процеси у привілейованих контейнерах по суті еквівалентні root на хості. Стандартно дорівнює false. Зверніть увагу, що це поле не може бути встановлено, коли spec.os.name є windows.

    • securityContext.readOnlyRootFilesystem (boolean)

      Чи має цей контейнер кореневу файлову систему тільки для читання. Стандартно дорівнює false. Зверніть увагу, що це поле не може бути встановлено, коли spec.os.name є windows.

    • securityContext.runAsUser (int64)

      UID, з яким запускається початковий процес контейнера. Стандартно використовується користувач, вказаний у метаданих образу, якщо не вказано інше. Також може бути встановлено в PodSecurityContext. Якщо значення встановлено як у SecurityContext, так і в PodSecurityContext, пріоритет має значення, зазначене в SecurityContext. Зверніть увагу, що це поле не може бути встановлено, коли spec.os.name є windows.

    • securityContext.runAsNonRoot (boolean)

      Вказує, що контейнер повинен запускатися як користувач, який не є root. Якщо значення true, Kubelet перевірить образ під час виконання, щоб гарантувати, що він не запускається з UID 0 (root), і не запустить контейнер, якщо це не так. Якщо поле не встановлено або має значення false, така перевірка не виконується. Також може бути налаштовано в SecurityContext. Якщо значення встановлено як у SecurityContext, так і в PodSecurityContext, пріоритет має значення, вказане в SecurityContext.

    • securityContext.runAsGroup (int64)

      GID, під яким запускається початковий процес контейнера. Якщо не встановлено, використовується стандартне значення для середовища виконання. Також може бути вказано в SecurityContext. Якщо значення встановлено як у SecurityContext, так і в PodSecurityContext, пріоритет має значення, зазначене в SecurityContext для цього контейнера. Зверніть увагу, що це поле не можна встановити, коли spec.os.name — windows.

    • securityContext.seLinuxOptions (SELinuxOptions)

      Контекст SELinux, який буде застосований до контейнера. Якщо не вказано, середовище виконання контейнера призначить випадковий контекст SELinux для кожного контейнера. Може також бути встановлено в PodSecurityContext. Якщо встановлено в обох SecurityContext і PodSecurityContext, пріоритет має значення, вказане в SecurityContext. Зверніть увагу, що це поле не може бути встановлено, коли spec.os.name є windows.

      SELinuxOptions — це мітки, що застосовуються до контейнера

      • securityContext.seLinuxOptions.level (string)

        Level є міткою рівня SELinux, що застосовується до контейнера.

      • securityContext.seLinuxOptions.role (string)

        Role є міткою ролі SELinux, що застосовується до контейнера.

      • securityContext.seLinuxOptions.type (string)

        Type є міткою типу SELinux, що застосовується до контейнера.

      • securityContext.seLinuxOptions.user (string)

        User є міткою користувача SELinux, що застосовується до контейнера.

    • securityContext.seccompProfile (SeccompProfile)

      Параметри seccomp для використання контейнерами в цьому Podʼі. Зверніть увагу, що це поле не можна встановити, коли spec.os.name — windows.

      SeccompProfile визначає налаштування профілю seccomp для Podʼа/контейнера. Може бути встановлено лише одне джерело профілю.

      • securityContext.seccompProfile.type (string), обовʼязкове

        type вказує, який тип профілю seccomp буде застосовано. Допустимі варіанти:

        • Localhost — має бути використаний профіль, визначений у файлі на вузлі.
        • RuntimeDefault — має бути використаний стандартний профіль для середовища виконання контейнерів.
        • Unconfined — не застосовується жоден профіль.
      • securityContext.seccompProfile.localhostProfile (string)

        localhostProfile вказує, що має бути використаний профіль, визначений у файлі на вузлі. Профіль має бути попередньо налаштований на вузлі, щоб працювати. Має бути низхідний шлях, відносно до налаштованого розташування профілю seccomp kubelet. Має бути встановлено, якщо тип "Localhost". НЕ має бути встановлено для будь-якого іншого типу.

    • securityContext.windowsOptions (WindowsSecurityContextOptions)

      Специфічні налаштування для Windows, які застосовуються до всіх контейнерів. Якщо не вказано, використовуються опції з PodSecurityContext. Якщо встановлено в обох SecurityContext і PodSecurityContext, пріоритет має значення, вказане в SecurityContext. Зверніть увагу, що це поле не може бути встановлено, коли spec.os.name є linux.

      WindowsSecurityContextOptions містять специфічні для Windows параметри та облікові дані.

      • securityContext.windowsOptions.gmsaCredentialSpec (string)

        GMSACredentialSpec — це місце, де вебхук GMSA (https://github.com/kubernetes-sigs/windows-gmsa) вставляє вміст специфікації облікових даних GMSA, названої полем GMSACredentialSpecName.

      • securityContext.windowsOptions.gmsaCredentialSpecName (string)

        GMSACredentialSpecName — це назва специфікації облікових даних GMSA, яка буде використана.

      • securityContext.windowsOptions.hostProcess (boolean)

        HostProcess визначає, чи слід запускати контейнер як контейнер ʼHost Processʼ. Усі контейнери Pod повинні мати однакове значення HostProcess (не дозволено мати суміш контейнерів HostProcess та не-HostProcess). Крім того, якщо HostProcess є true, то HostNetwork також повинен бути встановлений у true.

      • securityContext.windowsOptions.runAsUserName (string)

        Імʼя користувача в Windows для запуску точки входу процесу контейнера. Стандартно використовується користувач, вказаний у метаданих образу, якщо не вказано. Може також бути встановлено в PodSecurityContext. Якщо встановлено в обох SecurityContext і PodSecurityContext, пріоритет має значення, вказане в SecurityContext.

Не дозволяються

  • ports ([]ContainerPort)

    Patch strategy: обʼєднання за ключем containerPort

    Map: унікальні значення за ключами containerPort, protocol будуть збережені під час обʼєднання

    Для ефемерних контейнерів визначення портів не дозволяється.

    ContainerPort представляє мережевий порт в одному контейнері.

    • ports.containerPort (int32), обовʼязково

      Номер порту для відкриття на IP-адресі контейнера. Це повинен бути дійсний номер порту, 0 < x < 65536.

    • ports.hostIP (string)

      IP-адреса хоста, що звʼязується з зовнішнім портом.

    • ports.hostPort (int32)

      Номер порту для відкриття на хості. Якщо вказано, це повинен бути дійсний номер порту, 0 < x < 65536. Якщо вказано HostNetwork, це значення повинно збігатися з ContainerPort. Більшість контейнерів цього не потребують.

    • ports.name (string)

      Якщо вказано, це повинен бути IANA_SVC_NAME і єдиним в межах Podʼа. Кожен іменований порт в Podʼі повинен мати унікальне імʼя. Назва порту, на яку можна посилатися з Service.

    • ports.protocol (string)

      Протокол для порту. Повинен бути UDP, TCP або SCTP. Стандартне значення — "TCP".

  • resources (ResourceRequirements)

    Для ефемерних контейнерів заборонено використовувати ресурси. Ефемерні контейнери використовують вільні ресурси, вже виділені для Podʼа.

    • resources.claims ([]ResourceClaim)

      Map: унікальні значення за ключем будуть збережені під час обʼєднання

      Claims містить назви ресурсів, визначених в spec.resourceClaims, які використовуються цим контейнером.

      Це поле альфа-версії і вимагає включення функціоналу DynamicResourceAllocation.

      Це поле є незмінним. Його можна встановити тільки для контейнерів.

      ResourceClaim посилається на один запис в PodSpec.ResourceClaims.

      • resources.claims.name (string), обовʼязково

        Імʼя повинно відповідати імені одного запису в pod.spec.resourceClaims Podʼа, де використовується це поле. Це робить цей ресурс доступним всередині контейнера.

      • resources.claims.request (string)

        Request — це імʼя, вибране для запиту в зазначеній заявці. Якщо поле порожнє, буде доступно все з заявки; в іншому випадку, доступний буде лише результат цього запиту.

    • resources.limits (map[string]Quantity)

      Limits визначає максимальну кількість обчислювальних ресурсів, дозволених. Докладніше: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/

    • resources.requests (map[string]Quantity)

      Requests описує мінімальну кількість обчислювальних ресурсів, що потрібна. Якщо Requests відсутній для контейнера, він стандартно встановлюється в Limits, якщо це явно вказано, інакше — у значення, визначеного реалізацією. Requests не може перевищувати Limits. Докладніше: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/

  • lifecycle (Lifecycle)

    Для ефемерних контейнерів заборонено використовувати lifecycle.

    Lifecycle описує дії, які система управління повинна виконати у відповідь на події життєвого циклу контейнера. Для обробників життєвого циклу PostStart і PreStop управління контейнером блокується, поки дія не буде завершена, якщо процес контейнера виявляється несправним, тоді обробник переривається.

    • lifecycle.postStart (LifecycleHandler)

      PostStart викликається негайно після створення контейнера. Якщо обробник не вдалося виконати, контейнер буде завершено і перезапущено згідно зі своєю політикою перезапуску. Інше управління контейнером блокується, поки хук не завершиться. Докладніше: https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks

    • lifecycle.preStop (LifecycleHandler)

      PreStop викликається негайно перед тим, як контейнер буде завершено через запит API або подію управління, таку як невдача проби справності/запуску, випередження, скорочення ресурсів тощо. Обробник не викликається, якщо контейнер впаде або закінчить роботу. Період перебігу належного завершення підраховується до виконання хуку PreStop. Незалежно від результату обробника, контейнер в кінцевому підсумку завершиться протягом періоду належного завершення Pod (якщо він не буде затриманий завершенням залишкових операцій). Інше управління контейнером блокується, поки хук не завершиться або досягне періоду належного завершення. Докладніше: https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks

  • livenessProbe (Probe)

    Проби не дозволені для ефемерних контейнерів.

  • readinessProbe (Probe)

    Проби не дозволені для ефемерних контейнерів.

  • startupProbe (Probe)

    Проби не дозволені для ефемерних контейнерів.

Обробник життєвого циклу

Обробник життєвого циклу (LifecycleHandler) визначає конкретну дію, яку слід виконати в хуці життєвого циклу. Має бути вказане тільки одне з полів, за винятком TCPSocket.


  • exec (ExecAction)

    Exec визначає дію, яку слід виконати.

    ExecAction описує дію "виконати в контейнері".

    • exec.command ([]string)

      Atomic: буде замінено під час злиття

      Command — це командний рядок для виконання всередині контейнера, робоча тека для команди — корінь ('/') у файловій системі контейнера. Команда виконується безпосередньо, а не в оболонці, тому традиційні команди оболонки ('|', тощо) не працюватимуть. Для використання оболонки потрібно явно викликати цю оболонку. Статус виходу 0 вважається готовим/справним, а ненульовий — несправним.

  • httpGet (HTTPGetAction)

    HTTPGet визначає HTTP-запит, який слід виконати.

    HTTPGetAction описує дію на основі HTTP Get-запитів.

    • httpGet.port (IntOrString), обовʼязково

      Назва або номер порту для доступу до контейнера. Номер повинен бути в діапазоні від 1 до 65535. Назва повинна бути IANA_SVC_NAME.

      IntOrString — це тип, який може містити int32 або рядок. Під час перетворення з/у JSON або YAML він створює або споживає внутрішній тип. Це дозволяє мати, наприклад, поле JSON, яке може приймати назву або номер.

    • httpGet.host (string)

      Імʼя хосту для підключення, стандартно використовується IP-адреса Podʼа. Ймовірно, вам потрібно встановити "Host" в httpHeaders замість цього.

    • httpGet.httpHeaders ([]HTTPHeader)

      Atomic: буде замінено під час злиття

      Власні заголовки для встановлення в запиті. HTTP дозволяє повторювані заголовки.

      HTTPHeader описує власний заголовок, який буде використовуватись в HTTP-пробах.

      • httpGet.httpHeaders.name (string), обовʼязково

        Назва поля заголовка. Воно буде канонізовано при виведенні, тому імена, що відрізняються регістром, будуть сприйматись як один і той самий заголовок.

      • httpGet.httpHeaders.value (string), обовʼязково

        Значення поля заголовка.

    • httpGet.path (string)

      Шлях для доступу до HTTP-сервера.

    • httpGet.scheme (string)

      Схема для підключення до хоста. Стандартне значення — HTTP.

  • sleep (SleepAction)

    Sleep представляє тривалість, протягом якої контейнер повинен бездіяти перед завершенням.

    SleepAction описує дію "sleep".

    • sleep.seconds (int64), обовʼязково

      Seconds — кількість секунд для sleep.

  • tcpSocket (TCPSocketAction)

    Застаріло. TCPSocket НЕ підтримується як обробник життєвого циклу та зберігається для зворотної сумісності. Валідації цього поля не проводиться, і хуки життєвого циклу зазнають невдачі під час виконання, коли вказано обробник tcp.

    TCPSocketAction описує дію на основі відкриття сокета

    • tcpSocket.port (IntOrString), обовʼязково

      Номер або назва порту для доступу до контейнера. Номер повинен бути в діапазоні від 1 до 65535. Назва повинна бути IANA_SVC_NAME.

      IntOrString — це тип, який може містити int32 або рядок. Під час перетворення з/у JSON або YAML він створює або споживає внутрішній тип. Це дозволяє мати, наприклад, поле JSON, яке може приймати назву або номер.

    • tcpSocket.host (string)

      Додатково: Імʼя хоста для підключення, стандартно використовується IP-адреса Podʼа.

NodeAffinity

Node affinity — це група правил планування вузлів за спорідненістю.


  • preferredDuringSchedulingIgnoredDuringExecution ([]PreferredSchedulingTerm)

    Atomic: буде замінено під час злиття

    Планувальник надаватиме перевагу розміщенню Podʼів на вузлах, які відповідають виразам спорідненості, зазначеним у цьому полі, але може вибрати вузол, який порушує один або кілька цих виразів. Найбільш пріоритетним є вузол із найбільшою сумою ваг, тобто для кожного вузла, який відповідає всім вимогам планування (запит ресурсів, вирази спорідненості requiredDuringScheduling тощо), обчислюється сума шляхом ітерації через елементи цього поля та додавання "ваги" до суми, якщо вузол відповідає відповідним matchExpressions; вузол(и) з найвищою сумою є найпріоритетнішими.

    Порожній термін пріоритету планування відповідає всім об’єктам з неявною вагою 0 (тобто, він не діє). Нульовий термін пріоритету планування не відповідає жодному обʼєкту (тобто, також не діє).

    • preferredDuringSchedulingIgnoredDuringExecution.preference (NodeSelectorTerm), обов’язковий

      Термін селектора вузлів, пов’язаний з відповідною вагою.

      Нульовий або порожній термін селектора вузлів не відповідає жодному обʼєкту. Вимоги до них обʼєднані за допомогою операції AND. Тип TopologySelectorTerm реалізує підмножину NodeSelectorTerm.

      Atomic: буде замінено під час злиття

      Список вимог селектора вузлів за мітками вузлів.

      Atomic: буде замінено під час злиття

      Список вимог селектора вузлів за полями вузлів.

    • preferredDuringSchedulingIgnoredDuringExecution.weight (int32), обов’язковий

      Вага, пов’язана з відповідним nodeSelectorTerm, у діапазоні 1-100.

  • requiredDuringSchedulingIgnoredDuringExecution (NodeSelector)

    Якщо вимоги спорідненості, зазначені в цьому полі, не будуть виконані під час планування, Pod не буде розміщено на вузлі. Якщо вимоги спорідненості, зазначені в цьому полі, перестануть виконуватися в якийсь момент під час виконання Podʼа (наприклад, через оновлення), система може або не може спробувати врешті-решт виселити Pod з його вузла.

    Селектор вузлів представляє обʼєднання результатів одного або кількох запитів за мітками до набору вузлів; тобто він представляє OR селекторів, представлених термінами селектора вузлів.

    • requiredDuringSchedulingIgnoredDuringExecution.nodeSelectorTerms ([]NodeSelectorTerm), обов’язковий

      Atomic: буде замінено під час злиття

      Обов’язковий. Список термінів селектора вузлів. Терміни обʼєднані за допомогою операції OR.

      Null або порожній термін селектора вузла не відповідає жодному об'єкту. Вимоги до них складаються за принципом AND. Тип TopologySelectorTerm реалізує підмножину NodeSelectorTerm.

      • requiredDuringSchedulingIgnoredDuringExecution.nodeSelectorTerms.matchExpressions ([]NodeSelectorRequirement)

        Atomic: буде замінено під час злиття

        Список вимог селектора вузлів за мітками вузлів.

      • requiredDuringSchedulingIgnoredDuringExecution.nodeSelectorTerms.matchFields ([]NodeSelectorRequirement)

        Atomic: буде замінено під час злиття

        Список вимог селектора вузлів за полями вузлів.

PodAffinity

Pod affinity — це група правил планування між Podʼами за спорідненістю.


  • preferredDuringSchedulingIgnoredDuringExecution ([]WeightedPodAffinityTerm)

    Atomic: буде замінено під час злиття

    Планувальник надаватиме перевагу розміщенню Podʼів на вузлах, які відповідають виразам спорідненості, зазначеним у цьому полі, але може вибрати вузол, який порушує один або кілька з цих виразів. Найбільш пріоритетним є вузол із найбільшою сумою ваг, тобто для кожного вузла, який відповідає всім вимогам планування (запит ресурсів, вирази спорідненості requiredDuringScheduling тощо), обчислюється сума шляхом ітерації через елементи цього поля та додавання "ваги" до суми, якщо на вузлі є Podʼи, які відповідають відповідному podAffinityTerm; вузол(и) з найвищою сумою є найпріоритетнішими.

    Ваги всіх відповідних полів WeightedPodAffinityTerm додаються для кожного вузла, щоб знайти найпріоритетніший(і) вузол(и).

    • preferredDuringSchedulingIgnoredDuringExecution.podAffinityTerm (PodAffinityTerm), обов’язковий

      Обов’язковий. Термін спорідненості Podʼа, пов’язаний з відповідною вагою.

      Визначає набір Podʼів (тобто тих, які відповідають labelSelector у стосунку до заданих простірів імен), з якими цей Pod має бути розміщений разом (спорідненість) або не разом (анти-спорідненість), де розміщення разом визначається як виконання на вузлі, значення мітки якого з ключем <topologyKey> збігається з будь-яким вузлом, на якому виконується Pod з набору Podʼів.

      • preferredDuringSchedulingIgnoredDuringExecution.podAffinityTerm.topologyKey (string), обов’язковий

        Цей Pod має бути розміщений разом (спорідненість) або не разом (анти-спорідненість) з Podʼами, які відповідають labelSelector у зазначених просторах імен, де розміщення разом визначається як виконання на вузлі, значення мітки якого з ключем topologyKey збігається з будь-яким вузлом, на якому виконується будь-який з вибраних Podʼів. Порожній topologyKey не допускається.

      • preferredDuringSchedulingIgnoredDuringExecution.podAffinityTerm.labelSelector (LabelSelector)

        Запит за мітками до набору ресурсів, у даному випадку Podʼів. Якщо він дорівнює null, цей PodAffinityTerm не збігається з жодним Pod'ом.

      • preferredDuringSchedulingIgnoredDuringExecution.podAffinityTerm.matchLabelKeys ([]string)

        Atomic: буде замінено під час злиття

        MatchLabelKeys — це набір ключів міток podʼів для вибору podʼів, які будуть враховані. Ключі використовуються для пошуку значень у мітках вхідних podʼів, ці мітки ключ-значення обʼєднуються з labelSelector як key in (value), щоб вибрати групу існуючих podʼів, які будуть враховані для (анти)спорідненості вхідного podʼа. Ключі, яких немає у вхідних мітках podʼів, ігноруються. Стандартне значення – порожнє. Один і той же ключ не може існувати як у matchLabelKeys, так і в labelSelector. Також matchLabelKeys не може бути встановлено, якщо labelSelector не встановлений. Це бета-поле і вимагає увімкнення функціональної можливості MatchLabelKeysInPodAffinity (стандартно увімкнено).

      • preferredDuringSchedulingIgnoredDuringExecution.podAffinityTerm.mismatchLabelKeys ([]string)

        Atomic: буде замінено під час злиття

        MismatchLabelKeys — це набір ключів міток podʼів для вибору podʼів, які будуть враховані. Ключі використовуються для пошуку значень у мітках вхідних podʼів, ці мітки ключ-значення обʼєднуються з labelSelector як key notin (value), щоб вибрати групу існуючих podʼів, які будуть враховані для (анти)спорідненості вхідного podʼа. Ключі, яких немає у вхідних мітках podʼів, ігноруються. Стандартне значення — порожнє. Один і той же ключ не може існувати як у mismatchLabelKeys, так і в labelSelector. Також mismatchLabelKeys не може бути встановлено, якщо labelSelector не встановлений. Це бета-поле і вимагає увімкнення функціональної можливості MatchLabelKeysInPodAffinity (стандартно увімкнено).

      • preferredDuringSchedulingIgnoredDuringExecution.podAffinityTerm.namespaceSelector (LabelSelector)

        Запит за мітками до набору просторів імен, до яких застосовується термін. Термін застосовується до обʼєднання просторів імен, вибраних цим полем, і тих, що зазначені в полі namespaces. Нульовий селектор і нульовий або порожній список просторів імен означає "простір імен цього Podʼа". Порожній селектор ({}) відповідає всім просторам імен.

      • preferredDuringSchedulingIgnoredDuringExecution.podAffinityTerm.namespaces ([]string)

        Atomic: буде замінено під час злиття

        Простори імен визначають статичний список назв просторів імен, до яких застосовується термін. Термін застосовується до обʼєднання просторів імен, зазначених у цьому полі, і тих, що вибрані namespaceSelector. Нульовий або порожній список просторів імен і нульовий namespaceSelector означає "простір імен цього Podʼа".

    • preferredDuringSchedulingIgnoredDuringExecution.weight (int32), обов’язковий

      Вага, пов’язана з відповідним podAffinityTerm, у діапазоні 1-100.

  • requiredDuringSchedulingIgnoredDuringExecution ([]PodAffinityTerm)

    Atomic: буде замінено під час злиття

    Якщо вимоги спорідненісті, зазначені в цьому полі, не будуть виконані під час планування, Pod не буде розміщено на вузлі. Якщо вимоги спорідненісті, зазначені в цьому полі, перестануть виконуватися в якийсь момент під час виконання Podʼа (наприклад, через оновлення міток Podʼа), система може або не може спробувати врешті-решт виселити Pod з його вузла. Коли є кілька елементів, списки вузлів, що відповідають кожному podAffinityTerm, перетинаються, тобто всі терміни мають бути виконані.

    Визначає набір Podʼів (тобто тих, які відповідають labelSelector у стосунку до заданих простірів імен), з якими цей Pod має бути розміщений разом (спорідненість) або не разом (анти-спорідненість), де розміщення разом визначається як виконання на вузлі, значення мітки якого з ключем <topologyKey> збігається з будь-яким вузлом, на якому виконується Pod з набору Podʼів.

    • requiredDuringSchedulingIgnoredDuringExecution.topologyKey (string), обов’язковий

      Цей Pod має бути розміщений разом (спорідненість) або не разом (анти-спорідненість) з Podʼами, які відповідають labelSelector у зазначених просторах імен, де розміщення разом визначається як виконання на вузлі, значення мітки якого з ключем topologyKey збігається з будь-яким вузлом, на якому виконується будь-який з вибраних Podʼів. Порожній topologyKey не допускається.

    • requiredDuringSchedulingIgnoredDuringExecution.labelSelector (LabelSelector)

      Запит за мітками до набору ресурсів, у даному випадку Podʼів. Якщо він дорівнює null, цей PodAffinityTerm не збігається з жодним Podʼом.

    • requiredDuringSchedulingIgnoredDuringExecution.matchLabelKeys ([]string)

      Atomic: буде замінено під час злиття

      MatchLabelKeys — це набір ключів міток podʼів для вибору podʼів, які будуть враховані. Ключі використовуються для пошуку значень у мітках вхідних podʼів, ці мітки ключ-значення обʼєднуються з labelSelector як key in (value), щоб вибрати групу існуючих podʼів, які будуть враховані для (анти)спорідненості вхідного podʼа. Ключі, яких немає у вхідних мітках podʼів, ігноруються. Стандартне значення – порожнє. Один і той же ключ не може існувати як у matchLabelKeys, так і в labelSelector. Також matchLabelKeys не може бути встановлено, якщо labelSelector не встановлений. Це бета-поле і вимагає увімкнення функціональної можливості MatchLabelKeysInPodAffinity (стандартно увімкнено).

    • requiredDuringSchedulingIgnoredDuringExecution.mismatchLabelKeys ([]string)

      Atomic: буде замінено під час злиття

      MismatchLabelKeys — це набір ключів міток podʼів для вибору podʼів, які будуть враховані. Ключі використовуються для пошуку значень у мітках вхідних podʼів, ці мітки ключ-значення обʼєднуються з labelSelector як key notin (value), щоб вибрати групу існуючих podʼів, які будуть враховані для (анти)спорідненості вхідного podʼа. Ключі, яких немає у вхідних мітках podʼів, ігноруються. Стандартне значення — порожнє. Один і той же ключ не може існувати як у mismatchLabelKeys, так і в labelSelector. Також mismatchLabelKeys не може бути встановлено, якщо labelSelector не встановлений. Це бета-поле і вимагає увімкнення функціональної можливості MatchLabelKeysInPodAffinity (стандартно увімкнено).

    • requiredDuringSchedulingIgnoredDuringExecution.namespaceSelector (LabelSelector)

      Запит за мітками до набору просторів імен, до яких застосовується термін. Термін застосовується до обʼєднання просторів імен, вибраних цим полем, і тих, що зазначені в полі namespaces. Нульовий селектор і нульовий або порожній список просторів імен означає "простір імен цього Podʼа". Порожній селектор ({}) відповідає всім просторам імен.

    • requiredDuringSchedulingIgnoredDuringExecution.namespaces ([]string)

      Atomic: буде замінено під час злиття

      Простори імен визначають статичний список назв просторів імен, до яких застосовується термін. Термін застосовується до обʼєднання просторів імен, зазначених у цьому полі, і тих, що вибрані namespaceSelector. Нульовий або порожній список просторів імен і нульовий namespaceSelector означає "простір імен цього Podʼа".

PodAntiAffinity

Pod anti affinity — це група правил планування між Podʼами за анти-спорідненістю.


  • preferredDuringSchedulingIgnoredDuringExecution ([]WeightedPodAffinityTerm)

    Atomic: буде замінено під час злиття

    Планувальник надаватиме перевагу розміщенню Podʼів на вузлах, які відповідають виразам анти-спорідненості, зазначеним у цьому полі, але може вибрати вузол, який порушує один або кілька з цих виразів. Найбільш пріоритетним є вузол із найбільшою сумою ваг, тобто для кожного вузла, який відповідає всім вимогам планування (запит ресурсів, вирази анти-спорідненості requiredDuringScheduling тощо), обчислюється сума шляхом ітерації через елементи цього поля та додавання "ваги" до суми, якщо на вузлі є Podʼи, які відповідають відповідному podAffinityTerm; вузол(и) з найвищою сумою є найпріоритетнішими.

    Ваги всіх відповідних полів WeightedPodAffinityTerm додаються для кожного вузла, щоб знайти найпріоритетніший(і) вузол(и).

    • preferredDuringSchedulingIgnoredDuringExecution.podAffinityTerm (PodAffinityTerm), обов’язковий

      Обов’язковий. Термін спорідненості Podʼа, пов’язаний з відповідною вагою.

      Визначає набір Podʼів (тобто тих, які відповідають labelSelector у стосунку до заданих простірів імен), з якими цей Pod має бути розміщений разом (спорідненість) або не разом (анти-спорідненість), де розміщення разом визначається як виконання на вузлі, значення мітки якого з ключем <topologyKey> збігається з будь-яким вузлом, на якому виконується Pod з набору Podʼів.

      • preferredDuringSchedulingIgnoredDuringExecution.podAffinityTerm.topologyKey (string), обов’язковий

        Цей Pod повинен бути розміщений разом (спорідненість) або не разом (анти-спорідненість) з Podʼами, які відповідають labelSelector у зазначених просторах імен. Розміщення разом визначається як виконання на вузлі, значення мітки якого з ключем topologyKey збігається з будь-яким вузлом, на якому виконується будь-який з вибраних Podʼів. Порожній topologyKey не допускається.

      • preferredDuringSchedulingIgnoredDuringExecution.podAffinityTerm.labelSelector (LabelSelector)

        Запит за мітками до набору ресурсів, у даному випадку Podʼів. Якщо він дорівнює null, цей PodAffinityTerm не збігається з жодним Podʼом.

      • preferredDuringSchedulingIgnoredDuringExecution.podAffinityTerm.matchLabelKeys ([]string)

        Atomic: буде замінено під час злиття

        MatchLabelKeys — це набір ключів міток podʼів для вибору podʼів, які будуть враховані. Ключі використовуються для пошуку значень у мітках вхідних podʼів, ці мітки ключ-значення обʼєднуються з labelSelector як key in (value), щоб вибрати групу існуючих podʼів, які будуть враховані для (анти)спорідненості вхідного podʼа. Ключі, яких немає у вхідних мітках podʼів, ігноруються. Стандартне значення – порожнє. Один і той же ключ не може існувати як у matchLabelKeys, так і в labelSelector. Також matchLabelKeys не може бути встановлено, якщо labelSelector не встановлений. Це бета-поле і вимагає увімкнення функціональної можливості MatchLabelKeysInPodAffinity (стандартно увімкнено).

      • preferredDuringSchedulingIgnoredDuringExecution.podAffinityTerm.mismatchLabelKeys ([]string)

        Atomic: буде замінено під час злиття

        MismatchLabelKeys — це набір ключів міток podʼів для вибору podʼів, які будуть враховані. Ключі використовуються для пошуку значень у мітках вхідних podʼів, ці мітки ключ-значення обʼєднуються з labelSelector як key notin (value), щоб вибрати групу існуючих podʼів, які будуть враховані для (анти)спорідненості вхідного podʼа. Ключі, яких немає у вхідних мітках podʼів, ігноруються. Стандартне значення — порожнє. Один і той же ключ не може існувати як у mismatchLabelKeys, так і в labelSelector. Також mismatchLabelKeys не може бути встановлено, якщо labelSelector не встановлений. Це бета-поле і вимагає увімкнення функціональної можливості MatchLabelKeysInPodAffinity (стандартно увімкнено).

      • preferredDuringSchedulingIgnoredDuringExecution.podAffinityTerm.namespaceSelector (LabelSelector)

        Запит за мітками до набору просторів імен, до яких застосовується термін. Термін застосовується до обʼєднання просторів імен, вибраних цим полем, і тих, що зазначені в полі namespaces. Нульовий селектор і нульовий або порожній список просторів імен означає "простір імен цього Podʼа". Порожній селектор ({}) відповідає всім просторам імен.

      • preferredDuringSchedulingIgnoredDuringExecution.podAffinityTerm.namespaces ([]string)

        Atomic: буде замінено під час злиття

        Простори імен визначають статичний список назв просторів імен, до яких застосовується термін. Термін застосовується до обʼєднання просторів імен, зазначених у цьому полі, і тих, що вибрані namespaceSelector. Нульовий або порожній список просторів імен і нульовий namespaceSelector означає "простір імен цього Podʼа".

    • preferredDuringSchedulingIgnoredDuringExecution.weight (int32), обов’язковий

      Вага, пов’язана з відповідним podAffinityTerm, у діапазоні 1-100.

  • requiredDuringSchedulingIgnoredDuringExecution ([]PodAffinityTerm)

    Atomic: буде замінено під час злиття

    Якщо вимоги анти-спорідненості, зазначені в цьому полі, не будуть виконані під час планування, Pod не буде розміщено на вузлі. Якщо вимоги анти-спорідненості, зазначені в цьому полі, перестануть виконуватися в якийсь момент під час виконання Podʼа (наприклад, через оновлення міток Podʼа), система може або не може спробувати врешті-решт виселити Pod з його вузла. Коли є кілька елементів, списки вузлів, що відповідають кожному podAffinityTerm, перетинаються, тобто всі терміни мають бути виконані.

    Визначає набір Podʼів (тобто тих, які відповідають labelSelector у стосунку до заданих простірів імен), з якими цей Pod має бути розміщений разом (спорідненість) або не разом (анти-спорідненість), де розміщення разом визначається як виконання на вузлі, значення мітки якого з ключем <topologyKey> збігається з будь-яким вузлом, на якому виконується Pod з набору Podʼів.

    • requiredDuringSchedulingIgnoredDuringExecution.topologyKey (string), обов’язковий

      Цей Pod має бути розміщений разом (спорідненість) або не разом (анти-спорідненість) з Podʼами, які відповідають labelSelector у зазначених просторах імен. Розміщення разом визначається як виконання на вузлі, значення мітки якого з ключем topologyKey збігається з будь-яким вузлом, на якому виконується будь-який з вибраних Podʼів. Порожній topologyKey не допускається.

    • requiredDuringSchedulingIgnoredDuringExecution.labelSelector (LabelSelector)

      Запит за мітками до набору ресурсів, у даному випадку Podʼів. Якщо він дорівнює null, цей PodAffinityTerm не збігається з жодним Podʼом.

    • requiredDuringSchedulingIgnoredDuringExecution.matchLabelKeys ([]string)

      Atomic: буде замінено під час злиття

      MatchLabelKeys — це набір ключів міток podʼів для вибору podʼів, які будуть враховані. Ключі використовуються для пошуку значень у мітках вхідних podʼів, ці мітки ключ-значення обʼєднуються з labelSelector як key in (value), щоб вибрати групу існуючих podʼів, які будуть враховані для (анти)спорідненості вхідного podʼа. Ключі, яких немає у вхідних мітках podʼів, ігноруються. Стандартне значення – порожнє. Один і той же ключ не може існувати як у matchLabelKeys, так і в labelSelector. Також matchLabelKeys не може бути встановлено, якщо labelSelector не встановлений. Це бета-поле і вимагає увімкнення функціональної можливості MatchLabelKeysInPodAffinity (стандартно увімкнено).

    • requiredDuringSchedulingIgnoredDuringExecution.mismatchLabelKeys ([]string)

      Atomic: буде замінено під час злиття

      MismatchLabelKeys — це набір ключів міток podʼів для вибору podʼів, які будуть враховані. Ключі використовуються для пошуку значень у мітках вхідних podʼів, ці мітки ключ-значення обʼєднуються з labelSelector як key notin (value), щоб вибрати групу існуючих podʼів, які будуть враховані для (анти)спорідненості вхідного podʼа. Ключі, яких немає у вхідних мітках podʼів, ігноруються. Стандартне значення — порожнє. Один і той же ключ не може існувати як у mismatchLabelKeys, так і в labelSelector. Також mismatchLabelKeys не може бути встановлено, якщо labelSelector не встановлений. Це бета-поле і вимагає увімкнення функціональної можливості MatchLabelKeysInPodAffinity (стандартно увімкнено).

    • requiredDuringSchedulingIgnoredDuringExecution.namespaceSelector (LabelSelector)

      Запит за мітками до набору просторів імен, до яких застосовується термін. Термін застосовується до обʼєднання просторів імен, вибраних цим полем, і тих, що зазначені в полі namespaces. Нульовий селектор і нульовий або порожній список просторів імен означає "простір імен цього Podʼа". Порожній селектор ({}) відповідає всім просторам імен.

    • requiredDuringSchedulingIgnoredDuringExecution.namespaces ([]string)

      Atomic: буде замінено під час злиття

      Простори імен визначають статичний список назв просторів імен, до яких застосовується термін. Термін застосовується до обʼєднання просторів імен, зазначених у цьому полі, і тих, що вибрані namespaceSelector. Нульовий або порожній список просторів імен і нульовий namespaceSelector означає "простір імен цього Podʼа".

Проба

Проба описує перевірку стану, яка виконується для контейнера, щоб визначити, чи він справний або готовий приймати трафік.


  • exec (ExecAction)

    Exec визначає дію, яку потрібно виконати.

    ExecAction описує дію "виконати в контейнері".

    • exec.command ([]string)

      Atomic: буде замінено під час злиття

      Command — це командний рядок для виконання всередині контейнера, робоча тека для команди — корінь ('/') у файловій системі контейнера. Команда виконується безпосередньо, а не в оболонці, тому традиційні команди оболонки ('|', тощо) не працюватимуть. Для використання оболонки потрібно явно викликати цю оболонку. Статус виходу 0 вважається готовим/справним, а ненульовий — несправним.

  • httpGet (HTTPGetAction)

    HTTPGet визначає HTTP-запит для виконання.

    HTTPGetAction описує дію на основі HTTP GET запитів.

    • httpGet.port (IntOrString), обовʼязково

      Назва або номер порту для доступу до контейнера. Номер повинен бути в діапазоні від 1 до 65535. Назва повинна бути IANA_SVC_NAME.

      IntOrString — це тип, який може містити int32 або рядок. Під час перетворення з/у JSON або YAML він створює або споживає внутрішній тип. Це дозволяє мати, наприклад, поле JSON, яке може приймати назву або номер.

    • httpGet.host (string)

      Імʼя хосту для підключення, стандартно використовується IP-адреса Podʼа. Ймовірно, вам потрібно встановити "Host" в httpHeaders замість цього.

    • httpGet.httpHeaders ([]HTTPHeader)

      Atomic: буде замінено під час злиття

      Власні заголовки для встановлення в запиті. HTTP дозволяє повторювані заголовки.

      HTTPHeader описує власний заголовок, який буде використовуватись в HTTP-пробах.

      • httpGet.httpHeaders.name (string), обовʼязково

        Назва поля заголовка. Воно буде канонізовано при виведенні, тому імена, що відрізняються регістром, будуть сприйматись як один і той самий заголовок.

      • httpGet.httpHeaders.value (string), обовʼязково

        Значення поля заголовка.

    • httpGet.path (string)

      Шлях для доступу на HTTP сервері.

    • httpGet.scheme (string)

      Схема для підключення до хоста. Стандартне значення — HTTP.

  • tcpSocket (TCPSocketAction)

    TCPSocket визначає дію, що включає TCP-порт.

    TCPSocketAction описує дію на основі відкриття сокету.

    • tcpSocket.port (IntOrString), обовʼязково

      Номер або назва порту для доступу до контейнера. Номер повинен бути в діапазоні від 1 до 65535. Назва повинна бути IANA_SVC_NAME.

      IntOrString — це тип, який може містити int32 або рядок. Під час перетворення з/у JSON або YAML він створює або споживає внутрішній тип. Це дозволяє мати, наприклад, поле JSON, яке може приймати назву або номер.

    • tcpSocket.host (string)

      Додатково: Імʼя хоста для підключення, стандартно використовується IP-адреса Podʼа.

  • initialDelaySeconds (int32)

    Кількість секунд після запуску контейнера перед початком перевірки на життєздатність. Докладніше: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes

  • terminationGracePeriodSeconds (int64)

    Необовʼязкова тривалість у секундах, необхідна для завершення роботи Podʼа після збою перевірки. Період належного завершення — це тривалість у секундах після того, як процесам у Podʼі надіслано сигнал про завершення і час до примусової зупинки процесів сигналом kill. Встановіть цю величину більше, ніж очікуваний час завершення вашого процесу. Якщо це значення є nil, буде використано terminationGracePeriodSeconds Podʼа. В іншому випадку, це значення перекриває значення, надане у специфікації Podʼа. Значення має бути невідʼємним числом. Значення нуль означає негайну зупинку через сигнал kill (без можливості завершення). Це поле є бета-функцією і вимагає увімкнення gate ProbeTerminationGracePeriod. Мінімальне значення — 1. Якщо не встановлено, використовується spec.terminationGracePeriodSeconds.

  • periodSeconds (int32)

    Як часто (у секундах) виконувати перевірку. Стандартне значення — 10 секунд. Мінімальне значення — 1.

  • timeoutSeconds (int32)

    Кількість секунд після якої перевірка завершується з тайм-аутом. Стандартне значення — 1 секунда. Мінімальне значення — 1. Докладніше: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes

  • failureThreshold (int32)

    Мінімальна кількість послідовних збоїв, щоб перевірка вважалася невдалою після того, як вона вже пройшла успішно. Стандартне значення — 3. Мінімальне значення — 1.

  • successThreshold (int32)

    Мінімальна кількість послідовних успішних перевірок, щоб вважати перевірку успішною після того, як вона не вдалася. Стандартне значення — 1. Має бути 1 для liveness та startup. Мінімальне значення — 1.

  • grpc (GRPCAction)

    GRPC визначає дію, що включає GRPC-порт.

    **

    • grpc.port (int32), обовʼязково

      Номер порту GRPC сервісу. Номер має бути в діапазоні від 1 до 65535.

    • grpc.service (string)

      Service — це імʼя сервісу, яке потрібно вказати в GRPC HealthCheckRequest (див. https://github.com/grpc/grpc/blob/master/doc/health-checking.md).

      Якщо це не вказано, то стандартна поведінка визначається GRPC.

PodStatus

PodStatus представляє інформацію про стан Podʼа. Стан може відставати від фактичного стану системи, особливо якщо вузол, на якому розміщений Pod, не може звʼязатися з панеллю управління.


  • nominatedNodeName (string)

    nominatedNodeName встановлюється тільки тоді, коли цей Pod випереджає інші Podʼи на вузлі, але не може бути негайно розміщений, оскільки жертвам випередження надається час для завершення роботи. Це поле не гарантує, що Pod буде розміщений на цьому вузлі. Планувальник може вирішити розмістити Pod в іншому місці, якщо інші вузли стануть доступними раніше. Планувальник також може вирішити надати ресурси на цьому вузлі Podʼу вищого пріоритету, який створюється після вилучення. В результаті це поле може відрізнятися від PodSpec.nodeName, коли Pod розміщується.

  • hostIP (string)

    hostIP містить IP-адресу хоста, до якого призначено Pod. Пусте, якщо Pod ще не запущено. Pod може бути призначений на вузол, у якого є проблема з kubelet, що означає, що HostIP не буде оновлено, навіть якщо вузол призначено Podʼу.

  • hostIPs ([]HostIP)

    Patch strategy: злиття за ключем ip

    Atomic: буде замінено під час злиття

    hostIPs містить IP-адреси, виділені хосту. Якщо це поле задано, перший запис повинен відповідати полю hostIP. Цей список пустий, якщо Pod ще не запущено. Pod може бути призначений на вузол, у якого є проблема з kubelet, що означає, що HostIPs не буде оновлено, навіть якщо вузол призначено цьому Podʼу.

    HostIP представляє одну IP-адресу, виділену хосту.

    • hostIPs.ip (string), обовʼязково

      IP — це IP-адреса, призначена хосту.

  • startTime (Time)

    RFC 3339 дата і час, коли обʼєкт був підтверджений Kubelet. Це відбувається перед тим, як Kubelet завантажив образ контейнера(ів) для Podʼа.

    Time — це обгортка навколо time.Time, яка підтримує правильну серіалізацію в YAML і JSON. Надаються обгортки для багатьох фабричних методів, які пропонує пакет time.

  • phase (string)

    phase Podʼа — це просте, високорівневе резюме про те, на якому етапі свого життєвого циклу знаходиться Pod. Массив умов, поля reason і message, а також масиви статусів окремих контейнерів містять більше деталей про стан Podʼа. Існує пʼять можливих значень фаз:

    • Pending: Pod прийнято системою Kubernetes, але один або більше образів контейнерів ще не створено. Це включає час до розміщення, а також час, витрачений на завантаження образів через мережу, що може зайняти деякий час.

    • Running: Pod був привʼязаний до вузла, і всі контейнери були створені. Принаймні один контейнер все ще працює або знаходиться в процесі запуску чи перезапуску.

    • Succeeded: всі контейнери в Podʼі завершили роботу успішно і не будуть перезапускатися.

    • Failed: всі контейнери в Podʼі завершили роботу, і принаймні один контейнер завершився з помилкою. Контейнер або завершився з ненульовим статусом, або був завершений системою.

    • Unknown: з якоїсь причини стан Podʼа не вдалося отримати, зазвичай через помилку у звʼязку з хостом Podʼа.

    Докладніше: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#pod-phase

  • message (string)

    Повідомлення, зрозуміле людині, що вказує на деталі, чому Pod знаходиться в цьому стані.

  • reason (string)

    Коротке повідомлення у форматі CamelCase, що вказує на деталі, чому Pod знаходиться в цьому стані, наприклад, ʼEvictedʼ.

  • podIP (string)

    podIP — IP-адреса, виділена Podʼа. Доступна для маршрутизації принаймні в межах кластера. Пусте, якщо ще не виділено.

  • podIPs ([]PodIP)

    Patch strategy: злиття за ключем ip

    Map: унікальні значення ключа ip будуть збережені під час злиття

    podIPs містить IP-адреси, виділені Podʼу. Якщо це поле задано, 0-й запис повинен відповідати полю podIP. Podʼам може бути виділено не більше одного значення для кожного з IPv4 та IPv6. Цей список пустий, якщо IP-адреси ще не виділено.

    PodIP представляє одну IP-адресу, виділену Podʼу.

    • podIPs.ip (string), обовʼязково

      IP — це IP-адреса, призначена Podʼу.

  • conditions ([]PodCondition)

    Patch strategy: злиття за ключем type

    Map: унікальні значення ключа type будуть збережені під час злиття

    Поточний стан обслуговування Podʼа. Докладніше: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#pod-conditions

    PodCondition містить деталі поточного стану цього Podʼа.

    • conditions.status (string), обовʼязково

      Статус стану. Може бути True, False, Unknown. Докладніше: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#pod-conditions

    • conditions.type (string), обовʼязково

      Тип є типом стану. Докладніше: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#pod-conditions

    • conditions.lastProbeTime (Time)

      Останній час, коли ми перевіряли стан.

      Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

    • conditions.lastTransitionTime (Time)

      Останній час, коли стан перейшов з одного статусу в інший.

      Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

    • conditions.message (string)

      Повідомлення, зрозуміле людині, що вказує на деталі останнього переходу.

    • conditions.reason (string)

      Унікальна, однослівна, у CamelCase причина останнього переходу умови.

  • qosClass (string)

    Класифікація якості обслуговування (QOS), присвоєна Podʼу на основі вимог до ресурсів. Дивіться тип PodQOSClass для доступних класів QOS. Докладніше: https://kubernetes.io/docs/concepts/workloads/pods/pod-qos/#quality-of-service-classes

  • initContainerStatuses ([]ContainerStatus)

    Atomic: буде замінено під час злиття

    Список містить один запис на кожен контейнер ініціалізації в маніфесті. Найбільш успішний контейнер ініціалізації матиме ready = true, найбільш нещодавно запущений контейнер матиме startTime встановлений. Докладніше: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#pod-and-container-status

    ContainerStatus містить деталі поточного стану цього контейнера.

    • initContainerStatuses.allocatedResources (map[string]Quantity)

      AllocatedResources представляє обчислювальні ресурси, виділені для цього контейнера вузлом. Kubelet встановлює це значення у Container.Resources.Requests після успішного допуску podʼа та після успішного допуску бажаного масштабування podʼа.

    • initContainerStatuses.allocatedResourcesStatus ([]ResourceStatus)

      Patch strategy: злиття за ключем type

      Map: унікальні значення ключа type будуть збережені під час злиття

      AllocatedResourcesStatus представляє статус різних ресурсів, виділених для цього podʼа.

      **

      • initContainerStatuses.allocatedResourcesStatus.name (string), обовʼязково

        Назва ресурсу. Має бути унікальною в межах podʼа та відповідати одному з ресурсів зі специфікації podʼа.

      • initContainerStatuses.allocatedResourcesStatus.resources ([]ResourceHealth)

        Map: унікальні значення ключа resourceID будуть збережені під час злиття

        Список унікальних станів ресурсів. Кожен елемент списку містить унікальний ідентифікатор ресурсу та стан ресурсу. Мінімум, ResourceID має унікально ідентифікувати ресурс, виділений podʼу на вузлі протягом життя podʼа. Дивіться тип ResourceID для його визначення.

        ResourceHealth представляє стан справності ресурсу. Він містить останню інформацію про стан пристрою. Це частина KEP https://kep.k8s.io/4680, і планується додавання історичних змін стану справності в майбутніх ітераціях KEP.

        • initContainerStatuses.allocatedResourcesStatus.resources.resourceID (string), обовʼязково

          ResourceID є унікальним ідентифікатором ресурсу. Дивіться тип ResourceID для отримання додаткової інформації.

        • initContainerStatuses.allocatedResourcesStatus.resources.health (string)

          Health ресурсу. Може бути одним з:

          • Healthy: працює нормально
          • Unhealthy: повідомлено про несправний стан. Ми вважаємо це тимчасовою проблемою зі справністю, оскільки наразі у нас немає механізму для розрізнення тимчасових і постійних проблем.
          • Unknown: статус не можна визначити. Наприклад, втулок пристрою було відключено і він не був повторно зареєстрований з того часу.

          В майбутньому ми можемо ввести статус PermanentlyUnhealthy.

    • initContainerStatuses.containerID (string)

      ContainerID є ідентифікатором контейнера у форматі '<type>://<container_id>'. Де type є ідентифікатором середовища виконання контейнера, що повертається з виклику Version API CRI (наприклад, "containerd").

    • initContainerStatuses.image (string), обовʼязково

      Image є назвою образу контейнера з якого запущений у контейнері. Образ контейнера може не збігатися з образом, що використовується в PodSpec, оскільки він міг бути розвʼязаний середовищем виконання. Докладніше: https://kubernetes.io/docs/concepts/containers/images

    • initContainerStatuses.imageID (string), обовʼязково

      ImageID є ідентифікатором образу контейнера. Ідентифікатор образу може не збігатися з ідентифікатором образу, що використовується в PodSpec, оскільки він міг бути розвʼязаний середовищем виконання.

    • initContainerStatuses.lastState (ContainerState)

      LastTerminationState містить останній стан завершення контейнера, щоб допомогти в налагодженні аварійних зупинок та перезапусків контейнера. Це поле не заповнюється, якщо контейнер все ще запущений і RestartCount дорівнює 0.

      ContainerState містить можливий стан контейнера. Може бути зазначено лише один з його членів. Якщо жоден з них не вказано, стандартно використовується ContainerStateWaiting.

      • initContainerStatuses.lastState.running (ContainerStateRunning)

        Відомості про запущений контейнер

        ContainerStateRunning є станом контейнера, який запущений.

        • initContainerStatuses.lastState.running.startedAt (Time)

          Час, коли контейнер був востаннє (пере)запущений.

          Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

      • initContainerStatuses.lastState.terminated (ContainerStateTerminated)

        Відомості про контейнер, який завершив свою роботу

        ContainerStateTerminated є станом контейнера, який завершив свою роботу.

        • initContainerStatuses.lastState.terminated.containerID (string)

          ContainerID є ідентифікатором контейнера у форматі '<type>://<container_id>'.

        • initContainerStatuses.lastState.terminated.exitCode (int32), обовʼязково

          Код виходу з останнього завершення роботи контейнера

        • initContainerStatuses.lastState.terminated.startedAt (Time)

          Час, коли розпочалося попереднє виконання контейнера

          Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

        • initContainerStatuses.lastState.terminated.finishedAt (Time)

          Час, коли контейнер востаннє завершив свою роботу

          Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

        • initContainerStatuses.lastState.terminated.message (string)

          Повідомлення щодо останнього завершення роботи контейнера

        • initContainerStatuses.lastState.terminated.reason (string)

          (коротка) причина останнього завершення роботи контейнера

        • initContainerStatuses.lastState.terminated.signal (int32)

          Сигнал з останнього завершення роботи контейнера

      • initContainerStatuses.lastState.waiting (ContainerStateWaiting)

        Деталі про контейнер, що очікує

        ContainerStateWaiting є станом контейнера, що очікує.

        • initContainerStatuses.lastState.waiting.message (string)

          Повідомлення про причину, чому контейнер ще не запущений.

        • initContainerStatuses.lastState.waiting.reason (string)

          (коротка) причина, чому контейнер ще не запущений

    • initContainerStatuses.name (string), обовʼязково

      Name є DNS_LABEL, що представляє унікальну назву контейнера. Кожен контейнер в podʼі повинен мати унікальну назву серед усіх типів контейнерів. Не можна оновити.

    • initContainerStatuses.ready (boolean), обовʼязково

      Ready вказує, чи контейнер наразі проходить перевірку готовності. Значення змінюватиметься, оскільки перевірки готовності продовжують виконуватися. Якщо перевірки готовності не вказані, це поле стандартно буде true, як тільки контейнер буде повністю запущений (див. поле Started).

      Значення зазвичай використовується для визначення, чи контейнер готовий приймати трафік.

    • initContainerStatuses.resources (ResourceRequirements)

      Resources представляє запити та ліміти обчислювальних ресурсів, які були успішно застосовані до працюючого контейнера після його запуску або успішного масштабування.

      ResourceRequirements описує вимоги до обчислювальних ресурсів.

      • initContainerStatuses.resources.claims ([]ResourceClaim)

        Map: унікальні значення ключа name будуть збережені під час злиття

        Claims перелік назв ресурсів, визначених у spec.resourceClaims, які використовуються цим контейнером.

        Це поле альфа-версії і потребує включення функціональної можливості DynamicResourceAllocation.

        Це поле незмінне. Воно може бути встановлено лише для контейнерів.

        ResourceClaim посилається на один запис у PodSpec.ResourceClaims.

        • initContainerStatuses.resources.claims.name (string), обовʼязково

          Name має відповідати назві одного запису в pod.spec.resourceClaims podʼа, де використовується це поле. Це робить ресурс доступним всередині контейнера.

        • initContainerStatuses.resources.claims.request (string)

          Request є назвою, обраною для запиту в зазначеній заявці. Якщо порожньо, всі ресурси з заявки стають доступними, інакше лише результат цього запиту.

      • initContainerStatuses.resources.limits (map[string]Quantity)

        Limits описує максимальну кількість дозволених обчислювальних ресурсів. Докладніше: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/

      • initContainerStatuses.resources.requests (map[string]Quantity)

        Requests описує мінімальну кількість обчислювальних ресурсів, необхідних для контейнера. Якщо Requests не вказано для контейнера, воно стандартно дорівнює Limits, якщо вони явно вказані, інакше — значенню, визначеному реалізацією. Requests не може перевищувати Limits. Докладніше: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/

    • initContainerStatuses.restartCount (int32), обовʼязково

      RestartCount містить кількість разів, коли контейнер був перезапущений. Kubelet намагається завжди збільшувати це значення, але є випадки, коли стан може бути втрачено через перезавантаження вузла, і тоді значення може бути скинуто на 0. Значення ніколи не є відʼємним.

    • initContainerStatuses.started (boolean)

      Started вказує, чи контейнер завершив свій хук життєвого циклу postStart і пройшов перевірку запуску. Ініціалізується як false, стає true після того, як перевірка запуску вважається успішною. Скидається на false, коли контейнер перезапускається або якщо kubelet тимчасово втрачає стан. У обох випадках перевірки запуску будуть виконані знову. Завжди true, коли перевірка запуску не визначена і контейнер запущений та пройшов хук життєвого циклу postStart. Значення null слід трактувати так само, як false.

    • initContainerStatuses.state (ContainerState)

      State містить деталі про поточний стан контейнера.

      ContainerState містить можливий стан контейнера. Може бути зазначено лише один з його членів. Якщо жоден з них не вказано, стандартно використовується ContainerStateWaiting.

      • initContainerStatuses.state.running (ContainerStateRunning)

        Деталі про запущений контейнер

        ContainerStateRunning є станом контейнера, який запущений.

        • initContainerStatuses.state.running.startedAt (Time)

          Час, коли контейнер був востаннє (пере)запущений.

          Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

      • initContainerStatuses.state.terminated (ContainerStateTerminated)

        Відомості про контейнер, який завершив свою роботу

        ContainerStateTerminated є станом контейнера, який завершив свою роботу.

        • initContainerStatuses.state.terminated.containerID (string)

          ContainerID є ідентифікатором контейнера у форматі '<type>://<container_id>'.

        • initContainerStatuses.state.terminated.exitCode (int32), обовʼязково

          Код виходу з останнього завершення роботи контейнера

        • initContainerStatuses.state.terminated.startedAt (Time)

          Час, коли розпочалося попереднє виконання контейнера

          Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

        • initContainerStatuses.state.terminated.finishedAt (Time)

          Час, коли контейнер востаннє завершив свою роботу

          Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

        • initContainerStatuses.state.terminated.message (string)

          Повідомлення щодо останнього завершення роботи контейнера

        • initContainerStatuses.state.terminated.reason (string)

          (коротка) причина останнього завершення роботи контейнера

        • initContainerStatuses.state.terminated.signal (int32)

          Сигнал з останнього завершення роботи контейнера

      • initContainerStatuses.state.waiting (ContainerStateWaiting)

        Деталі про контейнер, що очікує

        ContainerStateWaiting є станом контейнера, що очікує.

        • initContainerStatuses.state.waiting.message (string)

          Повідомлення про причину, чому контейнер ще не запущений.

        • initContainerStatuses.state.waiting.reason (string)

          (коротка) причина, чому контейнер ще не запущений

    • initContainerStatuses.user (ContainerUser)

      User представляє інформацію про ідентифікацію користувача, спочатку прикріплену до першого процесу контейнера

      ContainerUser представляє інформацію про ідентифікацію користувача

      • initContainerStatuses.user.linux (LinuxContainerUser)

        Linux містить інформацію про ідентифікацію користувача, спочатку прикріплену до першого процесу контейнерів у Linux. Зверніть увагу, що фактична ідентичність, яка виконується, може змінюватися, якщо процес має достатні привілеї для цього.

        LinuxContainerUser представляє інформацію про ідентифікацію користувача в контейнерах Linux

        • initContainerStatuses.user.linux.gid (int64), обовʼязково

          GID є основним gid, спочатку прикріпленим до першого процесу в контейнері

        • initContainerStatuses.user.linux.uid (int64), обовʼязково

          UID є основним uid, спочатку прикріпленим до першого процесу в контейнері

        • initContainerStatuses.user.linux.supplementalGroups ([]int64)

          Atomic: буде замінено під час злиття

          SupplementalGroups є додатковими групами, спочатку прикріпленими до першого процесу в контейнері

    • initContainerStatuses.volumeMounts ([]VolumeMountStatus)

      Patch strategy: злиття за ключем mountPath

      Map: унікальні значення ключа mountPath будуть збережені під час злиття

      Стан монтування томів.

      VolumeMountStatus показує стан монтування томів.

      • initContainerStatuses.volumeMounts.mountPath (string), обовʼязково

        MountPath відповідає оригінальному VolumeMount.

      • initContainerStatuses.volumeMounts.name (string), обовʼязково

        Name відповідає назві оригінального VolumeMount.

      • initContainerStatuses.volumeMounts.readOnly (boolean)

        ReadOnly відповідає оригінальному VolumeMount.

      • initContainerStatuses.volumeMounts.recursiveReadOnly (string)

        RecursiveReadOnly має бути встановлено на Disabled, Enabled або unspecified (для монтувань відмінних "тільки для читання"). Значення IfPossible в оригінальному VolumeMount повинно бути перетворено на Disabled або Enabled, залежно від результату монтування.

  • containerStatuses ([]ContainerStatus)

    Atomic: буде замінено під час злиття

    Список містить один запис на кожен контейнер в маніфесті. Докладніше: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#pod-and-container-status

    ContainerStatus містить деталі поточного стану цього контейнера.

    • containerStatuses.allocatedResources (map[string]Quantity)

      AllocatedResources представляє обчислювальні ресурси, виділені для цього контейнера вузлом. Kubelet встановлює це значення у Container.Resources.Requests після успішного допуску podʼа та після успішного допуску бажаного масштабування podʼа.

    • containerStatuses.allocatedResourcesStatus ([]ResourceStatus)

      Patch strategy: злиття за ключем name

      Map: унікальні значення ключа name будуть збережені під час злиття

      AllocatedResourcesStatus представляє статус різних ресурсів, виділених для цього podʼа.

      **

      • containerStatuses.allocatedResourcesStatus.name (string), обовʼязково

        Назва ресурсу. Має бути унікальною в межах podʼа та відповідати одному з ресурсів зі специфікації podʼа.

      • containerStatuses.allocatedResourcesStatus.resources ([]ResourceHealth)

        Map: унікальні значення ключа resourceID будуть збережені під час злиття

        Список унікальних станів ресурсів. Кожен елемент списку містить унікальний ідентифікатор ресурсу та стан ресурсу. Мінімум, ResourceID має унікально ідентифікувати ресурс, виділений podʼу на вузлі протягом життя podʼа. Дивіться тип ResourceID для його визначення.

        ResourceHealth представляє стан справності ресурсу. Він містить останню інформацію про стан пристрою. Це частина KEP https://kep.k8s.io/4680, і планується додавання історичних змін стану справності в майбутніх ітераціях KEP.

        • containerStatuses.allocatedResourcesStatus.resources.resourceID (string), обовʼязково

          ResourceID є унікальним ідентифікатором ресурсу. Дивіться тип ResourceID для отримання додаткової інформації.

        • containerStatuses.allocatedResourcesStatus.resources.health (string)

          Health ресурсу. Може бути одним з:

          • Healthy: працює нормально
          • Unhealthy: повідомлено про несправний стан. Ми вважаємо це тимчасовою проблемою зі справністю, оскільки наразі у нас немає механізму для розрізнення тимчасових і постійних проблем.
          • Unknown: статус не можна визначити. Наприклад, втулок пристрою було відключено і він не був повторно зареєстрований з того часу.

          В майбутньому ми можемо ввести статус PermanentlyUnhealthy.

    • containerStatuses.containerID (string)

      ContainerID є ідентифікатором контейнера у форматі '<type>://<container_id>'. Де type є ідентифікатором середовища виконання контейнера, що повертається з виклику Version API CRI (наприклад, "containerd").

    • containerStatuses.image (string), обовʼязково

      Image є назвою образу контейнера з якого запущений у контейнері. Образ контейнера може не збігатися з образом, що використовується в PodSpec, оскільки він міг бути розвʼязаний середовищем виконання. Докладніше: https://kubernetes.io/docs/concepts/containers/images

    • containerStatuses.imageID (string), обовʼязково

      ImageID є ідентифікатором образу контейнера. Ідентифікатор образу може не збігатися з ідентифікатором образу, що використовується в PodSpec, оскільки він міг бути розвʼязаний середовищем виконання.

    • containerStatuses.lastState (ContainerState)

      LastTerminationState містить останній стан завершення контейнера, щоб допомогти в налагодженні аварійних зупинок та перезапусків контейнера. Це поле не заповнюється, якщо контейнер все ще запущений і RestartCount дорівнює 0.

      ContainerState містить можливий стан контейнера. Може бути зазначено лише один з його членів. Якщо жоден з них не вказано, стандартно використовується ContainerStateWaiting.

      • containerStatuses.lastState.running (ContainerStateRunning)

        Відомості про запущений контейнер

        ContainerStateRunning є станом контейнера, який запущений.

        • containerStatuses.lastState.running.startedAt (Time)

          Час, коли контейнер був востаннє (пере)запущений.

          Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

      • containerStatuses.lastState.terminated (ContainerStateTerminated)

        Відомості про контейнер, який завершив свою роботу

        ContainerStateTerminated є станом контейнера, який завершив свою роботу.

        • containerStatuses.lastState.terminated.containerID (string)

          ContainerID є ідентифікатором контейнера у форматі '<type>://<container_id>'.

        • containerStatuses.lastState.terminated.exitCode (int32), обовʼязково

          Код виходу з останнього завершення роботи контейнера

        • containerStatuses.lastState.terminated.startedAt (Time)

          Час, коли розпочалося попереднє виконання контейнера

          Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

        • containerStatuses.lastState.terminated.finishedAt (Time)

          Час, коли контейнер востаннє завершив свою роботу

          Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

        • containerStatuses.lastState.terminated.message (string)

          Повідомлення щодо останнього завершення роботи контейнера

        • containerStatuses.lastState.terminated.reason (string)

          (коротка) причина останнього завершення роботи контейнера

        • containerStatuses.lastState.terminated.signal (int32)

          Сигнал з останнього завершення роботи контейнера

      • containerStatuses.lastState.waiting (ContainerStateWaiting)

        Деталі про контейнер, що очікує

        ContainerStateWaiting є станом контейнера, що очікує.

        • containerStatuses.lastState.waiting.message (string)

          Повідомлення про причину, чому контейнер ще не запущений.

        • containerStatuses.lastState.waiting.reason (string)

          (коротка) причина, чому контейнер ще не запущений

    • containerStatuses.name (string), обовʼязково

      Name є DNS_LABEL, що представляє унікальну назву контейнера. Кожен контейнер в podʼі повинен мати унікальну назву серед усіх типів контейнерів. Не можна оновити.

    • containerStatuses.ready (boolean), обовʼязково

      Ready вказує, чи контейнер наразі проходить перевірку готовності. Значення змінюватиметься, оскільки перевірки готовності продовжують виконуватися. Якщо перевірки готовності не вказані, це поле стандартно буде true, як тільки контейнер буде повністю запущений (див. поле Started).

      Значення зазвичай використовується для визначення, чи контейнер готовий приймати трафік.

    • containerStatuses.resources (ResourceRequirements)

      Resources представляє запити та ліміти обчислювальних ресурсів, які були успішно застосовані до працюючого контейнера після його запуску або успішного масштабування.

      ResourceRequirements описує вимоги до обчислювальних ресурсів.

      • containerStatuses.resources.claims ([]ResourceClaim)

        Map: унікальні значення ключа name будуть збережені під час злиття

        Claims перелік назв ресурсів, визначених у spec.resourceClaims, які використовуються цим контейнером.

        Це поле альфа-версії і потребує включення функціональної можливості DynamicResourceAllocation.

        Це поле незмінне. Воно може бути встановлено лише для контейнерів.

        ResourceClaim посилається на один запис у PodSpec.ResourceClaims.

        • containerStatuses.resources.claims.name (string), обовʼязково

          Name має відповідати назві одного запису в pod.spec.resourceClaims podʼа, де використовується це поле. Це робить ресурс доступним всередині контейнера.

        • containerStatuses.resources.claims.request (string)

          Request є назвою, обраною для запиту в зазначеній заявці. Якщо порожньо, всі ресурси з заявки стають доступними, інакше лише результат цього запиту.

      • containerStatuses.resources.limits (map[string]Quantity)

        Limits описує максимальну кількість дозволених обчислювальних ресурсів. Докладніше: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/

      • containerStatuses.resources.requests (map[string]Quantity)

        Requests описує мінімальну кількість обчислювальних ресурсів, необхідних для контейнера. Якщо Requests не вказано для контейнера, воно стандартно дорівнює Limits, якщо вони явно вказані, інакше — значенню, визначеному реалізацією. Requests не може перевищувати Limits. Докладніше: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/

    • containerStatuses.restartCount (int32), обовʼязково

      RestartCount містить кількість разів, коли контейнер був перезапущений. Kubelet намагається завжди збільшувати це значення, але є випадки, коли стан може бути втрачено через перезавантаження вузла, і тоді значення може бути скинуто на 0. Значення ніколи не є відʼємним.

    • containerStatuses.started (boolean)

      Started вказує, чи контейнер завершив свій хук життєвого циклу postStart і пройшов перевірку запуску. Ініціалізується як false, стає true після того, як перевірка запуску вважається успішною. Скидається на false, коли контейнер перезапускається або якщо kubelet тимчасово втрачає стан. У обох випадках перевірки запуску будуть виконані знову. Завжди true, коли перевірка запуску не визначена і контейнер запущений та пройшов хук життєвого циклу postStart. Значення null слід трактувати так само, як false.

    • containerStatuses.state (ContainerState)

      State містить деталі про поточний стан контейнера.

      ContainerState містить можливий стан контейнера. Може бути зазначено лише один з його членів. Якщо жоден з них не вказано, стандартно використовується ContainerStateWaiting.

      • containerStatuses.state.running (ContainerStateRunning)

        Деталі про запущений контейнер

        ContainerStateRunning є станом контейнера, який запущений.

        • containerStatuses.state.running.startedAt (Time)

          Час, коли контейнер був востаннє (пере)запущений.

          Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

      • containerStatuses.state.terminated (ContainerStateTerminated)

        Відомості про контейнер, який завершив свою роботу

        ContainerStateTerminated є станом контейнера, який завершив свою роботу.

        • containerStatuses.state.terminated.containerID (string)

          ContainerID є ідентифікатором контейнера у форматі '<type>://<container_id>'.

        • containerStatuses.state.terminated.exitCode (int32), обовʼязково

          Код виходу з останнього завершення роботи контейнера

        • containerStatuses.state.terminated.startedAt (Time)

          Час, коли розпочалося попереднє виконання контейнера

          Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

        • containerStatuses.state.terminated.finishedAt (Time)

          Час, коли контейнер востаннє завершив свою роботу

          Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

        • containerStatuses.state.terminated.message (string)

          Повідомлення щодо останнього завершення роботи контейнера

        • containerStatuses.state.terminated.reason (string)

          (коротка) причина останнього завершення роботи контейнера

        • containerStatuses.state.terminated.signal (int32)

          Сигнал з останнього завершення роботи контейнера

      • containerStatuses.state.waiting (ContainerStateWaiting)

        Деталі про контейнер, що очікує

        ContainerStateWaiting є станом контейнера, що очікує.

        • containerStatuses.state.waiting.message (string)

          Повідомлення про причину, чому контейнер ще не запущений.

        • containerStatuses.state.waiting.reason (string)

          (коротка) причина, чому контейнер ще не запущений

    • containerStatuses.user (ContainerUser)

      User представляє інформацію про ідентифікацію користувача, спочатку прикріплену до першого процесу контейнера

      ContainerUser представляє інформацію про ідентифікацію користувача

      • containerStatuses.user.linux (LinuxContainerUser)

        Linux містить інформацію про ідентифікацію користувача, спочатку прикріплену до першого процесу контейнерів у Linux. Зверніть увагу, що фактична ідентичність, яка виконується, може змінюватися, якщо процес має достатні привілеї для цього.

        LinuxContainerUser представляє інформацію про ідентифікацію користувача в контейнерах Linux

        • containerStatuses.user.linux.gid (int64), обовʼязково

          GID є основним gid, спочатку прикріпленим до першого процесу в контейнері

        • containerStatuses.user.linux.uid (int64), обовʼязково

          UID є основним uid, спочатку прикріпленим до першого процесу в контейнері

        • containerStatuses.user.linux.supplementalGroups ([]int64)

          Atomic: буде замінено під час злиття

          SupplementalGroups є додатковими групами, спочатку прикріпленими до першого процесу в контейнері

    • containerStatuses.volumeMounts ([]VolumeMountStatus)

      Patch strategy: злиття за ключем mountPath

      Map: унікальні значення ключа mountPath будуть збережені під час злиття

      Стан монтування томів.

      VolumeMountStatus показує стан монтування томів.

      • containerStatuses.volumeMounts.mountPath (string), обовʼязково

        MountPath відповідає оригінальному VolumeMount.

      • containerStatuses.volumeMounts.name (string), обовʼязково

        Name відповідає назві оригінального VolumeMount.

      • containerStatuses.volumeMounts.readOnly (boolean)

        ReadOnly відповідає оригінальному VolumeMount.

      • containerStatuses.volumeMounts.recursiveReadOnly (string)

        RecursiveReadOnly має бути встановлено на Disabled, Enabled або unspecified (для монтувань відмінних "тільки для читання"). Значення IfPossible в оригінальному VolumeMount повинно бути перетворено на Disabled або Enabled, залежно від результату монтування.

  • ephemeralContainerStatuses ([]ContainerStatus)

    Atomic: буде замінено під час злиття

    Статус будь-яких ефемерних контейнерів, які працювали в цьому Podʼі.

    ContainerStatus містить деталі поточного стану цього контейнера.

    • ephemeralContainerStatuses.allocatedResources (map[string]Quantity)

      AllocatedResources представляє обчислювальні ресурси, виділені для цього контейнера вузлом. Kubelet встановлює це значення у Container.Resources.Requests після успішного допуску podʼа та після успішного допуску бажаного масштабування podʼа.

    • ephemeralContainerStatuses.allocatedResourcesStatus ([]ResourceStatus)

      Patch strategy: злиття за ключем name

      Map: унікальні значення ключа name будуть збережені під час злиття

      AllocatedResourcesStatus представляє статус різних ресурсів, виділених для цього podʼа.

      **

      • ephemeralContainerStatuses.allocatedResourcesStatus.name (string), обовʼязково

        Назва ресурсу. Має бути унікальною в межах podʼа та відповідати одному з ресурсів зі специфікації podʼа.

      • ephemeralContainerStatuses.allocatedResourcesStatus.resources ([]ResourceHealth)

        Map: унікальні значення ключа resourceID будуть збережені під час злиття

        Список унікальних станів ресурсів. Кожен елемент списку містить унікальний ідентифікатор ресурсу та стан ресурсу. Мінімум, ResourceID має унікально ідентифікувати ресурс, виділений podʼу на вузлі протягом життя podʼа. Дивіться тип ResourceID для його визначення.

        ResourceHealth представляє стан справності ресурсу. Він містить останню інформацію про стан пристрою. Це частина KEP https://kep.k8s.io/4680, і планується додавання історичних змін стану справності в майбутніх ітераціях KEP.

        • ephemeralContainerStatuses.allocatedResourcesStatus.resources.resourceID (string), обовʼязково

          ResourceID є унікальним ідентифікатором ресурсу. Дивіться тип ResourceID для отримання додаткової інформації.

        • ephemeralContainerStatuses.allocatedResourcesStatus.resources.health (string)

          Health ресурсу. Може бути одним з:

          • Healthy: працює нормально
          • Unhealthy: повідомлено про несправний стан. Ми вважаємо це тимчасовою проблемою зі справністю, оскільки наразі у нас немає механізму для розрізнення тимчасових і постійних проблем.
          • Unknown: статус не можна визначити. Наприклад, втулок пристрою було відключено і він не був повторно зареєстрований з того часу.

          В майбутньому ми можемо ввести статус PermanentlyUnhealthy.

    • ephemeralContainerStatuses.containerID (string)

      ContainerID є ідентифікатором контейнера у форматі '<type>://<container_id>'. Де type є ідентифікатором середовища виконання контейнера, що повертається з виклику Version API CRI (наприклад, "containerd").

    • ephemeralContainerStatuses.image (string), обовʼязково

      Image є назвою образу контейнера з якого запущений у контейнері. Образ контейнера може не збігатися з образом, що використовується в PodSpec, оскільки він міг бути розвʼязаний середовищем виконання. Докладніше: https://kubernetes.io/docs/concepts/containers/images

    • ephemeralContainerStatuses.imageID (string), обовʼязково

      ImageID є ідентифікатором образу контейнера. Ідентифікатор образу може не збігатися з ідентифікатором образу, що використовується в PodSpec, оскільки він міг бути розвʼязаний середовищем виконання.

    • ephemeralContainerStatuses.lastState (ContainerState)

      LastTerminationState містить останній стан завершення контейнера, щоб допомогти в налагодженні аварійних зупинок та перезапусків контейнера. Це поле не заповнюється, якщо контейнер все ще запущений і RestartCount дорівнює 0.

      ContainerState містить можливий стан контейнера. Може бути зазначено лише один з його членів. Якщо жоден з них не вказано, стандартно використовується ContainerStateWaiting.

      • ephemeralContainerStatuses.lastState.running (ContainerStateRunning)

        Відомості про запущений контейнер

        ContainerStateRunning є станом контейнера, який запущений.

        • ephemeralContainerStatuses.lastState.running.startedAt (Time)

          Час, коли контейнер був востаннє (пере)запущений.

          Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

      • ephemeralContainerStatuses.lastState.terminated (ContainerStateTerminated)

        Відомості про контейнер, який завершив свою роботу

        ContainerStateTerminated є станом контейнера, який завершив свою роботу.

        • ephemeralContainerStatuses.lastState.terminated.containerID (string)

          ContainerID є ідентифікатором контейнера у форматі '<type>://<container_id>'.

        • ephemeralContainerStatuses.lastState.terminated.exitCode (int32), обовʼязково

          Код виходу з останнього завершення роботи контейнера

        • ephemeralContainerStatuses.lastState.terminated.startedAt (Time)

          Час, коли розпочалося попереднє виконання контейнера

          Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

        • ephemeralContainerStatuses.lastState.terminated.finishedAt (Time)

          Час, коли контейнер востаннє завершив свою роботу

          Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

        • ephemeralContainerStatuses.lastState.terminated.message (string)

          Повідомлення щодо останнього завершення роботи контейнера

        • ephemeralContainerStatuses.lastState.terminated.reason (string)

          (коротка) причина останнього завершення роботи контейнера

        • ephemeralContainerStatuses.lastState.terminated.signal (int32)

          Сигнал з останнього завершення роботи контейнера

      • ephemeralContainerStatuses.lastState.waiting (ContainerStateWaiting)

        Деталі про контейнер, що очікує

        ContainerStateWaiting є станом контейнера, що очікує.

        • ephemeralContainerStatuses.lastState.waiting.message (string)

          Повідомлення про причину, чому контейнер ще не запущений.

        • ephemeralContainerStatuses.lastState.waiting.reason (string)

          (коротка) причина, чому контейнер ще не запущений

    • ephemeralContainerStatuses.name (string), обовʼязково

      Name є DNS_LABEL, що представляє унікальну назву контейнера. Кожен контейнер в podʼі повинен мати унікальну назву серед усіх типів контейнерів. Не можна оновити.

    • ephemeralContainerStatuses.ready (boolean), обовʼязково

      Ready вказує, чи контейнер наразі проходить перевірку готовності. Значення змінюватиметься, оскільки перевірки готовності продовжують виконуватися. Якщо перевірки готовності не вказані, це поле стандартно буде true, як тільки контейнер буде повністю запущений (див. поле Started).

      Значення зазвичай використовується для визначення, чи контейнер готовий приймати трафік.

    • ephemeralContainerStatuses.resources (ResourceRequirements)

      Resources представляє запити та ліміти обчислювальних ресурсів, які були успішно застосовані до працюючого контейнера після його запуску або успішного масштабування.

      ResourceRequirements описує вимоги до обчислювальних ресурсів.

      • ephemeralContainerStatuses.resources.claims ([]ResourceClaim)

        Map: унікальні значення ключа name будуть збережені під час злиття

        Claims перелік назв ресурсів, визначених у spec.resourceClaims, які використовуються цим контейнером.

        Це поле альфа-версії і потребує включення функціональної можливості DynamicResourceAllocation.

        Це поле незмінне. Воно може бути встановлено лише для контейнерів.

        ResourceClaim посилається на один запис у PodSpec.ResourceClaims.

        • ephemeralContainerStatuses.resources.claims.name (string), обовʼязково

          Name має відповідати назві одного запису в pod.spec.resourceClaims podʼа, де використовується це поле. Це робить ресурс доступним всередині контейнера.

        • ephemeralContainerStatuses.resources.claims.request (string)

          Request є назвою, обраною для запиту в зазначеній заявці. Якщо порожньо, всі ресурси з заявки стають доступними, інакше лише результат цього запиту.

      • ephemeralContainerStatuses.resources.limits (map[string]Quantity)

        Limits описує максимальну кількість дозволених обчислювальних ресурсів. Докладніше: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/

      • ephemeralContainerStatuses.resources.requests (map[string]Quantity)

        Requests описує мінімальну кількість обчислювальних ресурсів, необхідних для контейнера. Якщо Requests не вказано для контейнера, воно стандартно дорівнює Limits, якщо вони явно вказані, інакше — значенню, визначеному реалізацією. Requests не може перевищувати Limits. Докладніше: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/

    • ephemeralContainerStatuses.restartCount (int32), обовʼязково

      RestartCount містить кількість разів, коли контейнер був перезапущений. Kubelet намагається завжди збільшувати це значення, але є випадки, коли стан може бути втрачено через перезавантаження вузла, і тоді значення може бути скинуто на 0. Значення ніколи не є відʼємним.

    • ephemeralContainerStatuses.started (boolean)

      Started вказує, чи контейнер завершив свій хук життєвого циклу postStart і пройшов перевірку запуску. Ініціалізується як false, стає true після того, як перевірка запуску вважається успішною. Скидається на false, коли контейнер перезапускається або якщо kubelet тимчасово втрачає стан. У обох випадках перевірки запуску будуть виконані знову. Завжди true, коли перевірка запуску не визначена і контейнер запущений та пройшов хук життєвого циклу postStart. Значення null слід трактувати так само, як false.

    • ephemeralContainerStatuses.state (ContainerState)

      State містить деталі про поточний стан контейнера.

      ContainerState містить можливий стан контейнера. Може бути зазначено лише один з його членів. Якщо жоден з них не вказано, стандартно використовується ContainerStateWaiting.

      • ephemeralContainerStatuses.state.running (ContainerStateRunning)

        Деталі про запущений контейнер

        ContainerStateRunning є станом контейнера, який запущений.

        • ephemeralContainerStatuses.state.running.startedAt (Time)

          Час, коли контейнер був востаннє (пере)запущений.

          Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

      • ephemeralContainerStatuses.state.terminated (ContainerStateTerminated)

        Відомості про контейнер, який завершив свою роботу

        ContainerStateTerminated є станом контейнера, який завершив свою роботу.

        • ephemeralContainerStatuses.state.terminated.containerID (string)

          ContainerID є ідентифікатором контейнера у форматі '<type>://<container_id>'.

        • ephemeralContainerStatuses.state.terminated.exitCode (int32), обовʼязково

          Код виходу з останнього завершення роботи контейнера

        • ephemeralContainerStatuses.state.terminated.startedAt (Time)

          Час, коли розпочалося попереднє виконання контейнера

          Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

        • ephemeralContainerStatuses.state.terminated.finishedAt (Time)

          Час, коли контейнер востаннє завершив свою роботу

          Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

        • ephemeralContainerStatuses.state.terminated.message (string)

          Повідомлення щодо останнього завершення роботи контейнера

        • ephemeralContainerStatuses.state.terminated.reason (string)

          (коротка) причина останнього завершення роботи контейнера

        • ephemeralContainerStatuses.state.terminated.signal (int32)

          Сигнал з останнього завершення роботи контейнера

      • ephemeralContainerStatuses.state.waiting (ContainerStateWaiting)

        Деталі про контейнер, що очікує

        ContainerStateWaiting є станом контейнера, що очікує.

        • ephemeralContainerStatuses.state.waiting.message (string)

          Повідомлення про причину, чому контейнер ще не запущений.

        • ephemeralContainerStatuses.state.waiting.reason (string)

          (коротка) причина, чому контейнер ще не запущений

    • ephemeralContainerStatuses.user (ContainerUser)

      User представляє інформацію про ідентифікацію користувача, спочатку прикріплену до першого процесу контейнера

      ContainerUser представляє інформацію про ідентифікацію користувача

      • ephemeralContainerStatuses.user.linux (LinuxContainerUser)

        Linux містить інформацію про ідентифікацію користувача, спочатку прикріплену до першого процесу контейнерів у Linux. Зверніть увагу, що фактична ідентичність, яка виконується, може змінюватися, якщо процес має достатні привілеї для цього.

        LinuxContainerUser представляє інформацію про ідентифікацію користувача в контейнерах Linux

        • ephemeralContainerStatuses.user.linux.gid (int64), обовʼязково

          GID є основним gid, спочатку прикріпленим до першого процесу в контейнері

        • ephemeralContainerStatuses.user.linux.uid (int64), обовʼязково

          UID є основним uid, спочатку прикріпленим до першого процесу в контейнері

        • ephemeralContainerStatuses.user.linux.supplementalGroups ([]int64)

          Atomic: буде замінено під час злиття

          SupplementalGroups є додатковими групами, спочатку прикріпленими до першого процесу в контейнері

    • ephemeralContainerStatuses.volumeMounts ([]VolumeMountStatus)

      Patch strategy: злиття за ключем mountPath

      Map: унікальні значення ключа mountPath будуть збережені під час злиття

      Стан монтування томів.

      VolumeMountStatus показує стан монтування томів.

      • ephemeralContainerStatuses.volumeMounts.mountPath (string), обовʼязково

        MountPath відповідає оригінальному VolumeMount.

      • ephemeralContainerStatuses.volumeMounts.name (string), обовʼязково

        Name відповідає назві оригінального VolumeMount.

      • ephemeralContainerStatuses.volumeMounts.readOnly (boolean)

        ReadOnly відповідає оригінальному VolumeMount.

      • ephemeralContainerStatuses.volumeMounts.recursiveReadOnly (string)

        RecursiveReadOnly має бути встановлено на Disabled, Enabled або unspecified (для монтувань відмінних "тільки для читання"). Значення IfPossible в оригінальному VolumeMount повинно бути перетворено на Disabled або Enabled, залежно від результату монтування.

  • resourceClaimStatuses ([]PodResourceClaimStatus)

    Patch strategies: retainKeys, обʼєднання по ключу name

    Map: унікальні значення по ключу name будуть збережені під час обʼєднання

    Статус ресурсних заявок.

    PodResourceClaimStatus зберігається у PodStatus для кожної PodResourceClaim, яка посилається на ResourceClaimTemplate. Він зберігає згенеровану назву для відповідної ResourceClaim.

    • resourceClaimStatuses.name (string), обовʼязково

      Імʼя унікально ідентифікує цю ресурсну заявку всередині Podʼа. Воно має відповідати імені в pod.spec.resourceClaims, що означає, що рядок повинен бути DNS_LABEL.

    • resourceClaimStatuses.resourceClaimName (string)

      ResourceClaimName є назвою ResourceClaim, яка була згенерована для podʼа в просторі імен podʼа. Якщо це поле не встановлено, то створення ResourceClaim не було необхідним. У цьому випадку запис pod.spec.resourceClaims можна ігнорувати.

  • resize (string)

    Статус бажаної зміни розміру ресурсів для контейнерів Podʼа. Він порожній, якщо немає очікуваної зміни розміру ресурсів. Будь-які зміни в ресурсах контейнера автоматично встановлять це на "Proposed".

PodList

PodList — це список Podʼів.


Операції


get отримати вказаний Pod

HTTP запит

GET /api/v1/namespaces/{namespace}/pods/{name}

Параметри

  • name (у шляху): string, обовʼязково

    назва Podʼа

  • namespace (у шляху): string, обовʼязково

    namespace

  • pretty (у запиті): string

    pretty

Відповідь

200 (Pod): OK

401: Unauthorized

get отримати ефемерні контейнери вказаного Podʼа

HTTP запит

GET /api/v1/namespaces/{namespace}/pods/{name}/ephemeralcontainers

Параметри

  • name (у шляху): string, обовʼязково

    назва Podʼа

  • namespace (у шляху): string, обовʼязково

    namespace

  • pretty (у запиті): string

    pretty

Відповідь

200 (Pod): OK

401: Unauthorized

get отримати лог вказаного Podʼа

HTTP запит

GET /api/v1/namespaces/{namespace}/pods/{name}/log

Параметри

  • name (у шляху): string, обовʼязково

    назва Podʼа

  • namespace (у шляху): string, обовʼязково

    namespace

  • container (у запиті): string

    Контейнер, для якого потрібно виводити логи. Стандартно виводяться тільки логи контейнера, якщо в Podʼі є тільки один контейнер.

  • follow (у запиті): boolean

    Слідкувати за потоком логу Podʼа. Стандартне значення — false.

  • insecureSkipTLSVerifyBackend (у запиті): boolean

    insecureSkipTLSVerifyBackend вказує, що apiserver не повинен підтверджувати дійсність сертифікату обслуговуючого програмного забезпечення, з яким він зʼєднується. Це зробить HTTPS-зʼєднання між apiserver та обслуговуючим програмним забезпеченням ненадійним. Це означає, що apiserver не може підтвердити, що дані логу, які він отримує, отримано від реального kubelet. Якщо kubelet налаштований для підтвердження уповноваження TLS apiserver, це не означає, що зʼєднання з реальним kubelet вразливе до атаки посередника (наприклад, зловмисник не зможе перехопити фактичні дані логу, що надходять від реального kubelet).

  • limitBytes (у запиті): integer

    Якщо задано, кількість байтів, які слід прочитати з сервера, перш ніж завершити виведення логу. Це може не показувати повністю останню лінію логу, і може повернути трохи більше або трохи менше, ніж вказаний обмежувач.

  • pretty (у запиті): string

    pretty

  • previous (у запиті): boolean

    Повертати логи попередньо завершених контейнерів. Стандартне значення — false.

  • sinceSeconds (у запиті): integer

    Відносний час у секундах до поточного часу, з якого показувати логи. Якщо це значення передує часу запуску Podʼа, будуть повернуті лише логи з часу запуску Podʼа. Якщо це значення в майбутньому, жодних логів не буде повернено. Можна вказати тільки один з sinceSeconds або sinceTime.

  • tailLines (у запиті): integer

    Якщо задано, кількість рядків з кінця логу, які слід показати. Якщо не вказано, логи показуються з моменту створення контейнера, або відносно sinceSeconds або sinceTime.

  • timestamps (у запиті): boolean

    Якщо true, додаємо часову мітку RFC3339 або RFC3339Nano на початок кожного рядка виводу логу. Стандартне значення — false.

Відповідь

200 (string): OK

401: Unauthorized

get отримати статус вказаного Podʼа

HTTP запит

GET /api/v1/namespaces/{namespace}/pods/{name}/status

Параметри

  • name (у шляху): string, обовʼязково

    назва Podʼа

  • namespace (у шляху): string, обовʼязково

    namespace

  • pretty (у запиті): string

    pretty

Відповідь

200 (Pod): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу Pod

HTTP запит

GET /api/v1/namespaces/{namespace}/pods

Параметри

Відповідь

200 (PodList): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу Pod

HTTP запит

GET /api/v1/pods

Параметри

Відповідь

200 (PodList): OK

401: Unauthorized

create створення Podʼа

HTTP запит

POST /api/v1/namespaces/{namespace}/pods

Параметри

  • namespace (у шляху): string, обовʼязково

    namespace

  • body: Pod, обовʼязково

  • dryRun (у запиті): string

    dryRun

  • fieldManager (у запиті): string

    fieldManager

  • fieldValidation (у запиті): string

    fieldValidation

  • pretty (у запиті): string

    pretty

Відповідь

200 (Pod): OK

201 (Pod): Created

202 (Pod): Accepted

401: Unauthorized

update заміна вказаного Podʼа

HTTP запит

PUT /api/v1/namespaces/{namespace}/pods/{name}

Параметри

  • name (у шляху): string, обовʼязково

    імʼя Podʼа

  • namespace (у шляху): string, обовʼязково

    namespace

  • body: Pod, обовʼязково

  • dryRun (у запиті): string

    dryRun

  • fieldManager (у запиті): string

    fieldManager

  • fieldValidation (у запиті): string

    fieldValidation

  • pretty (у запиті): string

    pretty

Відповідь

200 (Pod): OK

201 (Pod): Created

401: Unauthorized

update заміна ephemeralcontainers вказаного Podʼа

HTTP запит

PUT /api/v1/namespaces/{namespace}/pods/{name}/ephemeralcontainers

Параметри

  • name (у шляху): string, обовʼязково

    імʼя Podʼа

  • namespace (у шляху): string, обовʼязково

    namespace

  • body: Pod, обовʼязково

  • dryRun (у запиті): string

    dryRun

  • fieldManager (у запиті): string

    fieldManager

  • fieldValidation (у запиті): string

    fieldValidation

  • pretty (у запиті): string

    pretty

Відповідь

200 (Pod): OK

201 (Pod): Created

401: Unauthorized

update заміна статусу вказаного Podʼа

HTTP запит

PUT /api/v1/namespaces/{namespace}/pods/{name}/status

Параметри

  • name (у шляху): string, обовʼязково

    імʼя Podʼа

  • namespace (у шляху): string, обовʼязково

    namespace

  • body: Pod, обовʼязково

  • dryRun (у запиті): string

    dryRun

  • fieldManager (у запиті): string

    fieldManager

  • fieldValidation (у запиті): string

    fieldValidation

  • pretty (у запиті): string

    pretty

Відповідь

200 (Pod): OK

201 (Pod): Created

401: Unauthorized

patch часткове оновлення вказаного Podʼа

HTTP запит

PATCH /api/v1/namespaces/{namespace}/pods/{name}

Параметри

  • name (у шляху): string, обовʼязково

    імʼя Podʼа

  • namespace (у шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (у запиті): string

    dryRun

  • fieldManager (у запиті): string

    fieldManager

  • fieldValidation (у запиті): string

    fieldValidation

  • force (у запиті): boolean

    force

  • pretty (у запиті): string

    pretty

Відповідь

200 (Pod): OK

201 (Pod): Created

401: Unauthorized

patch часткове оновлення ephemeralcontainers вказаного Podʼа

HTTP запит

PATCH /api/v1/namespaces/{namespace}/pods/{name}/ephemeralcontainers

Параметри

  • name (у шляху): string, обовʼязково

    імʼя Podʼа

  • namespace (у шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (у запиті): string

    dryRun

  • fieldManager (у запиті): string

    fieldManager

  • fieldValidation (у запиті): string

    fieldValidation

  • force (у запиті): boolean

    force

  • pretty (у запиті): string

    pretty

Відповідь

200 (Pod): OK

201 (Pod): Created

401: Unauthorized

patch часткове оновлення статусу вказаного Podʼа

HTTP запит

PATCH /api/v1/namespaces/{namespace}/pods/{name}/status

Параметри

  • name (у шляху): string, обовʼязково

    імʼя Podʼа

  • namespace (у шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (у запиті): string

    dryRun

  • fieldManager (у запиті): string

    fieldManager

  • fieldValidation (у запиті): string

    fieldValidation

  • force (у запиті): boolean

    force

  • pretty (у запиті): string

    pretty

Відповідь

200 (Pod): OK

201 (Pod): Created

401: Unauthorized

delete видалення Pod

HTTP запит

DELETE /api/v1/namespaces/{namespace}/pods/{name}

Параметри

  • name (у шляху): string, обовʼязково

    імʼя Podʼа

  • namespace (у шляху): string, обовʼязково

    namespace

  • body: DeleteOptions

  • dryRun (у запиті): string

    dryRun

  • gracePeriodSeconds (у запиті): integer

    gracePeriodSeconds

  • pretty (у запиті): string

    pretty

  • propagationPolicy (у запиті): string

    propagationPolicy

Відповідь

200 (Pod): OK

202 (Pod): Accepted

401: Unauthorized

deletecollection видалення колекції Podʼів

HTTP запит

DELETE /api/v1/namespaces/{namespace}/pods

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

6.5.1.2 - Binding

Звʼязування привʼязує один обʼєкт до іншого; наприклад, Pod привʼязується до вузла планувальником.

apiVersion: v1

import "k8s.io/api/core/v1"

Binding

Binding звʼязує один обʼєкт з іншим; наприклад, Pod звʼязується з вузлом за допомогою планувальника. Застаріло у версії 1.7, будь ласка, використовуйте субресурс bindings для Podʼів замість цього.


Операції


create створення Binding

HTTP запит

POST /api/v1/namespaces/{namespace}/bindings

Параметри

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Binding, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (Binding): OK

201 (Binding): Created

202 (Binding): Accepted

401: Unauthorized

create створення звʼязування для Pod

HTTP запит

POST /api/v1/namespaces/{namespace}/pods/{name}/binding

Параметри

  • name (в шляху): string, обовʼязково

    імʼя Binding

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Binding, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (Binding): OK

201 (Binding): Created

202 (Binding): Accepted

401: Unauthorized

6.5.1.3 - PodTemplate

PodTemplate описує шаблон для створення копій наперед визначеного Podʼа.

apiVersion: v1

import "k8s.io/api/core/v1"

PodTemplate

PodTemplate описує шаблон для створення копій наперед визначеного Podʼа.


PodTemplateList

PodTemplateList — список PodTemplate.


Операції


get прочитати вказаний PodTemplate

HTTP-запит

GET /api/v1/namespaces/{namespace}/podtemplates/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя PodTemplate

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (PodTemplate): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу PodTemplate

HTTP-запит

GET /api/v1/namespaces/{namespace}/podtemplates

Параметри

Відповідь

200 (PodTemplateList): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу PodTemplate

HTTP-запит

GET /api/v1/podtemplates

Параметри

Відповідь

200 (PodTemplateList): OK

401: Unauthorized

create створення PodTemplate

HTTP-запит

POST /api/v1/namespaces/{namespace}/podtemplates

Параметри

Відповідь

200 (PodTemplate): OK

201 (PodTemplate): Created

202 (PodTemplate): Accepted

401: Unauthorized

update замінити вказаний PodTemplate

HTTP-запит

PUT /api/v1/namespaces/{namespace}/podtemplates/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя PodTemplate

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: PodTemplate, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (PodTemplate): OK

201 (PodTemplate): Created

401: Unauthorized

patch частково оновити вказаний PodTemplate

HTTP-запит

PATCH /api/v1/namespaces/{namespace}/podtemplates/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя PodTemplate

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (PodTemplate): OK

201 (PodTemplate): Created

401: Unauthorized

delete видалити PodTemplate

HTTP-запит

DELETE /api/v1/namespaces/{namespace}/podtemplates/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя PodTemplate

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (PodTemplate): OK

202 (PodTemplate): Accepted

401: Unauthorized

deletecollection видалити колекцію PodTemplate

HTTP-запит

DELETE /api/v1/namespaces/{namespace}/podtemplates

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

6.5.1.4 - ReplicationController

ReplicationController представляє конфігураці. контролера реплікації.

apiVersion: v1

import "k8s.io/api/core/v1"

ReplicationController

ReplicationController представляє конфігурацію контролера реплікації.


ReplicationControllerSpec

ReplicationControllerSpec — це специфікація контролера реплікації.


  • selector (map[string]string)

    Selector — це запит міток (label query) з Podʼів, які повинні відповідати кількості реплік. Якщо Selector порожній, стандартно встановлюються мітки, які присутні в шаблоні Pod. Ключі та значення міток, які повинні збігатись для контролю цим контролером реплікації, за відсутності стандартних значень встановлюються мітки з шаблону Pod. Додаткова інформація: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors

  • template (PodTemplateSpec)

    Template — це обʼєкт, який описує Pod, який буде створений у разі виявлення недостатньої кількості реплік. Це має перевагу над TemplateRef. Єдине дозволене значення template.spec.restartPolicy — "Always". Додаткова інформація: https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller#pod-template

  • replicas (int32)

    Replicas — це кількість бажаних реплік. Це вказівка для розрізнення між явним нульовим значенням та невказаною кількістю. Стандартне значення — 1. Додаткова інформація: https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller#what-is-a-replicationcontroller

  • minReadySeconds (int32)

    Мінімальна кількість секунд, протягом яких новий створений Pod повинен бути готовим без збоїв жодного з його контейнерів, щоб його вважати доступним. Стандартне значення — 0 (Pod буде вважатися доступним, як тільки він буде готовий)

ReplicationControllerStatus

ReplicationControllerStatus представляє поточний статус контролера реплікації.


  • replicas (int32), обовʼязково

    Replicas — це найновіша зафіксована кількість реплік. Додаткова інформація: https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller#what-is-a-replicationcontroller

  • availableReplicas (int32)

    Кількість доступних реплік (готових принаймні протягом minReadySeconds) для цього контролера реплікації.

  • readyReplicas (int32)

    Кількість готових реплік для цього контролера реплікації.

  • fullyLabeledReplicas (int32)

    Кількість Podʼів, які мають мітки, що відповідають міткам шаблону Pod контролера реплікації.

  • conditions ([]ReplicationControllerCondition)

    Patch strategy: обʼєднання за ключем type

    Map: унікальні значення ключа type будуть збережені під час злиття

    Представляє останні доступні спостереження поточного стану контролера реплікації.

    ReplicationControllerCondition описує стан контролера реплікації в певний момент.

    • conditions.status (string), обовʼязково

      Статус стану, одне з True, False, Unknown.

    • conditions.type (string), обовʼязково

      Тип стану контролера реплікації.

    • conditions.lastTransitionTime (Time)

      Останній час переходу стану з одного статусу в інший.

      Time є обгорткою навколо time.Time, яка підтримує правильне перетворення в YAML та JSON. Надаються обгортки для багатьох методів створення, які пропонує пакет time.

    • conditions.message (string)

      Повідомлення, зрозуміле людині, із зазначенням деталей про перехід.

    • conditions.reason (string)

      Причина останнього переходу умови.

  • observedGeneration (int64)

    ObservedGeneration показує покоління останнього спостереження контролера реплікації.

ReplicationControllerList

ReplicationControllerList — це колекція контролерів реплікації.


Операції


get читання вказаного ReplicationController

HTTP-запит

GET /api/v1/namespaces/{namespace}/replicationcontrollers/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва ReplicationController

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (ReplicationController): ОК

401: Unauthorized

get читання статусу вказаного ReplicationController

HTTP-запит

GET /api/v1/namespaces/{namespace}/replicationcontrollers/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    назва ReplicationController

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (ReplicationController): ОК

401: Unauthorized

list перелік або спостереження за обʼєктами типу ReplicationController

HTTP-запит

GET /api/v1/namespaces/{namespace}/replicationcontrollers

Параметри

Відповідь

200 (ReplicationControllerList): ОК

401: Unauthorized

list перелік або спостереження за обʼєктами типу ReplicationController

HTTP-запит

GET /api/v1/replicationcontrollers

Параметри

Відповідь

200 (ReplicationControllerList): ОК

401: Unauthorized

create створення ReplicationController

HTTP-запит

POST /api/v1/namespaces/{namespace}/replicationcontrollers

Параметри

Відповідь

200 (ReplicationController): ОК

201 (ReplicationController): Created

202 (ReplicationController): Accepted

401: Unauthorized

update заміна вказаного ReplicationController

HTTP-запит

PUT /api/v1/namespaces/{namespace}/replicationcontrollers/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва ReplicationController

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: ReplicationController, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (ReplicationController): ОК

201 (ReplicationController): Created

401: Unauthorized

update заміна статусу вказаного ReplicationController

HTTP-запит

PUT /api/v1/namespaces/{namespace}/replicationcontrollers/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    назва ReplicationController

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: ReplicationController, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (ReplicationController): ОК

201 (ReplicationController): Created

401: Unauthorized

patch часткове оновлення вказаного ReplicationController

HTTP-запит

PATCH /api/v1/namespaces/{namespace}/replicationcontrollers/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва ReplicationController

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (ReplicationController): ОК

201 (ReplicationController): Created

401: Unauthorized

patch часткове оновлення статусу вказаного ReplicationController

HTTP-запит

PATCH /api/v1/namespaces/{namespace}/replicationcontrollers/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    назва ReplicationController

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (ReplicationController): ОК

201 (ReplicationController): Created

401: Unauthorized

delete видалення ReplicationController

HTTP-запит

DELETE /api/v1/namespaces/{namespace}/replicationcontrollers/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва ReplicationController

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (Status): ОК

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції ReplicationController

HTTP-запит

DELETE /api/v1/namespaces/{namespace}/replicationcontrollers

Параметри

Відповідь

200 (Status): ОК

401: Unauthorized

6.5.1.5 - ReplicaSet

ReplicaSet забезпечує, що в будь-який момент часу задана кількість реплік Podʼів працює.

apiVersion: apps/v1

import "k8s.io/api/apps/v1"

ReplicaSet

ReplicaSet забезпечує, що в будь-який момент часу задана кількість реплік Podʼів працює.


ReplicaSetSpec

ReplicaSetSpec — це специфікація ReplicaSet.


  • selector (LabelSelector), обовʼязково

    Селектор — це запит міток до Podʼів, які повинні відповідати кількості реплік. Ключі міток та їх значення, які повинні відповідати, щоб ними керував цей ReplicaSet. Вони повинні відповідати міткам шаблону Podʼа. Додаткова інформація: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors

  • template (PodTemplateSpec)

    Шаблон — це обʼєкт, що описує Pod, який буде створений, якщо виявлено недостатню кількість реплік. Додаткова інформація: https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller#pod-template

  • replicas (int32)

    Replicas — це бажана кількість реплік. Це вказівник для розрізнювання між явною нульовою та невизначеною кількістю. Стандартне значення — 1. Додаткова інформація: https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller/#what-is-a-replicationcontroller

  • minReadySeconds (int32)

    Мінімальна кількість секунд, протягом яких новий створений Pod повинен бути готовим без збоїв жодного з його контейнерів, щоб його вважати доступним. Стандартне значення — 0 (Pod буде вважатися доступним, як тільки він буде готовий)

ReplicaSetStatus

ReplicaSetStatus відображає поточний стан ReplicaSet.


  • replicas (int32), обовʼязково

    Replicas — це остання зафіксована кількість реплік. Додаткова інформація: https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller/#what-is-a-replicationcontroller

  • availableReplicas (int32)

    Кількість доступних реплік (готових протягом принаймні minReadySeconds) для цього набору реплік.

  • readyReplicas (int32)

    readyReplicas — це кількість Podʼів в стані Ready, на які спрямовується цей ReplicaSet.

  • fullyLabeledReplicas (int32)

    Кількість Podʼів, які мають мітки, що відповідають міткам шаблону Podʼа набору реплік.

  • conditions ([]ReplicaSetCondition)

    Patch strategy: злиття за ключем type

    Map: унікальні значення ключа type будуть збережені під час злиття

    Представляє останні доступні спостереження поточного стану набору реплік.

    ReplicaSetCondition описує стан набору реплік в певний момент часу.

    • conditions.status (string), обовʼязково

      Статус стану, одне з: True, False, Unknown.

    • conditions.type (string), обовʼязково

      Тип стану набору реплік.

    • conditions.lastTransitionTime (Time)

      Останній раз, коли стан переходив з одного статусу в інший.

      Time - це обгортка навколо time.Time, яка підтримує правильне перетворення у YAML і JSON. Надаються обгортки для багатьох методів, які пропонує пакет time.

    • conditions.message (string)

      Повідомлення, зрозуміле людині, із зазначенням деталей про перехід.

    • conditions.reason (string)

      Причина останнього переходу умови.

  • observedGeneration (int64)

    ObservedGeneration показує покоління останнього зафіксованого ReplicaSet.

ReplicaSetList

ReplicaSetList — це колекція ReplicaSets.


Операції


get зчитування вказаного ReplicaSet

HTTP-запит

GET /apis/apps/v1/namespaces/{namespace}/replicasets/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва ReplicaSet

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (ReplicaSet): OK

401: Unauthorized

get зчитування статусу вказаного ReplicaSet

HTTP-запит

GET /apis/apps/v1/namespaces/{namespace}/replicasets/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    назва ReplicaSet

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (ReplicaSet): OK

401: Unauthorized

list список або перегляд обʼєктів типу ReplicaSet

HTTP-запит

GET /apis/apps/v1/namespaces/{namespace}/replicasets

Параметри

Відповідь

200 (ReplicaSetList): OK

401: Unauthorized

list список або перегляд обʼєктів типу ReplicaSet

HTTP-запит

GET /apis/apps/v1/replicasets

Параметри

Відповідь

200 (ReplicaSetList): OK

401: Unauthorized

create створення ReplicaSet

HTTP-запит

POST /apis/apps/v1/namespaces/{namespace}/replicasets

Параметри

Відповідь

200 (ReplicaSet): OK

201 (ReplicaSet): Created

202 (ReplicaSet): Accepted

401: Unauthorized

update заміна вказаного ReplicaSet

HTTP-запит

PUT /apis/apps/v1/namespaces/{namespace}/replicasets/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва ReplicaSet

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: ReplicaSet, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (ReplicaSet): OK

201 (ReplicaSet): Created

401: Unauthorized

update заміна статусу вказаного ReplicaSet

HTTP-запит

PUT /apis/apps/v1/namespaces/{namespace}/replicasets/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    назва ReplicaSet

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: ReplicaSet, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (ReplicaSet): OK

201 (ReplicaSet): Created

401: Unauthorized

patch часткове оновлення вказаного ReplicaSet

HTTP-запит

PATCH /apis/apps/v1/namespaces/{namespace}/replicasets/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва ReplicaSet

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (ReplicaSet): OK

201 (ReplicaSet): Created

401: Unauthorized

patch часткове оновлення статусу вказаного ReplicaSet

HTTP-запит

PATCH /apis/apps/v1/namespaces/{namespace}/replicasets/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    назва ReplicaSet

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (ReplicaSet): OK

201 (ReplicaSet): Created

401: Unauthorized

delete видалення ReplicaSet

HTTP-запит

DELETE /apis/apps/v1/namespaces/{namespace}/replicasets/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва ReplicaSet

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції ReplicaSet

HTTP-запит

DELETE /apis/apps/v1/namespaces/{namespace}/replicasets

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

6.5.1.6 - Deployment

Deployment робить можливими декларативні оновлення для Podʼів та and ReplicaSet.

apiVersion: apps/v1

import "k8s.io/api/apps/v1"

Deployment

Deployment робить можливими декларативні оновлення для Podʼів та ReplicaSet.


DeploymentSpec

DeploymentSpec є специфікацією бажаної поведінки Deployment.


  • selector (LabelSelector), обовʼязково

    Селектор міток для Podʼів. Наявні ReplicaSets, чиї Podʼи вибрані за допомогою цього селектора, будуть ті, які будуть змінені цим Deployment. Він повинен відповідати міткам шаблону Podʼа.

  • template (PodTemplateSpec), обовʼязково

    Шаблон описує Podʼи, які будуть створені. Єдине допустиме значення для template.spec.restartPolicy — "Always".

  • replicas (int32)

    Кількість бажаних Podʼів. Це вказівник для розрізнення між явним нулем і не вказаним значенням. Стандартне значення — 1.

  • minReadySeconds (int32)

    Мінімальна кількість секунд, протягом яких новий створений Pod повинен бути готовим без збоїв жодного з його контейнерів, щоб його вважати доступним. Стандартне значення — 0 (Pod буде вважатися доступним, як тільки він буде готовий)

  • strategy (DeploymentStrategy)

    Patch strategy: retainKeys

    Стратегія розгортання, яку слід використовувати для заміни наявних Podʼів на нові.

    DeploymentStrategy описує, як замінити наявні Podʼи новими.

    • strategy.type (string)

      Тип розгортання. Може бути "Recreate" або "RollingUpdate". Стандартне значення — RollingUpdate.

    • strategy.rollingUpdate (RollingUpdateDeployment)

      Параметри конфігурації постійного оновлення. Присутні лише, якщо DeploymentStrategyType = RollingUpdate.

      Spec для управління бажаною поведінкою постійного оновлення.

      • strategy.rollingUpdate.maxSurge (IntOrString)

        Максимальна кількість Podʼів, які можуть бути заплановані понад бажану кількість Podʼів. Значення може бути абсолютним числом (наприклад, 5) або відсотком від кількості бажаних Podʼів (наприклад, 10%). Це не може бути 0, якщо MaxUnavailable дорівнює 0. Абсолютне число обчислюється з відсотком, округленим вверх. Стандартне значення — 25%. Наприклад: якщо встановлено 30%, новий ReplicaSet може бути масштабований вгору відразу після початку постійного оновлення, так що загальна кількість старих і нових Podʼів не перевищує 130% від бажаних Podʼів. Після примусового завершення роботи старих Podʼів, новий ReplicaSet можна додатково масштабувати, гарантуючи, що загальна кількість Podʼів, запущених в будь-який момент під час оновлення, становить не більше 130% від бажаної кількості Podʼів

        IntOrString — це тип, який може містити int32 або рядок. При використанні перетворення з/в JSON або YAML він виробляє або споживає внутрішній тип. Це дозволяє вам мати, наприклад, поле JSON, яке може приймати імʼя або число.

      • strategy.rollingUpdate.maxUnavailable (IntOrString)

        Максимальна кількість Podʼів, які можуть бути недоступні під час оновлення. Значення може бути абсолютним числом (наприклад, 5) або відсотком від бажаних Podʼів (наприклад, 10%). Абсолютне число обчислюється з відсотком шляхом округлення у меншу сторону. Це не може бути 0, якщо MaxSurge дорівнює 0. Стандартне значення — 25%. Наприклад: коли це встановлено на 30%, старий ReplicaSet може бути масштабований вниз до 70% від бажаних Podʼів відразу після початку постійного оновлення. Як тільки нові Podʼи готові, старий ReplicaSet може бути додатково масштабований вниз, разом з масштабованням вгору нового ReplicaSet, забезпечуючи, що загальна кількість Podʼів, доступних у будь-який час під час оновлення, становить принаймні 70% від кількості бажаних Podʼів.

        IntOrString — це тип, який може містити int32 або рядок. При використанні перетворення з/в JSON або YAML він виробляє або споживає внутрішній тип. Це дозволяє вам мати, наприклад, поле JSON, яке може приймати імʼя або число.

  • revisionHistoryLimit (int32)

    Кількість старих ReplicaSets, які слід зберігати для можливості відкату. Це вказівник для розрізнення між явним нулем і не вказаним значенням. Стандартне значення — 10.

  • progressDeadlineSeconds (int32)

    Максимальний час у секундах для Deployment для досягнення прогресу, перш ніж вважати його невдалим. Контролер розгортання буде продовжувати обробляти невдалі Deployment, і у статусі Deployment буде сповіщено причину ProgressDeadlineExceeded. Зверніть увагу, що прогрес не буде оцінюватися під час паузи Deployment. Стандартне значення — 600 с.

  • paused (boolean)

    Показує, що Deployment призупинено.

DeploymentStatus

DeploymentStatus — це найостанніший спостережуваний статус Deployment.


  • replicas (int32)

    Загальна кількість Podʼів, що не завершили роботу, які є ціллю цього Deployment (їх мітки відповідають селектору).

  • availableReplicas (int32)

    Загальна кількість доступних Podʼів (готових принаймні minReadySeconds), які є ціллю цього Deployment.

  • readyReplicas (int32)

    Кількість Podʼів, які є ціллю цього Deployment в стані Ready.

  • unavailableReplicas (int32)

    Загальна кількість недоступних Podʼів, які є ціллю цього Deployment. Це загальна кількість Podʼів, які все ще необхідні для того, щоб Deployment мав 100% доступну потужність. Вони можуть бути Podʼами, які працюють, але ще не доступні, або Podʼами, які ще не були створені.

  • updatedReplicas (int32)

    Загальна кількість незавершених Podʼів, які є ціллю цього Deployment та мають бажаний шаблон специфікацій.

  • collisionCount (int32)

    Кількість колізій хешів для Deployment. Контролер Deployment використовує це поле як механізм уникнення колізій, коли йому потрібно створити імʼя для нового ReplicaSet.

  • conditions ([]DeploymentCondition)

    Patch strategy: злиття за ключем type

    Map: унікальні значення ключа type будуть збережені під час злиття

    Представляє останні доступні спостереження про поточний стан Deployment.

    DeploymentCondition описує стан Deployment в певний момент.

    • conditions.status (string), обовʼязково

      Статус стану, одне з True, False, Unknown.

    • conditions.type (string), обовʼязково

      Тип стану Deployment.

    • conditions.lastTransitionTime (Time)

      Останній час, коли стан переходив з одного статусу в інший.

      Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

    • conditions.lastUpdateTime (Time)

      Останній раз, коли цей стан було оновлено.

      Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

    • conditions.message (string)

      Повідомлення, зрозуміле людині, із зазначенням деталей про перехід.

    • conditions.reason (string)

      Причина останнього зміни стану.

  • observedGeneration (int64)

    Генерація, що спостерігається контролером Deployment.

DeploymentList

DeploymentList - це список обʼєктів Deployment.


  • apiVersion: apps/v1

  • kind: DeploymentList

  • metadata (ListMeta)

    Стандартні метадані списку.

  • items ([]Deployment), обовʼязково

    Items — це список обʼєктів Deployment.

Операції


get отримати вказаний Deployment

HTTP Запит

GET /apis/apps/v1/namespaces/{namespace}/deployments/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва Deployment

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (Deployment): ОК

401: Unauthorized

get отримати статус вказаного Deployment

HTTP Запит

GET /apis/apps/v1/namespaces/{namespace}/deployments/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    назва Deployment

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (Deployment): ОК

401: Unauthorized

list перелік або перегляд обʼєктів типу Deployment

HTTP Запит

GET /apis/apps/v1/namespaces/{namespace}/deployments

Параметри

Відповідь

200 (DeploymentList): ОК

401: Unauthorized

list перелік або перегляд обʼєктів типу Deployment

HTTP Запит

GET /apis/apps/v1/deployments

Параметри

Відповідь

200 (DeploymentList): ОК

401: Unauthorized

create створення Deployment

HTTP Запит

POST /apis/apps/v1/namespaces/{namespace}/deployments

Параметри

Відповідь

200 (Deployment): ОК

201 (Deployment): Created

202 (Deployment): Accepted

401: Unauthorized

update заміна вказаного Deployment

HTTP Запит

PUT /apis/apps/v1/namespaces/{namespace}/deployments/{name}

Параметри

  • name (у шляху): string, обовʼязково

    імʼя Deployment

  • namespace (у шляху): string, обовʼязково

    namespace

  • body: Deployment, обовʼязково

  • dryRun (у запиті): string

    dryRun

  • fieldManager (у запиті): string

    fieldManager

  • fieldValidation (у запиті): string

    fieldValidation

  • pretty (у запиті): string

    pretty

Відповідь

200 (Deployment): ОК

201 (Deployment): Created

401: Unauthorized

update заміна статусу вказаного Deployment

HTTP Запит

PUT /apis/apps/v1/namespaces/{namespace}/deployments/{name}/status

Параметри

  • name (у шляху): string, обовʼязково

    імʼя Deployment

  • namespace (у шляху): string, обовʼязково

    namespace

  • body: Deployment, обовʼязково

  • dryRun (у запиті): string

    dryRun

  • fieldManager (у запиті): string

    fieldManager

  • fieldValidation (у запиті): string

    fieldValidation

  • pretty (у запиті): string

    pretty

Відповідь

200 (Deployment): ОК

201 (Deployment): Created

401: Unauthorized

patch часткове оновлення вказаного Deployment

HTTP Запит

PATCH /apis/apps/v1/namespaces/{namespace}/deployments/{name}

Параметри

  • name (у шляху): string, обовʼязково

    імʼя Deployment

  • namespace (у шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (у запиті): string

    dryRun

  • fieldManager (у запиті): string

    fieldManager

  • fieldValidation (у запиті): string

    fieldValidation

  • force (у запиті): boolean

    force

  • pretty (у запиті): string

    pretty

Відповідь

200 (Deployment): ОК

201 (Deployment): Created

401: Unauthorized

patch часткове оновлення статусу вказаного Deployment

HTTP Запит

PATCH /apis/apps/v1/namespaces/{namespace}/deployments/{name}/status

Параметри

  • name (у шляху): string, обовʼязково

    імʼя Deployment

  • namespace (у шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (у запиті): string

    dryRun

  • fieldManager (у запиті): string

    fieldManager

  • fieldValidation (у запиті): string

    fieldValidation

  • force (у запиті): boolean

    force

  • pretty (у запиті): string

    pretty

Відповідь

200 (Deployment): ОК

201 (Deployment): Created

401: Unauthorized

delete видалення Deployment

HTTP Запит

DELETE /apis/apps/v1/namespaces/{namespace}/deployments/{name}

Параметри

  • name (у шляху): string, обовʼязково

    імʼя Deployment

  • namespace (у шляху): string, обовʼязково

    namespace

  • body: DeleteOptions

  • dryRun (у запиті): string

    dryRun

  • gracePeriodSeconds (у запиті): integer

    gracePeriodSeconds

  • pretty (у запиті): string

    pretty

  • propagationPolicy (у запиті): string

    propagationPolicy

Відповідь

200 (Status): ОК

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції Deployment

HTTP Запит

DELETE /apis/apps/v1/namespaces/{namespace}/deployments

Параметри

Відповідь

200 (Status): ОК

401: Unauthorized

6.5.1.7 - StatefulSet

StatefulSet представляє набір Podʼів з постійною ідентичністю.

apiVersion: apps/v1

import "k8s.io/api/apps/v1"

StatefulSet

StatefulSet представляє набір Podʼів з постійною ідентичністю. Ідентичність визначається як:

  • Мережа: єдине стабільне DNS та імʼя хосту.
  • Сховище: Стільки VolumeClaims, скільки потрібно.

StatefulSet гарантує, що вказана мережева ідентичність завжди буде зіставлятись з вказаним сховищем.


StatefulSetSpec

StatefulSetSpec — це специфікація StatefulSet.


  • serviceName (string), обовʼязково

    serviceName — це назва Service, який керує цим StatefulSet. Цей сервіс повинен існувати до створення StatefulSet і відповідає за мережеву ідентичність набору. Podʼи отримують DNS/hostnames, які відповідають шаблону: pod-specific-string.serviceName.default.svc.cluster.local, де "pod-specific-string" управляється контролером StatefulSet.

  • selector (LabelSelector), обовʼязково

    selector — це запит міток для Podʼів, які повинні відповідати кількості реплік. Він повинен відповідати міткам шаблону Podʼа. Додаткова інформація: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors

  • template (PodTemplateSpec), обовʼязково

    template — це обʼєкт, який описує Pod, що буде створений у випадку недостатньої кількості реплік. Кожен Pod, створений StatefulSet, буде відповідати цьому шаблону, але матиме унікальну ідентичність у порівнянні з іншими Podʼами StatefulSet. Кожен Pod буде названий за форматом <statefulsetname>-<podindex>. Наприклад, Pod у StatefulSet з імʼям "web" з індексом номер "3" буде називатися "web-3". Єдине дозволене значення для template.spec.restartPolicy — "Always".

  • replicas (int32)

    replicas — це бажана кількість реплік даного шаблону. Це репліки в тому сенсі, що вони є екземплярами одного і того ж шаблону, але кожна репліка також має постійну ідентичність. Якщо не вказано, стандартне значення — 1.

  • updateStrategy (StatefulSetUpdateStrategy)

    updateStrategy вказує на StatefulSetUpdateStrategy, яка буде використовуватися для оновлення Podʼів у StatefulSet при внесенні змін до шаблону.

    StatefulSetUpdateStrategy вказує стратегію, яку контролер StatefulSet буде використовувати для виконання оновлень. Вона включає будь-які додаткові параметри, необхідні для виконання оновлення для зазначеної стратегії.

    • updateStrategy.type (string)

      Type вказує тип StatefulSetUpdateStrategy. Стандартне значення — RollingUpdate.

    • updateStrategy.rollingUpdate (RollingUpdateStatefulSetStrategy)

      RollingUpdate використовується для передачі параметрів, коли Type є RollingUpdateStatefulSetStrategyType.

      RollingUpdateStatefulSetStrategy використовується для передачі параметрів для RollingUpdateStatefulSetStrategyType.

      • updateStrategy.rollingUpdate.maxUnavailable (IntOrString)

        Максимальна кількість Podʼів, які можуть бути недоступні під час оновлення. Значення може бути абсолютним числом (наприклад, 5) або відсотком від бажаної кількості Podʼів (наприклад, 10%). Абсолютна кількість розраховується від відсотків шляхом округлення в більшу сторону. Це не може бути 0. Стандартне значення — 1. Це поле є альфа-рівнем і враховується лише серверами, які підтримують функцію MaxUnavailableStatefulSet. Поле застосовується до всіх Podʼів у діапазоні від 0 до Replicas-1. Це означає, що якщо будь-який Pod у діапазоні від 0 до Replicas-1 недоступний, він буде враховуватися як MaxUnavailable.

        IntOrString — це тип, який може містити int32 або рядок. Під час перетворення з/у JSON або YAML він створює або споживає внутрішній тип. Це дозволяє мати, наприклад, поле JSON, яке може приймати назву або номер.

      • updateStrategy.rollingUpdate.partition (int32)

        Partition вказує порядковий номер, на якому StatefulSet повинен бути розділений для оновлень. Під час rolling update всі Podʼи від порядкового номера Replicas-1 до Partition оновлюються. Всі Podʼи від порядкового номера Partition-1 до 0 залишаються незмінними. Це корисно для проведення канаркового розгортання. Стандартне значення — 0.

  • podManagementPolicy (string)

    podManagementPolicy контролює, як Podʼи створюються під час початкового масштабування, при заміні Podʼів на вузлах або при масштабуванні вниз. Стандартне значення — OrderedReady, коли Podʼи створюються в порядку зростання (pod-0, потім pod-1 і т.д.), і контролер чекатиме, поки кожен Pod буде готовий, перш ніж продовжити. При масштабуванні вниз Podʼи видаляються у зворотному порядку. Альтернативною політикою є Parallel, яка створює Podʼи паралельно для досягнення бажаного масштабу без очікування, а при масштабуванні вниз видаляє всі Podʼи одночасно.

  • revisionHistoryLimit (int32)

    revisionHistoryLimit — це максимальна кількість ревізій, які будуть зберігатися в історії ревізій StatefulSet. Історія ревізій складається з усіх ревізій, які не представлені поточною застосованою версією StatefulSetSpec. Стандартне значення — 10.

  • volumeClaimTemplates ([]PersistentVolumeClaim)

    Atomic: буде замінено під час злиття

    volumeClaimTemplates — це список запитів, до яких Podʼи можуть звертатися. Контролер StatefulSet відповідає за призначення мережевих ідентичностей запитам таким чином, щоб зберігати ідентичність Podʼа. Кожен запит у цьому списку повинен мати принаймні один відповідний (за імʼям) volumeMount в одному з контейнерів в шаблоні. Запит у цьому списку має пріоритет над будь-якими volumes у шаблоні з таким самим імʼям.

  • minReadySeconds (int32)

    Мінімальна кількість секунд, протягом яких новий створений Pod повинен бути готовим без збоїв жодного з його контейнерів, щоб його вважати доступним. Стандартне значення — 0 (Pod буде вважатися доступним, як тільки він буде готовий)

  • persistentVolumeClaimRetentionPolicy (StatefulSetPersistentVolumeClaimRetentionPolicy)

    persistentVolumeClaimRetentionPolicy описує життєвий цикл запитів на постійні томи, створених з volumeClaimTemplates. Стандартно усі запити на постійні томи створюються за необхідності та зберігаються до ручного видалення. Ця політика дозволяє змінювати життєвий цикл, наприклад, видаляючи запити на постійні томи під час видалення їх StatefulSet або при масштабуванні вниз Podʼів. Для цього потрібно включити функцію StatefulSetAutoDeletePVC, яка є бета-рівнем.

    StatefulSetPersistentVolumeClaimRetentionPolicy описує політику, яка використовується для PVC, створених з VolumeClaimTemplates StatefulSet.

    • persistentVolumeClaimRetentionPolicy.whenDeleted (string)

      WhenDeleted визначає, що відбувається з PVC, створеними з VolumeClaimTemplates StatefulSet, коли StatefulSet видаляється. Стандартна політика Retain призводить до того, що на PVC не впливає видалення StatefulSet. Політика Delete призводить до видалення таких PVC.

    • persistentVolumeClaimRetentionPolicy.whenScaled (string)

      WhenScaled визначає, що відбувається з PVC, створеними з VolumeClaimTemplates StatefulSet, коли StatefulSet масштабується вниз. Стандартна політика Retain призводить до того, що на PVC не впливає масштабування вниз. Політика Delete призводить до видалення відповідних PVC для будь-яких зайвих Podʼів, що перевищують кількість реплік.

  • ordinals (StatefulSetOrdinals)

    ordinals контролює нумерацію індексів реплік у StatefulSet. Стандартна поведінка ordinals призначає індекс "0" першій репліці та збільшує індекс на одиницю для кожної додаткової запитаної репліки.

    StatefulSetOrdinals описує політику, яка використовується для призначення порядкових номерів реплік у цьому StatefulSet.

    • ordinals.start (int32)

      start — це число, що представляє індекс першої репліки. Його можна використовувати для нумерації реплік з альтернативного індексу (наприклад, з 1) замість стандартної індексації з 0, або для організації поступового переміщення реплік з одного StatefulSet до іншого. Якщо встановлено, індекси реплік будуть у діапазоні:

      • [.spec.ordinals.start, .spec.ordinals.start + .spec.replicas].

      Якщо не встановлено, стандартне значення — 0. Індекси реплік будуть у діапазоні:

      • [0, .spec.replicas].

StatefulSetStatus

StatefulSetStatus представляє поточний стан StatefulSet.


  • replicas (int32), обовʼязково

    replicas — це кількість Podʼів, створених контролером StatefulSet.

  • readyReplicas (int32)

    readyReplicas — це кількість Podʼів, створених для цього StatefulSet, які мають стан Ready.

  • currentReplicas (int32)

    currentReplicas — це кількість Podʼів, створених контролером StatefulSet з версії StatefulSet, зазначеної в currentRevision.

  • updatedReplicas (int32)

    updatedReplicas — це кількість Podʼів, створених контролером StatefulSet з версії StatefulSet, зазначеної в updateRevision.

  • availableReplicas (int32)

    Загальна кількість доступних Podʼів (готових принаймні minReadySeconds), на які спрямований цей statefulset.

  • collisionCount (int32)

    collisionCount — це кількість хеш-колізій для StatefulSet. Контролер StatefulSet використовує це поле як механізм уникнення колізій при створенні імені для найновішого ControllerRevision.

  • conditions ([]StatefulSetCondition)

    Patch strategy: злиття за ключем type

    Map: унікальні значення ключа type будуть збережені під час злиття

    Представляє останні доступні спостереження поточного стану StatefulSet.

    StatefulSetCondition описує стан StatefulSet у певний момент часу.

    • conditions.status (string), обовʼязково

      Статус стану, один з True, False, Unknown.

    • conditions.type (string), обовʼязково

      Тип стану StatefulSet.

    • conditions.lastTransitionTime (Time)

      Останній час, коли стан переходив з одного статусу в інший.

      Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

    • conditions.message (string)

      Повідомлення, зрозуміле людині, із зазначенням деталей про перехід.

    • conditions.reason (string)

      Причина останнього переходу умови.

  • currentRevision (string)

    currentRevision, якщо не порожній, вказує версію StatefulSet, яка використовується для створення Podʼів у послідовності [0,currentReplicas].

  • updateRevision (string)

    updateRevision, якщо не порожній, вказує версію StatefulSet, яка використовується для створення Podʼів у послідовності [replicas-updatedReplicas,replicas]

  • observedGeneration (int64)

    observedGeneration — останнє покоління, яке спостерігалося для цього StatefulSet. Воно відповідає поколінню StatefulSet, яке оновлюється при зміні сервером API.

StatefulSetList

StatefulSetList — це колекція StatefulSet.


Операції


get отримати вказаний StatefulSet

HTTP-запит

GET /apis/apps/v1/namespaces/{namespace}/statefulsets/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва StatefulSet

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (StatefulSet): OK

401: Unauthorized

get отримати статус вказаного StatefulSet

HTTP-запит

GET /apis/apps/v1/namespaces/{namespace}/statefulsets/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    назва StatefulSet

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (StatefulSet): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу StatefulSet

HTTP-запит

GET /apis/apps/v1/namespaces/{namespace}/statefulsets

Параметри

Відповідь

200 (StatefulSetList): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу StatefulSet

HTTP-запит

GET /apis/apps/v1/statefulsets

Параметри

Відповідь

200 (StatefulSetList): OK

401: Unauthorized

create створення StatefulSet

HTTP-запит

POST /apis/apps/v1/namespaces/{namespace}/statefulsets

Параметри

Відповідь

200 (StatefulSet): OK

201 (StatefulSet): Created

202 (StatefulSet): Accepted

401: Unauthorized

update заміна вказаного StatefulSet

HTTP-запит

PUT /apis/apps/v1/namespaces/{namespace}/statefulsets/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва StatefulSet

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: StatefulSet, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (StatefulSet): OK

201 (StatefulSet): Created

401: Unauthorized

update заміна статусу вказаного StatefulSet

HTTP-запит

PUT /apis/apps/v1/namespaces/{namespace}/statefulsets/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    назва StatefulSet

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: StatefulSet, обовʼязково

  • dryRun (в запиті): string

    [dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (StatefulSet): OK

201 (StatefulSet): Created

401: Unauthorized

patch часткове оновлення вказаного StatefulSet

HTTP-запит

PATCH /apis/apps/v1/namespaces/{namespace}/statefulsets/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва StatefulSet

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (StatefulSet): OK

201 (StatefulSet): Created

401: Unauthorized

patch часткове оновлення статусу вказакного StatefulSet

HTTP-запит

PATCH /apis/apps/v1/namespaces/{namespace}/statefulsets/{name}/status

Параметри

  • name (в запиті): string, обовʼязково

    назва StatefulSet

  • namespace (в запиті): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (StatefulSet): OK

201 (StatefulSet): Created

401: Unauthorized

delete видалення StatefulSet

HTTP-запит

DELETE /apis/apps/v1/namespaces/{namespace}/statefulsets/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва StatefulSet

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції StatefulSet

HTTP-запит

DELETE /apis/apps/v1/namespaces/{namespace}/statefulsets

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

6.5.1.8 - ControllerRevision

ControllerRevision впроваджує незмінюваний знімок даних стану.

apiVersion: apps/v1

import "k8s.io/api/apps/v1"

ControllerRevision

ControllerRevision впроваджує незмінюваний знімок даних стану. Клієнти відповідають за серіалізацію та десеріалізацію обʼєктів, які містять їх внутрішній стан. Після успішного створення ControllerRevision, його не можна оновити. API Server не пройде валідацію всіх запитів, які намагаються змінити поле Data. Однак ControllerRevision може бути видалено. Зверніть увагу, що через використання цього обʼєкта обома контролерами DaemonSet і StatefulSet для оновлення та відкату, він знаходиться на стадії бета-тестування. З усім тим, його назва та представлення можуть змінюватися в майбутніх версіях, і клієнти не повинні покладатися на його стабільність. Він призначений головним чином для внутрішнього використання контролерами.


  • apiVersion: apps/v1

  • kind: ControllerRevision

  • metadata (ObjectMeta)

    Стаціонарні метадані обʼєкта. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

  • revision (int64), обовʼязково

    поле revision показує номер ревізії стану представленого в Data.

  • data (RawExtension)

    Data є серіалізованим представленням стану.

    RawExtension використовується для утримання розширень у зовнішніх версіях.

    Щоб використовувати це, створіть поле, яке має RawExtension як тип у вашій зовнішній, версійній структурі, і Object у вашій внутрішній структурі. Вам також потрібно зареєструвати різні типи втулків.

    // Внутрішній пакет:

    type MyAPIObject struct {
      runtime.TypeMeta `json:",inline"`
      MyPlugin runtime.Object `json:"myPlugin"`
    }
    
    type PluginA struct {
      AOption string `json:"aOption"`
    }
    

    // Зовнішній пакет:

    type MyAPIObject struct {
      runtime.TypeMeta `json:",inline"`
      MyPlugin runtime.RawExtension `json:"myPlugin"`
     }
    
    type PluginA struct {
      AOption string `json:"aOption"`
    }
    

    // У мережі JSON буде виглядати приблизно так:

    {
      "kind":"MyAPIObject",
      "apiVersion":"v1",
      "myPlugin": {
        "kind":"PluginA",
        "aOption":"foo",
      },
    }
    

    Що ж відбувається? Спочатку декодування використовує json або yaml для перетворення серіалізованих даних у вашу зовнішню структуру MyAPIObject. Це призводить до збереження сирого JSON, але не до його розпакування. Наступним кроком є копіювання (використовуючи pkg/conversion) у внутрішню структуру. У пакеті runtime, функції перетворення, встановлені в DefaultScheme, розпакують JSON, збережений у RawExtension, перетворюючи його в правильний тип обʼєкта і зберігаючи його в Object. (TODO: У випадку, якщо обʼєкт невідомого типу, буде створено обʼєкт runtime.Unknown і збережено.)

ControllerRevisionList

ControllerRevisionList — це ресурс, що містить список обʼєктів ControllerRevision.


Операції


get отримати вказаний ControllerRevision

HTTP запит

GET /apis/apps/v1/namespaces/{namespace}/controllerrevisions/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва ControllerRevision

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (ControllerRevision): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу ControllerRevision

HTTP-запит

GET /apis/apps/v1/namespaces/{namespace}/controllerrevisions

Параметри

Відповідь

200 (ControllerRevisionList): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу ControllerRevision

HTTP-запит

GET /apis/apps/v1/controllerrevisions

Параметри

Відповідь

200 (ControllerRevisionList): OK

401: Unauthorized

create створення ControllerRevision

HTTP-запит

POST /apis/apps/v1/namespaces/{namespace}/controllerrevisions

Параметри

Відповідь

200 (ControllerRevision): OK

201 (ControllerRevision): Created

202 (ControllerRevision): Accepted

401: Unauthorized

update зміна вказаного ControllerRevision

HTTP-запит

PUT /apis/apps/v1/namespaces/{namespace}/controllerrevisions/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ControllerRevision

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: ControllerRevision, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (ControllerRevision): OK

201 (ControllerRevision): Created

401: Unauthorized

patch часткове оновлення вказаного ControllerRevision

HTTP-запит

PATCH /apis/apps/v1/namespaces/{namespace}/controllerrevisions/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ControllerRevision

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (ControllerRevision): OK

201 (ControllerRevision): Created

401: Unauthorized

delete видалення ControllerRevision

HTTP-запит

DELETE /apis/apps/v1/namespaces/{namespace}/controllerrevisions/{name}

Параметри

  • name (в шляху): string, обовʼязковий

    імʼя ControllerRevision

  • namespace (в шляху): string, обовʼязковий

    namespace

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції ControllerRevision

HTTP-запит

DELETE /apis/apps/v1/namespaces/{namespace}/controllerrevisions

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

6.5.1.9 - DaemonSet

DaemonSet представляє налаштування набору фонових служб (демонів).

apiVersion: apps/v1

import "k8s.io/api/apps/v1"

DaemonSet

DaemonSet представляє налаштування набору фонових служб (демонів).


DaemonSetSpec

DaemonSetSpec є специфікацією DaemonSet.


  • selector (LabelSelector), обовʼязково

    Запит міток для Podʼів, якими керує набір демонів. Має мати збіг з міткам шаблону Pod. Докладніше: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors

  • template (PodTemplateSpec), обовʼязково

    Обʼєкт, який описує Pod, який буде створено. DaemonSet створює рівно одну копію цього Pod на кожному вузлі, який відповідає селектору вузлів шаблону (або на кожному вузлі, якщо селектор вузлів не вказано). Єдине допустиме значення параметра restartPolicy шаблону — "Always". Докладніше: https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller#pod-template

  • minReadySeconds (int32)

    Мінімальна кількість секунд, протягом яких новий Pod DaemonSet має бути готовим без збоїв будь-якого з його контейнерів, щоб вважатися доступним. Стандартне значення — 0 (Pod вважається доступним, як тільки він буде готовим).

  • updateStrategy (DaemonSetUpdateStrategy)

    Стратегія оновлення для заміни поточних Podʼів DaemonSet новими Podʼами.

    DaemonSetUpdateStrategy є структурою, що використовується для управління стратегією оновлення для DaemonSet.

    • updateStrategy.type (string)

      Тип оновлення набору демонів. Може бути "RollingUpdate" або "OnDelete". Стандартне значення — RollingUpdate.

    • updateStrategy.rollingUpdate (RollingUpdateDaemonSet)

      Налаштування параметрів постійного оновлення. Присутній тільки якщо type = "RollingUpdate".

      Spec для контролю небхідної поведінки постійного оновлення набору демонів.

      • updateStrategy.rollingUpdate.maxSurge (IntOrString)

        Максимальна кількість вузлів з навним доступним Pod DaemonSet, яка може мати оновлений Pod DaemonSet під час оновлення. Значення може бути абсолютним числом (наприклад, 5) або відсотком від бажаних Podʼів (наприклад, 10%). Це не може бути 0, якщо MaxUnavailable дорівнює 0. Абсолютне число обчислюється з відсотка, округленого в більшу сторону до мінімуму 1. Стандартне значення — 0. Наприклад: коли це встановлено на 30%, як максимум 30% від загальної кількості вузлів, повинні мати Pod демона (тобто status.desiredNumberScheduled), можуть мати свій новий Pod створений до того, як старий Pod буде видалений. Оновлення починається з запуску нових Podʼів на 30% вузлів. Як тільки оновлений Pod доступний (готовий протягом принаймні minReadySeconds), старий Pod DaemonSet на цьому вузлі позначається як видалений. Якщо старий Pod стає недоступним з будь-якої причини (готовність переходить у false, його виселяють або переносять з вузла), на цьому вузлі негайно створюється оновлений Pod без урахування обмежень по сплеску навантаження. Дозвіл на сплеск означає можливість подвоєння ресурсів, які використовуються DaemonSet на будь-якому вузлі, якщо перевірка готовності не вдається, тому ресурсомісткі DaemonSet повинні враховувати, що вони можуть спричинити виселення під час розладу.

        IntOrString — це тип, який може містити int32 або рядок. При використанні перетворення з/в JSON або YAML він виробляє або споживає внутрішній тип. Це дозволяє вам мати, наприклад, поле JSON, яке може приймати імʼя або число.

      • updateStrategy.rollingUpdate.maxUnavailable (IntOrString)

        Максимальна кількість Podʼів DaemonSet, які можуть бути недоступні під час оновлення. Значення може бути абсолютним числом (наприклад, 5) або відсотком від загальної кількості Podʼів DaemonSet на початок оновлення (наприклад, 10%). Абсолютне число обчислюється з відсотка, округленого в більшу сторону. Це не може бути 0, якщо MaxSurge дорівнює 0. Стандартне значення — 1. Наприклад: коли це встановлено на 30%, максимум 30% від загальної кількості вузлів, які повинні виконувати Pod демона (тобто status.desiredNumberScheduled), можуть мати свої Pod зупинені для оновлення в будь-який час. Оновлення починається з зупинки не більше 30% цих Podʼів DaemonSet і потім запускає нові Pod DaemonSet на їх місця. Після того, як нові Pod стануть доступними, вони продовжують роботу з іншими Podʼами DaemonSet, забезпечуючи тим самим, що принаймні 70% від початкової кількості Podʼів DaemonSet доступні.

        IntOrString — це тип, який може містити int32 або рядок. При використанні перетворення з/в JSON або YAML він виробляє або споживає внутрішній тип. Це дозволяє вам мати, наприклад, поле JSON, яке може приймати імʼя або число.

  • revisionHistoryLimit (int32)

    Кількість версій історії, яку потрібно зберегти, щоб дозволити відкат. Це вказівник для розрізнення між явним нулем та не вказаним значенням. Стандартне значення — 10.

DaemonSetStatus

DaemonSetStatus представляє поточний стан DaemonSet.


  • numberReady (int32), обовʼязково

    Кількість вузлів, на яких має бути запущений Pod демона й один або кілька з них у стані Ready.

  • numberAvailable (int32)

    Кількість вузлів, на яких має бути запущений Pod демона й один або кілька з них запущені та доступні (готові щонайменше протягом spec.minReadySeconds).

  • numberUnavailable (int32)

    Кількість вузлів, на яких має бути запущений Pod демона, але жоден з них не запущений і доступний (готовий щонайменше протягом spec.minReadySeconds).

  • numberMisscheduled (int32), обовʼязково

    Кількість вузлів, на яких запущений Pod демона, але вони не повинні його виконувати. Додаткова інформація: https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/

  • desiredNumberScheduled (int32), обовʼязково

    Загальна кількість вузлів, на яких має бути запущений Pod демона (включаючи вузли, на яких Pod демона вже правильно запущений). Додаткова інформація: https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/

  • currentNumberScheduled (int32), обовʼязково

    Кількість вузлів, на яких запущено принаймні один Pod демона і які повинні виконувати Pod демона. Додаткова інформація: https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/

  • updatedNumberScheduled (int32)

    Загальна кількість вузлів, на яких запущено оновлений Pod демона.

  • collisionCount (int32)

    Кількість колізій хешів для DaemonSet. Контролер DaemonSet використовує це поле як механізм уникнення колізій при створенні імені для найновішого ControllerRevision.

  • conditions ([]DaemonSetCondition)

    Patch strategy: злиття за ключем type

    Map: унікальні значення ключа type будуть збережені під час злиття

    Представляє останні доступні спостереження поточного стану DaemonSet.

    DaemonSetCondition описує стан DaemonSet у певний момент часу.

    • conditions.status (string), обовʼязково

      Статус стану, один із True, False, Unknown.

    • conditions.type (string), обовʼязково

      Тип стану DaemonSet.

    • conditions.lastTransitionTime (Time)

      Час останнього зміни стану з одного статусу до іншого.

      Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

    • conditions.message (string)

      Повідомлення, зрозуміле людині, із зазначенням деталей про перехід.

    • conditions.reason (string)

      Причина останньої зміни стану.

  • observedGeneration (int64)

    Останнє покоління, яке спостерігається контролером набору демонів.

DaemonSetList

DaemonSetList є колекцією DaemonSet.


Операції


get отримати вказаний DaemonSet

HTTP запит

GET /apis/apps/v1/namespaces/{namespace}/daemonsets/{name}

Параметри

  • name (в шляху): string, обовʼязково

    Назва DaemonSet.

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (DaemonSet): OK

401: Unauthorized

get отримати статус вказаного DaemonSet

HTTP запит

GET /apis/apps/v1/namespaces/{namespace}/daemonsets/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя DaemonSet

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (DaemonSet): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу DaemonSet

HTTP запит

GET /apis/apps/v1/namespaces/{namespace}/daemonsets

Параметри

Відповідь

200 (DaemonSetList): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу DaemonSet

HTTP запит

GET /apis/apps/v1/daemonsets

Параметри

Відповідь

200 (DaemonSetList): OK

401: Unauthorized

create створення DaemonSet

HTTP запит

POST /apis/apps/v1/namespaces/{namespace}/daemonsets

Параметри

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: DaemonSet, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (DaemonSet): OK

201 (DaemonSet): Created

202 (DaemonSet): Accepted

401: Unauthorized

update заміна вказаного DaemonSet

HTTP запит

PUT /apis/apps/v1/namespaces/{namespace}/daemonsets/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва DaemonSet

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: DaemonSet, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (DaemonSet): OK

201 (DaemonSet): Created

401: Unauthorized

update заміна статусу вказаного DaemonSet

HTTP запит

PUT /apis/apps/v1/namespaces/{namespace}/daemonsets/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    назва DaemonSet

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: DaemonSet, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (DaemonSet): OK

201 (DaemonSet): Created

401: Unauthorized

patch часткове оновлення вказаного DaemonSet

HTTP запит

PATCH /apis/apps/v1/namespaces/{namespace}/daemonsets/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва DaemonSet

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (DaemonSet): OK

201 (DaemonSet): Created

401: Unauthorized

patch часткове оновлення статусу вказаного DaemonSet

HTTP запит

PATCH /apis/apps/v1/namespaces/{namespace}/daemonsets/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    назва DaemonSet

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (DaemonSet): OK

201 (DaemonSet): Created

401: Unauthorized

delete видалення DaemonSet

HTTP запит

DELETE /apis/apps/v1/namespaces/{namespace}/daemonsets/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва DaemonSet

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції DaemonSet

HTTP запит

DELETE /apis/apps/v1/namespaces/{namespace}/daemonsets

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

6.5.1.10 - Job

Job представляє конфігурацію окремого завдання.

apiVersion: batch/v1

import "k8s.io/api/batch/v1"

Job

Job представляє конфігурацію окремого завдання.


JobSpec

JobSpec описує, як виглядатиме виконання завдання.

Репліки

  • template (PodTemplateSpec), обовʼязково

    Описує pod, який буде створено під час виконання завдання. Єдині дозволені значення template.spec.restartPolicy — "Never" або "OnFailure". Детальніше: https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/

  • parallelism (int32)

    Визначає максимальну бажану кількість Podʼів, які завдання повинно виконувати в будь-який момент часу. Фактична кількість Podʼів, що працюють в стабільному стані, буде меншою за цю кількість, коли ((.spec.completions - .status.successful) < .spec.parallelism), тобто коли залишилося менше роботи, ніж максимально дозволена паралельність. Детальніше: https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/

Життєвий цикл

  • completions (int32)

    Визначає бажану кількість успішно завершених Podʼів, які має виконати завдання. Встановлення null означає, що успіх будь-якого Podʼа сигналізує про успіх усіх Podʼів і дозволяє паралельності мати будь-яке позитивне значення. Встановлення значення 1 означає, що паралельність обмежується до 1 і успіх цього Podʼа сигналізує про успіх завдання. Детальніше: https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/

  • completionMode (string)

    completionMode визначає, як відстежуються завершення Podʼів. Може бути NonIndexed (стандартно) або Indexed.

    NonIndexed означає, що завдання вважається завершеним, коли успішно завершено кількість Podʼів вказана у .spec.completions. Кожне завершення Podʼа є аналогічним до іншого.

    Indexed означає, що Podʼи завдання отримують асоційований індекс завершення від 0 до (.spec.completions — 1), доступний в анотації batch.kubernetes.io/job-completion-index. Завдання вважається завершеним, коли для кожного індексу є один успішно завершений Pod. Коли значення Indexed, .spec.completions має бути вказано, а .spec.parallelism має бути менше або дорівнювати 10^5. Крім того, імʼя Podʼа має форму $(job-name)-$(index)-$(random-string), а імʼя хоста Podʼа має форму $(job-name)-$(index).

    У майбутньому можуть бути додані інші режими завершення. Якщо контролер завдання спостерігає режим, який він не розпізнає, що можливо під час оновлень через різницю версій, контролер пропускає оновлення для завдання.

  • backoffLimit (int32)

    Визначає кількість спроб перед тим, як відзначити завдання таким, що не вдалося. Стандартне значення — 6.

  • activeDeadlineSeconds (int64)

    Визначає тривалість у секундах відносно startTime, протягом якої завдання може бути активним, перш ніж система спробує його завершити; значення має бути додатним цілим числом. Якщо завдання призупинено (під час створення або через оновлення), цей таймер фактично зупиняється і скидається, коли завдання знову відновлюється.

  • ttlSecondsAfterFinished (int32)

    ttlSecondsAfterFinished обмежує термін життя завдання, яке завершило виконання (або Complete, або Failed). Якщо це поле встановлено, то через ttlSecondsAfterFinished після завершення завдання воно може бути автоматично видалене. Коли завдання видаляється, його життєвий цикл (наприклад, завершувачі) буде враховуватись. Якщо це поле не встановлено, завдання не буде автоматично видалено. Якщо це поле встановлено на нуль, завдання може бути видалене відразу після завершення.

  • suspend (boolean)

    suspend визначає, чи повинен контролер завдання створювати Podʼи чи ні. Якщо завдання створюється з параметром suspend, встановленим на true, контролер завдання не створює Podʼи. Якщо завдання призупиняється після створення (тобто прапорець змінюється з false на true), контролер завдання видалить усі активні Podʼи, повʼязані з цим завданням. Користувачі повинні спроєктувати своє робоче навантаження так, щоб воно могло правильно обробляти це. Призупинення завдання скине поле StartTime завдання, фактично скидаючи таймер ActiveDeadlineSeconds. Стандартне значення — false.

Селектор

  • selector (LabelSelector)

    Запит до міток на Podʼах, які повинні відповідати кількості Podʼів. Зазвичай система встановлює це поле для вас. Детальніше: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors

  • manualSelector (boolean)

    manualSelector керує генерацією міток Podʼів і селекторів Podʼів. Залиште manualSelector невстановленим, якщо ви не впевнені, що робите. Коли значення false або невстановлене, система вибирає унікальні мітки для цього завдання та додає ці мітки до шаблону Podʼа. Коли значення true, користувач відповідає за вибір унікальних міток і вказування селектора. Невдача у виборі унікальної мітки може спричинити некоректну роботу цього та інших завдань. Однак ви можете побачити manualSelector=true у завданнях, створених за допомогою старого API extensions/v1beta1. Детальніше: https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/#specifying-your-own-pod-selector

Бета-рівень

  • podFailurePolicy (PodFailurePolicy)

    Визначає політику обробки невдалих Podʼів. Зокрема, дозволяє вказати набір дій та умов, які повинні бути виконані для виконання повʼязаної дії. Якщо це поле порожнє, застосовується стандартна поведінка — лічильник невдалих Podʼів, представлений полем .status.failed завдання, збільшується і перевіряється з backoffLimit. Це поле не можна використовувати в комбінації з restartPolicy=OnFailure.

    PodFailurePolicy описує, як невдалі Podʼи впливають на backoffLimit.

    • podFailurePolicy.rules ([]PodFailurePolicyRule), обовʼязково

      Atomic: буде замінено під час обʼєднання

      Список правил політики невдач Podʼів. Правила оцінюються послідовно. Як тільки правило відповідає невдачі Podʼа, решта правил ігнорується. Якщо жодне правило не відповідає невдачі Podʼа, застосовується стандартна обробка — лічильник невдач Podʼів збільшується і перевіряється з backoffLimit. Максимально дозволено 20 елементів.

      PodFailurePolicyRule описує, як обробляється невдача Podʼа, коли виконуються вимоги. Одне з onExitCodes і onPodConditions, але не обидва, можуть бути використані в кожному правилі.

      • podFailurePolicy.rules.action (string), обовʼязково

        Визначає дію, яка виконується при невдачі Podʼа, коли виконуються вимоги. Можливі значення:

        • FailJob: означає, що завдання Podʼа позначається як Failed і всі запущені Podʼи завершуються.
        • FailIndex: означає, що індекс Podʼа позначається як Failed і не буде перезапущений. Це значення рівня бета. Воно може бути використане, коли ввімкнено прапорець JobBackoffLimitPerIndex (стандартно увімкнено).
        • Ignore: означає, що лічильник по відношенню до .backoffLimit не збільшується і створюється Pod заміна.
        • Count: означає, що Pod обробляється стандартним способом — лічильник .backoffLimit збільшується.

        Додаткові значення можуть бути додані в майбутньому. Клієнти повинні реагувати на невідому дію, пропускаючи правило.

      • podFailurePolicy.rules.onExitCodes (PodFailurePolicyOnExitCodesRequirement)

        Представляє вимогу до кодів завершення контейнера.

        PodFailurePolicyOnExitCodesRequirement описує вимогу для обробки невдалого Podʼа на основі кодів завершення його контейнера. Зокрема, перевіряється .state.terminated.exitCode для кожного контейнера застосунку та init-контейнера, представленого полями .status.containerStatuses і .status.initContainerStatuses у статусі Podʼа відповідно. Контейнери, завершені успішно (код завершення 0), виключаються з перевірки вимоги.

        • podFailurePolicy.rules.onExitCodes.operator (string), обовʼязково

          Представляє стосунок між кодом(ами) завершення контейнера та зазначеними значеннями. Контейнери, завершені успішно (код завершення 0), виключаються з перевірки вимоги. Можливі значення:

          • In: вимога задовольняється, якщо хоча б один код завершення контейнера (може бути кілька, якщо є кілька контейнерів, не обмежених полем 'containerName') входить до набору зазначених значень.
          • NotIn: вимога задовольняється, якщо хоча б один код завершення контейнера (може бути кілька, якщо є кілька контейнерів, не обмежених полем 'containerName') не входить до набору зазначених значень.

          Додаткові значення можуть бути додані в майбутньому. Клієнти повинні реагувати на невідомий оператор, вважаючи, що вимога не задоволена.

        • podFailurePolicy.rules.onExitCodes.values ([]int32), обовʼязково

          Set: унікальні значення зберігатимуться під час обʼєднання

          Визначає набір значень. Кожен повернутий код завершення контейнера (може бути кілька у випадку кількох контейнерів) перевіряється щодо цього набору значень з урахуванням оператора. Список значень має бути впорядкованим і не містити дублікатів. Значення '0' не може бути використано для оператора In. Потрібен принаймні один елемент. Максимально дозволено 255 елементів.

        • podFailurePolicy.rules.onExitCodes.containerName (string)

          Обмежує перевірку кодів завершення контейнера контейнером з зазначеним імʼям. Коли null, правило застосовується до всіх контейнерів. Коли зазначено, воно має відповідати одному з імен контейнерів або init-контейнерів у шаблоні Podʼа.

      • podFailurePolicy.rules.onPodConditions ([]PodFailurePolicyOnPodConditionsPattern), обовʼязково

        Atomic: буде замінено під час обʼєднання

        Представляє вимогу до стану Podʼа. Вимога представлена як список шаблонів стан Podʼа. Вимога задовольняється, якщо хоча б один шаблон відповідає фактичному стану Podʼа. Максимально дозволено 20 елементів.

        PodFailurePolicyOnPodConditionsPattern описує шаблон для відповідності фактичний стан Podʼа.

        • podFailurePolicy.rules.onPodConditions.status (string), обовʼязково

          Визначає необхідний статус стану Podʼа. Для відповідності стану Podʼа потрібно, щоб зазначений статус відповідав статусу стану Podʼа. Стандартне значення — True.

        • podFailurePolicy.rules.onPodConditions.type (string), обовʼязково

          Визначає необхідний тип стану Podʼа. Для відповідності стану Podʼа потрібно, щоб зазначений тип відповідав типу стану Podʼа.

  • successPolicy (SuccessPolicy)

    successPolicy вказує політику, коли Job може бути оголошено успішним. Якщо це поле порожнє, застосовується стандартна поведінка — Job вважається успішним лише тоді, коли кількість успішно виконаних podʼів дорівнює значенню completions. Якщо поле вказане, воно має бути незмінним і працює тільки для Indexed Jobs. Після того, як Job відповідає SuccessPolicy, невикористані podʼи завершуються.

    Це поле має рівень beta. Для використання цього поля потрібно увімкнути функцію JobSuccessPolicy (стандартно увімкнена).

    SuccessPolicy описує, коли Job може бути оголошено успішним на основі успішності деяких показників.

    • successPolicy.rules ([]SuccessPolicyRule), required

      Atomic: буде замінено під час злиття

      rules представляє список альтернативних правил для оголошення Jobs успішними до того, як .status.succeeded >= .spec.completions. Як тільки будь-яке з правил виконується, додається умова "SucceededCriteriaMet", і невикористані podʼи видаляються. Кінцевий стан для такого Job матиме стан "Complete". Ці правила оцінюються по порядку; як тільки Job відповідає одному з правил, інші ігноруються. Дозволено не більше 20 елементів.

      SuccessPolicyRule описує правило для оголошення Job успішним. Кожне правило повинно мати вказаний принаймні один із параметрів: "succeededIndexes" або "succeededCount".

      • successPolicy.rules.succeededCount (int32)

        succeededCount вказує мінімальний необхідний розмір фактичного набору успішно завершених індексів для Job. Коли succeededCount використовується разом із succeededIndexes, перевірка обмежується лише індексами, зазначеними в succeededIndexes. Наприклад, якщо succeededIndexes встановлено як "1-4", succeededCount дорівнює "3", а індекси, що були завершені — "1", "3" і "5", Job не оголошується успішним, оскільки враховуються лише індекси "1" і "3" згідно з цими правилами. Якщо це поле є null, воно не має стандартного значення і ніколи не оцінюється. Якщо вказано, воно повинно бути додатним цілим числом.

      • successPolicy.rules.succeededIndexes (string)

        succeededIndexes вказує набір індексів, які повинні бути у фактичному наборі успішно завершених індексів для Job. Список індексів має бути в межах від 0 до ".spec.completions-1" і не повинен містити дублікатів. Потрібен щонайменше один елемент. Індекси представлені у вигляді інтервалів, розділених комами. Інтервали можуть бути десятковими числами або парою десяткових чисел, розділених дефісом. Числа представляються як перший і останній елемент серії, розділені дефісом. Наприклад, якщо індекси, які були завершені — 1, 3, 4, 5 і 7, вони представлені як "1,3-5,7". Якщо це поле є null, воно не має стандартного значення і ніколи не оцінюється.

Альфа-рівень

  • backoffLimitPerIndex (int32)

    Визначає ліміт кількості повторних спроб в межах індексу перед тим, як позначити цей індекс як невдалий. Коли цей параметр увімкнений, кількість невдач по індексу зберігається в анотації Podʼа batch.kubernetes.io/job-index-failure-count. Це поле можна встановити лише при completionMode=Indexed для завдання, і політика перезапуску Podʼа повинна бути Never. Поле незмінне. Це поле на рівні бета. Воно може бути використане, коли ввімкнено прапорець JobBackoffLimitPerIndex (стандартно увімкнено).

  • managedBy (string)

    Поле ManagedBy вказує контролер, який керує Job. Контролер Job у Kubernetes синхронізує jobʼи, які не мають цього поля взагалі або якщо значення поля — зарезервований рядок kubernetes.io/job-controller, але пропускає синхронізацію Job із власними значенням у цьому полі. Значення має бути дійсним шляхом із префіксом домену (наприклад, acme.io/foo) — усі символи перед першим "/" мають бути дійсним піддоменом відповідно до RFC 1123. Усі символи після першого "/" мають бути дійсними символами HTTP-шляху згідно з RFC 3986. Значення не може перевищувати 63 символів. Це поле є незмінним.

    Це поле має рівень alpha. Контролер job приймає встановлення цього поля, коли ввімкнено функцію JobManagedBy (стандартно вимкнено).

  • maxFailedIndexes (int32)

    Визначає максимальну кількість невдалих індексів перед тим, як позначити завдання як невдале, коли backoffLimitPerIndex встановлено. Як тільки кількість невдалих індексів перевищує це число, все завдання позначається як Failed і його виконання припиняється. Якщо залишити null, завдання продовжує виконання всіх своїх індексів і позначається станом завдання Complete. Це поле можна вказати лише, коли встановлено backoffLimitPerIndex. Воно може бути null або дорівнювати кількості completions. Воно обовʼязково і повинно бути менше або дорівнювати 10^4, коли кількість completions більша за 10^5. Це поле на рівні бета. Воно може бути використане, коли ввімкнено прапорець JobBackoffLimitPerIndex (стандартно увімкнено).

  • podReplacementPolicy (string)

    podReplacementPolicy визначає, коли створювати нові Podʼи на заміну. Можливі значення:

    • TerminatingOrFailed означає, що ми створюємо Podʼи повторно, коли вони завершуються (мають metadata.deletionTimestamp) або не зазнали збою.
    • Failed означає, що потрібно чекати, поки раніше створений Pod повністю завершиться (має phase Failed або Succeeded) перед створенням нового Podʼа на заміну.

    При використанні podFailurePolicy, Failed є єдиним допустимим значенням. TerminatingOrFailed і Failed є допустимими значеннями, коли podFailurePolicy не використовується. Це поле на рівні бета. Щоб скористатися цією функцією, увімкніть функцію JobPodReplacementPolicy. Стандартно увімкнено.

JobStatus

JobStatus представляє поточний стан Job.


  • startTime (Time)

    Представляє час, коли контролер Job почав обробку завдання. Коли Job створюється в призупиненому стані, це поле не встановлюється до першого відновлення. Це поле скидається кожного разу, коли Job відновлюється після призупинення. Воно представлене у форматі RFC3339 і є в UTC.

    Якщо поле встановлено, його можна видалити лише після призупинення завдання. Поле не можна змінити, поки завдання не призупинено або не завершено.

    Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

  • completionTime (Time)

    Представляє час, коли завдання було завершено. Це поле може не встановлюватися в порядку "відбувається перед" у різних операціях. Воно представлене у форматі RFC3339 і є в UTC. Час завершення встановлюється, коли завдання успішно завершується, і тільки тоді. Значення не можна оновити або видалити. Значення вказує на той самий або пізніший момент часу, що і поле startTime.

    Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

  • active (int32)

    Кількість Podʼів в стані очікування та працюючих Podʼів, які не завершуються (без мітки видалення). Значення дорівнює нулю для завершених завдань.

  • failed (int32)

    Кількість Podʼів, які досягли фази Failed. Значення зростає монотонно.

  • succeeded (int32)

    Кількість Podʼів, які досягли фази Succeeded. Значення монотонно зростає для даної специфікації. Однак воно може зменшуватись у відповідь на скорочення кількості job, що еластично індексуються.

  • completedIndexes (string)

    completedIndexes містить завершені індекси, коли .spec.completionMode = "Indexed" у текстовому форматі. Індекси представлені у вигляді десяткових чисел, розділених комами. Числа перелічені у порядку зростання. Три або більше послідовних числа стискаються і представлені першим і останнім елементами серії, розділеними дефісом. Наприклад, якщо завершені індекси 1, 3, 4, 5 і 7, вони представлені як "1,3-5,7".

  • conditions ([]JobCondition)

    Patch strategy: обʼєднання за ключем type

    Atomic: буде замінено під час обʼєднання

    Останні доступні спостереження за поточним станом обʼєкта. Коли Job не вдається, один зі станів матиме тип "Failed" і статус true. Коли Job призупинено, один зі станів матиме тип "Suspended" і статус true; коли Job відновлюється, статус цього стану стає false. Коли Job завершено, один з станів матиме тип "Complete" і статус true.

    Завдання вважається завершеним, коли воно перебуває в термінальному стані "Complete" або "Failed". Завдання не може мати одночасно стан "Complete" і "Failed". Крім того, воно не може перебувати в станах "Complete" і "FailureTarget". Умови "Complete", "Failed" і "FailureTarget" не можуть бути відключені.

    Додаткова інформація: https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/

    JobCondition описує поточний стан завдання.

    • conditions.status (string), обовʼязково

      Статус стану, одне з True, False, Unknown.

    • conditions.type (string), обовʼязково

      Тип стану завдання, Complete або Failed.

    • conditions.lastProbeTime (Time)

      Останній раз, коли стан було перевірено.

      Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

    • conditions.lastTransitionTime (Time)

      Останній раз, коли стан переходила з одного статусу в інший.

      Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

    • conditions.message (string)

      Повідомлення, зрозуміле людині, із зазначенням деталей останнього переходу.

    • conditions.reason (string)

      (коротка) причина останнього переходу стану.

  • uncountedTerminatedPods (UncountedTerminatedPods)

    uncountedTerminatedPods містить UID Podʼів, які завершили роботу, але контролер завдань ще не врахував їх у статусних лічильниках.

    Контролер завдань створює Podʼи з завершувачем. Коли Pod завершується (успішно або з помилкою), контролер виконує три кроки для врахування його у статусі завдання:

    1. Додає UID Podʼа до масивів у цьому полі.
    2. Видаляє завершувач Podʼа.
    3. Видаляє UID Podʼа з масивів, збільшуючи відповідний лічильник.

    Старі завдання можуть не відстежуватися з використанням цього поля, у такому випадку поле залишається порожнім. Структура порожня для завершених завдань .

    UncountedTerminatedPods містить UID Podʼів, які завершили роботу, але ще не враховані в лічильниках статусу завдання.

    • uncountedTerminatedPods.failed ([]string)

      Set: унікальні значення зберігатимуться під час обʼєднання

      failed містить UID Podʼів, що завершилися з помилкою.

    • uncountedTerminatedPods.succeeded ([]string)

      Set: унікальні значення зберігатимуться під час обʼєднання

      succeeded містить UID Podʼів, що завершилися успішно.

Бета-рівень

  • ready (int32)

    Кількість активних Podʼів, які мають стан Ready та не завшуються (без deletionTimestamp)

Альфа-рівень

  • failedIndexes (string)

    FailedIndexes зберігає невдалі індекси, коли spec.backoffLimitPerIndex є набором. Індекси представлені у текстовому форматі, аналогічному до поля completedIndexes, тобто вони зберігаються як десяткові цілі числа, розділені комами. Числа подані в порядку зростання. Три або більше послідовних числа стискаються і представлені першим та останнім елементом серії, розділеними дефісом. Наприклад, якщо невдалі індекси: 1, 3, 4, 5 і 7, вони представлені як "1,3-5,7". Набір невдалих індексів не може перетинатися з набором завершених індексів.

    Це поле знаходиться на бета-рівні. Його можна використовувати, коли ввімкнено функцію JobBackoffLimitPerIndex (стандартно увімкнено).

  • terminating (int32)

    Кількість Podʼів, які завершуються (у фазі Pending або Running та мають deletionTimestamp).

    Це поле знаходиться на бета-рівні. Контролер завдань заповнює це поле, коли ввімкнено функцію JobPodReplacementPolicy (стандартно увімкнено).

JobList

JobList представляє собою колекцію завдань.


Операції


get отримати вказане завдання

HTTP запит

GET /apis/batch/v1/namespaces/{namespace}/jobs/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва завдання

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (Job): ОК

401: Unauthorized

get отримати статус вказаного завдання

HTTP запит

GET /apis/batch/v1/namespaces/{namespace}/jobs/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    назва завдання

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (Job): ОК

401: Unauthorized

list перелік або перегляд обʼєктів типу Job

HTTP запит

GET /apis/batch/v1/namespaces/{namespace}/jobs

Параметри

Відповідь

200 (JobList): ОК

401: Unauthorized

list перелік або перегляд обʼєктів типу Job

HTTP запит

GET /apis/batch/v1/jobs

Параметри

Відповідь

200 (JobList): ОК

401: Unauthorized

create створення Job

HTTP запит

POST /apis/batch/v1/namespaces/{namespace}/jobs

Параметри

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Job, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (Job): ОК

201 (Job): Created

202 (Job): Accepted

401: Unauthorized

update заміна вказаного Job

HTTP запит

PUT /apis/batch/v1/namespaces/{namespace}/jobs/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва завдання

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Job, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (Job): ОК

201 (Job): Created

401: Unauthorized

update заміна статусу вказаного Job

HTTP запит

PUT /apis/batch/v1/namespaces/{namespace}/jobs/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    назва завдання

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Job, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (Job): ОК

201 (Job): Created

401: Unauthorized

patch часткове оновлення вказаного Job

HTTP запит

PATCH /apis/batch/v1/namespaces/{namespace}/jobs/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва завдання

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (Job): ОК

201 (Job): Created

401: Unauthorized

patch часткове оновлення статусу вказаного Job

HTTP запит

PATCH /apis/batch/v1/namespaces/{namespace}/jobs/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    назва завдання

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (Job): ОК

201 (Job): Created

401: Unauthorized

delete видалення Job

HTTP запит

DELETE /apis/batch/v1/namespaces/{namespace}/jobs/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва завдання

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (Status): ОК

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції Job

HTTP запит

DELETE /apis/batch/v1/namespaces/{namespace}/jobs

Параметри

Відповідь

200 (Status): ОК

401: Unauthorized

6.5.1.11 - CronJob

CronJob являє собою конфігурацію одного завдання cron.

apiVersion: batch/v1

import "k8s.io/api/batch/v1"

CronJob

CronJob являє собою конфігурацію одного завдання cron.


CronJobSpec

CronJobSpec описує, як виглядатиме виконання завдання та коли воно буде запущено.


  • jobTemplate (JobTemplateSpec), обовʼязково

    Вказує на шаблон задачі, яка буде створена під час виконання CronJob.

    JobTemplateSpec описує дані, які повинні бути у задачі при створенні з шаблону

  • schedule (string), обовʼязково

    Розклад у форматі Cron, див. https://uk.wikipedia.org/wiki/Cron.

  • timeZone (string)

    Назва часового поясу для вказаного розкладу, див. https://en.wikipedia.org/wiki/List_of_tz_database_time_zones. Якщо не вказано, то буде використовуватись часовий пояс процесу kube-controller-manager. Допустимі назви часових поясів і зміщення завантажуються з системної бази даних часових поясів API-сервером під час валідації CronJob і контролером під час виконання. Якщо системна база даних часових поясів недоступна, використовується вбудована версія цієї бази. Якщо назва часового поясу стає недійсною протягом життєвого циклу CronJob або через зміну конфігурації хосту, контролер перестане створювати нові задачі та створить системну подію з причиною UnknownTimeZone. Додаткову інформацію можна знайти в https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/#time-zones.

  • concurrencyPolicy (string)

    Визначає, як обробляти одночасні виконання задачі. Допустимі значення:

    • "Allow" (стандартно): дозволяє CronJobs запускати задачі одночасно;
    • "Forbid": забороняє одночасні виконання, пропускаючи наступний запуск, якщо попередній ще не завершився;
    • "Replace": скасовує поточну задачу і замінює її новою.
  • startingDeadlineSeconds (int64)

    Необовʼязковий термін у секундах для запуску задачі, якщо вона пропустить запланований час з будь-якої причини. Пропущені виконання задач будуть вважатися неуспішними.

  • suspend (boolean)

    Цей прапорець каже контролеру призупиняти подальші виконання, він не застосовується до вже запущених виконань. Стандартне значення — false.

  • successfulJobsHistoryLimit (int32)

    Кількість успішно завершених задач, які потрібно зберегти. Значення повинно бути не відʼємним цілим числом. Стандартне значення — 3.

  • failedJobsHistoryLimit (int32)

    Кількість невдало завершених задач, які потрібно зберегти. Значення повинно бути не відʼємним цілим числом. Стандартне значення — 1.

CronJobStatus

CronJobStatus представляє поточний стан cron job.


  • active ([]ObjectReference)

    Atomic: буде замінено під час злиття

    Список посилань на запущені зараз задачі.

  • lastScheduleTime (Time)

    Інформація про час останнього успішного запуску задачі.

    Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

  • lastSuccessfulTime (Time)

    Інформація про час останнього успішного завершення задачі.

    Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

CronJobList

CronJobList — це колекція cron job.


Операції


get отримати вказаний CronJob

HTTP-запит

GET /apis/batch/v1/namespaces/{namespace}/cronjobs/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва CronJob

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (CronJob): OK

401: Unauthorized

get отримати статус вказаного CronJob

HTTP-запит

GET /apis/batch/v1/namespaces/{namespace}/cronjobs/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    назва CronJob

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (CronJob): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу CronJob

HTTP-запит

GET /apis/batch/v1/namespaces/{namespace}/cronjobs

Параметри

Відповідь

200 (CronJobList): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу CronJob

HTTP-запит

GET /apis/batch/v1/cronjobs

Параметри

Відповідь

200 (CronJobList): OK

401: Unauthorized

create створення CronJob

HTTP-запит

POST /apis/batch/v1/namespaces/{namespace}/cronjobs

Параметри

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: CronJob, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (CronJob): OK

201 (CronJob): Created

202 (CronJob): Accepted

401: Unauthorized

update заміна вказаного CronJob

HTTP-запит

PUT /apis/batch/v1/namespaces/{namespace}/cronjobs/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва CronJob

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: CronJob, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (CronJob): OK

201 (CronJob): Created

401: Unauthorized

update заміна статусу вказаного CronJob

HTTP-запит

PUT /apis/batch/v1/namespaces/{namespace}/cronjobs/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    назва CronJob

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: CronJob, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (CronJob): OK

201 (CronJob): Created

401: Unauthorized

patch часткове оновлення вказаного CronJob

HTTP-запит

PATCH /apis/batch/v1/namespaces/{namespace}/cronjobs/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва CronJob

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (CronJob): OK

201 (CronJob): Created

401: Unauthorized

patch часткове оновлення статусу вказаного CronJob

HTTP-запит

PATCH /apis/batch/v1/namespaces/{namespace}/cronjobs/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    назва CronJob

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (CronJob): OK

201 (CronJob): Created

401: Unauthorized

delete видалення CronJob

HTTP-запит

DELETE /apis/batch/v1/namespaces/{namespace}/cronjobs/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва CronJob

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції CronJob

HTTP-запит

DELETE /apis/batch/v1/namespaces/{namespace}/cronjobs

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

6.5.1.12 - HorizontalPodAutoscaler

Конфігурація горизонтального автомасштабування Podʼів.

apiVersion: autoscaling/v1

import "k8s.io/api/autoscaling/v1"

HorizontalPodAutoscaler

Конфігурація горизонтального автомасштабування Podʼів.


HorizontalPodAutoscalerSpec

Специфікація горизонтального автомасштабування Podʼів.


  • maxReplicas (int32), обовʼязково

    maxReplicas — верхня межа для кількості Podʼів, яку може встановити автомасштабувальник; не може бути менше, ніж MinReplicas.

  • scaleTargetRef (CrossVersionObjectReference), обовʼязково

    посилання на масштабований ресурс; горизонтальний автомасштабувальник Podʼів буде вивчати поточне використання ресурсу і встановлювати бажану кількість Podʼів за допомогою його субресурсу Scale (масштаб).

    CrossVersionObjectReference містить достатньо інформації для ідентифікації зазначеного ресурсу.

  • minReplicas (int32)

    minReplicas — нижня межа для кількості реплік, до яких може масштабуватися автомасштабувальник. Стандартне значення — 1 Pod. minReplicas може бути 0, якщо увімкнутий альфа-функціонал HPAScaleToZero і налаштовано принаймні одну метрику Object або External. Масштабування активне, поки є принаймні значення однієї метрики.

  • targetCPUUtilizationPercentage (int32)

    targetCPUUtilizationPercentage — це цільове середнє використання CPU (представлене як відсоток від запитаного показника CPU) для всіх Podʼів; якщо не вказано, буде використана стандартна політика автоматичного масштабування.

HorizontalPodAutoscalerStatus

Поточний статус горизонтального автомасштабування Podʼів.


  • currentReplicas (int32), обовʼязково

    currentReplicas — поточна кількість реплік Podʼів, що керуються цим автомасштабувальником.

  • desiredReplicas (int32), обовʼязково

    desiredReplicas — бажана кількість реплік Podʼів, що керуються цим автомасштабувальником.

  • currentCPUUtilizationPercentage (int32)

    currentCPUUtilizationPercentage — поточне середнє використання CPU у всіх Podʼах, виражене як відсоток від запитаної кількості CPU; наприклад, значення 70 означає, що в середньому Pod використовує зараз 70% свого запитаного CPU.

  • lastScaleTime (Time)

    lastScaleTime — час останнього масштабування HorizontalPodAutoscaler кількості Podʼів; використовується автомасштабувальником для контролю частоти змін кількості Podʼів.

    Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

  • observedGeneration (int64)

    observedGeneration — останнє покоління, сяке спостерігається цим автомасштабувальником.

HorizontalPodAutoscalerList

Список обʼєктів горизонтального автомасштабування Podʼів.


  • apiVersion: autoscaling/v1

  • kind: HorizontalPodAutoscalerList

  • metadata (ListMeta)

    Стандартні метадані списку.

  • items ([]HorizontalPodAutoscaler), обовʼязкове поле

    items — список обʼєктів горизонтального автомасштабування Podʼів.

Операції


get отримати вказаний HorizontalPodAutoscaler

HTTP запит

GET /apis/autoscaling/v1/namespaces/{namespace}/horizontalpodautoscalers/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя HorizontalPodAutoscaler

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (HorizontalPodAutoscaler): OK

401: Unauthorized

get отримати статус вказаного HorizontalPodAutoscaler

HTTP запит

GET /apis/autoscaling/v1/namespaces/{namespace}/horizontalpodautoscalers/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя HorizontalPodAutoscaler

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (HorizontalPodAutoscaler): OK

401: Unauthorized

list список або перегляд за обʼєктів типу HorizontalPodAutoscaler

HTTP запит

GET /apis/autoscaling/v1/namespaces/{namespace}/horizontalpodautoscalers

Параметри

Відповідь

200 (HorizontalPodAutoscalerList): OK

401: Unauthorized

list список або перегляд обʼєктів типу HorizontalPodAutoscaler

HTTP запит

GET /apis/autoscaling/v1/horizontalpodautoscalers

Параметри

Відповідь

200 (HorizontalPodAutoscalerList): ОК

401: Unauthorized

create створення HorizontalPodAutoscaler

HTTP запит

POST /apis/autoscaling/v1/namespaces/{namespace}/horizontalpodautoscalers

Параметри

Відповідь

200 (HorizontalPodAutoscaler): ОК

201 (HorizontalPodAutoscaler): Created

202 (HorizontalPodAutoscaler): Accepted

401: Unauthorized

update заміна вказаного HorizontalPodAutoscaler

HTTP запит

PUT /apis/autoscaling/v1/namespaces/{namespace}/horizontalpodautoscalers/{name}

Параметри

  • name (в шляху): string, обовʼязково

    Назва HorizontalPodAutoscaler

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: HorizontalPodAutoscaler, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (HorizontalPodAutoscaler): ОК

201 (HorizontalPodAutoscaler): Created

401: Unauthorized

update заміна статусу вказаного HorizontalPodAutoscaler

HTTP запит

PUT /apis/autoscaling/v1/namespaces/{namespace}/horizontalpodautoscalers/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    Назва HorizontalPodAutoscaler

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: HorizontalPodAutoscaler, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (HorizontalPodAutoscaler): ОК

201 (HorizontalPodAutoscaler): Created

401: Unauthorized

patch часткове оновлення вказаного HorizontalPodAutoscaler

HTTP запит

PATCH /apis/autoscaling/v1/namespaces/{namespace}/horizontalpodautoscalers/{name}

Параметри

  • name (в шляху): string, обовʼязково

    Назва HorizontalPodAutoscaler

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (HorizontalPodAutoscaler): ОК

201 (HorizontalPodAutoscaler): Created

401: Unauthorized

patch часткове оновлення статусу вказаного HorizontalPodAutoscaler

HTTP запит

PATCH /apis/autoscaling/v1/namespaces/{namespace}/horizontalpodautoscalers/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    Назва HorizontalPodAutoscaler

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (HorizontalPodAutoscaler): ОК

201 (HorizontalPodAutoscaler): Created

401: Unauthorized

delete видалення HorizontalPodAutoscaler

HTTP запит

DELETE /apis/autoscaling/v1/namespaces/{namespace}/horizontalpodautoscalers/{name}

Параметри

  • name (в шляху): string, обовʼязково

    Назва HorizontalPodAutoscaler

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (Status): ОК

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції HorizontalPodAutoscaler

HTTP запит

DELETE /apis/autoscaling/v1/namespaces/{namespace}/horizontalpodautoscalers

Параметри

Відповідь

200 (Status): ОК

401: Unauthorized

6.5.1.13 - HorizontalPodAutoscaler

HorizontalPodAutoscaler — це конфігурація для горизонтального автомасштабування, яка автоматично керує кількістю реплік будь-якого ресурсу, що реалізує субресурс масштабування, на основі вказаних метрик.

apiVersion: autoscaling/v2

import "k8s.io/api/autoscaling/v2"

HorizontalPodAutoscaler

HorizontalPodAutoscaler — це конфігурація для горизонтального автомасштабування, яка автоматично керує кількістю реплік будь-якого ресурсу, що реалізує субресурс масштабування, на основі вказаних метрик.


Зрозуміло, ось переклад без формату YAML:

HorizontalPodAutoscalerSpec

HorizontalPodAutoscalerSpec описує бажану функціональність HorizontalPodAutoscaler.


  • maxReplicas (int32), обовʼязково

    maxReplicas — верхня межа кількості реплік, до якої може масштабуватись автомасштабувальник. Не може бути менше minReplicas.

  • scaleTargetRef (CrossVersionObjectReference), обовʼязково

    scaleTargetRef вказує на цільовий ресурс для масштабування і використовується для збору метрик для Podʼів, а також для зміни кількості реплік.

    CrossVersionObjectReference містить достатньо інформації для ідентифікації вказаного ресурсу.

  • minReplicas (int32)

    minReplicas — нижня межа кількості реплік, до якої може масштабуватись автомасштабувальник. Стандартне значення — 1 Pod. minReplicas може бути 0, якщо ввімкнути альфа-функцію HPAScaleToZero і налаштувати щонайменше одну метрику типу Object або External. Масштабування активне, поки є принаймні одне значення метрики.

  • behavior (HorizontalPodAutoscalerBehavior)

    behavior — налаштовує поведінку масштабування цільового ресурсу як в напрямку збільшення, так і в напрямку зменшення (поля scaleUp та scaleDown відповідно). Якщо не вказано, будуть використані типові правила масштабування HPAScalingRules для збільшення і зменшення.

    HorizontalPodAutoscalerBehavior налаштовує поведінку масштабування цільового ресурсу як в напрямку збільшення, так і в напрямку зменшення (поля scaleUp та scaleDown відповідно).

    • behavior.scaleDown (HPAScalingRules)

      scaleDown — політика масштабування для зменшення. Якщо не встановлено, типове значення дозволяє зменшувати до minReplicas Podʼів з вікном стабілізації 300 секунд (тобто використовується найкраще рекомендоване значення за останні 300 секунд).

      HPAScalingRules налаштовує поведінку масштабування для одного напрямку. Ці правила застосовуються після обчислення бажаної кількості реплік з метрик для HPA. Вони можуть обмежувати швидкість масштабування, вказуючи політики масштабування, та запобігати "повзучості" за допомогою визначення вікна стабілізації, щоб кількість реплік не встановлювалась миттєво, а вибирався найбезпечніше значення з вікна стабілізації.

      • behavior.scaleDown.policies ([]HPAScalingPolicy)

        Atomic: will be replaced during a merge

        policies — список потенційних політик масштабування, які можуть використовуватись під час масштабування. Принаймні одна політика повинна бути вказана, інакше HPAScalingRules буде відкинуто як недійсне

        HPAScalingPolicy — це одна політика, яка повинна виконуватися для вказаного інтервалу в минулому.

        • behavior.scaleDown.policies.type (string), обовʼязково

          type — використовується для зазначення політики масштабування.

        • behavior.scaleDown.policies.value (int32), обовʼязково

          value — містить кількість зміни, що дозволяється політикою. Вона повинна бути більше нуля.

        • behavior.scaleDown.policies.periodSeconds (int32), обовʼязково

          periodSeconds — визначає вікно часу, протягом якого політика повинна бути true. PeriodSeconds повинен бути більше нуля і менше або рівний 1800 (30 хвилин).

      • behavior.scaleDown.selectPolicy (string)

        selectPolicy — використовується для зазначення того, яка політика повинна бути використана. Якщо не встановлено, використовується типове значення Max.

      • behavior.scaleDown.stabilizationWindowSeconds (int32)

        stabilizationWindowSeconds — кількість секунд, протягом яких враховуються попередні рекомендації під час збільшення або зменшення масштабування. stabilizationWindowSeconds повинен бути більше або рівний нулю і менше або рівний 3600 (одна година). Якщо не встановлено, використовуються типові значення:

        • Для збільшення масштабування: 0 (тобто стабілізація не виконується).
        • Для зменшення масштабування: 300 (тобто вікно стабілізації 300 секунд).
  • behavior.scaleUp (HPAScalingRules)

    scaleUp — це політика масштабування вгору. Якщо не встановлено, використовується стандартне значення, яке є найбільшим з:

    • збільшення не більше ніж на 4 Podʼи за 60 секунд
    • подвоєння кількості Podʼів за 60 секунд

    Стабілізація не використовується.

    HPAScalingRules налаштовує поведінку масштабування в одному напрямку. Ці правила застосовуються після обчислення DesiredReplicas з метрик для HPA. Вони можуть обмежити швидкість масштабування, вказуючи політики масштабування. Вони можуть запобігти нестабільному масштабуванню, вказуючи вікно стабілізації, щоб кількість реплік не змінювалася миттєво, а вибиралося найбезпечніше значення з вікна стабілізації.

    • behavior.scaleUp.policies ([]HPAScalingPolicy)

      Atomic: буде замінено під час обʼєднання

      policies — це список можливих політик масштабування, які можуть бути використані під час масштабування. Має бути вказана принаймні одна політика, інакше HPAScalingRules буде вважатися недійсним.

      HPAScalingPolicy — це окрема політика, якої треба має бути true протягом заданого інтервалу в минулому.

      • behavior.scaleUp.policies.type (string), обовʼязково

        type — використовується для зазначення політики масштабування.

      • behavior.scaleUp.policies.value (int32), обовʼязково

        value — містить кількість змін, дозволених політикою. Значення має бути більше нуля.

      • behavior.scaleUp.policies.periodSeconds (int32), обовʼязково

        periodSeconds визначає вікно часу, протягом якого політика має бути true. PeriodSeconds має бути більше нуля та менше або дорівнювати 1800 (30 хвилин).

    • behavior.scaleUp.selectPolicy (string)

      selectPolicy використовується для вказівки, яка політика має бути використана. Якщо не встановлено, використовується стандартне значення Max.

    • behavior.scaleUp.stabilizationWindowSeconds (int32)

      stabilizationWindowSeconds — це кількість секунд, протягом яких минулі рекомендації мають враховуватися під час масштабування вгору або вниз. StabilizationWindowSeconds має бути більше або дорівнювати нулю та менше або дорівнювати 3600 (одна година). Якщо не встановлено, використовуються стандартні значення:

      • Для масштабування вгору: 0 (тобто стабілізація не виконується).
      • Для масштабування вниз: 300 (тобто вікно стабілізації триває 300 секунд).
  • metrics ([]MetricSpec)

    Atomic: буде замінено під час обʼєднання

    metrics містить специфікації для обчислення бажаної кількості реплік (буде використана максимальна кількість реплік за всіма метриками). Бажана кількість реплік обчислюється множенням відношення між цільовим значенням та поточним значенням на поточну кількість Podʼів. Таким чином, метрики, що використовуються, мають зменшуватися зі збільшенням кількості Podʼів, і навпаки. Дивіться індивідуальні типи джерел метрик для отримання додаткової інформації про те, як кожен тип метрик має реагувати. Якщо не встановлено, стандартна метрика з буде встановлена на 80% середнього використання CPU.

    MetricSpec визначає, як масштабуватися на основі однієї метрики (лише type та одне інше відповідне поле мають бути встановлені одночасно).

    • metrics.type (string), обовʼязково

      type — тип джерела метрики. Має бути одним з "ContainerResource", "External", "Object", "Pods" або "Resource", кожен з яких відповідає відповідному полю в обʼєкті. Примітка: тип "ContainerResource" доступний лише за умови, що увімкнено функцію HPAContainerMetrics.

    • metrics.containerResource (ContainerResourceMetricSource)

      containerResource стосується метрики ресурсу (наприклад, ті, що вказані в запитах і лімітах), відомої Kubernetes, яка описує один контейнер у кожному Podʼі поточного цільового масштабу (наприклад, CPU або памʼять). Такі метрики вбудовані в Kubernetes і мають спеціальні параметри масштабування на додаток до тих, що доступні для звичайних метрик на кожен Pod за допомогою джерела "pods". Це альфа-функція і може бути увімкнена прапорцем функції HPAContainerMetrics.

      ContainerResourceMetricSource вказує, як масштабуватися на основі метрики ресурсу, відомої Kubernetes, як вказано в запитах і лімітах, описуючи кожен Pod у поточному цільовому масштабі (наприклад, CPU або памʼять). Значення будуть усереднені перед порівнянням з цільовим значенням. Такі метрики вбудовані в Kubernetes і мають спеціальні параметри масштабування на додаток до тих, що доступні для звичайних метрик на кожен Pod за допомогою джерела "pods". Має бути встановлений лише один тип "target".

      • metrics.containerResource.container (string), обовʼязково

        container — це назва контейнера в Podʼах цільового масштабу.

      • metrics.containerResource.name (string), обовʼязково

        name — це назва відповідного ресурсу.

      • metrics.containerResource.target (MetricTarget), обовʼязково

        target — визначає цільове значення для даної метрики.

        MetricTarget визначає цільове значення, середнє значення або середнє використання певної метрики.

        • metrics.containerResource.target.type (string), обовʼязково

          type — представляє, чи є тип метрики Utilization, Value або AverageValue.

        • metrics.containerResource.target.averageUtilization (int32)

          averageUtilization — це цільове значення середнього значення метрики ресурсу по всім відповідним Podʼам, представлене у відсотках від запитуваного значення ресурсу для Podʼів. Наразі дійсно лише для типу джерела метрики Resource.

        • metrics.containerResource.target.averageValue (Quantity)

          averageValue – це цільове значення середнього значення метрики по всім відповідним Podʼам (як кількість).

        • metrics.containerResource.target.value (Quantity)

          value — це цільове значення метрики (як кількість).

    • metrics.external (ExternalMetricSource)

      external стосується глобальної метрики, яка не повʼязана з жодним обʼєктом Kubernetes. Це дозволяє автоматичне масштабування на основі інформації, що надходить від компонентів, які працюють за межами кластера (наприклад, довжина черги у хмарному сервісі обміну повідомленнями або QPS від балансувальника навантаження, що працює за межами кластера).

      ExternalMetricSource вказує, як масштабуватися на основі метрики, не повʼязаної з жодним обʼєктом Kubernetes (наприклад, довжина черги у хмарному сервісі обміну повідомленнями або QPS від балансувальника навантаження, що працює за межами кластера).

      • metrics.external.metric (MetricIdentifier), обовʼязково

        metric — визначає цільову метрику за назвою та селектором.

        MetricIdentifier визначає назву та, за потреби, селектор для метрики.

        • metrics.external.metric.name (string), обовʼязково

          name — це назва даної метрики.

        • metrics.external.metric.selector (LabelSelector)

          selector — це строкове кодування стандартного селектора міток Kubernetes для даної метрики. Якщо встановлено, він передається як додатковий параметр серверу метрик для більш специфічного вибору метрик. Якщо не встановлено, для збору метрик буде використовуватися лише назва метрики.

      • metrics.external.target (MetricTarget), обовʼязково

        target — визначає цільове значення для даної метрики.

        MetricTarget визначає цільове значення, середнє значення або середнє використання певної метрики.

        • metrics.external.target.type (string), обовʼязково

          type — представляє, чи є тип метрики Utilization, Value або AverageValue.

        • metrics.external.target.averageUtilization (int32)

          averageUtilization — це цільове значення середнього значення метрики ресурсу по всім відповідним Podʼам, представлене у відсотках від запитуваного значення ресурсу для Podʼів. Наразі дійсно лише для типу джерела метрики Resource.

        • metrics.external.target.averageValue (Quantity)

          averageValue — це цільове значення середнього значення метрики по всім відповідним Podʼам (як кількість).

        • metrics.external.target.value (Quantity)

          value – це цільове значення метрики (як кількість).

    • metrics.object (ObjectMetricSource)

      object — стосується метрики, що описує один обʼєкт Kubernetes (наприклад, кількість запитів на секунду на обʼєкті Ingress).

      ObjectMetricSource вказує, як масштабуватися на основі метрики, що описує обʼєкт Kubernetes (наприклад, кількість запитів на секунду на обʼєкті Ingress).

      • metrics.object.describedObject (CrossVersionObjectReference), обовʼязково

        describedObject визначає опис обʼєкта, такого як тип, імʼя та версія API.

        CrossVersionObjectReference містить достатньо інформації для ідентифікації відповідного ресурсу.

      • metrics.object.metric (MetricIdentifier), обовʼязково

        metric — визначає цільову метрику за назвою та селектором.

        MetricIdentifier визначає назву та, за потреби, селектор для метрики.

        • metrics.object.metric.name (string), обовʼязково

          name — це назва даної метрики.

        • metrics.object.metric.selector (LabelSelector)

          selector — це строкове кодування стандартного селектора міток Kubernetes для даної метрики. Якщо встановлено, він передається як додатковий параметр серверу метрик для більш специфічного вибору метрик. Якщо не встановлено, для збору метрик буде використовуватися лише назва метрики.

      • metrics.object.target (MetricTarget), обовʼязково

        target — визначає цільове значення для даної метрики.

        MetricTarget визначає цільове значення, середнє значення або середнє використання певної метрики.

        • metrics.object.target.type (string), обовʼязково

          type — представляє, чи є тип метрики Utilization, Value або AverageValue.

        • metrics.object.target.averageUtilization (int32)

          averageUtilization — цільове значення середнього значення метрики ресурсу по всім відповідним Podʼам, представлене у відсотках від запитуваного значення ресурсу для Podʼів. Наразі дійсно лише для типу джерела метрики Resource.

        • metrics.object.target.averageValue (Quantity)

          averageValue — цільове значення середнього значення метрики по всім відповідним Podʼам (як кількість).

        • metrics.object.target.value (Quantity)

          value — цільове значення метрики (як кількість).

    • metrics.pods (PodsMetricSource)

      pods — стосується метрики, що описує кожен Pod у поточному цільовому масштабі (наприклад, кількість транзакцій на секунду). Значення будуть усереднені перед порівнянням з цільовим значенням.

      PodsMetricSource вказує, як масштабуватися на основі метрики, що описує кожен Pod у поточному цільовому масштабі (наприклад, кількість транзакцій на секунду). Значення будуть усереднені перед порівнянням з цільовим значенням.

      • metrics.pods.metric (MetricIdentifier), обовʼязково

        metric — визначає цільову метрику за назвою та селектором.

        MetricIdentifier визначає назву та, за потреби, селектор для метрики.

        • metrics.pods.metric.name (string), обовʼязково

          name — це назва даної метрики.

        • metrics.pods.metric.selector (LabelSelector)

          selector — це строкове кодування стандартного селектора міток Kubernetes для даної метрики. Якщо встановлено, він передається як додатковий параметр серверу метрик для більш специфічного вибору метрик. Якщо не встановлено, для збору метрик буде використовуватися лише назва метрики.

      • metrics.pods.target (MetricTarget), обовʼязково

        target визначає цільове значення для даної метрики.

        MetricTarget визначає цільове значення, середнє значення або середнє використання певної метрики.

        • metrics.pods.target.type (string), обовʼязково

          type — представляє, чи є тип метрики Utilization, Value або AverageValue.

        • metrics.pods.target.averageUtilization (int32)

          averageUtilization — це цільове значення середнього значення метрики ресурсу по всім відповідним Podʼам, представлене у відсотках від запитуваного значення ресурсу для Podʼів. Наразі дійсно лише для типу джерела метрики Resource.

        • metrics.pods.target.averageValue (Quantity)

          averageValue — це цільове значення середнього значення метрики по всім відповідним Podʼам (як кількість).

        • metrics.pods.target.value (Quantity)

          value — це цільове значення метрики (як кількість).

    • metrics.resource (ResourceMetricSource)

      resource — стосується метрики ресурсу (наприклад, ті, що вказані в запитах і лімітах), відомої Kubernetes, яка описує кожен у поточному цільовому масштабі (наприклад, CPU або памʼять). Такі метрики вбудовані в Kubernetes і мають спеціальні параметри масштабування на додаток до тих, що доступні для звичайних метрик на кожен за допомогою джерела "pods".

      ResourceMetricSource вказує, як масштабуватися на основі метрики ресурсу, відомої Kubernetes, як вказано в запитах і лімітах, описуючи кожен у поточному цільовому масштабі (наприклад, CPU або памʼять). Значення будуть усереднені перед порівнянням з цільовим значенням. Такі метрики вбудовані в Kubernetes і мають спеціальні параметри масштабування на додаток до тих, що доступні для звичайних метрик на кожен под за допомогою джерела "pods". Повинен бути встановлений лише один тип "target".

      • metrics.resource.name (string), обовʼязково

        name — це назва ресурсу.

      • metrics.resource.target (MetricTarget), обовʼязково

        target — визначає цільове значення для даної метрики.

        MetricTarget визначає цільове значення, середнє значення або середнє використання певної метрики.

        • metrics.resource.target.type (string), обовʼязково

          type представляє, чи є тип метрики Utilization, Value або AverageValue.

        • metrics.resource.target.averageUtilization (int32)

          averageUtilization — це цільове значення середнього значення метрики ресурсу по всім відповідним Podʼам, представлене у відсотках від запитуваного значення ресурсу для Podʼів. Наразі дійсно лише для типу джерела метрики Resource.

        • metrics.resource.target.averageValue (Quantity)

          averageValue — це цільове значення середнього значення метрики по всім відповідним Podʼам (як кількість).

        • metrics.resource.target.value (Quantity)

          value —це цільове значення метрики (як кількість).

HorizontalPodAutoscalerStatus

HorizontalPodAutoscalerStatus описує поточний стан горизонтального автомасштабувальника Podʼів.


  • desiredReplicas (int32), обовʼязково

    desiredReplicas — це бажана кількість реплік Podʼів, якими керує цей автомасштабувальник, відповідно до останнього обчислення автомасштабувальника.

  • conditions ([]HorizontalPodAutoscalerCondition)

    Patch strategy: обʼєднання за ключем type

    Map: під час обʼєднання зберігатимуться унікальні значення за ключем type

    conditions — це набір станів, необхідних для масштабування цільового обʼєкта автомасштабувальником, та вказує, чи було їх досягнуто.

    HorizontalPodAutoscalerCondition описує стан HorizontalPodAutoscaler у певний момент часу.

    • conditions.status (string), обовʼязково

      status — це статус стану (True, False, Unknown)

    • conditions.type (string), обовʼязково

      type описує поточний стан

    • conditions.lastTransitionTime (Time)

      lastTransitionTime — це останній час, коли стан перейшла з одного стану в інший

      Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

    • conditions.message (string)

      message - це зрозуміле людині пояснення, що містить деталі про зміну стану

    • conditions.reason (string)

      reason — це причина останньї зміни стану.

  • currentMetrics ([]MetricStatus)

    Atomic: буде замінено під час обʼєднання

    currentMetrics — це останній прочитаний статус метрик, які використовує цей автомасштабувальник.

    MetricStatus описує останній прочитаний статус окремої метрики.

    • currentMetrics.type (string), обовʼязково

      type — це тип джерела метрики. Це буде один з "ContainerResource", "External", "Object", "Pods" або "Resource", кожен з яких відповідає відповідному полю в обʼєкті. Примітка: тип "ContainerResource" доступний лише за увімкненого прапора функції HPAContainerMetrics.

    • currentMetrics.containerResource (ContainerResourceMetricStatus)

      container resource стосується метрики ресурсу (такої як зазначено в запитах та обмеженнях), відомої Kubernetes, що описує окремий контейнер у кожному Podʼі в поточному цільовому масштабуванні (наприклад, CPU або памʼять). Такі метрики вбудовані в Kubernetes і мають спеціальні опції масштабування, окрім тих, що доступні для звичайних метрик на кожен Pod, використовуючи джерело "pods".

      ContainerResourceMetricStatus вказує поточне значення метрики ресурсу, відомої Kubernetes, як зазначено в запитах та обмеженнях, що описує окремий контейнер у кожному Podʼі в поточному цільовому масштабуванні (наприклад, CPU або памʼять). Такі метрики вбудовані в Kubernetes і мають спеціальні опції масштабування, окрім тих, що доступні для звичайних метрик на кожен Pod, використовуючи джерело "pods".

      • currentMetrics.containerResource.container (string), обовʼязково

        container — це імʼя контейнера в Podʼах цільового масштабування

      • currentMetrics.containerResource.current (MetricValueStatus), обовʼязково

        current — містить поточне значення для даної метрики

        MetricValueStatus містить поточне значення метрики

        • currentMetrics.containerResource.current.averageUtilization (int32)

          currentAverageUtilization — це поточне значення середнього використання метрики ресурсу серед усіх відповідних Podʼів, представлене у відсотках від запитаного значення ресурсу для Podʼів.

        • currentMetrics.containerResource.current.averageValue (Quantity)

          averageValue — це поточне середнє значення метрики серед усіх відповідних Podʼів (як кількість)

        • currentMetrics.containerResource.current.value (Quantity)

          value — це поточне значення метрики (як кількість).

      • currentMetrics.containerResource.name (string), обовʼязково

        name — це імʼя ресурсу, про який йдеться.

    • currentMetrics.external (ExternalMetricStatus)

      external стосується глобальної метрики, яка не повʼязана з жодним обʼєктом Kubernetes. Вона дозволяє автомасштабування на основі інформації, що надходить від компонентів, що працюють за межами кластера (наприклад, довжина черги у хмарному сервісі обміну повідомленнями або QPS від балансувальника навантаження, що працює за межами кластера).

      ExternalMetricStatus вказує поточне значення глобальної метрики, не повʼязаної з жодним обʼєктом Kubernetes.

      • currentMetrics.external.current (MetricValueStatus), обовʼязково

        current — містить поточне значення для даної метрики

        MetricValueStatus містить поточне значення метрики

        • currentMetrics.external.current.averageUtilization (int32)

          currentAverageUtilization — це поточне значення середнього використання метрики ресурсу серед усіх відповідних Podʼів, представлене у відсотках від запитаного значення ресурсу для Podʼів.

        • currentMetrics.external.current.averageValue (Quantity)

          averageValue — це поточне середнє значення метрики серед усіх відповідних Podʼів (як кількість)

        • currentMetrics.external.current.value (Quantity)

          value — це поточне значення метрики (як кількість).

      • currentMetrics.external.metric (MetricIdentifier), обовʼязково

        metric — ідентифікує цільову метрику за імʼям і селектором

        MetricIdentifier визначає імʼя та, за потреби, селектор для метрики

        • currentMetrics.external.metric.name (string), обовʼязково

          name — це імʼя даної метрики

        • currentMetrics.external.metric.selector (LabelSelector)

          selector — це строково-кодована форма стандартного селектора міток Kubernetes для даної метрики. Коли встановлено, він передається як додатковий параметр до сервера метрик для більш специфічного вибору метрик. Коли не встановлено, буде використано лише metricName для збору метрик.

    • currentMetrics.object (ObjectMetricStatus)

      object стосується метрики, що описує окремий обʼєкт Kubernetes (наприклад, кількість запитів на секунду для обʼєкта Ingress).

      ObjectMetricStatus вказує поточне значення метрики, що описує обʼєкт Kubernetes (наприклад, кількість запитів на секунду для обʼєкта Ingress).

      • currentMetrics.object.current (MetricValueStatus), обовʼязково

        current — містить поточне значення для даної метрики

        MetricValueStatus містить поточне значення метрики

        • currentMetrics.object.current.averageUtilization (int32)

          currentAverageUtilization — це поточне значення середнього використання метрики ресурсу серед усіх відповідних Podʼів, представлене у відсотках від запитаного значення ресурсу для Podʼів.

        • currentMetrics.object.current.averageValue (Quantity)

          averageValue — це поточне середнє значення метрики серед усіх відповідних Podʼів (як кількість)

        • currentMetrics.object.current.value (Quantity)

          value — це поточне значення метрики (як кількість).

      • currentMetrics.object.describedObject (CrossVersionObjectReference), обовʼязково

        DescribedObject вказує описи обʼєкта, такі як kind, name, apiVersion

        CrossVersionObjectReference містить достатньо інформації, щоб ідентифікувати вказаний ресурс.

      • currentMetrics.object.metric (MetricIdentifier), обовʼязково

        metric — ідентифікує цільову метрику за імʼям і селектором

        MetricIdentifier визначає імʼя та, за потреби, селектор для метрики

        • currentMetrics.object.metric.name (string), обовʼязково

          name — це імʼя даної метрики

        • currentMetrics.object.metric.selector (LabelSelector)

          selector — це строково-кодована форма стандартного селектора міток Kubernetes для даної метрики. Коли встановлено, він передається як додатковий параметр до сервера метрик для більш специфічного вибору метрик. Коли не встановлено, буде використано лише metricName для збору метрик.

    • currentMetrics.pods (PodsMetricStatus)

      pods — стосується метрики, що описує кожен Pod у поточному цільовому масштабуванні (наприклад, кількість оброблених транзакцій на секунду). Значення буде усереднено перед порівнянням з цільовим значенням.

      PodsMetricStatus вказує поточне значення метрики, що описує кожен Pod у поточному цільовому масштабуванні (наприклад, кількість оброблених транзакцій на секунду).

      • currentMetrics.pods.current (MetricValueStatus), обовʼязково

        current — містить поточне значення для даної метрики

        MetricValueStatus містить поточне значення метрики

        • currentMetrics.pods.current.averageUtilization (int32)

          currentAverageUtilization — це поточне значення середнього використання метрики ресурсу серед усіх відповідних Podʼів, представлене у відсотках від запитаного значення ресурсу для Podʼів.

        • currentMetrics.pods.current.averageValue (Quantity)

          averageValue — це поточне значення середньої метрики серед усіх відповідних Podʼів (як кількість)

        • currentMetrics.pods.current.value (Quantity)

          value — це поточне значення метрики (як кількість).

      • currentMetrics.pods.metric (MetricIdentifier), обовʼязково

        metric — ідентифікує цільову метрику за імʼям і селектором

        MetricIdentifier визначає імʼя та, за потреби, селектор для метрики

        • currentMetrics.pods.metric.name (string), обовʼязково

          name — це імʼя даної метрики

        • currentMetrics.pods.metric.selector (LabelSelector)

          selector — це строково-кодована форма стандартного селектора міток Kubernetes для даної метрики. Коли встановлено, він передається як додатковий параметр до сервера метрик для більш специфічного вибору метрик. Коли не встановлено, буде використано лише metricName для збору метрик.

    • currentMetrics.resource (ResourceMetricStatus)

      resource — стосується метрики ресурсу (такої як зазначено в запитах та обмеженнях), відомої Kubernetes, що описує кожен Pod у поточному цільовому масштабуванні (наприклад, CPU або памʼять). Такі метрики вбудовані в Kubernetes і мають спеціальні опції масштабування, окрім тих, що доступні для звичайних метрик на кожен Pod, використовуючи джерело "pods".

      ResourceMetricStatus вказує поточне значення метрики ресурсу, відомої Kubernetes, як зазначено в запитах та обмеженнях, що описує кожен Pod у поточному цільовому масштабуванні (наприклад, CPU або памʼять). Такі метрики вбудовані в Kubernetes і мають спеціальні опції масштабування, окрім тих, що доступні для звичайних метрик на кожен Pod, використовуючи джерело "pods".

      • currentMetrics.resource.current (MetricValueStatus), обовʼязково

        current містить поточне значення для даної метрики

        MetricValueStatus містить поточне значення метрики

        • currentMetrics.resource.current.averageUtilization (int32)

          currentAverageUtilization — це поточне значення середнього використання метрики ресурсу серед усіх відповідних Podʼів, представлене у відсотках від запитаного значення ресурсу для Podʼів.

        • currentMetrics.resource.current.averageValue (Quantity)

          averageValue — це поточне середнє значення метрики серед усіх відповідних Podʼів (як кількість)

        • currentMetrics.resource.current.value (Quantity)

          value — це поточне значення метрики (як кількість).

      • currentMetrics.resource.name (string), обовʼязково

        name — це імʼя ресурсу, про який йдеться.

  • currentReplicas (int32)

    currentReplicas — це поточна кількість реплік Podʼів, якими керує цей автомасштабувальник, як це було останній раз спостережено автомасштабувальником.

  • lastScaleTime (Time)

    lastScaleTime — це останній час, коли HorizontalPodAutoscaler масштабував кількість Podʼів, використовується автомасштабувальником для контролю частоти зміни кількості Podʼів.

    Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

  • observedGeneration (int64)

    observedGeneration — це останнє покоління, яке спостерігав цей автомасштабувальник.

HorizontalPodAutoscalerList

HorizontalPodAutoscalerList — це список обʼєктів горизонтального автомасштабувальника Podʼів.


  • apiVersion: autoscaling/v2

  • kind: HorizontalPodAutoscalerList

  • metadata (ListMeta)

    metadata — це стандартні метадані списку.

  • items ([]HorizontalPodAutoscaler), обовʼязково

    items — це список обʼєктів горизонтального автомасштабувальника Podʼів.

Операції


get отримати вказаний HorizontalPodAutoscaler

HTTP запит

GET /apis/autoscaling/v2/namespaces/{namespace}/horizontalpodautoscalers/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя HorizontalPodAutoscaler

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (HorizontalPodAutoscaler): OK

401: Unauthorized

get отримати статус вказаного HorizontalPodAutoscaler

HTTP запит

GET /apis/autoscaling/v2/namespaces/{namespace}/horizontalpodautoscalers/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя HorizontalPodAutoscaler

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (HorizontalPodAutoscaler): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу HorizontalPodAutoscaler

HTTP запит

GET /apis/autoscaling/v2/namespaces/{namespace}/horizontalpodautoscalers

Параметри

Відповідь

200 (HorizontalPodAutoscalerList): OK

401: Unauthorized

list перелік або перегляд за обʼєктів типу HorizontalPodAutoscaler

HTTP запит

GET /apis/autoscaling/v2/horizontalpodautoscalers

Параметри

Відповідь

200 (HorizontalPodAutoscalerList): OK

401: Unauthorized

create створення HorizontalPodAutoscaler

HTTP запит

POST /apis/autoscaling/v2/namespaces/{namespace}/horizontalpodautoscalers

Параметри

Відповідь

200 (HorizontalPodAutoscaler): OK

201 (HorizontalPodAutoscaler): Created

202 (HorizontalPodAutoscaler): Accepted

401: Unauthorized

update заміна вказаний HorizontalPodAutoscaler

HTTP запит

PUT /apis/autoscaling/v2/namespaces/{namespace}/horizontalpodautoscalers/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя HorizontalPodAutoscaler

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: HorizontalPodAutoscaler, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (HorizontalPodAutoscaler): OK

201 (HorizontalPodAutoscaler): Created

401: Unauthorized

update заміна статусу вказаного HorizontalPodAutoscaler

HTTP запит

PUT /apis/autoscaling/v2/namespaces/{namespace}/horizontalpodautoscalers/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя HorizontalPodAutoscaler

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: HorizontalPodAutoscaler, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (HorizontalPodAutoscaler): OK

201 (HorizontalPodAutoscaler): Created

401: Unauthorized

patch часткове оновлення вказаного HorizontalPodAutoscaler

HTTP запит

PATCH /apis/autoscaling/v2/namespaces/{namespace}/horizontalpodautoscalers/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя HorizontalPodAutoscaler

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (HorizontalPodAutoscaler): OK

201 (HorizontalPodAutoscaler): Created

401: Unauthorized

patch часткове оновлення статусу вказаного HorizontalPodAutoscaler

HTTP запит

PATCH /apis/autoscaling/v2/namespaces/{namespace}/horizontalpodautoscalers/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя HorizontalPodAutoscaler

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (HorizontalPodAutoscaler): OK

201 (HorizontalPodAutoscaler): Created

401: Unauthorized

delete видалення HorizontalPodAutoscaler

HTTP запит

DELETE /apis/autoscaling/v2/namespaces/{namespace}/horizontalpodautoscalers/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя HorizontalPodAutoscaler

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: deleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (HorizontalPodAutoscaler): OK

202 (HorizontalPodAutoscaler): Accepted

401: Unauthorized

deletecollection видалення колекції HorizontalPodAutoscaler

HTTP запит

DELETE /apis/autoscaling/v2/namespaces/{namespace}/horizontalpodautoscalers

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

6.5.1.14 - PriorityClass

PriorityClass визначає зіставлення імені класу пріоритету з цілим значенням пріоритету.

apiVersion: scheduling.k8s.io/v1

import "k8s.io/api/scheduling/v1"

PriorityClass

PriorityClass визначає зіставлення імені класу пріоритету з цілим значенням пріоритету.


  • apiVersion: scheduling.k8s.io/v1

  • kind: PriorityClass

  • metadata (ObjectMeta)

    Стандартні метадані обʼєкта. Додаткова інформація: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

  • value (int32), обовʼязково

    Представляє ціле значення цього класу пріоритету. Це фактичний пріоритет, який отримують Podʼи, коли вони мають імʼя цього класу у їхній специфікації.

  • description (string)

    Опис є довільним рядком, який зазвичай надає вказівки про те, коли слід використовувати цей клас пріоритету.

  • globalDefault (boolean)

    Визначає, чи слід вважати цей PriorityClass за стандартний пріоритет для Podʼів, які не мають жодного класу пріоритету. Може бути встановлено лише один PriorityClass як globalDefault. Однак, якщо існує більше одного PriorityClass з полем globalDefault, встановленим на true, то за стандартний пріоритет буде використовувати найменше значення серед таких глобальних пріоритетних класів.

  • preemptionPolicy (string)

    Політика для випередження Podʼів з нижчим пріоритетом. Один із варіантів: Never, PreemptLowerPriority. Стандартно використовується PreemptLowerPriority, якщо не встановлено жодного значення.

PriorityClassList


Операції


get отримати вказаний PriorityClass

HTTP запит

GET /apis/scheduling.k8s.io/v1/priorityclasses/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя PriorityClass

  • pretty (в запиті): string

    pretty

Відповідь

200 (PriorityClass): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу PriorityClass

HTTP запит

GET /apis/scheduling.k8s.io/v1/priorityclasses

Параметри

Відповідь

200 (PriorityClassList): OK

401: Unauthorized

create створення PriorityClass

HTTP запит

POST /apis/scheduling.k8s.io/v1/priorityclasses

Параметри

Відповідь

200 (PriorityClass): OK

201 (PriorityClass): Created

202 (PriorityClass): Accepted

401: Unauthorized

update заміна вказаного PriorityClass

HTTP запит

PUT /apis/scheduling.k8s.io/v1/priorityclasses/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя PriorityClass

  • body: PriorityClass, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (PriorityClass): OK

201 (PriorityClass): Created

401: Unauthorized

patch часткове оновлення вказаного PriorityClass

HTTP запит

PATCH /apis/scheduling.k8s.io/v1/priorityclasses/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя PriorityClass

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (PriorityClass): OK

201 (PriorityClass): Created

401: Unauthorized

delete видалення PriorityClass

HTTP запит

DELETE /apis/scheduling.k8s.io/v1/priorityclasses/{name}

Параметри

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції PriorityClass

HTTP запит

DELETE /apis/scheduling.k8s.io/v1/priorityclasses

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

6.5.1.15 - PodSchedulingContext v1alpha3

Обʼєкти PodSchedulingContext містять інформацію, необхідну для планування Pod з ResourceClaims, що використовують режим виділення "WaitForFirstConsumer".

apiVersion: resource.k8s.io/v1alpha3

import "k8s.io/api/resource/v1alpha3"

PodSchedulingContext

Обʼєкти PodSchedulingContext містять інформацію, необхідну для планування Pod з ResourceClaims, що використовують режим виділення "WaitForFirstConsumer".

Це тип альфа-версії та потребує включення функціональних можливостей DRAControlPlaneController.


  • apiVersion: resource.k8s.io/v1alpha3

  • kind: PodSchedulingContext

  • metadata (ObjectMeta)

    Метадані стандартного обʼєкта

  • spec (PodSchedulingContextSpec), обовʼязково

    Специфікація описує, де потрібні ресурси для Pod.

  • status (PodSchedulingContextStatus)

    Статус описує, де можуть бути виділені ресурси для Pod.

PodSchedulingContextSpec

PodSchedulingContextSpec описує, де потрібні ресурси для Pod.


  • potentialNodes ([]string)

    Atomic: буде замінено під час злиття

    PotentialNodes перелічує вузли, де можливий запуск Pod.

    Розмір цього поля обмежений 128. Цього достатньо для багатьох кластерів. В більших кластерах може знадобитися більше спроб для знаходження вузла, що відповідає всім очікуваним ресурсам. В майбутньому це обмеження може бути збільшено, але не зменшено.

  • selectedNode (string)

    SelectedNode — це вузол, для якого буде виконана спроба виділити ресурси, на які посилається Pod і які використовують виділення "WaitForFirstConsumer".

PodSchedulingContextStatus

PodSchedulingContextStatus описує, де можуть бути виділені ресурси для Pod.


  • resourceClaims ([]ResourceClaimSchedulingStatus)

    Map: унікальні значення за ключем будуть збережені під час обʼєднання

    ResourceClaims описує доступність ресурсів для кожного входження pod.spec.resourceClaims, де відповідний ResourceClaim використовує режим виділення "WaitForFirstConsumer".

    ResourceClaimSchedulingStatus містить інформацію про конкретний ResourceClaim з режимом виділення "WaitForFirstConsumer".

    • resourceClaims.name (string), обовʼязково

      Імʼя відповідає полю pod.spec.resourceClaims[*].Name.

    • resourceClaims.unsuitableNodes ([]string)

      Atomic: буде замінено під час злиття

      UnsuitableNodes перелічує вузли, для яких ResourceClaim не може бути виділено.

      Розмір цього поля обмежений 128, так само як і для PodSchedulingSpec.PotentialNodes. Це обмеження може бути збільшено в майбутньому, але не зменшено.

PodSchedulingContextList

PodSchedulingContextList є колекцією обʼєктів планування Pod.


  • apiVersion: resource.k8s.io/v1alpha3

  • kind: PodSchedulingContextList

  • metadata (ListMeta)

    Стандартні метадані списку

  • items ([]PodSchedulingContext), обовʼязково

    Items — це список обʼєктів PodSchedulingContext.

Операції


get отримати вказаний PodSchedulingContext

HTTP запит

GET /apis/resource.k8s.io/v1alpha3/namespaces/{namespace}/podschedulingcontexts/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя контексту планування для Pod

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (PodSchedulingContext): OK

401: Unauthorized

get отримати статус вказаного PodSchedulingContext

HTTP запит

GET /apis/resource.k8s.io/v1alpha3/namespaces/{namespace}/podschedulingcontexts/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя контексту планування для Pod

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (PodSchedulingContext): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу PodSchedulingContext

HTTP запит

GET /apis/resource.k8s.io/v1alpha3/namespaces/{namespace}/podschedulingcontexts

Параметри

Відповідь

200 (PodSchedulingContextList): OK

401: Unauthorized

list список або перегляд обʼєктів типу PodSchedulingContext

HTTP запит

GET /apis/resource.k8s.io/v1alpha3/podschedulingcontexts

Параметри

Відповідь

200 (PodSchedulingContextList): OK

401: Unauthorized

create створення PodSchedulingContext

HTTP запит

POST /apis/resource.k8s.io/v1alpha3/namespaces/{namespace}/podschedulingcontexts

Параметри

Відповідь

200 (PodSchedulingContext): OK

201 (PodSchedulingContext): Created

202 (PodSchedulingContext): Accepted

401: Unauthorized

update заміна вказаного PodSchedulingContext

HTTP запит

PUT /apis/resource.k8s.io/v1alpha3/namespaces/{namespace}/podschedulingcontexts/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя контексту планування для Pod

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: PodSchedulingContext, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (PodSchedulingContext): OK

201 (PodSchedulingContext): Created

401: Unauthorized

update заміна статусус вказаного PodSchedulingContext

HTTP запит

PUT /apis/resource.k8s.io/v1alpha3/namespaces/{namespace}/podschedulingcontexts/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    назва the PodSchedulingContext

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: PodSchedulingContext, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (PodSchedulingContext): OK

201 (PodSchedulingContext): Created

401: Unauthorized

patch часткове оновлення вказаного PodSchedulingContext

HTTP запит

PATCH /apis/resource.k8s.io/v1alpha3/namespaces/{namespace}/podschedulingcontexts/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя контексту планування для Pod

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: PodSchedulingContext, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (PodSchedulingContext): OK

401: Unauthorized

patch часткове оновлення статусу вказаного PodSchedulingContext

HTTP запит

PATCH /apis/resource.k8s.io/v1alpha3/namespaces/{namespace}/podschedulingcontexts/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    назва the PodSchedulingContext

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (PodSchedulingContext): OK

201 (PodSchedulingContext): Created

401: Unauthorized

delete видалення PodSchedulingContext

HTTP запит

DELETE /apis/resource.k8s.io/v1alpha3/namespaces/{namespace}/podschedulingcontexts/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя PodSchedulingContext

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (PodSchedulingContext): OK

202 (PodSchedulingContext): Accepted

401: Unauthorized

deletecollection видалення колекції PodSchedulingContext

HTTP запит

DELETE /apis/resource.k8s.io/v1alpha3/namespaces/{namespace}/podschedulingcontexts

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

6.5.1.16 - ResourceClaim v1alpha3

ResourceClaim описує запит на доступ до ресурсів у кластері для використання робочими навантаженнями.

apiVersion: resource.k8s.io/v1alpha3

import "k8s.io/api/resource/v1alpha3"

ResourceClaim

ResourceClaim описує запит на доступ до ресурсів у кластері, для використання робочими навантаженнями. Наприклад, якщо робоче навантаження потребує пристрою-акселератора з конкретними властивостями, ось як виражається цей запит. Розділ статусу відстежує, чи було задоволено цей запит і які саме ресурси були виділені.

Це альфа-тип і потребує увімкнення функціональної можливості DynamicResourceAllocation.


  • apiVersion: resource.k8s.io/v1alpha3

  • kind: ResourceClaim

  • metadata (ObjectMeta)

    Стандартні метадані обʼєкта

  • spec (ResourceClaimSpec), обовʼязково

    Spec описує, що запитується і як це налаштувати. Специфікація є незмінною.

  • status (ResourceClaimStatus)

    Status описує, чи заявка готова до використання і що було виділено.

ResourceClaimSpec

ResourceClaimSpec визначає, що запитується в ResourceClaim і як це налаштувати.


  • controller (string)

    Controller — це імʼя драйвера DRA, який призначений для обробки розподілу цієї заявки. Якщо поле порожнє, розподіл обробляється планувальником під час планування podʼа.

    Має бути піддоменом DNS і закінчуватися доменом DNS, що належить постачальнику драйвера.

    Це альфа-поле і вимагає активації функціональної можливості DRAControlPlaneController.

  • devices (DeviceClaim)

    Devices визначає як запитувати пристрої.

    DeviceClaim визначає, як запитувати пристрої за допомогою ResourceClaim.

    • devices.config ([]DeviceClaimConfiguration)

      Atomic: буде замінено під час злиття

      Це поле містить конфігурацію для декількох потенційних драйверів, які можуть задовольнити запити у цій заявці. Воно ігнорується під час призначення заявки.

      DeviceClaimConfiguration використовується для параметрів конфігурації у DeviceClaim.

      • devices.config.opaque (OpaqueDeviceConfiguration)

        Opaque надає специфічні для драйвера параметри конфігурації.

        OpaqueDeviceConfiguration містить параметри конфігурації драйвера у форматі, визначеному постачальником драйвера.

        • devices.config.opaque.driver (string), обовʼязково

          Драйвер використовується для визначення того, якому втулку kubelet потрібно передати ці конфігураційні параметри.

          Політика допуску, надана розробником драйвера, може використовувати цей параметр, щоб вирішити, чи потрібно їх перевіряти.

          Має бути субдоменом DNS і закінчуватися на DNS-домені, що належить постачальнику драйвера.

        • devices.config.opaque.parameters (RawExtension), обовʼязково

          Параметри можуть містити довільні дані. Відповідальність за перевірку та керування версіями покладається на розробника драйверів. Зазвичай це включає самоідентифікацію та версію ("kind" + "apiVersion" для типів Kubernetes), а також конвертацію між різними версіями.

          RawExtension використовується для зберігання розширень у зовнішніх версіях.

          Щоб використовувати це, створіть поле, яке має тип RawExtension у вашій зовнішній, версійованій структурі, і Object у вашій внутрішній структурі. Також потрібно зареєструвати ваші різні типи втулків.

          // Внутрішній пакунок:

          type MyAPIObject struct {
            runtime.TypeMeta `json:",inline"`
            MyPlugin runtime.Object `json:"myPlugin"`
          }
          
          type PluginA struct {
            AOption string `json:"aOption"`
          }
          

          // Зовнішній пакунок:

          type MyAPIObject struct {
            runtime.TypeMeta `json:",inline"`
            MyPlugin runtime.RawExtension `json:"myPlugin"`
          }
          
          type PluginA struct {
            AOption string `json:"aOption"`
          }
          

          // Готовий JSON буде виглядати приблизно так:

          {
            "kind":"MyAPIObject",
            "apiVersion":"v1",
            "myPlugin": {
              "kind":"PluginA",
              "aOption":"foo",
            },
          }
          

          Що відбувається? Спочатку декодування використовує json або yaml для десеріалізації даних у ваш зовнішній MyAPIObject. Це призводить до зберігання необробленого JSON, але без розпакування. Наступний крок — копіювання (за допомогою pkg/conversion) у внутрішню структуру. Функції перетворення, встановлені в DefaultScheme пакета runtime, розпаковують JSON, збережений у RawExtension, перетворюючи його в правильний тип обʼєкта і зберігаючи його в Object. (TODO: У випадку, коли обʼєкт має невідомий тип, буде створено і збережено обʼєкт runtime.Unknown.)

      • devices.config.requests ([]string)

        Atomic: буде замінено під час злиття

        Requests перераховує назви запитів, до яких застосовується конфігурація. Якщо поле порожнє, конфігурація застосовується до всіх запитів.

    • devices.constraints ([]DeviceConstraint)

      Atomic: буде замінено під час злиття

      Ці обмеження повинні задовольнятися набором пристроїв, які виділяються для заявки.

      DeviceConstraint повинен мати рівно одне поле, крім Requests.

      • devices.constraints.matchAttribute (string)

        MatchAttribute вимагає, щоб усі пристрої, про які йдеться, мали цей атрибуту, а його тип і значення були однаковими для всіх цих пристроїв.

        Наприклад, якщо ви вказали "dra.example.com/numa" (гіпотетичний приклад!), то будуть обрані лише пристрої в одному й тому самому NUMA-вузлі. Пристрій, який не має цього атрибуту, не буде обраний. Усі пристрої повинні використовувати значення одного типу для цього атрибуту, оскільки це є частиною його специфікації, але якщо якийсь пристрій цього не робить, він також не буде обраний.

        Має включати доменний кваліфікатор.

      • devices.constraints.requests ([]string)

        Atomic: буде замінено під час злиття

        Requests — це список з одного або більше запитів у цій заявці, які мають спільно задовольняти цю умову. Якщо запит виконується кількома пристроями, то всі пристрої повинні відповідати цій умові. Якщо це не вказано, ця умова застосовується до всіх запитів у заявці.

    • devices.requests ([]DeviceRequest)

      Atomic: буде замінено під час злиття

      Requests представляють індивідуальні запити на окремі пристрої, які мають бути задоволені. Якщо список порожній, то не потрібно виділяти жодних ресурсів.

      DeviceRequest — це запит на пристрої, необхідні для заявки. Зазвичай це запит на один ресурс, такий як пристрій, але також може включати запит на кілька однакових пристроїв.

      Поле DeviceClassName наразі є обов’язковим. Клієнти повинні перевірити, чи воно дійсно встановлене. Його відсутність свідчить про зміни, які ще не підтримуються клієнтом, і в такому випадку клієнт повинен відмовитися від обробки запиту.

      • devices.requests.deviceClassName (string), обовʼязково

        DeviceClassName посилається на конкретний DeviceClass, який може визначати додаткові налаштування та селектори, що будуть успадковані цим запитом.

        Клас є обов’язковим. Доступність класів залежить від кластера.

        Адміністратори можуть використовувати це, щоб обмежити доступні для запитів пристрої, встановлюючи класи лише з селекторами для дозволених пристроїв. Якщо користувачі можуть вільно запитувати будь-що без обмежень, адміністратори можуть створити порожній DeviceClass для використання користувачами.

      • devices.requests.name (string), обовʼязково

        Name може бути використане для посилання на цей запит у записі pod.spec.containers[].resources.claims та в умові заявки.

        Має бути міткою DNS.

      • devices.requests.adminAccess (boolean)

        AdminAccess вказує, що це заявка на адміністративний доступ до пристрою(їв). Заявки з AdminAccess очікується використовувати для моніторингу або інших сервісів управління пристроєм. Вони ігнорують усі звичайні заявки на пристрій щодо режимів доступу та будь-яких розподілів ресурсів.

      • devices.requests.allocationMode (string)

        AllocationMode та пов’язані з ним поля визначають, як пристрої виділяються для виконання цього запиту. Підтримувані значення:

        • ExactCount: Цей запит на конкретну кількість пристроїв. Це значення використовується стандартно. Точна кількість вказується в полі count.

        • All: Цей запит на всі пристрої, що відповідають умовам, у пулі. Виділення не вдасться, якщо деякі пристрої вже виділені, за винятком випадків, коли запитується adminAccess.

        Якщо AllocationMode не вказано, стандатний режим — ExactCount. Якщо режим — ExactCount і кількість не вказана, стандартна кількість один. Будь-які інші запити повинні вказати це поле.

        Можуть бути додані нові режими в майбутньому. Клієнти повинні відмовитися від обробки запитів із невідомими режимами.

      • devices.requests.count (int64)

        Поле Count використовується лише тоді, коли режим підрахунку — "ExactCount". Має бути більше нуля. Якщо AllocationMode встановлено як ExactCount і це поле не вказано, стандартне значення — один.

      • devices.requests.selectors ([]DeviceSelector)

        Atomic: буде замінено під час злиття

        Селектори визначають критерії, які має задовольнити конкретний пристрій, щоб він був розглянутий для цього запиту. Усі селектори повинні бути виконані, щоб пристрій був прийнятий до розгляду.

        DeviceSelector повинен мати рівно одне встановлене поле.

        • devices.requests.selectors.cel (CELDeviceSelector)

          CEL містить вираз CEL для вибору пристрою.

          CELDeviceSelector містить CEL-вираз для вибору пристрою.

          • devices.requests.selectors.cel.expression (string), обовʼязково

            Вираз є виразом CEL, який оцінює один пристрій. Він має оцінюватися як true, коли пристрій відповідає бажаним критеріям, і як false, коли не відповідає. Будь-який інший результат є помилкою і призводить до зупинки надання пристроїв.

            Вхідні дані виразу — це обʼєкт з назвою "device", який має наступні властивості:

            • driver (рядок): імʼя драйвера, який визначає цей пристрій.
            • attributes (map[string]object): атрибути пристрою, згруповані за префіксом (наприклад, device.attributes["dra.example.com"] оцінюється як обʼєкт з усіма атрибутами, які були префіксовані "dra.example.com").
            • capacity (map[string]object): обсяги пристрою, згруповані за префіксом.

            Приклад: Розглянемо пристрій з driver="dra.example.com", який надає два атрибути з назвою "model" та "ext.example.com/family" і один обсяг з назвою "modules". Вхідні дані для цього виразу будуть мати такі поля:

            device.driver
            device.attributes["dra.example.com"].model
            device.attributes["ext.example.com"].family
            device.capacity["dra.example.com"].modules
            

            Поле device.driver можна використовувати для перевірки конкретного драйвера, або як загальну попередню умову (тобто ви хочете розглядати лише пристрої від цього драйвера), або як частину виразу з кількома умовами, який призначений для розгляду пристроїв з різних драйверів.

            Тип значення кожного атрибута визначається визначенням пристрою, і користувачі, які пишуть ці вирази, повинні звертатися до документації для своїх конкретних драйверів. Тип значення кожного обсягу — Quantity.

            Якщо невідомий префікс використовується для запиту в device.attributes або device.capacity, буде повернено порожній map. Будь-яке посилання на невідоме поле спричинить помилку оцінки і зупинку виділення.

            Робочий вираз має перевіряти наявність атрибутів перед їх використанням.

            Для зручності використання доступна функція cel.bind(), яка може бути використана для спрощення виразів, що звертаються до кількох атрибутів з одного домену. Наприклад:

            cel.bind(dra, device.attributes["dra.example.com"], dra.someBool && dra.anotherBool)
            

ResourceClaimStatus

ResourceClaimStatus відстежує, чи було виділено ресурс і яким був результат.


  • allocation (AllocationResult)

    Allocation встановлюється після успішного розподілу заявки.

    AllocationResult містить атрибути виділеного ресурсу.

    • allocation.controller (string)

      controller — це імʼя драйвера DRA, який обробив виділення. Цей драйвер також відповідає за деалокацію заявки. Воно порожнє, коли заявку можна деалокувати без залучення драйвера.

      Драйвер може виділяти пристрої, надані іншими драйверами, тому імʼя цього драйвера може відрізнятися від імен драйверів, зазначених у результатах.

      Це альфа-поле і вимагає активації функціональної можливості DRAControlPlaneController.

    • allocation.devices (DeviceAllocationResult)

      Devices є результатом виділення пристроїів.

      DeviceAllocationResult — результат виділення пристроїв.

      • allocation.devices.config ([]DeviceAllocationConfiguration)

        Atomic: буде замінено під час злиття

        Це поле є комбінацією всіх параметрів конфігурації заявки та класу. Драйвери можуть розрізняти ці параметри за допомогою прапорця.

        Воно включає параметри конфігурації для драйверів, які не мають виділених пристроїв у результаті, оскільки драйвери самостійно визначають, які параметри конфігурації вони підтримують. Вони можуть мовчки ігнорувати невідомі параметри конфігурації.

        DeviceAllocationConfiguration gets embedded in an AllocationResult.

        • allocation.devices.config.source (string), обовʼязково

          Source вказує, чи конфігурація походить з класу і, отже, не є чимось, що звичайний користувач міг би встановити, чи з заявки.

        • allocation.devices.config.opaque (OpaqueDeviceConfiguration)

          Opaque надає специфічні для драйвера параметри конфігурації.

          OpaqueDeviceConfiguration містить параметри конфігурації драйвера у форматі, визначеному постачальником драйвера.

          • allocation.devices.config.opaque.driver (string), обовʼязково

            Драйвер використовується для визначення того, якому втулку kubelet потрібно передати ці конфігураційні параметри.

            Політика допуску, надана розробником драйвера, може використовувати цей параметр, щоб вирішити, чи потрібно їх перевіряти.

            Має бути субдоменом DNS і закінчуватися на DNS-домені, що належить постачальнику драйвера.

          • allocation.devices.config.opaque.parameters (RawExtension), обовʼязково

            Параметри можуть містити довільні дані. Відповідальність за перевірку та керування версіями покладається на розробника драйверів. Зазвичай це включає самоідентифікацію та версію ("kind" + "apiVersion" для типів Kubernetes), а також конвертацію між різними версіями.

            RawExtension використовується для зберігання розширень у зовнішніх версіях.

            Щоб використовувати це, створіть поле, яке має тип RawExtension у вашій зовнішній, версійованій структурі, і Object у вашій внутрішній структурі. Також потрібно зареєструвати ваші різні типи втулків.

            // Внутрішній пакунок:

            type MyAPIObject struct {
              runtime.TypeMeta `json:",inline"`
              MyPlugin runtime.Object `json:"myPlugin"`
            }
            
            type PluginA struct {
              AOption string `json:"aOption"`
            }
            

            // Зовнішній пакунок:

            type MyAPIObject struct {
              runtime.TypeMeta `json:",inline"`
              MyPlugin runtime.RawExtension `json:"myPlugin"`
            }
            
            type PluginA struct {
              AOption string `json:"aOption"`
            }
            

            // Готовий JSON буде виглядати приблизно так:

            {
              "kind":"MyAPIObject",
              "apiVersion":"v1",
              "myPlugin": {
                "kind":"PluginA",
                "aOption":"foo",
              },
            }
            

            Що відбувається? Спочатку декодування використовує json або yaml для десеріалізації даних у ваш зовнішній MyAPIObject. Це призводить до зберігання необробленого JSON, але без розпакування. Наступний крок — копіювання (за допомогою pkg/conversion) у внутрішню структуру. Функції перетворення, встановлені в DefaultScheme пакета runtime, розпаковують JSON, збережений у RawExtension, перетворюючи його в правильний тип обʼєкта і зберігаючи його в Object. (TODO: У випадку, коли обʼєкт має невідомий тип, буде створено і збережено обʼєкт runtime.Unknown.)

        • allocation.devices.config.requests ([]string)

          Atomic: буде замінено під час злиття

          Requests перераховує назви запитів, до яких застосовується конфігурація. Якщо поле порожнє, конфігурація застосовується до всіх запитів.

      • allocation.devices.results ([]DeviceRequestAllocationResult)

        Atomic: буде замінено під час злиття

        Results — перелік віділених пристроїв.

        DeviceRequestAllocationResult містить результат розподілу для одного запиту.

        • allocation.devices.results.device (string), обовʼязково

          Device посилається на один екземпляр пристрою за його імʼям в ресурсному пулі драйвера. Має бути міткою DNS.

        • allocation.devices.results.driver (string), обовʼязково

          Driver вказує імʼя драйвера DRA, чий втулок kubelet слід викликати для обробки виділення, коли заявка потрібна на вузлі.

          Має бути піддоменом DNS і закінчуватися доменом DNS, що належить постачальнику драйвера.

        • allocation.devices.results.pool (string), обовʼязково

          Це імʼя разом з імʼям драйвера та полем імені пристрою ідентифікує, який пристрій був виділений (\<імʼя драйвера>/\<імʼя пулу>/\<імʼя пристрою>).

          Не повинно перевищувати 253 символи і може містити один або більше піддоменів DNS, розділених косими рисками.

        • allocation.devices.results.request (string), обовʼязково

          Request — це імʼя запиту в заявці, який спричинив виділення цього пристрою. Для одного запиту може бути виділено кілька пристроїв.

    • allocation.nodeSelector (NodeSelector)

      NodeSelector визначає, де доступні виділені ресурси. Якщо не встановлено, ресурси доступні скрізь.

      Селектор вузлів представляє об'єднання результатів одного або кількох запитів міток над набором вузлів; тобто, він представляє логічне OR селекторів, які представлені термінами селектора вузлів.

      • allocation.nodeSelector.nodeSelectorTerms ([]NodeSelectorTerm), обовʼязково

        Atomic: буде замінено під час злиття

        Обов’язкове поле. Список термінів селектора вузлів. Термінів застосовується логічне OR.

        Null або порожній термін селектора вузла не відповідає жодному об'єкту. Вимоги до них складаються за принципом AND. Тип TopologySelectorTerm реалізує підмножину NodeSelectorTerm.

        • allocation.nodeSelector.nodeSelectorTerms.matchExpressions ([]NodeSelectorRequirement)

          Atomic: буде замінено під час злиття

          Список вимог селектора вузлів за мітками вузлів.

        • allocation.nodeSelector.nodeSelectorTerms.matchFields ([]NodeSelectorRequirement)

          Atomic: буде замінено під час злиття

          Список вимог селектора вузлів за полями вузлів.

  • deallocationRequested (boolean)

    Вказує на те, що заявку потрібно деалокувати. Поки це поле встановлене, нові споживачі не можуть бути додані до ReservedFor.

    Використовується лише у випадках, коли заявку потрібно деалокувати за допомогою драйвера DRA. Цей драйвер повинен деалокувати заявку та скинути це поле разом із очищенням поля Allocation.

    Це альфа-поле і вимагає активації функціональної можливості DRAControlPlaneController.

  • reservedFor ([]ResourceClaimConsumerReference)

    Patch strategy: злиття за ключем uid

    Map: унікальні значення ключа uid будуть збережені під час злиття

    ReservedFor вказує, які сутності в даний момент можуть використовувати заявку. Pod, який посилається на ResourceClaim, що не зарезервована для цього Podʼа, не буде запущений. Заявка, яка використовується або може бути використана, оскільки вона зарезервована, не повинна бути деалокована.

    У кластері з кількома екземплярами планувальника два podʼи можуть бути заплановані одночасно різними планувальниками. Коли вони посилаються на один і той же ResourceClaim, який вже досяг максимального числа споживачів, лише один pod може бути запланований.

    Обидва планувальники намагаються додати свій pod до поля claim.status.reservedFor, але лише оновлення, яке досягає API-сервера першим, зберігається. Інше оновлення зазнає помилки, і планувальник, який його надіслав, знає, що потрібно повернути pod у чергу, чекаючи, поки ResourceClaim знову стане доступним.

    Може бути не більше 32 таких резервувань. Це число може бути збільшено в майбутньому, але не зменшено.

    ResourceClaimConsumerReference містить достатньо інформації, щоб знайти споживача ResourceClaim. Користувач має бути ресурсом в тому ж просторі імен, що і ResourceClaim.

    • reservedFor.name (string), обовʼязково

      Name — це імʼя ресурсу, на який посилаються.

    • reservedFor.resource (string), обовʼязково

      Resource — це тип ресурсу, на який посилаються, наприклад, "pods".

    • reservedFor.uid (string), обовʼязково

      UID ідентифікує саме одну інкарнацію ресурсу.

    • reservedFor.apiGroup (string)

      APIGroup — це група для ресурсу, на який посилаються. Вона порожня для основного API. Це відповідає групі в APIVersion, яка використовується при створенні ресурсів.

ResourceClaimList

ResourceClaimList — це колекція заявок.


  • apiVersion: resource.k8s.io/v1alpha3

  • kind: ResourceClaimList

  • metadata (ListMeta)

    Стандартні метадані списку

  • items ([]ResourceClaim), обовʼязково

    Items — це список вимог на ресурси.

Операції


get отримати вказаний ResourceClaim

HTTP запит

GET /apis/resource.k8s.io/v1alpha3/namespaces/{namespace}/resourceclaims/{name}

Параметри

  • name (в шляху): string, обовʼязково

    name of the ResourceClaim

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (ResourceClaim): OK

401: Unauthorized

get отримати статус вказаного ResourceClaim

HTTP запит

GET /apis/resource.k8s.io/v1alpha3/namespaces/{namespace}/resourceclaims/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    name of the ResourceClaim

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (ResourceClaim): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу ResourceClaim

HTTP запит

GET /apis/resource.k8s.io/v1alpha3/namespaces/{namespace}/resourceclaims

Параметри

Відповідь

200 (ResourceClaimList): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу ResourceClaim

HTTP запит

GET /apis/resource.k8s.io/v1alpha3/resourceclaims

Параметри

Відповідь

200 (ResourceClaimList): OK

401: Unauthorized

create створення ResourceClaim

HTTP запит

POST /apis/resource.k8s.io/v1alpha3/namespaces/{namespace}/resourceclaims

Параметри

Відповідь

200 (ResourceClaim): OK

201 (ResourceClaim): Created

202 (ResourceClaim): Accepted

401: Unauthorized

update заміна вказаного ResourceClaim

HTTP запит

PUT /apis/resource.k8s.io/v1alpha3/namespaces/{namespace}/resourceclaims/{name}

Параметри

  • name (в шляху): string, обовʼязково

    name of the ResourceClaim

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: ResourceClaim, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (ResourceClaim): OK

201 (ResourceClaim): Created

401: Unauthorized

update заміна статусу вказаного ResourceClaim

HTTP запит

PUT /apis/resource.k8s.io/v1alpha3/namespaces/{namespace}/resourceclaims/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    name of the ResourceClaim

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: ResourceClaim, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (ResourceClaim): OK

201 (ResourceClaim): Created

401: Unauthorized

patch часткове оновлення вказаного ResourceClaim

HTTP запит

PATCH /apis/resource.k8s.io/v1alpha3/namespaces/{namespace}/resourceclaims/{name}

Параметри

  • name (в шляху): string, обовʼязково

    name of the ResourceClaim

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (ResourceClaim): OK

201 (ResourceClaim): Created

401: Unauthorized

patch часткове оновлення статусу вказаного ResourceClaim

HTTP запит

PATCH /apis/resource.k8s.io/v1alpha3/namespaces/{namespace}/resourceclaims/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    name of the ResourceClaim

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (ResourceClaim): OK

201 (ResourceClaim): Created

401: Unauthorized

delete видалення ResourceClaim

HTTP запит

DELETE /apis/resource.k8s.io/v1alpha3/namespaces/{namespace}/resourceclaims/{name}

Параметри

  • name (в шляху): string, обовʼязково

    name of the ResourceClaim

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (ResourceClaim): OK

202 (ResourceClaim): Accepted

401: Unauthorized

deletecollection видалення of ResourceClaim

HTTP запит

DELETE /apis/resource.k8s.io/v1alpha3/namespaces/{namespace}/resourceclaims

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

6.5.1.17 - ResourceClaimTemplate v1alpha3

ResourceClaimTemplate використовується для створення обʼєктів ResourceClaim.

apiVersion: resource.k8s.io/v1alpha3

import "k8s.io/api/resource/v1alpha3"

ResourceClaimTemplate

ResourceClaimTemplate використовується для створення обʼєктів ResourceClaim.

Це альфа-тип і вимагає увімкнення функціональної можливості DynamicResourceAllocation.


  • apiVersion: resource.k8s.io/v1alpha3

  • kind: ResourceClaimTemplate

  • metadata (ObjectMeta)

    Стандартні метадані обʼєкта.

  • spec (ResourceClaimTemplateSpec), обовʼязково

    Описує ResourceClaim, який буде створений.

ResourceClaimTemplateSpec

ResourceClaimTemplateSpec містить метадані та поля для ResourceClaim.


  • spec (ResourceClaimSpec), обовʼязково

    Специфікація для ResourceClaim. Весь вміст копіюється без змін в ResourceClaim, який створюється з цього шаблону. Ті ж самі поля, що й в ResourceClaim, є дійсними тут.

  • metadata (ObjectMeta)

    ObjectMeta може містити мітки та анотації, які будуть скопійовані до PVC при створенні його. Інші поля не дозволені і будуть відхилені під час перевірки на валідність.

ResourceClaimTemplateList

ResourceClaimTemplateList є колекцією шаблонів заявок.


  • apiVersion: resource.k8s.io/v1alpha3

  • kind: ResourceClaimTemplateList

  • metadata (ListMeta)

    Стандартні метадані списку.

  • items ([]ResourceClaimTemplate), обовʼязково

    Список шаблонів заявок на ресурси.

Операції


get отримати вказаний ResourceClaimTemplate

HTTP запит

GET /apis/resource.k8s.io/v1alpha3/namespaces/{namespace}/resourceclaimtemplates/{name}

Параметри

  • name (в шляху): string, обовʼязково

    Назва шаблону ResourceClaimTemplate

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (ResourceClaimTemplate): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу ResourceClaimTemplate

HTTP запит

GET /apis/resource.k8s.io/v1alpha3/namespaces/{namespace}/resourceclaimtemplates

Параметри

Відповідь

200 (ResourceClaimTemplateList): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу ResourceClaimTemplate

HTTP запит

GET /apis/resource.k8s.io/v1alpha3/resourceclaimtemplates

Параметри

Відповідь

200 (ResourceClaimTemplateList): OK

401: Unauthorized

create створення ResourceClaimTemplate

HTTP запит

POST /apis/resource.k8s.io/v1alpha3/namespaces/{namespace}/resourceclaimtemplates

Параметри

Відповідь

200 (ResourceClaimTemplate): OK

201 (ResourceClaimTemplate): Created

202 (ResourceClaimTemplate): Accepted

401: Unauthorized

update заміна вказаного ResourceClaimTemplate

HTTP запит

PUT /apis/resource.k8s.io/v1alpha3/namespaces/{namespace}/resourceclaimtemplates/{name}

Параметри

  • name (в шляху): string, обовʼязково

    Назва шаблону ResourceClaimTemplate

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: ResourceClaimTemplate, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (ResourceClaimTemplate): OK

201 (ResourceClaimTemplate): Created

401: Unauthorized

patch часткове оновлення вказаного ResourceClaimTemplate

HTTP запит

PATCH /apis/resource.k8s.io/v1alpha3/namespaces/{namespace}/resourceclaimtemplates/{name}

Параметри

  • name (в шляху): string, обовʼязково

    Назва шаблону ResourceClaimTemplate

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (ResourceClaimTemplate): OK

201 (ResourceClaimTemplate): Created

401: Unauthorized

delete видалення ResourceClaimTemplate

HTTP запит

DELETE /apis/resource.k8s.io/v1alpha3/namespaces/{namespace}/resourceclaimtemplates/{name}

Параметри

  • name (в шляху): string, обовʼязково

    Назва шаблону ResourceClaimTemplate

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (ResourceClaimTemplate): OK

202 (ResourceClaimTemplate): Accepted

401: Unauthorized

deletecollection видалення колекції ResourceClaimTemplate

HTTP запит

DELETE /apis/resource.k8s.io/v1alpha3/namespaces/{namespace}/resourceclaimtemplates

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

6.5.1.18 - ResourceSlice v1alpha3

ResourceSlice представляє один або декілька ресурсів у пулі подібних ресурсів, керованих спільним драйвером.

apiVersion: resource.k8s.io/v1alpha3

import "k8s.io/api/resource/v1alpha3"

ResourceSlice

ResourceSlice представляє один або кілька ресурсів у пулі подібних ресурсів, що управляються спільним драйвером. Пул може охоплювати більше ніж один ResourceSlice, і точна кількість ResourceSlices, що складають пул, визначається драйвером.

Наразі підтримуються лише пристрої з атрибутами та ємностями (capacities). Кожен пристрій у певному пулі, незалежно від кількості ResourceSlices, повинен мати унікальне імʼя. ResourceSlice, в якому пристрій публікується, може змінюватися з часом. Унікальний ідентифікатор для пристрою — це кортеж <імʼя драйвера>, <імʼя пулу>, <імʼя пристрою>.

Щоразу, коли драйверу потрібно оновити пул, він інкрементує номер pool.Spec.Pool.Generation і оновлює всі ResourceSlices з новим номером і новими визначеннями ресурсів. Споживач повинен використовувати лише ResourceSlices з найвищим номером покоління та ігнорувати всі інші.

При виділенні всіх ресурсів в пулі, що відповідають певним критеріям, або при пошуку найкращого рішення серед кількох різних альтернатив, споживач повинен перевірити кількість ResourceSlices у пулі (включену в кожен ResourceSlice), щоб визначити, чи є його погляд на пул повним, і, якщо ні, чекати, поки драйвер завершить оновлення пулу.

Для ресурсів, які не є локальними для вузла, імʼя вузла не встановлюється. Замість цього драйвер може використовувати селектор вузлів для вказівки, де пристрої доступні.

Це альфа-тип і вимагає активації функціональної можливості DynamicResourceAllocation.


  • apiVersion: resource.k8s.io/v1alpha3

  • kind: ResourceSlice

  • metadata (ObjectMeta)

    Стандартні мета дані обʼєкта

  • spec (ResourceSliceSpec), обовʼязково

    Містить інформацію, опубліковану драйвером.

    Зміна специфікації автоматично інкрементує номер metadata.generation.

ResourceSliceSpec

ResourceSliceSpec містить інформацію, опубліковану драйвером в одному ResourceSlice.


  • driver (string), обовʼязково

    Driver ідентифікує драйвер DRA, який надає інформацію про ємність. Можна використовувати селектор полів для переліку лише об'єктів ResourceSlice з певним імʼям драйвера.

    Має бути піддоменом DNS і закінчуватися доменом DNS, що належить постачальнику драйвера. Це поле є незмінним.

  • pool (ResourcePool), обовʼязково

    Pool описує пул, до якого належить цей ResourceSlice.

    ResourcePool описує пул, до якого належать ResourceSlices.

    • pool.generation (int64), обовʼязково

      Generation відстежує зміни в пулі з часом. Щоразу, коли драйвер змінює щось в одному або кількох ресурсах у пулі, він повинен змінити покоління у всіх ResourceSlices, які є частиною цього пулу. Споживачі ResourceSlices повинні враховувати лише ресурси з пулу з найвищим номером покоління. Покоління може бути скинуто драйверами, що має бути прийнятно для споживачів, за умови, що всі ResourceSlices у пулі оновлені, щоб відповідати новому поколінню або видалені.

      Поєднаний з ResourceSliceCount, цей механізм дозволяє споживачам виявляти пули, які складаються з кількох ResourceSlices і знаходяться в неповному стані.

    • pool.name (string), обовʼязково

      Name використовується для ідентифікації пулу. Для локальних на вузлі пристроїв це часто є імʼя вузла, але це не є обовʼязковим.

      Не повинно перевищувати 253 символи і повинно складатися з одного або кількох піддоменів DNS, розділених косими рисками. Це поле є незмінним.

    • pool.resourceSliceCount (int64), обовʼязково

      ResourceSliceCount — це загальна кількість ResourceSlices у пулі на цьому номері покоління. Має бути більше нуля.

      Споживачі можуть використовувати це для перевірки, чи вони бачили всі ResourceSlices, що належать одному й тому ж пулу.

  • allNodes (boolean)

    AllNodes вказує на те, що всі вузли мають доступ до ресурсів у пулі.

    Має бути встановлено точно одне з полів NodeName, NodeSelector або AllNodes.

  • devices ([]Device)

    Atomic: буде замінено під час злиття

    Devices перераховує деякі або всі пристрої в цьому пулі.

    Не повинно бути більше ніж 128 записів.

    Device представляє один індивідуальний апаратний екземпляр, який може бути вибраний на основі його атрибутів. Окрім імені, має бути встановлено точно одне поле.

    • devices.name (string), обовʼязково

      Name є унікальним ідентифікатором серед усіх пристроїв, які управляються драйвером у пулі. Має бути піддоменом DNS.

    • devices.basic (BasicDevice)

      Basic визначає один екземпляр пристрою.

      BasicDevice визначає один екземпляр пристрою.

      • devices.basic.attributes (map[string]DeviceAttribute)

        Attributes визначає набір атрибутів для цього пристрою. Імʼя кожного атрибута повинно бути унікальним у цьому наборі.

        Максимальна кількість атрибутів та ємностей разом — 32.

        DeviceAttribute має бути встановлено точно одне поле.

        • devices.basic.attributes.bool (boolean)

          BoolValue є значенням true/false.

        • devices.basic.attributes.int (int64)

          IntValue є числом.

        • devices.basic.attributes.string (string)

          StringValue є рядком. Не повинно бути довше 64 символів.

        • devices.basic.attributes.version (string)

          VersionValue є семантичною версією відповідно до специфікації semver.org 2.0.0. Не повинна перевищувати 64 символи в довжину.

      • devices.basic.capacity (map[string]Quantity)

        Capacity визначає набір ємностей для цього пристрою. Імʼя кожної ємності повинно бути унікальним у цьому наборі.

        Максимальна кількість атрибутів та ємностей разом — 32.

  • nodeName (string)

    NodeName ідентифікує вузол, який надає ресурси в цьому пулі. Селектор полів можна використовувати для переліку лише обʼєктів ResourceSlice, що належать певному вузлу.

    Це поле може використовуватися для обмеження доступу з вузлів до ResourceSlices з тим же іменем вузла. Воно також вказує автомасштабувальникам, що додавання нових вузлів того ж типу, що й старий вузол, може також зробити нові ресурси доступними.

    Має бути встановлено точно одне з полів NodeName, NodeSelector або AllNodes. Це поле є незмінним.

  • nodeSelector (NodeSelector)

    NodeSelector визначає, які вузли мають доступ до ресурсів у пулі, коли цей пул не обмежений до одного вузла.

    Має бути використано точно один термін.

    Має бути встановлено точно одне з полів NodeName, NodeSelector або AllNodes.

    Селектор вузлів представляє обʼєднання результатів одного або кількох запитів міток по набору вузлів; тобто, він представляє логічну операцію OR селекторів, представлених термінами селектора вузлів.

    • nodeSelector.nodeSelectorTerms ([]NodeSelectorTerm), обовʼязково

      Atomic: буде замінено під час злиття

      Обовʼязково. Список термінів селектора вузлів. Терміни обʼєднуються операцією OR.

      Null або порожній термін селектора вузла не відповідає жодному об'єкту. Вимоги до них складаються за принципом AND. Тип TopologySelectorTerm реалізує підмножину NodeSelectorTerm.

      • nodeSelector.nodeSelectorTerms.matchExpressions ([]NodeSelectorRequirement)

        Atomic: буде замінено під час злиття

        Список вимог до селектора вузлів за мітками вузлів.

      • nodeSelector.nodeSelectorTerms.matchFields ([]NodeSelectorRequirement)

        Atomic: буде замінено під час злиття

        Список вимог до селектора вузла за полями вузла.

ResourceSliceList

ResourceSliceList — колекція класів ResourceSlices.


  • apiVersion: resource.k8s.io/v1alpha3

  • kind: ResourceSliceList

  • items ([]ResourceSlice), обовʼязково

    Items is the list of resource ResourceSlices.

  • metadata (ListMeta)

    Стандартні метадані списку

Операції


get отримати вказаний ResourceSlice

HTTP запит

GET /apis/resource.k8s.io/v1alpha3/resourceslices/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ResourceSlice

  • pretty (в запиті): string

    pretty

Відповідь

200 (ResourceSlice): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу ResourceSlice

HTTP запит

GET /apis/resource.k8s.io/v1alpha3/resourceslices

Параметри

Відповідь

200 (ResourceSliceList): OK

401: Unauthorized

create створення ResourceSlice

HTTP запит

POST /apis/resource.k8s.io/v1alpha3/resourceslices

Параметри

Відповідь

200 (ResourceSlice): OK

201 (ResourceSlice): Created

202 (ResourceSlice): Accepted

401: Unauthorized

update заміна вказаного ResourceSlice

HTTP запит

PUT /apis/resource.k8s.io/v1alpha3/resourceslices/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ResourceSlice

  • body: ResourceSlice, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (ResourceSlice): OK

201 (ResourceSlice): Created

401: Unauthorized

patch часткове оновлення вказаного ResourceSlice

HTTP запит

PATCH /apis/resource.k8s.io/v1alpha3/resourceslices/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ResourceSlice

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (ResourceSlice): OK

201 (ResourceSlice): Created

401: Unauthorized

delete видалення ResourceSlice

HTTP запит

DELETE /apis/resource.k8s.io/v1alpha3/resourceslices/{name}

Параметри

Відповідь

200 (ResourceSlice): OK

202 (ResourceSlice): Accepted

401: Unauthorized

deletecollection видалення колекції ResourceSlice

HTTP запит

DELETE /apis/resource.k8s.io/v1alpha3/resourceslices

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

6.5.2 - Ресурси Service

6.5.2.1 - Service

Service — це іменована абстракція служб програмного забезпечення (наприклад, mysql), що складається з локального порту (наприклад, 3306), який прослуховує проксі, і селектора, який визначає, які Podʼи будуть відповідати на запити, надіслані через проксі.

apiVersion: v1

import "k8s.io/api/core/v1"

Service

Service — це іменована абстракція служб програмного забезпечення (наприклад, mysql), що складається з локального порту (наприклад, 3306), який прослуховує проксі, і селектора, який визначає, які Podʼи будуть відповідати на запити, надіслані через проксі.


ServiceSpec

ServiceSpec описує атрибути, які користувач створює для служби.


  • selector (map[string]string)

    Направляє трафік до Podʼів з ключами та значеннями міток, які відповідають цьому селектору. Якщо селектор порожній або не вказаний, передбачається, що Service має зовнішній процес, який керує його точками доступу, і Kubernetes не буде їх змінювати. Застосовується лише до типів ClusterIP, NodePort і LoadBalancer. Ігнорується, якщо тип — ExternalName. Більше інформації: https://kubernetes.io/docs/concepts/services-networking/service/

  • ports ([]ServicePort)

    Patch strategy: злиття по ключу port

    Map: унікальні значення за ключами port, protocol зберігатимуться під час злиття

    Список портів, які відкриває Service. Більше інформації: https://kubernetes.io/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies

    ServicePort містить інформацію про порт Service.

    • ports.port (int32), обовʼязково

      Порт, який буде відкритий цим Service.

    • ports.targetPort (IntOrString)

      Номер або імʼя порту для доступу до Podʼів, на які спрямовано Service. Номер повинен бути в діапазоні від 1 до 65535. Імʼя повинно бути IANA_SVC_NAME. Якщо це рядок, він буде шукатися як іменований порт у портах контейнера цільового Podʼа. Якщо не вказано, використовується значення поля ʼportʼ (identity map). Це поле ігнорується для Service із clusterIP=None і має бути пропущене або встановлене рівним полю ʼportʼ. Більше інформації: https://kubernetes.io/docs/concepts/services-networking/service/#defining-a-service

      IntOrString — це тип, який може містити int32 або рядок. При використанні перетворення з/в JSON або YAML він виробляє або споживає внутрішній тип. Це дозволяє вам мати, наприклад, поле JSON, яке може приймати імʼя або число.

    • ports.protocol (string)

      IP-протокол для цього порту. Підтримуються "TCP", "UDP" і "SCTP". Стандартне значення — TCP.

    • ports.name (string)

      Імʼя цього порту в Service. Воно повинно бути DNS_LABEL. Усі порти в межах ServiceSpec повинні мати унікальні імена. При аналізі точок доступу для Service, вони повинні відповідати полю ʼnameʼ в EndpointPort. Необовʼязкове, якщо визначено лише один ServicePort для цього Service.

    • ports.nodePort (int32)

      Порт на кожному вузлі, на якому цей Service буде доступний, коли тип — NodePort або LoadBalancer. Зазвичай призначається системою. Якщо значення вказано, знаходиться в діапазоні та не використовується, воно буде використано, інакше операція завершиться невдачею. Якщо не вказано, порт буде виділено, якщо Service його потребує. Якщо це поле вказано під час створення Service, яка не потребує його, створення не вдасться. Це поле буде видалено під час оновлення Service, щоб більше не потребувати його (наприклад, змінюючи тип з NodePort на ClusterIP). Більше інформації: https://kubernetes.io/docs/concepts/services-networking/service/#type-nodeport

    • ports.appProtocol (string)

      Протокол застосунків для цього порту. Він використовується як підказка для реалізацій, щоб запропонувати багатший функціонал для протоколів, які вони розуміють. Це поле відповідає стандартному синтаксису міток Kubernetes. Допустимі значення - або:

  • type (string)

    Тип визначає, як Service буде відкрито. Стандартне значення — ClusterIP. Допустимі варіанти: ExternalName, ClusterIP, NodePort та LoadBalancer. "ClusterIP" виділяє точкам доступу внутрішню IP-адресу кластера для балансування навантаження. Точки доступу визначаються селектором або, якщо його не вказано, ручним створенням обʼєкта Endpoints або обʼєктів EndpointSlice. Якщо clusterIP має значення "None", жодна віртуальна IP-адреса не виділяється, і точки доступу публікуються як набір точок доступу, а не віртуальна IP-адреса. "NodePort" базується на ClusterIP і виділяє порт на кожному вузлі, який маршрутизується до тих самих точок доступу, що і clusterIP. "LoadBalancer" базується на NodePort і створює зовнішній балансувальник навантаження (якщо підтримується в поточній хмарі), який маршрутизується до тих самих точок доступу, що і clusterIP. "ExternalName" привʼязує цей Service до вказаного externalName. Декілька інших полів не застосовуються до Service ExternalName. Більше інформації: https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types

  • ipFamilies ([]string)

    Atomic: буде замінено під час злиття

    IPFamilies — це список IP-сімейств (наприклад, IPv4, IPv6), призначених цьому Serviceʼу. Це поле зазвичай призначається автоматично на основі конфігурації кластера та поля ipFamilyPolicy. Якщо це поле вказано вручну, запитане сімейство доступне в кластері, і ipFamilyPolicy дозволяє це, воно буде використане; інакше створення Service не вдасться. Це поле змінюється відповідно до умов: дозволяє додавати або видаляти вторинне IP-сімейство, але не дозволяє змінювати первинне IP-сімейство Service. Допустимі значення: "IPv4" і "IPv6". Це поле застосовується лише до Service типів ClusterIP, NodePort та LoadBalancer, і не застосовується до "headless" Service. Це поле буде очищено під час оновлення Service до типу ExternalName.

    Це поле може містити максимум два записи (двостекові сімейство, у будь-якому порядку). Ці сімейства повинні відповідати значенням поля clusterIPs, якщо вказано. Поля clusterIPs та ipFamilies керуються полем ipFamilyPolicy.

  • ipFamilyPolicy (string)

    IPFamilyPolicy представляє вимоги до подвійного стека для цього Service. Якщо значення не надано, це поле буде встановлено на SingleStack. Service можуть бути "SingleStack" (одне IP-сімейство), "PreferDualStack" (два IP-сімейства в конфігураціях з подвійним стеком або одне IP-сімейство в конфігураціях з одним стеком) або "RequireDualStack" (два IP-сімейства в конфігураціях з подвійним стеком, інакше буде збій). Поля ipFamilies та clusterIPs залежать від значення цього поля. Це поле буде очищено під час оновлення Service до типу ExternalName.

  • clusterIP (string)

    clusterIP — це IP-адреса Service, яка зазвичай призначається випадковим чином. Якщо адреса вказана вручну, знаходиться в діапазоні (згідно з конфігурацією системи) і не використовується, вона буде виділена Service; інакше створення Service не вдасться. Це поле не може бути змінено через оновлення, якщо тип поля також не змінюється на ExternalName (що вимагає, щоб це поле було порожнім) або тип поля змінюється з ExternalName (у цьому випадку це поле може бути зазначено опціонально, як описано вище). Допустимі значення: "None", порожній рядок (""), або дійсна IP-адреса. Встановлення цього значення в "None" створює "headless service" (без віртуальної IP-адреси), що корисно, коли потрібні прямі зʼєднання з точками доступу, і проксіювання не потрібне. Застосовується лише до типів ClusterIP, NodePort і LoadBalancer. Якщо це поле вказано під час створення Service типу ExternalName, створення не вдасться. Це поле буде очищено під час оновлення Service до типу ExternalName. Більше інформації: https://kubernetes.io/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies

  • clusterIPs ([]string)

    Atomic: буде замінено під час злиття

    ClusterIPs — це список IP-адрес, призначених Service, і зазвичай вони призначаються випадковим чином. Якщо адреса вказана вручну, знаходиться в діапазоні (згідно з конфігурацією системи) і не використовується, вона буде виділена Service; інакше створення Service не вдасться. Це поле не може бути змінено через оновлення, якщо тип поля також не змінюється на ExternalName (що вимагає, щоб це поле було порожнім) або тип поля змінюється з ExternalName (у цьому випадку це поле може бути зазначено опціонально, як описано вище). Допустимі значення: "None", порожній рядок (""), або дійсна IP-адреса. Встановлення цього значення на "None" створює "headless service" (без віртуальної IP-адреси), що корисно, коли потрібні прямі зʼєднання з точками доступу, і проксіювання не потрібно. Застосовується лише до типів ClusterIP, NodePort і LoadBalancer. Якщо це поле вказано під час створення Service типу ExternalName, створення не вдасться. Це поле буде очищено під час оновлення Service до типу ExternalName. Якщо це поле не вказано, воно буде ініціалізовано з поля clusterIP. Якщо це поле вказано, клієнти повинні переконатися, що clusterIPs[0] і clusterIP мають однакове значення.

    Це поле може містити максимум два записи (IP-адреси подвійного стека в будь-якому порядку). Ці IP-адреси повинні відповідати значенням поля ipFamilies. Поля clusterIPs та ipFamilies керуються полем ipFamilyPolicy. Більше інформації: https://kubernetes.io/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies

  • externalIPs ([]string)

    Atomic: буде замінено під час злиття

    externalIPs — це список IP-адрес, для яких вузли в кластері також будуть приймати трафік для цього Service. Ці IP-адреси не керуються Kubernetes. Користувач несе відповідальність за забезпечення того, щоб трафік надходив на вузол з цією IP-адресою. Загальний приклад — зовнішні балансувальники навантаження, які не є частиною системи Kubernetes.

  • sessionAffinity (string)

    Підтримує "ClientIP" і "None". Використовується для підтримки спорідненості сеансів. Вмикає спорідненість сеансів на основі IP-адреси клієнта. Значення повинно бути ClientIP або None. Стандартне значення — None. Більше інформації: https://kubernetes.io/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies

  • loadBalancerIP (string)

    Застосовується лише до типу Service: LoadBalancer. Ця функція залежить від того, чи підтримує базовий хмарний провайдер вказівку loadBalancerIP під час створення балансувальника навантаження. Це поле буде ігноруватися, якщо постачальник хмари не підтримує цю функцію. Застаріле: це поле було недостатньо описане, і його значення варіюється залежно від реалізацій. Використання його не є переносимим і може не підтримувати подвійний стек. Користувачам рекомендується використовувати анотації специфічні для реалізації, коли це можливо.

  • loadBalancerSourceRanges ([]string)

    Atomic: буде замінено під час злиття

    Якщо вказано і підтримується платформою, це обмежить трафік через балансувальник навантаження постачальника хмари до вказаних IP-адрес клієнтів. Це поле буде ігноруватися, якщо постачальник хмари не підтримує цю функцію. Більше інформації: https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/

  • loadBalancerClass (string)

    loadBalancerClass — це клас реалізації балансувальника навантаження, до якого належить Service. Якщо вказано, значення цього поля повинно бути ідентифікатором у стилі мітки з опціональним префіксом, наприклад, "internal-vip" або "example.com/internal-vip". Імена без префіксів зарезервовані для кінцевих користувачів. Це поле можна встановити лише при створенні або оновленні Service до типу ʼLoadBalancerʼ. Якщо не встановлено, використовується стандартна реалізація балансувальника навантаження, сьогодні це зазвичай робиться через інтеграцію з постачальником хмари, але має застосовуватися до будь-якої стандартної реалізації. Якщо встановлено, вважається, що реалізація балансувальника навантаження стежить за Service з відповідним класом. Будь-яка стандартна реалізація балансувальника навантаження (наприклад, постачальники хмари) повинна ігнорувати Service, які встановлюють це поле. Це поле можна встановити лише при створенні або оновленні Service до типу ʼLoadBalancerʼ. Після встановлення його не можна змінити. Це поле буде очищено при оновленні Service до типу, відмінного від ʼLoadBalancerʼ.

  • externalName (string)

    externalName — це зовнішнє посилання, яке механізми виявлення будуть повертати як псевдонім для цього Service (наприклад, запис DNS CNAME). Проксіювання не буде. Повинно бути вказано в нижньому регістрі відповідно до RFC-1123 hostname (https://tools.ietf.org/html/rfc1123) і вимагає type бути "ExternalName".

  • externalTrafficPolicy (string)

    externalTrafficPolicy описує, як вузли розподіляють трафік, який вони отримують на одній з "зовнішньо спрямованих" адрес Service (NodePorts, ExternalIPs і LoadBalancer IPs). Якщо встановлено значення "Local", проксі налаштує Service так, що передбачається, що зовнішні балансувальники навантаження будуть піклуватися про балансування трафіку Service між вузлами, і тому кожен вузол буде доставляти трафік лише до локальних точок доступу вузла цього Service, не маскуючи IP-адресу джерела клієнта. (Трафік, помилково надісланий на вузол без точок доступу, буде відхилений.) Стандартне значення "Cluster" використовує стандартну поведінку маршрутизації до всіх точок доступу рівномірно (можливо, змінену топологією та іншими функціями). Зверніть увагу, що трафік, надісланий на External IP або LoadBalancer IP зсередини кластера, завжди буде мати семантику "Cluster", але клієнти, які надсилають на NodePort зсередини кластера, можуть враховувати політику трафіку під час вибору вузла.

  • internalTrafficPolicy (string)

    InternalTrafficPolicy описує, як вузли розподіляють трафік, який вони отримують на ClusterIP. Якщо встановлено значення "Local", проксі вважатиме, що Podʼи хочуть спілкуватися лише з точками доступу Service на тому ж вузлі, що й Pod, відхиляючи трафік, якщо немає локальних точок доступу. Стандартне значення "Cluster" використовує стандартну поведінку маршрутизації до всіх точок доступу рівномірно (можливо, змінено топологією та іншими функціями).

  • healthCheckNodePort (int32)

    healthCheckNodePort визначає порт вузла перевірки справності Service. Це застосовується лише при встановленні типу на LoadBalancer і зовнішньому трафіку політики на Local. Якщо вказане значення, знаходиться в діапазоні і не використовується, воно буде використано. Якщо не вказано, значення буде автоматично призначено. Зовнішні системи (наприклад, балансувальники навантаження) можуть використовувати цей порт, щоб визначити, чи містить певний вузол точки доступу для цього Service чи ні. Якщо це поле вказано під час створення Service, яка цього не потребує, створення не вдасться. Це поле буде очищено при оновленні Service, щоб більше не потребувати його (наприклад, зміна типу). Це поле не можна оновити після встановлення.

  • publishNotReadyAddresses (boolean)

    publishNotReadyAddresses вказує, що будь-який агент, який має справу з точками доступу для цього Service, повинен ігнорувати будь-які індикатори готовності/не готовності. Основний випадок використання цього поля — для Headless Service для StatefulSet, щоб поширювати SRV DNS-записи для своїх Podʼів з метою їх виявлення. Контролери Kubernetes, які генерують ресурси Endpoints і EndpointSlice для Service, інтерпретують це як ознаку того, що всі точки доступу вважаються "готовими", навіть якщо самі Podʼи не готові. Агенти, які використовують тільки точки доступу, створені Kubernetes, через ресурси Endpoints або EndpointSlice, можуть безпечно передбачати цю поведінку.

  • sessionAffinityConfig (SessionAffinityConfig)

    sessionAffinityConfig містить конфігурації сеансової спорідненості.

    SessionAffinityConfig представляє конфігурації сеансової спорідненості.

    • sessionAffinityConfig.clientIP (ClientIPConfig)

      clientIP містить конфігурації сеансової спорідненості на основі IP клієнта.

      ClientIPConfig представляє конфігурації сеансової спорідненості на основі IP клієнта.

      • sessionAffinityConfig.clientIP.timeoutSeconds (int32)

        timeoutSeconds задає час залипання сесії типу ClientIP у секундах. Значення повинно бути >0 && <=86400 (для 1 дня), якщо ServiceAffinity == "ClientIP". Стандартне значення — 10800 (3 години).

  • allocateLoadBalancerNodePorts (boolean)

    allocateLoadBalancerNodePorts визначає, чи будуть автоматично виділені NodePorts для Service з типом LoadBalancer. Стандартне значення — "true". Його можна встановити у "false", якщо балансувальник навантаження кластера не покладається на NodePorts. Якщо абонент запитує конкретні NodePorts (вказуючи значення), ці запити будуть виконані, незалежно від цього поля. Це поле можна встановити лише для Service з типом LoadBalancer і воно буде очищено, якщо тип буде змінено на будь-який інший тип.

  • trafficDistribution (string)

    TrafficDistribution надає спосіб виразити вподобання щодо того, як розподіляти трафік до точок доступу сервісу. Реалізації можуть використовувати це поле як підказку, але не зобовʼязані суворо дотримуватися вказівок. Якщо поле не встановлене, реалізація застосує свою стандартну стратегію маршрутизації. Якщо встановлено значення "PreferClose", реалізації повинні надавати пріоритет точкам доступу, які топологічно близькі (наприклад, у тій самій зоні). Це бета-поле і потребує ввімкнення функції ServiceTrafficDistribution.

ServiceStatus

ServiceStatus представляє поточний стан Service.


  • conditions ([]Condition)

    Patch strategy: злиття за ключем type

    Map: унікальні значення за ключем type зберігаються під час злиття

    Поточний стан Service

    Condition містить деталі для одного аспекту поточного стану цього API ресурсу.

    • conditions.lastTransitionTime (Time), обовʼязково

      lastTransitionTime — це останній час, коли стан змінився з одного на інший. Це має бути тоді, коли змінився основний стан. Якщо це невідомо, то можна використати час, коли змінилося поле API.

      Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

    • conditions.message (string), обовʼязково

      message — це повідомлення, зрозуміле людині, яке вказує на деталі про зміну стану. Це може бути порожній рядок.

    • conditions.reason (string), обовʼязково

      reason містить програмний ідентифікатор, який вказує на причину останньоїзміни стану. Виробники специфічних типів станів можуть визначати очікувані значення та значення для цього поля, і чи вважаються значення гарантованим API. Значення має бути рядком у CamelCase. Це поле не може бути порожнім.

    • conditions.status (string), обовʼязково

      статус стану, одне з True, False, Unknown.

    • conditions.type (string), обовʼязково

      тип стану у CamelCase або у форматі foo.example.com/CamelCase.

    • conditions.observedGeneration (int64)

      observedGeneration представляє .metadata.generation, на основі якої встановлено стан. Наприклад, якщо .metadata.generation наразі дорівнює 12, але .status.conditions[x].observedGeneration дорівнює 9, то стан не актуальний стосовно поточного стану екземпляра.

  • loadBalancer (LoadBalancerStatus)

    LoadBalancer містить поточний статус балансувальника навантаження, якщо він присутній.

    LoadBalancerStatus представляє статус балансувальника навантаження.

    • loadBalancer.ingress ([]LoadBalancerIngress)

      Atomic: буде замінено під час злиття

      Ingress — це список точок входу для балансувальника навантаження. Трафік, призначений для Service, має надходити до цих точок входу.

      LoadBalancerIngress представляє стаnec точки входу балансувальника навантаження: трафік, призначений для Service, має надходити до точки входу.

      • loadBalancer.ingress.hostname (string)

        Hostname встановлюється для точок входу балансувальника навантаження, які базуються на DNS (зазвичай балансувальники навантаження AWS)

      • loadBalancer.ingress.ip (string)

        IP встановлюється для точок входу балансувальника навантаження, які базуються на IP (зазвичай балансувальники навантаження GCE або OpenStack)

      • loadBalancer.ingress.ipMode (string)

        IPMode визначає, як поводиться IP балансувальника навантаження, і може бути вказаний лише тоді, коли вказане поле ip. Встановлення цього значення на "VIP" означає, що трафік доставляється до вузла з встановленим призначенням на IP та порт балансувальника навантаження. Встановлення цього значення на "Proxy" означає, що трафік доставляється до вузла або Pod з встановленим призначенням на IP вузла та порт вузла або на IP Podʼа та порт. Реалізації Service можуть використовувати цю інформацію для налаштування маршрутизації трафіку.

      • loadBalancer.ingress.ports ([]PortStatus)

        Atomic: буде замінено під час злиття

        Ports — це список портів Service. Якщо використовується, кожен порт, визначений у Service, повинен мати запис у цьому списку.

        **

        • loadBalancer.ingress.ports.port (int32), обовʼязково

          Port — це номер порту Service, стан якого записаний тут.

        • loadBalancer.ingress.ports.protocol (string), обовʼязково

          Protocol — це протокол порту Service, стан якого записаний тут. Підтримувані значення: "TCP", "UDP", "SCTP".

        • loadBalancer.ingress.ports.error (string)

          Error — це запис проблеми з портом Service. Формат помилки має відповідати наступним правилам:

          • значення вбудованих помилок повинні бути визначені у цьому файлі та повинні використовувати CamelCase імена;
          • значення помилок, специфічних для хмарних провайдерів, повинні мати імена, які відповідають формату foo.example.com/CamelCase.

ServiceList

ServiceList містить список Serviceʼів.


Операції


get отримати вказаний Service

HTTP запит

GET /api/v1/namespaces/{namespace}/services/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя Service

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (Service): OK

401: Unauthorized

get отримати статус вказаного Service

HTTP запит

GET /api/v1/namespaces/{namespace}/services/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя Service

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (Service): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу Service

HTTP запит

GET /api/v1/namespaces/{namespace}/services

Параметри

Відповідь

200 (ServiceList): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу Service

HTTP запит

GET /api/v1/services

Параметри

Відповідь

200 (ServiceList): OK

401: Unauthorized

create створення Service

HTTP запит

POST /api/v1/namespaces/{namespace}/services

Параметри

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Service, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (Service): OK

201 (Service): Created

202 (Service): Accepted

401: Unauthorized

update заміна вказаного Service

HTTP запит

PUT /api/v1/namespaces/{namespace}/services/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя Service

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Service, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (Service): OK

201 (Service): Created

401: Unauthorized

update заміна статусу вказаного Service

HTTP запит

PUT /api/v1/namespaces/{namespace}/services/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя Service

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Service, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (Service): OK

201 (Service): Created

401: Unauthorized

patch часткове оновлення вказаного Service

HTTP запит

PATCH /api/v1/namespaces/{namespace}/services/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя Service

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (Service): OK

201 (Service): Created

401: Unauthorized

patch часткове оновлення статусу вказаного Service

HTTP запит

PATCH /api/v1/namespaces/{namespace}/services/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя Service

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (Service): OK

201 (Service): Created

401: Unauthorized

delete видалення Service

HTTP запит

DELETE /api/v1/namespaces/{namespace}/services/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя Service

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (Service): OK

202 (Service): Accepted

401: Unauthorized

deletecollection видалити колекцію Service

HTTP запит

DELETE /api/v1/namespaces/{namespace}/services

Параметри

Відповідь

200 (ServiceList): OK

401: Unauthorized

6.5.2.2 - Endpoints

Endpoints — є колекцією точок доступу, що фактично утворюють Service.

apiVersion: v1

import "k8s.io/api/core/v1"

Endpoints

Endpoints — є колекцією точок доступу, що фактично утворюють Service.

Name: "mysvc",
Subsets: [
  {
    Addresses: [{"ip": "10.10.1.1"}, {"ip": "10.10.2.2"}],
    Ports: [{"name": "a", "port": 8675}, {"name": "b", "port": 309}]
  },
  {
    Addresses: [{"ip": "10.10.3.3"}],
    Ports: [{"name": "a", "port": 93}, {"name": "b", "port": 76}]
  },
]

  • apiVersion: v1

  • kind: Endpoints

  • metadata (ObjectMeta)

    Стандартні метадані обʼєкта. Детальніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

  • subsets ([]EndpointSubset)

    Atomic: буде замінено під час злиття

    Набір всіх точок доступу є обʼєднанням (union) всіх субнаборів. Адреси розміщуються в субнабори відповідно до IP-адрес, які вони поділяють. Одна адреса з кількома портами, деякі з яких готові, а деякі ні (тому що вони належать різним контейнерам), буде відображатися в різних субнаборах для різних портів. Жодна адреса не зʼявиться одночасно в Addresses і NotReadyAddresses в одному субнаборі. Набори адрес і портів, які складають Service.

    EndpointSubset – це група адрес з одним набором портів. Розширений набір точок доступу є декартовим добутком Addresses x Ports. Наприклад, задано:

    {
      Addresses: [{"ip": "10.10.1.1"}, {"ip": "10.10.2.2"}],
      Ports:     [{"name": "a", "port": 8675}, {"name": "b", "port": 309}]
    }
    

    Отриманий набір кінцевих точок може виглядати як:

    a: [ 10.10.1.1:8675, 10.10.2.2:8675 ],
    b: [ 10.10.1.1:309, 10.10.2.2:309 ]
    
    • subsets.addresses ([]EndpointAddress)

      Atomic: буде замінено під час злиття

      IP-адреси, які пропонують відповідні порти, позначені як готові. Ці точки доступу повинні вважатися безпечними для використання балансувальниками навантаження та клієнтами.

      EndpointAddress — це кортеж, що описує одну IP-адресу.

      • subsets.addresses.ip (string), обовʼязкове

        IP цієї точки доступу. Не може бути loopback (127.0.0.0/8 або ::1), link-local (169.254.0.0/16 або fe80::/10), або link-local multicast (224.0.0.0/24 або ff02::/16).

      • subsets.addresses.hostname (string)

        Імʼя хоста цієї точки доступу

      • subsets.addresses.nodeName (string)

        Необовʼязково: Вузол, на якому знаходиться ця точка доступу. Це може бути використано для визначення точок доступу що є локальними для вузла.

      • subsets.addresses.targetRef (ObjectReference)

        Посилання на обʼєкт, що надає точку доступу.

    • subsets.notReadyAddresses ([]EndpointAddress)

      Atomic: буде замінено під час злиття

      IP-адреси, які пропонують відповідні порти, але наразі не позначені як готові, тому що вони ще не завершили запуск, нещодавно не пройшли перевірку готовності або нещодавно не пройшли перевірку на справність.

      EndpointAddress — це кортеж, що описує одну IP-адресу.

      • subsets.notReadyAddresses.ip (string), обовʼязкове

        IP цієї точки доступу. Не може бути loopback (127.0.0.0/8 або ::1), link-local (169.254.0.0/16 або fe80::/10), або link-local multicast (224.0.0.0/24 або ff02::/16).

      • subsets.notReadyAddresses.hostname (string)

        Імʼя хоста цієї точки доступу

      • subsets.notReadyAddresses.nodeName (string)

        Необовʼязково: Вузол, на якому знаходиться ця точка доступу. Це може бути використано для визначення точок доступу що є локальними для вузла.

      • subsets.notReadyAddresses.targetRef (ObjectReference)

        Посилання на обʼєкт, що надає точку доступу.

    • subsets.ports ([]EndpointPort)

      Atomic: буде замінено під час злиття

      Номери портів, доступні на відповідних IP-адресах.

      EndpointPort — це кортеж, що описує один порт.

      • subsets.ports.port (int32), обовʼязкове

        Номер порту точки доступу.

      • subsets.ports.protocol (string)

        IP-протокол для цього порту. Повинен бути UDP, TCP або SCTP. За замовчуванням TCP.

      • subsets.ports.name (string)

        Імʼя цього порту. Це повинно відповідати полю 'name' у відповідному ServicePort. Повинно бути DNS_LABEL. Необовʼязкове, лише якщо визначено один порт.

      • subsets.ports.appProtocol (string)

        Протокол програми для цього порту. Використовується як підказка для реалізацій, щоб пропонувати багатший функціонал для протоколів, які вони розуміють. Це поле відповідає стандартному синтаксису міток Kubernetes. Дійсні значення:

EndpointsList

EndpointsList – це список точок доступу.


Операції


get отримати вказані Endpoints

HTTP запит

GET /api/v1/namespaces/{namespace}/endpoints/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва Endpoints

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (Endpoints): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу Endpoints

HTTP запит

GET /api/v1/namespaces/{namespace}/endpoints

Параметри

Відповідь

200 (EndpointsList): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу Endpoints

HTTP запит

GET /api/v1/endpoints

Параметри

Відповідь

200 (EndpointsList): OK

401: Unauthorized

create створення Endpoints

HTTP запит

POST /api/v1/namespaces/{namespace}/endpoints

Параметри

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Endpoints, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (Endpoints): OK

201 (Endpoints): Created

202 (Endpoints): Accepted

401: Unauthorized

update заміна Endpoints

HTTP запит

PUT /api/v1/namespaces/{namespace}/endpoints/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва Endpoints

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Endpoints, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (Endpoints): OK

201 (Endpoints): Created

401: Unauthorized

patch часткове оновлення Endpoints

HTTP запит

PATCH /api/v1/namespaces/{namespace}/endpoints/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва Endpoints

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (Endpoints): OK

201 (Endpoints): Created

401: Unauthorized

delete видалення Endpoints

HTTP запит

DELETE /api/v1/namespaces/{namespace}/endpoints/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва Endpoints

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видалити колекцію Endpoints

HTTP запит

DELETE /api/v1/namespaces/{namespace}/endpoints

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

6.5.2.3 - EndpointSlice

EndpointSlice представляє підмножину точок доступу, які реалізують сервіс.

apiVersion: discovery.k8s.io/v1

import "k8s.io/api/discovery/v1"

EndpointSlice

EndpointSlice представляє підмножину точок доступу, які реалізують сервіс. Для даного сервісу може існувати декілька обʼєктів EndpointSlice, виділених мітками, які необхідно обʼєднати для отримання повного набору кінцевих точок.


  • apiVersion: discovery.k8s.io/v1

  • kind: EndpointSlice

  • metadata (ObjectMeta)

    Стандартні метадані обʼєкта.

  • addressType (string), обовʼязково

    addressType вказує тип адреси, яку містить цей EndpointSlice. Усі адреси в цьому сегменті повинні бути одного типу. Це поле є незмінним після створення. Наразі підтримуються такі типи адрес:

    • IPv4: Представляє адресу IPv4.
    • IPv6: Представляє адресу IPv6.
    • FQDN: Представляє повне доменне імʼя (Fully Qualified Domain Name).
  • endpoints ([]Endpoint), обовʼязково

    Atomic: буде замінено під час злиття

    endpoints — список унікальних точок доступу у цьому зрізі. Кожен зріз може містити максимум 1000 точок доступу.

    Точка доступу являє собою окремий логічний “бекенд", що реалізує сервіс.

    • endpoints.addresses ([]string), обовʼязково

      Set: унікальні значення будуть збережені під час злиття

      адреси цієї точки доступу. Вміст цього поля інтерпретується згідно з відповідним полем EndpointSlice addressType. Споживачі повинні обробляти різні типи адрес у контексті власних можливостей. Це поле має містити принаймні одну адресу, але не більше 100. Вважається, що всі вони є взаємозамінними, і клієнти можуть використовувати лише перший елемент. Зверніться до: https://issue.k8s.io/106267

    • endpoints.conditions (EndpointConditions)

      conditions містить інформацію про поточний стан точки доступу.

      EndpointConditions представляє поточний стано точки доступу.

      • endpoints.conditions.ready (boolean)

        ready вказує на те, що ця точка доступу готова приймати трафік, відповідно до системи, яка керує цією точкою доступу. Нульове значення вказує на невідомий стан. У більшості випадків споживачі повинні інтерпретувати цей невідомий стан як готовий. З міркувань сумісності значення ready ніколи не повинно бути "true" для точок доступу, що завершують роботу, за винятком випадків, коли звичайна поведінка готовності явно перевизначена, наприклад, коли пов'язана служба встановила прапорець publishNotReadyAddresses.

      • endpoints.conditions.serving (boolean)

        serving ідентичний ready, за винятком того, що він встановлюється незалежно від завершального стану точок доступу. Ця умова має бути встановлена в true для точки доступу що має стан ready, яка завершує роботу. Якщо вона дорівнює нулю, споживачі повинні відкладати обслуговування до стану готовності.

      • endpoints.conditions.terminating (boolean)

        terminating вказує на те, що ця точка доступу завершує роботу. Нульове значення вказує на невідомий стан. Споживачі повинні інтерпретувати цей невідомий стан як те, що точка доступу не завершує роботу.

    • endpoints.deprecatedTopology (map[string]string)

      deprecatedTopology містить інформацію про топологію, яка є частиною v1beta1 API. Це поле є застарілим і буде вилучено, коли буде вилучено API v1beta1 (не раніше kubernetes v1.24). Хоча це поле може містити значення, воно не може бути записане через v1 API, і будь-які спроби запису до нього будуть проігноровані. Замість цього інформацію про топологію можна знайти у полях zone та nodeName.

    • endpoints.hints (EndpointHints)

      hints містить інформацію, повʼязану з тим, як слід використовувати точку доступу.

      EndpointHints надає підказки, що описують, як слід використовувати точку доступу.

      • endpoints.hints.forZones ([]ForZone)

        Atomic: буде замінено під час злиття

        forZones вказує на зону(и), до якої(их) повинна потрапити ця точка доступу, щоб увімкнути топологічно орієнтовану маршрутизацію.

        ForZone надає інформацію про те, які зони повинні використовувати цю точку доступу.

        • endpoints.hints.forZones.name (string), обовʼязково

          name — назва зони.

    • endpoints.hostname (string)

      ім'я хосту цієї точки доступу. Це поле може використовуватися споживачами точок доступу, щоб відрізняти їх одна від одної (наприклад, в іменах DNS). Кілька точок доступу, які використовують одне й те саме ім'я хосту, слід вважати взаємозамінними (наприклад, кілька значень A в DNS). Повинні бути малими літерами і проходити перевірку DNS-мітки (RFC 1123).

    • endpoints.nodeName (string)

      nodeName — імʼя вузла, на якому розміщено цю точку доступу. Це може бути використано для визначення локальних для вузла точок доступу.

    • endpoints.targetRef (ObjectReference)

      targetRef — посилання на обʼєкт Kubernetes, який представляє цю точку доступу.

    • endpoints.zone (string)

      зона — назва зони, в якій існує ця точка доступу.

  • ports ([]EndpointPort)

    Atomic: буде замінено під час злиття

    ports визначає список мережевих портів, доступних для кожної точки доступу у цьому зрізі. Кожен порт повинен мати унікальну назву. Якщо параметр ports порожній, це означає, що немає визначених портів. Якщо порт визначено зі значенням nil port, це означає "all ports" (всі порти). Кожен зріз може містити максимум 100 портів.

    EndpointPort представляє Port, який використовується EndpointSlice

    • ports.port (int32)

      порт — це номер порту точки доступу. Якщо його не вказано, порти не обмежуються і повинні інтерпретуватися в контексті конкретного споживача.

    • ports.protocol (string)

      протокол представляє IP-протокол для цього порту. Має бути UDP, TCP або SCTP. Стандартно використовується TCP.

    • ports.name (string)

      name - імʼя цього порту. Усі порти у фрагменті EndpointSlice повинні мати унікальне імʼя. Якщо EndpointSlice є похідним від сервісу Kubernetes, це імʼя відповідає Service.ports[].name. Імʼя має бути або порожнім рядком, або пройти перевірку DNS_LABEL:

      • повинно мати довжину не більше 63 символів.
      • має складатися з малих літер та цифр або символу '-'.
      • повинно починатися і закінчуватися буквено-цифровим символом. Стандартно - порожній рядок.
    • ports.appProtocol (string)

      Протокол застосунку для цього порту. Це використовується як підказка для реалізацій, щоб запропонувати багатший функціонал для протоколів, які вони розуміють. Це поле дотримується стандартного синтаксису міток Kubernetes. Допустимі значення:

EndpointSliceList

EndpointSliceList представляє список зрізів точок доступу


  • apiVersion: discovery.k8s.io/v1

  • kind: EndpointSliceList

  • metadata (ListMeta)

    Стандартні метадані списку.

  • items ([]EndpointSlice), обовʼязково

    items — список зрізів точок доступу

Операції


get отримати вказанний EndpointSlice

HTTP запит

GET /apis/discovery.k8s.io/v1/namespaces/{namespace}/endpointslices/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя EndpointSlice

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (EndpointSlice): OK

401: Unauthorized

list перелік або перегляд обʼєктів EndpointSlice

HTTP запит

GET /apis/discovery.k8s.io/v1/namespaces/{namespace}/endpointslices

Параметри

Відповідь

200 (EndpointSliceList): OK

401: Unauthorized

list перелік або перегляд обʼєктів EndpointSlice

HTTP запит

GET /apis/discovery.k8s.io/v1/endpointslices

Параметри

Відповідь

200 (EndpointSliceList): OK

401: Unauthorized

create створення EndpointSlice

HTTP запит

POST /apis/discovery.k8s.io/v1/namespaces/{namespace}/endpointslices

Параметри

Відповідь

200 (EndpointSlice): OK

201 (EndpointSlice): Created

202 (EndpointSlice): Accepted

401: Unauthorized

update заміна вказаного EndpointSlice

HTTP запит

PUT /apis/discovery.k8s.io/v1/namespaces/{namespace}/endpointslices/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя EndpointSlice

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: EndpointSlice, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (EndpointSlice): OK

201 (EndpointSlice): Created

401: Unauthorized

patch часткове оновлення вказаного EndpointSlice

HTTP запит

PATCH /apis/discovery.k8s.io/v1/namespaces/{namespace}/endpointslices/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя EndpointSlice

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (EndpointSlice): OK

201 (EndpointSlice): Created

401: Unauthorized

delete видалення EndpointSlice

HTTP запит

DELETE /apis/discovery.k8s.io/v1/namespaces/{namespace}/endpointslices/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя EndpointSlice

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції EndpointSlice

HTTP запит

DELETE /apis/discovery.k8s.io/v1/namespaces/{namespace}/endpointslices

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

6.5.2.4 - Ingress

Ingress — це набір правил, які дозволяють вхідним зʼєднанням досягати точок доступу, визначених бекендом.

apiVersion: networking.k8s.io/v1

import "k8s.io/api/networking/v1"

Ingress

Ingress — це набір правил, які дозволяють вхідним зʼєднанням досягати точок доступу, визначених бекендом. Ingress можна налаштувати так, щоб надавати Service зовнішні адреси, балансувати трафік, закінчувати SSL, пропонувати віртуальний хостинг на основі імен тощо.


IngressSpec

IngressSpec описує Ingress, який користувач хоче, щоб існував.


  • defaultBackend (IngressBackend)

    defaultBackend — це бекенд, який повинен обробляти запити, що не відповідають жодному правилу. Якщо правила не вказані, необхідно вказати DefaultBackend. Якщо DefaultBackend не встановлено, обробка запитів, що не відповідають жодному з правил, буде відбуватись на розсуд контролера Ingress.

  • ingressClassName (string)

    ingressClassName — це імʼя ресурсу IngressClass у кластері. Реалізації контролера Ingress використовують це поле для визначення, чи повинні вони обслуговувати цей ресурс Ingress, через транзитивний звʼязок (controller -> IngressClass -> Ingress resource). Хоча анотація kubernetes.io/ingress.class (проста константна назва) ніколи не була формально визначена, вона була широко підтримана контролерами Ingress для створення прямого звʼязку між контролером Ingress і ресурсами Ingress. Новостворені ресурси Ingress повинні надавати перевагу використанню цього поля. Однак, попри те, що анотація офіційно застаріла, з міркувань зворотної сумісності контролери Ingress все ще повинні враховувати цю анотацію, якщо вона присутня.

  • rules ([]IngressRule)

    Atomic: буде замінено під час злиття

    rules — це список правил для хостів, що використовуються для налаштування Ingress. Якщо не вказано або жодне правило не має збігів, весь трафік надсилається на стандартний бекенд.

    IngressRule представляє правила, що зіставляють шляхи для зазначеного хосту з відповідними бекенд-сервісами. Вхідні запити спочатку оцінюються на відповідність хосту, а потім перенаправляються до бекенда, асоційованого з відповідним IngressRuleValue.

    • rules.host (string)

      host — це повне доменне імʼя мережевого хосту, як визначено в RFC 3986. Зверніть увагу на такі відхилення від частини "host" в URI, як визначено в RFC 3986:

      1. IP-адреси не допускаються. Зараз IngressRuleValue може застосовуватися лише до IP-адреси в Spec батьківського Ingress.
      2. Двокрапка (:) як роздільник не використовується, оскільки порти не допускаються. Зараз порт Ingress неявно визначений як :80 для http і :443 для https.

      Обидва ці моменти можуть змінитися в майбутньому. Вхідні запити зіставляються з хостом перед IngressRuleValue. Якщо хост не вказано, Ingress маршрутизує весь трафік на основі зазначеного IngressRuleValue.

      host може бути "точним" (precise), доменним імʼям без завершальної крапки мережевого хосту (наприклад, "foo.bar.com"), або "wildcard" (маска), що є доменним імʼям з префіксом у вигляді одного символу маски (наприклад, "*.foo.com"). Символ маски '*' повинен зʼявлятися сам по собі як перша мітка DNS і відповідає лише одній мітці. Ви не можете мати мітку маски саму по собі (наприклад, Host == "*"). Запити будуть зіставлятися з полем Host наступним чином:

      1. Якщо host є точним, запит відповідає цьому правилу, якщо заголовок http host дорівнює Host.
      2. Якщо host є маскою, то запит відповідає цьому правилу, якщо заголовок http host дорівнює суфіксу (видаляючи першу мітку) правила маски.
    • rules.http (HTTPIngressRuleValue)

      HTTPIngressRuleValue — це список http-селекторів, що вказують на бекенди. У прикладі: http://<host>/<path>?<searchpart> -> backend, де частини url відповідають RFC 3986, цей ресурс буде використовуватися для зіставлення з усім після останнього '/' і перед першим '?' або '#'.

      • rules.http.paths ([]HTTPIngressPath), обовʼязкове

        Atomic: буде замінено під час злиття

        paths — це набір шляхів, що зіставляють запити з бекендами.

        HTTPIngressPath асоціює шлях з бекендом. Вхідні URL-адреси, що відповідають шляху, перенаправляються до бекенду.

        • rules.http.paths.backend (IngressBackend), обовʼязкове

          backend визначає повʼязану точку доступу сервісу, до якого буде перенаправлено трафік.

        • rules.http.paths.pathType (string), обовʼязкове

          pathType визначає інтерпретацію зіставлення шляху. PathType може мати одне з таких значень:

          • Exact: Точно відповідає URL-шляху.
          • Prefix: Збіг базується на префіксі шляху URL, розділеному символом '/'. Збіг перевіряється поелементно за елементами шляху. Елемент шляху — це список міток у шляху, розділених роздільником '/'. Запит вважається відповідністю для шляху p, якщо кожен елемент p є попереднім елементом відповідного елемента в кінцевому шляху запиту. Якщо це не так, то це не збіг (наприклад, /foo/bar має збіг з /foo/bar/baz, але не має з /foo/barbaz).
          • ImplementationSpecific: Інтерпретація зіставлення шляху визначається IngressClass. Реалізації можуть трактувати це як окремий PathType або так само як і типи шляхів Prefix або Exact.

          Реалізації повинні підтримувати всі типи шляхів.

        • rules.http.paths.path (string)

          path зіставляється зі шляхом вхідного запиту. Зараз він може містити символи, не дозволені в традиційній частині "path" URL, як визначено в RFC 3986. Шляхи повинні починатися з '/' і повинні бути присутніми при використанні PathType зі значенням "Exact" або "Prefix".

  • tls ([]IngressTLS)

    Atomic: буде замінено під час злиття

    tls представляє конфігурацію TLS. Зараз Ingress підтримує лише один TLS-порт, 443. Якщо декілька елементів цього списку вказують різні хости, вони будуть мультиплексовані на одному і тому ж порту відповідно до імені хосту, зазначеного через розширення SNI TLS, якщо контролер Ingress, що виконує Ingress, підтримує SNI.

    IngressTLS описує транспортний рівень безпеки, повʼязаний з ingress.

    • tls.hosts ([]string)

      Atomic: буде замінено під час злиття

      hosts — це список хостів, включених у сертифікат TLS. Значення в цьому списку повинні відповідати іменам, використаним у tlsSecret. Типово відповідає стандартним налаштуванням хосту для контролера балансування навантаження, що виконує цей Ingress, якщо залишено незазначеним.

    • tls.secretName (string)

      secretName — це імʼя Secret, який використовується для завершення TLS-трафіку на порту 443. Поле залишено необовʼязковим, щоб дозволити маршрутизацію TLS на основі лише імені хосту SNI. Якщо хост SNI у слухачі конфліктує з полем "Host" у заголовку, використаному IngressRule, хост SNI використовується для завершення, а значення поля "Host" використовується для маршрутизації.

IngressBackend

IngressBackend описує всі точки доступу для вказаного Service і порту.


  • resource (TypedLocalObjectReference)

    resource — є ObjectRef на інший ресурс Kubernetes у просторі імен обʼєкта Ingress. Якщо вказано resource, не можна вказувати service.Name та service.Port. Це взаємозаперечне налаштування з "Service".

  • service (IngressServiceBackend)

    service — посилається на Service як на бекенд. Це взаємозаперечне налаштування з "Resource".

    IngressServiceBackend посилається на Kubernetes Service як на Backend.

    • service.name (string), обовʼязкове

      name — це посилання на сервіс. Сервіс повинен існувати в тому ж просторі імен, що й обʼєкт Ingress.

    • service.port (ServiceBackendPort)

      port вказаного сервіс. Для IngressServiceBackend потрібно вказати імʼя порту або номер порту.

      ServiceBackendPort — це порт сервісу, на який посилаються.

      • service.port.name (string)

        name — це імʼя порту на сервісі. Це взаємозаперечне налаштування з "Number".

      • service.port.number (int32)

        number — це числовий номер порту (наприклад, 80) на сервісі. Це взаємозаперечне налаштування з "Name".

IngressStatus

IngressStatus описує поточний стан Ingress.


  • loadBalancer (IngressLoadBalancerStatus)

    loadBalancer містить поточний статус балансувальника навантаження.

    IngressLoadBalancerStatus представляє статус балансувальника навантаження.

    • loadBalancer.ingress ([]IngressLoadBalancerIngress)

      Atomic: буде замінено під час злиття

      ingress — це список точок входу для балансувальника навантаження.

      IngressLoadBalancerIngress представляє статус точки входу балансувальника навантаження.

      • loadBalancer.ingress.hostname (string)

        hostname встановлюється для точок входу балансувальника навантаження, які базуються на DNS.

      • loadBalancer.ingress.ip (string)

        ip встановлюється для точок входу балансувальника навантаження, які базуються на IP.

      • loadBalancer.ingress.ports ([]IngressPortStatus)

        Atomic: буде замінено під час злиття

        ports надає інформацію про порти, які відкриті цим балансувальником навантаження.

        IngressPortStatus представляє стан помилки порту сервісу.

        • loadBalancer.ingress.ports.port (int32), обовʼязкове

          port — це номер порту точки входу.

        • loadBalancer.ingress.ports.protocol (string), обовʼязкове

          protocol — це протокол порту точки входу. Підтримувані значення: "TCP", "UDP", "SCTP".

        • loadBalancer.ingress.ports.error (string)

          error використовується для запису проблеми з портом сервісу. Формат помилки має відповідати наступним правилам:

          • вбудовані значення помилок повинні бути зазначені в цьому файлі та повинні використовувати CamelCase імена;
          • значення помилок, специфічні для хмарного провайдера, повинні мати імена, які відповідають формату foo.example.com/CamelCase.

IngressList

IngressList — це колекція Ingress.


Операції


get отримати вказаний Ingress

HTTP запит

GET /apis/networking.k8s.io/v1/namespaces/{namespace}/ingresses/{name}

Параметри

  • name (в шляху): string, обовʼязковий

    назва Ingress

  • namespace (в шляху): string, обовʼязковий

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (Ingress): OK

401: Unauthorized

get отримати статус вказаного Ingress

HTTP запит

GET /apis/networking.k8s.io/v1/namespaces/{namespace}/ingresses/{name}/status

Параметри

  • name (в шляху): string, обовʼязковий

    назва Ingress

  • namespace (в шляху): string, обовʼязковий

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (Ingress): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу Ingress

HTTP запит

GET /apis/networking.k8s.io/v1/namespaces/{namespace}/ingresses

Параметри

Відповідь

200 (IngressList): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу Ingress

HTTP запит

GET /apis/networking.k8s.io/v1/ingresses

Параметри

Відповідь

200 (IngressList): OK

401: Unauthorized

create створення Ingress

HTTP запит

POST /apis/networking.k8s.io/v1/namespaces/{namespace}/ingresses

Параметри

  • namespace (в шляху): string, обовʼязковий

    namespace

  • body: Ingress, обовʼязковий

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (Ingress): OK

201 (Ingress): Created

202 (Ingress): Accepted

401: Unauthorized

update заміна вказаного Ingress

HTTP запит

PUT /apis/networking.k8s.io/v1/namespaces/{namespace}/ingresses/{name}

Параметри

  • name (в шляху): string, обовʼязковий

    назва Ingress

  • namespace (в шляху): string, обовʼязковий

    namespace

  • body: Ingress, обовʼязковий

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (Ingress): OK

201 (Ingress): Created

401: Unauthorized

update заміна статусу вказаного Ingress

HTTP запит

PUT /apis/networking.k8s.io/v1/namespaces/{namespace}/ingresses/{name}/status

Параметри

  • name (в шляху): string, обовʼязковий

    назва Ingress

  • namespace (в шляху): string, обовʼязковий

    namespace

  • body: Ingress, обовʼязковий

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (Ingress): OK

201 (Ingress): Created

401: Unauthorized

patch часткове оновлення вказаного Ingress

HTTP запит

PATCH /apis/networking.k8s.io/v1/namespaces/{namespace}/ingresses/{name}

Параметри

  • name (в шляху): string, обовʼязковий

    назва Ingress

  • namespace (в шляху): string, обовʼязковий

    namespace

  • body: Ingress, обовʼязковий

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (Ingress): OK

201 (Ingress): Created

401: Unauthorized

patch часткове оновлення статусу вказаного Ingress

HTTP запит

PATCH /apis/networking.k8s.io/v1/namespaces/{namespace}/ingresses/{name}/status

Параметри

  • name (в шляху): string, обовʼязковий

    назва Ingress

  • namespace (в шляху): string, обовʼязковий

    namespace

  • body: Ingress, обовʼязковий

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (Ingress): OK

201 (Ingress): Created

401: Unauthorized

delete видалення Ingress

HTTP запит

DELETE /apis/networking.k8s.io/v1/namespaces/{namespace}/ingresses/{name}

Параметри

  • name (в шляху): string, обовʼязковий

    назва Ingress

  • namespace (в шляху): string, обовʼязковий

    namespace

  • body: Ingress, обовʼязковий

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції Ingress

HTTP запит

DELETE /apis/networking.k8s.io/v1/namespaces/{namespace}/ingresses

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

6.5.2.5 - IngressClass

IngressClass представляє клас Ingress, на який посилається Ingress Spec.

apiVersion: networking.k8s.io/v1

import "k8s.io/api/networking/v1"

IngressClass

IngressClass представляє клас Ingress, на який посилається Ingress Spec. Анотацію ingressclass.kubernetes.io/is-default-class можна використовувати, щоб вказати, що IngressClass слід вважати стандартним класом. Коли для одного ресурсу IngressClass ця анотація має значення true, новим ресурсам Ingress без вказаного класу буде присвоєно цей клас.


IngressClassSpec

IngressClassSpec надає інформацію про клас Ingress.


  • controller (string)

    controller вказує на імʼя контролера, який має обробляти цей клас. Це дозволяє використовувати різні "різновиди", керовані тим самим контролером. Наприклад, для одного імплементованого контролера можуть існувати різні параметри. Це повинно бути вказане як шлях з префіксом домену, не довше ніж 250 символів, наприклад, "acme.io/ingress-controller". Це поле є незмінним.

  • parameters (IngressClassParametersReference)

    parameters це посилання на спеціалізований ресурс, що містить додаткову конфігурацію для контролера. Це необовʼязково, якщо контролер не вимагає додаткових параметрів.

    IngressClassParametersReference ідентифікує обʼєкт API. Це може бути використано для вказівки на обʼєкт, що належить кластеру або області простору імен.

    • parameters.kind (string), обовʼязково

      kind це тип ресурсу, на який вказується посилання.

    • parameters.name (string), обовʼязково

      name це імʼя ресурсу, на який вказується посилання.

    • parameters.apiGroup (string)

      apiGroup це група для ресурсу, на який вказується посилання. Якщо apiGroup не вказано, вказаний Kind повинен бути в основній групі API. Для будь-яких інших типів сторонніх ресурсів apiGroup є обовʼязковим.

    • parameters.namespace (string)

      namespace це простір імен для ресурсу, на який вказується посилання. Це поле обовʼязкове, коли scope встановлено на "Namespace", і його не слід встановлювати, коли scope встановлено у "Cluster".

    • parameters.scope (string)

      scope вказує на те, чи відноситься ресурс до кластера або простору імен. Цей параметр може мати значення "Cluster" (типово) або "Namespace".

IngressClassSpec

IngressClassSpec надає інформацію про клас Ingress.


  • controller (string)

    controller вказує на імʼя контролера, який повинен обробляти цей клас. Це дозволяє використовувати різні "різновиди", які контролюються тим самим контролером. Наприклад, у вас можуть бути різні параметри для одного й того ж імплементаційного контролера. Це повинно бути вказано як шлях з префіксом домену довжиною не більше 250 символів, наприклад, "acme.io/ingress-controller". Це поле є незмінним.

  • parameters (IngressClassParametersReference)

    parameters це посилання на власний ресурс, що містить додаткову конфігурацію для контролера. Це необовʼязково, якщо контролер не потребує додаткових параметрів.

    IngressClassParametersReference ідентифікує обʼєкт API. Це може бути використано для {#list-list-or-watch-objects-of-kind-ingressclass}вказівки на ресурс, обмежений кластером або простором імен. {#http-request-1}

    • parameters.kind (string), обовʼязково

      kind це тип ресурсу, на який вказується посилання. {#parameters-1}

    • parameters.name (string), обовʼязково

      name це імʼя ресурсу, на який вказується посилання.

    • parameters.apiGroup (string)

      apiGroup це група для ресурсу, на який вказується посилання. Якщо apiGroup не вказано, вказаний Kind повинен належати до основної групи API. Для будь-яких інших типів сторонніх ресурсів apiGroup є обовʼязковим.

    • parameters.namespace (string)

      namespace це простір імен для ресурсу, на який вказується посилання. Це поле є обовʼязковим, коли scope встановлено на "Namespace", і його не слід встановлювати, коли scope встановлено на "Cluster".

    • parameters.scope (string)

      scope вказує, чи це посилання на ресурс, обмежений кластером або простором імен. Це може бути встановлено на "Cluster" (стандартно) або "Namespace".

IngressClassList

IngressClassList є колекцією IngressClasses.


  • apiVersion: networking.k8s.io/v1

  • kind: IngressClassList

  • metadata (ListMeta)

    Стандартні метадані списку.

  • items ([]IngressClass), обовʼязково

    items це список IngressClasses.

Операції


get отримати вказаний IngressClass

HTTP запит

GET /apis/networking.k8s.io/v1/ingressclasses/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя IngressClass

  • pretty (в запиті): string

    pretty

Відповідь

200 (IngressClass): ОК

401: Unauthorized

list перелік або перегляд обʼєктів типу IngressClass

HTTP запит

GET /apis/networking.k8s.io/v1/ingressclasses

Параметри

Відповідь

200 (IngressClassList): ОК

401: Unauthorized

create створення IngressClass

HTTP запит

POST /apis/networking.k8s.io/v1/ingressclasses

Параметри

Відповідь

200 (IngressClass): ОК

201 (IngressClass): Created

202 (IngressClass): Accepted

401: Unauthorized

update заміна вказаного IngressClass

HTTP запит

PUT /apis/networking.k8s.io/v1/ingressclasses/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя IngressClass

  • body: IngressClass, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (IngressClass): ОК

201 (IngressClass): Created

401: Unauthorized

patch часткове оновлення вказаного IngressClass

HTTP запит

PATCH /apis/networking.k8s.io/v1/ingressclasses/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя IngressClass

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (IngressClass): ОК

201 (IngressClass): Created

401: Unauthorized

delete видалення IngressClass

HTTP запит

DELETE /apis/networking.k8s.io/v1/ingressclasses/{name}

Параметри

Відповідь

200 (Status): ОК

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції IngressClass

HTTP запит

DELETE /apis/networking.k8s.io/v1/ingressclasses

Параметри

Відповідь

200 (Status): ОК

401: Unauthorized

6.5.3 - Ресурси конфігурації та зберігання

6.5.3.1 - ConfigMap

ConfigMap містить конфігураційні дані, які використовуються Podʼами.

apiVersion: v1

import "k8s.io/api/core/v1"

ConfigMap

ConfigMap містить конфігураційні дані, які використовуються Podʼами.


  • apiVersion: v1

  • kind: ConfigMap

  • metadata (ObjectMeta)

    Стандартні метадані обʼєкта. Детальніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

  • binaryData (map[string][]byte)

    BinaryData містить бінарні дані. Кожен ключ повинен складатися з алфавітно-цифрових символів, '-', '_' або '.'. BinaryData може містити байтові послідовності, які не належать до діапазону UTF-8. Ключі, що зберігаються у BinaryData, не повинні збігатися з ключами у полі Data, це перевіряється під час валідації. Використання цього поля вимагатиме apiserver та kubelet версії 1.10+.

  • data (map[string]string)

    Data містить конфігураційні дані. Кожен ключ повинен складатися з алфавітно-цифрових символів, '-', '_' або '.'. Значення з байтовими послідовностями, що не належать до діапазону UTF-8, повинні використовувати поле BinaryData. Ключі, що зберігаються у Data, не повинні збігатися з ключами у полі BinaryData, це перевіряється під час валідації.

  • immutable (boolean)

    Immutable, якщо встановлено в true, гарантує, що дані, збережені у ConfigMap, не можуть бути оновлені (можна змінювати лише метадані обʼєкта). Якщо не встановлено в true, поле можна змінити у будь-який час. Стандартне значення — nil.

ConfigMapList

ConfigMapList — це ресурс, що містить список обʼєктів ConfigMap.


Операції


get отримати вказаний ConfigMap

HTTP запит

GET /api/v1/namespaces/{namespace}/configmaps/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва ConfigMap

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (ConfigMap): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу ConfigMap

HTTP запит

GET /api/v1/namespaces/{namespace}/configmaps

Параметри

Відповідь

200 (ConfigMapList): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу ConfigMap

HTTP запит

GET /api/v1/configmaps

Параметри

Відповідь

200 (ConfigMapList): OK

401: Unauthorized

create створення ConfigMap

HTTP запит

POST /api/v1/namespaces/{namespace}/configmaps

Параметри

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: ConfigMap, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (ConfigMap): OK

201 (ConfigMap): Created

202 (ConfigMap): Accepted

401: Unauthorized

update заміна вказаного ConfigMap

HTTP запит

PUT /api/v1/namespaces/{namespace}/configmaps/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва ConfigMap

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: ConfigMap, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (ConfigMap): OK

201 (ConfigMap): Created

401: Unauthorized

patch часткове оновлення вказаного ConfigMap

HTTP запит

PATCH /api/v1/namespaces/{namespace}/configmaps/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва ConfigMap

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (ConfigMap): OK

201 (ConfigMap): Created

401: Unauthorized

delete видалення ConfigMap

HTTP запит

DELETE /api/v1/namespaces/{namespace}/configmaps/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва ConfigMap

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції ConfigMap

HTTP запит

DELETE /api/v1/namespaces/{namespace}/configmaps

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

6.5.3.2 - Secret

Secret зберігає секретні дані певного типу.

apiVersion: v1

import "k8s.io/api/core/v1"

Secret

Secret зберігає секретні дані певного типу. Загальна кількість байт значень у полі Data має бути меншою за MaxSecretSize.


  • apiVersion: v1

  • kind: Secret

  • metadata (ObjectMeta)

    Стандартні метадані обʼєкта. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

  • data (map[string][]byte)

    Data містить секретні дані. Кожен ключ повинен складатися з алфавітно-цифрових символів, '-', '_' або '.'. Сериалізована форма секретних даних є рядком, закодованим у base64, що представляє довільне (можливо, не рядкове) значення даних. Описано в https://tools.ietf.org/html/rfc4648#section-4.

  • immutable (boolean)

    Immutable, якщо встановлено в true, гарантує, що дані, збережені в Secret, не можуть бути оновлені (можна змінювати лише метадані обʼєкта). Якщо не встановлено в true, поле можна змінити у будь-який час. Стандартне значення — nil.

  • stringData (map[string]string)

    stringData дозволяє вказувати небінарні секретні дані у вигляді рядків. Це поле надається як поле вводу лише для запису для зручності. Усі ключі та значення обʼєднуються в поле data при записі, перезаписуючи будь-які наявні значення. Поле stringData ніколи не виводиться при читанні з API.

  • type (string)

    Використовується для полегшення програмної обробки секретних даних. Більше інформації: https://kubernetes.io/docs/concepts/configuration/secret/#secret-types.

SecretList

SecretList — це список обʼєктів Secret.


Операції


get отримати вказаний Secret

HTTP запит

GET /api/v1/namespaces/{namespace}/secrets/{name}

Параметри

  • name (в шляху): string, обовʼязково

    name of the Secret

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Response

200 (Secret): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу Secret

HTTP запит

GET /api/v1/namespaces/{namespace}/secrets

Параметри

Response

200 (SecretList): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу Secret

HTTP запит

GET /api/v1/secrets

Параметри

Response

200 (SecretList): OK

401: Unauthorized

create створення Secret

HTTP запит

POST /api/v1/namespaces/{namespace}/secrets

Параметри

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Secret, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Response

200 (Secret): OK

201 (Secret): Created

202 (Secret): Accepted

401: Unauthorized

update заміна вказаного Secret

HTTP запит

PUT /api/v1/namespaces/{namespace}/secrets/{name}

Параметри

  • name (в шляху): string, обовʼязково

    name of the Secret

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Secret, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Response

200 (Secret): OK

201 (Secret): Created

401: Unauthorized

patch часткове оновлення вказаного Secret

HTTP запит

PATCH /api/v1/namespaces/{namespace}/secrets/{name}

Параметри

  • name (в шляху): string, обовʼязково

    name of the Secret

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Response

200 (Secret): OK

201 (Secret): Created

401: Unauthorized

delete видалення Secret

HTTP запит

DELETE /api/v1/namespaces/{namespace}/secrets/{name}

Параметри

  • name (в шляху): string, обовʼязково

    name of the Secret

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Response

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції Secret

HTTP запит

DELETE /api/v1/namespaces/{namespace}/secrets

Параметри

Response

200 (Status): OK

401: Unauthorized

6.5.3.3 - CSIDriver

CSIDriver збирає інформацію про драйвер тома Container Storage Interface (CSI), розгорнутий в кластері.

apiVersion: storage.k8s.io/v1

import "k8s.io/api/storage/v1"

CSIDriver

CSIDriver збирає інформацію про драйвер тому Container Storage Interface (CSI), розгорнутий в кластері. Контролер приєднання та відʼєднання Kubernetes використовує цей обʼєкт для визначення необхідності приєднання. Kubelet використовує цей обʼєкт, щоб визначити, чи потрібно передавати інформацію про контейнер при монтуванні. Обʼєкти CSIDriver не має простору імен.


  • apiVersion: storage.k8s.io/v1

  • kind: CSIDriver

  • metadata (ObjectMeta)

    Стандартні метадані обʼєкта. metadata.Name вказує назву драйвера CSI, до якого відноситься цей обʼєкт; вона МАЄ бути такою ж, як імʼя, яке повертає виклик CSI GetPluginName() для цього драйвера. Назва драйвера повинна бути не більше 63 символів, починатися і закінчуватися алфавітно-цифровим символом ([a-z0-9A-Z]), з тире (-), крапками (.) та алфавітно-цифровими символами між ними. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

  • spec (CSIDriverSpec), обовʼязково

    spec представляє специфікацію драйвера CSI.

CSIDriverSpec

CSIDriverSpec — це специфікація CSIDriver.


  • attachобовʼязково (boolean)

    attachобовʼязково вказує, що цей драйвер томів CSI вимагає операцію приєднання (оскільки він реалізує метод CSI ControllerPublishVolume()), і що контролер приєднання та відʼєднання Kubernetes повинен викликати інтерфейс приєднання томів, який перевіряє статус VolumeAttachment і чекає, поки том буде приєднано, перед тим як перейти до монтування. Зовнішній attacher CSI координується з драйвером томів CSI та оновлює статус VolumeAttachment після завершення операції приєднання. Якщо увімкнено функцію CSIDriverRegistry і значення встановлено на false, операція приєднання буде пропущена. В іншому випадку операція приєднання буде викликана.

    Це поле незмінне.

  • fsGroupPolicy (string)

    fsGroupPolicy визначає, чи підтримує базовий том зміну власності та дозволів на том перед монтуванням. Додаткову інформацію дивіться у конкретних значеннях FSGroupPolicy.

    Це поле було незмінним в Kubernetes < 1.29, тепер воно є змінним.

    Стандартне значення ReadWriteOnceWithFSType, що дозволяє перевірити кожен том, щоб визначити, чи повинен Kubernetes змінювати власність і дозволи на том. Зі стандартною політикою визначена fsGroup буде застосована лише, якщо визначено fstype і режим доступу тому містить ReadWriteOnce.

  • podInfoOnMount (boolean)

    podInfoOnMount вказує, що цей драйвер томів CSI вимагає додаткову інформацію про Pod (наприклад, podName, podUID тощо) під час операцій монтування, якщо встановлено true. Якщо встановлено false, інформація про Pod не буде передаватися під час монтування. Стандартне значення — false.

    Драйвер CSI визначає podInfoOnMount як частину розгортання драйвера. Якщо true, Kubelet передаватиме інформацію про Pod як VolumeContext у викликах CSI NodePublishVolume(). Драйвер CSI відповідає за розбір та перевірку інформації, переданої як VolumeContext.

    Наступний VolumeContext буде передано, якщо podInfoOnMount встановлено в true. Цей список може розширюватися, але буде використовуватися префікс. "csi.storage.k8s.io/pod.name": pod.Name "csi.storage.k8s.io/pod.namespace": pod.Namespace "csi.storage.k8s.io/pod.uid": string(pod.UID) "csi.storage.k8s.io/ephemeral": "true", якщо том є ефемерним інлайн-томом, визначеним CSIVolumeSource, в іншому випадку "false"

    "csi.storage.k8s.io/ephemeral" — це нова функція в Kubernetes 1.16. Вона потрібна лише для драйверів, які підтримують як "Persistent", так і "Ephemeral" VolumeLifecycleMode. Інші драйвери можуть залишити інформацію про Podʼи вимкненою та/або ігнорувати це поле. Оскільки Kubernetes 1.15 не підтримує це поле, драйвери можуть підтримувати лише один режим під час розгортання на такому кластері, і Deployment визначає, який режим це буде, наприклад, через параметр командного рядка драйвера.

    Це поле було незмінним в Kubernetes < 1.29, тепер воно є змінним.

  • requiresRepublish (boolean)

    requiresRepublish вказує, що драйвер CSI хоче, щоб NodePublishVolume періодично викликали, щоб відобразити будь-які можливі зміни у змонтованому томі. Стандартне значення цього поля — false.

    Примітка: після успішного початкового виклику NodePublishVolume наступні виклики NodePublishVolume повинні лише оновлювати вміст тому. Нові точки монтування не будуть видимі для запущеного контейнера.

  • seLinuxMount (boolean)

    seLinuxMount визначає, чи підтримує драйвер CSI опцію монтування "-o context".

    Коли "true", драйвер CSI повинен забезпечити, щоб усі томи, надані цим драйвером CSI, могли монтуватися окремо з різними параметрами -o context. Це типово для сховищ, які надають томи як файлові системи на блокових пристроях або як незалежні загальні томи. Kubernetes викликатиме NodeStage / NodePublish з параметром монтування "-o context=xyz" при монтуванні тому ReadWriteOncePod, який використовується в Pod, що явно встановив контекст SELinux. У майбутньому це може бути розширено до інших режимів доступу до томів. У будь-якому випадку Kubernetes забезпечить, щоб том монтувався лише з одним контекстом SELinux.

    Коли "false", Kubernetes не передаватиме жодних спеціальних параметрів монтування SELinux драйверу. Це типово для томів, які представляють підтеки більшої спільної файлової системи.

    Стандартне значення — "false".

  • storageCapacity (boolean)

    storageCapacity вказує, що драйвер томів CSI хоче, щоб планування Podʼів враховувало обсяг сховища, який буде повідомлено під час розгортання драйвера шляхом створення обʼєктів CSIStorageCapacity з інформацією про місткість, якщо встановлено true.

    Перевірку можна ввімкнути відразу під час розгортання драйвера. У цьому випадку створення нових томів з відкладеним привʼязуванням зупиниться, доки Deployment драйвера не опублікує деякий відповідний обʼєкт CSIStorageCapacity.

    Альтернативно, драйвер можна розгорнути з невстановленим або false полем, і його можна змінити пізніше, коли буде опубліковано інформацію про місткість сховища.

    Це поле було незмінним у Kubernetes <= 1.22 і тепер воно є змінним.

  • tokenRequests ([]TokenRequest)

    Atomic: буде замінено під час злиття

    tokenRequests вказує, що драйвер CSI потребує токенів службових облікових записів Podʼів, для яких він монтує том, для необхідної автентифікації. Kubelet передасть токени у VolumeContext у викликах CSI NodePublishVolume. Драйвер CSI повинен розбирати та перевіряти наступний VolumeContext:

    "csi.storage.k8s.io/serviceAccount.tokens": {
      "<audience>": {
        "token": <token>,
        "expirationTimestamp": <expiration timestamp in RFC3339>,
      },
      ...
    }
    

    Примітка: Аудиторія в кожному запиті токена повинна бути різною, і не більше одного токена має бути пустим рядком. Для отримання нового токена після закінчення терміну дії можна використовувати RequiresRepublish для періодичного виклику NodePublishVolume.

    TokenRequest містить параметри токена службового облікового запису.

    • tokenRequests.audience (string), обовʼязково

      audience — це призначена аудиторія токена в "TokenRequestSpec". Стандартно це аудиторії kube apiserver.

    • tokenRequests.expirationSeconds (int64)

      expirationSeconds — це тривалість дії токена в "TokenRequestSpec". Має таке ж стандартне значення, як "ExpirationSeconds" у "TokenRequestSpec".

  • volumeLifecycleModes ([]string)

    Set: унікальні значення будуть збережені під час злиття

    volumeLifecycleModes визначає, які типи томів підтримує цей драйвер томів CSI. Стандартно, якщо список порожній, це "Persistent", що визначено специфікацією CSI та реалізовано в Kubernetes через звичайний механізм PV/PVC.

    Інший режим — "Ephemeral". У цьому режимі томи визначаються інлайн у специфікації Podʼа за допомогою CSIVolumeSource, і їх життєвий цикл повʼязаний з життєвим циклом цього Podʼа. Драйвер повинен бути обізнаний про це, оскільки він отримає лише виклик NodePublishVolume для такого тому.

    Для отримання додаткової інформації про реалізацію цього режиму див. https://kubernetes-csi.github.io/docs/ephemeral-local-volumes.html. Драйвер може підтримувати один або кілька цих режимів, і в майбутньому можуть бути додані інші режими.

    Це поле знаходиться у стадії бета. Це поле незмінне.

CSIDriverList

CSIDriverList — це колекція обʼєктів CSIDriver.


Операції


get отримати вказаний CSIDriver

HTTP запит

GET /apis/storage.k8s.io/v1/csidrivers/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя CSIDriver

  • pretty (в запиті): string

    pretty

Відповідь

200 (CSIDriver): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу CSIDriver

HTTP запит

GET /apis/storage.k8s.io/v1/csidrivers

Параметри

Відповідь

200 (CSIDriverList): OK

401: Unauthorized

create створення CSIDriver

HTTP запит

POST /apis/storage.k8s.io/v1/csidrivers

Параметри

Відповідь

200 (CSIDriver): OK

201 (CSIDriver): Created

202 (CSIDriver): Accepted

401: Unauthorized

update заміна вказаного CSIDriver

HTTP запит

PUT /apis/storage.k8s.io/v1/csidrivers/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя CSIDriver

  • body: CSIDriver, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (CSIDriver): OK

201 (CSIDriver): Created

401: Unauthorized

patch часткове оновлення вказаного CSIDriver

HTTP запит

PATCH /apis/storage.k8s.io/v1/csidrivers/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя CSIDriver

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (CSIDriver): OK

201 (CSIDriver): Created

401: Unauthorized

delete видалення CSIDriver

HTTP запит

DELETE /apis/storage.k8s.io/v1/csidrivers/{name}

Параметри

Відповідь

200 (CSIDriver): OK

202 (CSIDriver): Accepted

401: Unauthorized

deletecollection видалення колекції CSIDriver

HTTP запит

DELETE /apis/storage.k8s.io/v1/csidrivers

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

6.5.3.4 - CSINode

CSINode містить інформацію про всі драйвери CSI, встановлені на вузлі.

apiVersion: storage.k8s.io/v1

import "k8s.io/api/storage/v1"

CSINode

CSINode містить інформацію про всі драйвери CSI, встановлені на вузлі. Драйверам CSI не потрібно створювати обʼєкт CSINode безпосередньо. Якщо вони використовують sidecar контейнер node-driver-registrar, kubelet автоматично заповнить обʼєкт CSINode для драйвера CSI під час реєстрації втулка kubelet. CSINode має ту ж назву, що і вузол. Якщо обʼєкт відсутній, це означає, що або на вузлі немає доступних драйверів CSI, або версія Kubelet є достатньо низькою, щоб не створювати цей обʼєкт. CSINode має OwnerReference, яке вказує на відповідний обʼєкт вузла.


  • apiVersion: storage.k8s.io/v1

  • kind: CSINode

  • metadata (ObjectMeta)

    Стандартні метадані обʼєкта. metadata.name має бути назвою вузла Kubernetes.

  • spec (CSINodeSpec)

    spec — це специфікація CSINode

CSINodeSpec

CSINodeSpec містить інформацію про специфікації всіх драйверів CSI, встановлених на вузлі.


  • drivers ([]CSINodeDriver), обовʼязково

    Patch strategy: злиття за ключем name

    Map: унікальні значення ключа name будуть збережені під час злиття

    drivers — це список інформації про всі драйвери CSI, які існують на вузлі. Якщо всі драйвери в списку видалено, цей список може бути порожнім.

    CSINodeDriver містить інформацію про специфікацію одного драйвера CSI, встановленого на вузлі

    • drivers.name (string), обовʼязково

      name представляє імʼя драйвера CSI, до якого відноситься цей обʼєкт. Це МАЄ бути те саме імʼя, яке повертає виклик CSI GetPluginName() для цього драйвера.

    • drivers.nodeID (string), обовʼязково

      nodeID вузла з погляду драйвера. Це поле дозволяє Kubernetes взаємодіяти з системами зберігання, які не використовують ту ж номенклатуру для вузлів. Наприклад, Kubernetes може називати вузол "node1", але система зберігання може називати той самий вузол "nodeA". Коли Kubernetes видає команду системі зберігання для приєднання тому до конкретного вузла, він може використовувати це поле для посилання на імʼя вузла за допомогою ID, який зрозуміє система зберігання, наприклад "nodeA" замість "node1". Це поле обовʼязкове.

    • drivers.allocatable (VolumeNodeResources)

      allocatable представляє ресурс тому вузла, доступний для планування. Це поле є бета-версією.

      VolumeNodeResources — це набір обмежень ресурсів для планування томів.

      • drivers.allocatable.count (int32)

        count вказує максимальну кількість унікальних томів, що керуються драйвером CSI, які можна використовувати на вузлі. Том, який одночасно приєднаний і змонтований на вузлі, вважається використаним один раз, а не двічі. Те саме правило застосовується до унікального тому, який розділяється між кількома Podʼами на одному вузлі. Якщо це поле не вказано, то кількість підтримуваних томів на цьому вузлі не обмежена.

    • drivers.topologyKeys ([]string)

      Atomic: буде замінено під час злиття

      topologyKeys — це список ключів, підтримуваних драйвером. Коли драйвер ініціалізується в кластері, він надає набір ключів топології, які він розуміє (наприклад, "company.com/zone", "company.com/region"). Коли драйвер ініціалізується на вузлі, він надає ті самі ключі топології разом зі значеннями. Kubelet відображатиме ці ключі топології як мітки на своєму власному обʼєкті вузла. Коли Kubernetes виконує планування з урахуванням топології, він може використовувати цей список для визначення, які мітки він повинен отримати з обʼєкта вузла та передати назад драйверу. Для різних вузлів можуть використовуватися різні ключі топології. Це поле може бути порожнім, якщо драйвер не підтримує топологію.

CSINodeList

CSINodeList — це колекція обʼєктів CSINode.


Операції


get отримати вказаний CSINode

HTTP запит

GET /apis/storage.k8s.io/v1/csinodes/{name}

Параметри

  • name (в шляху): string, обовʼязково

    name of the CSINode

  • pretty (в запиті): string

    pretty

Відповідь

200 (CSINode): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу CSINode

HTTP запит

GET /apis/storage.k8s.io/v1/csinodes

Параметри

Відповідь

200 (CSINodeList): OK

401: Unauthorized

create створення CSINode

HTTP запит

POST /apis/storage.k8s.io/v1/csinodes

Параметри

Відповідь

200 (CSINode): OK

201 (CSINode): Created

202 (CSINode): Accepted

401: Unauthorized

update заміна вказаного CSINode

HTTP запит

PUT /apis/storage.k8s.io/v1/csinodes/{name}

Параметри

  • name (в шляху): string, обовʼязково

    name of the CSINode

  • body: CSINode, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (CSINode): OK

201 (CSINode): Created

401: Unauthorized

patch часткове оновлення вказаного CSINode

HTTP запит

PATCH /apis/storage.k8s.io/v1/csinodes/{name}

Параметри

  • name (в шляху): string, обовʼязково

    name of the CSINode

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (CSINode): OK

201 (CSINode): Created

401: Unauthorized

delete видалення CSINode

HTTP запит

DELETE /apis/storage.k8s.io/v1/csinodes/{name}

Параметри

Відповідь

200 (CSINode): OK

202 (CSINode): Accepted

401: Unauthorized

deletecollection видалення колекції CSINode

HTTP запит

DELETE /apis/storage.k8s.io/v1/csinodes

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

6.5.3.5 - CSIStorageCapacity

CSIStorageCapacity зберігає результат одного виклику CSI GetCapacity.

apiVersion: storage.k8s.io/v1

import "k8s.io/api/storage/v1"

CSIStorageCapacity

CSIStorageCapacity зберігає результат одного виклику CSI GetCapacity. Для заданого StorageClass це описує доступну місткість у певному сегменті топології. Це можна використовувати під час розгляду місця для створення нових PersistentVolumes.

Наприклад, це може виражати такі речі:

  • StorageClass "standard" має "1234 GiB" доступних у "topology.kubernetes.io/zone=us-east1"
  • StorageClass "localssd" має "10 GiB" доступних у "kubernetes.io/hostname=knode-abc123"

Наступні три випадки означають, що місткість недоступна для певної комбінації:

  • не існує обʼєкта з відповідною топологією та імʼям класу зберігання
  • такий обʼєкт існує, але місткість не задана
  • такий обʼєкт існує, але місткість дорівнює нулю

Виробник цих обʼєктів може вирішити, який підхід є більш відповідним.

Вони споживаються планувальником kube-scheduler, коли драйвер CSI вибирає планування з урахуванням місткості за допомогою CSIDriverSpec.StorageCapacity. Планувальник порівнює MaximumVolumeSize із запитаним розміром очікуваних томів, щоб відфільтрувати невідповідні вузли. Якщо MaximumVolumeSize не задано, він повертається до порівняння з менш точною Capacity. Якщо і це не задано, планувальник припускає, що місткість недостатня, і пробує інший вузол.


  • apiVersion: storage.k8s.io/v1

  • kind: CSIStorageCapacity

  • metadata (ObjectMeta)

    Стандартні метадані обʼєкта. Імʼя не має особливого значення. Воно повинно бути піддоменом DNS (допускаються точки, 253 символи). Щоб уникнути конфліктів з іншими драйверами CSI у кластері, рекомендується використовувати csisc-<uuid>, згенероване імʼя або імʼя у зворотному порядку домену, яке закінчується унікальним імʼям драйвера CSI.

    Обʼєкти знаходяться в межах простору імен.

    Більше інформації: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

  • storageClassName (string), обовʼязково

    storageClassName представляє імʼя StorageClass, до якого відноситься звітна місткість. Воно повинно відповідати тим самим вимогам, що й імʼя обʼєкта StorageClass (не порожнє, піддомен DNS). Якщо цей обʼєкт більше не існує, обʼєкт CSIStorageCapacity застарів і повинен бути видалений його творцем. Це поле незмінне.

  • capacity (Quantity)

    capacity — це значення, яке повідомляє драйвер CSI у своєму GetCapacityResponse для GetCapacityRequest з топологією і параметрами, що відповідають попереднім полям.

    Семантика наразі (CSI spec 1.2) визначена як: доступна місткість у байтах сховища, яка може бути використана для створення томів. Якщо не задано, ця інформація наразі недоступна.

  • maximumVolumeSize (Quantity)

    maximumVolumeSize — це значення, яке повідомляє драйвер CSI у своєму GetCapacityResponse для GetCapacityRequest з топологією і параметрами, що відповідають попереднім полям.

    Це визначено починаючи з CSI spec 1.4.0 як найбільший розмір, який може бути використаний у полі CreateVolumeRequest.capacity_range.required_bytes для створення тому з тими самими параметрами, що й у GetCapacityRequest. Відповідне значення в API Kubernetes — це ResourceRequirements.Requests у запиті на том.

  • nodeTopology (LabelSelector)

    nodeTopology визначає, які вузли мають доступ до сховища, для якого була надана місткість. Якщо не задано, сховище недоступне з жодного вузла у кластері. Якщо порожнє, сховище доступне з усіх вузлів. Це поле незмінне.

CSIStorageCapacityList

CSIStorageCapacityList — це колекція обʼєктів CSIStorageCapacity.


Операції


get отримати вказаний CSIStorageCapacity

HTTP запит

GET /apis/storage.k8s.io/v1/namespaces/{namespace}/csistoragecapacities/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя CSIStorageCapacity

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (CSIStorageCapacity): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу CSIStorageCapacity

HTTP запит

GET /apis/storage.k8s.io/v1/namespaces/{namespace}/csistoragecapacities

Параметри

Відповідь

200 (CSIStorageCapacityList): OK

401: Unauthorized

list перелік або перегляд обʼєктів CSIStorageCapacity

HTTP запит

GET /apis/storage.k8s.io/v1/csistoragecapacities

Параметри

Відповідь

200 (CSIStorageCapacityList): OK

401: Unauthorized

create створення CSIStorageCapacity

HTTP запит

POST /apis/storage.k8s.io/v1/namespaces/{namespace}/csistoragecapacities

Параметри

Відповідь

200 (CSIStorageCapacity): OK

201 (CSIStorageCapacity): Created

202 (CSIStorageCapacity): Accepted

401: Unauthorized

update заміна вказаного CSIStorageCapacity

HTTP запит

PUT /apis/storage.k8s.io/v1/namespaces/{namespace}/csistoragecapacities/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя CSIStorageCapacity

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: CSIStorageCapacity, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (CSIStorageCapacity): OK

201 (CSIStorageCapacity): Created

401: Unauthorized

patch часткове оновлення вказаного CSIStorageCapacity

HTTP запит

PATCH /apis/storage.k8s.io/v1/namespaces/{namespace}/csistoragecapacities/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя CSIStorageCapacity

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (CSIStorageCapacity): OK

201 (CSIStorageCapacity): Created

401: Unauthorized

delete видалення CSIStorageCapacity

HTTP запит

DELETE /apis/storage.k8s.io/v1/namespaces/{namespace}/csistoragecapacities/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя CSIStorageCapacity

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції CSIStorageCapacity

HTTP запит

DELETE /apis/storage.k8s.io/v1/namespaces/{namespace}/csistoragecapacities

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

6.5.3.6 - PersistentVolumeClaim

PersistentVolumeClaim — це запит користувача на постійний том і заявка на нього.

apiVersion: v1

import "k8s.io/api/core/v1"

PersistentVolumeClaim

PersistentVolumeClaim представляє запит користувача на отримання та право на постійний том.


PersistentVolumeClaimSpec

PersistentVolumeClaimSpec описує загальні атрибути пристроїв зберігання та дозволяє вказувати джерело для атрибутів, специфічних для постачальника.


  • accessModes ([]string)

    Atomic: буде замінено під час злиття

    accessModes містить бажані режими доступу, якими повинен користуватися том. Додаткова інформація: https://kubernetes.io/docs/concepts/storage/persistent-volumes#access-modes-1

  • selector (LabelSelector)

    selector — це запит мітки для томів, які слід враховувати при звʼязуванні.

  • resources (VolumeResourceRequirements)

    resources представляє мінімальні ресурси, якими повинен володіти том. Якщо включено можливість RecoverVolumeExpansionFailure, користувачам дозволяється вказувати вимоги до ресурсів, які нижчі за попереднє значення, але все ще мають бути вищими, ніж місткість, вказана в полі статусу вимоги. Додаткова інформація: https://kubernetes.io/docs/concepts/storage/persistent-volumes#resources

    VolumeResourceRequirements описує вимоги до ресурсів збереження для томів.

    • resources.limits (map[string]Quantity)

      Limits описує максимальну кількість дозволених обчислювальних ресурсів. Додаткова інформація: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/

    • resources.requests (map[string]Quantity)

      Requests описує мінімальну кількість обчислювальних ресурсів, що потрібна. Якщо Requests відсутній для контейнера, він стандартно встановлюється як Limits, якщо це явно вказано, інакше — як значення, визначене реалізацією. Запити не можуть перевищувати Limits. Додаткова інформація: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/

  • volumeName (string)

    volumeName — це посилання на звʼязування з постійним томом, що підтримує цей запит.

  • storageClassName (string)

    storageClassName — це назва StorageClass, необхідного для вимоги. Додаткова інформація: https://kubernetes.io/docs/concepts/storage/persistent-volumes#class-1

  • volumeMode (string)

    volumeMode визначає тип тому, необхідного для вимоги. Значення Filesystem підтверджується, коли воно не включене у специфікацію вимоги.

Бета-рівень

  • dataSource (TypedLocalObjectReference)

    Поле dataSource може використовуватися для вказівки на:

    • Наявний обʼєкт VolumeSnapshot (snapshot.storage.k8s.io/VolumeSnapshot)
    • Наявний PVC (PersistentVolumeClaim)

    Якщо провайдер або зовнішній контролер може підтримувати вказане джерело даних, він створить новий том на основі вмісту вказаного джерела даних. Коли вмикається функціональна властивість AnyVolumeDataSource, вміст dataSource буде скопійовано до dataSourceRef, а вміст dataSourceRef буде скопійовано до dataSource, коли не вказано dataSourceRef.namespace. Якщо вказано простір імен, то dataSourceRef не буде скопійовано до dataSource.

  • dataSourceRef (TypedObjectReference)

    dataSourceRef вказує на обʼєкт, з якого потрібно заповнити том даними, якщо потрібний непорожній том. Це може бути будь-який обʼєкт з непорожньої API-групи (не базовий обʼєкт) або обʼєкт PersistentVolumeClaim. Коли вказано це поле, звʼязування тому вдасться тільки в тому випадку, якщо тип вказаного обʼєкта відповідає якомусь встановленому наповнювачу тому або динамічному провайдеру. Це поле замінить функціональність поля dataSource і як таке, якщо обидва поля непорожні, вони повинні мати однакове значення. Для забезпечення зворотної сумісності, коли простір імен не вказано в dataSourceRef, обидва поля (dataSource та dataSourceRef) будуть автоматично встановлені в одне значення, якщо одне з них порожнє, а інше — непорожнє. Коли простір імен вказаний в dataSourceRef, dataSource не встановлюється в те ж саме значення і повинно бути порожнім. Є три важливі відмінності між dataSource та dataSourceRef:

    • Поки dataSource дозволяє лише два конкретних типи обʼєктів, dataSourceRef дозволяє будь-які не базові обʼєкти, а також обʼєкти PersistentVolumeClaim.
    • Поки dataSource ігнорує заборонені значення (вилучаючи їх), dataSourceRef зберігає всі значення і генерує помилку, якщо вказано заборонене значення.
    • Поки dataSource дозволяє лише локальні обʼєкти, dataSourceRef дозволяє обʼєкти в будь-яких просторах імен.

    (Бета) Використання цього поля вимагає ввімкненої властивості AnyVolumeDataSource. (Альфа) Використання поля namespace у dataSourceRef вимагає ввімкненої властивості CrossNamespaceVolumeDataSource.

    **

    • dataSourceRef.kind (string), обовʼязково

      Kind — це тип ресурсу, на який вказується

    • dataSourceRef.name (string), обовʼязково

      Name — це назва ресурсу, на який вказується

    • dataSourceRef.apiGroup (string)

      APIGroup — це група для ресурсу, на який вказується. Якщо APIGroup не вказано, вказаний Kind повинен бути в базовій групі API. Для будь-яких інших сторонніх типів APIGroup обовʼязковий.

    • dataSourceRef.namespace (string)

      Namespace — це простір імен ресурсу, на який вказується. Зверніть увагу, що при вказанні простору імен для призначення namespace необхідний обʼєкт gateway.networking.k8s.io/ReferenceGrant в просторі імен-джерелі, щоб дозволити власнику цього простору імен приймати посилання. Див. документацію ReferenceGrant для отримання деталей. (Альфа) Це поле вимагає ввімкненої властивості CrossNamespaceVolumeDataSource.

  • volumeAttributesClassName (string)

    Поле volumeAttributesClassName може бути використане для встановлення VolumeAttributesClass, який буде використано заявкою. Якщо вказано, драйвер CSI створить або оновить том із атрибутами, визначеними у відповідному VolumeAttributesClass. Це поле має інше призначення, ніж storageClassName, і може бути змінене після створення заявки. Порожнє значення означає, що жоден VolumeAttributesClass не буде застосований до заявки, однак не можна скинути це поле на порожне значпння після його встановлення. Якщо не вказано і PersistentVolumeClaim не привʼязано до конкретного PersistentVolume, то контролер томів встановить стандартний VolumeAttributesClass, якщо він існує. Якщо ресурс, на який посилається volumeAttributesClass, не існує, PersistentVolumeClaim отримає стан Pending ("Очікування"), що буде відображено в полі modifyVolumeStatus, доки такий ресурс не зʼявиться. Докладніше: https://kubernetes.io/docs/concepts/storage/volume-attributes-classes/. (Beta) Використання цього поля вимагає ввімкнення функціональної можливості VolumeAttributesClass (стандартно вимкнено).

PersistentVolumeClaimStatus

PersistentVolumeClaimStatus — це поточний статус запиту на постійний том.


  • accessModes ([]string)

    Atomic: буде замінено під час злиття

    accessModes містить фактичні режими доступу, якими володіє том, що підтримує PVC. Додаткова інформація: https://kubernetes.io/docs/concepts/storage/persistent-volumes#access-modes-1

  • allocatedResourceStatuses (map[string]string)

    allocatedResourceStatuses зберігає статус ресурсу, який змінюється для даного PVC. Імена ключів відповідають стандартному синтаксису міток Kubernetes. Допустимі значення:

    • Ключі без префіксу:
      • storage — місткість тому.
    • Власні ресурси повинні використовувати визначені реалізацією префіксовані імена, наприклад, "example.com/my-custom-resource".

    Крім вищезазначених значень — ключі без префіксу або з префіксом kubernetes.io вважаються зарезервованими й, отже, не можуть використовуватися.

    ClaimResourceStatus може бути в одному з наступних станів:

    • ControllerResizeInProgress: Стан встановлюється, коли контролер зміни розміру починає змінювати розмір тому в панелі управління.
    • ControllerResizeFailed: Стан встановлюється, коли зміна розміру не вдалася у контролері зміни розміру з термінальною помилкою.
    • NodeResizePending: Стан встановлюється, коли контролер зміни розміру завершив зміну розміру тому, але подальша зміна розміру тому необхідна на вузлі.
    • NodeResizeInProgress: Стан встановлюється, коли kubelet починає змінювати розмір тому.
    • NodeResizeFailed: Стан встановлюється, коли зміна розміру не вдалася у kubelet з термінальною помилкою. Тимчасові помилки не встановлюють NodeResizeFailed.

    Наприклад, якщо PVC розширюється для більшої місткості, це поле може бути в одному з наступних станів:

    • pvc.status.allocatedResourceStatus['storage'] = "ControllerResizeInProgress"
    • pvc.status.allocatedResourceStatus['storage'] = "ControllerResizeFailed"
    • pvc.status.allocatedResourceStatus['storage'] = "NodeResizePending"
    • pvc.status.allocatedResourceStatus['storage'] = "NodeResizeInProgress"
    • pvc.status.allocatedResourceStatus['storage'] = "NodeResizeFailed"

    Якщо це поле не встановлено, це означає, що операція зміни розміру для даного PVC не виконується.

    Контролер, що отримує оновлення PVC з невідомим раніше resourceName або ClaimResourceStatus, повинен ігнорувати оновлення з метою, для якої він був створений. Наприклад, контролер, який відповідає лише за зміну розміру місткості тому, повинен ігнорувати оновлення PVC, які змінюють інші дійсні ресурси, повʼязані з PVC.

    Це поле альфа-версії та вимагає ввімкнення властивості RecoverVolumeExpansionFailure.

  • allocatedResources (map[string]Quantity)

    allocatedResources відстежує ресурси, виділені для PVC, включаючи його місткість. Імена ключів відповідають стандартному синтаксису міток Kubernetes. Допустимі значення:

    • Ключі без префіксу:
      • storage - місткість тому.
    • Власні ресурси повинні використовувати визначені реалізацією префіксовані імена, наприклад, "example.com/my-custom-resource"

    Крім вищезазначених значень — ключі без префіксу або з префіксом kubernetes.io вважаються зарезервованими й, отже, не можуть використовуватися.

    Місткість, зазначена тут, може бути більшою за фактичну місткість, коли запит на розширення тому виконується. Для квоти на зберігання використовується більше значення з allocatedResources і PVC.spec.resources. Якщо allocatedResources не встановлено, для розрахунку квоти використовується лише PVC.spec.resources. Якщо запит на розширення місткості тому знижено, allocatedResources знижується лише в тому випадку, якщо операції розширення не виконуються і якщо фактична місткість тому дорівнює або нижча за запитану місткість.

    Контролер, що отримує оновлення PVC з невідомим раніше resourceName, повинен ігнорувати оновлення з метою, для якої він був створений. Наприклад, контролер, який відповідає лише за зміну розміру місткості тому, повинен ігнорувати оновлення PVC, які змінюють інші дійсні ресурси, повʼязані з PVC.

    Це поле альфа-версії та вимагає ввімкнення властивості RecoverVolumeExpansionFailure.

  • capacity (map[string]Quantity)

    capacity представляє фактичні ресурси базового тому.

  • conditions ([]PersistentVolumeClaimCondition)

    Patch strategy: злиття за ключем type

    conditions — це поточний стан запиту на постійний том. Якщо базовий постійний том змінюється в розмірі, стан буде встановлено на 'Resizing'.

    PersistentVolumeClaimCondition містить деталі про стан pvc

    • conditions.status (string), обовʼязково

    • conditions.type (string), обовʼязково

    • conditions.lastProbeTime (Time)

      lastProbeTime - це час, коли ми обстежили стан.

      Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

    • conditions.lastTransitionTime (Time)

      lastTransitionTime — це час, коли стан перейшов з одного статусу до іншого.

      Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

    • conditions.message (string)

      message — це зрозуміле для людини повідомлення, що вказує на деталі останнього переходу.

    • conditions.reason (string)

      reason — це унікальний, короткий, зрозумілий для машини рядок, який вказує причину останнього переходу стану. Якщо він повідомляє "Resizing", це означає, що базовий постійний том змінюється в розмірі.

  • currentVolumeAttributesClassName (string)

    currentVolumeAttributesClassName — це поточна назва VolumeAttributesClass, яку використовує PVC. Якщо не встановлено, то до цього PersistentVolumeClaim не застосовано жодного VolumeAttributeClass. Це бета-поле і вимагає ввімкнення функції VolumeAttributesClass (стандартно вимкнена).

  • modifyVolumeStatus (ModifyVolumeStatus)

    ModifyVolumeStatus представляє обʼєкт статусу операції ControllerModifyVolume. Якщо не встановлено, спроба виконання операції ModifyVolume не відбувається. Це бета-поле і вимагає ввімкнення функції VolumeAttributesClass (стандартно вимкнена).

    ModifyVolumeStatus представляє обʼєкт стану операції ControllerModifyVolume.

    • modifyVolumeStatus.status (string), required

      status — це статус операції ControllerModifyVolume. Він може перебувати в одному з наступних станів:

      • Pending
        Pending вказує на те, що PersistentVolumeClaim не може бути змінений через невиконані вимоги, такі як відсутність вказаного VolumeAttributesClass.
      • InProgress
        InProgress вказує на те, що том наразі модифікується.
      • Infeasible
        Infeasible вказує на те, що запит було відхилено як недійсний драйвером CSI. Щоб усунути помилку, потрібно вказати дійсний VolumeAttributesClass.

      Примітка: Нові статуси можуть бути додані в майбутньому. Споживачі повинні перевіряти наявність невідомих статусів і відповідно обробляти помилки.

    • modifyVolumeStatus.targetVolumeAttributesClassName (string)

      targetVolumeAttributesClassName — імʼя класу VolumeAttributesClass, який зараз узгоджується з PVC

  • phase (string)

    phase представляє поточну фазу запиту на постійний том.

PersistentVolumeClaimList

PersistentVolumeClaimList — це список елементів PersistentVolumeClaim.


Операції


get отримати вказаний PersistentVolumeClaim

HTTP-запит

GET /api/v1/namespaces/{namespace}/persistentvolumeclaims/{name}

Параметри

  • name (в шляху): string, обовʼязковий

    імʼя PersistentVolumeClaim

  • namespace (в шляху): string, обовʼязковий

    простір імен

  • pretty (в запиті): string

    pretty

Відповідь

200 (PersistentVolumeClaim): OK

401: Unauthorized

get отримати статус вказаного PersistentVolumeClaim

HTTP-запит

GET /api/v1/namespaces/{namespace}/persistentvolumeclaims/{name}/status

Параметри

  • name (в шляху): string, обовʼязковий

    імʼя PersistentVolumeClaim

  • namespace (в шляху): string, обовʼязковий

    простір імен

  • pretty (в запиті): string

    pretty

Відповідь

200 (PersistentVolumeClaim): OK

401: Unauthorized

list перелік або спостереження за обʼєктами типу PersistentVolumeClaim

HTTP-запит

GET /api/v1/namespaces/{namespace}/persistentvolumeclaims

Параметри

Відповідь

200 (PersistentVolumeClaimList): OK

401: Unauthorized

list перелік або спостереження за обʼєктами типу PersistentVolumeClaim

HTTP-запит

GET /api/v1/persistentvolumeclaims

Параметри

Відповідь

200 (PersistentVolumeClaimList): OK

401: Unauthorized

create створити PersistentVolumeClaim

HTTP-запит

POST /api/v1/namespaces/{namespace}/persistentvolumeclaims

Параметри

Відповідь

200 (PersistentVolumeClaim): OK

201 (PersistentVolumeClaim): Created

202 (PersistentVolumeClaim): Accepted

401: Unauthorized

update замінити вказаний PersistentVolumeClaim

HTTP-запит

PUT /api/v1/namespaces/{namespace}/persistentvolumeclaims/{name}

Параметри

Відповідь

200 (PersistentVolumeClaim): OK

201 (PersistentVolumeClaim): Created

401: Unauthorized

update замінити статус вказаного PersistentVolumeClaim

HTTP-запит

PUT /api/v1/namespaces/{namespace}/persistentvolumeclaims/{name}/status

Параметри

Відповідь

200 (PersistentVolumeClaim): OK

201 (PersistentVolumeClaim): Created

401: Unauthorized

patch частково оновити вказаний PersistentVolumeClaim

HTTP-запит

PATCH /api/v1/namespaces/{namespace}/persistentvolumeclaims/{name}

Параметри

  • name (в шляху): string, обовʼязковий

    імʼя PersistentVolumeClaim

  • namespace (в шляху): string, обовʼязковий

    простір імен

  • body: Patch, обовʼязковий

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (PersistentVolumeClaim): OK

201 (PersistentVolumeClaim): Created

401: Unauthorized

patch частково оновити статус вказаного PersistentVolumeClaim

HTTP-запит

PATCH /api/v1/namespaces/{namespace}/persistentvolumeclaims/{name}/status

Параметри

  • name (в шляху): string, обовʼязковий

    імʼя PersistentVolumeClaim

  • namespace (в шляху): string, обовʼязковий

    простір імен

  • body: Patch, обовʼязковий

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (PersistentVolumeClaim): OK

201 (PersistentVolumeClaim): Created

401: Unauthorized

delete видалити PersistentVolumeClaim

HTTP-запит

DELETE /api/v1/namespaces/{namespace}/persistentvolumeclaims/{name}

Параметри

Відповідь

200 (PersistentVolumeClaim): OK

202 (PersistentVolumeClaim): Accepted

401: Unauthorized

deletecollection видалити колекцію PersistentVolumeClaim

HTTP-запит

DELETE /api/v1/namespaces/{namespace}/persistentvolumeclaims

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

6.5.3.7 - PersistentVolume

PersistentVolume (PV) — це ресурс зберігання, який впроваджується адміністратором.

apiVersion: v1

import "k8s.io/api/core/v1"

PersistentVolume

PersistentVolume (PV) — це ресурс зберігання, який впроваджується адміністратором. Він є аналогом ресурсу Node. Докладніше: https://kubernetes.io/docs/concepts/storage/persistent-volumes.


PersistentVolumeSpec

PersistentVolumeSpec — це специфікація постійного тому.


  • accessModes ([]string)

    Atomic: буде замінено під час злиття

    accessModes містить всі способи, якими том може бути змонтований. Докладніше: https://kubernetes.io/docs/concepts/storage/persistent-volumes#access-modes

  • capacity (map[string]Quantity)

    capacity — це опис ресурсів та місткості постійного тому. Докладніше: https://kubernetes.io/docs/concepts/storage/persistent-volumes#capacity

  • claimRef (ObjectReference)

    claimRef є частиною двостороннього звʼязування між PersistentVolume та PersistentVolumeClaim. Очікується, що він буде ненульовим при звʼязуванні. claim.VolumeName є офіційним звʼязуванням між PV та PVC. Докладніше: https://kubernetes.io/docs/concepts/storage/persistent-volumes#binding

  • mountOptions ([]string)

    Atomic: буде замінено під час злиття

    mountOptions — це список опцій монтування, наприклад ["ro", "soft"]. Не перевіряється — монтування просто завершиться з помилкою, якщо одна з опцій недійсна. Докладніше: https://kubernetes.io/docs/concepts/storage/persistent-volumes/#mount-options

  • nodeAffinity (VolumeNodeAffinity)

    nodeAffinity визначає обмеження, які обмежують доступ до цього тому з певних вузлів. Це поле впливає на планування Podʼів, які використовують цей том.

    VolumeNodeAffinity визначає обмеження, які обмежують доступ до цього тому з певних вузлів.

    • nodeAffinity.required (NodeSelector)

      обовʼязково визначає жорсткі обмеження на вузли, які повинні бути виконані.

      Селектор вузлів представляє обʼєднання результатів одного або кількох запитів по мітках у наборі вузлів; тобто, він представляє операцію АБО для селекторів, представлених термінами селектора вузлів.

      • nodeAffinity.required.nodeSelectorTerms ([]NodeSelectorTerm), обовʼязково

        Atomic: буде замінено під час злиття

        Обовʼязково. Список термінів селектора вузлів. Терміни обʼєднуються операцією OR.

        Null або порожній термін селектора вузла не відповідає жодному об'єкту. Вимоги до них складаються за принципом AND. Тип TopologySelectorTerm реалізує підмножину NodeSelectorTerm.

        • nodeAffinity.required.nodeSelectorTerms.matchExpressions ([]NodeSelectorRequirement)

          Atomic: буде замінено під час злиття

          Список вимог селектора вузлів за мітками вузлів.

        • nodeAffinity.required.nodeSelectorTerms.matchFields ([]NodeSelectorRequirement)

          Atomic: буде замінено під час злиття

          Список вимог селектора вузлів за полями вузлів.

  • persistentVolumeReclaimPolicy (string)

    persistentVolumeReclaimPolicy визначає, що відбувається з постійним томом після його звільнення від заявки. Валідні варіанти: Retain (стандартно для створених вручну PersistentVolumes), Delete (стандартно для динамічно наданих PersistentVolumes) та Recycle (застаріле). Recycle повинен підтримуватися втулком тому, що забезпечує роботу цього PersistentVolume. Докладніше: https://kubernetes.io/docs/concepts/storage/persistent-volumes#reclaiming

  • storageClassName (string)

    storageClassName — це назва StorageClass, до якого належить цей постійний том. Порожнє значення означає, що цей том не належить жодному StorageClass.

  • volumeAttributesClassName (string)

    Імʼя VolumeAttributesClass, до якого належить цей постійний том. Порожнє значення не допускається. Якщо це поле не встановлено, це означає, що цей том не належить до жодного VolumeAttributesClass. Це поле змінюване і може бути змінене драйвером CSI після успішного оновлення тому до нового класу. Для непривʼязаного PersistentVolume значення volumeAttributesClassName буде зіставлено з непривʼязаними PersistentVolumeClaim під час процесу привʼязування. Це бета-поле і вимагає ввімкнення функції VolumeAttributesClass (стандартно вимкнена).

  • volumeMode (string)

    volumeMode визначає, чи призначений том для використання з форматованою файловою системою або залишатиметься в необробленому блочному стані. Значення Filesystem мається на увазі, якщо не включено в специфікацію.

Local

  • hostPath (HostPathVolumeSource)

    hostPath представляє теку на хості. Надається розробником або тестувальником. Це корисно лише для одновузлової розробки та тестування! Зберігання на хості жодним чином не підтримується та НЕ ПРАЦЮВАТИМЕ у багатовузловому кластері. Докладніше: https://kubernetes.io/docs/concepts/storage/volumes#hostpath

    Представляє шлях на хості, зіставлений зі шляхом у Podʼі. Шляхи томів хосту не підтримують управління власністю або перепризначення міток SELinux.

  • local (LocalVolumeSource)

    local — це безпосередньо приєднане сховище зі спорідненістю до вузла

    Local представляє безпосередньо приєднане сховище зі спорідненістю до вузла (бета-функція)

    • local.path (string), обовʼязкове

      повний шлях до тому на вузлі. Це може бути або тека, або блоковий пристрій (диск, розділ і т.д.).

    • local.fsType (string)

      fsType — це тип файлової системи для монтування. Застосовується лише тоді, коли Path є блоковим пристроєм. Повинен бути тип файлової системи, підтримуваний операційною системою хосту. Наприклад, "ext4", "xfs", "ntfs". Стандартне значення — автоматичний вибір файлової системи, якщо не вказано.

Постійні томи

  • awsElasticBlockStore (AWSElasticBlockStoreVolumeSource)

    awsElasticBlockStore представляє ресурс AWS Disk, який приєднано до машини хосту kubelet і пізніше надано доступ поду. Докладніше: https://kubernetes.io/docs/concepts/storage/volumes#awselasticblockstore

    Представляє постійний диск AWS.

    • awsElasticBlockStore.volumeID (string), обовʼязково

      volumeID — це унікальний ідентифікатор ресурсу постійного диска в AWS (Amazon EBS volume). Докладніше: https://kubernetes.io/docs/concepts/storage/volumes#awselasticblockstore

    • awsElasticBlockStore.fsType (string)

      fsType — це тип файлової системи тому, який ви хочете монтувати. Переконайтеся, що тип файлової системи підтримується операційною системою хосту. Приклади: "ext4", "xfs", "ntfs". Передбачається "ext4", якщо не вказано інше. Докладніше: https://kubernetes.io/docs/concepts/storage/volumes#awselasticblockstore

    • awsElasticBlockStore.partition (int32)

      partition — це розділ у томі, який ви хочете монтувати. Якщо відсутній, то стандартно монтується за назвою тому. Приклади: Для тому /dev/sda1, ви вказуєте розділ як "1". Аналогічно, розділ тому /dev/sda є "0" (або ви можете залишити властивість пустою).

    • awsElasticBlockStore.readOnly (boolean)

      readOnly значення true змусить використовувати параметр readOnly в VolumeMounts. Докладніше: https://kubernetes.io/docs/concepts/storage/volumes#awselasticblockstore

  • azureDisk (AzureDiskVolumeSource)

    azureDisk представляє монтування Azure Data Disk на хості та звʼязане монтування у Podʼі.

    Представляє монтування Azure Data Disk на хості та звʼязане монтування у Podʼі.

    • azureDisk.diskName (string), обовʼязково

      diskName — це імʼя диска даних у сховищі blob

    • azureDisk.diskURI (string), обовʼязково

      diskURI — це URI диска даних у сховищі blob

    • azureDisk.cachingMode (string)

      cachingMode — це режим кешування на хості: None, Read Only, Read Write.

    • azureDisk.fsType (string)

      fsType — тип файлової системи для монтування. Має бути типом файлової системи, підтриманим операційною системою хосту. Наприклад, "ext4", "xfs", "ntfs". Передбачається "ext4", якщо не вказано інше.

    • azureDisk.kind (string)

      kind — очікувані значення:

      • Shared: декілька томів блобів на обліковому записі сховища
      • Dedicated: один том блобів на обліковому записі сховища
      • Managed: керований диск даних Azure (лише в керованому наборі доступності). Стандартне значення — shared.
    • azureDisk.readOnly (boolean)

      readOnly — стандартне значення — false (запис/читання). Якщо тут встановлено true, то встановлюється параметр readOnly у VolumeMounts.

  • azureFile (AzureFilePersistentVolumeSource)

    azureFile представляє монтування Azure File Service на хості та звʼязане монтування у Podʼі.

    Представляє монтування Azure File Service на хості та звʼязане монтування у Podʼі.

    • azureFile.secretName (string), обовʼязково

      secretName — це імʼя Secret, що містить імʼя та ключ облікового запису Azure Storage

    • azureFile.shareName (string), обовʼязково

      shareName — це назва розділу Azure

    • azureFile.readOnly (boolean)

      readOnly — стандартне значення — false (запис/читання). Якщо тут встановлено true, то встановлюється параметр readOnly в VolumeMounts.

    • azureFile.secretNamespace (string)

      secretNamespace — це простір імен Secret, що містить імʼя та ключ облікового запису Azure. Стандартно використовується той самий простір імен, що й у Podʼа.

  • cephfs (CephFSPersistentVolumeSource)

    cephFS представляє монтування Ceph FS на хості, яке спільно використовується з життєвим циклом Pod.

    Представляє монтування файлової системи Ceph, яка існує протягом життя Podʼа. Томи Cephfs не підтримують управління власниками або перепризначення міток SELinux.

    • cephfs.monitors ([]string), обовʼязково

      Atomic: буде замінено під час злиття

      monitors — це колекція моніторів Ceph. Докладніше: https://examples.k8s.io/volumes/cephfs/README.md#how-to-use-it

    • cephfs.path (string)

      path — необовʼязково: використовується як коренева тека для монтування, стандартно — "/"

    • cephfs.readOnly (boolean)

      readOnly — необовʼязково: стандартне значення — false (запис/читання). Якщо встановлено true, встановлюється параметр readOnly в VolumeMounts. Докладніше: https://examples.k8s.io/volumes/cephfs/README.md#how-to-use-it

    • cephfs.secretFile (string)

      secretFile — необовʼязково: secretFile — це шлях до секретів для користувача, стандартне значення — /etc/ceph/user.secret. Докладніше: https://examples.k8s.io/volumes/cephfs/README.md#how-to-use-it

    • cephfs.secretRef (SecretReference)

      secretRef — необовʼязково: secretRef — посилання на Secret для автентифікації користувача. Стандартне значення порожнє. Докладніше: https://examples.k8s.io/volumes/cephfs/README.md#how-to-use-it

      SecretReference представляє посилання на Secret. Воно має достатньо інформації для отримання Secret в будь-якому просторі імен.

      • cephfs.secretRef.name (string)

        name — унікальне імʼя в межах простору імен для посилання на ресурс Secret.

      • cephfs.secretRef.namespace (string)

        namespace — визначає простір імен, в межах якого імʼя Secret має бути унікальним.

    • cephfs.user (string)

      user — необовʼязково: user — імʼя користувача rados, стандартне значення — admin. Докладніше: https://examples.k8s.io/volumes/cephfs/README.md#how-to-use-it

  • cinder (CinderPersistentVolumeSource)

    cinder представляє монтування та підключення тому Cinder на машині хосту kubelet. Докладніше: https://examples.k8s.io/mysql-cinder-pd/README.md

    Представляє ресурс тому Cinder в OpenStack. Том Cinder повинен існувати перед монтуванням у контейнер. Том також повинен знаходитися в тому ж регіоні, що й kubelet. Томи Cinder підтримують управління власниками та перепризначення міток SELinux.

    • cinder.volumeID (string), обовʼязково

      volumeID — використовується для ідентифікації тому в Cinder. Докладніше: https://examples.k8s.io/mysql-cinder-pd/README.md

    • cinder.fsType (string)

      fsType — тип файлової системи для монтування. Має бути підтримуваним типом файлової системи операційної системи хосту. Приклади: "ext4", "xfs", "ntfs". Передбачається "ext4", якщо не вказано інше. Докладніше: https://examples.k8s.io/mysql-cinder-pd/README.md

    • cinder.readOnly (boolean)

      readOnly — необовʼязково: стандартне значення — false (запис/читання). Якщо встановлено true, параметр readOnly встановлюється в VolumeMounts. Докладніше: https://examples.k8s.io/mysql-cinder-pd/README.md

    • cinder.secretRef (SecretReference)

      secretRef — необовʼязково: посилання на обʼєкт Secret, що містить параметри для підключення до OpenStack.

      SecretReference представляє посилання на Secret. Воно має достатньо інформації для отримання Secret в будь-якому просторі імен.

      • cinder.secretRef.name (string)

        name —- унікальне імʼя в межах простору імен для посилання на ресурс Secret.

      • cinder.secretRef.namespace (string)

        namespace — визначає простір імен, в межах якого імʼя Secret має бути унікальним.

  • csi (CSIPersistentVolumeSource)

    csi представляє сховище, яке обробляється зовнішнім драйвером CSI (функція Beta).

    Представляє сховище, яке керується зовнішнім драйвером CSI для сховища (функція Beta)

    • csi.driver (string), обовʼязково

      driver — це назва драйвера, який використовується для цього тому. Обовʼязково.

    • csi.volumeHandle (string), обовʼязково

      volumeHandle — це унікальне імʼя тому, яке повертається драйвером CSI для посилання на том у всіх наступних викликах. Обовʼязково.

    • csi.controllerExpandSecretRef (SecretReference)

      controllerExpandSecretRef — посилання на обʼєкт Secret, що містить чутливу інформацію для передачі до драйвера CSI для виконання виклику CSI ControllerExpandVolume. Це поле є необовʼязковим і може бути порожнім, якщо Secret не потрібен. Якщо обʼєкт Secret містить більше ніж один ключ, всі ключі передаються.

      SecretReference представляє посилання на Secret. Воно має достатньо інформації для отримання Secret в будь-якому просторі імен.

      • csi.controllerExpandSecretRef.name (string)

        name — унікальне імʼя в межах простору імен для посилання на ресурс Secret.

      • csi.controllerExpandSecretRef.namespace (string)

        namespace — визначає простір імен, в межах якого імʼя Secret має бути унікальним.

    • csi.controllerPublishSecretRef (SecretReference)

      controllerPublishSecretRef — посилання на обʼєкт Secret, що містить чутливу інформацію для передачі до драйвера CSI для виконання викликів CSI ControllerPublishVolume і ControllerUnpublishVolume. Це поле є необовʼязковим і може бути порожнім, якщо секрет не потрібен. Якщо обʼєкт Secret містить більше ніж один ключ, всі ключі передаються.

      SecretReference представляє посилання на Secret. Воно має достатньо інформації для отримання Secret в будь-якому просторі імен.

      • csi.controllerPublishSecretRef.name (string)

        name — унікальне імʼя в межах простору імен для посилання на ресурс Secret.

      • csi.controllerPublishSecretRef.namespace (string)

        namespace — визначає простір імен, в межах якого імʼя Secret має бути унікальним.

    • csi.fsType (string)

      fsType — тип файлової системи для монтування. Має бути підтримуваним типом файлової системи операційної системи хосту. Наприклад, "ext4", "xfs", "ntfs".

    • csi.nodeExpandSecretRef (SecretReference)

      nodeExpandSecretRef — посилання на обʼєкт Secret, що містить чутливу інформацію для передачі до драйвера CSI для виконання виклику CSI NodeExpandVolume. Це поле є необовʼязковим і може бути опущеним, якщо Secret не потрібен. Якщо обʼєкт Secret містить більше ніж один ключ, всі ключі передаються.

      SecretReference представляє посилання на Secret. Воно має достатньо інформації для отримання Secret в будь-якому просторі імен.

      • csi.nodeExpandSecretRef.name (string)

        name — унікальне імʼя в межах простору імен для посилання на ресурс Secret.

      • csi.nodeExpandSecretRef.namespace (string)

        namespace — визначає простір імен, в межах якого імʼя Secret має бути унікальним.

    • csi.nodePublishSecretRef (SecretReference)

      nodePublishSecretRef — посилання на обʼєкт, Secret що містить чутливу інформацію для передачі до драйвера CSI для виконання викликів CSI NodePublishVolume і NodeUnpublishVolume. Це поле є необовʼязковим і може бути порожнім, якщо Secret не потрібен. Якщо обʼєкт Secret містить більше ніж один ключ, всі ключі передаються.

      SecretReference представляє посилання на Secret. Воно має достатньо інформації для отримання Secret в будь-якому просторі імен.

      • csi.nodePublishSecretRef.name (string)

        name — унікальне імʼя в межах простору імен для посилання на ресурс Secret.

      • csi.nodePublishSecretRef.namespace (string)

        namespace — визначає простір імен, в межах якого імʼя Secret має бути унікальним.

    • csi.nodeStageSecretRef (SecretReference)

      nodeStageSecretRef — посилання на обʼєкт Secret, що містить чутливу інформацію для передачі до драйвера CSI для виконання викликів CSI NodeStageVolume і NodeUnstageVolume. Це поле є необовʼязковим і може бути порожнім, якщо Secret не потрібен. Якщо обʼєкт Secret містить більше ніж один ключ, всі ключі передаються.

      SecretReference представляє посилання на Secret. Воно має достатньо інформації для отримання Secret в будь-якому просторі імен.

      • csi.nodeStageSecretRef.name (string)

        name — унікальне імʼя в межах простору імен для посилання на ресурс Secret.

      • csi.nodeStageSecretRef.namespace (string)

        namespace — визначає простір імен, в межах якого імʼя Secret має бути унікальним.

    • csi.readOnly (boolean)

      readOnly — значення для передачі до ControllerPublishVolumeRequest. Стандартне значення — false (запис/читання).

    • csi.volumeAttributes (map[string]string)

      volumeAttributes — атрибути тому для публікації.

  • fc (FCVolumeSource)

    fc представляє ресурс Fibre Channel, який приєднується до хост-машини kubelet і потім експонується для використання в Podʼі.

    Представляє том Fibre Channel. Томи Fibre Channel можуть бути приєднані лише як для читання/запису один раз. Томи Fibre Channel підтримують управління власниками та перепризначення міток SELinux.

    • fc.fsType (string)

      fsType — це тип файлової системи для монтування. Має бути підтримуваним типом файлової системи операційної системи хосту. Наприклад, "ext4", "xfs", "ntfs". Передбачається "ext4", якщо не вказано інше.

    • fc.lun (int32)

      lun — необовʼязково: номер lun.

    • fc.readOnly (boolean)

      readOnly — необовʼязково: стандартне значення — false (запис/читання). Якщо встановлено true, встановлюється параметр readOnly у VolumeMounts.

    • fc.targetWWNs ([]string)

      Atomic: буде замінено під час злиття

      targetWWNs — необовʼязково: FC вказує всесвітні імена (worldwide names, WWN).

    • fc.wwids ([]string)

      Atomic: буде замінено під час злиття

      wwids — необовʼязково: світові ідентифікатори тома FC (WWID). Можна встановити або wwids, або комбінацію targetWWNs і lun, але не одночасно.

  • flexVolume (FlexPersistentVolumeSource)

    flexVolume представляє загальний ресурс тома, який надається/приєднується за допомогою втулка.

    FlexPersistentVolumeSource представляє загальний постійний том, який надається/приєднується за допомогою втулка.

    • flexVolume.driver (string), обовʼязково

      driver — це імʼя драйвера, яке використовується для цього тома.

    • flexVolume.fsType (string)

      fsType — тип файлової системи для монтування. Має бути підтримуваним типом файлової системи операційної системи хоста. Наприклад, "ext4", "xfs", "ntfs". Тип стандартної файлової системи залежить від сценарію FlexVolume.

    • flexVolume.options (map[string]string)

      options — необовʼязково: це поле містить додаткові параметри команди, якщо такі є.

    • flexVolume.readOnly (boolean)

      readOnly — необовʼязково: стандартне значення — false (запис/читання). Якщо встановлено true, встановлюється параметр readOnly у VolumeMounts.

    • flexVolume.secretRef (SecretReference)

      secretRef — необовʼязково: посилання на обʼєкт Secret, що містить чутливу інформацію для передачі в сценарії втулка. Це поле може бути порожнім, якщо обʼєкт Secret не вказано. Якщо Secret містить більше одного секрету, всі вони передаються в сценарії втулка.

      SecretReference представляє посилання на Secret. Воно має достатньо інформації для отримання Secret в будь-якому просторі імен.

      • flexVolume.secretRef.name (string)

        name — унікальне імʼя в межах простору імен для посилання на ресурс Secret.

      • flexVolume.secretRef.namespace (string)

        namespace — визначає простір імен, в межах якого імʼя Secret має бути унікальним.

  • flocker (FlockerVolumeSource)

    flocker представляє том Flocker, приєднаний до хост-машини kubelet і експонований для використання в Podʼі. Це залежить від того, чи працює служба керування Flocker.

    Представляє том Flocker, приєднаний агентом Flocker. Повинно бути встановлено одне і тільки одне значення datasetName або datasetUUID. Томи Flocker не підтримують управління власниками або перевизначення міток SELinux.

    • flocker.datasetName (string)

      datasetName — імʼя набору даних, збережене як метадані -> імʼя для набору даних Flocker. Вважається застарілим.

    • flocker.datasetUUID (string)

      datasetUUID — UUID набору даних. Це унікальний ідентифікатор набору даних Flocker.

  • gcePersistentDisk (GCEPersistentDiskVolumeSource)

    gcePersistentDisk представляє ресурс GCE Disk, який приєднується до хост-машини kubelet і потім експонується для використання в Podʼі. Впроваджується адміністратором. Докладніше: https://kubernetes.io/docs/concepts/storage/volumes#gcepersistentdisk

    Представляє постійний диск в Google Compute Engine.

    Диск GCE повинен існувати перед монтуванням в контейнер. Диск також повинен знаходитися в тому ж проєкті та зоні GCE, що і kubelet. Диск GCE може бути приєднаний тільки як для читання/запису один раз або тільки для читання багато разів. Диски GCE підтримують управління власниками та перепризначення міток SELinux.

    • gcePersistentDisk.pdName (string), обовʼязково

      pdName — унікальне імʼя ресурсу PD в GCE. Використовується для ідентифікації диска в GCE.

    • gcePersistentDisk.fsType (string)

      fsType — тип файлової системи тома, який ви хочете монтувати. Переконайтеся, що тип файлової системи підтримується операційною системою хосту. Приклади: "ext4", "xfs", "ntfs". Передбачається "ext4", якщо не вказано інше.

    • gcePersistentDisk.partition (int32)

      partition — розділ у томі, який ви хочете монтувати. Якщо пропущено,стандартно монтується за іменем тома. Приклади: Для тома /dev/sda1 ви вказуєте розділ як "1". Аналогічно, розділ тома для /dev/sda - "0" (або ви можете залишити властивість пустою).

    • gcePersistentDisk.readOnly (boolean)

      readOnly — тут встановлює параметр readOnly у VolumeMounts. Стандартне значення — false.

  • glusterfs (GlusterfsPersistentVolumeSource)

    glusterfs представляє том Glusterfs, який приєднується до хосту і експонується для використання в Podʼі. Впроваджується адміністратором. Докладніше: https://examples.k8s.io/volumes/glusterfs/README.md

    Представляє монтування Glusterfs, яке існує протягом життєвого циклу Podʼа. Томи Glusterfs не підтримують управління власниками або перепризначенн міток SELinux.

  • iscsi (ISCSIPersistentVolumeSource)

    iscsi представляє ресурс ISCSI Disk, який приєднується до хост-машини kubelet і потім експонується для використання в Podʼі. Надається адміністратором.

    ISCSIPersistentVolumeSource представляє диск ISCSI. ISCSI томи можуть бути монтувані тільки один раз для читання/запису. ISCSI томи підтримують управління власниками та перепризначення міток SELinux.

    • iscsi.iqn (string), обовʼязково

      iqn - кваліфіковане імʼя ISCSI цілі.

    • iscsi.lun (int32), обовʼязково

      lun — номер LUN цілі ISCSI.

    • iscsi.targetPortal (string), обовʼязково

      targetPortal — це цільовий портал ISCSI. Портал може бути IP або ip_addr:port, якщо порт відрізняється від типового (зазвичай TCP порти 860 та 3260).

    • iscsi.chapAuthDiscovery (boolean)

      chapAuthDiscovery — визначає підтримку автентифікації CHAP для виявлення ISCSI.

    • iscsi.chapAuthSession (boolean)

      chapAuthSession - визначає підтримку автентифікації CHAP сесії ISCSI.

    • iscsi.fsType (string)

      fsType — тип файлової системи тому, який ви хочете монтувати. Переконайтеся, що тип файлової системи підтримується операційною системою хоста. Приклади: "ext4", "xfs", "ntfs". Передбачається "ext4", якщо не вказано інше. Детальніше: https://kubernetes.io/docs/concepts/storage/volumes#iscsi

    • iscsi.initiatorName (string)

      initiatorName — це спеціальне імʼя ініціатора ISCSI. Якщо initiatorName вказано одночасно з iscsiInterface, буде створено новий інтерфейс ISCSI <target portal>:<volume name> для зʼєднання.

    • iscsi.iscsiInterface (string)

      iscsiInterface — це імʼя інтерфейсу, яке використовує транспорт ISCSI. Стандартне значення — 'default' (tcp).

    • iscsi.portals ([]string)

      Atomic: буде замінено під час злиття

      portals — список цільових порталів ISCSI. Портал може бути IP або ip_addr:port, якщо порт відрізняється від типового (зазвичай TCP порти 860 та 3260).

    • iscsi.readOnly (boolean)

      readOnly — встановлює параметр readOnly у VolumeMounts. Стандартне значення — false.

    • iscsi.secretRef (SecretReference)

      secretRef — це обʼєкт Secret для автентифікації цілі ISCSI та ініціатора.

      SecretReference представляє посилання на Secret. Воно має достатньо інформації для отримання Secret в будь-якому просторі імен.

      • iscsi.secretRef.name (string)

        name — унікальне імʼя в межах простору імен для посилання на ресурс Secret.

      • iscsi.secretRef.namespace (string)

        namespace — визначає простір імен, в межах якого імʼя Secret має бути унікальним.

  • nfs (NFSVolumeSource)

    nfs представляє монтування NFS на хості. Впроваджується адміністратором. Докладніше: https://kubernetes.io/docs/concepts/storage/volumes#nfs

    Представляє монтування NFS, яке існує протягом життєвого циклу Podʼа. NFS томи не підтримують управління власниками або перевизначення міток SELinux.

  • photonPersistentDisk (PhotonPersistentDiskVolumeSource)

    photonPersistentDisk представляє постійний диск Photon Controller, приєднаний і змонтований на хост-машині kubelet

    Представляє ресурс постійного диска Photon Controller.

    • photonPersistentDisk.pdID (string), обовʼязково

      pdID — це ідентифікатор, який ідентифікує постійний диск Photon Controller.

    • photonPersistentDisk.fsType (string)

      fsType — тип файлової системи для монтування. Повинен бути типом файлової системи, який підтримується операційною системою хоста. Наприклад: "ext4", "xfs", "ntfs". Передбачається "ext4", якщо не вказано інше.

  • portworxVolume (PortworxVolumeSource)

    portworxVolume представляє ресурс тома Portworx, приєднаний і змонтований на хост-машині kubelet

    Представляє ресурс тома Portworx.

    • portworxVolume.volumeID (string), обовʼязково

      volumeID — унікально ідентифікує том Portworx.

    • portworxVolume.fsType (string)

      fsType — тип файлової системи для монтування. Повинен бути типом файлової системи, який підтримується операційною системою хоста. Наприклад: "ext4", "xfs". Передбачається "ext4", якщо не вказано інше.

    • portworxVolume.readOnly (boolean)

      readOnly — стандартне значення — false (читання/запис). Якщо встановлено в true, тоді монтування тома буде тільки для читання.

  • quobyte (QuobyteVolumeSource)

    quobyte представляє монтування Quobyte на хості, яке триває протягом життєвого циклу Podʼа.

    Представляє монтування Quobyte, яке триває протягом життєвого циклу Podʼа. Quobyte томи не підтримують управління власниками або перевизначення міток SELinux.

    • quobyte.registry (string), обовʼязково

      registry — представляє один або кілька сервісів реєстрації Quobyte, вказаних як рядок у форматі host:port (кілька записів розділяються комами), які діють як центральний реєстр для томів.

    • quobyte.volume (string), обовʼязково

      volume — рядок, який посилається на вже створений том Quobyte за імʼям.

    • quobyte.group (string)

      group — група для відображення доступу до тома. Стандартно група не встановлюється.

    • quobyte.readOnly (boolean)

      readOnly — встановлює, чи має монтуватися том Quobyte тільки для читання. Стандартне значення — false.

    • quobyte.tenant (string)

      tenant — власник вказаного тома Quobyte в Backend. Використовується з динамічно створеними томами Quobyte, значення встановлюється втулком.

    • quobyte.user (string)

      user — користувач для відображення доступу до тома. Стандартно використовується користувач serivceaccount.

  • rbd (RBDPersistentVolumeSource)

    rbd представляє монтування Rados Block Device на хості, яке існує протягом життєвого циклу Podʼа. Детальніше: https://examples.k8s.io/volumes/rbd/README.md

    Представляє монтування Rados Block Device, яке існує протягом життєвого циклу Podʼа. RBD томи підтримують управління власниками та перевизначення міток SELinux.

    • rbd.image (string), обовʼязково

      image — імʼя образу rados. Детальніше: https://examples.k8s.io/volumes/rbd/README.md#how-to-use-it

    • rbd.monitors ([]string), обовʼязково

      Atomic: буде замінено під час злиття

      monitors — колекція моніторів Ceph. Детальніше: https://examples.k8s.io/volumes/rbd/README.md#how-to-use-it

    • rbd.fsType (string)

      fsType — тип файлової системи тому, який ви хочете змонтувати. Переконайтеся, що тип файлової системи підтримується операційною системою хоста. Приклади: "ext4", "xfs", "ntfs". Передбачається "ext4", якщо не вказано інше. Детальніше: https://kubernetes.io/docs/concepts/storage/volumes#rbd

    • rbd.keyring (string)

      keyring — шлях до ключів для RBDUser. Стандартне значення — /etc/ceph/keyring. Детальніше: https://examples.k8s.io/volumes/rbd/README.md#how-to-use-it

    • rbd.pool (string)

      pool — імʼя rados pool. Стандартне значення — rbd. Детальніше: https://examples.k8s.io/volumes/rbd/README.md#how-to-use-it

    • rbd.readOnly (boolean)

      readOnly — встановлює, що монтування RBD тому буде тільки для читання. Стандартне значення — false. Детальніше: https://examples.k8s.io/volumes/rbd/README.md#how-to-use-it

    • rbd.secretRef (SecretReference)

      secretRef - імʼя Secret автентифікації для RBDUser. Якщо вказано, перевизначає keyring. Стандартне значення — nil. Детальніше: https://examples.k8s.io/volumes/rbd/README.md#how-to-use-it

      SecretReference представляє посилання на Secret. Воно містить достатньо інформації для отримання Secret в будь-якому просторі імен

      • rbd.secretRef.name (string)

        name — унікальне імʼя ресурсу Secret в просторі імен.

      • rbd.secretRef.namespace (string)

        namespace — визначає простір імен, в якому імʼя Secret повинно бути унікальним.

    • rbd.user (string)

      user — імʼя користувача rados. Стандартне значення — admin. Детальніше: https://examples.k8s.io/volumes/rbd/README.md#how-to-use-it

  • scaleIO (ScaleIOPersistentVolumeSource)

    scaleIO представляє постійний том ScaleIO, приєднаний і змонтований на вузлах Kubernetes.

    ScaleIOPersistentVolumeSource представляє постійний том ScaleIO

    • scaleIO.gateway (string), обовʼязково

      gateway — адреса хосту шлюза API ScaleIO.

    • scaleIO.secretRef (SecretReference), обовʼязково

      secretRef — посилання на Secret для користувача ScaleIO та іншої чутливої інформації. Якщо це не надано, операція входу буде невдалою.

      SecretReference представляє посилання на Secret. Воно містить достатньо інформації для отримання Secret в будь-якому просторі імен

      • scaleIO.secretRef.name (string)

        name — унікальне імʼя ресурсу Secret в просторі імен.

      • scaleIO.secretRef.namespace (string)

        namespace — визначає простір імен, в якому імʼя Secret повинно бути унікальним.

    • scaleIO.system (string), обовʼязково

      system — назва системи зберігання, як налаштовано в ScaleIO.

    • scaleIO.fsType (string)

      fsType — тип файлової системи для монтування. Повинен бути типом файлової системи, який підтримується операційною системою хоста. Наприклад: "ext4", "xfs", "ntfs". Стандартне значення — "xfs".

    • scaleIO.protectionDomain (string)

      protectionDomain — назва домену захисту ScaleIO для налаштованого зберігання.

    • scaleIO.readOnly (boolean)

      readOnly — стандартне значення — false (читання/запис). Якщо встановлено в true, тоді монтування тому буде тільки для читання.

    • scaleIO.sslEnabled (boolean)

      sslEnabled — прапорець для увімкнення/вимкнення SSL-звʼязку з Gateway, стандартне значення — false.

    • scaleIO.storageMode (string)

      storageMode — вказує, чи повинно бути зберігання для тому ThickProvisioned або ThinProvisioned. Стандартне значення — ThinProvisioned.

    • scaleIO.storagePool (string)

      storagePool — Pool зберігання ScaleIO, повʼязаний з доменом захисту.

    • scaleIO.volumeName (string)

      volumeName — імʼя вже створеного тому в системі ScaleIO, повʼязаного з цим джерелом тому.

  • storageos (StorageOSPersistentVolumeSource)

    storageOS представляє том StorageOS, який приєднаний до вузла kubelet і змонтований у Pod. Детальніше: https://examples.k8s.io/volumes/storageos/README.md

    Представляє постійний том ресурсу StorageOS.

    • storageos.fsType (string)

      fsType — тип файлової системи для монтування. Повинен бути типом файлової системи, який підтримується операційною системою хоста. Наприклад: "ext4", "xfs", "ntfs". Передбачається "ext4", якщо не вказано інше.

    • storageos.readOnly (boolean)

      readOnly — стандартне значення — false (читання/запис). Якщо встановлено в true, то монтування тому буде тільки для читання.

    • storageos.secretRef (ObjectReference)

      secretRef - вказує на Secret, який використовується для отримання облікових даних API StorageOS. Якщо не вказано, спробує використати стандартне значення.

    • storageos.volumeName (string)

      volumeName — імʼя тому StorageOS, зорозуміле людині. Імена томів унікальні лише в межах простору імен.

    • storageos.volumeNamespace (string)

      volumeNamespace — визначає область тому в межах StorageOS. Якщо не вказано, використовується простір імен Podʼа. Це дозволяє відображати простори імен Kubernetes в межах StorageOS для більш тісної інтеграції. Встановіть VolumeName на будь-яке імʼя для заміни стандартної поведінки. Встановіть у "default", якщо ви не використовуєте простори імен в межах StorageOS. Простори імен, які не існують заздалегідь в межах StorageOS, будуть створені.

  • vsphereVolume (VsphereVirtualDiskVolumeSource)

    vsphereVolume представляє том vSphere, який приєднаний і змонтований на вузлах kubelet.

    Представляє ресурс тому vSphere.

    • vsphereVolume.volumePath (string), обовʼязково

      volumePath — шлях, який ідентифікує том vSphere vmdk.

    • vsphereVolume.fsType (string)

      fsType — тип файлової системи для монтування. Повинен бути типом файлової системи, який підтримується операційною системою хоста. Наприклад: "ext4", "xfs", "ntfs". Передбачається "ext4", якщо не вказано інше.

    • vsphereVolume.storagePolicyID (string)

      storagePolicyID — ідентифікатор профілю управління політикою зберігання (SPBM), повʼязаний з іменем політики зберігання.

    • vsphereVolume.storagePolicyName (string)

      storagePolicyName — імʼя профілю управління політикою зберігання (SPBM).

PersistentVolumeStatus

PersistentVolumeStatus — це поточний стан постійного тома.


  • lastPhaseTransitionTime (Time)

    lastPhaseTransitionTime — це час, коли фаза переходила з однієї у іншу, і автоматично скидається до поточного часу кожного разу при переході фази тома.

    Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

  • message (string)

    message — повідомлення, зрозуміле людині, яке вказує деталі щодо причини, чому том знаходиться у цьому стані.

  • phase (string)

    phase — вказує, чи доступний том, звʼязаний із заявкою або звільнений від заявки. Докладніше: https://kubernetes.io/docs/concepts/storage/persistent-volumes#phase

  • reason (string)

    reason — короткий рядок у CamelCase, який описує будь-яку помилку і призначений для машинного аналізу і зручного відображення у CLI.

PersistentVolumeList

PersistentVolumeList — це список елементів PersistentVolume.


Операції


get отримати вказаний PersistentVolume

HTTP запит

GET /api/v1/persistentvolumes/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва PersistentVolume

  • pretty (в запиті): string

    pretty

Відповідь

200 (PersistentVolume): OK

401: Unauthorized

get отримати статус вказаного PersistentVolume

HTTP запит

GET /api/v1/persistentvolumes/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    назва PersistentVolume

  • pretty (в запиті): string

    pretty

Відповідь

200 (PersistentVolume): OK

401: Unauthorized

list перелік або перегляд обʼєктів PersistentVolume

HTTP запит

GET /api/v1/persistentvolumes

Параметри

Відповідь

200 (PersistentVolumeList): OK

401: Unauthorized

create створення PersistentVolume

HTTP запит

POST /api/v1/persistentvolumes

Параметри

Відповідь

200 (PersistentVolume): OK

201 (PersistentVolume): Created

202 (PersistentVolume): Accepted

401: Unauthorized

update заміна вказаного PersistentVolume

HTTP запит

PUT /api/v1/persistentvolumes/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва PersistentVolume

  • body: PersistentVolume, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (PersistentVolume): OK

201 (PersistentVolume): Created

401: Unauthorized

update заміна статусу вказаного PersistentVolume

HTTP запит

PUT /api/v1/persistentvolumes/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    назва PersistentVolume

  • body: PersistentVolume, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (PersistentVolume): OK

201 (PersistentVolume): Created

401: Unauthorized

patch часткове оновлення вказаного PersistentVolume

HTTP запит

PATCH /api/v1/persistentvolumes/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва PersistentVolume

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (PersistentVolume): OK

201 (PersistentVolume): Created

401: Unauthorized

patch часткове оновлення статусу вказаного PersistentVolume

HTTP запит

PATCH /api/v1/persistentvolumes/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    назва PersistentVolume

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (PersistentVolume): OK

201 (PersistentVolume): Created

401: Unauthorized

delete видалення PersistentVolume

HTTP запит

DELETE /api/v1/persistentvolumes/{name}

Параметри

Відповідь

200 (PersistentVolume): OK

202 (PersistentVolume): Accepted

401: Unauthorized

deletecollection видалення колекції PersistentVolume

HTTP запит

DELETE /api/v1/persistentvolumes

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

6.5.3.8 - StorageClass

StorageClass описує параметри класу сховища, для якого PersistentVolumes можна динамічно виділяти.

apiVersion: storage.k8s.io/v1

import "k8s.io/api/storage/v1"

StorageClass

StorageClass описує параметри класу сховища, для якого PersistentVolumes можна динамічно виділяти.

Класи сховищ не мають простору імен; імʼя класу сховища згідно з etcd знаходиться в ObjectMeta.Name.


  • apiVersion: storage.k8s.io/v1

  • kind: StorageClass

  • metadata (ObjectMeta)

    Стандартні метадані обʼєкта. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

  • provisioner (string), обовʼязково

    provisioner вказує на тип провізора.

  • allowVolumeExpansion (boolean)

    allowVolumeExpansion показує, чи дозволяє клас зберігання розширення тому.

  • allowedTopologies ([]TopologySelectorTerm)

    Atomic: буде замінено під час обʼєднання

    allowedTopologies обмежує топологію вузлів, де томи можуть динамічно виділятися. Кожен втулок тому визначає свої власні специфікації топології. Порожній список TopologySelectorTerm означає, що обмежень по топології немає. Це поле враховується лише серверами, які включають функцію VolumeScheduling.

    Термін селектора топології представляє результат запитів до міток. Нульовий або порожній термін селектора топології не відповідає жодному обʼєкту. Вимоги до них обʼєднуються за принципом AND. Він надає підмножину функціональності як NodeSelectorTerm. Це альфа-версія функції та в майбутньому вона може змінитися.

    • allowedTopologies.matchLabelExpressions ([]TopologySelectorLabelRequirement)

      Atomic: буде замінено під час злиття

      Список вимог до вибору топології за мітками.

      Вимога вибору топології — це селектор, що відповідає заданій мітці. Це альфа-функція і може змінитися в майбутньому.

      • allowedTopologies.matchLabelExpressions.key (string), обовʼязково

        Ключ мітки, до якого застосовується селектор.

      • allowedTopologies.matchLabelExpressions.values ([]string), обовʼязково

        Atomic: буде замінено під час злиття

        Масив рядкових значень. Одне значення повинно відповідати мітці для вибору. Кожен запис у Values поєднується оператором OR.

  • mountOptions ([]string)

    Atomic: буде замінено під час злиття

    mountOptions контролює параметри монтування для динамічно виділених PersistentVolumes цього класу зберігання. Наприклад, ["ro", "soft"]. Не перевіряється — монтування PVs просто не вдасться, якщо один з них недійсний.

  • parameters (map[string]string)

    parameters містить параметри для провайдера, який повинен створити томи цього класу зберігання.

  • reclaimPolicy (string)

    reclaimPolicy контролює політику відновлення для динамічно виділених PersistentVolumes цього класу зберігання. Стандартне значення — Delete.

  • volumeBindingMode (string)

    volumeBindingMode вказує, як PersistentVolumeClaims повинні виділятися та звʼязуватися. Якщо не встановлено, використовується VolumeBindingImmediate. Це поле враховується лише серверами, які включають функцію VolumeScheduling.

StorageClassList

StorageClassList — це колекція класів зберігання.


Операції


get отримати вказаний StorageClass

HTTP запит

GET /apis/storage.k8s.io/v1/storageclasses/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя StorageClass

  • pretty (в запиті): string

    pretty

Відповідь

200 (StorageClass): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу StorageClass

HTTP запит

GET /apis/storage.k8s.io/v1/storageclasses

Параметри

Відповідь

200 (StorageClassList): OK

401: Unauthorized

create створення StorageClass

HTTP запит

POST /apis/storage.k8s.io/v1/storageclasses

Параметри

Відповідь

200 (StorageClass): OK

201 (StorageClass): Created

202 (StorageClass): Accepted

401: Unauthorized

update заміна вказаного StorageClass

HTTP запит

PUT /apis/storage.k8s.io/v1/storageclasses/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя StorageClass

  • body: StorageClass, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (StorageClass): OK

201 (StorageClass): Created

401: Unauthorized

patch часткове оновлення вказаного StorageClass

HTTP запит

PATCH /apis/storage.k8s.io/v1/storageclasses/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя StorageClass

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (StorageClass): OK

201 (StorageClass): Created

401: Unauthorized

delete видалення StorageClass

HTTP запит

DELETE /apis/storage.k8s.io/v1/storageclasses/{name}

Параметри

Відповідь

200 (StorageClass): OK

202 (StorageClass): Accepted

401: Unauthorized

deletecollection видалення колекції StorageClass

HTTP запит

DELETE /apis/storage.k8s.io/v1/storageclasses

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

6.5.3.9 - StorageVersionMigration v1alpha1

StorageVersionMigration представляє міграцію збережених даних до останньої версії сховища.

apiVersion: storagemigration.k8s.io/v1alpha1

import "k8s.io/api/storagemigration/v1alpha1"

StorageVersionMigration

StorageVersionMigration представляє міграцію збережених даних до останньої версії сховища.


StorageVersionMigrationSpec

Специфіка міграції версії сховища.


  • continueToken (string)

    Токен, який використовується в опціях списку, щоб отримати наступну порцію обʼєктів для міграції. Коли .status.conditions вказує на те, що міграція виконується, користувачі можуть використовувати цей токен, щоб перевірити хід міграції.

  • resource (GroupVersionResource), обовʼязково

    Ресурс, який мігрує. Мігратор надсилає запити до точки доступу, що обслуговує ресурс. Незмінний.

    Імена групи, версії та ресурсу.

    • resource.group (string)

      Імʼя групи.

    • resource.resource (string)

      Імʼя ресурсу.

    • resource.version (string)

      Імʼя версії.

StorageVersionMigrationStatus

Статус міграції версії сховища.


  • conditions ([]MigrationCondition)

    Patch strategy: обʼєднання за ключем name

    Map: унікальні значення ключа name будуть збережені під час злиття

    Останні доступні спостереження за поточним станом міграції.

    Описує стан міграції на певний момент.

    • conditions.status (string), обовʼязково

      Статус стану, одни з: True, False, Unknown.

    • conditions.type (string), обовʼязково

      Тип стану.

    • conditions.lastUpdateTime (Time)

      Час, коли булі остання зміна стану.

      Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

    • conditions.message (string)

      message містить зрозуміле для людини повідомлення з деталями про стан зміни.

    • conditions.reason (string)

      reason умови останньої зміни.

  • resourceVersion (string)

    ResourceVersion для порівняння з кешем GC для виконання міграції. Це поточна версія ресурсу для даної групи, версії та ресурсу, коли kube-controller-manager вперше спостерігає цей ресурс StorageVersionMigration.

StorageVersionMigrationList

StorageVersionMigrationList — колекція міграцій версій сховища.


Операції


get отримати вказаний StorageVersionMigration

HTTP запит

GET /apis/storagemigration.k8s.io/v1alpha1/storageversionmigrations/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя StorageVersionMigration

  • pretty (в запиті): string

    pretty

Відповідь

200 (StorageVersionMigration): OK

401: Unauthorized

get отримати статус вказаного StorageVersionMigration

HTTP запит

GET /apis/storagemigration.k8s.io/v1alpha1/storageversionmigrations/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя StorageVersionMigration

  • pretty (в запиті): string

    pretty

Відповідь

200 (StorageVersionMigration): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу StorageVersionMigration

HTTP запит

GET /apis/storagemigration.k8s.io/v1alpha1/storageversionmigrations

Параметри

Відповідь

200 (StorageVersionMigrationList): OK

401: Unauthorized

create створення StorageVersionMigration

HTTP запит

POST /apis/storagemigration.k8s.io/v1alpha1/storageversionmigrations

Параметри

Відповідь

200 (StorageVersionMigration): OK

201 (StorageVersionMigration): Created

202 (StorageVersionMigration): Accepted

401: Unauthorized

update заміна вказаного StorageVersionMigration

HTTP запит

PUT /apis/storagemigration.k8s.io/v1alpha1/storageversionmigrations/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя StorageVersionMigration

  • body: StorageVersionMigration, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (StorageVersionMigration): OK

201 (StorageVersionMigration): Created

401: Unauthorized

update заміна статусу вказаного StorageVersionMigration

HTTP запит

PUT /apis/storagemigration.k8s.io/v1alpha1/storageversionmigrations/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя StorageVersionMigration

  • body: StorageVersionMigration, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (StorageVersionMigration): OK

201 (StorageVersionMigration): Created

401: Unauthorized

patch часткове оновлення вказаного StorageVersionMigration

HTTP запит

PATCH /apis/storagemigration.k8s.io/v1alpha1/storageversionmigrations/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя StorageVersionMigration

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (StorageVersionMigration): OK

201 (StorageVersionMigration): Created

401: Unauthorized

patch частковеоновлення статусу вказаного StorageVersionMigration

HTTP запит

PATCH /apis/storagemigration.k8s.io/v1alpha1/storageversionmigrations/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя StorageVersionMigration

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (StorageVersionMigration): OK

201 (StorageVersionMigration): Created

401: Unauthorized

delete видалення StorageVersionMigration

HTTP запит

DELETE /apis/storagemigration.k8s.io/v1alpha1/storageversionmigrations/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя StorageVersionMigration

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції StorageVersionMigration

HTTP запит

DELETE /apis/storagemigration.k8s.io/v1alpha1/storageversionmigrations

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

6.5.3.10 - Volume

Volume представляє собою іменований том у Pod, до якого може мати доступ будь-який контейнер у Podʼі.

import "k8s.io/api/core/v1"

Volume

Volume становить собою іменований том у Pod, до якого може мати доступ будь-який контейнер у Podʼі.


Відкриті постійні томи

  • persistentVolumeClaim (PersistentVolumeClaimVolumeSource)

    persistentVolumeClaimVolumeSource — це посилання на PersistentVolumeClaim у тому ж просторі імен. Додаткова інформація: https://kubernetes.io/docs/concepts/storage/persistent-volumes#persistentvolumeclaims

    PersistentVolumeClaimVolumeSource посилається на PVC користувача в тому ж просторі імен. Цей том знаходить привʼязаний PV та монтує цей том для Podʼа. PersistentVolumeClaimVolumeSource, фактично, є обгорткою навколо іншого типу тому, який належить комусь іншому (системі).

    • persistentVolumeClaim.claimName (string), обовʼязково

      claimName — це назва PersistentVolumeClaim у тому ж просторі імен, що й у Podʼа, який використовує цей том. Додаткова інформація: https://kubernetes.io/docs/concepts/storage/persistent-volumes#persistentvolumeclaims

    • persistentVolumeClaim.readOnly (boolean)

      readOnly — Встановлює значення ReadOnly у VolumeMounts. Стандартне значення — false.

Проєкції

  • configMap (ConfigMapVolumeSource)

    configMap — представляє configMap, який повинен заповнити цей том.

    *Адаптує ConfigMap до тому.

    Вміст поля Data цільового ConfigMap буде представлений у томі у вигляді файлів, використовуючи ключі у полі Data як назви файлів, якщо елемент items заповнений конкретними зіставленнями ключів зі шляхами. Томи ConfigMap підтримують керування власністю та перепризначення міток SELinux.

    • configMap.name (string)

      Name — назва обʼєкта ConfigMap, повʼязаного з томом. Це поле є обов\язковим для заповнення, але для забезпечення зворотної сумісності дозволяється залишати його порожнім. Екземпляри цього типу з порожнім значенням тут майже напевно є помилковими. Додаткова інформація: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names

    • configMap.optional (boolean)

      optional — вказує, чи ConfigMap або його ключі мають бути визначені.

    • configMap.defaultMode (int32)

      defaultMode є необовʼязковим параметром: біти режимів, які використовуються для встановлення стандартних дозволів на створені файли. Має бути вісімковим значенням між 0000 та 0777 або десятковим значенням між 0 та 511. У форматі YAML можна використовувати як вісімкові, так і десяткові значення, у форматі JSON потрібно використовувати десяткові значення для режиму бітів. Стандартне значення — 0644. Теки всередині шляху не підпадають під це налаштування. Це може суперечити іншим параметрам, які впливають на режим файлу, наприклад, fsGroup, і результат може бути встановлення інших бітів режимів.

    • configMap.items ([]KeyToPath)

      Atomic: буде замінено під час злиття

      Якщо не вказано items, кожна пара ключ-значення у полі Data зазначеного ConfigMap буде перенесена в том як файл, імʼя якого — це ключ, а вміст — значення. Якщо вказано, перераховані ключі будуть перенесені у вказані шляхи, а невказані ключі відсутні. Якщо вказано ключ, якого немає у ConfigMap, налаштування тому завершиться помилкою, якщо він не позначений як необовʼязковий. Шляхи повинні бути відносними та не можуть містити шлях '..' або починатися з '..'.

    • secret (SecretVolumeSource)

      secret — представляє secret, який повинен заповнити цей том. Додаткова інформація: https://kubernetes.io/docs/concepts/storage/volumes#secret

      *Адаптує Secret до тому.

      Вміст поля Data цільового Secret буде представлений у томі у вигляді файлів, використовуючи ключі у полі Data як назви файлів. Томи Secret підтримують керування власністю та перепризначення міток SELinux.*

    • secret.secretName (string)

      secretName — назва обʼєкта Secret в просторі імен Podʼа, що буде використовуватись. Додаткова інформація: https://kubernetes.io/docs/concepts/storage/volumes#secret

    • secret.optional (boolean)

      optional — вказує, чи Secret або його ключі мають бути визначені.

    • secret.defaultMode (int32)

      defaultMode є необовʼязковим параметром: біти режимів, які використовуються для встановлення стандартних дозволів на створені файли. Має бути вісімковим значенням між 0000 та 0777 або десятковим значенням між 0 та 511. У форматі YAML можна використовувати як вісімкові, так і десяткові значення, у форматі JSON потрібно використовувати десяткові значення для режиму бітів. Стандартне значення — 0644. Теки всередині шляху не підпадають під це налаштування. Це може суперечити іншим параметрам, які впливають на режим файлу, наприклад, fsGroup, і результат може бути встановлення інших бітів режимів.

    • secret.items ([]KeyToPath)

      Atomic: буде замінено під час злиття

      Якщо не вказано items, кожна пара ключ-значення у полі Data зазначеного Secret буде перенесена в том як файл, імʼя якого — це ключ, а вміст — значення. Якщо вказано, перераховані ключі будуть перенесені у вказані шляхи, а невказані ключі відсутні. Якщо вказано ключ, якого немає у Secret, налаштування тому завершиться помилкою, якщо він не позначений як необовʼязковий. Шляхи повинні бути відносними та не можуть містити шлях '..' або починатися з '..'.

  • downwardAPI (DownwardAPIVolumeSource)

    downwardAPI — представляє downward API Podʼа, який повинен заповнити цей том.

    DownwardAPIVolumeSource представляє том з вмістом з downward API. Томи downward API підтримують керування власністю та перепризначення міток SELinux.

    • downwardAPI.defaultMode (int32)

      Опційно: біти режимів, які використовуються для встановлення стандартних дозволів на створені файли. Має бути вісімковим значенням між 0000 та 0777 або десятковим значенням між 0 та 511. У форматі YAML можна використовувати як вісімкові, так і десяткові значення, у форматі JSON потрібно використовувати десяткові значення для режиму бітів. Стандартне значення — 0644. Теки всередині шляху не підпадають під це налаштування. Це може суперечити іншим параметрам, які впливають на режим файлу, наприклад, fsGroup, і результат може бути встановлення інших бітів режимів.

    • downwardAPI.items ([]DownwardAPIVolumeFile)

      Atomic: буде замінено під час злиття

      Items – список файлів тому downward API

  • projected (ProjectedVolumeSource)

    projected — елементи для ресурсів all-in-one Secret, ConfigMap, downward API

    Представляє джерело projected тому

    • projected.defaultMode (int32)

      defaultMode є бітами режимів, які використовуються для встановлення стандартних дозволів на створені файли. Має бути вісімковим значенням між 0000 та 0777 або десятковим значенням між 0 та 511. У форматі YAML можна використовувати як вісімкові, так і десяткові значення, у форматі JSON потрібно використовувати десяткові значення для режиму бітів. Стандартне значення — 0644. Теки всередині шляху не підпадають під це налаштування. Це може суперечити іншим параметрам, які впливають на режим файлу, наприклад, fsGroup, і результат може бути встановлення інших бітів режимів.

    • projected.sources ([]VolumeProjection)

      Atomic: буде замінено під час злиття

      sources — список джерел, які мають бути спроєцьовані. Кожен запис у цьому списку працює з одним джерелом.

      Проєкція, яка може бути спроєцьована разом з іншими підтримуваними типами томів. Тільки одне з цих полів повинно бути встановлене.

      • projected.sources.clusterTrustBundle (ClusterTrustBundleProjection)

        ClusterTrustBundle дозволяє podʼу отримати доступ до поля .spec.trustBundle обʼєктів ClusterTrustBundle через файл з автоматичним оновленням.

        Альфа-функція, контрольована через функціональну можливість ClusterTrustBundleProjection.

        Обʼєкти ClusterTrustBundle можуть бути вибрані за іменем або за комбінацією імені підписувача і селектора міток.

        Kubelet виконує агресивну нормалізацію вмісту PEM, записаного у файлову систему podʼа. Езотеричні функції PEM, такі як міжблочні коментарі та заголовки блоків, видаляються. Сертифікати дедуплікуються. Порядок сертифікатів у файлі довільний, і Kubelet може змінювати його з часом.

        ClusterTrustBundleProjection описує, як вибрати набір обʼєктів ClusterTrustBundle і спроектувати їх вміст у файлову систему подів.

        • projected.sources.clusterTrustBundle.path (string), обовʼязково

          Відносний шлях від кореня тому для запису пакунка.

        • projected.sources.clusterTrustBundle.labelSelector (LabelSelector)

          Вибирає всі ClusterTrustBundles, які відповідають цьому селектору міток. Має ефект, тільки якщо задано signerName. Взаємовиключне з name. Якщо не задано, інтерпретується як «не збігається ні з чим». Якщо задано, але пусте, інтерпретується як «збігається з усім».

        • projected.sources.clusterTrustBundle.name (string)

          Вибирає один ClusterTrustBundle за назвою об'єкта. Взаємовиключне з signerName та labelSelector.

        • projected.sources.clusterTrustBundle.optional (boolean)

          Якщо true, не блокувати запуск podʼа, якщо посилання на ClusterTrustBundle(и) недоступні. Якщо використовується імʼя, тоді дозволено відсутність вказаного ClusterTrustBundle. Якщо використовується signerName, тоді комбінація signerName і labelSelector може не відповідати жодному ClusterTrustBundle.

        • projected.sources.clusterTrustBundle.signerName (string)

          Виберає усі ClusterTrustBundles, які відповідають цьому імені підписувача. Взаємовиключні з name. Вміст усіх вибраних ClusterTrustBundles буде уніфіковано та дедупліковано.

      • projected.sources.configMap (ConfigMapProjection)

        configMap — інформація про дані ConfigMap, які мають бути спроєцьовані

        *Адаптує ConfigMap для projected тому

        Вміст поля Data цільового ConfigMap буде представлений у projected томі у вигляді файлів, використовуючи ключі у полі даних як назви файлів, якщо елемент items заповнений конкретними зіставленнями ключів зі шляхами. Зверніть увагу, що це ідентично джерелу тому ConfigMap без стандартного режиму.*

        • projected.sources.configMap.name (string)

          Name — назва обʼєкта на який посилаються. Це поле є обов'язковим для заповнення, але для забезпечення зворотної сумісності дозволяється залишати його порожнім. Екземпляри цього типу з порожнім значенням тут майже напевно є помилковими. Додаткова інформація: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names

        • projected.sources.configMap.optional (boolean)

          optional — вказує, чи ConfigMap або його ключі мають бути визначені.

        • projected.sources.configMap.items ([]KeyToPath)

          Atomic: буде замінено під час злиття

          Якщо не вказано items, кожна пара ключ-значення у полі Data зазначеного ConfigMap буде перенесена в том як файл, імʼя якого — це ключ, а вміст — значення. Якщо вказано, перераховані ключі будуть перенесені у вказані шляхи, а невказані ключі відсутні. Якщо вказано ключ, якого немає у ConfigMap, налаштування тому завершиться помилкою, якщо він не позначений як необовʼязковий. Шляхи повинні бути відносними та не можуть містити шлях '..' або починатися з '..'.

      • projected.sources.downwardAPI (DownwardAPIProjection)

        downwardAPI — інформація про дані downward API, які мають бути спроєцьовані

        Представляє інформацію downward API для проєцювання у projected том. Зверніть увагу, що це ідентично джерелу тому downward API без стандартного режиму.

        • projected.sources.downwardAPI.items ([]DownwardAPIVolumeFile)

          Atomic: буде замінено під час злиття

          Items — список файлів DownwardAPIVolume

      • projected.sources.secret (SecretProjection)

        secret – інформація про дані Secret, які мають бути спроєцьовані

        *Адаптує Secret для projected тому.

        Вміст поля Data цільового Secret буде представлений у projected томі у вигляді файлів, використовуючи ключі у полі Data як назви файлів. Зверніть увагу, що це ідентично джерелу тому Secret без стандартного режиму.*

        • projected.sources.secret.name (string)

          Name — назва обʼєкта на який посилаються. Це поле є обов'язковим для заповнення, але для забезпечення зворотної сумісності дозволяється залишати його порожнім. Екземпляри цього типу з порожнім значенням тут майже напевно є помилковими. Додаткова інформація: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names

        • projected.sources.secret.optional (boolean)

          optional — вказує, чи Secret або його ключі мають бути визначені.

        • projected.sources.secret.items ([]KeyToPath)

          Atomic: буде замінено під час злиття

          Якщо не вказано items, кожна пара ключ-значення у полі Data зазначеного Secret буде перенесена в том як файл, імʼя якого — це ключ, а вміст — значення. Якщо вказано, перераховані ключі будуть перенесені у вказані шляхи, а невказані ключі відсутні. Якщо вказано ключ, якого немає у Secret, налаштування тому завершиться помилкою, якщо він не позначений як необовʼязковий. Шляхи повинні бути відносними та не можуть містити шлях '..' або починатися з '..'.

      • projected.sources.serviceAccountToken (ServiceAccountTokenProjection)

        serviceAccountToken — інформація про дані serviceAccountToken, які мають бути спроєцьовані

        ServiceAccountTokenProjection представляє projected том токена службового облікового запису. Ця проєкція може бути використана для вставки токена службового облікового запису в файлову систему Podʼа для використання з API (сервера API Kubernetes або іншого).

        • projected.sources.serviceAccountToken.path (string), обовʼязково

          path — це шлях відносно точки монтування файлу для проєцювання токена.

        • projected.sources.serviceAccountToken.audience (string)

          audience — це призначений отримувач токена. Отримувач токена повинен ідентифікувати себе із вказаним ідентифікатором в аудиторії токена або, в іншому випадку, повинен відхилити токен. Стандартно audience — це ідентифікатор apiserver.

        • projected.sources.serviceAccountToken.expirationSeconds (int64)

          expirationSeconds — це запитаний термін дійсності токена службового облікового запису. В міру наближення до закінчення терміну дії токена, втулок томів kubelet буде працювати у режимі проактивної ротації токена службового облікового запису. Kubelet буде спробувати почати ротацію токена, якщо токен старше 80 відсотків його часу життя або якщо токен старше 24 годин. Стандартне значення — 1 година і повинно бути принаймні 10 хвилин.

Локальні / Тимчасові теки

  • emptyDir (EmptyDirVolumeSource)

    emptyDir представляє тимчасову теку, яка існує впродовж часу існування Podʼа. Додаткова інформація: https://kubernetes.io/docs/concepts/storage/volumes#emptydir

    Представляє порожню теку для Podʼа. Томи порожніх тек підтримують управління власністю та перепризначення міток SELinux.

    • emptyDir.medium (string)

      medium представляє тип носія для зберігання, який повинен підтримувати цю теку. Стандартне значення — "" (порожній рядок), що означає використання стандартного носія вузла. Повинно бути порожнім рядком (стандартно) або "Memory". Додаткова інформація: Посилання на документацію Kubernetes про EmptyDir

    • emptyDir.sizeLimit (Quantity)

      sizeLimit — це загальна кількість локальної памʼяті, необхідна для цього тому EmptyDir. Обмеження розміру також застосовується для носія типу "Memory". Максимальне використання на носії типу "Memory" для EmptyDir буде мінімальним значенням між зазначеним тут SizeLimit та сумою обмежень памʼяті всіх контейнерів у Podʼі. Стандартне значення — nil, що означає, що обмеження не визначено. Додаткова інформація: https://kubernetes.io/docs/concepts/storage/volumes#emptydir

  • hostPath (HostPathVolumeSource)

    hostPath представляє попередньо наявний файл або теку на хост-машині, який безпосередньо доступний контейнеру. Це зазвичай використовується для системних агентів або інших привілейованих речей, яким дозволено бачити хост-машину. Більшість контейнерів НЕ потребуватимуть цього. Додаткова інформація: https://kubernetes.io/docs/concepts/storage/volumes#hostpath

    Представляє шлях хосту зіставлений з Pod. Томи hostPath не підтримують управління власністю або перевизначення міток SELinux.

Постійні томи

  • awsElasticBlockStore (AWSElasticBlockStoreVolumeSource)

    awsElasticBlockStore представляє ресурс AWS Disk, який підключений до хост-машини kubelet і потім доступний Podʼу. Додаткова інформація: https://kubernetes.io/docs/concepts/storage/volumes#awselasticblockstore

    *Представляє ресурс Persistent Disk в AWS.

    Диск AWS EBS повинен існувати перед підключенням до контейнера. Диск також повинен знаходитися в тій же зоні AWS, що і kubelet. Диск AWS EBS може бути змонтований з приавами читання/запис тільки один раз. Томи AWS EBS підтримують управління власністю та перепризначення міток SELinux.*

    • awsElasticBlockStore.volumeID (string), обовʼязково

      volumeID — це унікальний ідентифікатор постійного дискового ресурсу в AWS (том Amazon EBS). Додаткова інформація: https://kubernetes.io/docs/concepts/storage/volumes#awselasticblockstore

    • awsElasticBlockStore.fsType (string)

      fsType — це тип файлової системи тому, який ви хочете змонтувати. Порада: Переконайтеся, що тип файлової системи підтримується операційною системою хосту. Приклади: "ext4", "xfs", "ntfs". Якщо не вказано, неявно припускається, що це "ext4". Додаткова інформація: https://kubernetes.io/docs/concepts/storage/volumes#awselasticblockstore

    • awsElasticBlockStore.partition (int32)

      partition — це розділ у томі, який ви хочете змонтувати. Якщо він не вказаний, то стандартно монтується за назвою тому. Приклади: Для тому /dev/sda1 ви вказуєте розділ "1". Аналогічно, розділ тому для /dev/sda є "0" (або ви можете залишити властивість порожньою).

    • awsElasticBlockStore.readOnly (boolean)

      readOnly — значення true примусово встановлює налаштування readOnly у VolumeMounts. Додаткова інформація: https://kubernetes.io/docs/concepts/storage/volumes#awselasticblockstore

  • azureDisk (AzureDiskVolumeSource)

    azureDisk представляє монтування Azure Data Disk на хості та привʼязує монтування до Podʼа.

    AzureDisk представляє монтування Azure Data Disk на хості та привʼязане монтування до Podʼа.

    • azureDisk.diskName (string), обовʼязкове

      diskName — це імʼя диска даних у blob-сховищі

    • azureDisk.diskURI (string), обовʼязкове

      diskURI — це URI диска даних у blob-сховищі

    • azureDisk.cachingMode (string)

      cachingMode — це режим кешування хосту: None, Read Only, Read Write.

    • azureDisk.fsType (string)

      fsType — це тип файлової системи для монтування. Повинен бути типом файлової системи, підтримуваним операційною системою хосту. Наприклад, "ext4", "xfs", "ntfs". Неявно припускається, що це "ext4", якщо не вказано інше.

    • azureDisk.kind (string)

      Очікувані значення kind: Shared (кілька blob-дисків на один обліковий запис зберігання), Dedicated (один blob-диск на обліковий запис зберігання), Managed (azure managed data disk, тільки в керованому наборі доступності). Стандартне значення — Shared.

    • azureDisk.readOnly (boolean)

      readOnly стандартне значення — false (читання/запис). Значення readOnly тут примусово встановлює налаштування ReadOnly у VolumeMounts.

  • azureFile (AzureFileVolumeSource)

    azureFile представляє монтування служби файлів Azure на хості та привʼязане монтування до Podʼа.

    AzureFile представляє монтування служби файлів Azure на хості та привʼязане монтування до Podʼа.

    • azureFile.secretName (string), обовʼязкове

      secretName — це імʼя секрету, що містить імʼя та ключ облікового запису Azure Storage.

    • azureFile.shareName (string), обовʼязкове

      shareName — це імʼя розділу Azure.

    • azureFile.readOnly (boolean)

      readOnly стандартне значення — false (читання/запис). Значення readOnly тут примусово встановлює налаштування ReadOnly у VolumeMounts.

  • cephfs (CephFSVolumeSource)

    cephFS представляє монтування Ceph FS на хості, яке діє впродовж життєвого циклу Podʼа.

    Представляє монтування файлової системи Ceph, яке діє впродовж життєвого циклу Podʼа. Томи cephfs не підтримують управління власністю або перепризначення міток SELinux.

    • cephfs.monitors ([]string), обовʼязкове

      Atomic: буде замінено під час злиття

      monitors є обовʼязковим: Monitors — це колекція моніторів Ceph. Додаткова інформація: https://examples.k8s.io/volumes/cephfs/README.md#how-to-use-it

    • cephfs.path (string)

      path є необовʼязковим: Використовується як корінь монтування, а не як повне дерево Ceph. Стандартне значення — /

    • cephfs.readOnly (boolean)

      readOnly є необовʼязковим: Стандартне значення — false (читання/запис). Значення readOnly тут примусово встановлює налаштування ReadOnly у VolumeMounts. Додаткова інформація: https://examples.k8s.io/volumes/cephfs/README.md#how-to-use-it

    • cephfs.secretFile (string)

      secretFile є необовʼязковим: SecretFile — це шлях до вʼязки ключів користувача. Стандартне значення — /etc/ceph/user.secret. Додаткова інформація: https://examples.k8s.io/volumes/cephfs/README.md#how-to-use-it

    • cephfs.secretRef (LocalObjectReference)

      secretRef є необовʼязковим: SecretRef — це посилання на секрет автентифікації для користувача. Стандартне значення — порожнє. Додаткова інформація: https://examples.k8s.io/volumes/cephfs/README.md#how-to-use-it

    • cephfs.user (string)

      user є необовʼязковим: User — це імʼя користувача rados. Стандартне значення — admin. Додаткова інформація: https://examples.k8s.io/volumes/cephfs/README.md#how-to-use-it

  • cinder (CinderVolumeSource)

    cinder представляє том Cinder, підключений і змонтований на хост-машині kubelet. Додаткова інформація: https://examples.k8s.io/mysql-cinder-pd/README.md

    Представляє ресурс тому Cinder в Openstack. Том Cinder повинен існувати перед монтуванням до контейнера. Том також повинен знаходитися в тому ж регіоні, що і kubelet. Томи Cinder підтримують управління власністю та перепризначення міток SELinux.

    • cinder.volumeID (string), обовʼязкове

      volumeID використовується для ідентифікації тому в Cinder. Додаткова інформація: https://examples.k8s.io/mysql-cinder-pd/README.md

    • cinder.fsType (string)

      fsType — це тип файлової системи для монтування. Повинен бути типом файлової системи, підтримуваним операційною системою хоста. Приклади: "ext4", "xfs", "ntfs". Неявно припускається, що це "ext4", якщо не вказано інше. Додаткова інформація: https://examples.k8s.io/mysql-cinder-pd/README.md

    • cinder.readOnly (boolean)

      readOnly стандартне значення — false (читання/запис). Значення readOnly тут примусово встановлює налаштування ReadOnly у VolumeMounts. Додаткова інформація: https://examples.k8s.io/mysql-cinder-pd/README.md

    • cinder.secretRef (LocalObjectReference)

      secretRef є необовʼязковим: вказує на обʼєкт секрету, що містить параметри, які використовуються для підключення до OpenStack.

  • csi (CSIVolumeSource)

    csi (Container Storage Interface) представляє ефемерне сховище, яке обробляється певними зовнішніми драйверами CSI (бета-функція).

    Представляє джерело розташування тому для монтування, керованого зовнішнім драйвером CSI

    • csi.driver (string), обовʼязкове

      driver — це імʼя драйвера CSI, який обробляє цей том. Проконсультуйтеся з адміністратором для отримання правильного імені, зареєстрованого в кластері.

    • csi.fsType (string)

      fsType для монтування. Наприклад, "ext4", "xfs", "ntfs". Якщо не вказано, порожнє значення передається відповідному драйверу CSI, який визначить стандартну файлову систему.

    • csi.nodePublishSecretRef (LocalObjectReference)

      nodePublishSecretRef є посиланням на обʼєкт секрету, що містить конфіденційну інформацію, яку потрібно передати драйверу CSI для завершення викликів CSI NodePublishVolume і NodeUnpublishVolume. Це поле є необовʼязковим і може бути порожнім, якщо секрет не потрібен. Якщо обʼєкт секрету містить більше одного секрету, всі посилання на секрети передаються.

    • csi.readOnly (boolean)

      readOnly вказує на конфігурацію тільки для читання для тому. Стандартне значення — false (читання/запис).

    • csi.volumeAttributes (map[string]string)

      volumeAttributes зберігає властивості, специфічні для драйвера, які передаються драйверу CSI. Проконсультуйтеся з документацією вашого драйвера для підтримуваних значень.

  • ephemeral (EphemeralVolumeSource)

    ephemeral представляє том, який обробляється кластерним драйвером зберігання. Життєвий цикл тому привʼязаний до Podʼа, який його визначає — том буде створено перед запуском Podʼа і видалено після видалення Podʼа.

    Використовуйте це, якщо: a) том потрібен лише під час роботи Podʼа, b) потрібні функції звичайних томів, такі як відновлення зі знімка або відстеження ємності, c) драйвер зберігання вказується через клас зберігання, і d) драйвер зберігання підтримує динамічне надання томів через PersistentVolumeClaim (див. EphemeralVolumeSource для отримання додаткової інформації про звʼязок між цим типом тому та PersistentVolumeClaim).

    Використовуйте PersistentVolumeClaim або один з API, специфічних для постачальника, для томів, які зберігаються довше, ніж життєвий цикл окремого Podʼа.

    Використовуйте CSI для легких локальних ефемерних томів, якщо драйвер CSI призначений для такого використання — див. документацію драйвера для отримання додаткової інформації.

    Pod може одночасно використовувати як ефемерні томи, так і постійні томи.

    Представляє ефемерний том, який обробляється звичайним драйвером зберігання.

    • ephemeral.volumeClaimTemplate (PersistentVolumeClaimTemplate)

      Буде використовуватись для створення окремого PVC для надання тому. Pod, в якому вбудовано цей EphemeralVolumeSource, буде власником PVC, тобто PVC буде видалено разом з Podʼом. Назва PVC буде <pod name>-<volume name>, де <volume name> — це назва з масиву PodSpec.Volumes. Валідація Podʼа відхилить Pod, якщо обʼєднана назва не є дійсною для PVC (наприклад, занадто довга).

      Існуючий PVC з такою назвою, який не належить Podʼу, не буде використаний для Podʼа, щоб уникнути випадкового використання неповʼязаного тому. Запуск Podʼа буде заблокований до видалення неповʼязаного PVC. Якщо такий попередньо створений PVC призначений для використання Podʼом, PVC має бути оновлено з посиланням на власника Podʼа після створення Podʼа. Зазвичай це не повинно бути необхідним, але може бути корисним при ручному відновленні зламаного кластера.

      Це поле є лише для читання, і Kubernetes не вноситиме змін до PVC після його створення.

      Обовʼязкове, не може бути nil.

      PersistentVolumeClaimTemplate використовується для створення обʼєктів PersistentVolumeClaim як частини EphemeralVolumeSource.

      • ephemeral.volumeClaimTemplate.spec (PersistentVolumeClaimSpec), обовʼязкове

        Специфікація для PersistentVolumeClaim. Весь вміст копіюється без змін у PVC, який створюється з цього шаблону. Ті ж самі поля, що й у PersistentVolumeClaim, також дійсні тут.

      • ephemeral.volumeClaimTemplate.metadata (ObjectMeta)

        Може містити мітки та анотації, які будуть скопійовані у PVC під час його створення. Інші поля не дозволені і будуть відхилені під час валідації.

  • fc (FCVolumeSource)

    fc представляє ресурс Fibre Channel, що підключений до хост-машини kubelet і потім експонується для доступу у Podʼі.

    Представляє том Fibre Channel. Томи Fibre Channel можуть монтуватися для запису/читання лише один раз. Томи Fibre Channel підтримують керування власністю та перепризначення міток SELinux.

    • fc.fsType (string)

      fsType — це тип файлової системи для монтування. Має бути типом файлової системи, який підтримується операційною системою хоста. Наприклад, "ext4", "xfs", "ntfs". Неявно вважається "ext4", якщо не вказано інше.

    • fc.lun (int32)

      lun є необовʼязковим: Номер LUN (логічної одиниці) цілі FC

    • fc.readOnly (boolean)

      readOnly є необовʼязковим: Стандартне значення — false (читання/запис). Значення ReadOnly тут примусово встановить параметр ReadOnly у VolumeMounts.

    • fc.targetWWNs ([]string)

      Atomic: буде замінено під час злиття

      targetWWNs є необовʼязковими: FC звертається до всесвітніх імен (WWNs)

    • fc.wwids ([]string)

      Atomic: буде замінено під час злиття

      wwids є необовʼязковими: Всесвітні ідентифікатори томів FC (wwids). Або wwids, або комбінація targetWWNs і lun повинні бути встановлені, але не обидва одночасно.

  • flexVolume (FlexVolumeSource)

    flexVolume представляє загальний ресурс тома, що створюється/підключається за допомогою втулка на основі exec.

    FlexVolume представляє загальний ресурс тома, що створюється/підключається за допомогою втулка на основі exec.

    • flexVolume.driver (string), обовʼязково

      driver — це назва драйвера, який використовується для цього тома.

    • flexVolume.fsType (string)

      fsType — це тип файлової системи для монтування. Має бути тип файлової системи, який підтримується операційною системою хоста. Наприклад, "ext4", "xfs", "ntfs". Стандартний тип файлової системи залежить від скрипта FlexVolume.

    • flexVolume.options (map[string]string)

      options є необовʼязковим: це поле містить додаткові командні параметри, якщо такі є.

    • flexVolume.readOnly (boolean)

      readOnly є необовʼязковим: Стандартне значення — false (читання/запис). Значення ReadOnly тут примусово встановить параметр ReadOnly у VolumeMounts.

    • flexVolume.secretRef (LocalObjectReference)

      secretRef є необовʼязковим: secretRef — це посилання на обʼєкт секрету, що містить конфіденційну інформацію для передачі у скрипти втулка. Воно може бути порожнім, якщо обʼєкт секрету не вказаний. Якщо обʼєкт секрету містить більше одного секрету, всі секрети передаються у скрипти втулка.

  • flocker (FlockerVolumeSource)

    flocker представляє том Flocker, приєднаний до хост-машини kubelet. Залежить від роботи служби управління Flocker.

    Представляє том Flocker, змонтований агентом Flocker. Повинно бути встановлено тільки щось одне з datasetName і datasetUUID. Томи Flocker не підтримують керування власністю або перепризначення міток SELinux.

    • flocker.datasetName (string)

      datasetName — це назва набору даних, збереженого як метадані -> name на наборі даних для Flocker слід вважати застарілим

    • flocker.datasetUUID (string)

      datasetUUID — це UUID набору даних. Це унікальний ідентифікатор набору даних Flocker.

  • gcePersistentDisk (GCEPersistentDiskVolumeSource)

    gcePersistentDisk представляє ресурс диска GCE, який приєднаний до хост-машини kubelet і потім відкривається для доступу у Podʼі. Додаткова інформація: https://kubernetes.io/docs/concepts/storage/volumes#gcepersistentdisk

    *Представляє ресурс постійного диска в Google Compute Engine.

    Для монтування до контейнера повинен існувати диск GCE PD. Диск також повинен знаходитися в тому ж проекті GCE та зоні, що й kubelet. Диск GCE PD може бути змонтований лише один раз для читання/запису або багато разів для читання. Диски GCE PD підтримують керування власністю та перепризначення міток SELinux.*

    • gcePersistentDisk.pdName (string), обовʼязково

      pdName — унікальна назва ресурсу PD в GCE. Використовується для ідентифікації диска в GCE. Додаткова інформація: https://kubernetes.io/docs/concepts/storage/volumes#gcepersistentdisk

    • gcePersistentDisk.fsType (string)

      fsType — тип файлової системи тома, який ви хочете змонтувати. Порада: Переконайтеся, що тип файлової системи підтримується операційною системою хоста. Приклади: "ext4", "xfs", "ntfs". Неявно вважається "ext4", якщо не вказано інше. Додаткова інформація: https://kubernetes.io/docs/concepts/storage/volumes#gcepersistentdisk

    • gcePersistentDisk.partition (int32)

      partition — це розділ у томі, який ви хочете змонтувати. Якщо пропущено, стандартно монтується за імʼям тома. Приклади: Для тому /dev/sda1 ви вказуєте розділ як "1". Так само, розділ тому для /dev/sda — "0" (або ви можете залишити властивість порожньою). Додаткова інформація: https://kubernetes.io/docs/concepts/storage/volumes#gcepersistentdisk

    • gcePersistentDisk.readOnly (boolean)

      readOnly тут примусово встановить параметр ReadOnly у VolumeMounts. Стандартне значення — false. Додаткова інформація: https://kubernetes.io/docs/concepts/storage/volumes#gcepersistentdisk

  • glusterfs (GlusterfsVolumeSource)

    glusterfs представляє монтування Glusterfs на хості, яке діє впрожовж життєвого циклу Podʼа. Додаткова інформація: https://examples.k8s.io/volumes/glusterfs/README.md

    Представляє монтування Glusterfs, яке діє впрожовж життєвого циклу Podʼа. Томи Glusterfs не підтримують керування власністю або перепризначення міток SELinux.

  • iscsi (ISCSIVolumeSource)

    iscsi представляє ресурс диска ISCSI, який приєднаний до хост-машини kubelet і потім експонується для доступу у Podʼі. Додаткова інформація: https://examples.k8s.io/volumes/iscsi/README.md

    Представляє диск ISCSI. Томи ISCSI можуть бути змонтовані лише один раз для читання/запису. Томи ISCSI підтримують керування власністю та перепризначення міток SELinux.

    • iscsi.iqn (string), обовʼязково

      iqn — це цільове Імʼя ISCSI Qualified Name.

    • iscsi.lun (int32), обовʼязково

      lun представляє номер цільового LUN (логічної одиниці) ISCSI.

    • iscsi.targetPortal (string), обовʼязково

      targetPortal — це цільовий портал ISCSI. Портал — це IP або ip_addr:порт, якщо порт відмінний від типового (зазвичай TCP-порти 860 і 3260).

    • iscsi.chapAuthDiscovery (boolean)

      chapAuthDiscovery визначає, чи підтримується автентифікація CHAP для виявлення ISCSI

    • iscsi.chapAuthSession (boolean)

      chapAuthSession визначає, чи підтримується сесійна автентифікація CHAP для ISCSI

    • iscsi.fsType (string)

      fsType — це тип файлової системи тома, який ви хочете змонтувати. Порада: Переконайтеся, що тип файлової системи підтримується операційною системою хоста. Приклади: "ext4", "xfs", "ntfs". Неявно вважається "ext4", якщо не вказано інше. Додаткова інформація: https://kubernetes.io/docs/concepts/storage/volumes#iscsi

    • iscsi.initiatorName (string)

      initiatorName — це власне Імʼя Ініціатора ISCSI. Якщо initiatorName вказаний одночасно з iscsiInterface, буде створено новий інтерфейс ISCSI <цільовий портал>:<імʼя тома> для підключення.

    • iscsi.iscsiInterface (string)

      iscsiInterface — це імʼя інтерфейсу, який використовує транспорт ISCSI. Стандартне значення — 'default' (tcp).

    • iscsi.portals ([]string)

      Atomic: буде замінено під час злиття

      portals — це список цільових порталів ISCSI. Портал — це IP або ip_addr:порт, якщо порт відмінний від типового (зазвичай TCP-порти 860 і 3260).

    • iscsi.readOnly (boolean)

      readOnly тут примусово встановить параметр ReadOnly у VolumeMounts. Стандартне значення — false.

    • iscsi.secretRef (LocalObjectReference)

      secretRef — це Секрет CHAP для автентифікації цілі та ініціатора ISCSI.

  • image (ImageVolumeSource)

    image представляє обʼєкт OCI (образ контейнерна або артефакт), який завантажується та монтується на хост-машині kubelet. Том призначається під час запуску Podʼа в залежності від значення PullPolicy:

    • Always: kubelet завжди намагається завантажити посилання. Створення контейнера завершиться невдачею, якщо завантаження не вдасться.
    • Never: kubelet ніколи не завантажує посилання і використовує лише локальний образ або артефакт. Створення контейнера завершиться невдачею, якщо посилання немає.
    • IfNotPresent: kubelet завантажує посилання, якщо воно вже не присутнє на диску. Створення контейнера завершиться невдачею, якщо посилання немає, а завантаження не вдасться.

    Том буде перепризначатись, якщо pod буде видалено перестворено, що означає, що новий віддалений контент стане доступним при перестворенні Podʼа. Невдача при визначенні або завантаженні образу під час запуску Podʼа блокуватиме запуск контейнерів і може додати значну затримку. У разі невдачі будуть виконані повторні спроби за допомогою стандартного часу зворотнього відліку для томів і про них буде повідомлено у полі reason і message Podʼа.

    Типи обʼєктів, які можуть бути змонтовані цим томом, визначаються реалізацією серодовища виконання контейнерів на хост-машині і, як мінімум, повинні включати всі дійсні типи, підтримувані полем image контейнера. Обʼєкт OCI монтується в одну теку (spec.containers[*].volumeMounts.mountPath), обʼєднуючи шари маніфесту так само, як і для образів контейнерів. Том буде змонтований тільки для читання (ro) та міститиме файли, які не можна виконувати (noexec). Монтування субшляхів для контейнерів не підтримуються (spec.containers[*].volumeMounts.subpath). Поле spec.securityContext.fsGroupChangePolicy не впливає на цей тип тому.

    ImageVolumeSource представляє ресурс тома image.

    • image.pullPolicy (string)

      Політика завантаження OCI об\єктів. Можливі значення:

      • Always: kubelet завжди намагається завантажити посилання. Створення контейнера завершиться невдачею, якщо завантаження не вдасться.
      • Never: kubelet ніколи не завантажує посилання і використовує лише локальний образ або артефакт. Створення контейнера завершиться невдачею, якщо посилання немає.
      • IfNotPresent: kubelet завантажує посилання, якщо воно вже не присутнє на диску. Створення контейнера завершиться невдачею, якщо посилання немає, а завантаження не вдасться.

      Стандартно використовується значення Always, якщо вказано тег :latest, або IfNotPresent в інших випадках.

    • image.reference (string)

      Обовʼязково: Посилання на образ або артефакт, що буде використовуватися. Працює так само, як і поле pod.spec.containers[*].image. Секрети для завантаження (pull secrets) будуть зібрані так само, як і для образу контейнера, за допомогою пошуку облікових даних вузла, секретів для завантаження образів у Service Account та секретів для завантаження образів у специфікації podʼа. Більше інформації: https://kubernetes.io/docs/concepts/containers/images.

      Це поле є необовʼязковим, щоб дозволити вищим рівням керування конфігурацією використовувати стандартне значення або перевизначати образи контейнерів у контролерах робочих навантажень, таких як Deployments та StatefulSets.

  • nfs (NFSVolumeSource)

    nfs представляє монтування NFS на хості, яке діє впрожовж життєвого циклу Podʼа. Додаткова інформація: https://kubernetes.io/docs/concepts/storage/volumes#nfs

    Представляє монтування NFS, яке діє впрожовж життєвого циклу Podʼа. Томи NFS не підтримують керування власністю або перепризначення міток SELinux.

  • photonPersistentDisk (PhotonPersistentDiskVolumeSource)

    photonPersistentDisk представляє постійний диск PhotonController, приєднаний та змонтований на хост-машині kubelets.

    Представляє ресурс постійного диска Photon Controller.

    • photonPersistentDisk.pdID (string), обовʼязково

      pdID — це ідентифікатор, який ідентифікує постійний диск Photon Controller.

    • photonPersistentDisk.fsType (string)

      fsType — це тип файлової системи для монтування. Має бути тип файлової системи, який підтримується операційною системою хоста. Наприклад, "ext4", "xfs", "ntfs". Неявно вважається "ext4", якщо не вказано інше.

  • portworxVolume (PortworxVolumeSource)

    portworxVolume представляє том Portworx, приєднаний та змонтований на хост-машині kubelets.

    PortworxVolumeSource представляє ресурс тома Portworx.

    • portworxVolume.volumeID (string), обовʼязково

      volumeID унікально ідентифікує том Portworx.

    • portworxVolume.fsType (string)

      fsType представляє тип файлової системи для монтування. Має бути тип файлової системи, який підтримується операційною системою хоста. Наприклад, "ext4", "xfs". Неявно вважається "ext4", якщо не вказано інше.

    • portworxVolume.readOnly (boolean)

      readOnly стандартне значення — false (читання/запис). Встановлення readOnly тут примусить встановити параметр ReadOnly у VolumeMounts.

  • quobyte (QuobyteVolumeSource)

    quobyte представляє монтування Quobyte на хості, яке діє впродовж життєвого циклу Podʼа.

    Представляє монтування Quobyte, яке діє впродовж життєвого циклу Podʼа. Томи Quobyte не підтримують керування власністю або перепризначення міток SELinux.

    • quobyte.registry (string), обовʼязково

      registry представляє один або кілька служб реєстру Quobyte, вказаних як рядок у вигляді пари host:port (декілька записів розділяються комами), який діє як центральний реєстр для томів.

    • quobyte.volume (string), обовʼязково

      volume — це рядок, який посилається на вже створений том Quobyte за імʼям.

    • quobyte.group (string)

      group — група для відображення доступу до тома. Стандартне знечення — без групи.

    • quobyte.readOnly (boolean)

      readOnly тут примусово змусить монтування тома Quobyte з правами тільки на читання. Стандартне значення — false.

    • quobyte.tenant (string)

      tenant, який володіє вказаним томом Quobyte в Backend. Використовується з динамічно створюваними томами Quobyte, значення встановлюється втулком.

    • quobyte.user (string)

      user — користувач для зіставлення (map) доступу до тома. Стандартне знечення — користувач serivceaccount.

  • rbd (RBDVolumeSource)

    rbd представляє монтування блочного пристрою Rados на хості, яке діє впродовж життєвого циклу Podʼа. Додаткова інформація: https://examples.k8s.io/volumes/rbd/README.md

    Представляє монтування блочного пристрою Rados, яке діє впродовж життєвого циклу Podʼа. Томи RBD підтримують керування власністю та перепризначення міток SELinux.

    • rbd.image (string), обовʼязково

      image — це імʼя образу Rados. Додаткова інформація: https://examples.k8s.io/volumes/rbd/README.md#how-to-use-it

    • rbd.monitors ([]string), обовʼязково

      Atomic: буде замінено під час злиття

      monitors — це колекція моніторів Ceph. Додаткова інформація: https://examples.k8s.io/volumes/rbd/README.md#how-to-use-it

    • rbd.fsType (string)

      fsType — це тип файлової системи тома, який ви хочете змонтувати. Порада: Переконайтеся, що тип файлової системи підтримується операційною системою хоста. Приклади: "ext4", "xfs", "ntfs". Неявно вважається "ext4", якщо не вказано інше. Додаткова інформація: https://kubernetes.io/docs/concepts/storage/volumes#rbd

    • rbd.keyring (string)

      keyring — це шлях до вʼязки ключів користувача RBDUser. Стандартне значення — /etc/ceph/keyring. Додаткова інформація: htts://examples.k8s.io/volumes/rbd/README.md#how-to-use-it

    • rbd.pool (string)

      pool — це імʼя пулу Rados. Стандартне значення — rbd. Додаткова інформація: https://exampes.k8s.io/volumes/rbd/README.md#how-to-use-it

    • rbd.readOnly (boolean)

      readOnly тут примусово встановить параметр ReadOnly у VolumeMounts. Стандартне значення — false. Додаткова інформація: https://examples.k8s.io/volumes/rbd/README.md#how-to-use-it

    • rbd.secretRef (LocalObjectReference)

      secretRef — це імʼя автентифікаційного секрету для користувача RBDUser. Якщо вказано, перевизначає keyring. Стандартне значення — nil. Додаткова інформація: https://exampes.k8s.io/volumes/rbd/README.md#how-to-use-it

    • rbd.user (string)

      user — це імʼя користувача Rados. Стандартне значення — admin. Додаткова інформація: https://exampes.k8s.io/volumes/rbd/README.md#how-to-use-it

  • scaleIO (ScaleIOVolumeSource)

    scaleIO представляє постійний том ScaleIO, приєднаний та змонтований на вузлах Kubernetes.

    ScaleIOVolumeSource представляє постійний том ScaleIO

    • scaleIO.gateway (string), обовʼязково

      gateway — це адреса хоста шлюзу API ScaleIO.

    • scaleIO.secretRef (LocalObjectReference), обовʼязково

      secretRef посилається на секрет для користувача ScaleIO та іншої конфіденційної інформації. Якщо це не надано, операція входу не вдасться.

    • scaleIO.system (string), обовʼязково

      system — це імʼя системи зберігання, налаштоване в ScaleIO.

    • scaleIO.fsType (string)

      fsType — це тип файлової системи для монтування. Має бути тип файлової системи, який підтримується операційною системою хоста. Наприклад, "ext4", "xfs", "ntfs". Стандартне значення — "xfs".

    • scaleIO.protectionDomain (string)

      protectionDomain — це імʼя ScaleIO Protection Domain для налаштованого зберігання.

    • scaleIO.readOnly (boolean)

      readOnly стандартне значення — false (читання/запис). Встановлення readOnly тут примусить встановити параметр ReadOnly у VolumeMounts.

    • scaleIO.sslEnabled (boolean)

      sslEnabled — прапорець, що ввімкнує/вимикає SSL-звʼязок з шлюзом, станддартне значення — false

    • scaleIO.storageMode (string)

      storageMode вказує, чи повинно бути зберігання для тому ThickProvisioned чи ThinProvisioned. Стандартне значення — ThinProvisioned.

    • scaleIO.storagePool (string)

      storagePool — це пул зберігання ScaleIO, повʼязаний з доменом захисту.

    • scaleIO.volumeName (string)

      volumeName — це імʼя тому, вже створеного в системі ScaleIO, який повʼязаний з цим джерелом тому.

  • storageos (StorageOSVolumeSource)

    storageos представляє том StorageOS, приєднаний та змонтований на вузлах Kubernetes.

    Представляє постійний ресурс тому StorageOS.

    • storageos.fsType (string)

      fsType — це тип файлової системи для монтування. Має бути тип файлової системи, який підтримується операційною системою хоста. Наприклад, "ext4", "xfs", "ntfs". Неявно вважається "ext4", якщо не вказано інше.

    • storageos.readOnly (boolean)

      readOnly стандартне значення — false (читання/запис). Встановлення readOnly тут примусить встановити параметр ReadOnly у VolumeMounts.

    • storageos.secretRef (LocalObjectReference)

      secretRef вказує секрет для отримання облікових даних API StorageOS. Якщо не вказано, будуть спробовані стандартні значення.

    • storageos.volumeName (string)

      volumeName — це людино-читане імʼя тому StorageOS. Імена томів є унікальними лише в межах простору імен.

    • storageos.volumeNamespace (string)

      volumeNamespace вказує том простору імен в межах StorageOS. Якщо простір імен не вказано, тоді буде використано простір імен Pod. Це дозволяє дублювати простори імен Kubernetes у StorageOS для більш тісної інтеграції. Встановіть VolumeName на будь-яке імʼя для заміни стандартної поведінки. Встановіть на "default", якщо ви не використовуєте простори імен у StorageOS. Простори імен, які не існують заздалегідь у StorageOS, будуть створені.

  • vsphereVolume (VsphereVirtualDiskVolumeSource)

    vsphereVolume представляє том vSphere, приєднаний та змонтований на вузлах kubelet.

    Представляє ресурс тому vSphere.

    • vsphereVolume.volumePath (string), обовʼязково

      volumePath — це шлях, який ідентифікує том vmdk vSphere.

    • vsphereVolume.fsType (string)

      fsType — це тип файлової системи для монтування. Має бути тип файлової системи, який підтримується операційною системою хоста. Наприклад, "ext4", "xfs", "ntfs". Неявно вважається "ext4", якщо не вказано інше.

    • vsphereVolume.storagePolicyID (string)

      storagePolicyID — це ідентифікатор профілю управління політикою зберігання (SPBM), повʼязаний з іменем StoragePolicyName.

    • vsphereVolume.storagePolicyName (string)

      storagePolicyName — це імʼя профілю управління політикою зберігання (SPBM).

Застаріле

  • gitRepo (GitRepoVolumeSource)

    gitRepo представляє репозиторій git на певному рівні ревізії. Застаріло: GitRepo застаріло. Для створення контейнера з репозиторієм git підключіть EmptyDir до InitContainer, який клонує репо за допомогою git, а потім підключіть EmptyDir до контейнера Pod.

    *Представляє том, який заповнений вмістом репозиторію git. Томи репозиторію git не підтримують управління власниками. Томи репозиторію git підтримують перепризначення міток SELinux.

    Застаріло: GitRepo застаріло. Для створення контейнера з репозиторієм git підключіть EmptyDir до InitContainer, який клонує репо за допомогою git, а потім підключіть EmptyDir до контейнера Pod.*

    • gitRepo.repository (string), обовʼязково

      repository — це URL

    • gitRepo.directory (string)

      directory — це назва цільової теки. Не повинен містити або починатися з '..'. Якщо '.' надано, тека тому буде репозиторієм git. В іншому випадку, якщо вказано, том буде містити репозиторій git у підтеці з вказаною назвою.

    • gitRepo.revision (string)

      revision — це хеш коміту для вказаної ревізії.

DownwardAPIVolumeFile

DownwardAPIVolumeFile представляє інформацію для створення файлу, що містить поле pod.


  • path (string), обовʼязково

    Обовʼязково: path — це відносний шлях до файлу, який буде створено. Не повинен бути абсолютним або містити шлях "..". Має бути закодований у кодуванні utf-8. Перший елемент відносного шляху не повинен починатися з "..".

  • fieldRef (ObjectFieldSelector)

    Обовʼязково: Вибирає поле pod: підтримуються лише анотації, мітки, імʼя, uid та простір імен.

  • mode (int32)

    Опціонально: біти режиму, які використовуються для встановлення дозволів на цей файл, повинні бути вісімковим значенням від 0000 до 0777 або десятковим значенням від 0 до 511. У YAML приймаються як вісімкові, так і десяткові значення, у JSON потрібні десяткові значення для бітів режиму. Якщо не вказано, буде використано стандартне значення для тому. Це може конфліктувати з іншими параметрами, що впливають на режим файлу, наприклад, fsGroup, і результат може бути іншим набором бітів режиму.

  • resourceFieldRef (ResourceFieldSelector)

    Вибирає ресурс контейнера: наразі підтримуються лише обмеження та запити ресурсів (limits.cpu, limits.memory, requests.cpu та requests.memory).

KeyToPath

Зіставляє ключ зі шляхом в томі.


  • key (string), обовʼязково

    key — це ключ, який потрібно проєцювати.

  • path (string), обовʼязково

    path — це відносний шлях файлу, який слід прикріпити до ключа. Не може бути абсолютним шляхом. Не може містити елемента шляху '..'. Не може починатися з рядка '..'.

  • mode (int32)

    mode — опціонально: біти режиму, які використовуються для встановлення дозволів на цей файл. Має бути вісімковим значенням між 0000 та 0777 або десятковим значенням між 0 та 511. У YAML приймаються як вісімкові, так і десяткові значення, у JSON для бітів режиму потрібні десяткові значення. Якщо не вказано, буде використано стнадартне значення для тому. Це може конфліктувати з іншими параметрами, що впливають на режим файлу, такими як fsGroup, і результат може бути іншим набором бітів режиму.

6.5.3.11 - VolumeAttachment

VolumeAttachment фіксує намір приєднати або відʼєднати вказаний том до/від вказаного вузла.

apiVersion: storage.k8s.io/v1

import "k8s.io/api/storage/v1"

VolumeAttachment

VolumeAttachment фіксує намір приєднати або відʼєднати вказаний том до/від вказаного вузла.

Обʼєкти VolumeAttachment не належать до просторів імен.


  • apiVersion: storage.k8s.io/v1

  • kind: VolumeAttachment

  • metadata (ObjectMeta)

    Стандартні метадані обʼєкта. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

  • spec (VolumeAttachmentSpec), обовʼязково

    spec представляє специфікацію бажаної поведінки при приєднанні/відʼєднанні тому. Заповнюється системою Kubernetes.

  • status (VolumeAttachmentStatus)

    status представляє статус запиту VolumeAttachment. Заповнюється сутністю, що завершує операцію приєднання або відʼєднання, тобто external-attacher.

VolumeAttachmentSpec

VolumeAttachmentSpec — це специфікація запиту на приєднання тому.


  • attacher (string), обовʼязково

    attacher вказує назву драйвера тому, який МАЄ обробити цей запит. Це назва, яку повертає GetPluginName().

  • nodeName (string), обовʼязково

    nodeName представляє вузол, до якого повинен бути приєднаний том.

  • source (VolumeAttachmentSource), обовʼязково

    source представляє том, який повинен бути приєднаний.

    VolumeAttachmentSource представляє том, який повинен бути приєднаний. Зараз лише PersistenVolumes можуть бути приєднані за допомогою зовнішнього attacherʼa, у майбутньому ми можемо дозволити також inline томи в Podʼах. Може бути встановлений лише один елемент.

    • source.inlineVolumeSpec (PersistentVolumeSpec)

      inlineVolumeSpec містить всю необхідну інформацію для приєднання persistent volume, визначеного VolumeSource Podʼа. Це поле заповнюється лише для функції CSIMigration. Воно містить перетворені поля з VolumeSource Podʼа до PersistentVolumeSpec. Це поле є на рівні beta і враховується лише серверами, які включили функцію CSIMigration.

    • source.persistentVolumeName (string)

      persistentVolumeName представляє імʼя persistent volume для приєднання.

VolumeAttachmentStatus

VolumeAttachmentStatus — це статус запиту на приєднання тому.


  • attached (boolean), обовʼязково

    attached вказує, що том успішно приєднаний. Це поле має бути встановлено лише сутністю, яка завершує операцію приєднання, тобто external-attacher.

  • attachError (VolumeError)

    attachError представляє останню помилку, яка виникла під час операції приєднання, якщо така була. Це поле має бути встановлено лише сутністю, яка завершує операцію приєднання, тобто external-attacher.

    VolumeError фіксує помилку, яка виникла під час операції з томом.

    • attachError.message (string)

      message представляє помилку, яка виникла під час операції приєднання або відʼєднання. Цей рядок може бути доданий в лог, тож він не повинен містити конфіденційної інформації.

    • attachError.time (Time)

      time представляє час, коли сталася помилка.

      Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

  • attachmentMetadata (map[string]string)

    attachmentMetadata заповнюється будь-якою інформацією, яка повертається під час успішної операції приєднання і яка повинна бути передана в наступні виклики WaitForAttach або Mount. Це поле має бути встановлено лише сутністю, яка завершує операцію приєднання, тобто external-attacher.

  • detachError (VolumeError)

    detachError представляє останню помилку, яка виникла під час операції відʼєднання, якщо така була. Це поле має бути встановлено лише сутністю, яка завершує операцію відʼєднання, тобто external-attacher.

    VolumeError фіксує помилку, яка виникла під час операції з томом.

    • detachError.message (string)

      message представляє помилку, яка виникла під час операції приєднання або відʼєднання. Цей рядок може бути доданий в лог, тож він не повинен містити конфіденційної інформації.

    • detachError.time (Time)

      time представляє час, коли сталася помилка.

      Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

VolumeAttachmentList

VolumeAttachmentList — це колекція обʼєктів VolumeAttachment.


Операції


get отримати вказаний VolumeAttachment

HTTP запит

GET /apis/storage.k8s.io/v1/volumeattachments/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя VolumeAttachment

  • pretty (в запиті): string

    pretty

Відповідь

200 (VolumeAttachment): OK

401: Unauthorized

get отримати статус вказаного VolumeAttachment

HTTP запит

GET /apis/storage.k8s.io/v1/volumeattachments/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя VolumeAttachment

  • pretty (в запиті): string

    pretty

Відповідь

200 (VolumeAttachment): OK

401: Unauthorized

list перелік абоперегляд обʼєктів типу VolumeAttachment

HTTP запит

GET /apis/storage.k8s.io/v1/volumeattachments

Параметри

Відповідь

200 (VolumeAttachmentList): OK

401: Unauthorized

create створення VolumeAttachment

HTTP запит

POST /apis/storage.k8s.io/v1/volumeattachments

Параметри

Відповідь

200 (VolumeAttachment): OK

201 (VolumeAttachment): Created

202 (VolumeAttachment): Accepted

401: Unauthorized

update заміна вказаного VolumeAttachment

HTTP запит

PUT /apis/storage.k8s.io/v1/volumeattachments/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя VolumeAttachment

  • body: VolumeAttachment, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (VolumeAttachment): OK

201 (VolumeAttachment): Created

401: Unauthorized

update заміна вказаного VolumeAttachment

HTTP запит

PUT /apis/storage.k8s.io/v1/volumeattachments/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя VolumeAttachment

  • body: VolumeAttachment, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (VolumeAttachment): OK

201 (VolumeAttachment): Created

401: Unauthorized

patch часткове оновлення вказаного VolumeAttachment

HTTP запит

PATCH /apis/storage.k8s.io/v1/volumeattachments/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя VolumeAttachment

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (VolumeAttachment): OK

201 (VolumeAttachment): Created

401: Unauthorized

patch часткове оновлення статусу вказаного VolumeAttachment

HTTP запит

PATCH /apis/storage.k8s.io/v1/volumeattachments/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя VolumeAttachment

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (VolumeAttachment): OK

201 (VolumeAttachment): Created

401: Unauthorized

delete видалення VolumeAttachment

HTTP запит

DELETE /apis/storage.k8s.io/v1/volumeattachments/{name}

Параметри

Відповідь

200 (VolumeAttachment): OK

202 (VolumeAttachment): Accepted

401: Unauthorized

deletecollection видалення колекції VolumeAttachment

HTTP запит

DELETE /apis/storage.k8s.io/v1/volumeattachments

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

6.5.3.12 - VolumeAttributesClass v1beta1

VolumeAttributesClass представляє специфікацію змінних атрибутів тома, визначених драйвером CSI.

apiVersion: storage.k8s.io/v1beta1

import "k8s.io/api/storage/v1beta1"

VolumeAttributesClass

VolumeAttributesClass представляє специфікацію змінних атрибутів тома, визначених драйвером CSI. Клас можна вказати під час динамічного резервування PersistentVolumeClaims і змінити у специфікації PersistentVolumeClaim після резервування.


VolumeAttributesClassList

VolumeAttributesClassList — це колекція обʼєктів VolumeAttributesClass.


Операції


get отримати вказаний VolumeAttributesClass

HTTP запит

GET /apis/storage.k8s.io/v1beta1/volumeattributesclasses/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя VolumeAttributesClass

  • pretty (в запиті): string

    pretty

Відповідь

200 (VolumeAttributesClass): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу VolumeAttributesClass

HTTP запит

GET /apis/storage.k8s.io/v1beta1/volumeattributesclasses

Параметри

Відповідь

200 (VolumeAttributesClassList): OK

401: Unauthorized

create створення VolumeAttributesClass

HTTP запит

POST /apis/storage.k8s.io/v1beta1/volumeattributesclasses

Параметри

Відповідь

200 (VolumeAttributesClass): OK

201 (VolumeAttributesClass): Created

202 (VolumeAttributesClass): Accepted

401: Unauthorized

update заміна вказаного VolumeAttributesClass

HTTP запит

PUT /apis/storage.k8s.io/v1beta1/volumeattributesclasses/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя VolumeAttributesClass

  • body: VolumeAttributesClass, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (VolumeAttributesClass): OK

201 (VolumeAttributesClass): Created

401: Unauthorized

patch часткове оновлення вказаного VolumeAttributesClass

HTTP запит

PATCH /apis/storage.k8s.io/v1beta1/volumeattributesclasses/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя VolumeAttributesClass

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (VolumeAttributesClass): OK

201 (VolumeAttributesClass): Created

401: Unauthorized

delete видалення VolumeAttributesClass

HTTP запит

DELETE /apis/storage.k8s.io/v1beta1/volumeattributesclasses/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя VolumeAttributesClass

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (VolumeAttributesClass): OK

202 (VolumeAttributesClass): Accepted

401: Unauthorized

deletecollection видалення колекції VolumeAttributesClass

HTTP запит

DELETE /apis/storage.k8s.io/v1beta1/volumeattributesclasses

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

6.5.4 - Ресурси автентифікації

6.5.4.1 - ServiceAccount

ServiceAccount повʼязує разом:

  • імʼя, зрозуміле користувачам і, можливо, периферійним системам, для ідентифікації;
  • головну діючу особу, яка може бути автентифікована і авторизована;
  • набір секретів.

apiVersion: v1

import "k8s.io/api/core/v1"

ServiceAccount

ServiceAccount повʼязує разом

  • імʼя, зрозуміле користувачам і, можливо, периферійним системам, для ідентифікації;
  • головну діючу особу, яка може бути автентифікована і авторизована;
  • набір секретів.

  • apiVersion: v1

  • kind: ServiceAccount

  • metadata (ObjectMeta)

    Стандартні метадані обʼєкта. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

  • automountServiceAccountToken (boolean)

    automountServiceAccountToken вказує, чи повинні Podʼи, які працюють від імені цього службового облікового запису, автоматично мати змонтований API токен. Може бути перевизначено на рівні Podʼа.

  • imagePullSecrets ([]LocalObjectReference)

    Atomic: буде замінено під час злиття

    imagePullSecrets — це список посилань на Sercretʼи в тому ж просторі імен для використання при завантаженні будь-яких образів у Podʼах, які використовують цей службовий обліковий запис. ImagePullSecrets відрізняються від Secrets тим, що Secrets можуть бути змонтовані в Pod, а ImagePullSecrets доступні лише для kubelet. Докладніше: https://kubernetes.io/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod

  • secrets ([]ObjectReference)

    Patch strategy: обʼєднання за ключем name

    Map: унікальні значення ключа name будуть збережені під час злиття

    secrets — це список секретів у тому ж просторі імен, які Podʼи, що використовують цей службовий обліковий запис, можуть використовувати. Podʼи обмежуються цим списком лише у випадку, якщо цей службовий обліковий запис має анотацію "kubernetes.io/enforce-mountable-secrets" зі значенням "true". Це поле не слід використовувати для пошуку автоматично створених секретів токенів службових облікових записів для використання поза межами Podʼів. Натомість токени можна запитувати безпосередньо за допомогою API TokenRequest або секрети токенів службових облікових записів можна створювати вручну. Докладніше: https://kubernetes.io/docs/concepts/configuration/secret

ServiceAccountList

ServiceAccountList — це список обʼєктів ServiceAccount.


Операції


get отримати вказаний ServiceAccount

HTTP запит

GET /api/v1/namespaces/{namespace}/serviceaccounts/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ServiceAccount

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (ServiceAccount): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу ServiceAccount

HTTP запит

GET /api/v1/namespaces/{namespace}/serviceaccounts

Параметри

Відповідь

200 (ServiceAccountList): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу ServiceAccount

HTTP запит

GET /api/v1/serviceaccounts

Параметри

Відповідь

200 (ServiceAccountList): OK

401: Unauthorized

create створення ServiceAccount

HTTP запит

POST /api/v1/namespaces/{namespace}/serviceaccounts

Параметри

Відповідь

200 (ServiceAccount): OK

201 (ServiceAccount): Created

202 (ServiceAccount): Accepted

401: Unauthorized

update заміна вказаного ServiceAccount

HTTP запит

PUT /api/v1/namespaces/{namespace}/serviceaccounts/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ServiceAccount

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: ServiceAccount, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (ServiceAccount): OK

201 (ServiceAccount): Created

401: Unauthorized

patch часткове оновлення вказаного ServiceAccount

HTTP запит

PATCH /api/v1/namespaces/{namespace}/serviceaccounts/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ServiceAccount

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (ServiceAccount): OK

201 (ServiceAccount): Created

401: Unauthorized

delete видалення ServiceAccount

HTTP запит

DELETE /api/v1/namespaces/{namespace}/serviceaccounts/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ServiceAccount

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (ServiceAccount): OK

202 (ServiceAccount): Accepted

401: Unauthorized

deletecollection видалення колекції ServiceAccount

HTTP запит

DELETE /api/v1/namespaces/{namespace}/serviceaccounts

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

6.5.4.2 - TokenRequest

TokenRequest запитує токен для вказаного службового облікового запису.

apiVersion: authentication.k8s.io/v1

import "k8s.io/api/authentication/v1"

TokenRequest

TokenRequest запитує токен для вказаного службового облікового запису.


TokenRequestSpec

TokenRequestSpec містить параметри запиту токена, надані клієнтом.


  • audiences ([]string), обовʼязково

    Atomic: буде замінено під час злиття

    Audiences — це цільові аудиторії токена. Отримувач токена повинен ідентифікувати себе за допомогою ідентифікатора зі списку аудиторій токена, інакше він повинен відхилити токен. Токен, виданий для кількох аудиторій, може бути використаний для автентифікації з будь-якою з вказаних аудиторій, що передбачає високий ступінь довіри між цільовими аудиторіями.

  • boundObjectRef (BoundObjectReference)

    BoundObjectRef — це посилання на обʼєкт, до якого буде привʼязано токен. Токен буде дійсний лише до тих пір, поки існує привʼязаний обʼєкт. ПРИМІТКА: Точка доступу TokenReview сервера API перевірить BoundObjectRef, але інші аудиторії можуть цього не робити. Тримайте ExpirationSeconds маленьким, якщо ви хочете швидке відкликання.

    BoundObjectReference — це посилання на обʼєкт, до якого привʼязано токен.

    • boundObjectRef.apiVersion (string)

      Версія API посилання.

    • boundObjectRef.kind (string)

      Тип посилання. Дійсними типами є 'Pod' та 'Secret'.

    • boundObjectRef.name (string)

      Імʼя посилання.

    • boundObjectRef.uid (string)

      UID посилання.

  • expirationSeconds (int64)

    ExpirationSeconds — це запитувана тривалість дії запиту. Видавець токенів може повернути токен з іншою тривалістю дії, тому клієнт повинен перевірити поле 'expiration' у відповіді.

TokenRequestStatus

TokenRequestStatus — це результат запиту на отримання токена.


  • expirationTimestamp (Time), обовʼязково

    ExpirationTimestamp — це час закінчення дії виданого токена.

    Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

  • token (string), обовʼязково

    Token — це непрозорий токен на предʼявника.

Операції


create створення токена ServiceAccount

HTTP запит

POST /api/v1/namespaces/{namespace}/serviceaccounts/{name}/token

Параметри

  • name (в шляху): string, обовʼязково

    name of the TokenRequest

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: TokenRequest, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповіді

200 (TokenRequest): OK

201 (TokenRequest): Created

202 (TokenRequest): Accepted

401: Unauthorized

6.5.4.3 - TokenReview

TokenReview намагається автентифікувати токен вже відомому користувачу.

apiVersion: authentication.k8s.io/v1

import "k8s.io/api/authentication/v1"

TokenReview

TokenReview намагається автентифікувати токен вже відомому користувачу. Примітка: запити TokenReview можуть кешуватися dnekrjv автентифікації вебхука в kube-apiserver.


TokenReviewSpec

TokenReviewSpec є описом запиту автентифікації токена.


  • audiences ([]string)

    Atomic: буде замінено під час злиття

    Audiences — це список ідентифікаторів, які сервер ресурсів, представлений токеном, розпізнає як. Автентифікатори токенів, що володіють інформацією про аудиторію, перевірять, що токен був призначений принаймні для однієї з аудиторій у цьому списку. Якщо аудиторії не надані, типово використовується аудиторія Kubernetes apiserver.

  • token (string)

    Token — це непрозорий токен на предʼявника.

TokenReviewStatus

TokenReviewStatus — це результат запиту автентифікації токена.


  • audiences ([]string)

    Atomic: буде замінено під час злиття

    Audiences — це ідентифікатори аудиторії, обрані автентифікатором, які сумісні як з TokenReview, так і з токеном. Ідентифікатор є будь-яким ідентифікатором у перетині аудиторій TokenReviewSpec та аудиторій токена. Клієнт TokenReview API, який встановлює поле spec.audiences, повинен перевірити, що сумісний ідентифікатор аудиторії повертається в полі status.audiences, щоб переконатися, що сервер TokenReview враховує аудиторію. Якщо TokenReview повертає порожнє поле status.audience, де status.authenticated є "true", токен дійсний для аудиторії Kubernetes API server.

  • authenticated (boolean)

    Authenticated вказує, що токен був повʼязаний з відомим користувачем.

  • error (string)

    Error вказує, що токен не вдалося перевірити

  • user (UserInfo)

    User — це UserInfo, повʼязаний із наданим токеном.

    UserInfo містить інформацію про користувача, необхідну для реалізації інтерфейсу user.Info.

    • user.extra (map[string][]string)

      Будь-яка додаткова інформація, надана автентифікатором.

    • user.groups ([]string)

      Atomic: буде замінено під час злиття

      Назви груп, до яких належить цей користувач.

    • user.uid (string)

      Унікальне значення, яке ідентифікує цього користувача з плином часу. Якщо цього користувача видаляють і додають іншого користувача з тим же імʼям, вони матимуть різні UID.

    • user.username (string)

      Імʼя, яке унікально ідентифікує цього користувача серед усіх активних користувачів.

Операції

create створення TokenReview

HTTP запит

POST /apis/authentication.k8s.io/v1/tokenreviews

Параметри запиту

Відповідь

200 (TokenReview): OK

201 (TokenReview): Created

202 (TokenReview): Accepted

401: Unauthorized

6.5.4.4 - CertificateSigningRequest

Обʼєкти CertificateSigningRequest надають механізм для отримання сертифікатів x509 шляхом подання запиту на підписання сертифіката та його асинхронного схвалення і видачі.

apiVersion: certificates.k8s.io/v1

import "k8s.io/api/certificates/v1"

CertificateSigningRequest

Обʼєкти CertificateSigningRequest надають механізм для отримання сертифікатів x509 шляхом подання запиту на підписання сертифіката та його асинхронного схвалення і видачі.

Kubelets використовують цей API для отримання:

  1. клієнтських сертифікатів для автентифікації до kube-apiserver (з використанням signerName "kubernetes.io/kube-apiserver-client-kubelet").
  2. серверних сертифікатів для TLS-точок доступу, до яких kube-apiserver може підключатися безпечно (з використанням signerName "kubernetes.io/kubelet-serving").

Цей API може бути використаний для запиту клієнтських сертифікатів для автентифікації до kube-apiserver (з використанням signerName "kubernetes.io/kube-apiserver-client") або для отримання сертифікатів від нестандартних підписувачів, що не належать до Kubernetes.


  • apiVersion: certificates.k8s.io/v1

  • kind: CertificateSigningRequest

  • metadata (ObjectMeta)

  • spec (CertificateSigningRequestSpec), обовʼязково

    spec містить запит на сертифікат і є незмінним після створення. Тільки поля request, signerName, expirationSeconds та usages можуть бути встановлені під час створення. Інші поля визначаються Kubernetes і не можуть бути змінені користувачами.

  • status (CertificateSigningRequestStatus)

    status містить інформацію про те, чи запит схвалено або відхилено, а також сертифікат, виданий підписувачем, або умови збою, які вказують на збій підписувача.

CertificateSigningRequestSpec

CertificateSigningRequestSpec містить запит на сертифікат.


  • request ([]byte), обовʼязково

    Atomic: буде замінено під час злиття

    request містить x509 запит на підписання сертифіката, закодований у блоці PEM "CERTIFICATE REQUEST". При серіалізації у форматі JSON або YAML дані додатково кодуються в base64.

  • signerName (string), обовʼязково

    signerName вказує на запитуваного підписувача і є кваліфікованим імʼям.

    Запити List/watch для CertificateSigningRequests можуть фільтруватися за цим полем з використанням fieldSelector "spec.signerName=NAME".

    Добре відомі підписувачі Kubernetes:

    1. "kubernetes.io/kube-apiserver-client": видає клієнтські сертифікати, які можна використовувати для автентифікації до kube-apiserver. Запити для цього підписувача ніколи не затверджуються автоматично kube-controller-manager, можуть бути видані контролером "csrsigning" у kube-controller-manager.
    2. "kubernetes.io/kube-apiserver-client-kubelet": видає клієнтські сертифікати, які kubelets використовують для автентифікації до kube-apiserver. Запити для цього підписувача можуть бути автоматично затверджені контролером "csrapproving" у kube-controller-manager і можуть бути видані контролером "csrsigning" у kube-controller-manager.
    3. "kubernetes.io/kubelet-serving": видає серверні сертифікати, які kubelets використовують для обслуговування TLS-точок доступу, до яких kube-apiserver може підключатися безпечно. Запити для цього підписувача ніколи не затверджуються автоматично kube-controller-manager і можуть бути видані контролером "csrsigning" у kube-controller-manager.

    Докладніше: https://k8s.io/docs/reference/access-authn-authz/certificate-signing-requests/#kubernetes-signers

    Можуть також бути вказані нестандартні signerNames. Підписувач визначає:

    1. Розповсюдження довіри: як розповсюджуються довірчі пакети (CA bundles).
    2. Дозволені субʼєкти: та поведінка, коли запитується недозволений субʼєкт.
    3. Обовʼязкові, дозволені або заборонені розширення x509 у запиті (включаючи те, чи дозволені subjectAltNames, які типи, обмеження на дозволені значення) та поведінка при запиті недозволеного розширення.
    4. Обовʼязкові, дозволені або заборонені ключові використання / розширені ключові використання.
    5. Термін дії сертифіката: чи він фіксований підписувачем, налаштовується адміністратором.
    6. Чи дозволені запити на сертифікати CA.
  • expirationSeconds (int32)

    expirationSeconds — це запитувана тривалість дії виданого сертифіката. Підписувач сертифіката може видати сертифікат з іншою тривалістю дії, тому клієнт повинен перевірити різницю між полями notBefore і notAfter у виданому сертифікаті, щоб визначити фактичну тривалість.

    Реалізації v1.22+ вбудованих підписувачів Kubernetes дотримуватимуться цього поля, якщо запитувана тривалість не перевищує максимальну тривалість, яку вони дозволяють відповідно до прапорця CLI --cluster-signing-duration для контролера Kubernetes.

    Підписувачі сертифікатів можуть не дотримуватися цього поля з різних причин:

    1. Старий підписувач, який не знає про це поле (наприклад, вбудовані реалізації до v1.22)
    2. Підписувач, чия налаштована максимальна тривалість коротша за запитувану тривалість
    3. Підписувач, чия налаштована мінімальна тривалість довша за запитувану тривалість

    Мінімальне дійсне значення для expirationSeconds — 600, тобто 10 хвилин.

  • extra (map[string][]string)

    extra містить додаткові атрибути користувача, який створив CertificateSigningRequest. Заповнюється API-сервером при створенні та є незмінним.

  • groups ([]string)

    Atomic: буде замінено під час злиття

    groups містить членство в групах користувача, який створив CertificateSigningRequest. Заповнюється API-сервером при створенні та є незмінним.

  • uid (string)

    uid містить uid користувача, який створив CertificateSigningRequest. Заповнюється API-сервером при створенні та є незмінним.

  • usages ([]string)

    Atomic: буде замінено під час злиття

    usages вказує набір запитуваних використань ключів у виданому сертифікаті.

    Запити на TLS клієнтські сертифікати зазвичай запитують: "digital signature", "key encipherment", "client auth".

    Запити на TLS серверні сертифікати зазвичай запитують: "key encipherment", "digital signature", "server auth".

    Дійсні значення: "signing", "digital signature", "content commitment", "key encipherment", "key agreement", "data encipherment", "cert sign", "crl sign", "encipher only", "decipher only", "any", "server auth", "client auth", "code signing", "email protection", "s/mime", "ipsec end system", "ipsec tunnel", "ipsec user", "timestamping", "ocsp signing", "microsoft sgc", "netscape sgc"

  • username (string)

    username містить імʼя користувача, який створив CertificateSigningRequest. Заповнюється API-сервером при створенні та є незмінним.

CertificateSigningRequestStatus

CertificateSigningRequestStatus містить умови, що використовуються для позначення статусу запиту (схвалено/відхилено/не вдалося), та виданий сертифікат.


  • certificate ([]byte)

    Atomic: буде замінено під час злиття

    certificate заповнюється виданим сертифікатом підписувача після наявності умови "Approved". Це поле встановлюється через субресурс /status. Після заповнення це поле є незмінним.

    Якщо запит на підписання сертифіката відхилено, додається умова типу "Denied", і це поле залишається порожнім. Якщо підписувач не може видати сертифікат, додається умова типу "Failed", і це поле залишається порожнім.

    Вимоги до валідації:

    1. certificate повинно містити один або більше PEM блоків.
    2. Усі PEM блоки повинні мати мітку "CERTIFICATE", не містити заголовків, а закодовані дані повинні бути структурою сертифіката BER-кодованого ASN.1, як описано в розділі 4 RFC5280.
    3. Не-PEM вміст може зʼявлятися до або після блоків PEM "CERTIFICATE" і не перевіряється, щоб дозволити пояснювальний текст, як описано в розділі 5.2 RFC7468.

    Якщо в наявності більше одного блоку PEM, і визначення запитуваного spec.signerName не вказує інше, перший блок є виданим сертифікатом, а наступні блоки слід розглядати як проміжні сертифікати та представлятись під час TLS-handshake.

    Сертифікат закодований у форматі PEM.

    При серіалізації у форматі JSON або YAML дані додатково кодуються в base64, тому вони складаються з:

    base64(
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----
    )
    
  • conditions ([]CertificateSigningRequestCondition)

    Map: унікальні значення за ключем типу зберігатимуться під час злиття

    conditions, застосовані до запиту. Відомі стани: "Approved", "Denied" та "Failed".

    CertificateSigningRequestCondition описує стан обʼєкта CertificateSigningRequest

    • conditions.status (string), обовʼязково

      статус стану, одне з True, False, Unknown. Стани "Approved", "Denied" та "Failed" не можуть бути "False" або "Unknown".

    • conditions.type (string), обовʼязково

      тип стану. Відомі стани: "Approved", "Denied" та "Failed".

      Стан "Approved" додається через субресурс /approval, що вказує на те, що запит було схвалено і сертифікат повинен бути виданий підписувачем.

      Стан "Denied" додається через субресурс /approval, що вказує на те, що запит було відхилено і сертифікат не повинен бути виданий підписувачем.

      Стан "Failed" додається через субресурс /status, що вказує на те, що підписувачу не вдалося видати сертифікат.

      Стан "Approved" та "Denied" є взаємозаперечними. Стани "Approved", "Denied" та "Failed" не можуть бути видалені після додавання.

      Дозволено лише один стан певного типу.

    • conditions.lastTransitionTime (Time)

      lastTransitionTime - це час останньої зміни стану з одного статусу до іншого. Якщо не встановлено, коли додається новий тип стану або змінюється статус поточного стану, сервер стандартно встановлює цей час на поточний.

      Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

    • conditions.lastUpdateTime (Time)

      lastUpdateTime — це час останнього оновлення цього стану.

      Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

    • conditions.message (string)

      message містить зрозуміле для людини повідомлення з деталями про стан запиту.

    • conditions.reason (string)

      reason вказує коротку причину стану запиту.

CertificateSigningRequestList

CertificateSigningRequestList — це колекція обʼєктів CertificateSigningRequest.


  • apiVersion: certificates.k8s.io/v1

  • kind: CertificateSigningRequestList

  • metadata (ListMeta)

  • items ([]CertificateSigningRequest), обовʼязково

    items — це колекція обʼєктів CertificateSigningRequest.

Операції

get отримати вказаний CertificateSigningRequest

HTTP запит

GET /apis/certificates.k8s.io/v1/certificatesigningrequests/{name}

Параметри

  • name (в шляху): string, обовʼязково

    name of the CertificateSigningRequest

  • pretty (в запиті): string

    pretty

Відповідь

200 (CertificateSigningRequest): OK

401: Unauthorized

get отримати схвалення вказаного CertificateSigningRequest

HTTP запит

GET /apis/certificates.k8s.io/v1/certificatesigningrequests/{name}/approval

Параметри

  • name (в шляху): string, обовʼязково

    name of the CertificateSigningRequest

  • pretty (в запиті): string

    pretty

Відповідь

200 (CertificateSigningRequest): OK

401: Unauthorized

get отримати статус вказаного CertificateSigningRequest

HTTP запит

GET /apis/certificates.k8s.io/v1/certificatesigningrequests/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    name of the CertificateSigningRequest

  • pretty (в запиті): string

    pretty

Відповідь

200 (CertificateSigningRequest): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу CertificateSigningRequest

HTTP запит

GET /apis/certificates.k8s.io/v1/certificatesigningrequests

Параметри

Відповідь

200 (CertificateSigningRequestList): OK

401: Unauthorized

create створення CertificateSigningRequest

HTTP запит

POST /apis/certificates.k8s.io/v1/certificatesigningrequests

Параметри

Відповідь

200 (CertificateSigningRequest): OK

201 (CertificateSigningRequest): Created

202 (CertificateSigningRequest): Accepted

401: Unauthorized

update заміна вказаного CertificateSigningRequest

HTTP запит

PUT /apis/certificates.k8s.io/v1/certificatesigningrequests/{name}

Параметри

  • name (в шляху): string, обовʼязково

    name of the CertificateSigningRequest

  • body: CertificateSigningRequest, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (CertificateSigningRequest): OK

201 (CertificateSigningRequest): Created

401: Unauthorized

update заміна підтвердження вказаного CertificateSigningRequest

HTTP запит

PUT /apis/certificates.k8s.io/v1/certificatesigningrequests/{name}/approval

Параметри

  • name (в шляху): string, обовʼязково

    name of the CertificateSigningRequest

  • body: CertificateSigningRequest, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (CertificateSigningRequest): OK

201 (CertificateSigningRequest): Created

401: Unauthorized

update заміна статусу вказаного CertificateSigningRequest

HTTP запит

PUT /apis/certificates.k8s.io/v1/certificatesigningrequests/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    name of the CertificateSigningRequest

  • body: CertificateSigningRequest, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (CertificateSigningRequest): OK

201 (CertificateSigningRequest): Created

401: Unauthorized

patch часткове оновлення вказаного CertificateSigningRequest

HTTP запит

PATCH /apis/certificates.k8s.io/v1/certificatesigningrequests/{name}

Параметри

  • name (в шляху): string, обовʼязково

    name of the CertificateSigningRequest

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (CertificateSigningRequest): OK

201 (CertificateSigningRequest): Created

401: Unauthorized

patch часткове оновлення затвердження вказаного CertificateSigningRequest

HTTP запит

PATCH /apis/certificates.k8s.io/v1/certificatesigningrequests/{name}/approval

Параметри

  • name (в шляху): string, обовʼязково

    name of the CertificateSigningRequest

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (CertificateSigningRequest): OK

201 (CertificateSigningRequest): Created

401: Unauthorized

patch часткове оновлення статусу вказаного CertificateSigningRequest

HTTP запит

PATCH /apis/certificates.k8s.io/v1/certificatesigningrequests/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    name of the CertificateSigningRequest

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (CertificateSigningRequest): OK

201 (CertificateSigningRequest): Created

401: Unauthorized

delete видалення CertificateSigningRequest

HTTP запит

DELETE /apis/certificates.k8s.io/v1/certificatesigningrequests/{name}

Параметри

  • name (в шляху): string, обовʼязково

    name of the CertificateSigningRequest

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції CertificateSigningRequest

HTTP запит

DELETE /apis/certificates.k8s.io/v1/certificatesigningrequests

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

6.5.4.5 - ClusterTrustBundle v1alpha1

ClusterTrustBundle — це кластерний контейнер для X.

apiVersion: certificates.k8s.io/v1alpha1

import "k8s.io/api/certificates/v1alpha1"

ClusterTrustBundle

ClusterTrustBundle — це кластерний контейнер для довірчих якорів X.509 (кореневих сертифікатів).

Обʼєкти ClusterTrustBundle вважаються доступними для читання будь-яким автентифікованим користувачем у кластері, оскільки їх можна монтувати в Pod за допомогою проєкції clusterTrustBundle. Усі службові облікові записи типово мають доступ на читання ClusterTrustBundles. Користувачі, які мають доступ лише на рівні простору імен у кластері, можуть читати ClusterTrustBundles, використовуючи serviceaccount, до якого вони мають доступ.

Він може бути опціонально повʼязаний з певним підписувачем, у такому випадку він містить один дійсний набір довірчих якорів для цього підписувача. Підписувачі можуть мати кілька повʼязаних ClusterTrustBundles; кожен з них є незалежним набором довірчих якорів для цього підписувача. Контроль доступу використовується для забезпечення того, що лише користувачі з правами підписувача можуть створювати або змінювати відповідний набір.


  • apiVersion: certificates.k8s.io/v1alpha1

  • kind: ClusterTrustBundle

  • metadata (ObjectMeta)

    metadata містить метадані обʼєкта.

  • spec (ClusterTrustBundleSpec), обовʼязково

    spec містить підписувача (якщо є) та довірчі якорі.

ClusterTrustBundleSpec

ClusterTrustBundleSpec містить інформацію про підписувача та довірчі якорі.


  • trustBundle (string), обовʼязково

    trustBundle містить окремі довірчі якорі X.509 для цього набору, у вигляді PEM-пакета PEM-обгорток, DER-форматованих сертифікатів X.509.

    Дані повинні складатися лише з PEM-блоків сертифікатів, які розпізнаються як дійсні сертифікати X.509. Кожен сертифікат повинен містити розширення базових обмежень з встановленою позначкою CA. Сервер API відхилить обʼєкти, що містять дублюючі сертифікати або використовують заголовки блоків PEM.

    Користувачі ClusterTrustBundle, включаючи Kubelet, вільні переупорядковувати та видаляти дублікати блоків сертифікатів у цьому файлі за власною логікою, а також видаляти заголовки блоків PEM та міжблокові дані.

  • signerName (string)

    signerName вказує повʼязаного підписувача, якщо такий є.

    Щоб створити або оновити ClusterTrustBundle з встановленим signerName, вам потрібно мати наступні дозволи на рівні кластера: group=certificates.k8s.io resource=signers resourceName=<імʼя підписувача> verb=attest.

    Якщо signerName не порожній, тоді обʼєкт ClusterTrustBundle повинен мати імʼя, що починається з імені підписувача як префікс (перекладаючи косі на двокрапки). Наприклад, для імені підписувача example.com/foo, допустимі імена обʼєктів ClusterTrustBundle включають example.com:foo:abc та example.com:foo:v1.

    Якщо signerName порожній, тоді імʼя обʼєкта ClusterTrustBundle не повинно мати такого префікса.

    Запити на список/перегляд ClusterTrustBundle можуть фільтрувати за цим полем, використовуючи селектор поля spec.signerName=NAME.

ClusterTrustBundleList

ClusterTrustBundleList — це колекція обʼєктів ClusterTrustBundle.


  • apiVersion: certificates.k8s.io/v1alpha1

  • kind: ClusterTrustBundleList

  • metadata (ListMeta)

    metadata містить метадані списку.

  • items ([]ClusterTrustBundle), обовʼязково

    items — це колекція обʼєктів ClusterTrustBundle.

Операції


get отримати вказаний ClusterTrustBundle

HTTP запит

GET /apis/certificates.k8s.io/v1alpha1/clustertrustbundles/{name}

Параметри

  • name (в шляху): string, обовʼязково

    name of the ClusterTrustBundle

  • pretty (в запиті): string

    pretty

Відповідь

200 (ClusterTrustBundle): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу ClusterTrustBundle

HTTP запит

GET /apis/certificates.k8s.io/v1alpha1/clustertrustbundles

Параметри

Відповідь

200 (ClusterTrustBundleList): OK

401: Unauthorized

create створення ClusterTrustBundle

HTTP запит

POST /apis/certificates.k8s.io/v1alpha1/clustertrustbundles

Параметри

Відповідь

200 (ClusterTrustBundle): OK

201 (ClusterTrustBundle): Created

202 (ClusterTrustBundle): Accepted

401: Unauthorized

update заміна вказаного ClusterTrustBundle

HTTP запит

PUT /apis/certificates.k8s.io/v1alpha1/clustertrustbundles/{name}

Параметри

  • name (в шляху): string, обовʼязково

    name of the ClusterTrustBundle

  • body: ClusterTrustBundle, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (ClusterTrustBundle): OK

201 (ClusterTrustBundle): Created

401: Unauthorized

patch часткове оновлення вказаного ClusterTrustBundle

HTTP запит

PATCH /apis/certificates.k8s.io/v1alpha1/clustertrustbundles/{name}

Параметри

  • name (в шляху): string, обовʼязково

    name of the ClusterTrustBundle

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (ClusterTrustBundle): OK

201 (ClusterTrustBundle): Created

401: Unauthorized

delete видалення ClusterTrustBundle

HTTP запит

DELETE /apis/certificates.k8s.io/v1alpha1/clustertrustbundles/{name}

Параметри

  • name (в шляху): string, обовʼязково

    name of the ClusterTrustBundle

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції ClusterTrustBundle

HTTP запит

DELETE /apis/certificates.k8s.io/v1alpha1/clustertrustbundles

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

6.5.4.6 - SelfSubjectReview

SelfSubjectReview містить інформацію про користувача, яку має kube-apiserver про користувача, що робить цей запит.

apiVersion: authentication.k8s.io/v1

import "k8s.io/api/authentication/v1"

SelfSubjectReview

SelfSubjectReview містить інформацію про користувача, яку має kube-apiserver про користувача, що робить цей запит. При використанні імперсоніфікації, користувачі отримають інформацію про користувача, якого вони імітують. Якщо використовується імперсоніфікація або автентифікація заголовка запиту, будь-які додаткові ключі будуть ігноруватися і повертатися у нижньому регістрі.


SelfSubjectReviewStatus

SelfSubjectReviewStatus заповнюється kube-apiserver і відсилається користувачу.


  • userInfo (UserInfo)

    Атрибути користувача, який робить цей запит.

    UserInfo містить інформацію про користувача, необхідну для реалізації інтерфейсу user.Info.

    • userInfo.extra (map[string][]string)

      Будь-яка додаткова інформація, надана автентифікатором.

    • userInfo.groups ([]string)

      Atomic: буде замінено під час злиття

      Назви груп, до яких належить цей користувач.

    • userInfo.uid (string)

      Унікальне значення, що ідентифікує цього користувача з плином часу. Якщо цей користувач буде видалений і інший користувач з таким самим іменем буде доданий, вони матимуть різні UID.

    • userInfo.username (string)

      Імʼя, яке унікально ідентифікує цього користувача серед усіх активних користувачів.

Операції


create створення SelfSubjectReview

HTTP запит

POST /apis/authentication.k8s.io/v1/selfsubjectreviews

Параметри

Відповідь

200 (SelfSubjectReview): OK

201 (SelfSubjectReview): Created

202 (SelfSubjectReview): Accepted

401: Unauthorized

6.5.5 - Ресурси авторизації

6.5.5.1 - LocalSubjectAccessReview

LocalSubjectAccessReview перевіряє, чи може користувач або група виконати дію в заданому просторі імен.

apiVersion: authorization.k8s.io/v1

import "k8s.io/api/authorization/v1"

LocalSubjectAccessReview

LocalSubjectAccessReview перевіряє, чи може користувач або група виконати дію в заданому просторі імен. Наявність ресурсу, обмеженого простором імен, значно полегшує надання політики, обмеженої простором імен, що включає перевірку дозволів.


  • apiVersion: authorization.k8s.io/v1

  • kind: LocalSubjectAccessReview

  • metadata (ObjectMeta)

    Стандартні метадані списку. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

  • spec (SubjectAccessReviewSpec), обовʼязково

    Специфікація містить інформацію про запит, який оцінюється. spec.namespace повинен дорівнювати простору імен, щодо якого зроблено запит. Якщо поле порожнє, встановлюється стандартне значення.

  • status (SubjectAccessReviewStatus)

    Статус заповнюється сервером і вказує, чи дозволено запит, чи ні.

Операції


create створення LocalSubjectAccessReview

HTTP запит

POST /apis/authorization.k8s.io/v1/namespaces/{namespace}/localsubjectaccessreviews

Параметри

Відповідь

200 (LocalSubjectAccessReview): OK

201 (LocalSubjectAccessReview): Created

202 (LocalSubjectAccessReview): Accepted

401: Unauthorized

6.5.5.2 - SelfSubjectAccessReview

SelfSubjectAccessReview перевіряє, чи може поточний користувач виконати дію.

apiVersion: authorization.k8s.io/v1

import "k8s.io/api/authorization/v1"

SelfSubjectAccessReview

SelfSubjectAccessReview перевіряє, чи може поточний користувач виконати дію. Незаповнення spec.namespace означає "в усіх просторах імен". Self є особливим випадком, оскільки користувачі завжди повинні мати змогу перевірити, чи можуть вони виконати дію.


SelfSubjectAccessReviewSpec

SelfSubjectAccessReviewSpec є описом запиту на доступ. Має бути встановлене щось одне з ResourceAuthorizationAttributes або NonResourceAuthorizationAttributes.


  • nonResourceAttributes (NonResourceAttributes)

    NonResourceAttributes описує інформацію для запиту на доступ до не-ресурсів.

    NonResourceAttributes включає атрибути авторизації, доступні для запитів до інтерфейсу Authorizer, які не стосуються ресурсів.

    • nonResourceAttributes.path (string)

      Path — це URL-шлях запиту.

    • nonResourceAttributes.verb (string)

      Verb — це стандартне HTTP-дієслово.

  • resourceAttributes (ResourceAttributes)

    ResourceAuthorizationAttributes описує інформацію для запиту на доступ до ресурсу.

    ResourceAttributes включає атрибути авторизації, доступні для запитів до інтерфейсу Authorizer, що стосуються ресурсів.

    • resourceAttributes.fieldSelector (FieldSelectorAttributes)

      fieldSelector описує обмеження доступу на основі поля. Він може лише обмежувати доступ, але не розширювати його.

      Це поле є на рівні альфа. Щоб використовувати це поле, ви повинні ввімкнути функціональну можливість AuthorizeWithSelectors (стандартно вимкнено).

      FieldSelectorAttributes вказує на доступ, обмежений за полем. Автори вебхуків заохочуються до таких дій:

      • переконатися, що rawSelector і requirements не встановлені одночасно;
      • розглядати поле requirements, якщо воно встановлене;
      • не намагатися парсити або враховувати поле rawSelector, якщо воно встановлене. Це робиться для запобігання ще одній уразливості типу CVE-2022-2880 (тобто домогтися, щоб різні системи погодилися щодо того, як саме парсити запит, — це не те, чого ми прагнемо), більше деталей дивіться за посиланням https://www.oxeye.io/resources/golang-parameter-smuggling-attack.

      Для точок доступу SubjectAccessReview kube-apiserver:

      • Якщо rawSelector порожній, а requirements порожні, запит не обмежується.

      • Якщо rawSelector присутній, а requirements порожні, rawSelector буде парситися та обмежуватися, якщо парсинг вдасться.

      • Якщо rawSelector порожній, а requirements присутні, слід враховувати вимоги.

      • Якщо rawSelector присутній і requirements присутні, запит є недійсним.

      • resourceAttributes.fieldSelector.rawSelector (string)

        rawSelector — це серіалізація селектора поля, який буде включено в параметр запиту. Реалізаціям вебхуків рекомендується ігнорувати rawSelector. SubjectAccessReview у kube-apiserver буде парсити rawSelector, якщо поле requirements відсутнє.

      • resourceAttributes.fieldSelector.requirements ([]FieldSelectorRequirement)

        Atomic: буде замінено під час злиття

        requirements — це інтерпретація селектора поля після парсингу. Усі вимоги повинні бути виконані, щоб ресурс відповідав селектору. Реалізації вебхуків повинні обробляти requirements, але як саме їх обробляти — залишається на розсуд вебхука. Оскільки requirements можуть лише обмежувати запит, безпечно авторизувати запит як необмежений, якщо вимоги не зрозумілі.

        FieldSelectorRequirement — це селектор, який містить значення, ключ та оператор, який повʼязує ключ та значення.

        • resourceAttributes.fieldSelector.requirements.key (string), обовʼязково

          key — це ключ-селектор поля, до якого застосовується вимога.

        • resourceAttributes.fieldSelector.requirements.operator (string), обовʼязково

          operator представляє стосунок ключа до набору значень. Дійсні оператори: In, NotIn, Exists, DoesNotExist. Список операторів може розширюватися в майбутньому.

        • resourceAttributes.fieldSelector.requirements.values ([]string)

          Atomic: буде замінено під час злиття

          values — це масив строкових значень. Якщо оператор — In або NotIn, масив values не може бути порожнім. Якщо ж оператор — Exists або DoesNotExist, масив values повинен бути порожнім.

    • resourceAttributes.group (string)

      Group — це API-група ресурсу. "*" означає всі.

    • resourceAttributes.labelSelector (LabelSelectorAttributes)

      labelSelector описує обмеження доступу на основі міток. Він може лише обмежувати доступ, але не розширювати його.

      Це поле є на рівні альфа. Щоб використовувати це поле, потрібно ввімкнути функціональну можливість AuthorizeWithSelectors (стандартно вимкнено).

      LabelSelectorAttributes вказує на доступ, обмежений за мітками. Автори вебхуків заохочуються до таких дій:

      • переконатися, що rawSelector і requirements не встановлені одночасно;
      • розглядати поле requirements, якщо воно встановлене;
      • не намагатися парсити або враховувати поле rawSelector, якщо воно встановлене. Це робиться для запобігання ще одній уразливості типу CVE-2022-2880 (тобто домогтися, щоб різні системи погодилися щодо того, як саме парсити запит, — це не те, чого ми прагнемо), більше деталей дивіться за посиланням https://www.oxeye.io/resources/golang-parameter-smuggling-attack.

      Для точок доступу SubjectAccessReview kube-apiserver:

      • Якщо rawSelector порожній, а requirements порожні, запит не обмежується.

      • Якщо rawSelector присутній, а requirements порожні, rawSelector буде парситися та обмежуватися, якщо парсинг вдасться.

      • Якщо rawSelector порожній, а requirements присутні, слід враховувати вимоги.

      • Якщо rawSelector присутній і requirements присутні, запит є недійсним.

      • resourceAttributes.labelSelector.rawSelector (string)

        rawSelector — це серіалізація селектора поля, яка буде включена в параметр запиту. Реалізаціям вебхуків рекомендується ігнорувати rawSelector. SubjectAccessReview у kube-apiserver буде парсити rawSelector, якщо поле requirements відсутнє.

      • resourceAttributes.labelSelector.requirements ([]LabelSelectorRequirement)

        Atomic: буде замінено під час злиття

        requirements — це інтерпретація селектора мітки після парсингу. Усі вимоги повинні бути виконані, щоб ресурс відповідав селектору. Реалізації вебхуків повинні обробляти requirements, але спосіб обробки залишається на розсуд вебхука. Оскільки requirements можуть лише обмежувати запит, безпечно авторизувати запит як необмежений, якщо вимоги не зрозумілі.

        Вимога до селектора мітки — це селектор, який містить значення, ключ і оператор, який повʼязує ключ і значення.

        • resourceAttributes.labelSelector.requirements.key (string), обовʼязково

          key — це ключ мітки, до якого застосовується селектор.

        • resourceAttributes.labelSelector.requirements.operator (string), обовʼязково

          operator представляє стосунок ключа до набору значень. Дійсні оператори: In, NotIn, Exists та DoesNotExist.

        • resourceAttributes.labelSelector.requirements.values ([]string)

          Atomic: буде замінено під час злиття

          values — це масив строкових значень. Якщо оператор — In або NotIn, масив values не може бути порожнім. Якщо ж оператор — Exists або DoesNotExist, масив values повинен бути порожнім. Цей масив замінюється під час стратегічного злиття патчу.

    • resourceAttributes.name (string)

      Name — це назва ресурсу, який запитується для "отримання" ("get") або видалення для "delete". "" (порожня) означає всі.

    • resourceAttributes.namespace (string)

      Namespace — це простір імен дії, що запитується. Наразі немає різниці між відсутністю простору імен та всіма просторами імен "" (порожньо) стандартно встановлюється з для LocalSubjectAccessReviews "" (порожньо) означає відсутність для кластерних ресурсів "" (порожньо) означає "всі" для ресурсів, обмежених простором імен, з SubjectAccessReview або SelfSubjectAccessReview.

    • resourceAttributes.resource (string)

      Resource — це один з наявних типів ресурсів. "*" означає всі.

    • resourceAttributes.subresource (string)

      Subresource — це один з наявних типів субресурсів. "" означає відсутність.

    • resourceAttributes.verb (string)

      Verb — це дієслово API ресурсу Kubernetes, таке як: get, list, watch, create, update, delete, proxy. "*" означає всі.

    • resourceAttributes.version (string)

      Version — це версія API ресурсу. "*" означає всі.

Операції


create створення SelfSubjectAccessReview

HTTP запит

POST /apis/authorization.k8s.io/v1/selfsubjectaccessreviews

Параметри

Відповідь

200 (SelfSubjectAccessReview): OK

201 (SelfSubjectAccessReview): Created

202 (SelfSubjectAccessReview): Accepted

401: Unauthorized

6.5.5.3 - SelfSubjectRulesReview

SelfSubjectRulesReview перелічує набір дій, які поточний користувач може виконувати в межах простору імен.

apiVersion: authorization.k8s.io/v1

import "k8s.io/api/authorization/v1"

SelfSubjectRulesReview

SelfSubjectRulesReview перелічує набір дій, які поточний користувач може виконувати в межах простору імен. Отриманий список дій може бути неповним залежно від режиму авторизації сервера та будь-яких помилок, які виникли під час оцінки. SelfSubjectRulesReview слід використовувати інтерфейсами користувача для показу/приховування дій або швидкого надання кінцевому користувачеві можливості оцінити свої дозволи. Він НЕ ПОВИНЕН використовуватися зовнішніми системами для прийняття рішень щодо авторизації, оскільки це викликає проблеми з підміною, тривалістю життя кешу/відкликанням та правильністю. SubjectAccessReview і LocalAccessReview є правильним способом делегування рішень щодо авторизації до API сервера.


  • apiVersion: authorization.k8s.io/v1

  • kind: SelfSubjectRulesReview

  • metadata (ObjectMeta)

    Стандартні метадані списку. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

  • spec (SelfSubjectRulesReviewSpec), обовʼязково

    Специфікація містить інформацію про запит, який оцінюється.

  • status (SubjectRulesReviewStatus)

    Статус заповнюється сервером і вказує на набір дій, які користувач може виконувати.

    SubjectRulesReviewStatus містить результат перевірки правил. Ця перевірка може бути неповною залежно від набору авторизаторів, з якими налаштовано сервер, і будь-яких помилок, що виникли під час оцінки. Оскільки правила авторизації є адитивними, якщо правило зʼявляється у списку, можна безпечно припустити, що субʼєкт має цей дозвіл, навіть якщо цей список неповний.

    • status.incomplete (boolean), обовʼязково

      Incomplete встановлюється у true, коли правила, повернуті цим викликом, є неповними. Це найчастіше зустрічається, коли авторизатор, такий як зовнішній авторизатор, не підтримує оцінку правил.

    • status.nonResourceRules ([]NonResourceRule), обовʼязково

      Atomic: буде замінено під час злиття

      NonResourceRules — це список дій, які субʼєкт має право виконувати щодо не-ресурсів. Порядок у списку не є значущим, може містити дублікати та, можливо, бути неповним.

      NonResourceRule містить інформацію, яка описує правило для не-ресурсу

      • status.nonResourceRules.verbs ([]string), обовʼязково

        Atomic: буде замінено під час злиття

        Verb — це список дієслів API Kubernetes для не-ресурсів, таких як: get, post, put, delete, patch, head, options. "*" означає всі.

      • status.nonResourceRules.nonResourceURLs ([]string)

        Atomic: буде замінено під час злиття

        NonResourceURLs — це набір часткових URL-адрес, до яких користувач повинен мати доступ. * допускаються, але лише як повний, кінцевий крок у шляху. "*" означає всі.

    • status.resourceRules ([]ResourceRule), обовʼязково

      Atomic: буде замінено під час злиття

      ResourceRules — це список дій, які субʼєкт має право виконувати щодо ресурсів. Порядок у списку не є значущим, може містити дублікати та, можливо, бути неповним.

      ResourceRule — це список дій, які субʼєкт має право виконувати щодо ресурсів. Порядок у списку не є значущим, може містити дублікати та, можливо, бути неповним.

      • status.resourceRules.verbs ([]string), обовʼязково

        Atomic: буде замінено під час злиття

        Verb — це список дієслів API ресурсу Kubernetes, таких як: get, list, watch, create, update, delete, proxy. "*" означає всі.

      • status.resourceRules.apiGroups ([]string)

        Atomic: буде замінено під час злиття

        APIGroups — це назва API-групи, яка містить ресурси. Якщо зазначено кілька API-груп, будь-яка дія, запитана для одного з перелічених ресурсів у будь-якій API-групі, буде дозволена. "*" означає всі.

      • status.resourceRules.resourceNames ([]string)

        Atomic: буде замінено під час злиття

        ResourceNames — це необовʼязковий білий список імен, до яких застосовується правило. Порожній набір означає, що дозволено все. "*" означає всі.

      • status.resourceRules.resources ([]string)

        Atomic: буде замінено під час злиття

        Resources — це список ресурсів, до яких застосовується це правило. "*" означає всі в зазначених apiGroups. "*/foo" представляє субресурс 'foo' для всіх ресурсів у зазначених apiGroups.

    • status.evaluationError (string)

      EvaluationError може зʼявитися разом із Rules. Це вказує на те, що під час оцінки правил сталася помилка, наприклад, авторизатор не підтримує оцінку правил, і що ResourceRules та/або NonResourceRules можуть бути неповними.

SelfSubjectRulesReviewSpec

SelfSubjectRulesReviewSpec визначає специфікацію для SelfSubjectRulesReview.


  • namespace (string)

    Простір імен для оцінки правил. Обовʼязково.

Операції


create створення SelfSubjectRulesReview

HTTP запит

POST /apis/authorization.k8s.io/v1/selfsubjectrulesreviews

Параметри

Відповідь

200 (SelfSubjectRulesReview): OK

201 (SelfSubjectRulesReview): Created

202 (SelfSubjectRulesReview): Accepted

401: Unauthorized

6.5.5.4 - SubjectAccessReview

SubjectAccessReview перевіряє, чи може користувач або група виконати дію.

apiVersion: authorization.k8s.io/v1

import "k8s.io/api/authorization/v1"

SubjectAccessReview

SubjectAccessReview перевіряє, чи може користувач або група виконати дію.


SubjectAccessReviewSpec

SubjectAccessReviewSpec — це опис запиту на доступ. Має бути встановлено одне з ResourceAuthorizationAttributes або NonResourceAuthorizationAttributes


  • extra (map[string][]string)

    Extra відповідає методу user.Info.GetExtra() з автентифікатора. Оскільки це вхідні дані для авторизатора, це потребує відображення тут.

  • groups ([]string)

    Atomic: буде замінено під час злиття

    Groups — це групи, для яких ви проводите тестування.

  • nonResourceAttributes (NonResourceAttributes)

    NonResourceAttributes описує інформацію для запиту на доступ до не-ресурсів

    NonResourceAttributes включає атрибути авторизації, доступні для запитів на не-ресурси до інтерфейсу Authorizer

    • nonResourceAttributes.path (string)

      Path — це URL шлях запиту

    • nonResourceAttributes.verb (string)

      Verb — це стандартне HTTP дієслово

  • resourceAttributes (ResourceAttributes)

    ResourceAuthorizationAttributes описує інформацію для запиту на доступ до ресурсу

    ResourceAttributes включає атрибути авторизації, доступні для запитів на ресурси до інтерфейсу Authorizer

    • resourceAttributes.fieldSelector (FieldSelectorAttributes)

      fieldSelector описує обмеження доступу на основі поля. Він може лише обмежувати доступ, але не розширювати його.

      Це поле є на рівні альфа. Щоб використовувати це поле, потрібно ввімкнути функціональну можливість AuthorizeWithSelectors (стандартно вимкнено).

      FieldSelectorAttributes вказує на доступ, обмежений за полем. Автори вебхуків заохочуються до таких дій:

      • переконатися, що rawSelector і requirements не встановлені одночасно;
      • розглядати поле requirements, якщо воно встановлене;
      • не намагатися парсити або враховувати поле rawSelector, якщо воно встановлене. Це робиться для запобігання ще одній уразливості типу CVE-2022-2880 (тобто домогтися, щоб різні системи погодилися щодо того, як саме парсити запит, — це не те, чого ми прагнемо), більше деталей дивіться за посиланням https://www.oxeye.io/resources/golang-parameter-smuggling-attack.

      Для точок доступу SubjectAccessReview kube-apiserver:

      • Якщо rawSelector порожній, а requirements порожні, запит не обмежується.

      • Якщо rawSelector присутній, а requirements порожні, rawSelector буде парситися та обмежуватися, якщо парсинг вдасться.

      • Якщо rawSelector порожній, а requirements присутні, слід враховувати вимоги.

      • Якщо rawSelector присутній і requirements присутні, запит є недійсним.

      • resourceAttributes.fieldSelector.rawSelector (string)

        rawSelector — це серіалізація селектора поля, яка буде включена в параметр запиту. Реалізаціям вебхуків рекомендується ігнорувати rawSelector. SubjectAccessReview у kube-apiserver буде парсити rawSelector, якщо поле requirements відсутнє.

      • resourceAttributes.fieldSelector.requirements ([]FieldSelectorRequirement)

        Atomic: буде замінено під час злиття

        requirements — це інтерпретація селектора поля після парсингу. Усі вимоги повинні бути виконані, щоб ресурс відповідав селектору. Реалізації вебхуків повинні обробляти requirements, але спосіб їх обробки залишається на розсуд вебхука. Оскільки requirements можуть лише обмежувати запит, безпечно авторизувати запит як необмежений, якщо вимоги не зрозумілі.

        FieldSelectorRequirement — це селектор, який містить значення, ключ та оператор, який повʼязує ключ та значення.

        • resourceAttributes.fieldSelector.requirements.key (string), обовʼязково

          key — це ключ селектора поля, до якого застосовується вимога.

        • resourceAttributes.fieldSelector.requirements.operator (string), обовʼязково

          operator представляє звʼязок ключа до набору значень. Дійсні оператори: In, NotIn, Exists та DoesNotExist. Список операторів може розширюватися в майбутньому.

        • resourceAttributes.fieldSelector.requirements.values ([]string)

          Atomic: буде замінено під час злиття

          values — це набір значень, які відповідають ключу. Якщо оператор In або NotIn, це масив значень, які відповідають ключу. Якщо оператор Exists або DoesNotExist, це порожній масив.

    • resourceAttributes.group (string)

      Group — це API група ресурсу. "*" означає всі.

    • resourceAttributes.labelSelector (LabelSelectorAttributes)

      labelSelector описує обмеження доступу на основі міток. Він може лише обмежувати доступ, але не розширювати його.

      Це поле є на рівні альфа. Щоб використовувати це поле, потрібно ввімкнути функціональну можливість AuthorizeWithSelectors (стандартно вимкнено).

      LabelSelectorAttributes вказує на доступ, обмежений за мітками. Автори вебхуків заохочуються до таких дій:

      • переконатися, що rawSelector і requirements не встановлені одночасно;
      • розглядати поле requirements, якщо воно встановлене;
      • не намагатися парсити або враховувати поле rawSelector, якщо воно встановлене. Це робиться для запобігання ще одній уразливості типу CVE-2022-2880 (тобто домогтися, щоб різні системи погодилися щодо того, як саме парсити запит, — це не те, чого ми прагнемо), більше деталей дивіться за посиланням https://www.oxeye.io/resources/golang-parameter-smuggling-attack.

      Для точок доступу SubjectAccessReview kube-apiserver:

      • Якщо rawSelector порожній, а requirements порожні, запит не обмежується.

      • Якщо rawSelector присутній, а requirements порожні, rawSelector буде парситися та обмежуватися, якщо парсинг вдасться.

      • Якщо rawSelector порожній, а requirements присутні, слід враховувати вимоги.

      • Якщо rawSelector присутній і requirements присутні, запит є недійсним.

      • resourceAttributes.labelSelector.rawSelector (string)

        rawSelector — це серіалізація селектора поля, яка буде включена в параметр запиту. Реалізаціям вебхуків рекомендується ігнорувати rawSelector. SubjectAccessReview у kube-apiserver буде парсити rawSelector, якщо поле requirements відсутнє.

      • resourceAttributes.labelSelector.requirements ([]LabelSelectorRequirement)

        Atomic: буде замінено під час злиття

        requirements — це інтерпретація селектора мітки після парсингу. Усі вимоги повинні бути виконані, щоб ресурс відповідав селектору. Реалізації вебхуків повинні обробляти requirements, але спосіб обробки залишається на розсуд вебхука. Оскільки requirements можуть лише обмежувати запит, безпечно авторизувати запит як необмежений, якщо вимоги не зрозумілі.

        Вимога до селектора мітки — це селектор, який містить значення, ключ і оператор, який повʼязує ключ і значення.

        • resourceAttributes.labelSelector.requirements.key (string), обовʼязково

          key — це ключ мітки, до якого застосовується селектор.

        • resourceAttributes.labelSelector.requirements.operator (string), обовʼязково

          operator представляє стосунок ключа до набору значень. Дійсні оператори: In, NotIn, Exists та DoesNotExist.

        • resourceAttributes.labelSelector.requirements.values ([]string)

          Atomic: буде замінено під час злиття

          values — це масив строкових значень. Якщо оператор — In або NotIn, масив values не може бути порожнім. Якщо ж оператор — Exists або DoesNotExist, масив values повинен бути порожнім. Цей масив замінюється під час стратегічного злиття патчу.

    • resourceAttributes.name (string)

      Name — це імʼя ресурсу, який запитується для "отримання" ("get") або видаляється для "видалення" ("delete"). "" (порожньо) означає всі.

    • resourceAttributes.namespace (string)

      Namespace — це простір імен дії, яка запитується. Зараз немає різниці між відсутністю простору імен та всіма просторами імен "" (порожньо) змінюється на стандартне значення для LocalSubjectAccessReviews, "" (порожньо) є порожнім для кластерних ресурсів, "" (порожньо) означає "всі" для ресурсів з простором імен у SubjectAccessReview або SelfSubjectAccessReview

    • resourceAttributes.resource (string)

      Resource — це один з наявних типів ресурсів. "*" означає всі.

    • resourceAttributes.subresource (string)

      Subresource - це один з наявних типів субресурсів. "" означає жоден.

    • resourceAttributes.verb (string)

      Verb — це дієслово API ресурсу Kubernetes, таке як: get, list, watch, create, update, delete, proxy. "*" означає всі.

    • resourceAttributes.version (string)

      Version — це версія API ресурсу. "*" означає всі.

  • uid (string)

    UID — інформація про користувача, який робить запит.

  • user (string)

    User — це користувач, для якого проводиться тестування. Якщо ви вказуєте "User", але не "Groups", то це інтерпретується як "Що, якщо User не є членом жодної групи?"

SubjectAccessReviewStatus

SubjectAccessReviewStatus


  • allowed (boolean), обовʼязково

    Allowed є обовʼязковим. True, якщо дія буде дозволена, false в іншому випадку.

  • denied (boolean)

    Denied є необовʼязковим. True, якщо дія буде заборонена, в іншому випадку false. Якщо як allowed є false, так і denied є false, тоді авторизатор не має думки щодо дозволу дії. Denied не може бути true, якщо Allowed є true.

  • evaluationError (string)

    EvaluationError — це вказівка на те, що під час перевірки авторизації сталася якась помилка. Цілком можливо отримати помилку і мати можливість продовжити визначення статусу авторизації, не зважаючи на це. Наприклад, RBAC може не мати ролі, але достатньо ролей все ще присутні та привʼязані для розгляду запиту.

  • reason (string)

    Reason є необовʼязковим. Він вказує, чому запит був дозволений або відхилений.

Операції


create створення SubjectAccessReview

HTTP запит

POST /apis/authorization.k8s.io/v1/subjectaccessreviews

Параметри

Відповідь

200 (SubjectAccessReview): OK

201 (SubjectAccessReview): Created

202 (SubjectAccessReview): Accepted

401: Unauthorized

6.5.5.5 - ClusterRole

ClusterRole — це логічне групування PolicyRules на рівні кластера, на яке можна посилатися як на єдине ціле за допомогою привʼязки RoleBinding або ClusterRoleBinding.

apiVersion: rbac.authorization.k8s.io/v1

import "k8s.io/api/rbac/v1"

ClusterRole

ClusterRole — це логічне групування PolicyRules на рівні кластера, на яке можна посилатися як на єдине ціле за допомогою привʼязки RoleBinding або ClusterRoleBinding.


  • apiVersion: rbac.authorization.k8s.io/v1

  • kind: ClusterRole

  • metadata (ObjectMeta)

    Стандартні метадані обʼєкта.

  • aggregationRule (AggregationRule)

    AggregationRule — це необовʼязкове поле, яке описує, як створити правила для цього ClusterRole. Якщо AggregationRule встановлено, то правила управляються контролером і прямі зміни до правил будуть перезаписані контролером.

    AggregationRule описує, як знайти ClusterRoles для обʼєднання у ClusterRole

    • aggregationRule.clusterRoleSelectors ([]LabelSelector)

      Atomic: буде замінено під час злиття

      ClusterRoleSelectors містить список селекторів, які будуть використані для пошуку ClusterRoles та створення правил. Якщо будь-який з селекторів збігається, тоді дозволи ClusterRole будуть додані.

  • rules ([]PolicyRule)

    Atomic: буде замінено під час злиття

    Rules містить всі PolicyRules для цього ClusterRole.

    PolicyRule містить інформацію, яка описує правило політики, але не містить інформації про те, до кого застосовується правило або до якого простору імен воно відноситься.

    • rules.apiGroups ([]string)

      Atomic: буде замінено під час злиття

      APIGroups — це назва APIGroup, яка містить ресурси. Якщо вказано декілька API груп, будь-яка дія, запитана для одного з перерахованих ресурсів у будь-якій API групі, буде дозволена. "" представляє основну API групу, а "*" представляє всі API групи.

    • rules.resources ([]string)

      Atomic: буде замінено під час злиття

      Resources — це список ресурсів, до яких застосовується це правило. '*' представляє всі ресурси.

    • rules.verbs ([]string), обовʼязкове

      Atomic: буде замінено під час злиття

      Verbs — це список дієслів, які застосовуються до ВСІХ ResourceKinds, що містяться у цьому правилі. '*' представляє всі дієслова.

    • rules.resourceNames ([]string)

      Atomic: буде замінено під час злиття

      ResourceNames — це необовʼязковий білий список імен, до яких застосовується правило. Порожній набір означає, що дозволено все.

    • rules.nonResourceURLs ([]string)

      Atomic: буде замінено під час злиття

      NonResourceURLs — це набір часткових URL-адрес, до яких користувач повинен мати доступ. '*' дозволені, але тільки як повний, кінцевий крок у шляху. Оскільки не ресурсні URL-адреси не належать до простору імен, це поле застосовується тільки для ClusterRoles, на які посилається ClusterRoleBinding. Правила можуть застосовуватися або до API ресурсів (таких як "pods" або "secrets"), або до не ресурсних URL-шляхів (таких як "/api"), але не до обох одночасно.

ClusterRoleList

ClusterRoleList — це колекція ClusterRoles.


  • apiVersion: rbac.authorization.k8s.io/v1

  • kind: ClusterRoleList

  • metadata (ListMeta)

    Стандартні метадані обʼєкта.

  • items ([]ClusterRole), обовʼязково

    Items — це список ClusterRoles.

Операції


get отримати вказану ClusterRole

HTTP запит

GET /apis/rbac.authorization.k8s.io/v1/clusterroles/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ClusterRole

  • pretty (в запиті): string

    pretty

Відповідь

200 (ClusterRole): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу ClusterRole

HTTP запит

GET /apis/rbac.authorization.k8s.io/v1/clusterroles

Параметри

Відповідь

200 (ClusterRoleList): OK

401: Unauthorized

create створення ClusterRole

HTTP запит

POST /apis/rbac.authorization.k8s.io/v1/clusterroles

Параметри

Відповідь

200 (ClusterRole): OK

201 (ClusterRole): Created

202 (ClusterRole): Accepted

401: Unauthorized

update заміна вказаної ClusterRole

HTTP запит

PUT /apis/rbac.authorization.k8s.io/v1/clusterroles/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ClusterRole

  • body: ClusterRole, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (ClusterRole): OK

201 (ClusterRole): Created

401: Unauthorized

patch часткове оновлення вказаної ClusterRole

HTTP запит

PATCH /apis/rbac.authorization.k8s.io/v1/clusterroles/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ClusterRole

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (ClusterRole): OK

201 (ClusterRole): Created

401: Unauthorized

delete видалення ClusterRole

HTTP запит

DELETE /apis/rbac.authorization.k8s.io/v1/clusterroles/{name}

Параметри

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції ClusterRole

HTTP запит

DELETE /apis/rbac.authorization.k8s.io/v1/clusterroles

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

6.5.5.6 - ClusterRoleBinding

ClusterRoleBinding посилається на ClusterRole, але не містить її.

apiVersion: rbac.authorization.k8s.io/v1

import "k8s.io/api/rbac/v1"

ClusterRoleBinding

ClusterRoleBinding посилається на ClusterRole, але не містить її. ClusterRoleBinding може посилатися на ClusterRole в глобальному просторі імен та додає інформацію про субʼєкти через Subject.


  • apiVersion: rbac.authorization.k8s.io/v1

  • kind: ClusterRoleBinding

  • metadata (ObjectMeta)

    Стандартні метадані обʼєкта.

  • roleRef (RoleRef), обовʼязкове

    RoleRef може посилатися лише на ClusterRole в глобальному просторі імен. Якщо RoleRef не може бути розвʼязано, Авторизатор повинен повернути помилку. Це поле є незмінним.

    RoleRef містить інформацію, яка посилається на використану роль

    • roleRef.apiGroup (string), обовʼязкове

      APIGroup — це група для вказаного ресурсу

    • roleRef.kind (string), обовʼязкове

      Kind - тип вказаного ресурсу

    • roleRef.name (string), обовʼязкове

      Name - це імʼя вказаного ресурсу

  • subjects ([]Subject)

    Atomic: буде замінено під час злиття

    Subjects містить посилання на обʼєкти, до яких застосовується роль.

    Subject містить посилання на обʼєкт або ідентифікатори користувачів, до яких застосовується привʼязка ролей. Може містити або пряме посилання на обʼєкт API, або значення для не-обʼєктів, таких як імена користувачів і груп.

    • subjects.kind (string), обовʼязкове

      Kind — тип обʼєкта, на який посилається. Значення, визначені цією API групою, є "User", "Group" та "ServiceAccount". Якщо Авторизатор не впізнає значення kind, він повинен повідомити про помилку.

    • subjects.name (string), обовʼязкове

      Name — імʼя обʼєкта, на який посилається.

    • subjects.apiGroup (string)

      APIGroup — це API група вказаного субʼєкта. Стандартно "" для субʼєктів ServiceAccount. Стандартно "rbac.authorization.k8s.io" для субʼєктів User і Group.

    • subjects.namespace (string)

      Namespace — простір імен вказаного обʼєкта. Якщо тип обʼєкта не простір імен, наприклад, "User" або "Group", і це значення не порожнє, Авторизатор повинен повідомити про помилку.

ClusterRoleBindingList

ClusterRoleBindingList — це колекція ClusterRoleBindings.


  • apiVersion: rbac.authorization.k8s.io/v1

  • kind: ClusterRoleBindingList

  • metadata (ListMeta)

    Стандартні метадані обʼєкта.

  • items ([]ClusterRoleBinding), обовʼязкове

    Items — це список ClusterRoleBindings.

Операції


get отримати вказаний ClusterRoleBinding

HTTP запит

GET /apis/rbac.authorization.k8s.io/v1/clusterrolebindings/{name}

Параметри

  • name (в шляху): string, обовʼязково

    name of the ClusterRoleBinding

  • pretty (в запиті): string

    pretty

Відповідь

200 (ClusterRoleBinding): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу ClusterRoleBinding

HTTP запит

GET /apis/rbac.authorization.k8s.io/v1/clusterrolebindings

Параметри

Відповідь

200 (ClusterRoleBindingList): OK

401: Unauthorized

create створення ClusterRoleBinding

HTTP запит

POST /apis/rbac.authorization.k8s.io/v1/clusterrolebindings

Параметри

Відповідь

200 (ClusterRoleBinding): OK

201 (ClusterRoleBinding): Created

202 (ClusterRoleBinding): Accepted

401: Unauthorized

update заміна вказаного ClusterRoleBinding

HTTP запит

PUT /apis/rbac.authorization.k8s.io/v1/clusterrolebindings/{name}

Параметри

  • name (в шляху): string, обовʼязково

    name of the ClusterRoleBinding

  • body: ClusterRoleBinding, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (ClusterRoleBinding): OK

201 (ClusterRoleBinding): Created

401: Unauthorized

patch часткове оновлення вказаного ClusterRoleBinding

HTTP запит

PATCH /apis/rbac.authorization.k8s.io/v1/clusterrolebindings/{name}

Параметри

  • name (в шляху): string, обовʼязково

    name of the ClusterRoleBinding

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (ClusterRoleBinding): OK

201 (ClusterRoleBinding): Created

401: Unauthorized

delete видалення ClusterRoleBinding

HTTP запит

DELETE /apis/rbac.authorization.k8s.io/v1/clusterrolebindings/{name}

Параметри

  • name (в шляху): string, обовʼязково

    name of the ClusterRoleBinding

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції ClusterRoleBinding

HTTP запит

DELETE /apis/rbac.authorization.k8s.io/v1/clusterrolebindings

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

6.5.5.7 - Role

Роль — це логічне групування PolicyRules у просторі імен, на яке можна посилатися як на одиницю за допомогою RoleBinding.

apiVersion: rbac.authorization.k8s.io/v1

import "k8s.io/api/rbac/v1"

Role

Роль — це логічне групування PolicyRules у просторі імен, на яке можна посилатися як на одиницю за допомогою RoleBinding.


  • apiVersion: rbac.authorization.k8s.io/v1

  • kind: Role

  • metadata (ObjectMeta)

    Стандартні метадані обʼєкта.

  • rules ([]PolicyRule)

    Atomic: буде замінено під час злиття

    Rules містить всі PolicyRules для цієї Ролі

    PolicyRule містить інформацію, що описує правило політики, але не містить інформації про те, до кого застосовується правило або до якого простору імен воно відноситься.

    • rules.apiGroups ([]string)

      Atomic: буде замінено під час злиття

      APIGroups — це назва APIGroup, яка містить ресурси. Якщо вказано декілька API груп, будь-яка дія, запитана для одного з перерахованих ресурсів у будь-якій API групі буде дозволена. "" представляє основну API групу, а "*" представляє всі API групи.

    • rules.resources ([]string)

      Atomic: буде замінено під час злиття

      Resources — це список ресурсів, до яких застосовується це правило. '*' представляє всі ресурси.

    • rules.verbs ([]string), обовʼязково

      Atomic: буде замінено під час злиття

      Verbs — це список дієслів, які застосовуються до ВСІХ ResourceKinds, що містяться у цьому правилі. '*' представляє всі дієслова.

    • rules.resourceNames ([]string)

      Atomic: буде замінено під час злиття

      ResourceNames — це необовʼязковий білий список імен, до яких застосовується правило. Порожній набір означає, що дозволено все.

    • rules.nonResourceURLs ([]string)

      Atomic: буде замінено під час злиття

      NonResourceURLs — це набір часткових URL-адрес, до яких користувач повинен мати доступ. '*' дозволені, але тільки як повний, кінцевий крок у шляху. Оскільки не ресурсні URL-адреси не належать до простору імен, це поле застосовується тільки для ClusterRoles, на які посилається ClusterRoleBinding. Правила можуть застосовуватися або до API ресурсів (таких як "pods" або "secrets"), або до не ресурсних URL-шляхів (таких як "/api"), але не до обох одночасно.

RoleList

RoleList — це колекція Ролей.


  • apiVersion: rbac.authorization.k8s.io/v1

  • kind: RoleList

  • metadata (ListMeta)

    Стандартні метадані обʼєкта.

  • items ([]Role), обовʼязково

    Items — це список Ролей.

Операції


get отримати вказану Role

HTTP запит

GET /apis/rbac.authorization.k8s.io/v1/namespaces/{namespace}/roles/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя Role

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (Role): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу Role

HTTP запит

GET /apis/rbac.authorization.k8s.io/v1/namespaces/{namespace}/roles

Параметри

Відповідь

200 (RoleList): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу Role

HTTP запит

GET /apis/rbac.authorization.k8s.io/v1/roles

Параметри

Відповідь

200 (RoleList): OK

401: Unauthorized

create створення Role

HTTP запит

POST /apis/rbac.authorization.k8s.io/v1/namespaces/{namespace}/roles

Параметри

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Role, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (Role): OK

201 (Role): Created

202 (Role): Accepted

401: Unauthorized

update заміна вказаної Role

HTTP запит

PUT /apis/rbac.authorization.k8s.io/v1/namespaces/{namespace}/roles/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя Role

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Role, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (Role): OK

201 (Role): Created

401: Unauthorized

patch часткове оновлення вказаної Role

HTTP запит

PATCH /apis/rbac.authorization.k8s.io/v1/namespaces/{namespace}/roles/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя Role

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (Role): OK

201 (Role): Created

401: Unauthorized

delete видалення Role

HTTP запит

DELETE /apis/rbac.authorization.k8s.io/v1/namespaces/{namespace}/roles/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя Role

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection вилучення колекції Role

HTTP запит

DELETE /apis/rbac.authorization.k8s.io/v1/namespaces/{namespace}/roles

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

6.5.5.8 - RoleBinding

RoleBinding посилається на роль, але не містить її.

apiVersion: rbac.authorization.k8s.io/v1

import "k8s.io/api/rbac/v1"

RoleBinding

RoleBinding посилається на роль, але не містить її. RoleBinding може посилатися на Role в поточному просторі імен або на ClusterRole в глобальному просторі імен. RoleBinding додає інформацію про субʼєкти через Subjects і інформацію про простір імен, в якому існує. RoleBindings у визначеному просторі імен мають вплив лише в цьому просторі імен.


  • apiVersion: rbac.authorization.k8s.io/v1

  • kind: RoleBinding

  • metadata (ObjectMeta)

    Стандартні метадані обʼєкта.

  • roleRef (RoleRef), обовʼязкове

    RoleRef може посилатися на Role в поточному просторі імен або на ClusterRole в глобальному просторі імен. Якщо RoleRef не може бути розвʼязано, Авторизатор повинен повернути помилку. Це поле є незмінним.

    RoleRef містить інформацію, яка посилається на використану роль

    • roleRef.apiGroup (string), обовʼязкове

      APIGroup — це група для вказаного ресурсу

    • roleRef.kind (string), обовʼязкове

      Kind — тип вказаного ресурсу

    • roleRef.name (string), обовʼязкове

      Name — це імʼя вказаного ресурсу

  • subjects ([]Subject)

    Atomic: буде замінено під час злиття

    Subjects містить посилання на обʼєкти, до яких застосовується роль.

    Subject містить посилання на обʼєкт або ідентифікатори користувачів, до яких застосовується привʼязка ролей. Може містити або пряме посилання на обʼєкт API, або значення для не-обʼєктів, таких як імена користувачів і груп.

    • subjects.kind (string), обовʼязкове

      Kind — тип обʼєкта, на який посилається. Значення, визначені цією API групою, є "User", "Group" та "ServiceAccount". Якщо Авторизатор не впізнає значення kind, він повинен повідомити про помилку.

    • subjects.name (string), обовʼязкове

      Name — імʼя обʼєкта, на який посилається.

    • subjects.apiGroup (string)

      APIGroup — це API група вказаного субʼєкта. Стандартно — "" для субʼєктів ServiceAccount. Стандартно — "rbac.authorization.k8s.io" для субʼєктів User і Group.

    • subjects.namespace (string)

      Namespace — простір імен вказаного обʼєкта. Якщо тип обʼєкта не простір імен, наприклад, "User" або "Group", і це значення не порожнє, Авторизатор повинен повідомити про помилку.

RoleBindingList

RoleBindingList — це колекція RoleBindings.


  • apiVersion: rbac.authorization.k8s.io/v1

  • kind: RoleBindingList

  • metadata (ListMeta)

    Стандартні метадані обʼєкта.

  • items ([]RoleBinding), обовʼязкове

    Items — це список RoleBindings.

Операції


get отримати вказаний RoleBinding

HTTP запит

GET /apis/rbac.authorization.k8s.io/v1/namespaces/{namespace}/rolebindings/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя RoleBinding

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (RoleBinding): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу RoleBinding

HTTP запит

GET /apis/rbac.authorization.k8s.io/v1/namespaces/{namespace}/rolebindings

Параметри

Відповідь

200 (RoleBindingList): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу RoleBinding

HTTP запит

GET /apis/rbac.authorization.k8s.io/v1/rolebindings

Параметри

Відповідь

200 (RoleBindingList): OK

401: Unauthorized

create створення RoleBinding

HTTP запит

POST /apis/rbac.authorization.k8s.io/v1/namespaces/{namespace}/rolebindings

Параметри

Відповідь

200 (RoleBinding): OK

201 (RoleBinding): Created

202 (RoleBinding): Accepted

401: Unauthorized

update заміна вказаного RoleBinding

HTTP запит

PUT /apis/rbac.authorization.k8s.io/v1/namespaces/{namespace}/rolebindings/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя RoleBinding

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: RoleBinding, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (RoleBinding): OK

201 (RoleBinding): Created

401: Unauthorized

patch часткове оновлення вказаного RoleBinding

HTTP запит

PATCH /apis/rbac.authorization.k8s.io/v1/namespaces/{namespace}/rolebindings/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя RoleBinding

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (RoleBinding): OK

201 (RoleBinding): Created

401: Unauthorized

delete видалення RoleBinding

HTTP запит

DELETE /apis/rbac.authorization.k8s.io/v1/namespaces/{namespace}/rolebindings/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя RoleBinding

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції RoleBinding

HTTP запит

DELETE /apis/rbac.authorization.k8s.io/v1/namespaces/{namespace}/rolebindings

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

6.5.6 - Ресурси політики

6.5.6.1 - FlowSchema

FlowSchema визначає схему групи потоків.

apiVersion: flowcontrol.apiserver.k8s.io/v1

import "k8s.io/api/flowcontrol/v1"

FlowSchema

FlowSchema визначає схему групи потоків. Зверніть увагу, що потік складається з набору вхідних API-запитів з подібними атрибутами та ідентифікується парою рядків: імʼям FlowSchema та "розрізнювачем потоку".


FlowSchemaSpec

FlowSchemaSpec описує вигляд специфікації FlowSchema.


  • distinguisherMethod (FlowDistinguisherMethod)

    distinguisherMethod визначає, як обчислюється розрізнювач потоку для запитів, які відповідають цій схемі. nil вказує на те, що розрізнювач вимкнений і завжди буде пустий рядок.

    FlowDistinguisherMethod вказує на метод розрізнювача потоку.

    • distinguisherMethod.type (string), обовʼязково

      type - це тип методу розрізнювача потоку. Підтримувані типи: "ByUser" та "ByNamespace". Обовʼязково.

  • matchingPrecedence (int32)

    matchingPrecedence використовується для вибору серед FlowSchema, які відповідають заданому запиту. Обрана FlowSchema є серед тих, що мають чисельно найменший (який ми вважаємо логічно найвищим) MatchingPrecedence. Кожне значення MatchingPrecedence повинно бути в діапазоні [1, 10000]. Зауважте, що якщо пріоритет не вказано, він буде стандартно встановлений на 1000.

  • priorityLevelConfiguration (PriorityLevelConfigurationReference), обовʼязково

    priorityLevelConfiguration повинна посилатися на PriorityLevelConfiguration в кластері. Якщо посилання не вдається вирішити, FlowSchema буде ігноруватися і позначатися як недійсна в її статусі. Обовʼязково.

    PriorityLevelConfigurationReference містить інформацію, яка посилається на використання "request-priority".

    • priorityLevelConfiguration.name (string), обовʼязково

      name — це імʼя конфігурації рівня пріоритетів, на яку є посилання. Обовʼязково.

  • rules ([]PolicyRulesWithSubjects)

    Atomic: буде замінено під час злиття

    rules описують, які запити будуть відповідати цій схемі потоку. Ця FlowSchema відповідає запиту, якщо принаймні один член rules відповідає запиту. Якщо це порожній масив, то запити, які відповідають FlowSchema, не буде.

    PolicyRulesWithSubjects визначає тест, який застосовується до запиту до apiserver. Тест враховує субʼєкт, який робить запит, дієслово, яке запитується, і ресурс, яким має бути дія. Цей PolicyRulesWithSubjects відповідає запиту, якщо і тільки якщо обидва (а) принаймні один член subjects відповідає запиту і (б) принаймні один член resourceRules або nonResourceRules відповідає запиту.

    • rules.subjects ([]Subject), обовʼязково

      Atomic: буде замінено під час злиття

      subjects — це список звичайних користувачів, службових облікових записів або груп, яких це правило стосується. У цьому зрізі повинен бути принаймні один член. Зріз, який включає як системні групи "system:authenticated" і "system:unauthenticated", відповідає кожному запиту. Обовʼязково.

      Тема відповідає ініціатору запиту, визначеному системою автентифікації запиту. Існує три способи зіставлення автора; за обліковим записом користувача, групи або службового облікового запиту.

      • rules.subjects.kind (string), обовʼязково

        kind показує, яке з полів не пусте. Обовʼязково.

      • rules.subjects.group (GroupSubject)

        group відповідає на підставі назви групи користувачів.

        GroupSubject містить детальну інформацію для субʼєкта типу групи.

      • rules.subjects.serviceAccount (ServiceAccountSubject)

        serviceAccount відповідає службовим обліковим записам.

        ServiceAccountSubject містить детальну інформацію для субʼєкта типу службового облікового запису.

        • rules.subjects.serviceAccount.name (string), обовʼязково

          name — це імʼя облікових записів ServiceAccount, або "*" для відповідності незалежно від імені. Обовʼязково.

        • rules.subjects.serviceAccount.namespace (string), обовʼязково

          namespace — це простір імен відповідних обʼєктів ServiceAccount. Обовʼязково.

      • rules.subjects.user (UserSubject)

        user збіг на основі імені користувача.

        UserSubject містить детальну інформацію для субʼєкта типу користувача.

        • rules.subjects.user.name (string), обовʼязково

          name — це імʼя користувача, яке має збіг, або "*" для відповідності всім іменам користувачів. Обовʼязково.

    • rules.nonResourceRules ([]NonResourcePolicyRule)

      Atomic: буде замінено під час злиття

      nonResourceRules — це список NonResourcePolicyRules, які ідентифікують відповідні запити відповідно до їх дієслова і цільового URL без ресурсів.

      NonResourcePolicyRule є предикатом, який відповідає запитам без ресурсів відповідно до їх дієслова і цільового URL без ресурсів. NonResourcePolicyRule відповідає запиту, якщо і тільки якщо обидва (а) принаймні один член verbs відповідає запиту і (б) принаймні один член nonResourceURLs відповідає запиту.

      • rules.nonResourceRules.nonResourceURLs ([]string), обовʼязково

        Set: унікальні значення будуть збережені під час злиття

        nonResourceURLs — це набір префіксів URL, до яких користувач має мати доступ і не може бути порожнім. Наприклад:

        • "/healthz" є допустимим
        • "/hea*" є недійсним
        • "/hea" є допустимим, але не відповідає нічому
        • "/hea/*" також не відповідає нічому
        • "/healthz/*" відповідає всім перевіркам стану компонентів. "*" відповідає всім URL без ресурсів. Якщо він присутній, він повинен бути єдиним елементом. Обовʼязково.
      • rules.nonResourceRules.verbs ([]string), обовʼязково

        Set: унікальні значення будуть збережені під час злиття

        verbs — це список відповідних дієслів і не може бути порожнім. "*" відповідає всім дієсловам. Якщо він присутній, він повинен бути єдиним елементом. Обовʼязково.

    • rules.resourceRules ([]ResourcePolicyRule)

      Atomic: буде замінено під час злиття

      resourceRules — це зріз ResourcePolicyRules, які ідентифікують відповідні запити відповідно до їх дієслова і цільового ресурсу. Принаймні одна з resourceRules або nonResourceRules має бути не порожньою.

      ResourcePolicyRule є предикатом, який відповідає деяким запитам ресурсів, перевіряючи дієслово запиту і цільовий ресурс. ResourcePolicyRule відповідає запиту ресурсу, якщо і тільки якщо: (а) принаймні один член verbs відповідає запиту, (б) принаймні один член apiGroups відповідає запиту, (в) принаймні один член resources відповідає запиту, і (г) або (d1) запит не вказує простір імен (тобто Namespace=="") і clusterScope є true або (d2) запит вказує простір імен, і принаймні один член namespaces відповідає простору імен запиту.

      • rules.resourceRules.apiGroups ([]string), обовʼязково

        Set: унікальні значення будуть збережені під час злиття

        apiGroups — це список відповідних API-груп і не може бути порожнім. "*" відповідає всім API-групам і, якщо він присутній, він повинен бути єдиним елементом. Обовʼязково.

      • rules.resourceRules.resources ([]string), обовʼязково

        Set: унікальні значення будуть збережені під час злиття

        resources — це список відповідних ресурсів (тобто в нижньому регістрі та множині) і, за бажанням, субресурс. Наприклад, ["services", "nodes/status"]. Цей список не може бути порожнім. "*" відповідає всім ресурсам і, якщо він присутній, він повинен бути єдиним елементом. Обовʼязково.

      • rules.resourceRules.verbs ([]string), обовʼязково

        Set: унікальні значення будуть збережені під час злиття

        verbs — це список відповідних дієслів і не може бути порожнім. "*" відповідає всім дієсловам і, якщо він присутній, він повинен бути єдиним елементом. Обовʼязково.

      • rules.resourceRules.clusterScope (boolean)

        clusterScope показує, чи потрібно відповідати запитам, які не вказують простір імен (це стається або тому, що ресурс не має простору імен, або запит цілісно охоплює всі простори імен). Якщо це поле відсутнє або false, то поле namespaces повинне містити не порожній список.

      • rules.resourceRules.namespaces ([]string)

        Set: унікальні значення будуть збережені під час злиття

        namespaces — це список цільових просторів імен, які обмежують збіги. Запит, який вказує на простір імен, має збіг тільки у випадку, якщо або (a) цей список містить цільовий простір імен або (b) цей список містить "*". Зверніть увагу, що "*" відповідає будь-якому вказаному простору імен, але не відповідає запиту, який не вказує простір імен (див. поле clusterScope для цього). Цей список може бути порожнім, але лише в тому випадку, якщо clusterScope є true.

FlowSchemaStatus

FlowSchemaStatus відображає поточний стан FlowSchema.


  • conditions ([]FlowSchemaCondition)

    Patch стратегія: злиття за ключем type

    Map: унікальні значення за ключем type будуть збережені під час злиття

    conditions — це список поточних станів FlowSchema.

    FlowSchemaCondition описує умови для FlowSchema.

    • conditions.lastTransitionTime (Time)

      lastTransitionTime — час останнього переходу стану з одного статусу в інший.

      Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

    • conditions.message (string)

      message — повідомлення зрозуміле людині, що вказує деталі про останній перехід.

    • conditions.reason (string)

      reason — унікальна причина у вигляді одного слова у CamelCase для останньої зміни стану.

    • conditions.status (string)

      status — статус стану. Може бути True, False, Unknown. Обовʼязково.

    • conditions.type (string)

      type — тип стану. Обовʼязково.

FlowSchemaList

FlowSchemaList - це список обʼєктів FlowSchema.


Операції


get отримату вказану FlowSchema

HTTP запит

GET /apis/flowcontrol.apiserver.k8s.io/v1/flowschemas/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя FlowSchema

  • pretty (в запиті): string

    pretty

Відповідь

200 (FlowSchema): OK

401: Unauthorized

get отримати статус вказаної FlowSchema

HTTP запит

GET /apis/flowcontrol.apiserver.k8s.io/v1/flowschemas/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя FlowSchema

  • pretty (в запиті): string

    pretty

Відповідь

200 (FlowSchema): OK

401: Unauthorized

list перелвк або перегляд обʼєктів типу FlowSchema

HTTP запит

GET /apis/flowcontrol.apiserver.k8s.io/v1/flowschemas

Параметри

Відповідь

200 (FlowSchemaList): OK

401: Unauthorized

create створення FlowSchema

HTTP запит

POST /apis/flowcontrol.apiserver.k8s.io/v1/flowschemas

Параметри

Відповідь

200 (FlowSchema): OK

201 (FlowSchema): Created

202 (FlowSchema): Accepted

401: Unauthorized

update заміна вказаної FlowSchema

HTTP запит

PUT /apis/flowcontrol.apiserver.k8s.io/v1/flowschemas/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя FlowSchema

  • body: FlowSchema, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (FlowSchema): OK

201 (FlowSchema): Created

401: Unauthorized

updateзаміна статусу вказаної FlowSchema

HTTP запит

PUT /apis/flowcontrol.apiserver.k8s.io/v1/flowschemas/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя FlowSchema

  • body: FlowSchema, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (FlowSchema): OK

201 (FlowSchema): Created

401: Unauthorized

patch часткове оновлення вказаної FlowSchema

HTTP запит

PATCH /apis/flowcontrol.apiserver.k8s.io/v1/flowschemas/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя FlowSchema

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (FlowSchema): OK

201 (FlowSchema): Created

401: Unauthorized

patch часткове оновлення статусу вказаної FlowSchema

HTTP запит

PATCH /apis/flowcontrol.apiserver.k8s.io/v1/flowschemas/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя FlowSchema

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (FlowSchema): OK

201 (FlowSchema): Created

401: Unauthorized

delete видалення FlowSchema

HTTP запит

DELETE /apis/flowcontrol.apiserver.k8s.io/v1/flowschemas/{name}

Параметри

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції FlowSchema

HTTP запит

DELETE /apis/flowcontrol.apiserver.k8s.io/v1/flowschemas

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

6.5.6.2 - LimitRange

LimitRange встановлює обмеження на використання ресурсів для кожного типу ресурсу у просторі імен.

apiVersion: v1

import "k8s.io/api/core/v1"

LimitRange

LimitRange встановлює обмеження на використання ресурсів для кожного типу ресурсу в просторі імен.


LimitRangeSpec

LimitRangeSpec визначає мінімальні та максимальні обмеження на використання ресурсів, які відповідають певному типу.


  • limits ([]LimitRangeItem), обовʼязково

    Atomic: буде замінено під час злиття

    Limits — це список обʼєктів LimitRangeItem, що застосовуються.

    LimitRangeItem визначає мінімальні та максимальні обмеження на використання будь-якого ресурсу, який відповідає певному типу.

    • limits.type (string), обовʼязково

      Тип ресурсу, до якого застосовується це обмеження.

    • limits.default (map[string]Quantity)

      Стандартні граничні значення запиту ресурсу за назвою ресурсу, якщо обмеження ресурсів не вказано.

    • limits.defaultRequest (map[string]Quantity)

      DefaultRequest — це стандартне значення запиту на вимоги до ресурсу за назвою ресурсу, якщо запит на ресурси не вказано.

    • limits.max (map[string]Quantity)

      Максимальні обмеження на використання цього типу за назвою ресурсу.

    • limits.maxLimitRequestRatio (map[string]Quantity)

      MaxLimitRequestRatio, якщо зазначено, названий ресурс повинен мати запит і обмеження, які обидва є ненульовими, де обмеження, поділене на запит, менше або дорівнює перерахованому значенню; це представляє максимальне навантаження для названого ресурсу.

    • limits.min (map[string]Quantity)

      Мінімальні обмеження на використання цього типу за назвою ресурсу.

LimitRangeList

LimitRangeList — це список елементів LimitRange.


Операції


get отримати вказаний LimitRange

HTTP запит

GET /api/v1/namespaces/{namespace}/limitranges/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя LimitRange

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (LimitRange): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу LimitRange

HTTP запит

GET /api/v1/namespaces/{namespace}/limitranges

Параметри

Відповідь

200 (LimitRangeList): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу LimitRange

HTTP запит

GET /api/v1/limitranges

Параметри

Відповідь

200 (LimitRangeList): OK

401: Unauthorized

create створення LimitRange

HTTP запит

POST /api/v1/namespaces/{namespace}/limitranges

Параметри

Відповідь

200 (LimitRange): OK

201 (LimitRange): Created

202 (LimitRange): Accepted

401: Unauthorized

update заміна вказаного LimitRange

HTTP запит

PUT /api/v1/namespaces/{namespace}/limitranges/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя LimitRange

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: LimitRange, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (LimitRange): OK

201 (LimitRange): Created

401: Unauthorized

patch часткове оновлення вказаного LimitRange

HTTP запит

PATCH /api/v1/namespaces/{namespace}/limitranges/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя LimitRange

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (LimitRange): OK

201 (LimitRange): Created

401: Unauthorized

delete видалення LimitRange

HTTP запит

DELETE /api/v1/namespaces/{namespace}/limitranges/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя LimitRange

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції LimitRange

HTTP запит

DELETE /api/v1/namespaces/{namespace}/limitranges

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

6.5.6.3 - ResourceQuota

ResourceQuota встановлює сукупні обмеження квоти, що застосовуються до простору імен.

apiVersion: v1

import "k8s.io/api/core/v1"

ResourceQuota

ResourceQuota встановлює сукупні квоти, які застосовуються для кожного простору імен.


ResourceQuotaSpec

ResourceQuotaSpec визначає бажані жорсткі обмеження для застосування квоти.


  • hard (map[string]Quantity)

    hard — це набір бажаних жорстких обмежень для кожного названого ресурсу. Докладніше: https://kubernetes.io/docs/concepts/policy/resource-quotas/

  • scopeSelector (ScopeSelector)

    scopeSelector — це також набір фільтрів, таких як scopes, які повинні відповідати кожному обʼєкту, відстежуваному квотою, але виражені за допомогою ScopeSelectorOperator у поєднанні з можливими значеннями. Для відповідності ресурсу повинні відповідати як scopes, так і scopeSelector (якщо зазначено у spec).

    Селектор області застосування являє собою AND селекторів, представлених вимогами селектора ресурсу з обмеженою областю застосування.

    • scopeSelector.matchExpressions ([]ScopedResourceSelectorRequirement)

      Atomic: буде замінено під час злиття

      Список вимог селектора за областю застосування ресурсів.

      Вимога до селектора ресурсу з областю застосування — це селектор, який містить значення, імʼя області застосування та оператор, який повʼязує імʼя області застосування зі значеннями.

      • scopeSelector.matchExpressions.operator (string), обовʼязково

        Представляє стосунок області застосування з до набору значень. Допустимі оператори In, NotIn, Exists, DoesNotExists.

      • scopeSelector.matchExpressions.scopeName (string), обовʼязково

        Імʼя області застосування, до якої застосовується селектор.

      • scopeSelector.matchExpressions.values ([]string)

        Atomic: буде замінено під час злиття

        Масив рядкових значень. Якщо оператор In або NotIn, масив значень не повинен бути порожнім. Якщо оператор Exists або DoesNotExist, масив значень повинен бути порожнім. Цей масив замінюється під час стратегії обʼєднання патчів.

  • scopes ([]string)

    Atomic: буде замінено під час злиття

    Набір фільтрів, які повинні відповідати кожному обʼєкту, відстежуваному квотою. Якщо не вказано, квота відповідає всім обʼєктам.

ResourceQuotaStatus

ResourceQuotaStatus визначає застосовані жорсткі обмеження та спостережуване використання.


  • hard (map[string]Quantity)

    Hard — це набір застосованих жорстких обмежень для кожного названого ресурсу. Докладніше: https://kubernetes.io/docs/concepts/policy/resource-quotas/

  • used (map[string]Quantity)

    Used — це поточне спостережуване загальне використання ресурсу в просторі імен.

ResourceQuotaList

ResourceQuotaList — це список елементів ResourceQuota.


Операції


get отримати вказану ResourceQuota

HTTP запит

GET /api/v1/namespaces/{namespace}/resourcequotas/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ResourceQuota

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (ResourceQuota): OK

401: Unauthorized

get отримати статус вказаної ResourceQuota

HTTP запит

GET /api/v1/namespaces/{namespace}/resourcequotas/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ResourceQuota

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (ResourceQuota): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу ResourceQuota

HTTP запит

GET /api/v1/namespaces/{namespace}/resourcequotas

Параметри

Відповідь

200 (ResourceQuotaList): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу ResourceQuota

HTTP запит

GET /api/v1/resourcequotas

Параметри

Відповідь

200 (ResourceQuotaList): OK

401: Unauthorized

create створення ResourceQuota

HTTP запит

POST /api/v1/namespaces/{namespace}/resourcequotas

Параметри

Відповідь

200 (ResourceQuota): OK

201 (ResourceQuota): Created

202 (ResourceQuota): Accepted

401: Unauthorized

update заміна вказаної ResourceQuota

HTTP запит

PUT /api/v1/namespaces/{namespace}/resourcequotas/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ResourceQuota

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: ResourceQuota, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (ResourceQuota): OK

201 (ResourceQuota): Created

401: Unauthorized

update заміна статусу вказаної ResourceQuota

HTTP запит

PUT /api/v1/namespaces/{namespace}/resourcequotas/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ResourceQuota

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: ResourceQuota, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (ResourceQuota): OK

201 (ResourceQuota): Created

401: Unauthorized

patch часткове оновлення вказаної ResourceQuota

HTTP запит

PATCH /api/v1/namespaces/{namespace}/resourcequotas/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ResourceQuota

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (ResourceQuota): OK

201 (ResourceQuota): Created

401: Unauthorized

patch часткове оновлення статусу вказаної ResourceQuota

HTTP запит

PATCH /api/v1/namespaces/{namespace}/resourcequotas/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ResourceQuota

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (ResourceQuota): OK

201 (ResourceQuota): Created

401: Unauthorized

delete видалення ResourceQuota

HTTP запит

DELETE /api/v1/namespaces/{namespace}/resourcequotas/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ResourceQuota

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (ResourceQuota): OK

202 (ResourceQuota): Accepted

401: Unauthorized

deletecollection видалення колекції ResourceQuota

HTTP запит

DELETE /api/v1/namespaces/{namespace}/resourcequotas

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

6.5.6.4 - NetworkPolicy

NetworkPolicy описує, який мережевий трафік дозволено для набору Podʼів.

apiVersion: networking.k8s.io/v1

import "k8s.io/api/networking/v1"

NetworkPolicy

NetworkPolicy описує, який мережевий трафік дозволений для набору Podʼів


NetworkPolicySpec

NetworkPolicySpec надає специфікацію NetworkPolicy


  • podSelector (LabelSelector), обовʼязково

    podSelector вибирає Podʼи, до яких застосовується цей обʼєкт NetworkPolicy. Масив правил ingress застосовується до будь-яких Podʼів, вибраних цим полем. Кілька мережевих політик можуть вибирати той самий набір Podʼів. У цьому випадку правила ingress для кожного з них поєднуються. Це поле НЕ є необовʼязковим і слідує стандартним семантикам вибору міток. Порожній podSelector збігається з усіма Podʼами в цьому простору імен.

  • policyTypes ([]string)

    Atomic: буде замінено під час злиття

    policyTypes — це список типів правил, до яких відноситься NetworkPolicy. Дійсні опції включають [“Ingress"], [“Egress"] або [“Ingress", “Egress"]. Якщо це поле не вказано, воно буде визначено стандартно на основі наявності правил ingress або egress; політики, які містять розділ egress, вважаються такими, що впливають на egress, а всі політики (незалежно від того, чи містять вони розділ ingress) вважаються такими, що впливають на ingress. Якщо ви хочете написати політику тільки для egress, ви повинні явно вказати policyTypes [“Egress"]. Аналогічно, якщо ви хочете написати політику, яка визначає, що egress не дозволений, ви повинні вказати значення policyTypes, яке включає “Egress" (оскільки така політика не включатиме розділ egress і стандартно буде просто [“Ingress" ]). Це поле є рівнем бета у версії 1.8.

  • ingress ([]NetworkPolicyIngressRule)

    Atomic: буде замінено під час злиття

    ingress  — це список правил ingress, які застосовуються до вибраних Podʼів. Трафік дозволено до Podʼа, якщо немає мережевих політик, які вибирають Pod (і кластерна політика інакше дозволяє трафік), АБО якщо джерелом трафіку є локальний вузол Podʼа, АБО якщо трафік відповідає принаймні одному правилу ingress серед усіх обʼєктів NetworkPolicy, чий podSelector відповідає Podʼу. Якщо це поле порожнє, ця NetworkPolicy не дозволяє жодного трафіку (і стандартно слугує виключно для того, щоб забезпечити ізоляцію вибраних Podʼів).

    NetworkPolicyIngressRule описує конкретний набір трафіку, який дозволено до Podʼів, вибраних podSelector у NetworkPolicySpec. Трафік повинен відповідати як ports, так і from.

    • ingress.from ([]NetworkPolicyPeer)

      Atomic: буде замінено під час злиття

      from — це список джерел, яким дозволено доступ до Podʼів, вибраних для цього правила. Елементи в цьому списку комбінуються за допомогою логічної операції OR. Якщо це поле порожнє або відсутнє, це правило збігається з усіма джерелами (трафік не обмежений за джерелом). Якщо це поле присутнє і містить принаймні один елемент, це правило дозволяє трафік лише у разі відповідності принаймні одному елементу зі списку from.

      NetworkPolicyPeer описує однорангового учасника для дозволу трафіку до/від. Допускаються лише певні комбінації полів.

      • ingress.from.ipBlock (IPBlock)

        ipBlock визначає політику для конкретного IPBlock. Якщо це поле встановлено, то жодне інше поле не може бути встановлене.

        IPBlock описує конкретний CIDR (наприклад, “192.168.1.0/24",“2001:db8::/64"), який дозволено для Podʼів, вибраних podSelector у NetworkPolicySpec. Поле except описує CIDR, які не повинні бути включені до цього правила.

        • ingress.from.ipBlock.cidr (string), обовʼязково

          cidr — це рядок, що представляє IPBlock. Дійсні приклади: “192.168.1.0/24" або “2001:db8::/64".

        • ingress.from.ipBlock.except ([]string)

          Atomic: буде замінено під час злиття

          except — це перелік CIDR, які не повинні бути включені до IPBlock. Дійсні приклади: “192.168.1.0/24" або “2001:db8::/64". Значення except будуть відхилені, якщо вони виходять за межі діапазону cidr.

      • ingress.from.namespaceSelector (LabelSelector)

        namespaceSelector вибирає простори імен за допомогою кластерних міток. Це поле слідує стандартним семантикам вибору міток; якщо присутнє, але порожнє, воно вибирає всі простори імен.

        Якщо також встановлено podSelector, тоді NetworkPolicyPeer загалом вибирає Podʼи, які відповідають podSelector у просторах імен, вибраних namespaceSelector. Інакше він вибирає всі Podʼи в просторах імен, вибраних namespaceSelector.

      • ingress.from.podSelector (LabelSelector)

        podSelector — це вибір міток, що вибирає Podʼи. Це поле слідує стандартним семантикам вибору міток; якщо присутнє, але порожнє, воно вибирає всі Podʼи.

        Якщо також встановлено namespaceSelector, тоді NetworkPolicyPeer загалом вибирає Podʼи, які відповідають podSelector у просторах імен, вибраних NamespaceSelector. Інакше він вибирає Podʼи, які відповідають podSelector у власному просторі імен політики.

    • ingress.ports ([]NetworkPolicyPort)

      Atomic: буде замінено під час злиття

      ports — це список портів, які повинні бути доступні у Podʼах, вибраних для цього правила. Кожен елемент у цьому списку комбінується за допомогою логічної операції OR. Якщо це поле порожнє або відсутнє, це правило збігається з усіма портами (трафік не обмежений за портом). Якщо це поле присутнє і містить принаймні один елемент, тоді це правило дозволяє трафік лише у разі відповідності принаймні одному порту зі списку.

      NetworkPolicyPort описує порт, на якому дозволено трафік

      • ingress.ports.port (IntOrString)

        port представляє порт на заданому протоколі. Це може бути числовий або іменований порт на Podʼі. Якщо це поле не вказане, це збігається з усіма іменами та номерами портів. Якщо присутнє, то відповідає лише трафік на вказаному протоколі ТА порті.

        IntOrString — це тип, який може містити int32 або рядок. При використанні перетворення з/в JSON або YAML він виробляє або споживає внутрішній тип. Це дозволяє вам мати, наприклад, поле JSON, яке може приймати імʼя або число.

      • ingress.ports.endPort (int32)

        endPort вказує, що діапазон портів від port до endPort, якщо встановлено, включно, повинен бути дозволений політикою. Це поле не може бути визначене, якщо поле port не визначене або якщо поле port визначене як іменований (string) порт. Поле endPort повинно бути рівним або більшим за port.

      • ingress.ports.protocol (string)

        protocol представляє протокол (TCP, UDP або SCTP), якому повинен відповідати трафік. Якщо не вказано, це поле стандартно встановлюється у TCP.

  • egress ([]NetworkPolicyEgressRule)

    Atomic: буде замінено під час злиття

    egress — це список правил egress, які застосовуються до вибраних Podʼів. Вихідний трафік дозволений, якщо немає мережевих політик, які вибирають Pod (і кластерна політика інакше дозволяє трафік), АБО якщо трафік відповідає принаймні одному правилу egress серед усіх обʼєктів NetworkPolicy, чий podSelector відповідає Podʼу. Якщо це поле порожнє, ця NetworkPolicy обмежує весь вихідний трафік (і слугує виключно для того, щоб стандартно забезпечити ізоляцію вибраних Podʼів). Це поле є рівнем бета у версії 1.8.

    NetworkPolicyEgressRule описує конкретний набір трафіку, який дозволено від Podʼів, вибраних podSelector у NetworkPolicySpec. Трафік повинен відповідати як ports, так і to. Цей тип є рівнем бета у версії 1.8.

    • egress.to ([]NetworkPolicyPeer)

      Atomic: буде замінено під час злиття

      to — це список пунктів призначення для вихідного трафіку Podʼів, вибраних для цього правила. Елементи в цьому списку комбінуються за допомогою логічної операції OR. Якщо це поле порожнє або відсутнє, це правило збігається з усіма пунктами призначення (трафік не обмежений за пунктом призначення). Якщо це поле присутнє і містить принаймні один елемент, це правило дозволяє трафік лише у разі відповідності принаймні одному елементу зі списку to.

      NetworkPolicyPeer описує однорангового учасника для дозволу трафіку до/від. Допускаються лише певні комбінації полів.

      • egress.to.ipBlock (IPBlock)

        ipBlock визначає політику для конкретного IPBlock. Якщо це поле встановлено, то жодне інше поле не може бути встановлене.

        IPBlock описує конкретний CIDR (наприклад, “192.168.1.0/24",“2001:db8::/64"), який дозволено для Podʼів, вибраних podSelector у NetworkPolicySpec. Поле except описує CIDR, які не повинні бути включені до цього правила.

        • egress.to.ipBlock.cidr (string), обовʼязково

          cidr — це рядок, що представляє IPBlock. Дійсні приклади: “192.168.1.0/24" або “2001:db8::/64".

        • egress.to.ipBlock.except ([]string)

          Atomic: буде замінено під час злиття

          except — це перелік CIDR, які не повинні бути включені до IPBlock. Дійсні приклади: “192.168.1.0/24" або “2001:db8::/64". Значення except будуть відхилені, якщо вони виходять за межі діапазону cidr.

      • egress.to.namespaceSelector (LabelSelector)

        namespaceSelector вибирає простори імен за допомогою кластерних міток. Це поле слідує стандартним семантикам вибору міток; якщо присутнє, але порожнє, воно вибирає всі простори імен.

        Якщо також встановлено podSelector, тоді NetworkPolicyPeer загалом вибирає Podʼи, які відповідають podSelector у просторах імен, вибраних namespaceSelector. Інакше він вибирає всі Podʼи в просторах імен, вибраних namespaceSelector.

      • egress.to.podSelector (LabelSelector)

        podSelector — це вибір міток, що вибирає Podʼи. Це поле слідує стандартним семантикам вибору міток; якщо присутнє, але порожнє, воно вибирає всі Podʼи.

        Якщо також встановлено namespaceSelector, тоді NetworkPolicyPeer загалом вибирає Podʼи, які відповідають podSelector у просторах імен, вибраних NamespaceSelector. Інакше він вибирає Podʼи, які відповідають podSelector у власному просторі імен політики.

    • egress.ports ([]NetworkPolicyPort)

      Atomic: буде замінено під час злиття

      ports — це список портів призначення для вихідного трафіку. Кожен елемент у цьому списку комбінується за допомогою логічної операції OR. Якщо це поле порожнє або відсутнє, це правило збігається з усіма портами (трафік не обмежений за портом). Якщо це поле присутнє і містить принаймні один елемент, тоді це правило дозволяє трафік лише у разі відповідності принаймні одному порту зі списку.

      NetworkPolicyPort описує порт, на якому дозволено трафік

      • egress.ports.port (IntOrString)

        port представляє порт на заданому протоколі. Це може бути числовий або іменований порт у Podʼі. Якщо це поле не вказане, воно збігається з усіма іменами та номерами портів. Якщо присутнє, то відповідає лише трафік на вказаному протоколі ТА порті.

        IntOrString — це тип, який може містити int32 або рядок. При використанні перетворення з/в JSON або YAML він виробляє або споживає внутрішній тип. Це дозволяє вам мати, наприклад, поле JSON, яке може приймати імʼя або число.

      • egress.ports.endPort (int32)

        endPort вказує, що діапазон портів від port до endPort, якщо встановлено, включно, повинен бути дозволений політикою. Це поле не може бути визначене, якщо поле port не визначене або якщо поле port визначене як іменований (string) порт. Поле endPort повинно бути рівним або більшим за port.

      • egress.ports.protocol (string)

        protocol представляє протокол (TCP, UDP або SCTP), якому повинен відповідати трафік. Якщо не вказано, це поле стандартно встановлюється у TCP.

NetworkPolicyList

NetworkPolicyList — це список обʼєктів NetworkPolicy.


Операції


get отримату ввказану NetworkPolicy

HTTP запит

GET /apis/networking.k8s.io/v1/namespaces/{namespace}/networkpolicies/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя NetworkPolicy

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (NetworkPolicy): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу NetworkPolicy

HTTP запит

GET /apis/networking.k8s.io/v1/namespaces/{namespace}/networkpolicies

Параметри

Відповідь

200 (NetworkPolicyList): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу

HTTP запит

GET /apis/networking.k8s.io/v1/networkpolicies

Параметри

Відповідь

200 (NetworkPolicyList): OK

401: Unauthorized

create створення NetworkPolicy

HTTP запит

POST /apis/networking.k8s.io/v1/namespaces/{namespace}/networkpolicies

Параметри

Відповідь

200 (NetworkPolicy): OK

201 (NetworkPolicy): Created

202 (NetworkPolicy): Accepted

401: Unauthorized

update заміна вказаної NetworkPolicy

HTTP запит

PUT /apis/networking.k8s.io/v1/namespaces/{namespace}/networkpolicies/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя NetworkPolicy

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: NetworkPolicy, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (NetworkPolicy): OK

201 (NetworkPolicy): Created

401: Unauthorized

patch часткове оновлення вказаної NetworkPolicy

HTTP запит

PATCH /apis/networking.k8s.io/v1/namespaces/{namespace}/networkpolicies/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя NetworkPolicy

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (NetworkPolicy): OK

201 (NetworkPolicy): Created

401: Unauthorized

delete видалення NetworkPolicy

HTTP запит

DELETE /apis/networking.k8s.io/v1/namespaces/{namespace}/networkpolicies/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя NetworkPolicy

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції NetworkPolicy

HTTP запит

DELETE /apis/networking.k8s.io/v1/namespaces/{namespace}/networkpolicies

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

6.5.6.5 - PodDisruptionBudget

PodDisruptionBudget — обʼєкт, який визначає максимальний розлад, який може бути завданий колекції Podʼів.

apiVersion: policy/v1

import "k8s.io/api/policy/v1"

PodDisruptionBudget

PodDisruptionBudget — обʼєкт, який визначає максимальний розлад, який може бути завданий колекції Podʼів.


PodDisruptionBudgetSpec

PodDisruptionBudgetSpec — це опис PodDisruptionBudget.


  • maxUnavailable (IntOrString)

    Виселення дозволяється, якщо щонайбільше "maxUnavailable" Podʼів, вибраних за допомогою "selector", є недоступними після виселення, тобто навіть за відсутності виселеного Podʼа. Наприклад, можна запобігти всім добровільним виселенням, вказавши 0. Це взаємозаперечне налаштування з "minAvailable".

    IntOrString — це тип, який може містити int32 або рядок. При використанні перетворення з/в JSON або YAML він виробляє або споживає внутрішній тип. Це дозволяє вам мати, наприклад, поле JSON, яке може приймати імʼя або число.

  • minAvailable (IntOrString)

    Виселення дозволяється, якщо щонайменше "minAvailable" Podʼів, вибраних за допомогою "selector", залишаться доступними після виселення, тобто навіть за відсутності виселеного Podʼа. Наприклад, можна запобігти всім добровільним виселенням, вказавши "100%".

    IntOrString — це тип, який може містити int32 або рядок. При використанні перетворення з/в JSON або YAML він виробляє або споживає внутрішній тип. Це дозволяє вам мати, наприклад, поле JSON, яке може приймати імʼя або число.

  • selector (LabelSelector)

    Запит міток для Podʼів, виселення яких керується бюджетом розладів. Нульовий селектор не вибиратиме жодного Podʼа, тоді як порожній ({}) селектор вибиратиме всі Podʼи в межах простору імен.

  • unhealthyPodEvictionPolicy (string)

    UnhealthyPodEvictionPolicy визначає критерії, коли несправні Podʼи слід вважати кандидатами на виселення. Поточна реалізація вважає справними ті Podʼи, у яких у status.conditions є елемент із type="Ready",status="True".

    Дійсні політики: IfHealthyBudget і AlwaysAllow. Якщо політика не вказана, буде використано стандартну поведінку, яка відповідає політиці IfHealthyBudget.

    Політика IfHealthyBudget означає, що працюючі Podʼи (status.phase="Running"), але ще не справні, можуть бути виселені лише у випадку, якщо захищений застосунок не в розладі (status.currentHealthy принаймні дорівнює status.desiredHealthy). Справні Podʼи підпадають під дію PDB для виселення.

    Політика AlwaysAllow означає, що всі працюючі Podʼи (status.phase="Running"), але ще не справні, вважаються в стані розладу і можуть бути виселені незалежно від того, чи виконуються критерії у PDB. Це означає, що працюючі Podʼи застосунка в розладі можуть не мати шансу стати справними. Справні Podʼи підпадають під дію PDB для виселення.

    У майбутньому можуть бути додані додаткові політики. Клієнти, які приймають рішення про виселення, повинні забороняти виселення несправних Podʼів, якщо вони стикаються з незнайомою політикою в цьому полі.

    Це поле знаходиться на рівні бета. API виселення використовує це поле, коли функціональні можливості PDBUnhealthyPodEvictionPolicy увімкнені (стандартно увімкнено).

PodDisruptionBudgetStatus

PodDisruptionBudgetStatus представляє інформацію про стан PodDisruptionBudget. Статус може відставати від фактичного стану системи.


  • currentHealthy (int32), обовʼязково

    поточна кількість справних Podʼів

  • desiredHealthy (int32), обовʼязково

    мінімально бажана кількість справних Podʼів

  • disruptionsAllowed (int32), обовʼязково

    Кількість розладів Podʼів, які наразі дозволені.

  • expectedPods (int32), обовʼязково

    загальна кількість Podʼів, врахованих цим бюджетом розладів

  • conditions ([]Condition)

    Patch strategy: обʼєднання за ключем type

    Map: унікальні значення за ключем type зберігаються під час обʼєднання

    Conditions містить стани для PDB. Контролер розладів встановлює стан DisruptionAllowed. Нижче наведені відомі значення для поля reason (у майбутньому можуть бути додані додаткові причини):

    • SyncFailed: Контролер зіткнувся з помилкою і не зміг обчислити кількість дозволених розладів. Тому розлади не дозволяються, і статус стану буде False.
    • InsufficientPods: Кількість Podʼів дорівнює або менша за кількість, необхідну для PodDisruptionBudget. Розлади не дозволяються, і статус стану буде False.
    • SufficientPods: Є більше Podʼів, ніж потрібно для PodDisruptionBudget. Стан буде True, і кількість дозволених розладів буде вказана у властивості disruptionsAllowed.

    Condition містить деталі щодо одного аспекту поточного стану цього ресурсу API.

    • conditions.lastTransitionTime (Time), обовʼязково

      lastTransitionTime — це час останнього переходу стану з одного в інший. Це має бути момент, коли змінився основний стан. Якщо це невідомо, то допустимо використовувати час, коли змінилося поле API.

      Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

    • conditions.message (string), обовʼязково

      message — це повідомлення, зрозуміле людині, вказує деталі про зміну стану. Це може бути порожній рядок.

    • conditions.reason (string), обовʼязково

      reason містить програмний ідентифікатор, що вказує причину останньої зміни стану. Виробники певних типів станів можуть визначати очікувані значення та значення для цього поля та чи вважаються ці значення гарантованими API. Значення має бути рядком у CamelCase. Це поле не може бути порожнім.

    • conditions.status (string), обовʼязково

      статус стану, одне з True, False, Unknown.

    • conditions.type (string), обовʼязково

      тип стану в CamelCase або у форматі foo.example.com/CamelCase.

    • conditions.observedGeneration (int64)

      observedGeneration представляє .metadata.generation, на основі якого було встановлено стан. Наприклад, якщо .metadata.generation наразі дорівнює 12, але .status.conditions[x].observedGeneration дорівнює 9, стан застарів щодо поточного стану екземпляра.

  • disruptedPods (map[string]Time)

    DisruptedPods містить інформацію про Podʼи, виселення яких було оброблено субресурсом виселення API-сервера, але ще не було зафіксовано контролером PodDisruptionBudget. Pod буде в цьому map з моменту, коли API-сервер обробив запит на виселення, до моменту, коли контролер PDB побачить Pod як такий, що позначений для видалення (або після тайм-ауту). Ключем у map є назва Podʼа, а значенням — час, коли API-сервер обробив запит на виселення. Якщо видалення не відбулося і Pod все ще є, він буде автоматично видалений зі списку контролером PodDisruptionBudget через певний час. Якщо все йде добре, цей map повинен бути порожнім більшу частину часу. Велика кількість записів у map може вказувати на проблеми з видаленням Podʼів.

    Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

  • observedGeneration (int64)

    Останнє спостережене покоління під час оновлення цього статусу PDB. DisruptionsAllowed та інша інформація про статус дійсні лише, якщо observedGeneration дорівнює поколінню обʼєкта PDB.

PodDisruptionBudgetList

PodDisruptionBudgetList —це колекція PodDisruptionBudgets.


Операції


get отримати вказаний PodDisruptionBudget

HTTP запит

GET /apis/policy/v1/namespaces/{namespace}/poddisruptionbudgets/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя PodDisruptionBudget

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (PodDisruptionBudget): OK

401: Unauthorized

get отримати статус вказаного PodDisruptionBudget

HTTP запит

GET /apis/policy/v1/namespaces/{namespace}/poddisruptionbudgets/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя PodDisruptionBudget

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (PodDisruptionBudget): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу PodDisruptionBudget

HTTP запит

GET /apis/policy/v1/namespaces/{namespace}/poddisruptionbudgets

Параметри

Відповідь

200 (PodDisruptionBudgetList): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу PodDisruptionBudget

HTTP запит

GET /apis/policy/v1/poddisruptionbudgets

Параметри

Відповідь

200 (PodDisruptionBudgetList): OK

401: Unauthorized

create ствоерння PodDisruptionBudget

HTTP запит

POST /apis/policy/v1/namespaces/{namespace}/poddisruptionbudgets

Параметри

Відповідь

200 (PodDisruptionBudget): OK

201 (PodDisruptionBudget): Created

202 (PodDisruptionBudget): Accepted

401: Unauthorized

update заміна вказаного PodDisruptionBudget

HTTP запит

PUT /apis/policy/v1/namespaces/{namespace}/poddisruptionbudgets/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя PodDisruptionBudget

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: PodDisruptionBudget, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (PodDisruptionBudget): OK

201 (PodDisruptionBudget): Created

401: Unauthorized

update заміна статусу вказанрого PodDisruptionBudget

HTTP запит

PUT /apis/policy/v1/namespaces/{namespace}/poddisruptionbudgets/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя PodDisruptionBudget

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: PodDisruptionBudget, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (PodDisruptionBudget): OK

201 (PodDisruptionBudget): Created

401: Unauthorized

patch часткове оновлення вказаного PodDisruptionBudget

HTTP запит

PATCH /apis/policy/v1/namespaces/{namespace}/poddisruptionbudgets/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя PodDisruptionBudget

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (PodDisruptionBudget): OK

201 (PodDisruptionBudget): Created

401: Unauthorized

patch часткове оновлення статусу вказаного PodDisruptionBudget

HTTP запит

PATCH /apis/policy/v1/namespaces/{namespace}/poddisruptionbudgets/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя PodDisruptionBudget

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (PodDisruptionBudget): OK

201 (PodDisruptionBudget): Created

401: Unauthorized

delete видалення PodDisruptionBudget

HTTP запит

DELETE /apis/policy/v1/namespaces/{namespace}/poddisruptionbudgets/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя PodDisruptionBudget

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції PodDisruptionBudget

HTTP запит

DELETE /apis/policy/v1/namespaces/{namespace}/poddisruptionbudgets

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

6.5.6.6 - PriorityLevelConfiguration

PriorityLevelConfiguration представляє конфігурацію рівня пріоритету.

apiVersion: flowcontrol.apiserver.k8s.io/v1

import "k8s.io/api/flowcontrol/v1"

PriorityLevelConfiguration

PriorityLevelConfiguration представляє конфігурацію рівня пріоритету.


PriorityLevelConfigurationSpec

PriorityLevelConfigurationSpec визначає конфігурацію рівня пріоритету.


  • exempt (ExemptPriorityLevelConfiguration)

    exempt вказує, як обробляються запити для виняткового рівня пріоритету. Це поле ПОВИННО бути порожнім, якщо type встановлено на "Limited". Це поле МОЖЕ бути не порожнім, якщо type встановлено на "Exempt". Якщо воно порожнє і type встановлено на "Exempt", застосовуються стандартне значення для ExemptPriorityLevelConfiguration.

    ExemptPriorityLevelConfiguration описує настроювані аспекти обробки запитів на виключення. В обов’язковому винятковому об’єкті конфігурації значення в полях тут можуть змінювати авторизовані користувачі, на відміну від решти spec.

    • exempt.lendablePercent (int32)

      lendablePercent вказує частку NominalCL рівня, яка може бути позичена іншими рівнями пріоритету. Значення цього поля повинно бути в діапазоні від 0 до 100 включно, стандартне значення — 0. Кількість місць, які інші рівні можуть позичати у цього рівня, визначається наступним чином:

      LendableCL(i) = round( NominalCL(i) * lendablePercent(i)/100.0 )

    • exempt.nominalConcurrencyShares (int32)

      nominalConcurrencyShares (NCS) вносить свій внесок до обчислення NominalConcurrencyLimit (NominalCL) цього рівня. Це кількість виконавчих місць, які номінально зарезервовані для цього рівня пріоритету. Це НЕ обмежує розподіл з цього рівня, але впливає на інші рівні пріоритету через механізм позичання. Ліміт конкурентності сервера (ServerCL) розподіляється серед всіх рівнів пріоритету пропорційно їх значенням NCS:

      NominalCL(i) = ceil( ServerCL * NCS(i) / sum_ncs ) sum_ncs = sum[priority level k] NCS(k)

      Більші значення означають більший номінальний ліміт конкурентності за рахунок інших рівнів пріоритету. Стандартно це поле має значення 0.

  • limited (LimitedPriorityLevelConfiguration)

    limited вказує, як обробляються запити для обмеженого рівня пріоритету. Це поле повинно бути не порожнім лише тоді, коли type встановлено на "Limited".

    LimitedPriorityLevelConfiguration вказує, як обробляти запити, які підлягають обмеженням. Він вирішує дві проблеми:

    • Які обмеження на запити для цього рівня пріоритету?

    • Що робити з запитами, які перевищують ліміт?

    • limited.borrowingLimitPercent (int32)

      borrowingLimitPercent, якщо вказано, налаштовує ліміт на кількість місць, які цей рівень пріоритету може позичати від інших рівнів пріоритету. Ліміт відомий як BorrowingConcurrencyLimit (BorrowingCL) і є обмеженням на загальну кількість місць, які цей рівень може позичати одночасно. Це поле визначає співвідношення цього ліміту до номінального ліміту конкурентності рівня. Коли це поле не є нульовим, воно має вказувати невідʼємне ціле число, і ліміт обчислюється так:

      BorrowingCL(i) = round( NominalCL(i) * borrowingLimitPercent(i)/100.0 )

      Значення цього поля може перевищувати 100, що означає, що цей рівень пріоритету може позичати більше місць, ніж його власний номінальний ліміт конкурентності (NominalCL). Якщо це поле залишити nil, ліміт фактично нескінченний.

    • limited.lendablePercent (int32)

      lendablePercent вказує частку NominalCL рівня, яка може бути позичена іншими рівнями пріоритету. Значення цього поля повинно бути в діапазоні від 0 до 100 включно, стандартно — 0. Кількість місць, які інші рівні можуть позичати у цього рівня, визначається наступним чином:

      LendableCL(i) = round( NominalCL(i) * lendablePercent(i)/100.0 )

    • limited.limitResponse (LimitResponse)

      limitResponse вказує, як поводитися з запитами, які зараз не можна виконати.

      LimitResponse визначає, як обробляти запити, які зараз не можна виконати.

      • limited.limitResponse.type (string), обовʼязково

        type — "Queue" або "Reject". "Queue" означає, що запити, які зараз не можна виконати, утримуються в черзі, поки їх не буде можливо виконати або досягнуто обмеження черги. "Reject" означає, що запити, які зараз не можна виконати, відхиляються. Обовʼязковщ.

      • limited.limitResponse.queuing (QueuingConfiguration)

        queuing містить параметри конфігурації для черги. Це поле може бути не порожнім лише тоді, коли type встановлено на "Queue".

        QueuingConfiguration містить параметри конфігурації для черги

        • limited.limitResponse.queuing.handSize (int32)

          handSize — невелике позитивне число, яке налаштовує розподіл замовлень до черг. При включенні запита на цьому рівні пріоритету ідентифікатор потоку запиту (пара рядків) хешується, і значення хеша використовується для перетасовки списку черг і роздачі руки розміру, вказаного тут. Запит поміщається в одну з найкоротших черг в цій руці. handSize не повинно бути більшим, ніж queues, і повинно бути значно меншим (щоб кілька важких потоків не насичували більшість черг). Див. документацію для користувачів для більш детальної інформації щодо налаштування цього поля. Стандартне значення — 8.

        • limited.limitResponse.queuing.queueLengthLimit (int32)

          queueLengthLimit — максимальна кількість запитів, які дозволяється очікувати в заданій черзі цього рівня пріоритету одночасно; зайві запити відхиляються. Це значення повинно бути позитивним. Якщо не вказано, воно стандартно буде встановлено на 50.

        • limited.limitResponse.queuing.queues (int32)

          queues — кількість черг для цього рівня пріоритету. Черги існують незалежно в кожному apiserver. Значення повинно бути позитивним. Встановлення його на 1 фактично виключає shufflesharding і, таким чином, робить метод відмінності асоційованих схем потоків неактуальним. Стандартно поле має значення 64.

    • limited.nominalConcurrencyShares (int32)

      nominalConcurrencyShares (NCS) вносить свій внесок до обчислення NominalConcurrencyLimit (NominalCL) цього рівня. Це кількість виконавчих місць, доступних на цьому рівні пріоритету. Це використовується як для запитів, розподілених з цього рівня пріоритету, так і для запитів, розподілених з інших рівнів пріоритету, які позичають місця з цього рівня. Ліміт конкурентності сервера (ServerCL) розподіляється серед обмежених рівнів пріоритету в пропорції до їх значень NCS:

      NominalCL(i) = ceil( ServerCL * NCS(i) / sum_ncs ) sum_ncs = sum[priority level k] NCS(k)

      Більші значення означають більший номінальний ліміт конкурентності, за рахунок інших рівнів пріоритету.

      Якщо не вказано, стандартно це поле має значення 30.

      Встановлення цього поля в нуль підтримує створення «вʼязниці» для цього рівня пріоритету, яка використовується для утримання деяких запитів

  • type (string), required

    type вказує, чи підлягає цей рівень пріоритету обмеженням на виконання запитів. Значення "Exempt" означає, що запити цього рівня пріоритету не підлягають обмеженням (і, отже, ніколи не ставляться в чергу) і не впливають на потужність, доступну для інших рівнів пріоритету. Значення "Limited" означає, що (a) запити цього рівня пріоритету підлягають обмеженням і (b) частина обмеженої потужності сервера доступна виключно для цього рівня пріоритету. Обовʼязкове.

PriorityLevelConfigurationStatus

PriorityLevelConfigurationStatus представляє поточний стан "пріоритету запитів".


  • conditions ([]PriorityLevelConfigurationCondition)

    Patch strategy: обʼєднання за ключем type

    Map: унікальні значення за ключем типу зберігатимуться під час обʼєднання

    conditions - поточний стан "пріоритету запитів".

    PriorityLevelConfigurationCondition визначає стан рівня пріоритету.

    • conditions.lastTransitionTime (Time)

      lastTransitionTime — останній час, коли стан змінився з одного статусу на інший.

      Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

    • conditions.message (string)

      message — це повідомлення, зрозуміле людині та вказує на деталі останнього переходу.

    • conditions.reason (string)

      reason — унікальна причина, одне слово, у CamelCase причина останнього переходу стану.

    • conditions.status (string)

      status — це стан статусу. Може бути True, False, Unknown. Обовʼязково.

    • conditions.type (string)

      type - це тип умови. Обовʼязково.

PriorityLevelConfigurationList

PriorityLevelConfigurationList — це список обʼєктів PriorityLevelConfiguration.


Операції


get отримати вказану PriorityLevelConfiguration

HTTP запит

GET /apis/flowcontrol.apiserver.k8s.io/v1/prioritylevelconfigurations/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя PriorityLevelConfiguration

  • pretty (в запиті): string

    pretty

Відповідь

200 (PriorityLevelConfiguration): OK

401: Unauthorized

get отримати статус вказаної PriorityLevelConfiguration

HTTP запит

GET /apis/flowcontrol.apiserver.k8s.io/v1/prioritylevelconfigurations/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя PriorityLevelConfiguration

  • pretty (в запиті): string

    pretty

Відповідь

200 (PriorityLevelConfiguration): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу PriorityLevelConfiguration

HTTP запит

GET /apis/flowcontrol.apiserver.k8s.io/v1/prioritylevelconfigurations

Параметри

Відповідь

200 (PriorityLevelConfigurationList): OK

401: Unauthorized

create створення PriorityLevelConfiguration

HTTP запит

POST /apis/flowcontrol.apiserver.k8s.io/v1/prioritylevelconfigurations

Параметри

Відповідь

200 (PriorityLevelConfiguration): OK

201 (PriorityLevelConfiguration): Created

202 (PriorityLevelConfiguration): Accepted

401: Unauthorized

update заміна вказаної PriorityLevelConfiguration

HTTP запит

PUT /apis/flowcontrol.apiserver.k8s.io/v1/prioritylevelconfigurations/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя PriorityLevelConfiguration

  • body: PriorityLevelConfiguration, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (PriorityLevelConfiguration): OK

201 (PriorityLevelConfiguration): Created

401: Unauthorized

update заміна статусу вказаної PriorityLevelConfiguration

HTTP запит

PUT /apis/flowcontrol.apiserver.k8s.io/v1/prioritylevelconfigurations/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя PriorityLevelConfiguration

  • body: PriorityLevelConfiguration, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (PriorityLevelConfiguration): OK

201 (PriorityLevelConfiguration): Created

401: Unauthorized

patch часткове оновлення вказаної PriorityLevelConfiguration

HTTP запит

PATCH /apis/flowcontrol.apiserver.k8s.io/v1/prioritylevelconfigurations/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя PriorityLevelConfiguration

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (PriorityLevelConfiguration): OK

201 (PriorityLevelConfiguration): Created

401: Unauthorized

patch часткове оновлення статусу вказаної PriorityLevelConfiguration

HTTP запит

PATCH /apis/flowcontrol.apiserver.k8s.io/v1/prioritylevelconfigurations/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя PriorityLevelConfiguration

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (PriorityLevelConfiguration): OK

201 (PriorityLevelConfiguration): Created

401: Unauthorized

delete видалення PriorityLevelConfiguration

HTTP запит

DELETE /apis/flowcontrol.apiserver.k8s.io/v1/prioritylevelconfigurations/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя PriorityLevelConfiguration

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection вилучення колекції PriorityLevelConfiguration

HTTP запит

DELETE /apis/flowcontrol.apiserver.k8s.io/v1/prioritylevelconfigurations

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

6.5.6.7 - ValidatingAdmissionPolicy

ValidatingAdmissionPolicy описує визначення політики перевірки допуску, яка приймає або відхиляє обʼєкт, не змінюючи його.

apiVersion: admissionregistration.k8s.io/v1

import "k8s.io/api/admissionregistration/v1"

ValidatingAdmissionPolicy

ValidatingAdmissionPolicy описує визначення політики перевірки допуску, яка приймає або відхиляє обʼєкт, не змінюючи його.


  • apiVersion: admissionregistration.k8s.io/v1

  • kind: ValidatingAdmissionPolicy

  • metadata (ObjectMeta)

    Стандартні метадані обʼєкта; Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata.

  • spec (ValidatingAdmissionPolicySpec)

    Специфікація бажаної поведінки ValidatingAdmissionPolicy.

    ValidatingAdmissionPolicySpec — це специфікація бажаної поведінки AdmissionPolicy.

    • spec.auditAnnotations ([]AuditAnnotation)

      Atomic: буде замінено під час обʼєднання

      auditAnnotations містить вирази CEL, які використовуються для створення анотацій аудити для події аудити запиту API. validations і auditAnnotations не можуть бути одночасно порожніми; потрібна щонайменше одна з validations або auditAnnotations.

      AuditAnnotation описує, як створити анотацію аудиту для запиту API.

      • spec.auditAnnotations.key (string), обовʼязково

        key визначає ключ анотації аудиту. Ключі анотацій аудиту ValidatingAdmissionPolicy мають бути унікальними. Ключ повинен бути кваліфікованим імʼям ([A-Za-z0-9][-A-Za-z0-9_.]*) довжиною не більше 63 байт.

        Ключ поєднується з імʼям ресурсу ValidatingAdmissionPolicy для створення ключа анотації аудиту: "{ValidatingAdmissionPolicy name}/{key}".

        Якщо admission webhook використовує те саме імʼя ресурсу, що й цей ValidatingAdmissionPolicy, і той самий ключ анотації аудиту, ключ анотації буде ідентичним. У цьому випадку перша анотація, написана з цим ключем, буде включена в подію аудиту, а всі наступні анотації з тим самим ключем будуть відхилені.

        Обовʼязково.

      • spec.auditAnnotations.valueExpression (string), обовʼязково

        valueExpression представляє вираз, який оцінюється CEL для створення значення анотації аудиту. Вираз має оцінюватися або як рядок, або як значення null. Якщо вираз оцінюється як рядок, анотація аудиту включається зі значенням рядка. Якщо вираз оцінюється як null або порожній рядок, анотація аудиту буде пропущена. valueExpression може бути не довше 5 КБ. Якщо результат valueExpression перевищує 10 КБ, він буде скорочений до 10 КБ.

        Якщо кілька ресурсів ValidatingAdmissionPolicyBinding відповідають запиту API, то valueExpression буде оцінено для кожного звʼязування. Усі унікальні значення, створені valueExpressions, будуть обʼєднані в список, розділений комами.

        Обовʼязково.

    • spec.failurePolicy (string)

      failurePolicy визначає, як обробляти невдачі для admission policy. Невдачі можуть виникати через помилки розбору виразів CEL, помилки перевірки типів, помилки виконання та невірні або неправильно налаштовані визначення політики або звʼязувань.

      Політика вважається недійсною, якщо spec.paramKind посилається на відсутній Kind. Звʼязок вважається недійсним, якщо spec.paramRef.name посилається на нвідсутній ресурс.

      failurePolicy не визначає, як обробляються перевірки, які оцінюються як false.

      Коли failurePolicy встановлено на Fail, ValidatingAdmissionPolicyBinding validationActions визначають, як оцінюються невдачі.

      Допустимі значення: Ignore або Fail. Стандартне значення — Fail.

    • spec.matchConditions ([]MatchCondition)

      Patch strategy: обʼєднання за ключем name

      Map: під час обʼєднання зберігаються унікальні значення за ключем name

      MatchConditions — це список умов, які мають бути виконані для перевірки запиту. Умови збігу фільтрують запити, які вже відповідали правилам, namespaceSelector та objectSelector. Порожній список matchConditions відповідає всім запитам. Максимально допустимо 64 умови перевірки збігів.

      Якщо надається обʼєкт параметрів, до нього можна отримати доступ за допомогою дескриптора params так само як до виразів перевірки.

      Логіка точного збігу така (за порядком):

      1. Якщо БУДЬ-ЯКА умова відповідності оцінюється як FALSE, політика оминається.
      2. Якщо ВСІ умови відповідності оцінюються як TRUE, політика оцінюється.
      3. Якщо будь-яка умова відповідності оцінюється як помилка (але жодна не є FALSE):
        • Якщо failurePolicy=Fail, запит відхиляється
        • Якщо failurePolicy=Ignore, політика пропускається

      MatchCondition представляє умову, яка має бути виконана для надсилання запиту до webhook.

      • spec.matchConditions.expression (string), обовʼязково

        Expression представляє вираз, який буде оцінено CEL. Має оцінюватися як bool. CEL вирази мають доступ до вмісту AdmissionRequest та Authorizer, які знаходяться у змінних CEL:

        'object' — Обʼєкт із вхідного запиту. Значення null для запитів DELETE. 'oldObject' — Наявний обʼєкт. Значення null для запитів CREATE. 'request' — Атрибути запиту на допуск (/pkg/apis/admission/types.go#AdmissionRequest). 'authorizer' — Авторизатор CEL. Може використовуватися для виконання перевірок авторизації для виконавця (користувача або службового облікового запису) запиту. Див. https://pkg.go.dev/k8s.io/apiserver/pkg/cel/library#Authz 'authorizer.requestResource' — Ресурс CEL, створений із 'authorizer' і налаштований із запитним ресурсом. Документація по CEL: https://kubernetes.io/docs/reference/using-api/cel/

        Обовʼязково.

      • spec.matchConditions.name (string), обовʼязково

        Name є ідентифікатором для цієї умови збігу, використовується для стратегічного обʼєднання MatchConditions, а також для надання ідентифікатора для цілей логування. Хороше імʼя має бути описовим для повʼязаної з ним умови. Імʼя повинно бути кваліфікованим імʼям, що складається з алфавітно-цифрових символів, '-', '' або '.', і повинно починатися та закінчуватися алфавітно-цифровим символом (наприклад, 'MyName', або 'my.name', або '123-abc', регулярний вираз, що використовується для перевірки '([A-Za-z0-9][-A-Za-z0-9.]*)?[A-Za-z0-9]') з необовʼязковим префіксом DNS піддомену та '/' (наприклад, 'example.com/MyName')

        Обовʼязково.

    • spec.matchConstraints (MatchResources)

      MatchConstraints вказує, які ресурси ця політика призначена перевіряти. AdmissionPolicy піклується про запит, якщо він відповідає всім Constraints. Однак, щоб запобігти стану нестабільності кластерів, який не можна виправити через API, ValidatingAdmissionPolicy не може відповідати ValidatingAdmissionPolicy та ValidatingAdmissionPolicyBinding. Обовʼязково.

      MatchResources вирішує, чи запускати політику контролю доступу до обʼєкта на основі того, чи відповідає він критеріям відповідності. Правила виключення мають пріоритет над правилами включення (якщо ресурс відповідає обом, він виключається)

      • spec.matchConstraints.excludeResourceRules ([]NamedRuleWithOperations)

        Atomic: буде замінено під час злиття

        ExcludeResourceRules описує, які операції над якими ресурсами/субресурсами не повинні цікавити політику ValidatingAdmissionPolicy. Правила виключення мають пріоритет над правилами включення (якщо ресурс відповідає обом правилам, він виключається)

        NamedRuleWithOperations є кортежем Operations та Resources з ResourceNames.

        • spec.matchConstraints.excludeResourceRules.apiGroups ([]string)

          Atomic: буде замінено під час злиття

          APIGroups — це API групи, до яких належать ресурси. '*' означає всі групи. Якщо присутній симовл '*', довжина масиву повинна бути одиницею. Обовʼязково.

        • spec.matchConstraints.excludeResourceRules.apiVersions ([]string)

          Atomic: буде замінено під час злиття

          APIVersions — це API версії, до яких належать ресурси. '*' означає всі версії. Якщо присутній '*', довжина масиву повинна бути одиницею. Обовʼязково.

        • spec.matchConstraints.excludeResourceRules.operations ([]string)

          Atomic: буде замінено під час злиття

          Operations — це операції, які цікавлять хук допуску — CREATE, UPDATE, DELETE, CONNECT або * для всіх цих операцій та будь-яких майбутніх операцій допуску, які будуть додані. Якщо присутній символ '*', довжина масиву повинна бути одиницею. Обовʼязково.

        • spec.matchConstraints.excludeResourceRules.resourceNames ([]string)

          Atomic: буде замінено під час злиття

          ResourceNames —це необовʼязковий білий список імен, до яких застосовується правило. Порожній набір означає, що дозволено все.

        • spec.matchConstraints.excludeResourceRules.resources ([]string)

          Atomic: буде замінено під час злиття

          Resources — це список ресурсів, до яких застосовується це правило.

          Наприклад: 'pods' означає Podʼи. 'pods/log' означає субресурс логу для Podʼів. '*' означає всі ресурси, але не субресурси. 'pods/*' означає всі субресурси Podʼів. '*/scale' означає всі субресурси масштабування. '*/*' означає всі ресурси та їх субресурси.

          Якщо присутній символ підстановки, правило перевірки забезпечить, що ресурси не перекривають один одного.

          Залежно від обʼєкта, що охоплює, субресурси можуть бути недозволеними. Обовʼязково.

        • spec.matchConstraints.excludeResourceRules.scope (string)

          scope вказує область застосування цього правила. Допустимі значення: "Cluster", "Namespaced" і "*" "Cluster" означає, що тільки ресурси на рівні кластера відповідатимуть цьому правилу. Обʼєкти API простору імен є кластерними. "Namespaced" означає, що тільки ресурси на рівні простору імен відповідатимуть цьому правилу. "*" означає, що немає обмежень щодо області застосування. Субресурси відповідають області свого батьківського ресурсу. Стандартно — "*".

      • spec.matchConstraints.matchPolicy (string)

        matchPolicy визначає, як використовувати список "MatchResources" для відповідності вхідним запитам. Допустимі значення: "Exact" або "Equivalent".

        • Exact: відповідність запиту лише в разі точного збігу з певним правилом. Наприклад, якщо розгортання (deployments) можна змінити через apps/v1, apps/v1beta1 і extensions/v1beta1, але "правила" включають лише apiGroups:["apps"], apiVersions:["v1"], resources: ["deployments"], запит до apps/v1beta1 або extensions/v1beta1 не буде відправлено до ValidatingAdmissionPolicy.

        • Equivalent: відповідність запиту, якщо він змінює ресурс, зазначений у правилах, навіть через іншу групу або версію API. Наприклад, якщо розгортання можна змінити через apps/v1, apps/v1beta1 і extensions/v1beta1, і "правила" включають лише apiGroups:["apps"], apiVersions:["v1"], resources: ["deployments"], запит до apps/v1beta1 або extensions/v1beta1 буде перетворено на apps/v1 і відправлено до ValidatingAdmissionPolicy.

        Стандартно — "Equivalent".

      • spec.matchConstraints.namespaceSelector (LabelSelector)

        NamespaceSelector визначає, чи запускати політику контролю допуску для обʼєкта на основі того, чи відповідає простір імен для цього обʼєкта селектору. Якщо сам обʼєкт є простором імен, перевірка збігу виконується для обʼєкта.metadata.labels. Якщо обʼєкт є іншим кластерним ресурсом, політика ніколи не пропускається.

        Наприклад, щоб запускати вебхук для будь-яких обʼєктів, простір імен яких не повʼязаний з "runlevel" 0 або 1; ви встановите селектор наступним чином:

        "namespaceSelector": {
          "matchExpressions": [
            {
              "key": "runlevel",
              "operator": "NotIn",
              "values": [
                "0",
                "1"
              ]
            }
          ]
        }
        

        Якщо замість цього ви хочете запускати політику лише для будь-яких обʼєктів, простір імен яких повʼязаний з "environment" "prod" або "staging"; ви встановите селектор наступним чином:

        "namespaceSelector": {
          "matchExpressions": [
            {
              "key": "environment",
              "operator": "In",
              "values": [
                "prod",
                "staging"
              ]
            }
          ]
        }
        

        Дивіться https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/ для отримання додаткових прикладів селекторів міток.

        Стандартно — пустий LabelSelector, який відповідає всьому.

      • spec.matchConstraints.objectSelector (LabelSelector)

        ObjectSelector визначає, чи запускати перевірку на основі наявності в обʼєкта відповідних міток. objectSelector оцінюється щодо старого та нового обʼєктів, які будуть відправлені на cel перевірку, і вважається, що є збіг, якщо хоча б один обʼєкт має збіг з селектором. Порожній обʼєкт (oldObject у разі створення або newObject у разі видалення) або обʼєкт, який не може мати міток (наприклад, DeploymentRollback або PodProxyOptions) не вважається таким, що має збіг. Використовуйте селектор обʼєктів тільки якщо вебхук є опціональним, оскільки кінцеві користувачі можуть оминути вебхук допуску, встановивши мітки. Стандартно пустий LabelSelector, який відповідає всьому.

      • spec.matchConstraints.resourceRules ([]NamedRuleWithOperations)

        Atomic: буде замінено під час злиття

        ResourceRules описує, які операції з якими ресурсами/субресурсами відповідають ValidatingAdmissionPolicy. Політика цікавиться операцією, якщо вона відповідає будь-якому Правилу.

        NamedRuleWithOperations є кортежем Operations та Resources з ResourceNames.

        • spec.matchConstraints.resourceRules.apiGroups ([]string)

          Atomic: буде замінено під час злиття

          APIGroups — це групи API, до яких належать ресурси. '*' означає всі групи. Якщо присутній символ '*', довжина списку має бути одиницею. Обовʼязково.

        • spec.matchConstraints.resourceRules.apiVersions ([]string)

          Atomic: буде замінено під час злиття

          APIVersions — це версії API, до яких належать ресурси. '*' означає всі версії. Якщо присутній символ '*', довжина списку має бути одиницею. Обовʼязково.

        • spec.matchConstraints.resourceRules.operations ([]string)

          Atomic: буде замінено під час злиття

          Operations — це операції, які цікавлять вебхук допуску — CREATE, UPDATE, DELETE, CONNECT або * для всіх цих операцій і будь-яких майбутніх операцій допуску, які будуть додані. Якщо присутній символ '*', довжина списку має бути одиницею. Обовʼязково.

        • spec.matchConstraints.resourceRules.resourceNames ([]string)

          Atomic: буде замінено під час злиття

          ResourceNames — це необовʼязковий білий список імен, до яких застосовується правило. Порожній набір означає, що дозволено все.

        • spec.matchConstraints.resourceRules.resources ([]string)

          Atomic: буде замінено під час злиття

          Resources — це список ресурсів, до яких застосовується це правило.

          Наприклад, 'pods' означає Podʼи, 'pods/log' означає субресурс логу Podʼів. '*' означає всі ресурси, але не субресурси. 'pods/*' означає всі субресурси Podʼів. '*/scale' означає всі субресурси масштабування. '*/*' означає всі ресурси та їх субресурси.

          Якщо присутній універсальний символ, правило валідації забезпечить відсутність перекриття ресурсів.

          Залежно від навколишнього обʼєкта, субресурси можуть бути недопустимими. Обовʼязково.

        • spec.matchConstraints.resourceRules.scope (string)

          scope визначає область застосування цього правила. Допустимі значення — "Cluster", "Namespaced" та "*" "Cluster" означає, що правило буде застосовано тільки до ресурсів на рівні кластера. API обʼєкти простору імен є ресурсами на рівні кластера. "Namespaced" означає, що правило буде застосовано тільки до ресурсів простору імен. "*" означає, що немає обмежень на область застосування. Субресурси відповідають області застосування свого батьківського ресурсу. Стандартне значення — "*".

    • spec.paramKind (ParamKind)

      ParamKind визначає тип ресурсів, що використовуються для параметризації цієї політики. Якщо відсутній, то для цієї політики немає параметрів і змінна param CEL не буде надана для виразів перевірки. Якщо ParamKind посилається на неіснуючий тип, ця політика налаштована неправильно і застосовується FailurePolicy. Якщо paramKind вказано, але paramRef не встановлено в ValidatingAdmissionPolicyBinding, змінна params буде null.

      ParamKind є кортежем Group, Kind і Version.

      • spec.paramKind.apiVersion (string)

        APIVersion — це версія групи API, до якої належать ресурси. У форматі "group/version". Обовʼязково.

      • spec.paramKind.kind (string)

        Kind — це тип API, до якого належать ресурси. Обовʼязково.

    • spec.validations ([]Validation)

      Atomic: буде замінено під час злиття

      Validations містять CEL-вирази, які використовуються для застосування перевірки. Validations і AuditAnnotations не можуть обидва бути порожніми; потрібен мінімум щось одне з Validations або AuditAnnotations.

      Validation визначає CEL-вираз, який використовується для перевірки.

      • spec.validations.expression (string), обовʼязково

        Expression представляє вираз, який буде оцінюватися CEL. ref: https://github.com/google/cel-spec CEL-вирази мають доступ до вмісту запиту/відповіді API, організованих у змінні CEL, а також деякі інші корисні змінні:

        • 'object' — Обʼєкт з вхідного запиту. Значення null для запитів DELETE.
        • 'oldObject' — Наявний обʼєкт. Значення null для запитів CREATE.
        • 'request' — Атрибути запиту API(ref).
        • 'params' — Параметр ресурсу, на який посилається перевірка політики. Заповнюється лише, якщо політика має ParamKind.
        • 'namespaceObject' — Обʼєкт простору імен, до якого належить вхідний обʼєкт. Значення null для ресурсів на рівні кластера.
        • 'variables' - Map змінних, від їх назви до їхнього ледачого (lazily) оцінюваного значення. Наприклад, змінна з назвою 'foo' може бути доступна як 'variables.foo'.
        • 'authorizer' — CEL Authorizer. Може використовуватися для виконання перевірок авторизації для виконавця (користувача або облікового запису служби) запиту. Див. https://pkg.go.dev/k8s.io/apiserver/pkg/cel/library#Authz
        • 'authorizer.requestResource' — CEL ResourceCheck, створений з 'authorizer' та налаштований для ресурсу запиту.

        apiVersion, kind, metadata.name і metadata.generateName завжди доступні з кореня обʼєкта. Інші властивості метаданих недоступні.

        Доступні лише імена властивостей у формі [a-zA-Z_.-/][a-zA-Z0-9_.-/]*. Доступні імена властивостей екрануються згідно з наступними правилами, коли доступні у виразі:

        • '__' екранується як 'underscores'

        • '.' екранується як 'dot'

        • '-' екранується як 'dash'

        • '/' екранується як 'slash'

        • Імена властивостей, що точно збігаються з CEL РЕЗЕРВОВАНИМИ ключовими словами, екрануються як '{keyword}'. Ключові слова включають: "true", "false", "null", "in", "as", "break", "const", "continue", "else", "for", "function", "if", "import", "let", "loop", "package", "namespace", "return". Приклади:

        • Вираз, що звертається до властивості з назвою "namespace": {"Expression": "object.namespace > 0"}

        • Вираз, що звертається до властивості з назвою "x-prop": {"Expression": "object.x__dash__prop > 0"}

        • Вираз, що звертається до властивості з назвою "redact__d": {"Expression": "object.redact__underscores__d > 0"}

        Рівність масивів із типом списку 'set' або 'map' ігнорує порядок елементів, тобто [1, 2] == [2, 1]. Конкатенація масивів із типом списку x-kubernetes використовує семантику типу списку:

        • 'set': X + Y виконує обʼєднання, де позиції масиву всіх елементів у X зберігаються, а елементи в Y, що не перетинаються, додаються зі збереженням їх часткового порядку.
        • 'map': X + Y виконує злиття, де позиції масиву всіх ключів у X зберігаються, але значення замінюються значеннями з Y, коли множини ключів X та Y перетинаються. Елементи в Y з ключами, що не перетинаються з ключами, що не перетинаються, додаються зі збереженням їх часткового порядку. Обовʼязково.
      • spec.validations.message (string)

        Message представляє повідомлення, що відображається при невдалій перевірці. Повідомлення обовʼязкове, якщо Expression містить розриви рядка. Повідомлення не повинно містити розриви рядка. Якщо не вказано, повідомлення — "failed rule: {Rule}". Наприклад, "must be a URL with the host matching spec.host" Якщо Expression містить розриви рядка, повідомлення обовʼязкове. Повідомлення не повинно містити розриви рядка. Якщо не встановлено, повідомлення — "failed Expression: {Expression}".

      • spec.validations.messageExpression (string)

        messageExpression оголошує CEL-вираз, який оцінюється як повідомлення про невдачу перевірки, що повертається, коли це правило не виконується. Оскільки messageExpression використовується як повідомлення про невдачу, воно повинно оцінюватися як рядок. Якщо і message, і messageExpression присутні у перевірці, то messageExpression буде використано, якщо перевірка не вдалася. Якщо messageExpression призводить до помилки під час виконання, помилка записується в лог, і повідомлення про невдачу перевірки створюється так, ніби поле messageExpression не було встановлено. Якщо messageExpression оцінюється як порожній рядок, рядок з лише пробілами або рядок, що містить розриви рядка, то повідомлення про невдачу перевірки також створюється так, ніби поле messageExpression не було встановлено, і факт того, що messageExpression створило порожній рядок/рядок з лише пробілами/рядок з розривами рядка, буде записано в лог. messageExpression має доступ до всіх тих самих змінних, що і expression, за винятком 'authorizer' та 'authorizer.requestResource'. Приклад: "object.x must be less than max ("+string(params.max)+")"

      • spec.validations.reason (string)

        Reason представляє машинно-зчитуваний опис того, чому ця перевірка не вдалася. Якщо це перша перевірка в списку, що не вдалася, ця причина, а також відповідний код відповіді HTTP, використовуються у відповіді HTTP клієнту. Наразі підтримувані причини: "Unauthorized", "Forbidden", "Invalid", "RequestEntityTooLarge". Якщо не встановлено, використовується StatusReasonInvalid у відповіді клієнту.

    • spec.variables ([]Variable)

      Patch strategy: злиття по ключу name

      Map: унікальні значення по ключу name будуть зберігатися під час злиття

      Variables містять визначення змінних, які можна використовувати у складі інших виразів. Кожна змінна визначена як іменований CEL-вираз. Змінні, визначені тут, будуть доступні у variables в інших виразах політики, за винятком MatchConditions, оскільки MatchConditions оцінюються перед рештою політики.

      Вираз змінної може посилатися на інші змінні, визначені раніше у списку, але не на ті, що стоять після неї. Таким чином, змінні мають бути відсортовані за порядком першої появи та ациклічно.

      Variable — це визначення змінної, яка використовується для складання. Змінна визначається як іменований вираз.

      • spec.variables.expression (string), обовʼязково

        Expression — це вираз, який буде оцінений як значення змінної. CEL-вираз має доступ до тих самих ідентифікаторів, що і CEL-вирази в Validation.

      • spec.variables.name (string), обовʼязково

        Name — це назва змінної. Назва повинна бути дійсним ідентифікатором CEL і унікальною серед усіх змінних. Змінна може бути доступна в інших виразах через variables Наприклад, якщо name є "foo", змінна буде доступна як variables.foo.

  • status (ValidatingAdmissionPolicyStatus)

    Статус ValidatingAdmissionPolicy, включаючи попередження, які корисні для визначення, чи працює політика відповідно до очікувань. Заповнюється системою. Тільки для читання.

    ValidatingAdmissionPolicyStatus представляє статус політики перевірки допуску.

    • status.conditions ([]Condition)

      Map: унікальні значення по ключу type будуть зберігатися під час злиття

      Стани представляють останні доступні спостереження поточного стану політики.

      Condition містить деталі одного аспекту поточного стану цього API-ресурсу.

      • status.conditions.lastTransitionTime (Time), обовʼязково

        lastTransitionTime — це останній час, коли стан перейшов з одного стану в інший. Це має бути, коли змінився основний стан. Якщо це невідомо, то прийнятно використовувати час, коли змінилося поле API.

        Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

      • status.conditions.message (string), обовʼязково

        message — це повідомлення зрозуміле людині, яке вказує деталі про зміну стану. Воно може бути порожній рядок.

      • status.conditions.reason (string), обовʼязково

        reason містить програмний ідентифікатор, що вказує на причину останньої зміни стану. Виробники конкретних типів станів можуть визначити очікувані значення та значення для цього поля, а також чи вважаються значення гарантованим API. Значення має бути рядком у форматі CamelCase. Це поле не може бути порожнім.

      • status.conditions.status (string), обовʼязково

        статус стану, один з True, False, Unknown.

      • status.conditions.type (string), обовʼязково

        тип стану у форматі CamelCase або у форматі foo.example.com/CamelCase.

      • status.conditions.observedGeneration (int64)

        observedGeneration представляє .metadata.generation, на основі якого було встановлено стан. Наприклад, якщо .metadata.generation зараз 12, але .status.conditions[x].observedGeneration - 9, стан застарів відносно поточного стану екземпляра.

    • status.observedGeneration (int64)

      Покоління, яке спостерігалося контролером.

    • status.typeChecking (TypeChecking)

      Результати перевірки типу для кожного виразу. Наявність цього поля вказує на завершення перевірки типу.

      TypeChecking містить результати перевірки типу виразів у ValidatingAdmissionPolicy

      • status.typeChecking.expressionWarnings ([]ExpressionWarning)

        Atomic: буде замінено під час злиття

        Попередження перевірки типу для кожного виразу.

        ExpressionWarning — це інформація про попередження, що стосується конкретного виразу.

        • status.typeChecking.expressionWarnings.fieldRef (string), обовʼязково

          Шлях до поля, що посилається на вираз. Наприклад, посилання на вираз першого елемента перевірок є "spec.validations[0].expression".

        • status.typeChecking.expressionWarnings.warning (string), обовʼязково

          Вміст інформації про попередження перевірки типу у формі, зручною для читання людиною. Кожен рядок попередження містить тип, за яким перевірено вираз, а потім помилку перевірки типу від компілятора.

ValidatingAdmissionPolicyList

ValidatingAdmissionPolicyList - це список ValidatingAdmissionPolicy.


ValidatingAdmissionPolicyBinding

ValidatingAdmissionPolicyBinding повʼязує ValidatingAdmissionPolicy з параметризованими ресурсами. ValidatingAdmissionPolicyBinding та параметризовані CRD разом визначають, як адміністратори кластерів налаштовують політики для кластерів.

Для даного запиту на допуск кожне привʼязування спричиняє оцінку його політики N разів, де N дорівнює 1 для політик/привʼязок, які не використовують параметри, або кількість параметрів, обраних привʼязкою.

CEL вирази політики повинні мати обчислену вартість CEL нижче максимально допустимого бюджету CEL. Кожна оцінка політики отримує незалежний бюджет CEL. Додавання/видалення політик, привʼязок або параметрів не може впливати на те, чи знаходиться комбінація (policy, binding, param) у своєму бюджеті CEL.


  • apiVersion (string)

    APIVersion визначає версійну схему цього представлення обʼєкта. Сервери повинні перетворювати визнані схеми на останнє внутрішнє значення і можуть відхиляти невідомі значення. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources.

  • kind (string)

    Kind — це рядкове значення, що представляє REST ресурс, який представляє цей обʼєкт. Сервери можуть визначити це з точки доступу, до якої клієнт надсилає запити. Не можоже бути оновлене. У CamelCase. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds.

  • metadata (ObjectMeta)

    Стандартні метадані обʼєкта. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata.

  • spec (ValidatingAdmissionPolicyBindingSpec)

    Специфікація бажаної поведінки ValidatingAdmissionPolicyBinding.

    ValidatingAdmissionPolicyBindingSpec - це специфікація ValidatingAdmissionPolicyBinding.

    • spec.matchResources (MatchResources)

      MatchResources оголошує, які ресурси відповідають цій привʼязці і будуть перевірені нею. Зауважте, що це перетинається з matchConstraints політики, тому лише запити, які відповідають політиці, можуть бути обрані. Якщо це поле не встановлено, всі ресурси, які відповідають політиці, перевіряються цією привʼязкою. Якщо resourceRules не встановлено, це не обмежує відповідність ресурсу. Якщо ресурс відповідає іншим полям цього обʼєкта, він буде перевірений. Зауважте, що це відрізняється від matchConstraints ValidatingAdmissionPolicy, де resourceRules є обовʼязковими.

      MatchResources вирішує, чи запускати політику контролю допуску на обʼєкті на основі відповідності критеріям відповідності. Правила виключення мають пріоритет над правилами включення (якщо ресурс відповідає обом, він виключається).

      • spec.matchResources.excludeResourceRules ([]NamedRuleWithOperations)

        Atomic: буде замінено під час обʼєднання

        ExcludeResourceRules описує, які операції на яких ресурсах/субресурсах ValidatingAdmissionPolicy не повинна враховувати. Правила виключення мають пріоритет над правилами включення (якщо ресурс відповідає обом, він виключається).

        NamedRuleWithOperations є кортежем Operations та Resources з ResourceNames.

        • spec.matchResources.excludeResourceRules.apiGroups ([]string)

          Atomic: буде замінено під час обʼєднання

          APIGroups — це групи API, до яких належать ресурси. '*' означає всі групи. Якщо присутній символ '*', довжина списку має бути одиницею. Обовʼязково.

        • spec.matchResources.excludeResourceRules.apiVersions ([]string)

          Atomic: буде замінено під час обʼєднання

          APIVersions — це версії API, до яких належать ресурси. '*' означає всі версії. Якщо присутній символ '*', довжина списку має бути одиницею. Обовʼязково.

        • spec.matchResources.excludeResourceRules.operations ([]string)

          Atomic: буде замінено під час обʼєднання

          Operations — це операції, які цікавлять вебхук допуску — CREATE, UPDATE, DELETE, CONNECT або * для всіх цих операцій і будь-яких майбутніх операцій допуску, які будуть додані. Якщо присутній символ '*', довжина списку має бути одиницею. Обовʼязково.

        • spec.matchResources.excludeResourceRules.resourceNames ([]string)

          Atomic: буде замінено під час обʼєднання

          ResourceNames — це необовʼязковий білий список імен, до яких застосовується правило. Порожній набір означає, що дозволено все.

        • spec.matchResources.excludeResourceRules.resources ([]string)

          Atomic: буде замінено під час обʼєднання

          Resources — це список ресурсів, до яких застосовується це правило.

          Наприклад, 'pods' означає Podʼи, 'pods/log' означає субресурс логу Podʼів. '*' означає всі ресурси, але не субресурси. 'pods/*' означає всі субресурси Podʼів. '*/scale' означає всі субресурси масштабування. '*/*' означає всі ресурси та їх субресурси.

          Якщо присутній універсальний символ, правило валідації забезпечить відсутність перекриття ресурсів.

          Залежно від навколишнього обʼєкта, субресурси можуть бути недопустимими. Обовʼязково.

        • spec.matchResources.excludeResourceRules.scope (string)

          scope визначає сферу дії цього правила. Дійсні значення — "Cluster", "Namespaced" та "*". "Cluster" означає, що тільки ресурси кластерного рівня відповідатимуть цьому правилу. Обʼєкти API namespace є ресурсами кластерного рівня. "Namespaced" означає, що тільки ресурси namespace відповідатимуть цьому правилу. "*" означає, що немає обмежень на сферу дії. Субресурси відповідають сфері дії їхнього батьківського ресурсу. Стандартне значння — "*".

      • spec.matchResources.matchPolicy (string)

        matchPolicy визначає, як список "MatchResources" використовується для пошуку збігів з вхідними запитами. Дозволені значення — "Exact" або "Equivalent".

        • Exact: відповідати запиту тільки, якщо він точно відповідає зазначеному правилу. Наприклад, якщо розгортання (deployments) можна змінювати через apps/v1, apps/v1beta1 та extensions/v1beta1, але "rules" включали тільки apiGroups:["apps"], apiVersions:["v1"], resources: ["deployments"], запит на apps/v1beta1 або extensions/v1beta1 не буде надіслано до ValidatingAdmissionPolicy.

        • Equivalent: відповідати запиту, якщо він змінює ресурс, зазначений у правилах, навіть через іншу групу або версію API. Наприклад, якщо розгортання (deployments) можна змінювати через apps/v1, apps/v1beta1 та extensions/v1beta1, і "rules" включали тільки apiGroups:["apps"], apiVersions:["v1"], resources: ["deployments"], запит на apps/v1beta1 або extensions/v1beta1 буде перетворено на apps/v1 і надіслано до ValidatingAdmissionPolicy.

        Стандартно — "Equivalent".

      • spec.matchResources.namespaceSelector (LabelSelector)

        NamespaceSelector визначає, чи застосовувати політику контролю доступу до об’єкта на основі відповідності простору імен цього об’єкта селектору. Якщо об’єкт сам по собі є простором імен, відповідність перевіряється по обʼєкту.metadata.labels. Якщо об’єкт є іншим ресурсом на рівні кластера, він ніколи не пропускає політику.

        Наприклад, щоб запустити вебхук для будь-яких об’єктів, простір імен яких не пов’язаний з "runlevel" 0 або 1, необхідно налаштувати селектор наступним чином:

        "namespaceSelector": {
          "matchExpressions": [
            {
              "key": "runlevel",
              "operator": "NotIn",
              "values": [
                "0",
                "1"
              ]
            }
          ]
        }
        

        Якщо натомість ви хочете застосовувати політику лише для об’єктів, простір імен яких пов’язаний з "environment" "prod" або "staging", необхідно налаштувати селектор наступним чином:

        "namespaceSelector": {
          "matchExpressions": [
            {
              "key": "environment",
              "operator": "In",
              "values": [
                "prod",
                "staging"
              ]
            }
          ]
        }
        

        Дивіться https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/ для отримання додаткових прикладів селекторів міток.

        Стандартно використовується порожній LabelSelector, який відповідає всьому.

      • spec.matchResources.objectSelector (LabelSelector)

        ObjectSelector визначає, чи потрібно виконувати перевірку на основі відповідності міток об’єкта. objectSelector оцінюється як для oldObject, так і для newObject, які будуть надіслані на перевірку cel, і вважається відповідним, якщо будь-який об’єкт відповідає селектору. Null обʼєкт (oldObject у випадку створення або newObject у випадку видалення) або об’єкт, який не може мати міток (наприклад, DeploymentRollback або PodProxyOptions), не вважається відповідним. Використовуйте селектор об’єктів, тільки якщо вебхук є опціональним, оскільки кінцеві користувачі можуть оминути вебхук допуску, встановивши мітки. Стандартно використовується порожній LabelSelector, який відповідає всьому.

      • spec.matchResources.resourceRules ([]NamedRuleWithOperations)

        Atomic: буде замінено під час злиття

        ResourceRules описує, які операції на яких ресурсах/субресурсах відповідають ValidatingAdmissionPolicy. Політика враховує операцію, якщо вона відповідає будь-якому правилу.

        NamedRuleWithOperations є кортежем Operations та Resources з ResourceNames.

        • spec.matchResources.resourceRules.apiGroups ([]string)

          Atomic: буде замінено під час злиття

          APIGroups — це групи API, до яких належать ресурси. '*' означає всі групи. Якщо присутній символ '*', довжина списку має бути одиницею. Обовʼязково.

        • spec.matchResources.resourceRules.apiVersions ([]string)

          Atomic: буде замінено під час злиття

          APIVersions — це версії API, до яких належать ресурси. '*' означає всі версії. Якщо присутній символ '*', довжина списку має бути одиницею. Обовʼязково.

        • spec.matchResources.resourceRules.operations ([]string)

          Atomic: буде замінено під час злиття

          Operations — це операції, які цікавлять вебхук допуску — CREATE, UPDATE, DELETE, CONNECT або * для всіх цих операцій і будь-яких майбутніх операцій допуску, які будуть додані. Якщо присутній символ '*', довжина списку має бути одиницею. Обовʼязково.

        • spec.matchResources.resourceRules.resourceNames ([]string)

          Atomic: буде замінено під час злиття

          ResourceNames — це необовʼязковий білий список імен, до яких застосовується правило. Порожній набір означає, що все дозволено.

        • spec.matchResources.resourceRules.resources ([]string)

          Atomic: буде замінено під час злиття

          Resources — це список ресурсів, до яких застосовується це правило.

        Наприклад, 'pods' означає Podʼи, 'pods/log' означає субресурс логу Podʼів. '*' означає всі ресурси, але не субресурси. 'pods/*' означає всі субресурси Podʼів. '*/scale' означає всі субресурси масштабування. '*/*' означає всі ресурси та їх субресурси.

        Якщо присутній універсальний символ, правило валідації забезпечить відсутність перекриття ресурсів.

        Залежно від навколишнього обʼєкта, субресурси можуть бути недопустимими. Обовʼязково.

        • spec.matchResources.resourceRules.scope (string)

          scope визначає область застосування цього правила. Допустимі значення — "Cluster", "Namespaced" та "*". "Cluster" означає, що правило буде застосовано тільки до ресурсів на рівні кластера. API обʼєкти простору імен є ресурсами на рівні кластера. "Namespaced" означає, що правило буде застосовано тільки до ресурсів простору імен. "*" означає, що немає обмежень на область застосування. Субресурси відповідають області застосування свого батьківського ресурсу. Стандартне значення — "*".

    • spec.paramRef (ParamRef)

      paramRef вказує на ресурс параметра, який використовується для налаштування політики контролю допуску. Він повинен вказувати на ресурс типу, визначеного в ParamKind прив’язаної ValidatingAdmissionPolicy. Якщо політика вказує ParamKind, а ресурс, на який посилається ParamRef, не існує, ця привʼязка вважається неправильно налаштованою, і застосовується FailurePolicy ValidatingAdmissionPolicy. Якщо політика не вказує ParamKind, це поле ігнорується, і правила оцінюються без параметра.

      ParamRef описує, як знайти параметри, які будуть використовуватися як вхідні дані для виразів правил, що застосовуються привʼязкою політики.

      • spec.paramRef.name (string)

        name — це імʼя ресурсу, на який посилаються.

        Одне з name або selector повинно бути встановлено, але name і selector є взаємовиключними властивостями. Якщо одне встановлено, інше повинно бути відключено.

        Один параметр, який використовується для всіх запитів на допуск, можна налаштувати, встановивши поле name, залишивши selector порожнім і встановивши простір імен, якщо paramKind має простір імен.

      • spec.paramRef.namespace (string)

        namespace — це простір імен ресурсу, на який посилаються. Дозволяє обмежити пошук параметрів певним простором імен. Застосовується як до полів name, так і до selector.

        Можна використовувати параметр для кожного простору імен, вказавши простір імен для paramKind у політиці та залишивши це поле порожнім.

        • Якщо paramKind є кластерним, це поле МАЄ бути не встановленим. Встановлення цього поля призведе до помилки конфігурації.

        • Якщо paramKind має простір імен, використовується простір імен обʼєкта, який оцінюється на допуск, коли це поле залишено порожнім. Слідкуйте за тим, що якщо це поле залишити порожнім, привʼязка не повинна відповідати жодним ресурсам на рівні кластера, що призведе до помилки.

      • spec.paramRef.parameterNotFoundAction (string)

        parameterNotFoundAction контролює поведінку привʼязки, коли ресурс існує, і імʼя або селектор є дійсними, але немає параметрів, які відповідають привʼязці. Якщо значення встановлено на Allow, тоді відсутність відповідних параметрів буде розцінюватися як успішна валідація привʼязкою. Якщо встановлено Deny, то відсутність відповідних параметрів буде підпадати під дію failurePolicy політики.

        Допустимі значення: Allow або Deny.

        Обовʼязково

      • spec.paramRef.selector (LabelSelector)

        selector може бути використаний для відповідності кільком обʼєктам параметрів на основі їх міток. Поставте selector: {} для відповідності всім ресурсам ParamKind.

        Якщо знайдено кілька параметрів, всі вони оцінюються за допомогою виразів політики, і результати об’єднуються логічним І.

        Одне з name або selector повинно бути встановлено, але name і selector є взаємовиключними властивостями. Якщо одне встановлено, інше повинно бути відключено.

    • spec.policyName (string)

      PolicyName посилається на ім’я ValidatingAdmissionPolicy, до якої прив’язується ValidatingAdmissionPolicyBinding. Якщо вказаний ресурс не існує, ця прив’язка вважається недійсною і буде ігнорована. Обовʼязково.

    • spec.validationActions ([]string)

      Set: під час злиття зберігатимуться унікальні значення

      validationActions визначає, як виконуються перевірки ValidatingAdmissionPolicy, на яку посилається ValidatingAdmissionPolicyBinding. Якщо перевірка оцінюється як хибна, вона завжди виконується відповідно до цих дій.

      Збої, визначені FailurePolicy ValidatingAdmissionPolicy, виконуються відповідно до цих дій лише у випадку, якщо FailurePolicy встановлено на Fail, інакше збої ігноруються. Це включає помилки компіляції, помилки під час виконання та неправильні конфігурації політики.

      validationActions оголошується як набір значень дій. Порядок не має значення. validationActions не можуть містити дублікатів одного й того самого значення дії.

      Підтримувані значення дій:

      "Deny" означає, що збій перевірки призводить до відхилення запиту.

      "Warn" означає, що збій перевірки повідомляється клієнту запиту в HTTP-заголовках попередження з кодом попередження 299. Попередження можуть надсилатися як для дозволених, так і для відхилених відповідей на допуск.

      "Audit" означає, що збій перевірки включається до опублікованої події аудиту для запиту. Подія аудиту міститиме анотацію аудиту validation.policy.admission.k8s.io/validation_failure зі значенням, що містить деталі збоїв перевірки, відформатовані як JSON-список об’єктів, кожен з яких має наступні поля:

      • message: Рядок повідомлення про збій перевірки
      • policy: Ім’я ресурсу ValidatingAdmissionPolicy
      • binding: Ім’я ресурсу ValidatingAdmissionPolicyBinding
      • expressionIndex: Індекс збоїв перевірки в ValidatingAdmissionPolicy
      • validationActions: Дії примусового виконання для збою перевірки Приклад анотації аудиту: "validation.policy.admission.k8s.io/validation_failure": "[{"message": "Invalid value", {"policy": "policy.example.com", {"binding": "policybinding.example.com", {"expressionIndex": "1", {"validationActions": ["Audit"]}]"

      Клієнти повинні очікувати обробки додаткових значень, ігноруючи будь-які значення, які не розпізнаються.

      "Deny" і "Warn" не можуть використовуватися разом, оскільки ця комбінація непотрібно дублює збій перевірки як у тілі відповіді API, так і в HTTP-заголовках попередження.

      Обовʼязково.

Операції


get отримати вказану ValidatingAdmissionPolicy

HTTP запит

GET /apis/admissionregistration.k8s.io/v1/validatingadmissionpolicies/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ValidatingAdmissionPolicy

  • pretty (в запиті): string

    pretty

Відповідь

200 (ValidatingAdmissionPolicy): OK

401: Unauthorized

get отримати статус вказаної ValidatingAdmissionPolicy

HTTP запит

GET /apis/admissionregistration.k8s.io/v1/validatingadmissionpolicies/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ValidatingAdmissionPolicy

  • pretty (в запиті): string

    pretty

Відповідь

200 (ValidatingAdmissionPolicy): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу ValidatingAdmissionPolicy

HTTP запит

GET /apis/admissionregistration.k8s.io/v1/validatingadmissionpolicies

Параметри

Відповідь

200 (ValidatingAdmissionPolicyList): OK

401: Unauthorized

create створення ValidatingAdmissionPolicy

HTTP запит

POST /apis/admissionregistration.k8s.io/v1/validatingadmissionpolicies

Параметри

Відповідь

200 (ValidatingAdmissionPolicy): OK

201 (ValidatingAdmissionPolicy): Created

202 (ValidatingAdmissionPolicy): Accepted

401: Unauthorized

update заміна вказаної ValidatingAdmissionPolicy

HTTP запит

PUT /apis/admissionregistration.k8s.io/v1/validatingadmissionpolicies/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ValidatingAdmissionPolicy

  • body: ValidatingAdmissionPolicy, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (ValidatingAdmissionPolicy): OK

201 (ValidatingAdmissionPolicy): Created

401: Unauthorized

update заміна статусу вказаної ValidatingAdmissionPolicy

HTTP запит

PUT /apis/admissionregistration.k8s.io/v1/validatingadmissionpolicies/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ValidatingAdmissionPolicy

  • body: ValidatingAdmissionPolicy, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (ValidatingAdmissionPolicy): OK

201 (ValidatingAdmissionPolicy): Created

401: Unauthorized

patch часткове оновлення вказаної ValidatingAdmissionPolicy

HTTP запит

PATCH /apis/admissionregistration.k8s.io/v1/validatingadmissionpolicies/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ValidatingAdmissionPolicy

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (ValidatingAdmissionPolicy): OK

201 (ValidatingAdmissionPolicy): Created

401: Unauthorized

patch часткове оновдення статусу вказанох ValidatingAdmissionPolicy

HTTP запит

PATCH /apis/admissionregistration.k8s.io/v1/validatingadmissionpolicies/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ValidatingAdmissionPolicy

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (ValidatingAdmissionPolicy): OK

201 (ValidatingAdmissionPolicy): Created

401: Unauthorized

delete видалення ValidatingAdmissionPolicy

HTTP запит

DELETE /apis/admissionregistration.k8s.io/v1/validatingadmissionpolicies/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ValidatingAdmissionPolicy

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції ValidatingAdmissionPolicy

HTTP запит

DELETE /apis/admissionregistration.k8s.io/v1/validatingadmissionpolicies

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

6.5.6.8 - ValidatingAdmissionPolicyBinding

ValidatingAdmissionPolicyBinding звʼязує ValidatingAdmissionPolicy з параметризованими ресурсами.

apiVersion: admissionregistration.k8s.io/v1

import "k8s.io/api/admissionregistration/v1"

ValidatingAdmissionPolicyBinding

ValidatingAdmissionPolicyBinding повʼязує ValidatingAdmissionPolicy з параметризованими ресурсами. ValidatingAdmissionPolicyBinding і параметризовані CRD разом визначають, як адміністраторам кластерів налаштовувати політики для кластерів.

Для кожного запиту на допуск кожне звʼязування спричинить оцінку його політики N разів, де N дорівнює 1 для політик/звʼязувань, які не використовують параметри, в іншому випадку N є кількість параметрів, вибраних звʼязуванням.

CEL вирази політики повинні мати обчислену вартість CEL нижчу за максимальний бюджет CEL. Кожна оцінка політики отримує незалежний бюджет витрат CEL. Додавання/видалення політик, звʼязувань або параметрів не повинно впливати на те, чи є дана комбінація (політика, звʼязування, параметр) у межах свого бюджету CEL.


  • apiVersion: admissionregistration.k8s.io/v1

  • kind: ValidatingAdmissionPolicyBinding

  • metadata (ObjectMeta)

    Стандартний обʼєкт метаданих; Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata.

  • spec (ValidatingAdmissionPolicyBindingSpec)

    Визначення бажаної поведінки ValidatingAdmissionPolicyBinding.

    ValidatingAdmissionPolicyBindingSpec є специфікацією ValidatingAdmissionPolicyBinding.

    • spec.matchResources (MatchResources)

      MatchResources декларує, які ресурси відповідають цьому звʼязуванню і будуть перевірені ним. Зверніть увагу, що це перетинається з matchConstraints політики, тому тільки запити, які відповідають політиці, можуть бути вибрані цим звʼязуванням. Якщо це не задано, всі ресурси, що відповідають політиці, будуть перевірені цим звʼязуванням.

      Коли resourceRules не задано, це не обмежує відповідність ресурсів. Якщо ресурс відповідає іншим полям цього обʼєкта, він буде перевірений. Зверніть увагу, що це відрізняється від matchConstraints ValidatingAdmissionPolicy, де resourceRules є обовʼязковими.

      MatchResources визначає, чи слід застосовувати політику контролю доступу до обʼєкта на основі того, чи відповідає він критеріям відповідності. Правила виключення мають перевагу над правилами включення (якщо ресурс відповідає обом, він буде виключений).

      • spec.matchResources.excludeResourceRules ([]NamedRuleWithOperations)

        Atomic: буде замінено під час злиття

        ExcludeResourceRules описує, які операції над якими ресурсами/підресурсами ValidatingAdmissionPolicy не повинна враховувати. Правила виключення мають перевагу над правилами включення (якщо ресурс відповідає обом, він буде виключений).

        NamedRuleWithOperations є кортежем Operations та Resources з ResourceNames.

        • spec.matchResources.excludeResourceRules.apiGroups ([]string)

          Atomic: буде замінено під час злиття

          APIGroups — це групи API, до яких належать ресурси. '*' — це всі групи. Якщо '*' присутній, довжина фрагменту повинна бути одиницею. Обовʼязковий параметр.

        • spec.matchResources.excludeResourceRules.apiVersions ([]string)

          Atomic: буде замінено під час злиття

          APIVersions — це версії API, до яких належать ресурси. '*' — всі версії. Якщо '*' присутній, довжина фрагменту повинна бути одиницею. Обовʼязковий параметр.

        • spec.matchResources.excludeResourceRules.operations ([]string)

          Atomic: буде замінено під час злиття

          Operations — це операції, які цікавлять хук допуску - CREATE, UPDATE, DELETE, CONNECT або * для всіх цих операцій і будь-яких майбутніх операцій допуску, які будуть додані. Якщо присутній символ "*", довжина фрагмента повинна бути одиницею. Обовʼязково.

        • spec.matchResources.excludeResourceRules.resourceNames ([]string)

          Atomic: буде замінено під час злиття

          ResourceNames — необовʼязковий білий список імен, до яких застосовується правило. Порожній список означає, що дозволено все.

        • spec.matchResources.excludeResourceRules.resources ([]string)

          Atomic: буде замінено під час злиття

          Resources — список ресурсів, до яких застосовується це правило.

          Наприклад: 'pods' означає podʼи. 'pods/log' означає підресурс журналу podʼів. '*' означає всі ресурси, але не підресурси. 'pods/*' означає всі підресурси podʼів. '*/scale' означає всі підресурси масштабу. '*/*' означає всі ресурси і їхні підресурси.

          Якщо присутній символ підстановки, правило валідації забезпечить, щоб ресурси не перекривалися між собою.

          Залежно від обʼєкта, що містить, підресурси можуть бути не дозволені. Обовʼязкове.

        • spec.matchResources.excludeResourceRules.scope (string)

          scope визначає область цього правила. Дійсні значення: "Cluster", "Namespaced" та "*". "Cluster" означає, що лише ресурси з областю дії кластера відповідатимуть цьому правилу. Обʼєкти API простору імен є кластерними. "Namespaced" означає, що лише ресурси з простору імен відповідатимуть цьому правилу. "*" означає, що обмежень за областю дії немає. Підресурси відповідають області їхнього батьківського ресурсу. Стандартно "*".

      • spec.matchResources.matchPolicy (string)

        matchPolicy визначає, як список "MatchResources" використовується для відповідності вхідним запитам. Дійсні значення: "Exact" або "Equivalent".

        • Exact: відповідати запиту лише тоді, коли він точно відповідає зазначеному правилу. Наприклад, якщо deployments можуть бути змінені через apps/v1, apps/v1beta1 і extensions/v1beta1, але "rules" включали лише apiGroups:["apps"], apiVersions:["v1"], resources: ["deployments"], запит до apps/v1beta1 або extensions/v1beta1 не буде надісланий до ValidatingAdmissionPolicy.

        • Equivalent: відповідати запиту, якщо він змінює ресурс, зазначений у правилах, навіть через іншу групу API або версію. Наприклад, якщо deployments можуть бути змінені через apps/v1, apps/v1beta1 і extensions/v1beta1, і "rules" включають лише apiGroups:["apps"], apiVersions:["v1"], resources: ["deployments"], запит до apps/v1beta1 або extensions/v1beta1 буде перетворено на apps/v1 і надіслано до ValidatingAdmissionPolicy.

        Стандартно — "Equivalent".

      • spec.matchResources.namespaceSelector (LabelSelector)

        NamespaceSelector вирішує, чи слід застосовувати політику контролю доступу до обʼєкта на основі того, чи відповідає простір імен цього обʼєкта селектору. Якщо сам обʼєкт є простором імен, відповідність перевіряється за object.metadata.labels. Якщо обʼєкт є іншим ресурсом з областю кластеру, політика ніколи не пропускається.

        Наприклад, щоб застосовувати вебхук до будь-яких обʼєктів, простір імен яких не асоційований з "runlevel" значенням "0" або "1", ви встановите селектор наступним чином:

        "namespaceSelector": {
          "matchExpressions": [
            {
              "key": "runlevel",
              "operator": "NotIn",
              "values": [
                "0",
                "1"
              ]
            }
          ]
        }
        

        Якщо ви хочете застосовувати політику лише до об'єктів, простір імен яких асоційований з "environment" значенням "prod" або "staging", ви встановите селектор наступним чином:

        "namespaceSelector": {
          "matchExpressions": [
            {
              "key": "environment",
              "operator": "In",
              "values": [
                "prod",
                "staging"
              ]
            }
          ]
        }
        

        Дивіться https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/ для прикладів селекторів міток.

        Стандартно використовується порожній LabelSelector, який відповідає всьому.

      • spec.matchResources.objectSelector (LabelSelector)

        ObjectSelector вирішує, чи слід виконувати валідацію на основі того, чи має обʼєкт відповідні мітки. objectSelector оцінюється як для oldObject, так і для newObject, які будуть надіслані на перевірку CEL, і вважається відповідним, якщо хоча б один з обʼєктів відповідає селектору. Обʼєкт null (oldObject у випадку створення або newObject у випадку видалення) або обʼєкт, який не може мати міток (наприклад, DeploymentRollback або PodProxyOptions), не вважається таким, що мають збіг.

        Використовуйте селектор обʼєкта лише якщо вебхук є опціональним, оскільки кінцеві користувачі можуть пропустити вебхук допуску, встановивши мітки. Стандартно використовується порожній LabelSelector, який відповідає всьому.

      • spec.matchResources.resourceRules ([]NamedRuleWithOperations)

        Atomic: буде замінено під час злиття

        ResourceRules описує, які операції з якими ресурсами/підресурсами мають збіг ValidatingAdmissionPolicy. Політика враховує операцію, якщо вона відповідає будь-якому правилу.

        NamedRuleWithOperations є кортежем Operations та Resources з ResourceNames.

        • spec.matchResources.resourceRules.apiGroups ([]string)

          Atomic: буде замінено під час злиття

          APIGroups — це групи API, до яких належать ресурси. '*' — всі групи. Якщо '*' присутній, довжина фрагменту повинна бути одиницею. Обовʼязковий параметр.

        • spec.matchResources.resourceRules.apiVersions ([]string)

          Atomic: буде замінено під час злиття

          APIVersions — це версії API, до яких належать ресурси. '*' — всі версії. Якщо '*' присутній, довжина фрагменту повинна бути одиницею. Обовʼязковий параметр.

        • spec.matchResources.resourceRules.operations ([]string)

          Atomic: буде замінено під час злиття

          Operations — це операції, які цікавлять хук допуску - CREATE, UPDATE, DELETE, CONNECT або * для всіх цих операцій і будь-яких майбутніх операцій допуску, які будуть додані. Якщо присутній символ "*", довжина фрагмента повинна бути одиницею. Обовʼязково.

        • spec.matchResources.resourceRules.resourceNames ([]string)

          Atomic: буде замінено під час злиття

          ResourceNames — це необовʼязковий білий список імен, до яких застосовується правило. Порожній набір означає, що дозволено все.

        • spec.matchResources.resourceRules.resources ([]string)

          Atomic: буде замінено під час злиття

          Resources — список ресурсів, до яких застосовується це правило.

          Наприклад: 'pods' означає podʼи. 'pods/log' означає підресурс журналу podʼів. '*' означає всі ресурси, але не підресурси. 'pods/*' означає всі підресурси podʼів. '*/scale' означає всі підресурси масштабу. '*/*' означає всі ресурси і їхні підресурси.

          Якщо присутній символ підстановки, правило валідації забезпечить, щоб ресурси не перекривалися між собою.

          Залежно від обʼєкта, що містить, підресурси можуть бути не дозволені. Обовʼязкове.

        • spec.matchResources.resourceRules.scope (string)

          scope визначає область цього правила. Дійсні значення: "Cluster", "Namespaced" та "*". "Cluster" означає, що лише ресурси з областю дії кластера відповідатимуть цьому правилу. Обʼєкти API простору імен є кластерними. "Namespaced" означає, що лише ресурси з простору імен відповідатимуть цьому правилу. "*" означає, що обмежень за областю дії немає. Підресурси відповідають області їхнього батьківського ресурсу. Стандартно "*".

    • spec.paramRef (ParamRef)

      paramRef вказує на ресурс параметра, який використовується для конфігурації політики контролю доступу. Він має вказувати на ресурс типу, зазначеного в ParamKind привʼязаної ValidatingAdmissionPolicy. Якщо політика вказує ParamKind, а ресурс, на який посилається ParamRef, не існує, це привʼязування вважається неправильно налаштованим, і застосовується FailurePolicy ValidatingAdmissionPolicy. Якщо політика не вказує ParamKind, це поле ігнорується, а правила оцінюються без параметра.

      ParamRef описує, як знайти параметри, які будуть використовуватися як вхідні дані для виразів правил, застосованих привʼязуванням політики.

      • spec.paramRef.name (string)

        name — це ім'я ресурсу, на який посилаються.

        Один з параметрів name або selector повинен бути заданий, але name і selector є взаємовиключними властивостями. Якщо одне з них задане, інше повинно бути не задане.

        Один параметр, що використовується для всіх запитів на допуск, можна налаштувати, задавши поле name, залишивши selector порожнім і задавши простір імен, якщо paramKind має область простору імен.

      • spec.paramRef.namespace (string)

        namespace — це простір імен ресурсу, на який посилаються. Дозволяє обмежити пошук параметрів певним простором імен. Застосовується до обох полів name і selector.

        Параметр для кожного простору імен можна використовувати, вказавши у політиці paramKind для простору імен і залишивши це поле порожнім.

        • Якщо paramKind має область дії кластер, це поле МАЄ бути не задане. Встановлення цього поля призводить до помилки конфігурації.

        • Якщо paramKind має область дії простір імен, буде використано простір імен обʼєкта, що оцінюється для допуску, коли це поле залишено порожнім. Зверніть увагу, що якщо це поле залишено пустим, привʼязування не повинно відповідати жодним ресурсам з областю дії кластера, що призведе до помилки.

      • spec.paramRef.parameterNotFoundAction (string)

        parameterNotFoundAction контролює поведінку привʼязування, коли ресурс існує, і name або selector є дійсними, але не знайдено жодних параметрів, які відповідають привʼязуванню. Якщо значення встановлено на Allow, то відсутність відповідних параметрів буде розглядатися привʼязуванням як успішна валідація. Якщо встановлено на Deny, то відсутність відповідних параметрів підлягатиме failurePolicy політиці.

        Дозволені значення — Allow або Deny

        Обовʼязково.

      • spec.paramRef.selector (LabelSelector)

      selector може використовуватися для відповідності кільком обʼєктам параметрів на основі їхніх міток. Постачайте selector: {} для відповідності всім ресурсам типу ParamKind.

      Якщо знайдено кілька параметрів, вони всі оцінюються за виразами політики, і результати обʼєднуються за допомогою логічного оператора AND.

      Один з параметрів name або selector повинен бути заданий, але name і selector є взаємовиключними властивостями. Якщо одне з них задане, інше повинно бути не задане.

    • spec.policyName (string)

      PolicyName посилається на імʼя ValidatingAdmissionPolicy, до якого привʼязується ValidatingAdmissionPolicyBinding. Якщо посиланий ресурс не існує, це привʼязування вважається недійсним і буде ігноруватися. Обовʼязкове.

    • spec.validationActions ([]string)

      Set: унікальні значення будуть збережені під час злиття

      validationActions визначає, як виконуються валідації вказаної ValidatingAdmissionPolicy. Якщо валідація оцінюється як невірна, вона завжди виконується відповідно до цих дій.

      Помилки, визначені FailurePolicy ValidatingAdmissionPolicy, виконуються відповідно до цих дій тільки якщо FailurePolicy встановлено на Fail, в іншому випадку помилки ігноруються. Це включає помилки компіляції, помилки виконання та неправильні конфігурації політики.

      validationActions оголошено як набір значень дій. Порядок не має значення. validationActions не може містити дублікатів однієї і тієї ж дії.

      Підтримувані значення дій:

      "Deny" вказує, що невдача валідації призводить до відмови у запиті.

      "Warn" вказує, що невдача валідації повідомляється клієнту запиту в заголовках HTTP Warning з кодом попередження 299. Попередження можуть бути надіслані як для дозволених, так і для відхилених відповідей на допуск.

      "Audit" вказує, що невдача валідації включена в опубліковану подію аудиту запиту. Подія аудиту буде містити анотацію аудиту validation.policy.admission.k8s.io/validation_failure зі значенням, яке містить деталі невдач валідації у форматі JSON списку обʼєктів, кожен з яких має такі поля:

      • message: Рядок повідомлення про невдачу валідації
      • policy: Імʼя ресурсу ValidatingAdmissionPolicy
      • binding: Імʼя ресурсу ValidatingAdmissionPolicyBinding
      • expressionIndex: Індекс невдалих валідацій у ValidatingAdmissionPolicy
      • validationActions: Дії виконання, що були застосовані до невдачі валідації

      Приклад анотації аудиту: "validation.policy.admission.k8s.io/validation_failure": "[{"message": "Invalid value", {"policy": "policy.example.com", {"binding": "policybinding.example.com", {"expressionIndex": "1", {"validationActions": ["Audit"]}]"

      Клієнти повинні очікувати обробку додаткових значень, ігноруючи будь-які нерозпізнані значення.

      "Deny" та "Warn" не можуть використовуватися разом, оскільки ця комбінація зайво дублює невдачу валідації як у тілі відповіді API, так і в заголовках HTTP попередження.

      Обовʼязкове.

ValidatingAdmissionPolicy

ValidatingAdmissionPolicy описує визначення політики валідації допуску, яка приймає або відхиляє обʼєкт без його зміни.


  • apiVersion (string)

    APIVersion визначає версію схеми цього представлення обʼєкта. Сервери повинні конвертувати визнані схеми до останнього внутрішнього значення і можуть відхиляти невизнані значення. Додаткова інформація: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources

  • kind (string)

    Kind — це рядкове значення, що представляє REST-ресурс, який цей обʼєкт уособлює. Сервери можуть виводити його з точки доступу, до якої клієнт надсилає запити. Не може бути оновлено. У форматі CamelCase. Додаткова інформація: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds

  • metadata (ObjectMeta)

    Стандартний обʼєкт метаданих; Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata.

  • spec (ValidatingAdmissionPolicySpec)

    Визначення бажаної поведінки ValidatingAdmissionPolicy.

    ValidatingAdmissionPolicySpec — це специфікація бажаної поведінки AdmissionPolicy.

    • spec.auditAnnotations ([]AuditAnnotation)

      Atomic: буде замінено під час злиття

      auditAnnotations містить вирази CEL, які використовуються для створення анотацій аудиту для події аудиту API-запиту. validations і auditAnnotations не можуть бути обидва порожніми; принаймні одне з них є обовʼязковим.

      AuditAnnotation описує, як створити анотацію аудиту для запиту API.

      • spec.auditAnnotations.key (string), обовʼязково

        key визначає ключ анотації аудиту. Ключі анотацій аудиту для ValidatingAdmissionPolicy повинні бути унікальними. Ключ повинен бути кваліфікованим іменем ([A-Za-z0-9][-A-Za-z0-9_.]*) довжиною не більше 63 байтів.

        Ключ комбінується з іменем ресурсу ValidatingAdmissionPolicy для створення ключа анотації аудиту: "{Ім'я ValidatingAdmissionPolicy}/{ключ}".

        Якщо admission webhook використовує те саме ім'я ресурсу, що і ця ValidatingAdmissionPolicy, та той же ключ анотації аудиту, ключ анотації буде ідентичним. У цьому випадку перша анотація, написана з цим ключем, буде включена в подію аудиту, а всі наступні анотації з тим же ключем будуть відкинуті.

        Обовʼязкове.

      • spec.auditAnnotations.valueExpression (string), обовʼязково

        valueExpression представляє вираз, який оцінюється CEL для створення значення анотації аудиту. Вираз має оцінюватися як рядок або null. Якщо вираз оцінюється як рядок, анотація аудиту включається з рядковим значенням. Якщо вираз оцінюється як null або порожній рядок, анотація аудиту буде пропущена. valueExpression не може перевищувати 5 КБ в довжину. Якщо результат valueExpression перевищує 10 КБ в довжину, він буде обрізаний до 10 КБ.

        Якщо кілька ресурсів ValidatingAdmissionPolicyBinding відповідають API-запиту, вираз valueExpression буде оцінений для кожного привʼязування. Всі унікальні значення, отримані від valueExpressions, будуть обʼєднані в список, розділений комами.

        Обовʼязкове.

    • spec.failurePolicy (string)

      failurePolicy визначає, як обробляти помилки для політики допуску. Помилки можуть виникати через помилки парсингу виразів CEL, помилки перевірки типів, помилки виконання та неправильні або некоректно налаштовані визначення політики або привʼязки.

      Політика вважається недійсною, якщо spec.paramKind посилається на неіснуючий Kind. Привʼязка є недійсною, якщо spec.paramRef.name посилається на неіснуючий ресурс.

      failurePolicy не визначає, як обробляються валідації, що оцінюються як невірні.

      Коли failurePolicy встановлено на Fail, ValidatingAdmissionPolicyBinding validationActions визначає, як застосовуються помилки.

      Допустимі значення: Ignore або Fail. Стандартно — Fail.

    • spec.matchConditions ([]MatchCondition)

      Patch strategy: обʼєднання за ключем name

      Map: унікальні значення ключа name будуть збережені під час злиття

      MatchConditions — це список умов, які повинні бути виконані для валідації запиту. Умови збігу фільтрують запити, які вже були відповідно до правил, namespaceSelector і objectSelector. Порожній список matchConditions відповідає всім запитам. Максимальна кількість умов збігу — 64.

      Якщо надано обʼєкт параметра, до нього можна звертатися через дескриптор params так само, як і до виразів валідації.

      Точна логіка збігу (впорядкована):

      1. Якщо будь-яка умова matchCondition оцінюється як FALSE, політика пропускається.
      2. Якщо всі умови matchConditions оцінюються як TRUE, політика оцінюється.
      3. Якщо будь-яка умова matchCondition оцінюється як помилка (але жодна не є FALSE):
        • Якщо failurePolicy=Fail, запит відхиляється.
        • Якщо failurePolicy=Ignore, політика пропускається.

      MatchCondition представляє умову, яка повинна бути виконана для того, щоб запит був надісланий до вебхука.

      • spec.matchConditions.expression (string), обовʼязково

        Expression представляє вираз, який буде оцінюватися CEL. Повинен оцінюватися як bool. CEL вирази мають доступ до вмісту AdmissionRequest та Authorizer, організованого у змінні CEL:

        • 'object' — обʼєкт з вхідного запиту. Значення є null для запитів DELETE.
        • 'oldObject' — існуючий обʼєкт. Значення є null для запитів CREATE.
        • 'request' — атрибути запиту на допуск (/pkg/apis/admission/types.go#AdmissionRequest).
        • 'authorizer' — CEL Authorizer. Може бути використаний для виконання перевірок авторизації для принципала (користувача або облікового запису служби) запиту. Див. https://pkg.go.dev/k8s.io/apiserver/pkg/cel/library#Authz.
        • 'authorizer.requestResource' — CEL ResourceCheck, створений з authorizer і налаштований з ресурсом запиту.

        Документація про CEL: https://kubernetes.io/docs/reference/using-api/cel/

        Обовʼязкове.

      • spec.matchConditions.name (string), обовʼязково

        Name є ідентифікатором для цієї умови збігу, який використовується для стратегічного злиття MatchConditions, а також для надання ідентифікатора для цілей журналювання. Добре вибране імʼя повинно бути описовим для відповідного виразу. Name повинно бути кваліфікованим іменем, що складається з алфавітно-цифрових символів, '-', '_' або '.', і повинно починатися та закінчуватися алфавітно-цифровим символом (наприклад, 'MyName', 'my.name', '123-abc', регулярний вираз для перевірки — '([A-Za-z0-9][-A-Za-z0-9_.]*)?[A-Za-z0-9]') з необовʼязковим префіксом DNS піддомену та '/' (наприклад, 'example.com/MyName').

        Обовʼязкове.

    • spec.matchConstraints (MatchResources)

      MatchConstraints визначає ресурси, які ця політика має перевіряти. AdmissionPolicy турбується про запит, якщо він відповідає усім Constraints. Однак, для запобігання випадкам, коли кластер може бути переведений в нестабільний стан, з якого не можна відновитися через API, ValidatingAdmissionPolicy не може відповідати ValidatingAdmissionPolicy і ValidatingAdmissionPolicyBinding.

      Обовʼязкове.

      MatchResources визначає, чи потрібно застосовувати політику контролю доступу до обʼєкта на основі того, чи відповідає він критеріям збігу. Правила виключення мають пріоритет над правилами включення (якщо ресурс відповідає обом критеріям, він буде виключений).

      • spec.matchConstraints.excludeResourceRules ([]NamedRuleWithOperations)

        Atomic: буде замінено під час злиття

        ExcludeResourceRules описує операції над ресурсами/підресурсами, про які ValidatingAdmissionPolicy не повинна турбуватися. Правила виключення мають пріоритет над правилами включення (якщо ресурс відповідає обом критеріям, він буде виключений).

        NamedRuleWithOperations є кортежем Operations та Resources з ResourceNames.

        • spec.matchConstraints.excludeResourceRules.apiGroups ([]string)

          Atomic: буде замінено під час злиття

          APIGroups — це групи API, до яких належать ресурси. '*' — всі групи. Якщо '*' присутній, довжина фрагменту повинна бути одиницею. Обовʼязковий параметр.

        • spec.matchConstraints.excludeResourceRules.apiVersions ([]string)

          Atomic: буде замінено під час злиття

          APIVersions — це версії API, до яких належать ресурси. '*' — всі версії. Якщо '*' присутній, довжина фрагменту повинна бути одиницею. Обовʼязковий параметр.

        • spec.matchConstraints.excludeResourceRules.operations ([]string)

          Atomic: буде замінено під час злиття

          Operations — це операції, які цікавлять хук допуску - CREATE, UPDATE, DELETE, CONNECT або * для всіх цих операцій і будь-яких майбутніх операцій допуску, які будуть додані. Якщо присутній символ "*", довжина фрагмента повинна бути одиницею. Обовʼязково.

        • spec.matchConstraints.excludeResourceRules.resourceNames ([]string)

          Atomic: буде замінено під час злиття

          ResourceNames — це необовʼязковий білий список імен, до яких застосовується правило. Порожній набір означає, що дозволено все.

        • spec.matchConstraints.excludeResourceRules.resources ([]string)

          Atomic: буде замінено під час злиття

          Resources — список ресурсів, до яких застосовується це правило.

          Наприклад: 'pods' означає podʼи. 'pods/log' означає підресурс журналу podʼів. '*' означає всі ресурси, але не підресурси. 'pods/*' означає всі підресурси podʼів. '*/scale' означає всі підресурси масштабу. '*/*' означає всі ресурси і їхні підресурси.

          Якщо присутній символ підстановки, правило валідації забезпечить, щоб ресурси не перекривалися між собою.

          Залежно від обʼєкта, що містить, підресурси можуть бути не дозволені. Обовʼязкове.

        • spec.matchConstraints.excludeResourceRules.scope (string)

          scope визначає область цього правила. Дійсні значення: "Cluster", "Namespaced" та "*". "Cluster" означає, що лише ресурси з областю дії кластера відповідатимуть цьому правилу. Обʼєкти API простору імен є кластерними. "Namespaced" означає, що лише ресурси з простору імен відповідатимуть цьому правилу. "*" означає, що обмежень за областю дії немає. Підресурси відповідають області їхнього батьківського ресурсу. Стандартно "*".

      • spec.matchConstraints.matchPolicy (string)

        matchPolicy визначає, як список "MatchResources" використовується для відповідності вхідним запитам. Дійсні значення: "Exact" або "Equivalent".

        • Exact: відповідати запиту лише тоді, коли він точно відповідає зазначеному правилу. Наприклад, якщо deployments можуть бути змінені через apps/v1, apps/v1beta1 і extensions/v1beta1, але "rules" включали лише apiGroups:["apps"], apiVersions:["v1"], resources: ["deployments"], запит до apps/v1beta1 або extensions/v1beta1 не буде надісланий до ValidatingAdmissionPolicy.

        • Equivalent: відповідати запиту, якщо він змінює ресурс, зазначений у правилах, навіть через іншу групу API або версію. Наприклад, якщо deployments можуть бути змінені через apps/v1, apps/v1beta1 і extensions/v1beta1, і "rules" включають лише apiGroups:["apps"], apiVersions:["v1"], resources: ["deployments"], запит до apps/v1beta1 або extensions/v1beta1 буде перетворено на apps/v1 і надіслано до ValidatingAdmissionPolicy.

        Стандартно — "Equivalent".

      • spec.matchConstraints.namespaceSelector (LabelSelector)

        NamespaceSelector визначає, чи слід застосовувати політику контролю доступу до обʼєкта на основі того, чи відповідає простір імен цього обʼєкта селектору. Якщо обʼєкт сам є простором імен, то відповідність перевіряється на object.metadata.labels. Якщо обʼєкт є іншим ресурсом, що охоплює кластер, політика ніколи не пропускається.

        Наприклад, щоб застосувати вебхук до будь-яких обʼєктів, простір імен яких не асоціюється з "runlevel" "0" або "1", ви повинні встановити селектор наступним чином:

        "namespaceSelector": {
          "matchExpressions": [
            {
              "key": "runlevel",
              "operator": "NotIn",
              "values": [
                "0",
                "1"
              ]
            }
          ]
        }
        

        Якщо ви хочете застосувати політику лише до обʼєктів, простір імен яких асоційований з "середовищем" "prod" або "staging", ви повинні налаштувати селектор таким чином:

        "namespaceSelector": {
          "matchExpressions": [
            {
              "key": "environment",
              "operator": "In",
              "values": [
                "prod",
                "staging"
              ]
            }
          ]
        }
        

        Дивіться https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/ щоб отримати більше прикладів селекторів міток.

        Стандартне значення пустий LabelSelector, який відповідає всьому.

      • spec.matchConstraints.objectSelector (LabelSelector)

        ObjectSelector визначає, чи потрібно виконати перевірку на основі того, чи має обʼєкт відповідні мітки. ObjectSelector оцінюється як для старого обʼєкта (oldObject), так і для нового обʼєкта (newObject), які будуть надіслані для перевірки cel, і вважається, що він відповідає, якщо будь-який з обʼєктів відповідає селектору. Null-обʼєкт (oldObject у випадку створення або newObject у випадку видалення) або обʼєкт, який не може мати мітки (такі як DeploymentRollback або PodProxyOptions), не вважається таким, що має збіг. Використовуйте селектор обʼєктів лише в разі, якщо веб-хук є опційним, оскільки кінцеві користувачі можуть пропустити admission webhook, налаштувавши мітки. Стандартно використовуйте пустий LabelSelector, який відповідає всьому.

      • spec.matchConstraints.resourceRules ([]NamedRuleWithOperations)

        Atomic: буде замінено під час злиття

        ResourceRules описує, які операції на яких ресурсах/підресурсах відповідає ValidatingAdmissionPolicy. Політика враховує операцію, якщо вона відповідає будь-якому правилу.

        NamedRuleWithOperations є кортежем Operations та Resources з ResourceNames.

        • spec.matchConstraints.resourceRules.apiGroups ([]string)

          Atomic: буде замінено під час злиття

          APIGroups — це групи API, до яких належать ресурси. '*' — всі групи. Якщо '*' присутній, довжина фрагменту повинна бути одиницею. Обовʼязковий параметр.

        • spec.matchConstraints.resourceRules.apiVersions ([]string)

          Atomic: буде замінено під час злиття

          APIVersions — це версії API, до яких належать ресурси. '*' — всі версії. Якщо '*' присутній, довжина фрагменту повинна бути одиницею. Обовʼязковий параметр.

        • spec.matchConstraints.resourceRules.operations ([]string)

          Atomic: буде замінено під час злиття

          Operations — це операції, які цікавлять хук допуску - CREATE, UPDATE, DELETE, CONNECT або * для всіх цих операцій і будь-яких майбутніх операцій допуску, які будуть додані. Якщо присутній символ "*", довжина фрагмента повинна бути одиницею. Обовʼязково.

        • spec.matchConstraints.resourceRules.resourceNames ([]string)

          Atomic: буде замінено під час злиття

          ResourceNames — це необовʼязковий білий список імен, до яких застосовується правило. Порожній набір означає, що дозволено все.

        • spec.matchConstraints.resourceRules.resources ([]string)

          Atomic: буде замінено під час злиття

          Resources — список ресурсів, до яких застосовується це правило.

          Наприклад: 'pods' означає podʼи. 'pods/log' означає підресурс журналу podʼів. '*' означає всі ресурси, але не підресурси. 'pods/*' означає всі підресурси podʼів. '*/scale' означає всі підресурси масштабу. '*/*' означає всі ресурси і їхні підресурси.

          Якщо присутній символ підстановки, правило валідації забезпечить, щоб ресурси не перекривалися між собою.

          Залежно від обʼєкта, що містить, підресурси можуть бути не дозволені. Обовʼязкове.

        • spec.matchConstraints.resourceRules.scope (string)

          scope визначає область цього правила. Дійсні значення: "Cluster", "Namespaced" та "*". "Cluster" означає, що лише ресурси з областю дії кластера відповідатимуть цьому правилу. Обʼєкти API простору імен є кластерними. "Namespaced" означає, що лише ресурси з простору імен відповідатимуть цьому правилу. "*" означає, що обмежень за областю дії немає. Підресурси відповідають області їхнього батьківського ресурсу. Стандартно "*".

    • spec.paramKind (ParamKind)

      ParamKind вказує тип ресурсів, які використовуються для параметризації цієї політики. Якщо відсутній, параметрів для цієї політики немає, і змінна param CEL не буде надана для виразів перевірки. Якщо ParamKind посилається на неіснуючий тип, ця конфігурація політики є неправильною, і застосовується FailurePolicy. Якщо paramKind зазначено, але paramRef не встановлено у ValidatingAdmissionPolicyBinding, змінна params буде null.

      ParamKind — це кортеж Group Kind та Version.

      • spec.paramKind.apiVersion (string)

        APIVersion - версія групи API, до якої належать ресурси. У форматі "group/version". Обовʼязковий параметр.

      • spec.paramKind.kind (string)

        Kind — це тип API, до якого належать ресурси. Обовʼязковий параметр.

    • spec.validations ([]Validation)

      Atomic: буде замінено під час злиття

      Validations містять вирази CEL, які використовуються для застосування перевірки. Validations та AuditAnnotations не можуть бути обидва пустими; потрібно щонайменше один з Validations або AuditAnnotations.

      Validation вказує вираз CEL, який використовується для застосування перевірки.

      • spec.validations.expression (string), обовʼязково

        Expression представляє вираз, який буде оцінюватися CEL. ref: https://github.com/google/cel-spec CEL-вирази мають доступ до вмісту запиту/відповіді API, організованих у змінні CEL, а також деякі інші корисні змінні:

        • 'object' — Обʼєкт з вхідного запиту. Значення null для запитів DELETE.
        • 'oldObject' — Наявний обʼєкт. Значення null для запитів CREATE.
        • 'request' — Атрибути запиту API(ref).
        • 'params' — Параметр ресурсу, на який посилається перевірка політики. Заповнюється лише, якщо політика має ParamKind.
        • 'namespaceObject' — Обʼєкт простору імен, до якого належить вхідний обʼєкт. Значення null для ресурсів на рівні кластера.
        • 'variables' - Map змінних, від їх назви до їхнього ледачого (lazily) оцінюваного значення. Наприклад, змінна з назвою 'foo' може бути доступна як 'variables.foo'.
        • 'authorizer' — CEL Authorizer. Може використовуватися для виконання перевірок авторизації для виконавця (користувача або облікового запису служби) запиту. Див. https://pkg.go.dev/k8s.io/apiserver/pkg/cel/library#Authz
        • 'authorizer.requestResource' — CEL ResourceCheck, створений з 'authorizer' та налаштований для ресурсу запиту.

        apiVersion, kind, metadata.name і metadata.generateName завжди доступні з кореня обʼєкта. Інші властивості метаданих недоступні.

        Доступні лише імена властивостей у формі [a-zA-Z_.-/][a-zA-Z0-9_.-/]*. Доступні імена властивостей екрануються згідно з наступними правилами, коли доступні у виразі:

        • '__' екранується як 'underscores'

        • '.' екранується як 'dot'

        • '-' екранується як 'dash'

        • '/' екранується як 'slash'

        • Імена властивостей, що точно збігаються з CEL РЕЗЕРВОВАНИМИ ключовими словами, екрануються як '{keyword}'. Ключові слова включають: "true", "false", "null", "in", "as", "break", "const", "continue", "else", "for", "function", "if", "import", "let", "loop", "package", "namespace", "return". Приклади:

        • Вираз, що звертається до властивості з назвою "namespace": {"Expression": "object.namespace > 0"}

        • Вираз, що звертається до властивості з назвою "x-prop": {"Expression": "object.x__dash__prop > 0"}

        • Вираз, що звертається до властивості з назвою "redact__d": {"Expression": "object.redact__underscores__d > 0"}

        Рівність масивів із типом списку 'set' або 'map' ігнорує порядок елементів, тобто [1, 2] == [2, 1]. Конкатенація масивів із типом списку x-kubernetes використовує семантику типу списку:

        • 'set': X + Y виконує обʼєднання, де позиції масиву всіх елементів у X зберігаються, а елементи в Y, що не перетинаються, додаються зі збереженням їх часткового порядку.
        • 'map': X + Y виконує злиття, де позиції масиву всіх ключів у X зберігаються, але значення замінюються значеннями з Y, коли множини ключів X та Y перетинаються. Елементи в Y з ключами, що не перетинаються з ключами, що не перетинаються, додаються зі збереженням їх часткового порядку. Обовʼязково.
      • spec.validations.message (string)

        Message представляє повідомлення, що відображається при невдалій перевірці. Повідомлення обовʼязкове, якщо Expression містить розриви рядка. Повідомлення не повинно містити розриви рядка. Якщо не вказано, повідомлення — "failed rule: {Rule}". Наприклад, "must be a URL with the host matching spec.host" Якщо Expression містить розриви рядка, повідомлення обовʼязкове. Повідомлення не повинно містити розриви рядка. Якщо не встановлено, повідомлення — "failed Expression: {Expression}".

      • spec.validations.messageExpression (string)

        messageExpression оголошує CEL-вираз, який оцінюється як повідомлення про невдачу перевірки, що повертається, коли це правило не виконується. Оскільки messageExpression використовується як повідомлення про невдачу, воно повинно оцінюватися як рядок. Якщо і message, і messageExpression присутні у перевірці, то messageExpression буде використано, якщо перевірка не вдалася. Якщо messageExpression призводить до помилки під час виконання, помилка записується в лог, і повідомлення про невдачу перевірки створюється так, ніби поле messageExpression не було встановлено. Якщо messageExpression оцінюється як порожній рядок, рядок з лише пробілами або рядок, що містить розриви рядка, то повідомлення про невдачу перевірки також створюється так, ніби поле messageExpression не було встановлено, і факт того, що messageExpression створило порожній рядок/рядок з лише пробілами/рядок з розривами рядка, буде записано в лог. messageExpression має доступ до всіх тих самих змінних, що і expression, за винятком 'authorizer' та 'authorizer.requestResource'. Приклад: "object.x must be less than max ("+string(params.max)+")"

      • spec.validations.reason (string)

        Reason представляє машинно-зчитуваний опис того, чому ця перевірка не вдалася. Якщо це перша перевірка в списку, що не вдалася, ця причина, а також відповідний код відповіді HTTP, використовуються у відповіді HTTP клієнту. Наразі підтримувані причини: "Unauthorized", "Forbidden", "Invalid", "RequestEntityTooLarge". Якщо не встановлено, використовується StatusReasonInvalid у відповіді клієнту.

    • spec.variables ([]Variable)

      Patch strategy: злиття по ключу name

      Map: унікальні значення по ключу name будуть зберігатися під час злиття

      Variables містять визначення змінних, які можна використовувати у складі інших виразів. Кожна змінна визначена як іменований CEL-вираз. Змінні, визначені тут, будуть доступні у variables в інших виразах політики, за винятком MatchConditions, оскільки MatchConditions оцінюються перед рештою політики.

      Вираз змінної може посилатися на інші змінні, визначені раніше у списку, але не на ті, що стоять після неї. Таким чином, змінні мають бути відсортовані за порядком першої появи та ациклічно.

      Variable — це визначення змінної, яка використовується для складання. Змінна визначається як іменований вираз.

      • spec.variables.expression (string), обовʼязково

        Expression — це вираз, який буде оцінений як значення змінної. CEL-вираз має доступ до тих самих ідентифікаторів, що і CEL-вирази в Validation.

      • spec.variables.name (string), обовʼязково

        Name — це назва змінної. Назва повинна бути дійсним ідентифікатором CEL і унікальною серед усіх змінних. Змінна може бути доступна в інших виразах через variables Наприклад, якщо name є "foo", змінна буде доступна як variables.foo.

  • status (ValidatingAdmissionPolicyStatus)

    Статус ValidatingAdmissionPolicy, включаючи попередження, які корисні для визначення, чи працює політика відповідно до очікувань. Заповнюється системою. Тільки для читання.

    ValidatingAdmissionPolicyStatus представляє статус політики перевірки допуску.

    • status.conditions ([]Condition)

      Map: унікальні значення по ключу type будуть зберігатися під час злиття

      Стани представляють останні доступні спостереження поточного стану політики.

      Condition містить деталі одного аспекту поточного стану цього API-ресурсу.

      • status.conditions.lastTransitionTime (Time), обовʼязково

        lastTransitionTime — це останній час, коли стан перейшов з одного стану в інший. Це має бути, коли змінився основний стан. Якщо це невідомо, то прийнятно використовувати час, коли змінилося поле API.

        Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

      • status.conditions.message (string), обовʼязково

        message — це повідомлення зрозуміле людині, яке вказує деталі про зміну стану. Воно може бути порожній рядок.

      • status.conditions.reason (string), обовʼязково

        reason містить програмний ідентифікатор, що вказує на причину останньої зміни стану. Виробники конкретних типів станів можуть визначити очікувані значення та значення для цього поля, а також чи вважаються значення гарантованим API. Значення має бути рядком у форматі CamelCase. Це поле не може бути порожнім.

      • status.conditions.status (string), обовʼязково

        статус стану, один з True, False, Unknown.

      • status.conditions.type (string), обовʼязково

        тип стану у форматі CamelCase або у форматі foo.example.com/CamelCase.

      • status.conditions.observedGeneration (int64)

        observedGeneration представляє .metadata.generation, на основі якого було встановлено стан. Наприклад, якщо .metadata.generation зараз 12, але .status.conditions[x].observedGeneration - 9, стан застарів відносно поточного стану екземпляра.

    • status.observedGeneration (int64)

      Покоління, яке спостерігалося контролером.

    • status.typeChecking (TypeChecking)

      Результати перевірки типу для кожного виразу. Наявність цього поля вказує на завершення перевірки типу.

      TypeChecking містить результати перевірки типу виразів у ValidatingAdmissionPolicy

      • status.typeChecking.expressionWarnings ([]ExpressionWarning)

        Atomic: буде замінено під час злиття

        Попередження перевірки типу для кожного виразу.

        ExpressionWarning — це інформація про попередження, що стосується конкретного виразу.

        • status.typeChecking.expressionWarnings.fieldRef (string), обовʼязково

          Шлях до поля, що посилається на вираз. Наприклад, посилання на вираз першого елемента перевірок є "spec.validations[0].expression".

        • status.typeChecking.expressionWarnings.warning (string), обовʼязково

          Вміст інформації про попередження перевірки типу у формі, зручною для читання людиною. Кожен рядок попередження містить тип, за яким перевірено вираз, а потім помилку перевірки типу від компілятора.

ValidatingAdmissionPolicyBindingList

ValidatingAdmissionPolicyBindingList — це список ValidatingAdmissionPolicyBinding.


Операції


get отримати вказанний ValidatingAdmissionPolicyBinding

HTTP запит

GET /apis/admissionregistration.k8s.io/v1/validatingadmissionpolicybindings/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ValidatingAdmissionPolicyBinding

  • pretty (в запиті): string

    pretty

Відповідь

200 (ValidatingAdmissionPolicyBinding): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу ValidatingAdmissionPolicyBinding

HTTP запит

GET /apis/admissionregistration.k8s.io/v1/validatingadmissionpolicybindings

Параметри

Відповідь

200 (ValidatingAdmissionPolicyBindingList): OK

401: Unauthorized

create створення ValidatingAdmissionPolicyBinding

HTTP запит

POST /apis/admissionregistration.k8s.io/v1/validatingadmissionpolicybindings

Параметри

Відповідь

200 (ValidatingAdmissionPolicyBinding): OK

201 (ValidatingAdmissionPolicyBinding): Created

202 (ValidatingAdmissionPolicyBinding): Accepted

401: Unauthorized

update заміна вказаного ValidatingAdmissionPolicyBinding

HTTP запит

PUT /apis/admissionregistration.k8s.io/v1/validatingadmissionpolicybindings/{name}

Параметри

Відповідь

200 (ValidatingAdmissionPolicyBinding): OK

201 (ValidatingAdmissionPolicyBinding): Created

401: Unauthorized

patch часткове оновлення вказаного ValidatingAdmissionPolicyBinding

HTTP запит

PATCH /apis/admissionregistration.k8s.io/v1/validatingadmissionpolicybindings/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ValidatingAdmissionPolicyBinding

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (ValidatingAdmissionPolicyBinding): OK

201 (ValidatingAdmissionPolicyBinding): Created

401: Unauthorized

delete видалення ValidatingAdmissionPolicyBinding

HTTP запит

DELETE /apis/admissionregistration.k8s.io/v1/validatingadmissionpolicybindings/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ValidatingAdmissionPolicyBinding

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції ValidatingAdmissionPolicyBinding

HTTP запит

DELETE /apis/admissionregistration.k8s.io/v1/validatingadmissionpolicybindings

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

6.5.7 - Розширені ресурси

6.5.7.1 - CustomResourceDefinition

CustomResourceDefinition представляє ресурс, який повинен бути експонований на сервері API.

apiVersion: apiextensions.k8s.io/v1

import "k8s.io/apiextensions-apiserver/pkg/apis/apiextensions/v1"

CustomResourceDefinition

CustomResourceDefinition представляє ресурс, який повинен бути експонований на сервері API. Його імʼя повинно бути у форматі <.spec.name>.<.spec.group>.


CustomResourceDefinitionSpec

CustomResourceDefinitionSpec визначає, як користувач хоче, щоб їхні ресурси виглядали


  • group (string), обовʼязково

    group — це API-група визначеного власного ресурсу. Власні ресурси обслуговуються як /apis/<group>/.... Повинно відповідати імені CustomResourceDefinition у форматі <names.plural>.<group>.

  • names (CustomResourceDefinitionNames), обовʼязково

    names вказують імена ресурсу та виду для власного ресурсу.

    CustomResourceDefinitionNames вказує імена для обслуговування цього CustomResourceDefinition

    • names.kind (string), обовʼязково

      kind — серіалізована версія виду ресурсу. Зазвичай CamelCase та однина. Екземпляри власного ресурсу використовуватимуть це значення як атрибут kind у викликах API.

    • names.plural (string), обовʼязково

      plural — імʼя ресурсу в множині для обслуговування. Власні ресурси обслуговуються як /apis/<group>/<version>/.../<plural>. Повинно відповідати імені CustomResourceDefinition у форматі <names.plural>.<group>. Всі літери мають бути у нижньому регістрі.

    • names.categories ([]string)

      Atomic: буде замінено під час злиття

      categories — це список згрупованих ресурсів, до яких належить цей власний ресурс (наприклад, 'all'). Публікується в документах відкриття API та використовується клієнтами для підтримки викликів типу kubectl get all.

    • names.listKind (string)

      listKind — серіалізована версія списку для цього ресурсу. Стандартне значення "kindList".

    • names.shortNames ([]string)

      Atomic: буде замінено під час злиття

      shortNames — короткі імена ресурсу, відображені в документах відкриття API та використовувані клієнтами для підтримки викликів типу kubectl get <shortname>. Всі літери мають бути у нижньому регістрі.

    • names.singular (string)

      singular — назва ресурсу в однині. Всі літери мають бути у нижньому регістрі. Стандартно, це значення є приведеним до нижнього регістру kind.

  • scope (string), обовʼязково

    scope вказує, чи має визначений власний ресурс область застосування, спільну для кластера або простору імен. Допустимі значення: Cluster і Namespaced.

  • versions ([]CustomResourceDefinitionVersion), обовʼязково

    Atomic: буде замінено під час злиття

    versions — це список всіх API-версій визначеного власного ресурсу. Назви версій використовуються для визначення порядку в зазначених API-версіях. Якщо рядок версії є "kube-like", він буде вище не "kube-like" рядків версій, що упорядковуються лексикографічно. "Kube-like" версії починаються з "v", за яким слідує номер (головна версія), а потім необовʼязково рядок "alpha" або "beta" та інший номер (додаткова версія). Ці версії сортуються так: GA > beta > alpha (де GA - версія без суфікса, такого як beta або alpha), а потім порівнюються головна версія, а потім додаткова версія. Приклад відсортованого списку версій: v10, v2, v1, v11beta2, v10beta3, v3beta1, v12alpha1, v11alpha2, foo1, foo10.

    CustomResourceDefinitionVersion описує версію для CRD.

    • versions.name (string), обовʼязково

      name — це імʼя версії, наприклад "v1", "v2beta1" і т.д. Власні ресурси обслуговуються під цією версією за адресою /apis/<group>/<version>/..., якщо served встановлено в true.

    • versions.served (boolean), обовʼязково

      served — це прапорець, що дозволяє включити/відключити цю версію для обслуговування через REST API.

    • versions.storage (boolean), обовʼязково

      storage — вказує, що цю версію слід використовувати при збереженні власних ресурсів у сховищі. Повинна бути рівно одна версія з параметром storage=true.

    • versions.additionalPrinterColumns ([]CustomResourceColumnDefinition)

      Atomic: буде замінено під час злиття

      additionalPrinterColumns визначає додаткові стовпці, що повертаються в таблицях. Див. https://kubernetes.io/docs/reference/using-api/api-concepts/#receiving-resources-as-tables для деталей. Якщо стовпці не вказані, використовується один стовпець, що відображає вік власного ресурсу.

      CustomResourceColumnDefinition вказує стовпець для друку на стороні сервера.

      • versions.additionalPrinterColumns.jsonPath (string), обовʼязково

        jsonPath — простий шлях JSON (тобто з нотацією масиву), який оцінюється для кожного власного ресурсу для створення значення цього стовпця.

      • versions.additionalPrinterColumns.name (string), обовʼязково

        name — імʼя для стовпця зрозуміле людині.

      • versions.additionalPrinterColumns.type (string), обовʼязково

        type — визначення типу OpenAPI для цього стовпця. Див. https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#data-types для деталей.

      • versions.additionalPrinterColumns.description (string)

        description — опис цього стовпця зрозумілий людині.

      • versions.additionalPrinterColumns.format (string)

        format - є необовʼязковим визначенням типу OpenAPI для цього стовпця. Формат 'name' застосовується до стовпця первинного ідентифікатора, щоб допомогти клієнтам ідентифікувати стовпець — це імʼя ресурсу. Дивіться https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#data-types для більш детальної інформації.

      • versions.additionalPrinterColumns.priority (int32)

        priority — ціле число, що визначає відносну важливість цього стовпчика порівняно з іншими. Менші числа вважаються більш пріоритетними. Стовпці, які можуть бути пропущені в сценаріях з обмеженим простором, повинні мати пріоритет, більший за 0.

    • versions.deprecated (boolean)

      deprecated вказує, що ця версія API для власних ресурсів застаріла. Якщо встановлено значення true, запити API до цієї версії отримають заголовок попередження у відповіді сервера. Стандартне значення — false.

    • versions.deprecationWarning (string)

      deprecationWarning перевизначає стандартне попередження, що повертається клієнтам API. Може бути встановлене лише тоді, коли deprecated встановлено в true. Стандартне попередження вказує на те, що ця версія застаріла і рекомендує використовувати останню доступну версію з рівною або більшою стабільністю, якщо така існує.

    • versions.schema (CustomResourceValidation)

      schema описує схему, яка використовується для валідації, обрізання та встановлення стандартних значень для цієї версії власного ресурсу.

      CustomResourceValidation є переліком методів валідації для CustomResource.

      • versions.schema.openAPIV3Schema (JSONSchemaProps)

        openAPIV3Schema визначає схему OpenAPI v3 для валідації та обрізання власного ресурсу.

    • versions.selectableFields ([]SelectableField)

      Atomic: буде замінено під час злиття

      selectableFields визначає шляхи до полів, які можуть бути використані як селектори полів. Дозволяється використовувати максимум 8 вибіркових полів. https://kubernetes.io/docs/concepts/overview/working-with-objects/field-selectors

      SelectableField вказує шлях JSON до поля, яке може бути використане з селекторами полів.

      • versions.selectableFields.jsonPath (string), required

        jsonPath — це простий шлях JSON, який оцінюється для кожного власного ресурсу, щоб отримати значення селектора поля. Дозволяються лише JSON-шляхи без нотації масивів. Повинен вказувати на поле типу string, boolean або integer. Дозволяються типи з enum-значеннями та рядки з форматами. Якщо jsonPath посилається на відсутнє поле в ресурсі, він оцінюється як порожній рядок. Не повинен вказувати на поля метаданих. Обовʼязкове поле.

    • versions.subresources (CustomResourceSubresources)

      subresources вказують, які додаткові ресурси цієї версії визначеного власного ресурсу доступні.

      CustomResourceSubresources вказує, як оброляти мастшатабування субресурсів для CustomResource.

      • versions.subresources.scale.specReplicasPath (string), обовʼязково

        specReplicasPath визначає шлях JSON всередині власного ресурсу, який відповідає Scale spec.replicas. Допускаються тільки JSON-шляхи без нотації масиву. Повинен бути JSON-шлях у форматі .spec. Якщо у власному ресурсі немає значення за вказаним шляхом, субресурс /scale поверне помилку при виконанні GET.

      • versions.subresources.scale.statusReplicasPath (string), обовʼязково

        statusReplicasPath визначає шлях JSON всередині власного ресурсу, який відповідає Scale status.replicas. Допускаються лише JSON-шляхи без нотації масиву. Повинен бути JSON-шлях під .status. Якщо у власному ресурсі немає значення за вказаним шляхом, значення status.replicas у субресурсі /scale буде стандартно дорівнювати 0.

      • versions.subresources.scale.labelSelectorPath (string)

        labelSelectorPath визначає шлях JSON всередині власного ресурсу, який відповідає Scale status.selector. Допускаються лише JSON-шляхи без нотації масиву. Повинен бути JSON-шлях під .status або .spec. Має бути налаштований на роботу з HorizontalPodAutoscaler. Поле, на яке вказує цей JSON-шлях, має бути рядковим полем (не складною структурою селектора), яке містить серіалізований селектор міток у рядковій формі. Детальніше: https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions#scale-subresource Якщо у власному ресурсі немає значення за вказаним шляхом, значення status.selector у субресурсі /scale буде стандартно дорівнювати порожньому рядку.

      • versions.subresources.status (CustomResourceSubresourceStatus)

        status вказує, що власний ресурс має обслуговувати субресурс /status. Коли ввімкнено:

        1. запити до первинної точки доступу власного ресурсу ігнорують зміни в розділі status обʼєкта.
        2. Запити до субресурсу /status власного ресурсу ігнорують зміни будь-чого, окрім строфи status обʼєкта.

        CustomResourceSubresourceStatus визначає, як обслуговувати субресурс статусу для власних ресурсів. Статус представляється JSON-шляхом .status всередині власного ресурсу. Якщо встановлено,

        • відкриває субресурс /status для власного ресурсу
        • PUT-запити до субресурсу /status отримують обʼєкт власного ресурсу та ігнорують зміни у всьому, окрім рядка статусу
        • PUT/POST/PATCH запити до власного ресурсу ігнорують зміни у рядку стану
  • conversion (CustomResourceConversion)

    conversion визначає налаштування конвертації для CRD.

    CustomResourceConversion описує, як конвертувати різні версії CR.

    • conversion.strategy (string), обовʼязково

      strategy визначає, як налаштовуються власні ресурси між версіями. Допустимі значення:

      • "None": Конвертер змінює тільки apiVersion і не торкається інших полів у власному ресурсі.
      • "Webhook": API Server викликає зовнішній webhook для виконання конвертації. Додаткова інформація потрібна для цього варіанту. Це вимагає, щоб spec.preserveUnknownFields було встановлено у false, а spec.conversion.webhook було налаштовано.
    • conversion.webhook (WebhookConversion)

      webhook описує, як викликати конвертаційний webhook. Обовʼязково, якщо strategy встановлено на "Webhook".

      WebhookConversion описує, як викликати конвертаційний webhook

      • conversion.webhook.conversionReviewVersions ([]string), обовʼязково

        Atomic: буде замінено під час злиття

        conversionReviewVersions — впорядкований список пріоритетних версій ConversionReview, які очікує Webhook. API сервер використовує першу версію зі списку, яку він підтримує. Якщо жодна з версій, зазначених у цьому списку, не підтримується API сервером, конвертація для власного ресурсу не відбудеться. Якщо збережена конфігурація Webhook визначає дозволені версії та не включає жодної версії, відомої API серверу, виклики до webhook не будуть успішними.

      • conversion.webhook.clientConfig (WebhookClientConfig)

        clientConfig містить інструкції щодо виклику webhook, якщо strategy є Webhook.

        WebhookClientConfig містить інформацію для встановлення TLS-зʼєднання з webhook.

        • conversion.webhook.clientConfig.caBundle ([]byte)

          caBundle — PEM-кодований CA пакет, який буде використовуватися для перевірки сертифіката сервера webhook. Якщо не вказано, використовуються системні корені довіри на apiserver.

        • conversion.webhook.clientConfig.service (ServiceReference)

          service — це посилання на сервіс для цього webhook. Необхідно вказати або service, або url.

          Якщо webhook працює в межах кластера, слід використовувати service.

          ServiceReference містить посилання на Service.legacy.k8s.io

          • conversion.webhook.clientConfig.service.name (string), обовʼязково

            name — це імʼя сервісу. Обовʼязково

          • conversion.webhook.clientConfig.service.namespace (string), обовʼязково

            namespace — це простір імен сервісу. Обовʼязково

          • conversion.webhook.clientConfig.service.path (string)

            path — це необовʼязковий URL шлях, за яким буде контактуватися webhook.

          • conversion.webhook.clientConfig.service.port (int32)

            port — це необовʼязковий порт сервісу, за яким буде контактуватися webhook. port повинен бути дійсним номером порту (1-65535, включно). Стандартно встановлено 443 для зворотної сумісності.

        • conversion.webhook.clientConfig.url (string)

          url вказує місце розташування webhook у стандартній URL формі (scheme://host:port/path). Потрібно вказати точно один з url або service.

          host не повинен посилатися на сервіс, що працює в кластері; натомість використовуйте поле service. host може бути знайдений через зовнішній DNS на деяких apiservers (наприклад, kube-apiserver не може розвʼязати DNS у кластері, оскільки це було б порушенням рівнів). host також може бути IP-адресою.

          Зверніть увагу, що використання localhost або 127.0.0.1 як host ризиковано, якщо ви не вживаєте великої обережності, щоб запустити цей webhook на всіх хостах, які можуть потребувати викликів до цього webhook. Такі установки, ймовірно, будуть непереносними, тобто їх не легко переносити в новий кластер.

          Схема повинна бути "https"; URL повинен починатися з "https://".

          Шлях є необовʼязковим, і якщо присутній, може бути будь-яким рядком, допустимим в URL. Ви можете використовувати шлях для передачі довільного рядка до webhook, наприклад, ідентифікатора кластера.

          Спроба використати автентифікацію користувача або базову автентифікацію, наприклад, "user:password@" не дозволена. Фрагменти ("#...") та параметри запиту ("?...") також не дозволені.

  • preserveUnknownFields (boolean)

    preserveUnknownFields вказує, що поля обʼєкта, які не зазначені в схемі OpenAPI, повинні зберігатися під час зберігання. apiVersion, kind, metadata та відомі поля всередині metadata завжди зберігаються. Це поле застаріле і замість нього слід встановлювати x-preserve-unknown-fields на true в spec.versions[*].schema.openAPIV3Schema. Деталі дивіться на https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#field-pruning.

JSONSchemaProps

JSONSchemaProps є JSON-схемою, яка відповідає Специфікації Draft 4 (http://json-schema.org/).


  • $ref (string)

  • $schema (string)

  • additionalItems (JSONSchemaPropsOrBool)

    JSONSchemaPropsOrBool представляє JSONSchemaProps або булеве значення. Стандартно встановлюється у true для булевого значення.

  • additionalProperties (JSONSchemaPropsOrBool)

    JSONSchemaPropsOrBool представляє JSONSchemaProps або булеве значення. Стандартно встановлюється у true для булевого значення.

  • allOf ([]JSONSchemaProps)

    Atomic: буде замінено під час злиття

  • anyOf ([]JSONSchemaProps)

    Atomic: буде замінено під час злиття

  • default (JSON)

    default є стандартним значенням для невизначених полів обʼєкта. Використання стандартних значень є бета-функцією у функціональних можливостей CustomResourceDefaulting. Використання стандартних значень вимагає, щоб spec.preserveUnknownFields було встановлено у false.

    JSON представляє будь-яке допустиме значення JSON. Підтримуються такі типи: bool, int64, float64, string, []interface{}, map[string]interface{} та nil.

  • definitions (map[string]JSONSchemaProps)

  • dependencies (map[string]JSONSchemaPropsOrStringArray)

    JSONSchemaPropsOrStringArray представляє JSONSchemaProps або масив рядків.

  • description (string)

  • enum ([]JSON)

    Atomic: буде замінено під час злиття

    JSON представляє будь-яке допустиме значення JSON. Підтримуються такі типи: bool, int64, float64, string, []interface{}, map[string]interface{} та nil.

  • example (JSON)

    JSON представляє будь-яке допустиме значення JSON. Підтримуються такі типи: bool, int64, float64, string, []interface{}, map[string]interface{} та nil.

  • exclusiveMaximum (boolean)

  • exclusiveMinimum (boolean)

  • externalDocs (ExternalDocumentation)

    ExternalDocumentation дозволяє посилатися на зовнішній ресурс для розширеної документації.

    • externalDocs.description (string)

    • externalDocs.url (string)

  • format (string)

    format — це рядок формату OpenAPI v3. Невідомі формати ігноруються. Наступні формати перевіряються:

    • bsonobjectid: BSON Object ID, тобто 24-символьний шістнадцятковий рядок
    • uri: URI, який розбирається за допомогою Golang net/url.ParseRequestURI
    • email: адреса електронної пошти, яка розбирається за допомогою Golang net/mail.ParseAddress
    • hostname: дійсне представлення імені хоста в Інтернеті, визначене RFC 1034, розділ 3.1 [RFC1034]
    • ipv4: IPv4 IP, який розбирається за допомогою Golang net.ParseIP
    • ipv6: IPv6 IP, який розбирається за допомогою Golang net.ParseIP
    • cidr: CIDR, який розбирається за допомогою Golang net.ParseCIDR
    • Mac: MAC-адреса, яка розбирається за допомогою Golang net.ParseMAC
    • uuid: UUID, який дозволяє великі літери та визначається регулярним виразом (?i)^[0-9a-f]{8}-?[0-9a-f]{4}-?[0-9a-f]{4}-?[0-9a-f]{4}-?[0-9a-f]{12}$
    • uuid3: UUID3, який дозволяє великі літери та визначається регулярним виразом (?i)^[0-9a-f]{8}-?[0-9a-f]{4}-?3[0-9a-f]{3}-?[0-9a-f]{4}-?[0-9a-f]{12}$
    • uuid4: UUID4, який дозволяє великі літери та визначається регулярним виразом (?i)^[0-9a-f]{8}-?[0-9a-f]{4}-?4[0-9a-f]{3}-?[89ab][0-9a-f]{3}-?[0-9a-f]{12}$
    • uuid5: UUID5, який дозволяє великі літери та визначається регулярним виразом (?i)^[0-9a-f]{8}-?[0-9a-f]{4}-?5[0-9a-f]{3}-?[89ab][0-9a-f]{3}-?[0-9a-f]{12}$
    • isbn: номер ISBN10 або ISBN13, наприклад, "0321751043" або "978-0321751041"
    • isbn10: номер ISBN10, наприклад, "0321751043"
    • isbn13: номер ISBN13, наприклад, "978-0321751041"
    • creditcard: номер кредитної картки, який визначається регулярним виразом ^(?:4[0-9]{12}(?:[0-9]{3})?|5[1-5][0-9]{14}|6(?:011|5[0-9][0-9])[0-9]{12}|3[47][0-9]{13}|3(?:0[0-5]|[68][0-9])[0-9]{11}|(?:2131|1800|35\d{3})\d{11})$ з будь-якими нецифровими символами
    • ssn: номер соціального страхування США, який відповідає регулярному виразу ^\d{3}[- ]?\d{2}[- ]?\d{4}$
    • hexcolor: шістнадцятковий код кольору, наприклад, "#FFFFFF", який відповідає регулярному виразу ^#?([0-9a-fA-F]{3}|[0-9a-fA-F]{6})$
    • rgbcolor: код кольору RGB, наприклад, "rgb(255,255,255)"
    • byte: двійкові дані, закодовані в base64
    • password: будь-який тип рядка
    • date: рядок дати, наприклад, "2006-01-02", як визначено у full-date у RFC3339
    • duration: рядок тривалості, наприклад, "22 ns", який розбирається за допомогою Golang time.ParseDuration або сумісний з форматом тривалості Scala
    • datetime: рядок дати і часу, наприклад, "2014-12-15T19:30:20.000Z", як визначено у date-time у RFC3339
  • id (string)

  • items (JSONSchemaPropsOrArray)

    JSONSchemaPropsOrArray представляє значення, яке може бути JSONSchemaProps або масивом JSONSchemaProps. Переважно використовується для цілей серіалізації.

  • maxItems (int64)

  • maxLength (int64)

  • maxProperties (int64)

  • maximum (double)

  • minItems (int64)

  • minLength (int64)

  • minProperties (int64)

  • minimum (double)

  • multipleOf (double)

  • not (JSONSchemaProps)

  • nullable (boolean)

  • oneOf ([]JSONSchemaProps)

Atomic: буде замінено під час злиття

  • pattern (string)

  • patternProperties (map[string]JSONSchemaProps)

  • properties (map[string]JSONSchemaProps)

  • required ([]string)

    Atomic: буде замінено під час злиття

  • title (string)

  • type (string)

  • uniqueItems (boolean)

  • x-kubernetes-embedded-resource (boolean)

    x-kubernetes-embedded-resource визначає, що значення є вбудованим обʼєктом Kubernetes runtime.Object, з TypeMeta та ObjectMeta. Тип має бути object. Дозволяється подальше обмеження вбудованого обʼєкта. kind, apiVersion та metadata перевіряються автоматично. x-kubernetes-preserve-unknown-fields може бути true, але це не обовʼязково, якщо обʼєкт повністю вказаний (аж до kind, apiVersion, metadata).

  • x-kubernetes-int-or-string (boolean)

    x-kubernetes-int-or-string вказує, що це значення є або цілим числом, або рядком. Якщо це true, дозволено порожній тип, а тип як нащадок anyOf дозволений, якщо дотримується один з наступних шаблонів:

    1. anyOf:
      • type: integer
      • type: string
    2. allOf:
      • anyOf:
        • type: integer
        • type: string
      • ... нуль або більше
  • x-kubernetes-list-map-keys ([]string)

    Atomic: буде замінено під час злиття

    x-kubernetes-list-map-keys анотує масив з типом списку x-kubernetes map, вказуючи ключі, які використовуються як індекс map.

    Цей теґ МАЄ використовуватися тільки для списків, які мають розширення "x-kubernetes-list-type" встановлене на "map". Також значення, вказані для цього атрибута, мають бути полем типу scalar структури нащадка (вкладення не підтримується).

    Властивості, зазначені у цьому полі, повинні бути або обовʼязковими, або мати стандартне значення, щоб забезпечити наявність цих властивостей для всіх елементів списку.

  • x-kubernetes-list-type (string)

    x-kubernetes-list-type анотує масив, щоб більш детально описати його топологію. Це розширення має використовуватися тільки для списків і може мати 3 можливі значення:

    1. atomic: список розглядається як єдине ціле, як скаляр. Списки atomic будуть повністю замінені при оновленні. Це розширення може використовуватися для будь-якого типу списків (структур, скалярів тощо).
    2. set: Набори — це списки, які не повинні мати кілька елементів з однаковим значенням. Кожне значення повинно бути скаляром, обʼєктом з x-kubernetes-map-type atomic або масивом з x-kubernetes-list-type atomic.
    3. map: Ці списки схожі на map тим, що їх елементи мають неіндексований ключ, який використовується для їх ідентифікації. Порядок зберігається при злитті. Теґ map має використовуватися тільки для списків з елементами типу object. Стандартне значення для масивів — atomic.
  • x-kubernetes-map-type (string)

    x-kubernetes-map-type анотує обʼєкт, щоб більш детально описати його топологію. Це розширення має використовуватися тільки, коли тип обʼєкта є object і може мати 2 можливі значення:

    1. granular: Ці maps є справжніми map (пари ключ-значення) і кожне поле незалежне одне від одного (їх можна маніпулювати окремими акторами). Це стандартн поведінка для всіх map.
    2. atomic: список розглядається як єдине ціле, як скаляр. Atomic maps будуть повністю замінені при оновленні.
  • x-kubernetes-preserve-unknown-fields (boolean)

    x-kubernetes-preserve-unknown-fields зупиняє етап декодування на сервері API від видалення полів, які не вказані у схемі перевірки. Це впливає на поля рекурсивно, але повертається до нормальної поведінки видалення, якщо вкладені властивості або додаткові властивості вказані у схемі. Це може бути true або не визначено. Використання false заборонено.

  • x-kubernetes-validations

    Patch strategy: злиття за ключем rule.

    Map: унікальні значення ключа rule будуть збережені під час злиття.

    x-kubernetes-validations описує список правил валідації записаних мовою CEL.

    ValidationRule описує правило валідації записане мовою CEL.

    • x-kubernetes-validations.rule (string), обовʼязково

      Правило (rule) представляє вираз, який буде оцінюватися за допомогою CEL. Докладніше: https://github.com/google/cel-spec. Правило обмежується місцем розташування розширення x-kubernetes-validations у схемі. Змінна self у виразі CEL привʼязана до обмеженого значення. Приклад:

      • Правило обмежене коренем ресурсу з субресурсом status: {"rule": "self.status.actual <= self.spec.maxDesired"}

      Якщо Правило обмежене обʼєктом з властивостями, доступні властивості обʼєкта вибираються через self.field, а наявність поля можна перевірити через has(self.field). Поля з нульовим значенням розглядаються як відсутні поля у виразах CEL. Якщо Правило обмежене обʼєктом з additionalProperties (тобто map), значення map доступні через self[mapKey], наявність ключа в map можна перевірити через mapKey in self, а всі записи map доступні через макроси та функції CEL, такі як self.all(...). Якщо Правило обмежене масивом, елементи масиву доступні через self[i], а також через макроси та функції. Якщо Правило обмежене скаляром, self привʼязується до значення скаляра. Приклади:

      • Правило обмежене картою обʼєктів: {"rule": "self.components['Widget'].priority < 10"}
      • Правило обмежене списком цілих чисел: {"rule": "self.values.all(value, value >= 0 && value < 100)"}
      • Правило обмежене рядковим значенням: {"rule": "self.startsWith('kube')"}

      apiVersion, kind, metadata.name та metadata.generateName завжди доступні з кореня обʼєкта та з будь-яких обʼєктів, позначених як x-kubernetes-embedded-resource. Жодні інші властивості метаданих не доступні.

      Невідомі дані, збережені у власних ресурсах через x-kubernetes-preserve-unknown-fields, не доступні у виразах CEL. Це включає:

      • Невідомі значення полів, що зберігаються схемами обʼєктів з x-kubernetes-preserve-unknown-fields.

      • Властивості обʼєкта, де схема властивості має "невідомий тип". "Невідомий тип" рекурсивно визначається як:

      • Схема без типу і з x-kubernetes-preserve-unknown-fields встановленим у true

      • Масив, де схема елементів має "невідомий тип"

      • Обʼєкт, де схема additionalProperties має "невідомий тип"

      Доступні лише імена властивостей формату [a-zA-Z_.-/][a-zA-Z0-9_.-/]*. Доступні імена властивостей екрануються за наступними правилами, коли до них звертаються у виразі:

      • '__' екранується як 'underscores'
      • '.' екранується як 'dot'
      • '-' екранується як 'dash'
      • '/' екранується як 'slash'
      • Імена властивостей, які точно збігаються з зарезервованими ключовими словами CEL, екрануються як '{keyword}'. Ключові слова: "true", "false", "null", "in", "as", "break", "const", "continue", "else", "for", "function", "if", "import", "let", "loop", "package", "namespace", "return".

      Приклади:

      • Правило, яке звертається до властивості з імʼям "namespace": {"rule": "self.namespace > 0"}
      • Правило, яке звертається до властивості з імʼям "x-prop": {"rule": "self.x__dash__prop > 0"}
      • Правило, яке звертається до властивості з імʼям "redact__d": {"rule": "self.redact__underscores__d > 0"}

      Рівність масивів з x-kubernetes-list-type 'set' або 'map' ігнорує порядок елементів, тобто [1, 2] == [2, 1]. Конкатенація масивів з x-kubernetes-list-type використовує семантику типу списку:

      • 'set': X + Y виконує обʼєднання, де позиції масиву всіх елементів у X зберігаються, а елементи в Y, що не перетинаються, додаються зі збереженням їх часткового порядку.
      • 'map': X + Y виконує злиття, де позиції масиву всіх ключів у X зберігаються, але значення замінюються значеннями в Y, коли набори ключів X та Y перетинаються. Елементи в Y з ключами, що не перетинаються з ключами, додаються зі збереженням їх часткового порядку.

      Якщо в rule використовується змінна oldSelf, це неявно означає, що це "правило переходу" (transition rule).

      Стандартно, змінна oldSelf має той самий тип, що й self. Коли параметр optionalOldSelf встановлено як true, змінна oldSelf стає CEL-варіантом (optional), і її метод value() матиме той самий тип, що й self. Деталі можна знайти в документації до поля optionalOldSelf.

      Правила переходу стандартно застосовуються лише до запитів UPDATE і пропускаються, якщо старе значення не було знайдено. Ви можете налаштувати безумовну оцінку правила переходу, встановивши optionalOldSelf як true.

    • x-kubernetes-validations.fieldPath (string)

      fieldPath представляє шлях до поля, що повертається, коли перевірка не вдається. Він має бути відносним JSON шляхом (тобто з нотацією масиву), обмеженим місцем розташування цього розширення x-kubernetes-validations у схемі та посилатися на існуюче поле. Наприклад, коли перевірка перевіряє, чи існує певний атрибут foo в map testMap, fieldPath може бути встановлений як .testMap.foo. Якщо перевірка перевіряє, що два списки повинні мати унікальні атрибути, fieldPath може бути встановлений як будь-який зі списків: наприклад, .testList. Він не підтримує числовий індекс списку. Він підтримує операції з дочірніми елементами для посилання на існуюче поле. Для отримання додаткової інформації дивіться Підтримка JSONPath у Kubernetes. Числовий індекс масиву не підтримується. Для імені поля, що містить спеціальні символи, використовуйте ['specialName'] для посилання на імʼя поля. Наприклад, для атрибута foo.34$, що зʼявляється у списку testList, fieldPath може бути встановлений як .testList['foo.34$'].

    • x-kubernetes-validations.message (string)

      message представляє повідомлення, яке відображається, коли перевірка не вдається. Повідомлення є обовʼязковим, якщо у Правилі є розриви рядків. Повідомлення не повинно містити розривів рядків. Якщо не встановлено, повідомлення буде "failed rule: {Rule}". Наприклад, "must be a URL with the host matching spec.host".

  • x-kubernetes-validations.messageExpression (string)

    messageExpression оголошує вираз CEL, який оцінюється як повідомлення про помилку перевірки, яке повертається, коли це правило не вдається. Оскільки messageExpression використовується як повідомлення про помилку, він повинен оцінюватися як рядок. Якщо і message, і messageExpression присутні у правилі, тоді messageExpression буде використаний у разі невдалої перевірки. Якщо messageExpression призводить до помилки під час виконання, ця помилка записується в лог, і повідомлення про помилку перевірки створюється так, ніби поле messageExpression не встановлено. Якщо messageExpression оцінюється як порожній рядок, рядок, що містить лише пробіли, або рядок, що містить розриви рядків, то повідомлення про помилку перевірки також створюється так, ніби поле messageExpression не встановлено, і факт того, що messageExpression створив порожній рядок/рядок з пробілами/рядок з розривами рядків, записується в лог. messageExpression має доступ до всіх тих же змінних, що й правило; єдина відмінність — тип значення, що повертається. Приклад: "x must be less than max ("+string(self.max)+")".

    • x-kubernetes-validations.optionalOldSelf (boolean)

      optionalOldSelf використовується для того, щоб активувати оцінку правила переходу навіть під час першого створення обʼєкта або коли старий обʼєкт не містить значення.

      Коли цей параметр увімкнено, змінна oldSelf стає CEL-варіантом (optional), значенням якого буде None, якщо старе значення відсутнє або обʼєкт створюється вперше.

      Ви можете перевірити наявність значення у oldSelf за допомогою методу oldSelf.hasValue() і розпакувати його після перевірки за допомогою oldSelf.value(). Більше інформації можна знайти в документації CEL щодо типів Optional: https://pkg.go.dev/github.com/google/cel-go/cel#OptionalTypes

      Цей параметр не може бути встановлений, якщо oldSelf не використовується в rule.

  • x-kubernetes-validations.reason (string)

    reason забезпечує машинозчитувану причину невдачі перевірки, яка повертається до абонента, коли запит не проходить це правило перевірки. Код стану HTTP, що повертається до абонента, буде відповідати причині першого невдалого правила перевірки. Поточні підтримувані причини: "FieldValueInvalid", "FieldValueForbidden", "FieldValueобовʼязково", "FieldValueDuplicate". Якщо не встановлено, стандартно використовується "FieldValueInvalid". Усі майбутні додані причини повинні прийматися клієнтами при читанні цього значення, а невідомі причини повинні оброблятися як FieldValueInvalid.

CustomResourceDefinitionStatus

CustomResourceDefinitionStatus вказує стан CustomResourceDefinition.


  • acceptedNames (CustomResourceDefinitionNames)

    acceptedNames — це імена, які фактично використовуються для обслуговування виявлення ресурсів. Вони можуть відрізнятися від імен у специфікації.

    CustomResourceDefinitionNames вказує імена для обслуговування цього CustomResourceDefinition

    • acceptedNames.kind (string), обовʼязково

      kind — серіалізоване імʼя типу ресурсу. Зазвичай CamelCase в однині. Екземпляри спеціальних ресурсів будуть використовувати це значення як атрибут kind у викликах API.

    • acceptedNames.plural (string), обовʼязково

      plural — імʼя ресурсу для обслуговування в множині. Спеціальні ресурси обслуговуються як /apis/\<group>/\<version>/.../\<plural>. Має відповідати імені CustomResourceDefinition (у формі \<names.plural>.\<group>). Має бути в нижньому регістрі.

    • acceptedNames.categories ([]string)

      Atomic: буде замінено під час злиття

      categories — це список згрупованих ресурсів, до яких належить цей власний ресурс (наприклад, 'all'). Публікується у документах виявлення API і використовується клієнтами для підтримки викликів типу kubectl get all.

    • acceptedNames.listKind (string)

      listKind — серіалізоване імʼя списку для цього ресурсу. Стандартне значення — "kindList".

    • acceptedNames.shortNames ([]string)

      Atomic: буде замінено під час злиття

      shortNames — короткі імена для ресурсу, які відображаються в документах виявлення API і використовуються клієнтами для підтримки викликів типу kubectl get \<shortname>. Мають бути в нижньому регістрі.

    • acceptedNames.singular (string)

      singular — імʼя ресурсу в однині. Має бути в нижньому регістрі. Стандартно використовується нижній регістр kind.

  • conditions ([]CustomResourceDefinitionCondition)

    Map: унікальні значення за типом ключа будуть збережені під час злиття

    conditions — вказують стан для окремих аспектів CustomResourceDefinition

    CustomResourceDefinitionCondition містить деталі поточного стану цього CustomResourceDefinition.

    • conditions.status (string), обовʼязково

      status — статус стану. Може бути True, False або Unknown.

    • conditions.type (string), обовʼязково

      type — тип стану. Типи включають Established, NamesAccepted і Terminating.

    • conditions.lastTransitionTime (Time)

      lastTransitionTime — час останньої зміни стану з одного статусу в інший.

      Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

    • conditions.message (string)

      message — текст, зрощумілий людині, що вказує деталі останньої зміни стану.

    • conditions.reason (string)

      reason — унікальна однозначна причина в CamelCase для останньої зміни стану.

  • storedVersions ([]string)

    Atomic: буде замінено під час злиття

    storedVersions перераховує всі версії CustomResources, які коли-небудь зберігалися. Відстеження цих версій дозволяє визначити шлях міграції для збережених версій в etcd. Поле є змінним, тому контролер міграції може завершити міграцію до іншої версії (переконавшись, що у сховищі не залишилося старих обʼєктів), а потім видалити решту версій з цього списку. Версії не можна видаляти з spec.versions, доки вони існують у цьому списку.

CustomResourceDefinitionList

CustomResourceDefinitionList є списком обʼєктів CustomResourceDefinition.


Операції


get отримати вказаний CustomResourceDefinition

HTTP запит

GET /apis/apiextensions.k8s.io/v1/customresourcedefinitions/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя CustomResourceDefinition

  • pretty (в запиті): string

    pretty

Відповідь

200 (CustomResourceDefinition): OK

401: Unauthorized

get отримати статус вказаного CustomResourceDefinition

HTTP запит

GET /apis/apiextensions.k8s.io/v1/customresourcedefinitions/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя CustomResourceDefinition

  • pretty (в запиті): string

    pretty

Відповідь

200 (CustomResourceDefinition): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу CustomResourceDefinition

HTTP запит

GET /apis/apiextensions.k8s.io/v1/customresourcedefinitions

Параметри

Відповідь

200 (CustomResourceDefinitionList): OK

401: Unauthorized

create створення CustomResourceDefinition

HTTP запит

POST /apis/apiextensions.k8s.io/v1/customresourcedefinitions

Параметри

Відповідь

200 (CustomResourceDefinition): OK

201 (CustomResourceDefinition): Created

202 (CustomResourceDefinition): Accepted

401: Unauthorized

update заміна вказаного CustomResourceDefinition

HTTP запит

PUT /apis/apiextensions.k8s.io/v1/customresourcedefinitions/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя CustomResourceDefinition

  • body: CustomResourceDefinition, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (CustomResourceDefinition): OK

201 (CustomResourceDefinition): Created

401: Unauthorized

update заміна статусу вказаного CustomResourceDefinition

HTTP запит

PUT /apis/apiextensions.k8s.io/v1/customresourcedefinitions/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя CustomResourceDefinition

  • body: CustomResourceDefinition, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (CustomResourceDefinition): OK

201 (CustomResourceDefinition): Created

401: Unauthorized

patch часткове оновлення вказаного CustomResourceDefinition

HTTP запит

PATCH /apis/apiextensions.k8s.io/v1/customresourcedefinitions/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя CustomResourceDefinition

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (CustomResourceDefinition): OK

201 (CustomResourceDefinition): Created

401: Unauthorized

patch часткове оновлення статусу вказаного CustomResourceDefinition

HTTP запит

PATCH /apis/apiextensions.k8s.io/v1/customresourcedefinitions/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя CustomResourceDefinition

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (CustomResourceDefinition): OK

201 (CustomResourceDefinition): Created

401: Unauthorized

delete видалення CustomResourceDefinition

HTTP запит

DELETE /apis/apiextensions.k8s.io/v1/customresourcedefinitions/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя CustomResourceDefinition

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції CustomResourceDefinition

HTTP запит

DELETE /apis/apiextensions.k8s.io/v1/customresourcedefinitions

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

6.5.7.2 - DeviceClass v1alpha3

DeviceClass — це ресурс, наданий постачальником або адміністратором, який містить конфігурацію пристрою та селектори.

apiVersion: resource.k8s.io/v1alpha3

import "k8s.io/api/resource/v1alpha3"

DeviceClass

DeviceClass — це ресурс, наданий постачальником або адміністратором, який містить конфігурацію пристрою та селектори. На нього можна посилатися у запитах до пристрою, щоб застосувати ці пресети. Охоплює кластер.

Це альфа-тип і вимагає увімкнення функціональної можливості DynamicResourceAllocation.


  • apiVersion: resource.k8s.io/v1alpha3

  • kind: DeviceClass

  • metadata (ObjectMeta)

    Стандартний обʼєкт метаданих

  • spec (DeviceClassSpec), обовʼязково

    Spec визначає, що можна призначити і як це налаштувати.

    Поле є змінюваним. Споживачі повинні бути готові до того, що класи можуть змінюватися в будь-який час, як через оновлення, так і через заміну. Розподілення заявок виконується один раз на основі того, що було встановлено в класах на момент виділення.

    Зміна spec автоматично збільшує номер metadata.generation.

DeviceClassSpec

DeviceClassSpec використовується в [DeviceClass] для визначення того, що може бути призначено і як це налаштувати.


  • config ([]DeviceClassConfiguration)

    Atomic: буде замінено під час злиття

    Config визначає параметри конфігурації, які застосовуються до кожного пристрою, що описується у цьому класі. Деякі класи потенційно можуть задовольнятися кількома драйверами, тому кожен екземпляр конфігурації постачальника застосовується лише до одного драйвера.

    Вони передаються драйверу, але не враховуються при розподілі заявки.

    DeviceClassConfiguration використовується в DeviceClass.

    • config.opaque (OpaqueDeviceConfiguration)

      Opaque надає специфічні для драйвера параметри конфігурації.

      OpaqueDeviceConfiguration містить параметри конфігурації драйвера у форматі, визначеному постачальником драйвера.

      • config.opaque.driver (string), обовʼязково

        Driver використовується для визначення, в який втулок kubelet потрібно передати ці параметри конфігурації.

        Політика допуску, надана розробником драйвера, може використовувати це для прийняття рішення про те, чи потрібно перевіряти їх.

        Повинен бути DNS піддоменом і закінчуватися на DNS домен, що належить постачальнику драйвера.

      • config.opaque.parameters (RawExtension), обовʼязково

        Параметри можуть містити довільні дані. Відповідальність за перевірку та керування версіями покладається на розробника драйверів. Зазвичай це включає самоідентифікацію та версію ("kind" + "apiVersion" для типів Kubernetes), а також конвертацію між різними версіями.

        RawExtension використовується для зберігання розширень у зовнішніх версіях.

        Щоб використовувати це, створіть поле, яке має тип RawExtension у вашій зовнішній, версійованій структурі, і Object у вашій внутрішній структурі. Також потрібно зареєструвати ваші різні типи втулків.

        // Внутрішній пакунок:

        type MyAPIObject struct {
        	runtime.TypeMeta `json:",inline"`
        	MyPlugin runtime.Object `json:"myPlugin"`
        }
        
        type PluginA struct {
        	AOption string `json:"aOption"`
        }
        

        // Зовнішній пакунок:

        type MyAPIObject struct {
        	runtime.TypeMeta `json:",inline"`
        	MyPlugin runtime.RawExtension `json:"myPlugin"`
        }
        
        type PluginA struct {
        	AOption string `json:"aOption"`
        }
        

        // Готовий JSON буде виглядати приблизно так:

        {
        	"kind":"MyAPIObject",
        	"apiVersion":"v1",
        	"myPlugin": {
        		"kind":"PluginA",
        		"aOption":"foo",
        	},
        }
        

        Що відбувається? Спочатку декодування використовує json або yaml для десеріалізації даних у ваш зовнішній MyAPIObject. Це призводить до зберігання необробленого JSON, але без розпакування. Наступний крок — копіювання (за допомогою pkg/conversion) у внутрішню структуру. Функції перетворення, встановлені в DefaultScheme пакета runtime, розпаковують JSON, збережений у RawExtension, перетворюючи його в правильний тип обʼєкта і зберігаючи його в Object. (TODO: У випадку, коли обʼєкт має невідомий тип, буде створено і збережено обʼєкт runtime.Unknown.)

  • selectors ([]DeviceSelector)

    Atomic: буде замінено під час злиття

    Кожному селектору повинен відповідати пристрій, що заявляється в цьому класі.

    DeviceSelector повинен мати рівно одне встановлене поле.

    • selectors.cel (CELDeviceSelector)

      CEL містить вираз CEL для вибору пристрою.

      CELDeviceSelector містить вираз CEL для вибору пристрою.

      • selectors.cel.expression (string), обовʼязковий

        Вираз є виразом CEL, який оцінює один пристрій. Він має оцінюватися як true, коли пристрій відповідає бажаним критеріям, і як false, коли не відповідає. Будь-який інший результат є помилкою і призводить до зупинки надання пристроїв.

        Вхідні дані виразу — це обʼєкт з назвою "device", який має наступні властивості:

        • driver (рядок): імʼя драйвера, який визначає цей пристрій.
        • attributes (map[string]object): атрибути пристрою, згруповані за префіксом (наприклад, device.attributes["dra.example.com"] оцінюється як обʼєкт з усіма атрибутами, які були префіксовані "dra.example.com").
        • capacity (map[string]object): обсяги пристрою, згруповані за префіксом.

        Приклад: Розглянемо пристрій з driver="dra.example.com", який надає два атрибути з назвою "model" та "ext.example.com/family" і один обсяг з назвою "modules". Вхідні дані для цього виразу будуть мати такі поля:

        device.driver
        device.attributes["dra.example.com"].model
        device.attributes["ext.example.com"].family
        device.capacity["dra.example.com"].modules
        

        Поле device.driver можна використовувати для перевірки конкретного драйвера, або як загальну попередню умову (тобто ви хочете розглядати лише пристрої від цього драйвера), або як частину виразу з кількома умовами, який призначений для розгляду пристроїв з різних драйверів.

        Тип значення кожного атрибута визначається визначенням пристрою, і користувачі, які пишуть ці вирази, повинні звертатися до документації для своїх конкретних драйверів. Тип значення кожного обсягу — Quantity.

        Якщо невідомий префікс використовується для запиту в device.attributes або device.capacity, буде повернено порожній map. Будь-яке посилання на невідоме поле спричинить помилку оцінки і зупинку виділення.

        Робочий вираз має перевіряти наявність атрибутів перед їх використанням.

        Для зручності використання доступна функція cel.bind(), яка може бути використана для спрощення виразів, що звертаються до кількох атрибутів з одного домену. Наприклад:

        cel.bind(dra, device.attributes["dra.example.com"], dra.someBool && dra.anotherBool)
        
  • suitableNodes (NodeSelector)

    Лише вузли, що відповідають селектору, будуть враховуватися планувальником при спробі знайти Вузол, що підходить для Podʼа, коли цей Pod використовує запит, який ще не був виділений і цей запит виділяється через контролер панелі управління. Він ігнорується, коли запит не використовує контролер панелі управління для виділення.

    Налаштування цього поля є необовʼязковим. Якщо не задано, всі Вузли є кандидатами.

    Це поле є альфа-версією і потребує увімкнення функціональної можливості DRAControlPlaneController.

    Селектор вузлів представляє об'єднання результатів одного або кількох запитів міток над набором вузлів; тобто, він представляє OR (логічне "або") селекторів, що представлені термінами селектора вузлів.

    • suitableNodes.nodeSelectorTerms ([]NodeSelectorTerm), обов'язково

      Atomic: буде замінено під час злиття

      Обов'язковий параметр. Список термів селектора вузлів. Терми обʼєднуються оператором OR.

      Null або порожній термін селектора вузла не відповідає жодному об'єкту. Вимоги до них складаються за принципом AND. Тип TopologySelectorTerm реалізує підмножину NodeSelectorTerm.

      • suitableNodes.nodeSelectorTerms.matchExpressions ([]NodeSelectorRequirement)

        Atomic: буде замінено під час злиття

        Список вимог до селектора вузлів за мітками вузлів.

      • suitableNodes.nodeSelectorTerms.matchFields ([]NodeSelectorRequirement)

        Atomic: буде замінено під час злиття

        Список вимог до селектора вузла за полями вузла.

DeviceClassList

DeviceClassList — це колекція класів.


  • apiVersion: resource.k8s.io/v1alpha3

  • kind: DeviceClassList

  • metadata (ListMeta)

    Стандартні метадані списку

  • items ([]DeviceClass), обовʼязково

    Items —список класів ресурсів.

Operations


get отримати вказаний DeviceClass

HTTP запит

GET /apis/resource.k8s.io/v1alpha3/deviceclasses/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя DeviceClass

  • pretty (в запиті): string

    pretty

Відповідь

200 (DeviceClass): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу DeviceClass

HTTP запит

GET /apis/resource.k8s.io/v1alpha3/deviceclasses

Параметри

Відповідь

200 (DeviceClassList): OK

401: Unauthorized

create створення DeviceClass

HTTP запит

POST /apis/resource.k8s.io/v1alpha3/deviceclasses

Параметри

Відповідь

200 (DeviceClass): OK

201 (DeviceClass): Created

202 (DeviceClass): Accepted

401: Unauthorized

update заміна вказаного DeviceClass

HTTP запит

PUT /apis/resource.k8s.io/v1alpha3/deviceclasses/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя DeviceClass

  • body: DeviceClass, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (DeviceClass): OK

201 (DeviceClass): Created

401: Unauthorized

patch часткове оновлення вказаного DeviceClass

HTTP запит

PATCH /apis/resource.k8s.io/v1alpha3/deviceclasses/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя DeviceClass

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (DeviceClass): OK

201 (DeviceClass): Created

401: Unauthorized

delete видалення DeviceClass

HTTP запит

DELETE /apis/resource.k8s.io/v1alpha3/deviceclasses/{name}

Параметри

Відповідь

200 (DeviceClass): OK

202 (DeviceClass): Accepted

401: Unauthorized

deletecollection видалення колекції DeviceClass

HTTP запит

DELETE /apis/resource.k8s.io/v1alpha3/deviceclasses

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

6.5.7.3 - MutatingWebhookConfiguration

MutatingWebhookConfiguration описує конфігурацію вебхука, який приймає або відхиляє і може змінювати обʼєкт.

apiVersion: admissionregistration.k8s.io/v1

import "k8s.io/api/admissionregistration/v1"

MutatingWebhookConfiguration

MutatingWebhookConfiguration описує конфігурацію вебхука, який приймає або відхиляє і може змінювати обʼєкт.


  • apiVersion: admissionregistration.k8s.io/v1

  • kind: MutatingWebhookConfiguration

  • metadata (ObjectMeta)

    Стандартний обʼєкт метаданих; Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata.

  • webhooks ([]MutatingWebhook)

    Patch strategy: злиття за ключем name

    Map: унікальні значення ключа name будуть збережені під час злиття

    Webhooks — це список вебхуків та відповідних ресурсів і операцій.

    MutatingWebhook описує вебхук допуску та ресурси й операції, до яких він застосовується.

    • webhooks.admissionReviewVersions ([]string), обовʼязково

      Atomic: буде замінено під час злиття

      AdmissionReviewVersions — це впорядкований список версій AdmissionReview, які очікує вебхук. Сервер API спробує використати першу версію зі списку, яку він підтримує. Якщо жодна з вказаних версій не підтримується сервером API, перевірка цього обʼєкта зазнає невдачі. Якщо збережена конфігурація вебхука вказує дозволені версії, але не включає жодної версії, відомої серверу API, виклики до вебхука зазнають невдачі й підпадають під політику відмови.

    • webhooks.clientConfig (WebhookClientConfig), обовʼязково

      ClientConfig визначає, як спілкуватися з вебхуком. Обовʼязково.

      WebhookClientConfig містить інформацію для встановлення TLS-зʼєднання з вебхуком.

      • webhooks.clientConfig.caBundle ([]byte)

        caBundle — це закодований у PEM набір сертифікатів CA, який використовуватиметься для перевірки сертифіката сервера вебхука. Якщо не вказано, використовуються системні корені довіри на сервері API.

      • webhooks.clientConfig.service (ServiceReference)

        service — це посилання на сервіс для цього вебхука. Необхідно вказати або service, або url.

        Якщо вебхук працює в межах кластера, то слід використовувати service.

        ServiceReference містить посилання на Service.legacy.k8s.io.

        • webhooks.clientConfig.service.name (string), обовʼязково

          name — це імʼя сервісу. Обовʼязково.

        • webhooks.clientConfig.service.namespace (string), обовʼязково

          namespace — це простір імен сервісу. Обовʼязково.

        • webhooks.clientConfig.service.path (string)

          path — це необовʼязковий URL шлях, який буде надіслано в будь-якому запиті до цього сервісу.

        • webhooks.clientConfig.service.port (int32)

          Якщо вказано, то це порт на сервісі, який є хостом вебхуку. Типово 443 для зворотної сумісності. port має бути дійсним номером порту (1-65535, включно).

      • webhooks.clientConfig.url (string)

        url вказує місце розташування вебхука в стандартній формі URL (scheme://host:port/path). Необхідно вказати або url, або service.

        host не повинен посилатися на сервіс, що працює в кластері; використовуйте поле service натомість. Хост може бути знайдений через зовнішній DNS в деяких серверах API (наприклад, kube-apiserver не може працювати з кластерним DNS, оскільки це було б порушенням розшарування). host може також бути IP-адресою.

        Зверніть увагу, що використання localhost або 127.0.0.1 як host є ризикованим, якщо ви не вживаєте великих заходів обережності, щоб запустити цей вебхук на всіх хостах, що запускають сервер API, який може потребувати викликів до цього вебхука. Такі встановлення, ймовірно, будуть непереносимими, тобто їх буде важко розгорнути в новому кластері.

        Схема має бути "https"; URL має починатися з "https://".

        Шлях є необовʼязковим, і, якщо він присутній, може бути будь-яким рядком, допустимим в URL. Ви можете використовувати шлях для передачі довільного рядка до вебхука, наприклад, ідентифікатора кластера.

        Спроба використання автентифікації користувача або базової автентифікації, наприклад, "user:password@", не дозволена. Також не дозволяються фрагменти ("#...") і параметри запиту ("?...").

    • webhooks.name (string), обовʼязково

      Імʼя вебхуку допуску. Імʼя має бути повністю кваліфікованим, наприклад, imagepolicy.kubernetes.io, де "imagepolicy" є назвою вебхука, а kubernetes.io — назвою організації. Обовʼязково.

    • webhooks.sideEffects (string), обовʼязково

      SideEffects вказує, чи має цей вебхук побічні ефекти. Допустимі значення: None, NoneOnDryRun (вебхуки, створені у v1beta1, також можуть вказати Some або Unknown). Вебхуки з побічними ефектами МАЮТЬ реалізувати систему узгодження, оскільки запит може бути відхилено на наступному етапі ланцюжка допуску, і побічні ефекти потрібно буде скасувати. Запити з атрибутом dryRun автоматично відхиляються, якщо вони відповідають вебхуку з sideEffects == Unknown або Some.

    • webhooks.failurePolicy (string)

      FailurePolicy визначає, як обробляються нерозпізнані помилки від точки доступу допуску — дозволені значення: Ignore або Fail. Стандартне значення — Fail.

    • webhooks.matchConditions ([]MatchCondition)

      Patch strategy: злиття за ключем name

      Map: унікальні значення за ключем name будуть збережені під час злиття

      MatchConditions — це список умов, які мають бути виконані для надсилання запиту до цього вебхука. Умови відповідності фільтрують запити, які вже були підібрані за правилами, namespaceSelector і objectSelector. Порожній список matchConditions відповідає всім запитам. Максимальна кількість умов відповідності — 64.

      Логіка точного збігу така (за порядком):

      1. Якщо БУДЬ-ЯКА умова відповідності оцінюється як FALSE, вебхук оминається.
      2. Якщо ВСІ умови відповідності оцінюються як TRUE, вебхук викликається.
      3. Якщо будь-яка умова відповідності оцінюється як помилка (але жодна не є FALSE):
        • Якщо failurePolicy=Fail, запит відхиляється
        • Якщо failurePolicy=Ignore, помилка ігнорується і вебхук оминається

      MatchCondition представляє умову, яка має бути виконана для надсилання запиту до вебхука.

      • webhooks.matchConditions.expression (string), обовʼязково

        Expression представляє вираз, який буде оцінено CEL. Результат обробки — bool. Вирази CEL мають доступ до вмісту AdmissionRequest і Authorizer, організованих у змінні CEL:

        'object' — Обʼєкт із вхідного запиту. Значення null для запитів DELETE. 'oldObject' — Наявний обʼєкт. Значення null для запитів CREATE. 'request' — Атрибути запиту допуску (/pkg/apis/admission/types.go#AdmissionRequest). 'authorizer' — CEL Authorizer. Може бути використано для виконання перевірок авторизації для виконавця (користувач або службового облікового запису) запиту. Див. https://pkg.go.dev/k8s.io/apiserver/pkg/cel/library#Authz 'authorizer.requestResource' — CEL ResourceCheck, створений з 'authorizer' і налаштований із ресурсом запиту. Документація щодо CEL: https://kubernetes.io/docs/reference/using-api/cel/

        Обовʼязково.

      • webhooks.matchConditions.name (string), обовʼязково

        Name — це ідентифікатор цієї умови відповідності, використовується для стратегії злиття умов відповідності, а також для надання ідентифікатора для цілей логування. Хороша назва має бути описовою для повʼязаного виразу. Назва має бути кваліфікованою назвою, що складається з алфавітно-цифрових символів, '-', '' або '.', і має починатися та закінчуватися алфавітно-цифровим символом (наприклад, 'MyName' або 'my.name' або '123-abc', регулярний вираз, що використовується для перевірки, — '([A-Za-z0-9][-A-Za-z0-9.]*)?[A-Za-z0-9]') з необовʼязковим префіксом DNS субдомену та '/' (наприклад, 'example.com/MyName').

        Обовʼязково.

    • webhooks.matchPolicy (string)

      matchPolicy визначає, як використовується список "rules" для відповідності вхідним запитам. Допустимі значення — "Exact" або "Equivalent".

      • Exact: відповідність запиту тільки в тому випадку, якщо він точно відповідає зазначеному правилу. Наприклад, якщо розгортання (deployments) можуть бути змінені через apps/v1, apps/v1beta1 і extensions/v1beta1, але "rules" включають тільки apiGroups:["apps"], apiVersions:["v1"], resources: ["deployments"], запит до apps/v1beta1 або extensions/v1beta1 не буде надіслано до вебхука.

      • Equivalent: відповідність запиту, якщо він змінює ресурс, вказаний у правилах, навіть через іншу групу API або версію. Наприклад, якщо розгортання (deployments) можуть бути змінені через apps/v1, apps/v1beta1 і extensions/v1beta1, і "rules" включають тільки apiGroups:["apps"], apiVersions:["v1"], resources: ["deployments"], запит до apps/v1beta1 або extensions/v1beta1 буде перетворений на apps/v1 і надісланий до вебхука.

      Стандартне значення — "Equivalent".

    • webhooks.namespaceSelector (LabelSelector)

      NamespaceSelector визначає, чи буде вебхук працювати з обʼєктом на основі того, чи збігається простір імен для цього обʼєкта з селектором. Якщо обʼєкт сам є простором імен, перевірка збігу виконується за метаданими обʼєкта. Якщо обʼєкт є іншим ресурсом на рівні кластера, він ніколи не оминає вебхук.

      Наприклад, щоб запустити вебхук для будь-яких обʼєктів, чий простір імен не повʼязаний з "runlevel" 0 або 1, потрібно налаштувати селектор наступним чином:

      "namespaceSelector": {
        "matchExpressions": [
          {
            "key": "runlevel",
            "operator": "NotIn",
            "values": [
              "0",
              "1"
            ]
          }
        ]
      }
      

      Якщо замість цього ви хочете запустити вебхук для будь-яких обʼєктів, чий простір імен повʼязаний з "environment" "prod" або "staging", потрібно налаштувати селектор наступним чином:

      "namespaceSelector": {
        "matchExpressions": [
          {
            "key": "environment",
            "operator": "In",
            "values": [
              "prod",
              "staging"
            ]
          }
        ]
      }
      

      Див. https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/ для отримання додаткових прикладів селекторів міток.

      Типове значення — порожній LabelSelector, який має збіг зі всім.

    • webhooks.objectSelector (LabelSelector)

      ObjectSelector визначає, чи буде вебхук працювати з обʼєктом на основі того, чи має обʼєкт відповідні мітки. ObjectSelector оцінюється як для oldObject, так і для newObject, які будуть надіслані до вебхука, і вважається відповідним, якщо будь-який з обʼєктів відповідає селектору. Нульовий обʼєкт (oldObject у випадку створення або newObject у випадку видалення) або обʼєкт, який не може мати міток (наприклад, DeploymentRollback або PodProxyOptions обʼєкт), не вважається таким, що має збіг. Використовуйте objectSelector лише якщо вебхук є опціональним, оскільки кінцеві користувачі можуть оминути вебхук допуску, встановивши мітки. Типове значення — порожній LabelSelector, який має збіг зі всім.

    • webhooks.reinvocationPolicy (string)

      reinvocationPolicy вказує, чи має цей вебхук викликатися кілька разів у рамках однієї оцінки допуску. Допустимі значення — "Never" і "IfNeeded".

      Never: вебхук не буде викликатися більше одного разу в рамках однієї оцінки допуску.

      IfNeeded: вебхук буде викликаний щонайменше один додатковий раз у рамках оцінки допуску, якщо обʼєкт, який допускаєтсья, змінюється іншими втулками допуску після початкового виклику вебхука. Вебхуки, які вказують цю опцію, мають бути ідемпотентними, здатними обробляти обʼєкти, які вони попередньо прийняли. Зверніть увагу:

      • не гарантується, що кількість додаткових викликів буде дорівнювати одному.
      • якщо додаткові виклики призводять до подальших змін обʼєкта, вебхуки не гарантуються до повторного виклику.
      • вебхуки, що використовують цю опцію, можуть бути впорядковані для мінімізації кількості додаткових викликів.
      • для перевірки обʼєкта після завершення всіх змін, використовуйте вебхук для валідації допуску.

      Стандартне значення — "Never".

    • webhooks.rules ([]RuleWithOperations)

      Atomic: буде замінено під час злиття

      Rules описує, які операції з якими ресурсами/субресурсами цікавлять вебхук. Вебхук цікавить операція, якщо вона відповідає будь-якому правилу. Однак, щоб запобігти тому, що ValidatingAdmissionWebhooks і MutatingAdmissionWebhooks можуть привести кластер до стану, з якого неможливо відновитися без повного вимкнення втулка, ValidatingAdmissionWebhooks і MutatingAdmissionWebhooks ніколи не викликаються на запити допуску для обʼєктів ValidatingWebhookConfiguration і MutatingWebhookConfiguration.

      RuleWithOperations — це кортеж операцій і ресурсів. Рекомендується переконатися, що всі розширення кортежу є дійсними.

      • webhooks.rules.apiGroups ([]string)

        Atomic: буде замінено під час злиття

        APIGroups — це групи API, до яких належать ресурси. '*' означає всі групи. Якщо присутній символ '*', довжина списку має бути одиницею. Обовʼязково.

      • webhooks.rules.apiVersions ([]string)

        Atomic: буде замінено під час злиття

        APIVersions — це версії API, до яких належать ресурси. '*' означає всі версії. Якщо присутній символ '*', довжина списку має бути одиницею. Обовʼязково.

      • webhooks.rules.operations ([]string)

        Atomic: буде замінено під час злиття

        Operations — це операції, які цікавлять вебхук допуску — CREATE, UPDATE, DELETE, CONNECT або * для всіх цих операцій і будь-яких майбутніх операцій допуску, які будуть додані. Якщо присутній символ '*', довжина списку має бути одиницею. Обовʼязково.

      • webhooks.rules.resources ([]string)

        Atomic: буде замінено під час злиття

        Resources — це список ресурсів, до яких застосовується це правило.

        Наприклад, 'pods' означає Podʼи, 'pods/log' означає субресурс логу Podʼів. '*' означає всі ресурси, але не субресурси. 'pods/*' означає всі субресурси Podʼів. '*/scale' означає всі субресурси масштабування. '*/*' означає всі ресурси та їх субресурси.

        Якщо присутній універсальний символ, правило валідації забезпечить відсутність перекриття ресурсів.

        Залежно від навколишнього обʼєкта, субресурси можуть бути недопустимими. Обовʼязково.

      • webhooks.rules.scope (string)

        scope визначає область застосування цього правила. Допустимі значення — "Cluster", "Namespaced" та "*" "Cluster" означає, що правило буде застосовано тільки до ресурсів на рівні кластера. API обʼєкти простору імен є ресурсами на рівні кластера. "Namespaced" означає, що правило буде застосовано тільки до ресурсів простору імен. "*" означає, що немає обмежень на область застосування. Субресурси відповідають області застосування свого батьківського ресурсу. Стандартне значення — "*".

    • webhooks.timeoutSeconds (int32)

      TimeoutSeconds визначає тайм-аут для цього вебхука. Після закінчення тайм-ауту виклик вебхука буде проігноровано або виклик API завершиться невдачею залежно від політики відмови. Значення тайм-ауту має бути від 1 до 30 секунд. Стандартне значення — 10 секунд.

MutatingWebhookConfigurationList

MutatingWebhookConfigurationList — це список MutatingWebhookConfiguration.


Операції


get отримати вказану MutatingWebhookConfiguration

HTTP запит

GET /apis/admissionregistration.k8s.io/v1/mutatingwebhookconfigurations/{name}

Параметри

  • name (в шляху): string, обовʼязково

    name of the MutatingWebhookConfiguration

  • pretty (в запиті): string

    pretty

Відповідь

200 (MutatingWebhookConfiguration): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу MutatingWebhookConfiguration

HTTP запит

GET /apis/admissionregistration.k8s.io/v1/mutatingwebhookconfigurations

Параметри

Відповідь

200 (MutatingWebhookConfigurationList): OK

401: Unauthorized

create створення MutatingWebhookConfiguration

HTTP запит

POST /apis/admissionregistration.k8s.io/v1/mutatingwebhookconfigurations

Параметри

Відповідь

200 (MutatingWebhookConfiguration): OK

201 (MutatingWebhookConfiguration): Created

202 (MutatingWebhookConfiguration): Accepted

401: Unauthorized

update заміна вказаної MutatingWebhookConfiguration

HTTP запит

PUT /apis/admissionregistration.k8s.io/v1/mutatingwebhookconfigurations/{name}

Параметри

Відповідь

200 (MutatingWebhookConfiguration): OK

201 (MutatingWebhookConfiguration): Created

401: Unauthorized

patch часткове оновлення вказаної MutatingWebhookConfiguration

HTTP запит

PATCH /apis/admissionregistration.k8s.io/v1/mutatingwebhookconfigurations/{name}

Параметри

  • name (в шляху): string, обовʼязково

    name of the MutatingWebhookConfiguration

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (MutatingWebhookConfiguration): OK

201 (MutatingWebhookConfiguration): Created

401: Unauthorized

delete видалення MutatingWebhookConfiguration

HTTP запит

DELETE /apis/admissionregistration.k8s.io/v1/mutatingwebhookconfigurations/{name}

Параметри

  • name (в шляху): string, обовʼязково

    name of the MutatingWebhookConfiguration

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції MutatingWebhookConfiguration

HTTP запит

DELETE /apis/admissionregistration.k8s.io/v1/mutatingwebhookconfigurations

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

6.5.7.4 - ValidatingWebhookConfiguration

ValidatingWebhookConfiguration описує конфігурацію та вебхук допуску, який приймає або відхиляє та об’єкт, не змінюючи його.

apiVersion: admissionregistration.k8s.io/v1

import "k8s.io/api/admissionregistration/v1"

ValidatingWebhookConfiguration

ValidatingWebhookConfiguration описує конфігурацію вебхуку допуску, який приймає або відхиляє обʼєкт не змінюючи його.


  • apiVersion: admissionregistration.k8s.io/v1

  • kind: ValidatingWebhookConfiguration

  • metadata (ObjectMeta)

    Стандартні метадані обʼєкта; Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata.

  • webhooks ([]ValidatingWebhook)

    Patch strategy: обʼєднання за ключем name

    Map: унікальні значення ключа name будуть збережені під час злиття

    Webhooks — це список вебхуків і ресурсів та операцій, які вони зачіпають.

    ValidatingWebhook описує вебхук допуску та ресурси й операції, до яких він застосовується.

    • webhooks.admissionReviewVersions ([]string), обовʼязково

      Atomic: буде замінено під час злиття

      AdmissionReviewVersions — це впорядкований список бажаних версій AdmissionReview, які очікує вебхук. API сервер спробує використати першу версію у списку, яку він підтримує. Якщо жодна з версій, зазначених у цьому списку, не підтримується API сервером, валідація для цього обʼєкта зазнає невдачі. Якщо збережена конфігурація вебхука вказує дозволені версії та не включає жодних версій, відомих API серверу, виклики до вебхука зазнають невдачі і є предметом для застосування політики відмов.

    • webhooks.clientConfig (WebhookClientConfig), обовʼязково

      ClientConfig визначає, як спілкуватися з вебхуком. Обовʼязково

      WebhookClientConfig містить інформацію для встановлення TLS-зʼєднання з вебхуком

      • webhooks.clientConfig.caBundle ([]byte)

        caBundle — це PEM-кодований набір сертифікатів CA, який буде використовуватися для перевірки сертифіката сервера вебхука. Якщо не вказано, використовуються системні корені довіри на API сервері.

      • webhooks.clientConfig.service (ServiceReference)

        service — це посилання на сервіс для цього вебхука. Необхідно вказати або service, або url.

        Якщо вебхук працює в межах кластера, тоді слід використовувати service.

        ServiceReference містить посилання на Service.legacy.k8s.io

        • webhooks.clientConfig.service.name (string), обовʼязково

          name — це імʼя сервісу. Обовʼязково

        • webhooks.clientConfig.service.namespace (string), обовʼязково

          namespace — це простір імен сервісу. Обовʼязково

        • webhooks.clientConfig.service.path (string)

          path — це необовʼязковий URL-шлях, який буде надіслано в будь-якому запиті до цього сервісу.

        • webhooks.clientConfig.service.port (int32)

        Якщо вказано, то це порт на сервісі, який є хостом вебхуку. Типово 443 для зворотної сумісності. port має бути дійсним номером порту (1-65535, включно).

      • webhooks.clientConfig.url (string)

        url вказує місце розташування вебхука в стандартній формі URL (scheme://host:port/path). Необхідно вказати або url, або service.

        host не повинен посилатися на сервіс, що працює в кластері; використовуйте поле service натомість. Хост може бути знайдений через зовнішній DNS в деяких серверах API (наприклад, kube-apiserver не може працювати з кластерним DNS, оскільки це було б порушенням розшарування). host може також бути IP-адресою.

        Зверніть увагу, що використання localhost або 127.0.0.1 як host є ризикованим, якщо ви не вживаєте великих заходів обережності, щоб запустити цей вебхук на всіх хостах, що запускають сервер API, який може потребувати викликів до цього вебхука. Такі встановлення, ймовірно, будуть непереносимими, тобто їх буде важко розгорнути в новому кластері.

        Схема повинна бути "https"; URL повинен починатися з "https://".

        Шлях є необовʼязковим, і, якщо він присутній, може бути будь-яким рядком, допустимим в URL. Ви можете використовувати шлях для передачі довільного рядка до вебхука, наприклад, ідентифікатора кластера.

        Спроба використання автентифікації користувача або базової автентифікації, наприклад, "user:password@", не дозволена. Також не дозволяються фрагменти ("#...") і параметри запиту ("?...").

    • webhooks.name (string), обовʼязково

      Імʼя вебхука допуску. Імʼя повинно бути повністю кваліфікованим, наприклад, imagepolicy.kubernetes.io, де "imagepolicy" — це імʼя вебхука, а kubernetes.io — це імʼя організації. Обовʼязково.

    • webhooks.sideEffects (string), обовʼязково

      SideEffects вказує, чи має цей вебхук побічні ефекти. Допустимі значення: None, NoneOnDryRun (вебхуки, створені у v1beta1, також можуть вказати Some або Unknown). Вебхуки з побічними ефектами МАЮТЬ реалізувати систему узгодження, оскільки запит може бути відхилено на наступному етапі ланцюжка допуску, і побічні ефекти потрібно буде скасувати. Запити з атрибутом dryRun автоматично відхиляються, якщо вони відповідають вебхуку з sideEffects == Unknown або Some.

    • webhooks.failurePolicy (string)

      FailurePolicy визначає, як обробляються нерозпізнані помилки від точки доступу допуску — дозволені значення: Ignore або Fail. Стандартне значення — Fail.

    • webhooks.matchConditions ([]MatchCondition)

      Patch strategy: обʼєднання за ключем name

      Map: під час обʼєднання будуть збережені унікальні значення за ключем name

    MatchConditions — це список умов, які мають бути виконані для надсилання запиту до цього вебхука. Умови відповідності фільтрують запити, які вже були підібрані за правилами, namespaceSelector і objectSelector. Порожній список matchConditions відповідає всім запитам. Максимальна кількість умов відповідності — 64.

    Логіка точного збігу така (за порядком): 1. Якщо БУДЬ-ЯКА умова відповідності оцінюється як FALSE, вебхук оминається. 2. Якщо ВСІ умови відповідності оцінюються як TRUE, вебхук викликається. 3. Якщо будь-яка умова відповідності оцінюється як помилка (але жодна не є FALSE): - Якщо failurePolicy=Fail, запит відхиляється - Якщо failurePolicy=Ignore, помилка ігнорується і вебхук оминається

    MatchCondition представляє умову, яка повинна бути виконана для надсилання запиту до вебхука.

    • webhooks.matchConditions.expression (string), обовʼязково

      Expression представляє вираз, який буде оцінено CEL. Результат обробки — bool. Вирази CEL мають доступ до вмісту AdmissionRequest і Authorizer, організованих у змінні CEL:

      'object' — Обʼєкт із вхідного запиту. Значення null для запитів DELETE. 'oldObject' — Наявний обʼєкт. Значення null для запитів CREATE. 'request' — Атрибути запиту допуску (/pkg/apis/admission/types.go#AdmissionRequest). 'authorizer' — CEL Authorizer. Може бути використано для виконання перевірок авторизації для виконавця (користувач або службового облікового запису) запиту. Див. https://pkg.go.dev/k8s.io/apiserver/pkg/cel/library#Authz 'authorizer.requestResource' — CEL ResourceCheck, створений з 'authorizer' і налаштований із ресурсом запиту. Документація щодо CEL: https://kubernetes.io/docs/reference/using-api/cel/

      Обовʼязково.

    • webhooks.matchConditions.name (string), обовʼязково

      Name — це ідентифікатор цієї умови відповідності, використовується для стратегії злиття умов відповідності, а також для надання ідентифікатора для цілей логування. Хороша назва має бути описовою для повʼязаного виразу. Назва має бути кваліфікованою назвою, що складається з алфавітно-цифрових символів, '-', '' або '.', і має починатися та закінчуватися алфавітно-цифровим символом (наприклад, 'MyName' або 'my.name' або '123-abc', регулярний вираз, що використовується для перевірки, — '([A-Za-z0-9][-A-Za-z0-9.]*)?[A-Za-z0-9]') з необовʼязковим префіксом DNS субдомену та '/' (наприклад, 'example.com/MyName').

      Обовʼязково.

    • webhooks.matchPolicy (string)

      matchPolicy визначає, як використовується список "rules" для відповідності вхідним запитам. Допустимі значення — "Exact" або "Equivalent".

      • Exact: відповідність запиту тільки в тому випадку, якщо він точно відповідає зазначеному правилу. Наприклад, якщо розгортання (deployments) можуть бути змінені через apps/v1, apps/v1beta1 і extensions/v1beta1, але "rules" включають тільки apiGroups:["apps"], apiVersions:["v1"], resources: ["deployments"], запит до apps/v1beta1 або extensions/v1beta1 не буде надіслано до вебхука.

      • Equivalent: відповідність запиту, якщо він змінює ресурс, вказаний у правилах, навіть через іншу групу API або версію. Наприклад, якщо розгортання (deployments) можуть бути змінені через apps/v1, apps/v1beta1 і extensions/v1beta1, і "rules" включають тільки apiGroups:["apps"], apiVersions:["v1"], resources: ["deployments"], запит до apps/v1beta1 або extensions/v1beta1 буде перетворений на apps/v1 і надісланий до вебхука.

      Стандартне значення — "Equivalent".

    • webhooks.namespaceSelector (LabelSelector)

      NamespaceSelector визначає, чи буде вебхук працювати з обʼєктом на основі того, чи збігається простір імен для цього обʼєкта з селектором. Якщо обʼєкт сам є простором імен, перевірка збігу виконується за метаданими обʼєкта. Якщо обʼєкт є іншим ресурсом на рівні кластера, він ніколи не оминає вебхук.

      Наприклад, щоб запустити вебхук для будь-яких обʼєктів, чий простір імен не повʼязаний з "runlevel" 0 або 1, потрібно налаштувати селектор наступним чином:

      "namespaceSelector": {
        "matchExpressions": [
          {
            "key": "runlevel",
            "operator": "NotIn",
            "values": [
              "0",
              "1"
            ]
          }
        ]
      }
      

      Якщо замість цього ви хочете запустити вебхук для будь-яких обʼєктів, чий простір імен повʼязаний з "environment" "prod" або "staging", потрібно налаштувати селектор наступним чином:

      "namespaceSelector": {
        "matchExpressions": [
          {
            "key": "environment",
            "operator": "In",
            "values": [
              "prod",
              "staging"
            ]
          }
        ]
      }
      

      Див. https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/ для отримання додаткових прикладів селекторів міток.

      Типове значення — порожній LabelSelector, який має збіг зі всім.

    • webhooks.objectSelector (LabelSelector)

      ObjectSelector визначає, чи буде вебхук працювати з обʼєктом на основі того, чи має обʼєкт відповідні мітки. ObjectSelector оцінюється як для oldObject, так і для newObject, які будуть надіслані до вебхука, і вважається відповідним, якщо будь-який з обʼєктів відповідає селектору. Нульовий обʼєкт (oldObject у випадку створення або newObject у випадку видалення) або обʼєкт, який не може мати міток (наприклад, DeploymentRollback або PodProxyOptions обʼєкт), не вважається таким, що має збіг. Використовуйте objectSelector лише якщо вебхук є опціональним, оскільки кінцеві користувачі можуть оминути вебхук допуску, встановивши мітки. Типове значення — порожній LabelSelector, який має збіг зі всім.

    • webhooks.rules ([]RuleWithOperations)

      Atomic: буде замінено під час злиття

      Rules описують, які операції з якими ресурсами/субресурсами цікавлять вебхук. Вебхук цікавить операція, якщо вона збігаєтьсяз БУДЬ-ЯКИМ правилом. Однак, щоб запобігти ValidatingAdmissionWebhooks і MutatingAdmissionWebhooks від приведення кластера в стан, з якого не можна вийти без повного відключення втулка, ValidatingAdmissionWebhooks і MutatingAdmissionWebhooks ніколи не викликаються для запитів на допуск для обʼєктів ValidatingWebhookConfiguration і MutatingWebhookConfiguration.

      RuleWithOperations — це кортеж операцій і ресурсів. Рекомендується переконатися, що всі розширення кортежу є дійсними.

      • webhooks.rules.apiGroups ([]string)

        Atomic: буде замінено під час обʼєднання

        APIGroups — це групи API, до яких належать ресурси. '*' означає всі групи. Якщо присутній символ '*', довжина списку має бути одиницею. Обовʼязково.

      • webhooks.rules.apiVersions ([]string)

        Atomic: буде замінено під час обʼєднання

        APIVersions — це версії API, до яких належать ресурси. '*' означає всі версії. Якщо присутній символ '*', довжина списку має бути одиницею. Обовʼязково.

      • webhooks.rules.operations ([]string)

        Atomic: буде замінено під час обʼєднання

        Operations — це операції, які цікавлять вебхук допуску — CREATE, UPDATE, DELETE, CONNECT або * для всіх цих операцій і будь-яких майбутніх операцій допуску, які будуть додані. Якщо присутній символ '*', довжина списку має бути одиницею. Обовʼязково.

      • webhooks.rules.resources ([]string)

        Atomic: буде замінено під час обʼєднання

        Resources — це список ресурсів, до яких застосовується це правило.

        Наприклад, 'pods' означає Podʼи, 'pods/log' означає субресурс логу Podʼів. '*' означає всі ресурси, але не субресурси. 'pods/*' означає всі субресурси Podʼів. '*/scale' означає всі субресурси масштабування. '*/*' означає всі ресурси та їх субресурси.

        Якщо присутній універсальний символ, правило валідації забезпечить відсутність перекриття ресурсів.

        Залежно від навколишнього обʼєкта, субресурси можуть бути недопустимими. Обовʼязково.

      • webhooks.rules.scope (string)

        scope визначає область застосування цього правила. Допустимі значення — "Cluster", "Namespaced" та "*". "Cluster" означає, що правило буде застосовано тільки до ресурсів на рівні кластера. API обʼєкти простору імен є ресурсами на рівні кластера. "Namespaced" означає, що правило буде застосовано тільки до ресурсів простору імен. "*" означає, що немає обмежень на область застосування. Субресурси відповідають області застосування свого батьківського ресурсу. Стандартне значення — "*".

    • webhooks.timeoutSeconds (int32)

      TimeoutSeconds визначає тайм-аут для цього вебхука. Після закінчення тайм-ауту виклик вебхука буде проігноровано або виклик API завершиться невдачею залежно від політики відмови. Значення тайм-ауту має бути від 1 до 30 секунд. Стандартне значення — 10 секунд.

ValidatingWebhookConfigurationList

ValidatingWebhookConfigurationList — це список ValidatingWebhookConfiguration.


Операції


get отримати вказану ValidatingWebhookConfiguration

HTTP запит

GET /apis/admissionregistration.k8s.io/v1/validatingwebhookconfigurations/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва ValidatingWebhookConfiguration

  • pretty (в запиті): string

    pretty

Відповідь

200 (ValidatingWebhookConfiguration): OK

401: Unauthorized

list перелік або перегляд обʼктів ValidatingWebhookConfiguration

HTTP запит

GET /apis/admissionregistration.k8s.io/v1/validatingwebhookconfigurations

Параметри

Відповідь

200 (ValidatingWebhookConfigurationList): OK

401: Unauthorized

create створення ValidatingWebhookConfiguration

HTTP запит

POST /apis/admissionregistration.k8s.io/v1/validatingwebhookconfigurations

Параметри

Відповідь

200 (ValidatingWebhookConfiguration): OK

201 (ValidatingWebhookConfiguration): Created

202 (ValidatingWebhookConfiguration): Accepted

401: Unauthorized

update заміна вказаної ValidatingWebhookConfiguration

HTTP запит

PUT /apis/admissionregistration.k8s.io/v1/validatingwebhookconfigurations/{name}

Параметри

Відповідь

200 (ValidatingWebhookConfiguration): OK

201 (ValidatingWebhookConfiguration): Created

401: Unauthorized

patch часткове оновлення вказаної ValidatingWebhookConfiguration

HTTP запит

PATCH /apis/admissionregistration.k8s.io/v1/validatingwebhookconfigurations/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва ValidatingWebhookConfiguration

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (ValidatingWebhookConfiguration): OK

201 (ValidatingWebhookConfiguration): Created

401: Unauthorized

delete видалення ValidatingWebhookConfiguration

HTTP запит

DELETE /apis/admissionregistration.k8s.io/v1/validatingwebhookconfigurations/{name}

Параметри

  • name (в шляху): string, обовʼязково

    назва ValidatingWebhookConfiguration

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видаленя колекції ValidatingWebhookConfiguration

HTTP запит

DELETE /apis/admissionregistration.k8s.io/v1/validatingwebhookconfigurations

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

6.5.8 - Ресурси кластера

6.5.8.1 - APIService

APIService представляє сервер для певної GroupVersion.

apiVersion: apiregistration.k8s.io/v1

import "k8s.io/kube-aggregator/pkg/apis/apiregistration/v1"

APIService

APIService представляє сервер для певної GroupVersion. Імʼя повинно бути "version.group".


APIServiceSpec

APIServiceSpec містить інформацію для пошуку та звʼязку з сервером. Підтримується лише https, хоча ви можете вимкнути перевірку сертифіката.


  • groupPriorityMinimum (int32), обовʼязково

    GroupPriorityMinimum — це мінімальний пріоритет, який має мати ця група. Вищий пріоритет означає, що група має перевагу для клієнтів над групами з нижчим пріоритетом. Зверніть увагу, що інші версії цієї групи можуть мати ще вищі значення GroupPriorityMinimum, що надає групі вищий пріоритет. Першочергове сортування базується на GroupPriorityMinimum, впорядкованому від найвищого до найнижчого (20 перед 10). Вторинне сортування базується на алфавітному порівнянні імені обʼєкта. (v1.bar перед v1.foo) Ми рекомендуємо щось на зразок: *.k8s.io (за винятком extensions) на 18000, а PaaS (OpenShift, Deis) рекомендується бути у 2000-х.

  • versionPriority (int32), обовʼязково

    VersionPriority контролює впорядкування цієї версії API всередині її групи. Повинно бути більше нуля. Першочергове сортування базується на VersionPriority, впорядкованому від найвищого до найнижчого (20 перед 10). Оскільки це всередині групи, число може бути маленьким, ймовірно, у 10-х. У випадку рівних пріоритетів версій, для визначення порядку всередині групи буде використовуватися рядок версії. Якщо рядок версії "kube-like", він буде сортуватися вище за рядки версій, які не є "kube-like", які впорядковуються лексикографічно. "Kube-like" версії починаються з "v", потім йде число (основна версія), потім за бажанням рядок "alpha" або "beta" і ще одне число (другорядна версія). Ці версії сортуються спочатку за принципом GA > beta > alpha (де GA — це версія без суфікса, такого як beta або alpha), а потім порівнюються основна версія, потім другорядна версія. Приклад відсортованого списку версій: v10, v2, v1, v11beta2, v10beta3, v3beta1, v12alpha1, v11alpha2, foo1, foo10.

  • caBundle ([]byte)

    Atomic: буде замінено під час злиття

    CABundle — це PEM закодований набір сертифікатів CA, який буде використовуватися для перевірки сертифіката сервера API. Якщо не вказано, використовуються системні довірені корені на сервері API.

  • group (string)

    Group — це назва групи API, яку хостить цей сервер

  • insecureSkipTLSVerify (boolean)

    InsecureSkipTLSVerify вимикає перевірку сертифіката TLS при звʼязку з цим сервером. Це категорично не рекомендується. Вам слід використовувати CABundle замість цього.

  • service (ServiceReference)

    Service — це посилання на сервіс для цього сервера API. Воно повинно спілкуватись на порту 443. Якщо Service дорівнює nil, це означає, що обробка для версії API групи виконується локально на цьому сервері. Виклик просто делегується звичайному ланцюгу обробки для виконання.

    ServiceReference утримує посилання на Service.legacy.k8s.io

    • service.name (string)

      Name — це імʼя сервісу

    • service.namespace (string)

      Namespace — це простір імен сервісу

    • service.port (int32)

      Якщо вказано, порт сервісу, який хостить webhook. Стандартно — 443 для зворотної сумісності. port повинен бути допустимим номером порту (1-65535 включно).

  • version (string)

    Version — це версія API, яку хостить цей сервер. Наприклад, "v1"

APIServiceStatus

APIServiceStatus містить похідну інформацію про сервер API


  • conditions ([]APIServiceCondition)

    Patch strategy: злиття за ключем type

    Map: унікальні значення за ключем type будуть збережені під час злиття

    Поточний стан сервісу apiService.

    APIServiceCondition описує стан APIService у певний момент часу

    • conditions.status (string), обовʼязково

      Status — це стан статусу. Може бути True, False, Unknown.

    • conditions.type (string), обовʼязково

      Type — це тип статусу.

    • conditions.lastTransitionTime (Time)

      Останній раз, коли стан статусу змінився з одного на інший.

      Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

    • conditions.message (string)

      Повідомлення, зрозуміле людині, що вказує деталі про останню зміну статусу.

    • conditions.reason (string)

      Унікальна, однослівна, CamelCase причина останньої зміни статусу.

APIServiceList

APIServiceList — це список обʼєктів APIService.


Операції


get отримати вказаний APIService

HTTP запит

GET /apis/apiregistration.k8s.io/v1/apiservices/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя APIService

  • pretty (в запиті): string

    pretty

Відповідь

200 (APIService): OK

401: Unauthorized

get отримати статус вказаного APIService

HTTP запит

GET /apis/apiregistration.k8s.io/v1/apiservices/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя APIService

  • pretty (в запиті): string

    pretty

Відповідь

200 (APIService): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу APIService

HTTP запит

GET /apis/apiregistration.k8s.io/v1/apiservices

Параметри

Відповідь

200 (APIServiceList): OK

401: Unauthorized

create створення APIService

HTTP запит

POST /apis/apiregistration.k8s.io/v1/apiservices

Параметри

Відповідь

200 (APIService): OK

201 (APIService): Created

202 (APIService): Accepted

401: Unauthorized

update заміна вказаного APIService

HTTP запит

PUT /apis/apiregistration.k8s.io/v1/apiservices/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя APIService

  • body: APIService, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (APIService): OK

201 (APIService): Created

401: Unauthorized

update заміна статусу вказаного APIService

HTTP запит

PUT /apis/apiregistration.k8s.io/v1/apiservices/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя APIService

  • body: APIService, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (APIService): OK

201 (APIService): Created

401: Unauthorized

patch часткове оновлення вказаного APIService

HTTP запит

PATCH /apis/apiregistration.k8s.io/v1/apiservices/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя APIService

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (APIService): OK

201 (APIService): Created

401: Unauthorized

patch чатскове оновлення статусу вказаного APIService

HTTP запит

PATCH /apis/apiregistration.k8s.io/v1/apiservices/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя APIService

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (APIService): OK

201 (APIService): Created

401: Unauthorized

delete видаленя APIService

HTTP запит

DELETE /apis/apiregistration.k8s.io/v1/apiservices/{name}

Параметри

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видаленя колекції APIService

HTTP запит

DELETE /apis/apiregistration.k8s.io/v1/apiservices

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

6.5.8.2 - ComponentStatus

ComponentStatus (і ComponentStatusList) містить інформацію про валідацію кластера.

apiVersion: v1

import "k8s.io/api/core/v1"

ComponentStatus

ComponentStatus (і ComponentStatusList) містить інформацію про валідацію кластера. Застаріло: Цей API застарів у версії v1.19+


  • apiVersion: v1

  • kind: ComponentStatus

  • metadata (ObjectMeta)

    Стандартні метадані обʼєкта. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

  • conditions ([]ComponentCondition)

    Patch strategy: обʼєднання за ключем type

    Map: унікальні значення ключа type будуть збережені під час злиття

    Список спостережуваних станів компонента

    Інформація про стан компонента.

    • conditions.status (string), обовʼязково

      Статус стану компонента. Допустимі значення для "Healthy": "True", "False" або "Unknown".

    • conditions.type (string), обовʼязково

      Тип стану компонента. Допустиме значення: "Healthy"

    • conditions.error (string)

      Код помилки стану компонента. Наприклад, код помилки перевірки справності.

    • conditions.message (string)

      Повідомлення про стан компонента. Наприклад, інформація про перевірку справності.

ComponentStatusList

Стан усіх умов для компонента у вигляді списку обʼєктів ComponentStatus. Застаріло: Цей API застарів у версії v1.19+


Операції


get отримання вказаного ComponentStatus

HTTP запит

GET /api/v1/componentstatuses/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ComponentStatus

  • pretty (в запиті): string

    pretty

Відповідь

200 (ComponentStatus): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу ComponentStatus

HTTP запит

GET /api/v1/componentstatuses

Параметри

Відповідь

200 (ComponentStatusList): OK

401: Unauthorized

6.5.8.3 - Event

Подія — це повідомлення про подію десь у кластері.

apiVersion: events.k8s.io/v1

import "k8s.io/api/events/v1"

Event

Event — це звіт про подію десь у кластері. Зазвичай це вказує на зміну стану в системі. Події мають обмежений термін зберігання, і тригери та повідомлення можуть змінюватися з часом. Споживачі подій не повинні покладатися на час події з певною причиною, що відображає послідовний тригер, або на продовження існування подій з цією причиною. До подій слід ставитися як до інформативних, можливо найкращих, додаткових даних.


  • apiVersion: events.k8s.io/v1

  • kind: Event

  • metadata (ObjectMeta)

    Стандартні метадані обʼєкта. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

  • eventTime (MicroTime), обовʼязково

    eventTime — це час, коли подія вперше спостерігалась. Це обовʼязкове поле.

    MicroTime — це версія Time з мікросекундною точністю.

  • action (string)

    action — це дія, яка була виконана або яка не вдалася щодо відповідного обʼєкта. Це машинний код. Це поле не може бути порожнім для нових Подій і може містити не більше 128 символів.

  • deprecatedCount (int32)

    deprecatedCount — застаріле поле, яке забезпечує зворотню сумісність з типом подій core.v1.

  • deprecatedFirstTimestamp (Time)

    deprecatedFirstTimestamp — застаріле поле, яке забезпечує зворотню сумісність з типом подій core.v1.

    Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

  • deprecatedLastTimestamp (Time)

    deprecatedLastTimestamp — застаріле поле, яке забезпечує зворотню сумісність з типом подій core.v1.

    Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

  • deprecatedSource (EventSource)

    deprecatedSource — застаріле поле, яке забезпечує зворотню сумісність з типом подій core.v1.

    EventSource — містить інформацію для події.

    • deprecatedSource.component (string)

      Компонент, з якого була згенерована подія.

    • deprecatedSource.host (string)

      Імʼя вузла, на якому була згенерована подія.

  • note (string)

    note — опис статусу цієї операції, зрозумілий людині. Максимальна довжина примітки — 1 кБ, але бібліотеки повинні бути готові обробляти значення до 64 кБ.

  • reason (string)

    reason — це причина виконання дії. Це текст зрозумілий людині. Це поле не може бути порожнім для нових Подій і може містити не більше 128 символів.

  • regarding (ObjectReference)

    regarding — це обʼєкт, про який йдеться у цій Події. У більшості випадків це обʼєкт, який реалізує контролер звітів, наприклад, ReplicaSetController реалізує ReplicaSets, і ця подія випускається через те, що він діє на деякі зміни в обʼєкті ReplicaSet.

  • related (ObjectReference)

    related — це необовʼязковий вторинний обʼєкт для складніших дій. Наприклад, коли обʼєкт, щодо якого йдеться, спричинює створення або видалення повʼязаного обʼєкта.

  • reportingController (string)

    reportingController — це імʼя контролера, який випустив цю Подію, наприклад, kubernetes.io/kubelet. Це поле не може бути порожнім для нових Подій.

  • reportingInstance (string)

    reportingInstance — це ідентифікатор інстанції контролера, наприклад, kubelet-xyzf. Це поле не може бути порожнім для нових Подій і може містити не більше 128 символів.

  • series (EventSeries)

    series — це дані про серію Подій, яку представляє ця подія, або nil, якщо це поодинока Подія.

    EventSeries — містить інформацію про серію подій, тобто процес, що триває певний час. Частота оновлення EventSeries залежить від звітування подій. Стандартний інструмент повідомлення про події в "k8s.io/client-go/tools/events/event_broadcaster.go" показує, як ця структура оновлюється на тактах та може керувати індивідуалізованими реалізаціями інструментів звітування.

    • series.count (int32), обовʼязково

      count — це кількість випадків у цій серії до останнього часу такту.

    • series.lastObservedTime (MicroTime), обовʼязково

      lastObservedTime — це час, коли останню Подію з серії було побачено перед останім тактом.

      MicroTime — це версія Time з мікросекундною точністю.

  • type (string)

    type — це тип цієї події (Normal, Warning), нові типи можуть бути додані у майбутньому. Це машинне кодування. Це поле не може бути порожнім для нових Подій.

EventList

EventList — це список обʼєктів подій.


Операції


get отримати вказаний Event

HTTP запит

GET /apis/events.k8s.io/v1/namespaces/{namespace}/events/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя Event

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (Event): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу Event

HTTP запит

GET /apis/events.k8s.io/v1/namespaces/{namespace}/events

Параметри

Відповідь

200 (EventList): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу Event

HTTP запит

GET /apis/events.k8s.io/v1/events

Параметри

Відповідь

200 (EventList): OK

401: Unauthorized

create створення Event

HTTP запит

POST /apis/events.k8s.io/v1/namespaces/{namespace}/events

Параметри

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Event, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (Event): OK

201 (Event): Created

202 (Event): Accepted

401: Unauthorized

update заміна вказаного Event

HTTP запит

PUT /apis/events.k8s.io/v1/namespaces/{namespace}/events/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя Event

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Event, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (Event): OK

201 (Event): Created

401: Unauthorized

patch часткове оновлення вказаного Event

HTTP запит

PATCH /apis/events.k8s.io/v1/namespaces/{namespace}/events/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя Event

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (Event): OK

201 (Event): Created

401: Unauthorized

delete видалення Event

HTTP запит

DELETE /apis/events.k8s.io/v1/namespaces/{namespace}/events/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя Event

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції Event

HTTP запит

DELETE /apis/events.k8s.io/v1/namespaces/{namespace}/events

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

6.5.8.4 - IPAddress v1beta1

IP-адреса являє собою одну IP-адресу з одного сімейства IP-адрес.

apiVersion: networking.k8s.io/v1beta1

import "k8s.io/api/networking/v1beta1"

IPAddress

IPAddress представляє одну IP-адресу одного сімейства IP. Цей обʼєкт призначений для використання API, які оперують IP-адресами. Обʼєкт використовується ядром API Service для виділення IP-адрес. IP-адресу можна представити у різних форматах. Щоб гарантувати унікальність IP-адреси, імʼя обʼєкта є IP-адреса в канонічному форматі: чотири десяткові цифри, розділені крапками без ведучих нулів для IPv4 і представлення, визначене RFC 5952 для IPv6. Дійсні: 192.168.1.5 або 2001:db8::1 або 2001:db8:aaaa:bbbb:cccc:dddd:eeee:1 Недійсні: 10.01.2.3 або 2001:db8:0:0:0::1


IPAddressSpec

IPAddressSpec описує атрибути IP-адреси.


  • parentRef (ParentReference), обовʼязково

    ParentRef посилається на ресурс, до якого приєднана IPAddress. IPAddress повинна мати посилання на батьківський обʼєкт.

    ParentReference описує посилання на батьківський обʼєкт.

    • parentRef.name (string)

      Імʼя є іменем обʼєкта, на який посилаються.

    • parentRef.resource (string)

      Ресурс є ресурсом обʼєкта, на який посилаються.

    • parentRef.group (string)

      Група є групою обʼєкта, на який посилаються.

    • parentRef.namespace (string)

      Простір імен є простором імен обʼєкта, на який посилаються.

IPAddressList

IPAddressList містить список IPAddress.


Операції


get отримати вказану IPAddress

HTTP запит

GET /apis/networking.k8s.io/v1beta1/ipaddresses/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя IPAddress

  • pretty (в запиті): string

    pretty

Відповідь

200 (IPAddress): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу IPAddress

HTTP запит

GET /apis/networking.k8s.io/v1beta1/ipaddresses

Параметри

Відповідь

200 (IPAddressList): OK

401: Unauthorized

create створення IPAddress

HTTP запит

POST /apis/networking.k8s.io/v1beta1/ipaddresses

Параметри

Відповідь

200 (IPAddress): OK

201 (IPAddress): Created

202 (IPAddress): Accepted

401: Unauthorized

update заміна вказаної IPAddress

HTTP запит

PUT /apis/networking.k8s.io/v1beta1/ipaddresses/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя IPAddress

  • body: IPAddress, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (IPAddress): OK

201 (IPAddress): Created

401: Unauthorized

patch часткове оновлення вказаної IPAddress

HTTP запит

PATCH /apis/networking.k8s.io/v1beta1/ipaddresses/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя IPAddress

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (IPAddress): OK

201 (IPAddress): Created

401: Unauthorized

delete видалення IPAddress

HTTP запит

DELETE /apis/networking.k8s.io/v1beta1/ipaddresses/{name}

Параметри

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції IPAddress

HTTP запит

DELETE /apis/networking.k8s.io/v1beta1/ipaddresses

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

6.5.8.5 - Lease

Lease визначає концепцію оренди.

apiVersion: coordination.k8s.io/v1

import "k8s.io/api/coordination/v1"

Lease

Lease визначає концепцію оренди.


LeaseSpec

LeaseSpec — це специфікація оренди.


  • acquireTime (MicroTime)

    acquireTime — це час, коли поточну оренду було отримано.

    MicroTime — це версія Time з точністю до мікросекунд.

  • holderIdentity (string)

    holderIdentity містить ідентифікатор власника поточної оренди. Якщо використовується координований вибір лідера, ідентифікатор власника повинен відповідати значенню поля LeaseCandidate.metadata.name, яке було обране.

  • leaseDurationSeconds (int32)

    leaseDurationSeconds — це тривалість, яку кандидати на оренду повинні чекати, щоб примусово її отримати. Вона вимірюється від часу останнього спостережуваного renewTime.

  • leaseTransitions (int32)

    leaseTransitions — це кількість переходів оренди між власниками.

  • preferredHolder (string)

    PreferredHolder сигналізує тримачу лізингу, що існує більш оптимальний тримач лізингу і що лізинг слід передати. Це поле може бути встановлене лише якщо також встановлена стратегія (Strategy).

  • renewTime (MicroTime)

    renewTime — це час, коли поточний власник оренди останнього разу оновив оренду.

    MicroTime — це версія Time з точністю до мікросекунд.

  • strategy (string)

    Strategy вказує стратегію для вибору лідера в координованому виборі лідера. Якщо це поле не вказано, координування для цього лізингу не активне. (Альфа) Для використання цього поля потрібно увімкнути функціональну можливість CoordinatedLeaderElection.

LeaseList

LeaseList — це список обʼєктів Lease.


Операції


get отримати вказаний Lease

HTTP запит

GET /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя Lease

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (Lease): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу Lease

HTTP запит

GET /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases

Параметри

Відповідь

200 (LeaseList): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу Lease

HTTP запит

GET /apis/coordination.k8s.io/v1/leases

Параметри

Відповідь

200 (LeaseList): OK

401: Unauthorized

create створення Lease

HTTP запит

POST /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases

Параметри

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Lease, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (Lease): OK

201 (Lease): Created

202 (Lease): Accepted

401: Unauthorized

update заміна вказаного Lease

HTTP запит

PUT /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя Lease

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Lease, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (Lease): OK

201 (Lease): Created

401: Unauthorized

patch часткове оновлення вказаного Lease

HTTP запит

PATCH /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя Lease

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (Lease): OK

201 (Lease): Created

401: Unauthorized

delete видалення Lease

HTTP запит

DELETE /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя Lease

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції Lease

HTTP запит

DELETE /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

6.5.8.6 - LeaseCandidate v1alpha1

LeaseCandidate визначає кандидата для об'єкта Lease.

apiVersion: coordination.k8s.io/v1alpha1

import "k8s.io/api/coordination/v1alpha1"

LeaseCandidate

LeaseCandidate визначає кандидата для обʼєкта Lease. Кандидати створюються таким чином, щоб координований вибір лідера вибрав найкращого лідера з переліку кандидатів.


LeaseCandidateSpec

LeaseCandidateSpec є специфікацією Lease.


  • leaseName (string), обовʼязково

    LeaseName — це імʼя Lease, за який цей кандидат змагається. Це поле є незмінним.

  • preferredStrategies ([]string), обовʼязково

    Atomic: буде замінено під час злиття

    PreferredStrategies вказує на список стратегій для вибору лідера у координованому виборі лідера. Список упорядкований, і перша стратегія переважає всі інші стратегії. Цей список використовується координованим вибором лідера для прийняття рішення про остаточну стратегію виборів. Це передбачає:

    • Якщо всі клієнти мають стратегію X як перший елемент у цьому списку, буде використана стратегія X.
    • Якщо кандидат має стратегію [X], а інший кандидат має стратегію [Y, X], Y переважає X, і буде використана стратегія Y.
    • Якщо кандидат має стратегію [X, Y], а інший кандидат має стратегію [Y, X], це є помилкою користувача, і вибір лідера не буде здійснюватися до вирішення проблеми.

    (Альфа) Для використання цього поля потрібно увімкнути функціональну можливість CoordinatedLeaderElection.

  • binaryVersion (string)

    BinaryVersion — це бінарна версія. Вона повинна бути у форматі semver без початкової v. Це поле є обовʼязковим, коли стратегія "OldestEmulationVersion".

  • emulationVersion (string)

    EmulationVersion —це версія емуляції. Вона повинна бути у форматі semver без початкової v. EmulationVersion повинна бути менше або дорівнювати BinaryVersion. Це поле є обовʼязковим, коли стратегія є "OldestEmulationVersion".

  • pingTime (MicroTime)

    PingTime — це останній час, коли сервер запитував LeaseCandidate на продовження. Це виконується лише під час вибору лідера, щоб перевірити, чи стали якісь LeaseCandidates недійсними. Коли PingTime оновлюється, LeaseCandidate відповідає, оновлюючи RenewTime.

    MicroTime — це версія Time з точністю до мікросекунд.

  • renewTime (MicroTime)

    RenewTime — це час, коли LeaseCandidate був востаннє оновлений. Щоразу, коли Lease потребує вибору лідера, поле PingTime оновлюється, щоб сигналізувати LeaseCandidate про необхідність оновлення RenewTime. Старі обʼєкти LeaseCandidate також видаляються, якщо пройшло кілька годин з моменту останнього оновлення. Поле PingTime регулярно оновлюється, щоб запобігти видаленню ще активних LeaseCandidates.

    MicroTime — це версія Time з точністю до мікросекунд.

LeaseCandidateList

LeaseCandidateList — перелік обʼєктів Lease.


Operations


get отримати вказаного LeaseCandidate

HTTP запит

GET /apis/coordination.k8s.io/v1alpha1/namespaces/{namespace}/leasecandidates/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя LeaseCandidate

  • namespace (в шляху): string, обовʼязково

    namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (LeaseCandidate): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу LeaseCandidate

HTTP запит

GET /apis/coordination.k8s.io/v1alpha1/namespaces/{namespace}/leasecandidates

Параметри

Відповідь

200 (LeaseCandidateList): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу LeaseCandidate

HTTP запит

GET /apis/coordination.k8s.io/v1alpha1/leasecandidates

Параметри

Відповідь

200 (LeaseCandidateList): OK

401: Unauthorized

create створення LeaseCandidate

HTTP запит

POST /apis/coordination.k8s.io/v1alpha1/namespaces/{namespace}/leasecandidates

Параметри

Відповідь

200 (LeaseCandidate): OK

201 (LeaseCandidate): Created

202 (LeaseCandidate): Accepted

401: Unauthorized

update заміна вказаного LeaseCandidate

HTTP запит

PUT /apis/coordination.k8s.io/v1alpha1/namespaces/{namespace}/leasecandidates/{name}

Параметри

  • name (в шляху): string, обовʼязково

    name of the LeaseCandidate

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: LeaseCandidate, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (LeaseCandidate): OK

201 (LeaseCandidate): Created

401: Unauthorized

patch часткове оновлення вказаного LeaseCandidate

HTTP запит

PATCH /apis/coordination.k8s.io/v1alpha1/namespaces/{namespace}/leasecandidates/{name}

Параметри

  • name (в шляху): string, обовʼязково

    name of the LeaseCandidate

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (LeaseCandidate): OK

201 (LeaseCandidate): Created

401: Unauthorized

delete видалення LeaseCandidate

HTTP запит

DELETE /apis/coordination.k8s.io/v1alpha1/namespaces/{namespace}/leasecandidates/{name}

Параметри

  • name (в шляху): string, обовʼязково

    name of the LeaseCandidate

  • namespace (в шляху): string, обовʼязково

    namespace

  • body: DeleteOptions

  • dryRun (в запиті): string

    dryRun

  • gracePeriodSeconds (в запиті): integer

    gracePeriodSeconds

  • pretty (в запиті): string

    pretty

  • propagationPolicy (в запиті): string

    propagationPolicy

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції LeaseCandidate

HTTP запит

DELETE /apis/coordination.k8s.io/v1alpha1/namespaces/{namespace}/leasecandidates

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

6.5.8.7 - Namespace

Простір імен надає область видимості для імен.

apiVersion: v1

import "k8s.io/api/core/v1"

Namespace

Namespace надає область видимості для імен. Використання кількох просторів імен є необовʼязковим.


NamespaceSpec

NamespaceSpec описує атрибути простору імен.


  • finalizers ([]string)

    Atomic: буде замінено під час злиття

    Finalizers є непрозорим списком значень, які повинні бути порожніми щоб назавжди видалити обʼєкт з сховища. Докладніше: https://kubernetes.io/docs/tasks/administer-cluster/namespaces/

NamespaceStatus

NamespaceStatus — це інформація про поточний статус простору імен.


  • conditions ([]NamespaceCondition)

    Patch strategy: злиття за ключем type

    Map: унікальні значення ключа type будуть збережені під час злиття

    Представляє останні доступні спостереження поточного стану простору імен.

    NamespaceCondition містить деталі про стан контролера просторів імен.

    • conditions.status (string), обовʼязково

      Статус стану, одне з True, False, Unknown.

    • conditions.type (string), обовʼязково

      Тип стану контролера просторів імен.

    • conditions.lastTransitionTime (Time)

      Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

    • conditions.message (string)

    • conditions.reason (string)

  • phase (string)

    Phase — це поточна фаза життєвого циклу простору імен. Докладніше: https://kubernetes.io/docs/tasks/administer-cluster/namespaces/

NamespaceList

NamespaceList — це список просторів імен.


Операції


get отримати вказаний Namespace

HTTP запит

GET /api/v1/namespaces/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя Namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (Namespace): OK

401: Unauthorized

get отримати статус вказаного Namespace

HTTP запит

GET /api/v1/namespaces/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя Namespace

  • pretty (в запиті): string

    pretty

Відповідь

200 (Namespace): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу Namespace

HTTP запит

GET /api/v1/namespaces

Параметри

Відповідь

200 (NamespaceList): OK

401: Unauthorized

create створення Namespace

HTTP запит

POST /api/v1/namespaces

Параметри

Відповідь

200 (Namespace): OK

201 (Namespace): Created

202 (Namespace): Accepted

401: Unauthorized

update заміна вказаного Namespace

HTTP запит

PUT /api/v1/namespaces/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя Namespace

  • body: Namespace, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (Namespace): OK

201 (Namespace): Created

401: Unauthorized

update заміна, завершення вказаного Namespace

HTTP запит

PUT /api/v1/namespaces/{name}/finalize

Параметри

  • name (в шляху): string, обовʼязково

    імʼя Namespace

  • body: Namespace, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (Namespace): OK

201 (Namespace): Created

401: Unauthorized

update заміна статусу вказаного Namespace

HTTP запит

PUT /api/v1/namespaces/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя Namespace

  • body: Namespace, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (Namespace): OK

201 (Namespace): Created

401: Unauthorized

patch часткове оновлення вказаного Namespace

HTTP запит

PATCH /api/v1/namespaces/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя Namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (Namespace): OK

201 (Namespace): Created

401: Unauthorized

patch часткове оновлення статусу вказаного Namespace

HTTP запит

PATCH /api/v1/namespaces/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя Namespace

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (Namespace): OK

201 (Namespace): Created

401: Unauthorized

delete видалення Namespace

HTTP запит

DELETE /api/v1/namespaces/{name}

Параметри

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

6.5.8.8 - Node

Node — робочий вузол в Kubernetes.

apiVersion: v1

import "k8s.io/api/core/v1"

Node

Node є робочим вузлом в Kubernetes. Кожен вузол буде мати унікальний ідентифікатор у кеші (тобто в etcd).


NodeSpec

NodeSpec описує атрибути, з якими створюється вузол.


  • configSource (NodeConfigSource)

    Застаріло: Раніше використовувалося для вказівки джерела конфігурації вузла для функції DynamicKubeletConfig. Цю функцію вилучено.

    NodeConfigSource вказує джерело конфігурації вузла. Тільки одне підполе (без урахування метаданих) має бути не нульовим. Цей API є застарілим з версії 1.22

    • configSource.configMap (ConfigMapNodeConfigSource)

      ConfigMap є посиланням на ConfigMap вузла.

      ConfigMapNodeConfigSource містить інформацію для посилання на ConfigMap як джерело конфігурації для вузла. Цей API є застарілим з версії 1.22: https://git.k8s.io/enhancements/keps/sig-node/281-dynamic-kubelet-configuration

      • configSource.configMap.kubeletConfigKey (string), обовʼязково

        KubeletConfigKey визначає, який ключ посилання ConfigMap відповідає структурі KubeletConfiguration. Це поле є обовʼязковим у всіх випадках.

      • configSource.configMap.name (string), обовʼязково

        Name — metadata.name посилання ConfigMap. Це поле є обовʼязковим у всіх випадках.

      • configSource.configMap.namespace (string), обовʼязково

        Namespace — metadata.namespace посилання ConfigMap. Це поле є обовʼязковим у всіх випадках.

      • configSource.configMap.resourceVersion (string)

        ResourceVersion — metadata.ResourceVersion посилання ConfigMap. Це поле заборонено в Node.Spec, і обовʼязкове в Node.Status.

      • configSource.configMap.uid (string)

        UID є metadata.UID посилання ConfigMap. Це поле заборонено в Node.Spec, і обовʼязково в Node.Status.

  • externalID (string)

    Застаріло. Не всі kubelets встановлюватимуть це поле. Видаліть поле після версії 1.13. див.: https://issues.k8s.io/61966

  • podCIDR (string)

    PodCIDR представляє діапазон IP-адрес Podʼів, призначених вузлу.

  • podCIDRs ([]string)

    Set: унікальні значення будуть збережені під час злиття

    podCIDRs представляє діапазони IP-адрес, призначених вузлу для використання Podʼами на цьому вузлі. Якщо це поле вказане, перший запис повинен відповідати полю podCIDR. Воно може містити не більше одного значення для кожного з IPv4 та IPv6.

  • providerID (string)

    Ідентифікатор вузла, призначений постачальником хмарних послуг у форматі: <ProviderName>://<ProviderSpecificNodeID>

  • taints ([]Taint)

    Atomic: буде замінено під час злиття

    Якщо вказано, задає taints вузла.

    Вузол, до якого прив’язано цей Taint, має "ефект" на будь-який Pod, який не толерує Taint.

    • taints.effect (string), обовʼязково

      Обовʼязково. Ефект taint на Podʼи, які не толерують taint. Допустимі ефекти: NoSchedule, PreferNoSchedule і NoExecute.

    • taints.key (string), обовʼязково

      Обовʼязково. Ключ taint, який буде застосовано до вузла.

    • taints.timeAdded (Time)

      TimeAdded представляє час, коли taint було додано. Записується тільки для taint NoExecute.

      Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

    • taints.value (string)

      Значення taint, що відповідає ключу taint.

  • unschedulable (boolean)

    Unschedulable контролює можливість планування нових Podʼів на вузлі. Стандартно вузол є доступним для планування. Докладніше: https://kubernetes.io/docs/concepts/nodes/node/#manual-node-administration

NodeStatus

NodeStatus — це інформація про поточний статус вузла.


  • addresses ([]NodeAddress)

    Patch strategy: merge on key type

    Map: унікальні значення ключа type будуть збережені під час злиття

    Список адрес, доступних вузлу. Запитується у постачальника хмарних послуг, якщо доступно. Докладніше: https://kubernetes.io/docs/concepts/nodes/node/#addresses Примітка: Це поле визначено як доступне для злиття, але ключ злиття не є достатньо унікальним, що може призвести до пошкодження даних при злитті. Абоненти повинні використовувати патч для повної заміни. Див. приклад на https://pr.k8s.io/79391. Споживачі повинні припускати, що адреси можуть змінюватися протягом усього життя вузла. Однак є деякі винятки, коли це може бути неможливо, наприклад, Podʼи, які наслідують адресу вузла у своєму статусі, або споживачі API (status.hostIP).

    NodeAddress містить інформацію про адресу вузла.

    • addresses.address (string), обовʼязково

      Адреса вузла.

    • addresses.type (string), обовʼязково

      Тип адреси вузла, один із Hostname, ExternalIP або InternalIP.

  • allocatable (map[string]Quantity)

    Allocatable представляє ресурси вузла, доступні для планування. Стандартне значення — Capacity.

  • capacity (map[string]Quantity)

    Capacity представляє загальні ресурси вузла. Докладніше: https://kubernetes.io/docs/reference/node/node-status/#capacity

  • conditions ([]NodeCondition)

    Patch strategy: merge on key type

    Map: унікальні значення ключа type будуть збережені під час злиття

    Conditions — це масив поточних спостережуваних станів вузла. Докладніше: https://kubernetes.io/docs/concepts/nodes/node/#condition

    NodeCondition містить інформацію про стан вузла.

    • conditions.status (string), обовʼязково

      Статус стану, один із True, False, Unknown.

    • conditions.type (string), обовʼязково

      Тип стану вузла.

    • conditions.lastHeartbeatTime (Time)

      Останній час отримання оновлення про певний стан.

      Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

    • conditions.lastTransitionTime (Time)

      Останній час переходу стану від одного статусу до іншого.

      Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

    • conditions.message (string)

      Повідомлення, зрозуміле людині, що вказує на деталі останнього переходу.

    • conditions.reason (string)

      (коротко) причина останнього переходу стану.

  • config (NodeConfigStatus)

    Статус конфігурації, призначеної вузлу через функцію динамічної конфігурації Kubelet.

    NodeConfigStatus описує статус конфігурації, призначеної Node.Spec.ConfigSource.

    • config.active (NodeConfigSource)

      Active повідомляє про контрольовану конфігурацію, яку вузол активно використовує. Active представляє або поточну версію призначеної конфігурації, або поточну останню відому правильну конфігурацію, залежно від того, чи виникає помилка при спробі використати призначену конфігурацію.

      NodeConfigSource вказує джерело конфігурації вузла. Тільки одне підполе (без урахування метаданих), має бути не нульовим. Цей API є застарілим з версії 1.22

      • config.active.configMap (ConfigMapNodeConfigSource)

        ConfigMap є посиланням на ConfigMap вузла.

        ConfigMapNodeConfigSource містить інформацію для посилання на ConfigMap як джерело конфігурації для вузла. Цей API є застарілим з версії 1.22: https://git.k8s.io/enhancements/keps/sig-node/281-dynamic-kubelet-configuration

        • config.active.configMap.kubeletConfigKey (string), обовʼязково

          KubeletConfigKey визначає, який ключ посилання ConfigMap відповідає структурі KubeletConfiguration. Це поле є обовʼязковим у всіх випадках.

        • config.active.configMap.name (string), обовʼязково

          Name — metadata.name посилання ConfigMap. Це поле є обовʼязковим у всіх випадках.

        • config.active.configMap.namespace (string), обовʼязково

          Namespace — metadata.namespace посилання ConfigMap. Це поле є обовʼязковим у всіх випадках.

        • config.active.configMap.resourceVersion (string)

          ResourceVersion — metadata.ResourceVersion посилання ConfigMap. Це поле заборонено в Node.Spec, і обовʼязкове в Node.Status.

        • config.active.configMap.uid (string)

          UID — metadata.UID посилання ConfigMap. Це поле заборонено в Node.Spec, і обовʼязкове в Node.Status.

    • config.assigned (NodeConfigSource)

      Assigned повідомляє про контрольовану конфігурацію, яку вузол спробує використовувати. Коли Node.Spec.ConfigSource оновлюється, вузол зберігає асоційоване конфігураційне навантаження на локальний диск разом із записом, що вказує на призначену конфігурацію. Вузол звертається до цього запису, щоб вибрати свою контрольовану конфігурацію, і повідомляє про цей запис в Assigned. Assigned оновлюється в статусі лише після того, як запис збережено на диск. Коли Kubelet перезавантажується, він намагається зробити призначену конфігурацію активною конфігурацією, завантажуючи та перевіряючи контрольоване навантаження, ідентифіковане Assigned.

      NodeConfigSource вказує джерело конфігурації вузла. Тільки одне підполе (без урахування метаданих), має бути не нульовим. Цей API є застарілим з версії 1.22

      • config.assigned.configMap (ConfigMapNodeConfigSource)

        ConfigMap є посиланням на ConfigMap вузла

        ConfigMapNodeConfigSource містить інформацію для посилання на ConfigMap як джерело конфігурації для вузла. Цей API є застарілим з версії 1.22: https://git.k8s.io/enhancements/keps/sig-node/281-dynamic-kubelet-configuration

        • config.assigned.configMap.kubeletConfigKey (string), обовʼязково

          KubeletConfigKey визначає, який ключ посилання ConfigMap відповідає структурі KubeletConfiguration. Це поле є обовʼязковим у всіх випадках.

        • config.assigned.configMap.name (string), обовʼязково

          Name — metadata.name посилання ConfigMap. Це поле є обовʼязковим у всіх випадках.

        • config.assigned.configMap.namespace (string), обовʼязково

          Namespace — metadata.namespace посилання ConfigMap. Це поле є обовʼязковим у всіх випадках.

        • config.assigned.configMap.resourceVersion (string)

          ResourceVersion — metadata.ResourceVersion посилання ConfigMap. Це поле заборонено в Node.Spec, і обовʼязкове в Node.Status.

        • config.assigned.configMap.uid (string)

          UID — metadata.UID посилання ConfigMap. Це поле заборонено в Node.Spec, і обовʼязкове в Node.Status.

    • config.error (string)

      Error описує будь-які проблеми під час узгодження Spec.ConfigSource з Active конфігурацією. Помилки можуть виникати, наприклад, при спробі зберегти Spec.ConfigSource у локальний запис Assigned, при спробі зберегти повʼязане конфігураційне навантаження, при спробі завантажити або перевірити Assigned конфігурацію тощо. Помилки можуть виникати на різних етапах синхронізації конфігурації. Ранні помилки (наприклад, помилки завантаження або збереження) не призведуть до повернення до LastKnownGood і можуть бути виправлені під час повторних спроб Kubelet. Пізні помилки (наприклад, помилки завантаження або перевірки збереженої конфігурації) призведуть до повернення до LastKnownGood. У останньому випадку зазвичай можна вирішити помилку, виправивши конфігурацію, призначену в Spec.ConfigSource. Додаткову інформацію для налагодження можна знайти, шукаючи повідомлення про помилку в лозі Kubelet. Error є описом стану помилки, зрозумілим людині; машини можуть перевірити, чи порожній Error, але не повинні покладатися на стабільність тексту Error у різних версіях Kubelet.

    • config.lastKnownGood (NodeConfigSource)

      LastKnownGood повідомляє про контрольовану конфігурацію, до якої вузол повернеться при виникненні помилки під час спроби використати Assigned конфігурацію. Assigned конфігурація стає LastKnownGood, коли вузол визначає, що Assigned конфігурація стабільна і правильна. Це наразі реалізовано як 10-хвилинний період перевірки, що починається, коли локальний запис Assigned конфігурації оновлюється. Якщо Assigned конфігурація є Active наприкінці цього періоду, вона стає LastKnownGood. Зазначте, що якщо Spec.ConfigSource скидається до nil (використовуйте стандартні локальні налаштування), LastKnownGood також негайно скидається до nil, оскільки локальна стандартна конфігурація завжди вважається правильною. Ви не повинні робити припущення про метод вузла щодо визначення стабільності та правильності конфігурації, оскільки це може змінюватися або ставати налаштовуваним у майбутньому.

      NodeConfigSource вказує джерело конфігурації вузла. Тільки одне підполе (без урахування метаданих), має бути не нульовим. Цей API є застарілим з версії 1.22

      • config.lastKnownGood.configMap (ConfigMapNodeConfigSource)

        ConfigMap є посиланням на ConfigMap вузла.

        ConfigMapNodeConfigSource містить інформацію для посилання на ConfigMap як джерело конфігурації для вузла. Цей API є застарілим з версії 1.22: https://git.k8s.io/enhancements/keps/sig-node/281-dynamic-kubelet-configuration

        • config.lastKnownGood.configMap.kubeletConfigKey (string), обовʼязково

          KubeletConfigKey визначає, який ключ посилання ConfigMap відповідає структурі KubeletConfiguration. Це поле є обовʼязковим у всіх випадках.

        • config.lastKnownGood.configMap.name (string), обовʼязково

          Name — metadata.name посилання ConfigMap. Це поле є обовʼязковим у всіх випадках.

        • config.lastKnownGood.configMap.namespace (string), обовʼязково

          Namespace — metadata.namespace посилання ConfigMap. Це поле є обовʼязковим у всіх випадках.

        • config.lastKnownGood.configMap.resourceVersion (string)

          ResourceVersion — metadata.ResourceVersion посилання ConfigMap. Це поле заборонено в Node.Spec, і обовʼязкове в Node.Status.

        • config.lastKnownGood.configMap.uid (string)

          UID — metadata.UID посилання ConfigMap. Це поле заборонено в Node.Spec, і обовʼязкове в Node.Status.

  • daemonEndpoints (NodeDaemonEndpoints)

    Endpoints демонів, що працюють на вузлі.

    NodeDaemonEndpoints містить порти, відкриті демонами, що працюють на вузлі.

    • daemonEndpoints.kubeletEndpoint (DaemonEndpoint)

      Endpoint, на якому слухає Kubelet.

      DaemonEndpoint містить інформацію про один Endpoint демона.

      • daemonEndpoints.kubeletEndpoint.Port (int32), обовʼязково

        Номер порту даного Endpoint.

  • features (NodeFeatures)

    Features описує набір функцій, реалізованих реалізацією CRI.

    NodeFeatures описує набір функцій, реалізованих реалізацією CRI. Функції, що містяться в NodeFeatures, повинні залежати лише від реалізації CRI, незалежно від обробників під час виконання.

    • features.supplementalGroupsPolicy (boolean)

      SupplementalGroupsPolicy встановлюється в true, якщо середовище виконання підтримує SupplementalGroupsPolicy та ContainerUser.

  • images ([]ContainerImage)

    Atomic: буде замінено під час злиття

    Список контейнерних образів на цьому вузлі.

    Опис контейнерного образу

    • images.names ([]string)

      Atomic: буде замінено під час злиття

      Імена, відомі для образу. Наприклад, ["kubernetes.example/hyperkube:v1.0.7", "cloud-vendor.registry.example/cloud-vendor/hyperkube:v1.0.7"]

    • images.sizeBytes (int64)

      Розмір образу у байтах.

  • nodeInfo (NodeSystemInfo)

    Набір id/uuid для унікальної ідентифікації вузла. Докладніше: https://kubernetes.io/docs/concepts/nodes/node/#info

    NodeSystemInfo є набором id/uuid для унікальної ідентифікації вузла.

    • nodeInfo.architecture (string), обовʼязково

      Архітектура, повідомлена вузлом.

    • nodeInfo.bootID (string), обовʼязково

      Boot ID, повідомлений вузлом.

    • nodeInfo.containerRuntimeVersion (string), обовʼязково

      Версія контейнерного середовища, повідомлена вузлом через віддалений API середовища (наприклад, containerd://1.4.2).

    • nodeInfo.kernelVersion (string), обовʼязково

      Версія ядра, повідомлена вузлом з 'uname -r' (наприклад, 3.16.0-0.bpo.4-amd64).

    • nodeInfo.kubeProxyVersion (string), обовʼязково

      Застаріле: Версія KubeProxy, повідомлена вузлом.

    • nodeInfo.kubeletVersion (string), обовʼязково

      Версія Kubelet, повідомлена вузлом.

    • nodeInfo.machineID (string), обовʼязково

      MachineID, повідомлений вузлом. Для унікальної ідентифікації машини в кластері це поле є переважним. Докладніше у man(5) machine-id: http://man7.org/linux/man-pages/man5/machine-id.5.html

    • nodeInfo.operatingSystem (string), обовʼязково

      Операційна система, повідомлена вузлом.

    • nodeInfo.osImage (string), обовʼязково

      Образ ОС, повідомлений вузлом з /etc/os-release (наприклад, Debian GNU/Linux 7 (wheezy)).

    • nodeInfo.systemUUID (string), обовʼязково

      SystemUUID, повідомлений вузлом. Для унікальної ідентифікації машини переважним є MachineID. Це поле специфічне для хостів Red Hat https://access.redhat.com/documentation/en-us/red_hat_subscription_management/1/html/rhsm/uuid

  • phase (string)

    NodePhase є недавно спостережуваною фазою життєвого циклу вузла. Докладніше: https://kubernetes.io/docs/concepts/nodes/node/#phase. Поле ніколи не заповнюється і тепер є застарілим.

  • runtimeHandlers ([]NodeRuntimeHandler)

    Atomic: буде замінено під час злиття

    Доступні обробники середовища виконання.

    NodeRuntimeHandler — це набір інформації про обробники середовища виконання.

    • runtimeHandlers.features (NodeRuntimeHandlerFeatures)

      Підтримувані функції.

      NodeRuntimeHandlerFeatures — це набір функцій, реалізованих обробником середовища виконання.

      • runtimeHandlers.features.recursiveReadOnlyMounts (boolean)

        RecursiveReadOnlyMounts встановлюється в true, якщо обробник середовища виконання підтримує RecursiveReadOnlyMounts.

      • runtimeHandlers.features.userNamespaces (boolean)

        UserNamespaces встановлюється в true, якщо обробник середовища виконання підтримує UserNamespaces, включаючи підтримку для томів.

    • runtimeHandlers.name (string)

      Назва обробника середовища виконання. Порожнє для стандартного обробника середовища виконання.

  • volumesAttached ([]AttachedVolume)

    Atomic: буде замінено під час злиття

    Список томів, підключених до вузла.

    AttachedVolume описує том, підключений до вузла

    • volumesAttached.devicePath (string), обовʼязково

      DevicePath представляє шлях пристрою, де том має бути доступний.

    • volumesAttached.name (string), обовʼязково

      Імʼя підключеного тому.

  • volumesInUse ([]string)

    Atomic: буде замінено під час злиття

    Список підключених томів, що використовуються (змонтовані) вузлом.

NodeList

NodeList є повним списком усіх вузлів, які зареєстровані у панелі управління.


Операції


get отримати вказаний Node

HTTP запит

GET /api/v1/nodes/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя Node

  • pretty (в запиті): string

    pretty

Відповідь

200 (Node): OK

401: Unauthorized

get отримати статус вказаного Node

HTTP запит

GET /api/v1/nodes/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя Node

  • pretty (в запиті): string

    pretty

Відповідь

200 (Node): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу Node

HTTP запит

GET /api/v1/nodes

Параметри

Відповідь

200 (NodeList): OK

401: Unauthorized

create створення Node

HTTP запит

POST /api/v1/nodes

Параметри

  • body: Node, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (Node): OK

201 (Node): Created

202 (Node): Accepted

401: Unauthorized

update заміна вказаного Node

HTTP запит

PUT /api/v1/nodes/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя Node

  • body: Node, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (Node): OK

201 (Node): Created

401: Unauthorized

update заміна статусу вказаного Node

HTTP запит

PUT /api/v1/nodes/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя Node

  • body: Node, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (Node): OK

201 (Node): Created

401: Unauthorized

patch часткове оновлення вказаного Node

HTTP запит

PATCH /api/v1/nodes/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя Node

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (Node): OK

201 (Node): Created

401: Unauthorized

patch часткове оновлення статусу вказаного Node

HTTP запит

PATCH /api/v1/nodes/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя Node

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (Node): OK

201 (Node): Created

401: Unauthorized

delete видалення Node

HTTP запит

DELETE /api/v1/nodes/{name}

Параметри

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції Node

HTTP запит

DELETE /api/v1/nodes

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

6.5.8.9 - RuntimeClass

RuntimeClass визначає клас середовища виконання контейнерів, підтримуваних у кластері.

apiVersion: node.k8s.io/v1

import "k8s.io/api/node/v1"

RuntimeClass

RuntimeClass визначає клас середовища виконання контейнерів, підтримуваних у кластері. RuntimeClass використовується для визначення, яке середовище виконання контейнерів використовується для запуску всіх контейнерів у Podʼі. RuntimeClass визначаються вручну користувачем або провайдером кластера і посилаються в PodSpec. Kubelet відповідає за розвʼязання посилання RuntimeClassName перед запуском Podʼа. Для отримання додаткової інформації дивіться: https://kubernetes.io/docs/concepts/containers/runtime-class/


  • apiVersion: node.k8s.io/v1

  • kind: RuntimeClass

  • metadata (ObjectMeta)

    Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

  • handler (string), обовʼязково

    handler визначає базове середовище виконання та конфігурацію, яку реалізація CRI буде використовувати для обробки Podʼів цього класу. Можливі значення специфічні для конфігурації вузла та CRI. Припускається, що всі обробники доступні на кожному вузлі, і обробники з однаковими назвами еквівалентні на кожному вузлі. Наприклад, обробник з назвою "runc" може вказувати, що для запуску контейнерів у Podʼі буде використовуватися середовище виконання runc OCI (з використанням нативних Linux контейнерів). Handler повинен бути у нижньому регістрі, відповідати вимогам мітки DNS (RFC 1123) і бути незмінним.

  • overhead (Overhead)

    overhead представляє накладні витрати ресурсів, повʼязані з запуском Podʼа для даного RuntimeClass. Для отримання додаткової інформації дивіться https://kubernetes.io/docs/concepts/scheduling-eviction/pod-overhead/

    Структура Overhead представляє накладні витрати ресурсів, повʼязані з запуском Podʼа.

    • overhead.podFixed (map[string]Quantity)

      podFixed представляє фіксовані накладні витрати ресурсів, повʼязані з запуском Podʼа.

  • scheduling (Scheduling)

    scheduling містить обмеження планування, щоб забезпечити розміщення Podʼів, які працюють з цим RuntimeClass, на вузлах, які його підтримують. Якщо scheduling дорівнює nil, передбачається, що цей RuntimeClass підтримується всіма вузлами.

    Scheduling визначає обмеження планування для вузлів, які підтримують RuntimeClass.

    • scheduling.nodeSelector (map[string]string)

      nodeSelector перераховує мітки, які повинні бути присутніми на вузлах, що підтримують цей RuntimeClass. Podʼи, що використовують цей RuntimeClass, можуть бути розміщені тільки на вузлах, що відповідають цьому селектору. Селектор вузла RuntimeClass обʼєднується з наявним селектором вузла Podʼа. Будь-які конфлікти призведуть до відхилення Podʼа на етапі допуску.

    • scheduling.tolerations ([]Toleration)

      Atomic: буде замінено під час злиття

      tolerations додаються (за винятком дублікатів) до Podʼів, що працюють з цим RuntimeClass під час допуску, ефективно обʼєднуючи набір вузлів, які Pod та RuntimeClass можуть толерувати.

      Pod, до якого привʼязаний цей Toleration, толерує будь-який taint, що відповідає трійці <key,value,effect> за допомогою оператора порівняння .

      • scheduling.tolerations.key (string)

        Key — це ключ taint, до якого застосовується toleration. Порожній ключ означає відповідність всім ключам taint. Якщо ключ порожній, оператор повинен бути Exists; ця комбінація означає відповідність усім значенням та всім ключам.

      • scheduling.tolerations.operator (string)

        Operator представляє відношення ключа до значення. Допустимі оператори: Exists і Equal. Стандартне значення — Equal. Exists еквівалентно шаблону для значення, так що Pod може толерувати всі taints певної категорії.

      • scheduling.tolerations.value (string)

        Value — це значення taint, з яким збігається toleration. Якщо оператор Exists, значення повинно бути порожнім, інакше — це просто звичайний рядок.

      • scheduling.tolerations.effect (string)

        Effect вказує ефект taint для порівняння. Порожній означає відповідність всім ефектам taint. Якщо вказано, допустимі значення — NoSchedule, PreferNoSchedule та NoExecute.

      • scheduling.tolerations.tolerationSeconds (int64)

        TolerationSeconds представляє період часу, протягом якого toleration (який повинен мати ефект NoExecute, інакше це поле ігнорується) толерує taint. Стандартне значення — не встановлено, що означає толерування taint назавжди (не виселяти). Нульові та відʼємні значення будуть розглядатися системою як 0 (негайне виселення).

RuntimeClassList

RuntimeClassList — це список обʼєктів RuntimeClass.


Операції


get отримати вказаний RuntimeClass

HTTP запит

GET /apis/node.k8s.io/v1/runtimeclasses/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя RuntimeClass

  • pretty (в запиті): string

    pretty

Відповідь

200 (RuntimeClass): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу RuntimeClass

HTTP запит

GET /apis/node.k8s.io/v1/runtimeclasses

Параметри

Відповідь

200 (RuntimeClassList): OK

401: Unauthorized

create створення RuntimeClass

HTTP запит

POST /apis/node.k8s.io/v1/runtimeclasses

Параметри

Відповідь

200 (RuntimeClass): OK

201 (RuntimeClass): Created

202 (RuntimeClass): Accepted

401: Unauthorized

update заміна вказаного RuntimeClass

HTTP запит

PUT /apis/node.k8s.io/v1/runtimeclasses/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя RuntimeClass

  • body: RuntimeClass, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (RuntimeClass): OK

201 (RuntimeClass): Created

401: Unauthorized

patch часткове оновлення вказаного RuntimeClass

HTTP запит

PATCH /apis/node.k8s.io/v1/runtimeclasses/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя RuntimeClass

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (RuntimeClass): OK

201 (RuntimeClass): Created

401: Unauthorized

delete видалення RuntimeClass

HTTP запит

DELETE /apis/node.k8s.io/v1/runtimeclasses/{name}

Параметри

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції RuntimeClass

HTTP запит

DELETE /apis/node.k8s.io/v1/runtimeclasses

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

6.5.8.10 - ServiceCIDR v1beta1

ServiceCIDR визначає діапазон IP-адрес у форматі CIDR (наприклад, 192.168.0.0/24 або 2001:db2::/64).

apiVersion: networking.k8s.io/v1beta1

import "k8s.io/api/networking/v1beta1"

ServiceCIDR

ServiceCIDR визначає діапазон IP-адрес у форматі CIDR (наприклад, 192.168.0.0/24 або 2001:db2::/64). Цей діапазон використовується для виділення ClusterIP для обʼєктів Service.


ServiceCIDRSpec

ServiceCIDRSpec визначає CIDR, які користувач хоче використовувати для виділення ClusterIP для Services.


  • cidrs ([]string)

    Atomic: буде замінено під час злиття

    CIDRs визначає IP-блоки у нотації CIDR (наприклад, "192.168.0.0/24" або "2001:db8::/64"), з яких призначаються IP-адреси для сервісів кластера. Дозволено не більше двох CIDR, по одному для кожного сімейства IP. Це поле є незмінним.

ServiceCIDRStatus

ServiceCIDRStatus описує поточний стан ServiceCIDR.


  • conditions ([]Condition)

    Patch strategy: злиття за ключем type

    Map: унікальні значення ключа type будуть збережені під час злиття

    conditions містить масив metav1.Condition, який описує стан ServiceCIDR. Поточний стан сервісу.

    Condition містить деталі для одного аспекту поточного стану цього API-ресурсу.

    • conditions.lastTransitionTime (Time), обовʼязково

      lastTransitionTime — це останній час, коли стан змінився з одного статусу на інший. Це повинно відповідати моменту, коли змінився основний стан. Якщо це невідомо, можна використовувати час, коли змінилося поле API.

      Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

    • conditions.message (string), обовʼязково

      message — це зрозуміле для людини повідомлення, яке надає деталі про перехід. Це може бути порожній рядок.

    • conditions.reason (string), обовʼязково

      reason містить програмний ідентифікатор, що вказує причину останньої зміни стану. Виробники певних типів станів можуть визначати очікувані значення та значення для цього поля та чи вважаються ці значення гарантованими API. Значення має бути рядком у CamelCase. Це поле не може бути порожнім.

    • conditions.status (string), обовʼязково

      статус стану, одне з True, False, Unknown.

    • conditions.type (string), обовʼязково

      тип стану в CamelCase або у форматі foo.example.com/CamelCase.

    • conditions.observedGeneration (int64)

      observedGeneration представляє .metadata.generation, на основі якого було встановлено стан. Наприклад, якщо .metadata.generation наразі дорівнює 12, але .status.conditions[x].observedGeneration дорівнює 9, стан застарів щодо поточного стану екземпляра.

ServiceCIDRList

ServiceCIDRList містить список об'єктів ServiceCIDR.


Операції


get Отримати вказаний ServiceCIDR

HTTP запит

GET /apis/networking.k8s.io/v1beta1/servicecidrs/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ServiceCIDR

  • pretty (в запиті): string

    pretty

Відповідь

200 (ServiceCIDR): OK

401: Unauthorized

get отримати статус вказаного ServiceCIDR

HTTP запит

GET /apis/networking.k8s.io/v1beta1/servicecidrs/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ServiceCIDR

  • pretty (в запиті): string

    pretty

Відповідь

200 (ServiceCIDR): OK

401: Unauthorized

list перелік або перегляд обʼєктів типу ServiceCIDR

HTTP запит

GET /apis/networking.k8s.io/v1beta1/servicecidrs

Параметри

Відповідь

200 (ServiceCIDRList): OK

401: Unauthorized

create створення ServiceCIDR

HTTP запит

POST /apis/networking.k8s.io/v1beta1/servicecidrs

Параметри

Відповідь

200 (ServiceCIDR): OK

201 (ServiceCIDR): Created

202 (ServiceCIDR): Accepted

401: Unauthorized

update заміна вказаного ServiceCIDR

HTTP запит

PUT /apis/networking.k8s.io/v1beta1/servicecidrs/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ServiceCIDR

  • body: ServiceCIDR, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (ServiceCIDR): OK

201 (ServiceCIDR): Created

401: Unauthorized

update заміна статусу вказаного ServiceCIDR

HTTP запит

PUT /apis/networking.k8s.io/v1beta1/servicecidrs/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ServiceCIDR

  • body: ServiceCIDR, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • pretty (в запиті): string

    pretty

Відповідь

200 (ServiceCIDR): OK

201 (ServiceCIDR): Created

401: Unauthorized

patch часткове оновлення вказаного ServiceCIDR

HTTP запит

PATCH /apis/networking.k8s.io/v1beta1/servicecidrs/{name}

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ServiceCIDR

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (ServiceCIDR): OK

201 (ServiceCIDR): Created

401: Unauthorized

patch часткове оновлення статусу вказаного ServiceCIDR

HTTP запит

PATCH /apis/networking.k8s.io/v1beta1/servicecidrs/{name}/status

Параметри

  • name (в шляху): string, обовʼязково

    імʼя ServiceCIDR

  • body: Patch, обовʼязково

  • dryRun (в запиті): string

    dryRun

  • fieldManager (в запиті): string

    fieldManager

  • fieldValidation (в запиті): string

    fieldValidation

  • force (в запиті): boolean

    force

  • pretty (в запиті): string

    pretty

Відповідь

200 (ServiceCIDR): OK

201 (ServiceCIDR): Created

401: Unauthorized

delete видалення ServiceCIDR

HTTP запит

DELETE /apis/networking.k8s.io/v1beta1/servicecidrs/{name}

Параметри

Відповідь

200 (Status): OK

202 (Status): Accepted

401: Unauthorized

deletecollection видалення колекції ServiceCIDR

HTTP запит

DELETE /apis/networking.k8s.io/v1beta1/servicecidrs

Параметри

Відповідь

200 (Status): OK

401: Unauthorized

6.5.9 - Загальні визначення

6.5.9.1 - DeleteOptions

DeleteOptions можуть бути надані при видаленні обʼєкта API.

import "k8s.io/apimachinery/pkg/apis/meta/v1"

DeleteOptions можуть бути надані при видаленні обʼєкта API.


  • apiVersion (string)

    APIVersion визначає версійовану схему цього представлення обʼєкта. Сервери повинні конвертувати визнані схеми до останнього внутрішнього значення, і можуть відхилити невизнані значення. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources

  • dryRun ([]string)

    Atomic: буде замінено під час злиття

    Коли параметр присутній, вказує, що зміни не повинні бути збережені. Недійсні або невизнані директиви dryRun призведуть до відповіді з помилкою і подальшої відмови в обробці запиту. Допустимі значення: - All: всі етапи випробувального запуску будуть оброблені

  • gracePeriodSeconds (int64)

    Тривалість в секундах до видалення обʼєкта. Значення повинно бути не відʼємним цілим числом. Значення нуль означає видалення без затримки. Якщо це значення є nil, буде використовуватися стандартне значення для вказаних типів. Стандартно буде використовуватися значення для обʼєкта, якщо не вказано. Нуль означає видалення без затримки.

  • kind (string)

    Kind — це рядкове значення, що представляє ресурс REST, який представляє цей обʼєкт. Сервери можуть отримати це з точки доступу, на яку клієнт надсилає запити. Не може бути оновлено. У форматі CamelCase. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds

  • orphanDependents (boolean)

    Застаріле: будь ласка, використовуйте PropagationPolicy, це поле буде застаріле в версії 1.7. Чи повинні бути покинуті залежні обʼєкти. Якщо true/false, завершувач "orphan" буде доданий/видалений зі списку завершувачів обʼєкта. Можна встановити або це поле, або PropagationPolicy, але не обидва.

  • preconditions (Preconditions)

    Має бути виконано перед видаленням. Якщо це неможливо, буде повернено статус 409 Conflict.

    Умови мають бути виконані перед виконанням операції (оновлення, видалення і т. д.).

    • preconditions.resourceVersion (string)

      Вказує цільову ResourceVersion

    • preconditions.uid (string)

      Вказує цільовий UID.

  • propagationPolicy (string)

    Чи та як буде виконуватися збір сміття. Можна встановити або це поле, або OrphanDependents. Стандартна політика визначається наявним набором завершувачів у metadata.finalizers та стандартною політикою, що специфічна для ресурсу. Прийнятні значення: 'Orphan' — залишити залежності без батьків; 'Background' — дозволити збирачеві сміття видаляти залежності в фоновому режимі; 'Foreground' — каскадна політика, що видаляє всі залежності безпосередньо.

6.5.9.2 - LabelSelector

Селектор міток — є запитом на наявність міток до набору ресурсів.

import "k8s.io/apimachinery/pkg/apis/meta/v1"

Селектор міток — це запит на наявність міток до набору ресурсів. Результати matchLabels та matchExpressions поєднуються логічним І (AND). Порожній селектор міток має збіг зі всіма обʼєктам. Нульовий селектор міток не збігається з жодним обʼєктом.


  • matchExpressions ([]LabelSelectorRequirement)

    Atomic: буде замінено під час злиття

    matchExpressions — це список вимог селектора міток. Вимоги зʼєднуються логічною операцією І (AND).

    Вимоги селектора міток — це селектор, що містить значення, ключ та оператор, який повʼязує ключ і значення.

    • matchExpressions.key (string), обовʼязково

      key — це ключ мітки, до якого застосовується селектор.

    • matchExpressions.operator (string), обовʼязково

      operator представляє стосунок ключа до набору значень. Допустимі оператори: In, NotIn, Exists та DoesNotExist.

    • matchExpressions.values ([]string)

      Atomic: буде замінено під час злиття

      values — це масив рядкових значень. Якщо оператор — In або NotIn, масив значень повинен бути не пустим. Якщо оператор — Exists або DoesNotExist, масив значень повинен бути пустим. Цей масив замінюється під час стратегічного злиття патча.

  • matchLabels (map[string]string)

    matchLabels — це зіставлення пар {ключ, значення}. Один {ключ, значення} у зіставленні matchLabels еквівалентний елементу matchExpressions, де поле key — "key", оператор — "In", а масив значень містить лише "value". Вимоги зʼєднуються логічною операцією І (AND).

6.5.9.3 - ListMeta

ListMeta описує метадані, які синтетичні ресурси повинні мати, включаючи списки та різноманітні обʼєкти статусу.

import "k8s.io/apimachinery/pkg/apis/meta/v1"

ListMeta описує метадані, які синтетичні ресурси повинні мати, включаючи списки та різноманітні обʼєкти статусу. Ресурс може мати лише один з {ObjectMeta, ListMeta}.


  • continue (string)

    continue може бути встановлено, якщо користувач встановив обмеження на кількість елементів, які повертаються, і вказує на те, що сервер має більше даних. Значення непрозоре і може бути використано для видачі іншого запиту до точки доступу, яка обслуговувала цей список, для отримання наступного набору доступних обʼєктів. Продовження стабільного списку може бути неможливим, якщо конфігурація сервера змінилася або пройшло більше декількох хвилин. Поле resourceVersion, повернене при використанні цього значення continue, буде ідентичним значенню у першій відповіді, якщо ви не отримали цей токен з повідомлення про помилку.

  • remainingItemCount (int64)

    remainingItemCount — це кількість наступних елементів у списку, які не включені у цю відповідь списку. Якщо запит на список містив селектори міток або полів, то кількість залишених елементів невідома, і поле буде залишено невстановленим і опущено під час серіалізації. Якщо список завершено (або через те, що він не розділяється на частини, або через те, що це остання частина), то більше залишених елементів немає, і це поле буде залишено невстановленим і опущено під час серіалізації. Сервери, старші за v1.15, не встановлюють це поле. Призначене використання remainingItemCount — оцінювання розміру колекції. Клієнти не повинні покладатися на встановлення або точність remainingItemCount.

  • resourceVersion (string)

    Рядок, який ідентифікує внутрішню версію цього обʼєкта на сервері, яку можуть використовувати клієнти для визначення, коли обʼєкти змінилися. Значення повинно бути розглянуте клієнтами як непрозоре і передане незміненим назад на сервер. Заповнюється системою. Тільки для читання. Додаткова інформація: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#concurrency-control-and-consistency

  • selfLink (string)

    Застаріле: selfLink — це застаріле поле тільки для читання, яке більше не заповнюється системою.

6.5.9.4 - LocalObjectReference.

LocalObjectReference містить достатньо інформації, щоб дозволити вам знайти вказаний обʼєкт всередині того самого простору імен.

import "k8s.io/api/core/v1"

LocalObjectReference містить достатньо інформації, щоб дозволити вам знайти вказаний обʼєкт всередині того самого простору імен." title: "LocalObjectReference


  • name (string)

    Назва обʼєкта, на який ви посилаєтеся. Це поле є фактично обов'язковим, але через зворотну сумісність дозволено залишати його порожнім. Екземпляри цього типу з порожнім значенням тут, як правило, є помилковими. Докладніше: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names

6.5.9.5 - NodeSelectorRequirement

Вимоги селектора вузлів — це селектор, що містить значення, ключ та оператор, який повʼязує ключ і значення.

import "k8s.io/api/core/v1"

Вимоги селектора вузлів — це селектор, що містить значення, ключ та оператор, який повʼязує ключ і значення.


  • key (string), обовʼязково

    key — це ключ мітки, до якого застосовується селектор.

  • operator (string), обовʼязково

    operator представляє стосунок ключа до набору значень. Допустимі оператори: In, NotIn, Exists, DoesNotExist, Gt та Lt.

  • values ([]string)

    Atomic: буде замінено під час злиття

    values — це масив рядкових значень. Якщо оператор — In або NotIn, масив значень повинен бути не пустим. Якщо оператор — Exists або DoesNotExist, масив значень повинен бути пустим. Якщо оператор — Gt або Lt, масив значень повинен містити один елемент, який буде інтерпретовано як ціле число. Цей масив замінюється під час стратегічного злиття патча.

6.5.9.6 - ObjectFieldSelector

ObjectFieldSelector вибирає поле з версією API обʼєкта.

import "k8s.io/api/core/v1"

ObjectFieldSelector вибирає поле з версією API обʼєкта.


  • fieldPath (string), обовʼязково

    Шлях поля для вибору в зазначеній версії API.

  • apiVersion (string)

    Версія схеми, в якій виражений fieldPath, стандартне значення — "v1".

6.5.9.7 - ObjectMeta

ObjectMeta — це метадані, які повинні бути у всіх збережених ресурсів, включаючи всі обʼєкти, які користувачі повинні створювати.

import "k8s.io/apimachinery/pkg/apis/meta/v1"

ObjectMeta — це метадані, які повинні бути у всіх збережених ресурсів, включаючи всі обʼєкти, які користувачі повинні створювати.


  • name (string)

    Ім’я (назва) має бути унікальним у просторі імен. Потрібне під час створення ресурсів, хоча деякі ресурси можуть дозволяти клієнту запитувати створення відповідного імені автоматично. Назва в першу чергу призначена для створення ідемпотентності та визначення конфігурації. Не може бути змінене. Більше інформації: https://kubernetes.io/docs/concepts/overview/working-with-objects/names#names

  • generateName (string)

    GenerateName — це необов’язковий префікс, який використовується сервером для генерації унікального імені, ТІЛЬКИ ЯКЩО поле Name не було надано. Якщо використовується це поле, ім’я, що повертається клієнту, відрізнятиметься від переданого. Це значення також поєднується з унікальним суфіксом. Надане значення має ті самі правила перевірки, що й поле Name, і може бути скорочено на довжину суфікса, необхідного для того, щоб зробити значення унікальним на сервері.

    Якщо це поле вказано, а згенерована назва існує, сервер поверне 409.

    Застосовується, лише якщо ім’я не вказано. Більше інформації: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#idempotency

  • namespace (string)

    Простір імен визначає простір, у якому кожне ім’я має бути унікальним. Порожній простір імен еквівалентний простору імен "default", але "default" є канонічним представленням. Не всі об’єкти повинні мати область імен — значення цього поля для цих об’єктів буде порожнім.

    Має бути DNS_LABEL. Не може бути змінене. Більше інформації: https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces

  • labels (map[string]string)

    Масив (map) рядків ключів і значень, які можна використовувати для організації та категоризації (охоплення та вибору) обʼєктів. Може відповідати селекторам контролерів реплікації та сервісів. Більше інформації: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels

  • annotations (map[string]string)

    Анотації — це неструктурований масив (map) значень ключів, що зберігається з ресурсом, який може бути заданий зовнішніми інструментами для зберігання та отримання довільних метаданих. Вони не є запитуваними та повинні зберігатися при модифікації обʼєктів. Більше інформації: https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations

System

  • finalizers ([]string)

    Set: унікальні значення будуть збережені під час злиття

    Це поле повинно бути порожнім перед тим, як обʼєкт буде видалено з реєстру. Кожен запис є ідентифікатором відповідального компонента, який видалить цей запис зі списку. Якщо deletionTimestamp обʼєкта не є nil, записи у цьому списку можуть бути лише видалені. Завершувачі можуть оброблятися та видалятися у будь-якому порядку. Порядок НЕ є обовʼязковим, оскільки це створює значний ризик зависання завершувачів. Поле finalizers є спільним, будь-який актор з відповідними дозволами може змінити його порядок. Якщо список завершувачів обробляється у порядку, це може призвести до ситуації, коли компонент, відповідальний за перший завершувач у списку, чекає сигналу (значення поля, зовнішньої системи або іншого), що виробляється компонентом, відповідальним за завершувача, який знаходиться далі у списку, що призводить до тупикової ситуації. Без обовʼязкового порядку завершувачі можуть впорядковуватися самостійно та не вразливі до змін порядку у списку.

  • managedFields ([]ManagedFieldsEntry)

    Atomic: буде замінено під час злиття

    ManagedFields зіставляє ідентифікатор робочого процесу та версію з набором полів, якими керує цей робочий процес. Це здебільшого для внутрішнього ведення обліку, і користувачам зазвичай не потрібно встановлювати або розуміти це поле. Робочий процес може бути імʼям користувача, імʼям контролера або імʼям конкретного шляху застосування, як-от "ci-cd". Набір полів завжди знаходиться у версії, яку використовував робочий процес при зміні обʼєкта.

    ManagedFieldsEntry — це ідентифікатор робочого процесу, набір полів (FieldSet) і версія групи ресурсу, до якого застосовується набір полів.

    • managedFields.apiVersion (string)

      APIVersion визначає версію ресурсу, до якого застосовується цей набір полів. Формат такий самий, як у верхньорівневого поля APIVersion: "group/version". Це необхідно для відстеження версії набору полів, оскільки він не може бути автоматично конвертований.

    • managedFields.fieldsType (string)

      FieldsType є дискримінатором для різних форматів і версій полів. На цей час можливе лише одне значення: "FieldsV1".

    • managedFields.fieldsV1 (FieldsV1)

      FieldsV1 зберігає перший формат JSON версії, як описано в типі "FieldsV1".

      *FieldsV1 зберігає набір полів у структурі даних, подібній до Trie, у форматі JSON.

      Кожен ключ або представляє саму область (позначену як '.'), і завжди буде зіставлятись з порожнім набором, або є рядком, що представляє субполе або елемент. Рядок буде слідувати одному з чотирьох форматів: f:<name>, де <name> — це імʼя поля в структурі або ключа в map; v:<value>, де <value> — це точне значення у форматі JSON для елемента списку; i:<index>, де <index> — це позиція елемента у списку; k:<keys>, де <keys> — це масив (map) полів ключів елемента списку з їх унікальними значеннями. Якщо ключ зіставляється з порожнім значенням Fields, поле, яке представляє цей ключ, є частиною набору.

      Точний формат визначено в sigs.k8s.io/structured-merge-diff*

    • managedFields.manager (string)

      Manager є ідентифікатором робочого процесу, що керує цим набором полів.

    • managedFields.operation (string)

      Operation — це тип операції, яка призвела до створення цього запису ManagedFieldsEntry. Єдині допустимі значення для цього поля — 'Apply' та 'Update'.

    • managedFields.subresource (string)

      Subresource — це назва субресурсу, який використовується для оновлення цього обʼєкта, або порожній рядок, якщо обʼєкт було оновлено через основний ресурс. Значення цього поля використовується для розрізнення між менеджерами, навіть якщо вони мають однакові імена. Наприклад, оновлення статусу буде відрізнятися від звичайного оновлення за допомогою того самого імені менеджера. Зверніть увагу, що поле APIVersion не повʼязане з полем Subresource і завжди відповідає версії основного ресурсу.

    • managedFields.time (Time)

      Time — це часовий відбиток, коли був доданий запис ManagedFields. Час також буде оновлено, якщо додано поле, менеджер змінює будь-яке зі значень власних полів або видаляє поле. Відмітка часу не оновлюється, коли поле видаляється з запису через те, що його взяв на себе інший менеджер.

      Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

    • ownerReferences ([]OwnerReference)

      Patch strategy: злиття за ключем uid

      Map: унікальні значення ключа uid будуть збережені під час злиття

      Список обʼєктів, від яких залежить цей обʼєкт. Якщо ВСІ обʼєкти у списку були видалені, цей обʼєкт буде прибраний в процесі збирання сміття. Якщо цей обʼєкт керується контролером, то запис у цьому списку вказуватиме на цей контролер, із полем controller встановленим в true. Не може бути більше одного керуючого контролера.

      OwnerReference містить достатньо інформації, щоб дозволити вам ідентифікувати власний обʼєкт. Власний обʼєкт повинен бути в тому ж просторі імен, що й залежний, або мати область видимості кластера, тому поля namespace немає.

    • ownerReferences.apiVersion (string), обовʼязкове

      APIVersion визначає версію ресурсу, до якого відноситься цей обʼєкт.

    • ownerReferences.kind (string), обовʼязкове

      Kind визначає тип ресурсу, до якого відноситься цей обʼєкт. Докладніше: hhtps://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds

    • ownerReferences.name (string), обовʼязкове

      Ім’я визначає ім’я ресурсу, до якого відноситься цей обʼєкт. Докладніше: hhtps://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#names

    • ownerReferences.uid (string), обовʼязкове

      UID визначає унікальний ідентифікатор ресурсу, до якого відноситься цей обʼєкт. Докладніше: hhtps://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#uids

    • ownerReferences.blockOwnerDeletion (boolean)

      Якщо true, І якщо у власника є pfdthoedfx "foregroundDeletion", то власника не можна видалити зі сховища ключ-значення, доки це посилання не буде видалено. Див. https://kubernetes.io/docs/concepts/architecture/garbage-collection/#foreground-deletion щодо того, як збирач сміття взаємодіє з цим полем та застосовує явне видалення. стандартно — false. Щоб встановити це поле, користувачу потрібно мати дозвіл "delete" від власника, інакше буде повернуто 422 (Unprocessable Entity).

    • ownerReferences.controller (boolean)

      Якщо true, це посилання вказує на керуючий контролер.

Read-only

  • creationTimestamp (Time)

    CreationTimestamp — це відмітка часу, що представляє час сервера під час створення цього обʼєкта. Немає гарантії, що вона встановлена в порядку "відбулося перед" між окремими операціями. Клієнти не можуть встановлювати це значення. Використовується формат RFC3339 та знаходиться в часовому поясі UTC.

    Заповнюється системою. Тільки для читання. Null для списків. Додаткова інформація: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

    Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

  • deletionGracePeriodSeconds (int64)

    Кількість секунд, які дозволяють цьому обʼєкту завершити роботу належним чином перед тим, як він буде видалений з системи. Встановлюється лише тоді, коли також встановлено deletionTimestamp. Може бути скорочено тільки в меншу сторону. Тільки для читання.

  • deletionTimestamp (Time)

    Час видалення (DeletionTimestamp) — це дата та час у форматі RFC 3339, коли цей ресурс буде видалено. Це поле встановлюється сервером, коли користувач запитує належне видалення, і не може бути прямо встановлене клієнтом. Ресурс очікується бути видаленим (більше не видимий у списку ресурсів та недосяжний за іменем) після часу, вказаного у цьому полі, як тільки список завершувачів (finalizers) буде порожнім. Поки список завершувачів містить елементи, видалення заблоковане. Як тільки встановлюється час видалення, це значення не можна скасувати або встановити далі в майбутнє, хоча його можна скоротити або ресурс може бути видалений раніше цього часу. Наприклад, користувач може запросити видалення Podʼа через 30 секунд. Kubelet відреагує, надіславши сигнал належного завершення роботи контейнерам у Podʼі. Після цих 30 секунд Kubelet надішле сигнал примусового завершення (SIGKILL) контейнеру й після очищення видалить Pod з API. У випадку мережевих розділень цей обʼєкт може існувати після цієї позначки часу, доки адміністратор або автоматизований процес не визначить, що ресурс повністю завершив роботу. Якщо не встановлено, належне видалення обʼєкта не було запитано.

    Заповнюється системою, коли запитано належне видалення. Тільки для читання. Додаткова інформація: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

    Time — це обгортка навколо time.Time, яка підтримує коректне перетворення у YAML та JSON. Для багатьох з функцій, які пропонує пакет time, надаються обгортки.

  • generation (int64)

    Послідовний номер, що представляє конкретну генерацію бажаного стану. Заповнюється системою. Тільки для читання.

  • resourceVersion (string)

    Непрозоре (opaque) значення, яке представляє внутрішню версію цього обʼєкта, яке може бути використано клієнтами для визначення змін в обʼєктах. Це може використовуватися для оптимістичного одночасного виконання, виявлення змін та операції спостереження над ресурсом або набором ресурсів. Клієнти повинні розглядати ці значення як непрозорі та передавати їх незмінними назад на сервер. Вони можуть бути дійсними тільки для певного ресурсу або набору ресурсів.

    Заповнюється системою. Тільки для читання. Значення повинно бути розглянуте клієнтами як непрозоре. Додаткова інформація: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#concurrency-control-and-consistency

  • selfLink (string)

    Застаріле: selfLink — це застаріле поле, призначене лише для читання, яке більше не заповнюється системою.

  • uid (string)

    UID є унікальним у часі та просторі значенням для цього об’єкта. Зазвичай він генерується сервером після успішного створення ресурсу, і його не можна змінювати під час операцій PUT.

    Заповнюється системою. Лише для читання. Додаткова інформація: https://kubernetes.io/docs/concepts/overview/working-with-objects/names#uids

6.5.9.8 - ObjectReference

ObjectReference містить достатньо інформації для того, щоб дозволити вам переглядати або змінювати зазначений обʼєкт.

import "k8s.io/api/core/v1"

ObjectReference містить достатньо інформації для того, щоб дозволити вам переглядати або змінювати зазначений обʼєкт.


6.5.9.9 - Patch

Patch надає конкретну назву та тип тілу запиту PATCH Kubernetes.

import "k8s.io/apimachinery/pkg/apis/meta/v1"

Patch надає конкретну назву та тип тілу запиту PATCH Kubernetes.


6.5.9.10 - Quantity

Quantity — це представлення числа з фіксованою комою.

import "k8s.io/apimachinery/pkg/api/resource"

Quantity — це представлення числа з фіксованою комою. Воно надає зручний спосіб перетворення в/з JSON та YAML, на додачу до інструментів String() та AsInt64().

Формат серіалізації виглядає наступним чином:

\<quantity>        ::= \<signedNumber>\<suffix>

  (Зауважте, що \<suffix> може бути порожнімy, з "" у \<decimalSI>.)

\<digit>           ::= 0 | 1 | ... | 9 
\<digits>          ::= \<digit> | \<digit>\<digits> 
\<number>          ::= \<digits> | \<digits>.\<digits> | \<digits>. | .\<digits> 
\<sign>            ::= "+" | "-" 
\<signedNumber>    ::= \<number> | \<sign>\<number> 
\<suffix>          ::= \<binarySI> | \<decimalExponent> | \<decimalSI> 
\<binarySI>        ::= Ki | Mi | Gi | Ti | Pi | Ei

  (Міжнародна система мір; Див: http://physics.nist.gov/cuu/Units/binary.html)

\<decimalSI>       ::= m | "" | k | M | G | T | P | E

  (Зауважте, що 1024 = 1Ki але 1000 = 1k; капіталізація не використовується.)

\<decimalExponent> ::= "e" \<signedNumber> | "E" \<signedNumber> 

Незалежно від того, яка з трьох форм експоненти використовується, жодна кількість не може представляти число більше, ніж 2^63-1, а також не може мати більше трьох десяткових знаків. Числа, більші або точніші, будуть обмежені або округлені вгору. (Наприклад: 0.1m буде округлено до 1m.) Це може бути розширено в майбутньому, якщо ми потребуватимемо більших або менших кількостей.

Коли Quantity отримується зі строки, поканик запамʼятає тип суфікса, який він мав, і використовуватиме той самий тип знову, коли буде серіалізований.

Перед серіалізацією, Quantity буде приведено у "канонічну форму". Це означає, що експонента/суфікс буде відрегульована вгору або вниз (з відповідним збільшенням або зменшенням мантиси) таким чином, що:

  • Точність не буде втрачена
  • Дробові цифри не будуть випущені
  • Експонента (або суфікс) буде максимально можливою.

Знак буде опущено, якщо число не є негативним.

Приклади:

  • 1.5 буде серіалізовано як "1500m"
  • 1.5Gi буде серіалізовано як "1536Mi"

Зверніть увагу, що кількість НІКОЛИ не буде внутрішньо представлена числом з плаваючою комою. Це і є головна мета цього підходу.

Неканонічні значення все ще будуть проходити оцінку, якщо вони правильно сформовані, але будуть повторно випущені у своїй канонічній формі. (Отже, завжди використовуйте канонічну форму.)

Цей формат призначений для ускладнення використання цих чисел без написання спеціального коду обробки в надії на те, що це змусить реалізаторів також використовувати реалізацію чисел з фіксованою точкою.


6.5.9.11 - ResourceFieldSelector

ResourceFieldSelector представляє ресурси контейнера (cpu, memory) та формат їх виводу.

import "k8s.io/api/core/v1"

ResourceFieldSelector представляє ресурси контейнера (cpu, memory) та їх формат виводу.


  • resource (string), обовʼязково

    Обовʼязково: ресурс, який потрібно вибрати.

  • containerName (string)

    Назва контейнера: обовʼязково для томів, необовʼязково для змінних середовища.

  • divisor (Quantity)

    Вказує формат виводу відображених ресурсів, стандартне значення — "1".

6.5.9.12 - Status

Status — це значення, що повертається для викликів, які не повертають інших обʼєктів.

import "k8s.io/apimachinery/pkg/apis/meta/v1"

Status — це значення, що повертається для викликів, які не повертають інших обʼєктів.


  • apiVersion (string)

    APIVersion визначає версійну схему цього представлення обʼєкта. Сервери повинні конвертувати визнані схеми до останнього внутрішнього значення, і можуть відхиляти невизнані значення. Додаткова інформація: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources

  • code (int32)

    Рекомендований HTTP-код відповіді для цього статусу, 0, якщо не встановлено.

  • details (StatusDetails)

    Atommic: буде замінено під час злиття

    Розширені дані, повʼязані з причиною. Кожна причина може визначити свої власні розширені деталі. Це поле є необовʼязковим, і дані, що повертаються, не гарантовано відповідають будь-якій схемі, крім тієї, що визначена типом причини.

    StatusDetails — це набір додаткових властивостей, які МОЖУТЬ бути встановлені сервером для надання додаткової інформації про відповідь. Поле Reason обʼєкта Status визначає, які атрибути будуть встановлені. Клієнти повинні ігнорувати поля, які не відповідають визначеному типу кожного атрибута, і повинні припускати, що будь-який атрибут може бути порожнім, недійсним або невизначеним.

    • details.causes ([]StatusCause)

      Atommic: буде замінено під час злиття

      Масив Causes містить додаткові деталі, повʼязані з невдачею StatusReason. Не всі StatusReasons можуть надавати детальні причини.

      StatusCause надає додаткову інформацію про невдачу api.Status, включаючи випадки, коли зустрічаються декілька помилок.

      • details.causes.field (string)

        Поле ресурсу, яке спричинило цю помилку, назване за його серіалізацією в JSON. Може містити крапку і постфіксну нотацію для вкладених атрибутів. Масиви індексуються починаючи з нуля. Поля можуть зʼявлятися більше одного разу в масиві причин через наявність кількох помилок в полях. Необовʼязкове.

        Приклади: "name" — поле "name" поточного ресурсу "items[0].name" — поле "name" першого елемента масиву у "items"

        • details.causes.message (string)

          Опис причини помилки, зрозумілий для людини. Це поле може бути представлене читачеві як є.

        • details.causes.reason (string)

          Машинозчитуваний опис причини помилки. Якщо це значення порожнє, інформація відсутня.

      • details.group (string)

        Атрибут групи ресурсу, повʼязаний зі статусом StatusReason.

      • details.kind (string)

        Атрибут kind ресурсу, повʼязаний зі статусом StatusReason. У деяких операціях він може відрізнятися від запитаного типу ресурсу. Додаткова інформація: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds

      • details.name (string)

        Атрибут name ресурсу, повʼязаний зі статусом StatusReason (коли є одне імʼя, яке можна описати).

      • details.retryAfterSeconds (int32)

        Якщо вказано, час у секундах до повторного виконання операції. Деякі помилки можуть вказувати, що клієнт повинен виконати альтернативну дію — для цих помилок це поле може показати, як довго чекати перед виконанням альтернативної дії.

      • details.uid (string)

        UID ресурсу. (коли є один ресурс, який можна описати). Додаткова інформація: https://kubernetes.io/docs/concepts/overview/working-with-objects/names#uids

  • kind (string)

    Kind — це рядкове значення, що представляє обʼєкт REST, який цей обʼєкт представляє. Сервери можуть виводити це з точки доступу, на який клієнт надсилає запити. Не може бути оновлено. У форматі CamelCase. Додаткова інформація: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds

  • message (string)

    Зрозумілий для людини опис статусу цієї операції.

  • metadata (ListMeta)

    Стандартні метадані списку. Додаткова інформація: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds

  • reason (string)

    Машинозчитуваний опис того, чому ця операція має статус "Failure". Якщо це значення порожнє, немає доступної інформації. Причина уточнює HTTP-код стану, але не перевизначає його.

  • status (string)

    Статус операції. Один із: "Success" або "Failure". Додаткова інформація: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status

6.5.9.13 - TypedLocalObjectReference

TypedLocalObjectReference містить достатньо інформації, щоб дозволити вам знаходити типізований згаданий обʼєкт всередині того ж простору імен.

import "k8s.io/api/core/v1"

TypedLocalObjectReference містить достатньо інформації, щоб дозволити вам знаходити типізований згаданий обʼєкт всередині того ж простору імен.


  • kind (string), обовʼязково

    Kind — це тип ресурсу, на який посилаються.

  • name (string), обовʼязково

    Name — це назва ресурсу, на який посилаються.

  • apiGroup (string)

    APIGroup — це група для ресурсу, на який посилаються. Якщо APIGroup не вказано, вказаний Kind повинен бути в основній групі API. Для будь-яких інших сторонніх типів APIGroup є обовʼязковим.

6.5.10 - Загальні параметри

allowWatchBookmarks

allowWatchBookmarks запитує події спостереження з типом "BOOKMARK". Сервери, які не реалізують закладки, можуть ігнорувати цей прапорець, і закладки надсилаються на розсуд сервера. Клієнти не повинні припускати, що закладки повертаються через певні інтервали, і не можуть припускати, що сервер надішле будь-яку подію BOOKMARK під час сеансу. Якщо це не спостереження, це поле ігнорується.


continue

Опція continue повинна бути встановлена при отриманні додаткових результатів з сервера. Оскільки це значення визначається сервером, клієнти можуть використовувати значення continue лише з попереднього результату запиту з ідентичними параметрами запиту (за винятком значення continue), і сервер може відхилити значення continue, яке він не розпізнає. Якщо вказане значення continue більше не є дійсним через закінчення терміну дії (зазвичай від п’яти до п’ятнадцяти хвилин) або зміну конфігурації на сервері, сервер відповість помилкою 410 ResourceExpired разом з токеном продовження. Якщо клієнту потрібен узгоджений список, він повинен перезапустити свій список без поля continue. В іншому випадку клієнт може надіслати інший запит списку з токеном, отриманим разом із помилкою 410, сервер відповість списком, починаючи з наступного ключа, але з останнім знімком, який не узгоджується з попередніми результатами списку — об’єкти, які створені, змінені або видалені після першого запиту списку будуть включені у відповідь, якщо їх ключі знаходяться після «наступного ключа».

Це поле не підтримується, коли watch має значення true. Клієнти можуть почати спостереження з останнього значення resourceVersion, повернутого сервером, і не пропустити жодних змін.


dryRun

Якщо присутній, вказує, що зміни не повинні бути збережені. Неправильний або нерозпізнана директива dryRun призведе до помилки та припинення обробки запиту. Дійсні значення:

  • All: будуть оброблені всі етапи dry run

fieldManager

fieldManager — це імʼя, повʼязане з актором або субʼєктом, який вносить ці зміни. Значення має бути менше або дорівнювати 128 символам і містити лише друковані символи, як визначено https://golang.org/pkg/unicode/#IsPrint.


fieldSelector

Селектор для обмеження списку об’єктів, що повертаються, за їх полями. Стандартне значення — все.


fieldValidation

fieldValidation інструктує сервер, як обробляти обʼєкти в запиті (POST/PUT/PATCH), які містять невідомі або дубльовані поля. Дійсні значення:

  • Ignore: буде ігнорувати будь-які невідомі поля, які тихо видаляються з обʼєкта, і буде ігнорувати всі, крім останнього дубльованого поля, з яким стикається декодер. Це поведінка за замовчуванням до v1.23.
  • Warn: надішле попередження через стандартний заголовок відповіді про попередження для кожного невідомого поля, яке видаляється з обʼєкта, і для кожного дубльованого поля, з яким стикається. Запит все одно буде успішним, якщо не буде інших помилок, і зберігатиметься лише останнє з будь-яких дубльованих полів. Це стандартне значення у v1.23+
  • Strict: призведе до помилки BadRequest, якщо будь-які невідомі поля будуть видалені з обʼєкта, або якщо є будь-які дубльовані поля. Помилка, повернена сервером, міститиме всі невідомі та дубльовані поля, з якими стикаються.

force

Force "змушує" застосовувати запити Apply. Це означає, що користувач повторно отримуватиме конфліктні поля, що належать іншим користувачам. Прапорець force має бути скинутий для запитів на патч, які не є apply.


gracePeriodSeconds

Тривалість у секундах до того, як об’єкт повинен бути видалений. Значення має бути додатним цілим числом. Значення нуль вказує на негайне видалення. Якщо це значення є nil, буде використано стандартний період очікування для вказаного типу. Стандартне значення — значення для кожного обʼєкта, якщо не вказано інше. Нуль означає негайне видалення.


labelSelector

Селектор для обмеження списку обʼєктів, що повертаються, за їх мітками. Стандартне значення — все.


limit

limit — це максимальна кількість відповідей, які можна повернути для виклику списку. Якщо елементів більше, сервер встановить поле continue у метаданих списку у значення, яке можна використовувати з тим самим початковим запитом для отримання наступного набору результатів. Встановлення обмеження може повернути менше, ніж запитувана кількість елементів (до нуля елементів), якщо всі запитувані обʼєкти відфільтровані, і клієнти повинні використовувати лише наявність поля continue, щоб визначити, чи доступні додаткові результати. Сервери можуть не підтримувати аргумент limit і повернуть усі доступні результати. Якщо limit вказано, а поле continue порожнє, клієнти можуть припустити, що додаткових результатів немає. Це поле не підтримується, якщо watch має значення true.

Сервер гарантує, що обʼєкти, повернені при використанні continue, будуть ідентичні видачі єдиного виклику списку без обмеження — тобто жодні обʼєкти, створені, змінені або видалені після видачі першого запиту, не будуть включені в жодні подальші запити. Це іноді називають узгодженим знімком і гарантує, що клієнт, який використовує limit для отримання менших частин дуже великого результату, може бути впевнений, що він бачить всі можливі обʼєкти. Якщо обʼєкти оновлюються під час отримання сегментованого списку, повертається версія обʼєкта, яка була присутня на момент розрахунку першого результату списку.


namespace

назва обʼєкта та сфера авторизації, наприклад для команд і проєктів


pretty

Якщо 'true', вивід буде відформатовано з відступами. Стандартне значення 'false', якщо user-agent не вказує вебоглядач або інструмент командного рядка HTTP (curl та wget).


propagationPolicy

Чи буде виконуватися і як буде виконуватися збір сміття. Можна встановити це поле або OrphanDependents, але не обидва. Стандартна політика визначається наявним набором завершувачів у metadata.finalizers і стандартною політикою для конкретного ресурсу. Прийнятні значення: 'Orphan' — зробити залежні обʼєкти сиротами; 'Background' — дозволити збирачу сміття видаляти залежні обʼєкти у фоновому режимі; 'Foreground' — політика каскаду, яка видаляє всі залежні обʼєкти явно.


resourceVersion

resourceVersion встановлює обмеження на те, з яких версій ресурсів може обслуговуватися запит. Докладніше див. https://kubernetes.io/docs/reference/using-api/api-concepts/#resource-versions.

Стандартне значення не встановлено


resourceVersionMatch

resourceVersionMatch визначає, як resourceVersion застосовується до викликів списку. Наполегливо рекомендується встановлювати resourceVersionMatch для викликів списку, де встановлено resourceVersion. Докладніше див. https://kubernetes.io/docs/reference/using-api/api-concepts/#resource-versions.

Стандартне значення не встановлено


sendInitialEvents

sendInitialEvents=true можна встановити разом із watch=true. У цьому випадку потік спостереження розпочнеться зі штучних подій для створення поточного стану об’єктів у колекції. Після того, як усі такі події будуть надіслані, буде надіслано штучну подію "Bookmark". Закладка повідомить про ResourceVersion (RV), що відповідає набору об’єктів, і буде позначена анотацією "k8s.io/initial-events-end": "true". Після цього потік спостереження продовжуватиметься як зазвичай, надсилаючи події спостереження, що відповідають змінам (після RV) об’єктів, що спостерігаються.

Коли встановлено опцію sendInitialEvents, ми вимагаємо також встановити опцію resourceVersionMatch. Семантика запиту спостереження є такою:

  • resourceVersionMatch = NotOlderThan інтерпретується як "дані щонайменше такі ж нові, як надані resourceVersion" і подія bookmark надсилається, коли стан синхронізується до resourceVersion принаймні такий свіжий, як той, який надається ListOptions. Якщо resourceVersion не встановлено, це інтерпретується як "послідовне читання", і подія bookmark надсилається, коли стан синхронізується щонайменше до моменту початку обробки запиту.
  • resourceVersionMatch встановлено на будь-яке інше значення або не встановлено — Повертається помилка Invalid.

Стандартне значення — true, якщо resourceVersion="" або resourceVersion="0" (з міркувань зворотної сумісності) і false в інших випадках.


timeoutSeconds

Тайм-аут для викликів list/watch. Це обмежує тривалість виклику, незалежно від будь-якої активності чи неактивності.


watch

Спостереження за змінами описаних ресурсів і повернення їх у вигляді потоку сповіщень про додавання, оновлення та видалення. Вкажіть resourceVersion.


6.6 - Інструментування

6.6.1 - Метрики SLI компонентів Kubernetes

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.29 [stable]

Типово Kubernetes 1.31 публікує метрики Індикаторів Рівня Обслуговування (SLI) для кожного компонентного бінарного файлу Kubernetes. Ця точка доступу метрики відкривається на порту HTTPS кожного компонента за шляхом /metrics/slis. Функціональна можливість ComponentSLIs типово увімкнена для кожного компонента Kubernetes починаючи з версії v1.27.

Метрики SLI

З увімкненими метриками SLI кожен компонент Kubernetes відкриває дві метрики, позначені для кожної перевірки стану:

  • вимірювач (gauge, який представляє поточний стан перевірки стану)
  • лічильник (counter, який записує накопичувальні підрахунки, спостережені для кожного стану перевірки стану)

Ви можете використовувати інформацію метрики для розрахунку статистики доступності кожного компонента. Наприклад, сервер API перевіряє стан etcd. Ви можете визначити та повідомити, наскільки доступним чи недоступним був etcd — як повідомляє його клієнт, сервер API.

Дані вимірювача Prometheus виглядають так:

# HELP kubernetes_healthcheck [ALPHA] Ця метрика записує результат однієї перевірки стану.
# TYPE kubernetes_healthcheck gauge
kubernetes_healthcheck{name="autoregister-completion",type="healthz"} 1
kubernetes_healthcheck{name="autoregister-completion",type="readyz"} 1
kubernetes_healthcheck{name="etcd",type="healthz"} 1
kubernetes_healthcheck{name="etcd",type="readyz"} 1
kubernetes_healthcheck{name="etcd-readiness",type="readyz"} 1
kubernetes_healthcheck{name="informer-sync",type="readyz"} 1
kubernetes_healthcheck{name="log",type="healthz"} 1
kubernetes_healthcheck{name="log",type="readyz"} 1
kubernetes_healthcheck{name="ping",type="healthz"} 1
kubernetes_healthcheck{name="ping",type="readyz"} 1

Дані лічильника виглядають так:

# HELP kubernetes_healthchecks_total [ALPHA] Ця метрика записує результати всіх перевірок стану.
# TYPE kubernetes_healthchecks_total counter
kubernetes_healthchecks_total{name="autoregister-completion",status="error",type="readyz"} 1
kubernetes_healthchecks_total{name="autoregister-completion",status="success",type="healthz"} 15
kubernetes_healthchecks_total{name="autoregister-completion",status="success",type="readyz"} 14
kubernetes_healthchecks_total{name="etcd",status="success",type="healthz"} 15
kubernetes_healthchecks_total{name="etcd",status="success",type="readyz"} 15
kubernetes_healthchecks_total{name="etcd-readiness",status="success",type="readyz"} 15
kubernetes_healthchecks_total{name="informer-sync",status="error",type="readyz"} 1
kubernetes_healthchecks_total{name="informer-sync",status="success",type="readyz"} 14
kubernetes_healthchecks_total{name="log",status="success",type="healthz"} 15
kubernetes_healthchecks_total{name="log",status="success",type="readyz"} 15
kubernetes_healthchecks_total{name="ping",status="success",type="healthz"} 15
kubernetes_healthchecks_total{name="ping",status="success",type="readyz"} 15

Використання цих даних

Точка доступу метрик компонентів SLI призначена для збору даних з високою частотою. Збір даних з високою частотою означає, що ви отримуєте більш точний сигнал вимірювача, який можна потім використовувати для розрахунку SLO. Точка доступу /metrics/slis надає необроблені дані, необхідні для розрахунку SLO доступності для відповідного компонента Kubernetes.

6.6.2 - Дані метрик вузла

Механізми доступу до метрик на рівні вузла, томів, Pod та контейнерів, як їх бачить kubelet.

kubelet збирає статистичні дані метрик на рівні вузла, томів, pod та контейнерів, і надає цю інформацію через Summary API.

Ви можете надіслати запит з проксі до Summary API через сервер API Kubernetes.

Ось приклад запиту до Summary API для вузла з іменем minikube:

kubectl get --raw "/api/v1/nodes/minikube/proxy/stats/summary"

Ось той самий виклик API за допомогою curl:

# Спочатку потрібно запустити "kubectl proxy"
# Змініть 8080 на порт, який призначає "kubectl proxy"
curl http://localhost:8080/api/v1/nodes/minikube/proxy/stats/summary

Джерело метрик Summary API

Стандартно, Kubernetes отримує дані метрик вузлів, використовуючи вбудований cAdvisor, який працює в kubelet. Якщо ви увімкнете функціональну можливість PodAndContainerStatsFromCRI у вашому кластері та використовуєте середовище виконання контейнерів, яке підтримує доступ до статистики через Інтерфейс Виконання Контейнерів (CRI), тоді kubelet отримує дані метрик на рівні Pod та контейнерів за допомогою CRI, а не через cAdvisor.

Що далі

На сторінках завдань для Виправлення неполадок у кластерах обговорюється, як використовувати конвеєр метрик, який залежить від цих даних.

6.6.3 - Метрики Pod та Контейнерів CRI

Збір метрик Pod та контейнерів через CRI.
СТАН ФУНКЦІОНАЛУ: Kubernetes v1.23 [alpha]

kubelet збирає метрики Pod та контейнерів через cAdvisor. Як альфа-функція, Kubernetes дозволяє налаштувати збір метрик Pod та контейнерів через Інтерфейс Виконання Контейнерів (CRI). Ви повинні увімкнути функціональну можливість PodAndContainerStatsFromCRI та використовувати сумісну реалізацію CRI (containerd >= 1.6.0, CRI-O >= 1.23.0), щоб використовувати механізм збору через CRI.

Метрики Pod та Контейнерів CRI

З увімкненим PodAndContainerStatsFromCRI, kubelet опитує підлегле середовище виконання контейнерів для отримання статистики Pod та контейнерів замість того, щоб безпосередньо перевіряти хост-систему за допомогою cAdvisor. Переваги використання середовища виконання контейнерів для цієї інформації, на відміну від прямого збору за допомогою cAdvisor, включають:

  • Потенційне покращення продуктивності, якщо середовище виконання контейнерів вже збирає цю інформацію під час нормальної роботи. У цьому випадку дані можуть бути повторно використані замість того, щоб бути знову агрегованими kubelet.

  • Це ще більше розʼєднує kubelet і середовище виконання контейнерів, дозволяючи збирати метрики для середовищ виконання контейнерів, які не запускають процеси безпосередньо на хості з kubelet, де вони спостережувані за допомогою cAdvisor (наприклад: середовища виконання контейнерів, що використовують віртуалізацію).

6.6.4 - Довідник Метрик Kubernetes

Деталі щодо метрик, які експортують компоненти Kubernetes.

Метрики (v1.30)

Ця сторінка містить деталі метрик, які експортують різні компоненти Kubernetes. Ви можете запитувати точки доступу метрик для цих компонентів за допомогою HTTP-запиту та отримувати поточні дані метрик у форматі Prometheus.

Список стабільних метрик Kubernetes

Стабільні метрики дотримуються суворих API контрактів, і жодні мітки не можуть бути додані або видалені зі стабільних метрик протягом їхнього життєвого циклу.

apiserver_admission_controller_admission_duration_seconds
Гістограма затримки контролера допуску в секундах, визначена за назвою та розподілена для кожної операції та ресурсу API і типу (перевірка або допуск).
  • STABLE
  • Histogram
  • nameoperationrejectedtype
apiserver_admission_step_admission_duration_seconds
Гістограма затримки підетапу допуску в секундах для кожної операції, ресурсу API та типу етапу (валідація або допуск).
  • STABLE
  • Histogram
  • operationrejectedtype
apiserver_admission_webhook_admission_duration_seconds
Гістограма затримки вебхука в секундах, ідентифікована за назвою та розбита за кожною операцією, ресурсом API та типом (валідація або допуск).
  • STABLE
  • Histogram
  • nameoperationrejectedtype
apiserver_current_inflight_requests
Максимальна кількість поточних використаних запитів цього apiserver на тип запиту за останню секунду.
  • STABLE
  • Gauge
  • request_kind
apiserver_longrunning_requests
Вимірювач усіх активних тривалих запитів apiserver, розділених за дієсловом, групою, версією, ресурсом, областю та компонентом. Не всі запити відстежуються таким чином.
  • STABLE
  • Gauge
  • componentgroupresourcescopesubresourceverbversion
apiserver_request_duration_seconds
Розподіл затримки відповіді в секундах для кожного дієслова, значення dry run, групи, версії, ресурсу, субресурсу, області застосування та компонента.
  • Histogram
  • componentdry_rungroupresourcescopesubresourceverbversion
apiserver_request_total
Лічильник запитів apiserver з розбивкою по кожному дієслову, dry run, групі, версії, ресурсу, області застосування, компоненту і коду HTTP-відповіді.
  • Counter
  • codecomponentdry_rungroupresourcescopesubresourceverbversion
apiserver_requested_deprecated_apis
Вимірювач запитуваних застарілих API, розподілених за групами API, версією, ресурсом, субресурсом і видаленим_випуском.
  • STABLE
  • Gauge
  • groupremoved_releaseresourcesubresourceversion
apiserver_response_sizes
Розподіл розміру відповіді в байтах для кожної групи, версії, дієслова, ресурсу, субресурсу, області дії та компонента.
  • STABLE
  • Histogram
  • componentgroupresourcescopesubresourceverbversion
apiserver_storage_objects
Кількість збережених обʼєктів на момент останньої перевірки з розподілом за типом. У разі помилки вибірки значення буде -1.
  • STABLE
  • Gauge
  • resource
apiserver_storage_size_bytes
Розмір сховища для файлу бази даних, фізично виділеного в байтах.
  • STABLE
  • Custom
  • storage_cluster_id
container_cpu_usage_seconds_total
Сукупний час процесора, який споживає контейнер, у секундах ядра
  • STABLE
  • Custom
  • containerpodnamespace
container_memory_working_set_bytes
Поточний робочий набір контейнера в байтах
  • STABLE
  • Custom
  • containerpodnamespace
container_start_time_seconds
Час запуску контейнера в секундах епохи Unix
  • STABLE
  • Custom
  • containerpodnamespace
cronjob_controller_job_creation_skew_duration_seconds
Час між запланованим запуском cronjob і створенням відповідного завдання
  • STABLE
  • Histogram
job_controller_job_pods_finished_total
Кількість завершених Podʼів, які повністю відстежуються
  • STABLE
  • Counter
  • completion_moderesult
job_controller_job_sync_duration_seconds
Час, необхідний для синхронізації завдання
  • STABLE
  • Histogram
  • actioncompletion_moderesult
job_controller_job_syncs_total
Кількість синхронізацій завдання
  • STABLE
  • Counter
  • actioncompletion_moderesult
job_controller_jobs_finished_total
Кількість завершених завдань
  • STABLE
  • Counter
  • completion_modereasonresult
kube_pod_resource_limit
Ліміт ресурсів для робочих навантажень в кластері, з розбивкою за Podʼами. Це показує використання ресурсів, яке планувальник і kubelet очікують на кожен Pod для ресурсів, а також одиницю виміру для ресурсу, якщо така є.
  • STABLE
  • Custom
  • namespacepodnodeschedulerpriorityresourceunit
kube_pod_resource_request
Ресурси, запитувані робочими навантаженнями в кластері, з розбивкою за Podʼами. Це показує використання ресурсів, яке планувальник і kubelet очікують на кожен Pod для ресурсів, а також одиницю виміру для ресурсу, якщо така є.
  • STABLE
  • Custom
  • namespacepodnodeschedulerpriorityresourceunit
kubernetes_healthcheck
Ця метрика фіксує результат однієї перевірки справності.
  • STABLE
  • Gauge
  • nametype
kubernetes_healthchecks_total
Ця метрика фіксує результати всіх перевірок справності.
  • STABLE
  • Counter
  • namestatustype
node_collector_evictions_total
Кількість виселень Node, що відбулися з моменту запуску поточного екземпляра NodeController.
  • STABLE
  • Counter
  • zone
node_cpu_usage_seconds_total
Сукупний час процесора, споживаний вузлом у секундах ядра
  • STABLE
  • Custom
node_memory_working_set_bytes
Поточний робочий набір вузла в байтах
  • STABLE
  • Custom
pod_cpu_usage_seconds_total
Сукупний час процесора, споживаний Podʼом у секундах ядра
  • STABLE
  • Custom
  • podnamespace
pod_memory_working_set_bytes
Поточний робочий набір Podʼа в байтах
  • STABLE
  • Custom
  • podnamespace
resource_scrape_error
1, якщо сталася помилка під час отримання метрик контейнера, 0 в іншому випадку
  • STABLE
  • Custom
scheduler_framework_extension_point_duration_seconds
Затримка для запуску всіх втулків певної точки розширення.
  • STABLE
  • Histogram
  • extension_pointprofilestatus
scheduler_pending_pods
Кількість відкладених Podʼів за типом черги. 'active' означає кількість Podʼів в activeQ; 'backoff' означає кількість Pods у backoffQ; 'unschedulable' означає кількість Podʼів в unschedulablePods, які планувальник намагався запланувати, але не зміг; 'gated' означає кількість незапланованих Podʼів, які планувальник ніколи не намагався запланувати, тому що вони є gated.
  • STABLE
  • Gauge
  • queue
scheduler_pod_scheduling_attempts
Кількість спроб успішно запланувати Pod.
  • STABLE
  • Histogram
scheduler_pod_scheduling_duration_seconds
E2e затримка для Podʼа, що планується, яка може включати кілька спроб планування.
  • STABLE
  • Histogram
  • attempts
  • 1.29.0
scheduler_preemption_attempts_total
Загальна кількість спроб випередження в кластері до цього часу
  • STABLE
  • Counter
scheduler_preemption_victims
Кількість обраних жертв випередження
  • STABLE
  • Histogram
scheduler_queue_incoming_pods_total
Кількість Podʼів, доданих до черг планування за подіями та типами черг.
  • STABLE
  • Counter
  • eventqueue
scheduler_schedule_attempts_total
Кількість спроб запланувати Podʼи, за результатом. "unscheduled" означає, що Pod не вдалося запланувати, тоді як "error" означає внутрішню проблему планувальника.
  • STABLE
  • Counter
  • profileresult
scheduler_scheduling_attempt_duration_seconds
Затримка спроби планування в секундах (алгоритм планування + привʼязка)
  • STABLE
  • Histogram
  • profileresult

Список бета-метрик Kubernetes

Бета-метрики дотримуються менш суворих API контрактів порівняно зі стабільними метриками. Жодні мітки не можуть бути видалені з бета-метрик протягом їхнього життєвого циклу, проте мітки можуть бути додані, поки метрика перебуває на етапі бета-тестування. Це забезпечує впевненість у тому, що бета-метрики підтримуватимуть існуючі панелі моніторингу та оповіщення, водночас дозволяючи вносити зміни в майбутньому.

apiserver_flowcontrol_current_executing_requests
Кількість запитів на початковій (для WATCH) або будь-якій (для не-WATCH) стадії виконання в підсистемі API Priority and Fairness
  • BETA
  • Gauge
  • flow_schemapriority_level
apiserver_flowcontrol_current_executing_seats
Паралельність (кількість місць), яку займають поточні запити, що виконуються (початкова стадія для WATCH, будь-яка інша стадія) у підсистемі API Priority and Fairness
  • BETA
  • Gauge
  • flow_schemapriority_level
apiserver_flowcontrol_current_inqueue_requests
Кількість запитів, що перебувають у чергах підсистеми API Priority and Fairness
  • BETA
  • Gauge
  • flow_schemapriority_level
apiserver_flowcontrol_dispatched_requests_total
Кількість виконаних запитів в підсистемі API Priority and Fairness
  • BETA
  • Counter
  • flow_schemapriority_level
apiserver_flowcontrol_nominal_limit_seats
Номінальна кількість місць виконання, налаштована для кожного рівня пріоритету
  • BETA
  • Gauge
  • priority_level
apiserver_flowcontrol_rejected_requests_total
Кількість запитів, відхилених підсистемою API Priority and Fairness
  • BETA
  • Counter
  • flow_schemapriority_levelreason
apiserver_flowcontrol_request_wait_duration_seconds
Час очікування запиту в черзі
  • BETA
  • Histogram
  • executeflow_schemapriority_level
disabled_metrics_total
Кількість вимкнених метрик.
  • BETA
  • Counter
hidden_metrics_total
Кількість прихованих метрик.
  • BETA
  • Counter
kubernetes_feature_enabled
Ця метрика фіксує дані про стадію та ввімкнення функції k8s.
  • BETA
  • Gauge
  • namestage
registered_metrics_total
Кількість зареєстрованих метрик з розбивкою за рівнем стабільності та версією застарівння.
  • BETA
  • Counter
  • deprecated_versionstability_level
scheduler_pod_scheduling_sli_duration_seconds
E2e затримка для пакета, що планується, з моменту потрапляння пакета в чергу на планування і може включати декілька спроб планування.
  • BETA
  • Histogram
  • attempts

Список альфа-метрик Kubernetes

Альфа-метрики не мають жодних гарантій API. Ці метрики слід використовувати на свій страх і ризик, наступні версії Kubernetes можуть взагалі вилучити ці метрики або мутувати API таким чином, щоб зламати наявні інформаційні панелі та сповіщення.

aggregator_discovery_aggregation_count_total
Лічильник кількості разів, коли виявлення (discovery) було агреговано
  • ALPHA
  • Counter
aggregator_openapi_v2_regeneration_count
Лічильник кількості регенерацій специфікації OpenAPI v2 розбито за назвою APIService та причиною.
  • ALPHA
  • Counter
  • apiservicereason
aggregator_openapi_v2_regeneration_duration
Показник тривалості регенерації специфікації OpenAPI v2 у секундах.
  • ALPHA
  • Gauge
  • reason
aggregator_unavailable_apiservice
Кількість APIService, які позначені як недоступні, з розбивкою за назвою APIService.
  • ALPHA
  • Custom
  • name
aggregator_unavailable_apiservice_total
Лічильник APIServices, які позначені як недоступні, з розбивкою за назвою APIService та причиною.
  • ALPHA
  • Counter
  • namereason
apiextensions_apiserver_validation_ratcheting_seconds
Час для порівняння старого з новим для цілей CRDValidationRatcheting під час UPDATE в секундах.
  • ALPHA
  • Histogram
apiextensions_openapi_v2_regeneration_count
Лічильник кількості регенерацій специфікації OpenAPI v2, розбитий за назвою та причиною виклику CRD.
  • ALPHA
  • Counter
  • crdreason
apiextensions_openapi_v3_regeneration_count
Лічильник кількості регенерацій специфікації OpenAPI v3 з розбивкою за групами, версіями, джерелом CRD та причиною.
  • ALPHA
  • Counter
  • crdgroupreasonversion
apiserver_admission_match_condition_evaluation_errors_total
Кількість помилок оцінки умов допуску, ідентифікованих за назвою ресурсу, що містить умову допуску, з розбивкою для кожного типу, що містить matchConditions ("вебхук" або "політика"), операцію та тип допуску (валідація або допуск).
  • ALPHA
  • Counter
  • kindnameoperationtype
apiserver_admission_match_condition_evaluation_seconds
Час оцінки відповідності умов допуску в секундах, ідентифікований за назвою і розбитий для кожного типу, що містить matchConditions ("вебхук" або "політика"), операцію і тип (валідація або допуск).
  • ALPHA
  • Histogram
  • kindnameoperationtype
apiserver_admission_match_condition_exclusions_total
Кількість виключень для оцінки відповідності умов допуску, ідентифікована за назвою ресурсу, що містить умову відповідності, і розбита для кожного типу, що містить matchConditions ("вебхук" або "політика"), операцію і тип допуску (валідація або допуск).
  • ALPHA
  • Counter
  • kindnameoperationtype
apiserver_admission_step_admission_duration_seconds_summary
Зведення затримок на підетапах допуску в секундах для кожної операції, ресурсу API та типу етапу (валідація або допуск) для кожної операції та ресурсу API.
  • ALPHA
  • Summary
  • operationrejectedtype
apiserver_admission_webhook_fail_open_count
Кількість відкритих помилок вебхука допуску, ідентифікованих за іменами та розбитих за кожним типом допуску (валідація або мутація).
  • ALPHA
  • Counter
  • nametype
apiserver_admission_webhook_rejection_count
Кількість відмов від вебхуків допуску, ідентифікованих за іменами та розбитих за кожним типом допуску (валідація або допуск) та операцією. Додаткові мітки вказують на тип помилки (error_webhook_error або apiserver_internal_error, якщо сталася помилка; no_error в іншому випадку) і необовʼязково ненульовий код відмови, якщо вебхук відхиляє запит з кодом HTTP-статусу (обробляється apiserver, коли код більше або дорівнює 400). Коди, більші за 600, усікаються до 600, щоб обмежити кардинальність метрики.
  • ALPHA
  • Counter
  • error_typenameoperationrejection_codetype
apiserver_admission_webhook_request_total
Загальна кількість запитів на вебхук, ідентифікована за назвою та розбита за типом допуску (валідація чи модифікація) та операцією. Додаткові мітки вказують, чи був запит відхилений, і код статусу HTTP. Коди, що перевищують 600, усікаються до 600, щоб обмежити кардинальність метрики.
  • ALPHA
  • Counter
  • codenameoperationrejectedtype
apiserver_audit_error_total
Лічильник подій аудиту, які не були перевірені належним чином. Мітка plugin визначає втулок, на який вплинула помилка.
  • ALPHA
  • Counter
  • plugin
apiserver_audit_event_total
Лічильник подій аудиту, що генеруються та надсилаються до бекенду аудиту.
  • ALPHA
  • Counter
apiserver_audit_level_total
Лічильник рівнів політики для подій аудиту (1 на запит).
  • ALPHA
  • Counter
  • level
apiserver_audit_requests_rejected_total
Лічильник запитів apiserver, відхилених через помилку в логах аудиту в бекенді.
  • ALPHA
  • Counter
apiserver_authentication_config_controller_automatic_reload_last_timestamp_seconds
Мітка часу останнього автоматичного перезавантаження конфігурації автентифікації з розподілом за статусом та ідентифікатором apiserver.
  • ALPHA
  • Gauge
  • apiserver_id_hashstatus
apiserver_authentication_config_controller_automatic_reloads_total
Загальна кількість автоматичних перезавантажень конфігурації автентифікації з розподілом за статусом та ідентифікацією apiserver.
  • ALPHA
  • Counter
  • apiserver_id_hashstatus
apiserver_authentication_jwt_authenticator_latency_seconds
Латентність операцій автентифікації jwt у секундах. Це час, витрачений на автентифікацію токена лише у випадку пропуску в кеші (тобто коли токен не знайдено в кеші).
  • ALPHA
  • Histogram
  • jwt_issuer_hashresult
apiserver_authorization_decisions_total
Загальна кількість кінцевих рішень, прийнятих авторизатором, з розбивкою за типом авторизатора, імʼям та рішенням.
  • ALPHA
  • Counter
  • decisionnametype
apiserver_authorization_match_condition_evaluation_errors_total
Загальна кількість помилок, коли вебхук авторизації стикається з помилкою умови збігу, з розбивкою за типом та іменем авторизації.
  • ALPHA
  • Counter
  • nametype
apiserver_authorization_match_condition_evaluation_seconds
Час оцінки умови збігу авторизації в секундах, з розбивкою за типом та іменем авторизатора.
  • ALPHA
  • Histogram
  • nametype
apiserver_authorization_match_condition_exclusions_total
Загальна кількість винятків, коли вебхук авторизації пропускається, оскільки умови збігу виключають його.
  • ALPHA
  • Counter
  • nametype
apiserver_authorization_webhook_duration_seconds
Затримка запиту в секундах.
  • ALPHA
  • Histogram
  • nameresult
apiserver_authorization_webhook_evaluations_fail_open_total
Результат NoOpinion через тайм-аут вебхуку або помилку.
  • ALPHA
  • Counter
  • nameresult
apiserver_authorization_webhook_evaluations_total
Перехід туди-назад до вебхуків авторизації.
  • ALPHA
  • Counter
  • nameresult
apiserver_cache_list_fetched_objects_total
Кількість об’єктів, зчитаних із кешу спостереження під час обслуговування запиту LIST
  • ALPHA
  • Counter
  • indexresource_prefix
apiserver_cache_list_returned_objects_total
Кількість об’єктів, повернутих за запитом LIST із кешу спостереження
  • ALPHA
  • Counter
  • resource_prefix
apiserver_cache_list_total
Кількість запитів LIST, наданих із кешу спостереження
  • ALPHA
  • Counter
  • indexresource_prefix
apiserver_cel_compilation_duration_seconds
Час компіляції CEL у секундах.
  • ALPHA
  • Histogram
apiserver_cel_evaluation_duration_seconds
Час оцінки CEL у секундах.
  • ALPHA
  • Histogram
apiserver_certificates_registry_csr_honored_duration_total
Загальна кількість виданих CSR із запитаною тривалістю, яка була виконана, розділена за підписувачами (лише імена підписувачів kubernetes.io визначено окремо)
  • ALPHA
  • Counter
  • signerName
apiserver_certificates_registry_csr_requested_duration_total
Загальна кількість виданих CSR із запитаною тривалістю, розділена за підписувачами (лише імена підписантів kubernetes.io визначено конкретно)
  • ALPHA
  • Counter
  • signerName
apiserver_client_certificate_expiration_seconds
Розподіл залишкового терміну служби сертифіката, який використовується для автентифікації запиту.
  • ALPHA
  • Histogram
apiserver_clusterip_repair_ip_errors_total
Кількість помилок, виявлених в clusterips циклом ремонту, за типами: leak, repair, full, outOfRange, duplicate, unknown, invalid
  • ALPHA
  • Counter
  • type
apiserver_clusterip_repair_reconcile_errors_total
Кількість збоїв узгодження в циклі узгодження ремонту clusterip
  • ALPHA
  • Counter
apiserver_conversion_webhook_duration_seconds
Затримка запиту конверсії вубхука
  • ALPHA
  • Histogram
  • failure_typeresult
apiserver_conversion_webhook_request_total
Лічильник конверсійних запитів вубхук з успішністю/неуспішністю та типом помилки
  • ALPHA
  • Counter
  • failure_typeresult
apiserver_crd_conversion_webhook_duration_seconds
Тривалість конверсії CRD вебхука в секундах
  • ALPHA
  • Histogram
  • crd_namefrom_versionsucceededto_version
apiserver_current_inqueue_requests
Максимальна кількість запитів у черзі в цьому apiserver для кожного типу запитів за останню секунду.
  • ALPHA
  • Gauge
  • request_kind
apiserver_delegated_authn_request_duration_seconds
Затримка запиту в секундах. Розбито за кодом статусу.
  • ALPHA
  • Histogram
  • code
apiserver_delegated_authn_request_total
Кількість HTTP-запитів, розділених за кодом статусу.
  • ALPHA
  • Counter
  • code
apiserver_delegated_authz_request_duration_seconds
Затримка запиту в секундах. Розбито за кодом статусу.
  • ALPHA
  • Histogram
  • code
apiserver_delegated_authz_request_total
Кількість HTTP-запитів, розділених за кодом статусу.
  • ALPHA
  • Counter
  • code
apiserver_egress_dialer_dial_duration_seconds
Гістограма затримки набору в секундах, позначена протоколом (http-connect або grpc), транспортом (tcp або uds)
  • ALPHA
  • Histogram
  • protocoltransport
apiserver_egress_dialer_dial_failure_count
Кількість невдалих спроб зʼєднання, позначених протоколом (http-connect або grpc), транспортом (tcp або uds) та стадією (зʼєднання або проксі). Етап вказує на те, на якому етапі сталася помилка зʼєднання
  • ALPHA
  • Counter
  • protocolstagetransport
apiserver_egress_dialer_dial_start_total
Стартує зʼєднання, позначене протоколом (http-connect або grpc) і транспортом (tcp або uds).
  • ALPHA
  • Counter
  • protocoltransport
apiserver_encryption_config_controller_automatic_reload_failures_total
Загальна кількість невдалих автоматичних перезавантажень конфігурації шифрування з розподілом за ідентичністю apiserver.
  • ALPHA
  • Counter
  • apiserver_id_hash
  • 1.30.0
apiserver_encryption_config_controller_automatic_reload_success_total
Загальна кількість успішних автоматичних перезавантажень конфігурації шифрування з розподілом за ідентичністю apiserver.
  • ALPHA
  • Counter
  • apiserver_id_hash
  • 1.30.0
apiserver_envelope_encryption_dek_cache_fill_percent
Відсоток слотів кешу, які наразі зайняті кешованими DEK.
  • ALPHA
  • Gauge
apiserver_envelope_encryption_dek_cache_inter_arrival_time_seconds
Час (у секундах) між надходженням запитів на трансформацію.
  • ALPHA
  • Histogram
  • transformation_type
apiserver_envelope_encryption_dek_source_cache_size
Кількість записів у вихідному кеші ключа шифрування даних (DEK). При перезапуску це значення є наближеним значенням кількості розшифрованих RPC-викликів, які сервер зробить до втулка KMS.
  • ALPHA
  • Gauge
  • provider_name
apiserver_envelope_encryption_invalid_key_id_from_status_total
Кількість разів, коли невірний keyID повертається викликом Status RPC з розбивкою по помилках.
  • ALPHA
  • Counter
  • errorprovider_name
apiserver_envelope_encryption_key_id_hash_last_timestamp_seconds
Останній раз в секундах, коли було використано keyID.
  • ALPHA
  • Gauge
  • apiserver_id_hashkey_id_hashprovider_nametransformation_type
apiserver_envelope_encryption_key_id_hash_status_last_timestamp_seconds
Останній час у секундах, коли ідентифікатор ключа було повернуто викликом Status RPC.
  • ALPHA
  • Gauge
  • apiserver_id_hashkey_id_hashprovider_name
apiserver_envelope_encryption_key_id_hash_total
Кількість разів використання keyID з розподілом за типом перетворення, провайдером та ідентичністю apiserver.
  • ALPHA
  • Counter
  • apiserver_id_hashkey_id_hashprovider_nametransformation_type
apiserver_envelope_encryption_kms_operations_latency_seconds
Загальна тривалість роботи KMS зі статусом коду помилки gRPC.
  • ALPHA
  • Histogram
  • grpc_status_codemethod_nameprovider_name
apiserver_flowcontrol_current_inqueue_seats
Кількість місць у чергах підсистеми API Priority and Fairness, що перебувають на розгляді в даний момент
  • ALPHA
  • Gauge
  • flow_schemapriority_level
apiserver_flowcontrol_current_limit_seats
Поточна похідна кількість місць виконання, доступних для кожного рівня пріоритету
  • ALPHA
  • Gauge
  • priority_level
apiserver_flowcontrol_current_r
R(час останньої зміни)
  • ALPHA
  • Gauge
  • priority_level
apiserver_flowcontrol_demand_seats
Спостереження, в кінці кожної наносекунди, за (кількістю місць, які може використати кожен рівень пріоритету) / (номінальна кількість місць для цього рівня)
  • ALPHA
  • TimingRatioHistogram
  • priority_level
apiserver_flowcontrol_demand_seats_average
Середньозважене за часом значення demand_seats за останній період коригування
  • ALPHA
  • Gauge
  • priority_level
apiserver_flowcontrol_demand_seats_high_watermark
Найвищий показник, за останній період коригування, для demand_seats
  • ALPHA
  • Gauge
  • priority_level
apiserver_flowcontrol_demand_seats_smoothed
Згладжені вимоги до місць
  • ALPHA
  • Gauge
  • priority_level
apiserver_flowcontrol_demand_seats_stdev
Середньозважене за часом стандартне відхилення, за останній період коригування, demand_seats
  • ALPHA
  • Gauge
  • priority_level
apiserver_flowcontrol_dispatch_r
R(час останньої диспетчеризації)
  • ALPHA
  • Gauge
  • priority_level
apiserver_flowcontrol_epoch_advance_total
Кількість разів, коли лічильник прогресу набору черг стрибнув назад
  • ALPHA
  • Counter
  • priority_levelsuccess
apiserver_flowcontrol_latest_s
S(останній відправлений запит)
  • ALPHA
  • Gauge
  • priority_level
apiserver_flowcontrol_lower_limit_seats
Налаштовано нижню межу кількості місць виконання, доступних для кожного рівня пріоритету
  • ALPHA
  • Gauge
  • priority_level
apiserver_flowcontrol_next_discounted_s_bounds
min і max, за чергою, для S (найстаріша заявка в черзі) — оціночне значення незавершеної роботи
  • ALPHA
  • Gauge
  • boundpriority_level
apiserver_flowcontrol_next_s_bounds
min і max, за чергами, для S (найстаріша заявка в черзі)
  • ALPHA
  • Gauge
  • boundpriority_level
apiserver_flowcontrol_priority_level_request_utilization
Спостереження наприкінці кожної наносекунди кількості запитів (у частках від відповідного ліміту), що очікують або перебувають на будь-якій стадії виконання (але тільки на початковій стадії для WATCH)
  • ALPHA
  • TimingRatioHistogram
  • phasepriority_level
apiserver_flowcontrol_priority_level_seat_utilization
Спостереження наприкінці кожної наносекунди за використанням місць на будь-якій стадії виконання (але тільки на початковій стадії для WATCH)
  • ALPHA
  • TimingRatioHistogram
  • priority_level
  • phase:executing
apiserver_flowcontrol_read_vs_write_current_requests
Спостереження наприкінці кожної наносекунди за кількістю запитів (у частках від відповідного ліміту), які очікують на виконання або перебувають на стадії виконання
  • ALPHA
  • TimingRatioHistogram
  • phaserequest_kind
apiserver_flowcontrol_request_concurrency_in_use
Паралельність (кількість місць), яку займають поточні запити, що виконуються (початкова стадія для WATCH, будь-яка інша стадія) у підсистемі API Priority and Fairness
  • ALPHA
  • Gauge
  • flow_schemapriority_level
  • 1.31.0
apiserver_flowcontrol_request_concurrency_limit
Номінальна кількість місць виконання, налаштована для кожного рівня пріоритету
  • ALPHA
  • Gauge
  • priority_level
  • 1.30.0
apiserver_flowcontrol_request_dispatch_no_accommodation_total
Кількість випадків, коли спроба диспетчеризації призвела до відмови у розміщенні через відсутність вільних місць
  • ALPHA
  • Counter
  • flow_schemapriority_level
apiserver_flowcontrol_request_execution_seconds
Тривалість початкового (для WATCH) або будь-якого (для не-WATCH) етапу виконання запиту в підсистемі API Priority and Fairness
  • ALPHA
  • Histogram
  • flow_schemapriority_leveltype
apiserver_flowcontrol_request_queue_length_after_enqueue
Довжина черги в підсистемі API Priority and Fairness, яку бачить кожен запит після того, як його поставлено в чергу
  • ALPHA
  • Histogram
  • flow_schemapriority_level
apiserver_flowcontrol_seat_fair_frac
Справедлива частка паралелізму сервера для виділення кожному рівню пріоритету, який може його використовувати
  • ALPHA
  • Gauge
apiserver_flowcontrol_target_seats
Цілі розподілу місць
  • ALPHA
  • Gauge
  • priority_level
apiserver_flowcontrol_upper_limit_seats
Налаштована верхня межа кількості місць виконання, доступних для кожного рівня пріоритету
  • ALPHA
  • Gauge
  • priority_level
apiserver_flowcontrol_watch_count_samples
Кількість спостерігачів для запитів, що змінюються, в API Priority and Fairness
  • ALPHA
  • Histogram
  • flow_schemapriority_level
apiserver_flowcontrol_work_estimated_seats
Кількість розрахункових місць (максимум початкових і кінцевих місць), повʼязаних із запитами в API Priority and Fairness
  • ALPHA
  • Histogram
  • flow_schemapriority_level
apiserver_init_events_total
Лічильник подій init, оброблених у watch кеші, з розбивкою за типами ресурсів.
  • ALPHA
  • Counter
  • resource
apiserver_kube_aggregator_x509_insecure_sha1_total
Підраховує кількість запитів до серверів з незахищеними SHA1-підписами в обслуговуючому сертифікаті АБО кількість збоїв зʼєднання через незахищені SHA1-підписи (або/або, залежно від середовища виконання)
  • ALPHA
  • Counter
apiserver_kube_aggregator_x509_missing_san_total
Підраховує кількість запитів до серверів, у яких відсутнє розширення SAN в обслуговуючому сертифікаті, АБО кількість збоїв зʼєднання через відсутність x509 сертифіката, у якому відсутнє розширення SAN (або, залежно від середовища виконання)
  • ALPHA
  • Counter
apiserver_nodeport_repair_port_errors_total
Кількість помилок, виявлених на портах циклом виправлення, з розбивкою за типом помилки: leak, repair, full, outOfRange, duplicate, unknown
  • ALPHA
  • Counter
  • type
apiserver_request_aborts_total
Кількість запитів, які apiserver перервав, можливо, через таймаут, для кожної групи, версії, дієслова, ресурсу, субресурсу та області дії
  • ALPHA
  • Counter
  • groupresourcescopesubresourceverbversion
apiserver_request_body_size_bytes
Розмір тіла запиту Apiserver в байтах з розбивкою за ресурсами та дієсловами.
  • ALPHA
  • Histogram
  • resourceverb
apiserver_request_filter_duration_seconds
Розподіл затримки фільтрації запитів у секундах для кожного типу фільтрів
  • ALPHA
  • Histogram
  • filter
apiserver_request_post_timeout_total
Відстежує активність обробників запитів після того, як повʼязані з ними запити були вичерпані apiserverʼом
  • ALPHA
  • Counter
  • sourcestatus
apiserver_request_sli_duration_seconds
Розподіл затримок відповіді (не враховуючи тривалості вебхука та часу очікування в черзі пріоритету і справедливості) в секундах для кожного дієслова, групи, версії, ресурсу, субресурсу, області дії та компонента.
  • ALPHA
  • Histogram
  • componentgroupresourcescopesubresourceverbversion
apiserver_request_slo_duration_seconds
Розподіл затримок відповіді (не враховуючи тривалості вебхука та часу очікування в черзі пріоритету і справедливості) в секундах для кожного дієслова, групи, версії, ресурсу, субресурсу, області дії та компонента.
  • ALPHA
  • Histogram
  • componentgroupresourcescopesubresourceverbversion
  • 1.27.0
apiserver_request_terminations_total
Кількість запитів, які apiserver припинив з метою самозахисту.
  • ALPHA
  • Counter
  • codecomponentgroupresourcescopesubresourceverbversion
apiserver_request_timestamp_comparison_time
Час, витрачений на порівняння старих і нових обʼєктів у запитах UPDATE або PATCH
  • ALPHA
  • Histogram
  • code_path
apiserver_rerouted_request_total
Загальна кількість запитів, які були перенаправлені на рівноправний kube apiserver через те, що локальний apiserver не зміг їх обслужити
  • ALPHA
  • Counter
  • code
apiserver_selfrequest_total
Лічильник самозвернень apiserver, розбитий для кожного дієслова, ресурсу API та субресурсу.
  • ALPHA
  • Counter
  • resourcesubresourceverb
apiserver_storage_data_key_generation_duration_seconds
Затримки в секундах операцій генерації ключів шифрування даних (DEK).
  • ALPHA
  • Histogram
apiserver_storage_data_key_generation_failures_total
Загальна кількість невдалих операцій генерації ключів шифрування даних (DEK).
  • ALPHA
  • Counter
apiserver_storage_db_total_size_in_bytes
Загальний розмір файлу бази даних, фізично виділений в байтах.
  • ALPHA
  • Gauge
  • endpoint
  • 1.28.0
apiserver_storage_decode_errors_total
Кількість збережених помилок декодування обʼєктів з розподілом за типами обʼєктів
  • ALPHA
  • Counter
  • resource
apiserver_storage_envelope_transformation_cache_misses_total
Загальна кількість пропусків кешу при доступі до ключа дешифрування (KEK).
  • ALPHA
  • Counter
apiserver_storage_events_received_total
Кількість отриманих подій etcd з розбивкою за типами.
  • ALPHA
  • Counter
  • resource
apiserver_storage_list_evaluated_objects_total
Кількість протестованих обʼєктів під час обслуговування LIST-запиту зі сховища
  • ALPHA
  • Counter
  • resource
apiserver_storage_list_fetched_objects_total
Кількість обʼєктів, прочитаних зі сховища під час обслуговування LIST-запиту
  • ALPHA
  • Counter
  • resource
apiserver_storage_list_returned_objects_total
Кількість обʼєктів, що повертаються на запит LIST зі сховища
  • ALPHA
  • Counter
  • resource
apiserver_storage_list_total
Кількість запитів LIST, виконаних зі сховища
  • ALPHA
  • Counter
  • resource
apiserver_storage_transformation_duration_seconds
Затримки в секундах операцій перетворення значень.
  • ALPHA
  • Histogram
  • transformation_typetransformer_prefix
apiserver_storage_transformation_operations_total
Загальна кількість перетворень. Успішне перетворення матиме статус "OK", а у випадку невдалого перетворення — інший рядок статусу. Цей статус і поле типу перетворення можуть бути використані для сповіщення про невдале шифрування/розшифрування з використанням типу перетворення transformation_type from_storage для розшифрування і to_storage для шифрування.
  • ALPHA
  • Counter
  • statustransformation_typetransformer_prefix
apiserver_stream_translator_requests_total
Загальна кількість запитів, які були оброблені проксі StreamTranslatorProxy, що обробляє потокове відтворення RemoteCommand/V5
  • ALPHA
  • Counter
  • code
apiserver_terminated_watchers_total
Лічильник спостерігачів закрито через відсутність реакції за типом ресурсу.
  • ALPHA
  • Counter
  • resource
apiserver_tls_handshake_errors_total
Кількість запитів, відхилених з помилкою 'TLS handshake error from'
  • ALPHA
  • Counter
apiserver_validating_admission_policy_check_duration_seconds
Затримка допуску валідації для окремих виразів валідації в секундах, позначена політикою, а також вказівкою на звʼязаність, стан та вжиті заходи примусового виконання.
  • ALPHA
  • Histogram
  • enforcement_actionpolicypolicy_bindingstate
apiserver_validating_admission_policy_check_total
Перевірка політики допуску перевіряє загальну кількість, позначену політикою, з подальшою ідентифікацією за обовʼязковістю, вжитими заходами примусового виконання та станом.
  • ALPHA
  • Counter
  • enforcement_actionpolicypolicy_bindingstate
apiserver_validating_admission_policy_definition_total
Валідація політики допуску підраховує загальну кількість, позначену станом та заходами примусового виконання.
  • ALPHA
  • Counter
  • enforcement_actionstate
apiserver_watch_cache_events_dispatched_total
Лічильник подій, відправлених у кеш watch, розбитий за типами ресурсів.
  • ALPHA
  • Counter
  • resource
apiserver_watch_cache_events_received_total
Лічильник подій, отриманих у кеші watch, розбитий за типом ресурсу.
  • ALPHA
  • Counter
  • resource
apiserver_watch_cache_initializations_total
Лічильник ініціалізацій кешу watch, розбитий за типами ресурсів.
  • ALPHA
  • Counter
  • resource
apiserver_watch_cache_read_wait_seconds
Гістограма часу, витраченого на очікування оновлення кешу watch.
  • ALPHA
  • Histogram
  • resource
apiserver_watch_events_sizes
Перегляд розподілу розміру події в байтах
  • ALPHA
  • Histogram
  • groupkindversion
apiserver_watch_events_total
Кількість подій, надісланих клієнтам watch
  • ALPHA
  • Counter
  • groupkindversion
apiserver_watch_list_duration_seconds
Розподіл затримки відповіді в секундах для запитів до списків спостереження за групами, версіями, ресурсами та сферами застосування.
  • ALPHA
  • Histogram
  • groupresourcescopeversion
apiserver_webhooks_x509_insecure_sha1_total
Підраховує кількість запитів до серверів з незахищеними SHA1-підписами в обслуговуючому сертифікаті АБО кількість збоїв зʼєднання через незахищені SHA1-підписи (або/або, залежно від середовища виконання)
  • ALPHA
  • Counter
apiserver_webhooks_x509_missing_san_total
Підраховує кількість запитів до серверів, у яких відсутнє розширення SAN в обслуговуючому сертифікаті, АБО кількість збоїв зʼєднання через відсутність x509 сертифіката, у якому відсутнє розширення SAN (або/або, залежно від середовища виконання)
  • ALPHA
  • Counter
attach_detach_controller_attachdetach_controller_forced_detaches
Кількість разів, коли контролер A/D виконував примусове відʼєднання
  • ALPHA
  • Counter
  • reason
attachdetach_controller_total_volumes
Кількість томів в A/D контролері
  • ALPHA
  • Custom
  • plugin_namestate
authenticated_user_requests
Лічильник автентифікованих запитів, розбитий за іменами користувачів.
  • ALPHA
  • Counter
  • username
authentication_attempts
Лічильник автентифікованих спроб.
  • ALPHA
  • Counter
  • result
authentication_duration_seconds
Тривалість автентифікації в секундах з розбивкою за результатами.
  • ALPHA
  • Histogram
  • result
authentication_token_cache_active_fetch_count
  • ALPHA
  • Gauge
  • status
authentication_token_cache_fetch_total
  • ALPHA
  • Counter
  • status
authentication_token_cache_request_duration_seconds
  • ALPHA
  • Histogram
  • status
authentication_token_cache_request_total
  • ALPHA
  • Counter
  • status
authorization_attempts_total
Лічильник спроб авторизації з розбивкою за результатом. Це може бути "allowed", "denied", "no-opinion" або "error".
  • ALPHA
  • Counter
  • result
authorization_duration_seconds
Тривалість авторизації в секундах з розбивкою за результатами.
  • ALPHA
  • Histogram
  • result
cloud_provider_webhook_request_duration_seconds
Затримка запиту в секундах. З розбивкою по коду статусу.
  • ALPHA
  • Histogram
  • codewebhook
cloud_provider_webhook_request_total
Кількість HTTP-запитів, розділених за кодом статусу.
  • ALPHA
  • Counter
  • codewebhook
cloudprovider_gce_api_request_duration_seconds
Затримка виклику API GCE
  • ALPHA
  • Histogram
  • regionrequestversionzone
cloudprovider_gce_api_request_errors
Кількість помилок виклику API
  • ALPHA
  • Counter
  • regionrequestversionzone
container_swap_usage_bytes
Поточний обсяг використання свопу контейнера у байтах. Відображається лише на системах, відмінних від Windows
  • ALPHA
  • Custom
  • containerpodnamespace
csi_operations_seconds
Тривалість роботи інтерфейсу Container Storage Interface з кодом помилки gRPC усього
  • ALPHA
  • Histogram
  • driver_namegrpc_status_codemethod_namemigrated
endpoint_slice_controller_changes
Кількість змін EndpointSlice
  • ALPHA
  • Counter
  • operation
endpoint_slice_controller_desired_endpoint_slices
Кількість EndpointSlices, які могли б існувати при ідеальному розподілі точок доступу
  • ALPHA
  • Gauge
endpoint_slice_controller_endpoints_added_per_sync
Кількість точок доступу, доданих під час кожної синхронізації Service
  • ALPHA
  • Histogram
endpoint_slice_controller_endpoints_desired
Кількість бажаних точок доступу
  • ALPHA
  • Gauge
endpoint_slice_controller_endpoints_removed_per_sync
Кількість видалених точок доступу під час кожної синхронізації Service
  • ALPHA
  • Histogram
endpoint_slice_controller_endpointslices_changed_per_sync
Кількість EndpointSlices, змінених під час кожної синхронізації Service
  • ALPHA
  • Histogram
  • topologytraffic_distribution
endpoint_slice_controller_num_endpoint_slices
Кілкість EndpointSlices
  • ALPHA
  • Gauge
endpoint_slice_controller_services_count_by_traffic_distribution
Кількість Services, що використовують певний trafficDistribution
  • ALPHA
  • Gauge
  • traffic_distribution
endpoint_slice_controller_syncs
Кількість синхронізацій EndpointSlice
  • ALPHA
  • Counter
  • result
endpoint_slice_mirroring_controller_addresses_skipped_per_sync
Кількість адрес, пропущених під час кожної синхронізації точок доступу через те, що вони недійсні або перевищують MaxEndpointsPerSubset
  • ALPHA
  • Histogram
endpoint_slice_mirroring_controller_changes
Кількість змін EndpointSlice
  • ALPHA
  • Counter
  • operation
endpoint_slice_mirroring_controller_desired_endpoint_slices
Кількість EndpointSlices, які могли б існувати при ідеальному розподілі точок доступу
  • ALPHA
  • Gauge
endpoint_slice_mirroring_controller_endpoints_added_per_sync
Кількість точок доступу, доданих під час кожної синхронізації Endpoints
  • ALPHA
  • Histogram
endpoint_slice_mirroring_controller_endpoints_desired
Кількість бажаних точок доступу
  • ALPHA
  • Gauge
endpoint_slice_mirroring_controller_endpoints_removed_per_sync
Кількість видалених точок доступу під час кожної синхронізації Endpoints
  • ALPHA
  • Histogram
endpoint_slice_mirroring_controller_endpoints_sync_duration
Тривалість syncEndpoints() у секундах
  • ALPHA
  • Histogram
endpoint_slice_mirroring_controller_endpoints_updated_per_sync
Кількість точок доступу, оновлених під час кожної синхронізації Endpoints
  • ALPHA
  • Histogram
endpoint_slice_mirroring_controller_num_endpoint_slices
Кількість EndpointSlices
  • ALPHA
  • Gauge
ephemeral_volume_controller_create_failures_total
Кількість запитів на створення PersistenVolumeClaims
  • ALPHA
  • Counter
ephemeral_volume_controller_create_total
Кількість запитів на створення PersistenVolumeClaims
  • ALPHA
  • Counter
etcd_bookmark_counts
Кількість закладок etcd (подій, що сповіщають про хід виконання) з розподілом за типами.
  • ALPHA
  • Gauge
  • resource
etcd_lease_object_counts
Кількість обʼєктів, закріплених за одним lease etcd.
  • ALPHA
  • Histogram
etcd_request_duration_seconds
Затримка запиту etcd в секундах для кожної операції та типу обʼєкта.
  • ALPHA
  • Histogram
  • operationtype
etcd_request_errors_total
Etcd підраховує кількість невдалих запитів для кожної операції та типу обʼєкта.
  • ALPHA
  • Counter
  • operationtype
etcd_requests_total
Підрахунок запитів etcd здійснюється для кожної операції та типу обʼєкта.
  • ALPHA
  • Counter
  • operationtype
etcd_version_info
Версія сервера etcd
  • ALPHA
  • Gauge
  • binary_version
field_validation_request_duration_seconds
Розподіл затримки відповіді в секундах для кожного значення валідації поля
  • ALPHA
  • Histogram
  • field_validation
force_cleaned_failed_volume_operation_errors_total
Кількість томів, які не пройшли примусове очищення після реконструкції, не пройшли примусового очищення під час запуску kubelet.
  • ALPHA
  • Counter
force_cleaned_failed_volume_operations_total
Кількість томів, які були примусово очищені після невдалої реконструкції під час запуску kubelet. Сюди входять як успішні, так і невдалі очищення.
  • ALPHA
  • Counter
garbagecollector_controller_resources_sync_error_total
Кількість помилок синхронізації ресурсів збирача сміття
  • ALPHA
  • Counter
get_token_count
Лічильник загальної кількості запитів Token() до альтернативного джерела токенів
  • ALPHA
  • Counter
get_token_fail_count
Лічильник невдалих запитів Token() до альтернативного джерела токенів
  • ALPHA
  • Counter
horizontal_pod_autoscaler_controller_metric_computation_duration_seconds
Час (у секундах), який контролер HPA витрачає на обчислення однієї метрики. Мітка 'action' має бути або 'scale_down', або 'scale_up', або 'none'. Мітка 'error' повинна мати значення 'spec', 'internal' або 'none'. Мітка 'metric_type' відповідає HPA.spec.metrics[*].type
  • ALPHA
  • Histogram
  • actionerrormetric_type
horizontal_pod_autoscaler_controller_metric_computation_total
Кількість обчислень метрики. Мітка 'action' має бути або 'scale_down', або 'scale_up', або 'none'. Також мітка 'error' повинна мати значення 'spec', 'internal' або 'none'. Мітка 'metric_type' відповідає HPA.spec.metrics[*].type
  • ALPHA
  • Counter
  • actionerrormetric_type
horizontal_pod_autoscaler_controller_reconciliation_duration_seconds
Час (у секундах), який потрібен контролеру HPA для одноразового узгодження. Мітка 'action' має бути або 'scale_down', або 'scale_up', або 'none'. Також мітка 'error' має бути або 'spec', або 'internal', або 'none'. Зауважте, що якщо під час звірки виникають і специфічні, і внутрішні помилки, то в мітці `error` відображається перша з них.
  • ALPHA
  • Histogram
  • actionerror
horizontal_pod_autoscaler_controller_reconciliations_total
Кількість коригувань контролера HPA. Мітка 'action' має бути або 'scale_down', або 'scale_up', або 'none'. Також мітка 'error' має бути або 'spec', або 'internal', або 'none'. Зверніть увагу, що якщо під час узгодження виникають як специфічні, так і внутрішні помилки, то в мітці `error` відображається перша з них.
  • ALPHA
  • Counter
  • actionerror
job_controller_job_finished_indexes_total
`Кількість готових індексів. Можливі значення для мітки статусу: "successed", "failed". Можливі значення для мітки backoffLimit: "perIndex" та "global"`.
  • ALPHA
  • Counter
  • backoffLimitstatus
job_controller_job_pods_creation_total
`Кількість Podʼів, створених контролером Job, позначених причиною створення Podʼа. Ця метрика також розрізняє Podʼи, створені з використанням різних налаштувань PodReplacementPolicy. Можливі значення мітки "reason": "new", "recreate_terminating_or_failed", "recreate_failed", "recreate_failed". Можливі значення мітки "status": "succeeded", "failed".`
  • ALPHA
  • Counter
  • reasonstatus
job_controller_jobs_by_external_controller_total
Кількість Job, якими керує зовнішній контролер
  • ALPHA
  • Counter
  • controller_name
job_controller_pod_failures_handled_by_failure_policy_total
`Кількість збійних Podʼів, оброблених політикою збоїв, відносно дії політики збоїв, застосованої на основі відповідного правила. Можливі значення мітки дії відповідають можливим значенням дії правила політики відмов, а саме: "FailJob", "Ignore" та "Count".`
  • ALPHA
  • Counter
  • action
job_controller_terminated_pods_tracking_finalizer_total
`Кількість завершених Podʼів (phase=Failed|Successed), які мають завершувач batch.kubernetes.io/job-tracking, Мітка події може бути "add" або "delete".`
  • ALPHA
  • Counter
  • event
kube_apiserver_clusterip_allocator_allocated_ips
Показник, що вимірює кількість виділених IP-адрес для Services
  • ALPHA
  • Gauge
  • cidr
kube_apiserver_clusterip_allocator_allocation_errors_total
Кількість помилок при виділенні кластерних IP-адрес
  • ALPHA
  • Counter
  • cidrscope
kube_apiserver_clusterip_allocator_allocation_total
Кількість розподілених кластерних IP-адрес
  • ALPHA
  • Counter
  • cidrscope
kube_apiserver_clusterip_allocator_available_ips
Показник, що вимірює кількість доступних IP-адрес для Services
  • ALPHA
  • Gauge
  • cidr
kube_apiserver_nodeport_allocator_allocated_ports
Вимірювання кількості виділених NodePorts для Service
  • ALPHA
  • Gauge
kube_apiserver_nodeport_allocator_available_ports
Вимірювання кількості доступних NodePorts для Services
  • ALPHA
  • Gauge
kube_apiserver_pod_logs_backend_tls_failure_total
Загальна кількість запитів до Podʼів/логів, які завершилися невдало через перевірку TLS сервером kubelet
  • ALPHA
  • Counter
kube_apiserver_pod_logs_insecure_backend_total
Загальна кількість запитів до Podʼів/логів за типом використання: enforce_tls, skip_tls_allowed, skip_tls_denied
  • ALPHA
  • Counter
  • usage
kube_apiserver_pod_logs_pods_logs_backend_tls_failure_total
Загальна кількість запитів до Podʼів/логів, які завершилися невдало через перевірку TLS сервера kubelet
  • ALPHA
  • Counter
  • 1.27.0
kube_apiserver_pod_logs_pods_logs_insecure_backend_total
Загальна кількість запитів до Podʼів/логів за типом використання: enforce_tls, skip_tls_allowed, skip_tls_denied
  • ALPHA
  • Counter
  • usage
  • 1.27.0
kubelet_active_pods
Кількість Podʼів, які kubelet вважає активними і які розглядаються при прийнятті нових Podʼів. статичне значення істинне, якщо Pod не від apiserver'а.
  • ALPHA
  • Gauge
  • static
kubelet_certificate_manager_client_expiration_renew_errors
Лічильник помилок поновлення сертифікатів.
  • ALPHA
  • Counter
kubelet_certificate_manager_client_ttl_seconds
Показник TTL (час життя) клієнтського сертифіката Kubelet. Значення в секундах до закінчення терміну дії сертифіката (відʼємне, якщо термін дії вже закінчився). Якщо клієнтський сертифікат недійсний або невикористаний, значення буде +INF.
  • ALPHA
  • Gauge
kubelet_certificate_manager_server_rotation_seconds
Гістограма кількості секунд, які проіснував попередній сертифікат перед ротацією.
  • ALPHA
  • Histogram
kubelet_certificate_manager_server_ttl_seconds
Показник найкоротшого TTL (time-to-live) сертифікату обслуговування Kubelet. Значення в секундах до закінчення терміну дії сертифіката (відʼємне, якщо термін дії вже закінчився). Якщо обслуговуючий сертифікат недійсний або невикористаний, значення буде +INF.
  • ALPHA
  • Gauge
kubelet_cgroup_manager_duration_seconds
Тривалість у секундах для операцій cgroup manager. Розбито за методами.
  • ALPHA
  • Histogram
  • operation_type
kubelet_container_log_filesystem_used_bytes
Байти, що використовуються логами контейнера у файловій системі.
  • ALPHA
  • Custom
  • uidnamespacepodcontainer
kubelet_containers_per_pod_count
Кількість контейнерів на один Pod.
  • ALPHA
  • Histogram
kubelet_cpu_manager_pinning_errors_total
Кількість розподілів ядер процесора, які потребували pinning, зазнали невдачі.
  • ALPHA
  • Counter
kubelet_cpu_manager_pinning_requests_total
Кількість розподілів ядер процесора, які потребували pinning.
  • ALPHA
  • Counter
kubelet_credential_provider_plugin_duration
Тривалість виконання в секундах для втулка постачальника облікових даних
  • ALPHA
  • Histogram
  • plugin_name
kubelet_credential_provider_plugin_errors
Кількість помилок від втулка постачальника облікових даних
  • ALPHA
  • Counter
  • plugin_name
kubelet_desired_pods
Кількість Podʼів, які kubelet має запустити. static має значення true, якщо pod не від apiserverʼа.
  • ALPHA
  • Gauge
  • static
kubelet_device_plugin_alloc_duration_seconds
Тривалість у секундах обслуговування запиту на виділення втулка пристрою. Розбито за назвою ресурсу.
  • ALPHA
  • Histogram
  • resource_name
kubelet_device_plugin_registration_total
Загальна кількість реєстрацій втулків для пристроїв. Розбито за назвою ресурсу.
  • ALPHA
  • Counter
  • resource_name
kubelet_evented_pleg_connection_error_count
Кількість помилок, що виникли під час встановлення потокового зʼєднання з середовищем виконання CRI.
  • ALPHA
  • Counter
kubelet_evented_pleg_connection_latency_seconds
Затримка потокового зʼєднання з процесом виконання CRI, вимірюється в секундах.
  • ALPHA
  • Histogram
kubelet_evented_pleg_connection_success_count
Кількість разів, коли потоковий клієнт отримував події CRI.
  • ALPHA
  • Counter
kubelet_eviction_stats_age_seconds
Час між збором статистики та виселенням Pod на основі цієї статистики за сигналом про виселення
  • ALPHA
  • Histogram
  • eviction_signal
kubelet_evictions
Сумарна кількість виселень Podʼів за сигналом про виселення
  • ALPHA
  • Counter
  • eviction_signal
kubelet_graceful_shutdown_end_time_seconds
Останній час запуску належного припинення роботи програмного забезпечення в секундах unix
  • ALPHA
  • Gauge
kubelet_graceful_shutdown_start_time_seconds
Останній час запуску належного припинення роботи програмного забезпечення в секундах unix
  • ALPHA
  • Gauge
kubelet_http_inflight_requests
Кількість запитів http під час польоту
  • ALPHA
  • Gauge
  • long_runningmethodpathserver_type
kubelet_http_requests_duration_seconds
Тривалість обслуговування http-запитів у секундах
  • ALPHA
  • Histogram
  • long_runningmethodpathserver_type
kubelet_http_requests_total
Кількість http запитів, отриманих з моменту запуску сервера
  • ALPHA
  • Counter
  • long_runningmethodpathserver_type
kubelet_image_garbage_collected_total
Загальна кількість образів, зібраних системою збирання сміття kubelet, незалежно від використання диска або віку образів.
  • ALPHA
  • Counter
  • reason
kubelet_image_pull_duration_seconds
Тривалість у секундах для отримання образу.
  • ALPHA
  • Histogram
  • image_size_in_bytes
kubelet_lifecycle_handler_http_fallbacks_total
The number of times lifecycle handlers successfully fell back to http from https.
  • ALPHA
  • Counter
kubelet_managed_ephemeral_containers
Поточна кількість ефемерних контейнерів у Podʼах, якими керує цей kubelet.
  • ALPHA
  • Gauge
kubelet_memory_manager_pinning_errors_total
Кількість розподілів сторінок памʼяті, які потребували закріплення, що не вдалося.
  • ALPHA
  • Counter
kubelet_memory_manager_pinning_requests_total
Кількість розподілів сторінок памʼяті, які потребували закріплення.
  • ALPHA
  • Counter
kubelet_mirror_pods
Кількість дзеркальних Podʼів, які спробує створити kubelet (по одному на кожен допустимий статичний Pod)
  • ALPHA
  • Gauge
kubelet_node_name
Імʼя вузла. Кількість завжди дорівнює 1.
  • ALPHA
  • Gauge
  • node
kubelet_node_startup_duration_seconds
Тривалість у секундах запуску вузла в цілому.
  • ALPHA
  • Gauge
kubelet_node_startup_post_registration_duration_seconds
Тривалість у секундах запуску вузла після реєстрації.
  • ALPHA
  • Gauge
kubelet_node_startup_pre_kubelet_duration_seconds
Тривалість у секундах запуску вузла до запуску kubelet.
  • ALPHA
  • Gauge
kubelet_node_startup_pre_registration_duration_seconds
Тривалість у секундах запуску вузла перед реєстрацією.
  • ALPHA
  • Gauge
kubelet_node_startup_registration_duration_seconds
Тривалість у секундах запуску вузла під час реєстрації.
  • ALPHA
  • Gauge
kubelet_orphan_pod_cleaned_volumes
Загальна кількість осиротілих Pod, чиї томи були очищені під час останнього періодичного обстеження.
  • ALPHA
  • Gauge
kubelet_orphan_pod_cleaned_volumes_errors
Кількість осиротілих Pod, чиї томи не вдалося очистити під час останнього періодичного обстеження.
  • ALPHA
  • Gauge
kubelet_orphaned_runtime_pods_total
Кількість Podʼів, які були виявлені в середовищі виконання контейнерів, які невідомі для pod worker. Це зазвичай вказує на те, що kubelet був перезапущений під час примусового видалення Pod в API або в локальній конфігурації, що є незвичним.
  • ALPHA
  • Counter
kubelet_pleg_discard_events
Кількість подій відхилення в PLEG (Pod Lifecycle Event Generator).
  • ALPHA
  • Counter
kubelet_pleg_last_seen_seconds
Позначка часу в секундах, коли PLEG востаннє був активний.
  • ALPHA
  • Gauge
kubelet_pleg_relist_duration_seconds
Тривалість у секундах для повторного переліку Podʼів в PLEG.
  • ALPHA
  • Histogram
kubelet_pleg_relist_interval_seconds
Інтервал у секундах між повторними переліками в PLEG.
  • ALPHA
  • Histogram
kubelet_pod_resources_endpoint_errors_get
Кількість запитів до точки доступу PodResource Get, які повернули помилку. Розбито за версіями API сервера.
  • ALPHA
  • Counter
  • server_api_version
kubelet_pod_resources_endpoint_errors_get_allocatable
Кількість запитів до точки доступу PodResource GetAllocatableResources, які повернули помилку. Розбито за версіями API сервера.
  • ALPHA
  • Counter
  • server_api_version
kubelet_pod_resources_endpoint_errors_list
Кількість запитів до точки доступу PodResource List, які повернули помилку. Розбито за версіями API сервера.
  • ALPHA
  • Counter
  • server_api_version
kubelet_pod_resources_endpoint_requests_get
Кількість запитів до точки доступу PodResource Get, розбита за версіями API сервера.
  • ALPHA
  • Counter
  • server_api_version
kubelet_pod_resources_endpoint_requests_get_allocatable
Кількість запитів до точки доступу PodResource GetAllocatableResources, розбита за версіями API сервера.
  • ALPHA
  • Counter
  • server_api_version
kubelet_pod_resources_endpoint_requests_list
Кількість запитів до точки доступу PodResource List, розбита за версіями API сервера.
  • ALPHA
  • Counter
  • server_api_version
kubelet_pod_resources_endpoint_requests_total
Загальна кількість запитів до точки доступу PodResource, розбита за версіями API сервера.
  • ALPHA
  • Counter
  • server_api_version
kubelet_pod_start_duration_seconds
Тривалість у секундах від першого виявлення kubelet'ом Podʼа до початку його запуску.
  • ALPHA
  • Histogram
kubelet_pod_start_sli_duration_seconds
Тривалість у секундах для запуску Pod, за виключенням часу на завантаження образів та виконання init-контейнерів, виміряна з моменту позначки часу створення Pod до того, як всі його контейнери будуть відзначені як запущені та доступні для спостереження через watch.
  • ALPHA
  • Histogram
kubelet_pod_start_total_duration_seconds
Тривалість у секундах для запуску Pod з моменту створення, включаючи час на завантаження образів та виконання init-контейнерів, виміряна з позначки часу створення Pod до того моменту, коли всі його контейнери будуть відзначені як запущені та доступні для спостережені через watch.
  • ALPHA
  • Histogram
kubelet_pod_status_sync_duration_seconds
Тривалість у секундах синхронізації оновлення статусу Pod. Вимірює час від виявлення зміни статусу Pod до успішного оновлення API для цього Pod, навіть якщо відбулося кілька проміжних змін статусу Pod.
  • ALPHA
  • Histogram
kubelet_pod_worker_duration_seconds
Тривалість у секундах синхронізації одного Pod, розбита за операціями: create, update або sync.
  • ALPHA
  • Histogram
  • operation_type
kubelet_pod_worker_start_duration_seconds
Тривалість у секундах від моменту, коли kubelet виявляє Pod до початку запуску виконавця робочого навантаження.
  • ALPHA
  • Histogram
kubelet_preemptions
Загальна кількість передчасних випереджень Podʼів за ресурсом випередження.
  • ALPHA
  • Counter
  • preemption_signal
kubelet_restarted_pods_total
Кількість Podʼів, які були перезапущені через те, що вони були видалені та створені знову з тим самим UID, поки kubelet відстежував їх (звично для статичних Podʼів, надзвичайно рідко для pod API).
  • ALPHA
  • Counter
  • static
kubelet_run_podsandbox_duration_seconds
Тривалість у секундах операцій run_podsandbox. Розбито за RuntimeClass.Handler.
  • ALPHA
  • Histogram
  • runtime_handler
kubelet_run_podsandbox_errors_total
Загальна кількість помилок операцій run_podsandbox в розрізі RuntimeClass.Handler.
  • ALPHA
  • Counter
  • runtime_handler
kubelet_running_containers
Кількість контейнерів, що зараз працюють.
  • ALPHA
  • Gauge
  • container_state
kubelet_running_pods
Кількість Podʼів, які мають працюючий pod sandbox
  • ALPHA
  • Gauge
kubelet_runtime_operations_duration_seconds
Тривалість у секундах операцій середовища виконання. Розбито за типом операції.
  • ALPHA
  • Histogram
  • operation_type
kubelet_runtime_operations_errors_total
Загальна кількість помилок операцій середовища виконання за типом операції.
  • ALPHA
  • Counter
  • operation_type
kubelet_runtime_operations_total
Загальна кількість операцій середовища виконання за типом операції.
  • ALPHA
  • Counter
  • operation_type
kubelet_server_expiration_renew_errors
Лічильник помилок оновлення сертифікатів.
  • ALPHA
  • Counter
kubelet_sleep_action_terminated_early_total
Кількість разів, коли обробник сну життєвого циклу був завершений до завершення його роботи.
  • ALPHA
  • Counter
kubelet_started_containers_errors_total
Загальна кількість помилок під час запуску контейнерів.
  • ALPHA
  • Counter
  • codecontainer_type
kubelet_started_containers_total
Загальна кількість запущених контейнерів.
  • ALPHA
  • Counter
  • container_type
kubelet_started_host_process_containers_errors_total
Сукупна кількість помилок при запуску контейнерів hostprocess. Ця метрика буде збиратися тільки у Windows.
  • ALPHA
  • Counter
  • codecontainer_type
kubelet_started_host_process_containers_total
Сукупна кількість запущених контейнерів hostprocess. Ця метрика буде збиратися лише у Windows.
  • ALPHA
  • Counter
  • container_type
kubelet_started_pods_errors_total
Сукупна кількість помилок під час запуску Podʼів
  • ALPHA
  • Counter
kubelet_started_pods_total
Сукупна кількість запущених Podʼів
  • ALPHA
  • Counter
kubelet_topology_manager_admission_duration_ms
Тривалість у мілісекундах для обслуговування запиту на допуск Podʼа.
  • ALPHA
  • Histogram
kubelet_topology_manager_admission_errors_total
Кількість відмов запитів допуску, коли не вдалося виділити ресурси.
  • ALPHA
  • Counter
kubelet_topology_manager_admission_requests_total
Кількістьт заявок допуску, для яких потрібне вирівнювання ресурсів.
  • ALPHA
  • Counter
kubelet_volume_metric_collection_duration_seconds
Тривалість у секундах для розрахунку статистики тому
  • ALPHA
  • Histogram
  • metric_source
kubelet_volume_stats_available_bytes
Кількість доступних байт в томі
  • ALPHA
  • Custom
  • namespacepersistentvolumeclaim
kubelet_volume_stats_capacity_bytes
Місткість тому у байтах
  • ALPHA
  • Custom
  • namespacepersistentvolumeclaim
kubelet_volume_stats_health_status_abnormal
Статус справності аномального тому. Значення 1 або 0. 1 — означає, що том н є справним, 0 — говорить про справність тому
  • ALPHA
  • Custom
  • namespacepersistentvolumeclaim
kubelet_volume_stats_inodes
Максимальна кількість inode в томі
  • ALPHA
  • Custom
  • namespacepersistentvolumeclaim
kubelet_volume_stats_inodes_free
Кількість вільних inode в томі
  • ALPHA
  • Custom
  • namespacepersistentvolumeclaim
kubelet_volume_stats_inodes_used
Кількість використаних inode у томі
  • ALPHA
  • Custom
  • namespacepersistentvolumeclaim
kubelet_volume_stats_used_bytes
Кількість використаних байт у томі
  • ALPHA
  • Custom
  • namespacepersistentvolumeclaim
kubelet_working_pods
Кількість Podʼів, які фактично виконує kubelet, з розбивкою за фазами життєвого циклу, чи є Pod бажаним, осиротілим або тільки для виконання (також осиротілим), а також чи є Pod статичним. Осиротілий Pod був видалений з локальної конфігурації або примусово видалений в API та споживає ресурси, які не є видимими в інших випадках.
  • ALPHA
  • Gauge
  • configlifecyclestatic
kubeproxy_network_programming_duration_seconds
В Cluster Network Programming Latency затримка в секундах
  • ALPHA
  • Histogram
kubeproxy_proxy_healthz_total
Сукупний стан справності проксі-сервера HTTP
  • ALPHA
  • Counter
  • code
kubeproxy_proxy_livez_total
Сукупний стан життєздатності проксі-сервера HTTP
  • ALPHA
  • Counter
  • code
kubeproxy_sync_full_proxy_rules_duration_seconds
Затримка SyncProxyRules у секундах для повних повторних синхронізацій
  • ALPHA
  • Histogram
kubeproxy_sync_partial_proxy_rules_duration_seconds
Затримка SyncProxyRules у секундах для часткових повторних синхронізацій
  • ALPHA
  • Histogram
kubeproxy_sync_proxy_rules_duration_seconds
SyncProxyRules затримка в секундах
  • ALPHA
  • Histogram
kubeproxy_sync_proxy_rules_endpoint_changes_pending
Правила проксі, що очікують на розгляд зміни Endpoint
  • ALPHA
  • Gauge
kubeproxy_sync_proxy_rules_endpoint_changes_total
Кумулятивні проксі-правила зміни Endpoint
  • ALPHA
  • Counter
kubeproxy_sync_proxy_rules_iptables_last
Кількість правил iptables, записаних kube-proxy під час останньої синхронізації
  • ALPHA
  • Gauge
  • table
kubeproxy_sync_proxy_rules_iptables_partial_restore_failures_total
Сукупні помилки часткового відновлення iptables проксі-сервера
  • ALPHA
  • Counter
kubeproxy_sync_proxy_rules_iptables_restore_failures_total
Сукупні помилки відновлення iptables проксі-сервера
  • ALPHA
  • Counter
kubeproxy_sync_proxy_rules_iptables_total
Загальна кількість правил iptables, якими володіє kube-proxy
  • ALPHA
  • Gauge
  • table
kubeproxy_sync_proxy_rules_last_queued_timestamp_seconds
Останній раз, коли синхронізація правил проксі була поставлена в чергу
  • ALPHA
  • Gauge
kubeproxy_sync_proxy_rules_last_timestamp_seconds
Останній раз, коли правила проксі були успішно синхронізовані
  • ALPHA
  • Gauge
kubeproxy_sync_proxy_rules_no_local_endpoints_total
Кількість сервісів з політикою локального трафіку без точок доступу
  • ALPHA
  • Gauge
  • traffic_policy
kubeproxy_sync_proxy_rules_service_changes_pending
Правила проксі в очікувані, що змінюють Service
  • ALPHA
  • Gauge
kubeproxy_sync_proxy_rules_service_changes_total
Сукупні правила проксі в очікувані, що змінюють Service
  • ALPHA
  • Counter
kubernetes_build_info
Метрика з постійним значенням '1', позначена як major, minor, версія git, коміт git, стан дерева git, дата збірки, версія Go, компілятор, з якого було зібрано Kubernetes, та платформа, на якій він працює.
  • ALPHA
  • Gauge
  • build_datecompilergit_commitgit_tree_stategit_versiongo_versionmajorminorplatform
leader_election_master_status
Ознака того, чи є система звітності головною для відповідного lease, 0 вказує на резервну копію, 1 — на головну. "name" — це рядок, який використовується для ідентифікації lease. Будь ласка, згрупуйте за назвою.
  • ALPHA
  • Gauge
  • name
leader_election_slowpath_total
Загальна кількість повільних шляхів, використаних при поновленні leases лідера. 'name' — це рядок, який використовується для ідентифікації lease. Будь ласка, згрупуйте за іменами.
  • ALPHA
  • Counter
  • name
node_authorizer_graph_actions_duration_seconds
Гістограма тривалості дій з графом в авторизаторі вузла.
  • ALPHA
  • Histogram
  • operation
node_collector_unhealthy_nodes_in_zone
Вимірювання кількості не готових вузлів за зонами.
  • ALPHA
  • Gauge
  • zone
node_collector_update_all_nodes_health_duration_seconds
Час у секундах, протягом якого NodeController оновлює стан справності усіх вузлів.
  • ALPHA
  • Histogram
node_collector_update_node_health_duration_seconds
Тривалість у секундах, протягом якої NodeController оновлює стан справності одного вузла.
  • ALPHA
  • Histogram
node_collector_zone_health
Індикатор, що вимірює відсоток справних вузлів у кожній зоні.
  • ALPHA
  • Gauge
  • zone
node_collector_zone_size
Вимірювання кількості зареєстрованих вузлів за зонами.
  • ALPHA
  • Gauge
  • zone
node_controller_cloud_provider_taint_removal_delay_seconds
Кількість секунд після створення вузла, коли NodeController видалив позначку хмарного провайдера з одного вузла.
  • ALPHA
  • Histogram
node_controller_initial_node_sync_delay_seconds
Кількість секунд після створення вузла, коли NodeController завершив початкову синхронізацію одного вузла.
  • ALPHA
  • Histogram
node_ipam_controller_cidrset_allocation_tries_per_request
Кількість точок доступу, доданих під час кожної синхронізації Service
  • ALPHA
  • Histogram
  • clusterCIDR
node_ipam_controller_cidrset_cidrs_allocations_total
Лічильник, що вимірює загальну кількість розподілів CIDR.
  • ALPHA
  • Counter
  • clusterCIDR
node_ipam_controller_cidrset_cidrs_releases_total
Лічильник, що вимірює загальну кількість оновлень CIDR.
  • ALPHA
  • Counter
  • clusterCIDR
node_ipam_controller_cidrset_usage_cidrs
Індикатор, що вимірює відсоток виділених CIDR.
  • ALPHA
  • Gauge
  • clusterCIDR
node_ipam_controller_cirdset_max_cidrs
Максимальна кількість CIDR, яку можна виділити.
  • ALPHA
  • Gauge
  • clusterCIDR
node_swap_usage_bytes
Поточне використання свопу вузла у байтах. Відображається лише на системах, відмінних від Windows
  • ALPHA
  • Custom
number_of_l4_ilbs
Кількість L4 ILBs
  • ALPHA
  • Gauge
  • feature
plugin_manager_total_plugins
Кількість втулків у Plugin Manager
  • ALPHA
  • Custom
  • socket_pathstate
pod_gc_collector_force_delete_pod_errors_total
Кількість помилок, що виникли при примусовому видаленні Podʼів з моменту запуску Pod GC Controller.
  • ALPHA
  • Counter
  • namespacereason
pod_gc_collector_force_delete_pods_total
Кількість Podʼів, які було примусово видалено з моменту запуску контролера Pod GC Controller.
  • ALPHA
  • Counter
  • namespacereason
pod_security_errors_total
Кількість помилок, що перешкоджають нормальній оцінці. Нефатальні помилки можуть призвести до того, що для оцінювання буде використано останній обмежений профіль.
  • ALPHA
  • Counter
  • fatalrequest_operationresourcesubresource
pod_security_evaluations_total
Кількість оцінок політики, що відбулися, не враховуючи проігнорованих або звільнених від розгляду запитів.
  • ALPHA
  • Counter
  • decisionmodepolicy_levelpolicy_versionrequest_operationresourcesubresource
pod_security_exemptions_total
Кількість звільнених запитів, не враховуючи ігнорованих або тих, що виходять за межі області застосування.
  • ALPHA
  • Counter
  • request_operationresourcesubresource
pod_swap_usage_bytes
Поточний обсяг використання підкачки у байтах. Відображається лише на системах, відмінних від Windows
  • ALPHA
  • Custom
  • podnamespace
prober_probe_duration_seconds
Тривалість у секундах для відповіді проби.
  • ALPHA
  • Histogram
  • containernamespacepodprobe_type
prober_probe_total
Сукупна кількість проб життєздатності, готовності або запуску для контейнера в розрізі результатів.
  • ALPHA
  • Counter
  • containernamespacepodpod_uidprobe_typeresult
pv_collector_bound_pv_count
Вимірювач кількості постійного тому, який наразі привʼязаний
  • ALPHA
  • Custom
  • storage_class
pv_collector_bound_pvc_count
Вимірювач кількості поточно привʼязаних persistent volume claim
  • ALPHA
  • Custom
  • namespace
pv_collector_total_pv_count
Вимірювач загальної кількості постійних томів
  • ALPHA
  • Custom
  • plugin_namevolume_mode
pv_collector_unbound_pv_count
Вимірювач кількості постійних томів, що зараз не привʼязані
  • ALPHA
  • Custom
  • storage_class
pv_collector_unbound_pvc_count
Вимірювач кількості не привʼязаних persistent volume claim
  • ALPHA
  • Custom
  • namespace
reconstruct_volume_operations_errors_total
Кількість томів, які не вдалося відновити з операційної системи під час запуску kubelet.
  • ALPHA
  • Counter
reconstruct_volume_operations_total
Кількість томів, які намагалися відновити з операційної системи під час запуску kubelet. Сюди входять як успішні, так і невдалі спроби відновлення.
  • ALPHA
  • Counter
replicaset_controller_sorting_deletion_age_ratio
Відношення віку вибраних видалених Podʼів до поточного наймолодшого віку Podʼів (на даний момент). Має бути менше ніж 2. Мета цієї метрики — виміряти приблизну ефективність впливу функціоналу LogarithmicScaleDown на сортування (і видалення) Podʼів при зменшенні масштабу набору реплік. При обчисленні та створенні звітів враховуються лише готові Podʼи.
  • ALPHA
  • Histogram
resourceclaim_controller_create_attempts_total
Кількість запитів на створення ResourceClaims
  • ALPHA
  • Counter
resourceclaim_controller_create_failures_total
Кількість невдалих запитів на створення ResourceClaims
  • ALPHA
  • Counter
rest_client_dns_resolution_duration_seconds
Затримка DNS-резолвера в секундах. Розбито за хостами.
  • ALPHA
  • Histogram
  • host
rest_client_exec_plugin_call_total
Кількість викликів втулка exec, розділених за типом події, що виникла (no_error, plugin_execution_error, plugin_not_found_error, client_internal_error) та необовʼязковим кодом завершення роботи. Код завершення буде встановлено у 0 тоді і тільки тоді, коли виклик втулка був успішним.
  • ALPHA
  • Counter
  • call_statuscode
rest_client_exec_plugin_certificate_rotation_age
Гістограма кількості секунд, які прожив останній клієнтський сертифікат втулка auth exec до того, як його було ротовано. Якщо клієнтські сертифікати втулка auth exec не використовуються, гістограма не міститиме даних.
  • ALPHA
  • Histogram
rest_client_exec_plugin_ttl_seconds
Показник найкоротшого TTL (часу життя) клієнтських сертифікатів, якими керує втулок auth exec. Значення в секундах до закінчення терміну дії сертифіката (відʼємне, якщо термін дії вже закінчився). Якщо втулки auth exec не використовуються або не керують сертифікатами TLS, значення буде +INF.
  • ALPHA
  • Gauge
rest_client_rate_limiter_duration_seconds
Затримка обмежувача швидкості на стороні клієнта в секундах. Розбито за дієсловами та хостами.
  • ALPHA
  • Histogram
  • hostverb
rest_client_request_duration_seconds
Час затримки запиту в секундах. Розбито за дієсловами та хостами.
  • ALPHA
  • Histogram
  • hostverb
rest_client_request_retries_total
Кількість повторних спроб запиту, з розподілом за кодом статусу, дієсловом та хостом.
  • ALPHA
  • Counter
  • codehostverb
rest_client_request_size_bytes
Розмір запиту в байтах. Розбито за дієсловом та хостом.
  • ALPHA
  • Histogram
  • hostverb
rest_client_requests_total
Кількість HTTP-запитів, розділених за кодом статусу, методом та хостом.
  • ALPHA
  • Counter
  • codehostmethod
rest_client_response_size_bytes
Розмір відповіді в байтах. Розбито за дієсловом та хостом.
  • ALPHA
  • Histogram
  • hostverb
rest_client_transport_cache_entries
Кількість транспортних записів у внутрішньому кеші.
  • ALPHA
  • Gauge
rest_client_transport_create_calls_total
Кількість викликів для отримання нового транспорту, розділена за результатом операції hit: отримано з кешу, miss: створено та додано до кешу, uncacheable: створено та не кешовано
  • ALPHA
  • Counter
  • result
retroactive_storageclass_errors_total
Загальна кількість невдалих ретроактивних присвоєнь StorageClass до persistent volume claim
  • ALPHA
  • Counter
retroactive_storageclass_total
Загальна кількість ретроактивних присвоєнь StorageClass для persistent volume claim
  • ALPHA
  • Counter
root_ca_cert_publisher_sync_duration_seconds
Кількість синхронізацій просторів імен, що відбулися у видавця сертифікатів root ca.
  • ALPHA
  • Histogram
  • code
root_ca_cert_publisher_sync_total
Кількість синхронізацій просторів імен, що відбулися у видавця сертифікатів root ca.
  • ALPHA
  • Counter
  • code
running_managed_controllers
Показує, де зараз запущено екземпляри контролера
  • ALPHA
  • Gauge
  • managername
scheduler_goroutines
Кількість запущених підпрограм, розділених за роботою, яку вони виконують, наприклад, звʼязуванням.
  • ALPHA
  • Gauge
  • operation
scheduler_permit_wait_duration_seconds
Тривалість очікування на отримання дозволу.
  • ALPHA
  • Histogram
  • result
scheduler_plugin_evaluation_total
Кількість спроб запланувати Podʼи для кожного втулка і точки розширення (доступно тільки в PreFilter, Filter, PreScore і Score).
  • ALPHA
  • Counter
  • extension_pointpluginprofile
scheduler_plugin_execution_duration_seconds
Тривалість запуску втулка в певній точці розширення.
  • ALPHA
  • Histogram
  • extension_pointpluginstatus
scheduler_scheduler_cache_size
Кількість вузлів, Podʼів та передбачуваних (звʼязаних) Podʼів у кеші планувальника.
  • ALPHA
  • Gauge
  • type
scheduler_scheduling_algorithm_duration_seconds
Затримка алгоритму планування в секундах
  • ALPHA
  • Histogram
scheduler_unschedulable_pods
Кількість незапланованих Podʼів, розбитих за назвою втулка. Pod збільшує показник для всіх втулків, які спричинили його незапланованість, тому ця метрика має сенс лише у розбивці за втулками.
  • ALPHA
  • Gauge
  • pluginprofile
scheduler_volume_binder_cache_requests_total
Загальна кількість запитів кешу привʼязування томів
  • ALPHA
  • Counter
  • operation
scheduler_volume_scheduling_stage_error_total
Кількість помилок на етапі планування томів
  • ALPHA
  • Counter
  • operation
scrape_error
1, якщо виникла помилка при отриманні метрик контейнера, 0 в іншому випадку
  • ALPHA
  • Custom
  • 1.29.0
service_controller_loadbalancer_sync_total
Метрика, що підраховує кількість разів, коли був налаштований будь-який балансувальник навантаження, як наслідок зміни сервісу/вузла на кластері
  • ALPHA
  • Counter
service_controller_nodesync_error_total
Метрика, яка підраховує кількість разів, коли будь-який балансувальник навантаження був налаштований і помилявся, як наслідок зміни вузлів у кластері
  • ALPHA
  • Counter
service_controller_nodesync_latency_seconds
Метрика, що вимірює затримку синхронізації вузлів, яка оновлює хости балансувальника навантаження при оновленні вузлів кластера.
  • ALPHA
  • Histogram
service_controller_update_loadbalancer_host_latency_seconds
Метрика, що вимірює затримку оновлення кожного з хостів балансувальника навантаження.
  • ALPHA
  • Histogram
serviceaccount_invalid_legacy_auto_token_uses_total
Використання сукупних недійсних автоматично згенерованих застарілих токенів
  • ALPHA
  • Counter
serviceaccount_legacy_auto_token_uses_total
Використання сукупних автоматично згенерованих застарілих токенів
  • ALPHA
  • Counter
serviceaccount_legacy_manual_token_uses_total
Використання сукупних вручну створених застарілих токенів
  • ALPHA
  • Counter
serviceaccount_legacy_tokens_total
Використані токени застарілих службових облікових записів
  • ALPHA
  • Counter
serviceaccount_stale_tokens_total
Використані токени службових облікових записів з простроченим терміном придатності
  • ALPHA
  • Counter
serviceaccount_valid_tokens_total
Використання дійсних токенів проєцьованих службових облікових записів
  • ALPHA
  • Counter
storage_count_attachable_volumes_in_use
Підрахунок кількості використовуваних томів
  • ALPHA
  • Custom
  • nodevolume_plugin
storage_operation_duration_seconds
Тривалість операції зберігання
  • ALPHA
  • Histogram
  • migratedoperation_namestatusvolume_plugin
taint_eviction_controller_pod_deletion_duration_seconds
Затримка, в секундах, між моментом активації ефекту заплямування (taint) для Pod і його видаленням через TaintEvictionController.
  • ALPHA
  • Histogram
taint_eviction_controller_pod_deletions_total
Загальна кількість Podʼів, видалених TaintEvictionController з моменту його запуску.
  • ALPHA
  • Counter
ttl_after_finished_controller_job_deletion_duration_seconds
Час, необхідний для видалення завдання (job) з моменту, коли воно стало доступним для видалення
  • ALPHA
  • Histogram
volume_manager_selinux_container_errors_total
Кількість помилок, коли kubelet не може обчислити контекст SELinux для контейнера. Kubelet не зможе запустити такий Pod і спробує ще раз, тому значення цієї метрики може не відповідати дійсній кількості контейнерів.
  • ALPHA
  • Gauge
  • access_mode
volume_manager_selinux_container_warnings_total
Кількість помилок, коли kubelet не може обчислити контекст SELinux для контейнера, які ігноруються. Вони стануть справжніми помилками, коли функцію SELinuxMountReadWriteOncePod буде розширено на всі режими доступу до томів.
  • ALPHA
  • Gauge
  • access_mode
volume_manager_selinux_pod_context_mismatch_errors_total
Кількість помилок, коли Pod визначає різні контексти SELinux для своїх контейнерів, які використовують однаковий обʼєм. Kubelet не зможе запустити такий Pod і спробує ще раз, тому значення цієї метрики може не відповідати дійсній кількості Podʼів.
  • ALPHA
  • Gauge
  • access_mode
volume_manager_selinux_pod_context_mismatch_warnings_total
Кількість помилок, коли Pod визначає різні контексти SELinux для своїх контейнерів, які використовують той самий том. Це ще не помилки, але вони стануть справжніми помилками, коли можливість SELinuxMountReadWriteOncePod буде розширено на всі режими доступу до тома.
  • ALPHA
  • Gauge
  • access_mode
volume_manager_selinux_volume_context_mismatch_errors_total
Кількість помилок, коли Pod використовує том, який вже змонтовано з іншим контекстом SELinux, ніж потрібен Pod. Kubelet не зможе запустити такий Pod і повторити спробу, тому значення цієї метрики може не відповідати дійсній кількості Podʼів.
  • ALPHA
  • Gauge
  • access_modevolume_plugin
volume_manager_selinux_volume_context_mismatch_warnings_total
Кількість помилок, коли Pod використовує том, який вже змонтовано з іншим контекстом SELinux, ніж потрібен Pod. Це ще не помилки, але вони стануть справжніми помилками, коли функцію SELinuxMountReadWriteOncePod буде розширено на всі режими доступу до томів.
  • ALPHA
  • Gauge
  • access_modevolume_plugin
volume_manager_selinux_volumes_admitted_total
Кількість томів, контекст SELinux яких був нормальним і які буде змонтовано за допомогою параметра контексту mount -o.
  • ALPHA
  • Gauge
  • access_modevolume_plugin
volume_manager_total_volumes
Кількість томів у Volume Manager
  • ALPHA
  • Custom
  • plugin_namestate
volume_operation_total_errors
Всього помилок в роботі з томом
  • ALPHA
  • Counter
  • operation_nameplugin_name
volume_operation_total_seconds
Тривалість операції зберігання від початку до кінця в секундах
  • ALPHA
  • Histogram
  • operation_nameplugin_name
watch_cache_capacity
Загальний обсяг кешу watch, розбитий за типами ресурсів.
  • ALPHA
  • Gauge
  • resource
watch_cache_capacity_decrease_total
Загальна кількість подій зменшення ємності кешу watch, з розбивкою за типами ресурсів.
  • ALPHA
  • Counter
  • resource
watch_cache_capacity_increase_total
Загальна кількість подій збільшення ємності кешу watch, з розбивкою за типами ресурсів.
  • ALPHA
  • Counter
  • resource
workqueue_adds_total
Загальна кількість додавань, оброблених робочою чергою
  • ALPHA
  • Counter
  • name
workqueue_depth
Поточна глибина робочої черги
  • ALPHA
  • Gauge
  • name
workqueue_longest_running_processor_seconds
Скільки секунд працював найдовший процесор у черзі.
  • ALPHA
  • Gauge
  • name
workqueue_queue_duration_seconds
Скільки часу в секундах елемент перебуває в черзі до того, як його буде запитано.
  • ALPHA
  • Histogram
  • name
workqueue_retries_total
Загальна кількість повторних спроб, оброблених робочою чергою
  • ALPHA
  • Counter
  • name
workqueue_unfinished_work_seconds
Скільки секунд роботи було виконано, яка виконується і не спостерігається параметром work_duration. Великі значення вказують на застряглі потоки. Про кількість застряглих потоків можна зробити висновок, спостерігаючи за швидкістю, з якою цей показник зростає.
  • ALPHA
  • Gauge
  • name
workqueue_work_duration_seconds
Скільки часу в секундах займає обробка елемента з робочої черги.
  • ALPHA
  • Histogram
  • name

6.7 - Безпека та проблеми Kubernetes

6.7.1 - Трекер проблем Kubernetes

Для повідомлення про проблему безпеки використовуйте Процес розкриття інформації про безпеку в Kubernetes.

Робота з кодом Kubernetes та публічними проблемами відстежуватися за допомогою GitHub Issues.

Повідомлення про безпеку надсилаються у список розсилки kubernetes-security-announce@googlegroups.com.

6.7.2 - Процес розкриття інформації про безпеку в Kubernetes

Ця сторінка описує процес розкриття інформації про безпеку в Kubernetes.

Оголошення з питань безпеки

Приєднуйтесь до групи kubernetes-security-announce, щоб отримувати електронні листи щодо безпеки та основних оголошень API.

Повідомлення про вразливості

Ми дуже вдячні фахівцям з безпеки та користувачам, які повідомляють про вразливості Kubernetes Open Source Community. Всі звіти ретельно розглядаються командою волонтерів спільноти.

Для повідомлення про вразливість подайте свій звіт у Програму винагородження за виправлення помилок у Kubernetes. Це дозволяє класифікувати та обробляти вразливість за стандартизованими часовими рамками відповіді.

Ви також можете надіслати електронного листа на приватну адресу security@kubernetes.io з деталями щодо безпеки та необхідними деталями для всіх звітів про помилки Kubernetes.

Ви можете зашифрувати свій лист для цього списку за допомогою GPG-ключів членів комітету з питань реагування на загрози безпеці. Шифрування за допомогою GPG НЕ є обовʼязковим для повідомлення про проблеми з безпекою.

Коли потрібно повідомляти про вразливість?

  • Ви вважаєте, що виявили потенційну вразливість в Kubernetes
  • Ви не впевнені, як вразливість впливає на Kubernetes
  • Ви вважаєте, що виявили вразливість в іншому проєкті, від якого залежить Kubernetes
    • Для проєктів з власним процесом повідомлення про вразливості та розкриттям відповідних відомостей, будь ласка, повідомте про це безпосередньо туди

Коли НЕ потрібно повідомляти про вразливість?

  • Вам потрібна допомога у налаштуванні компонентів Kubernetes для безпеки
  • Вам потрібна допомога з застосуванням оновлень, повʼязаних з безпекою
  • Ваша проблема не стосується безпеки

Реагування на вразливості безпеки

Кожне повідомлення отримує відповідь та аналіз від членів комітету з питань реагування на загрози безпеці протягом 3 робочих днів. Це ініціює Security Release Process.

Будь-яка інформація про вразливість, що надходить до Комітету, залишається в проєкті Kubernetes і не буде розповсюджуватися до інших проєктів, якщо це необхідно для виправлення проблеми.

В міру того, як повідомлення про проблеми безпеки переходить з етапу попереднього розгляду, визначення шляхів виправлення та планування випуску, ми будемо тримати особу, що повідомила про проблему, в курсі подій.

Терміни оприлюднення інформації

Дата публічного оприлюднення узгоджується Комітетом з реагування на проблеми безпеки Kubernetes та автором повідомлення про ваду. Ми надаємо перевагу повному розкриттю вади якомога швидше, як тільки користувачеві буде доступне рішення для її усунення. Доцільно затримати розкриття, коли помилка або виправлення ще не до кінця зрозумілі, рішення ще не добре протестоване, або для узгодження з постачальником. Часові рамки для розкриття інформації — від негайного (особливо якщо вона вже відома загалу) до декількох тижнів. Для вразливостей, які легко усунути, ми очікуємо, що від дати повідомлення до дати розкриття буде близько 7 днів. Комітет з реагування на вразливості Kubernetes має вирішальне слово при встановленні дати оприлюднення.

6.7.3 - Офіційний список CVE

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.27 [beta]

Це список офіційних CVE, оголошених Комітетом з питань реагування на загрози безпеці Kubernetes. Детальніше дивіться в Процес розкриття інформації про безпеку в Kubernetes.

Проєкт Kubernetes публікує програмно доступний потік опублікованих проблем безпеки у форматах JSON feed та RSS feed. Ви можете отримати до них доступ, виконавши наступні команди:

Посилання на формат JSON

curl -Lv https://k8s.io/docs/reference/issues-security/official-cve-feed/index.json

Посилання на формат RSS

curl -Lv https://k8s.io/docs/reference/issues-security/official-cve-feed/feed.xml
Офіційний перелік Kubernetes CVE (оновлено: 19 вер. 2024 18:46:33 UTC)
CVE IDОпис проблемиCVE на GitHub
CVE-2024-7646Ingress-nginx Annotation Validation Bypass#126744
CVE-2024-5321Incorrect permissions on Windows containers logs#126161
CVE-2024-3744azure-file-csi-driver discloses service account tokens in logs#124759
CVE-2024-3177Bypassing mountable secrets policy imposed by the ServiceAccount admission plugin#124336
CVE-2023-5528Insufficient input sanitization in in-tree storage plugin leads to privilege escalation on Windows nodes#121879
CVE-2023-5044Code injection via nginx.ingress.kubernetes.io/permanent-redirect annotation#126817
CVE-2023-5043Ingress nginx annotation injection causes arbitrary command execution#126816
CVE-2022-4886ingress-nginx path sanitization can be bypassed#126815
CVE-2023-3955Insufficient input sanitization on Windows nodes leads to privilege escalation#119595
CVE-2023-3893Insufficient input sanitization on kubernetes-csi-proxy leads to privilege escalation#119594
CVE-2023-3676Insufficient input sanitization on Windows nodes leads to privilege escalation#119339
CVE-2023-2431Bypass of seccomp profile enforcement#118690
CVE-2023-2728Bypassing policies imposed by the ImagePolicyWebhook and bypassing mountable secrets policy imposed by the ServiceAccount admission plugin#118640
CVE-2023-2727Bypassing policies imposed by the ImagePolicyWebhook and bypassing mountable secrets policy imposed by the ServiceAccount admission plugin#118640
CVE-2023-2878secrets-store-csi-driver discloses service account tokens in logs#118419
CVE-2022-3294Node address isn't always verified when proxying#113757
CVE-2022-3162Unauthorized read of Custom Resources#113756
CVE-2022-3172Aggregated API server can cause clients to be redirected (SSRF)#112513
CVE-2021-25749`runAsNonRoot` logic bypass for Windows containers#112192
CVE-2021-25748Ingress-nginx `path` sanitization can be bypassed with newline character#126814
CVE-2021-25746Ingress-nginx directive injection via annotations#126813
CVE-2021-25745Ingress-nginx `path` can be pointed to service account token file#126812
CVE-2021-25742Ingress-nginx custom snippets allows retrieval of ingress-nginx serviceaccount token and secrets across all namespaces#126811
CVE-2021-25741Symlink Exchange Can Allow Host Filesystem Access#104980
CVE-2021-25737Holes in EndpointSlice Validation Enable Host Network Hijack#102106
CVE-2021-3121Processes may panic upon receipt of malicious protobuf messages#101435
CVE-2021-25735Validating Admission Webhook does not observe some previous fields#100096
CVE-2020-8554Man in the middle using LoadBalancer or ExternalIPs#97076
CVE-2020-8566Ceph RBD adminSecrets exposed in logs when loglevel >= 4#95624
CVE-2020-8565Incomplete fix for CVE-2019-11250 allows for token leak in logs when logLevel >= 9#95623
CVE-2020-8564Docker config secrets leaked when file is malformed and log level >= 4#95622
CVE-2020-8563Secret leaks in kube-controller-manager when using vSphere provider#95621
CVE-2020-8557Node disk DOS by writing to container /etc/hosts#93032
CVE-2020-8559Privilege escalation from compromised node to cluster#92914
CVE-2020-8558Node setting allows for neighboring hosts to bypass localhost boundary#92315
CVE-2020-8555Half-Blind SSRF in kube-controller-manager#91542
CVE-2020-10749IPv4 only clusters susceptible to MitM attacks via IPv6 rogue router advertisements#91507
CVE-2019-11254kube-apiserver Denial of Service vulnerability from malicious YAML payloads#89535
CVE-2020-8552apiserver DoS (oom)#89378
CVE-2020-8551Kubelet DoS via API#89377
CVE-2020-8553ingress-nginx auth-type basic annotation vulnerability#126818
CVE-2019-11251kubectl cp symlink vulnerability#87773
CVE-2018-1002102Unvalidated redirect#85867
CVE-2019-11255CSI volume snapshot, cloning and resizing features can result in unauthorized volume data access or mutation#85233
CVE-2019-11253Kubernetes API Server JSON/YAML parsing vulnerable to resource exhaustion attack#83253
CVE-2019-11250Bearer tokens are revealed in logs#81114
CVE-2019-11248/debug/pprof exposed on kubelet's healthz port#81023
CVE-2019-11249Incomplete fixes for CVE-2019-1002101 and CVE-2019-11246, kubectl cp potential directory traversal#80984
CVE-2019-11247API server allows access to custom resources via wrong scope#80983
CVE-2019-11245container uid changes to root after first restart or if image is already pulled to the node#78308
CVE-2019-11243rest.AnonymousClientConfig() does not remove the serviceaccount credentials from config created by rest.InClusterConfig()#76797
CVE-2019-11244`kubectl:-http-cache=<world-accessible dir>` creates world-writeable cached schema files#76676
CVE-2019-1002100json-patch requests can exhaust apiserver resources#74534
CVE-2018-1002105proxy request handling in kube-apiserver can leave vulnerable TCP connections#71411
CVE-2018-1002101smb mount security issue#65750
CVE-2018-1002100Kubectl copy doesn't check for paths outside of it's destination directory.#61297
CVE-2017-1002102atomic writer volume handling allows arbitrary file deletion in host filesystem#60814
CVE-2017-1002101subpath volume mount handling allows arbitrary file access in host filesystem#60813
CVE-2017-1002100Azure PV should be Private scope not Container scope#47611
CVE-2017-1000056PodSecurityPolicy admission plugin authorizes incorrectly#43459

Цей потік автоматично оновлюється з помітними, але невеликими затримками (від хвилин до годин) від моменту оголошення CVE до доступу до нього у цьому потоці.

Джерелом інформації для цього потоку є набір GitHub Issues, відфільтрованих за міткою official-cve-feed. Сирі дані зберігаються у сховищі Google Cloud, до якого мають доступ лише декілька довірених членів спільноти.

6.8 - Довідкова інформація про вузли

У цьому розділі містяться наступні теми про вузли:

Ви також можете ознайомитись з довідкою про вузли в інших розділах документації Kubernetes, зокрема:

6.8.1 - Kubelet Checkpoint API

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.30 [beta]

Контрольна точка контейнера — це функціонал для створення копії контейнера зі станом запущеного контейнера. Після того, як у вас є копія контейнера з його станом, ви можете перенести його на інший компʼютер для налагодження або подібних цілей.

Якщо перемістити дані такої копії контейнера на компʼютер, здатний їх відновити, відновлений контейнер продовжить працювати точно з того самого місця, де він був зупинений. Також можна переглянути збережені дані, за умови, що є відповідні інструменти для цього.

Створення копії контейнера зі станом може мати наслідки для безпеки. Зазвичай така копія містить усі сторінки памʼяті всіх процесів у контейнері. Це означає, що все, що колись було в памʼяті, тепер доступне на локальному диску. Це включає всі приватні дані та можливі ключі, які використовувались для шифрування. Реалізації CRI повинні створювати архів копії зі збереженням стану таким чином, щоб до нього міг мати доступ лише користувач root. Важливо памʼятати, що якщо архів копії зі збереженням стану передається в іншу систему, усі сторінки памʼяті будуть доступні власнику архіву копії.

Операції

post створення копії зі збереженням стану вказаного контейнера

Дайте команду kubelet створити копію зі збереженням стану конкретного контейнера з вказаного Pod.

Для отримання додаткової інформації щодо керування доступом до інтерфейсу контролю kubelet дивіться довідку з автентифікації/авторизації kubelet.

Kubelet запитає контрольну точку у відповідного CRI. У запиті до контрольної точки kubelet вкаже імʼя архіву контрольної точки у вигляді checkpoint-<podFullName>-<containerName>-<timestamp>.tar, а також попросить зберігати архів контрольних точок у теці checkpoints в його кореневій теці (як визначено параметром --root-dir). Типово це буде /var/lib/kubelet/checkpoints.

Архів копії зі збереженням стану має формат tar і може бути переглянутий за допомогою реалізації tar. Вміст архіву залежить від реалізації CRI (інтерфейс запуску контейнерів на вузлі).

HTTP-запит

POST /checkpoint/{namespace}/{pod}/{container}

Параметри

  • namespace (в шляху): string, обовʼязково

    Namespace
  • pod (в шляху): string, обовʼязково

    Pod
  • container (в шляху): string, обовʼязково

    Контейнер
  • timeout (в запиті): integer

    Тайм-аут у секундах для очікування завершення створення копії зі збереженням стану. Якщо вказано нуль або тайм-аут не вказано, буде використане стандартне значення тайм-ауту для CRI. Час створення копії зі збереженням стану залежить безпосередньо від використаної памʼяті контейнера. Чим більше памʼяті використовує контейнер, тим більше часу потрібно для створення відповідної копії зі збереженням стану.

Відповідь

200: OK

401: Unauthorized

404: Not Found (якщо функціональні можливості ContainerCheckpoint відключено)

404: Not Found (якщо вказаний namespace, pod або container не може бути знайдено)

500: Internal Server Error (якщо реалізація CRI стикається з помилкою під час створення копії зі збереженням стану (див. повідомлення про помилку для деталей))

500: Internal Server Error (якщо реалізація CRI не реалізує API створення контейнера (див. повідомлення про помилку для деталей))

6.8.2 - Вимоги до версії ядра Linux

Багато функцій залежать від певних можливостей ядра і мають мінімальні вимоги до версії ядра. Однак покладатися лише на номери версій ядра може бути недостатньо для деяких операційних систем, оскільки підтримувачі дистрибутивів таких як RHEL, Ubuntu та SUSE часто зворотно переносять вибрані функції до старіших версій ядра (залишаючи старішу версію ядра).

Pod sysctls

У Linux системний виклик sysctl() налаштовує параметри ядра під час виконання. Є інструмент командного рядка з назвою sysctl, який можна використовувати для налаштування цих параметрів, і багато з них доступні через файлову систему proc.

Деякі sysctls доступні лише за наявності достатньо нової версії ядра.

Наступні sysctls мають мінімальні вимоги до версії ядра і підтримуються в безпечному наборі:

  • net.ipv4.ip_local_reserved_ports (з Kubernetes 1.27, потребує ядро 3.16+);
  • net.ipv4.tcp_keepalive_time (з Kubernetes 1.29, потребує ядро 4.5+);
  • net.ipv4.tcp_fin_timeout (з Kubernetes 1.29, потребує ядро 4.6+);
  • net.ipv4.tcp_keepalive_intvl (з Kubernetes 1.29, потребує ядро 4.5+);
  • net.ipv4.tcp_keepalive_probes (з Kubernetes 1.29, потребує ядро 4.5+);
  • net.ipv4.tcp_syncookies (з ізоляцією в просторі імен з ядра 4.6+);
  • net.ipv4.vs.conn_reuse_mode (використовується в режимі проксі ipvs, потребує ядро 4.1+);

Режим проксі nftables в kube-proxy

Для Kubernetes 1.31, режим nftables у kube-proxy вимагає версії 1.0.1 або новішої версії інструменту командного рядка nft, а також ядра 5.13 або новішого.

Для тестування та розробки можна використовувати старіші ядра, аж до 5.4, якщо встановити опцію nftables.skipKernelVersionCheck у конфігурації kube-proxy. Але це не рекомендується в операційній діяльності, оскільки це може викликати проблеми з іншими користувачами nftables у системі.

Контрольні групи версії 2

Підтримка cgroup v1 у Kubernetes перебуває в режимі супроводу, починаючи з версії Kubernetes v1.31; рекомендовано використовувати cgroup v2. У Linux 5.8, файл системного рівня cpu.stat був доданий до кореневої cgroup для зручності.

У документації runc, ядра старіші за 5.2 не рекомендуються через відсутність підтримки freezer.

Інші вимоги до ядра

Деякі функції можуть залежати від нових можливостей ядра і мати конкретні вимоги до ядра:

  1. Рекурсивне монтування в режимі тільки для читання: Реалізується шляхом застосування атрибута MOUNT_ATTR_RDONLY із прапором AT_RECURSIVE, використовуючи mount_setattr(2), доданий у ядрі Linux v5.12.
  2. Підтримка простору імен користувачів в Pod вимагає мінімальної версії ядра 6.5+, згідно з KEP-127.
  3. Для swap на рівні вузлів не підтримується tmpfs, встановлений як noswap, до версії ядра 6.3.

Довгострокова підтримка ядра Linux

Актуальні випуски ядра можна знайти на kernel.org.

Зазвичай існує кілька випусків ядра з довгостроковою підтримкою, які забезпечують зворотне перенесення виправлень для старіших версій ядра. До таких ядер застосовуються лише важливі виправлення помилок, і вони зазвичай виходять не дуже часто, особливо для старіших версій. Перегляньте список випусків на вебсайті ядра Linux в розділі Longterm.

Що далі

  • Перегляньте sysctls для отримання додаткової інформації.
  • Дозвольте запуск kube-proxy у режимі nftables.
  • Дізнайтесь більше про cgroups v2.

6.8.3 - Статті про видалення dockershim та використання сумісних з CRI середовищ виконання

Це список статей й інших сторінок, що стосуються видалення dockershim у Kubernetes та використання сумісних з CRI контейнерних середовищ виконання у звʼязку з цим видаленням.

Проєкт Kubernetes

Можна надати відгуки через тікет GitHub Відгуки та проблеми видалення Dockershim (k/kubernetes/#106917).

Зовнішні джерела

6.8.4 - Мітки вузлів, які заповнює kubelet

Вузли Kubernetes мають попередньо встановлений набір міток.

Ви також можете встановлювати власні мітки на вузлах, як через конфігурацію kubelet, так і використовуючи API Kubernetes.

Попередньо встановлені мітки

Попередньо встановлені мітки, які Kubernetes встановлює на вузли:

Що далі

6.8.5 - Версії API Kubelet Device Manager

Ця сторінка надає інформацію про сумісність між API втулків пристроїв Kubernetes та різними версіями самого Kubernetes.

Матриця сумісності

v1alpha1v1beta1
Kubernetes 1.21-
Kubernetes 1.22-
Kubernetes 1.23-
Kubernetes 1.24-
Kubernetes 1.25-
Kubernetes 1.26-

Позначення:

  • Точно такі ж функції / обʼєкти API в обох, API втулка пристроїв та версії Kubernetes.
  • + API втулка пристроїв має функції або обʼєкти API, яких може не бути в кластері Kubernetes, або через те, що API втулка пристроїв додало додаткові нові виклики API, або через те, що сервер видалив старий виклик API. Однак, все, що у них є спільного (більшість інших API), працюватиме. Зверніть увагу, що альфа-версії API можуть зникнути або значно змінитися між незначними релізами.
  • - Кластер Kubernetes має функції, які не може використовувати API втулка пристроїв, або через те, що сервер додав додаткові виклики API, або через те, що API втулка пристроїв видалило старий виклик API. Однак, все, що у них є спільного (більшість API), працюватиме.

6.8.6 - Обʼєднання конфігураційних тек Kubelet

Коли використовується прапорець kubelet --config-dir для вказівки теки для конфігурації, існує певна специфічна поведінка для обʼєднання різних типів.

Ось кілька прикладів того, як різні типи даних поводяться під час обʼєднання конфігурації:

Поля структур

У YAML структурі є два типи полів структури: одиничні (або скалярні типи) та вбудовані (структури, що містять скалярні типи). Процес обʼєднання конфігурацій обробляє заміну одиничних та вбудованих полів структур для створення кінцевої конфігурації kubelet.

Наприклад, ви можете хотіти мати базову конфігурацію kubelet для всіх вузлів, але налаштувати поля address і authorization. Це можна зробити наступним чином:

Зміст основного файлу конфігурації kubelet:

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
port: 20250
authorization:
  mode: Webhook
  webhook:
    cacheAuthorizedTTL: "5m"
    cacheUnauthorizedTTL: "30s"
serializeImagePulls: false
address: "192.168.0.1"

Зміст файлу у теці --config-dir:

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
authorization:
  mode: AlwaysAllow
  webhook:
    cacheAuthorizedTTL: "8m"
    cacheUnauthorizedTTL: "45s"
address: "192.168.0.8"

Кінцева конфігурація буде виглядати наступним чином:

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
port: 20250
serializeImagePulls: false
authorization:
  mode: AlwaysAllow
  webhook:
    cacheAuthorizedTTL: "8m"
    cacheUnauthorizedTTL: "45s"
address: "192.168.0.8"

Списки

Ви можете замінити значення списків конфігурації kubelet. Однак весь список буде замінений під час процесу обʼєднання. Наприклад, ви можете замінити список clusterDNS наступним чином:

Зміст основного файлу конфігурації kubelet:

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
port: 20250
serializeImagePulls: false
clusterDNS:
  - "192.168.0.9"
  - "192.168.0.8"

Зміст файлу у теці --config-dir:

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
clusterDNS:
  - "192.168.0.2"
  - "192.168.0.3"
  - "192.168.0.5"

Кінцева конфігурація буде виглядати наступним чином:

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
port: 20250
serializeImagePulls: false
clusterDNS:
  - "192.168.0.2"
  - "192.168.0.3"
  - "192.168.0.5"

Map, включаючи вкладені структури

Індивідуальні поля в map, незалежно від їх типів значень (булеві, рядкові тощо), можуть бути вибірково замінені. Однак для map[string][]string весь список, повʼязаний з певним полем, буде замінений. Розглянемо це детальніше на прикладі, зокрема для таких полів, як featureGates і staticPodURLHeader:

Зміст основного файлу конфігурації kubelet:

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
port: 20250
serializeImagePulls: false
featureGates:
  AllAlpha: false
  MemoryQoS: true
staticPodURLHeader:
  kubelet-api-support:
  - "Authorization: 234APSDFA"
  - "X-Custom-Header: 123"
  custom-static-pod:
  - "Authorization: 223EWRWER"
  - "X-Custom-Header: 456"

Зміст файлу у теці --config-dir:

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
featureGates:
  MemoryQoS: false
  KubeletTracing: true
  DynamicResourceAllocation: true
staticPodURLHeader:
  custom-static-pod:
  - "Authorization: 223EWRWER"
  - "X-Custom-Header: 345"

Кінцева конфігурація буде виглядати наступним чином:

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
port: 20250
serializeImagePulls: false
featureGates:
  AllAlpha: false
  MemoryQoS: false
  KubeletTracing: true
  DynamicResourceAllocation: true
staticPodURLHeader:
  kubelet-api-support:
  - "Authorization: 234APSDFA"
  - "X-Custom-Header: 123"
  custom-static-pod:
  - "Authorization: 223EWRWER"
  - "X-Custom-Header: 345"

6.8.7 - Стан вузла

Стан вузла у Kubernetes є критичним аспектом управління кластером Kubernetes. У цій статті ми розглянемо основи моніторингу та підтримки стану вузлів, щоб забезпечити справний та стабільний кластер.

Поля стану вузла

Стан вузла містить наступну інформацію:

Ви можете використовувати команду kubectl для перегляду стану вузла та інших деталей:

kubectl describe node <insert-node-name-here>

Кожен розділ вихідних даних описано нижче.

Адреси

Використання цих полів варіюється залежно від вашого постачальника хмарних послуг або конфігурації на голому залізі.

  • HostName: Імʼя хосту, яке повідомляється ядром вузла. Може бути перевизначене за допомогою параметра kubelet --hostname-override.
  • ExternalIP: Як правило, це IP-адреса вузла, яка доступна ззовні кластера.
  • InternalIP: Як правило, це IP-адреса вузла, яка доступна лише всередині кластера.

Стани

Поле conditions описує стан усіх Running вузлів. Прикладами умов є:

Стан вузлів та опис, коли кожен стан застосовується.
Умова вузлаОпис
ReadyTrue, якщо вузол справний та готовий приймати Podʼи, False, якщо вузол не справний і не приймає Podʼи, та Unknown, якщо контролер вузла не отримав інформацію від вузла протягом останнього node-monitor-grace-period (стандартно 40 секунд)
DiskPressureTrue, якщо є тиск на розмір диска, тобто якщо місткість диска низька; інакше False
MemoryPressureTrue, якщо є тиск на памʼять вузла, тобто якщо памʼять вузла низька; інакше False
PIDPressureTrue, якщо є тиск на процеси, тобто якщо на вузлі занадто багато процесів; інакше False
NetworkUnavailableTrue, якщо мережа для вузла неправильно налаштована, інакше False

В API Kubernetes стан вузла представлений як частина .status ресурсу Node. Наприклад, наступна структура JSON описує справний вузол:

"conditions": [
  {
    "type": "Ready",
    "status": "True",
    "reason": "KubeletReady",
    "message": "kubelet is posting ready status",
    "lastHeartbeatTime": "2019-06-05T18:38:35Z",
    "lastTransitionTime": "2019-06-05T11:41:27Z"
  }
]

Коли на вузлах виникають проблеми, панель управління Kubernetes автоматично створює taints, які відповідають станам, що впливають на вузол. Прикладом цього є ситуація, коли status стану Ready залишається Unknown або False довше, ніж налаштований інтервал NodeMonitorGracePeriod у kube-controller-manager, який стандартно становить 40 секунд. Це спричинить додавання на вузол taint node.kubernetes.io/unreachable для статусу Unknown або taint node.kubernetes.io/not-ready для статусу False.

Ці taints впливають на Podʼи, що перебувають в очікуванні, оскільки планувальник враховує taints вузла при призначенні Podʼів на вузол. Наявні Podʼи, заплановані на вузол, можуть бути виселені через застосування taints типу NoExecute. Podʼи також можуть мати tolerations, що дозволяє їм бути запланованими та продовжувати працювати на вузлі, навіть якщо на ньому є певний taint.

Дивіться Виселення на основі taint та Taint вузлів за станами для отримання додаткової інформації.

Місткість та Доступність

Описує ресурси, доступні на вузлі: процесор, памʼять та максимальну кількість Podʼів, які можуть бути заплановані на вузлі.

Поля у блоці місткості вказують на загальну кількість ресурсів, які має вузол. Блок доступності вказує на кількість ресурсів на вузлі, які доступні для використання звичайними подами.

Ви можете дізнатися більше про місткість та доступність ресурсів, дізнаючись, як зарезервувати обчислювальні ресурси на вузлі.

Інформація

Описує загальну інформацію про вузол, таку як версія ядра, версія Kubernetes (kubelet і kube-proxy), деталі контейнерного середовища та яка операційна система використовується на вузлі. Kubelet збирає цю інформацію з вузла та публікує її в API Kubernetes.

Пульс

Пульс, що надсилається вузлами Kubernetes, допомагають вашому кластеру визначити доступність кожного вузла та вжити заходів у разі виявлення збоїв.

Для вузлів існує дві форми пульсу:

  • оновлення .status вузла
  • обʼєкти Lease у просторі імен kube-node-lease. Кожен вузол має повʼязаний обʼєкт Lease.

Порівняно з оновленнями .status вузла, Lease є легким ресурсом. Використання Lease для пульсу знижує вплив цих оновлень на продуктивність для великих кластерів.

Kubelet відповідає за створення та оновлення .status вузлів, а також за оновлення їх повʼязаних Lease.

  • Kubelet оновлює .status вузла або коли стан змінюється, або якщо не було оновлень протягом налаштованого інтервалу. Стандартний інтервал для оновлень .status вузлів становить 5 хвилин, що значно довше, ніж типових 40 секунд для вузлів, що стали недоступними.
  • Kubelet створює та оновлює свій обʼєкт Lease кожні 10 секунд (стандартний інтервал оновлення). Оновлення Lease відбуваються незалежно від оновлень .status вузла. Якщо оновлення Lease не вдається, Kubelet повторює спробу, використовуючи експоненціальне збільшення інтервалу з початкового 200 мілісекунд до максимально 7 секунд.

6.9 - Довідник з мережі

Цей розділ документації Kubernetes містить деталі про використання мережі в Kubernetes.

6.9.1 - Протоколи Service

Якщо ви налаштовуєте Service, ви можете обрати будь-який мережевий протокол, що підтримується Kubernetes.

Kubernetes підтримує наступні протоколи для Service:

Коли ви визначаєте Service, ви також можете вказати протокол застосунку, який він використовує.

Цей документ описує деякі особливі випадки, всі з яких зазвичай використовують TCP як транспортний протокол:

Підтримувані протоколи

Існує 3 допустимі значення для protocol порту Service:

SCTP

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.20 [stable]

При використанні втулка мережі, що підтримує SCTP-трафік, ви можете використовувати SCTP для більшості Service. Для Service типу LoadBalancer підтримка SCTP залежить від можливості постачальника хмарних послуг надавати цю функцію. (Більшість не підтримують).

SCTP не підтримується на вузлах, що працюють під управлінням Windows.

Підтримка багатодомашніх SCTP-асоціацій

Підтримка багатодомашніх SCTP-асоціацій вимагає, щоб втулок CNI міг підтримувати призначення декількох інтерфейсів та IP-адрес для Podʼів.

NAT для багатодомашніх SCTP-асоціацій вимагає спеціальної логіки у відповідних модулях ядра.

TCP

Ви можете використовувати TCP для будь-якого виду Service, і це стандартний протокол.

UDP

Ви можете використовувати UDP для більшості Service. Для Service типу LoadBalancer підтримка UDP залежить від можливості постачальника хмарних послуг надавати цю функцію.

Особливі випадки

HTTP

Якщо ваш постачальник хмарних послуг підтримує це, ви можете використовувати Service у режимі LoadBalancer для налаштування балансувальника навантаження поза межами вашого кластера Kubernetes у спеціальному режимі, де балансувальник навантаження вашого постачальника хмарних послуг реалізує зворотнє проксіювання трафіку HTTP / HTTPS, з перенаправленням трафіку на бекенд-точки доступу для цього Service.

Зазвичай, ви встановлюєте протокол для Service як TCP і додаєте анотацію (зазвичай специфічну для вашого постачальника хмарних послуг), яка налаштовує балансувальник навантаження для обробки трафіку на рівні HTTP. Ця конфігурація може також включати обслуговування HTTPS (HTTP через TLS) та зворотнє проксіювання plain HTTP до вашого навантаження.

Ви можете додатково вказати, що протокол застосунку зʼєднання є http або https. Використовуйте http, якщо сесія від балансувальника навантаження до вашого навантаження є HTTP без TLS, та використовуйте https, якщо сесія від балансувальника навантаження до вашого навантаження використовує TLS-шифрування.

PROXY protocol

Якщо ваш постачальник хмарних послуг підтримує це, ви можете використовувати Service із типом LoadBalancer для налаштування балансувальника навантаження поза межами самого Kubernetes, який буде перенаправляти зʼєднання, обгорнуті у PROXY protocol.

Балансувальник навантаження тоді надсилає початкову серію октетів, що описують вхідне зʼєднання, схоже на цей приклад (PROXY protocol v1):

PROXY TCP4 192.0.2.202 10.0.42.7 12345 7\r\n

Дані після проксі-протоколу є оригінальними даними від клієнта. Коли будь-яка сторона закриває зʼєднання, балансувальник навантаження також ініціює закриття зʼєднання та надсилає будь-які залишкові дані, якщо це можливо.

Зазвичай, ви визначаєте Service із протоколом TCP. Ви також встановлюєте анотацію, специфічну для вашого постачальника хмарних послуг, яка налаштовує балансувальник навантаження обгортати кожне вхідне зʼєднання у PROXY протокол.

TLS

Якщо ваш постачальник хмарних послуг підтримує це, ви можете використовувати Service із типом LoadBalancer як спосіб налаштування зовнішнього зворотного проксіювання, де зʼєднання від клієнта до балансувальника навантаження зашифроване за допомогою TLS, а балансувальник навантаження виступає як TLS-сервер. Зʼєднання від балансувальника навантаження до вашого навантаження також може бути TLS, або може бути plain text. Точні варіанти залежать від вашого постачальника хмарних послуг або користувацької реалізації Service.

Зазвичай, ви встановлюєте протокол як TCP та встановлюєте анотацію (зазвичай специфічну для вашого постачальника хмарних послуг), яка налаштовує балансувальник навантаження виступати як TLS-сервер. Ви б налаштовували TLS-ідентифікацію (як сервер, та можливо також як клієнт, який підключається до вашого навантаження) за допомогою механізмів, специфічних для вашого постачальника хмарних послуг.

6.9.2 - Порти та Протоколи

При запуску Kubernetes у середовищі зі строгими мережевими межами, такими як локальний дата-центр із фізичними мережевими фаєрволами або віртуальні мережі у публічній хмарі, корисно знати про порти та протоколи, які використовують компоненти Kubernetes.

Панель управління

ПротоколНапрямокДіапазон портівПризначенняВикористовується
TCPВхідний6443Kubernetes API серверУсі
TCPВхідний2379-2380etcd server client APIkube-apiserver, etcd
TCPВхідний10250Kubelet APIВласний, Панель управління
TCPВхідний10259kube-schedulerВласний
TCPВхідний10257kube-controller-managerВласний

Хоча порти etcd включені до секції контрольної площини, ви також можете розмістити свій власний кластер etcd зовнішньо або на користувацьких портах.

Робочі вузли

ПротоколНапрямокДіапазон портівПризначенняВикористовується
TCPВхідний10250Kubelet APIВласний, Панель управління
TCPВхідний10256kube-proxyВласний, Балансувальники навантаження
TCPВхідний30000-32767NodePort Сервіси†Усі

† Типовий діапазон портів для NodePort Services.

Усі типові номери портів можуть бути змінені. Коли використовуються власні порти, ці порти повинні бути відкриті замість вказаних тут типових.

Одним із поширених прикладів є порт API сервера, який іноді змінюється на 443. Альтернативно, типовий порт залишається без змін, а API сервер розміщується за балансувальником навантаження, який слухає на 443 та направляє запити до API сервера на типовий порт.

6.9.3 - Віртуальні IP та Проксі для Service

Кожен вузол у кластері Kubernetes запускає компонент kube-proxy (якщо ви не розгорнули власний альтернативний компонент замість kube-proxy).

Компонент kube-proxy відповідає за реалізацію механізму віртуальних IP для Service типу відмінного від ExternalName. Кожен екземпляр kube-proxy відстежує додавання та видалення обʼєктів Service and EndpointSlice у панелі управління. Для кожного сервісу kube-proxy викликає відповідні API (залежно від режиму kube-proxy) для налаштування вузла для перехоплення трафіку на clusterIP та port сервісу, і перенаправляє цей трафік на одну з точок доступу Service (зазвичай це Pod, але можливо також будь-яка інша IP-адреса, надана користувачем). Цикл керування забезпечує, що правила на кожному вузлі надійно синхронізуються зі станом Service та EndpointSlice, вказаним API сервером.

Механізм віртуальних IP для Service, використовуючи режим iptables

Інколи виникає питання, чому Kubernetes покладається на проксіювання для пересилання вхідного трафіку до бекендів. Що щодо інших підходів? Наприклад, чи можливо налаштувати DNS-записи, які мають кілька A-значень (або AAAA для IPv6), і покладатися на розвʼязання імен по колу?

Є кілька причин для використання проксіювання для Service:

  • Існує довга історія реалізацій DNS, які не дотримуються TTL записів та кешують результати пошуку імен після закінчення терміну їх дії.
  • Деякі програми виконують пошук DNS лише один раз і кешують результати безстроково.
  • Навіть якщо програми та бібліотеки виконували правильне повторне розвʼязування, низькі або нульові TTL для DNS-записів можуть накладати високі навантаження на DNS, якими стає важко керувати.

Далі на цій сторінці ви можете прочитати про те, як працюють різні реалізації kube-proxy. В цілому, слід зазначити, що при запуску kube-proxy можуть бути змінені правила на рівні ядра (наприклад, можуть бути створені правила iptables), які не будуть очищені, в деяких випадках, до перезавантаження. Отже, запуск kube-proxy повинен здійснюватися тільки адміністратором, який розуміє наслідки наявності низькорівневого, привілейованого мережевого проксі-сервісу на компʼютері. Хоча виконуваний файл kube-proxy підтримує функцію cleanup, ця функція не є офіційною і тому доступна лише для використання "як є".

Деякі деталі у цьому довіднику стосуються прикладу: бекенд Pod для stateless навантаження з обробки образів, що працює з трьома репліками. Ці репліки замінні — фронтенди не турбує, який бекенд вони використовують. Хоча фактичні Podʼи, що складають бекенд-набір, можуть змінюватися, клієнти фронтенду не повинні бути обізнані про це і не повинні відстежувати набір бекендів самостійно.

Режими проксі

kube-proxy запускається в різних режимах, які визначаються його конфігурацією.

На Linux вузлах доступні режими для kube-proxy такі:

iptables
Режим, в якому kube-proxy налаштовує правила пересилання пакетів за допомогою iptables.
ipvs
Режим, в якому kube-proxy налаштовує правила пересилання пакетів за допомогою ipvs.
nftables
Режим, в якому kube-proxy налаштовує правила пересилання пакетів за допомогою nftables.

У Windows доступний лише один режим для kube-proxy:

kernelspace
Режим, в якому kube-proxy налаштовує правила пересилання пакетів у ядрі Windows.

Режим проксі iptables

Цей режим проксі доступний лише на вузлах Linux.

У цьому режимі kube-proxy налаштовує правила пересилання пакетів за допомогою API iptables підсистеми netfilter ядра. Для кожної точки доступу він встановлює правила iptables, які типово випадково вибирають бекенд Pod.

Приклад

Як приклад, розглянемо програму обробки образів, описану раніше на сторінці. Коли створюється бекенд Service, панель управління Kubernetes призначає віртуальну IP-адресу, наприклад, 10.0.0.1. Для цього прикладу припустимо, що порт Service — 1234. Усі екземпляри kube-proxy у кластері спостерігають за створенням нового Service.

Коли kube-proxy на вузлі бачить новий Service, він встановлює серію правил iptables, які перенаправляють з віртуальної IP-адреси на додаткові правила iptables, визначені для кожного Service. Правила для кожного Service посилаються на інші правила для кожної точки доступу бекенду, а правила для кожної точки доступу перенаправляють трафік (використовуючи NAT призначення) до бекендів.

Коли клієнт підключається до віртуальної IP-адреси Service, вступає в дію правило iptables. Вибирається бекенд (або на основі спорідненості сесії, або випадково), і пакети перенаправляються до бекенду без переписування IP-адреси клієнта.

Цей самий основний потік виконується, коли трафік надходить через node-port або через балансувальник навантаження, хоча в цих випадках IP-адреса клієнта змінюється.

Оптимізація продуктивності режиму iptables

У режимі iptables, kube-proxy створює кілька правил iptables для кожного Service та кілька правил iptables для кожної IP-адреси точки доступу. У кластерах з десятками тисяч Podʼів та Service це означає десятки тисяч правил iptables, і kube-proxy може потребувати багато часу на оновлення правил у ядрі, коли Service (або їх EndpointSlices) змінюються. Ви можете налаштувати поведінку синхронізації kube-proxy за допомогою параметрів у розділі iptables файлу конфігурації kube-proxy (який ви вказуєте через kube-proxy --config <path>):

...
iptables:
  minSyncPeriod: 1s
  syncPeriod: 30s
...
minSyncPeriod

Параметр minSyncPeriod встановлює мінімальний інтервал між спробами ресинхронізації правил iptables з ядром. Якщо він дорівнює 0s, то kube-proxy завжди негайно синхронізує правила при зміні будь-якого Service чи Endpoint. Це працює добре в дуже малих кластерах, але призводить до зайвої роботи, коли велика кількість змін відбувається за короткий період часу. Наприклад, якщо у вас є Service, який підтримується Deployment зі 100 Podʼів, і ви видаляєте Deployment, то з minSyncPeriod: 0s, kube-proxy буде по одному видаляти точки доступу Service з правил iptables, загалом 100 оновлень. З більшим значенням minSyncPeriod, події видалення багатьох Podʼів можуть агрегуватися разом, наприклад, kube-proxy може зробити 5 оновлень, кожне з яких видаляє по 20 точок доступу, що значно економить процесорний час і прискорює синхронізацію всіх змін.

Чим більше значення minSyncPeriod, тим більше роботи можна агрегувати, але недолік полягає в тому, що кожна окрема зміна може очікувати до повного minSyncPeriod, перш ніж буде оброблена, що означає, що правила iptables витрачають більше часу несинхронізованими з поточним станом API-сервера.

Стандартне значення 1s працює добре в більшості кластерів, але в дуже великих кластерах може бути необхідно встановити більше значення. Особливо, якщо метрика sync_proxy_rules_duration_seconds kube-proxy показує середній час значно більше 1 секунди, збільшення minSyncPeriod може зробити оновлення ефективнішими.

Оновлення конфігурації старого параметра minSyncPeriod

У попередніх версіях kube-proxy всі правила для всіх Service оновлювалися кожною синхронізацією, що призводило до проблем продуктивності (затримок оновлення) у великих кластерах, і рекомендоване рішення полягало в налаштуванні більшого значення minSyncPeriod. Починаючи з Kubernetes v1.28, режим iptables kube-proxy використовує більш мінімалістичний підхід, здійснюючи оновлення тільки там, де фактично змінилися Service або EndpointSlices.

Якщо ви раніше перевизначали параметр minSyncPeriod, вам слід спробувати видалити це перевизначення і дозволити kube-proxy використовувати стандартні значення (1s) або принаймні менше значення, ніж ви використовували до оновлення.

Якщо ви не запускаєте kube-proxy з Kubernetes 1.31, перевірте поведінку і повʼязані поради для версії, яку ви фактично використовуєте.

syncPeriod

Параметр syncPeriod контролює кілька операцій синхронізації, які не повʼязані безпосередньо зі змінами в окремих Service та EndpointSlices. Зокрема, він визначає, як швидко kube-proxy помічає, якщо зовнішній компонент втрутився в правила iptables kube-proxy. У великих кластерах kube-proxy також виконує певні операції очищення лише один раз протягом syncPeriod, щоб уникнути непотрібної роботи.

Зазвичай збільшення syncPeriod не має значного впливу на продуктивність, але раніше іноді було корисно встановлювати його дуже великим значенням (наприклад, 1h). Проте це більше не рекомендується і, ймовірно, таке налаштування спричинить більше проблем з функціональністю, ніж покращить продуктивність.

Режим проксі IPVS

Цей режим проксі доступний лише на вузлах Linux.

У режимі ipvs kube-proxy використовує ядро IPVS та API iptables для створення правил для перенаправлення трафіку з IP-адрес Service на IP-адреси точок доступу.

Режим проксі IPVS базується на функції перехоплення netfilter, аналогічній режиму iptables, але використовує хеш-таблицю як основну структуру даних та працює в просторі ядра. Це означає, що kube-proxy в режимі IPVS перенаправляє трафік з меншою затримкою порівняно з режимом iptables, зі значно кращою продуктивністю при синхронізації правил проксі. У порівнянні з режимом проксі iptables, режим IPVS також підтримує вищу пропускну здатність мережевого трафіку.

IPVS надає більше опцій для балансування трафіку до бекендів Pods:

  • rr (Round Robin): Трафік рівномірно розподіляється між серверами.

  • wrr (Weighted Round Robin): Трафік маршрутизується до серверів на основі їх ваг. Сервери з вищими вагами отримують нові зʼєднання і більше запитів, ніж сервери з меншими вагами.

  • lc (Least Connection): Більше трафіку призначається серверам з меншою кількістю активних зʼєднань.

  • wlc (Weighted Least Connection): Більше трафіку маршрутизується до серверів з меншою кількістю зʼєднань відносно їх ваг, тобто кількість зʼєднань, поділена на вагу.

  • lblc (Locality based Least Connection): Трафік для тієї ж самої IP-адреси надсилається на той же сервер, якщо він не перевантажений і доступний; в іншому випадку трафік надсилається на сервери з меншою кількістю зʼєднань з можливістю збереження для майбутнього призначення.

  • lblcr (Locality Based Least Connection with Replication): Трафік для тієї ж самої IP-адреси надсилається на сервер з найменшою кількістю зʼєднань. Якщо всі сервери перевантажені, вибирається один із меншою кількістю зʼєднань і додається до множини цільових серверів. Якщо множина цільових серверів не змінюється протягом визначеного часу, то найбільш навантажений сервер вилучається з множини, щоб уникнути високого рівня реплікації.

  • sh (Source Hashing): Трафік відправляється на сервер за допомогою статично призначеної хеш-таблиці на основі джерела IP-адрес.

  • dh (Destination Hashing): Трафік відправляється на сервер за допомогою статично призначеної хеш-таблиці на основі цільових адрес.

  • sed (Shortest Expected Delay): Трафік пересилається на сервер з найменшим очікуваним затримкою. Очікувана затримка обчислюється як (C + 1) / U, де C — кількість зʼєднань на сервері, а U — фіксована сервісна швидкість (вага) сервера.

  • nq (Never Queue): Трафік відправляється на сервер, що простоює, якщо є такий, замість очікування швидкішого; якщо всі сервери зайняті, алгоритм переходить до поведінки sed.

Механізм віртуальної IP-адреси для Services, використовуючи режим IPVS

Режим проксі nftables

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.31 [beta]

Цей режим проксі доступний лише на вузлах Linux, він потребує ядра версії 5.13 чи новіщої.

У цьому режимі kube-proxy налаштовує правила пересилання пакетів за допомогою API nftables ядра підсистеми netfilter. Для кожної точки доступу встановлюються правила nftables, які стандартно вибирають бекенд Pod випадковим чином.

API nftables є наступником API iptables і призначений для забезпечення кращої продуктивності та масштабованості порівняно з iptables. Режим проксі nftables може обробляти зміни в точках доступу сервісу швидше та ефективніше, ніж режим iptables, і також може ефективніше обробляти пакети в ядрі (хоча це стає помітним лише в кластерах з десятками тисяч сервісів).

В Kubernetes 1.31, режим nftables все ще відносно новий і може бути несумісний з усіма мережевими втулками; ознайомтесь з документацією до вашого мережевого втулка.

Міграція з iptables на nftables

Користувачі, які хочуть перейти зі стандартного режиму iptables на режим nftables, повинні знати, що деякі функції в режимі nftables працюють трохи інакше:

  • Інтерфейси NodePort: У режимі iptables, стандартно, сервіси NodePort доступні на всіх локальних IP-адресах. Це зазвичай не те, чого хочуть користувачі, тому режим nftables стандартно використовує параметр --nodeport-addresses primary, що означає, що сервіси NodePort доступні лише на основних IPv4 та/або IPv6 адресах вузла. Ви можете змінити це, вказавши явне значення для цієї опції: наприклад, --nodeport-addresses 0.0.0.0/0, щоб слухати на всіх (локальних) IP-адресах IPv4.

  • Сервіси NodePort на 127.0.0.1: У режимі iptables, якщо діапазон --nodeport-addresses включає 127.0.0.1 (і не передано опцію --iptables-localhost-nodeports false), тоді сервіси NodePort будуть доступні навіть на "localhost" (127.0.0.1). У режимі nftables (та режимі ipvs) це не працюватиме. Якщо ви не впевнені, чи залежите від цієї функціональності, ви можете перевірити метрику kube-proxy iptables_localhost_nodeports_accepted_packets_total; якщо вона не дорівнює 0, це означає, що якийсь клієнт підключився до сервісу NodePort через 127.0.0.1.

  • Взаємодія NodePort з брандмауерами: Режим iptables kube-proxy намагається бути сумісним із занадто агресивними брандмауерами; для кожного сервісу NodePort він додаватиме правила для прийому вхідного трафіку на цьому порту, на випадок, якщо цей трафік буде заблокований брандмауером. Цей підхід не працює з брандмауерами на основі nftables, тому режим nftables kube-proxy не робить нічого в цьому напрямку; якщо у вас є локальний брандмауер, ви повинні переконатися, що він належним чином налаштований для пропуску трафіку Kubernetes (наприклад, дозволивши вхідний трафік на весь діапазон NodePort).

  • Обхід помилок Conntrack: Ядра Linux версій до 6.1 мають помилку, яка може призвести до закриття довготривалих TCP-зʼєднань до IP-адрес сервісів з помилкою "Connection reset by peer". Режим iptables kube-proxy встановлює обхід для цієї помилки, але пізніше було виявлено, що цей обхід викликає інші проблеми в деяких кластерах. Режим nftables стандартно не встановлює жодного обходу, але ви можете перевірити метрику kube-proxy iptables_ct_state_invalid_dropped_packets_total, щоб зʼясувати, чи залежить ваш кластер від цього обходу, і якщо це так, ви можете запустити kube-proxy з опцією --conntrack-tcp-be-liberal, щоб оминути цю проблему в режимі nftables.

Режим проксі kernelspace

Цей режим проксі доступний лише на вузлах Windows.

kube-proxy налаштовує правила фільтрації пакетів у Windows у віртуальній платформі фільтрації (Virtual Filtering Platform, VFP), яка є розширенням віртуального комутатора Windows (vSwitch). Ці правила обробляють інкапсульовані пакети в межах віртуальних мереж на рівні вузлів і переписують пакети таким чином, щоб IP-адреса призначення (і інформація на рівні 2) була правильною для маршрутизації пакета до вірного призначення. Windows VFP аналогічний інструментам, таким як Linux nftables або iptables. Він розширює Hyper-V Switch, який спочатку був реалізований для підтримки мережевого звʼязку віртуальних машин.

Коли Pod на вузлі надсилає трафік на віртуальну IP-адресу, а kube-proxy вибирає Pod на іншому вузлі як ціль для балансування навантаження, режим проксі kernelspace переписує цей пакет так, щоб він був призначений для цільового бекенд Pod. Служба мережевого хоста Windows (HNS) забезпечує конфігурацію правил переписування пакетів таким чином, щоб зворотній трафік виглядав так, ніби він прийшов від віртуальної IP-адреси, а не конкретного бекенду Pod.

Прямий вивід сервера для режиму kernelspace

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.14 [alpha]

Як альтернативу базовому способу роботи, вузол, на якому розміщено бекенд Pod для Service, може застосовувати пряме переписування пакетів безпосередньо, а не покладати це завдання на вузол, на якому працює клієнтський Pod. Це називається прямим виводом сервера.

Для використання цієї можливості вам необхідно запускати kube-proxy з аргументом командного рядка --enable-dsr і включити функціональних можливостейWinDSR.

Прямий вивід сервера також оптимізує випадок зворотного трафіку для Pod, навіть коли обидва Pod працюють на одному вузлі.

Сесійна спорідненість

У цих моделях проксі, трафік, що направляється на IP:Port Service, передається до відповідного бекенду без того, щоб клієнти щось знали про Kubernetes, Service або Podʼи.

Якщо ви хочете забезпечити, щоб зʼєднання від певного клієнта завжди передавалися до одного й того ж Podʼа, ви можете вибрати сесійну спорідненість на основі IP-адрес клієнта, встановивши .spec.sessionAffinity в ClientIP для Service (типово None).

Тайм-аут збереження сесії

Ви також можете встановити максимальний час збереження сесії, встановивши .spec.sessionAffinityConfig.clientIP.timeoutSeconds відповідно для Service. (стандартне значення 10800, що відповідає 3 годинам).

Призначення IP-адрес Service

На відміну від IP-адрес Podʼів, які фактично маршрутизуються до фіксованого призначення, IP-адреси Service насправді не відповідають одному окремому хосту. Замість цього, kube-proxy використовує логіку обробки пакетів (наприклад, Linux iptables), щоб визначити віртуальні IP-адреси, які потрібно перенаправляти за потреби.

Коли клієнти підключаються до VIP, їхній трафік автоматично транспортується до відповідної точки доступу. Змінні середовища та DNS для Service насправді заповнюються відносно віртуальної IP-адреси Service (і порту).

Уникнення конфліктів

Одна з основних філософій Kubernetes полягає в тому, що ви не повинні потрапляти в ситуації, які можуть призвести до провалу ваших дій не з вашої вини. Для дизайну ресурсу Service це означає, що вам не потрібно вибирати свою власну IP-адресу, якщо цей вибір може конфліктувати з вибором іншої особи. Це може призвести до порушення ізоляції.

Щоб дозволити вам вибирати IP-адреси для ваших Service, ми повинні забезпечити, що жодні два Service не зможуть конфліктувати. Kubernetes досягає цього, призначаючи кожному Service його власну IP-адресу з діапазону service-cluster-ip-range, який налаштований для API Server.

Відстеження призначення IP-адрес

Для того щоб гарантувати, що кожен Service отримує унікальну IP-адресу, внутрішній розподілювач атомарно оновлює глобальний map призначення в etcd перед створенням кожного Service. Обʼєкт map повинен існувати в реєстрі для того, щоб Service отримували призначення IP-адрес, інакше створення завершиться невдачею з повідомленням про неможливість призначити IP-адресу.

В панелі управління фоновий контролер відповідає за створення цього map (необхідно для підтримки міграції зі старих версій Kubernetes, які використовували блокування в памʼяті). Kubernetes також використовує контролери для перевірки недійсних призначень (наприклад, через втручання адміністратора) та для очищення призначених IP-адрес, які більше не використовуються жодними Services.

Відстеження призначення IP-адрес за допомогою Kubernetes API

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.31 [beta]

Якщо ви включите функціональні можливості MultiCIDRServiceAllocator та API-групу networking.k8s.io/v1alpha1, панель управління замінить наявний розподілювач etcd переглянутою реалізацією, яка використовує обʼєкти IPAddress та ServiceCIDR замість внутрішнього глобального map призначення. Кожен IP-адрес кластера, повʼязаний з Service, посилається на обʼєкт IPAddress.

Увімкнення функціональних можливостей також замінює фоновий контролер альтернативою, яка обробляє обʼєкти IPAddress та підтримує міграцію зі старої моделі розподілювача. Kubernetes 1.31 не підтримує міграцію з обʼєктів IPAddress до внутрішнього map призначення.

Однією з основних переваг переглянутого розподілювача є видалення обмежень розміру для діапазону IP-адрес, який може бути використаний для IP-адрес кластера Service. З увімкненою MultiCIDRServiceAllocator, для IPv4 відсутні обмеження, а для IPv6 ви можете використовувати маски підмереж, що є /64 або менше (на відміну від /108 зі старої реалізації).

Доступ до призначень IP-адрес через API означає, що ви, як адміністратор кластера, можете дозволяти користувачам переглядати призначені їх Service IP-адреси. Розширення Kubernetes, такі як Gateway API, можуть використовувати IPAddress API для розширення вбудованих мережевих можливостей Kubernetes.

Нижче наведений короткий приклад того, як користувач може запитувати IP-адреси:

kubectl get services
NAME         TYPE        CLUSTER-IP        EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   2001:db8:1:2::1   <none>        443/TCP   3d1h
kubectl get ipaddresses
NAME              PARENTREF
2001:db8:1:2::1   services/default/kubernetes
2001:db8:1:2::a   services/kube-system/kube-dns

Kubernetes також дозволяє користувачам динамічно визначати доступні діапазони IP для Service за допомогою обʼєктів ServiceCIDR. Під час початкового налаштування, обʼєкт ServiceCIDR зі стандартним іменем kubernetes створюється зі значенням аргументу командного рядка --service-cluster-ip-range для kube-apiserver:

kubectl get servicecidrs
NAME         CIDRS         AGE
kubernetes   10.96.0.0/28  17m

Користувачі можуть створювати або видаляти нові обʼєкти ServiceCIDR для управління доступними діапазонами IP для Service:

cat <<'EOF' | kubectl apply -f -
apiVersion: networking.k8s.io/v1beta1
kind: ServiceCIDR
metadata:
  name: newservicecidr
spec:
  cidrs:
  - 10.96.0.0/24
EOF
servicecidr.networking.k8s.io/newcidr1 created
kubectl get servicecidrs
NAME             CIDRS         AGE
kubernetes       10.96.0.0/28  17m
newservicecidr   10.96.0.0/24  7m

Діапазони IP-адрес для віртуальних IP-адрес Service

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.26 [stable]

Kubernetes розділяє діапазон ClusterIP на дві групи, в залежності від розміру налаштованого service-cluster-ip-range, використовуючи таку формулу: min(max(16, cidrSize / 16), 256). Ця формула означає ніколи менше 16 або більше 256, з поступовим збільшенням між ними.

Kubernetes віддає перевагу виділенню динамічних IP-адрес для Service, вибираючи з верхньої групи. Це означає, що якщо ви хочете призначити конкретну IP-адресу для Service з типом ClusterIP, ви повинні вручну призначити IP-адресу з нижньої групи. Цей підхід зменшує ризик конфлікту при виділенні IP-адрес.

Політики трафіку

Ви можете встановити поля .spec.internalTrafficPolicy і .spec.externalTrafficPolicy, щоб контролювати, як Kubernetes маршрутизує трафік до справних ("готових") бекендів.

Політика втурішнього трафіку

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.26 [stable]

Ви можете встановити поле .spec.internalTrafficPolicy, щоб контролювати маршрутизацію трафіку від внутрішніх джерел. Допустимі значення: Cluster і Local. Встановіть поле в Cluster, щоб маршрутизувати внутрішній трафік до всіх готових точок доступу і в Local, щоб маршрутизувати тільки до готових точок доступу, що знаходяться на вузлі. Якщо політика трафіку встановлена в Local, а на вузлі відсутні локальні точки доступу, kube-proxy відкидає трафік.

Політика зовнішнього трафіку

Ви можете налаштувати поле .spec.externalTrafficPolicy для контролю напрямку трафіку зовнішніх джерел. Допустимі значення: Cluster і Local. Встановіть поле на значення Cluster, щоб направляти зовнішній трафік до всіх готових точок доступу, і Local, щоб направляти тільки до готових локальних точок доступу на вузлі. Якщо політика трафіку встановлена на Local і відсутні локальні точки доступу, kube-proxy не передає жодного трафіку для відповідного Service.

Якщо вибрано Cluster, всі вузли є потенційними цілями балансування навантаження, поки вузол не видаляється і kube-proxy працює коректно. У цьому режимі: перевірки стану балансувальника навантаження налаштовані на доступність порту та шляху готовності проксі сервісу. Для kube-proxy це оцінюється як: ${NODE_IP}:10256/healthz. kube-proxy повертає HTTP-код 200 або 503. Точка доступу перевірки стану балансувальника навантаження kube-proxy повертає 200 у випадку:

  1. kube-proxy працює коректно, що означає:
    • він може успішно просувати програмування мережі і не має проблем з таймаутом (таймаут визначається як: 2 × iptables.syncPeriod); і
  2. вузол не видаляється (не встановлено мітки видалення для вузла).

Причина того, що kube-proxy повертає 503 і позначає вузол як непридатний, коли він видаляється, полягає в тому, що kube-proxy підтримує очищення зʼєднання для вузлів, що припиняють роботу. З точки зору управління Kubernetes керування навантаженням при видаленні вузла відбувається декілька важливих аспектів.

Під час видалення:

  • kube-proxy почне не проходити свою перевірку готовності і фактично позначає вузол як непридатний для трафіку балансувальника навантаження. Невдача перевірки стану балансувальника навантаження призводить до того, що балансувальники навантаження, які підтримують очищення зʼєднань, дозволяють завершити існуючі зʼєднання та блокують створення нових зʼєднань.

Після видалення:

  • Контролер сервісу в менеджері хмарних контролерів Kubernetes видаляє вузол зі згаданого набору потенційних цілей. Видалення будь-якого екземпляра зі списку бекендів балансувальника навантаження миттєво припиняє всі зʼєднання. Це також причина того, що kube-proxy спочатку не проходить перевірку стану, коли вузол видаляється.

Для вендорів Kubernetes важливо враховувати, що якщо будь-який вендор налаштовує перевірку готовності kube-proxy як перевірку життєздатності, kube-proxy почне постійно перезапускатися при видаленні вузла до його повного видалення. kube-proxy використовує шлях /livez, який, на відміну від /healthz, не враховує стан видалення вузла, але лише прогрес програмування мережі. /livez є рекомендованим шляхом для визначення перевірки життєздатності kube-proxy.

Користувачі, які використовують kube-proxy, можуть перевірити стан готовності/життєздатності, оцінюючи метрики: proxy_livez_total/proxy_healthz_total. Обидві метрики публікують дві серії: одна з міткою 200 і одна з міткою 503.

Для Local Services: kube-proxy повертає 200, якщо

  1. kube-proxy працює коректно/готовий, і
  2. є локальна точка доступу на вузлі, який розглядається.

Видалення вузла не впливає на код відповіді kube-proxy щодо перевірки стану балансувальника навантаження. Причина полягає в тому, що видалення вузлів може призвести до відключення входу в мережу, якщо всі точки доступу одночасно працюють на таких вузлах.

Проєкт Kubernetes рекомендує, щоб код інтеграції провайдера хмари налаштовував перевірки стану балансувальника навантаження, які націлені на порт healthz сервісного проксі. Якщо ви використовуєте або реалізовуєте власну віртуальну реалізацію IP, яку люди можуть використовувати замість kube-proxy, вам слід налаштувати аналогічний порт перевірки стану з логікою, яка відповідає реалізації kube-proxy.

Трафік до термінальних точок доступу доступу

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.28 [stable]

Якщо в kube-proxy включений функціоналу ProxyTerminatingEndpoints і політика трафіку встановлена на Local, kube-proxy на даному вузлі використовує більш складний алгоритм для вибору точок доступу доступу Service. З цим включеним функціоналом, kube-proxy перевіряє наявність локальних точок доступу доступу і те, чи всі локальні кінцеві точки позначені як термінальні. Якщо всі локальні кінцеві точки позначені як термінальні, тоді kube-proxy направлятиме трафік на ці термінальні кінцеві точки. В іншому випадку kube-proxy завжди віддає перевагу направленню трафіку на кінцеві точки, які не є термінальними.

Це поведінка направлення для терміналних точок доступу доступу існує для того, щоб NodePort і LoadBalancer сервіси могли відповідно завершувати зʼєднання при використанні externalTrafficPolicy: Local.

Під час виконання постійного (rolling) оновлення, вузли, які підтримують балансувальник навантаження, можуть переходити від N до 0 реплік цього розгортання. У деяких випадках зовнішні балансувальники навантаження можуть надсилати трафік на вузол з 0 репліками між перевірками готовності. Направлення трафіку на термінальні точки доступу забезпечує, що вузли, які зменшують кількість точок доступу, можуть відповідним чином приймати та відводити трафік на ці термінальні точки доступу. До моменту завершення видалення точки доступу, зовнішній балансувальник навантаження має побачити, що перевірка готовності вузла не вдалася і повністю видалить вузол зі списку бекендів.

Розподіл трафіку

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.31 [beta]

Поле spec.trafficDistribution в Kubernetes Service дозволяє виразити уподобання щодо того, як треба маршрутизувати трафік до точок доступу Service. Реалізації, такі як kube-proxy, використовують поле spec.trafficDistribution як рекомендацію. Поведінка, повʼязана з певними уподобаннями, може трохи відрізнятися між різними реалізаціями.

PreferClose з kube-proxy
Для kube-proxy це означає, що пріоритет в надсиланні трафіку надається точкам доступу в тій самій зоні, що й клієнт. Контролер EndpointSlice оновлює EndpointSlice з підказками для комунікації цього уподобання, яке kube-proxy використовує для прийняття рішень щодо маршрутизації. Якщо в зоні клієнта відсутні будь-які доступні точки доступу, трафік буде маршрутизовано на рівні всього кластера для цього клієнта.

У відсутність будь-якого значення для trafficDistribution, стандартна стратегія для kube-proxy полягає в розподілі трафіку до будь-якої точки доступу в кластері.

Порівняння з service.kubernetes.io/topology-mode: Auto

Поле trafficDistribution зі значенням PreferClose і анотація service.kubernetes.io/topology-mode: Auto спрямовані на пріоритет маршрутизації трафіку в межах однієї зони. Однак, є ключові відмінності у їхніх підходах:

  • service.kubernetes.io/topology-mode: Auto: Спробує розподілити трафік пропорціонально між зонами на основі ресурсів CPU, які можна виділити. Цей евристичний метод включає захисні заходи (такі як поведінка відкату для малих кількостей точок доступу) і може призвести до вимкнення функціоналу в певних сценаріях з причин навантаження балансування. Цей підхід жертвує деякою передбачуваністю на користь можливості балансування навантаження.

  • trafficDistribution: PreferClose: Цей підхід спрямований на більш простоту і передбачуваність: "Якщо є точки доступу в зоні, вони отримають весь трафік для цієї зони; якщо точок доступу у зоні немає, трафік буде розподілено на інші зони". Хоча цей підхід може пропонувати більшу передбачуваність, він означає, що вам потрібно керувати можливим перевантаженням.

Якщо встановлено анотацію service.kubernetes.io/topology-mode зі значенням Auto, вона матиме пріоритет перед полем trafficDistribution. (У майбутньому анотація може бути застарілою на користь поля trafficDistribution).

Взаємодія з політиками трафіку

Порівняно з полем trafficDistribution, поля політики трафіку (externalTrafficPolicy і internalTrafficPolicy) призначені для обовʼязкового дотримання локальних вимог до трафіку. Ось як поле trafficDistribution взаємодіє з ними:

  • Пріоритет політик трафіку: Для заданого Service, якщо політика трафіку (externalTrafficPolicy або internalTrafficPolicy) встановлена на Local, вона має пріоритет перед trafficDistribution: PreferClose для відповідного типу трафіку (зовнішнього або внутрішнього відповідно).

  • Вплив trafficDistribution: Для заданого Service, якщо політика трафіку (externalTrafficPolicy або internalTrafficPolicy) встановлена на Cluster (стандартне значення), або якщо поля не встановлені, тоді trafficDistribution: PreferClose керує поведінкою маршрутизації для відповідного типу трафіку (зовнішнього або внутрішнього відповідно). Це означає, що буде здійснена спроба направити трафік на точку доступу, яка знаходиться в тій же зоні, що й клієнт.

Міркування щодо використання управління розподілом трафіку

  • Збільшена ймовірність перевантаження точок доступу: Евристичний підхід PreferClose буде намагатися маршрутизувати трафік до найближчих справних точок доступу замість рівномірного розподілу цього трафіку між усіма точками доступу. Якщо у вас недостатня кількість точок доступу у зоні, вони можуть стати перевантаженими. Це особливо ймовірно, якщо вхідний трафік не розподіляється пропорційно між зонами. Для зменшення цього ризику варто розглянути наступні стратегії:

    • Обмеження розподілу топології Pod: Використовуйте обмеження розподілу топології Pod для рівномірнішого розподілу ваших Podʼів по зонам.

    • Розгортання з врахуванням зон: Якщо очікуєте нерівномірних патернів трафіку, створюйте окреме розгортання для кожної зони. Цей підхід дозволяє окремим робочим навантаженням масштабуватися незалежно. Також в екосистемі, поза проектом Kubernetes, доступні надбудови для управління робочими навантаженнями, які можуть допомогти у цьому.

  • Реалізація залежно від імплементації: Кожна реалізація панелі даних може трохи по-різному обробляти це поле. Якщо ви використовуєте імплементацію, відмінну від kube-proxy, зверніться до документації саме цієї імплементації, щоб зрозуміти, як це поле обробляється.

Що далі

Щоб дізнатися більше про Service, читайте Підключення застосунків до Service.

Також ви можете:

6.10 - Інструменти встановлення

6.10.1 - Kubeadm

Kubeadm — це інструмент, створений для надання команд kubeadm init та kubeadm join як "швидкі" практичні шляхи для створення кластерів Kubernetes.

kubeadm виконує необхідні дії для запуску мінімально життєздатного кластера. За своєю концепцією, він займається лише процесом розгортання, а не наданням машин. Також встановлення різноманітних додаткових компонентів, таких як інформаційна панель Kubernetes, засоби моніторингу та специфічні для хмарних середовищ надбудови, не є його завданням.

Замість цього ми очікуємо, що на вищому рівні будуть створені більш високорівневі та більш налаштовані інструменти на основі kubeadm, і ідеально використання kubeadm як основи для всіх розгортань спростить створення сумісних кластерів.

Як встановити

Для встановлення kubeadm, див. посібник з встановлення.

Що далі

  • kubeadm init — для створення вузла панелі управління Kubernetes
  • kubeadm join — для додавання робочого вузла Kubernetes до кластера
  • kubeadm upgrade — для оновлення кластера Kubernetes до нової версії
  • kubeadm config — якщо ви ініціалізували свій кластер за допомогою kubeadm версії 1.7.x або нижче, для налаштування кластера для kubeadm upgrade
  • kubeadm token — для управління токенами для kubeadm join
  • kubeadm reset — для скасування будь-яких змін, внесених цим хостом за допомогою kubeadm init або kubeadm join
  • kubeadm certs — для управління сертифікатами Kubernetes
  • kubeadm kubeconfig — для управління файлами kubeconfig
  • kubeadm version — для виводу версії kubeadm
  • kubeadm alpha — для попереднього перегляду набору функцій, що стануть доступними для збору відгуків від спільноти

6.10.1.1 - Kubeadm Generated

6.10.1.1.1 -

kubeadm: легке розгортання захищеного кластера Kubernetes

Опис

┌──────────────────────────────────────────────────────────┐
│ KUBEADM                                                  │
│ Easily bootstrap a secure Kubernetes cluster             │
│                                                          │
│ Please give us feedback at:                              │
│ https://github.com/kubernetes/kubeadm/issues             │
└──────────────────────────────────────────────────────────┘

Приклад використання:

Створіть кластер з двох машин з одним вузлом панелі управління
(який керує кластером) та одним робочим вузлом
(де працюють ваші робочі навантаження, такі як Podʼи та Deployments).

┌──────────────────────────────────────────────────────────┐
│ На першій машині:                                        │
├──────────────────────────────────────────────────────────┤
│ control-plane# kubeadm init                              │
└──────────────────────────────────────────────────────────┘

┌──────────────────────────────────────────────────────────┐
│ На другій машині:                                        │
├──────────────────────────────────────────────────────────┤
│ worker# kubeadm join &lt;arguments-returned-from-init&gt;      │
└──────────────────────────────────────────────────────────┘

Повторіть другий крок на стількох інших машинах, скільки потрібно.
-h, --help

Довідка kubeadm

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.2 -

Команди, повʼязані з обробкою сертифікатів kubernetes

Опис

Команди, повʼязані з обробкою сертифікатів kubernetes

kubeadm certs [command]

Параметри

-h, --help

довідка certs

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.3 -

Генерує ключів сертифікатів

Опис

Ця команда виведе захищений випадково згенерований ключ сертифіката, який можна використовувати з командою "init".

Ви також можете скористатися командою "kubeadm init --upload-certs" без зазначення ключа сертифіката, і вона згенерує і виведе його для вас.

kubeadm certs certificate-key [flags]

Параметри

-h, --help

Довідка certificate-key

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.4 -

Перевіряє термін дії сертифікатів для кластера Kubernetes

Опис

Перевіряє термін дії сертифікатів у локальному PKI, яким керує kubeadm.

kubeadm certs check-expiration [flags]

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли поле або ключ map відсутні в шаблоні. Застосовується тільки до форматів виведення golang і jsonpath.

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка check-expiration

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

-o, --output string     Типово: "text"

Формат виводу. Один з: text|json|yaml|go-template|go-template-file|template|templatefile|jsonpath|jsonpath-as-json|jsonpath-file.

--show-managed-fields

Якщо true, залишати managedFields при виведенні обʼєктів у форматі JSON або YAML.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.5 -

Генерує ключі та запити на підписання сертифікатів

Опис

Генерує ключі та запити на підписування сертифікатів (CSRs) для всіх сертифікатів, необхідних для роботи панелі управління. Ця команда також генерує часткові файли kubeconfig з даними приватного ключа в полі "users > user > client-key-data", і для кожного файлу kubeconfig створюється супутній файл ".csr".

Ця команда призначена для використання в Режимі Kubeadm з зовнішнім CA Kubeadm. Вона генерує CSRs, які ви можете подати на підписання до вашого зовнішнього центру сертифікації.

Закодовані в PEM підписані сертифікати повинні бути збережені поруч з файлами ключів, використовуючи ".crt" як розширення файлу, або, у випадку з файлами kubeconfig, закодований в PEM підписаний сертифікат повинен бути закодований у base64 і доданий до файлу kubeconfig в полі "users > user > client-certificate-data".

kubeadm certs generate-csr [flags]

Приклади

# Наступна команда згенерує ключі та CSRs для всіх сертифікатів панелі управління та файлів kubeconfig:
kubeadm certs generate-csr --kubeconfig-dir /tmp/etc-k8s --cert-dir /tmp/etc-k8s/pki

Параметри

--cert-dir string

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка generate-csr

--kubeconfig-dir string     Типово: "/etc/kubernetes"

Шлях, де буде збережено файл kubeconfig.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.6 -

Поновлення сертифікатів для кластера Kubernetes

Опис

Ця команда не призначена для самостійного запуску. Дивіться список доступних підкоманд.

kubeadm certs renew [flags]

Параметри

-h, --help

довідка renew

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.7 -

Поновлює сертифікат, вбудований у файл kubeconfig для використання адміністратором і для самого kubeadm

Опис

Поновлює сертифікат, вбудований у файл kubeconfig для використання адміністратором і для самого kubeadm.

Поновлення виконується безумовно, незалежно від дати закінчення терміну дії сертифіката; додаткові атрибути, такі як SAN, будуть базуватися на поточних файлах/сертифікатах, нема потреби їх поновлювати.

Типово поновлення намагається використовувати центр сертифікації в локальному PKI, керованому kubeadm; як альтернативу можна використовувати API сертифікатів K8s для поновлення сертифікатів, або, як останній варіант, згенерувати CSR-запит.

Після оновлення, щоб зміни набули чинності, необхідно перезапустити компоненти панелі управління та, зрештою, повторно розповсюдити оновлений сертифікат у випадку, якщо файл використовується деінде.

kubeadm certs renew admin.conf [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка admin.conf

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.8 -

Поновлення всіх доступних сертифікатів

Опис

Поновлення усі відомих сертифікатів, необхідних для запуску панелі управління. Поновлення виконується безумовно, незалежно від дати закінчення терміну дії. Поновлення також можна виконувати окремо для більшого контролю.

kubeadm certs renew all [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка all

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.9 -

Поновлює сертифікат, який apiserver використовує для доступу до etcd

Опис

Поновлює сертифікат, який apiserver використовує для доступу до etcd.

Поновлення виконується безумовно, незалежно від дати закінчення терміну дії сертифіката; додаткові атрибути, такі як SAN, будуть базуватися на наявних файлах/сертифікатах, нема потреби їх поновлювати.

Типово поновлення намагається використовувати центр сертифікації в локальному PKI, керованому kubeadm; як альтернативу можна використовувати API сертифікатів K8s для поновлення сертифікатів, або, як останній варіант, згенерувати CSR запит.

Після оновлення, щоб зміни набули чинності, необхідно перезапустити компоненти панелі управління та, зрештою, повторно розповсюдити оновлений сертифікат у випадку, якщо файл використовується деінде.

kubeadm certs renew apiserver-etcd-client [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка apiserver-etcd-client

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.10 -

Поновлює сертифікат для сервера API для підключення до kubelet

Опис

Поновлює сертифікат для сервера API для підключення до kubelet.

Поновлення виконується безумовно, незалежно від дати закінчення терміну дії сертифіката; додаткові атрибути, такі як SAN, будуть базуватися на наявних файлах/сертифікатах, нема потреби їх перезавантажувати.

Типово поновлення намагається використовувати центр сертифікації в локальному PKI, керованому kubeadm; як альтернативу можна використовувати API сертифікатів K8s для поновлення сертифікатів, або, як останній варіант, згенерувати CSR-запит.

Після оновлення, щоб зміни набули чинності, необхідно перезапустити компоненти панелі управління та, зрештою, повторно розповсюдити оновлений сертифікат у випадку, якщо файл використовується деінде.

kubeadm certs renew apiserver-kubelet-client [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка apiserver-kubelet-client

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.11 -

Поновлює сертифікат для обслуговування API Kubernetes

Синопсис

Поновлює сертифікат для обслуговування API Kubernetes.

Поновлення виконується безумовно, незалежно від дати закінчення терміну дії сертифіката; додаткові атрибути, такі як SAN, будуть базуватися на наявних файлах/сертифікатах, нема потреби їх перезавантажувати.

Типово поновлення намагається використовувати центр сертифікації в локальному PKI, керованому kubeadm; як альтернативу можна використовувати API сертифікатів K8s для поновлення сертифікатів, або, як останній варіант, згенерувати CSR-запит.

Після оновлення, щоб зміни набули чинності, необхідно перезапустити компоненти панелі управління та, зрештою, повторно розповсюдити оновлений сертифікат у випадку, якщо файл використовується деінде.

kubeadm certs renew apiserver [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка apiserver

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.12 -

Поновлює сертифікат, вбудований у файл kubeconfig для використання менеджером контролера

Опис

Поновлює сертифікат, вбудований у файл kubeconfig для використання менеджером контролера.

Поновлення виконується безумовно, незалежно від дати закінчення терміну дії сертифіката; додаткові атрибути, такі як SAN, будуть базуватися на наявних файлах/сертифікатах, нема потреби їх перезавантажувати.

Типово поновлення намагається використовувати центр сертифікації в локальному PKI, керованому kubeadm; як альтернативу можна використовувати API сертифікатів K8s для поновлення сертифікатів, або, як останній варіант, згенерувати CSR-запит.

Після оновлення, щоб зміни набули чинності, необхідно перезапустити компоненти панелі управління та, зрештою, повторно розповсюдити оновлений сертифікат у випадку, якщо файл використовується деінде.

kubeadm certs renew controller-manager.conf [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка controller-manager.conf

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.13 -

Поновлює сертифікат для проб життєздатності для перевірки стану справності etcd

Опис

Поновлює сертифікат для проб життєздатності для перевірки стану справності etcd.

Поновлення виконується безумовно, незалежно від дати закінчення терміну дії сертифіката; додаткові атрибути, такі як SAN, будуть базуватися на наявних файлах/сертифікатах, нема потреби їх перезавантажувати.

Типово поновлення намагається використовувати центр сертифікації в локальному PKI, керованому kubeadm; як альтернативу можна використовувати API сертифікатів K8s для поновлення сертифікатів, або, як останній варіант, згенерувати CSR-запит.

Після оновлення, щоб зміни набули чинності, необхідно перезапустити компоненти панелі управління та, зрештою, повторно розповсюдити оновлений сертифікат у випадку, якщо файл використовується деінде.

kubeadm certs renew etcd-healthcheck-client [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка etcd-healthcheck-client

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.14 -

Поновлює сертифікат для вузлів etcd, щоб вони могли взаємодіяти один з одним

Опис

Поновлює сертифікат для вузлів etcd, щоб вони могли взаємодіяти один з одним.

Поновлення виконується безумовно, незалежно від дати закінчення терміну дії сертифіката; додаткові атрибути, такі як SAN, будуть базуватися на наявних файлах/сертифікатах, нема потреби їх перезавантажувати.

Типово поновлення намагається використовувати центр сертифікації в локальному PKI, керованому kubeadm; як альтернативу можна використовувати API сертифікатів K8s для поновлення сертифікатів, або, як останній варіант, згенерувати CSR-запит.

Після оновлення, щоб зміни набули чинності, необхідно перезапустити компоненти панелі управління та, зрештою, повторно розповсюдити оновлений сертифікат у випадку, якщо файл використовується деінде.

kubeadm certs renew etcd-peer [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка etcd-peer

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.15 -

Поновлює сертифікат для обслуговування etcd

Опис

Поновлює сертифікат для обслуговування etcd.

Поновлення виконується безумовно, незалежно від дати закінчення терміну дії сертифіката; додаткові атрибути, такі як SAN, будуть базуватися на наявних файлах/сертифікатах, нема потреби їх перезавантажувати.

Типово поновлення намагається використовувати центр сертифікації в локальному PKI, керованому kubeadm; як альтернативу можна використовувати API сертифікатів K8s для поновлення сертифікатів, або, як останній варіант, згенерувати CSR-запит.

Після оновлення, щоб зміни набули чинності, необхідно перезапустити компоненти панелі управління та, зрештою, повторно розповсюдити оновлений сертифікат у випадку, якщо файл використовується деінде.

kubeadm certs renew etcd-server [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка etcd-server

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.16 -

Поновлення сертифіката клієнта front proxy

Опис

Поновлення сертифіката клієнта front proxy.

Поновлення виконується безумовно, незалежно від дати закінчення терміну дії сертифіката; додаткові атрибути, такі як SAN, будуть базуватися на наявних файлах/сертифікатах, нема потреби їх перезавантажувати.

Типово поновлення намагається використовувати центр сертифікації в локальному PKI, керованому kubeadm; як альтернативу можна використовувати API сертифікатів K8s для поновлення сертифікатів, або, як останній варіант, згенерувати CSR-запит.

Після оновлення, щоб зміни набули чинності, необхідно перезапустити компоненти панелі управління та, зрештою, повторно розповсюдити оновлений сертифікат у випадку, якщо файл використовується деінде.

kubeadm certs renew front-proxy-client [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка front-proxy-client

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.17 -

Поновлює сертифікат, вбудований у файл kubeconfig для використання менеджером планувальника

Опис

Поновлює сертифікат, вбудований у файл kubeconfig для використання менеджером планувальника.

Поновлення виконується безумовно, незалежно від дати закінчення терміну дії сертифіката; додаткові атрибути, такі як SAN, будуть базуватися на наявних файлах/сертифікатах, нема потреби їх перезавантажувати.

Типово поновлення намагається використовувати центр сертифікації в локальному PKI, керованому kubeadm; як альтернативу можна використовувати API сертифікатів K8s для поновлення сертифікатів, або, як останній варіант, згенерувати CSR-запит.

Після оновлення, щоб зміни набули чинності, необхідно перезапустити компоненти панелі управління та, зрештою, повторно розповсюдити оновлений сертифікат у випадку, якщо файл використовується деінде.

kubeadm certs renew scheduler.conf [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка scheduler.conf

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.18 -

Поновлює сертифікат, вбудований у файл kubeconfig для суперкористувача

Опис

Поновлює сертифікат, вбудований у файл kubeconfig для суперкористувача.

Поновлення виконується безумовно, незалежно від дати закінчення терміну дії сертифіката; додаткові атрибути, такі як SAN, будуть базуватися на наявних файлах/сертифікатах, нема потреби їх перезавантажувати.

Типово поновлення намагається використовувати центр сертифікації в локальному PKI, керованому kubeadm; як альтернативу можна використовувати API сертифікатів K8s для поновлення сертифікатів, або, як останній варіант, згенерувати CSR-запит.

Після оновлення, щоб зміни набули чинності, необхідно перезапустити компоненти панелі управління та, зрештою, повторно розповсюдити оновлений сертифікат у випадку, якщо файл використовується деінде.

kubeadm certs renew super-admin.conf [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка super-admin.conf

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.19 -

Генерує ключів сертифікатів

Опис

Ця команда виведе захищений випадково згенерований ключ сертифіката, який можна використовувати з командою "init".

Ви також можете скористатися командою "kubeadm init --upload-certs" без зазначення ключа сертифіката, і вона згенерує і виведе його для вас.

kubeadm certs certificate-key [flags]

Параметри

-h, --help

Довідка certificate-key

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.20 -

Перевіряє термін дії сертифікатів для кластера Kubernetes

Опис

Перевіряє термін дії сертифікатів у локальному PKI, яким керує kubeadm.

kubeadm certs check-expiration [flags]

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли поле або ключ map відсутні в шаблоні. Застосовується тільки до форматів виведення golang і jsonpath.

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-o, --experimental-output string     Типово: "text"

Формат виводу. Один з: text|json|yaml|go-template|go-template-file|template|templatefile|jsonpath|jsonpath-as-json|jsonpath-file.

-h, --help

Довідка check-expiration

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

--show-managed-fields

Якщо true, залишати managedFields при виведенні обʼєктів у форматі JSON або YAML.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.21 -

Генерує ключі та запити на підписання сертифікатів

Опис

Генерує ключі та запити на підписування сертифікатів (CSRs) для всіх сертифікатів, необхідних для роботи панелі управління. Ця команда також генерує часткові файли kubeconfig з даними приватного ключа в полі "users > user > client-key-data", і для кожного файлу kubeconfig створюється супутній файл ".csr".

Ця команда призначена для використання в Режимі Kubeadm з зовнішнім CA Kubeadm. Вона генерує CSRs, які ви можете подати на підписання до вашого зовнішнього центру сертифікації.

Закодовані в PEM підписані сертифікати повинні бути збережені поруч з файлами ключів, використовуючи ".crt" як розширення файлу, або, у випадку з файлами kubeconfig, закодований в PEM підписаний сертифікат повинен бути закодований у base64 і доданий до файлу kubeconfig в полі "users > user > client-certificate-data".

kubeadm certs generate-csr [flags]

Приклади

# Наступна команда згенерує ключі та CSRs для всіх сертифікатів панелі управління та файлів kubeconfig:
kubeadm certs generate-csr --kubeconfig-dir /tmp/etc-k8s --cert-dir /tmp/etc-k8s/pki

Параметри

--cert-dir string

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка generate-csr

--kubeconfig-dir string     Типово: "/etc/kubernetes"

Шлях, де буде збережено файл kubeconfig.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.22 -

Поновлення сертифікатів для кластера Kubernetes

Опис

Ця команда не призначена для самостійного запуску. Дивіться список доступних підкоманд.

kubeadm certs renew [flags]

Параметри

-h, --help

довідка renew

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.23 -

Поновлює сертифікат, вбудований у файл kubeconfig для використання адміністратором і для самого kubeadm

Опис

Поновлює сертифікат, вбудований у файл kubeconfig для використання адміністратором і для самого kubeadm.

Поновлення виконується безумовно, незалежно від дати закінчення терміну дії сертифіката; додаткові атрибути, такі як SAN, будуть базуватися на поточних файлах/сертифікатах, нема потреби їх поновлювати.

Типово поновлення намагається використовувати центр сертифікації в локальному PKI, керованому kubeadm; як альтернативу можна використовувати API сертифікатів K8s для поновлення сертифікатів, або, як останній варіант, згенерувати CSR-запит.

Після оновлення, щоб зміни набули чинності, необхідно перезапустити компоненти панелі управління та, зрештою, повторно розповсюдити оновлений сертифікат у випадку, якщо файл використовується деінде.

kubeadm certs renew admin.conf [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка admin.conf

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.24 -

Поновлення всіх доступних сертифікатів

Опис

Поновлення усі відомих сертифікатів, необхідних для запуску панелі управління. Поновлення виконується безумовно, незалежно від дати закінчення терміну дії. Поновлення також можна виконувати окремо для більшого контролю.

kubeadm certs renew all [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка all

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.25 -

Поновлює сертифікат, який apiserver використовує для доступу до etcd

Опис

Поновлює сертифікат, який apiserver використовує для доступу до etcd.

Поновлення виконується безумовно, незалежно від дати закінчення терміну дії сертифіката; додаткові атрибути, такі як SAN, будуть базуватися на наявних файлах/сертифікатах, нема потреби їх поновлювати.

Типово поновлення намагається використовувати центр сертифікації в локальному PKI, керованому kubeadm; як альтернативу можна використовувати API сертифікатів K8s для поновлення сертифікатів, або, як останній варіант, згенерувати CSR запит.

Після оновлення, щоб зміни набули чинності, необхідно перезапустити компоненти панелі управління та, зрештою, повторно розповсюдити оновлений сертифікат у випадку, якщо файл використовується деінде.

kubeadm certs renew apiserver-etcd-client [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка apiserver-etcd-client

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.26 -

Поновлює сертифікат для сервера API для підключення до kubelet

Опис

Поновлює сертифікат для сервера API для підключення до kubelet.

Поновлення виконується безумовно, незалежно від дати закінчення терміну дії сертифіката; додаткові атрибути, такі як SAN, будуть базуватися на наявних файлах/сертифікатах, нема потреби їх перезавантажувати.

Типово поновлення намагається використовувати центр сертифікації в локальному PKI, керованому kubeadm; як альтернативу можна використовувати API сертифікатів K8s для поновлення сертифікатів, або, як останній варіант, згенерувати CSR-запит.

Після оновлення, щоб зміни набули чинності, необхідно перезапустити компоненти панелі управління та, зрештою, повторно розповсюдити оновлений сертифікат у випадку, якщо файл використовується деінде.

kubeadm certs renew apiserver-kubelet-client [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка apiserver-kubelet-client

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.27 -

Поновлює сертифікат для обслуговування API Kubernetes

Синопсис

Поновлює сертифікат для обслуговування API Kubernetes.

Поновлення виконується безумовно, незалежно від дати закінчення терміну дії сертифіката; додаткові атрибути, такі як SAN, будуть базуватися на наявних файлах/сертифікатах, нема потреби їх перезавантажувати.

Типово поновлення намагається використовувати центр сертифікації в локальному PKI, керованому kubeadm; як альтернативу можна використовувати API сертифікатів K8s для поновлення сертифікатів, або, як останній варіант, згенерувати CSR-запит.

Після оновлення, щоб зміни набули чинності, необхідно перезапустити компоненти панелі управління та, зрештою, повторно розповсюдити оновлений сертифікат у випадку, якщо файл використовується деінде.

kubeadm certs renew apiserver [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка apiserver

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.28 -

Поновлює сертифікат, вбудований у файл kubeconfig для використання менеджером контролера

Опис

Поновлює сертифікат, вбудований у файл kubeconfig для використання менеджером контролера.

Поновлення виконується безумовно, незалежно від дати закінчення терміну дії сертифіката; додаткові атрибути, такі як SAN, будуть базуватися на наявних файлах/сертифікатах, нема потреби їх перезавантажувати.

Типово поновлення намагається використовувати центр сертифікації в локальному PKI, керованому kubeadm; як альтернативу можна використовувати API сертифікатів K8s для поновлення сертифікатів, або, як останній варіант, згенерувати CSR-запит.

Після оновлення, щоб зміни набули чинності, необхідно перезапустити компоненти панелі управління та, зрештою, повторно розповсюдити оновлений сертифікат у випадку, якщо файл використовується деінде.

kubeadm certs renew controller-manager.conf [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка controller-manager.conf

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.29 -

Поновлює сертифікат для проб життєздатності для перевірки стану справності etcd

Опис

Поновлює сертифікат для проб життєздатності для перевірки стану справності etcd.

Поновлення виконується безумовно, незалежно від дати закінчення терміну дії сертифіката; додаткові атрибути, такі як SAN, будуть базуватися на наявних файлах/сертифікатах, нема потреби їх перезавантажувати.

Типово поновлення намагається використовувати центр сертифікації в локальному PKI, керованому kubeadm; як альтернативу можна використовувати API сертифікатів K8s для поновлення сертифікатів, або, як останній варіант, згенерувати CSR-запит.

Після оновлення, щоб зміни набули чинності, необхідно перезапустити компоненти панелі управління та, зрештою, повторно розповсюдити оновлений сертифікат у випадку, якщо файл використовується деінде.

kubeadm certs renew etcd-healthcheck-client [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка etcd-healthcheck-client

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.30 -

Поновлює сертифікат для вузлів etcd, щоб вони могли взаємодіяти один з одним

Опис

Поновлює сертифікат для вузлів etcd, щоб вони могли взаємодіяти один з одним.

Поновлення виконується безумовно, незалежно від дати закінчення терміну дії сертифіката; додаткові атрибути, такі як SAN, будуть базуватися на наявних файлах/сертифікатах, нема потреби їх перезавантажувати.

Типово поновлення намагається використовувати центр сертифікації в локальному PKI, керованому kubeadm; як альтернативу можна використовувати API сертифікатів K8s для поновлення сертифікатів, або, як останній варіант, згенерувати CSR-запит.

Після оновлення, щоб зміни набули чинності, необхідно перезапустити компоненти панелі управління та, зрештою, повторно розповсюдити оновлений сертифікат у випадку, якщо файл використовується деінде.

kubeadm certs renew etcd-peer [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка etcd-peer

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.31 -

Поновлює сертифікат для обслуговування etcd

Опис

Поновлює сертифікат для обслуговування etcd.

Поновлення виконується безумовно, незалежно від дати закінчення терміну дії сертифіката; додаткові атрибути, такі як SAN, будуть базуватися на наявних файлах/сертифікатах, нема потреби їх перезавантажувати.

Типово поновлення намагається використовувати центр сертифікації в локальному PKI, керованому kubeadm; як альтернативу можна використовувати API сертифікатів K8s для поновлення сертифікатів, або, як останній варіант, згенерувати CSR-запит.

Після оновлення, щоб зміни набули чинності, необхідно перезапустити компоненти панелі управління та, зрештою, повторно розповсюдити оновлений сертифікат у випадку, якщо файл використовується деінде.

kubeadm certs renew etcd-server [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка etcd-server

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.32 -

Поновлення сертифіката клієнта front proxy

Опис

Поновлення сертифіката клієнта front proxy.

Поновлення виконується безумовно, незалежно від дати закінчення терміну дії сертифіката; додаткові атрибути, такі як SAN, будуть базуватися на наявних файлах/сертифікатах, нема потреби їх перезавантажувати.

Типово поновлення намагається використовувати центр сертифікації в локальному PKI, керованому kubeadm; як альтернативу можна використовувати API сертифікатів K8s для поновлення сертифікатів, або, як останній варіант, згенерувати CSR-запит.

Після оновлення, щоб зміни набули чинності, необхідно перезапустити компоненти панелі управління та, зрештою, повторно розповсюдити оновлений сертифікат у випадку, якщо файл використовується деінде.

kubeadm certs renew front-proxy-client [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка front-proxy-client

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.33 -

Поновлює сертифікат, вбудований у файл kubeconfig для використання менеджером планувальника

Опис

Поновлює сертифікат, вбудований у файл kubeconfig для використання менеджером планувальника.

Поновлення виконується безумовно, незалежно від дати закінчення терміну дії сертифіката; додаткові атрибути, такі як SAN, будуть базуватися на наявних файлах/сертифікатах, нема потреби їх перезавантажувати.

Типово поновлення намагається використовувати центр сертифікації в локальному PKI, керованому kubeadm; як альтернативу можна використовувати API сертифікатів K8s для поновлення сертифікатів, або, як останній варіант, згенерувати CSR-запит.

Після оновлення, щоб зміни набули чинності, необхідно перезапустити компоненти панелі управління та, зрештою, повторно розповсюдити оновлений сертифікат у випадку, якщо файл використовується деінде.

kubeadm certs renew scheduler.conf [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка scheduler.conf

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.34 -

Поновлює сертифікат, вбудований у файл kubeconfig для суперкористувача

Опис

Поновлює сертифікат, вбудований у файл kubeconfig для суперкористувача.

Поновлення виконується безумовно, незалежно від дати закінчення терміну дії сертифіката; додаткові атрибути, такі як SAN, будуть базуватися на наявних файлах/сертифікатах, нема потреби їх перезавантажувати.

Типово поновлення намагається використовувати центр сертифікації в локальному PKI, керованому kubeadm; як альтернативу можна використовувати API сертифікатів K8s для поновлення сертифікатів, або, як останній варіант, згенерувати CSR-запит.

Після оновлення, щоб зміни набули чинності, необхідно перезапустити компоненти панелі управління та, зрештою, повторно розповсюдити оновлений сертифікат у випадку, якщо файл використовується деінде.

kubeadm certs renew super-admin.conf [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка super-admin.conf

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.35 -

Виводить код завершення командного рядка для вказаного командного рядка (bash або zsh)

Опис

Виводить код завершення команд для вказаного командного інтерпретатора (bash або zsh). Код оболонки має бути використаний, щоб забезпечити інтерактивне завершення команд kubeadm. Це можна зробити, отримавши його з .bash_profile.

Примітка: Ця команда вимагає наявності пакету bash-completion.

Для встановлення на macOS використовуйте brew:

brew install bash-completion

Після встановлення bash-completion, вам потрібно додати наступний код у ваш файл .bash_profile:

source $(brew --prefix)/etc/bash_completion

Якщо bash-completion не встановлено у Linux, встановіть його за допомогою пакетного менеджера вашої системи.

Примітка для користувачів zsh: [1] zsh completion підтримується тількіи для версій zsh >= 5.2.

kubeadm completion SHELL [flags]

Приклади

# Встановлення bash completion на Mac за допомогою homebrew
brew install bash-completion
printf "\n# Bash completion support\nsource $(brew --prefix)/etc/bash_completion\n" >> $HOME/.bash_profile
source $HOME/.bash_profile

# Завантаження коду completion kubeadm для bash у поточну оболонку
source <(kubeadm completion bash)

# Запишіть код завершення bash у файл і викличте його з .bash_profile
kubeadm completion bash > ~/.kube/kubeadm_completion.bash.inc
printf "\n# Kubeadm shell completion\nsource '$HOME/.kube/kubeadm_completion.bash.inc'\n" >> $HOME/.bash_profile
source $HOME/.bash_profile

# Завантажте код завершення kubeadm для zsh[1] у поточну оболонку
source <(kubeadm completion zsh)

Параметри

-h, --help

Довідка completion

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.36 -

Керування конфігурацією для кластера kubeadm, збереженою у ConfigMap у кластері

Опис

У просторі імен kube-system є ConfigMap з назвою "kubeadm-config", яку kubeadm використовує для зберігання внутрішньої конфігурації кластера. kubeadm CLI v1.8.0+ автоматично створює ConfigMap з конфігурацією, що використовується командою 'kubeadm init', але якщо ви ініціалізували кластер за допомогою kubeadm v1.7.x або нижчої версії, вам слід скористатися командою 'kubeadm init phase upload-config', щоб створити ConfigMap. Це необхідно для того, щоб команда 'kubeadm upgrade' могла правильно налаштувати ваш оновлений кластер.

kubeadm config [flags]

Параметри

-h, --help

Довідка config

--kubeconfig string     Default: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який буде використовуватися при спілкуванні з кластером. Якщо прапорець не встановлено, можна шукати існуючий файл kubeconfig у стандартних місцях.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.36.1 -

Взаємодія з зображеннями контейнерів, які використовує kubeadm

Опис

Взаємодія з зображеннями контейнерів, які використовує kubeadm

kubeadm config images [flags]

Параметри

-h, --help

Доввідка images

Параметри успадковані від батьківських команд

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig для використання при спілкуванні з кластером. Якщо прапорець не встановлено, набір стандартних розташувань може бути перевірений на наявність поточного файлу kubeconfig.

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.36.2 -

Виводить список образів, які буде використовувати kubeadm. Файл конфігурації використовується у випадку налаштування будь-яких образів або сховищ образів

Опис

Виводить список образів, які буде використовувати kubeadm. Файл конфігурації використовується у випадку налаштування будь-яких образів або сховищ образів.

kubeadm config images list [flags]

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли у шаблоні відсутнє поле або ключ мапи. Застосовується тільки до форматів виводу golang і jsonpath.

--config string

Шлях до файлу конфігурації kubeadm.

--feature-gates string

Набір пар ключ=значення, що описують функціональні можливості для різних функцій. Варіанти:
ControlPlaneKubeletLocalMode=true|false (ALPHA — default=false)
EtcdLearnerMode=true|false (BETA — default=true)
PublicKeysECDSA=true|false (DEPRECATED — default=false)
RootlessControlPlane=true|false (ALPHA — default=false)
WaitForAllControlPlaneComponents=true|false (ALPHA — default=false)

-h, --help

довідка list

--image-repository string     Типово: "registry.k8s.io"

Вибрати реєстр контейнерів для завантаження образів панелі управління

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

-o, --output string     Типово: "text"

Формат виводу. Один з: text|json|yaml|go-template|go-template-file|template|templatefile|jsonpath|jsonpath-as-json|jsonpath-file.

--show-managed-fields

Якщо true, зберігати managedFields при виведенні обʼєктів у форматі JSON або YAML.

Параметри успадковані від батьківських команд

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig для використання при спілкуванні з кластером. Якщо прапорець не встановлено, набір стандартних розташувань може бути перевірений на наявність поточного файлу kubeconfig.

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.36.3 -

Витягує образи які використовує kubeadm з реєстру

Опис

Витягує образи які використовує kubeadm з реєстру

kubeadm config images pull [flags]

Параметри

--config string

Шлях до файлу конфігурації kubeadm.

--cri-socket string

Шлях до CRI сокету для підключення. Якщо порожньо, kubeadm спробує автоматично визначити це значення; використовуйте цей параметр лише якщо у вас встановлено більше одного CRI або якщо у вас нестандартний CRI сокет.

--feature-gates string

Набір пар ключ=значення, що описують ворота функцій для різних можливостей. Варіанти:
ControlPlaneKubeletLocalMode=true|false (ALPHA — default=false)
EtcdLearnerMode=true|false (BETA — default=true)
PublicKeysECDSA=true|false (DEPRECATED — default=false)
RootlessControlPlane=true|false (ALPHA — default=false)
WaitForAllControlPlaneComponents=true|false (ALPHA — default=false)

-h, --help

довідка pull

--image-repository string     Типово: "registry.k8s.io"

Вибрати реєстр контейнерів для завантаження образів панелі управління

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig для використання при спілкуванні з кластером. Якщо прапорець не встановлено, набір стандартних розташувань може бути перевірений на наявність поточного файлу kubeconfig.

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.36.4 -

Зчитує стару версію типів конфігураційного API kubeadm з файлу і виводе аналогічний обʼєкт конфігурації для нової версії

Опис

Ця команда дозволяє конвертувати обʼєкти конфігурації старих версій у найновішу підтримувану версію, локально у CLI інструменті, без жодних змін у кластері. У цій версії kubeadm підтримуються наступні версії API:

  • kubeadm.k8s.io/v1beta4

Крім того, kubeadm може записувати конфігурацію лише версії "kubeadm.k8s.io/v1beta4", але читати обидві версії. Отже, незалежно від того, яку версію ви передаєте параметру --old-config, API обʼєкт буде прочитано, десеріалізовано, встановлено стандартні значення, конвертовано, валідовано та повторно серіалізовано під час запису у stdout або --new-config, якщо вказано.

Іншими словами, вихід цієї команди є тим, що kubeadm фактично читав би внутрішньо, якщо ви надіслали б цей файл команді "kubeadm init".

kubeadm config migrate [flags]

Параметри

--allow-experimental-api

Дозволити міграцію на експериментальні, невипущені API

-h, --help

довідка migrate

--new-config string

Шлях до отриманого еквівалентного конфігураційного файлу kubeadm з використанням нової версії API. Необовʼязково, якщо не вказано, вивід буде надіслано у STDOUT.

--old-config string

Шлях до конфігураційного файлу kubeadm, який використовує стару версію API і який має бути конвертований. Цей прапорець є обовʼязковим.

Параметри успадковані від батьківських команд

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig для використання при спілкуванні з кластером. Якщо прапорець не встановлено, набір стандартних розташувань може бути перевірений на наявність поточного файлу kubeconfig.

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.36.5 -

Вивід конфігурації

Опис

Ця команда виводить конфігурацію вказаних субкоманд. Докладніше: https://pkg.go.dev/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm#section-directories

kubeadm config print [flags]

Параметри

-h, --help

довідка print

Параметри успадковані від батьківських команд

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig для використання при спілкуванні з кластером. Якщо прапорець не встановлено, набір стандартних розташувань може бути перевірений на наявність поточного файлу kubeconfig.

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.36.6 -

Вивід стандартної конфігурації ініціалізації, яка може використовуватись у kubeadm init.

Опис

Ця команда виводить обʼєкти, такі як стандартну конфігурацію ініціалізації, які можуть бути використані у kubeadm init.

Зверніть увагу, що конфіденційні значення, такі як поля Bootstrap Token, замінюються значеннями-заповнювачами, такими як abcdef.0123456789abcdef", щоб пройти перевірку, але не виконувати реальні дії для створення токена.

kubeadm config print init-defaults [flags]

Параметри

--component-configs strings

Список обʼєктів API конфігурації компонентів через кому для виводу типових значень. Доступні значення: [KubeProxyConfiguration KubeletConfiguration]. Якщо цей прапорець не встановлено, конфігурації компонентів не буде надруковано.

-h, --help

довідка init-defaults

Параметри успадковані від батьківських команд

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig для використання при спілкуванні з кластером. Якщо прапорець не встановлено, набір стандартних розташувань може бути перевірений на наявність поточного файлу kubeconfig.

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.36.7 -

Вивід стандартної конфігурації для команди kubeadm join.

Опис

Ця команда виводить обʼєкти, такі як стандартна конфігурація команди join, яка використовується для 'kubeadm join'.

Зверніть увагу, що конфіденційні значення, такі як поля Bootstrap Token, замінюються значеннями-заповнювачами, такими як abcdef.0123456789abcdef", щоб пройти перевірку, але не виконувати реальні дії для створення токена.

kubeadm config print join-defaults [flags]

Параметри

-h, --help

довідка join-defaults

Параметри успадковані від батьківських команд

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig для використання при спілкуванні з кластером. Якщо прапорець не встановлено, набір стандартних розташувань може бути перевірений на наявність поточного файлу kubeconfig.

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.36.8 -

Виводить стандартну конфігурацію для команди kubeadm reset.

Опис

Ця команда виводить обʼєкти, такі як стандартна конфігурація команди reset, яка використовується для 'kubeadm reset'.

Зауважте, що конфіденційні значення, такі як поля Bootstrap Token, замінюються значеннями-заповнювачами, такими як "abcdef.0123456789abcdef", щоб пройти перевірку, але не виконувати реальні дії для створення токена.

kubeadm config print reset-defaults [flags]

Параметри

-h, --help

Довідка reset-defaults

Параметри успадковані від батьківських команд

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig для використання при спілкуванні з кластером. Якщо прапорець не встановлено, набір стандартних розташувань може бути перевірений на наявність поточного файлу kubeconfig.

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.36.9 -

Виводить стандартну конфігурацію для оновлення, яка може бути використана для 'kubeadm upgrade'

Опис

Ця команда виводить обʼєкти, такі як стандартна конфігурація команди upgrade, яка використовується для 'kubeadm upgrade'.

Зверніть увагу, що конфіденційні значення, такі як поля Bootstrap Token, замінюються значеннями-заповнювачами, такими як abcdef.0123456789abcdef", щоб пройти перевірку, але не виконувати реальні дії для створення токена.

kubeadm config print upgrade-defaults [flags]

Параметри

-h, --help

Довідка upgrade-defaults

Параметри успадковані від батьківських команд

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig для використання при спілкуванні з кластером. Якщо прапорець не встановлено, набір стандартних розташувань може бути перевірений на наявність поточного файлу kubeconfig.

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.36.10 -

Зчитує файл, що містить конфігураційний API kubeadm, і повідомляє про будь-які проблеми під час валідації

Опис

Ця команда дозволяє перевірити файл конфігурації API kubeadm та повідомити про будь-які попередження та помилки. Якщо помилок немає, статус виводу буде нульовим, в іншому випадку він буде ненульовим. Будь-які проблеми з розбором, такі як невідомі поля API, спричинять помилки. Невідомі версії API та поля з недійсними значеннями також спричинять помилки. Будь-які інші помилки або попередження можуть бути повідомлені залежно від вмісту вхідного файлу.

У цій версії kubeadm підтримуються наступні версії API:

  • kubeadm.k8s.io/v1beta4
kubeadm config validate [flags]

Параметри

--allow-experimental-api

Дозволяє валідацію експериментальних, невипущених API.

--config string

Шлях до файлу конфігурації kubeadm.

-h, --help

довідка validate

Параметри успадковані від батьківських команд

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig для використання при спілкуванні з кластером. Якщо прапорець не встановлено, набір стандартних розташувань може бути перевірений на наявність поточного файлу kubeconfig.

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.37 -

Виводить список образів, які буде використовувати kubeadm. Файл конфігурації використовується у випадку налаштування будь-яких образів або сховищ образів

Опис

Виводить список образів, які буде використовувати kubeadm. Файл конфігурації використовується у випадку налаштування будь-яких образів або сховищ образів.

kubeadm config images list [flags]

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли у шаблоні відсутнє поле або ключ мапи. Застосовується тільки до форматів виводу golang і jsonpath.

--config string

Шлях до файлу конфігурації kubeadm.

-o, --experimental-output string     Типово: "text"

Формат виводу. Один з: text|json|yaml|go-template|go-template-file|template|templatefile|jsonpath|jsonpath-as-json|jsonpath-file.

--feature-gates string

Набір пар ключ=значення, що описують функціональні можливості для різних функцій. Варіанти:
EtcdLearnerMode=true|false (BETA — default=true)
PublicKeysECDSA=true|false (DEPRECATED — default=false)
RootlessControlPlane=true|false (ALPHA — default=false)
UpgradeAddonsBeforeControlPlane=true|false (DEPRECATED — default=false)
WaitForAllControlPlaneComponents=true|false (ALPHA — default=false)

-h, --help

довідка list

--image-repository string     Типово: "registry.k8s.io"

Вибрати реєстр контейнерів для завантаження образів панелі управління

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

--show-managed-fields

Якщо true, зберігати managedFields при виведенні обʼєктів у форматі JSON або YAML.

Параметри успадковані від батьківських команд

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig для використання при спілкуванні з кластером. Якщо прапорець не встановлено, набір стандартних розташувань може бути перевірений на наявність поточного файлу kubeconfig.

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.38 -

Витягує образи які використовує kubeadm з реєстру

Опис

Витягує образи які використовує kubeadm з реєстру

kubeadm config images pull [flags]

Параметри

--config string

Шлях до файлу конфігурації kubeadm.

--cri-socket string

Шлях до CRI сокету для підключення. Якщо порожньо, kubeadm спробує автоматично визначити це значення; використовуйте цей параметр лише якщо у вас встановлено більше одного CRI або якщо у вас нестандартний CRI сокет.

--feature-gates string

Набір пар ключ=значення, що описують ворота функцій для різних можливостей. Варіанти:
EtcdLearnerMode=true|false (BETA — default=true)
PublicKeysECDSA=true|false (DEPRECATED — default=false)
RootlessControlPlane=true|false (ALPHA — default=false)
UpgradeAddonsBeforeControlPlane=true|false (DEPRECATED — default=false)
WaitForAllControlPlaneComponents=true|false (ALPHA — default=false)

-h, --help

довідка pull

--image-repository string     Типово: "registry.k8s.io"

Вибрати реєстр контейнерів для завантаження образів панелі управління

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig для використання при спілкуванні з кластером. Якщо прапорець не встановлено, набір стандартних розташувань може бути перевірений на наявність поточного файлу kubeconfig.

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.39 -

Зчитує стару версію типів конфігураційного API kubeadm з файлу і виводе аналогічний обʼєкт конфігурації для нової версії

Опис

Ця команда дозволяє конвертувати обʼєкти конфігурації старих версій у найновішу підтримувану версію, локально у CLI інструменті, без жодних змін у кластері. У цій версії kubeadm підтримуються наступні версії API:

  • kubeadm.k8s.io/v1beta3

Крім того, kubeadm може записувати конфігурацію лише версії "kubeadm.k8s.io/v1beta3", але читати обидві версії. Отже, незалежно від того, яку версію ви передаєте параметру --old-config, API обʼєкт буде прочитано, десеріалізовано, встановлено стандартні значення, конвертовано, валідовано та повторно серіалізовано під час запису у stdout або --new-config, якщо вказано.

Іншими словами, вихід цієї команди є тим, що kubeadm фактично читав би внутрішньо, якщо ви надіслали б цей файл команді "kubeadm init".

kubeadm config migrate [flags]

Параметри

--allow-experimental-api

Дозволити міграцію на експериментальні, невипущені API

-h, --help

довідка migrate

--new-config string

Шлях до отриманого еквівалентного конфігураційного файлу kubeadm з використанням нової версії API. Необовʼязково, якщо не вказано, вивід буде надіслано у STDOUT.

--old-config string

Шлях до конфігураційного файлу kubeadm, який використовує стару версію API і який має бути конвертований. Цей прапорець є обовʼязковим.

Параметри успадковані від батьківських команд

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig для використання при спілкуванні з кластером. Якщо прапорець не встановлено, набір стандартних розташувань може бути перевірений на наявність поточного файлу kubeconfig.

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.40 -

Вивід конфігурації

Опис

Ця команда виводить конфігурацію вказаних субкоманд. Докладніше: https://pkg.go.dev/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm#section-directories

kubeadm config print [flags]

Параметри

-h, --help

довідка print

Параметри успадковані від батьківських команд

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig для використання при спілкуванні з кластером. Якщо прапорець не встановлено, набір стандартних розташувань може бути перевірений на наявність поточного файлу kubeconfig.

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.41 -

Вивід стандартної конфігурації ініціалізації, яка може використовуватись у kubeadm init.

Опис

Ця команда виводить обʼєкти, такі як стандартну конфігурацію ініціалізації, які можуть бути використані у kubeadm init.

Зверніть увагу, що конфіденційні значення, такі як поля Bootstrap Token, замінюються значеннями-заповнювачами, такими як abcdef.0123456789abcdef", щоб пройти перевірку, але не виконувати реальні дії для створення токена.

kubeadm config print init-defaults [flags]

Параметри

--component-configs strings

Список обʼєктів API конфігурації компонентів через кому для виводу типових значень. Доступні значення: [KubeProxyConfiguration KubeletConfiguration]. Якщо цей прапорець не встановлено, конфігурації компонентів не буде надруковано.

-h, --help

довідка init-defaults

Параметри успадковані від батьківських команд

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig для використання при спілкуванні з кластером. Якщо прапорець не встановлено, набір стандартних розташувань може бути перевірений на наявність поточного файлу kubeconfig.

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.42 -

Вивід стандартної конфігурації для команди kubeadm join.

Опис

Ця команда виводить обʼєкти, такі як стандартна конфігурація команди join, яка використовується для 'kubeadm join'.

Зверніть увагу, що конфіденційні значення, такі як поля Bootstrap Token, замінюються значеннями-заповнювачами, такими як abcdef.0123456789abcdef", щоб пройти перевірку, але не виконувати реальні дії для створення токена.

kubeadm config print join-defaults [flags]

Параметри

-h, --help

довідка join-defaults

Параметри успадковані від батьківських команд

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig для використання при спілкуванні з кластером. Якщо прапорець не встановлено, набір стандартних розташувань може бути перевірений на наявність поточного файлу kubeconfig.

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.43 -

Зчитує файл, що містить конфігураційний API kubeadm, і повідомляє про будь-які проблеми під час валідації

Опис

Ця команда дозволяє перевірити файл конфігурації API kubeadm та повідомити про будь-які попередження та помилки. Якщо помилок немає, статус виводу буде нульовим, в іншому випадку він буде ненульовим. Будь-які проблеми з розбором, такі як невідомі поля API, спричинять помилки. Невідомі версії API та поля з недійсними значеннями також спричинять помилки. Будь-які інші помилки або попередження можуть бути повідомлені залежно від вмісту вхідного файлу.

У цій версії kubeadm підтримуються наступні версії API:

  • kubeadm.k8s.io/v1beta3
kubeadm config validate [flags]

Параметри

--allow-experimental-api

Дозволяє валідацію експериментальних, невипущених API.

--config string

Шлях до файлу конфігурації kubeadm.

-h, --help

довідка validate

Параметри успадковані від батьківських команд

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig для використання при спілкуванні з кластером. Якщо прапорець не встановлено, набір стандартних розташувань може бути перевірений на наявність поточного файлу kubeconfig.

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.44 -

Запустіть цю команду, щоб налаштувати панель управління Kubernetes

Опис

Запустіть цю команду, щоб налаштувати панель управління Kubernetes

Команда "init" виконує наступні етапи:

preflight                     Виконання перевірок перед запуском
certs                         Генерація сертифікатів
  /ca                           Генерація самопідписаного CA Kubernetes для забезпечення ідентифікації інших компонентів Kubernetes
  /apiserver                    Генерація сертифіката для обслуговування Kubernetes API
  /apiserver-kubelet-client     Генерація сертифіката для зʼєднання API server з kubelet
  /front-proxy-ca               Генерація самопідписаного CA для забезпечення ідентифікації front proxy
  /front-proxy-client           Генерація сертифіката для клієнта front proxy
  /etcd-ca                      Генерація самопідписаного CA для забезпечення ідентифікації etcd
  /etcd-server                  Генерація сертифіката для обслуговування etcd
  /etcd-peer                    Генерація сертифіката для звʼязку між вузлами etcd
  /etcd-healthcheck-client      Генерація сертифіката для перевірки живучості etcd
  /apiserver-etcd-client        Генерація сертифіката, який використовується apiserver для доступу до etcd
  /sa                           Генерація приватного ключа для підписання токенів службових облікових записів разом з його відкритим ключем
kubeconfig                    Генерація всіх kubeconfig файлів, необхідних для створення панелі управління, та kubeconfig файлу адміністратора
  /admin                        Генерація kubeconfig файлу для використання адміністратором та самим kubeadm
  /super-admin                  Генерація kubeconfig файлу для супер-адміністратора
  /kubelet                      Генерація kubeconfig файлу для використання kubelet *лише* для завантаження кластера
  /controller-manager           Генерація kubeconfig файлу для використання контролер-менеджером
  /scheduler                    Генерація kubeconfig файлу для використання планувальником
etcd                          Генерація маніфесту статичного Pod для локального etcd
  /local                        Генерація маніфесту статичного Pod для локального, одновузлового локального etcd
control-plane                 Генерація всіх маніфестів статичних Podʼів, необхідних для створення панелі управління
  /apiserver                    Генерація маніфесту статичного Pod для kube-apiserver
  /controller-manager           Генерація маніфесту статичного Pod для kube-controller-manager
  /scheduler                    Генерація маніфесту статичного Pod для kube-scheduler
kubelet-start                 Запис налаштувань kubelet та (перезавантаження) kubelet
upload-config                 Завантаження конфігурації kubeadm та kubelet у ConfigMap
  /kubeadm                      Завантаження конфігурації кластера kubeadm у ConfigMap
  /kubelet                      Завантаження конфігурації компоненту kubelet у ConfigMap
upload-certs                  Завантаження сертифікатів у kubeadm-certs
mark-control-plane            Маркування вузла як вузла панелі управління
bootstrap-token               Генерація bootstrap токенів, які використовуються для приєднання вузла до кластера
kubelet-finalize             Оновлення налаштувань, що стосуються kubelet, після TLS завантаження
  /enable-client-cert-rotation  Ввімкнути ротацію сертифікатів клієнтів kubelet
  /experimental-cert-rotation   Ввімкнути ротацію сертифікатів клієнтів kubelet (ЗАСТАРІЛО: натомість використовуйте 'enable-client-cert-rotation')
  /experimental-cert-rotation  Увімкнення ротації сертифікатів клієнта kubelet
addon                        Встановлення необхідних надбудов для проходження тестів відповідності
  /coredns                     Встановлення надбудови CoreDNS у Kubernetes кластер
  /kube-proxy                  Встановлення надбудови kube-proxy у Kubernetes кластер
show-join-command            Показати команду приєднання для вузлів керування та робочих вузлів
kubeadm init [прапорці]

Параметри

--apiserver-advertise-address string

IP адреса, за якою API Server буде оголошувати, що він слухає. Якщо не встановлено, буде використаний стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого буде привʼязаний API Server.

--apiserver-cert-extra-sans strings

Додаткові опціональні альтернативні імена субʼєкта (SANs) для використання в сертифікаті обслуговування API Server. Можуть бути як IP-адреси, так і DNS імена.

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях для збереження та зберігання сертифікатів.

--certificate-key string

Ключ, що використовується для шифрування сертифікатів панелі управління у Secret kubeadm-certs. Ключ сертифіката — це шістнадцятковий рядок, який є ключем AES розміром 32 байти

--config string

Шлях до файлу конфігурації kubeadm.

--control-plane-endpoint string

Вкажіть стабільну IP адресу або DNS імʼя для панелі управління.

--cri-socket string

Шлях до сокета CRI для підключення. Якщо не заповнено, kubeadm спробує автоматично визначити це значення; використовуйте цю опцію тільки якщо у вас встановлено більше одного CRI або якщо у вас нестандартний сокет CRI.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

--feature-gates string

Набір пар ключ=значення, що описують функціональні можливості для різних функцій. Опції:
ControlPlaneKubeletLocalMode=true|false (ALPHA — default=false)
EtcdLearnerMode=true|false (BETA — default=true)
PublicKeysECDSA=true|false (DEPRECATED — default=false)
RootlessControlPlane=true|false (ALPHA — default=false)
WaitForAllControlPlaneComponents=true|false (ALPHA — default=false)

-h, --help

довідка init

--ignore-preflight-errors strings

Список перевірок, помилки яких будуть показані як попередження. Приклад: 'IsPrivilegedUser,Swap'. Значення 'all' ігнорує помилки всіх перевірок.

--image-repository string     Типово: "registry.k8s.io"

Виберіть реєстр контейнерів для завантаження образів панелі управління

--kubernetes-version string     Типово: "stable-1"

Виберіть конкретну версію Kubernetes для панелі управління.

--node-name string

Вкажіть імʼя вузла.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

--pod-network-cidr string

Вкажіть діапазон IP-адрес для мережі Podʼів. Якщо встановлено, панель управління автоматично виділить CIDR для кожного вузла.

--service-cidr string     Типово: "10.96.0.0/12"

Використовуйте альтернативний діапазон IP-адрес для VIP сервісів.

--service-dns-domain string     Типово: "cluster.local"

Використовуйте альтернативний домен для сервісів, наприклад "myorg.internal".

--skip-certificate-key-print

Не виводити ключ, який використовується для шифрування сертифікатів панелі управління.

--skip-phases strings

Список етапів, які потрібно оминути

--skip-token-print

Пропустити друк стандартного bootstrap токена, згенерованого 'kubeadm init'.

--token string

Токен для встановлення двосторонньої довіри між вузлами та вузлами панелі управління. Формат [a-z0-9]{6}.[a-z0-9]{16} — наприклад, abcdef.0123456789abcdef

--token-ttl duration     Типово: 24h0m0s

Час перед автоматичним видаленням токена (наприклад, 1s, 2m, 3h). Якщо встановлено '0', токен ніколи не закінчиться

--upload-certs

Завантажити сертифікати панелі управління у Secret kubeadm-certs.

Параметри успадковані від батьківських команд

--rootfs string

[ЕКСПЕРИМЕНТАЛЬНО] Шлях до 'реальної' кореневої файлової системи хоста.

6.10.1.1.44.1 -

Використовуйте цю команду для виклику однієї фази робочого процесу init

Опис

Використовуйте цю команду для виклику однієї фази робочого процесу init.

Параметри

-h, --help

Довідка phase

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.44.2 -

Встановлює необхідні надбудови для проходження тестів на відповідність

Опис

Ця команда не призначена для самостійного запуску. Дивіться список доступних субкоманд.

kubeadm init phase addon [flags]

Параметри

-h, --help

Довідка addon

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.44.3 -

Встановлює всі надбудови

Опис

Вставляє всі надбудови.

kubeadm init phase addon all [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

--feature-gates string

Набір пар ключ=значення, що описують функціональні можливості для різних функцій. Опції:
ControlPlaneKubeletLocalMode=true|false (ALPHA — default=false)
EtcdLearnerMode=true|false (BETA — default=true)
PublicKeysECDSA=true|false (DEPRECATED — default=false)
RootlessControlPlane=true|false (ALPHA — default=false)
WaitForAllControlPlaneComponents=true|false (ALPHA — default=false)

-h, --help

Довідка all

--image-repository string     Типово: "registry.k8s.io"

Вибір реєстру контейнерів для завантаження образів панелі управління

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

--kubernetes-version string     Типово: "stable-1"

Вибір конкретної версії Kubernetes для панелі управління.

--pod-network-cidr string

Вказує діапазон IP-адрес для мережі Pod. Якщо встановлено, панель управління автоматично виділить CIDR для кожного вузла.

--service-cidr string     Типово: "10.96.0.0/12"

Використовуйте альтернативний діапазон IP-адрес для сервісів VIP.

--service-dns-domain string     Типово: "cluster.local"

Використовуйте альтернативний домен для сервісів, наприклад, "myorg.internal".

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.44.4 -

Встановлює надбудову CoreDNS в кластер Kubernetes

Опис

Встановлює компоненти надбудови CoreDNS через сервер API. Зверніть увагу, що хоча DNS-сервер розгорнуто, його не буде заплановано, доки не буде встановлено CNI.

kubeadm init phase addon coredns [flags]

Параметри

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

--feature-gates string

Набір пар ключ=значення, що описують функціональні можливості для різних функцій. Опції:
ControlPlaneKubeletLocalMode=true|false (ALPHA — default=false)
EtcdLearnerMode=true|false (BETA — default=true)
PublicKeysECDSA=true|false (DEPRECATED — default=false)
RootlessControlPlane=true|false (ALPHA — default=false)
WaitForAllControlPlaneComponents=true|false (ALPHA — default=false)

-h, --help

Довідка coredns

--image-repository string     Типово: "registry.k8s.io"

Вибір реєстру контейнерів для завантаження образів панелі управління

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

--kubernetes-version string     Типово: "stable-1"

Вибір конкретної версії Kubernetes для панелі управління.

--print-manifest

Вивести маніфести надбудов в STDOUT замість їх встановлення

--service-cidr string     Типово: "10.96.0.0/12"

Використовуйте альтернативний діапазон IP-адрес для сервісів VIP.

--service-dns-domain string     Типово: "cluster.local"

Використовуйте альтернативний домен для сервісів, наприклад, "myorg.internal".

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.44.5 -

Встановлює надбудову kube-proxy в кластер Kubernetes

Опис

Встановлює компоненти надбудови kube-proxy через API-сервер.

kubeadm init phase addon kube-proxy [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка kube-proxy

--image-repository string     Типово: "registry.k8s.io"

Виберіть реєстр контейнерів для завантаження образів панелі управління

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

--pod-network-cidr string

Вказує діапазон IP-адрес для мережі Pod. Якщо встановлено, панель управління автоматично виділить CIDR для кожного вузла.

--print-manifest

Вивести маніфести надбудов в STDOUT замість їх встановлення

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.44.6 -

Генерує токени bootstrap, які використовуються для приєднання вузла до кластера

Опис

Токени bootstrap використовуються для встановлення двосторонньої довіри між вузлом, що приєднується до кластера, і вузлом панелі управління.

Ця команда виконує всі налаштування, необхідні для роботи токенів bootstrap, а потім створює початковий токен.

kubeadm init phase bootstrap-token [flags]

Приклади

# Налаштувати всі конфігурації токенів Bootstrap та створити 
# початковий токен, функціонально еквівалентний до того, що 
# генерується командою kubeadm init.
kubeadm init phase bootstrap-token

Параметри

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

Довідка bootstrap-token

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

--skip-token-print

Пропустити друк стандартного bootstrap токена, згенерованого 'kubeadm init'.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.44.7 -

Генерує сертифікати

Опис

Ця команда не призначена для самостійного запуску. Дивіться список доступних підкоманд.

kubeadm init phase certs [flags]

Параметри

-h, --help

Довідка certs

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.44.8 -

Генерує всі сертифікати

Опис

Генерує всі сертифікати.

kubeadm init phase certs all [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-cert-extra-sans strings

Додаткові опціональні альтернативні імена субʼєкта (SANs) для використання в сертифікаті обслуговування API Server. Можуть бути як IP-адреси, так і DNS імена.

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка all

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

--service-cidr string     Типово: "10.96.0.0/12"

Використовуйте альтернативний діапазон IP-адрес для сервісів VIP.

--service-dns-domain string     Типово: "cluster.local"

Використовуйте альтернативний домен для сервісів, наприклад, "myorg.internal".

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.44.9 -

Генерує сертифікати, які apiserver використовує для доступу до etcd

Опис

Генерує сертифікати, які apiserver використовує для доступу до etcd та зберігає їх у файлах apiserver-etcd-client.crt та apiserver-etcd-client.key

Якщо обидва файли вже існують, kubeadm оминає крок створення і використовує наявні файли.

kubeadm init phase certs apiserver-etcd-client [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка apiserver-etcd-client

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.44.10 -

Генерує сертифікати для сервера API для зʼєднання з kubelet

Опис

Генерує сертифікати для сервера API для зʼєднання з kubelet та зберігає їх у файлах apiserver-kubelet-client.crt та apiserver-kubelet-client.key.

Якщо обидва файли вже існують, kubeadm оминає крок створення і використовує наявні файли.

kubeadm init phase certs apiserver-kubelet-client [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка apiserver-kubelet-client

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.44.11 -

Генерує сертифікати для обслуговування API Kubernetes

Опис

Генерує сертифікати для обслуговування API Kubernetes та зберігає їх у файли apiserver.crt та apiserver.key.

Якщо обидва файли вже існують, kubeadm оминає крок створення і використовує наявні файли.

kubeadm init phase certs apiserver [flags]

Операції

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-cert-extra-sans strings

Додаткові опціональні альтернативні імена субʼєкта (SANs) для використання в сертифікаті обслуговування API Server. Можуть бути як IP-адреси, так і DNS імена.

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка apiserver

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

--service-cidr string     Типово: "10.96.0.0/12"

Використовуйте альтернативний діапазон IP-адрес для сервісів VIP.

--service-dns-domain string     Типово: "cluster.local"

Використовуйте альтернативний домен для сервісів, наприклад, "myorg.internal".

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.44.12 -

Генерує самопідписаний центр сертифікації Kubernetes, щоб надати ідентифікатори для інших компонентів Kubernetes

Опис

Генерує самопідписаний центр сертифікації Kubernetes, щоб надати ідентифікатори для інших компонентів Kubernetes та зберігає їх у файлах ca.crt та ca.key.

Якщо обидва файли вже існують, kubeadm оминає крок створення і використовує наявні файли.

kubeadm init phase certs ca [flags]

Операції

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка ca

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.44.13 -

Генерує самопідписаний центр сертифікації для надання ідентифікаторів для etcd

Опис

Ця команда генерує самопідписаний центр сертифікації (CA) для надання ідентифікаторів для etcd, та зберігає їх у файлах etcd/ca.crt та etcd/ca.key.

Якщо обидва файли вже існують, kubeadm пропускає крок генерації та використовує наявні файли.

kubeadm init phase certs etcd-ca [flags]

Операції

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка etcd-ca

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.44.14 -

Генерує сертифікат для проб життєздатності для перевірки справності etcd

Опис

Генерує сертифікат для проб життєздатності для перевірки справності etcd, та зберігає його у файлах etcd/healthcheck-client.crt та etcd/healthcheck-client.key.

Якщо обидва файли вже існують, kubeadm пропускає крок генерації та використовує наявні файли.

kubeadm init phase certs etcd-healthcheck-client [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка etcd-healthcheck-client

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.44.15 -

Генгерує сертифікати для вузлів etcd для звʼязку між собою

Опис

Генерує сертифікати для вузлів etcd для звʼязку між собою, та зберігає їх у файлах etcd/peer.crt та etcd/peer.key.

Типові SANs: localhost, 127.0.0.1, 127.0.0.1, ::1

Якщо обидва файли вже існують, kubeadm пропускає крок генерації та використовує наявні файли.

kubeadm init phase certs etcd-peer [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка etcd-peer

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.44.16 -

Генерує сертифітати для обслуговування etcd

Опис

Генерує сертифікати для обслуговування etcd, та зберігає їх у файлах etcd/server.crt та etcd/server.key.

Типові SANs: localhost, 127.0.0.1, 127.0.0.1, ::1

Якщо обидва файли вже існують, kubeadm пропускає крок генерації та використовує наявні файли.

kubeadm init phase certs etcd-server [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка etcd-server

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.44.17 -

Генерує самопідписні CA для надання ідентифікаторів для front proxy

Опис

Генерує самопідписні CA для надання ідентифікаторів для front proxy, та зберігає їх у файлах front-proxy-ca.crt та front-proxy-ca.key.

Якщо обидва файли вже існують, kubeadm пропускає крок генерації та використовує наявні файли.

kubeadm init phase certs front-proxy-ca [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка front-proxy-ca

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.44.18 -

Генерує сетритфікати для клієнта front proxy

Опис

Генерує сертифікати для клієнта front proxy, та зберігає їх у файлах front-proxy-client.crt та front-proxy-client.key.

Якщо обидва файли вже існують, kubeadm пропускає крок генерації та використовує наявні файли.

kubeadm init phase certs front-proxy-client [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка front-proxy-client

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.44.19 -

Генерує приватний ключ для підпису токенів службових облікових записів, що дозволяє їм мати власні публічні ключі

Опис

Генерує приватний ключ для підпису токенів службових облікових записів, що дозволяє їм мати власні публічні ключі, та записує їх у файли sa.key та sa.pub.

Якщо обидва файли вже існують, kubeadm пропускає крок генерації та використовує наявні файли.

kubeadm init phase certs sa [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--kubeconfig string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка sa

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.44.20 -

Генерує всі маніфести статичних Podʼів потрібні для створення панелі управління

Опис

Ця команда не призначена для самостійного запуску. Дивіться список доступних субкоманд.

kubeadm init phase control-plane [flags]

Параметри

-h, --help

Довідка control-plane

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.44.21 -

Генерує всі фали маніфестів статичних Podʼів

Опис

Генерує всі файли маніфестів статичних Podʼів.

kubeadm init phase control-plane all [flags]

Приклади

# Генерує всі файли маніфестів статичних Podʼів для компонентів панелі управління,
# функціонально еквівалентні до тих, що генеруються командою kubeadm init.
kubeadm init phase control-plane all

# Генерує всі файли маніфестів статичних Podʼів з використанням опцій, отриманих з конфігураційного файлу.
kubeadm init phase control-plane all --config config.yaml

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

--feature-gates string

Набір пар ключ=значення, що описують функціональні можливості для різних функцій. Варіанти:
ControlPlaneKubeletLocalMode=true|false (ALPHA — default=false)
EtcdLearnerMode=true|false (BETA — default=true)
PublicKeysECDSA=true|false (DEPRECATED — default=false)
RootlessControlPlane=true|false (ALPHA — default=false)
WaitForAllControlPlaneComponents=true|false (ALPHA — default=false)

-h, --help

Довідка all

--image-repository string     Типово: "registry.k8s.io"

Вибрати реєстр контейнерів для завантаження образів панелі управління

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

--pod-network-cidr string

Вказує діапазон IP-адрес для мережі Pod. Якщо встановлено, панель управління автоматично виділить CIDR для кожного вузла.

--service-cidr string     Типово: "10.96.0.0/12"

Використовуйте альтернативний діапазон IP-адрес для сервісів VIP.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.44.22 -

Генерує маніфест статичного Podʼа для kube-apiserver

Опис

Генерує маніфест статичного Podʼа для kube-apiserver

kubeadm init phase control-plane apiserver [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

--feature-gates string

Набір пар ключ=значення, що описують функціональні можливості для різних функцій. Варіанти:
ControlPlaneKubeletLocalMode=true|false (ALPHA — default=false)
EtcdLearnerMode=true|false (BETA — default=true)
PublicKeysECDSA=true|false (DEPRECATED — default=false)
RootlessControlPlane=true|false (ALPHA — default=false)
WaitForAllControlPlaneComponents=true|false (ALPHA — default=false)

-h, --help

Довідка apiserver

--image-repository string     Типово: "registry.k8s.io"

Вибрати реєстр контейнерів для завантаження образів панелі управління

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

--service-cidr string     Типово: "10.96.0.0/12"

Використовуйте альтернативний діапазон IP-адрес для сервісів VIP.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.44.23 -

Генерує маніфест статичного Podʼа для kube-controller-manager

Опис

Генерує маніфест статичного Podʼа для kube-controller-manager

kubeadm init phase control-plane controller-manager [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка controller-manager

--image-repository string     Типово: "registry.k8s.io"

Вибрати реєстр контейнерів для завантаження образів панелі управління

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

--pod-network-cidr string

Вказує діапазон IP-адрес для мережі Pod. Якщо встановлено, панель управління автоматично виділить CIDR для кожного вузла.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.44.24 -

Генерує маніфест статичного Podʼа для kube-scheduler

Опис

Генерує маніфест статичного Podʼа для kube-scheduler

kubeadm init phase control-plane scheduler [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-o, --experimental-output string     Типово: "text"

Формат виводу. Один з: text|json|yaml|go-template|go-template-file|template|templatefile|jsonpath|jsonpath-as-json|jsonpath-file.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка scheduler

--image-repository string     Типово: "registry.k8s.io"

Вибрати реєстр контейнерів для завантаження образів панелі управління

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.44.25 -

Генерує файл маніфесту статичного Podʼа для екземпляра local etcd

Опис

Ця команда не призначена для самостійного запуску. Дивіться список доступних субкоманд.

kubeadm init phase etcd [flags]

Параметри

-h, --help

Довідка etcd

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.44.26 -

Генерує файл маніфесту статичного Podʼа для екземпляра local, одновузлового local etcd

Опис

Генерує файл маніфесту статичного Podʼа для екземпляра local, одновузлового local etcd

kubeadm init phase etcd local [flags]

Приклади

# Генерує файл маніфесту статичного Podʼа для etcd, функціонально
# еквівалентного до того, що генерується командою kubeadm init.
kubeadm init phase etcd local

# Генерує файл маніфесту статичного Podʼа для etcd з використанням опцій
# отриманих з файлу конфігурації.
kubeadm init phase etcd local --config config.yaml

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка local

--image-repository string     Типово: "registry.k8s.io"

Вибрати реєстр контейнерів для завантаження образів панелі управління

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.44.27 -

Генерує всі файли kubeconfig, необхідні для встановлення панелі управління та файл kubeconfig адміністратора

Опис

Ця команда не призначена для самостійного запуску. Дивіться список доступних субкоманд.

kubeadm init phase kubeconfig [flags]

Параметри

-h, --help

Довідка kubeconfig

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.44.28 -

Генерує файл kubeconfig для використання адміністратором та для самого kubeadm

Опис

Ця команда генерує файл kubeconfig для використання адміністратором та для самого kubeadm й зберігає його у файл admin.conf.

kubeadm init phase kubeconfig admin [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка admin

--kubeconfig-dir string     Типово: "/etc/kubernetes"

Шлях, де буде збережено файл kubeconfig.

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.44.29 -

Генерує всі файли kubeconfig

Опис

Генерує всі файли kubeconfig.

kubeadm init phase kubeconfig all [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка all

--kubeconfig-dir string     Типово: "/etc/kubernetes"

Шлях, де буде збережено файл kubeconfig.

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

--node-name string

Вкажіть імʼя вузла.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.44.30 -

Генерує файл kubeconfig для використання менеджером контролерів

Опис

Генерує файл kubeconfig для використання менеджером контролерів та зберігає його у файл controller-manager.conf.

kubeadm init phase kubeconfig controller-manager [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка controller-manager

--kubeconfig-dir string     Типово: "/etc/kubernetes"

Шлях, де буде збережено файл kubeconfig.

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.44.31 -

Генерує файл kubeconfig, для kubelet для використання лише для потреб початкового завантаження

Опис

Генерує файл kubeconfig, для kubelet для використання лише для потреб початкового завантаження та зберігає його у файлі kubelet.conf.

Зауважте, що цей файл має використовуватись лише для потреб початкового завантаження кластера. Після розгортання панелі управління, ви маєте запросити облікові дані для kubelet через CSR API.

kubeadm init phase kubeconfig kubelet [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка kubelet

--kubeconfig-dir string     Типово: "/etc/kubernetes"

Шлях, де буде збережено файл kubeconfig.

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

--node-name string

Вкажіть імʼя вузла.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.44.32 -

Генерує файл kubeconfig для використання планувальником

Опис

Генерує файл kubeconfig для використання планувальником та зберігає його у файл scheduler.conf.

kubeadm init phase kubeconfig scheduler [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка scheduler

--kubeconfig-dir string     Типово: "/etc/kubernetes"

Шлях, де буде збережено файл kubeconfig.

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.44.33 -

Генерує файл kubeconfig для суперкористувача

Опис

Генерує файл kubeconfig для суперкористувача та зберігає його у файл super-admin.conf.

kubeadm init phase kubeconfig super-admin [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка super-admin

--kubeconfig-dir string     Типово: "/etc/kubernetes"

Шлях, де буде збережено файл kubeconfig.

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.44.34 -

Оновлює налаштування, що стосуються kubelet, після початкового завантаження TLS

Опис

Оновлює налаштування, що стосуються kubelet, після початкового завантаження TLS

kubeadm init phase kubelet-finalize [flags]

Приклади

# Оновлення налаштувань, що стосуються kubelet, після початкового завантаження TLS"
kubeadm init phase kubelet-finalize all --config

Параметри

-h, --help

Довідка kubelet-finalize

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.44.35 -

Запускає всі фази kubelet-finalize

Опис

Запускає всі фази kubelet-finalize.

kubeadm init phase kubelet-finalize all [flags]

Приклади

# Оновлення налаштувань, що стосуються kubelet, після початкового завантаження TLS
kubeadm init phase kubelet-finalize all --config

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка all

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.44.36 -

Вмикає ротацію сертифікатів клієнтів kubelet

Опис

Вмикає ротацію сертифікатів клієнтів kubelet

kubeadm init phase kubelet-finalize enable-client-cert-rotation [flags]

Параметри

Параметри успадковані від батьківських команд

--cert-dir string     Типово: "/var/run/kubernetes"

Тека, в якій знаходяться TLS-сертифікати. Якщо вказано --tls-cert-file та --tls-private-key-file, цей прапорець буде проігноровано.

--config string

Шлях до файлу конфігурації.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка enable-client-cert-rotation

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.44.37 -

Вмикає ротацію сертифікатів клієнтів kubelet (ЗАСТАРІЛО: використовуйте натомість 'enable-client-cert-rotation' )

Опис

Вмикає ротацію сертифікатів клієнтів kubelet (ЗАСТАРІЛО: використовуйте натомість 'enable-client-cert-rotation' )

kubeadm init phase kubelet-finalize experimental-cert-rotation [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка experimental-cert-rotation

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.44.38 -

Записує налаштування kubelet та (пере)запускаємо kubelet

Опис

Записує файл з KubeletConfiguration та файл оточення з налаштуваннями kubelet для конкретного вузла, а потім (пере)запустимо kubelet.

kubeadm init phase kubelet-start [flags]

Приклади

# Записує файл динамічного оточення з прапорами kubelet з файлу InitConfiguration.
kubeadm init phase kubelet-start --config config.yaml

Параметри

--config string

Шлях до конфігураційного файлу kubeadm.

--cri-socket string

Шлях до CRI сокету для підключення. Якщо порожньо, kubeadm спробує автоматично визначити це значення; використовуйте цей параметр лише якщо у вас встановлено більше одного CRI або якщо у вас нестандартний CRI сокет.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка kubelet-start

--image-repository string     Типово: "registry.k8s.io"

Вибрати реєстр контейнерів для завантаження образів панелі управління

--node-name string

Вкажіть імʼя вузла.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.44.39 -

Позначає вузол як вузол панелі управління

Опис

Позначає вузол як вузол панелі управління.

kubeadm init phase mark-control-plane [flags]

Приклади

# Застосовує мітку та taint панелі управління до поточного вузла, функціонально еквівалентно до того, що виконується командою kubeadm init.
kubeadm init phase mark-control-plane --config config.yaml

# Застосовує мітку та taint панелі управління до конкретного вузла
kubeadm init phase mark-control-plane --node-name myNode

Параметри

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка mark-control-plane

--node-name string

Вкажіть імʼя вузла.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.44.40 -

Виконує передпольотні перевірки

Опис

Виконує передпольотні перевірки для kubeadm init.

kubeadm init phase preflight [flags]

Приклади

# Виконує передпольотні перевірки для kubeadm init з конфігураційним файлом config.yaml
kubeadm init phase preflight --config config.yaml

Параметри

--config string

Шлях до конфігураційного файлу kubeadm.

--cri-socket string

Шлях до CRI сокету для підключення. Якщо порожньо, kubeadm спробує автоматично визначити це значення; використовуйте цей параметр лише якщо у вас встановлено більше одного CRI або якщо у вас нестандартний CRI сокет.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка preflight

--ignore-preflight-errors strings

Список перевірок, помилки яких будуть показані як попередження. Приклад: 'IsPrivilegedUser,Swap'. Значення 'all' ігнорує помилки всіх перевірок.

--image-repository string     Типово: "registry.k8s.io"

Вибрати реєстр контейнерів для завантаження образів панелі управління

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.44.41 -

Показує команду join для панелі управління та робочого вузла

Опис

Показує команду join для панелі управління та робочого вузла.

kubeadm init phase show-join-command [flags]

Параметри

-h, --help

Довідка show-join-command

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.44.42 -

Завантажує сертифікати до kubeadm-certs

Опис

Завантажує сертифікати панелі управління в Secret kubeadm-certs

kubeadm init phase upload-certs [flags]

Параметри

--certificate-key string

Ключ, що використовується для шифрування сертифікатів панелі управління у Secret kubeadm-certs. Ключ сертифіката — це шістнадцятковий рядок, який є ключем AES розміром 32 байти

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка upload-certs

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

--skip-certificate-key-print

Не виводити ключ, який використовується для шифрування сертифікатів панелі управління.

--upload-certs

Завантажити сертифікати панелі управління у Secret kubeadm-certs.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.44.43 -

Завантажує конфігурації kubeadm та kubelet у ConfigMap

Опис

Ця команда не призначена для самостійного запуску. Дивіться список доступних субкоманд.

kubeadm init phase upload-config [flags]

Параметри

-h, --help

Довідка upload-config

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.44.44 -

Завантажуємо всю конфігурацію в ConfigMap

Опис

Завантажує всю конфігурацію в ConfigMap.

kubeadm init phase upload-config all [flags]

Параметри

--config string

Шлях до конфігураційного файлу kubeadm.

--cri-socket string

Шлях до CRI сокету для підключення. Якщо порожньо, kubeadm спробує автоматично визначити це значення; використовуйте цей параметр лише якщо у вас встановлено більше одного CRI або якщо у вас нестандартний CRI сокет.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка all

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.44.45 -

Завантажує kubeadm ClusterConfiguration у ConfigMap

Опис

Завантажує конфігурацію кластера kubeadm ClusterConfig до ConfigMap з назвою kubeadm-config у просторі імен kube-system. Це дозволить правильно конфігурувати компоненти системи та спростить роботу користувачів під час оновлення.

Альтернативно, ви можете використовувати kubeadm config.

kubeadm init phase upload-config kubeadm [flags]

Приклади

# Завантаження конфігурації кластера
kubeadm init phase upload-config kubeadm --config=myConfig.yaml

Параметри

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

--cri-socket string

Шлях до CRI сокету для підключення. Якщо порожньо, kubeadm спробує автоматично визначити це значення; використовуйте цей параметр лише якщо у вас встановлено більше одного CRI або якщо у вас нестандартний CRI сокет.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка kubeadm

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.44.46 -

Завантажує налаштування компонентів kubelet у ConfigMap

Опис

Завантажуємо конфігурацію kubelet, видобуту з обʼєкта kubeadm InitConfiguration, до ConfigMap kubelet-config у кластері

kubeadm init phase upload-config kubelet [flags]

Приклади

# Завантаження конфігурації kubelet з файла конфігурації kubeadm у ConfigMap в кластері
kubeadm init phase upload-config kubelet --config kubeadm.yaml

Параметри

--config string

Шлях до конфігураційного файлу kubeadm.

--cri-socket string

Шлях до CRI сокету для підключення. Якщо порожньо, kubeadm спробує автоматично визначити це значення; використовуйте цей параметр лише якщо у вас встановлено більше одного CRI або якщо у вас нестандартний CRI сокет.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка kubelet

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.45 -

Використовуйте цю команду для виклику однієї фази робочого процесу init

Опис

Використовуйте цю команду для виклику однієї фази робочого процесу init.

Параметри

-h, --help

Довідка phase

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.46 -

Встановлює необхідні надбудови для проходження тестів на відповідність

Опис

Ця команда не призначена для самостійного запуску. Дивіться список доступних субкоманд.

kubeadm init phase addon [flags]

Параметри

-h, --help

Довідка addon

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.47 -

Встановлює всі надбудови

Опис

Вставляє всі надбудови.

kubeadm init phase addon all [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

--feature-gates string

Набір пар ключ=значення, що описують функціональні можливості для різних функцій. Опції:
EtcdLearnerMode=true|false (BETA — default=true)
PublicKeysECDSA=true|false (DEPRECATED — default=false)
RootlessControlPlane=true|false (ALPHA — default=false)
UpgradeAddonsBeforeControlPlane=true|false (DEPRECATED — default=false)
WaitForAllControlPlaneComponents=true|false (ALPHA — default=false)

-h, --help

Довідка all

--image-repository string     Типово: "registry.k8s.io"

Вибір реєстру контейнерів для завантаження образів панелі управління

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

--kubernetes-version string     Типово: "stable-1"

Вибір конкретної версії Kubernetes для панелі управління.

--pod-network-cidr string

Вказує діапазон IP-адрес для мережі Pod. Якщо встановлено, панель управління автоматично виділить CIDR для кожного вузла.

--service-cidr string     Типово: "10.96.0.0/12"

Використовуйте альтернативний діапазон IP-адрес для сервісів VIP.

--service-dns-domain string     Типово: "cluster.local"

Використовуйте альтернативний домен для сервісів, наприклад, "myorg.internal".

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.48 -

Встановлює надбудову CoreDNS в кластер Kubernetes

Опис

Встановлює компоненти надбудови CoreDNS через сервер API. Зверніть увагу, що хоча DNS-сервер розгорнуто, його не буде заплановано, доки не буде встановлено CNI.

kubeadm init phase addon coredns [flags]

Параметри

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

--feature-gates string

Набір пар ключ=значення, що описують функціональні можливості для різних функцій. Опції:
EtcdLearnerMode=true|false (BETA — default=true)
PublicKeysECDSA=true|false (DEPRECATED — default=false)
RootlessControlPlane=true|false (ALPHA — default=false)
UpgradeAddonsBeforeControlPlane=true|false (DEPRECATED — default=false)
WaitForAllControlPlaneComponents=true|false (ALPHA — default=false)

-h, --help

Довідка coredns

--image-repository string     Типово: "registry.k8s.io"

Вибір реєстру контейнерів для завантаження образів панелі управління

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

--kubernetes-version string     Типово: "stable-1"

Вибір конкретної версії Kubernetes для панелі управління.

--print-manifest

Вивести маніфести надбудов в STDOUT замість їх встановлення

--service-cidr string     Типово: "10.96.0.0/12"

Використовуйте альтернативний діапазон IP-адрес для сервісів VIP.

--service-dns-domain string     Типово: "cluster.local"

Використовуйте альтернативний домен для сервісів, наприклад, "myorg.internal".

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.49 -

Встановлює надбудову kube-proxy в кластер Kubernetes

Опис

Встановлює компоненти надбудови kube-proxy через API-сервер.

kubeadm init phase addon kube-proxy [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка kube-proxy

--image-repository string     Типово: "registry.k8s.io"

Виберіть реєстр контейнерів для завантаження образів панелі управління

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

--pod-network-cidr string

Вказує діапазон IP-адрес для мережі Pod. Якщо встановлено, панель управління автоматично виділить CIDR для кожного вузла.

--print-manifest

Вивести маніфести надбудов в STDOUT замість їх встановлення

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.50 -

Генерує токени bootstrap, які використовуються для приєднання вузла до кластера

Опис

Токени bootstrap використовуються для встановлення двосторонньої довіри між вузлом, що приєднується до кластера, і вузлом панелі управління.

Ця команда виконує всі налаштування, необхідні для роботи токенів bootstrap, а потім створює початковий токен.

kubeadm init phase bootstrap-token [flags]

Приклади

# Налаштувати всі конфігурації токенів Bootstrap та створити 
# початковий токен, функціонально еквівалентний до того, що 
# генерується командою kubeadm init.
kubeadm init phase bootstrap-token

Параметри

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

Довідка bootstrap-token

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

--skip-token-print

Пропустити друк стандартного bootstrap токена, згенерованого 'kubeadm init'.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.51 -

Генерує сертифікати

Опис

Ця команда не призначена для самостійного запуску. Дивіться список доступних підкоманд.

kubeadm init phase certs [flags]

Параметри

-h, --help

Довідка certs

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.52 -

Генерує всі сертифікати

Опис

Генерує всі сертифікати.

kubeadm init phase certs all [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-cert-extra-sans strings

Додаткові опціональні альтернативні імена субʼєкта (SANs) для використання в сертифікаті обслуговування API Server. Можуть бути як IP-адреси, так і DNS імена.

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка all

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

--service-cidr string     Типово: "10.96.0.0/12"

Використовуйте альтернативний діапазон IP-адрес для сервісів VIP.

--service-dns-domain string     Типово: "cluster.local"

Використовуйте альтернативний домен для сервісів, наприклад, "myorg.internal".

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.53 -

Генерує сертифікати, які apiserver використовує для доступу до etcd

Опис

Генерує сертифікати, які apiserver використовує для доступу до etcd та зберігає їх у файлах apiserver-etcd-client.crt та apiserver-etcd-client.key

Якщо обидва файли вже існують, kubeadm оминає крок створення і використовує наявні файли.

kubeadm init phase certs apiserver-etcd-client [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка apiserver-etcd-client

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.54 -

Генерує сертифікати для сервера API для зʼєднання з kubelet

Опис

Генерує сертифікати для сервера API для зʼєднання з kubelet та зберігає їх у файлах apiserver-kubelet-client.crt та apiserver-kubelet-client.key.

Якщо обидва файли вже існують, kubeadm оминає крок створення і використовує наявні файли.

kubeadm init phase certs apiserver-kubelet-client [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка apiserver-kubelet-client

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.55 -

Генерує сертифікати для обслуговування API Kubernetes

Опис

Генерує сертифікати для обслуговування API Kubernetes та зберігає їх у файли apiserver.crt та apiserver.key.

Якщо обидва файли вже існують, kubeadm оминає крок створення і використовує наявні файли.

kubeadm init phase certs apiserver [flags]

Операції

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-cert-extra-sans strings

Додаткові опціональні альтернативні імена субʼєкта (SANs) для використання в сертифікаті обслуговування API Server. Можуть бути як IP-адреси, так і DNS імена.

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка apiserver

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

--service-cidr string     Типово: "10.96.0.0/12"

Використовуйте альтернативний діапазон IP-адрес для сервісів VIP.

--service-dns-domain string     Типово: "cluster.local"

Використовуйте альтернативний домен для сервісів, наприклад, "myorg.internal".

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.56 -

Генерує самопідписаний центр сертифікації Kubernetes, щоб надати ідентифікатори для інших компонентів Kubernetes

Опис

Генерує самопідписаний центр сертифікації Kubernetes, щоб надати ідентифікатори для інших компонентів Kubernetes та зберігає їх у файлах ca.crt та ca.key.

Якщо обидва файли вже існують, kubeadm оминає крок створення і використовує наявні файли.

kubeadm init phase certs ca [flags]

Операції

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка ca

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.57 -

Генерує самопідписаний центр сертифікації для надання ідентифікаторів для etcd

Опис

Ця команда генерує самопідписаний центр сертифікації (CA) для надання ідентифікаторів для etcd, та зберігає їх у файлах etcd/ca.crt та etcd/ca.key.

Якщо обидва файли вже існують, kubeadm пропускає крок генерації та використовує наявні файли.

kubeadm init phase certs etcd-ca [flags]

Операції

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка etcd-ca

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.58 -

Генерує сертифікат для проб життєздатності для перевірки справності etcd

Опис

Генерує сертифікат для проб життєздатності для перевірки справності etcd, та зберігає його у файлах etcd/healthcheck-client.crt та etcd/healthcheck-client.key.

Якщо обидва файли вже існують, kubeadm пропускає крок генерації та використовує наявні файли.

kubeadm init phase certs etcd-healthcheck-client [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка etcd-healthcheck-client

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.59 -

Генгерує сертифікати для вузлів etcd для звʼязку між собою

Опис

Генерує сертифікати для вузлів etcd для звʼязку між собою, та зберігає їх у файлах etcd/peer.crt та etcd/peer.key.

Типові SANs: localhost, 127.0.0.1, 127.0.0.1, ::1

Якщо обидва файли вже існують, kubeadm пропускає крок генерації та використовує наявні файли.

kubeadm init phase certs etcd-peer [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка etcd-peer

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.60 -

Генерує сертифітати для обслуговування etcd

Опис

Генерує сертифікати для обслуговування etcd, та зберігає їх у файлах etcd/server.crt та etcd/server.key.

Типові SANs: localhost, 127.0.0.1, 127.0.0.1, ::1

Якщо обидва файли вже існують, kubeadm пропускає крок генерації та використовує наявні файли.

kubeadm init phase certs etcd-server [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка etcd-server

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.61 -

Генерує самопідписні CA для надання ідентифікаторів для front proxy

Опис

Генерує самопідписні CA для надання ідентифікаторів для front proxy, та зберігає їх у файлах front-proxy-ca.crt та front-proxy-ca.key.

Якщо обидва файли вже існують, kubeadm пропускає крок генерації та використовує наявні файли.

kubeadm init phase certs front-proxy-ca [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка front-proxy-ca

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.62 -

Генерує сетритфікати для клієнта front proxy

Опис

Генерує сертифікати для клієнта front proxy, та зберігає їх у файлах front-proxy-client.crt та front-proxy-client.key.

Якщо обидва файли вже існують, kubeadm пропускає крок генерації та використовує наявні файли.

kubeadm init phase certs front-proxy-client [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка front-proxy-client

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.63 -

Генерує приватний ключ для підпису токенів службових облікових записів, що дозволяє їм мати власні публічні ключі

Опис

Генерує приватний ключ для підпису токенів службових облікових записів, що дозволяє їм мати власні публічні ключі, та записує їх у файли sa.key та sa.pub.

Якщо обидва файли вже існують, kubeadm пропускає крок генерації та використовує наявні файли.

kubeadm init phase certs sa [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

-h, --help

Довідка sa

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.64 -

Генерує всі маніфести статичних Podʼів потрібні для створення панелі управління

Опис

Ця команда не призначена для самостійного запуску. Дивіться список доступних субкоманд.

kubeadm init phase control-plane [flags]

Параметри

-h, --help

Довідка control-plane

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.65 -

Генерує всі фали маніфестів статичних Podʼів

Опис

Генерує всі файли маніфестів статичних Podʼів.

kubeadm init phase control-plane all [flags]

Приклади

# Генерує всі файли маніфестів статичних Podʼів для компонентів панелі управління,
# функціонально еквівалентні до тих, що генеруються командою kubeadm init.
kubeadm init phase control-plane all

# Генерує всі файли маніфестів статичних Podʼів з використанням опцій, отриманих з конфігураційного файлу.
kubeadm init phase control-plane all --config config.yaml

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--apiserver-extra-args <пари 'ключ=значення', розділені комами>

Набір додаткових параметрів для передачі до API Server або для перевизначення стандартних у форматі <імʼя_параметра>=<значення>

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--controller-manager-extra-args <пари 'ключ=значення', розділені комами>

Набір додаткових параметрів для передачі до Controller Manager або для перевизначення стандартних у форматі <імʼя_параметра>=<значення>

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

--feature-gates string

Набір пар ключ=значення, що описують функціональні можливості для різних функцій. Варіанти:
EtcdLearnerMode=true|false (BETA — default=true)
PublicKeysECDSA=true|false (DEPRECATED — default=false)
RootlessControlPlane=true|false (ALPHA — default=false)
UpgradeAddonsBeforeControlPlane=true|false (DEPRECATED — default=false)
WaitForAllControlPlaneComponents=true|false (ALPHA — default=false)

-h, --help

Довідка all

--image-repository string     Типово: "registry.k8s.io"

Вибрати реєстр контейнерів для завантаження образів панелі управління

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

--pod-network-cidr string

Вказує діапазон IP-адрес для мережі Pod. Якщо встановлено, панель управління автоматично виділить CIDR для кожного вузла.

--scheduler-extra-args <пари 'ключ=значення', розділені комами>

Набір додаткових параметрів для передачі до Scheduler або для перевизначення стандартних у форматі <імʼя_параметра>=<значення>

--service-cidr string     Типово: "10.96.0.0/12"

Використовуйте альтернативний діапазон IP-адрес для сервісів VIP.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.66 -

Генерує маніфест статичного Podʼа для kube-apiserver

Опис

Генерує маніфест статичного Podʼа для kube-apiserver

kubeadm init phase control-plane apiserver [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--apiserver-extra-args <пари 'ключ=значення', розділені комами>

Набір додаткових параметрів для передачі до API Server або для перевизначення стандартних у форматі <імʼя_параметра>=<значення>

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

--feature-gates string

Набір пар ключ=значення, що описують функціональні можливості для різних функцій. Варіанти:
EtcdLearnerMode=true|false (BETA — default=true)
PublicKeysECDSA=true|false (DEPRECATED — default=false)
RootlessControlPlane=true|false (ALPHA — default=false)
UpgradeAddonsBeforeControlPlane=true|false (DEPRECATED — default=false)
WaitForAllControlPlaneComponents=true|false (ALPHA — default=false)

-h, --help

Довідка apiserver

--image-repository string     Типово: "registry.k8s.io"

Вибрати реєстр контейнерів для завантаження образів панелі управління

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

--service-cidr string     Типово: "10.96.0.0/12"

Використовуйте альтернативний діапазон IP-адрес для сервісів VIP.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.67 -

Генерує маніфест статичного Podʼа для kube-controller-manager

Опис

Генерує маніфест статичного Podʼа для kube-controller-manager

kubeadm init phase control-plane controller-manager [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--controller-manager-extra-args <пари 'ключ=значення', розділені комами>

Набір додаткових параметрів для передачі до Controller Manager або для перевизначення стандартних у форматі <імʼя_параметра>=<значення>

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка controller-manager

--image-repository string     Типово: "registry.k8s.io"

Вибрати реєстр контейнерів для завантаження образів панелі управління

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

--pod-network-cidr string

Вказує діапазон IP-адрес для мережі Pod. Якщо встановлено, панель управління автоматично виділить CIDR для кожного вузла.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.68 -

Генерує маніфест статичного Podʼа для kube-scheduler

Опис

Генерує маніфест статичного Podʼа для kube-scheduler

kubeadm init phase control-plane scheduler [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-o, --experimental-output string     Типово: "text"

Формат виводу. Один з: text|json|yaml|go-template|go-template-file|template|templatefile|jsonpath|jsonpath-as-json|jsonpath-file.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка scheduler

--image-repository string     Типово: "registry.k8s.io"

Вибрати реєстр контейнерів для завантаження образів панелі управління

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

--scheduler-extra-args <пари 'ключ=значення', розділені комами>

Набір додаткових параметрів для передачі до Scheduler або для перевизначення стандартних у форматі <імʼя_параметра>=<значення>

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.69 -

Генерує файл маніфесту статичного Podʼа для екземпляра local etcd

Опис

Ця команда не призначена для самостійного запуску. Дивіться список доступних субкоманд.

kubeadm init phase etcd [flags]

Параметри

-h, --help

Довідка etcd

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.70 -

Генерує файл маніфесту статичного Podʼа для екземпляра local, одновузлового local etcd

Опис

Генерує файл маніфесту статичного Podʼа для екземпляра local, одновузлового local etcd

kubeadm init phase etcd local [flags]

Приклади

# Генерує файл маніфесту статичного Podʼа для etcd, функціонально
# еквівалентного до того, що генерується командою kubeadm init.
kubeadm init phase etcd local

# Генерує файл маніфесту статичного Podʼа для etcd з використанням опцій
# отриманих з файлу конфігурації.
kubeadm init phase etcd local --config config.yaml

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка local

--image-repository string     Типово: "registry.k8s.io"

Вибрати реєстр контейнерів для завантаження образів панелі управління

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.71 -

Генерує всі файли kubeconfig, необхідні для встановлення панелі управління та файл kubeconfig адміністратора

Опис

Ця команда не призначена для самостійного запуску. Дивіться список доступних субкоманд.

kubeadm init phase kubeconfig [flags]

Параметри

-h, --help

Довідка kubeconfig

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.72 -

Генерує файл kubeconfig для використання адміністратором та для самого kubeadm

Опис

Ця команда генерує файл kubeconfig для використання адміністратором та для самого kubeadm й зберігає його у файл admin.conf.

kubeadm init phase kubeconfig admin [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка admin

--kubeconfig-dir string     Типово: "/etc/kubernetes"

Шлях, де буде збережено файл kubeconfig.

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.73 -

Генерує всі файли kubeconfig

Опис

Генерує всі файли kubeconfig.

kubeadm init phase kubeconfig all [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка all

--kubeconfig-dir string     Типово: "/etc/kubernetes"

Шлях, де буде збережено файл kubeconfig.

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

--node-name string

Вкажіть імʼя вузла.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.74 -

Генерує файл kubeconfig для використання менеджером контролерів

Опис

Генерує файл kubeconfig для використання менеджером контролерів та зберігає його у файл controller-manager.conf.

kubeadm init phase kubeconfig controller-manager [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка controller-manager

--kubeconfig-dir string     Типово: "/etc/kubernetes"

Шлях, де буде збережено файл kubeconfig.

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.75 -

Генерує файл kubeconfig, для kubelet для використання лише для потреб початкового завантаження

Опис

Генерує файл kubeconfig, для kubelet для використання лише для потреб початкового завантаження та зберігає його у файлі kubelet.conf.

Зауважте, що цей файл має використовуватись лише для потреб початкового завантаження кластера. Після розгортання панелі управління, ви маєте запросити облікові дані для kubelet через CSR API.

kubeadm init phase kubeconfig kubelet [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка kubelet

--kubeconfig-dir string     Типово: "/etc/kubernetes"

Шлях, де буде збережено файл kubeconfig.

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

--node-name string

Вкажіть імʼя вузла.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.76 -

Генерує файл kubeconfig для використання планувальником

Опис

Генерує файл kubeconfig для використання планувальником та зберігає його у файл scheduler.conf.

kubeadm init phase kubeconfig scheduler [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка scheduler

--kubeconfig-dir string     Типово: "/etc/kubernetes"

Шлях, де буде збережено файл kubeconfig.

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.77 -

Генерує файл kubeconfig для суперкористувача

Опис

Генерує файл kubeconfig для суперкористувача та зберігає його у файл super-admin.conf.

kubeadm init phase kubeconfig super-admin [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка super-admin

--kubeconfig-dir string     Типово: "/etc/kubernetes"

Шлях, де буде збережено файл kubeconfig.

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.78 -

Оновлює налаштування, що стосуються kubelet, після початкового завантаження TLS

Опис

Оновлює налаштування, що стосуються kubelet, після початкового завантаження TLS

kubeadm init phase kubelet-finalize [flags]

Приклади

# Оновлення налаштувань, що стосуються kubelet, після початкового завантаження TLS"
kubeadm init phase kubelet-finalize all --config

Параметри

-h, --help

Довідка kubelet-finalize

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.79 -

Запускає всі фази kubelet-finalize

Опис

Запускає всі фази kubelet-finalize.

kubeadm init phase kubelet-finalize all [flags]

Приклади

# Оновлення налаштувань, що стосуються kubelet, після початкового завантаження TLS
kubeadm init phase kubelet-finalize all --config

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка all

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.80 -

Вмикає ротацію сертифікатів клієнтів kubelet

Опис

Вмикає ротацію сертифікатів клієнтів kubelet.

kubeadm init phase kubelet-finalize experimental-cert-rotation [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка experimental-cert-rotation

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.81 -

Записує налаштування kubelet та (пере)запускаємо kubelet

Опис

Записує файл з KubeletConfiguration та файл оточення з налаштуваннями kubelet для конкретного вузла, а потім (пере)запустимо kubelet.

kubeadm init phase kubelet-start [flags]

Приклади

# Записує файл динамічного оточення з прапорами kubelet з файлу InitConfiguration.
kubeadm init phase kubelet-start --config config.yaml

Параметри

--config string

Шлях до конфігураційного файлу kubeadm.

--cri-socket string

Шлях до CRI сокету для підключення. Якщо порожньо, kubeadm спробує автоматично визначити це значення; використовуйте цей параметр лише якщо у вас встановлено більше одного CRI або якщо у вас нестандартний CRI сокет.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка kubelet-start

--image-repository string     Типово: "registry.k8s.io"

Вибрати реєстр контейнерів для завантаження образів панелі управління

--node-name string

Вкажіть імʼя вузла.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.82 -

Позначає вузол як вузол панелі управління

Опис

Позначає вузол як вузол панелі управління.

kubeadm init phase mark-control-plane [flags]

Приклади

# Застосовує мітку та taint панелі управління до поточного вузла, функціонально еквівалентно до того, що виконується командою kubeadm init.
kubeadm init phase mark-control-plane --config config.yaml

# Застосовує мітку та taint панелі управління до конкретного вузла
kubeadm init phase mark-control-plane --node-name myNode

Параметри

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка mark-control-plane

--node-name string

Вкажіть імʼя вузла.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.83 -

Виконує передпольотні перевірки

Опис

Виконує передпольотні перевірки для kubeadm init.

kubeadm init phase preflight [flags]

Приклади

# Виконує передпольотні перевірки для kubeadm init з конфігураційним файлом config.yaml
kubeadm init phase preflight --config config.yaml

Параметри

--config string

Шлях до конфігураційного файлу kubeadm.

--cri-socket string

Шлях до CRI сокету для підключення. Якщо порожньо, kubeadm спробує автоматично визначити це значення; використовуйте цей параметр лише якщо у вас встановлено більше одного CRI або якщо у вас нестандартний CRI сокет.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка preflight

--ignore-preflight-errors strings

Список перевірок, помилки яких будуть показані як попередження. Приклад: 'IsPrivilegedUser,Swap'. Значення 'all' ігнорує помилки всіх перевірок.

--image-repository string     Типово: "registry.k8s.io"

Вибрати реєстр контейнерів для завантаження образів панелі управління

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.84 -

Показує команду join для панелі управління та робочого вузла

Опис

Показує команду join для панелі управління та робочого вузла.

kubeadm init phase show-join-command [flags]

Параметри

-h, --help

Довідка show-join-command

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.85 -

Завантажує сертифікати до kubeadm-certs

Опис

Завантажує сертифікати панелі управління в Secret kubeadm-certs

kubeadm init phase upload-certs [flags]

Параметри

--certificate-key string

Ключ, що використовується для шифрування сертифікатів панелі управління у Secret kubeadm-certs. Ключ сертифіката — це шістнадцятковий рядок, який є ключем AES розміром 32 байти

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка upload-certs

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

--skip-certificate-key-print

Не виводити ключ, який використовується для шифрування сертифікатів панелі управління.

--upload-certs

Завантажити сертифікати панелі управління у Secret kubeadm-certs.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.86 -

Завантажує конфігурації kubeadm та kubelet у ConfigMap

Опис

Ця команда не призначена для самостійного запуску. Дивіться список доступних субкоманд.

kubeadm init phase upload-config [flags]

Параметри

-h, --help

Довідка upload-config

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.87 -

Завантажуємо всю конфігурацію в ConfigMap

Опис

Завантажує всю конфігурацію в ConfigMap.

kubeadm init phase upload-config all [flags]

Параметри

--config string

Шлях до конфігураційного файлу kubeadm.

--cri-socket string

Шлях до CRI сокету для підключення. Якщо порожньо, kubeadm спробує автоматично визначити це значення; використовуйте цей параметр лише якщо у вас встановлено більше одного CRI або якщо у вас нестандартний CRI сокет.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка all

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.88 -

Завантажує kubeadm ClusterConfiguration у ConfigMap

Опис

Завантажує конфігурацію кластера kubeadm ClusterConfig до ConfigMap з назвою kubeadm-config у просторі імен kube-system. Це дозволить правильно конфігурувати компоненти системи та спростить роботу користувачів під час оновлення.

Альтернативно, ви можете використовувати kubeadm config.

kubeadm init phase upload-config kubeadm [flags]

Приклади

# Завантаження конфігурації кластера
kubeadm init phase upload-config kubeadm --config=myConfig.yaml

Параметри

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

--cri-socket string

Шлях до CRI сокету для підключення. Якщо порожньо, kubeadm спробує автоматично визначити це значення; використовуйте цей параметр лише якщо у вас встановлено більше одного CRI або якщо у вас нестандартний CRI сокет.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка kubeadm

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.89 -

Завантажує налаштування компонентів kubelet у ConfigMap

Опис

Завантажуємо конфігурацію kubelet, видобуту з обʼєкта kubeadm InitConfiguration, до ConfigMap kubelet-config у кластері

kubeadm init phase upload-config kubelet [flags]

Приклади

# Завантаження конфігурації kubelet з файла конфігурації kubeadm у ConfigMap в кластері
kubeadm init phase upload-config kubelet --config kubeadm.yaml

Параметри

--config string

Шлях до конфігураційного файлу kubeadm.

--cri-socket string

Шлях до CRI сокету для підключення. Якщо порожньо, kubeadm спробує автоматично визначити це значення; використовуйте цей параметр лише якщо у вас встановлено більше одного CRI або якщо у вас нестандартний CRI сокет.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка kubelet

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.90 -

Запустіть цю команду на будь-якому компʼютері, який ви хочете приєднати до існуючого кластера

Опис

Під час приєднання до ініціалізованого кластера за допомогою kubeadm, необхідно встановити двосторонню довіру. Цей процес розділяється на два етапи: виявлення (щоб Node довіряв Панелі Управління Kubernetes) та TLS завантаження (щоб Панель управління Kubernetes довіряла Node).

Існує дві основні схеми для виявлення. Перша — використовувати спільний токен разом з IP-адресою сервера API. Друга — надати файл, який є підмножиною стандартного файлу kubeconfig. Файл discovery/kubeconfig підтримує токен, втулки автентифікації client-go ("exec"), "tokenFile" та "authProvider". Цей файл може бути локальним або завантаженим через URL HTTPS. Форми приєднання є:

kubeadm join --discovery-token abcdef.1234567890abcdef 1.2.3.4:6443
kubeadm join --discovery-file path/to/file.conf
kubeadm join --discovery-file https://url/file.conf

Можна використовувати лише одну форму. Якщо інформація для виявлення завантажується з URL, обовʼязково використовувати HTTPS. У цьому випадку для перевірки зʼєднання використовується встановлений на хості набір сертифікатів CA.

Якщо ви використовуєте спільний токен для виявлення, слід також передати прапорець --discovery-token-ca-cert-hash для перевірки публічного ключа кореневого центру сертифікації (CA), який представлений Панеллю Управління Kubernetes. Значення цього прапорця визначається як "<тип-хешу>:<шестнадцяткове-кодоване-значення>", де підтримуваний тип хешу — "sha256". Хеш обчислюється по байтах обʼєкта Subject Public Key Info (SPKI) (як в RFC7469). Це значення доступне у вихідних даних "kubeadm init" або може бути обчислене за допомогою стандартних інструментів. Прапорець --discovery-token-ca-cert-hash може бути повторений кілька разів, щоб дозволити використання більше одного публічного ключа.

Якщо ви не можете знати хеш публічного ключа CA заздалегідь, ви можете передати прапорець --discovery-token-unsafe-skip-ca-verification для вимкнення цієї перевірки. Це послаблює модель безпеки kubeadm, оскільки інші вузли можуть потенційно видавати себе за Панель Управління Kubernetes.

Механізм TLS завантаження також керується через спільний токен. Це використовується для тимчасової автентифікації в Панелі Управління Kubernetes для подання запиту на підписання сертифіката (CSR) для локально створеної пари ключів. Типово, kubeadm налаштує Панель Управління Kubernetes автоматично схвалювати ці запити на підписання. Цей токен передається за допомогою прапорця --tls-bootstrap-token abcdef.1234567890abcdef.

Часто той самий токен використовується для обох частин. У цьому випадку прапорець --token можна використовувати замість окремого зазначення кожного токена.

Команда "join [api-server-endpoint]" виконує наступні фази:

preflight              Виконати передстартові перевірки для приєднання
control-plane-prepare  Підготувати машину для обслуговування панелі управління
  /download-certs        Завантажити сертифікати, спільні для вузлів панелі управління, з Secret kubeadm-certs
  /certs                 Створити сертифікати для нових компонентів панелі управління
  /kubeconfig            Створити kubeconfig для нових компонентів панелі управління
  /control-plane         Створити маніфести для нових компонентів панелі управління
kubelet-start          Записати налаштування kubelet, сертифікати та (перезавантажити) kubelet
control-plane-join     Приєднати машину як екземпляр панелі управління
  /etcd                  Додати нового локального члена etcd
  /mark-control-plane    Позначити вузол як панель управління
wait-control-plane     Експериментально: чекати запуску панелі управління
kubeadm join [api-server-endpoint] [flags]

Параметри

--apiserver-advertise-address string

Якщо вузол має хостити новий екземпляр панелі управління, IP-адреса, яку сервер API буде оголошувати як ту, на якій він слухає. Якщо не встановлено, буде використовуватися стандартний інтерфейс.

--apiserver-bind-port int32     Стандартно: 6443

Якщо вузол має хостити новий екземпляр панелі управління, порт, до якого буде привʼязаний сервер API.

--certificate-key string

Використовуйте цей ключ для розшифрування секретів сертифікатів, завантажених за допомогою init. Ключ сертифіката — це шестнадцятковий закодований рядок, який є AES ключем розміром 32 байти.

--config string

Шлях до файлу конфігурації kubeadm.

--control-plane

Створити новий екземпляр панелі управління на цьому вузлі

--cri-socket string

Шлях до CRI сокета для підключення. Якщо не встановлено, kubeadm спробує автоматично визначити це значення; використовуйте цей параметр, лише якщо у вас встановлено більше одного CRI або якщо у вас нестандартний CRI сокет.

--discovery-file string

Для виявлення на основі файлу, файл або URL, з якого буде завантажена інформація про кластер.

--discovery-token string

Для виявлення на основі токена, токен, який використовується для перевірки інформації про кластер, отриманої з сервера API.

--discovery-token-ca-cert-hash strings

Для виявлення на основі токена, перевірити, що публічний ключ кореневого центру сертифікації відповідає цьому хешу (формат: "<тип>:<значення>").

--discovery-token-unsafe-skip-ca-verification

Для виявлення на основі токена, дозволити приєднання без закріплення --discovery-token-ca-cert-hash.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка join

--ignore-preflight-errors strings

Список перевірок, помилки яких будуть показані як попередження. Приклад: 'IsPrivilegedUser,Swap'. Значення 'all' ігнорує помилки від усіх перевірок.

--node-name string

Вказати імʼя вузла.

--patches string

Шлях до теки, що містить файли з назвами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним з "strategic", "merge" або "json" і відповідають форматам патчів, підтримуваних kubectl. Типовий "patchtype" — "strategic". "extension" має бути або "json", або "yaml". "suffix" — це необовʼязковий рядок, який можна використовувати для визначення, які патчі застосовуються першими в алфавітно-числовому порядку.

--skip-phases strings

Список фаз, які потрібно пропустити

--tls-bootstrap-token string

Вкажіть токен, який використовується для тимчасової автентифікації з Панеллю Управління Kubernetes під час приєднання вузла.

--token string

Використовуйте цей токен для discovery-token та tls-bootstrap-token, коли ці значення не вказані окремо.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.90.1 -

Використовуйте цю команду для виклику однієї фази робочого процесу join

Опис

Використовуйте цю команду для виклику однієї фази робочого процесу join

Параметри

-h, --help

Довідка phase

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.90.2 -

Приєднує машину до екземпляра панелі управління

Опис

Приєднує машину до екземпляра панелі управління.

kubeadm join phase control-plane-join [flags]

Приклади

# Приєднує машину до екземпляра панелі управління
kubeadm join phase control-plane-join all

Параметри

-h, --help

Довідка control-plane-join

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.90.3 -

Приєднує машину до екземпляру панелі управління

Опис

Приєднує машину до екземпляру панелі управління.

kubeadm join phase control-plane-join all [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane

Створити новий екземпляр панелі управління на цьому вузлі

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка all

--node-name string

Вкажіть імʼя вузла.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.90.4 -

Додає нового учасника local etcd

Опис

Додає нового учасника local etcd

kubeadm join phase control-plane-join etcd [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane

Створити новий екземпляр панелі управління на цьому вузлі

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка etcd

--node-name string

Вкажіть імʼя вузла.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.90.5 -

Позначає вузол як вузол панелі управління

Опис

Позначає вузол як вузол панелі управління.

kubeadm join phase control-plane-join mark-control-plane [flags]

Параметри

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane

Створити новий екземпляр панелі управління на цьому вузлі

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка mark-control-plane

--node-name string

Вкажіть імʼя вузла.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.90.6 -

Готує машину до обслуговування панелі управління

Опис

Готує машину до обслуговування панелі управління.

kubeadm join phase control-plane-prepare [flags]

Приклади

# Готує машину до обслуговування панелі управління
kubeadm join phase control-plane-prepare all

Параметри

-h, --help

Довідка control-plane-prepare

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.90.7 -

Готує машину для роботи як панелі управління

Опис

Готує машину для роботи як панелі управління.

kubeadm join phase control-plane-prepare all [api-server-endpoint] [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--certificate-key string

Ключ, що використовується для шифрування сертифікатів панелі управління у Secret kubeadm-certs. Ключ сертифіката — це шістнадцятковий рядок, який є ключем AES розміром 32 байти

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane

Створити новий екземпляр панелі управління на цьому вузлі

--discovery-file string

Для виявлення на основі файлу, файл або URL, з якого буде завантажена інформація про кластер.

--discovery-token string

Для виявлення на основі токена, токен, який використовується для перевірки інформації про кластер, отриманої з сервера API.

--discovery-token-ca-cert-hash strings

Для виявлення на основі токена, перевірити, що публічний ключ кореневого центру сертифікації відповідає цьому хешу (формат: "<тип>:<значення>").

--discovery-token-unsafe-skip-ca-verification

Для виявлення на основі токена, дозволити приєднання без закріплення --discovery-token-ca-cert-hash.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка all

--node-name string

Вкажіть імʼя вузла.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

--tls-bootstrap-token string

Вкажіть токен, який використовується для тимчасової автентифікації з Панеллю Управління Kubernetes під час приєднання вузла.

--token string

Використовуйте цей токен для discovery-token та tls-bootstrap-token, коли ці значення не вказані окремо.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.90.8 -

Генерує сертифікати для нових компенонетів панелі управління

Опис

Генерує сертифікати для нових компонентів панелі управління.

kubeadm join phase control-plane-prepare certs [api-server-endpoint] [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane

Створити новий екземпляр панелі управління на цьому вузлі

--discovery-file string

Для виявлення на основі файлу, файл або URL, з якого буде завантажена інформація про кластер.

--discovery-token string

Для виявлення на основі токена, токен, який використовується для перевірки інформації про кластер, отриманої з сервера API.

--discovery-token-ca-cert-hash strings

Для виявлення на основі токена, перевірити, що публічний ключ кореневого центру сертифікації відповідає цьому хешу (формат: "<тип>:<значення>").

--discovery-token-unsafe-skip-ca-verification

Для виявлення на основі токена, дозволити приєднання без закріплення --discovery-token-ca-cert-hash.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка certs

--node-name string

Вкажіть імʼя вузла.

--tls-bootstrap-token string

Вкажіть токен, який використовується для тимчасової автентифікації з Панеллю Управління Kubernetes під час приєднання вузла.

--token string

Використовуйте цей токен для discovery-token та tls-bootstrap-token, коли ці значення не вказані окремо.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.90.9 -

Генерує маніфести для нових компонентів панелі управління

Опис

Генерує маніфести для нових компонентів панелі управління.

kubeadm join phase control-plane-prepare control-plane [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane

Створити новий екземпляр панелі управління на цьому вузлі

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка control-plane

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.90.10 -

Завантажує сертифікати, спільні для вузлів панелі управління, з архіву kubeadm-certs Secret

Опис

Завантажує сертифікати, спільні для вузлів панелі управління, з архіву kubeadm-certs Secret

kubeadm join phase control-plane-prepare download-certs [api-server-endpoint] [flags]

Параметри

--certificate-key string

Ключ, що використовується для шифрування сертифікатів панелі управління у Secret kubeadm-certs. Ключ сертифіката — це шістнадцятковий рядок, який є ключем AES розміром 32 байти

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane

Створити новий екземпляр панелі управління на цьому вузлі

--discovery-file string

Для виявлення на основі файлу, файл або URL, з якого буде завантажена інформація про кластер.

--discovery-token string

Для виявлення на основі токена, токен, який використовується для перевірки інформації про кластер, отриманої з сервера API.

--discovery-token-ca-cert-hash strings

Для виявлення на основі токена, перевірити, що публічний ключ кореневого центру сертифікації відповідає цьому хешу (формат: "<тип>:<значення>").

--discovery-token-unsafe-skip-ca-verification

Для виявлення на основі токена, дозволити приєднання без закріплення --discovery-token-ca-cert-hash.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка download-certs

--tls-bootstrap-token string

Вкажіть токен, який використовується для тимчасової автентифікації з Панеллю Управління Kubernetes під час приєднання вузла.

--token string

Використовуйте цей токен для discovery-token та tls-bootstrap-token, коли ці значення не вказані окремо.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.90.11 -

Генерує kubeconfig для нових компонентів панелі управління

Опис

Генерує kubeconfig для нових компонентів панелі управління, які будуть додані до кластера.

kubeadm join phase control-plane-prepare kubeconfig [api-server-endpoint] [flags]

Параметри

--certificate-key string

Ключ, що використовується для шифрування сертифікатів панелі управління у Secret kubeadm-certs. Ключ сертифіката — це шістнадцятковий рядок, який є ключем AES розміром 32 байти

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane

Створити новий екземпляр панелі управління на цьому вузлі

--discovery-file string

Для виявлення на основі файлу, файл або URL, з якого буде завантажена інформація про кластер.

--discovery-token string

Для виявлення на основі токена, токен, який використовується для перевірки інформації про кластер, отриманої з сервера API.

--discovery-token-ca-cert-hash strings

Для виявлення на основі токена, перевірити, що публічний ключ кореневого центру сертифікації відповідає цьому хешу (формат: "<тип>:<значення>").

--discovery-token-unsafe-skip-ca-verification

Для виявлення на основі токена, дозволити приєднання без закріплення --discovery-token-ca-cert-hash.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка kubeconfig

--tls-bootstrap-token string

Вкажіть токен, який використовується для тимчасової автентифікації з Панеллю Управління Kubernetes під час приєднання вузла.

--token string

Використовуйте цей токен для discovery-token та tls-bootstrap-token, коли ці значення не вказані окремо.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.90.12 -

Записує налаштування kubelet, сертифікати та (пере)запускає kubelet

Опис

Записує файл з KubeletConfiguration та файл оточення з налаштуваннями kubelet для конкретного вузла, а потім (пере)запускає kubelet.

kubeadm join phase kubelet-start [api-server-endpoint] [flags]

Параметри

tr>
--config string

Шлях до конфігураційного файлу kubeadm.

--cri-socket string

Шлях до CRI сокету для підключення. Якщо порожньо, kubeadm спробує автоматично визначити це значення; використовуйте цей параметр лише якщо у вас встановлено більше одного CRI або якщо у вас нестандартний CRI сокет.

--discovery-file string

Для виявлення на основі файлу, файл або URL, з якого буде завантажена інформація про кластер.

--discovery-token string

Для виявлення на основі токена, токен, який використовується для перевірки інформації про кластер, отриманої з сервера API.

--discovery-token-ca-cert-hash strings

Для виявлення на основі токена, перевірити, що публічний ключ кореневого центру сертифікації відповідає цьому хешу (формат: "<тип>:<значення>").

--discovery-token-unsafe-skip-ca-verification

Для виявлення на основі токена, дозволити приєднання без закріплення --discovery-token-ca-cert-hash.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка kubelet-start

--node-name string

Вкажіть імʼя вузла.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

--tls-bootstrap-token string

Вкажіть токен, який використовується для тимчасової автентифікації з Панеллю Управління Kubernetes під час приєднання вузла.

--token string

Використовуйте цей токен для discovery-token та tls-bootstrap-token, коли ці значення не вказані окремо.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.90.13 -

Виконує передполітні перевірки join

Опис

Виконує передполітні перевірки для kubeadm join.

kubeadm join phase preflight [api-server-endpoint] [flags]

Приклади

# Виконує передполітні перевірки для kubeadm join
kubeadm join phase preflight --config kubeadm-config.yaml

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--certificate-key string

Ключ, що використовується для шифрування сертифікатів панелі управління у Secret kubeadm-certs. Ключ сертифіката — це шістнадцятковий рядок, який є ключем AES розміром 32 байти

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane

Створити новий екземпляр панелі управління на цьому вузлі

--cri-socket string

Шлях до CRI сокету для підключення. Якщо порожньо, kubeadm спробує автоматично визначити це значення; використовуйте цей параметр лише якщо у вас встановлено більше одного CRI або якщо у вас нестандартний CRI сокет.

--discovery-file string

Для виявлення на основі файлу, файл або URL, з якого буде завантажена інформація про кластер.

--discovery-token string

Для виявлення на основі токена, токен, який використовується для перевірки інформації про кластер, отриманої з сервера API.

--discovery-token-ca-cert-hash strings

Для виявлення на основі токена, перевірити, що публічний ключ кореневого центру сертифікації відповідає цьому хешу (формат: "<тип>:<значення>").

--discovery-token-unsafe-skip-ca-verification

Для виявлення на основі токена, дозволити приєднання без закріплення --discovery-token-ca-cert-hash.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка preflight

--ignore-preflight-errors strings

Список перевірок, помилки яких будуть показані як попередження. Приклад: 'IsPrivilegedUser,Swap'. Значення 'all' ігнорує помилки від усіх перевірок.

--node-name string

Вкажіть імʼя вузла.

--tls-bootstrap-token string

Вкажіть токен, який використовується для тимчасової автентифікації з Панеллю Управління Kubernetes під час приєднання вузла.

--token string

Використовуйте цей токен для discovery-token та tls-bootstrap-token, коли ці значення не вказані окремо.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.90.14 -

[EXPERIMENTAL] Очікує запуску панелі управління

Опис

[EXPERIMENTAL] Очікує запуску панелі управління

kubeadm join phase wait-control-plane [flags]

Параметри

-h, --help

Довідка wait-control-plane

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.91 -

Використовуйте цю команду для виклику однієї фази робочого процесу join

Опис

Використовуйте цю команду для виклику однієї фази робочого процесу join

Параметри

-h, --help

Довідка phase

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.92 -

Приєднує машину до екземпляра панелі управління

Опис

Приєднує машину до екземпляра панелі управління.

kubeadm join phase control-plane-join [flags]

Приклади

# Приєднує машину до екземпляра панелі управління
kubeadm join phase control-plane-join all

Параметри

-h, --help

Довідка control-plane-join

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.93 -

Приєднує машину до екземпляру панелі управління

Опис

Приєднує машину до екземпляру панелі управління.

kubeadm join phase control-plane-join all [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane

Створити новий екземпляр панелі управління на цьому вузлі

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка all

--node-name string

Вкажіть імʼя вузла.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.94 -

Додає нового учасника local etcd

Опис

Додає нового учасника local etcd

kubeadm join phase control-plane-join etcd [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane

Створити новий екземпляр панелі управління на цьому вузлі

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка etcd

--node-name string

Вкажіть імʼя вузла.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.95 -

Позначає вузол як вузол панелі управління

Опис

Позначає вузол як вузол панелі управління.

kubeadm join phase control-plane-join mark-control-plane [flags]

Параметри

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane

Створити новий екземпляр панелі управління на цьому вузлі

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка mark-control-plane

--node-name string

Вкажіть імʼя вузла.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.96 -

Реєструє новий вузол панелі управління у ClusterStatus, який підтримується у kubeadm-config ConfigMap ("DEPRECATED")

Опис

Реєструє новий вузол панелі управління у ClusterStatus, який підтримується у kubeadm-config ConfigMap ("DEPRECATED")

kubeadm join phase control-plane-join update-status [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane

Створити новий екземпляр панелі управління на цьому вузлі

-h, --help

Довідка update-status

--node-name string

Вкажіть імʼя вузла.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.97 -

Готує машину до обслуговування панелі управління

Опис

Готує машину до обслуговування панелі управління.

kubeadm join phase control-plane-prepare [flags]

Приклади

# Готує машину до обслуговування панелі управління
kubeadm join phase control-plane-prepare all

Параметри

-h, --help

Довідка control-plane-prepare

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.98 -

Готує машину для роботи як панелі управління

Опис

Готує машину для роботи як панелі управління.

kubeadm join phase control-plane-prepare all [api-server-endpoint] [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--certificate-key string

Ключ, що використовується для шифрування сертифікатів панелі управління у Secret kubeadm-certs. Ключ сертифіката — це шістнадцятковий рядок, який є ключем AES розміром 32 байти

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane

Створити новий екземпляр панелі управління на цьому вузлі

--discovery-file string

Для виявлення на основі файлу, файл або URL, з якого буде завантажена інформація про кластер.

--discovery-token string

Для виявлення на основі токена, токен, який використовується для перевірки інформації про кластер, отриманої з сервера API.

--discovery-token-ca-cert-hash strings

Для виявлення на основі токена, перевірити, що публічний ключ кореневого центру сертифікації відповідає цьому хешу (формат: "<тип>:<значення>").

--discovery-token-unsafe-skip-ca-verification

Для виявлення на основі токена, дозволити приєднання без закріплення --discovery-token-ca-cert-hash.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка all

--node-name string

Вкажіть імʼя вузла.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

--tls-bootstrap-token string

Вкажіть токен, який використовується для тимчасової автентифікації з Панеллю Управління Kubernetes під час приєднання вузла.

--token string

Використовуйте цей токен для discovery-token та tls-bootstrap-token, коли ці значення не вказані окремо.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.99 -

Генерує сертифікати для нових компенонетів панелі управління

Опис

Генерує сертифікати для нових компонентів панелі управління.

kubeadm join phase control-plane-prepare certs [api-server-endpoint] [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane

Створити новий екземпляр панелі управління на цьому вузлі

--discovery-file string

Для виявлення на основі файлу, файл або URL, з якого буде завантажена інформація про кластер.

--discovery-token string

Для виявлення на основі токена, токен, який використовується для перевірки інформації про кластер, отриманої з сервера API.

--discovery-token-ca-cert-hash strings

Для виявлення на основі токена, перевірити, що публічний ключ кореневого центру сертифікації відповідає цьому хешу (формат: "<тип>:<значення>").

--discovery-token-unsafe-skip-ca-verification

Для виявлення на основі токена, дозволити приєднання без закріплення --discovery-token-ca-cert-hash.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка certs

--node-name string

Вкажіть імʼя вузла.

--tls-bootstrap-token string

Вкажіть токен, який використовується для тимчасової автентифікації з Панеллю Управління Kubernetes під час приєднання вузла.

--token string

Використовуйте цей токен для discovery-token та tls-bootstrap-token, коли ці значення не вказані окремо.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.100 -

Генерує маніфести для нових компонентів панелі управління

Опис

Генерує маніфести для нових компонентів панелі управління.

kubeadm join phase control-plane-prepare control-plane [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane

Створити новий екземпляр панелі управління на цьому вузлі

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка control-plane

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.101 -

[EXPERIMENTAL] Завантажує сертифікати, спільні для вузлів панелі управління, з архіву kubeadm-certs Secret

Опис

[EXPERIMENTAL] Завантажує сертифікати, спільні для вузлів панелі управління, з архіву kubeadm-certs Secret

kubeadm join phase control-plane-prepare download-certs [api-server-endpoint] [flags]

Параметри

--certificate-key string

Ключ, що використовується для шифрування сертифікатів панелі управління у Secret kubeadm-certs. Ключ сертифіката — це шістнадцятковий рядок, який є ключем AES розміром 32 байти

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane

Створити новий екземпляр панелі управління на цьому вузлі

--discovery-file string

Для виявлення на основі файлу, файл або URL, з якого буде завантажена інформація про кластер.

--discovery-token string

Для виявлення на основі токена, токен, який використовується для перевірки інформації про кластер, отриманої з сервера API.

--discovery-token-ca-cert-hash strings

Для виявлення на основі токена, перевірити, що публічний ключ кореневого центру сертифікації відповідає цьому хешу (формат: "<тип>:<значення>").

--discovery-token-unsafe-skip-ca-verification

Для виявлення на основі токена, дозволити приєднання без закріплення --discovery-token-ca-cert-hash.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка download-certs

--tls-bootstrap-token string

Вкажіть токен, який використовується для тимчасової автентифікації з Панеллю Управління Kubernetes під час приєднання вузла.

--token string

Використовуйте цей токен для discovery-token та tls-bootstrap-token, коли ці значення не вказані окремо.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.102 -

Генерує kubeconfig для нових компонентів панелі управління

Опис

Генерує kubeconfig для нових компонентів панелі управління, які будуть додані до кластера.

kubeadm join phase control-plane-prepare kubeconfig [api-server-endpoint] [flags]

Параметри

--certificate-key string

Ключ, що використовується для шифрування сертифікатів панелі управління у Secret kubeadm-certs. Ключ сертифіката — це шістнадцятковий рядок, який є ключем AES розміром 32 байти

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane

Створити новий екземпляр панелі управління на цьому вузлі

--discovery-file string

Для виявлення на основі файлу, файл або URL, з якого буде завантажена інформація про кластер.

--discovery-token string

Для виявлення на основі токена, токен, який використовується для перевірки інформації про кластер, отриманої з сервера API.

--discovery-token-ca-cert-hash strings

Для виявлення на основі токена, перевірити, що публічний ключ кореневого центру сертифікації відповідає цьому хешу (формат: "<тип>:<значення>").

--discovery-token-unsafe-skip-ca-verification

Для виявлення на основі токена, дозволити приєднання без закріплення --discovery-token-ca-cert-hash.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка kubeconfig

--tls-bootstrap-token string

Вкажіть токен, який використовується для тимчасової автентифікації з Панеллю Управління Kubernetes під час приєднання вузла.

--token string

Використовуйте цей токен для discovery-token та tls-bootstrap-token, коли ці значення не вказані окремо.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.103 -

Записує налаштування kubelet, сертифікати та (пере)запускає kubelet

Опис

Записує файл з KubeletConfiguration та файл оточення з налаштуваннями kubelet для конкретного вузла, а потім (пере)запускає kubelet.

kubeadm join phase kubelet-start [api-server-endpoint] [flags]

Параметри

tr>
--config string

Шлях до конфігураційного файлу kubeadm.

--cri-socket string

Шлях до CRI сокету для підключення. Якщо порожньо, kubeadm спробує автоматично визначити це значення; використовуйте цей параметр лише якщо у вас встановлено більше одного CRI або якщо у вас нестандартний CRI сокет.

--discovery-file string

Для виявлення на основі файлу, файл або URL, з якого буде завантажена інформація про кластер.

--discovery-token string

Для виявлення на основі токена, токен, який використовується для перевірки інформації про кластер, отриманої з сервера API.

--discovery-token-ca-cert-hash strings

Для виявлення на основі токена, перевірити, що публічний ключ кореневого центру сертифікації відповідає цьому хешу (формат: "<тип>:<значення>").

--discovery-token-unsafe-skip-ca-verification

Для виявлення на основі токена, дозволити приєднання без закріплення --discovery-token-ca-cert-hash.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка kubelet-start

--node-name string

Вкажіть імʼя вузла.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

--tls-bootstrap-token string

Вкажіть токен, який використовується для тимчасової автентифікації з Панеллю Управління Kubernetes під час приєднання вузла.

--token string

Використовуйте цей токен для discovery-token та tls-bootstrap-token, коли ці значення не вказані окремо.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.104 -

Виконує передполітні перевірки join

Опис

Виконує передполітні перевірки для kubeadm join.

kubeadm join phase preflight [api-server-endpoint] [flags]

Приклади

# Виконує передполітні перевірки для kubeadm join
kubeadm join phase preflight --config kubeadm-config.yaml

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--certificate-key string

Ключ, що використовується для шифрування сертифікатів панелі управління у Secret kubeadm-certs. Ключ сертифіката — це шістнадцятковий рядок, який є ключем AES розміром 32 байти

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane

Створити новий екземпляр панелі управління на цьому вузлі

--cri-socket string

Шлях до CRI сокету для підключення. Якщо порожньо, kubeadm спробує автоматично визначити це значення; використовуйте цей параметр лише якщо у вас встановлено більше одного CRI або якщо у вас нестандартний CRI сокет.

--discovery-file string

Для виявлення на основі файлу, файл або URL, з якого буде завантажена інформація про кластер.

--discovery-token string

Для виявлення на основі токена, токен, який використовується для перевірки інформації про кластер, отриманої з сервера API.

--discovery-token-ca-cert-hash strings

Для виявлення на основі токена, перевірити, що публічний ключ кореневого центру сертифікації відповідає цьому хешу (формат: "<тип>:<значення>").

--discovery-token-unsafe-skip-ca-verification

Для виявлення на основі токена, дозволити приєднання без закріплення --discovery-token-ca-cert-hash.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка preflight

--ignore-preflight-errors strings

Список перевірок, помилки яких будуть показані як попередження. Приклад: 'IsPrivilegedUser,Swap'. Значення 'all' ігнорує помилки від усіх перевірок.

--node-name string

Вкажіть імʼя вузла.

--tls-bootstrap-token string

Вкажіть токен, який використовується для тимчасової автентифікації з Панеллю Управління Kubernetes під час приєднання вузла.

--token string

Використовуйте цей токен для discovery-token та tls-bootstrap-token, коли ці значення не вказані окремо.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.105 -

[EXPERIMENTAL] Очікує запуску панелі управління

Опис

[EXPERIMENTAL] Очікує запуску панелі управління

kubeadm join phase wait-control-plane [flags]

Параметри

-h, --help

Довідка wait-control-plane

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.106 -

Файлові утиліти Kubeconfig

Опис

Файлові утиліти Kubeconfig.

Параметри

-h, --help

Довідка kubeconfig

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.106.1 -

Виводить файл kubeconfig для додаткового користувача

Опис

Виводить файл kubeconfig для додаткового користувача.

kubeadm kubeconfig user [flags]

Приклади

# Виводить файл kubeconfig для додаткового користувача з іменем foo
kubeadm kubeconfig user --client-name=foo

# Виводить файл kubeconfig для додаткового користувача з іменем foo, використовуючи конфігураційний файл kubeadm bar
kubeadm kubeconfig user --client-name=foo --config=bar

Параметри

--client-name string

Імʼя користувача. Буде використовуватися як CN у разі створення клієнтських сертифікатів

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка user

--org strings

Організації сертифіката клієнта. Буде використовуватися як O, якщо будуть створені клієнтські сертифікати

--token string

TТокен, який слід використовувати як механізм автентифікації для цього kubeconfig замість клієнтських сертифікатів

--validity-period duration     Типово: 8760h0m0s

Термін дії клієнтського сертифіката. Відраховується від поточного часу.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.107 -

Виводить файл kubeconfig для додаткового користувача

Опис

Виводить файл kubeconfig для додаткового користувача.

kubeadm kubeconfig user [flags]

Приклади

# Виводить файл kubeconfig для додаткового користувача з іменем foo
kubeadm kubeconfig user --client-name=foo

# Виводить файл kubeconfig для додаткового користувача з іменем foo, використовуючи конфігураційний файл kubeadm bar
kubeadm kubeconfig user --client-name=foo --config=bar

Параметри

--client-name string

Імʼя користувача. Буде використовуватися як CN у разі створення клієнтських сертифікатів

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка user

--org strings

Організації сертифіката клієнта. Буде використовуватися як O, якщо будуть створені клієнтські сертифікати

--token string

TТокен, який слід використовувати як механізм автентифікації для цього kubeconfig замість клієнтських сертифікатів

--validity-period duration     Типово: 8760h0m0s

Термін дії клієнтського сертифіката. Відраховується від поточного часу.

Параметри успадковані від батьківських команд

--rootfs string

[ЕКСПЕРИМЕНТАЛЬНО] Шлях до "справжньої" кореневої файлової системи хоста.

6.10.1.1.108 -

Виконує максимально можливий відкат змін для хоста, зроблених командами kubeadm init або kubeadm join.

Опис

Виконує максимально можливий відкат змін для хоста, зроблених командами kubeadm init або kubeadm join.

Команда "reset" виконує наступні фази:

preflight           Запуск попередніх перевірок
remove-etcd-member  Вилучення локального учасника etcd.
cleanup-node        Запуск очищення вузла.
kubeadm reset [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях до теки, де зберігаються сертифікати. Якщо вказано, очистити цю теку.

--cleanup-tmp-dir

Очистити теку "/etc/kubernetes/tmp"

--config string

Шлях до файлу конфігурації kubeadm.

--cri-socket string

Шлях до CRI сокету для підключення. Якщо порожньо, kubeadm спробує автоматично визначити це значення; використовуйте цей параметр лише якщо у вас встановлено більше одного CRI або якщо у вас нестандартний CRI сокет.

--dry-run

Не вносити жодних змін; лише вивести, що буде зроблено.

-f, --force

Виконати reset вузла без запиту на підтвердження.

-h, --help

довідка reset

--ignore-preflight-errors strings

Список перевірок, помилки яких будуть показані як попередження. Приклад: 'IsPrivilegedUser,Swap'. Значення 'all' ігнорує помилки від усіх перевірок.

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig для використання при спілкуванні з кластером. Якщо прапорець не встановлено, можна шукати наявний файл kubeconfig у наборі стандартних місць.

--skip-phases strings

Список фаз, які слід пропустити

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.108.1 -

Використовуйте цю команду для виклику однієї фази процесу reset

Опис

Використовуйте цю команду для виклику однієї фази процесу reset

Параметри

-h, --help

Довідка phase

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.108.2 -

Запускає очищення вузла

Опис

Запускає очищення вузла.

kubeadm reset phase cleanup-node [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--cleanup-tmp-dir

Очистити теку "/etc/kubernetes/tmp"

--cri-socket string

Шлях до CRI сокету для підключення. Якщо порожньо, kubeadm спробує автоматично визначити це значення; використовуйте цей параметр лише якщо у вас встановлено більше одного CRI або якщо у вас нестандартний CRI сокет.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка cleanup-node

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.108.3 -

Виконує передполітні перевірки для kubeadm reset

Опис

Виконує передполітні перевірки для kubeadm reset.

kubeadm reset phase preflight [flags]

Параметри

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-f, --force

Виконати reset вузла без запиту на підтвердження.

-h, --help

Довідка preflight

--ignore-preflight-errors strings

Список перевірок, помилки яких будуть показані як попередження. Приклад: 'IsPrivilegedUser,Swap'. Значення 'all' ігнорує помилки від усіх перевірок.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.108.4 -

Видаляє члена local etcd

Опмс

Видаляє члена local etcd для вузла панелі управління.

kubeadm reset phase remove-etcd-member [flags]

Параметри

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка remove-etcd-member

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.109 -

Використовуйте цю команду для виклику однієї фази процесу reset

Опис

Використовуйте цю команду для виклику однієї фази процесу reset

Параметри

-h, --help

Довідка phase

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.110 -

Запускає очищення вузла

Опис

Запускає очищення вузла.

kubeadm reset phase cleanup-node [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--cleanup-tmp-dir

Очистити теку "/etc/kubernetes/tmp"

--cri-socket string

Шлях до CRI сокету для підключення. Якщо порожньо, kubeadm спробує автоматично визначити це значення; використовуйте цей параметр лише якщо у вас встановлено більше одного CRI або якщо у вас нестандартний CRI сокет.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка cleanup-node

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.111 -

Виконує передполітні перевірки для kubeadm reset

Опис

Виконує передполітні перевірки для kubeadm reset.

kubeadm reset phase preflight [flags]

Параметри

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-f, --force

Виконати reset вузла без запиту на підтвердження.

-h, --help

Довідка preflight

--ignore-preflight-errors strings

Список перевірок, помилки яких будуть показані як попередження. Приклад: 'IsPrivilegedUser,Swap'. Значення 'all' ігнорує помилки від усіх перевірок.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.112 -

Видаляє члена local etcd

Опмс

Видаляє члена local etcd для вузла панелі управління.

kubeadm reset phase remove-etcd-member [flags]

Параметри

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка remove-etcd-member

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.113 -

Керує токенами bootstrap

Опис

Ця команда управляє bootstrap токенами. Вона є опціональною та необхідна лише для розширених випадків використання.

Коротко кажучи, bootstrap токени використовуються для встановлення двосторонньої довіри між клієнтом і сервером. Bootstrap токен може бути використаний, коли клієнт (наприклад, вузол, який збирається приєднатися до кластера) має довіряти серверу, з яким він взаємодіє. У цьому випадку можна використовувати bootstrap токен з дозволом на "підписування" ("signing"). Bootstrap токени також можуть функціонувати як спосіб дозволити короткострокову автентифікацію на API сервері (токен слугує способом, щоб API сервер довіряв клієнту), наприклад, для виконання TLS Bootstrap.

Що таке bootstrap токен більш конкретно?

  • Це Secret у просторі імен kube-system типу "bootstrap.kubernetes.io/token".
  • Bootstrap токен повинен мати форму "[a-z0-9]{6}.[a-z0-9]{16}". Перша частина є публічним ідентифікатором токена, а друга — секретом токена, який повинен бути збережений у таємниці за будь-яких обставин!
  • Назва Secret повинна бути "bootstrap-token-(token-id)".

Більше інформації про bootstrap токени можна знайти тут: https://kubernetes.io/docs/admin/bootstrap-tokens/

kubeadm token [flags]

Параметри

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка token

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.113.1 -

Створює токени запуску на сервері.

Опис

Ця команда створює токен запуску для вас. Ви можете вказати способи використання цього токену, "час життя" і необовʼязковий опис, зрозумілий людині.

[token] — це власне токен, який потрібно записати. Це має бути безпечно згенерований випадковий токен виду "[a-z0-9]{6}.[a-z0-9]{16}". Якщо [token] не вказано, kubeadm згенерує випадковий токен замість нього.

kubeadm token create [token]

Параметри

--certificate-key string

Якщо використовується разом із '--print-join-command', виводить повний прапорець 'kubeadm join', необхідний для приєднання до кластера як панелі управління. Щоб створити новий ключ сертифіката, потрібно використовувати 'kubeadm init phase upload-certs --upload-certs'.

--config string

Шлях до файлу конфігурації kubeadm.

--description string

Опис, зрозумілий для людини, як використовується цей токен.

--groups strings     Типово: "system:bootstrappers:kubeadm:default-node-token"

Додаткові групи, які будуть автентифікуватися за допомогою цього токена при використанні для автентифікації. Повинно відповідати "\Asystem:bootstrappers:[a-z0-9:-]{0,255}[a-z0-9]\z"

-h, --help

довідка create

--print-join-command

Замість того, щоб виводити тільки токен, вивести повний прапорець 'kubeadm join', необхідний для приєднання до кластера за допомогою токена.

--ttl duration     Типово: 24h0m0s

Тривалість перед автоматичним видаленням токена (наприклад, 1s, 2m, 3h). Якщо встановлено '0', токен ніколи не закінчиться.

--usages strings     Типово: "signing,authentication"

Описує способи, в яких цей токен може використовуватися. Ви можете передавати --usages кілька разів або надати список параметрів через кому. Дійсні параметри: [signing,authentication]

Параметри успадковані від батьківських команд

--dry-run

Чи ввімкнути режим dry-run чи ні

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig для використання при спілкуванні з кластером. Якщо прапорець не встановлено, можна шукати наявний файл kubeconfig у наборі стандартних місць.

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.113.2 -

Видаляє токени запуску на сервері.

Опис

Ця команда видаляє токени запуску для вас.

Значення [token-value] — це повний токен у вигляді "[a-z0-9]{6}.[a-z0-9]{16}" або Token ID виду "[a-z0-9]{6}", який потрібно видалити.

kubeadm token delete [token-value] ...

Параметри

-h, --help

довідка delete

Параметри успадковані від батьківських команд

--dry-run

Чи ввімкнути режим dry-run чи ні

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig для використання при спілкуванні з кластером. Якщо прапорець не встановлено, можна шукати наявний файл kubeconfig у наборі стандартних місць.

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.113.3 -

Генерує та виводить токен запуску, але не створює його на сервері

Опис

Ця команда виведе випадково згенерований токен запуску, який можна використовувати з командами "init" та "join".

Ви не зобовʼязані використовувати цю команду для створення токена. Ви можете зробити це самостійно, якщо він має формат "[a-z0-9]{6}.[a-z0-9]{16}". Ця команда надається для зручності створення токенів у зазначеному форматі.

Ви також можете використовувати "kubeadm init" без вказання токена, і він буде згенерований та виведений для вас.

kubeadm token generate [flags]

Параметри

-h, --help

довідка generate

Параметри успадковані від батьківських команд

--dry-run

Чи ввімкнути режим dry-run чи ні

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig для використання при спілкуванні з кластером. Якщо прапорець не встановлено, можна шукати наявний файл kubeconfig у наборі стандартних місць.

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.113.4 -

Виводить перелік токенів запуску на сервері

Опис

Ця команда виведе перелік всіх токенів запуску на сервері.

kubeadm token list [flags]

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігноруйте будь-які помилки в шаблонах, коли поле або ключ map відсутні в шаблоні. Застосовується лише до форматів виводу golang і jsonpath.

-h, --help

довідка list

-o, --output string     Типово: "text"

Формат виводу. Один із: text|json|yaml|go-template|go-template-file|template|templatefile|jsonpath|jsonpath-as-json|jsonpath-file.

--show-managed-fields

Якщо true, залиште managedFields під час вводу обʼєктів у форматі JSON або YAML.

Параметри успадковані від батьківських команд

--dry-run

Чи ввімкнути режим dry-run чи ні

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig для використання при спілкуванні з кластером. Якщо прапорець не встановлено, можна шукати наявний файл kubeconfig у наборі стандартних місць.

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.114 -

Створює токени запуску на сервері.

Опис

Ця команда створює токен запуску для вас. Ви можете вказати способи використання цього токену, "час життя" і необовʼязковий опис, зрозумілий людині.

[token] — це власне токен, який потрібно записати. Це має бути безпечно згенерований випадковий токен виду "[a-z0-9]{6}.[a-z0-9]{16}". Якщо [token] не вказано, kubeadm згенерує випадковий токен замість нього.

kubeadm token create [token]

Параметри

--certificate-key string

Якщо використовується разом із '--print-join-command', виводить повний прапорець 'kubeadm join', необхідний для приєднання до кластера як панелі управління. Щоб створити новий ключ сертифіката, потрібно використовувати 'kubeadm init phase upload-certs --upload-certs'.

--config string

Шлях до файлу конфігурації kubeadm.

--description string

Опис, зрозумілий для людини, як використовується цей токен.

--groups strings     Типово: "system:bootstrappers:kubeadm:default-node-token"

Додаткові групи, які будуть автентифікуватися за допомогою цього токена при використанні для автентифікації. Повинно відповідати "\Asystem:bootstrappers:[a-z0-9:-]{0,255}[a-z0-9]\z"

-h, --help

довідка create

--print-join-command

Замість того, щоб виводити тільки токен, вивести повний прапорець 'kubeadm join', необхідний для приєднання до кластера за допомогою токена.

--ttl duration     Типово: 24h0m0s

Тривалість перед автоматичним видаленням токена (наприклад, 1s, 2m, 3h). Якщо встановлено '0', токен ніколи не закінчиться.

--usages strings     Типово: "signing,authentication"

Описує способи, в яких цей токен може використовуватися. Ви можете передавати --usages кілька разів або надати список параметрів через кому. Дійсні параметри: [signing,authentication]

Параметри успадковані від батьківських команд

--dry-run

Чи ввімкнути режим dry-run чи ні

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig для використання при спілкуванні з кластером. Якщо прапорець не встановлено, можна шукати наявний файл kubeconfig у наборі стандартних місць.

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.115 -

Видаляє токени запуску на сервері.

Опис

Ця команда видаляє токени запуску для вас.

Значення [token-value] — це повний токен у вигляді "[a-z0-9]{6}.[a-z0-9]{16}" або Token ID виду "[a-z0-9]{6}", який потрібно видалити.

kubeadm token delete [token-value] ...

Параметри

-h, --help

довідка delete

Параметри успадковані від батьківських команд

--dry-run

Чи ввімкнути режим dry-run чи ні

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig для використання при спілкуванні з кластером. Якщо прапорець не встановлено, можна шукати наявний файл kubeconfig у наборі стандартних місць.

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.116 -

Генерує та виводить токен запуску, але не створює його на сервері

Опис

Ця команда виведе випадково згенерований токен запуску, який можна використовувати з командами "init" та "join".

Ви не зобовʼязані використовувати цю команду для створення токена. Ви можете зробити це самостійно, якщо він має формат "[a-z0-9]{6}.[a-z0-9]{16}". Ця команда надається для зручності створення токенів у зазначеному форматі.

Ви також можете використовувати "kubeadm init" без вказання токена, і він буде згенерований та виведений для вас.

kubeadm token generate [flags]

Параметри

-h, --help

довідка generate

Параметри успадковані від батьківських команд

--dry-run

Чи ввімкнути режим dry-run чи ні

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig для використання при спілкуванні з кластером. Якщо прапорець не встановлено, можна шукати наявний файл kubeconfig у наборі стандартних місць.

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.117 -

Виводить перелік токенів запуску на сервері

Опис

Ця команда виведе перелік всіх токенів запуску на сервері.

kubeadm token list [flags]

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігноруйте будь-які помилки в шаблонах, коли поле або ключ map відсутні в шаблоні. Застосовується лише до форматів виводу golang і jsonpath.

-o, --experimental-output string     Типово: "text"

Формат виводу. Один із: text|json|yaml|go-template|go-template-file|template|templatefile|jsonpath|jsonpath-as-json|jsonpath-file.

-h, --help

довідка list

--show-managed-fields

Якщо true, залиште managedFields під час вводу обʼєктів у форматі JSON або YAML.

Параметри успадковані від батьківських команд

--dry-run

Чи ввімкнути режим dry-run чи ні

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig для використання при спілкуванні з кластером. Якщо прапорець не встановлено, можна шукати наявний файл kubeconfig у наборі стандартних місць.

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.118 -

Оновлення кластера до новішої версії відбувається плавно за допомогою цієї команди

Опис

Оновлення кластера до новішої версії відбувається плавно за допомогою цієї команди

kubeadm upgrade [flags]

Параметри

-h, --help

Довідка upgrade

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.118.1 -

Оновлює кластер Kubernetes до вказаної версії.

Опис

Оновлює кластер Kubernetes до вказаної версії.

kubeadm upgrade apply [version]

Параметри

--allow-experimental-upgrades

Показує нестабільні версії Kubernetes як альтернативу для оновлення і дозволяє оновлювати до альфа/бета/версій кандидатів Kubernetes.

--allow-release-candidate-upgrades

Показує версії кандидатів на випуск Kubernetes як альтернативу для оновлення і дозволяє оновлювати до версій кандидатів на випуск Kubernetes.

--certificate-renewal     Типово: true

Виконує оновлення сертифікатів, які використовуються компонентами під час оновлення.

--config string

Шлях до файлу конфігурації kubeadm.

--dry-run

Не змінює жодного стану, просто показує дії, які будуть виконані.

--etcd-upgrade     Типово: true

Виконує оновлення etcd.

-f, --force

Примусове оновлення, навіть якщо деякі вимоги можуть бути не виконані. Це також передбачає неітерактивний режим.

-h, --help

довідка apply

--ignore-preflight-errors strings

Список перевірок, помилки яких будуть показані як попередження. Приклад: 'IsPrivilegedUser,Swap'. Значення 'all' ігнорує помилки з усіх перевірок.

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який буде використовуватися при зверненні до кластера. Якщо прапорець не заданий, буде проведено пошук файлу kubeconfig в стандартних місцях.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним із "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним із "strategic", "merge" або "json", і вони відповідають форматам патчів, які підтримуються kubectl. За замовчуванням "patchtype" - "strategic". "extension" повинен бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який може використовуватися для визначення порядку застосування патчів за алфавітом.

--print-config

Вказує, чи потрібно надрукувати файл конфігурації, який буде використаний під час оновлення.

-y, --yes

Виконати оновлення і не запитувати підтвердження (режим без взаємодії).

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.118.2 -

Показує які відмінності можуть бути застосовані до наявних маніфестів статичних Pod. Дивіться також: kubeadm upgrade apply --dry-run

Опис

Показує які відмінності можуть бути застосовані до наявних маніфестів статичних Pod. Дивіться також: kubeadm upgrade apply --dry-run

kubeadm upgrade diff [version] [flags]

Параметри

--config string

Шлях до файлу конфігурації kubeadm.

-c, --context-lines int     Типово: 3

Скільки рядків контексту в виведенні diff.

-h, --help

довідка diff

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який буде використовуватися при зверненні до кластера. Якщо прапорець не заданий, буде проведено пошук файлу kubeconfig в стандартних місцях.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.118.3 -

Команда upgrade для вузлів в кластері

Опис

Команда upgrade для вузлів в кластері.

Команда "node" виконує наступні фази:

preflight       Виконання попереднії перевірок оновлення вузла
control-plane   Оновлення екземпляру панелі управління, розгорнутий на цьому вузлі, якщо такий є
kubelet-config  Оновлення конфігурацію kubelet для цього вузла
kubeadm upgrade node [flags]

Параметри

--certificate-renewal     Типово: true

Виконати оновлення сертифікатів, використовуваних компонентами, які змінюються під час оновлення.

--config string

Шлях до файлу конфігурації kubeadm.

--dry-run

Не змінює жодного стану, просто показує дії, які будуть виконані.

--etcd-upgrade     Типово: true

Виконати оновлення etcd.

-h, --help

довідка node

--ignore-preflight-errors strings

Список перевірок, помилки в яких будуть відображені як попередження. Приклад: 'IsPrivilegedUser,Swap'. Значення 'all' ігнорує помилки з усіх перевірок.

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який буде використовуватися при зверненні до кластера. Якщо прапорець не заданий, буде проведено пошук файлу kubeconfig в стандартних місцях.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним із "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним із "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" - "strategic". "extension" повинен бути або "json", або "yaml". "suffix" - це необовʼязковий рядок, який може використовуватися для визначення порядку застосування патчів за алфавітном.

--skip-phases strings

Список фаз, які слід пропустити.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.118.4 -

Використовуйте цю команду для виклику однієї фази робочого процесу node

Опис

Використовуйте цю команду для виклику однієї фази робочого процесу node

Параметри

-h, --help

Довідка phase

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.118.5 -

Оновлює екземпляр панелі управління, розгорнутої на цьому вузлі, якщо така є

Опис

Оновлює екземпляр панелі управління, розгорнутої на цьому вузлі, якщо така є.

kubeadm upgrade node phase control-plane [flags]

Параметри

--certificate-renewal     Типово: true

Виконує оновлення сертифікатів, які використовуються компонентами під час оновлення.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

--etcd-upgrade     Типово: true

Виконує оновлення etcd.

-h, --help

Довідка control-plane

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.118.6 -

Оновлює конфігурації kubelet для цього вузла

Опис

Завантажує конфігурацію kubelet з файлу kubelet-config ConfigMap, що зберігається в кластері

kubeadm upgrade node phase kubelet-config [flags]

Параметри

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка kubelet-config

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.118.7 -

Виконує попередні перевірки на вузлі перед оновленням

Опис

Ця команда виконує попередні перевірки для kubeadm upgrade node.

kubeadm upgrade node phase preflight [flags]

Параметри

-h, --help

Довідка preflight

--ignore-preflight-errors strings

Список перевірок, помилки яких будуть показані як попередження. Приклад: 'IsPrivilegedUser,Swap'. Значення 'all' ігнорує помилки всіх перевірок.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.118.8 -

Перевіряє, до яких версій можна оновитися, і перевіряє, чи можна оновити ваш поточний кластер.

Опис

Перевіряє, до яких версій можна оновитися, і перевіряє, чи можна оновити ваш поточний кластер. Ця команда може бути виконана лише на вузлах панелі управління, де існує файл kubeconfig "admin.conf". Щоб пропустити перевірку Інтернету, вкажіть необовʼязковий параметр [version].

kubeadm upgrade plan [version] [flags]

Параметри

--allow-experimental-upgrades

Показати нестабільні версії Kubernetes як альтернативу для оновлення і дозволити оновлення до альфа/бета/кандидатів на випуск версій Kubernetes.

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли поле або ключ map відсутній у шаблоні. Застосовується лише до форматів виведення golang та jsonpath.

--allow-release-candidate-upgrades

Показати версії кандидатів на випуск Kubernetes як альтернативу для оновлення і дозволити оновлення до версій кандидатів на випуск Kubernetes.

--config string

Шлях до файлу конфігурації kubeadm.

-h, --help

довідка plan

--ignore-preflight-errors strings

Список перевірок, помилки яких будуть показані як попередження. Приклад: 'IsPrivilegedUser,Swap'. Значення 'all' ігнорує помилки з усіх перевірок.

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який буде використовуватися при зверненні до кластера. Якщо прапорець не заданий, буде проведено пошук файлу kubeconfig в стандартнх місцях.

-o, --output string     Типово: "text"

Формат виводу. Один із: text|json|yaml|go-template|go-template-file|template|templatefile|jsonpath|jsonpath-as-json|jsonpath-file.

--print-config

Вказує, чи потрібно надрукувати файл конфігурації, який буде використаний під час оновлення.

--show-managed-fields

Якщо true, зберігати managedFields під час виводу обʼєктів у форматі JSON або YAML.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.1.119 -

Оновлює кластер Kubernetes до вказаної версії.

Опис

Оновлює кластер Kubernetes до вказаної версії.

kubeadm upgrade apply [version]

Параметри

--allow-experimental-upgrades

Показує нестабільні версії Kubernetes як альтернативу для оновлення і дозволяє оновлювати до альфа/бета/версій кандидатів Kubernetes.

--allow-release-candidate-upgrades

Показує версії кандидатів на випуск Kubernetes як альтернативу для оновлення і дозволяє оновлювати до версій кандидатів на випуск Kubernetes.

--certificate-renewal     Типово: true

Виконує оновлення сертифікатів, які використовуються компонентами під час оновлення.

--config string

Шлях до файлу конфігурації kubeadm.

--dry-run

Не змінює жодного стану, просто показує дії, які будуть виконані.

--etcd-upgrade     Типово: true

Виконує оновлення etcd.

--feature-gates string

Набір пар ключ=значення, які описують відзначки функцій для різних функцій. Опції:
EtcdLearnerMode=true|false (BETA — default=true)
PublicKeysECDSA=true|false (DEPRECATED — default=false)
RootlessControlPlane=true|false (ALPHA — default=false)
UpgradeAddonsBeforeControlPlane=true|false (DEPRECATED — default=false)
WaitForAllControlPlaneComponents=true|false (ALPHA — default=false)

-f, --force

Примусове оновлення, навіть якщо деякі вимоги можуть бути не виконані. Це також передбачає неітерактивний режим.

-h, --help

довідка apply

--ignore-preflight-errors strings

Список перевірок, помилки яких будуть показані як попередження. Приклад: 'IsPrivilegedUser,Swap'. Значення 'all' ігнорує помилки з усіх перевірок.

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який буде використовуватися при зверненні до кластера. Якщо прапорець не заданий, буде проведено пошук файлу kubeconfig в стандартних місцях.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним із "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration". "patchtype" може бути одним із "strategic", "merge" або "json", і вони відповідають форматам патчів, які підтримуються kubectl. За замовчуванням "patchtype" - "strategic". "extension" повинен бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який може використовуватися для визначення порядку застосування патчів за алфавітом.

--print-config

Вказує, чи потрібно надрукувати файл конфігурації, який буде використаний під час оновлення.

-y, --yes

Виконати оновлення і не запитувати підтвердження (режим без взаємодії).

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.120 -

Показує які відмінності можуть бути застосовані до наявних маніфестів статичних Pod. Дивіться також: kubeadm upgrade apply --dry-run

Опис

Показує які відмінності можуть бути застосовані до наявних маніфестів статичних Pod. Дивіться також: kubeadm upgrade apply --dry-run

kubeadm upgrade diff [version] [flags]

Параметри

--api-server-manifest string     Типово: "/etc/kubernetes/manifests/kube-apiserver.yaml"

Шлях до маніфесту API сервера.

--config string

Шлях до файлу конфігурації kubeadm.

-c, --context-lines int     Типово: 3

Скільки рядків контексту в виведенні diff.

--controller-manager-manifest string     Типово: "/etc/kubernetes/manifests/kube-controller-manager.yaml"

Шлях до маніфесту контролера.

-h, --help

довідка diff

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який буде використовуватися при зверненні до кластера. Якщо прапорець не заданий, буде проведено пошук файлу kubeconfig в стандартних місцях.

--scheduler-manifest string     Типово: "/etc/kubernetes/manifests/kube-scheduler.yaml"

Шлях до маніфесту планувальника.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.121 -

Команда upgrade для вузлів в кластері

Опис

Команда upgrade для вузлів в кластері.

Команда "node" виконує наступні фази:

preflight       Виконання попереднії перевірок оновлення вузла
control-plane   Оновлення екземпляру панелі управління, розгорнутий на цьому вузлі, якщо такий є
kubelet-config  Оновлення конфігурацію kubelet для цього вузла
kubeadm upgrade node [flags]

Параметри

--certificate-renewal     Типово: true

Виконати оновлення сертифікатів, використовуваних компонентами, які змінюються під час оновлення.

--config string

Шлях до файлу конфігурації kubeadm.

--dry-run

Не змінює жодного стану, просто показує дії, які будуть виконані.

--etcd-upgrade     Типово: true

Виконати оновлення etcd.

-h, --help

довідка node

--ignore-preflight-errors strings

Список перевірок, помилки в яких будуть відображені як попередження. Приклад: 'IsPrivilegedUser,Swap'. Значення 'all' ігнорує помилки з усіх перевірок.

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який буде використовуватися при зверненні до кластера. Якщо прапорець не заданий, буде проведено пошук файлу kubeconfig в стандартних місцях.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним із "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration". "patchtype" може бути одним із "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" - "strategic". "extension" повинен бути або "json", або "yaml". "suffix" - це необовʼязковий рядок, який може використовуватися для визначення порядку застосування патчів за алфавітном.

--skip-phases strings

Список фаз, які слід пропустити.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.122 -

Використовуйте цю команду для виклику однієї фази робочого процесу node

Опис

Використовуйте цю команду для виклику однієї фази робочого процесу node

Параметри

-h, --help

Довідка phase

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.123 -

Оновлює екземпляр панелі управління, розгорнутої на цьому вузлі, якщо така є

Опис

Оновлює екземпляр панелі управління, розгорнутої на цьому вузлі, якщо така є.

kubeadm upgrade node phase control-plane [flags]

Параметри

--certificate-renewal     Типово: true

Виконує оновлення сертифікатів, які використовуються компонентами під час оновлення.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

--etcd-upgrade     Типово: true

Виконує оновлення etcd.

-h, --help

Довідка control-plane

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.124 -

Оновлює конфігурації kubelet для цього вузла

Опис

Завантажує конфігурацію kubelet з файлу kubelet-config ConfigMap, що зберігається в кластері

kubeadm upgrade node phase kubelet-config [flags]

Параметри

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка kubelet-config

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.125 -

Виконує попередні перевірки на вузлі перед оновленням

Опис

Ця команда виконує попередні перевірки для kubeadm upgrade node.

kubeadm upgrade node phase preflight [flags]

Параметри

-h, --help

Довідка preflight

--ignore-preflight-errors strings

Список перевірок, помилки яких будуть показані як попередження. Приклад: 'IsPrivilegedUser,Swap'. Значення 'all' ігнорує помилки всіх перевірок.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.126 -

Перевіряє, до яких версій можна оновитися, і перевіряє, чи можна оновити ваш поточний кластер.

Опис

Перевіряє, до яких версій можна оновитися, і перевіряє, чи можна оновити ваш поточний кластер. Ця команда може бути виконана лише на вузлах панелі управління, де існує файл kubeconfig "admin.conf". Щоб пропустити перевірку Інтернету, вкажіть необовʼязковий параметр [version].

kubeadm upgrade plan [version] [flags]

Параметри

--allow-experimental-upgrades

Показати нестабільні версії Kubernetes як альтернативу для оновлення і дозволити оновлення до альфа/бета/кандидатів на випуск версій Kubernetes.

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли поле або ключ map відсутній у шаблоні. Застосовується лише до форматів виведення golang та jsonpath.

--allow-release-candidate-upgrades

Показати версії кандидатів на випуск Kubernetes як альтернативу для оновлення і дозволити оновлення до версій кандидатів на випуск Kubernetes.

--config string

Шлях до файлу конфігурації kubeadm.

-o, --experimental-output string     Типово: "text"

Формат виводу. Один із: text|json|yaml|go-template|go-template-file|template|templatefile|jsonpath|jsonpath-as-json|jsonpath-file.

--feature-gates string

Набір пар ключ=значення, що описують функціональні можливості для різних функцій. Опції:
EtcdLearnerMode=true|false (BETA — default=true)
PublicKeysECDSA=true|false (DEPRECATED — default=false)
RootlessControlPlane=true|false (ALPHA — default=false)
UpgradeAddonsBeforeControlPlane=true|false (DEPRECATED — default=false)
WaitForAllControlPlaneComponents=true|false (ALPHA — default=false)

-h, --help

довідка plan

--ignore-preflight-errors strings

Список перевірок, помилки яких будуть показані як попередження. Приклад: 'IsPrivilegedUser,Swap'. Значення 'all' ігнорує помилки з усіх перевірок.

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який буде використовуватися при зверненні до кластера. Якщо прапорець не заданий, буде проведено пошук файлу kubeconfig в стандартнх місцях.

--print-config

Вказує, чи потрібно надрукувати файл конфігурації, який буде використаний під час оновлення.

--show-managed-fields

Якщо true, зберігати managedFields під час виводу обʼєктів у форматі JSON або YAML.

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

6.10.1.1.127 -

Виводіть версію kubeadm

Опис

Ця команда виводить версію kubeadm.

kubeadm version [flags]

Параметри

-h, --help

довідка version

-o, --output string

Формат виводу; доступні варіанти: 'yaml', 'json' та 'short'

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.2 - kubeadm init

Ця команда ініціалізує вузол панелі управління Kubernetes.

Запустіть цю команду, щоб налаштувати панель управління Kubernetes

Опис

Запустіть цю команду, щоб налаштувати панель управління Kubernetes

Команда "init" виконує наступні етапи:

preflight                     Виконання перевірок перед запуском
certs                         Генерація сертифікатів
  /ca                           Генерація самопідписаного CA Kubernetes для забезпечення ідентифікації інших компонентів Kubernetes
  /apiserver                    Генерація сертифіката для обслуговування Kubernetes API
  /apiserver-kubelet-client     Генерація сертифіката для зʼєднання API server з kubelet
  /front-proxy-ca               Генерація самопідписаного CA для забезпечення ідентифікації front proxy
  /front-proxy-client           Генерація сертифіката для клієнта front proxy
  /etcd-ca                      Генерація самопідписаного CA для забезпечення ідентифікації etcd
  /etcd-server                  Генерація сертифіката для обслуговування etcd
  /etcd-peer                    Генерація сертифіката для звʼязку між вузлами etcd
  /etcd-healthcheck-client      Генерація сертифіката для перевірки живучості etcd
  /apiserver-etcd-client        Генерація сертифіката, який використовується apiserver для доступу до etcd
  /sa                           Генерація приватного ключа для підписання токенів службових облікових записів разом з його відкритим ключем
kubeconfig                    Генерація всіх kubeconfig файлів, необхідних для створення панелі управління, та kubeconfig файлу адміністратора
  /admin                        Генерація kubeconfig файлу для використання адміністратором та самим kubeadm
  /super-admin                  Генерація kubeconfig файлу для супер-адміністратора
  /kubelet                      Генерація kubeconfig файлу для використання kubelet *лише* для завантаження кластера
  /controller-manager           Генерація kubeconfig файлу для використання контролер-менеджером
  /scheduler                    Генерація kubeconfig файлу для використання планувальником
etcd                          Генерація маніфесту статичного Pod для локального etcd
  /local                        Генерація маніфесту статичного Pod для локального, одновузлового локального etcd
control-plane                 Генерація всіх маніфестів статичних Podʼів, необхідних для створення панелі управління
  /apiserver                    Генерація маніфесту статичного Pod для kube-apiserver
  /controller-manager           Генерація маніфесту статичного Pod для kube-controller-manager
  /scheduler                    Генерація маніфесту статичного Pod для kube-scheduler
kubelet-start                 Запис налаштувань kubelet та (перезавантаження) kubelet
upload-config                 Завантаження конфігурації kubeadm та kubelet у ConfigMap
  /kubeadm                      Завантаження конфігурації кластера kubeadm у ConfigMap
  /kubelet                      Завантаження конфігурації компоненту kubelet у ConfigMap
upload-certs                  Завантаження сертифікатів у kubeadm-certs
mark-control-plane            Маркування вузла як вузла панелі управління
bootstrap-token               Генерація bootstrap токенів, які використовуються для приєднання вузла до кластера
kubelet-finalize             Оновлення налаштувань, що стосуються kubelet, після TLS завантаження
  /enable-client-cert-rotation  Ввімкнути ротацію сертифікатів клієнтів kubelet
  /experimental-cert-rotation   Ввімкнути ротацію сертифікатів клієнтів kubelet (ЗАСТАРІЛО: натомість використовуйте 'enable-client-cert-rotation')
  /experimental-cert-rotation  Увімкнення ротації сертифікатів клієнта kubelet
addon                        Встановлення необхідних надбудов для проходження тестів відповідності
  /coredns                     Встановлення надбудови CoreDNS у Kubernetes кластер
  /kube-proxy                  Встановлення надбудови kube-proxy у Kubernetes кластер
show-join-command            Показати команду приєднання для вузлів керування та робочих вузлів
kubeadm init [прапорці]

Параметри

--apiserver-advertise-address string

IP адреса, за якою API Server буде оголошувати, що він слухає. Якщо не встановлено, буде використаний стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого буде привʼязаний API Server.

--apiserver-cert-extra-sans strings

Додаткові опціональні альтернативні імена субʼєкта (SANs) для використання в сертифікаті обслуговування API Server. Можуть бути як IP-адреси, так і DNS імена.

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях для збереження та зберігання сертифікатів.

--certificate-key string

Ключ, що використовується для шифрування сертифікатів панелі управління у Secret kubeadm-certs. Ключ сертифіката — це шістнадцятковий рядок, який є ключем AES розміром 32 байти

--config string

Шлях до файлу конфігурації kubeadm.

--control-plane-endpoint string

Вкажіть стабільну IP адресу або DNS імʼя для панелі управління.

--cri-socket string

Шлях до сокета CRI для підключення. Якщо не заповнено, kubeadm спробує автоматично визначити це значення; використовуйте цю опцію тільки якщо у вас встановлено більше одного CRI або якщо у вас нестандартний сокет CRI.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

--feature-gates string

Набір пар ключ=значення, що описують функціональні можливості для різних функцій. Опції:
ControlPlaneKubeletLocalMode=true|false (ALPHA — default=false)
EtcdLearnerMode=true|false (BETA — default=true)
PublicKeysECDSA=true|false (DEPRECATED — default=false)
RootlessControlPlane=true|false (ALPHA — default=false)
WaitForAllControlPlaneComponents=true|false (ALPHA — default=false)

-h, --help

довідка init

--ignore-preflight-errors strings

Список перевірок, помилки яких будуть показані як попередження. Приклад: 'IsPrivilegedUser,Swap'. Значення 'all' ігнорує помилки всіх перевірок.

--image-repository string     Типово: "registry.k8s.io"

Виберіть реєстр контейнерів для завантаження образів панелі управління

--kubernetes-version string     Типово: "stable-1"

Виберіть конкретну версію Kubernetes для панелі управління.

--node-name string

Вкажіть імʼя вузла.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

--pod-network-cidr string

Вкажіть діапазон IP-адрес для мережі Podʼів. Якщо встановлено, панель управління автоматично виділить CIDR для кожного вузла.

--service-cidr string     Типово: "10.96.0.0/12"

Використовуйте альтернативний діапазон IP-адрес для VIP сервісів.

--service-dns-domain string     Типово: "cluster.local"

Використовуйте альтернативний домен для сервісів, наприклад "myorg.internal".

--skip-certificate-key-print

Не виводити ключ, який використовується для шифрування сертифікатів панелі управління.

--skip-phases strings

Список етапів, які потрібно оминути

--skip-token-print

Пропустити друк стандартного bootstrap токена, згенерованого 'kubeadm init'.

--token string

Токен для встановлення двосторонньої довіри між вузлами та вузлами панелі управління. Формат [a-z0-9]{6}.[a-z0-9]{16} — наприклад, abcdef.0123456789abcdef

--token-ttl duration     Типово: 24h0m0s

Час перед автоматичним видаленням токена (наприклад, 1s, 2m, 3h). Якщо встановлено '0', токен ніколи не закінчиться

--upload-certs

Завантажити сертифікати панелі управління у Secret kubeadm-certs.

Параметри успадковані від батьківських команд

--rootfs string

[ЕКСПЕРИМЕНТАЛЬНО] Шлях до 'реальної' кореневої файлової системи хоста.

Процес Init

kubeadm init розгортає вузол панелі управління Kubernetes, виконуючи наступні кроки:

  1. Виконує серію перевірок перед запуском, щоб перевірити стан системи перед внесенням змін. Деякі перевірки лише видають попередження, інші вважаються помилками, і kubeadm припиняє роботу, доки проблема не буде виправлена або користувач не вкаже --ignore-preflight-errors=<list-of-errors>.

  2. Генерує самопідписний CA для налаштування ідентифікаторів для кожного компонента в кластері. Користувач може надати свої власні сертифікат та/або ключ CA, помістивши їх у теку сертифікатів, налаштовану через --cert-dir (типово /etc/kubernetes/pki). Сертифікати APIServer матимуть додаткові записи SAN для будь-яких аргументів --apiserver-cert-extra-sans, з приведенням до нижнього регістру за потреби.

  3. Записує файли kubeconfig у /etc/kubernetes/ для kubelet, controller-manager та scheduler для підключення до API server, кожен зі своїм ідентифікатором. Також створюються додаткові файли kubeconfig, для kubeadm як адміністративної сутності (admin.conf) та для супер адміністратора, що може обходити RBAC (super-admin.conf).

  4. Генерує манифести статичних Pod для API server, controller-manager та scheduler. Якщо зовнішній etcd не надано, створюється додатковий маніфест статичного Pod для etcd.

    Статичні манифести Pod записуються у /etc/kubernetes/manifests; kubelet спостерігає за цією текою для створення Podʼів при запуску.

    Як тільки Podʼи панелі управління будуть запущені та працюватимуть, процес kubeadm init може продовжитися.

  5. Додає мітки та taint на вузол панелі управління, щоб жодні додаткові робочі навантаження не запускалися там.

  6. Генерує токен, який додаткові вузли можуть використовувати для реєстрації у майбутньому на вузлі панелі управління. За бажанням, користувач може надати токен через --token, як описано в документації kubeadm token.

  7. Виконує всі необхідні налаштування для дозволу приєднання вузлів за допомогою механізмів Bootstrap Tokens та TLS Bootstrap:

    • Записує ConfigMap для надання всієї необхідної інформації для приєднання, та налаштовує відповідні правила доступу RBAC.

    • Дозволяє Bootstrap Tokens доступ до API підписання CSR.

    • Налаштовує автоматичне схвалення нових запитів CSR.

    Див. kubeadm join для додаткової інформації.

  8. Встановлює DNS сервер (CoreDNS) та компоненти надбудови kube-proxy через API server. У версії Kubernetes 1.11 і пізніших CoreDNS є типовим сервером DNS. Зверніть увагу, що хоча DNS сервер розгорнутий, він не буде запланований до встановлення CNI.

Використання фаз ініціалізації з kubeadm

Kubeadm дозволяє створювати вузол панелі управління поетапно, використовуючи команду kubeadm init phase.

Щоб переглянути впорядкований список фаз та підфаз, можна викликати kubeadm init --help. Список буде розташований на початку екрана довідки, і кожна фаза матиме опис поруч із нею. Зверніть увагу, що при виклику kubeadm init всі фази та підфази будуть виконані в точно такому порядку.

Деякі фази мають унікальні прапорці, тому, якщо ви хочете переглянути список доступних опцій, додайте --help, наприклад:

sudo kubeadm init phase control-plane controller-manager --help

Ви також можете використовувати --help, щоб побачити список підфаз для певної батьківської фази:

sudo kubeadm init phase control-plane --help

kubeadm init також має прапорець --skip-phases, який можна використовувати для пропуску певних фаз. Прапорець приймає список назв фаз, які можна взяти з вищезгаданого впорядкованого списку.

Приклад:

sudo kubeadm init phase control-plane all --config=configfile.yaml
sudo kubeadm init phase etcd local --config=configfile.yaml
# тепер ви можете змінити файли маніфестів панелі управління та etcd
sudo kubeadm init --skip-phases=control-plane,etcd --config=configfile.yaml

Цей приклад записує файли маніфесту для панелі управління та etcd у /etc/kubernetes/manifests на основі конфігурації в configfile.yaml. Це дозволяє вам змінювати файли, а потім пропускати ці фази, використовуючи --skip-phases. Викликом останньої команди ви створите вузол панелі управління з власними файлами маніфестів.

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.22 [beta]

Альтернативно, ви можете використовувати поле skipPhases у InitConfiguration.

Використання kubeadm init з конфігураційним файлом

Можна налаштувати kubeadm init за допомогою конфігураційного файлу замість прапорців командного рядка, а деякі більш розширені функції можуть бути доступні лише як опції конфігураційного файлу. Цей файл передається за допомогою прапорця --config, і він повинен містити структуру ClusterConfiguration і, за бажанням, інші структури, розділені ---\n. Змішування --config з іншими прапорцями може не бути дозволеним у деяких випадках.

Ви можете вивести стандартну конфігурацію за допомогою команди kubeadm config print.

Якщо ваша конфігурація не використовує останню версію, рекомендується перейти на нову версію за допомогою команди kubeadm config migrate.

Для отримання додаткової інформації про поля та використання конфігурації ви можете перейти на нашу сторінку API-довідки.

Використання kubeadm init з функціональними можливостями

Kubeadm підтримує набір функціональних можливостей (feature gate), які унікальні для kubeadm і можуть бути застосовані лише під час створення кластера за допомогою kubeadm init. Ці функціональні можливості можуть контролювати поведінку кластера. Функціональні можливості видаляються після того, як функція переходить до стадії GA (General Availability).

Щоб передати функціональні можливості, можна використовувати прапорець --feature-gates для kubeadm init, або можна додати елементи до поля featureGates, коли передаєте конфігураційний файл за допомогою --config.

Передача функціональних можливостей для основних компонентів Kubernetes безпосередньо в kubeadm не підтримується. Натомість це можливо зробити за допомогою налаштування компонентів за допомогою API kubeadm.

Список функціональних можливостей:

Прапорці функцій kubeadm
ФункціяСтандартноAlphaBetaGA
ControlPlaneKubeletLocalModefalse1.31--
EtcdLearnerModetrue1.271.29-
PublicKeysECDSAfalse1.19--
WaitForAllControlPlaneComponentsfalse1.30--

Опис функціональних можливостей:

ControlPlaneKubeletLocalMode
З цією функціональною можливістю, при приєднанні нового вузла панелі управління kubeadm налаштовуватиме kubelet для підключення до локального kube-apiserver. Це забезпечує дотримання політики щодо версійних розбіжностей під час постійних оновлень (rolling upgrades).
EtcdLearnerMode
З цією функціональною можливістю, коли приєднується новий вузол панелі управління, буде створений новий учасник etcd як 'учень' і його буде підвищено до учасника з правом голосу лише після повного узгодження даних etcd.
PublicKeysECDSA
Може бути використаний для створення кластера, що використовує сертифікати ECDSA замість стандартного алгоритму RSA. Також підтримується оновлення поточних сертифікатів ECDSA за допомогою kubeadm certs renew, але ви не можете перемикатися між алгоритмами RSA та ECDSA на ходу або під час оновлення. У Kubernetes 1.31 є помилка, коли ключі у згенерованих kubeconfig файлах встановлюються для використання RSA, попри увімкнену функціональну можливість. У версіях Kubernetes до v1.31 була помилка, коли ключі у згенерованих файлах kubeconfig встановлювалися з використанням RSA, навіть якщо ви увімкнули функціональну можливість PublicKeysECDSA.
WaitForAllControlPlaneComponents
З цією функціональною можливістю kubeadm буде чекати, поки всі компоненти панелі управління (kube-apiserver, kube-controller-manager, kube-scheduler) на вузлі панелі управління не повідомлять статус 200 на їхніх точках доступу /healthz. Ці перевірки виконуються на https://127.0.0.1:PORT/healthz, де PORT береться з --secure-port компонента. Якщо ви вкажете власні значення --secure-port у конфігурації kubeadm, вони будуть використані. Без ввімкненої функціональної можливості kubeadm буде чекати лише, поки kube-apiserver на вузлі панелі управління стане готовим. Процес очікування починається відразу після того, як kubelet на хості запускається за допомогою kubeadm. Рекомендується ввімкнути цю функціональну можливість, якщо ви хочете спостерігати готовність усіх компонентів панелі управління під час виконання команди kubeadm init або kubeadm join.

Список застарілих функціональних можливостей:

Застарілі функціональні можливості kubeadm
ФункціяСтандартноAlphaBetaGADeprecated
RootlessControlPlanefalse1.22--1.31

Опис застарілих функціональних можливостей:

RootlessControlPlane
Встановлення цього прапорця налаштовує розгорнуті компоненти панелі управління kubeadm у статичних Podʼах для kube-apiserver, kube-controller-manager, kube-scheduler та etcd для запуску від імені користувачів без прав суперкористувача. Якщо прапорець не встановлений, ці компоненти запускаються з правами root. Ви можете змінити значення цього прапорця функції перед оновленням до нової версії Kubernetes.

Список видалених функціональних можливостей:

Видалені функціональні можливості kubeadm
ЕлементAlphaBetaGAВидалено
IPv6DualStack1.161.211.231.24
UnversionedKubeletConfigMap1.221.231.251.26
UpgradeAddonsBeforeControlPlane1.28--1.31

Опис видалених функціональних можливостей:

IPv6DualStack
Цей прапорець допомагає налаштувати компоненти подвійного стека, коли функція знаходиться в процесі розробки. Для отримання більш детальної інформації про підтримку подвійного стека в Kubernetes дивіться Підтримка подвійного стека за допомогою kubeadm.
UnversionedKubeletConfigMap
Цей прапорець контролює назву ConfigMap, в якому kubeadm зберігає дані конфігурації kubelet. Якщо цей прапорець не вказаний або встановлений у true, ConfigMap називається kubelet-config. Якщо ви встановите цей прапорець у false, назва ConfigMap включатиме основну та додаткову версію для Kubernetes (наприклад: kubelet-config-1.31). Kubeadm забезпечує, що правила RBAC для читання та запису цього ConfigMap є відповідними до значення, яке ви встановили. Коли kubeadm записує цей ConfigMap (під час kubeadm init або kubeadm upgrade apply), kubeadm дотримується значення UnversionedKubeletConfigMap. При читанні цього ConfigMap (під час kubeadm join, kubeadm reset, kubeadm upgrade ...), kubeadm спочатку намагається використовувати назву ConfigMap без версії; якщо це не вдається, kubeadm переходить до використання застарілої (версійної) назви для цього ConfigMap.
UpgradeAddonsBeforeControlPlane
Цю функціональну можливість було видалено. Вона була визнана у версії v1.28 як застаріла функція і потім видалена у версії v1.31. Для документації щодо старіших версій, будь ласка, перейдіть на відповідну версію вебсайту.

Додавання параметрів kube-proxy

Для отримання інформації про параметри kube-proxy у конфігурації kubeadm дивіться:

Для отримання інформації про увімкнення режиму IPVS за допомогою kubeadm дивіться:

Передача власних прапорців користувача до компонентів панелі управління

Для отримання інформації про передачу прапорців до компонентів панелі управління дивіться:

Використання kubeadm без підключення до Інтернету

Для запуску kubeadm без підключення до Інтернету необхідно попередньо завантажити необхідні образи панелі управління.

Ви можете отримати перелік та завантажити образи за допомогою команди kubeadm config images:

kubeadm config images list
kubeadm config images pull

Ви можете використати --config з вищенаведеними командами з файлом конфігурації kubeadm для контролю полів kubernetesVersion та imageRepository.

Усі стандартні образи registry.k8s.io, необхідні kubeadm, підтримують кілька архітектур.

Використання власних образів

Стандартно, kubeadm завантажує образи з registry.k8s.io. Якщо запитана версія Kubernetes є CI міткою (наприклад, ci/latest), використовується gcr.io/k8s-staging-ci-images.

Ви можете змінити цю поведінку, використовуючи kubeadm з файлом конфігурації. Дозволені налаштування:

  • Вказати kubernetesVersion, що впливає на версію образів.
  • Вказати альтернативний imageRepository, який буде використовуватися замість registry.k8s.io.
  • Вказати конкретний imageRepository та imageTag для etcd або CoreDNS.

Шляхи образів між стандартним registry.k8s.io та власним репозиторієм, зазначеним за допомогою imageRepository, можуть відрізнятися з причин зворотної сумісності. Наприклад, один образ може мати підшлях у registry.k8s.io/subpath/image, але стандартно бути my.customrepository.io/image при використанні власного репозиторію користувача.

Щоб переконатися, що ви завантажуєте образи до вашого власного репозиторію у шляхи, які може використовувати kubeadm, вам потрібно:

  • Завантажити образи зі стандартних шляхів з registry.k8s.io за допомогою kubeadm config images {list|pull}.
  • Завантажити образи до шляхів з kubeadm config images list --config=config.yaml, де config.yaml містить власне значення imageRepository та/або imageTag для etcd та CoreDNS.
  • Передати той самий config.yaml до kubeadm init.

Власні образи sandbox (pause)

Щоб встановити власний образ для цих контейнерів, потрібно налаштувати ваше середовище виконання контейнерів для використання цього образу. Зверніться до документації вашого середовища виконання контейнерів, щоб дізнатися, як змінити це налаштування; для певних середовищ виконання контейнерів ви також можете знайти поради у розділі Середовища виконання контейнерів.

Завантаження сертифікатів панелі управління до кластера

Додавши прапорець --upload-certs до kubeadm init, ви можете тимчасово завантажити сертифікати панелі управління до Secret у кластері. Зверніть увагу, що дія цього Secret автоматично спливає через 2 години. Сертифікати шифруються за допомогою 32-байтного ключа, який можна задати за допомогою --certificate-key. Той самий ключ можна використовувати для завантаження сертифікатів при приєднанні додаткових вузлів панелі управління, передавши --control-plane та --certificate-key до kubeadm join.

Для повторного завантаження сертифікатів після закінчення їхнього терміну дії можна використовувати таку команду фази:

kubeadm init phase upload-certs --upload-certs --config=SOME_YAML_FILE

Якщо попередньо визначений ключ сертифіката не передано до kubeadm init і kubeadm init phase upload-certs, новий ключ буде згенеровано автоматично.

Для генерації нового ключа за запитом можна використовувати наступну команду:

kubeadm certs certificate-key

Управління сертифікатами за допомогою kubeadm

Для отримання докладної інформації про управління сертифікатами за допомогою kubeadm перегляньте Управління сертифікатами за допомогою kubeadm. Документ містить інформацію про використання зовнішнього центру сертификації (CA), власні сертифікати та оновлення сертифікатів.

Керування drop-in файлом для kubelet у kubeadm

Пакет kubeadm постачається з файлом конфігурації для запуску kubelet через systemd. Зауважте, що CLI kubeadm ніколи не торкається цього drop-in файлу. Цей drop-in файл є частиною пакунка kubeadm DEB/RPM.

Для отримання додаткової інформації дивіться Керування drop-in файлом для systemd в kubeadm.

Використання kubeadm з CRI runtimes

Стандартно kubeadm намагається зʼясувати яке у вас середовище виконання контейнерів. Для детальнішої інформації щодо цього, дивіться посібник з установки CRI для kubeadm.

Налаштування імені вузла

Типово kubeadm присвоює імʼя вузла на основі мережевої адреси машини. Ви можете змінити це налаштування за допомогою прапорця --node-name. Цей прапорець передає відповідне значення --hostname-override до kubelet.

Зверніть увагу, що заміна імені хосту може вплинути на роботу хмарних провайдерів, деталі за посиланням.

Автоматизація kubeadm

Замість копіювання токену, який ви отримали з kubeadm init на кожний вузол, як у базовому посібнику з kubeadm, ви можете паралельно розподіляти токен для полегшення автоматизації. Щоб реалізувати цю автоматизацію, вам потрібно знати IP-адресу, яку матиме вузол панелі управління після запуску, або використовувати DNS-імʼя чи адресу балансувальника навантаження.

  1. Згенеруйте токен. Цей токен повинен мати форму <6 символьний рядок>.<16 символьний рядок>. Формально він повинен відповідати регулярному виразу: [a-z0-9]{6}\.[a-z0-9]{16}.

    kubeadm може згенерувати токен для вас:

    kubeadm token generate
    
  2. Запустіть одночасно вузол панелі управління та робочі вузли з цим токеном. Під час їх запуску вони мають знайти один одного та сформувати кластер. Той самий аргумент --token можна використовувати як у kubeadm init, так і у kubeadm join.

  3. Аналогічно можна поступити з --certificate-key при приєднанні додаткових вузлів панелі управління. Ключ можна згенерувати за допомогою:

    kubeadm certs certificate-key
    

Як тільки кластер буде запущений, ви зможете використовувати файл /etc/kubernetes/admin.conf з вузла панелі управління для спілкування з кластером з адміністративними правами чи Генерація файлів kubeconfig для додаткових користувачів.

Зауважте, що цей спосіб ініціалізації має деякі спрощені гарантії безпеки, оскільки не дозволяє перевіряти кореневий хеш сертифіката з --discovery-token-ca-cert-hash (оскільки він не генерується при проведенні вузлів). Докладні відомості дивіться в kubeadm join.

Що далі

  • kubeadm init phase для отримання більш детальної інформації про фази kubeadm init.
  • kubeadm join для налаштування робочого вузла Kubernetes та його приєднання до кластера.
  • kubeadm upgrade для оновлення кластера Kubernetes до новішої версії.
  • kubeadm reset для скидання будь-яких змін, внесених до цього хосту за допомогою kubeadm init або kubeadm join.

6.10.1.3 - kubeadm join

Ця команда ініціалізує робочий вузол Kubernetes і приєднує його до кластера.

Запустіть цю команду на будь-якому компʼютері, який ви хочете приєднати до існуючого кластера

Опис

Під час приєднання до ініціалізованого кластера за допомогою kubeadm, необхідно встановити двосторонню довіру. Цей процес розділяється на два етапи: виявлення (щоб Node довіряв Панелі Управління Kubernetes) та TLS завантаження (щоб Панель управління Kubernetes довіряла Node).

Існує дві основні схеми для виявлення. Перша — використовувати спільний токен разом з IP-адресою сервера API. Друга — надати файл, який є підмножиною стандартного файлу kubeconfig. Файл discovery/kubeconfig підтримує токен, втулки автентифікації client-go ("exec"), "tokenFile" та "authProvider". Цей файл може бути локальним або завантаженим через URL HTTPS. Форми приєднання є:

kubeadm join --discovery-token abcdef.1234567890abcdef 1.2.3.4:6443
kubeadm join --discovery-file path/to/file.conf
kubeadm join --discovery-file https://url/file.conf

Можна використовувати лише одну форму. Якщо інформація для виявлення завантажується з URL, обовʼязково використовувати HTTPS. У цьому випадку для перевірки зʼєднання використовується встановлений на хості набір сертифікатів CA.

Якщо ви використовуєте спільний токен для виявлення, слід також передати прапорець --discovery-token-ca-cert-hash для перевірки публічного ключа кореневого центру сертифікації (CA), який представлений Панеллю Управління Kubernetes. Значення цього прапорця визначається як "<тип-хешу>:<шестнадцяткове-кодоване-значення>", де підтримуваний тип хешу — "sha256". Хеш обчислюється по байтах обʼєкта Subject Public Key Info (SPKI) (як в RFC7469). Це значення доступне у вихідних даних "kubeadm init" або може бути обчислене за допомогою стандартних інструментів. Прапорець --discovery-token-ca-cert-hash може бути повторений кілька разів, щоб дозволити використання більше одного публічного ключа.

Якщо ви не можете знати хеш публічного ключа CA заздалегідь, ви можете передати прапорець --discovery-token-unsafe-skip-ca-verification для вимкнення цієї перевірки. Це послаблює модель безпеки kubeadm, оскільки інші вузли можуть потенційно видавати себе за Панель Управління Kubernetes.

Механізм TLS завантаження також керується через спільний токен. Це використовується для тимчасової автентифікації в Панелі Управління Kubernetes для подання запиту на підписання сертифіката (CSR) для локально створеної пари ключів. Типово, kubeadm налаштує Панель Управління Kubernetes автоматично схвалювати ці запити на підписання. Цей токен передається за допомогою прапорця --tls-bootstrap-token abcdef.1234567890abcdef.

Часто той самий токен використовується для обох частин. У цьому випадку прапорець --token можна використовувати замість окремого зазначення кожного токена.

Команда "join [api-server-endpoint]" виконує наступні фази:

preflight              Виконати передстартові перевірки для приєднання
control-plane-prepare  Підготувати машину для обслуговування панелі управління
  /download-certs        Завантажити сертифікати, спільні для вузлів панелі управління, з Secret kubeadm-certs
  /certs                 Створити сертифікати для нових компонентів панелі управління
  /kubeconfig            Створити kubeconfig для нових компонентів панелі управління
  /control-plane         Створити маніфести для нових компонентів панелі управління
kubelet-start          Записати налаштування kubelet, сертифікати та (перезавантажити) kubelet
control-plane-join     Приєднати машину як екземпляр панелі управління
  /etcd                  Додати нового локального члена etcd
  /mark-control-plane    Позначити вузол як панель управління
wait-control-plane     Експериментально: чекати запуску панелі управління
kubeadm join [api-server-endpoint] [flags]

Параметри

--apiserver-advertise-address string

Якщо вузол має хостити новий екземпляр панелі управління, IP-адреса, яку сервер API буде оголошувати як ту, на якій він слухає. Якщо не встановлено, буде використовуватися стандартний інтерфейс.

--apiserver-bind-port int32     Стандартно: 6443

Якщо вузол має хостити новий екземпляр панелі управління, порт, до якого буде привʼязаний сервер API.

--certificate-key string

Використовуйте цей ключ для розшифрування секретів сертифікатів, завантажених за допомогою init. Ключ сертифіката — це шестнадцятковий закодований рядок, який є AES ключем розміром 32 байти.

--config string

Шлях до файлу конфігурації kubeadm.

--control-plane

Створити новий екземпляр панелі управління на цьому вузлі

--cri-socket string

Шлях до CRI сокета для підключення. Якщо не встановлено, kubeadm спробує автоматично визначити це значення; використовуйте цей параметр, лише якщо у вас встановлено більше одного CRI або якщо у вас нестандартний CRI сокет.

--discovery-file string

Для виявлення на основі файлу, файл або URL, з якого буде завантажена інформація про кластер.

--discovery-token string

Для виявлення на основі токена, токен, який використовується для перевірки інформації про кластер, отриманої з сервера API.

--discovery-token-ca-cert-hash strings

Для виявлення на основі токена, перевірити, що публічний ключ кореневого центру сертифікації відповідає цьому хешу (формат: "<тип>:<значення>").

--discovery-token-unsafe-skip-ca-verification

Для виявлення на основі токена, дозволити приєднання без закріплення --discovery-token-ca-cert-hash.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка join

--ignore-preflight-errors strings

Список перевірок, помилки яких будуть показані як попередження. Приклад: 'IsPrivilegedUser,Swap'. Значення 'all' ігнорує помилки від усіх перевірок.

--node-name string

Вказати імʼя вузла.

--patches string

Шлях до теки, що містить файли з назвами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним з "strategic", "merge" або "json" і відповідають форматам патчів, підтримуваних kubectl. Типовий "patchtype" — "strategic". "extension" має бути або "json", або "yaml". "suffix" — це необовʼязковий рядок, який можна використовувати для визначення, які патчі застосовуються першими в алфавітно-числовому порядку.

--skip-phases strings

Список фаз, які потрібно пропустити

--tls-bootstrap-token string

Вкажіть токен, який використовується для тимчасової автентифікації з Панеллю Управління Kubernetes під час приєднання вузла.

--token string

Використовуйте цей токен для discovery-token та tls-bootstrap-token, коли ці значення не вказані окремо.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Процес приєднання

kubeadm join ініціалізує робочий вузол Kubernetes або вузол панелі управління та додає його до кластера. Ця дія складається з наступних кроків для робочих вузлів:

  1. kubeadm завантажує необхідну інформацію про кластер з сервера API. Стандартно використовується токен початкового завантаження та хеш ключа CA для перевірки достовірності цих даних. Кореневий CA також може бути виявлений безпосередньо через файл або URL.

  2. Як тільки інформація про кластер відома, kubelet може почати процес TLS початкового завантаження.

    Завантажувач TLS використовує спільний токен для тимчасової автентифікації з сервером API Kubernetes для надсилання запиту на підписання сертифіката (CSR); стандартно панель управління підписує цей CSR-запит автоматично.

  3. Нарешті, kubeadm налаштовує локальний kubelet для підключення до сервера API з остаточною ідентичністю, призначеною вузлу.

Для вузлів панелі управління виконуються додаткові кроки:

  1. Завантаження сертифікатів, спільних для вузлів панелі управління з кластера (якщо це явно запитано користувачем).

  2. Генерація маніфестів компонентів панелі управління, сертифікатів та kubeconfig.

  3. Додавання нового локального члена etcd.

Використання фаз приєднання з kubeadm

Kubeadm дозволяє приєднати вузол до кластера поетапно, використовуючи kubeadm join phase.

Щоб переглянути впорядкований список фаз та підфаз, можна викликати kubeadm join --help. Список буде розташований у верхній частині екрана допомоги, і кожна фаза буде мати опис поруч із нею. Зверніть увагу, що при виклику kubeadm join усі фази та підфази будуть виконані саме в цьому порядку.

Деякі фази мають унікальні прапорці, тому якщо ви хочете переглянути список доступних опцій, додайте --help, наприклад:

kubeadm join phase kubelet-start --help

Подібно до команди kubeadm init phase, команда kubeadm join phase дозволяє пропустити список фаз, використовуючи прапорець --skip-phases.

Наприклад:

sudo kubeadm join --skip-phases=preflight --config=config.yaml
СТАН ФУНКЦІОНАЛУ: Kubernetes v1.22 [beta]

Крім того, ви можете використовувати поле skipPhases в JoinConfiguration.

Визначення, якому CA кластера довіряти

Процес виявлення kubeadm має кілька варіантів, кожен з яких має свої компроміси щодо безпеки. Правильний метод для вашого середовища залежить від того, як ви впроваджуєте вузли та які вимоги до безпеки у вас є щодо вашої мережі та життєвого циклу вузлів.

Виявлення на основі токена з закріпленням CA

Це типовий режим у kubeadm. У цьому режимі kubeadm завантажує конфігурацію кластера (включаючи кореневий CA) та перевіряє її за допомогою токена, а також перевіряє, що відкритий ключ кореневого CA відповідає наданому хешу і що сертифікат сервера API дійсний в кореневому CA.

Хеш ключа CA має формат sha256:<hex_encoded_hash>. Стандартне значення хешу друкується в кінці команди kubeadm init або у виведенні команди kubeadm token create --print-join-command. Воно знаходиться в стандартному форматі (див. RFC7469) і може бути також обчислено сторонніми інструментами або системами забезпечення. Наприклад, використовуючи OpenSSL CLI:

openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der 2>/dev/null | openssl dgst -sha256 -hex | sed 's/^.* //'

Приклади команд kubeadm join:

Для робочих вузлів:

kubeadm join --discovery-token abcdef.1234567890abcdef --discovery-token-ca-cert-hash sha256:1234..cdef 1.2.3.4:6443

Для вузлів панелі управління:

kubeadm join --discovery-token abcdef.1234567890abcdef --discovery-token-ca-cert-hash sha256:1234..cdef --control-plane 1.2.3.4:6443

Ви також можете викликати join для вузла панелі управління з прапорцем --certificate-key для копіювання сертифікатів на цей вузол, якщо команда kubeadm init була викликана з прапорцем --upload-certs.

Переваги:

  • Дозволяє вузлам початкового завантаження безпечно виявляти корінь довіри для вузла панелі управління, навіть якщо інші робочі вузли або мережа скомпрометовані.

  • Зручно виконувати вручну, оскільки вся необхідна інформація вміщується в одну команду kubeadm join.

Недоліки:

  • Хеш CA зазвичай не відомий до тих пір, поки вузол панелі управління не буде впроваджений, що може ускладнити створення автоматизованих інструментів впровадження, які використовують kubeadm. Генеруючи свій CA заздалегідь, ви можете обійти це обмеження.

Виявлення на основі токена без закріплення CA

Цей режим покладається лише на симетричний токен для підпису (HMAC-SHA256) інформації про виявлення, що встановлює корінь довіри для панелі управління. Щоб використовувати цей режим, вузли, що приєднуються, повинні пропустити перевірку хешу публічного ключа CA, використовуючи --discovery-token-unsafe-skip-ca-verification. Якщо можливо, слід розглянути використання одного з інших режимів.

Приклад команди kubeadm join:

kubeadm join --token abcdef.1234567890abcdef --discovery-token-unsafe-skip-ca-verification 1.2.3.4:6443

Переваги:

  • Все ще захищає від багатьох атак на рівні мережі.

  • Токен можна створити заздалегідь і поділитися з вузлом панелі управління та робочими вузлами, які потім можуть початково завантажуватися паралельно без координації. Це дозволяє використовувати його в багатьох сценаріях розгортання.

Недоліки:

  • Якщо зловмисник зможе вкрасти токен початкового завантаження через якусь уразливість, вони можуть використовувати цей токен (разом з доступом на рівні мережі) для видавання себе за вузол панелі управління для інших вузлів початкового завантаження. Це може бути або не бути відповідним компромісом у вашому середовищі.

Виявлення на основі файлів або HTTPS

Це забезпечує автономний спосіб встановлення кореня довіри між вузлом панелі управління та вузлами початкового завантаження. Розгляньте використання цього режиму, якщо ви створюєте автоматизоване впровадження за допомогою kubeadm. Формат файлу для виявлення — це звичайний файл Kubernetes kubeconfig.

У разі, якщо файл для виявлення не містить облікових даних, буде використовуватися токен TLS.

Приклади команд kubeadm join:

  • kubeadm join --discovery-file path/to/file.conf (локальний файл)

  • kubeadm join --discovery-file https://url/file.conf (віддалений HTTPS URL)

Переваги:

  • Дозволяє вузлам початкового завантаження безпечно виявляти корінь довіри для вузла панелі управління, навіть якщо мережа або інші робочі вузли скомпрометовані.

Недоліки:

  • Вимагає, щоб у вас був спосіб перенести інформацію про виявлення від вузла панелі управління до вузлів початкового завантаження. Якщо файл для виявлення містить облікові дані, ви повинні тримати його в секреті та передавати через безпечний канал. Це може бути можливо з вашим постачальником хмарних послуг або інструментом забезпечення розгортання.

Використання власних облікових даних kubelet з kubeadm join

Щоб дозволити kubeadm join використовувати заздалегідь визначені облікові дані kubelet і пропустити клієнтське початкове завантаження TLS та затвердження CSR для нового вузла:

  1. На робочому вузлі панелі управління в кластері, який має /etc/kubernetes/pki/ca.key, виконайте kubeadm kubeconfig user --org system:nodes --client-name system:node:$NODE > kubelet.conf. $NODE має бути встановлено на імʼя нового вузла.
  2. Відредагуйте отриманий kubelet.conf вручну, щоб налаштувати імʼя кластера та точку доступу сервера, або запустіть kubeadm kubeconfig user --config (приймає InitConfiguration).

Якщо у вашому кластері немає файлу ca.key, вам потрібно підписати вбудовані сертифікати в kubelet.conf зовнішнім чином. Для додаткової інформації дивіться Сертифікати PKI та вимоги та Управління сертифікатами за допомогою kubeadm.

  1. Скопіюйте отриманий kubelet.conf до /etc/kubernetes/kubelet.conf на новому вузлі.
  2. Виконайте kubeadm join з прапорцем --ignore-preflight-errors=FileAvailable--etc-kubernetes-kubelet.conf на новому вузлі.

Ще більший захист вашого встановлення

Типові налаштування kubeadm можуть не підходити для всіх. Цей розділ показує, як посилити захист kubeadm коштом зручності користування.

Вимкнення автоматичного затвердження клієнтських сертифікатів вузла

За замовчуванням увімкнено автоматичне затвердження запитів на клієнтські сертифікати CSR, коли використовується токен Bootstrap під час аутентифікації. Якщо ви не бажаєте, щоб кластер автоматично затверджував клієнтські сертифікати kubelet, ви можете вимкнути цю функцію виконавши наступну команду:

kubectl delete clusterrolebinding kubeadm:node-autoapprove-bootstrap

Після цього команда kubeadm join буде блокуватися до тих пір, поки адміністратор не затвердить CSR вручну:

  1. За допомогою kubectl get csr ви можете переглянути, що оригінальний CSR знаходиться в стані Pending.

    kubectl get csr
    

    Результат буде подібним до такого:

    NAME                                                   AGE       REQUESTOR                 CONDITION
    node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ   18s       system:bootstrap:878f07   Pending
    
  2. kubectl certificate approve дозволяє адміністратору затвердити CSR. Ця дія наказує контролеру підпису сертифікатів видати сертифікат запитувачеві з властивостями, зазначеними у CSR.

    kubectl certificate approve node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ
    

    Результат буде подібний до такого:

    certificatesigningrequest "node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ" approved
    
  3. Це змінить ресурс CSR на стан Active.

    kubectl get csr
    

    Результат буде подібний до такого:

    NAME                                                   AGE       REQUESTOR                 CONDITION
    node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ   1m        system:bootstrap:878f07   Approved,Issued
    

Це змушує процес kubeadm join працювати тільки у випадку, коли була виконана команда kubectl certificate approve.

Вимкнення загального доступу до ConfigMap cluster-info

Для того, щоб досягти потоку приєднання, використовуючи токен як єдину частину інформації про перевірку, необхідно викласти у відкритий доступ ConfigMap з деякими даними, необхідними для перевірки ідентичності вузла панелі управління, стандартно публікується у відкритому доступі. Хоча в цьому ConfigMap немає приватних даних, деякі користувачі можуть бажати вимкнути цю можливість. Це дія призведе до відключення можливості використання прапорця --discovery-token в потоці kubeadm join. Ось кроки для вимкнення цієї функції:

  • Отримайте файл cluster-info з API сервера:

    kubectl -n kube-public get cm cluster-info -o jsonpath='{.data.kubeconfig}' | tee cluster-info.yaml
    

    Вивід буде подібний до такого:

    apiVersion: v1
    kind: Config
    clusters:
    - cluster:
        certificate-authority-data: <ca-cert>
        server: https://<ip>:<port>
      name: ""
    contexts: []
    current-context: ""
    preferences: {}
    users: []
    
  • Використовуйте файл cluster-info.yaml як аргумент для kubeadm join --discovery-file.

  • Вимкніть загальний доступ до ConfigMap cluster-info:

    kubectl -n kube-public delete rolebinding kubeadm:bootstrap-signer-clusterinfo
    

Ці команди слід виконати після kubeadm init, але перед kubeadm join.

Використання kubeadm join з конфігураційним файлом

Можливо сконфігурувати kubeadm join, використовуючи конфігураційний файл замість прапорців командного рядка, і деякі більш розширені функції можуть бути доступні лише як опції конфігураційного файлу. Цей файл передається за допомогою прапорця --config і повинен містити структуру JoinConfiguration. У деяких випадках змішування --config з іншими прапорцями може бути недозволеним.

Стандартна конфігурація може бути виведена за допомогою команди kubeadm config print.

Якщо ваша конфігурація не використовує останню версію, рекомендується перейти на неї за допомогою команди kubeadm config migrate.

Для отримання додаткової інформації щодо полів та використання конфігурації ви можете перейти до нашого довідника API.

Що далі

  • kubeadm init для ініціалізації вузла панелі управління Kubernetes.
  • kubeadm token для управління токенами для kubeadm join.
  • kubeadm reset для скасування будь-яких змін, внесених до цього хосту за допомогою kubeadm init або kubeadm join.

6.10.1.4 - kubeadm upgrade

kubeadm upgrade — це зручна команда, яка обгортає складну логіку оновлення однією командою, з підтримкою як планування оновлення, так і його фактичного виконання.

Інструкція kubeadm upgrade

Кроки для виконання оновлення за допомогою kubeadm викладені в цьому документі. Для старіших версій kubeadm, будь ласка, зверніться до старих наборів документації на сайті Kubernetes.

Ви можете використовувати kubeadm upgrade diff для перегляду змін, які будуть застосовані до маніфестів статичних Pod.

У Kubernetes версії v1.15.0 і пізніше, kubeadm upgrade apply та kubeadm upgrade node також автоматично оновлять сертифікати, керовані kubeadm на цьому вузлі, включаючи ті, що зберігаються у файлах kubeconfig. Щоб відмовитися від цього, можна передати прапорець --certificate-renewal=false. Для отримання додаткової інформації про оновлення сертифікатів дивіться документацію з управління сертифікатами.

kubeadm upgrade plan

Перевіряє, до яких версій можна оновитися, і перевіряє, чи можна оновити ваш поточний кластер.

Опис

Перевіряє, до яких версій можна оновитися, і перевіряє, чи можна оновити ваш поточний кластер. Ця команда може бути виконана лише на вузлах панелі управління, де існує файл kubeconfig "admin.conf". Щоб пропустити перевірку Інтернету, вкажіть необовʼязковий параметр [version].

kubeadm upgrade plan [version] [flags]

Параметри

--allow-experimental-upgrades

Показати нестабільні версії Kubernetes як альтернативу для оновлення і дозволити оновлення до альфа/бета/кандидатів на випуск версій Kubernetes.

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли поле або ключ map відсутній у шаблоні. Застосовується лише до форматів виведення golang та jsonpath.

--allow-release-candidate-upgrades

Показати версії кандидатів на випуск Kubernetes як альтернативу для оновлення і дозволити оновлення до версій кандидатів на випуск Kubernetes.

--config string

Шлях до файлу конфігурації kubeadm.

-h, --help

довідка plan

--ignore-preflight-errors strings

Список перевірок, помилки яких будуть показані як попередження. Приклад: 'IsPrivilegedUser,Swap'. Значення 'all' ігнорує помилки з усіх перевірок.

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який буде використовуватися при зверненні до кластера. Якщо прапорець не заданий, буде проведено пошук файлу kubeconfig в стандартнх місцях.

-o, --output string     Типово: "text"

Формат виводу. Один із: text|json|yaml|go-template|go-template-file|template|templatefile|jsonpath|jsonpath-as-json|jsonpath-file.

--print-config

Вказує, чи потрібно надрукувати файл конфігурації, який буде використаний під час оновлення.

--show-managed-fields

Якщо true, зберігати managedFields під час виводу обʼєктів у форматі JSON або YAML.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm upgrade apply

Оновлює кластер Kubernetes до вказаної версії.

Опис

Оновлює кластер Kubernetes до вказаної версії.

kubeadm upgrade apply [version]

Параметри

--allow-experimental-upgrades

Показує нестабільні версії Kubernetes як альтернативу для оновлення і дозволяє оновлювати до альфа/бета/версій кандидатів Kubernetes.

--allow-release-candidate-upgrades

Показує версії кандидатів на випуск Kubernetes як альтернативу для оновлення і дозволяє оновлювати до версій кандидатів на випуск Kubernetes.

--certificate-renewal     Типово: true

Виконує оновлення сертифікатів, які використовуються компонентами під час оновлення.

--config string

Шлях до файлу конфігурації kubeadm.

--dry-run

Не змінює жодного стану, просто показує дії, які будуть виконані.

--etcd-upgrade     Типово: true

Виконує оновлення etcd.

-f, --force

Примусове оновлення, навіть якщо деякі вимоги можуть бути не виконані. Це також передбачає неітерактивний режим.

-h, --help

довідка apply

--ignore-preflight-errors strings

Список перевірок, помилки яких будуть показані як попередження. Приклад: 'IsPrivilegedUser,Swap'. Значення 'all' ігнорує помилки з усіх перевірок.

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який буде використовуватися при зверненні до кластера. Якщо прапорець не заданий, буде проведено пошук файлу kubeconfig в стандартних місцях.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним із "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним із "strategic", "merge" або "json", і вони відповідають форматам патчів, які підтримуються kubectl. За замовчуванням "patchtype" - "strategic". "extension" повинен бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який може використовуватися для визначення порядку застосування патчів за алфавітом.

--print-config

Вказує, чи потрібно надрукувати файл конфігурації, який буде використаний під час оновлення.

-y, --yes

Виконати оновлення і не запитувати підтвердження (режим без взаємодії).

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm upgrade diff

Показує які відмінності можуть бути застосовані до наявних маніфестів статичних Pod. Дивіться також: kubeadm upgrade apply --dry-run

Опис

Показує які відмінності можуть бути застосовані до наявних маніфестів статичних Pod. Дивіться також: kubeadm upgrade apply --dry-run

kubeadm upgrade diff [version] [flags]

Параметри

--config string

Шлях до файлу конфігурації kubeadm.

-c, --context-lines int     Типово: 3

Скільки рядків контексту в виведенні diff.

-h, --help

довідка diff

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який буде використовуватися при зверненні до кластера. Якщо прапорець не заданий, буде проведено пошук файлу kubeconfig в стандартних місцях.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm upgrade node

Команда upgrade для вузлів в кластері

Опис

Команда upgrade для вузлів в кластері.

Команда "node" виконує наступні фази:

preflight       Виконання попереднії перевірок оновлення вузла
control-plane   Оновлення екземпляру панелі управління, розгорнутий на цьому вузлі, якщо такий є
kubelet-config  Оновлення конфігурацію kubelet для цього вузла
kubeadm upgrade node [flags]

Параметри

--certificate-renewal     Типово: true

Виконати оновлення сертифікатів, використовуваних компонентами, які змінюються під час оновлення.

--config string

Шлях до файлу конфігурації kubeadm.

--dry-run

Не змінює жодного стану, просто показує дії, які будуть виконані.

--etcd-upgrade     Типово: true

Виконати оновлення etcd.

-h, --help

довідка node

--ignore-preflight-errors strings

Список перевірок, помилки в яких будуть відображені як попередження. Приклад: 'IsPrivilegedUser,Swap'. Значення 'all' ігнорує помилки з усіх перевірок.

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який буде використовуватися при зверненні до кластера. Якщо прапорець не заданий, буде проведено пошук файлу kubeconfig в стандартних місцях.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним із "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним із "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" - "strategic". "extension" повинен бути або "json", або "yaml". "suffix" - це необовʼязковий рядок, який може використовуватися для визначення порядку застосування патчів за алфавітном.

--skip-phases strings

Список фаз, які слід пропустити.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Що далі

  • kubeadm config якщо ви ініціалізували свій кластер за допомогою kubeadm версії 1.7.x або нижче, щоб налаштувати ваш кластер для оновлення за допомогою kubeadm upgrade.

6.10.1.5 - kubeadm config

Під час виконання kubeadm init, kubeadm надсилає обʼєкт ClusterConfiguration у ваш кластер у ConfigMap з назвою kubeadm-config у просторі імен kube-system. Ця конфігурація зчитується під час виконання kubeadm join, kubeadm reset та kubeadm upgrade.

Ви можете використовувати kubeadm config print для виведення стандартної статичної конфігурації, яку використовує kubeadm для kubeadm init і kubeadm join.

Для отримання додаткової інформації про init та join перейдіть до Використання kubeadm init з конфігураційним файлом або Використання kubeadm join з конфігураційним файлом.

Для отримання додаткової інформації про використання API конфігурації kubeadm перейдіть до Налаштування компонентів за допомогою API kubeadm.

Ви можете використовувати kubeadm config migrate для перетворення старих конфігураційних файлів, що містять застарілу версію API, на новішу підтримувану версію API.

kubeadm config validate можна використовувати для перевірки конфігураційного файлу.

kubeadm config images list та kubeadm config images pull можна використовувати для виведення списку та завантаження зображень, необхідних kubeadm.

kubeadm config print

Вивід конфігурації

Опис

Ця команда виводить конфігурацію вказаних субкоманд. Докладніше: https://pkg.go.dev/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm#section-directories

kubeadm config print [flags]

Параметри

-h, --help

довідка print

Параметри успадковані від батьківських команд

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig для використання при спілкуванні з кластером. Якщо прапорець не встановлено, набір стандартних розташувань може бути перевірений на наявність поточного файлу kubeconfig.

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm config print init-defaults

Вивід стандартної конфігурації ініціалізації, яка може використовуватись у kubeadm init.

Опис

Ця команда виводить обʼєкти, такі як стандартну конфігурацію ініціалізації, які можуть бути використані у kubeadm init.

Зверніть увагу, що конфіденційні значення, такі як поля Bootstrap Token, замінюються значеннями-заповнювачами, такими як abcdef.0123456789abcdef", щоб пройти перевірку, але не виконувати реальні дії для створення токена.

kubeadm config print init-defaults [flags]

Параметри

--component-configs strings

Список обʼєктів API конфігурації компонентів через кому для виводу типових значень. Доступні значення: [KubeProxyConfiguration KubeletConfiguration]. Якщо цей прапорець не встановлено, конфігурації компонентів не буде надруковано.

-h, --help

довідка init-defaults

Параметри успадковані від батьківських команд

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig для використання при спілкуванні з кластером. Якщо прапорець не встановлено, набір стандартних розташувань може бути перевірений на наявність поточного файлу kubeconfig.

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm config print join-defaults

Вивід стандартної конфігурації для команди kubeadm join.

Опис

Ця команда виводить обʼєкти, такі як стандартна конфігурація команди join, яка використовується для 'kubeadm join'.

Зверніть увагу, що конфіденційні значення, такі як поля Bootstrap Token, замінюються значеннями-заповнювачами, такими як abcdef.0123456789abcdef", щоб пройти перевірку, але не виконувати реальні дії для створення токена.

kubeadm config print join-defaults [flags]

Параметри

-h, --help

довідка join-defaults

Параметри успадковані від батьківських команд

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig для використання при спілкуванні з кластером. Якщо прапорець не встановлено, набір стандартних розташувань може бути перевірений на наявність поточного файлу kubeconfig.

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm config migrate

Зчитує стару версію типів конфігураційного API kubeadm з файлу і виводе аналогічний обʼєкт конфігурації для нової версії

Опис

Ця команда дозволяє конвертувати обʼєкти конфігурації старих версій у найновішу підтримувану версію, локально у CLI інструменті, без жодних змін у кластері. У цій версії kubeadm підтримуються наступні версії API:

  • kubeadm.k8s.io/v1beta4

Крім того, kubeadm може записувати конфігурацію лише версії "kubeadm.k8s.io/v1beta4", але читати обидві версії. Отже, незалежно від того, яку версію ви передаєте параметру --old-config, API обʼєкт буде прочитано, десеріалізовано, встановлено стандартні значення, конвертовано, валідовано та повторно серіалізовано під час запису у stdout або --new-config, якщо вказано.

Іншими словами, вихід цієї команди є тим, що kubeadm фактично читав би внутрішньо, якщо ви надіслали б цей файл команді "kubeadm init".

kubeadm config migrate [flags]

Параметри

--allow-experimental-api

Дозволити міграцію на експериментальні, невипущені API

-h, --help

довідка migrate

--new-config string

Шлях до отриманого еквівалентного конфігураційного файлу kubeadm з використанням нової версії API. Необовʼязково, якщо не вказано, вивід буде надіслано у STDOUT.

--old-config string

Шлях до конфігураційного файлу kubeadm, який використовує стару версію API і який має бути конвертований. Цей прапорець є обовʼязковим.

Параметри успадковані від батьківських команд

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig для використання при спілкуванні з кластером. Якщо прапорець не встановлено, набір стандартних розташувань може бути перевірений на наявність поточного файлу kubeconfig.

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm config validate

Зчитує файл, що містить конфігураційний API kubeadm, і повідомляє про будь-які проблеми під час валідації

Опис

Ця команда дозволяє перевірити файл конфігурації API kubeadm та повідомити про будь-які попередження та помилки. Якщо помилок немає, статус виводу буде нульовим, в іншому випадку він буде ненульовим. Будь-які проблеми з розбором, такі як невідомі поля API, спричинять помилки. Невідомі версії API та поля з недійсними значеннями також спричинять помилки. Будь-які інші помилки або попередження можуть бути повідомлені залежно від вмісту вхідного файлу.

У цій версії kubeadm підтримуються наступні версії API:

  • kubeadm.k8s.io/v1beta4
kubeadm config validate [flags]

Параметри

--allow-experimental-api

Дозволяє валідацію експериментальних, невипущених API.

--config string

Шлях до файлу конфігурації kubeadm.

-h, --help

довідка validate

Параметри успадковані від батьківських команд

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig для використання при спілкуванні з кластером. Якщо прапорець не встановлено, набір стандартних розташувань може бути перевірений на наявність поточного файлу kubeconfig.

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm config images list

Виводить список образів, які буде використовувати kubeadm. Файл конфігурації використовується у випадку налаштування будь-яких образів або сховищ образів

Опис

Виводить список образів, які буде використовувати kubeadm. Файл конфігурації використовується у випадку налаштування будь-яких образів або сховищ образів.

kubeadm config images list [flags]

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли у шаблоні відсутнє поле або ключ мапи. Застосовується тільки до форматів виводу golang і jsonpath.

--config string

Шлях до файлу конфігурації kubeadm.

--feature-gates string

Набір пар ключ=значення, що описують функціональні можливості для різних функцій. Варіанти:
ControlPlaneKubeletLocalMode=true|false (ALPHA — default=false)
EtcdLearnerMode=true|false (BETA — default=true)
PublicKeysECDSA=true|false (DEPRECATED — default=false)
RootlessControlPlane=true|false (ALPHA — default=false)
WaitForAllControlPlaneComponents=true|false (ALPHA — default=false)

-h, --help

довідка list

--image-repository string     Типово: "registry.k8s.io"

Вибрати реєстр контейнерів для завантаження образів панелі управління

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

-o, --output string     Типово: "text"

Формат виводу. Один з: text|json|yaml|go-template|go-template-file|template|templatefile|jsonpath|jsonpath-as-json|jsonpath-file.

--show-managed-fields

Якщо true, зберігати managedFields при виведенні обʼєктів у форматі JSON або YAML.

Параметри успадковані від батьківських команд

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig для використання при спілкуванні з кластером. Якщо прапорець не встановлено, набір стандартних розташувань може бути перевірений на наявність поточного файлу kubeconfig.

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm config images pull

Витягує образи які використовує kubeadm з реєстру

Опис

Витягує образи які використовує kubeadm з реєстру

kubeadm config images pull [flags]

Параметри

--config string

Шлях до файлу конфігурації kubeadm.

--cri-socket string

Шлях до CRI сокету для підключення. Якщо порожньо, kubeadm спробує автоматично визначити це значення; використовуйте цей параметр лише якщо у вас встановлено більше одного CRI або якщо у вас нестандартний CRI сокет.

--feature-gates string

Набір пар ключ=значення, що описують ворота функцій для різних можливостей. Варіанти:
ControlPlaneKubeletLocalMode=true|false (ALPHA — default=false)
EtcdLearnerMode=true|false (BETA — default=true)
PublicKeysECDSA=true|false (DEPRECATED — default=false)
RootlessControlPlane=true|false (ALPHA — default=false)
WaitForAllControlPlaneComponents=true|false (ALPHA — default=false)

-h, --help

довідка pull

--image-repository string     Типово: "registry.k8s.io"

Вибрати реєстр контейнерів для завантаження образів панелі управління

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig для використання при спілкуванні з кластером. Якщо прапорець не встановлено, набір стандартних розташувань може бути перевірений на наявність поточного файлу kubeconfig.

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Що далі

  • kubeadm upgrade для оновлення кластера Kubernetes до новішої версії

6.10.1.6 - kubeadm reset

Виконує максимально можливий відкат змін, зроблених командами kubeadm init або kubeadm join.

Виконує максимально можливий відкат змін для хоста, зроблених командами kubeadm init або kubeadm join.

Опис

Виконує максимально можливий відкат змін для хоста, зроблених командами kubeadm init або kubeadm join.

Команда "reset" виконує наступні фази:

preflight           Запуск попередніх перевірок
remove-etcd-member  Вилучення локального учасника etcd.
cleanup-node        Запуск очищення вузла.
kubeadm reset [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях до теки, де зберігаються сертифікати. Якщо вказано, очистити цю теку.

--cleanup-tmp-dir

Очистити теку "/etc/kubernetes/tmp"

--config string

Шлях до файлу конфігурації kubeadm.

--cri-socket string

Шлях до CRI сокету для підключення. Якщо порожньо, kubeadm спробує автоматично визначити це значення; використовуйте цей параметр лише якщо у вас встановлено більше одного CRI або якщо у вас нестандартний CRI сокет.

--dry-run

Не вносити жодних змін; лише вивести, що буде зроблено.

-f, --force

Виконати reset вузла без запиту на підтвердження.

-h, --help

довідка reset

--ignore-preflight-errors strings

Список перевірок, помилки яких будуть показані як попередження. Приклад: 'IsPrivilegedUser,Swap'. Значення 'all' ігнорує помилки від усіх перевірок.

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig для використання при спілкуванні з кластером. Якщо прапорець не встановлено, можна шукати наявний файл kubeconfig у наборі стандартних місць.

--skip-phases strings

Список фаз, які слід пропустити

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Робочий процес

kubeadm reset відповідає за очищення файлової системи вузла від файлів, створених за допомогою команд kubeadm init або kubeadm join. Для вузлів панелі управління reset також видаляє локального учасника стека etcd цього вузла з кластера etcd.

kubeadm reset phase можна використовувати для виконання окремих фаз наведеного вище робочого процесу. Щоб пропустити список фаз, ви можете використовувати прапорець --skip-phases, який працює аналогічно до роботи з фазами kubeadm join та kubeadm init.

Очищення зовнішнього etcd

kubeadm reset не видалить жодних даних etcd, якщо використовується зовнішній etcd. Це означає, що якщо ви знову виконаєте kubeadm init з використанням тих самих точок доступу etcd, ви побачите стан від попередніх кластерів.

Щоб видалити дані etcd, рекомендується використовувати клієнт, такий як etcdctl, наприклад:

etcdctl del "" --prefix

Дивіться документацію etcd для отримання додаткової інформації.

Відповідне завершення роботи kube-apiserver

Якщо ваш kube-apiserver налаштований з прапорцем --shutdown-delay-duration, ви можете виконати наступні команди, щоб спробувати завершити роботу відповідним чином для запущеного Pod API сервера, перед тим як виконати kubeadm reset:

yq eval -i '.spec.containers[0].command = []' /etc/kubernetes/manifests/kube-apiserver.yaml
timeout 60 sh -c 'while pgrep kube-apiserver >/dev/null; do sleep 1; done' || true

Що далі

  • kubeadm init для створення вузла панелі управління Kubernetes
  • kubeadm join для приєднання робочого вузла Kubernetes до кластера

6.10.1.7 - kubeadm token

Токени запуску (Bootstrap token) використовуються для встановлення двосторонньої довіри між вузлом, який приєднується до кластера, та вузлом панелі управління, як описано в розділі автентифікація за допомогою токенів запуску.

kubeadm init створює початковий токен з часом життя 24 години. Наступні команди дозволяють вам керувати таким токеном, а також створювати та керувати новими.

kubeadm token create

Створює токени запуску на сервері.

Опис

Ця команда створює токен запуску для вас. Ви можете вказати способи використання цього токену, "час життя" і необовʼязковий опис, зрозумілий людині.

[token] — це власне токен, який потрібно записати. Це має бути безпечно згенерований випадковий токен виду "[a-z0-9]{6}.[a-z0-9]{16}". Якщо [token] не вказано, kubeadm згенерує випадковий токен замість нього.

kubeadm token create [token]

Параметри

--certificate-key string

Якщо використовується разом із '--print-join-command', виводить повний прапорець 'kubeadm join', необхідний для приєднання до кластера як панелі управління. Щоб створити новий ключ сертифіката, потрібно використовувати 'kubeadm init phase upload-certs --upload-certs'.

--config string

Шлях до файлу конфігурації kubeadm.

--description string

Опис, зрозумілий для людини, як використовується цей токен.

--groups strings     Типово: "system:bootstrappers:kubeadm:default-node-token"

Додаткові групи, які будуть автентифікуватися за допомогою цього токена при використанні для автентифікації. Повинно відповідати "\Asystem:bootstrappers:[a-z0-9:-]{0,255}[a-z0-9]\z"

-h, --help

довідка create

--print-join-command

Замість того, щоб виводити тільки токен, вивести повний прапорець 'kubeadm join', необхідний для приєднання до кластера за допомогою токена.

--ttl duration     Типово: 24h0m0s

Тривалість перед автоматичним видаленням токена (наприклад, 1s, 2m, 3h). Якщо встановлено '0', токен ніколи не закінчиться.

--usages strings     Типово: "signing,authentication"

Описує способи, в яких цей токен може використовуватися. Ви можете передавати --usages кілька разів або надати список параметрів через кому. Дійсні параметри: [signing,authentication]

Параметри успадковані від батьківських команд

--dry-run

Чи ввімкнути режим dry-run чи ні

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig для використання при спілкуванні з кластером. Якщо прапорець не встановлено, можна шукати наявний файл kubeconfig у наборі стандартних місць.

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm token delete

Видаляє токени запуску на сервері.

Опис

Ця команда видаляє токени запуску для вас.

Значення [token-value] — це повний токен у вигляді "[a-z0-9]{6}.[a-z0-9]{16}" або Token ID виду "[a-z0-9]{6}", який потрібно видалити.

kubeadm token delete [token-value] ...

Параметри

-h, --help

довідка delete

Параметри успадковані від батьківських команд

--dry-run

Чи ввімкнути режим dry-run чи ні

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig для використання при спілкуванні з кластером. Якщо прапорець не встановлено, можна шукати наявний файл kubeconfig у наборі стандартних місць.

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm token generate

Генерує та виводить токен запуску, але не створює його на сервері

Опис

Ця команда виведе випадково згенерований токен запуску, який можна використовувати з командами "init" та "join".

Ви не зобовʼязані використовувати цю команду для створення токена. Ви можете зробити це самостійно, якщо він має формат "[a-z0-9]{6}.[a-z0-9]{16}". Ця команда надається для зручності створення токенів у зазначеному форматі.

Ви також можете використовувати "kubeadm init" без вказання токена, і він буде згенерований та виведений для вас.

kubeadm token generate [flags]

Параметри

-h, --help

довідка generate

Параметри успадковані від батьківських команд

--dry-run

Чи ввімкнути режим dry-run чи ні

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig для використання при спілкуванні з кластером. Якщо прапорець не встановлено, можна шукати наявний файл kubeconfig у наборі стандартних місць.

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm token list

Виводить перелік токенів запуску на сервері

Опис

Ця команда виведе перелік всіх токенів запуску на сервері.

kubeadm token list [flags]

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігноруйте будь-які помилки в шаблонах, коли поле або ключ map відсутні в шаблоні. Застосовується лише до форматів виводу golang і jsonpath.

-h, --help

довідка list

-o, --output string     Типово: "text"

Формат виводу. Один із: text|json|yaml|go-template|go-template-file|template|templatefile|jsonpath|jsonpath-as-json|jsonpath-file.

--show-managed-fields

Якщо true, залиште managedFields під час вводу обʼєктів у форматі JSON або YAML.

Параметри успадковані від батьківських команд

--dry-run

Чи ввімкнути режим dry-run чи ні

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig для використання при спілкуванні з кластером. Якщо прапорець не встановлено, можна шукати наявний файл kubeconfig у наборі стандартних місць.

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Що далі

  • kubeadm join — для початкового запуску робочого вузла Kubernetes nf приєднання його до кластера

6.10.1.8 - kubeadm version

Виводіть версію kubeadm

Опис

Ця команда виводить версію kubeadm.

kubeadm version [flags]

Параметри

-h, --help

довідка version

-o, --output string

Формат виводу; доступні варіанти: 'yaml', 'json' та 'short'

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.9 - kubeadm alpha

Наразі в kubeadm alpha немає експериментальних команд.

Що далі

  • kubeadm init для створення вузла панелі управління Kubernetes
  • kubeadm join для підключення вузла до кластера
  • kubeadm reset для скасування будь-яких змін, внесених на хості за допомогою kubeadm init або kubeadm join

6.10.1.10 - kubeadm certs

kubeadm certs надає утиліти для керування сертифікатами. Для отримання детальної інформації про використання цих команд, дивіться Керування сертифікатами за допомогою kubeadm.

kubeadm certs

Збірка операцій для роботи з сертифікатами Kubernetes.

Команди, повʼязані з обробкою сертифікатів kubernetes

Опис

Команди, повʼязані з обробкою сертифікатів kubernetes

kubeadm certs [command]

Параметри

-h, --help

довідка certs

Параметри успадковані від батьківських команд

--rootfs string

[EXPERIMENTAL] Шлях до реальної кореневої файлової системи хоста.

kubeadm certs renew

Ви можете поновити всі сертифікати Kubernetes, використовуючи підкоманду all, або поновити їх вибірково. Для отримання детальної інформації дивіться Ручне поновлення сертифікатів.

Поновлення сертифікатів для кластера Kubernetes

Опис

Ця команда не призначена для самостійного запуску. Дивіться список доступних підкоманд.

kubeadm certs renew [flags]

Параметри

-h, --help

довідка renew

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Поновлення всіх доступних сертифікатів

Опис

Поновлення усі відомих сертифікатів, необхідних для запуску панелі управління. Поновлення виконується безумовно, незалежно від дати закінчення терміну дії. Поновлення також можна виконувати окремо для більшого контролю.

kubeadm certs renew all [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка all

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Поновлює сертифікат, вбудований у файл kubeconfig для використання адміністратором і для самого kubeadm

Опис

Поновлює сертифікат, вбудований у файл kubeconfig для використання адміністратором і для самого kubeadm.

Поновлення виконується безумовно, незалежно від дати закінчення терміну дії сертифіката; додаткові атрибути, такі як SAN, будуть базуватися на поточних файлах/сертифікатах, нема потреби їх поновлювати.

Типово поновлення намагається використовувати центр сертифікації в локальному PKI, керованому kubeadm; як альтернативу можна використовувати API сертифікатів K8s для поновлення сертифікатів, або, як останній варіант, згенерувати CSR-запит.

Після оновлення, щоб зміни набули чинності, необхідно перезапустити компоненти панелі управління та, зрештою, повторно розповсюдити оновлений сертифікат у випадку, якщо файл використовується деінде.

kubeadm certs renew admin.conf [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка admin.conf

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Поновлює сертифікат, який apiserver використовує для доступу до etcd

Опис

Поновлює сертифікат, який apiserver використовує для доступу до etcd.

Поновлення виконується безумовно, незалежно від дати закінчення терміну дії сертифіката; додаткові атрибути, такі як SAN, будуть базуватися на наявних файлах/сертифікатах, нема потреби їх поновлювати.

Типово поновлення намагається використовувати центр сертифікації в локальному PKI, керованому kubeadm; як альтернативу можна використовувати API сертифікатів K8s для поновлення сертифікатів, або, як останній варіант, згенерувати CSR запит.

Після оновлення, щоб зміни набули чинності, необхідно перезапустити компоненти панелі управління та, зрештою, повторно розповсюдити оновлений сертифікат у випадку, якщо файл використовується деінде.

kubeadm certs renew apiserver-etcd-client [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка apiserver-etcd-client

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Поновлює сертифікат для сервера API для підключення до kubelet

Опис

Поновлює сертифікат для сервера API для підключення до kubelet.

Поновлення виконується безумовно, незалежно від дати закінчення терміну дії сертифіката; додаткові атрибути, такі як SAN, будуть базуватися на наявних файлах/сертифікатах, нема потреби їх перезавантажувати.

Типово поновлення намагається використовувати центр сертифікації в локальному PKI, керованому kubeadm; як альтернативу можна використовувати API сертифікатів K8s для поновлення сертифікатів, або, як останній варіант, згенерувати CSR-запит.

Після оновлення, щоб зміни набули чинності, необхідно перезапустити компоненти панелі управління та, зрештою, повторно розповсюдити оновлений сертифікат у випадку, якщо файл використовується деінде.

kubeadm certs renew apiserver-kubelet-client [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка apiserver-kubelet-client

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Поновлює сертифікат для обслуговування API Kubernetes

Синопсис

Поновлює сертифікат для обслуговування API Kubernetes.

Поновлення виконується безумовно, незалежно від дати закінчення терміну дії сертифіката; додаткові атрибути, такі як SAN, будуть базуватися на наявних файлах/сертифікатах, нема потреби їх перезавантажувати.

Типово поновлення намагається використовувати центр сертифікації в локальному PKI, керованому kubeadm; як альтернативу можна використовувати API сертифікатів K8s для поновлення сертифікатів, або, як останній варіант, згенерувати CSR-запит.

Після оновлення, щоб зміни набули чинності, необхідно перезапустити компоненти панелі управління та, зрештою, повторно розповсюдити оновлений сертифікат у випадку, якщо файл використовується деінде.

kubeadm certs renew apiserver [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка apiserver

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Поновлює сертифікат, вбудований у файл kubeconfig для використання менеджером контролера

Опис

Поновлює сертифікат, вбудований у файл kubeconfig для використання менеджером контролера.

Поновлення виконується безумовно, незалежно від дати закінчення терміну дії сертифіката; додаткові атрибути, такі як SAN, будуть базуватися на наявних файлах/сертифікатах, нема потреби їх перезавантажувати.

Типово поновлення намагається використовувати центр сертифікації в локальному PKI, керованому kubeadm; як альтернативу можна використовувати API сертифікатів K8s для поновлення сертифікатів, або, як останній варіант, згенерувати CSR-запит.

Після оновлення, щоб зміни набули чинності, необхідно перезапустити компоненти панелі управління та, зрештою, повторно розповсюдити оновлений сертифікат у випадку, якщо файл використовується деінде.

kubeadm certs renew controller-manager.conf [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка controller-manager.conf

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Поновлює сертифікат для проб життєздатності для перевірки стану справності etcd

Опис

Поновлює сертифікат для проб життєздатності для перевірки стану справності etcd.

Поновлення виконується безумовно, незалежно від дати закінчення терміну дії сертифіката; додаткові атрибути, такі як SAN, будуть базуватися на наявних файлах/сертифікатах, нема потреби їх перезавантажувати.

Типово поновлення намагається використовувати центр сертифікації в локальному PKI, керованому kubeadm; як альтернативу можна використовувати API сертифікатів K8s для поновлення сертифікатів, або, як останній варіант, згенерувати CSR-запит.

Після оновлення, щоб зміни набули чинності, необхідно перезапустити компоненти панелі управління та, зрештою, повторно розповсюдити оновлений сертифікат у випадку, якщо файл використовується деінде.

kubeadm certs renew etcd-healthcheck-client [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка etcd-healthcheck-client

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Поновлює сертифікат для вузлів etcd, щоб вони могли взаємодіяти один з одним

Опис

Поновлює сертифікат для вузлів etcd, щоб вони могли взаємодіяти один з одним.

Поновлення виконується безумовно, незалежно від дати закінчення терміну дії сертифіката; додаткові атрибути, такі як SAN, будуть базуватися на наявних файлах/сертифікатах, нема потреби їх перезавантажувати.

Типово поновлення намагається використовувати центр сертифікації в локальному PKI, керованому kubeadm; як альтернативу можна використовувати API сертифікатів K8s для поновлення сертифікатів, або, як останній варіант, згенерувати CSR-запит.

Після оновлення, щоб зміни набули чинності, необхідно перезапустити компоненти панелі управління та, зрештою, повторно розповсюдити оновлений сертифікат у випадку, якщо файл використовується деінде.

kubeadm certs renew etcd-peer [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка etcd-peer

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Поновлює сертифікат для обслуговування etcd

Опис

Поновлює сертифікат для обслуговування etcd.

Поновлення виконується безумовно, незалежно від дати закінчення терміну дії сертифіката; додаткові атрибути, такі як SAN, будуть базуватися на наявних файлах/сертифікатах, нема потреби їх перезавантажувати.

Типово поновлення намагається використовувати центр сертифікації в локальному PKI, керованому kubeadm; як альтернативу можна використовувати API сертифікатів K8s для поновлення сертифікатів, або, як останній варіант, згенерувати CSR-запит.

Після оновлення, щоб зміни набули чинності, необхідно перезапустити компоненти панелі управління та, зрештою, повторно розповсюдити оновлений сертифікат у випадку, якщо файл використовується деінде.

kubeadm certs renew etcd-server [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка etcd-server

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Поновлення сертифіката клієнта front proxy

Опис

Поновлення сертифіката клієнта front proxy.

Поновлення виконується безумовно, незалежно від дати закінчення терміну дії сертифіката; додаткові атрибути, такі як SAN, будуть базуватися на наявних файлах/сертифікатах, нема потреби їх перезавантажувати.

Типово поновлення намагається використовувати центр сертифікації в локальному PKI, керованому kubeadm; як альтернативу можна використовувати API сертифікатів K8s для поновлення сертифікатів, або, як останній варіант, згенерувати CSR-запит.

Після оновлення, щоб зміни набули чинності, необхідно перезапустити компоненти панелі управління та, зрештою, повторно розповсюдити оновлений сертифікат у випадку, якщо файл використовується деінде.

kubeadm certs renew front-proxy-client [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка front-proxy-client

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Поновлює сертифікат, вбудований у файл kubeconfig для використання менеджером планувальника

Опис

Поновлює сертифікат, вбудований у файл kubeconfig для використання менеджером планувальника.

Поновлення виконується безумовно, незалежно від дати закінчення терміну дії сертифіката; додаткові атрибути, такі як SAN, будуть базуватися на наявних файлах/сертифікатах, нема потреби їх перезавантажувати.

Типово поновлення намагається використовувати центр сертифікації в локальному PKI, керованому kubeadm; як альтернативу можна використовувати API сертифікатів K8s для поновлення сертифікатів, або, як останній варіант, згенерувати CSR-запит.

Після оновлення, щоб зміни набули чинності, необхідно перезапустити компоненти панелі управління та, зрештою, повторно розповсюдити оновлений сертифікат у випадку, якщо файл використовується деінде.

kubeadm certs renew scheduler.conf [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка scheduler.conf

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Поновлює сертифікат, вбудований у файл kubeconfig для суперкористувача

Опис

Поновлює сертифікат, вбудований у файл kubeconfig для суперкористувача.

Поновлення виконується безумовно, незалежно від дати закінчення терміну дії сертифіката; додаткові атрибути, такі як SAN, будуть базуватися на наявних файлах/сертифікатах, нема потреби їх перезавантажувати.

Типово поновлення намагається використовувати центр сертифікації в локальному PKI, керованому kubeadm; як альтернативу можна використовувати API сертифікатів K8s для поновлення сертифікатів, або, як останній варіант, згенерувати CSR-запит.

Після оновлення, щоб зміни набули чинності, необхідно перезапустити компоненти панелі управління та, зрештою, повторно розповсюдити оновлений сертифікат у випадку, якщо файл використовується деінде.

kubeadm certs renew super-admin.conf [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка super-admin.conf

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm certs certificate-key

Ця команда може бути використана для створення нового ключа сертифіката для панелі управління. Ключ може бути переданий як --certificate-key до kubeadm init та kubeadm join для забезпечення автоматичного копіювання сертифікатів при підключенні додаткових вузлів панелі управління.

Генерує ключів сертифікатів

Опис

Ця команда виведе захищений випадково згенерований ключ сертифіката, який можна використовувати з командою "init".

Ви також можете скористатися командою "kubeadm init --upload-certs" без зазначення ключа сертифіката, і вона згенерує і виведе його для вас.

kubeadm certs certificate-key [flags]

Параметри

-h, --help

Довідка certificate-key

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm certs check-expiration

Ця команда перевіряє термін дії сертифікатів у локальному PKI, керованому kubeadm. Для отримання детальної інформації дивіться Перевірка терміну дії сертифікатів.

Перевіряє термін дії сертифікатів для кластера Kubernetes

Опис

Перевіряє термін дії сертифікатів у локальному PKI, яким керує kubeadm.

kubeadm certs check-expiration [flags]

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли поле або ключ map відсутні в шаблоні. Застосовується тільки до форматів виведення golang і jsonpath.

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка check-expiration

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

-o, --output string     Типово: "text"

Формат виводу. Один з: text|json|yaml|go-template|go-template-file|template|templatefile|jsonpath|jsonpath-as-json|jsonpath-file.

--show-managed-fields

Якщо true, залишати managedFields при виведенні обʼєктів у форматі JSON або YAML.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm certs generate-csr

Ця команда може бути використана для створення ключів і CSRs для всіх сертифікатів панелі управління та файлів kubeconfig. Користувач може потім підписати CSRs з CA на свій вибір. Для отримання додаткової інформації про використання команди дивіться Підписання запитів на підписання сертифікатів (CSR), створених за допомогою kubeadm.

Генерує ключі та запити на підписання сертифікатів

Опис

Генерує ключі та запити на підписування сертифікатів (CSRs) для всіх сертифікатів, необхідних для роботи панелі управління. Ця команда також генерує часткові файли kubeconfig з даними приватного ключа в полі "users > user > client-key-data", і для кожного файлу kubeconfig створюється супутній файл ".csr".

Ця команда призначена для використання в Режимі Kubeadm з зовнішнім CA Kubeadm. Вона генерує CSRs, які ви можете подати на підписання до вашого зовнішнього центру сертифікації.

Закодовані в PEM підписані сертифікати повинні бути збережені поруч з файлами ключів, використовуючи ".crt" як розширення файлу, або, у випадку з файлами kubeconfig, закодований в PEM підписаний сертифікат повинен бути закодований у base64 і доданий до файлу kubeconfig в полі "users > user > client-certificate-data".

kubeadm certs generate-csr [flags]

Приклади

# Наступна команда згенерує ключі та CSRs для всіх сертифікатів панелі управління та файлів kubeconfig:
kubeadm certs generate-csr --kubeconfig-dir /tmp/etc-k8s --cert-dir /tmp/etc-k8s/pki

Параметри

--cert-dir string

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка generate-csr

--kubeconfig-dir string     Типово: "/etc/kubernetes"

Шлях, де буде збережено файл kubeconfig.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Що далі

  • kubeadm init для запуску вузла панелі управління Kubernetes
  • kubeadm join для підключення вузла до кластера
  • kubeadm reset для скасування будь-яких змін, внесених за допомогою kubeadm init або kubeadm join

6.10.1.11 - kubeadm init phase

kubeadm init phase дозволяє вам викликати атомарні кроки процесу початкового завантаження. Таким чином, ви можете дозволити kubeadm виконати частину роботи, а ви можете заповнити прогалини якщо ви бажаєте застосувати кастомізацію.

kubeadm init phase узгоджується з kubeadm init workflow, і за лаштунками обидва використовують той самий код.

kubeadm init phase preflight

Використовуючи цю команду, ви можете виконати попередні перевірки на вузлі панелі управління.

Виконує передпольотні перевірки

Опис

Виконує передпольотні перевірки для kubeadm init.

kubeadm init phase preflight [flags]

Приклади

# Виконує передпольотні перевірки для kubeadm init з конфігураційним файлом config.yaml
kubeadm init phase preflight --config config.yaml

Параметри

--config string

Шлях до конфігураційного файлу kubeadm.

--cri-socket string

Шлях до CRI сокету для підключення. Якщо порожньо, kubeadm спробує автоматично визначити це значення; використовуйте цей параметр лише якщо у вас встановлено більше одного CRI або якщо у вас нестандартний CRI сокет.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка preflight

--ignore-preflight-errors strings

Список перевірок, помилки яких будуть показані як попередження. Приклад: 'IsPrivilegedUser,Swap'. Значення 'all' ігнорує помилки всіх перевірок.

--image-repository string     Типово: "registry.k8s.io"

Вибрати реєстр контейнерів для завантаження образів панелі управління

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm init phase kubelet-start

Ця фаза створить файл конфігурації kubelet та файл оточення та запустить kubelet.

Записує налаштування kubelet та (пере)запускаємо kubelet

Опис

Записує файл з KubeletConfiguration та файл оточення з налаштуваннями kubelet для конкретного вузла, а потім (пере)запустимо kubelet.

kubeadm init phase kubelet-start [flags]

Приклади

# Записує файл динамічного оточення з прапорами kubelet з файлу InitConfiguration.
kubeadm init phase kubelet-start --config config.yaml

Параметри

--config string

Шлях до конфігураційного файлу kubeadm.

--cri-socket string

Шлях до CRI сокету для підключення. Якщо порожньо, kubeadm спробує автоматично визначити це значення; використовуйте цей параметр лише якщо у вас встановлено більше одного CRI або якщо у вас нестандартний CRI сокет.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка kubelet-start

--image-repository string     Типово: "registry.k8s.io"

Вибрати реєстр контейнерів для завантаження образів панелі управління

--node-name string

Вкажіть імʼя вузла.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm init phase certs

Може використовуватися для створення всіх необхідних сертифікатів за допомогою kubeadm.

Генерує сертифікати

Опис

Ця команда не призначена для самостійного запуску. Дивіться список доступних підкоманд.

kubeadm init phase certs [flags]

Параметри

-h, --help

Довідка certs

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Генерує всі сертифікати

Опис

Генерує всі сертифікати.

kubeadm init phase certs all [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-cert-extra-sans strings

Додаткові опціональні альтернативні імена субʼєкта (SANs) для використання в сертифікаті обслуговування API Server. Можуть бути як IP-адреси, так і DNS імена.

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка all

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

--service-cidr string     Типово: "10.96.0.0/12"

Використовуйте альтернативний діапазон IP-адрес для сервісів VIP.

--service-dns-domain string     Типово: "cluster.local"

Використовуйте альтернативний домен для сервісів, наприклад, "myorg.internal".

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Генерує самопідписаний центр сертифікації Kubernetes, щоб надати ідентифікатори для інших компонентів Kubernetes

Опис

Генерує самопідписаний центр сертифікації Kubernetes, щоб надати ідентифікатори для інших компонентів Kubernetes та зберігає їх у файлах ca.crt та ca.key.

Якщо обидва файли вже існують, kubeadm оминає крок створення і використовує наявні файли.

kubeadm init phase certs ca [flags]

Операції

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка ca

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Генерує сертифікати для обслуговування API Kubernetes

Опис

Генерує сертифікати для обслуговування API Kubernetes та зберігає їх у файли apiserver.crt та apiserver.key.

Якщо обидва файли вже існують, kubeadm оминає крок створення і використовує наявні файли.

kubeadm init phase certs apiserver [flags]

Операції

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-cert-extra-sans strings

Додаткові опціональні альтернативні імена субʼєкта (SANs) для використання в сертифікаті обслуговування API Server. Можуть бути як IP-адреси, так і DNS імена.

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка apiserver

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

--service-cidr string     Типово: "10.96.0.0/12"

Використовуйте альтернативний діапазон IP-адрес для сервісів VIP.

--service-dns-domain string     Типово: "cluster.local"

Використовуйте альтернативний домен для сервісів, наприклад, "myorg.internal".

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Генерує сертифікати для сервера API для зʼєднання з kubelet

Опис

Генерує сертифікати для сервера API для зʼєднання з kubelet та зберігає їх у файлах apiserver-kubelet-client.crt та apiserver-kubelet-client.key.

Якщо обидва файли вже існують, kubeadm оминає крок створення і використовує наявні файли.

kubeadm init phase certs apiserver-kubelet-client [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка apiserver-kubelet-client

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Генерує самопідписні CA для надання ідентифікаторів для front proxy

Опис

Генерує самопідписні CA для надання ідентифікаторів для front proxy, та зберігає їх у файлах front-proxy-ca.crt та front-proxy-ca.key.

Якщо обидва файли вже існують, kubeadm пропускає крок генерації та використовує наявні файли.

kubeadm init phase certs front-proxy-ca [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка front-proxy-ca

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Генерує сетритфікати для клієнта front proxy

Опис

Генерує сертифікати для клієнта front proxy, та зберігає їх у файлах front-proxy-client.crt та front-proxy-client.key.

Якщо обидва файли вже існують, kubeadm пропускає крок генерації та використовує наявні файли.

kubeadm init phase certs front-proxy-client [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка front-proxy-client

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Генерує самопідписаний центр сертифікації для надання ідентифікаторів для etcd

Опис

Ця команда генерує самопідписаний центр сертифікації (CA) для надання ідентифікаторів для etcd, та зберігає їх у файлах etcd/ca.crt та etcd/ca.key.

Якщо обидва файли вже існують, kubeadm пропускає крок генерації та використовує наявні файли.

kubeadm init phase certs etcd-ca [flags]

Операції

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка etcd-ca

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Генерує сертифітати для обслуговування etcd

Опис

Генерує сертифікати для обслуговування etcd, та зберігає їх у файлах etcd/server.crt та etcd/server.key.

Типові SANs: localhost, 127.0.0.1, 127.0.0.1, ::1

Якщо обидва файли вже існують, kubeadm пропускає крок генерації та використовує наявні файли.

kubeadm init phase certs etcd-server [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка etcd-server

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Генгерує сертифікати для вузлів etcd для звʼязку між собою

Опис

Генерує сертифікати для вузлів etcd для звʼязку між собою, та зберігає їх у файлах etcd/peer.crt та etcd/peer.key.

Типові SANs: localhost, 127.0.0.1, 127.0.0.1, ::1

Якщо обидва файли вже існують, kubeadm пропускає крок генерації та використовує наявні файли.

kubeadm init phase certs etcd-peer [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка etcd-peer

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Генерує сертифікат для проб життєздатності для перевірки справності etcd

Опис

Генерує сертифікат для проб життєздатності для перевірки справності etcd, та зберігає його у файлах etcd/healthcheck-client.crt та etcd/healthcheck-client.key.

Якщо обидва файли вже існують, kubeadm пропускає крок генерації та використовує наявні файли.

kubeadm init phase certs etcd-healthcheck-client [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка etcd-healthcheck-client

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Генерує сертифікати, які apiserver використовує для доступу до etcd

Опис

Генерує сертифікати, які apiserver використовує для доступу до etcd та зберігає їх у файлах apiserver-etcd-client.crt та apiserver-etcd-client.key

Якщо обидва файли вже існують, kubeadm оминає крок створення і використовує наявні файли.

kubeadm init phase certs apiserver-etcd-client [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка apiserver-etcd-client

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Генерує приватний ключ для підпису токенів службових облікових записів, що дозволяє їм мати власні публічні ключі

Опис

Генерує приватний ключ для підпису токенів службових облікових записів, що дозволяє їм мати власні публічні ключі, та записує їх у файли sa.key та sa.pub.

Якщо обидва файли вже існують, kubeadm пропускає крок генерації та використовує наявні файли.

kubeadm init phase certs sa [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--kubeconfig string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка sa

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm init phase kubeconfig

Ви можете створити всі необхідні файли kubeconfig за допомогою підкоманди all або викликати їх окремо.

Генерує всі файли kubeconfig, необхідні для встановлення панелі управління та файл kubeconfig адміністратора

Опис

Ця команда не призначена для самостійного запуску. Дивіться список доступних субкоманд.

kubeadm init phase kubeconfig [flags]

Параметри

-h, --help

Довідка kubeconfig

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Генерує всі файли kubeconfig

Опис

Генерує всі файли kubeconfig.

kubeadm init phase kubeconfig all [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка all

--kubeconfig-dir string     Типово: "/etc/kubernetes"

Шлях, де буде збережено файл kubeconfig.

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

--node-name string

Вкажіть імʼя вузла.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Генерує файл kubeconfig для використання адміністратором та для самого kubeadm

Опис

Ця команда генерує файл kubeconfig для використання адміністратором та для самого kubeadm й зберігає його у файл admin.conf.

kubeadm init phase kubeconfig admin [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка admin

--kubeconfig-dir string     Типово: "/etc/kubernetes"

Шлях, де буде збережено файл kubeconfig.

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Генерує файл kubeconfig, для kubelet для використання лише для потреб початкового завантаження

Опис

Генерує файл kubeconfig, для kubelet для використання лише для потреб початкового завантаження та зберігає його у файлі kubelet.conf.

Зауважте, що цей файл має використовуватись лише для потреб початкового завантаження кластера. Після розгортання панелі управління, ви маєте запросити облікові дані для kubelet через CSR API.

kubeadm init phase kubeconfig kubelet [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка kubelet

--kubeconfig-dir string     Типово: "/etc/kubernetes"

Шлях, де буде збережено файл kubeconfig.

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

--node-name string

Вкажіть імʼя вузла.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Генерує файл kubeconfig для використання менеджером контролерів

Опис

Генерує файл kubeconfig для використання менеджером контролерів та зберігає його у файл controller-manager.conf.

kubeadm init phase kubeconfig controller-manager [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка controller-manager

--kubeconfig-dir string     Типово: "/etc/kubernetes"

Шлях, де буде збережено файл kubeconfig.

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Генерує файл kubeconfig для використання планувальником

Опис

Генерує файл kubeconfig для використання планувальником та зберігає його у файл scheduler.conf.

kubeadm init phase kubeconfig scheduler [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка scheduler

--kubeconfig-dir string     Типово: "/etc/kubernetes"

Шлях, де буде збережено файл kubeconfig.

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Генерує файл kubeconfig для суперкористувача

Опис

Генерує файл kubeconfig для суперкористувача та зберігає його у файл super-admin.conf.

kubeadm init phase kubeconfig super-admin [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка super-admin

--kubeconfig-dir string     Типово: "/etc/kubernetes"

Шлях, де буде збережено файл kubeconfig.

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm init phase control-plane

Використовуючи цю фазу, ви можете створити всі необхідні файли статичних Podʼів для компонентів панелі управління.

Генерує всі маніфести статичних Podʼів потрібні для створення панелі управління

Опис

Ця команда не призначена для самостійного запуску. Дивіться список доступних субкоманд.

kubeadm init phase control-plane [flags]

Параметри

-h, --help

Довідка control-plane

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Генерує всі фали маніфестів статичних Podʼів

Опис

Генерує всі файли маніфестів статичних Podʼів.

kubeadm init phase control-plane all [flags]

Приклади

# Генерує всі файли маніфестів статичних Podʼів для компонентів панелі управління,
# функціонально еквівалентні до тих, що генеруються командою kubeadm init.
kubeadm init phase control-plane all

# Генерує всі файли маніфестів статичних Podʼів з використанням опцій, отриманих з конфігураційного файлу.
kubeadm init phase control-plane all --config config.yaml

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

--feature-gates string

Набір пар ключ=значення, що описують функціональні можливості для різних функцій. Варіанти:
ControlPlaneKubeletLocalMode=true|false (ALPHA — default=false)
EtcdLearnerMode=true|false (BETA — default=true)
PublicKeysECDSA=true|false (DEPRECATED — default=false)
RootlessControlPlane=true|false (ALPHA — default=false)
WaitForAllControlPlaneComponents=true|false (ALPHA — default=false)

-h, --help

Довідка all

--image-repository string     Типово: "registry.k8s.io"

Вибрати реєстр контейнерів для завантаження образів панелі управління

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

--pod-network-cidr string

Вказує діапазон IP-адрес для мережі Pod. Якщо встановлено, панель управління автоматично виділить CIDR для кожного вузла.

--service-cidr string     Типово: "10.96.0.0/12"

Використовуйте альтернативний діапазон IP-адрес для сервісів VIP.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Генерує маніфест статичного Podʼа для kube-apiserver

Опис

Генерує маніфест статичного Podʼа для kube-apiserver

kubeadm init phase control-plane apiserver [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

--feature-gates string

Набір пар ключ=значення, що описують функціональні можливості для різних функцій. Варіанти:
ControlPlaneKubeletLocalMode=true|false (ALPHA — default=false)
EtcdLearnerMode=true|false (BETA — default=true)
PublicKeysECDSA=true|false (DEPRECATED — default=false)
RootlessControlPlane=true|false (ALPHA — default=false)
WaitForAllControlPlaneComponents=true|false (ALPHA — default=false)

-h, --help

Довідка apiserver

--image-repository string     Типово: "registry.k8s.io"

Вибрати реєстр контейнерів для завантаження образів панелі управління

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

--service-cidr string     Типово: "10.96.0.0/12"

Використовуйте альтернативний діапазон IP-адрес для сервісів VIP.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Генерує маніфест статичного Podʼа для kube-controller-manager

Опис

Генерує маніфест статичного Podʼа для kube-controller-manager

kubeadm init phase control-plane controller-manager [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка controller-manager

--image-repository string     Типово: "registry.k8s.io"

Вибрати реєстр контейнерів для завантаження образів панелі управління

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

--pod-network-cidr string

Вказує діапазон IP-адрес для мережі Pod. Якщо встановлено, панель управління автоматично виділить CIDR для кожного вузла.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Генерує маніфест статичного Podʼа для kube-scheduler

Опис

Генерує маніфест статичного Podʼа для kube-scheduler

kubeadm init phase control-plane scheduler [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-o, --experimental-output string     Типово: "text"

Формат виводу. Один з: text|json|yaml|go-template|go-template-file|template|templatefile|jsonpath|jsonpath-as-json|jsonpath-file.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка scheduler

--image-repository string     Типово: "registry.k8s.io"

Вибрати реєстр контейнерів для завантаження образів панелі управління

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm init phase etcd

Використовуйте наступну фазу, щоб створити локальний екземпляр etcd на основі файлу статичного Pod.

Генерує файл маніфесту статичного Podʼа для екземпляра local etcd

Опис

Ця команда не призначена для самостійного запуску. Дивіться список доступних субкоманд.

kubeadm init phase etcd [flags]

Параметри

-h, --help

Довідка etcd

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Генерує файл маніфесту статичного Podʼа для екземпляра local, одновузлового local etcd

Опис

Генерує файл маніфесту статичного Podʼа для екземпляра local, одновузлового local etcd

kubeadm init phase etcd local [flags]

Приклади

# Генерує файл маніфесту статичного Podʼа для etcd, функціонально
# еквівалентного до того, що генерується командою kubeadm init.
kubeadm init phase etcd local

# Генерує файл маніфесту статичного Podʼа для etcd з використанням опцій
# отриманих з файлу конфігурації.
kubeadm init phase etcd local --config config.yaml

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка local

--image-repository string     Типово: "registry.k8s.io"

Вибрати реєстр контейнерів для завантаження образів панелі управління

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm init phase upload-config

За допомогою цієї команди ви можете завантажити конфігурацію kubeadm до вашого кластера. Також ви можете скористатися kubeadm config.

Завантажує конфігурації kubeadm та kubelet у ConfigMap

Опис

Ця команда не призначена для самостійного запуску. Дивіться список доступних субкоманд.

kubeadm init phase upload-config [flags]

Параметри

-h, --help

Довідка upload-config

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Завантажуємо всю конфігурацію в ConfigMap

Опис

Завантажує всю конфігурацію в ConfigMap.

kubeadm init phase upload-config all [flags]

Параметри

--config string

Шлях до конфігураційного файлу kubeadm.

--cri-socket string

Шлях до CRI сокету для підключення. Якщо порожньо, kubeadm спробує автоматично визначити це значення; використовуйте цей параметр лише якщо у вас встановлено більше одного CRI або якщо у вас нестандартний CRI сокет.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка all

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Завантажує kubeadm ClusterConfiguration у ConfigMap

Опис

Завантажує конфігурацію кластера kubeadm ClusterConfig до ConfigMap з назвою kubeadm-config у просторі імен kube-system. Це дозволить правильно конфігурувати компоненти системи та спростить роботу користувачів під час оновлення.

Альтернативно, ви можете використовувати kubeadm config.

kubeadm init phase upload-config kubeadm [flags]

Приклади

# Завантаження конфігурації кластера
kubeadm init phase upload-config kubeadm --config=myConfig.yaml

Параметри

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

--cri-socket string

Шлях до CRI сокету для підключення. Якщо порожньо, kubeadm спробує автоматично визначити це значення; використовуйте цей параметр лише якщо у вас встановлено більше одного CRI або якщо у вас нестандартний CRI сокет.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка kubeadm

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Завантажує налаштування компонентів kubelet у ConfigMap

Опис

Завантажуємо конфігурацію kubelet, видобуту з обʼєкта kubeadm InitConfiguration, до ConfigMap kubelet-config у кластері

kubeadm init phase upload-config kubelet [flags]

Приклади

# Завантаження конфігурації kubelet з файла конфігурації kubeadm у ConfigMap в кластері
kubeadm init phase upload-config kubelet --config kubeadm.yaml

Параметри

--config string

Шлях до конфігураційного файлу kubeadm.

--cri-socket string

Шлях до CRI сокету для підключення. Якщо порожньо, kubeadm спробує автоматично визначити це значення; використовуйте цей параметр лише якщо у вас встановлено більше одного CRI або якщо у вас нестандартний CRI сокет.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка kubelet

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm init phase upload-certs

Використовуйте наступну фазу, щоб завантажити сертифікати панелі управління в кластер. Стандартно термін дії сертифікатів і ключа шифрування закінчується через дві години.

Завантажує сертифікати до kubeadm-certs

Опис

Завантажує сертифікати панелі управління в Secret kubeadm-certs

kubeadm init phase upload-certs [flags]

Параметри

--certificate-key string

Ключ, що використовується для шифрування сертифікатів панелі управління у Secret kubeadm-certs. Ключ сертифіката — це шістнадцятковий рядок, який є ключем AES розміром 32 байти

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка upload-certs

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

--skip-certificate-key-print

Не виводити ключ, який використовується для шифрування сертифікатів панелі управління.

--upload-certs

Завантажити сертифікати панелі управління у Secret kubeadm-certs.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm init phase mark-control-plane

Використовуйте наступну фазу для позначення вузла як вузла панелі управління.

Позначає вузол як вузол панелі управління

Опис

Позначає вузол як вузол панелі управління.

kubeadm init phase mark-control-plane [flags]

Приклади

# Застосовує мітку та taint панелі управління до поточного вузла, функціонально еквівалентно до того, що виконується командою kubeadm init.
kubeadm init phase mark-control-plane --config config.yaml

# Застосовує мітку та taint панелі управління до конкретного вузла
kubeadm init phase mark-control-plane --node-name myNode

Параметри

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка mark-control-plane

--node-name string

Вкажіть імʼя вузла.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm init phase bootstrap-token

Використовуйте наступну фазу для створення або керування bootstrap токенів.

Генерує токени bootstrap, які використовуються для приєднання вузла до кластера

Опис

Токени bootstrap використовуються для встановлення двосторонньої довіри між вузлом, що приєднується до кластера, і вузлом панелі управління.

Ця команда виконує всі налаштування, необхідні для роботи токенів bootstrap, а потім створює початковий токен.

kubeadm init phase bootstrap-token [flags]

Приклади

# Налаштувати всі конфігурації токенів Bootstrap та створити 
# початковий токен, функціонально еквівалентний до того, що 
# генерується командою kubeadm init.
kubeadm init phase bootstrap-token

Параметри

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

Довідка bootstrap-token

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

--skip-token-print

Пропустити друк стандартного bootstrap токена, згенерованого 'kubeadm init'.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm init phase kubelet-finalize

Використовуйте наступну фазу для оновлення налаштувань, що стосуються kubelet після TLS bootstrap. Ви можете використовувати субкоманду all, щоб запустити всі фази `kubelet-finalize.

Оновлює налаштування, що стосуються kubelet, після початкового завантаження TLS

Опис

Оновлює налаштування, що стосуються kubelet, після початкового завантаження TLS

kubeadm init phase kubelet-finalize [flags]

Приклади

# Оновлення налаштувань, що стосуються kubelet, після початкового завантаження TLS"
kubeadm init phase kubelet-finalize all --config

Параметри

-h, --help

Довідка kubelet-finalize

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Запускає всі фази kubelet-finalize

Опис

Запускає всі фази kubelet-finalize.

kubeadm init phase kubelet-finalize all [flags]

Приклади

# Оновлення налаштувань, що стосуються kubelet, після початкового завантаження TLS
kubeadm init phase kubelet-finalize all --config

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка all

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Вмикає ротацію сертифікатів клієнтів kubelet (ЗАСТАРІЛО: використовуйте натомість 'enable-client-cert-rotation' )

Опис

Вмикає ротацію сертифікатів клієнтів kubelet (ЗАСТАРІЛО: використовуйте натомість 'enable-client-cert-rotation' )

kubeadm init phase kubelet-finalize experimental-cert-rotation [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка experimental-cert-rotation

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm init phase addon

Ви можете встановити всі доступні надбудови за допомогою підкоманди all, або встановити їх вибірково.

Встановлює необхідні надбудови для проходження тестів на відповідність

Опис

Ця команда не призначена для самостійного запуску. Дивіться список доступних субкоманд.

kubeadm init phase addon [flags]

Параметри

-h, --help

Довідка addon

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Встановлює всі надбудови

Опис

Вставляє всі надбудови.

kubeadm init phase addon all [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

--feature-gates string

Набір пар ключ=значення, що описують функціональні можливості для різних функцій. Опції:
ControlPlaneKubeletLocalMode=true|false (ALPHA — default=false)
EtcdLearnerMode=true|false (BETA — default=true)
PublicKeysECDSA=true|false (DEPRECATED — default=false)
RootlessControlPlane=true|false (ALPHA — default=false)
WaitForAllControlPlaneComponents=true|false (ALPHA — default=false)

-h, --help

Довідка all

--image-repository string     Типово: "registry.k8s.io"

Вибір реєстру контейнерів для завантаження образів панелі управління

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

--kubernetes-version string     Типово: "stable-1"

Вибір конкретної версії Kubernetes для панелі управління.

--pod-network-cidr string

Вказує діапазон IP-адрес для мережі Pod. Якщо встановлено, панель управління автоматично виділить CIDR для кожного вузла.

--service-cidr string     Типово: "10.96.0.0/12"

Використовуйте альтернативний діапазон IP-адрес для сервісів VIP.

--service-dns-domain string     Типово: "cluster.local"

Використовуйте альтернативний домен для сервісів, наприклад, "myorg.internal".

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Встановлює надбудову CoreDNS в кластер Kubernetes

Опис

Встановлює компоненти надбудови CoreDNS через сервер API. Зверніть увагу, що хоча DNS-сервер розгорнуто, його не буде заплановано, доки не буде встановлено CNI.

kubeadm init phase addon coredns [flags]

Параметри

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

--feature-gates string

Набір пар ключ=значення, що описують функціональні можливості для різних функцій. Опції:
ControlPlaneKubeletLocalMode=true|false (ALPHA — default=false)
EtcdLearnerMode=true|false (BETA — default=true)
PublicKeysECDSA=true|false (DEPRECATED — default=false)
RootlessControlPlane=true|false (ALPHA — default=false)
WaitForAllControlPlaneComponents=true|false (ALPHA — default=false)

-h, --help

Довідка coredns

--image-repository string     Типово: "registry.k8s.io"

Вибір реєстру контейнерів для завантаження образів панелі управління

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

--kubernetes-version string     Типово: "stable-1"

Вибір конкретної версії Kubernetes для панелі управління.

--print-manifest

Вивести маніфести надбудов в STDOUT замість їх встановлення

--service-cidr string     Типово: "10.96.0.0/12"

Використовуйте альтернативний діапазон IP-адрес для сервісів VIP.

--service-dns-domain string     Типово: "cluster.local"

Використовуйте альтернативний домен для сервісів, наприклад, "myorg.internal".

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Встановлює надбудову kube-proxy в кластер Kubernetes

Опис

Встановлює компоненти надбудови kube-proxy через API-сервер.

kubeadm init phase addon kube-proxy [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка kube-proxy

--image-repository string     Типово: "registry.k8s.io"

Виберіть реєстр контейнерів для завантаження образів панелі управління

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

--kubernetes-version string     Типово: "stable-1"

Вибрати конкретну версію Kubernetes для панелі управління.

--pod-network-cidr string

Вказує діапазон IP-адрес для мережі Pod. Якщо встановлено, панель управління автоматично виділить CIDR для кожного вузла.

--print-manifest

Вивести маніфести надбудов в STDOUT замість їх встановлення

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Для отримання більш детальної інформації про кожне поле в конфігурації v1beta4 ви можете перейти на нашу сторінки довідки API.

Що далі

  • kubeadm init для завантаження вузла керування Kubernetes
  • kubeadm join для підключення вузла до кластера
  • kubeadm reset для скасування будь-яких змін, зроблених за допомогою kubeadm init або kubeadm join
  • kubeadm alpha для випробування експериментальних функцій

6.10.1.12 - kubeadm join phase

kubeadm join phase дозволяє викликати атомарні кроки процесу приєднання. Таким чином, ви можете дозволити kubeadm виконати частину роботи, а ви заповните прогалини, якщо захочете застосувати налаштування.

kubeadm join phase узгоджується з workflow приєднання kubeadm, і за лаштунками обидва використовують той самий код.

kubeadm join phase

Використовуйте цю команду для виклику однієї фази робочого процесу join

Опис

Використовуйте цю команду для виклику однієї фази робочого процесу join

Параметри

-h, --help

Довідка phase

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm join phase preflight

Використовуючи цю фазу, ви можете виконати передпольотну перевірку вузла, що приєднується.

Виконує передполітні перевірки join

Опис

Виконує передполітні перевірки для kubeadm join.

kubeadm join phase preflight [api-server-endpoint] [flags]

Приклади

# Виконує передполітні перевірки для kubeadm join
kubeadm join phase preflight --config kubeadm-config.yaml

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--certificate-key string

Ключ, що використовується для шифрування сертифікатів панелі управління у Secret kubeadm-certs. Ключ сертифіката — це шістнадцятковий рядок, який є ключем AES розміром 32 байти

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane

Створити новий екземпляр панелі управління на цьому вузлі

--cri-socket string

Шлях до CRI сокету для підключення. Якщо порожньо, kubeadm спробує автоматично визначити це значення; використовуйте цей параметр лише якщо у вас встановлено більше одного CRI або якщо у вас нестандартний CRI сокет.

--discovery-file string

Для виявлення на основі файлу, файл або URL, з якого буде завантажена інформація про кластер.

--discovery-token string

Для виявлення на основі токена, токен, який використовується для перевірки інформації про кластер, отриманої з сервера API.

--discovery-token-ca-cert-hash strings

Для виявлення на основі токена, перевірити, що публічний ключ кореневого центру сертифікації відповідає цьому хешу (формат: "<тип>:<значення>").

--discovery-token-unsafe-skip-ca-verification

Для виявлення на основі токена, дозволити приєднання без закріплення --discovery-token-ca-cert-hash.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка preflight

--ignore-preflight-errors strings

Список перевірок, помилки яких будуть показані як попередження. Приклад: 'IsPrivilegedUser,Swap'. Значення 'all' ігнорує помилки від усіх перевірок.

--node-name string

Вкажіть імʼя вузла.

--tls-bootstrap-token string

Вкажіть токен, який використовується для тимчасової автентифікації з Панеллю Управління Kubernetes під час приєднання вузла.

--token string

Використовуйте цей токен для discovery-token та tls-bootstrap-token, коли ці значення не вказані окремо.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm join phase control-plane-prepare

Використовуючи цю фазу, ви можете підготувати вузол до обслуговування панелі управління.

Готує машину до обслуговування панелі управління

Опис

Готує машину до обслуговування панелі управління.

kubeadm join phase control-plane-prepare [flags]

Приклади

# Готує машину до обслуговування панелі управління
kubeadm join phase control-plane-prepare all

Параметри

-h, --help

Довідка control-plane-prepare

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Готує машину для роботи як панелі управління

Опис

Готує машину для роботи як панелі управління.

kubeadm join phase control-plane-prepare all [api-server-endpoint] [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--certificate-key string

Ключ, що використовується для шифрування сертифікатів панелі управління у Secret kubeadm-certs. Ключ сертифіката — це шістнадцятковий рядок, який є ключем AES розміром 32 байти

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane

Створити новий екземпляр панелі управління на цьому вузлі

--discovery-file string

Для виявлення на основі файлу, файл або URL, з якого буде завантажена інформація про кластер.

--discovery-token string

Для виявлення на основі токена, токен, який використовується для перевірки інформації про кластер, отриманої з сервера API.

--discovery-token-ca-cert-hash strings

Для виявлення на основі токена, перевірити, що публічний ключ кореневого центру сертифікації відповідає цьому хешу (формат: "<тип>:<значення>").

--discovery-token-unsafe-skip-ca-verification

Для виявлення на основі токена, дозволити приєднання без закріплення --discovery-token-ca-cert-hash.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка all

--node-name string

Вкажіть імʼя вузла.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

--tls-bootstrap-token string

Вкажіть токен, який використовується для тимчасової автентифікації з Панеллю Управління Kubernetes під час приєднання вузла.

--token string

Використовуйте цей токен для discovery-token та tls-bootstrap-token, коли ці значення не вказані окремо.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Завантажує сертифікати, спільні для вузлів панелі управління, з архіву kubeadm-certs Secret

Опис

Завантажує сертифікати, спільні для вузлів панелі управління, з архіву kubeadm-certs Secret

kubeadm join phase control-plane-prepare download-certs [api-server-endpoint] [flags]

Параметри

--certificate-key string

Ключ, що використовується для шифрування сертифікатів панелі управління у Secret kubeadm-certs. Ключ сертифіката — це шістнадцятковий рядок, який є ключем AES розміром 32 байти

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane

Створити новий екземпляр панелі управління на цьому вузлі

--discovery-file string

Для виявлення на основі файлу, файл або URL, з якого буде завантажена інформація про кластер.

--discovery-token string

Для виявлення на основі токена, токен, який використовується для перевірки інформації про кластер, отриманої з сервера API.

--discovery-token-ca-cert-hash strings

Для виявлення на основі токена, перевірити, що публічний ключ кореневого центру сертифікації відповідає цьому хешу (формат: "<тип>:<значення>").

--discovery-token-unsafe-skip-ca-verification

Для виявлення на основі токена, дозволити приєднання без закріплення --discovery-token-ca-cert-hash.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка download-certs

--tls-bootstrap-token string

Вкажіть токен, який використовується для тимчасової автентифікації з Панеллю Управління Kubernetes під час приєднання вузла.

--token string

Використовуйте цей токен для discovery-token та tls-bootstrap-token, коли ці значення не вказані окремо.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Генерує сертифікати для нових компенонетів панелі управління

Опис

Генерує сертифікати для нових компонентів панелі управління.

kubeadm join phase control-plane-prepare certs [api-server-endpoint] [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane

Створити новий екземпляр панелі управління на цьому вузлі

--discovery-file string

Для виявлення на основі файлу, файл або URL, з якого буде завантажена інформація про кластер.

--discovery-token string

Для виявлення на основі токена, токен, який використовується для перевірки інформації про кластер, отриманої з сервера API.

--discovery-token-ca-cert-hash strings

Для виявлення на основі токена, перевірити, що публічний ключ кореневого центру сертифікації відповідає цьому хешу (формат: "<тип>:<значення>").

--discovery-token-unsafe-skip-ca-verification

Для виявлення на основі токена, дозволити приєднання без закріплення --discovery-token-ca-cert-hash.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка certs

--node-name string

Вкажіть імʼя вузла.

--tls-bootstrap-token string

Вкажіть токен, який використовується для тимчасової автентифікації з Панеллю Управління Kubernetes під час приєднання вузла.

--token string

Використовуйте цей токен для discovery-token та tls-bootstrap-token, коли ці значення не вказані окремо.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Генерує kubeconfig для нових компонентів панелі управління

Опис

Генерує kubeconfig для нових компонентів панелі управління, які будуть додані до кластера.

kubeadm join phase control-plane-prepare kubeconfig [api-server-endpoint] [flags]

Параметри

--certificate-key string

Ключ, що використовується для шифрування сертифікатів панелі управління у Secret kubeadm-certs. Ключ сертифіката — це шістнадцятковий рядок, який є ключем AES розміром 32 байти

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane

Створити новий екземпляр панелі управління на цьому вузлі

--discovery-file string

Для виявлення на основі файлу, файл або URL, з якого буде завантажена інформація про кластер.

--discovery-token string

Для виявлення на основі токена, токен, який використовується для перевірки інформації про кластер, отриманої з сервера API.

--discovery-token-ca-cert-hash strings

Для виявлення на основі токена, перевірити, що публічний ключ кореневого центру сертифікації відповідає цьому хешу (формат: "<тип>:<значення>").

--discovery-token-unsafe-skip-ca-verification

Для виявлення на основі токена, дозволити приєднання без закріплення --discovery-token-ca-cert-hash.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка kubeconfig

--tls-bootstrap-token string

Вкажіть токен, який використовується для тимчасової автентифікації з Панеллю Управління Kubernetes під час приєднання вузла.

--token string

Використовуйте цей токен для discovery-token та tls-bootstrap-token, коли ці значення не вказані окремо.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Генерує маніфести для нових компонентів панелі управління

Опис

Генерує маніфести для нових компонентів панелі управління.

kubeadm join phase control-plane-prepare control-plane [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--apiserver-bind-port int32     Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane

Створити новий екземпляр панелі управління на цьому вузлі

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка control-plane

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm join phase kubelet-start

На цьому етапі ви можете записати налаштування kubelet, сертифікати та (пере)запустити kubelet.

Записує налаштування kubelet, сертифікати та (пере)запускає kubelet

Опис

Записує файл з KubeletConfiguration та файл оточення з налаштуваннями kubelet для конкретного вузла, а потім (пере)запускає kubelet.

kubeadm join phase kubelet-start [api-server-endpoint] [flags]

Параметри

tr>
--config string

Шлях до конфігураційного файлу kubeadm.

--cri-socket string

Шлях до CRI сокету для підключення. Якщо порожньо, kubeadm спробує автоматично визначити це значення; використовуйте цей параметр лише якщо у вас встановлено більше одного CRI або якщо у вас нестандартний CRI сокет.

--discovery-file string

Для виявлення на основі файлу, файл або URL, з якого буде завантажена інформація про кластер.

--discovery-token string

Для виявлення на основі токена, токен, який використовується для перевірки інформації про кластер, отриманої з сервера API.

--discovery-token-ca-cert-hash strings

Для виявлення на основі токена, перевірити, що публічний ключ кореневого центру сертифікації відповідає цьому хешу (формат: "<тип>:<значення>").

--discovery-token-unsafe-skip-ca-verification

Для виявлення на основі токена, дозволити приєднання без закріплення --discovery-token-ca-cert-hash.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка kubelet-start

--node-name string

Вкажіть імʼя вузла.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

--tls-bootstrap-token string

Вкажіть токен, який використовується для тимчасової автентифікації з Панеллю Управління Kubernetes під час приєднання вузла.

--token string

Використовуйте цей токен для discovery-token та tls-bootstrap-token, коли ці значення не вказані окремо.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm join phase control-plane-join

Використовуючи цю фазу, ви можете приєднати вузол як екземпляр панелі управління.

Приєднує машину до екземпляра панелі управління

Опис

Приєднує машину до екземпляра панелі управління.

kubeadm join phase control-plane-join [flags]

Приклади

# Приєднує машину до екземпляра панелі управління
kubeadm join phase control-plane-join all

Параметри

-h, --help

Довідка control-plane-join

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Приєднує машину до екземпляру панелі управління

Опис

Приєднує машину до екземпляру панелі управління.

kubeadm join phase control-plane-join all [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane

Створити новий екземпляр панелі управління на цьому вузлі

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка all

--node-name string

Вкажіть імʼя вузла.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Додає нового учасника local etcd

Опис

Додає нового учасника local etcd

kubeadm join phase control-plane-join etcd [flags]

Параметри

--apiserver-advertise-address string

IP-адреса, на якому API-сервер буде оголошувати що віе прослуховує звернення. Якщо не вказано, використовується стандартний мережевий інтерфейс.

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane

Створити новий екземпляр панелі управління на цьому вузлі

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка etcd

--node-name string

Вкажіть імʼя вузла.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Позначає вузол як вузол панелі управління

Опис

Позначає вузол як вузол панелі управління.

kubeadm join phase control-plane-join mark-control-plane [flags]

Параметри

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane

Створити новий екземпляр панелі управління на цьому вузлі

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка mark-control-plane

--node-name string

Вкажіть імʼя вузла.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Що далі

  • kubeadm init для завантаження вузла керування Kubernetes
  • kubeadm join для підключення вузла до кластера
  • kubeadm reset для скасування будь-яких змін, зроблених за допомогою kubeadm init або kubeadm join
  • kubeadm alpha для випробування експериментальних функцій

6.10.1.13 - kubeadm kubeconfig

kubeadm kubeconfig надає інструменти для управління файлами kubeconfig.

Приклади використання kubeadm kubeconfig user дивіться в розділі Генерація файлів kubeconfig для додаткових користувачів.

kubeadm kubeconfig

Файлові утиліти Kubeconfig

Опис

Файлові утиліти Kubeconfig.

Параметри

-h, --help

Довідка kubeconfig

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm kubeconfig user

За допомогою цієї команди можна вивести файл kubeconfig для додаткового користувача.

Виводить файл kubeconfig для додаткового користувача

Опис

Виводить файл kubeconfig для додаткового користувача.

kubeadm kubeconfig user [flags]

Приклади

# Виводить файл kubeconfig для додаткового користувача з іменем foo
kubeadm kubeconfig user --client-name=foo

# Виводить файл kubeconfig для додаткового користувача з іменем foo, використовуючи конфігураційний файл kubeadm bar
kubeadm kubeconfig user --client-name=foo --config=bar

Параметри

--client-name string

Імʼя користувача. Буде використовуватися як CN у разі створення клієнтських сертифікатів

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка user

--org strings

Організації сертифіката клієнта. Буде використовуватися як O, якщо будуть створені клієнтські сертифікати

--token string

TТокен, який слід використовувати як механізм автентифікації для цього kubeconfig замість клієнтських сертифікатів

--validity-period duration     Типово: 8760h0m0s

Термін дії клієнтського сертифіката. Відраховується від поточного часу.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

6.10.1.14 - kubeadm reset phase

kubeadm reset phase дозволяє вам викликати атомарні кроки процесу reset. Таким чином, ви можете дозволити kubeadm виконати частину роботи, а ви можете заповнити прогалини якщо ви бажаєте застосувати кастомізацію.

kubeadm reset phase узгоджується з kubeadm reset workflow, і за лаштунками обидва використовують той самий код.

kubeadm reset phase

Використовуйте цю команду для виклику однієї фази процесу reset

Опис

Використовуйте цю команду для виклику однієї фази процесу reset

Параметри

-h, --help

Довідка phase

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm reset phase preflight

За допомогою цієї фази ви можете виконати передпольотну перевірку вузла, який скидається.

Виконує передполітні перевірки для kubeadm reset

Опис

Виконує передполітні перевірки для kubeadm reset.

kubeadm reset phase preflight [flags]

Параметри

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-f, --force

Виконати reset вузла без запиту на підтвердження.

-h, --help

Довідка preflight

--ignore-preflight-errors strings

Список перевірок, помилки яких будуть показані як попередження. Приклад: 'IsPrivilegedUser,Swap'. Значення 'all' ігнорує помилки від усіх перевірок.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm reset phase remove-etcd-member

За допомогою цієї фази ви можете вилучити члена etcd цього вузла панелі управління з кластера etcd.

Видаляє члена local etcd

Опмс

Видаляє члена local etcd для вузла панелі управління.

kubeadm reset phase remove-etcd-member [flags]

Параметри

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка remove-etcd-member

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm reset phase cleanup-node

За допомогою цієї фази ви можете виконати очищення на цьому вузлі.

Запускає очищення вузла

Опис

Запускає очищення вузла.

kubeadm reset phase cleanup-node [flags]

Параметри

--cert-dir string     Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--cleanup-tmp-dir

Очистити теку "/etc/kubernetes/tmp"

--cri-socket string

Шлях до CRI сокету для підключення. Якщо порожньо, kubeadm спробує автоматично визначити це значення; використовуйте цей параметр лише якщо у вас встановлено більше одного CRI або якщо у вас нестандартний CRI сокет.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка cleanup-node

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Що далі

  • kubeadm init для завантаження вузла керування Kubernetes
  • kubeadm join для підключення вузла до кластера
  • kubeadm reset для скасування будь-яких змін, зроблених за допомогою kubeadm init або kubeadm join
  • kubeadm alpha для випробування експериментальних функцій

6.10.1.15 - kubeadm upgrade phase

У версії v1.15.0 kubeadm запровадив попередню підтримку фаз kubeadm upgrade node. Фази для інших підкоманд kubeadm upgrade, таких як apply, можуть бути додані в наступних випусках.

kubeadm upgrade node phase

Використовуючи цю фазу, ви можете вибрати виконання окремих кроків оновлення вторинних вузлів панелі управління або робочих вузлів. Зверніть увагу, що kubeadm upgrade apply все ще потрібно викликати на первинному вузлі панелі управління.

Використовуйте цю команду для виклику однієї фази робочого процесу node

Опис

Використовуйте цю команду для виклику однієї фази робочого процесу node

Параметри

-h, --help

Довідка phase

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Виконує попередні перевірки на вузлі перед оновленням

Опис

Ця команда виконує попередні перевірки для kubeadm upgrade node.

kubeadm upgrade node phase preflight [flags]

Параметри

-h, --help

Довідка preflight

--ignore-preflight-errors strings

Список перевірок, помилки яких будуть показані як попередження. Приклад: 'IsPrivilegedUser,Swap'. Значення 'all' ігнорує помилки всіх перевірок.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Оновлює екземпляр панелі управління, розгорнутої на цьому вузлі, якщо така є

Опис

Оновлює екземпляр панелі управління, розгорнутої на цьому вузлі, якщо така є.

kubeadm upgrade node phase control-plane [flags]

Параметри

--certificate-renewal     Типово: true

Виконує оновлення сертифікатів, які використовуються компонентами під час оновлення.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

--etcd-upgrade     Типово: true

Виконує оновлення etcd.

-h, --help

Довідка control-plane

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Оновлює конфігурації kubelet для цього вузла

Опис

Завантажує конфігурацію kubelet з файлу kubelet-config ConfigMap, що зберігається в кластері

kubeadm upgrade node phase kubelet-config [flags]

Параметри

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка kubelet-config

--kubeconfig string     Типово: "/etc/kubernetes/admin.conf"

Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

--patches string

Шлях до теки, що містить файли з іменами "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним з "strategic", "merge" або "json", і вони відповідають форматам патчів, що підтримуються kubectl. Стандартно "patchtype" є "strategic". "extension" повинно бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення, які патчі застосовуються першими за алфавітно-цифровим порядком.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Що далі

  • kubeadm init для завантаження вузла керування Kubernetes
  • kubeadm join для підключення вузла до кластера
  • kubeadm reset для скасування будь-яких змін, зроблених за допомогою kubeadm init або kubeadm join
  • kubeadm upgrade для оновлення вузла kubeadm
  • kubeadm alpha для випробування експериментальних функцій

6.10.1.16 - Деталі реалізації

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.10 [stable]

kubeadm init та kubeadm join разом забезпечують гарну послідовність дій користувача для створення базового кластера Kubernetes з нуля, відповідно до найкращих практик. Однак може бути не очевидно, як kubeadm це робить.

Цей документ надає додаткову інформацію про те, що відбувається за лаштунками, з метою поширення знань про найкращі практики для кластера Kubernetes.

Основні принципи дизайну

Кластер, який налаштовується за допомогою kubeadm init та kubeadm join, має бути:

  • Захищеним: Він повинен дотримуватися останніх найкращих практик, таких як:
    • забезпечення RBAC
    • використання Node Authorizer
    • використання захищеного зв’язку між компонентами панелі управління
    • використання захищеного зв’язку між API-сервером і kubelet-ами
    • обмеження доступу до API kubelet-а
    • обмеження доступу до API для системних компонентів, таких як kube-proxy та CoreDNS
    • обмеження доступу до того, що може отримати Bootstrap Token
  • Зручним для користувачів: Користувачеві не повинно знадобитися виконувати більше, ніж кілька команд:
    • kubeadm init
    • export KUBECONFIG=/etc/kubernetes/admin.conf
    • kubectl apply -f <network-of-choice.yaml>
    • kubeadm join --token <token> <endpoint>:<port>
  • Розширюваним:
    • Він не повинен віддавати перевагу жодному конкретному мережевому провайдеру. Налаштування мережі кластерів не входить до сфери компетенції
    • Він повинен надавати можливість використовувати конфігураційний файл для налаштування різних параметрів

Константи та добре відомі значення та шляхи

Щоб зменшити складність і спростити розробку вищого рівня інструментів, що будуються на основі kubeadm, він використовує обмежений набір констант для добре відомих шляхів та імен файлів.

Тека Kubernetes /etc/kubernetes є константою в застосунку, оскільки вона є очевидним шляхом у більшості випадків і найінтуїтивнішим розташуванням; інші константні шляхи та імена файлів є такими:

  • /etc/kubernetes/manifests як шлях, де kubelet повинен шукати маніфести статичних Podʼів. Імена маніфестів статичних Podʼів:

    • etcd.yaml
    • kube-apiserver.yaml
    • kube-controller-manager.yaml
    • kube-scheduler.yaml
  • /etc/kubernetes/ як шлях, де зберігаються файли kubeconfig з ідентифікаторами для компонентів панелі управління. Імена файлів kubeconfig:

    • kubelet.conf (bootstrap-kubelet.conf під час TLS bootstrap)
    • controller-manager.conf
    • scheduler.conf
    • admin.conf для адміністратора кластера і kubeadm
    • super-admin.conf для супер-адміністратора кластера, який може обходити RBAC
  • Імена сертифікатів і ключових файлів:

    • ca.crt, ca.key для центру авторизації Kubernetes
    • apiserver.crt, apiserver.key для сертифіката API-сервера
    • apiserver-kubelet-client.crt, apiserver-kubelet-client.key для клієнтського сертифіката, що використовується API-сервером для безпечного підключення до kubelet-ів
    • sa.pub, sa.key для ключа, який використовується менеджером контролерів при підписанні ServiceAccount
    • front-proxy-ca.crt, front-proxy-ca.key для центру авторизації front-проксі
    • front-proxy-client.crt, front-proxy-client.key для клієнта front-проксі

Внутрішній дизайн робочого процесу kubeadm init

Команда kubeadm init складається з послідовності атомарних завдань для виконання, як описано в внутрішньому робочому процесі kubeadm init.

Команда kubeadm init phase дозволяє користувачам викликати кожне завдання окремо, і в кінцевому підсумку пропонує багаторазовий і компонований API/інструментарій, який може бути використаний іншими інструментами початкового завантаження Kubernetes, будь-яким інструментом автоматизації ІТ або досвідченим користувачем для створення власних кластерів.

Перевірка перед установкою (Preflight checks)

Kubeadm виконує набір перевірок перед початком ініціалізації з метою перевірки передумов і уникнення типових проблем під час запуску кластера.

Користувач може пропустити певні перевірки перед установкою або всі за допомогою опції --ignore-preflight-errors.

  • [Попередження], якщо версія Kubernetes, яку слід використовувати (вказана за допомогою прапорця --kubernetes-version), є хоча б на одну мінорну версію вищою за версію kubeadm CLI.
  • Вимоги до системи Kubernetes:
    • якщо використовується Linux:
      • [Помилка], якщо версія ядра старіша за мінімально необхідну версію
      • [Помилка], якщо не налаштовані необхідні підсистеми cgroups
  • [Помилка], якщо точка доступу CRI не відповідає
  • [Помилка], якщо користувач не є root
  • [Помилка], якщо імʼя машини не є дійсним DNS-піддоменом
  • [Попередження], якщо імʼя хосту неможливо знайти через мережевий пошук
  • [Помилка], якщо версія kubelet нижча за мінімальну підтримувану версію kubelet, підтримувану kubeadm (поточна мінорна версія -1)
  • [Помилка], якщо версія kubelet хоча б на одну мінорну версію вища за необхідну версію панелі управління (непідтримуване відхилення версій)
  • [Попередження], якщо служба kubelet не існує або вона вимкнена
  • [Попередження], якщо активний firewalld
  • [Помилка], якщо використовується порт привʼязки API-сервера або порти 10250/10251/10252
  • [Помилка], якщо тека /etc/kubernetes/manifests вже існує і не є порожньою
  • [Помилка], якщо включений swap
  • [Помилка], якщо команди conntrack, ip, iptables, mount, nsenter відсутні в шляху до команд
  • [Попередження], якщо команди ebtables, ethtool, socat, tc, touch, crictl відсутні в шляху до команд
  • [Попередження], якщо додаткові аргументи для API-сервера, менеджера контролерів, планувальника містять недійсні параметри
  • [Попередження], якщо зʼєднання з https://API.AdvertiseAddress:API.BindPort пройде через проксі
  • [Попередження], якщо зʼєднання з підмережею сервісів пройде через проксі (перевіряється лише перша адреса)
  • [Попередження], якщо зʼєднання з підмережею Podʼів пройде через проксі (перевіряється лише перша адреса)
  • Якщо використовується зовнішній etcd:
    • [Помилка], якщо версія etcd старіша за мінімально необхідну версію
    • [Помилка], якщо сертифікати або ключі etcd вказані, але не надані
  • Якщо використовується внутрішній etcd (і, таким чином, буде встановлений локальний etcd):
    • [Помилка], якщо використовується порт 2379
    • [Помилка], якщо тека Etcd.DataDir вже існує і не є порожньою
  • Якщо режим авторизації — ABAC:
    • [Помилка], якщо abac_policy.json не існує
  • Якщо режим авторизації — WebHook:
    • [Помилка], якщо webhook_authz.conf не існує

Генерація необхідних сертифікатів

Kubeadm генерує пари сертифікатів і приватних ключів для різних цілей:

  • Самопідписаний центр сертифікації для кластера Kubernetes, збережений у файлі ca.crt і приватний ключ у файлі ca.key

  • Сертифікат обслуговування для API-сервера, згенерований за допомогою ca.crt як CA, збережений у файлі apiserver.crt разом із приватним ключем apiserver.key. Цей сертифікат повинен містити наступні альтернативні імена:

    • Внутрішній clusterIP сервісу Kubernetes (перша адреса в CIDR служб, наприклад, 10.96.0.1, якщо підмережа сервісів — 10.96.0.0/12)
    • DNS-імена Kubernetes, наприклад kubernetes.default.svc.cluster.local, якщо значення прапорця --service-dns-domain є cluster.local, а також типові DNS-імена kubernetes.default.svc, kubernetes.default, kubernetes
    • Імʼя вузла (node-name)
    • --apiserver-advertise-address
    • Додаткові альтернативні імена, вказані користувачем
  • Клієнтський сертифікат для API-сервера для безпечного підключення до kubelet-ів, згенерований за допомогою ca.crt як CA і збережений у файлі apiserver-kubelet-client.crt разом із його приватним ключем apiserver-kubelet-client.key. Цей сертифікат повинен бути в організації system:masters

  • Приватний ключ для підпису токенів ServiceAccount, збережений у файлі sa.key разом із його публічним ключем sa.pub

  • Центр сертифікації для front proxy, збережений у файлі front-proxy-ca.crt разом із його ключем front-proxy-ca.key

  • Клієнтський сертифікат для клієнта front proxy, згенерований за допомогою front-proxy-ca.crt як CA і збережений у файлі front-proxy-client.crt разом із його приватним ключем front-proxy-client.key

Сертифікати зберігаються типово у /etc/kubernetes/pki, але цю теку можна налаштувати за допомогою прапорця --cert-dir.

Зверніть увагу на наступне:

  1. Якщо дані пари сертифікат-приватний ключ вже існують і їх зміст відповідає вищезазначеним вимогам, вони будуть використані, і фаза генерації для даного сертифіката буде пропущена. Це означає, що користувач може, наприклад, скопіювати поточний CA в /etc/kubernetes/pki/ca.{crt,key}, і після цього kubeadm використовуватиме ці файли для підпису інших сертифікатів. Див. також використання власних сертифікатів
  2. Для CA можливо надати файл ca.crt, але не надавати файл ca.key. Якщо всі інші сертифікати і файли kubeconfig вже на місці, kubeadm визнає цю умову і активує ExternalCA, що також означає, що контролер csrsigner в контролері-менеджері не буде запущений
  3. Якщо kubeadm працює в режимі зовнішньої CA; всі сертифікати повинні бути надані користувачем, оскільки kubeadm не може їх генерувати самостійно
  4. У випадку запуску kubeadm у режимі --dry-run, файли сертифікатів записуються в тимчасову теку
  5. Генерацію сертифікатів можна викликати окремо за допомогою команди kubeadm init phase certs all

It seems like you're referring to documentation or a detailed guide on how kubeadm handles various aspects of Kubernetes initialization and configuration. If you need a translation of this content into Ukrainian, I can provide that. Here's the translation:

Генерація kubeconfig файлів для компонентів панелі управління

Kubeadm генерує kubeconfig файли з ідентичностями для компонентів панелі управління:

  • Файл kubeconfig для kubelet, який використовується під час ініціалізації TLS — /etc/kubernetes/bootstrap-kubelet.conf. У цьому файлі є bootstrap-token або вбудовані клієнтські сертифікати для автентифікації цього вузла у кластері.

    Цей клієнтський сертифікат повинен:

    • Бути в організації system:nodes, як вимагається модулем Node Authorization
    • Мати Загальне Імʼя (CN) system:node:<hostname-lowercased>
  • Файл kubeconfig для контролера-менеджера, /etc/kubernetes/controller-manager.conf; у цьому файлі вбудований клієнтський сертифікат з ідентичністю контролера-менеджера. Цей клієнтський сертифікат повинен мати CN system:kube-controller-manager, як визначено стандартними RBAC ролями ядра компонентів

  • Файл kubeconfig для планувальника, /etc/kubernetes/scheduler.conf; у цьому файлі вбудований клієнтський сертифікат з ідентичністю планувальника. Цей клієнтський сертифікат повинен мати CN system:kube-scheduler, як визначено стандартними RBAC ролями ядра компонентів

Додатково, kubeconfig файл для kubeadm як адміністративної сутності генерується і зберігається у /etc/kubernetes/admin.conf. Цей файл включає сертифікат з Subject: O = kubeadm:cluster-admins, CN = kubernetes-admin. kubeadm:cluster-admins — це група, керована kubeadm. Вона повʼязана з cluster-admin ClusterRole під час kubeadm init, за допомогою super-admin.conf файлу, який не потребує RBAC. Файл admin.conf повинен залишатися на вузлах панелі управління і не повинен бути переданий іншим користувачам.

Під час kubeadm init генерується інший kubeconfig файл і зберігається у /etc/kubernetes/super-admin.conf. Цей файл включає сертифікат з Subject: O = system:masters, CN = kubernetes-super-admin. system:masters — це суперкористувачі, які обходять RBAC і роблять super-admin.conf корисним у випадку надзвичайної ситуації, коли кластер заблокований через неправильну конфігурацію RBAC. Файл super-admin.conf повинен зберігатися в безпечному місці і не повинен передаватися іншим користувачам.

Дивіться RBAC user facing role bindings для додаткової інформації про RBAC і вбудовані ClusterRoles та групи.

Зверніть увагу на наступне:

  1. Всі kubeconfig файли включають в себе сертифікат ca.crt.
  2. Якщо вказаний kubeconfig файл вже існує і його зміст відповідає вищезазначеним вимогам, то буде використано існуючий файл, і фаза генерації для даного kubeconfig буде пропущена.
  3. Якщо kubeadm працює в режимі ExternalCA mode, всі необхідні kubeconfig файли також повинні бути надані користувачем, оскільки kubeadm не може згенерувати їх самостійно.
  4. У випадку виконання kubeadm в режимі --dry-run, файли kubeconfig записуються в тимчасову теку.
  5. Генерацію kubeconfig файлів можна викликати окремо за допомогою команди kubeadm init phase kubeconfig all

Генерація маніфестів статичних Pod для компонентів панелі управління

Kubeadm записує файли маніфестів статичних Pod для компонентів панелі управління до /etc/kubernetes/manifests. kubelet спостерігає за цією текою для створення Podʼів при запуску.

Маніфести статичних Podʼів мають спільний набір властивостей:

  • Всі статичні Podʼи розгорнуті в просторі імен kube-system

  • Всі статичні Podʼи мають мітки tier:control-plane та component:{імʼя-компоненти}

  • Всі статичні Podʼи використовують клас пріоритету system-node-critical

  • На всіх статичних Podʼах встановлено hostNetwork: true, щоб дозволити запуск панелі управління до налаштування мережі; в результаті:

    • Адреса, яку використовує контролер-менеджер та планувальник для посилання на API-сервер, є 127.0.0.1
    • Якщо сервер etcd налаштовано локально, адреса etcd-server буде встановлена як 127.0.0.1:2379
  • Включено обрання лідера як для контролер-менеджера, так і для планувальника

  • Контролер-менеджер та планувальник будуть посилатися на файли kubeconfig з їхніми відповідними, унікальними ідентифікаторами

  • Всі статичні Podʼи отримують будь-які додаткові прапорці, вказані користувачем, як описано в передача користувацьких аргументів компонентам панелі управління

  • Всі статичні Podʼи отримують будь-які додаткові томи, вказані користувачем (Шлях хоста)

Зверніть увагу, що:

  1. Усі образи типово будуть витягуватися з registry.k8s.io. Для налаштування репозиторію образів див. використання власних образів
  2. У разі виконання kubeadm у режимі --dry-run файли статичних Podʼів записуються у тимчасову теку
  3. Генерацію маніфестів статичних Podʼів для компонентів панелі управління можна запустити окремо за допомогою команди kubeadm init phase control-plane all

Сервер API

Маніфест статичних Podʼів для сервера API обробляється наступними параметрами, наданими користувачами:

  • apiserver-advertise-address та apiserver-bind-port для звʼязку; якщо вони не вказані, стандартне значення буде IP-адреса основного мережевого інтерфейсу на машині та порт 6443
  • service-cluster-ip-range для використання сервісів
  • Якщо вказаний зовнішній сервер etcd, то etcd-servers та повʼязані налаштування TLS (etcd-cafile, etcd-certfile, etcd-keyfile); якщо зовнішній сервер etcd не вказано, буде використовуватися локальний etcd (через мережу хосту)
  • Якщо вказаний провайдер хмарних послуг, то налаштовується відповідний параметр --cloud-provider разом зі шляхом --cloud-config, якщо такий файл існує (експериментально, альфа версія, буде вилучено в майбутній версії)

Інші прапорці сервера API, що встановлені безумовно, включають:

  • --insecure-port=0 для уникнення небезпечних зʼєднань з сервером API

  • --enable-bootstrap-token-auth=true для активації модуля автентифікації BootstrapTokenAuthenticator. Див. TLS Bootstrapping для деталей

  • --allow-privileged до true (необхідно, наприклад, для kube-proxy)

  • --requestheader-client-ca-file до front-proxy-ca.crt

  • --enable-admission-plugins до:

    • NamespaceLifecycle наприклад, для уникнення видалення системних зарезервованих просторів імен
    • LimitRanger та ResourceQuota для встановлення обмежень на простори імен
    • ServiceAccount для автоматизації службових облікових записів
    • PersistentVolumeLabel приєднує мітки регіону або зони до PersistentVolumes, як визначено провайдером хмарних послуг (Цей контролер допуску є застарілим і буде вилучений у майбутній версії. Він типово не розгорнутий kubeadm починаючи з v1.9, якщо явно не вибрано використання gce або aws як провайдерів хмарних послуг)
    • DefaultStorageClass для встановлення типового класу зберігання на обʼєктах PersistentVolumeClaim
    • DefaultTolerationSeconds
    • NodeRestriction для обмеження того, що kubelet може змінювати (наприклад, тільки Podʼи на цьому вузлі)
  • --kubelet-preferred-address-types до InternalIP,ExternalIP,Hostname; це робить kubectl logs та іншу комунікацію API server-kubelet працюючою в середовищах, де імена хостів вузлів не розвʼязуються

  • Прапорці для використання сертифікатів, згенерованих на попередніх етапах:

    • --client-ca-file до ca.crt
    • --tls-cert-file до apiserver.crt
    • --tls-private-key-file до apiserver.key
    • --kubelet-client-certificate до apiserver-kubelet-client.crt
    • --kubelet-client-key до apiserver-kubelet-client.key
    • --service-account-key-file до sa.pub
    • --requestheader-client-ca-file до front-proxy-ca.crt
    • --proxy-client-cert-file до front-proxy-client.crt
    • --proxy-client-key-file до front-proxy-client.key
  • Інші прапорці для забезпечення безпеки front proxy (Агрегація API) комунікацій:

    • --requestheader-username-headers=X-Remote-User
    • --requestheader-group-headers=X-Remote-Group
    • --requestheader-extra-headers-prefix=X-Remote-Extra-
    • --requestheader-allowed-names=front-proxy-client

Менеджер контролерів

Маніфест статичного Podʼа для менеджера контролерів обробляється наступними параметрами, наданими користувачами:

  • Якщо kubeadm запускається з вказанням --pod-network-cidr, активується функція менеджера підмережі, необхідна для деяких мережевих втулків CNI, встановлюючи:

    • --allocate-node-cidrs=true
    • Прапорці --cluster-cidr та --node-cidr-mask-size відповідно до заданого CIDR
  • Якщо вказаний провайдер хмарних послуг, то відповідно налаштовується --cloud-provider, разом зі шляхом --cloud-config, якщо такий файл конфігурації існує (експериментально, альфа версія, буде вилучено в майбутній версії)

Інші прапорці, які встановлюються безумовно, включають:

  • --controllers, що активує всі стандартні контролери плюс контролери BootstrapSigner та TokenCleaner для TLS-запуску. Див. TLS Bootstrapping для деталей.

  • --use-service-account-credentials до true

  • Прапорці для використання сертифікатів, згенерованих на попередніх етапах:

    • --root-ca-file до ca.crt
    • --cluster-signing-cert-file до ca.crt, якщо відключений зовнішній режим CA, в іншому випадку до ""
    • --cluster-signing-key-file до ca.key, якщо відключений зовнішній режим CA, в іншому випадку до ""
    • --service-account-private-key-file до sa.key.

Планувальник

Маніфест статичного Podʼа для планувальника обробляється наступними параметрами, наданими користувачами.

Генерація маніфесту статичного Pod для локального etcd

Якщо ви вказали зовнішній etcd, цей крок буде пропущено. В іншому випадку kubeadm генерує маніфест статичного Pod для створення локального екземпляра etcd, що працює в Pod з наступними характеристиками:

  • слухати на localhost:2379 і використовувати HostNetwork=true
  • зробити монтування hostPath з dataDir до файлової системи хосту
  • Будь-які додаткові прапорці, вказані користувачем

Зверніть увагу, що:

  1. Образ контейнера etcd буде типово витягнутий з registry.gcr.io. Для налаштування власного репозиторію образів див. використання власних образів.
  2. Якщо ви запускаєте kubeadm у режимі --dry-run, маніфест статичного Pod для etcd записується у тимчасову теку.
  3. Ви можете безпосередньо викликати генерацію маніфесту статичного Pod для локального etcd за допомогою команди kubeadm init phase etcd local.

Очікування запуску панелі управління

kubeadm очікує (до 4 хвилин) на відповідь ok від localhost:6443/healthz (життєздатність kube-apiserver). Однак, для виявлення умов блокування, kubeadm швидко видає помилку, якщо localhost:10255/healthz (життєздатність kubelet) або localhost:10255/healthz/syncloop (готовність kubelet) не повертають ok в межах відповідно 40 та 60 секунд.

kubeadm покладається на kubelet для завантаження образів панелі управління і їх коректного запуску як статичних Podʼів. Після того як панель управління буде запущена, kubeadm завершує виконання завдань, описаних у наступних розділах.

Збереження конфігурації кластера kubeadm у ConfigMap для подальшого посилання

kubeadm зберігає конфігурацію, передану в kubeadm init, у ConfigMap з назвою kubeadm-config в просторі імен kube-system.

Це забезпечить можливість kubeadm у майбутньому (наприклад, під час оновлення kubeadm upgrade) визначати фактичний поточний стан кластера і приймати нові рішення на основі цих даних.

Зверніть увагу, що:

  1. Перед збереженням конфігурації кластера чутлива інформація, така як токен, видаляється з конфігурації.
  2. Завантаження конфігурації вузла панелі управління може бути викликане окремо за допомогою команди kubeadm init phase upload-config.

Позначення вузла як вузла панелі управління

Як тільки панель управління буде доступна, kubeadm виконує наступні дії:

  • Позначає вузол як вузол панелі управління з міткою node-role.kubernetes.io/control-plane=""
  • Додає на вузол taint node-role.kubernetes.io/control-plane:NoSchedule

Зверніть увагу, що фазу позначення вузла як вузла панелі управління можна викликати окремо за допомогою команди kubeadm init phase mark-control-plane.

Налаштування TLS-Bootstrapping для приєднання вузлів

Kubeadm використовує Автентифікацію за допомогою Запускових Токенів для приєднання нових вузлів до існуючого кластера; для отримання більш детальної інформації дивіться також пропозицію дизайну.

kubeadm init забезпечує належну конфігурацію всього процесу, включаючи наступні кроки, а також налаштування прапорців API-сервера та контролера, як вже було описано у попередніх розділах.

Створення bootstrap токена

kubeadm init створює перший bootstrap токен, що генерується автоматично або надається користувачем за допомогою прапорця --token. Згідно з документацією щодо специфікації bootstrap токена, токен слід зберегти як секрет з іменем bootstrap-token-<token-id> у просторі імен kube-system.

Зверніть увагу, що:

  1. bootstrap токен, типово створений kubeadm init, використовуватиметься для перевірки тимчасових користувачів під час процесу TLS-запуску; ці користувачі будуть членами групи system:bootstrappers:kubeadm:default-node-token.
  2. Токен має обмежену чинність, стандартно 24 години (цей інтервал можна змінити за допомогою прапорця --token-ttl).
  3. Додаткові токени можна створити за допомогою команди kubeadm token, яка також надає інші корисні функції для управління токенами.

Дозвіл на виклик API CSR вузлами, які приєднуються

Kubeadm забезпечує можливість користувачам у групі system:bootstrappers:kubeadm:default-node-token доступ до API підпису сертифікатів.

Це реалізується створенням ClusterRoleBinding з назвою kubeadm:kubelet-bootstrap між вищезазначеною групою та рольовим доступом RBAC стандартно system:node-bootstrapper.

Налаштування автоматичного схвалення нових bootstrap токенів

Kubeadm забезпечує автоматичне схвалення запитів на підпис сертифікату Bootstrap Token за допомогою контролера csrapprover.

Це реалізується створенням ClusterRoleBinding з назвою kubeadm:node-autoapprove-bootstrap між групою system:bootstrappers:kubeadm:default-node-token та стандартним рольовим доступом system:certificates.k8s.io:certificatesigningrequests:nodeclient.

Роль system:certificates.k8s.io:certificatesigningrequests:nodeclient також має бути створена, надаючи дозвіл POST на шлях /apis/certificates.k8s.io/certificatesigningrequests/nodeclient.

Налаштування ротації сертифікатів вузлів з автоматичним схваленням

Kubeadm забезпечує активацію ротації сертифікатів для вузлів і автоматичне схвалення запитів на підпис сертифікатів для вузлів за допомогою контролера csrapprover.

Це реалізується створенням ClusterRoleBinding з назвою kubeadm:node-autoapprove-certificate-rotation між групою system:nodes та стандартним рольовим доступом system:certificates.k8s.io:certificatesigningrequests:selfnodeclient.

Створення публічного ConfigMap cluster-info

У цій фазі створюється ConfigMap cluster-info у просторі імен kube-public.

Додатково створюється Role та RoleBinding, які надають доступ до ConfigMap неавтентифікованим користувачам (тобто користувачам у RBAC групі system:unauthenticated).

Встановлення надбудов

Kubeadm встановлює внутрішній DNS-сервер і компоненти надбудов kube-proxy через API-сервер.

proxy

Для kube-proxy створюється обліковий запис ServiceAccount у просторі імен kube-system, після чого kube-proxy розгортається як DaemonSet:

  • Облікові дані (ca.crt та token) до панелі управління отримуються з облікового запису ServiceAccount.
  • Місцезнаходження (URL) API-сервера отримується з ConfigMap.
  • Обліковий запис ServiceAccount kube-proxy повʼязується з правами у рольовому доступі ClusterRole system:node-proxier.

DNS

  • Сервіс CoreDNS називається kube-dns. Це зроблено для запобігання будь-яких перерв у роботі, коли користувач переключає DNS кластера з kube-dns на CoreDNS за допомогою методу --config, описаного тут.

  • У просторі імен kube-system створюється обліковий запис ServiceAccount для CoreDNS.

  • Обліковий запис coredns привʼязаний до привілеїв у ClusterRole system:coredns.

У версії Kubernetes 1.21 була видалена підтримка використання kube-dns з kubeadm. Ви можете використовувати CoreDNS з kubeadm, навіть якщо повʼязаний сервіс називається kube-dns.

Внутрішній дизайн фаз kubeadm join

Подібно до kubeadm init, внутрішній робочий процес kubeadm join також складається з послідовності атомарних завдань, що виконуються.

Вони поділені на дві частини: виявлення (щоб вузол довіряв Kubernetes Master) та початкове завантаження TLS (щоб Kubernetes Master довіряв вузлу).

Дивіться Автентифікація за допомогою Bootstrap Tokens або відповідну пропозицію дизайну.

Попередні перевірки

kubeadm виконує набір попередніх перевірок перед початком приєднання, з метою перевірити попередні умови та уникнути поширених проблем запуску кластера.

Зверніть увагу на наступне:

  1. Попередні перевірки kubeadm join є, по суті, підмножиною попередніх перевірок kubeadm init.
  2. Починаючи з версії 1.24, kubeadm використовує crictl для спілкування з усіма відомими CRI точками доступу.
  3. Починаючи з версії 1.9, kubeadm забезпечує підтримку приєднання вузлів, що працюють на Windows; у такому разі пропускаються специфічні для Linux перевірки.
  4. У будь-якому випадку користувач може пропустити певні попередні перевірки (або, врешті-решт, усі попередні перевірки) за допомогою опції --ignore-preflight-errors.

Виявлення інформації про кластер

Є дві основні схеми для виявлення. Перша полягає у використанні спільного токена разом з IP-адресою сервера API. Друга — наданні файлу (який є підмножиною стандартного файлу kubeconfig).

Виявлення спільного токена

Якщо kubeadm join викликається з параметром --discovery-token, використовується виявлення за допомогою токена; у цьому випадку вузол основному отримує сертифікати CA кластера з ConfigMap cluster-info у просторі імен kube-public.

Щоб запобігти атакам типу "особа посередині", вживаються кілька заходів:

  • Спочатку сертифікат CA отримується через небезпечне зʼєднання (це можливо, тому що kubeadm init надає доступ користувачам cluster-info для system:unauthenticated)

  • Потім сертифікат CA проходить наступні кроки перевірки:

    • Базова перевірка: використовуючи ID токена через підпис JWT
    • Перевірка публічного ключа: використовуючи наданий --discovery-token-ca-cert-hash. Це значення доступне у виводі kubeadm init або може бути обчислене за допомогою стандартних інструментів (хеш обчислюється над байтами обʼєкта Subject Public Key Info (SPKI) відповідно до RFC7469). Прапор --discovery-token-ca-cert-hash може бути повторений кілька разів, щоб дозволити більше одного публічного ключа.
    • Як додаткова перевірка, сертифікат CA отримується через безпечне зʼєднання і порівнюється з сертифікатом CA, отриманим спочатку

Виявлення файлу/HTTPS

Якщо kubeadm join викликається з параметром --discovery-file, використовується виявлення за допомогою файлу; цей файл може бути локальним файлом або завантаженим через HTTPS URL; у випадку HTTPS, використовується встановлений на хості пакет сертифікатів CA для перевірки зʼєднання.

При виявленні файлу сертифікат CA кластера надається у самому файлі; фактично, файл для виявлення є файлом kubeconfig з встановленими тільки атрибутами server і certificate-authority-data, як описано у референс-документації kubeadm join; коли зʼєднання з кластером встановлено, kubeadm намагається отримати доступ до ConfigMap cluster-info, і якщо він доступний, використовує його.

TLS Bootstrap

Після того, як інформація про кластер відома, записується файл bootstrap-kubelet.conf, що дозволяє kubelet виконати початкове завантаження TLS.

Механізм початкового завантаження TLS використовує спільний токен для тимчасової автентифікації з сервером API Kubernetes для подання запиту на підписання сертифіката (CSR) для локально створеної пари ключів.

Запит автоматично затверджується, і операція завершується збереженням файлів ca.crt і kubelet.conf, які використовуються kubelet для приєднання до кластера, тоді як bootstrap-kubelet.conf видаляється.

6.11 - Інструмент командного рядка (kubectl)

Kubernetes надає інструмент командного рядка для взаємодії із кластером Kubernetes, панеллю управління, використовуючи API Kubernetes.

Цей інструмент має назву kubectl.

Для отримання налаштувань kubectl шукає файл config в теці $HOME/.kube. Ви можете вказати інший файл kubeconfig у змінній оточення KUBECONFIG або у значенні ключа --kubeconfig.

Тут ми розглянемо синтаксис команд kubectl, опис операторів та розберемо їх на прикладах. Докладніше про кожну команду, включаючи всі підтримувані прапорці та субкоманди, див. довідкову документацію kubectl.

Інструкції з встановлення знаходяться у статті Встановлення kubectl; короткий посібник є у шпаргалці. Якщо ви звикли користуватись інструментом командного рядка docker, kubectl для користувачів Docker пояснює деякі еквівалентні команди для Kubernetes.

Синтаксис

Використовуйте наступний синтаксис для виконання команд kubectl у вашому терміналі:

kubectl [команда] [ТИП] [ІМʼЯ] [прапорці]

де команда, ТИП, ІМʼЯ та прапорці визначаються наступним чином:

  • команда: Вказує операцію, яку ви хочете виконати з одним чи кількома ресурсами, наприклад create, get, describe, delete.

  • ТИП: Вказує тип ресурсу. Типи ресурсів нечутливі до регістру, і можна вказувати форми однини, множини чи абревіатури. Наприклад, наступні команди виводять той самий результат:

    kubectl get pod pod1
    kubectl get pods pod1
    kubectl get po pod1
    
  • ІМʼЯ: Вказує імʼя ресурсу. Імена чутливі до регістру. Якщо імʼя відсутнє, виводяться деталі для всіх ресурсів, наприклад kubectl get pods.

    При виконанні операції над кількома ресурсами можна вказати кожен ресурс за типом та іменем або вказати один чи кілька файлів:

    • Щоб вказати ресурси за типом та іменем:

      • Щоб групувати ресурси, якщо всі вони одного типу: ТИП1 імʼя1 імʼя2 імʼя<#>.
        Приклад: kubectl get pod example-pod1 example-pod2.

      • Щоб вказати кілька типів ресурсів окремо: ТИП1/імʼя1 ТИП1/імʼя2 ТИП2/імʼя3 ТИП<#>/імʼя<#>.
        Приклад: kubectl get pod/example-pod1 replicationcontroller/example-rc1.

    • Щоб вказати ресурси за допомогою одного чи кількох файлів: -f файл1 -f файл2 -f файл<#>.

  • прапорці: Є необовʼязковими. Наприклад, ви можете використовувати прапорці -s або --server, щоб вказати адресу та порт сервера API Kubernetes.

Якщо вам потрібна допомога, виконайте команду kubectl help у вікні термінала.

Автентифікація та перевизначення простору імен в кластері

Типово kubectl спочатку визначатиме, чи він виконується в середині Podʼа, і отже, в кластері. Програма починає з перевірки наявності змінних середовища KUBERNETES_SERVICE_HOST та KUBERNETES_SERVICE_PORT, а також наявності файлу токена службового облікового запису за шляхом /var/run/secrets/kubernetes.io/serviceaccount/token. Якщо всі три умови виконуються, вважається, що використовується автентифікація в кластері.

Для забезпечення зворотної сумісності, якщо під час автентифікації в кластері встановлено змінну середовища POD_NAMESPACE, вона перевизначить типовий простір імен скориставшись токеном службового облікового запису. Це буде впливати на будь-які маніфести або інструменти, які покладаються на типовий простір імен.

Змінна середовища POD_NAMESPACE

Якщо змінна середовища POD_NAMESPACE встановлена, операції CLI для ресурсів з обмеженим простором імен будуть отримувати типове значення від цієї змінної. Наприклад, якщо значення змінної — seattle, kubectl get pods поверне Podʼи з простору імен seattle. Це тому, що Podʼи є ресурсом обмеженим простором імен, і ми не вказали команді простір імен в командному рядку. Ознайомтесь з виводом kubectl api-resources, щоб визначити, чи ресурс обмежений простіром імен чи ні.

Явне використання --namespace <value> перевизначає цю поведінку.

Як kubectl обробляє токени ServiceAccount

Якщо:

  • маємо файл токена службового облікового запису Kubernetes, змонтований за шляхом /var/run/secrets/kubernetes.io/serviceaccount/token, і
  • встановлено змінну середовища KUBERNETES_SERVICE_HOST, і
  • встановлено змінну середовища KUBERNETES_SERVICE_PORT, і
  • ви не вказуєте простір імен явно в командному рядку kubectl

тоді kubectl вважатиме, що він працює у вашому кластері. Інструмент kubectl знаходить простір імен цього службового облікового запису (це такий самий простір імен, що й у Podʼа) та діє відповідно до цього простору імен. Це відрізняється від того, що відбувається поза кластером; коли kubectl працює за межами кластера і ви не вказуєте простір імен, команда kubectl діє в просторі імен, встановленому для поточного контексту у вашій конфігурації клієнта. Щоб змінити типовий простір імен для kubectl, ви можете використовувати наступну команду:

kubectl config set-context --current --namespace=<namespace-name>

Операції

Наступна таблиця містить короткі описи та загальний синтаксис для всіх операцій kubectl:

ОпераціяСинтаксисОпис
alphakubectl alpha SUBCOMMAND [flags]Вивести список доступних команд, які відповідають альфа-функціям, які зазвичай не є активованими у кластерах Kubernetes.
annotatekubectl annotate (-f FILENAME | TYPE NAME | TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags]Додати або оновити анотації одного чи кількох ресурсів.
api-resourceskubectl api-resources [flags]Вивести список доступних ресурсів API.
api-versionskubectl api-versions [flags]Вивести список доступних версій API.
applykubectl apply -f FILENAME [flags]Застосувати зміну конфігурації до ресурсу з файлу або stdin.
attachkubectl attach POD -c CONTAINER [-i] [-t] [flags]Приєднатися до запущеного контейнера для перегляду виводу або взаємодії з контейнером (stdin).
authkubectl auth [flags] [options]Перегляд авторизації.
autoscalekubectl autoscale (-f FILENAME | TYPE NAME | TYPE/NAME) [--min=MINPODS] --max=MAXPODS [--cpu-percent=CPU] [flags]Автоматично масштабувати набір Podʼів, керованих контролером реплікації.
certificatekubectl certificate SUBCOMMAND [options]Змінити ресурси сертифікатів.
cluster-infokubectl cluster-info [flags]Показати інформацію про точки доступу майстра та сервісів в кластері.
completionkubectl completion SHELL [options]Вивести код функції автозавершення оболонки для bash або zsh.
configkubectl config SUBCOMMAND [flags]Змінити файли kubeconfig. Див. окремі команди для отримання деталей.
convertkubectl convert -f FILENAME [options]Конвертувати файли конфігурації між різними версіями API. Приймаються формати YAML та JSON. Примітка — потрібно встановити втулок kubectl-convert.
cordonkubectl cordon NODE [options]Позначити вузол як недоступний для планування.
cpkubectl cp <file-spec-src> <file-spec-dest> [options]Копіювати файли та теки в та з контейнерів.
createkubectl create -f FILENAME [flags]Створити один чи кілька ресурсів з файлу або stdin.
deletekubectl delete (-f FILENAME | TYPE [NAME | /NAME | -l label | --all]) [flags]Видалити ресурси з файлу, stdin або вказати селектори міток, імена, селектори ресурсів або ресурси.
describekubectl describe (-f FILENAME | TYPE [NAME_PREFIX | /NAME | -l label]) [flags]Показати докладний стан одного чи кількох ресурсів.
diffkubectl diff -f FILENAME [flags]Показати розбіжності між файлом або stdin від робочої конфігурації.
drainkubectl drain NODE [options]Звільнити вузол від ресурсів для підготовки його до обслуговування.
editkubectl edit (-f FILENAME | TYPE NAME | TYPE/NAME) [flags]Редагувати та оновити визначення одного чи кількох ресурсів на сервері за допомогою типового редактора.
eventskubectl eventsВивести список подій.
execkubectl exec POD [-c CONTAINER] [-i] [-t] [flags] [-- COMMAND [args...]]Виконати команду в контейнері у Podʼі.
explainkubectl explain TYPE [--recursive=false] [flags]Отримати документацію про різні ресурси, такі як Podʼи, вузли, сервіси і т. д.
exposekubectl expose (-f FILENAME | TYPE NAME | TYPE/NAME) [--port=port] [--protocol=TCP|UDP] [--target-port=number-or-name] [--name=name] [--external-ip=external-ip-of-service] [--type=type] [flags]Надати доступ ззовні до контролера реплікації, Service або Pod, як до нового Service Kubernetes.
getkubectl get (-f FILENAME | TYPE [NAME | /NAME | -l label]) [--watch] [--sort-by=FIELD] [[-o | --output]=OUTPUT_FORMAT] [flags]Вивести список ресурсів.
kustomizekubectl kustomize <dir> [flags] [options]Вивести список ресурсів API, згенерованих з інструкцій у файлі kustomization.yaml. Аргумент повинен бути шляхом до теки, що містить файл, або URL репозиторію git з суфіксом шляху, який вказує на те ж саме відносно кореня репозиторію.
labelkubectl label (-f FILENAME | TYPE NAME | TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags]Додати або оновити мітки одного чи кількох ресурсів.
logskubectl logs POD [-c CONTAINER] [--follow] [flags]Вивести логи контейнера у Podʼі.
optionskubectl optionsСписок глобальних параметрів командного рядка, які застосовуються до всіх команд.
patchkubectl patch (-f FILENAME | TYPE NAME | TYPE/NAME) --patch PATCH [flags]Оновити одне чи кілька полів ресурсу за допомогою процесу стратегії обʼєднання патчів.
pluginkubectl plugin [flags] [options]Надає інструменти для взаємодії з втулками.
port-forwardkubectl port-forward POD [LOCAL_PORT:]REMOTE_PORT [...[LOCAL_PORT_N:]REMOTE_PORT_N] [flags]Переспрямувати один або декілька локальних портів у Pod.
proxykubectl proxy [--port=PORT] [--www=static-dir] [--www-prefix=prefix] [--api-prefix=prefix] [flags]Запустити проксі до сервера API Kubernetes.
replacekubectl replace -f FILENAMEЗамінити ресурс з файлу або stdin.
rolloutkubectl rollout SUBCOMMAND [options]Керувати розгортанням ресурсу. Дійсні типи ресурсів: Deployment, DaemonSet та StatefulSet.
runkubectl run NAME --image=image [--env="key=value"] [--port=port] [--dry-run=server|client|none] [--overrides=inline-json] [flags]Запустити вказаний образ у кластері.
scalekubectl scale (-f FILENAME | TYPE NAME | TYPE/NAME) --replicas=COUNT [--resource-version=version] [--current-replicas=count] [flags]Оновити розмір вказаного контролера реплікації.
setkubectl set SUBCOMMAND [options]Налаштувати ресурси застосунку.
taintkubectl taint NODE NAME KEY_1=VAL_1:TAINT_EFFECT_1 ... KEY_N=VAL_N:TAINT_EFFECT_N [options]Оновити taint на одному чи декількох вузлах.
topkubectl top (POD | NODE) [flags] [options]Показати використання ресурсів (CPU/Memory/Storage) для Podʼа чи вузла.
uncordonkubectl uncordon NODE [options]Позначити вузол як доступний для планування.
versionkubectl version [--client] [flags]Показати версію Kubernetes, яка працює на клієнті та сервері.
waitkubectl wait ([-f FILENAME] | resource.group/resource.name | resource.group [(-l label | --all)]) [--for=delete|--for condition=available] [options]Експериментально: чекати на певний стан одного чи кількох ресурсів.

Щоб дізнатися більше про операції, що виконують команди, див. довідку kubectl.

Типи ресурсів

У наступній таблиці наведено список всіх підтримуваних типів ресурсів та їх скорочених аліасів.

(Цей вивід можна отримати за допомогою kubectl api-resources, він був актуальним на момент Kubernetes 1.25.0)

ІМʼЯСКОРОЧЕННЯВЕРСІЯ APIПРОСТІР ІМЕНТИП
bindingsv1trueBinding
componentstatusescsv1falseComponentStatus
configmapscmv1trueConfigMap
endpointsepv1trueEndpoints
eventsevv1trueEvent
limitrangeslimitsv1trueLimitRange
namespacesnsv1falseNamespace
nodesnov1falseNode
persistentvolumeclaimspvcv1truePersistentVolumeClaim
persistentvolumespvv1falsePersistentVolume
podspov1truePod
podtemplatesv1truePodTemplate
replicationcontrollersrcv1trueReplicationController
resourcequotasquotav1trueResourceQuota
secretsv1trueSecret
serviceaccountssav1trueServiceAccount
servicessvcv1trueService
mutatingwebhookconfigurationsadmissionregistration.k8s.io/v1falseMutatingWebhookConfiguration
validatingwebhookconfigurationsadmissionregistration.k8s.io/v1falseValidatingWebhookConfiguration
customresourcedefinitionscrd,crdsapiextensions.k8s.io/v1falseCustomResourceDefinition
apiservicesapiregistration.k8s.io/v1falseAPIService
controllerrevisionsapps/v1trueControllerRevision
daemonsetsdsapps/v1trueDaemonSet
deploymentsdeployapps/v1trueDeployment
replicasetsrsapps/v1trueReplicaSet
statefulsetsstsapps/v1trueStatefulSet
tokenreviewsauthentication.k8s.io/v1falseTokenReview
localsubjectaccessreviewsauthorization.k8s.io/v1trueLocalSubjectAccessReview
selfsubjectaccessreviewsauthorization.k8s.io/v1falseSelfSubjectAccessReview
selfsubjectrulesreviewsauthorization.k8s.io/v1falseSelfSubjectRulesReview
subjectaccessreviewsauthorization.k8s.io/v1falseSubjectAccessReview
horizontalpodautoscalershpaautoscaling/v2trueHorizontalPodAutoscaler
cronjobscjbatch/v1trueCronJob
jobsbatch/v1trueJob
certificatesigningrequestscsrcertificates.k8s.io/v1falseCertificateSigningRequest
leasescoordination.k8s.io/v1trueLease
endpointslicesdiscovery.k8s.io/v1trueEndpointSlice
eventsevevents.k8s.io/v1trueEvent
flowschemasflowcontrol.apiserver.k8s.io/v1beta2falseFlowSchema
prioritylevelconfigurationsflowcontrol.apiserver.k8s.io/v1beta2falsePriorityLevelConfiguration
ingressclassesnetworking.k8s.io/v1falseIngressClass
ingressesingnetworking.k8s.io/v1trueIngress
networkpoliciesnetpolnetworking.k8s.io/v1trueNetworkPolicy
runtimeclassesnode.k8s.io/v1falseRuntimeClass
poddisruptionbudgetspdbpolicy/v1truePodDisruptionBudget
podsecuritypoliciespsppolicy/v1beta1falsePodSecurityPolicy
clusterrolebindingsrbac.authorization.k8s.io/v1falseClusterRoleBinding
clusterrolesrbac.authorization.k8s.io/v1falseClusterRole
rolebindingsrbac.authorization.k8s.io/v1trueRoleBinding
rolesrbac.authorization.k8s.io/v1trueRole
priorityclassespcscheduling.k8s.io/v1falsePriorityClass
csidriversstorage.k8s.io/v1falseCSIDriver
csinodesstorage.k8s.io/v1falseCSINode
csistoragecapacitiesstorage.k8s.io/v1trueCSIStorageCapacity
storageclassesscstorage.k8s.io/v1falseStorageClass
volumeattachmentsstorage.k8s.io/v1falseVolumeAttachment

Параметри виводу

Використовуйте наступні розділи для отримання інформації про те, як ви можете форматувати або сортувати вивід деяких команд. Докладні відомості щодо команд, які підтримують різні параметри виводу, див. в документації по kubectl.

Форматування виводу

Стандартний формат виводу для всіх команд kubectl – це читабельний текстовий формат. Щоб вивести деталі у вашому терміналі у певному форматі, ви можете додати параметр -o або --output до підтримуваної команди kubectl.

Синтаксис

kubectl [команда] [ТИП] [ІМʼЯ] -o <формат_виводу>

Залежно від операції kubectl, підтримуються наступні формати виводу:

Формат виводуОпис
-o custom-columns=<специфікація>Вивести таблицю, використовуючи розділений комою список власних стовпців.
-o custom-columns-file=<імʼя_файлу>Вивести таблицю, використовуючи шаблон власних стовпців у файлі <імʼя_файлу>.
-o jsonВивести обʼєкт API у форматі JSON.
-o jsonpath=<шаблон>Вивести поля, визначені в виразі jsonpath.
-o jsonpath-file=<імʼя_файлу>Вивести поля, визначені в виразі jsonpath у файлі <імʼя_файлу>.
-o nameВивести лише імʼя ресурсу і нічого більше.
-o wideВивести у текстовому форматі з будь-якою додатковою інформацією. Для Pod включно з імʼям вузла.
-o yamlВивести обʼєкт API у форматі YAML.
Приклад

Тут наступна команда виводить інформацію про Pod у форматі YAML:

kubectl get pod web-pod-13je7 -o yaml

Нагадування: Дивіться довідку kubectl для отримання деталей щодо підтримуваних форматів виводу для кожної команди.

Власні стовпці

Щоб визначити власні стовпці та виводити лише ті деталі, які вам потрібні у вигляді таблиці, ви можете використовувати опцію custom-columns. Ви можете вибрати визначення спеціальних стовпців під час складення параметрів команди або використовувати файл шаблону: -o custom-columns=<spec> або -o custom-columns-file=<filename>.

Приклади

З використанням параметрів в командному рядку:

kubectl get pods <pod-name> -o custom-columns=NAME:.metadata.name,RSRC:.metadata.resourceVersion

З використанням файлу шаблону template.txt:

kubectl get pods <pod-name> -o custom-columns-file=template.txt

де template.txt містить:

NAME          RSRC
metadata.name metadata.resourceVersion

Результати виводу будуть виглядати як для використання шаблону, так і для параметрів командного рядка, як:

NAME           RSRC
submit-queue   610995

Стовпці на стороні сервера

kubectl підтримує отримання конкретної інформації в стовпці щодо обʼєктів від сервера. Це означає, що для будь-якого заданого ресурсу сервер поверне стовпці та рядки, що стосуються цього ресурсу, для показу його клієнту. Це дозволяє отримати послідовний, зручний для читання вивід для різних клієнтів, які використовуються для одного і того ж кластера, оскільки сервер ізолює деталі виведення.

Ця функція стандартно увімкнена. Щоб вимкнути її, додайте прапорець --server-print=false до команди kubectl get.

Приклади

Щоб вивести інформацію про стан Podʼа, використовуйте команду на зразок наступної:

kubectl get pods <pod-name> --server-print=false

Вивід буде подібний до:

NAME       AGE
pod-name   1m

Сортування списку обʼєктів

Щоб вивести обʼєкти у відсортованому списку у вашому вікні термінала, ви можете додати прапорець --sort-by до команди kubectl. Впорядкуйте ваші обʼєкти, вказавши будь-яке числове чи рядкове поле з прапорцем --sort-by. Для вказання поля використовуйте вираз jsonpath.

Синтаксис

kubectl [команда] [ТИП] [ІМʼЯ] --sort-by=<вираз_jsonpath>
Приклад

Щоб вивести список Podʼів, відсортованих за назвами, зробіть наступне:

kubectl get pods --sort-by=.metadata.name

Приклади: Загальні операції

Використовуйте цей набір прикладів, щоб ознайомитися з тим, як використовувати найпоширеніші операції kubectl:

kubectl apply — Застосувати або оновити ресурс із файлу чи stdin.

# Створити сервіс, використовуючи визначення у файлі example-service.yaml.
kubectl apply -f example-service.yaml

# Створити контролер реплікації, використовуючи визначення у файлі example-controller.yaml.
kubectl apply -f example-controller.yaml

# Створити обʼєкти, які визначені у файлах з розширеннями .yaml, .yml, або .json у теці <directory>.
kubectl apply -f <directory>

kubectl get — Показати відомості про один чи кілька ресурсів.

# Показати всі Podʼі у форматі звичайного тексту.
kubectl get pods

# Показати всі Podʼі у форматі звичайного тексту та додаткову інформацію (наприклад, імʼя вузла).
kubectl get pods -o wide

# Показати контролер реплікації із вказаним імʼям у форматі звичайного тексту. Порада: Ви можете скоротити та замінити тип ресурсу 'replicationcontroller' на скорочену назву 'rc'.
kubectl get replicationcontroller <rc-name>

# Показати всі контролери реплікації та сервіси разом у форматі звичайного тексту.
kubectl get rc,services

# Показати всі daemonsets у форматі звичайного тексту.
kubectl get ds

# Показати всі Podʼи, які працюють на вузлі server01
kubectl get pods --field-selector=spec.nodeName=server01

kubectl describe — Показати детальний стан одного чи кількох ресурсів, включаючи ті, які ще не ініціалізовані.

# Показати деталі вузла із імʼям <node-name>.
kubectl describe nodes <node-name>

# Показати деталі Podʼа із імʼям <pod-name>.
kubectl describe pods/<pod-name>

# Показати деталі всіх Podʼів, які керуються контролером реплікації із вказаним імʼям <rc-name>.
# Памʼятайте: Будь-які Podʼи, які створює контролер реплікації, отримують префікс із імʼям контролера реплікації.
kubectl describe pods <rc-name>

# Показати всі Podʼи
kubectl describe pods

kubectl delete — Видалити ресурси або з використанням файлу, або з stdin, або вказавши селектори міток, імена, селектори ресурсів чи самі ресурси.

# Видалити Pod, використовуючи тип та імʼя, вказане у файлі pod.yaml.
kubectl delete -f pod.yaml

# Видалити всі Podʼи та сервіси із міткою '<label-key>=<label-value>'.
kubectl delete pods,services -l <label-key>=<label-value>

# Видалити всі Podʼи, включаючи неініціалізовані.
kubectl delete pods --all

kubectl exec — Виконати команду у контейнері Podʼа.

# Отримати вивід виконання команди 'date' у Podʼі <pod-name>. Типово вивід виконується з першого контейнера.
kubectl exec <pod-name> -- date

# Отримати вивід виконання команди 'date' у контейнері <container-name> Podʼа <pod-name>.
kubectl exec <pod-name> -c <container-name> -- date

# Отримати інтерактивний TTY та виконати /bin/bash у Podʼі <pod-name>. Типово вивід виконується з першого контейнера.
kubectl exec -ti <pod-name> -- /bin/bash

kubectl logs — Вивести логи для контейнера у Podʼі.

# Отримати логи з Podʼа <pod-name>.
kubectl logs <pod-name>

# Почати виведення логів у режимі стрічки з Podʼа <pod-name>. Це схоже на команду 'tail -f' у Linux.
kubectl logs -f <pod-name>

kubectl diff — Переглянути відмінності запропонованих оновлень кластера.

# Відмінності ресурсів, включених у "pod.json".
kubectl diff -f pod.json

# Відмінності, отримані з stdin.
cat service.yaml | kubectl diff -f -

Приклади: Створення та використання втулків

Використовуйте цей набір прикладів, щоб ознайомитися із написанням та використанням втулків kubectl:

# створіть простий втулок будь-якою мовою та зробить файл виконуваним
# так, щоб він починався префіксом "kubectl-"
cat ./kubectl-hello
#!/bin/sh

# цей втулок виводить слова "hello world"
echo "hello world"

Дайте втулку права на виконання:

chmod a+x ./kubectl-hello

# та перемістіть його в місце, яке є у вашому шляху (PATH)
sudo mv ./kubectl-hello /usr/local/bin
sudo chown root:root /usr/local/bin

# Ви зараз створили та "встановили" втулок kubectl.
# Ви можете почати використовувати цей втулок, викликаючи його з kubectl, 
# ніби це звичайна команда
kubectl hello
hello world
# Ви можете "вилучити" втулок, видаливши його з теки у вашому
# $PATH, де ви його розмістили
sudo rm /usr/local/bin/kubectl-hello

Щоб переглянути всі втулки, доступні для kubectl, використовуйте команду kubectl plugin list:

kubectl plugin list

Вивід буде схожий на:

The following kubectl-compatible plugins are available:

/usr/local/bin/kubectl-hello
/usr/local/bin/kubectl-foo
/usr/local/bin/kubectl-bar

kubectl plugin list також попереджає вас про втулки, які не мають прав на виконання, або які перекриваються з іншими втулками; наприклад:

sudo chmod -x /usr/local/bin/kubectl-foo # вилучити права виконання
kubectl plugin list
The following kubectl-compatible plugins are available:

/usr/local/bin/kubectl-hello
/usr/local/bin/kubectl-foo
  - warning: /usr/local/bin/kubectl-foo identified as a plugin, but it is not executable
/usr/local/bin/kubectl-bar

error: one plugin warning was found

Ви можете думати про втулки як про можливість будувати більш складні функції на основі наявних команд kubectl:

cat ./kubectl-whoami

Наступні кілька прикладів передбачають, що ви вже зробили так, що kubectl-whoami має наступний вміст:

#!/bin/bash

# цей втулок використовує команду `kubectl config` для виведення
# інформації про поточного користувача, на основі вибраного контексту
kubectl config view --template='{{ range .contexts }}{{ if eq .name "'$(kubectl config current-context)'" }}Current user: {{ printf "%s\n" .context.user }}{{ end }}{{ end }}'

Запуск вищезазначеної команди дає вам вивід із зазначенням користувача для поточного контексту у вашому файлі KUBECONFIG:

# зробіть файл виконавчим
sudo chmod +x ./kubectl-whoami

# та перемістіть його у місце вказане в PATH
sudo mv ./kubectl-whoami /usr/local/bin

kubectl whoami
Current user: plugins-user

Що далі

6.11.1 - Вступ до kubectl

kubectl — це версія CLI для Kubernetes, яка може виконувати багато різних речей.

Хоча це керівництво зосереджене на використанні kubectl для декларативного управління застосунками в Kubernetes, воно також охоплює інші функції kubectl.

Набори команд

Більшість команд kubectl зазвичай відносяться до однієї з кількох категорій:

ТипВикористанняОпис
Декларативне управління ресурсамиРозгортання та операційна діяльність (наприклад, GitOps)Декларативне управління ресурсами Kubernetes за допомогою конфігурації ресурсів
Імперативне управління ресурсамиТільки розробкаВиконання команд для управління ресурсами Kubernetes за допомогою аргументів командного рядка та прапорців
Виведення стану робочого навантаженняНалагодженняВиведення інформації про робочі навантаження
Взаємодія з контейнерамиНалагодженняExec, attach, cp, logs
Управління кластеромОперації з кластеромВиведення та блокування вузлів

Декларативне управління застосунками

Найкращим підходом для управління ресурсами є використання декларативних файлів, які називаються конфігурацією ресурсів, разом з командою kubectl Apply. Ця команда читає локальну (або віддалену) структуру файлів та змінює стан кластера, щоб відображати заявлені наміри.

Виведення стану робочих навантажень

Користувачам потрібно переглядати стан робочих навантажень.

  • Виведення підсумкового стану та інформації про ресурси
  • Виведення повного стану та інформації про ресурси
  • Виведення конкретних полів з ресурсів
  • Запит ресурсів, які відповідають міткам

Налагодження робочих навантажень

kubectl підтримує налагодження, надаючи команди для:

  • Виведення логів контейнерів
  • Виведення подій кластера
  • Виконання або приєднання до контейнера
  • Копіювання файлів з контейнерів в кластері у файлову систему користувача

Управління кластером

Час від часу користувачам може знадобитися виконати операції на вузлах кластера. kubectl підтримує команди для виведення робочих навантажень з вузла, щоб його можна було відключити або налагодити.

Парадні команди

Користувачі можуть вважати, що використання конфігурації ресурсів надто багатослівне для розробки та віддають перевагу роботі з кластером імперативно за допомогою робочого процесу, схожого на роботу з оболонкою. kubectl пропонує парадні (porcelain 1) команди для створення та модифікації ресурсів.

  • Генерування + створення ресурсів таких, як Deployment, StatefulSet, Service, ConfigMap й так далі
  • Встановлення полів ресурсів
  • Редагування (поточних) ресурсів в текстовому редакторі

6.11.2 - Швидкий довідник kubectl

Ця сторінка містить перелік загальновживаних команд та прапорців kubectl.

Автозавершення команд kubeclt

BASH

source <(kubectl completion bash) # встановлення автозавершення для bash в поточному терміналі, пакунок bash-completion повинен бути встановлений.
echo "source <(kubectl completion bash)" >> ~/.bashrc # додавання автозавершення для bash в профіль bash для постіного використання

Ви також можете використовувати зручне скорочення для kubectl, яке також працює з автозавершенням:

alias k=kubectl
complete -o default -F __start_kubectl k

ZSH

source <(kubectl completion zsh)  # встановлення автозавершення для zsh в поточному терміналі
echo '[[ $commands[kubectl] ]] && source <(kubectl completion zsh)' >> ~/.zshrc # додавання автозавершення для zsh в профіль zsh для постіного використання

FISH

echo 'kubectl completion fish | source' > ~/.config/fish/completions/kubectl.fish && source ~/.config/fish/completions/kubectl.fish

-A замість --all-namespaces

Додавання --all-namespaces трапляється досить часто, тому вам слід знати скорочення для --all-namespaces:

kubectl -A

Контекст та конфігурація kubectl

Встановіть, з яким кластером Kubernetes kubectl спілкується та змінює інформацію про конфігурацію. Див. документацію Автентифікація між кластерами за допомогою kubeconfig для детальної інформації про конфігураційний файл.

kubectl config view # Показати обʼєднані налаштування kubeconfig.

# використовувати декілька файлів kubeconfig одночасно та переглядати обʼєднані конфігурації {#creating-objects}
KUBECONFIG=~/.kube/config:~/.kube/config2 

kubectl config view

# Показати обʼєднані налаштування kubeconfig, необроблені дані сертифікатів та експоновані секрети
kubectl config view --raw

# отримання пароля для користувача e2e
kubectl config view -o jsonpath='{.users[?(@.name == "e2e")].user.password}'

# отримання сертифіката для користувача e2e
kubectl config view --raw -o jsonpath='{.users[?(.name == "e2e")].user.client-certificate-data}' | base64 -d

kubectl config view -o jsonpath='{.users[].name}'    # показати першого користувача
kubectl config view -o jsonpath='{.users[*].name}'   # отримати список користувачів
kubectl config get-contexts                          # показати список контекстів
kubectl config get-contexts -o name                  # отримати всі імена контекстів
kubectl config current-context                       # показати поточний контекст
kubectl config use-context my-cluster-name           # встановити стандартний контекст у my-cluster-name

kubectl config set-cluster my-cluster-name           # встановити запис кластера у kubeconfig

# налаштувати URL проксі-сервера для запитів, зроблених цим клієнтом у kubeconfig
kubectl config set-cluster my-cluster-name --proxy-url=my-proxy-url

# додати нового користувача до kubeconf з підтримкою базової автентифікації
kubectl config set-credentials kubeuser/foo.kubernetes.com --username=kubeuser --password=kubepassword

# постійно зберігати простір імен для всіх наступних команд kubectl у цьому контексті
kubectl config set-context --current --namespace=ggckad-s2

# встановити контекст, використовуючи конкретне імʼя користувача та простір імен
kubectl config set-context gce --user=cluster-admin --namespace=foo \
  && kubectl config use-context gce

kubectl config unset users.foo                       # видалити користувача foo

# скорочення для налаштування/показу контексту/простору імен (працює тільки для bash та сумісних з bash оболонок, поточний контекст має бути встановлений перед використанням kn для налаштування простору імен)
alias kx='f() { [ "$1" ] && kubectl config use-context $1 || kubectl config current-context ; } ; f'
alias kn='f() { [ "$1" ] && kubectl config set-context --current --namespace $1 || kubectl config view --minify | grep namespace | cut -d" " -f6 ; } ; f'

Kubectl apply

apply керує застосунками через файли, що визначають ресурси Kubernetes. Ця команда створює та оновлює ресурси в кластері, виконуючи команду kubectl apply. Це рекомендований спосіб керування застосунками Kubernetes в операційному середовищі. Дивіться Kubectl Book.

Створення обʼєктів

Маніфести Kubernetes можна визначати у форматах YAML або JSON. Можна використовувати розширення файлів .yaml, .yml та .json.

kubectl apply -f ./my-manifest.yaml                 # створити ресурс(и)
kubectl apply -f ./my1.yaml -f ./my2.yaml           # створити з декількох файлів
kubectl apply -f ./dir                              # створити ресурс(и) з усіх манифестів у теці
kubectl apply -f https://example.com/manifest.yaml  # створити ресурс(и) з URL (Примітка: це приклад домену і не містить дійсного манифесту)
kubectl create deployment nginx --image=nginx       # запустити один екземпляо nginx

# створити завдання, яке виводить "Hello World"
kubectl create job hello --image=busybox:1.28 -- echo "Hello World"

# створити CronJob, який виводить "Hello World" кожну хвилину
kubectl create cronjob hello --image=busybox:1.28   --schedule="*/1 * * * *" -- echo "Hello World"

kubectl explain pods                           # отримати документацію для манифестів pod

# створити декілька YAML обʼєктів зі stdin {#creating-objects}
kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: busybox-sleep
spec:
  containers:
  - name: busybox
    image: busybox:1.28
    args:
    - sleep
    - "1000000"
---
apiVersion: v1
kind: Pod
metadata:
  name: busybox-sleep-less
spec:
  containers:
  - name: busybox
    image: busybox:1.28
    args:
    - sleep
    - "1000"
EOF

# створити секрет з декількома ключами
kubectl apply -f - <<EOF
apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  password: $(echo -n "s33msi4" | base64 -w0)
  username: $(echo -n "jane" | base64 -w0)
EOF

Перегляд і пошук ресурсів

# Отримати команди з базовим виводом
kubectl get services                          # Вивід усіх сервісів у просторі імен
kubectl get pods --all-namespaces             # Вивід усіх Podʼів у всіх просторах імен
kubectl get pods -o wide                      # Вивід усіх Podʼів у поточному просторі імен, з детальною інформацією
kubectl get deployment my-dep                 # Вивід конкретного deployment
kubectl get pods                              # Вивід усіх Podʼів у просторі імен
kubectl get pod my-pod -o yaml                # Отримати Pod в фоматі YAML

# Опис команд з докладним виводом
kubectl describe nodes my-node
kubectl describe pods my-pod

# Вивід сервісів, відсортованих за назвою
kubectl get services --sort-by=.metadata.name

# Вивід Podʼів, відсортованих за кількістю перезапусків
kubectl get pods --sort-by='.status.containerStatuses[0].restartCount'

# Вивід PersistentVolumes, відсортованих за ємністю
kubectl get pv --sort-by=.spec.capacity.storage

# Отримати мітки version усіх Podʼів з міткою app=cassandra
kubectl get pods --selector=app=cassandra -o \
  jsonpath='{.items[*].metadata.labels.version}'

# Отримати значення ключа з крапками, напр. 'ca.crt'
kubectl get configmap myconfig \
  -o jsonpath='{.data.ca\.crt}'

# Отримати значення, закодоване у base64, з дефісами замість підкреслень
kubectl get secret my-secret --template='{{index .data "key-name-with-dashes"}}'

# Отримати всі робочі вузли (використовувати селектор для виключення результатів з міткою
# з назвою 'node-role.kubernetes.io/control-plane')
kubectl get node --selector='!node-role.kubernetes.io/control-plane'

# Отримати всі запущені Podʼи у просторі імен
kubectl get pods --field-selector=status.phase=Running

# Отримати ExternalIP усіх вузлів
kubectl get nodes -o jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}'

# Вивід імен Podʼів, що належать певному RC
# Команда "jq" корисна для перетворень, які занадто складні для jsonpath, її можна знайти на https://jqlang.github.io/jq/
sel=${$(kubectl get rc my-rc --output=json | jq -j '.spec.selector | to_entries | .[] | "\(.key)=\(.value),"')%?}
echo $(kubectl get pods --selector=$sel --output=jsonpath={.items..metadata.name})

# Показати мітки для всіх Podʼів (або будь-якого іншого обʼєкта Kubernetes, що підтримує мітки)
kubectl get pods --show-labels

# Перевірити, які вузли готові
JSONPATH='{range .items[*]}{@.metadata.name}:{range @.status.conditions[*]}{@.type}={@.status};{end}{end}' \
 && kubectl get nodes -o jsonpath="$JSONPATH" | grep "Ready=True"

# Перевірити, які вузли готові з custom-columns
kubectl get node -o custom-columns='NODE_NAME:.metadata.name,STATUS:.status.conditions[?(@.type=="Ready")].status'

# Вивести розкодовані секрети без зовнішніх інструментів
kubectl get secret my-secret -o go-template='{{range $k,$v := .data}}{{"### "}}{{$k}}{{"\n"}}{{$v|base64decode}}{{"\n\n"}}{{end}}'

# Вивід усіх секретів, які зараз використовуються Podʼом
kubectl get pods -o json | jq '.items[].spec.containers[].env[]?.valueFrom.secretKeyRef.name' | grep -v null | sort | uniq

# Вивід всіх containerID initContainer усіх Podʼів
# Корисно при очищенні зупинених контейнерів, уникаючи видалення initContainer.
kubectl get pods --all-namespaces -o jsonpath='{range .items[*].status.initContainerStatuses[*]}{.containerID}{"\n"}{end}' | cut -d/ -f3

# Вивід подій, відсортованих за часовою позначкою
kubectl get events --sort-by=.metadata.creationTimestamp

# Вивід всіх попереджувальних подій
kubectl events --types=Warning

# Порівняти поточний стан кластера зі станом, в якому б кластер знаходився, якби було застосовано маніфест.
kubectl diff -f ./my-manifest.yaml

# Створити дерево всіх ключів, розділених крапками, що повертаються для вузлів
# Корисно при пошуку ключа у складній вкладеній структурі JSON
kubectl get nodes -o json | jq -c 'paths|join(".")'

# Створити всіх ключів, розділених крапками, що повертаються для Podʼів тощо
kubectl get pods -o json | jq -c 'paths|join(".")'

# Вивести ENV для всіх Podʼів, за умови, що у вас є типовий контейнер для Podʼів, типовий простір імен і підтримка команди `env`.
# Корисно при виконанні будь-якої підтримуваної команди для всіх Podʼів, не тільки `env`
for pod in $(kubectl get po --output=jsonpath={.items..metadata.name}); do echo $pod && kubectl exec -it $pod -- env; done

# Отримати субресурс status для deployment
kubectl get deployment nginx-deployment --subresource=status

Оновлення ресурсів

kubectl set image deployment/frontend www=image:v2               # Rolling update контейнерів "www" в deployment "frontend", оновлення образу
kubectl rollout history deployment/frontend                      # Перегляд історії deployment, включаючи ревізію
kubectl rollout undo deployment/frontend                         # Відкат до попереднього deployment
kubectl rollout undo deployment/frontend --to-revision=2         # Відкат до конкретної ревізії
kubectl rollout status -w deployment/frontend                    # Спостереження за статусом rolling update deployment "frontend" до завершення
kubectl rollout restart deployment/frontend                      # Rolling restart deployment "frontend"

cat pod.json | kubectl replace -f -                              # Заміна Pod на основі JSON, переданого через stdin

# Примусова заміна, видалення та повторне створення ресурсу. Це призведе до простою сервісу.
kubectl replace --force -f ./pod.json

# Створення сервісу для реплікованого nginx, який працює на порту 80 і підключається до контейнерів на порту 8000
kubectl expose rc nginx --port=80 --target-port=8000

# Оновлення версії (теґа) образу одноконтейнерного Podʼа до v4
kubectl get pod mypod -o yaml | sed 's/\(image: myimage\):.*$/\1:v4/' | kubectl replace -f -

kubectl label pods my-pod new-label=awesome                      # Додавання мітки
kubectl label pods my-pod new-label-                             # Видалення мітки
kubectl label pods my-pod new-label=new-value --overwrite        # Перезапис поточного значення
kubectl annotate pods my-pod icon-url=http://goo.gl/XXBTWq       # Додавання анотації
kubectl annotate pods my-pod icon-url-                           # Видалення анотації
kubectl autoscale deployment foo --min=2 --max=10                # Автомасштабування deployment "foo"

Накладання патчів на ресурси

# Часткове оновлення вузла
kubectl patch node k8s-node-1 -p '{"spec":{"unschedulable":true}}'

# Оновлення образу контейнера; spec.containers[*].name обовʼязково, тому що це ключ для злиття
kubectl patch pod valid-pod -p '{"spec":{"containers":[{"name":"kubernetes-serve-hostname","image":"new image"}]}}'

# Оновлення образу контейнера за допомогою json patch з позиційними масивами
kubectl patch pod valid-pod --type='json' -p='[{"op": "replace", "path": "/spec/containers/0/image", "value":"new image"}]'

# Вимкнення livenessProbe у deployment за допомогою json patch з позиційними масивами
kubectl patch deployment valid-deployment --type json -p='[{"op": "remove", "path": "/spec/template/spec/containers/0/livenessProbe"}]'

# Додавання нового елементу до позиційного масиву
kubectl patch sa default --type='json' -p='[{"op": "add", "path": "/secrets/1", "value": {"name": "whatever" } }]'

# Оновлення кількості реплік deployment шляхом накладання патчу на його субресурс scale
kubectl patch deployment nginx-deployment --subresource='scale' --type='merge' -p '{"spec":{"replicas":2}}'

Редагування ресурсів

Ви можете змінювати ресурси, використовуючи ваш улюблений редактор:

kubectl edit svc/docker-registry                      # Редагування service з назвою docker-registry
KUBE_EDITOR="nano" kubectl edit svc/docker-registry   # Використання альтернативного рекактора

Масштабування ресурсів

kubectl scale --replicas=3 rs/foo                                 # Масштабування replicaset з назвою 'foo' до 3
kubectl scale --replicas=3 -f foo.yaml                            # Масштабування ресурсу вказанеого у "foo.yaml" до 3
kubectl scale --current-replicas=2 --replicas=3 deployment/mysql  # Якщо deployment з назвою mysql має поточний розмір — 2, масштабувати mysql до 3
kubectl scale --replicas=5 rc/foo rc/bar rc/baz                   # Масштабувати кілька контролерів реплікації

Видалення ресурсів

kubectl delete -f ./pod.json                                      # Вилучити Pod використовуючи тип та назву, вказані в pod.json
kubectl delete pod unwanted --now                                 # Вилучити Pod негайно, без його належного завершення
kubectl delete pod,service baz foo                                # Вилучити Podʼи та сервіси з назвами "baz" та "foo"
kubectl delete pods,services -l name=myLabel                      # Вилучити Podʼи та сервіси з міткою name=myLabel
kubectl -n my-ns delete pod,svc --all                             # Вилучити всі Podʼи та сервіси в просторі імен my-ns,
# Вилучити всі Podʼи, що збігаються з шаблоном awk pattern1 або pattern2
kubectl get pods  -n mynamespace --no-headers=true | awk '/pattern1|pattern2/{print $1}' | xargs  kubectl delete -n mynamespace pod

Взаємодія з працюючими Podʼами

kubectl logs my-pod                                 # вивести логи Podʼа (stdout)
kubectl logs -l name=myLabel                        # вивести логи Podʼів з міткою name=myLabel (stdout)
kubectl logs my-pod --previous                      # вивести логи Podʼа (stdout) для попереднього варіанта контейнера
kubectl logs my-pod -c my-container                 # вивести логи контейнера в Podʼі (stdout, випадок з декількома контейнерами)
kubectl logs -l name=myLabel -c my-container        # вивести логи контейнера в Podʼі з міткою name=myLabel (stdout)
kubectl logs my-pod -c my-container --previous      # вивести логи контейнера в Podʼі (stdout, випадок з декількома контейнерами) для попереднього варіанта контейнера
kubectl logs -f my-pod                              # транслювати логи Podʼа (stdout)
kubectl logs -f my-pod -c my-container              # транслювати логи контейнера в Podʼі (stdout, випадок з декількома контейнерами)
kubectl logs -f -l name=myLabel --all-containers    # транслювати всі логи Podʼів з міткою name=myLabel (stdout)
kubectl run -i --tty busybox --image=busybox:1.28 -- sh  # Запустити Pod як інтерактивну оболонку
kubectl run nginx --image=nginx -n mynamespace      # Запустити один екземпляр Podʼа nginx в просторі імен mynamespace
kubectl run nginx --image=nginx --dry-run=client -o yaml > pod.yaml
                                                    # Згенерувати специфікацію для запуску Podʼа nginx і записати її у файл pod.yaml
kubectl attach my-pod -i                            # Підʼєднатися до працюючого контейнера
kubectl port-forward my-pod 5000:6000               # Слухати порт 5000 на локальній машині і пересилати на порт 6000 на Podʼі my-pod
kubectl exec my-pod -- ls /                         # Виконати команду в існуючому Podʼі (випадок з 1 контейнером)
kubectl exec --stdin --tty my-pod -- /bin/sh        # Інтерактивний доступ до оболонки працюючого Podʼа (випадок з 1 контейнером)
kubectl exec my-pod -c my-container -- ls /         # Виконати команду в існуючому Podʼі (випадок з декількома контейнерами)
kubectl debug my-pod -it --image=busybox:1.28       # Створити інтерактивну налагоджувальну сесію в існуючому Podʼі і відразу підʼєднатися до неї
kubectl debug node/my-node -it --image=busybox:1.28 # Створити інтерактивну налагоджувальну сесію на вущлі і відразу підʼєднатися до неї
kubectl top pod                                     # Показати метрики для всіх Podʼів в стандартному просторі імен
kubectl top pod POD_NAME --containers               # Показати метрики для заданого Podʼа та його контейнерів
kubectl top pod POD_NAME --sort-by=cpu              # Показати метрики для заданого Podʼа і сортувати їх за 'cpu' або 'memory'

Копіювання файлів та тек до і з контейнерів

kubectl cp /tmp/foo_dir my-pod:/tmp/bar_dir            # Скопіювати локальну теку /tmp/foo_dir до /tmp/bar_dir у віддаленому Podʼі в поточному просторі імен
kubectl cp /tmp/foo my-pod:/tmp/bar -c my-container    # Скопіювати локальний файл /tmp/foo до /tmp/bar у віддаленому Podʼі в конкретному контейнері
kubectl cp /tmp/foo my-namespace/my-pod:/tmp/bar       # Скопіювати локальний файл /tmp/foo до /tmp/bar у віддаленому Podʼі в просторі імен my-namespace
kubectl cp my-namespace/my-pod:/tmp/foo /tmp/bar       # Скопіювати /tmp/foo з віддаленого Podʼа до /tmp/bar локально
tar cf - /tmp/foo | kubectl exec -i -n my-namespace my-pod -- tar xf - -C /tmp/bar           # Скопіювати локальний файл /tmp/foo до /tmp/bar у віддаленому Podʼі в просторі імен my-namespace
kubectl exec -n my-namespace my-pod -- tar cf - /tmp/foo | tar xf - -C /tmp/bar              # Скопіювати /tmp/foo з віддаленого Podʼа до /tmp/bar локально

Взаємодія з Deployment та Service

kubectl logs deploy/my-deployment                         # Вивести логи Podʼа для Deployment (одноконтейнерний випадок)
kubectl logs deploy/my-deployment -c my-container         # Вивести логи Podʼа для Deployment (багатоконтейнерний випадок)

kubectl port-forward svc/my-service 5000                  # Слухати на локальному порту 5000 і переадресувати на порт 5000 на Service бекенд
kubectl port-forward svc/my-service 5000:my-service-port  # Слухати на локальному порту 5000 і переадресувати на порт цільового Service з імʼям <my-service-port>

kubectl port-forward deploy/my-deployment 5000:6000       # Слухати на локальному порту 5000 і переадресувати на порт 6000 на Podʼі, створеному <my-deployment>
kubectl exec deploy/my-deployment -- ls                   # Виконати команду в першому Podʼі та першому контейнері в Deployment (одноконтейнерний або багатоконтейнерний випадок)

Взаємодія з вузлами та кластером

kubectl cordon my-node                                                # Позначити my-node як непридатний до планування
kubectl drain my-node                                                 # Вивільнити my-node для підготовки до обслуговування
kubectl uncordon my-node                                              # Позначити my-node як придатний до планування
kubectl top node                                                      # Показати метрики для всіх вузлів
kubectl top node my-node                                              # Показати метрики для певного вузла
kubectl cluster-info                                                  # Показати адреси майстра та сервісів
kubectl cluster-info dump                                             # Вивести поточний стан кластера у stdout
kubectl cluster-info dump --output-directory=/path/to/cluster-state   # Вивести поточний стан кластера у /path/to/cluster-state

# Переглянути наявні taint, які є на поточних вузлах.
kubectl get nodes -o='custom-columns=NodeName:.metadata.name,TaintKey:.spec.taints[*].key,TaintValue:.spec.taints[*].value,TaintEffect:.spec.taints[*].effect'

# Якщо taint з таким ключем та ефектом вже існує, його значення замінюється, як зазначено.
kubectl taint nodes foo dedicated=special-user:NoSchedule

Типи ресурсів

Для виводу всіх підтримуваних типів ресурсів разом з їх короткими іменами, API групою, чи вони просторово обмежені, та kind:

kubectl api-resources

Інші операції для дослідження ресурсів API:

kubectl api-resources --namespaced=true      # Всі ресурси, які просторово обмежені
kubectl api-resources --namespaced=false     # Всі ресурси, які не є просторово обмеженими
kubectl api-resources -o name                # Усі ресурси з простим виведенням (тільки назва ресурсу)
kubectl api-resources -o wide                # Усі ресурси з розширеним виведенням (так званий "wide" формат)
kubectl api-resources --verbs=list,get       # Усі ресурси, які підтримують запити "list" та "get"
kubectl api-resources --api-group=extensions # Усі ресурси в API групі "extensions"

Форматування виводу

Щоб вивести деталі у вікні термінала у певному форматі, додайте прапорець -o (або --output) до відповідної команди kubectl.

Формат виводуОпис
-o=custom-columns=<spec>Вивести таблицю, використовуючи список власних стовпців, розділених комами
-o=custom-columns-file=<filename>Вивести таблицю, використовуючи шаблон власних стовпців з файлу <filename>
-o=go-template=<template>Вивести поля, визначені за допомогою шаблону на основі golang
-o=go-template-file=<filename>Вивести поля, визначені за допомогою шаблону на основі golang з файлу <filename>
-o=jsonВивести API обʼєкт у форматі JSON
-o=jsonpath=<template>Вивести поля, визначені за допомогою виразу jsonpath
-o=jsonpath-file=<filename>Вивести поля, визначені за допомогою виразу jsonpath з файлу <filename>
-o=nameВивести лише назву ресурсу і нічого більше
-o=wideВивести в текстовому форматі з додатковою інформацією, включаючи імʼя вузла для Podʼів
-o=yamlВивести API обʼєкт у форматі YAML

Приклади використання -o=custom-columns:

# Усі образи, що працюють в кластері
kubectl get pods -A -o=custom-columns='DATA:spec.containers[*].image'

# Усі образи, що працюють в просторі імен: default, згруповані по Pod
kubectl get pods --namespace default --output=custom-columns="NAME:.metadata.name,IMAGE:.spec.containers[*].image"

# Усі образи, за винятком "registry.k8s.io/coredns:1.6.2"
kubectl get pods -A -o=custom-columns='DATA:spec.containers[?(@.image!="registry.k8s.io/coredns:1.6.2")].image'

# Усі поля metadata незалежно від назви
kubectl get pods -A -o=custom-columns='DATA:metadata.*'

Додаткові приклади можна знайти в документації kubectl reference documentation.

Рівні деталізації виводу та налагодження для kubectl

Деталізація виводу в kubectl контролюється за допомогою прапорця -v або --v, за яким слідує ціле число, що представляє рівень логування. Загальні конвенції щодо логування Kubernetes та повʼязані рівні описані тут.

Рівень деталізаціїОпис
--v=0Загалом корисно, щоб цей рівень завжди був видимим для оператора кластера.
--v=1Прийнятний стандартний рівень логування, якщо вам не потрібна висока деталізація.
--v=2Корисна стабільна інформація про сервіс та важливі повідомлення логу, які можуть корелювати зі значними змінами в системі. Рекомендований стандартний рівень логування для більшості систем.
--v=3Розширена інформація про зміни.
--v=4Рівень логування для налагодження.
--v=5Рівень логування для налагодження з трасуванням.
--v=6Показати запитані ресурси.
--v=7Показати заголовки HTTP-запитів.
--v=8Показати вміст HTTP-запитів.
--v=9Показати вміст HTTP-запитів без обрізання вмісту.

Що далі

6.11.3 - Довідник kubectl

6.11.3.1 - kubectl

Огляд

kubectl керує менеджером кластерів Kubernetes.

Докладніше: https://kubernetes.io/docs/reference/kubectl/

kubectl [flags]

Параметри

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

-h, --help

довідка kubectl

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl annotate — Оновлення анотацій ресурсу
  • kubectl api-resources — Вивід підтримуваних ресурсів API на сервері
  • kubectl api-versions — Вивід підтримуваних версій API на сервері у форматі "група/версія"
  • kubectl apply — Застосування конфігурації до ресурсу за іменем файлу або через stdin
  • kubectl attach — Приєднання до запущеного контейнера
  • kubectl auth — Інспектування авторизації
  • kubectl autoscale — Автоматичне масштабування deployment, replica set, stateful set або контролера реплікацій
  • kubectl certificate — Зміна ресурсів сертифікатів
  • kubectl cluster-info — Вивід інформації про кластер
  • kubectl completion — Вивід коду автозавершення оболонки для вказаної оболонки (bash, zsh, fish або powershell)
  • kubectl config — Зміна файлів kubeconfig
  • kubectl cordon — Позначення вузла як незапланованого
  • kubectl cp — Копіювання файлів та тек до контейнерів і з них
  • kubectl create — Створення ресурсу з файлу або через stdin
  • kubectl debug — Створення сеансів налагодження для усунення несправностей навантажень та вузлів
  • kubectl delete — Видалення ресурсів за іменами файлів, через stdin, ресурсів та імен або за селектором ресурсів і міток
  • kubectl describe — Показ деталей конкретного ресурсу або групи ресурсів
  • kubectl diff — Показ різниці між поточною версією та потенційно застосованою версією
  • kubectl drain — Очищення вузла перед технічним обслуговуванням
  • kubectl edit — Редагування ресурсу на сервері
  • kubectl events — Вивід списку подій
  • kubectl exec — Виконання команди в контейнері
  • kubectl explain — Отримання документації для ресурсу
  • kubectl expose — Використання контролера реплікації, service, deployment або pod та експонування його як нового сервіса Kubernetes
  • kubectl get — Показ одного чи кількох ресурсів
  • kubectl kustomize — Побудова цільового kustomization з текуи або URL
  • kubectl label — Оновлення міток ресурсу
  • kubectl logs — Вивід логів для контейнера в Pod
  • kubectl options — Вивід списку прапорців, успадкованих всіма командами
  • kubectl patch — Оновлення полів ресурсу
  • kubectl plugin — Надає утиліти для взаємодії з втулками
  • kubectl port-forward — Перенаправлення одного або декількох локальних портів до Podʼа
  • kubectl proxy — Запуск проксі для сервера API Kubernetes
  • kubectl replace — Заміна ресурсу за іменем файлу або через stdin
  • kubectl rollout — Керування розгортанням ресурсу
  • kubectl run — Запуск певного образу в кластері
  • kubectl scale — Встановлення нового розміру для deployment, replica set або контролера реплікацій
  • kubectl set — Встановлення конкретних функцій для обʼєктів
  • kubectl taint — Оновлення taint на одному або кількох вузлах
  • kubectl top — Показ використання ресурсів (CPU/памʼять)
  • kubectl uncordon — Позначення вузла як придатного для планування
  • kubectl version — Вивід інформації про версію клієнта та сервера
  • kubectl wait — Експериментальна функція: очікування на визначену умову для одного або кількох ресурсів

6.11.3.2 - kubectl annotate

Огляд

Оновлення анотацій на одному або декількох ресурсах.

Всі обʼєкти Kubernetes підтримують можливість зберігати додаткові дані разом з обʼєктом у вигляді анотацій. Анотації — це пари ключ/значення, які можуть бути більшими за мітки та включати довільні рядкові значення, такі як структурований JSON. Інструменти та розширення системи можуть використовувати анотації для зберігання власних даних.

Спроба створити анотацію, яка вже існує, призведе до невдачі, якщо не вказано --overwrite. Якщо вказано --resource-version і не збігається з поточною версією ресурсу на сервері, виконання команди буде невдалим.

Для отримання повного списку підтримуваних ресурсів скористайтеся kubectl api-resources.

kubectl annotate [--overwrite] (-f FILENAME | TYPE NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--resource-version=version]

Приклади

# Оновити Pod 'foo' з анотацією 'description' і значенням 'my frontend'
# Якщо ту саму анотацію встановлено кілька разів, буде застосовано лише останнє значення
kubectl annotate pods foo description='my frontend'

# Оновити Pod, ідентифікований за типом і іменем у "pod.json"
kubectl annotate -f pod.json description='my frontend'

# Оновити Pod 'foo' з анотацією 'description' і значенням 'my frontend running nginx', перезаписуючи будь-яке існуюче значення
kubectl annotate --overwrite pods foo description='my frontend running nginx'

# Оновити всі Podʼи в просторі імен
kubectl annotate pods --all description='my frontend running nginx'

# Оновити Pod 'foo' лише у випадку, якщо ресурс не змінювався з версії 1
kubectl annotate pods foo description='my frontend running nginx' --resource-version=1

# Оновити Pod 'foo', видаливши анотацію з назвою 'description', якщо вона існує
# Не потребує прапорця --overwrite
kubectl annotate pods foo description-

Параметри

--all

Вибрати всі ресурси у просторі імен вказаних типів ресурсів.

-A, --all-namespaces

Якщо true, перевірити вказану дію в усіх просторах імен.

--allow-missing-template-keys     Типово: true

Якщо це значення встановлено, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--field-manager string     Типово: "kubectl-annotate"

Імʼя менеджера, що використовується для відстеження права власності на поле.

--field-selector string

Селектор (запит поля) для фільтрації підтримує '=', '==' і '!=' (наприклад, --field-selector key1=value1,key2=value2). Сервер підтримує лише обмежену кількість запитів до полів кожного типу.

-f, --filename strings

Імʼя файлу, теки або URL до файлів, що ідентифікують ресурс для оновлення анотації

-h, --help

довідка annotate

-k, --kustomize string

Обробити теку kustomization. Цей прапорець не можна використовувати разом з -f або -R.

--list

Якщо true, показувати анотації для даного ресурсу.

--local

Якщо значення true, annotation НЕ буде звертатися до api-server, а виконуватиметься локально.

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--overwrite

Якщо true, дозволити перезапис анотацій, інакше відхиляти оновлення анотацій, які перезаписують наявні анотації.

-R, --recursive

Рекурсивно обробити теку, вказану у -f, --filename. Корисно, якщо ви хочете керувати повʼязаними маніфестами, організованими в одній теці.

--resource-version string

Якщо значення не порожнє, оновлення анотації буде успішним, тільки якщо це поточна версія ресурсу для обʼєкта. Дійсно лише при зазначенні одного ресурсу.

-l, --selector string

Селектор (запит на мітки) для фільтрації, що підтримує '=', '==' і '!=' (наприклад, -l key1=value1,key2=value2). Обʼєкти, щоб мати збіг, повинні задовольняти усім зазначеним обмеженням міток.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes

6.11.3.3 - kubectl api-resources

Огляд

Виводить підтримувані ресурси API на сервері.

kubectl api-resources [flags]

Приклади

# Вивести підтримувані ресурси API
kubectl api-resources

# Вивести підтримувані ресурси API з більш детальною інформацією
kubectl api-resources -o wide

# Вивести підтримувані ресурси API відсортовані за колонкою
kubectl api-resources --sort-by=name

# Вивести підтримувані ресурси API, які мають простір імен
kubectl api-resources --namespaced=true

# Вивести підтримувані ресурси API, які не мають простору імен
kubectl api-resources --namespaced=false

# Вивести підтримувані ресурси API з конкретною APIGroup
kubectl api-resources --api-group=rbac.authorization.k8s.io

Параметри

--api-group string

Обмеження на ресурси у вказаній групі API.

--cached

Використовувати кешований список ресурсів, якщо він доступний.

--categories strings

Обмеження на ресурси, які належать до вказаних категорій.

-h, --help

довідка api-resources

--namespaced     Типово: true

Якщо false, будуть повернуті ресурси без простору імен, інакше стандартно будуть повернуті ресурси з простором імен.

--no-headers

При використанні стандартного або власного формату виводу стовпців не друкувати заголовки (заголовки стандартно друкуються).

-o, --output string

Формат виводу. Один з: (wide, name).

--sort-by string

Якщо поле не порожнє, відсортувати список ресурсів за вказаним полем. Поле може бути як 'name', так і 'kind'.

--verbs strings

Обмежитися ресурсами, які підтримують вказані дієслова.

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes

6.11.3.4 - kubectl api-versions

Огляд

Виводити підтримувані версії API на сервері у вигляді "група/версія".

kubectl api-versions

Приклади

  # Вивести підтримуванні версії API
  kubectl api-versions

Параметри

-h, --help

довідка api-versions

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes

6.11.3.5 - kubectl apply

Огляд

Застосовує конфігурацію до ресурсу за назвою файлу або stdin. Імʼя ресурсу має бути вказано обовʼязково. Ресурс буде створено, якщо його ще не існує. Щоб використовувати 'apply', завжди створюйте ресурс спочатку за допомогою 'apply' або 'create --save-config'.

Приймаються формати JSON і YAML.

Альфа-застереження: функціональність --prune ще не завершена. Не використовуйте, якщо ви не знаєте поточного стану. Див. https://issues.k8s.io/34274.

kubectl apply (-f FILENAME | -k DIRECTORY)

Приклади

# Застосувати конфігурацію з pod.json до Pod
kubectl apply -f ./pod.json

# Застосувати ресурси з теки, що містить kustomization.yaml — наприклад, dir/kustomization.yaml
kubectl apply -k dir/

# Застосувати JSON, що передається через stdin до Pod
cat pod.json | kubectl apply -f -

# Застосувати конфігурацію з усіх файлів, які закінчуються на '.json'
kubectl apply -f '*.json'

# Примітка: --prune все ще знаходиться в альфа-версії
# Застосувати конфігурацію з manifest.yaml, яка відповідає мітці app=nginx і видалити всі інші ресурси, які не знаходяться в файлі і відповідають мітці app=nginx
kubectl apply --prune -f manifest.yaml -l app=nginx

# Застосувати конфігурацію з manifest.yaml і видалити всі інші config map, які не знаходяться в файлі
kubectl apply --prune -f manifest.yaml --all --prune-allowlist=core/v1/ConfigMap

Параметри

--all

Вибрати всі ресурси у просторі імен вказаних типів ресурсів.

--allow-missing-template-keys     Типово: true

Якщо це значення встановлено, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--cascade string[="background"]     Типово: "background"

Має бути "background", "orphan" або "foreground". Вибирає стратегію каскадного видалення для залежних елементів (наприклад, Podʼів, створених Replication Controller). Стандартне значення — background.

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--field-manager string     Типово: "kubectl-client-side-apply"

Імʼя менеджера, що використовується для відстеження права власності на поле.

-f, --filename strings

Імʼя файлу, теки або URL до файлів, що ідентифікують ресурс для оновлення анотації

--force

Якщо true, негайно видалити ресурси з API і оминути належне видалення. Зверніть увагу, що негайне видалення деяких ресурсів може призвести до неузгодженості або втрати даних і потребує підтвердження.

--force-conflicts

Якщо значення true, серверне застосування (server-side apply) буде примусово вносити зміни всупереч конфліктам.

--grace-period int     Типово: -1

Період часу в секундах, який дається ресурсу для належного завершення роботи. Ігнорується, якщо значення відʼємне. Встановлюється у 1 для негайного завершення роботи. Може бути встановлене у 0, тільки якщо --force має значення true (примусове видалення).

-h, --help

довідка apply

-k, --kustomize string

Обробити теку kustomization. Цей прапорець не можна використовувати разом з -f або -R.

--openapi-patch     Типово: true

Якщо true, використовувати openapi для обчислення різниці, коли openapi присутній і ресурс можна знайти в специфікації openapi. В іншому випадку, повернутись до використання вбудованих типів.

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--overwrite     Типово: true

Автоматично вирішувати конфлікти між зміненою та поточною конфігурацією, використовуючи значення зі зміненої конфігурації

--prune

Автоматично видаляти обʼєкти ресурсів, які не зʼявляються у конфігураціях і створюються за допомогою --save-config. Слід використовувати з -l або --all.

--prune-allowlist strings

Замінити список стандартний дозволів (allowlist) <group/version/kind> для --prune

-R, --recursive

Рекурсивно обробити теку, вказану у -f, --filename. Корисно, якщо ви хочете керувати повʼязаними маніфестами, організованими в одній теці.

-l, --selector string

Селектор (запит на мітки) для фільтрації, що підтримує '=', '==' і '!=' (наприклад, -l key1=value1,key2=value2). Обʼєкти, щоб мати збіг, повинні задовольняти усім зазначеним обмеженням міток.

--server-side

Якщо значення true, apply виконується на сервері, а не на клієнті.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--timeout duration

Час очікування перед прийнятям рішення про відмову видалення, нуль означає визначення таймауту залежно від розміру обʼєкта

--validate string[="strict"]     Типово: "strict"

Повинно бути одним із: strict (або true), warn, ignore (або false).

"true" або "strict" буде використовувати схему для перевірки вводу і відхилятиме запит, якщо він невірний. Буде виконана перевірка на стороні сервера, якщо ServerSideFieldValidation увімкнено на api-server, але якщо ні, то повернеться до менш надійної перевірки на стороні клієнта.

"warn" попередить про невідомі або повторювані поля, не блокуючи запит, якщо на боці сервера API увімкнено перевірку полів, і буде поводитися як " ignore" у протилежному випадку.

"false" або "ignore" не виконуватимуть жодної перевірки схеми, мовчки відкидаючі будь-які невідомі або дубльовані поля.

--wait

Якщо true, очікувати, поки ресурси зникнуть, перш ніж повернутися. Очікує фіналізаторів.

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes
  • kubectl apply edit-last-applied — Редагувати останню анотацію last-applied-configuration ресурса/обʼєкта
  • kubectl apply set-last-applied — Встановити анотацію last-applied-configuration на наявному обʼєкті, щоб відповідати вмісту файлу
  • kubectl apply view-last-applied — Переглянути останню анотацію last-applied-configuration ресурса/обʼєкта

6.11.3.5.1 - kubectl apply edit-last-applied

Огляд

Редагуйте останні анотації last-applied-configuration ресурсів зі стандартного редактора.

Команда edit-last-applied дозволяє безпосередньо редагувати будь-який API-ресурс, який ви можете отримати за допомогою інструментів командного рядка. Вона відкриє редактор, визначений вашими змінними середовища KUBE_EDITOR або EDITOR, або використає стандартний редактор — 'vi' для Linux або 'notepad' для Windows. Ви можете редагувати кілька обʼєктів, але зміни застосовуються поодинці. Команда приймає імена файлів або аргументи командного рядка, але файли, на які ви посилаєтесь, повинні бути збереженими версіями ресурсів.

Стандартний формат — YAML. Для редагування в JSON вкажіть "-o json".

Прапорець --windows-line-endings може бути використано для примусового завершення рядків в стилі Windows, інакше буде використано типовий варіант для вашої операційної системи.

У разі виникнення помилки під час оновлення буде створено тимчасовий файл на диску, який містить ваші незастосовані зміни. Найбільш поширеною помилкою під час оновлення ресурсу є зміна іншим редактором цього ресурсу на сервері. У такому випадку вам доведеться застосувати ваші зміни до новішої версії ресурсу або оновити вашу тимчасовий збережену копію, щоб включити останню версію ресурсу.

kubectl apply edit-last-applied (RESOURCE/NAME | -f FILENAME)

Приклади

# Редагувати анотації last-applied-configuration за типом/імʼям у форматі YAML
kubectl apply edit-last-applied deployment/nginx

# Редагувати анотації last-applied-configuration за файлом у форматі JSON
kubectl apply edit-last-applied -f deploy.yaml -o json

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--field-manager string     Типово: "kubectl-client-side-apply"

Імʼя менеджера, що використовується для відстеження права власності на поле.

-f, --filename strings

Імʼя файлу, теки або URL до файлів, що ідентифікують ресурс для оновлення анотації

-h, --help

довідка edit-last-applied

-k, --kustomize string

Обробити теку kustomization. Цей прапорець не можна використовувати разом з -f або -R.

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

-R, --recursive

Рекурсивно обробити теку, вказану у -f, --filename. Корисно, якщо ви хочете керувати повʼязаними маніфестами, організованими в одній теці.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--validate string[="strict"]     Типово: "strict"

Повинно бути одним із: strict (або true), warn, ignore (або false).

"true" або "strict" буде використовувати схему для перевірки вводу і відхилятиме запит, якщо він невірний. Буде виконана перевірка на стороні сервера, якщо ServerSideFieldValidation увімкнено на api-server, але якщо ні, то повернеться до менш надійної перевірки на стороні клієнта.

"warn" попередить про невідомі або повторювані поля, не блокуючи запит, якщо на боці сервера API увімкнено перевірку полів, і буде поводитися як " ignore" у протилежному випадку.

"false" або "ignore" не виконуватимуть жодної перевірки схеми, мовчки відкидаючі будь-які невідомі або дубльовані поля.

--windows-line-endings

Стандартно використовується закінчення рядка, притаманне вашій платформі.

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl apply — Застосувати конфігурацію до ресурсу за назвою файлу або з stdin

6.11.3.5.2 - kubectl apply set-last-applied

Огляд

Встановлює останню last-applied-configuration анотацію, встановивши її, щоб відповідати вмісту файлу. Це призводить до того, що last-applied-configuration оновлюється так, ніби 'kubectl apply -f<file> ' було запущено без оновлення будь-яких інших частин обʼєкта.

kubectl apply set-last-applied -f FILENAME

Приклади

# Встановити last-applied-configuration ресурсу, щоб відповідати вмісту файлу
kubectl apply set-last-applied -f deploy.yaml

# Виконати set-last-applied для кожного файлу конфігурації у директорії
kubectl apply set-last-applied -f path/

# Встановити last-applied-configuration ресурсу, щоб відповідати вмісту файлу; створить анотацію, якщо вона ще не існує
kubectl apply set-last-applied -f deploy.yaml --create-annotation=true

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--create-annotation

Створить анотації 'last-applied-configuration', якщо поточні обʼєкти не мають таких анотацій

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

-f, --filename strings

Імʼя файлу, теки або URL до файлів, які містять анотації last-applied-configuration

-h, --help

довідка set-last-applied

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl apply — Застосувати конфігурацію до ресурсу за назвою файлу або з stdin

6.11.3.5.3 - kubectl apply view-last-applied

Огляд

Переглянути останні застосовані конфігурації за типом/іменем або файлом.

Стандартно вивід буде зроблено у stdout у форматі YAML. Ви можете змінити формат виводу за допомогою опції -o.

kubectl apply view-last-applied (TYPE [NAME | -l label] | TYPE/NAME | -f FILENAME)

Приклади

# Переглянути анотації last-applied-configuration за типом/імʼям у форматі YAML
kubectl apply view-last-applied deployment/nginx

# Переглянути анотації last-applied-configuration за файлом у форматі JSON
kubectl apply view-last-applied -f deploy.yaml -o json

Параметри

--all

Вибрати всі ресурси у просторі імен вказаних типів ресурсів.

-f, --filename strings

Імʼя файлу, теки або URL до файлів, що містить анотацію last-applied-configuration

-h, --help

довідка view-last-applied

-k, --kustomize string

Обробити теку kustomization. Цей прапорець не можна використовувати разом з -f або -R.

-o, --output string     Типово: "yaml"

Формат виводу. Має буьти одним з (yaml, json)

-R, --recursive

Рекурсивно обробити теку, вказану у -f, --filename. Корисно, якщо ви хочете керувати повʼязаними маніфестами, організованими в одній теці.

-l, --selector string

Селектор (запит на мітки) для фільтрації, що підтримує '=', '==' і '!=' (наприклад, -l key1=value1,key2=value2). Обʼєкти, щоб мати збіг, повинні задовольняти усім зазначеним обмеженням міток.

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl apply — Застосувати конфігурацію до ресурсу за назвою файлу або з stdin

6.11.3.6 - kubectl attach

Огляд

Приєднатися до процесу, який вже запущено всередині існуючого контейнера.

kubectl attach (POD | TYPE/NAME) -c CONTAINER

Приклади

# Отримати вивід з запущеного Podʼа mypod; використовуйте анотацію 'kubectl.kubernetes.io/default-container'
# для вибору контейнера, до якого потрібно приєднатися, або буде обрано перший контейнер у Podʼі
kubectl attach mypod

# Отримати вивід з контейнера ruby-container з Podʼа mypod
kubectl attach mypod -c ruby-container

# Перемкнутися в режим raw terminal; відправляє stdin в 'bash' у контейнері ruby-container з Podʼа mypod
# і відправляє stdout/stderr з 'bash' назад до клієнта
kubectl attach mypod -c ruby-container -i -t

# Отримати вивід з першого Podʼа replica set з назвою nginx
kubectl attach rs/nginx

Параметри

-c, --container string

Назва контейнера. Якщо не вказано, використовуйте анотацію kubectl.kubernetes.io/default-container для вибору контейнера, який буде приєднано, інакше буде обрано перший контейнер у Pod

-h, --help

довідка attach

--pod-running-timeout duration     Типово: 1m0s

Тривалість часу (наприклад, 5s, 2m або 3h, більше нуля) для очікування, поки не запрацює хоча б один Pod

-q, --quiet

Виводити дані лише з віддаленого сеансу

-i, --stdin

Передайте stdin в контейнер

-t, --tty

Stdin є TTY

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes

6.11.3.7 - kubectl auth

Огляд

Перевірка дозволів.

kubectl auth [flags]

Параметри

-h, --help

Довідка auth

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes
  • kubectl auth can-i — Перевірити, чи дозволена дія
  • kubectl auth reconcile — Узгоджує правила для обʼєктів ролі RBAC, привʼязки ролей, кластерної ролі та привʼязки кластерної ролі
  • kubectl auth whoami — Експериментально: Перевірити атрибути власного субʼєкта

6.11.3.7.1 - kubectl auth can-i

Огляд

Перевіряє, чи дозволена дія.

VERB — дієслово API Kubernetes, таке як 'get', 'list', 'watch', 'delete' тощо. TYPE — це ресурс Kubernetes. Скорочення та групи будуть розпізнані. NONRESOURCEURL — часткова URL-адреса, яка починається з "/". NAME — назва певного ресурсу Kubernetes. Ця команда чудово поєднується з імпровізацією. Дивіться глобальний прапорець --as.

kubectl auth can-i VERB [TYPE | TYPE/NAME | NONRESOURCEURL]

Приклади

# Перевірити, чи можу я створювати Podʼи в будь-якому просторі імен
kubectl auth can-i create pods --all-namespaces

# Перевірити, чи можу я переглядати списки deployment у моєму поточному просторі імен
kubectl auth can-i list deployments.apps

# Перевірити, чи може служюовий обліковий запис "foo" у просторі імен "dev" переглядати перелік Podʼів
# у просторі імен "prod"
# Ви повинні мати дозвіл на використання імперсонації для глобальної опції "--as"
kubectl auth can-i list pods --as=system:serviceaccount:dev:foo -n prod

# Перевірити, чи можу я виконувати всі дії в моєму поточному просторі імен ("*" означає все)
kubectl auth can-i '*' '*'

# Перевірити, чи можу я отримати завдання з назвою "bar" у просторі імен "foo"
kubectl auth can-i list jobs.batch/bar -n foo

# Перевірити, чи можу я читати логи Podʼів
kubectl auth can-i get pods --subresource=log

# Перевірити, чи можу я отримати доступ до URL /logs/
kubectl auth can-i get /logs/

# Перевірити, чи можу я затвердити certificates.k8s.io
kubectl auth can-i approve certificates.k8s.io

# Переглянути всі дозволені дії в просторі імен "foo"
kubectl auth can-i --list --namespace=foo

Параметри

-A, --all-namespaces

Якщо true, перевірити вказану дію в усіх просторах імен.

-h, --help

Довідка can-i

--list

Якщо true, виводить усі дозволені дії.

--no-headers

Якщо true, виводить дозволені дії без заголовків

-q, --quiet

Якщо true, заборонити вивід і просто повернути код результату.

--subresource string

SubResource, такі як pod/log або deployment/scale

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

6.11.3.7.2 - kubectl auth reconcile

Огляд

Узгодження правил для ролі RBAC, привʼязки ролі, ролі кластера та обʼєктів привʼязки ролі кластера.

Створюються відсутні обʼєкти, а для обʼєктів простору імен створюється відповідний простір імен, якщо потрібно.

Наявні ролі буде оновлено з урахуванням дозволів вхідних обʼєктів і вилучено зайві дозволи, якщо вказано --remove-extra-permissions.

Існуючі привʼязки буде оновлено до обʼєктів вхідних даних і вилучено зайві обʼєкти, якщо вказано --remove-extra-subjects.

Це бажано застосовувати для ресурсів RBAC, щоб забезпечити семантично усвідомлене обʼєднання правил і обʼєктів.

kubectl auth reconcile -f FILENAME

Приклади

# Узгодження ресурсів RBAC з файлу
kubectl auth reconcile -f my-rbac-rules.yaml

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

-f, --filename strings

Імʼя файлу, теки або URL до файлів, що ідентифікують ресурс для узгодження

-h, --help

Довідка reconcile

-k, --kustomize string

Обробити теку kustomization. Цей прапорець не можна використовувати разом з -f або -R.

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

-R, --recursive

Рекурсивно обробити теку, вказану у -f, --filename. Корисно, якщо ви хочете керувати повʼязаними маніфестами, організованими в одній теці.

--remove-extra-permissions

Якщо true, видаляє зайві дозволи, додані до ролей

--remove-extra-subjects

Якщо true, видаляє зайвих субʼєктів, доданих до rolebindings

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

6.11.3.7.3 - kubectl auth whoami

Огляд

Експериментально: Перевірте, хто ви і які у вас атрибути (групи, додаткові).

Ця команда корисна для ознайомлення з поточними атрибутами користувача, особливо якщо у кластері Kubernacle увімкнено динамічну автентифікацію, наприклад, вебхук, проксі-авторизацію або OIDC-провайдер, увімкнено в кластері Kubernetes.

kubectl auth whoami

Приклади

# Отримати атрибути вашого субʼєкта
kubectl auth whoami

# Отримати атрибути вашого субʼєкта у форматі JSON
kubectl auth whoami -o json

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

-h, --help

Довідка whoami

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

6.11.3.8 - kubectl autoscale

Огляд

Створює автомасштабувальник, який автоматично вибирає і встановлює кількість Podʼів, що запускаються в кластері Kubernetes.

Шукає deployment, replica set, stateful set або контролер реплікації за назвою і створює автомасштабувальник, який використовує даний ресурс як зразок. Автомасштабувальник може автоматично збільшувати або зменшувати кількість розгорнутих у системі Podʼів за потребою.

kubectl autoscale (-f FILENAME | TYPE NAME | TYPE/NAME) [--min=MINPODS] --max=MAXPODS [--cpu-percent=CPU]

Приклади

# Автоматично масштабувати deployment "foo" з кількістю Podʼів від 2 до 10, 
# цільове використання CPU не вказано, тому буде використано стандартну 
# політику автосмасштабування
kubectl autoscale deployment foo --min=2 --max=10

# Автоматично масштабувати контролер реплікації "foo" з кількістю Podʼів від 
# 1 до 5, цільове використання CPU на рівні 80%
kubectl autoscale rc foo --max=5 --cpu-percent=80

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--cpu-percent int32     Типово: -1

Цільове середнє використання CPU (представлене у відсотках від запитуваного CPU) для всіх Podʼів. Якщо він не вказаний або відʼємний, буде використано стандартну політику автомасштабування.

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--field-manager string     Типово: "kubectl-autoscale"

Імʼя менеджера, що використовується для відстеження права власності на поле.

-f, --filename strings

Імʼя файлу, теки або URL до файлів, що ідентифікують ресурс для автомасштабування

-h, --help

Довідка autoscale

-k, --kustomize string

Обробити теку kustomization. Цей прапорець не можна використовувати разом з -f або -R.

--max int32     Типово: -1

Верхня межа для кількості Podʼів, яку може встановити автомасштабування. Обовʼязково.

--min int32     Типово: -1

Нижня межа для кількості Podʼів, яка може бути встановлена автомасштабуванням. Якщо не вказано або значення відʼємне, сервер застосує стандартне значення.

--name string

Імʼя для новоствореного обʼєкта. Якщо не вказано, буде використано імʼя вхідного ресурсу.

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

-R, --recursive

Рекурсивно обробити теку, вказану у -f, --filename. Корисно, якщо ви хочете керувати повʼязаними маніфестами, організованими в одній теці.

--save-config

Якщо значення true, конфігурація поточного обʼєкта буде збережена в його анотації. В іншому випадку, анотацію буде збережено без змін. Цей прапорець корисно встановити, якщо ви хочете застосувати kubectl до цього обʼєкта у майбутньому.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl - kubectl керує менеджером кластерів Kubernetes

6.11.3.9 - kubectl certificate

Огляд

Зміна ресурсів сертифікатів.

kubectl certificate SUBCOMMAND

Параметри

-h, --help

Довідка certificate

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes
  • kubectl certificate approve — Схвалення запиту на підписання сертифіката
  • kubectl certificate deny — Відхилення запиту на підписання сертифіката

6.11.3.9.1 - kubectl certificate approve

Огляд

Схвалення запиту на підписання сертифіката.

kubectl certificate approve дозволяє адміністратору кластера затвердити запит на підписання сертифіката (CSR). Ця дія вказує контролеру підпису сертифікатів видати сертифікат запитувачу з атрибутами, вказаними у CSR.

ЗАСТЕРЕЖЕННЯ: Залежно від запитуваних атрибутів, виданий сертифікат потенційно може надати заявнику доступ до ресурсів кластера або автентифікацію в якості запитуваного облікового запису. Перш ніж затверджувати CSR, переконайтеся, що ви розумієте, що може робити підписаний сертифікат.

kubectl certificate approve (-f FILENAME | NAME)

Приклади

# Схвалити CSR 'csr-sqgzp'
kubectl certificate approve csr-sqgzp

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

-f, --filename strings

Імʼя файлу, теки або URL до файлів, що ідентифікують ресурс для оновленння

--force

Оновіть CSR, навіть якщо його вже затверджено.

-h, --help

Довідка approve

-k, --kustomize string

Обробити теку kustomization. Цей прапорець не можна використовувати разом з -f або -R.

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

-R, --recursive

Рекурсивно обробити теку, вказану у -f, --filename. Корисно, якщо ви хочете керувати повʼязаними маніфестами, організованими в одній теці.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

6.11.3.9.2 - kubectl certificate deny

Огляд

Відхилення запиту на підписання сертифіката.

kubectl certificate deny дозволяє адміністратору кластера відхилити запит на підписання сертифіката (CSR). Ця дія вказує контролеру підписання сертифікатів не видавати сертифікат запитувачу.

kubectl certificate deny (-f FILENAME | NAME)

Приклади

# Відхилити CSR 'csr-sqgzp'
kubectl certificate deny csr-sqgzp

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

-f, --filename strings

Імʼя файлу, теки або URL до файлів, що ідентифікують ресурс для оновленння

--force

Оновіть CSR, навіть якщо його вже відхилено.

-h, --help

Довідка deny

-k, --kustomize string

Обробити теку kustomization. Цей прапорець не можна використовувати разом з -f або -R.

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

-R, --recursive

Рекурсивно обробити теку, вказану у -f, --filename. Корисно, якщо ви хочете керувати повʼязаними маніфестами, організованими в одній теці.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

6.11.3.10 - kubectl cluster-info

Огляд

Виведіть адреси панелі управління та сервісів з міткою kubernetes.io/cluster-service=true. Для подальшого налагодження та діагностики проблем кластера використовуйте 'kubectl cluster-info dump'.

kubectl cluster-info [flags]

Приклади

# Вивести адресу панелі управління та сервісів кластера
kubectl cluster-info

Параметри

-h, --help

Довідка cluster-info

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes
  • kubectl cluster-info dump — створення дампу необхідної інформації для налагодження та діагностики

6.11.3.10.1 - kubectl cluster-info dump

Огляд

Виведення інформації про кластер, придатної для налагодження та діагностики проблем кластера. Стандартно все виводиться до stdout. За бажанням ви можете вказати теку за допомогою --output-directory. Якщо ви вкажете теку, Kubernetes створить набір файлів у цій теці. Типово команда виводить дані лише у поточному просторі імен та просторі імен "kube-system", але ви можете перемикнутися на інший простір імен за допомогою прапорця --namespaces або вказати --all-namespaces для виводу даних з усіх просторів імен.

Команда також виводить логи усіх pods у кластері; ці логи виводяться до різних тек, залежно від простору імен та назви pod.

kubectl cluster-info dump [flags]

Приклади

# Вивести поточний стан кластера до stdout
kubectl cluster-info dump

# Вивести поточний стан кластера до /path/to/cluster-state
kubectl cluster-info dump --output-directory=/path/to/cluster-state

# Вивести всі простори імен до stdout
kubectl cluster-info dump --all-namespaces

# Вивести набір просторів імен до /path/to/cluster-state
kubectl cluster-info dump --namespaces default,kube-system --output-directory=/path/to/cluster-state

Параметри

-A, --all-namespaces

Якщо true, перевірити вказану дію в усіх просторах імен.

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

-h, --help

Довідка dump

--namespaces strings

Список просторів імен для дампа через кому.

-o, --output string     Типово: "json"

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--output-directory string

Куди виводити файли. Якщо порожньо або '-' використовує stdout, інакше створює ієрархію тек у цій теці

--pod-running-timeout duration     Типово: 20s

Тривалість часу (наприклад, 5s, 2m або 3h, більше нуля) для очікування, поки не запрацює хоча б один Pod

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

6.11.3.11 - kubectl completion

Огляд

Вивести код завершення команд для вказаного командного інтерпретатора (bash, zsh, fish або powershell). Щоб забезпечити інтерактивне завершення команд kubectl, код оболонки слід опрацювати. Це можна зробити, отримавши його з .bash_profile.

Докладні інструкції про те, як це зробити, можна знайти тут:

для macOS:
https://kubernetes.io/docs/tasks/tools/install-kubectl-macos/#enable-shell-autocompletion
для linux:
https://kubernetes.io/docs/tasks/tools/install-kubectl-linux/#enable-shell-autocompletion
для windows:
https://kubernetes.io/docs/tasks/tools/install-kubectl-windows/#enable-shell-autocompletion

Примітка для користувачів zsh: [1] завершення zsh підтримуються лише у версіях zsh >= 5.2.

kubectl completion SHELL

Приклади

# Встановлення bash completion на macOS за допомогою homebrew
## Якщо використовується Bash 3.2, включений в macOS
brew install bash-completion
## або, якщо використовується Bash 4.1+
brew install bash-completion@2
## Якщо kubectl встановлено через homebrew, це повинно почати працювати негайно
## Якщо ви встановили іншими способами, можливо, вам потрібно додати completion до вашої теки completion
kubectl completion bash > $(brew --prefix)/etc/bash_completion.d/kubectl

# Встановлення bash completion на Linux
## Якщо bash-completion не встановлено на Linux, встановіть пакет 'bash-completion'
## через менеджер пакетів вашого дистрибутива.
## Завантажте код завершення kubectl для bash в поточну оболонку
source <(kubectl completion bash)
## Запишіть код завершення bash у файл і підключіть його з .bash_profile
kubectl completion bash > ~/.kube/completion.bash.inc
printf "
# kubectl shell completion
source '$HOME/.kube/completion.bash.inc'
" >> $HOME/.bash_profile
source $HOME/.bash_profile

# Завантажте код завершення kubectl для zsh[1] в поточну оболонку
source <(kubectl completion zsh)
# Налаштуйте код завершення kubectl для zsh[1], щоб автоматично завантажуватися при запуску
kubectl completion zsh > "${fpath[1]}/_kubectl"

# Завантажте код завершення kubectl для fish[2] в поточну оболонку
kubectl completion fish | source
# Щоб завантажити завершення для кожної сесії, виконайте один раз:
kubectl completion fish > ~/.config/fish/completions/kubectl.fish

# Завантажте код завершення kubectl для powershell в поточну оболонку
kubectl completion powershell | Out-String | Invoke-Expression
# Налаштуйте код завершення kubectl для powershell, щоб запускатися при старті
## Збережіть код завершення в сценарій і виконайте в профілі
kubectl completion powershell > $HOME\.kube\completion.ps1
Add-Content $PROFILE "$HOME\.kube\completion.ps1"
## Виконайте код завершення в профілі
Add-Content $PROFILE "if (Get-Command kubectl -ErrorAction SilentlyContinue) {
kubectl completion powershell | Out-String | Invoke-Expression
}"
## Додайте код завершення безпосередньо в сценарій $PROFILE
kubectl completion powershell >> $PROFILE

Параметри

-h, --help

Довідник completion

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes

6.11.3.12 - kubectl config

Огляд

Змінюйте файли kubeconfig за допомогою субкоманд на кшталт "kubectl config set current-context my-context".

Порядок завантаження відповідає наступним правилам:

  1. Якщо встановлено прапорець --kubeconfig, то завантажується лише цей файл. Прапорець може бути встановлений лише один раз і злиття не відбувається.
  2. Якщо встановлено змінну середовища $KUBECONFIG, то вона використовується як список шляхів (звичайні правила розмежування шляхів у вашій системі). Ці шляхи обʼєднуються. Коли значення змінюється, воно змінюється у файлі, який визначає строфу. Коли значення створюється, воно створюється у першому існуючому файлі. Якщо у ланцюжку не існує жодного файлу, то створюється останній файл у списку.
  3. В іншому випадку використовується ${HOME}/.kube/config і злиття не відбувається.
kubectl config SUBCOMMAND

Параметри

-h, —-help

Довідник config

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, —-namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, —-server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, —-version=raw виводить інформацію про версію та завершує роботу; —-version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

6.11.3.12.1 - kubectl config current-context

Огляд

Показ поточного контексту.

kubectl config current-context [flags]

Приклади

# Показ поточного контексту
kubectl config current-context

Параметри

-h, --help

Довідка current-context

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

6.11.3.12.2 - kubectl config delete-cluster

Огляд

Видалити вказаний кластер з kubeconfig.

kubectl config delete-cluster NAME

Приклади

# Видалити кластер minikube з kubeconfig
kubectl config delete-cluster minikube
-h, --help

Довідка delete-cluster

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

6.11.3.12.3 - kubectl config delete-context

Огляд

Видалити вказаний контекст з kubeconfig.

kubectl config delete-context NAME

Приклади

# Видалити контекст для кластера minikube
kubectl config delete-context minikube

Параметри

-h, --help

Довідка delete-context

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

6.11.3.12.4 - kubectl config delete-user

Огляд

Видалити вказаного користувача з kubeconfig.

kubectl config delete-user NAME

Приклади

# Видалити користувача minikube
kubectl config delete-user minikube

Параметри

-h, --help

Довідка delete-user

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

6.11.3.12.5 - kubectl config get-clusters

Огляд

Показати кластери, визначені в kubeconfig.

kubectl config get-clusters [flags]

Приклади

# Вивести перелік кластерів, які відомі kubectl
kubectl config get-clusters

Параметри

-h, --help

Довідка get-clusters

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

6.11.3.12.6 - kubectl config get-contexts

Огляд

Показати один або декілька контекстів з файлу kubeconfig.

kubectl config get-contexts [(-o|--output=)name)]

Приклади

# Показати перелік всіх контекстів з файлу kubeconfig
kubectl config get-contexts

# Показати опис одного контексту з файлу kubeconfig
kubectl config get-contexts my-context

Параметри

-h, --help

Довідка get-contexts

--no-headers

При використанні стандартного або власного формату виводу стовпців не друкувати заголовки (заголовки стандартно друкуються).

-o, --output string

Формат виводу. Один з: (name).

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

6.11.3.12.7 - kubectl config get-users

Огляд

Показує користувачів, визначених у kubeconfig.

kubectl config get-users [flags]

Приклади

# Перелік користувачів, відомих kubectl
kubectl config get-users

Параметри

-h, --help

Довідка get-users

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

6.11.3.12.8 - kubectl config rename-context

Огляд

Перейменовує контекст з файлу kubeconfig.

CONTEXT_NAME — назва контексту, яку ви хочете змінити.

NEW_NAME — нова назва, яку ви хочете встановити.

Примітка: Якщо контекст, який перейменовується, є "поточним контекстом", це поле також буде оновлено.

kubectl config rename-context CONTEXT_NAME NEW_NAME

Приклади

# Перейменуйте контекст 'old-name' на 'new-name' у вашому файлі kubeconfig
kubectl config rename-context old-name new-name

Параметри

-h, --help

Довідка rename-context

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

6.11.3.12.9 - kubectl config set

Огляд

Встановлює індивідуальне значення у файлі kubeconfig.

PROPERTY_NAME — це імʼя, розділене крапками, де кожен токен представляє або імʼя атрибута, або ключ map. Ключі map можуть не містити крапок.

PROPERTY_VALUE — нове значення, яке ви хочете встановити. Двійкові поля, такі як 'certificate-authority-data', очікують рядок у кодуванні base64, якщо не використовується прапорець --set-raw-bytes.

Якщо вказати імʼя атрибута, яке вже існує, нові поля буде додано до наявних значень.

kubectl config set PROPERTY_NAME PROPERTY_VALUE

Приклади

# Встановити поле server для кластера my-cluster на https://1.2.3.4
kubectl config set clusters.my-cluster.server https://1.2.3.4

# Встановити поле certificate-authority-data для кластера my-cluster
kubectl config set clusters.my-cluster.certificate-authority-data $(echo "cert_data_here" | base64 -i -)

# Встановити поле cluster в контексті my-context на my-cluster
kubectl config set contexts.my-context.cluster my-cluster

# Встановити поле client-key-data для користувача cluster-admin з використанням опції --set-raw-bytes
kubectl config set users.cluster-admin.client-key-data cert_data_here --set-raw-bytes=true

Параметри

-h, --help

Довідка set

--set-raw-bytes tristate[=true]

При записі []byte PROPERTY_VALUE, записувати заданий рядок так як є, без декодування base64.

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

6.11.3.12.10 - kubectl config set-cluster

Огляд

Встановлює запис кластера у kubeconfig.

Якщо вказати назву, яка вже існує, нові поля буде обʼєднано з наявними значеннями для цих полів.

kubectl config set-cluster NAME [--server=server] [--certificate-authority=path/to/certificate/authority] [--insecure-skip-tls-verify=true] [--tls-server-name=example.com]

Приклади

# Встановити тільки поле server для запису кластера e2e без змін інших значень
kubectl config set-cluster e2e --server=https://1.2.3.4

# Вбудувати дані CA для запису кластера e2e
kubectl config set-cluster e2e --embed-certs --certificate-authority=~/.kube/e2e/kubernetes.ca.crt

# Вимкнути перевірку сертифікатів для запису кластера e2e
kubectl config set-cluster e2e --insecure-skip-tls-verify=true

# Встановити власне імʼя сервера TLS для перевірки для запису кластера e2e
kubectl config set-cluster e2e --tls-server-name=my-cluster-name

# Встановити URL проксі для запису кластера e2e
kubectl config set-cluster e2e --proxy-url=https://1.2.3.4

Параметри

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--embed-certs tristate[=true]

embed-certs для запису кластера в kubeconfig

-h, --help

Довідка set-cluster

--insecure-skip-tls-verify tristate[=true]

insecure-skip-tls-verify для запису кластера в kubeconfig

--proxy-url string

proxy-url для запису кластера в kubeconfig

--server string

server для запису кластера в kubeconfig

--tls-server-name string

tls-server-name ля запису кластера в kubeconfig

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

6.11.3.12.11 - kubectl config set-context

Огляд

Встановлює запис контексту у kubeconfig.

Якщо вказати назву, яка вже існує, нові поля буде обʼєднано з наявними значеннями для цих полів.

kubectl config set-context [NAME | --current] [--cluster=cluster_nickname] [--user=user_nickname] [--namespace=namespace]

Приклади

# Встановіть поле користувача у записі контексту gce, не змінюючи інших значень
kubectl config set-context gce --user=cluster-admin

Параметри

--cluster string

cluster для запису контексту в kubeconfig

--current

Змінити поточний контекст

-h, --help

Довідка set-context

--namespace string

namespace для запису контексту в kubeconfig

--user string

user для запису контексту в kubeconfig

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

6.11.3.12.12 - kubectl config set-credentials

Огляд

Задайте запис user у kubeconfig.

Якщо вказати імʼя, яке вже існує, нові поля буде обʼєднано з наявними значеннями.

Прапорці клієнтського сертифіката:
--client-certificate=certfile --client-key=keyfile
Прапорці токенів на предʼявника:
--token=bearer_token
Базові прапорці авторизації:
--username=базовий_користувач --password=базовий_пароль

Токен на предʼявника та базова авторизація є взаємозаперечними.

kubectl config set-credentials NAME [--client-certificate=path/to/certfile] [--client-key=path/to/keyfile] [--token=bearer_token] [--username=basic_user] [--password=basic_password] [--auth-provider=provider_name] [--auth-provider-arg=key=value] [--exec-command=exec_command] [--exec-api-version=exec_api_version] [--exec-arg=arg] [--exec-env=key=value]

Приклади

# Встановити тільки поле "client-key" для запису "cluster-admin"
# без змін інших значень
kubectl config set-credentials cluster-admin --client-key=~/.kube/admin.key

# Встановити базову автентифікацію для запису "cluster-admin"
kubectl config set-credentials cluster-admin --username=admin --password=uXFGweU9l35qcif

# Вбудувати дані сертифіката клієнта для запису "cluster-admin"
kubectl config set-credentials cluster-admin --client-certificate=~/.kube/admin.crt --embed-certs=true

# Увімкнути провайдера автентифікації Google Compute Platform для запису "cluster-admin"
kubectl config set-credentials cluster-admin --auth-provider=gcp

# Увімкнути провайдера автентифікації OpenID Connect для запису "cluster-admin" з додатковими аргументами
kubectl config set-credentials cluster-admin --auth-provider=oidc --auth-provider-arg=client-id=foo --auth-provider-arg=client-secret=bar

# Видалити значення конфігурації "client-secret" для провайдера автентифікації OpenID Connect для запису "cluster-admin"
kubectl config set-credentials cluster-admin --auth-provider=oidc --auth-provider-arg=client-secret-

# Увімкнути новий втулок автентифікації exec для запису "cluster-admin"
kubectl config set-credentials cluster-admin --exec-command=/path/to/the/executable --exec-api-version=client.authentication.k8s.io/v1beta1

# Увімкнути новий втулок автентифікації exec для запису "cluster-admin" з інтерактивним режимом
kubectl config set-credentials cluster-admin --exec-command=/path/to/the/executable --exec-api-version=client.authentication.k8s.io/v1beta1 --exec-interactive-mode=Never

# Визначити нові аргументи для втулка автентифікації exec для запису "cluster-admin"
kubectl config set-credentials cluster-admin --exec-arg=arg1 --exec-arg=arg2

# Створити або оновити змінні середовища для втулка автентифікації exec для запису "cluster-admin"
kubectl config set-credentials cluster-admin --exec-env=key1=val1 --exec-env=key2=val2

# Видалити змінні середовища для втулка автентифікації exec для запису "cluster-admin"
kubectl config set-credentials cluster-admin --exec-env=var-to-remove-

Параметри

--auth-provider string

Провайдер авторизації/автентифікації для запису користувача у kubeconfig

--auth-provider-arg strings

аргументи 'key=value' для провайдера авторизації/автентифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для запису користувача у kubeconfig

--client-key string

Шлях до файлу ключа клієнта для запису користувача у kubeconfig

--embed-certs tristate[=true]

Додати клієнтський сертифікат/ключ для входу користувача у kubeconfig

--exec-api-version string

Версія API втулка exec credential для запису користувача у kubeconfig

--exec-arg strings

Нові аргументи команди втулка exec credential для запису користувача у kubeconfig

--exec-command string

Команди втулка exec credential для запису користувача у kubeconfig

--exec-env strings

'key=value' значеня зміних оточення для втулка exec credential

--exec-interactive-mode string

Режим InteractiveMode втулка exec credentials для запису користувача у kubeconfig

--exec-provide-cluster-info tristate[=true]

ProvideClusterInfo втулка exec credentials для запису користувача у kubeconfig

-h, --help

Довідка set-credentials

--password string

Пароль для запису користувача у kubeconfig

--token string

Токен для запису користувача у kubeconfig

--username string

Імʼя користувачадля запису користувача у kubeconfig

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

6.11.3.12.13 - kubectl config unset

Огляд

Скинути окреме значення у файлі kubeconfig.

PROPERTY_NAME — це імʼя, розділене крапками, де кожен токен представляє або імʼя атрибута, або ключ map. Ключі map можуть не містити крапок.

kubectl config unset PROPERTY_NAME

Приклади

# Видалити поточний контекст
kubectl config unset current-context

# Видалити простір імен у контексті foo
kubectl config unset contexts.foo.namespace

Параметри

-h, --help

Довідка unset

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

6.11.3.12.14 - kubectl config use-context

Огляд

Встановлює current-context у файлі kubeconfig.

kubectl config use-context CONTEXT_NAME

Приклади

# Використання контексту для кластера minikube
kubectl config use-context minikube

Параметри

-h, --help

Довідка use-context

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

6.11.3.12.15 - kubectl config view

Огляд

Показує обʼєднану конфігурацію kubeconfig або вказаний файл kubeconfig.

Ви можете використовувати --output jsonpath={...} для вибору конкретних полів конфігурації.

kubectl config view [options]

Приклади

# Показати обʼєднані налаштування kubeconfig
kubectl config view

# Показати обʼєднані налаштування kubeconfig, необроблені дані сертифіката та показати секрети
kubectl config view --raw

# Отримати пароль для користувача e2e
kubectl config view -o jsonpath='{.users[?(@.name == "e2e")].user.password}'

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--flatten

Спростити отриманий файл kubeconfig до окремого вихідного файлу (корисно для створення переносних файлів kubeconfig)

-h, --help

Довідка view

--merge tristate[=true]     Типово: true

Обʼєднати повну ієрархію файлів kubeconfig

--minify

Вилучити з виводу всю інформацію, яка не використовується в current-context

-o, --output string     Типово: "json"

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--raw

Показувати необроблені байт-дані та конфіденційні дані

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

6.11.3.13 - kubectl cordon

Огляд

Позначає вузол як не придатний для планування.

kubectl cordon NODE
# Позначити вузол "foo" як не придатний для планування
kubectl cordon foo

Параметри

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

-h, --help

Довідка cordon

-l, --selector string

Селектор (запит на мітки) для фільтрації, що підтримує '=', '==' і '!=' (наприклад, -l key1=value1,key2=value2). Обʼєкти, щоб мати збіг, повинні задовольняти усім зазначеним обмеженням міток.

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes

6.11.3.14 - kubectl cp

Огляд

Копіювання файлів і тек до контейнерів та з них.

kubectl cp <file-spec-src> <file-spec-dest>

Приклади

# !!!Увага!!!
# Вимагає наявності двійкового файлу 'tar' у вашому контейнері.
# Якщо 'tar' відсутній, 'kubectl cp' не вдасться виконати.
#
# Для розширених випадків використання, таких як символічні посилання, розширення
# шаблонів або збереження режиму файлу, розгляньте можливість використання 'kubectl exec'.

# Скопіювати локальний файл /tmp/foo до /tmp/bar у віддаленому Pod в просторі імен <some-namespace>
tar cf - /tmp/foo | kubectl exec -i -n <some-namespace> <some-pod> -- tar xf - -C /tmp/bar

# Скопіювати /tmp/foo з віддаленого Pod до /tmp/bar локально
kubectl exec -n <some-namespace> <some-pod> -- tar cf - /tmp/foo | tar xf - -C /tmp/bar

# Скопіювати локальну теку /tmp/foo_dir до /tmp/bar_dir у віддаленому Pod в стандартному просторі імен
kubectl cp /tmp/foo_dir <some-pod>:/tmp/bar_dir

# Скопіювати локальний файл /tmp/foo до /tmp/bar у віддаленому Pod у конкретному контейнері
kubectl cp /tmp/foo <some-pod>:/tmp/bar -c <specific-container>

# Скопіювати локальний файл /tmp/foo до /tmp/bar у віддаленому Pod в просторі імен <some-namespace>
kubectl cp /tmp/foo <some-namespace>/<some-pod>:/tmp/bar

# Скопіювати /tmp/foo з віддаленого Pod до /tmp/bar локально
kubectl cp <some-namespace>/<some-pod>:/tmp/foo /tmp/bar

Параметри

-c, --container string

Назва контейнера. Якщо не вказано, використовуйте анотацію kubectl.kubernetes.io/default-container для вибору контейнера, який буде приєднано, інакше буде обрано перший контейнер у Pod

-h, --help

Довідка cp

--no-preserve

Права власності та дозволи на скопійований файл/теку не будуть збережені в контейнері

--retries int

Вказати кількість спроб для завершення операції копіювання з контейнера. Вкажіть 0 для вимкнення або будь-яке відʼємне значення для нескінченної кількості спроб. Стандартне значення — 0 (без повторних спроб).

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes

6.11.3.15 - kubectl create

Огляд

Створити ресурс з файлу або з stdin.

Приймаються формати JSON та YAML.

kubectl create -f FILENAME

Приклади

# Створити Pod з використанням даних з pod.json
kubectl create -f ./pod.json

# Створити Pod на основі JSON, переданого у стандартний ввід
cat pod.json | kubectl create -f -

# Редагувати дані у registry.yaml у форматі JSON, а потім створити ресурс з використанням відредагованих даних
kubectl create -f registry.yaml --edit -o json

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--edit

Відредагувати ресурс API перед створенням

--field-manager string     Типово: "kubectl-create"

Імʼя менеджера, що використовується для відстеження права власності на поле.

-f, --filename strings

Імʼя файлу, теки або URL до файлів, що використовуються для створення ресурсу

-h, --help

Довідка create

-k, --kustomize string

Обробити теку kustomization. Цей прапорець не можна використовувати разом з -f або -R.

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--raw string

Необроблений URI для POST на сервер. Використовує транспорт, вказаний у файлі kubeconfig.

-R, --recursive

Рекурсивно обробити теку, вказану у -f, --filename. Корисно, якщо ви хочете керувати повʼязаними маніфестами, організованими в одній теці.

--save-config

Якщо значення true, конфігурація поточного обʼєкта буде збережена в його анотації. В іншому випадку, анотацію буде збережено без змін. Цей прапорець корисно встановити, якщо ви хочете застосувати kubectl до цього обʼєкта у майбутньому.

-l, --selector string

Селектор (запит на мітки) для фільтрації, що підтримує '=', '==' і '!=' (наприклад, -l key1=value1,key2=value2). Обʼєкти, щоб мати збіг, повинні задовольняти усім зазначеним обмеженням міток.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--validate string[="strict"]     Типово: "strict"

Повинно бути одним із: strict (або true), warn, ignore (або false).

"true" або "strict" буде використовувати схему для перевірки вводу і відхилятиме запит, якщо він невірний. Буде виконана перевірка на стороні сервера, якщо ServerSideFieldValidation увімкнено на api-server, але якщо ні, то повернеться до менш надійної перевірки на стороні клієнта.

"warn" попередить про невідомі або повторювані поля, не блокуючи запит, якщо на боці сервера API увімкнено перевірку полів, і буде поводитися як " ignore" у протилежному випадку.

"false" або "ignore" не виконуватимуть жодної перевірки схеми, мовчки відкидаючі будь-які невідомі або дубльовані поля.

--windows-line-endings

Має значення лише якщо --edit=true. Стандартно використовується закінчення рядка, притаманне вашій платформі.

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

6.11.3.15.1 - kubectl create clusterrole

Огляд

Створення кластерної ролі.

kubectl create clusterrole NAME --verb=verb --resource=resource.group [--resource-name=resourcename] [--dry-run=server|client|none]

Приклади

# Створити кластерну роль з назвою "pod-reader", яка дозволяє користувачу виконувати "get", "watch" та "list" для Podʼів
kubectl create clusterrole pod-reader --verb=get,list,watch --resource=pods

# Створити кластерну роль з назвою "pod-reader" із вказаними іменами ресурсів
kubectl create clusterrole pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod

# Створити кластерну роль з назвою "foo" із вказаною API Group
kubectl create clusterrole foo --verb=get,list,watch --resource=rs.apps

# Створити кластерну роль з назвою "foo" із вказаним субресурсом
kubectl create clusterrole foo --verb=get,list,watch --resource=pods,pods/status

# Створити кластерну роль з назвою "foo" із вказаним NonResourceURL
kubectl create clusterrole "foo" --verb=get --non-resource-url=/logs/*

# Створити кластерну роль з назвою "monitoring" із вказаним правилом агрегації
kubectl create clusterrole monitoring --aggregation-rule="rbac.example.com/aggregate-to-monitoring=true"

Параметри

--aggregation-rule <пари 'ключ=значення', розділені комами>

Селектор міток агрегації для обʼєднання ClusterRoles.

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--field-manager string     Типово: "kubectl-create"

Імʼя менеджера, що використовується для відстеження права власності на поле.

-h, --help

Довідка clusterrole

--non-resource-url strings

Частковий URL, до якого користувач повинен мати доступ.

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--resource strings

Ресурс, до якого застосовується правило

--resource-name strings

Ресурс у білому списку, до якого застосовується правило, повторіть цей прапорець для кожного елемента

--save-config

Якщо значення true, конфігурація поточного обʼєкта буде збережена в його анотації. В іншому випадку, анотацію буде збережено без змін. Цей прапорець корисно встановити, якщо ви хочете застосувати kubectl до цього обʼєкта у майбутньому.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--validate string[="strict"]     Типово: "strict"

Повинно бути одним із: strict (або true), warn, ignore (або false).

"true" або "strict" буде використовувати схему для перевірки вводу і відхилятиме запит, якщо він невірний. Буде виконана перевірка на стороні сервера, якщо ServerSideFieldValidation увімкнено на api-server, але якщо ні, то повернеться до менш надійної перевірки на стороні клієнта.

"warn" попередить про невідомі або повторювані поля, не блокуючи запит, якщо на боці сервера API увімкнено перевірку полів, і буде поводитися як " ignore" у протилежному випадку.

"false" або "ignore" не виконуватимуть жодної перевірки схеми, мовчки відкидаючі будь-які невідомі або дубльовані поля.

--verb strings

Дієслово, яке застосовується до ресурсів, що містяться в правилі

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl create — Створення ресурсу з файлу або зі stdin

6.11.3.15.2 - kubectl create clusterrolebinding

Огляд

Створення привʼязки кластерної ролі для певної кластерної ролі.

kubectl create clusterrolebinding NAME --clusterrole=NAME [--user=username] [--group=groupname] [--serviceaccount=namespace:serviceaccountname] [--dry-run=server|client|none]

Приклади

# Створити привʼязування кластерної ролі для user1, user2 та group1, використовуючи кластерну роль cluster-admin
kubectl create clusterrolebinding cluster-admin --clusterrole=cluster-admin --user=user1 --user=user2 --group=group1

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--clusterrole string

ClusterRole на яку повинна посилатися привʼязка ClusterRoleBinding

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--field-manager string     Типово: "kubectl-create"

Імʼя менеджера, що використовується для відстеження права власності на поле.

--group strings

Групи для привʼязки до кластерної ролі. Прапорець можна повторити, щоб додати кілька груп.

-h, --help

Довідка clusterrolebinding

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--save-config

Якщо значення true, конфігурація поточного обʼєкта буде збережена в його анотації. В іншому випадку, анотацію буде збережено без змін. Цей прапорець корисно встановити, якщо ви хочете застосувати kubectl до цього обʼєкта у майбутньому.

--serviceaccount strings

Службові облікові записи для привʼязки до кластерної ролі, у форматі <простір імен>:<імʼя>. Прапорець можна повторювати для додавання декількох службових облікових записів.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--user strings

Імена користувачів для привʼязки до кластерної ролі. Прапорець можна повторити, щоб додати кількох користувачів.

--validate string[="strict"]     Типово: "strict"

Повинно бути одним із: strict (або true), warn, ignore (або false).

"true" або "strict" буде використовувати схему для перевірки вводу і відхилятиме запит, якщо він невірний. Буде виконана перевірка на стороні сервера, якщо ServerSideFieldValidation увімкнено на api-server, але якщо ні, то повернеться до менш надійної перевірки на стороні клієнта.

"warn" попередить про невідомі або повторювані поля, не блокуючи запит, якщо на боці сервера API увімкнено перевірку полів, і буде поводитися як " ignore" у протилежному випадку.

"false" або "ignore" не виконуватимуть жодної перевірки схеми, мовчки відкидаючі будь-які невідомі або дубльовані поля.

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl create — Створення ресурсу з файлу або зі stdin

6.11.3.15.3 - kubectl create configmap

Огляд

Створює ConfigMap на основі файлу, теки або вказаного літерального значення.

Один ConfigMap може містити одну або декілька пар ключ/значення.

При створенні ConfigMap на основі файлу, стандартним значенням ключа буде імʼя файлу, а значенням — його вміст. Якщо назва файлу є невірним ключем, ви можете вказати альтернативний ключ.

При створенні ConfigMap на основі теки кожен файл, назва якого є допустимим ключем у теці, буде запаковано до ConfigMap. Будь-які записи у теці, окрім звичайних файлів, ігноруються (наприклад, субтеки, символічні посилання, пристрої, канали й т.д.).

kubectl create configmap NAME [--from-file=[key=]source] [--from-literal=key1=value1] [--dry-run=server|client|none]

Приклади

# Створити новий ConfigMap з назвою my-config на основі теки bar
kubectl create configmap my-config --from-file=path/to/bar

# Створити новий ConfigMap з назвою my-config із вказаними ключами замість імен файлів на диску
kubectl create configmap my-config --from-file=key1=/path/to/bar/file1.txt --from-file=key2=/path/to/bar/file2.txt

# Створити новий ConfigMap з назвою my-config із ключами key1=config1 і key2=config2
kubectl create configmap my-config --from-literal=key1=config1 --from-literal=key2=config2

# Створити новий ConfigMap з назвою my-config із пар ключ=значення у файлі
kubectl create configmap my-config --from-file=path/to/bar

# Створити новий ConfigMap з назвою my-config із файлу зі змінними середовища
kubectl create configmap my-config --from-env-file=path/to/foo.env --from-env-file=path/to/bar.env

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--append-hash

Додайте хеш configmap до назви configmap.

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--field-manager string     Типово: "kubectl-create"

Імʼя менеджера, що використовується для відстеження права власності на поле.

--from-env-file strings

Вкажіть шлях до файлу для отримання рядків з парами key=val для створення configmap.

--from-file strings

Файл ключа можна вказати за допомогою шляху до файлу, у цьому випадку імʼя файлу буде використано як ключ configmap, або за допомогою ключа і шляху до файлу, у цьому випадку буде використано заданий ключ. Якщо вказати теку, буде виконано ітерацію для кожного названого файлу у цій теці, імʼя якого є допустимим ключем configmap.

--from-literal strings

Вкажіть ключ і літеральне значення для вставки в configmap (тобто mykey=somevalue)

-h, --help

Довідка configmap

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--save-config

Якщо значення true, конфігурація поточного обʼєкта буде збережена в його анотації. В іншому випадку, анотацію буде збережено без змін. Цей прапорець корисно встановити, якщо ви хочете застосувати kubectl до цього обʼєкта у майбутньому.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--validate string[="strict"]     Типово: "strict"

Повинно бути одним із: strict (або true), warn, ignore (або false).

"true" або "strict" буде використовувати схему для перевірки вводу і відхилятиме запит, якщо він невірний. Буде виконана перевірка на стороні сервера, якщо ServerSideFieldValidation увімкнено на api-server, але якщо ні, то повернеться до менш надійної перевірки на стороні клієнта.

"warn" попередить про невідомі або повторювані поля, не блокуючи запит, якщо на боці сервера API увімкнено перевірку полів, і буде поводитися як " ignore" у протилежному випадку.

"false" або "ignore" не виконуватимуть жодної перевірки схеми, мовчки відкидаючі будь-які невідомі або дубльовані поля.

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl create — Створення ресурсу з файлу або зі stdin

6.11.3.15.4 - kubectl create cronjob

Огляд

Створіть завдання cron із зазначеним імʼям.

kubectl create cronjob NAME --image=image --schedule='0/5 * * * ?' -- [COMMAND] [args...] [flags]

Приклади

# Створити крон-завдання
kubectl create cronjob my-job --image=busybox --schedule="*/1 * * * *"

# Створити крон-завдання з командою
kubectl create cronjob my-job --image=busybox --schedule="*/1 * * * *" -- date

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--field-manager string     Типово: "kubectl-create"

Імʼя менеджера, що використовується для відстеження права власності на поле.

-h, --help

Довідка cronjob

--image string

Назва образу контейнера для запуску.

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--restart string

Політика перезапуску job. Підтримувані значення: OnFailure, Never

--save-config

Якщо значення true, конфігурація поточного обʼєкта буде збережена в його анотації. В іншому випадку, анотацію буде збережено без змін. Цей прапорець корисно встановити, якщо ви хочете застосувати kubectl до цього обʼєкта у майбутньому.

--schedule string

Розклад у форматі Cron, за яким має виконуватися завдання.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--validate string[="strict"]     Типово: "strict"

Повинно бути одним із: strict (або true), warn, ignore (або false).

"true" або "strict" буде використовувати схему для перевірки вводу і відхилятиме запит, якщо він невірний. Буде виконана перевірка на стороні сервера, якщо ServerSideFieldValidation увімкнено на api-server, але якщо ні, то повернеться до менш надійної перевірки на стороні клієнта.

"warn" попередить про невідомі або повторювані поля, не блокуючи запит, якщо на боці сервера API увімкнено перевірку полів, і буде поводитися як " ignore" у протилежному випадку.

"false" або "ignore" не виконуватимуть жодної перевірки схеми, мовчки відкидаючі будь-які невідомі або дубльовані поля.

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl create — Створення ресурсу з файлу або зі stdin

6.11.3.15.5 - kubectl create deployment

Огляд

Створює deployment із зазначеним іменем.

kubectl create deployment NAME --image=image -- [COMMAND] [args...]

Приклади

# Створити deployment з назвою my-dep, що використовує образ busybox
kubectl create deployment my-dep --image=busybox

# Створити deployment з командою
kubectl create deployment my-dep --image=busybox -- date

# Створити deployment з назвою my-dep, що використовує образ nginx з 3 репліками
kubectl create deployment my-dep --image=nginx --replicas=3

# Створити deployment з назвою my-dep, що використовує образ busybox і відкриває порт 5701
kubectl create deployment my-dep --image=busybox --port=5701

# Створити deployment з назвою my-dep, що містить декілька контейнерів
kubectl create deployment my-dep --image=busybox:latest --image=ubuntu:latest --image=nginx

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--field-manager string     Типово: "kubectl-create"

Імʼя менеджера, що використовується для відстеження права власності на поле.

-h, --help

Довідка deployment

--image strings

Назви образів для запуску. Deployment може містити кілька образів для багатоконтейнерних pod.

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--port int32     Типово: -1

Порт containerPort, який цей deployment експонує.

-r, --replicas int32     Типово: 1

Кількість реплік для створення. Стандартно дорівнює 1.

--save-config

Якщо значення true, конфігурація поточного обʼєкта буде збережена в його анотації. В іншому випадку, анотацію буде збережено без змін. Цей прапорець корисно встановити, якщо ви хочете застосувати kubectl до цього обʼєкта у майбутньому.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--validate string[="strict"]     Типово: "strict"

Повинно бути одним із: strict (або true), warn, ignore (або false).

"true" або "strict" буде використовувати схему для перевірки вводу і відхилятиме запит, якщо він невірний. Буде виконана перевірка на стороні сервера, якщо ServerSideFieldValidation увімкнено на api-server, але якщо ні, то повернеться до менш надійної перевірки на стороні клієнта.

"warn" попередить про невідомі або повторювані поля, не блокуючи запит, якщо на боці сервера API увімкнено перевірку полів, і буде поводитися як " ignore" у протилежному випадку.

"false" або "ignore" не виконуватимуть жодної перевірки схеми, мовчки відкидаючі будь-які невідомі або дубльовані поля.

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl create — Створення ресурсу з файлу або зі stdin

6.11.3.15.6 - kubectl create ingress

Огляд

Створює ingress із зазначеною назвою.

kubectl create ingress NAME --rule=host/path=service:port[,tls[=secret]] 

Приклади

# Створити один ingress з назвою 'simple', який направляє запити з foo.com/bar на svc1:8080 з TLS-сертифікатом "my-cert"
kubectl create ingress simple --rule="foo.com/bar=svc1:8080,tls=my-cert"

# Створити ingress, який захоплює усі шляхи "/path" і направляє їх на сервіс svc:port з класом ingress "otheringress"
kubectl create ingress catch-all --class=otheringress --rule="/path=svc:port"

# Створити ingress з двома анотаціями: ingress.annotation1 і ingress.annotations2
kubectl create ingress annotated --class=default --rule="foo.com/bar=svc:port" \
--annotation ingress.annotation1=foo \
--annotation ingress.annotation2=bla

# Створити ingress з тим же хостом і декількома шляхами
kubectl create ingress multipath --class=default \
--rule="foo.com/=svc:port" \
--rule="foo.com/admin/=svcadmin:portadmin"

# Створити ingress з декількома хостами і типом шляху як Prefix
kubectl create ingress ingress1 --class=default \
--rule="foo.com/path*=svc:8080" \
--rule="bar.com/admin*=svc2:http"

# Створити ingress з увімкненим TLS, використовуючи стандартний сертифікат ingress і різними типами шляхів
kubectl create ingress ingtls --class=default \
--rule="foo.com/=svc:https,tls" \
--rule="foo.com/path/subpath*=othersvc:8080"

# Створити ingress з увімкненим TLS, використовуючи конкретний секрет і типом шляху як Prefix
kubectl create ingress ingsecret --class=default \
--rule="foo.com/*=svc:8080,tls=secret1"

# Створити ingress зі стандартним бекендом
kubectl create ingress ingdefault --class=default \
--default-backend=defaultsvc:http \
--rule="foo.com/*=svc:8080,tls=secret1"

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--annotation strings

Анотація для вставки в обʼєкт ingress у форматі annotation=value

--class string

Ingress Class що буде використано

--default-backend string

Стандартний сервіс бекенду, у форматі svcname:port

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--field-manager string     Типово: "kubectl-create"

Імʼя менеджера, що використовується для відстеження права власності на поле.

-h, --help

Довідка ingress

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--rule strings

Правило у форматі host/path=service:port[,tls=secretname]. Шляхи, що містять початковий символ '*', вважаються pathType=Prefix. tls — необовʼязковий аргумент.

--save-config

Якщо значення true, конфігурація поточного обʼєкта буде збережена в його анотації. В іншому випадку, анотацію буде збережено без змін. Цей прапорець корисно встановити, якщо ви хочете застосувати kubectl до цього обʼєкта у майбутньому.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--validate string[="strict"]     Типово: "strict"

Повинно бути одним із: strict (або true), warn, ignore (або false).

"true" або "strict" буде використовувати схему для перевірки вводу і відхилятиме запит, якщо він невірний. Буде виконана перевірка на стороні сервера, якщо ServerSideFieldValidation увімкнено на api-server, але якщо ні, то повернеться до менш надійної перевірки на стороні клієнта.

"warn" попередить про невідомі або повторювані поля, не блокуючи запит, якщо на боці сервера API увімкнено перевірку полів, і буде поводитися як " ignore" у протилежному випадку.

"false" або "ignore" не виконуватимуть жодної перевірки схеми, мовчки відкидаючі будь-які невідомі або дубльовані поля.

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl create — Створення ресурсу з файлу або зі stdin

6.11.3.15.7 - kubectl create job

Огляд

Створює job з вказаним іменем.

kubectl create job NAME --image=image [--from=cronjob/name] -- [COMMAND] [args...]

Приклади

# Створити задачу (job)
kubectl create job my-job --image=busybox

# Створити задачу з командою
kubectl create job my-job --image=busybox -- date

# Створити задачу на основі крон-завдання з назвою "a-cronjob"
kubectl create job test-job --from=cronjob/a-cronjob

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--field-manager string     Типово: "kubectl-create"

Імʼя менеджера, що використовується для відстеження права власності на поле.

--from string

Імʼя ресурсу, з якого буде створено Job (підтримується тільки cronjob).

-h, --help

Довідка job

--image string

Назва образу контейнера для запуску.

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--save-config

Якщо значення true, конфігурація поточного обʼєкта буде збережена в його анотації. В іншому випадку, анотацію буде збережено без змін. Цей прапорець корисно встановити, якщо ви хочете застосувати kubectl до цього обʼєкта у майбутньому.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--validate string[="strict"]     Типово: "strict"

Повинно бути одним із: strict (або true), warn, ignore (або false).

"true" або "strict" буде використовувати схему для перевірки вводу і відхилятиме запит, якщо він невірний. Буде виконана перевірка на стороні сервера, якщо ServerSideFieldValidation увімкнено на api-server, але якщо ні, то повернеться до менш надійної перевірки на стороні клієнта.

"warn" попередить про невідомі або повторювані поля, не блокуючи запит, якщо на боці сервера API увімкнено перевірку полів, і буде поводитися як " ignore" у протилежному випадку.

"false" або "ignore" не виконуватимуть жодної перевірки схеми, мовчки відкидаючі будь-які невідомі або дубльовані поля.

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl create — Створення ресурсу з файлу або зі stdin

6.11.3.15.8 - kubectl create namespace

Огляд

Створює простір імен з вказаним іменем.

kubectl create namespace NAME [--dry-run=server|client|none]

Приклади

# Створити простір імен з іменем my-namespace
kubectl create namespace my-namespace

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--field-manager string     Типово: "kubectl-create"

Імʼя менеджера, що використовується для відстеження права власності на поле.

-h, --help

Довідка namespace

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--save-config

Якщо значення true, конфігурація поточного обʼєкта буде збережена в його анотації. В іншому випадку, анотацію буде збережено без змін. Цей прапорець корисно встановити, якщо ви хочете застосувати kubectl до цього обʼєкта у майбутньому.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--validate string[="strict"]     Типово: "strict"

Повинно бути одним із: strict (або true), warn, ignore (або false).

"true" або "strict" буде використовувати схему для перевірки вводу і відхилятиме запит, якщо він невірний. Буде виконана перевірка на стороні сервера, якщо ServerSideFieldValidation увімкнено на api-server, але якщо ні, то повернеться до менш надійної перевірки на стороні клієнта.

"warn" попередить про невідомі або повторювані поля, не блокуючи запит, якщо на боці сервера API увімкнено перевірку полів, і буде поводитися як " ignore" у протилежному випадку.

"false" або "ignore" не виконуватимуть жодної перевірки схеми, мовчки відкидаючі будь-які невідомі або дубльовані поля.

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl create — Створення ресурсу з файлу або зі stdin

6.11.3.15.9 - kubectl create poddisruptionbudget

Огляд

Створіть бюджет розладу роботи Podʼів із зазначеною назвою, селектором і бажаним мінімумом доступних Podʼів.

kubectl create poddisruptionbudget NAME --selector=SELECTOR --min-available=N [--dry-run=server|client|none]

Приклади

# Створити бюджет розладу роботи Podʼів з назвою "my-pdb",
# який вибере всі Podʼи з міткою app=rails і вимагатиме, щоб принаймні один з них був доступний в будь-який момент
kubectl create poddisruptionbudget my-pdb --selector=app=rails --min-available=1

# Створити бюджет розладу роботи Podʼів з назвою "my-pdb",
# який вибере всі Podʼи з міткою app=nginx і вимагатиме, щоб принаймні половина вибраних Podʼів була доступна в будь-який момент
kubectl create pdb my-pdb --selector=app=nginx --min-available=50%

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--field-manager string     Типово: "kubectl-create"

Імʼя менеджера, що використовується для відстеження права власності на поле.

-h, --help

Довідка poddisruptionbudget

--max-unavailable string

Максимальна кількість або відсоток недоступних Podʼів, яких вимагає цей бюджет.

--min-available string

Мінімальна кількість або відсоток доступних Podʼів, яких вимагає цей бюджет.

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--save-config

Якщо значення true, конфігурація поточного обʼєкта буде збережена в його анотації. В іншому випадку, анотацію буде збережено без змін. Цей прапорець корисно встановити, якщо ви хочете застосувати kubectl до цього обʼєкта у майбутньому.

--selector string

Селектор мітки, який буде використано для цього бюджету. Підтримуються лише вимоги до селектора на основі рівності.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--validate string[="strict"]     Типово: "strict"

Повинно бути одним із: strict (або true), warn, ignore (або false).

"true" або "strict" буде використовувати схему для перевірки вводу і відхилятиме запит, якщо він невірний. Буде виконана перевірка на стороні сервера, якщо ServerSideFieldValidation увімкнено на api-server, але якщо ні, то повернеться до менш надійної перевірки на стороні клієнта.

"warn" попередить про невідомі або повторювані поля, не блокуючи запит, якщо на боці сервера API увімкнено перевірку полів, і буде поводитися як " ignore" у протилежному випадку.

"false" або "ignore" не виконуватимуть жодної перевірки схеми, мовчки відкидаючі будь-які невідомі або дубльовані поля.

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl create — Створення ресурсу з файлу або зі stdin

6.11.3.15.10 - kubectl create priorityclass

Огляд

Створює клас пріоритету з вказаним імʼям, значенням, globalDefault та описом.

kubectl create priorityclass NAME --value=VALUE --global-default=BOOL [--dry-run=server|client|none]

Приклади

# Створити клас пріоритету з назвою high-priority
kubectl create priorityclass high-priority --value=1000 --description="high priority"

# Створити клас пріоритету з назвою default-priority, який вважається глобальним стандартним класом пріоритету
kubectl create priorityclass default-priority --value=1000 --global-default=true --description="default priority"

# Створити клас пріоритету з назвою high-priority, який не може випереджувати Podʼи з нижчим пріоритетом
kubectl create priorityclass high-priority --value=1000 --description="high priority" --preemption-policy="Never"

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--description string

description — довільний рядок, який зазвичай містить вказівки щодо того, коли слід використовувати цей клас пріоритету.

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--field-manager string     Типово: "kubectl-create"

Імʼя менеджера, що використовується для відстеження права власності на поле.

--global-default

global-default вказує, чи слід вважати цей PriorityClass стандартним пріоритетом.

-h, --help

Довідка priorityclass

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--preemption-policy string     Типово: "PreemptLowerPriority"

preemption-policy — це політика випередження Podʼів з нижчим пріоритетом.

--save-config

Якщо значення true, конфігурація поточного обʼєкта буде збережена в його анотації. В іншому випадку, анотацію буде збережено без змін. Цей прапорець корисно встановити, якщо ви хочете застосувати kubectl до цього обʼєкта у майбутньому.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--validate string[="strict"]     Типово: "strict"

Повинно бути одним із: strict (або true), warn, ignore (або false).

"true" або "strict" буде використовувати схему для перевірки вводу і відхилятиме запит, якщо він невірний. Буде виконана перевірка на стороні сервера, якщо ServerSideFieldValidation увімкнено на api-server, але якщо ні, то повернеться до менш надійної перевірки на стороні клієнта.

"warn" попередить про невідомі або повторювані поля, не блокуючи запит, якщо на боці сервера API увімкнено перевірку полів, і буде поводитися як " ignore" у протилежному випадку.

"false" або "ignore" не виконуватимуть жодної перевірки схеми, мовчки відкидаючі будь-які невідомі або дубльовані поля.

--value int32

значення цього класу пріоритету.

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl create — Створення ресурсу з файлу або зі stdin

6.11.3.15.11 - kubectl create quota

Огляд

Створення квоти ресурсів із зазначеною назвою, жорсткими обмеженнями та необовʼязковими діапазонами.

kubectl create quota NAME [--hard=key1=value1,key2=value2] [--scopes=Scope1,Scope2] [--dry-run=server|client|none]

Приклади

# Створити нову квоту ресурсів з назвою my-quota
kubectl create quota my-quota --hard=cpu=1,memory=1G,pods=2,services=3,replicationcontrollers=2,resourcequotas=1,secrets=5,persistentvolumeclaims=10

# Створити нову квоту ресурсів з назвою best-effort
kubectl create quota best-effort --hard=pods=100 --scopes=BestEffort

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--field-manager string     Типово: "kubectl-create"

Імʼя менеджера, що використовується для відстеження права власності на поле.

--hard string

Розділений комами набір пар resource=quantity, які визначають жорсткі межі.

-h, --help

Довідка quota

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--save-config

Якщо значення true, конфігурація поточного обʼєкта буде збережена в його анотації. В іншому випадку, анотацію буде збережено без змін. Цей прапорець корисно встановити, якщо ви хочете застосувати kubectl до цього обʼєкта у майбутньому.

--scopes string

Розділений комами набір діапазонів квот, які повинні відповідати кожному обʼєкту, що відстежується за допомогою квоти.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--validate string[="strict"]     Типово: "strict"

Повинно бути одним із: strict (або true), warn, ignore (або false).

"true" або "strict" буде використовувати схему для перевірки вводу і відхилятиме запит, якщо він невірний. Буде виконана перевірка на стороні сервера, якщо ServerSideFieldValidation увімкнено на api-server, але якщо ні, то повернеться до менш надійної перевірки на стороні клієнта.

"warn" попередить про невідомі або повторювані поля, не блокуючи запит, якщо на боці сервера API увімкнено перевірку полів, і буде поводитися як " ignore" у протилежному випадку.

"false" або "ignore" не виконуватимуть жодної перевірки схеми, мовчки відкидаючі будь-які невідомі або дубльовані поля.

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl create — Створення ресурсу з файлу або зі stdin

6.11.3.15.12 - kubectl create role

Створює роль з одним правилом.

kubectl create role NAME --verb=verb --resource=resource.group/subresource [--resource-name=resourcename] [--dry-run=server|client|none]

Приклади

# Створити роль з назвою "pod-reader", яка дозволяє користувачу виконувати "get", "watch" і "list" для Podʼів
kubectl create role pod-reader --verb=get --verb=list --verb=watch --resource=pods

# Створити роль з назвою "pod-reader" з вказаними ResourceName
kubectl create role pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod

# Створити роль з назвою "foo" з вказаною API Group
kubectl create role foo --verb=get,list,watch --resource=rs.apps

# Створити роль з назвою "foo" з вказаним SubResource
kubectl create role foo --verb=get,list,watch --resource=pods,pods/status

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--field-manager string     Типово: "kubectl-create"

Імʼя менеджера, що використовується для відстеження права власності на поле.

-h, --help

Довідка role

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--resource strings

Ресурс, до якого застосовується правило

--resource-name strings

Ресурс у білому списку, до якого застосовується правило, повторіть цей прапорець для кожного елемента

--save-config

Якщо значення true, конфігурація поточного обʼєкта буде збережена в його анотації. В іншому випадку, анотацію буде збережено без змін. Цей прапорець корисно встановити, якщо ви хочете застосувати kubectl до цього обʼєкта у майбутньому.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--validate string[="strict"]     Типово: "strict"

Повинно бути одним із: strict (або true), warn, ignore (або false).

"true" або "strict" буде використовувати схему для перевірки вводу і відхилятиме запит, якщо він невірний. Буде виконана перевірка на стороні сервера, якщо ServerSideFieldValidation увімкнено на api-server, але якщо ні, то повернеться до менш надійної перевірки на стороні клієнта.

"warn" попередить про невідомі або повторювані поля, не блокуючи запит, якщо на боці сервера API увімкнено перевірку полів, і буде поводитися як " ignore" у протилежному випадку.

"false" або "ignore" не виконуватимуть жодної перевірки схеми, мовчки відкидаючі будь-які невідомі або дубльовані поля.

--verb strings

Дієслово, яке застосовується до ресурсів, що містяться в правилі

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl create — Створення ресурсу з файлу або зі stdin

6.11.3.15.13 - kubectl create rolebinding

Огляд

Створення привʼязки для певної ролі або кластерної ролі.

kubectl create rolebinding NAME --clusterrole=NAME|--role=NAME [--user=username] [--group=groupname] [--serviceaccount=namespace:serviceaccountname] [--dry-run=server|client|none]

Приклади

# Створити привʼязки ролей для user1, user2 та group1, використовуючи роль admin
kubectl create rolebinding admin --clusterrole=admin --user=user1 --user=user2 --group=group1

# Створити привʼязки ролей для serviceaccount monitoring:sa-dev, використовуючи роль admin
kubectl create rolebinding admin-binding --role=admin --serviceaccount=monitoring:sa-dev

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--clusterrole string

ClusterRole на яку повинна посилатися привʼязка ClusterRoleBinding

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--field-manager string     Типово: "kubectl-create"

Імʼя менеджера, що використовується для відстеження права власності на поле.

--group strings

Групи для привʼязки до кластерної ролі. Прапорець можна повторити, щоб додати кілька груп.

-h, --help

Довідка rolebinding

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--role string

Роль, на яку має посилатися ця RoleBinding

--save-config

Якщо значення true, конфігурація поточного обʼєкта буде збережена в його анотації. В іншому випадку, анотацію буде збережено без змін. Цей прапорець корисно встановити, якщо ви хочете застосувати kubectl до цього обʼєкта у майбутньому.

--serviceaccount strings

Службові облікові записи для привʼязки до кластерної ролі, у форматі <простір імен>:<імʼя>. Прапорець можна повторювати для додавання декількох службових облікових записів.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--user strings

Імена користувачів для привʼязки до кластерної ролі. Прапорець можна повторити, щоб додати кількох користувачів.

--validate string[="strict"]     Типово: "strict"

Повинно бути одним із: strict (або true), warn, ignore (або false).

"true" або "strict" буде використовувати схему для перевірки вводу і відхилятиме запит, якщо він невірний. Буде виконана перевірка на стороні сервера, якщо ServerSideFieldValidation увімкнено на api-server, але якщо ні, то повернеться до менш надійної перевірки на стороні клієнта.

"warn" попередить про невідомі або повторювані поля, не блокуючи запит, якщо на боці сервера API увімкнено перевірку полів, і буде поводитися як " ignore" у протилежному випадку.

"false" або "ignore" не виконуватимуть жодної перевірки схеми, мовчки відкидаючі будь-які невідомі або дубльовані поля.

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl create — Створення ресурсу з файлу або зі stdin

6.11.3.15.14 - kubectl create secret

Огляд

Створення секрету з вказаним типом.

Секрет типу docker-registry призначений для доступу до реєстру контейнера.

Тип секрету generic вказує на Opaque тип секрету.

Секрет типу tls містить TLS-сертифікат і повʼязаний з ним ключ.

kubectl create secret (docker-registry | generic | tls)

Параметри

-h, --help

Довідка secret

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

6.11.3.15.15 - kubectl create secret docker-registry

Огляд

Створення нового секрету для використання з реєстрами Docker.

Секрети Dockercfg використовуються для автентифікації у реєстрах Docker.

При використанні командного рядка Docker для надсилання образів, ви можете автентифікуватися в заданому реєстрі за допомогою запуску команди:

$ docker login DOCKER_REGISTRY_SERVER --username=DOCKER_USER --password=DOCKER_PASSWORD --email=DOCKER_EMAIL.

В результаті буде створено файл ~/.dockercfg, який використовується наступними командами docker push і docker pull для автентифікації в реєстрі. Адреса електронної пошти не є обовʼязковою.

При створенні програм може виникнути ситуація, коли реєстр Docker вимагає автентифікації. Для того, щоб вузли вузли могли отримувати образи від вашого імені, вони повинні мати облікові дані. Ви можете надати цю інформацію створивши секрет dockercfg і прикріпивши його до свого службового облікового запису.

kubectl create secret docker-registry NAME --docker-username=user --docker-password=password --docker-email=email [--docker-server=string] [--from-file=[key=]source] [--dry-run=server|client|none]

Приклади

# Якщо у вас ще немає файлу .dockercfg, створіть секрет dockercfg безпосередньо
kubectl create secret docker-registry my-secret --docker-server=DOCKER_REGISTRY_SERVER --docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL

# Створити новий секрет з назвою my-secret з ~/.docker/config.json
kubectl create secret docker-registry my-secret --from-file=path/to/.docker/config.json

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--append-hash

Додайте хеш secret до назви secret.

--docker-email string

Email для реєстру Docker

--docker-password string

Пароль для автентифікації в реєстрі Docker

--docker-server string     Типово: "https://index.docker.io/v1/"

Розташування сервера реєстру Docker

--docker-username string

Імʼя користувача для автентифікації в реєстрі Docker

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--field-manager string     Типово: "kubectl-create"

Імʼя менеджера, що використовується для відстеження права власності на поле.

--from-file strings

Файли ключів можна вказати за допомогою шляху до файлу, у цьому випадку їм буде присвоєно стандартне імʼя.dockerconfigjson, або за бажанням за допомогою імені та шляху до файлу, у цьому випадку буде використано вказане імʼя. Якщо вказати теку, буде виконано ітераційний пошук кожного файлу з іменем, що є дійсним секретним ключем. Для цієї команди ключем завжди має бути .dockerconfigjson.

-h, --help

Довідка docker-registry

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--save-config

Якщо значення true, конфігурація поточного обʼєкта буде збережена в його анотації. В іншому випадку, анотацію буде збережено без змін. Цей прапорець корисно встановити, якщо ви хочете застосувати kubectl до цього обʼєкта у майбутньому.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--validate string[="strict"]     Типово: "strict"

Повинно бути одним із: strict (або true), warn, ignore (або false).

"true" або "strict" буде використовувати схему для перевірки вводу і відхилятиме запит, якщо він невірний. Буде виконана перевірка на стороні сервера, якщо ServerSideFieldValidation увімкнено на api-server, але якщо ні, то повернеться до менш надійної перевірки на стороні клієнта.

"warn" попередить про невідомі або повторювані поля, не блокуючи запит, якщо на боці сервера API увімкнено перевірку полів, і буде поводитися як " ignore" у протилежному випадку.

"false" або "ignore" не виконуватимуть жодної перевірки схеми, мовчки відкидаючі будь-які невідомі або дубльовані поля.

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl create secret — Створити секрет за допомогою вказаної субкоманди

6.11.3.15.16 - kubectl create secret generic

Огляд

Створення секрету на основі файлу, теки або вказаного літерального значення.

Один секрет може містити одну або декілька пар ключ/значення.

При створенні секрету на основі файлу, стандартно ключем буде назва файлу, а значенням — його вміст. Якщо імʼя файлу не є допустимим ключем або ви хочете вибрати свій власний ключ, ви можете вказати альтернативний ключ.

При створенні секрету на основі теки, кожен файл, імʼя якого є дійсним ключем у теці, буде запаковано у секрет. Будь-які записи теки, окрім звичайних файлів, ігноруються (наприклад, підтеки, символічні посилання, пристрої, канали й т.д.).

kubectl create secret generic NAME [--type=string] [--from-file=[key=]source] [--from-literal=key1=value1] [--dry-run=server|client|none]

Приклади

# Створити новий секрет з назвою my-secret з ключами для кожного файлу в теці bar
kubectl create secret generic my-secret --from-file=path/to/bar

# Створити новий секрет з назвою my-secret з вказаними ключами замість імен на диску
kubectl create secret generic my-secret --from-file=ssh-privatekey=path/to/id_rsa --from-file=ssh-publickey=path/to/id_rsa.pub

# Створити новий секрет з назвою my-secret з key1=supersecret та key2=topsecret
kubectl create secret generic my-secret --from-literal=key1=supersecret --from-literal=key2=topsecret

# Створити новий секрет з назвою my-secret з використанням комбінації файлу та літерала
kubectl create secret generic my-secret --from-file=ssh-privatekey=path/to/id_rsa --from-literal=passphrase=topsecret

# Створити новий секрет з назвою my-secret з файлів env
kubectl create secret generic my-secret --from-env-file=path/to/foo.env --from-env-file=path/to/bar.env

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--append-hash

Додайте хеш secret до назви secret.

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--field-manager string     Типово: "kubectl-create"

Імʼя менеджера, що використовується для відстеження права власності на поле.

--from-env-file strings

Вкажіть шлях до файлу для отримання рядків з парами key=val для створення secret.

--from-file strings

Файл ключа можна вказати за допомогою шляху до файлу, у цьому випадку імʼя файлу буде використано як ключ, або за допомогою ключа і шляху до файлу, у цьому випадку буде використано заданий ключ. Якщо вказати теку, буде виконано ітерацію для кожного названого файлу у цій теці, імʼя якого є допустимим ключем secret.

--from-literal strings

Вкажіть ключ і літеральне значення для вставки в secret (тобто mykey=somevalue)

-h, --help

Довідка generic

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--save-config

Якщо значення true, конфігурація поточного обʼєкта буде збережена в його анотації. В іншому випадку, анотацію буде збережено без змін. Цей прапорець корисно встановити, якщо ви хочете застосувати kubectl до цього обʼєкта у майбутньому.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--type string

Тип секрету, який необхідно створити

--validate string[="strict"]     Типово: "strict"

Повинно бути одним із: strict (або true), warn, ignore (або false).

"true" або "strict" буде використовувати схему для перевірки вводу і відхилятиме запит, якщо він невірний. Буде виконана перевірка на стороні сервера, якщо ServerSideFieldValidation увімкнено на api-server, але якщо ні, то повернеться до менш надійної перевірки на стороні клієнта.

"warn" попередить про невідомі або повторювані поля, не блокуючи запит, якщо на боці сервера API увімкнено перевірку полів, і буде поводитися як " ignore" у протилежному випадку.

"false" або "ignore" не виконуватимуть жодної перевірки схеми, мовчки відкидаючі будь-які невідомі або дубльовані поля.

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl create secret — Створити секрет за допомогою вказаної субкоманди

6.11.3.15.17 - kubectl create secret tls

Огляд

Створення TLS-секрету із заданої пари публічного/приватного ключа.

Пара відкритий/закритий ключ повинна існувати заздалегідь. Сертифікат відкритого ключа повинен бути зашифрований у форматі .PEM і відповідати заданому закритому ключу.

kubectl create secret tls NAME --cert=path/to/cert/file --key=path/to/key/file [--dry-run=server|client|none]

Приклади

# Створіть новий TLS-секрет з імʼям tls-secret із заданою парою ключів
kubectl create secret tls tls-secret --cert=path/to/tls.crt --key=path/to/tls.key

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--append-hash

Додайте хеш secret до назви secret.

--cert string

Шлях до PEM-закодованого сертифіката відкритого ключа.

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--field-manager string     Типово: "kubectl-create"

Імʼя менеджера, що використовується для відстеження права власності на поле.

-h, --help

Довідка tls

--key string

Шлях до приватного ключа, повʼязаного з даним сертифікатом.

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--save-config

Якщо значення true, конфігурація поточного обʼєкта буде збережена в його анотації. В іншому випадку, анотацію буде збережено без змін. Цей прапорець корисно встановити, якщо ви хочете застосувати kubectl до цього обʼєкта у майбутньому.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--validate string[="strict"]     Типово: "strict"

Повинно бути одним із: strict (або true), warn, ignore (або false).

"true" або "strict" буде використовувати схему для перевірки вводу і відхилятиме запит, якщо він невірний. Буде виконана перевірка на стороні сервера, якщо ServerSideFieldValidation увімкнено на api-server, але якщо ні, то повернеться до менш надійної перевірки на стороні клієнта.

"warn" попередить про невідомі або повторювані поля, не блокуючи запит, якщо на боці сервера API увімкнено перевірку полів, і буде поводитися як " ignore" у протилежному випадку.

"false" або "ignore" не виконуватимуть жодної перевірки схеми, мовчки відкидаючі будь-які невідомі або дубльовані поля.

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl create secret — Створити секрет за допомогою вказаної субкоманди

6.11.3.15.18 - kubectl create service

Огляд

Створення сервісу з використанням субкоманд.

kubectl create service [flags]

Параметри

-h, --help

Довідка service

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

6.11.3.15.19 - kubectl create service clusterip

Огляд

Створення сервісу ClusterIP із зазначеним імʼям.

kubectl create service clusterip NAME [--tcp=<port>:<targetPort>] [--dry-run=server|client|none]

Приклади

# Створити новий сервіс ClusterIP з назвою my-cs
kubectl create service clusterip my-cs --tcp=5678:8080

# Створити новий сервіс ClusterIP з назвою my-cs (у режимі headless)
kubectl create service clusterip my-cs --clusterip="None"

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--clusterip string

Призначте власний ClusterIP або встановіть значення "None" для сервісу "headless" (без балансування навантаження).

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--field-manager string     Типово: "kubectl-create"

Імʼя менеджера, що використовується для відстеження права власності на поле.

-h, --help

Довідка clusterip

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--save-config

Якщо значення true, конфігурація поточного обʼєкта буде збережена в його анотації. В іншому випадку, анотацію буде збережено без змін. Цей прапорець корисно встановити, якщо ви хочете застосувати kubectl до цього обʼєкта у майбутньому.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--tcp strings

Пари портів можна вказати у вигляді '<порт>:<цільовий порт>'.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--validate string[="strict"]     Типово: "strict"

Повинно бути одним із: strict (або true), warn, ignore (або false).

"true" або "strict" буде використовувати схему для перевірки вводу і відхилятиме запит, якщо він невірний. Буде виконана перевірка на стороні сервера, якщо ServerSideFieldValidation увімкнено на api-server, але якщо ні, то повернеться до менш надійної перевірки на стороні клієнта.

"warn" попередить про невідомі або повторювані поля, не блокуючи запит, якщо на боці сервера API увімкнено перевірку полів, і буде поводитися як " ignore" у протилежному випадку.

"false" або "ignore" не виконуватимуть жодної перевірки схеми, мовчки відкидаючі будь-які невідомі або дубльовані поля.

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl create service — Створити сервіс за допомогою вказаної субкоманди

6.11.3.15.20 - kubectl create service externalname

Огляд

Створення сервісу ExternalName із зазначеним імʼям.

Сервіс ExternalName посилається на зовнішню DNS-адресу, а не лише на Podʼи, що дозволить авторам застосунків посилатися на сервіси, які існують за межами платформи, в інших кластерах або локально.

kubectl create service externalname NAME --external-name external.name [--dry-run=server|client|none]

Приклади

# Створіть новий сервіс ExternalName з іменем my-ns
kubectl create service externalname my-ns --external-name bar.com

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--external-name string

Зовнішня назва сервісу

--field-manager string     Типово: "kubectl-create"

Імʼя менеджера, що використовується для відстеження права власності на поле.

-h, --help

Довідка externalname

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--save-config

Якщо значення true, конфігурація поточного обʼєкта буде збережена в його анотації. В іншому випадку, анотацію буде збережено без змін. Цей прапорець корисно встановити, якщо ви хочете застосувати kubectl до цього обʼєкта у майбутньому.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--tcp strings

Пари портів можна вказати у вигляді '<порт>:<цільовий порт>'.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--validate string[="strict"]     Типово: "strict"

Повинно бути одним із: strict (або true), warn, ignore (або false).

"true" або "strict" буде використовувати схему для перевірки вводу і відхилятиме запит, якщо він невірний. Буде виконана перевірка на стороні сервера, якщо ServerSideFieldValidation увімкнено на api-server, але якщо ні, то повернеться до менш надійної перевірки на стороні клієнта.

"warn" попередить про невідомі або повторювані поля, не блокуючи запит, якщо на боці сервера API увімкнено перевірку полів, і буде поводитися як " ignore" у протилежному випадку.

"false" або "ignore" не виконуватимуть жодної перевірки схеми, мовчки відкидаючі будь-які невідомі або дубльовані поля.

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl create service — Створити сервіс за допомогою вказаної субкоманди

6.11.3.15.21 - kubectl create service loadbalancer

Огляд

Створення сервісу LoadBalancer з вказаним імʼям.

kubectl create service loadbalancer NAME [--tcp=port:targetPort] [--dry-run=server|client|none]

Приклади

# Створіть новий сервіс LoadBalancer з назвою my-lbs
kubectl create service loadbalancer my-lbs --tcp=5678:8080

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--field-manager string     Типово: "kubectl-create"

Імʼя менеджера, що використовується для відстеження права власності на поле.

-h, --help

Довідка loadbalancer

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--save-config

Якщо значення true, конфігурація поточного обʼєкта буде збережена в його анотації. В іншому випадку, анотацію буде збережено без змін. Цей прапорець корисно встановити, якщо ви хочете застосувати kubectl до цього обʼєкта у майбутньому.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--tcp strings

Пари портів можна вказати у вигляді '<порт>:<цільовий порт>'.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--validate string[="strict"]     Типово: "strict"

Повинно бути одним із: strict (або true), warn, ignore (або false).

"true" або "strict" буде використовувати схему для перевірки вводу і відхилятиме запит, якщо він невірний. Буде виконана перевірка на стороні сервера, якщо ServerSideFieldValidation увімкнено на api-server, але якщо ні, то повернеться до менш надійної перевірки на стороні клієнта.

"warn" попередить про невідомі або повторювані поля, не блокуючи запит, якщо на боці сервера API увімкнено перевірку полів, і буде поводитися як " ignore" у протилежному випадку.

"false" або "ignore" не виконуватимуть жодної перевірки схеми, мовчки відкидаючі будь-які невідомі або дубльовані поля.

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl create service — Створити сервіс за допомогою вказаної субкоманди

6.11.3.15.22 - kubectl create service nodeport

Огляд

Створення сервісу NodePort з вказаним імʼям.

kubectl create service nodeport NAME [--tcp=port:targetPort] [--dry-run=server|client|none]

Приклади

# Створіть новий сервіс NodePort з назвою my-ns
kubectl create service nodeport my-ns --tcp=5678:8080

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--field-manager string     Типово: "kubectl-create"

Імʼя менеджера, що використовується для відстеження права власності на поле.

-h, --help

Довідка nodeport

--node-port int

Порт, який використовується для експонування сервісу на кожному вузлі кластера.

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--save-config

Якщо значення true, конфігурація поточного обʼєкта буде збережена в його анотації. В іншому випадку, анотацію буде збережено без змін. Цей прапорець корисно встановити, якщо ви хочете застосувати kubectl до цього обʼєкта у майбутньому.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--tcp strings

Пари портів можна вказати у вигляді '<порт>:<цільовий порт>'.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--validate string[="strict"]     Типово: "strict"

Повинно бути одним із: strict (або true), warn, ignore (або false).

"true" або "strict" буде використовувати схему для перевірки вводу і відхилятиме запит, якщо він невірний. Буде виконана перевірка на стороні сервера, якщо ServerSideFieldValidation увімкнено на api-server, але якщо ні, то повернеться до менш надійної перевірки на стороні клієнта.

"warn" попередить про невідомі або повторювані поля, не блокуючи запит, якщо на боці сервера API увімкнено перевірку полів, і буде поводитися як " ignore" у протилежному випадку.

"false" або "ignore" не виконуватимуть жодної перевірки схеми, мовчки відкидаючі будь-які невідомі або дубльовані поля.

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl create service — Створити сервіс за допомогою вказаної субкоманди

6.11.3.15.23 - kubectl create serviceaccount

Огляд

Створення службового облікового запису з вказаним імʼям.

kubectl create serviceaccount NAME [--dry-run=server|client|none]

Приклади

# Створіть новий служюовий обліковий записк з назвою my-service-account
kubectl create serviceaccount my-service-account

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--field-manager string     Типово: "kubectl-create"

Імʼя менеджера, що використовується для відстеження права власності на поле.

-h, --help

Довідка serviceaccount

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--save-config

Якщо значення true, конфігурація поточного обʼєкта буде збережена в його анотації. В іншому випадку, анотацію буде збережено без змін. Цей прапорець корисно встановити, якщо ви хочете застосувати kubectl до цього обʼєкта у майбутньому.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--validate string[="strict"]     Типово: "strict"

Повинно бути одним із: strict (або true), warn, ignore (або false).

"true" або "strict" буде використовувати схему для перевірки вводу і відхилятиме запит, якщо він невірний. Буде виконана перевірка на стороні сервера, якщо ServerSideFieldValidation увімкнено на api-server, але якщо ні, то повернеться до менш надійної перевірки на стороні клієнта.

"warn" попередить про невідомі або повторювані поля, не блокуючи запит, якщо на боці сервера API увімкнено перевірку полів, і буде поводитися як " ignore" у протилежному випадку.

"false" або "ignore" не виконуватимуть жодної перевірки схеми, мовчки відкидаючі будь-які невідомі або дубльовані поля.

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl create — Створення ресурсу з файлу або з stdin

6.11.3.15.24 - kubectl create token

Огляд

Запит на отримання токена службового облікового запису.

kubectl create token SERVICE_ACCOUNT_NAME

Приклади

# Запит токена для автентифікації на kube-apiserver як службовий обліковий запис "myapp" у поточному просторі імен
kubectl create token myapp

# Запит токена для службового облікового запису у власному просторі імен
kubectl create token myapp --namespace myns

# Запит токена із власним часом дії
kubectl create token myapp --duration 10m

# Запит токена із власною аудиторією
kubectl create token myapp --audience https://example.com

# Запит токена, привʼязаного до обʼєкта типу Secret
kubectl create token myapp --bound-object-kind Secret --bound-object-name mysecret

# Запит токена, привʼязаного до обʼєкта типу Secret з конкретним UID
kubectl create token myapp --bound-object-kind Secret --bound-object-name mysecret --bound-object-uid 0d4691ed-659b-4935-a832-355f77ee47cc

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--audience strings

Аудиторія запитуваного токена. Якщо не встановлено, стандартно запитується токен для використання з сервером API Kubernetes. Може бути повторений для запиту токена, дійсного для декількох аудиторій.

--bound-object-kind string

Тип обʼєкта, до якого привʼязується токен. Підтримуються типи Node, Pod, Secret. Якщо задано, має бути вказано --bound-object-name.

--bound-object-name string

Імʼя обʼєкта, до якого потрібно привʼязати токен. Термін дії токена закінчиться, коли обʼєкт буде видалено. Потрібно вказати --bound-object-kind.

--bound-object-uid string

UID обʼєкта, до якого потрібно привʼязати токен. Потрібні --bound-object-kind та --bound-object-name. Якщо не вказано, використовується UID наявного обʼєкта.

--duration duration

Запитуваний термін життя випущеного токена. Якщо не вказано або вказано 0, то термін життя буде визначено сервером автоматично. Сервер може повернути токен з більшим або меншим терміном дії.

-h, --help

Довідка token

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl create — Створення ресурсу з файлу або з stdin

6.11.3.16 - kubectl debug

Огляд

Налагодження ресурсів кластера за допомогою інтерактивних контейнерів налагодження.

'debug' автоматизує виконання поширених завдань налагодження для обʼєктів кластера, ідентифікованих за ресурсом та імʼям. Типово будуть використовуватися Podʼи, якщо ресурс не вказано.

Дія, яку виконує 'debug', залежить від вказаного ресурсу. Підтримувані дії включають:

  • Workload: Створити копію поточного Podʼа зі зміненими атрибутами, наприклад, змінити теґ образу на нову версію.
  • Workload: Додати ефемерний контейнер до вже працюючого Podʼа, наприклад, щоб додати утиліти для налагодження без перезапуску Podʼа.
  • Node: Створити новий Pod, який працює у host namespaces вузла та має доступ до файлової системи вузла.
kubectl debug (POD | TYPE[[.VERSION].GROUP]/NAME) [ -- COMMAND [args...] ]

Приклади

# Створити інтерактивну сесію налагодження в Pod mypod та одразу приєднатися до неї.
kubectl debug mypod -it --image=busybox

# Створити інтерактивну сесію налагодження для Pod з файлу pod.yaml та одразу приєднатися до неї.
# (вимагає увімкнення функції EphemeralContainers в кластері)
kubectl debug -f pod.yaml -it --image=busybox

# Створити контейнер налагодження з назвою debugger, використовуючи власний автоматизований образ для налагодження.
kubectl debug --image=myproj/debug-tools -c debugger mypod

# Створити копію mypod, додавши контейнер налагодження, та приєднатися до неї.
kubectl debug mypod -it --image=busybox --copy-to=my-debugger

# Створити копію mypod, змінивши команду mycontainer.
kubectl debug mypod -it --copy-to=my-debugger --container=mycontainer -- sh

# Створити копію mypod, змінивши образи всіх контейнерів на busybox.
kubectl debug mypod --copy-to=my-debugger --set-image=*=busybox

# Створити копію mypod, додавши контейнер налагодження та змінивши образи контейнерів.
kubectl debug mypod -it --copy-to=my-debugger --image=debian --set-image=app=app:debug,sidecar=sidecar:debug

# Створити інтерактивну сесію налагодження на вузлі та одразу приєднатися до неї.
# Контейнер працюватиме в host namespaces та файлову систему вузла буде змонтовано у /host.
kubectl debug node/mynode -it --image=busybox

Параметри

--arguments-only

Якщо вказано, все, що знаходиться після --, буде передано до нового контейнера як Args замість Command.

--attach

Якщо значення true, дочекайтись запуску контейнера, а потім приєднати його так, ніби було викликано команду 'kubectl attach ...'. Стандартне значення false, якщо не задано параметр '-i/--stdin', у цьому випадку стандартне значення true.

-c, --container string

Назва контейнера, який буде використано для налагодження.

--copy-to string

Створіює копію цільового Pod з цією назвою.

--custom string

Шлях до JSON або YAML-файлу, що містить часткову специфікацію контейнера для налаштування вбудованих профілів налагодження.

--env stringToString     Типово: []

Змінні оточення, які потрібно встановити в контейнері.

-f, --filename strings

визначення ресурсу для налагодження

-h, --help

Довідка debug

--image string

Назва образу контейнера для запуску.

--image-pull-policy string

Політика отримання образів для контейнера. Якщо залишити порожнім, це значення не буде вказано клієнтом і буде стандартно визначене сервером.

--keep-annotations

Якщо значення true, зберігати оригінальні анотації p Podʼів (цей прапорець працює лише при використанні '--copy-to').

--keep-init-containers     Default: true

Запустити ініціалізаційні контейнери для pod. Стандартно дорівнює true (цей прапорець працює лише у випадку використання з '--copy-to').

--keep-labels

Якщо значення true, зберігати оригінальні мітки Podʼів (цей прапорець працює лише при використанні '--copy-to').

--keep-liveness

Якщо значення true, зберегти оригінальні проби життєздатності Podʼа. (Цей прапорець працює лише при використанні '--copy-to').

--keep-readiness

Якщо значення true, зберегти оригінальні проби готовності Podʼа. (Цей прапорець працює лише при використанні '--copy-to').

--keep-startup

Якщо значення true, зберігати оригінальні проби запуску (цей прапорець працює лише при використанні '--copy-to').

--profile string     Типово: "legacy"

Варіанти: " legacy", "general", "baseline", "netadmin", "restricted" або "sysadmin".

-q, --quiet

Якщо true, то придушити інформаційні повідомлення.

--replace

При використанні з '--copy-to' видаляє оригінальний Pod.

--same-node

Якщо використовується з '--copy-to', призначити копію цільового Pod на той самий вузол.

--set-image stringToString     Типово: []

При використанні з '--copy-to', список пар name=image для зміни образів контейнерів, подібно до того, як працює команда 'kubectl set image'.

--share-processes     Типово: true

При використанні з '--copy-to' вмикає спільне використання простору імен процесів у копії.

-i, --stdin

Залишати stdin відкритим у контейнері (контейнерах), навіть якщо до нього нічого не приєднано.

--target string

При використанні ефемерного контейнера, спрямовувати процеси до цього контейнера.

-t, --tty

Призначення TTY для контейнера налагодження.

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes

6.11.3.17 - kubectl delete

Огляд

Видалення ресурсів за іменами файлів, stdin, ресурсами та іменами, або за ресурсами та селекторами міток.

Приймаються формати JSON та YAML. Можна вказати лише один тип аргументів: імена файлів, ресурси та імена, або ресурси та селектори міток.

Деякі ресурси, такі як Podʼи, підтримують належне видалення. Ці ресурси визначають стандартний період перед примусовим завершенням (пільговий період), але ви можете змінити це значення за допомогою прапорця --grace-period або передати --now, щоб встановити пільговий період на 1. Оскільки ці ресурси часто представляють сутності в кластері, видалення може не бути підтверджене одразу. Якщо вузол, який хостить Pod, відключений або не може досягти API-сервера, завершення може зайняти значно більше часу, ніж пільговий період. Щоб примусово видалити ресурс, ви повинні вказати прапорець --force. Примітка: лише підмножина ресурсів підтримує належне видалення. За відсутності підтримки, прапорець --grace-period ігнорується.

ВАЖЛИВО: Примусове видалення Podʼів не чекає підтвердження, що процеси Podʼа завершені, що може залишити ці процеси запущеними, поки вузол не виявить видалення та не завершить належне видалення. Якщо ваші процеси використовують спільне сховище або звертаються до віддаленого API та залежать від імені Podʼа для ідентифікації, примусове видалення цих Podʼів може призвести до запуску кількох процесів на різних машинах з однаковою ідентифікацією, що може призвести до пошкодження даних або неконсистентності. Примусово видаляйте Pod лише коли ви впевнені, що Pod завершено, або якщо ваш застосунок може витримати кілька копій одного Podʼа, які працюють одночасно. Також, якщо ви примусово видаляєте Pod, планувальник може розмістити нові Pod на цих вузлах до того, як вузол звільнить ці ресурси, що спричинить негайне виселення цих Podʼів.

Зверніть увагу, що команда delete НЕ перевіряє версію ресурсу, тому якщо хтось подасть оновлення ресурсу в той момент, коли ви подасте команду delete, їхнє оновлення буде втрачено разом з рештою ресурсу.

Після видалення CustomResourceDefinition інвалідація кешу виявлення може тривати до 6 годин. Якщо ви не хочете чекати, можливо, варто запустити "kubectl api-resources", щоб оновити кеш виявлення.

kubectl delete ([-f FILENAME] | [-k DIRECTORY] | TYPE [(NAME | -l label | --all)])

Приклади

# Видалити Pod, використовуючи тип та імʼя, вказані в pod.json
kubectl delete -f ./pod.json

# Видалити ресурси з теки, що містить kustomization.yaml — наприклад, dir/kustomization.yaml
kubectl delete -k dir

# Видалити ресурси з усіх файлів, що закінчуються на '.json'
kubectl delete -f '*.json'

# Видалити Pod на основі типу та імені в JSON, переданому в stdin
cat pod.json | kubectl delete -f -

# Видалити Podʼи та сервіси з іменами "baz" та "foo"
kubectl delete pod,service baz foo

# Видалити Podʼи та сервіси з міткою name=myLabel
kubectl delete pods,services -l name=myLabel

# Видалити Pod з мінімальною затримкою
kubectl delete pod foo --now

# Примусово видалити Pod на мертвому вузлі
kubectl delete pod foo --force

# Видалити всі Podʼи
kubectl delete pods --all

Параметри

--all

Вилучити всі ресурси у просторі імен вказаних типів ресурсів.

-A, --all-namespaces

Якщо вказано, показати список запитуваних обʼєктів у всіх просторах назв. Простір імен у поточному контексті ігнорується, навіть якщо вказано --namespace.

--cascade string[="background"]     Типово: "background"

Має бути "background", "orphan" або "foreground". Вибирає стратегію каскадного видалення для залежних елементів (наприклад, Podʼів, створених Replication Controller). Стандартне значення — background.

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--field-selector string

Селектор (запит поля) для фільтрації підтримує '=', '==' і '!=' (наприклад, --field-selector key1=value1,key2=value2). Сервер підтримує лише обмежену кількість запитів до полів кожного типу.

-f, --filename strings

містить ресурс, який потрібно видалити.

--force

Якщо true, негайно видалити ресурси з API і оминути процедуру належного видалення. Зверніть увагу, що негайне видалення деяких ресурсів може призвести до неузгодженості або втрати даних і потребує підтвердження.

--grace-period int     Типово: -1

Період часу в секундах, який дається ресурсу для належного завершення роботи. Ігнорується, якщо значення відʼємне. Встановлюється у 1 для негайного завершення роботи. Може бути встановлене у 0, тільки якщо --force має значення true (примусове видалення).

-h, --help

Довідка delete

--ignore-not-found

Вважати "resource not found" за успішне видалення. Стандартно дорівнює "true", якщо вказано --all.

-i, --interactive

Якщо true, видаляти ресурс тільки після підтвердження користувача.

-k, --kustomize string

Обробити теку kustomization. Цей прапорець не можна використовувати разом з -f або -R.

--now

Якщо значення true, ресурсам дається сигнал про негайне припинення роботи (так само, як і --grace-period=1).

-o, --output string

Режим виводу. Використовуйте "-o name" для скороченого виводду (resource/name).

--raw string

Необроблений URI для DELETE на сервер. Використовує транспорт, вказаний у файлі kubeconfig.

-R, --recursive

Рекурсивно обробити теку, вказану у -f, --filename. Корисно, якщо ви хочете керувати повʼязаними маніфестами, організованими в одній теці.

-l, --selector string

Селектор (запит на мітки) для фільтрації, що підтримує '=', '==' і '!=' (наприклад, -l key1=value1,key2=value2). Обʼєкти, щоб мати збіг, повинні задовольняти усім зазначеним обмеженням міток.

--timeout duration

Час очікування перед прийнятям рішення про відмову видалення, нуль означає визначення таймауту залежно від розміру обʼєкта

--wait     Типово: true

Якщо true, очікувати, поки ресурси зникнуть, перш ніж повернутися. Очікує фіналізаторів.

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes

6.11.3.18 - kubectl describe

Огляд

Показує детальну інформацію про певний ресурс або групу ресурсів.

Виводіть детальний опис вибраних ресурсів, включно з повʼязаними ресурсами, такими як події або контролери. Ви можете вибрати один обʼєкт за назвою, всі обʼєкти цього типу, вказати префікс назви або селектор міток. Наприклад:

kubectl describe TYPE NAME_PREFIX

спочатку перевірить наявність точного збігу між TYPE і NAME_PREFIX. Якщо такого ресурсу не існує, він виведе дані для кожного ресурсу, який має назву з префіксом NAME_PREFIX.

Для отримання повного списку підтримуваних ресурсів скористайтеся "kubectl api-resources".

kubectl describe (-f FILENAME | TYPE [NAME_PREFIX | -l label] | TYPE/NAME)

Приклади

# Вивести опис вузла
kubectl describe nodes kubernetes-node-emt8.c.myproject.internal

# Вивести опис Podʼа
kubectl describe pods/nginx

# Вивести опис Podʼа, визначений типом та іменем у "pod.json"
kubectl describe -f pod.json

# Вивести опис всіх Podʼів
kubectl describe pods

# Вивести опис Podʼів за міткою name=myLabel
kubectl describe pods -l name=myLabel

# Вивести опис всіх Podʼів, керовані контролером реплікації 'frontend'
# (Podʼи, створені rc, отримують імʼя rc як префікс у назві Podʼа)
kubectl describe pods frontend

Параметри

-A, --all-namespaces

Якщо вказано, показати список запитуваних обʼєктів у всіх просторах назв. Простір імен у поточному контексті ігнорується, навіть якщо вказано --namespace.

--chunk-size int     Типово: 500

Повертати великі списки частинами, а не всі одразу. Для вимкнення задайте 0. Цей прапорець є бета-версією і може змінюватися в майбутньому.

-f, --filename strings

Імʼя файлу, теки або URL до файлів, що ідентифікують ресурс для отриманні інформації

-h, --help

Довідка describe

-k, --kustomize string

Обробити теку kustomization. Цей прапорець не можна використовувати разом з -f або -R.

-R, --recursive

Рекурсивно обробити теку, вказану у -f, --filename. Корисно, якщо ви хочете керувати повʼязаними маніфестами, організованими в одній теці.

-l, --selector string

Селектор (запит на мітки) для фільтрації, що підтримує '=', '==' і '!=' (наприклад, -l key1=value1,key2=value2). Обʼєкти, щоб мати збіг, повинні задовольняти усім зазначеним обмеженням міток.

--show-events     Типово: true

Якщо true, показувати події, повʼязані з описаним обʼєктом.

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes

6.11.3.19 - kubectl diff

Огляд

Порівнює конфігурації, вказані за назвою файлу або stdin, між поточною онлайн-конфігурацією та конфігурацією, яка була б застосована.

На виході завжди буде YAML.

Змінна середовища KUBECTL_EXTERNAL_DIFF може бути використана для вибору вашої власної команди diff. Користувачі також можуть використовувати зовнішні команди з параметрами, наприклад: KUBECTL_EXTERNAL_DIFF="colordiff -N -u"

Стандартно команду "diff", доступну у вашому шляху, буде запущено з параметрами "-u" (уніфікований diff) і "-N" (вважати відсутні файли порожніми).

Стан завершення роботи: 0 — Відмінностей не знайдено. 1 — Відмінності знайдено. >1 — Запуск Kubectl або diff завершився з помилкою.

Зауваження: якщо використовується KUBECTL_EXTERNAL_DIFF, очікується, що його буде застосовано відповідно до цієї конвенції.

kubectl diff -f FILENAME

Приклади

# Diff resources included in pod.json
kubectl diff -f pod.json

# Diff file read from stdin
cat service.yaml | kubectl diff -f -

Параметри

--concurrency int     Типово: 1

Кількість обʼєктів для паралельної обробки у порівнянні з реальною версією. Більша кількість = швидше, але більше памʼяті, вводу/виводу та процесора за коротший проміжок часу.

--field-manager string     Типово: "kubectl-client-side-apply"

Імʼя менеджера, що використовується для відстеження права власності на поле.

-f, --filename strings

Імʼя файлу, теки або URL до файлів, що містить конфігурацію для diff

--force-conflicts

Якщо значення true, серверне застосування (server-side apply) буде примусово вносити зміни всупереч конфліктам.

-h, --help

Довідка diff

-k, --kustomize string

Обробити теку kustomization. Цей прапорець не можна використовувати разом з -f або -R.

--prune

Включити ресурси, які буде видалено під час обрізання. Можна використовувати з параметром -l і типово показує всі ресурси, які буде вилучено

--prune-allowlist strings

Замінити список стандартний дозволів (allowlist) <group/version/kind> для --prune

-R, --recursive

Рекурсивно обробити теку, вказану у -f, --filename. Корисно, якщо ви хочете керувати повʼязаними маніфестами, організованими в одній теці.

-l, --selector string

Селектор (запит на мітки) для фільтрації, що підтримує '=', '==' і '!=' (наприклад, -l key1=value1,key2=value2). Обʼєкти, щоб мати збіг, повинні задовольняти усім зазначеним обмеженням міток.

--server-side

Якщо значення true, apply виконується на сервері, а не на клієнті.

--show-managed-fields

Якщо true, включити керовані поля в diff.

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes

6.11.3.20 - kubectl drain

Огляд

Очищує вузол для підготовки до обслуговування.

Зазначений вузол будо позначено, як не придатний для розміщення робочих навантажень для запобігання створенню нових Podʼів на ньому. 'drain' виселяє Podʼи, якщо API сервер підтримує розлади або виселення. В іншому випадку він використовує звичайний DELETE, щоб видалити Podʼи. 'drain' виселяє або видаляє всі Podʼи, окрім дзеркальних Podʼів (які не можна видалити за допомогою API сервера). Якщо це самокерований Pod демона, drain не спрацює, якщо немає --ignore-daemonsets, і Pod не буде видалено, бо такі Podʼи будуть негайно замінені новими контролером DaemonSet, який не звертає уваги на позначку unschedulable. Якщо є якісь Podʼи, які не є дзеркальними Podʼами, і які не керуються контролером реплікації, replica set, daemon set, stateful set, або job то drain не видалить жодного Pod, якщо ви не скористаєтеся опцією --force. --force також дозволить продовжити видалення, якщо відсутній керуючий ресурс одного або декількох Podʼів.

'drain' чекає на коректне завершення. Ви не повинні працювати на машині, поки команда не завершиться.

Коли ви будете готові повернути вузол до експлуатації, скористайтеся командою kubectl uncordon, яка зробить вузол знову доступним для планування.

kubectl drain

kubectl drain NODE

Приклади

# Спорожнити вузол "foo", навіть якщо на ньому є Podʼи, які не керуються контролером реплікації, replica set, job, daemon set або stateful set
kubectl drain foo --force

# Як вище, але перервати, якщо наявні Podʼи, які не керуються контролером реплікації, replica set, job, daemon set або stateful set, і використовувати пільговий період у 15 хвилин
kubectl drain foo --grace-period=900

Параметри

--chunk-size int     Типово: 500

Повертати великі списки частинами, а не всі одразу. Для вимкнення задайте 0. Цей прапорець є бета-версією і може змінюватися в майбутньому.

--delete-emptydir-data

Продовжувати, навіть якщо є Podʼи, що використовують emptyDir (локальні дані, які буде видалено, коли вузол буде спорожнено).

--disable-eviction

Примусово виводити ресурси за допомогою delete, навіть якщо підтримується виселення. Це дозволить обійти перевірку PodDisruptionBudgets, використовуйте з обережністю.

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--force

Продовжувати, навіть якщо є Podʼи, які не задекларували контролер.

--grace-period int     Типово: -1

Період часу в секундах, який дається ресурсу для належного завершення роботи. Якщо значення відʼємне, то буде використано стандартне значення, вказане у Pod.

-h, --help

Довідка drain

--ignore-daemonsets

Ігнорувати Podʼи керовані DaemonSet.

--pod-selector string

Селектор міток для фільтрування Podʼів на вузлі

-l, --selector string

Селектор (запит на мітки) для фільтрації, що підтримує '=', '==' і '!=' (наприклад, -l key1=value1,key2=value2). Обʼєкти, щоб мати збіг, повинні задовольняти усім зазначеним обмеженням міток.

--skip-wait-for-delete-timeout int

Якщо хначення DeletionTimestamp Podʼа старіще за N секунд, пропускати очікування Podʼа. Значення секунд має бути більще за 0, щоб його оминути.

--timeout duration

Час очікування перед прийнятям рішення про відмову видалення, нуль означає нескіченно

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes

6.11.3.21 - kubectl edit

Огляд

Редагування ресурсу за допомогою стандартного редактора.

Команда edit дозволяє вам безпосередньо редагувати будь-який ресурс API, який ви можете отримати за допомогою інструментів командного рядка. Вона відкриє редактор, визначений вашими змінними оточення KUBE_EDITOR або EDITOR, або відкриє "vi" для Linux чи "notepad" для Windows. Під час спроби відкрити редактор спочатку буде використано оболонку, визначену у змінній оточення 'SHELL'. Якщо її не визначено, буде використано стандартну оболонку, якою є "/bin/bash" для Linux або "cmd" для Windows.

Ви можете редагувати декілька обʼєктів, хоча зміни застосовуються по одній за раз. Команда приймає імена файлів, а також аргументи командного рядка, хоча файли, на які ви вказуєте, мають бути попередньо збереженими версіями ресурсів.

Редагування виконується за допомогою версії API, використаної для отримання ресурсу. Щоб редагувати з використанням певної версії API, повністю вкажіть ресурс, версію і групу.

Стандартний формат — YAML. Для редагування у форматі JSON вкажіть "-o json".

Прапорець --windows-line-endings може бути використаний для забезпечення примусового завершення рядків у форматі Windows, інакше буде використано типовий для вашої операційної системи.

Якщо під час оновлення виникне помилка, на диску буде створено тимчасовий файл, який міститиме ваші незастосовані зміни. Найпоширенішою помилкою при оновленні ресурсу є зміна ресурсу на сервері іншим редактором. У цьому випадку вам доведеться застосувати ваші зміни до новішої версії ресурсу або оновити вашу тимчасову збережену копію, щоб вона містила останню версію ресурсу.

kubectl edit (RESOURCE/NAME | -f FILENAME)

Приклади

# Змінити сервіс з назвою 'registry'
kubectl edit svc/registry

# Використовувати альтернативний редактор
KUBE_EDITOR="nano" kubectl edit svc/registry

# Редагувати job 'myjob' у форматі JSON з використанням формату API v1
kubectl edit job.v1.batch/myjob -o json

# Редагувати deployment 'mydeployment' в YAML і зберегти змінений конфіг в його анотації
kubectl edit deployment/mydeployment -o yaml --save-config

# Редагувати субресурс 'status' для deployment 'mydeployment'
kubectl edit deployment mydeployment --subresource='status'

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--field-manager string     Типово: "kubectl-edit"

Імʼя менеджера, що використовується для відстеження права власності на поле.

-f, --filename strings

Імʼя файлу, теки або URL до файлів, для редагування ресурсів

-h, --help

Довідка edit

-k, --kustomize string

Обробити теку kustomization. Цей прапорець не можна використовувати разом з -f або -R.

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--output-patch

Вивести патч, якщо ресурс редагується.

-R, --recursive

Рекурсивно обробити теку, вказану у -f, --filename. Корисно, якщо ви хочете керувати повʼязаними маніфестами, організованими в одній теці.

--save-config

Якщо значення true, конфігурація поточного обʼєкта буде збережена в його анотації. В іншому випадку, анотацію буде збережено без змін. Цей прапорець корисно встановити, якщо ви хочете застосувати kubectl до цього обʼєкта у майбутньому.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--subresource string

Якщо вказано, редагування працюватиме з субресурсом запитуваного обʼєкта. Має бути одним із [status]. Цей прапорець є бета-версією і може змінюватися у майбутньому.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--validate string[="strict"]     Типово: "strict"

Повинно бути одним із: strict (або true), warn, ignore (або false).

"true" або "strict" буде використовувати схему для перевірки вводу і відхилятиме запит, якщо він невірний. Буде виконана перевірка на стороні сервера, якщо ServerSideFieldValidation увімкнено на api-server, але якщо ні, то повернеться до менш надійної перевірки на стороні клієнта.

"warn" попередить про невідомі або повторювані поля, не блокуючи запит, якщо на боці сервера API увімкнено перевірку полів, і буде поводитися як " ignore" у протилежному випадку.

"false" або "ignore" не виконуватимуть жодної перевірки схеми, мовчки відкидаючі будь-які невідомі або дубльовані поля.

--windows-line-endings

Стандартно використовується закінчення рядка, притаманне вашій платформі.

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes

6.11.3.22 - kubectl events

Огляд

Показати події.

Виводить таблицю з найважливішою інформацією про події. Ви можете запитувати події для простору імен, для всіх просторів імен або відфільтрувати лише ті, що стосуються вказаного ресурсу.

kubectl events [(-o|--output=)json|yaml|name|go-template|go-template-file|template|templatefile|jsonpath|jsonpath-as-json|jsonpath-file] [--for TYPE/NAME] [--watch] [--types=Normal,Warning]

Приклади

# Вивести список нещодавніх подій у стандартному просторі імен
kubectl events

# Показати нещодавні події у всіх просторах імен
kubectl events --all-namespaces

# Вивести список нещодавніх подій для вказаного pod, потім дочекатися нових подій і виводити їх по мірі надходження
kubectl events --for pod/web-pod-13je7 --watch

# Показати нещодавні події у форматі YAML
kubectl events -oyaml

# Показати лише нещодавні події типу 'Warning' або 'Normal'
kubectl events --types=Warning,Normal

Параметри

-A, --all-namespaces

Якщо вказано, показати список запитуваних обʼєктів у всіх просторах назв. Простір імен у поточному контексті ігнорується, навіть якщо вказано --namespace.

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--chunk-size int     Типово: 500

Повертати великі списки частинами, а не всі одразу. Для вимкнення задайте 0. Цей прапорець є бета-версією і може змінюватися в майбутньому.

--for string

Відфільтрувати події, щоб залишити лише ті, що стосуються вказаного ресурсу.

-h, --help

Довідка events

--no-headers

При використанні стандартного або власного формату виводу стовпців не друкувати заголовки.

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--types strings

Вивести лише події заданих типів.

-w, --watch

Після отримання списку бажаних подій слідкувати за новими подіями.

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes

6.11.3.23 - kubectl exec

Огляд

Виконує команду в контейнері.

kubectl exec (POD | TYPE/NAME) [-c CONTAINER] [flags] -- COMMAND [args...]

Приклади

# Отримати вивід від виконання команди 'date' з Pod mypod, використовуючи типово перший контейнер
kubectl exec mypod -- date

# Отримати вивід команди 'date' у ruby-контейнері з Pod mypod
kubectl exec mypod -c ruby-container -- date

# Перехід у режим необробленого терміналу; надсилає stdin до 'bash' у ruby-контейнері з Pod mypod
# і надсилає stdout/stderr з 'bash' назад клієнту
kubectl exec mypod -c ruby-container -i -t -- bash -il

# Вивести вміст /usr з першого контейнера Pod mypod і відсортувати за часом модифікації
# Якщо команда, яку ви хочете виконати в Pod, має спільні прапорці (наприклад, -i),
# ви повинні використовувати два тире (--), щоб відокремити прапорці/аргументи вашої команди.
# Також зауважте, що не слід брати команду та її прапорці/аргументи у лапки
# якщо тільки ви не виконуватимете її так у звичайному режимі (тобто, виконайте ls -t /usr, а не "ls -t /usr").
kubectl exec mypod -i -t -- ls -t /usr

# Отримання результатів виконання команди 'date' з першого Pod deployment mydeployment, з використанням стандартно першого контейнера
kubectl exec deploy/mydeployment -- date

# Отримати вивід команди 'date' з першого Pod сервісу myservice, використовуючи стандартно перший контейнер
kubectl exec svc/myservice -- date

Параметри

-c, --container string

Назва контейнера. Якщо не вказано, використовуйте анотацію kubectl.kubernetes.io/default-container для вибору контейнера, який буде приєднано, інакше буде обрано перший контейнер у pod

-f, --filename strings

Імʼя файлу, теки або URL до файлів, для виконання ресурсів

-h, --help

Довідка exec

--pod-running-timeout duration     Типово: 1m0s

Тривалість часу (наприклад, 5s, 2m або 3h, більше нуля) для очікування, поки не запрацює хоча б один Pod

-q, --quiet

Виводити лише дані, отримані під час віддаленого сеансу

-i, --stdin

Передати stdin до контейнера

-t, --tty

Stdin є TTY

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes

6.11.3.24 - kubectl explain

Огляд

Описує поля і структуру різних ресурсів.

Ця команда описує поля, повʼязані з кожним підтримуваним ресурсом API. Поля ідентифікуються за допомогою простого ідентифікатора JSONPath:

<type>.<fieldName>[.<fieldName>]

Інформація про кожне поле отримується з сервера у форматі OpenAPI.

Використовуйте "kubectl api-resources" для отримання повного списку підтримуваних ресурсів.

kubectl explain TYPE [--recursive=FALSE|TRUE] [--api-version=api-version-group] [--output=plaintext|plaintext-openapiv2]

Приклади

# Отримати документацію про ресурс та його поля
kubectl explain pods

# Отримати всі поля ресурсу
kubectl explain pods --recursive

# Отримати пояснення щодо deployment у підтримуваних версіях api
kubectl explain deployments --api-version=apps/v1

# Отримати документацію щодо певного поля ресурсу
kubectl explain pods.spec.containers

# Отримати документацію ресурсів у іншому форматі
kubectl explain deployment --output=plaintext-openapiv2

Параметри

--api-version string

Використовувати вказану api-version (group/version) ресурсу.

-h, --help

Довідка explain

--output string     Типово: "plaintext"

Формат, у якому потрібно показати схему. Допустимими значеннями є: (plaintext, plaintext-openapiv2).

--recursive

Якщо значення true, вивести назви всіх полів рекурсивно. Інакше, вивести доступні поля з їхнім описом.

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes

6.11.3.25 - kubectl expose

Огляд

Експонувати ресурс як нову службу Kubernetes.

Шукає deployment, service, replica set, replica controller або pod за назвою і використовує селектор для цього ресурсу як селектор для нового service на зазначеному порту. Deployment або replica set буде показано як сервіс, лише якщо його селектор буде перетворено на селектор, який підтримується сервісом, тобто коли селектор містить лише компонент matchLabels. Зауважте, що якщо за допомогою --port не вказано жодного порту, а експонований ресурс має декілька портів, усі вони будуть використані новим сервісом повторно. Також, якщо не вказано жодних міток, новий сервіс повторно використає мітки з ресурсу, який він відкриває.

Можливі ресурси включають (без урахування регістру):

pod (po), service (svc), replicationcontroller (rc), deployment (deploy), replicaset (rs)

kubectl expose (-f FILENAME | TYPE NAME) [--port=port] [--protocol=TCP|UDP|SCTP] [--target-port=number-or-name] [--name=name] [--external-ip=external-ip-of-service] [--type=type]

Приклади

# Створити сервіс для реплікованого nginx, який працює на порту 80 та підключається до контейнерів на порту 8000
kubectl expose rc nginx --port=80 --target-port=8000

# Створити сервіс для контролера реплікації, визначеного типом та іменем у "nginx-controller.yaml", який працює на порту 80 та підключається до контейнерів на порту 8000
kubectl expose -f nginx-controller.yaml --port=80 --target-port=8000

# Створити сервіс для Pod valid-pod, який працює на порту 444 з іменем "frontend"
kubectl expose pod valid-pod --port=444 --name=frontend

# Створити другий сервіс на основі вищезгаданого сервісу, відкриваючи контейнерний порт 8443 як порт 443 з іменем "nginx-https"
kubectl expose service nginx --port=443 --target-port=8443 --name=nginx-https

# Створити сервіс для реплікованого стрімінгового застосунку на порту 4100, балансуючи UDP-трафік, з імʼям 'video-stream'
kubectl expose rc streamer --port=4100 --protocol=UDP --name=video-stream

# Створити сервіс для реплікованого nginx за допомогою replica set, який працює на порту 80 та підключається до контейнерів на порту 8000
kubectl expose rs nginx --port=80 --target-port=8000

# Створити сервіс для deployment nginx, який працює на порту 80 та підключається до контейнерів на порту 8000
kubectl expose deployment nginx --port=80 --target-port=8000

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--cluster-ip string

ClusterIP, який буде призначено сервісу. Залиште порожнім для автоматичного призначення або встановіть значення "None", щоб створити сервіс headless.

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--external-ip string

Додаткова зовнішня IP-адреса (не керована Kubernetes), яку буде використано для сервісу. Якщо цю IP-адресу перенаправлено на вузол, до сервісу можна отримати доступ з цієї IP-адреси на додачу до згенерованої IP-адреси сервісу.

--field-manager string     Типово: "kubectl-expose"

Імʼя менеджера, що використовується для відстеження права власності на поле.

-f, --filename strings

Імʼя файлу, теки або URL до файлів, яки визначають ресурс, для експонування сервісу

-h, --help

Довідка expose

-k, --kustomize string

Обробити теку kustomization. Цей прапорець не можна використовувати разом з -f або -R.

-l, --labels string

Мітки, які будуть застосовані до сервісу, створеного цим викликом.

--load-balancer-ip string

IP для призначення LoadBalancer. Якщо поле порожнє, буде створено та використано ефемерний IP (залежить від хмарного провайдера).

--name string

Імʼя для новоствореного обʼєкта.

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--override-type string     Типово: "merge"

Метод, який використовується для перевизначення згенерованого обʼєкта: json, merge або strategic.

--overrides string

Вбудоване перевизначення JSON для згенерованого обʼєкта. Якщо він не порожній, то використовується для перевизначення згенерованого обʼєкта. Вимагає, щоб обʼєкт надавав дійсне поле apiVersion.

--port string

Порт, на якому має працювати сервіс. Копіюється з ресурсу, що експонується, якщо не вказано

--protocol string

Мережевий протокол для сервісу, який буде створено. Стандартно — "TCP".

-R, --recursive

Рекурсивно обробити теку, вказану у -f, --filename. Корисно, якщо ви хочете керувати повʼязаними маніфестами, організованими в одній теці.

--save-config

Якщо значення true, конфігурація поточного обʼєкта буде збережена в його анотації. В іншому випадку, анотацію буде збережено без змін. Цей прапорець корисно встановити, якщо ви хочете застосувати kubectl до цього обʼєкта у майбутньому.

--selector string

Селектор міток, який потрібно використовувати для цього сервісу. Підтримуються лише вимоги до селектора на основі рівності. Якщо порожньо (стандартно), виводитиметься селектор з контролера реплікації або replica set.

--session-affinity

Якщо не порожньо, встановлює сесійну подібнітсть для сервісу. Допустимі значення: None, ClientIP.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--target-port string

Назва або номер порту в контейнері, на який сервіс повинен спрямовувати трафік. Необовʼязково.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--type string

Тип сервісу: ClusterIP, NodePort, LoadBalancer або ExternalName. Стандартно використовується 'ClusterIP'.

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes

6.11.3.26 - kubectl get

Огляд

Показати один або декілька ресурсів.

Виводить таблицю з найважливішою інформацією про вказані ресурси. Ви можете відфільтрувати список за допомогою селектора міток і прапорця --selector. Якщо потрібний тип ресурсу є простором назв, ви побачите результати лише у поточному просторі назв, якщо не вказати якийсь namespaces.

Зазначивши виведення як "template" і надавши шаблон Go як значення прапорця --template, ви можете відфільтрувати атрибути отриманих ресурсів.

Для отримання повного списку підтримуваних ресурсів скористайтеся "kubectl api-resources".

kubectl get [(-o|--output=)json|yaml|name|go-template|go-template-file|template|templatefile|jsonpath|jsonpath-as-json|jsonpath-file|custom-columns|custom-columns-file|wide] (TYPE[.VERSION][.GROUP] [NAME | -l label] | TYPE[.VERSION][.GROUP]/NAME ...) [flags]

Приклади

# Вивести перелік всіх Podʼів у форматі виводу ps
kubectl get pods

# Вивести перелік всії Podʼів у форматі виводу ps з додатковою інформацією (наприклад, імʼя вузла)
kubectl get pods -o wide

# Вивести перелік один контролер реплікації з вказаним NAME у форматі виводу ps
kubectl get replicationcontroller web

# Вивести перелік deployment у форматі виводу JSON, у версії "v1" групи API "apps"
kubectl get deployments.v1.apps -o json

# Вивести один Pod у форматі виводу JSON
kubectl get -o json pod web-pod-13je7

# Вивести перелік Podʼів, визначений типом та іменем у "pod.yaml", у форматі виводу JSON
kubectl get -f pod.yaml -o json

# Вивести перелік ресурси з теки з kustomization.yaml - наприклад, dir/kustomization.yaml
kubectl get -k dir/

# Повернути лише значення фази вказаного Pod
kubectl get -o template pod/web-pod-13je7 --template={{.status.phase}}

# Вивести перелік інформації про ресурси у власних стовпцях
kubectl get pod test-pod -o custom-columns=CONTAINER:.spec.containers[0].name,IMAGE:.spec.containers[0].image

# Вивести перелік всіх контролерів реплікації та сервіси разом у форматі виводу ps
kubectl get rc,services

# Вивести перелік один або більше ресурсів за їх типом та іменами
kubectl get rc/web service/frontend pods/web-pod-13je7

# Вивести перелік субресурс 'status' для одного Pod
kubectl get pod web-pod-13je7 --subresource status

# Вивести перелік всіх deployments в namespace 'backend'
kubectl get deployments.apps --namespace backend

# Вивести перелік всіх pods пристуніх в усіх namespaces
kubectl get pods --all-namespaces

Параметри

-A, --all-namespaces

Якщо вказано, показати список запитуваних обʼєктів у всіх просторах назв. Простір імен у поточному контексті ігнорується, навіть якщо вказано --namespace.

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--chunk-size int     Типово: 500

Повертати великі списки частинами, а не всі одразу. Для вимкнення задайте 0. Цей прапорець є бета-версією і може змінюватися в майбутньому.

--field-selector string

Селектор (запит поля) для фільтрації підтримує '=', '==' і '!=' (наприклад, --field-selector key1=value1,key2=value2). Сервер підтримує лише обмежену кількість запитів до полів кожного типу.

-f, --filename strings

Імʼя файлу, теки або URL до файлів, яки визначають ресурс, для отримання з сервера.

-h, --help

Довідка get

--ignore-not-found

Якщо запитуваний обʼєкт не існує, команда поверне код виходу 0.

-k, --kustomize string

Обробити теку kustomization. Цей прапорець не можна використовувати разом з -f або -R.

-L, --label-columns strings

Приймає список міток, розділених комами, які буде представлено у вигляді стовпчиків. Назви чутливі до регістру. Ви також можете використовувати декілька прапорців, наприклад, -L label1 -L label2...

--no-headers

При використанні стандартного або власного формату виводу стовпців не друкувати заголовки (заголовки стандартно друкуються).

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file, custom-columns, custom-columns-file, wide).Дивіться нестандартні стовпці [https://kubernetes.io/docs/reference/kubectl/#custom-columns](/uk/docs/reference/kubectl/#custom-columns), шаблон golang [http://golang.org/pkg/text/template/#pkg-overview] та шаблон jsonpath [https://kubernetes.io/docs/reference/kubectl/jsonpath/](/uk/docs/reference/kubectl/jsonpath/).

--output-watch-events

Виводити обʼєкти подій спостереження, якщо використовується --watch або --watch-only. Існуючі обʼєкти виводяться як початкові події ADDED.

--raw string

Необроблений URI для запиту з сервер. Використовує транспорт, вказаний у файлі kubeconfig.

-R, --recursive

Рекурсивно обробити теку, вказану у -f, --filename. Корисно, якщо ви хочете керувати повʼязаними маніфестами, організованими в одній теці.

-l, --selector string

Селектор (запит на мітки) для фільтрації, що підтримує '=', '==' і '!=' (наприклад, -l key1=value1,key2=value2). Обʼєкти, щоб мати збіг, повинні задовольняти усім зазначеним обмеженням міток.

--server-print     Типово: true

Якщо це значення true, сервер має повернути відповідний вивід таблиці. Підтримує API розширення та CRD.

--show-kind

Якщо є, вкажіть тип ресурсу для запитуваного обʼєкта (обʼєктів).

--show-labels

Під час друку показувати всі мітки в останньому стовпчику (стандартно приховувати стовпчик міток)

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--sort-by string

Якщо поле не порожнє, відсортувати список ресурсів за вказаним полем. Специфікація поля виражається у вигляді виразу JSONPath (наприклад, '{.metadata.name}'). Поле в ресурсі API, визначене цим виразом JSONPath, має бути цілим чи рядком.

--subresource string

Якщо вказано, редагування працюватиме з субресурсом запитуваного обʼєкта. Має бути одним із [status scale]. Цей прапорець є бета-версією і може змінюватися у майбутньому.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

-w, --watch

Після отримання списку бажаних подій слідкувати за новими подіями.

--watch-only

Спостерігати за змінами запитуваного обʼєкта (обʼєктів), не переглядаючи/отримуючи їх спочатку.

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes

6.11.3.27 - kubectl kustomize

Огляд

Створення набору ресурсів KRM за допомогою файлу 'kustomization.yaml'. Аргумент DIR має бути шляхом до теки з файлом 'kustomization.yaml' або URL-адресою git-сховища з суфіксом шляху, що вказує на те саме відносно кореня сховища. Якщо DIR не вказано, буде використано символ ".".

kubectl kustomize DIR [flags]

Приклади

# Створити поточну робочу теку
kubectl kustomize

# Створити теку конфігурації зі спільним доступом
kubectl kustomize /home/config/production

# Побудувати з github
kubectl kustomize https://github.com/kubernetes-sigs/kustomize.git/examples/helloWorld?ref=v1.0.6

Параметри

--as-current-user

використовувати uid та gid виконавця команди для запуску функції в контейнері

--enable-alpha-plugins

увімкнути втулки kustomize

--enable-helm

Увімкніть використання генератора наповнювача чартів Helm.

-e, --env strings

список змінних оточення, які будуть використовуватися функціями

--helm-api-versions strings

Версії Kubernetes api, що використовуються Helm для Capabilities.APIVersions

--helm-command string     Типово: "helm"

команда helm (шлях до виконавчого файлу)

--helm-kube-version string

Версія Kubernetes, що використовується Helm для Capabilities.KubeVersion

-h, --help

Довідка kustomize

--load-restrictor string     Типово: "LoadRestrictionsRootOnly"

якщо встановлено значення 'LoadRestrictionsNone', локальні кастомізації можуть завантажувати файли ззовні свого кореня. Однак це порушує можливість переміщення кастомізації.

--mount strings

список параметрів сховища, отриманий з файлової системи

--network

вмикає доступ до мережі для функцій, які декларують про це

--network-name string     Типово: "bridge"

мережа docker для запуску контейнера

-o, --output string

Якщо вказано, записати вивід у цей шлях.

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes

6.11.3.28 - kubectl label

Огляд

Оновлює мітки ресурсів.

  • Ключ і значення мітки повинні починатися з літери або цифри і можуть містити літери, цифри, дефіси, крапки і підкреслення, до 63 символів кожна.
  • За бажанням, ключ може починатися з префікса субдомену DNS і одного символу "/", наприклад, example.com/my-app.
  • Якщо --overwrite має значення true, то наявні мітки можна перезаписати, інакше спроба перезаписати мітку призведе до помилки.
  • Якщо вказано --resource-version, то під час оновлення буде використано цю версію ресурсу, інакше буде використано наявну версію ресурсу.
kubectl label [--overwrite] (-f FILENAME | TYPE NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--resource-version=version]

Приклади

# Оновити pod 'foo' міткою 'unhealthy' і значенням 'true'
kubectl label pods foo unhealthy=true

# Оновити pod 'foo' міткою 'status' і значенням 'unhealthy', замінивши будь-яке існуюче значення
kubectl label --overwrite pods foo status=unhealthy

# Оновити всі pods у просторі назв
kubectl label pods --all status=unhealthy

# Оновити pod, визначений за типом та назвою у файлі "pod.json"
kubectl label -f pod.json status=unhealthy

# Оновлювати pod 'foo' тільки якщо ресурс не змінився з версії 1
kubectl label pods foo status=unhealthy --resource-version=1

# Оновити pod 'foo', видаливши мітку з назвою 'bar', якщо вона існує
# Не потребує прапорця --overwrite
kubectl label pods foo bar-

Параметри

--all

Вибрати всі ресурси у просторі імен вказаних типів ресурсів.

-A, --all-namespaces

Якщо true, перевірити вказану дію в усіх просторах імен.

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--field-manager string     Типово: "kubectl-label"

Імʼя менеджера, що використовується для відстеження права власності на поле.

--field-selector string

Селектор (запит поля) для фільтрації підтримує '=', '==' і '!=' (наприклад, --field-selector key1=value1,key2=value2). Сервер підтримує лише обмежену кількість запитів до полів кожного типу.

-f, --filename strings

Імʼя файлу, теки або URL до файлів, яки визначають ресурс, для оновлення міток.

-h, --help

Довідка label

-k, --kustomize string

Обробити теку kustomization. Цей прапорець не можна використовувати разом з -f або -R.

--list

Якщо true, показувати мітки для даного ресурсу.

--local

Якщо значення true, мітка НЕ буде звертатися до api-server, а виконуватиметься локально.

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--overwrite

Якщо true, дозволити перезапис міток, інакше відхиляти оновлення міток, які перезаписують наявні мітки.

-R, --recursive

Рекурсивно обробити теку, вказану у -f, --filename. Корисно, якщо ви хочете керувати повʼязаними маніфестами, організованими в одній теці.

--resource-version string

Якщо значення не порожнє, оновлення мітки буде успішним, тільки якщо це поточна версія ресурсу для обʼєкта. Дійсно лише при зазначенні одного ресурсу.

-l, --selector string

Селектор (запит на мітки) для фільтрації, що підтримує '=', '==' і '!=' (наприклад, -l key1=value1,key2=value2). Обʼєкти, щоб мати збіг, повинні задовольняти усім зазначеним обмеженням міток.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes

6.11.3.29 - kubectl logs

Огляд

Вивести логи для контейнера у Podʼі або вказаного ресурсу. Якщо в pod є лише один контейнер, назва контейнера не є обовʼязковою.

kubectl logs [-f] [-p] (POD | TYPE/NAME) [-c CONTAINER]

Приклади

# Вивести знімок логів з Podʼа nginx з одним контейнером
kubectl logs nginx

# Вивести знімок логів з Podʼа nginx з кількома контейнерами
kubectl logs nginx --all-containers=true

# Вивести знімок логів з усіх контейнерів у Podʼах, визначених міткою app=nginx
kubectl logs -l app=nginx --all-containers=true

# Вивести знімок логів з попереднього завершеного контейнера ruby з Podʼа web-1
kubectl logs -p -c ruby web-1

# Почати трансляцію логів контейнера ruby у Podʼі web-1
kubectl logs -f -c ruby web-1

# Почати трансляцію логів з усіх контейнерів у Podʼах, визначених міткою app=nginx
kubectl logs -f -l app=nginx --all-containers=true

# Показати лише останні 20 рядків виводу в Podʼі nginx
kubectl logs --tail=20 nginx

# Показати всі логи з Podʼа nginx, записані за останню годину
kubectl logs --since=1h nginx

# Показати логи з kubelet з простроченим сертифікатом сервера
kubectl logs --insecure-skip-tls-verify-backend nginx

# Вивести знімок логів з першого контейнера завдання з назвою hello
kubectl logs job/hello

# Вивести знімок логів з контейнера nginx-1 у deployment з назвою nginx
kubectl logs deployment/nginx -c nginx-1

Параметри

--all-containers

Отримайте логи всіх контейнерів у pod(ах).

--all-pods

Отримати логи з усіх Pod(ів). Встановлює префікс у true.

-c, --container string

Вивести логи цього контейнера

-f, --follow

Вкажіть, чи потрібно транслювати логи.

-h, --help

Довідка logs

--ignore-errors

Якщо ви переглядаєте / стежите за логами pod, дозвольте будь-яким помилкам, що трапляються, бути не фатальними

--insecure-skip-tls-verify-backend

Пропустити перевірку ідентичності kubelet, з якого запитуються логи. Теоретично, зловмисник може повернути недійсний вміст логу. Можливо, ви захочете використати цей параметр, якщо термін дії сертифікатів, що обслуговують ваш kubelet, закінчився.

--limit-bytes int

Максимальна кількість байт логів для виводу. Стандартно без обмежень.

--max-log-requests int     Типово: 5

Вкажіть максимальну кількість паралельних логів, які слід відстежувати при використанні селектора. Стандартно встановлено значення 5.

--pod-running-timeout duration     Типово: 20s

Тривалість часу (наприклад, 5s, 2m або 3h, більше нуля) для очікування, поки не запрацює хоча б один Pod

--prefix

До початку кожного рядка логу додайте джерело логу (імʼя pod та імʼя контейнера)

-p, --previous

Якщо true, вивести логи для попереднього екземпляра контейнера в pod, якщо він існує.

-l, --selector string

Селектор (запит на мітки) для фільтрації, що підтримує '=', '==' і '!=' (наприклад, -l key1=value1,key2=value2). Обʼєкти, щоб мати збіг, повинні задовольняти усім зазначеним обмеженням міток.

--since duration

Виводити лише ті логи, що є новішими за відносну тривалість, наприклад, 5s, 2m або 3h. Стандартно для всіх логів. Можна використовувати лише один з параметрів since-time / since.

--since-time string

Виводити логи лише після певної дати (RFC3339). Стандартно для всіх логів. Можна використовувати лише один з параметрів since-time / since.

--tail int     Типово: -1

Рядки нещодавнього файлу логу для показу. Стандартно дорівнює -1 без селектора, показуючи всі рядки логу, інакше 10, якщо селектор вказано.

--timestamps

Додайте мітки часу до кожного рядка у виводі логу

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes

6.11.3.30 - kubectl options

Огляд

Виводить список прапорців, успадкованих усіма командами

kubectl options [flags]

Приклади

# Вивести список прапорців, успадкованих усіма командами
kubectl options

Параметри

-h, --help

Довідка options

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes

6.11.3.31 - kubectl patch

Огляд

Оновлення полів ресурсу за допомогою патча стратегічного злиття, патча злиття JSON або патча JSON.

Підтримуються формати JSON і YAML.

Примітка: Стратегічне злиття не підтримується для власних ресурсів користувача.

kubectl patch (-f FILENAME | TYPE NAME) [-p PATCH|--patch-file FILE]

Приклади

# Частково оновити вузол за допомогою патчів стратегічного злиття, вказавши патч як JSON
kubectl patch node k8s-node-1 -p '{"spec":{"unschedulable":true}}'

# Частково оновити вузол за допомогою патчів стратегічного злиття, вказавши патч як YAML
kubectl patch node k8s-node-1 -p $'spec:\n unschedulable: true'

# Частково оновити вузол, визначений типом та імʼям у "node.json", за допомогою патчів стратегічного злиття
kubectl patch -f node.json -p '{"spec":{"unschedulable":true}}'

# Оновити образ контейнера; spec.containers[*].name є обовʼязковим, оскільки це ключ для злиття
kubectl patch pod valid-pod -p '{"spec":{"containers":[{"name":"kubernetes-serve-hostname","image":"new image"}]}}'

# Оновити образ контейнера за допомогою патча JSON з позиційними масивами
kubectl patch pod valid-pod --type='json' -p='[{"op": "replace", "path": "/spec/containers/0/image", "value":"new image"}]'

# Оновити кількість реплік deployment через субресурс 'scale' за допомогою злиття патчів
kubectl patch deployment nginx-deployment --subresource='scale' --type='merge' -p '{"spec":{"replicas":2}}'

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--field-manager string     Типово: "kubectl-patch"

Імʼя менеджера, що використовується для відстеження права власності на поле.

-f, --filename strings

Імʼя файлу, теки або URL до файлів, яки визначають ресурс для оновлення.

-h, --help

Довідка patch

-k, --kustomize string

Обробити теку kustomization. Цей прапорець не можна використовувати разом з -f або -R.

--local

Якщо true, патч буде працювати з вмістом файлу, а не з ресурсом на стороні сервера.

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

-p, --patch string

Патч, який буде застосовано до JSON-файлу ресурсу.

--patch-file string

Файл, що містить патч, який буде застосовано до ресурсу.

-R, --recursive

Рекурсивно обробити теку, вказану у -f, --filename. Корисно, якщо ви хочете керувати повʼязаними маніфестами, організованими в одній теці.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--subresource string

Якщо вказано, редагування працюватиме з субресурсом запитуваного обʼєкта. Має бути одним із [status scale]. Цей прапорець є бета-версією і може змінюватися у майбутньому.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--type string     Типово: "strategic"

Тип патчу, що застосовується; один з [json merge strategic].

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes

6.11.3.32 - kubectl plugin

Впроваджує утиліти для взаємодії з втулками.

Втулки надають розширену функціональність, яка не є частиною основного коду kubectl. Будь ласка, зверніться до документації та прикладів для отримання додаткової інформації про те, як писати власні втулки.

Найпростіший спосіб знайти та встановити втулки — за допомогою субпроєкту kubernetes krew. Щоб встановити krew, відвідайте krew.sigs.k8s.io.

kubectl plugin [flags]

Приклади

# Вивести перелік всіх доступних втулків
kubectl plugin list

# Вивести перелік назв двійкових файлів доступних втулків без шляхів
kubectl plugin list --name-only

Параметри

-h, --help

Довідка plugin

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes
  • kubectl plugin list — список усіх виконуваних файлів втулків видимих у PATH користувача

6.11.3.32.1 - kubectl plugin list

Огляд

Показати всі доступні файли втулків у PATH користувача. Для виводу тільки назв двійкових файлів використовуйте прапорець --name-only.

Доступними вважаються файли втулків, які є:

  • виконуваними
  • будь-де в PATH користувача
  • починаються з "kubectl-"
kubectl plugin list [flags]

Приклади

# Вивести перелік всіх доступних втулків
kubectl plugin list

# Вивести перелік назв двійкових файлів доступних втулків без шляхів
kubectl plugin list --name-only

Параметри

-h, --help

Довідка list

--name-only

Якщо значення true, показувати лише назву команди кожного втулка, а не повний шлях до нього

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl plugin — Впроваджує утиліти для взаємодії з втулками.

6.11.3.33 - kubectl port-forward

Огляд

Перенаправте один або кілька локальних портів у Pod.

Використовуйте тип/назву ресурсу, наприклад, deployment/mydeployment, для вибору Podʼа. Якщо його не вказано, тип ресурсу стандартно дорівнюватиме 'pod'.

Якщо є кілька Podʼів, що відповідають критеріям, автоматично буде обрано один з них. Сеанс перенаправлення завершується після завершення роботи вибраного Podʼа, і для відновлення перенаправлення потрібно повторно виконати команду.

kubectl port-forward TYPE/NAME [options] [LOCAL_PORT:]REMOTE_PORT [...[LOCAL_PORT_N:]REMOTE_PORT_N]

Приклади

# Слухати на портах 5000 і 6000 локально, перенаправляючи дані з/на порти 5000 і 6000 у Pod
kubectl port-forward pod/mypod 5000 6000

# Слухати на портах 5000 і 6000 локально, перенаправляючи дані з/на порти 5000 і 6000 у Pod, обраний за допомогою deployment
kubectl port-forward deployment/mydeployment 5000 6000

# Слухати на порту 8443 локально, перенаправляючи на targetPort порту сервісу з імʼям "https" у Pod, обраний за допомогою сервісу
kubectl port-forward service/myservice 8443:https

# Слухати на порту 8888 локально, перенаправляючи на порт 5000 у Pod
kubectl port-forward pod/mypod 8888:5000

# Слухати на порту 8888 на всіх адресах, перенаправляючи на порт 5000 у Pod
kubectl port-forward --address 0.0.0.0 pod/mypod 8888:5000

# Слухати на порту 8888 на localhost та вибраній IP-адресі, перенаправляючи на порт 5000 у Pod
kubectl port-forward --address localhost,10.19.21.23 pod/mypod 8888:5000

# Слухати на випадковому порту локально, перенаправляючи на 5000 у Pod
kubectl port-forward pod/mypod :5000

Параметри

--address strings     Типово: "localhost"

Адреси для прослуховування (через кому). Допускається вказувати лише IP-адреси або localhost. Якщо вказано localhost, kubectl спробує привʼязатися до адрес 127.0.0.1 та ::1 і завершить роботу, якщо жодна з цих адрес не буде доступною для привʼязки.

-h, --help

Довідка port-forward

--pod-running-timeout duration     Типово: 1m0s

Тривалість часу (наприклад, 5s, 2m або 3h, більше нуля) для очікування, поки не запрацює хоча б один Pod

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes

6.11.3.34 - kubectl proxy

Огляд

Створює проксі-сервер або шлюз на рівні програми між localhost і сервером API Kubernetes. Він також дозволяє передавати статичний вміст за вказаним HTTP-шляхом. Всі вхідні дані надходять через один порт і перенаправляються на порт віддаленого сервера Kubernetes API, за винятком шляху, що збігається зі шляхом до статичного контенту.

kubectl proxy [--port=PORT] [--www=static-dir] [--www-prefix=prefix] [--api-prefix=prefix]

Приклади

# Проксіювати Kubernetes API і більше нічого
kubectl proxy --api-prefix=/

# Проксіювати лише частину Kubernetes API та деякі статичні файли
# Ви можете отримати інформацію про Podʼи за допомогою 'curl localhost:8001/api/v1/pods'
kubectl proxy --www=/my/files --www-prefix=/static/ --api-prefix=/api/

# Проксіювати весь Kubernetes API за іншим коренем
# Ви можете отримати інформацію про Podʼи за допомогою 'curl localhost:8001/custom/api/v1/pods'
kubectl proxy --api-prefix=/custom/

# Запустити проксі до сервера Kubernetes API на порту 8011, обслуговуючи статичний контент з ./local/www/
kubectl proxy --port=8011 --www=./local/www/

# Запустити проксі до сервера Kubernetes API на довільному локальному порту
# Обраний порт для сервера буде виведено в stdout
kubectl proxy --port=0

# Запустити проксі до сервера Kubernetes API, змінюючи префікс API на k8s-api
# Це робить, наприклад, API підів доступним за адресою localhost:8001/k8s-api/v1/pods/
kubectl proxy --api-prefix=/k8s-api

Параметри

--accept-hosts string     Типово: "^localhost$,^127\.0\.0\.1$,^\[::1\]$"

Регулярний вираз для хостів, які повинен приймати проксі.

--accept-paths string     Типово: "^.*"

Регулярний вираз для шляхів, які повинен приймати проксі.

--address string     Типово: "127.0.0.1"

IP-адреса, на якій буде здійснюватися обслуговування.

--api-prefix string     Типово: "/"

Префікс для обслуговування проксі API.

--append-server-path

Якщо значення true, вмикає автоматичне додавання шляху до сервера kube context до кожного запиту.

--disable-filter

Якщо це значення встановлено, воно вимикає фільтрацію запитів у проксі-сервері. Це небезпечно і може зробити вас вразливими до XSRF-атак, якщо ви використовуєте відкритий порт.

-h, --help

Довідка proxy

--keepalive duration

keepalive задає період підтримки активного мережевого зʼєднання. Встановіть значення 0, щоб вимкнути keepalive.

-p, --port int     Типово: 8001

Порт, на якому буде запущено проксі. Встановіть 0, щоб вибрати випадковий порт.

--reject-methods string     Типово: "^$"

Регулярний вираз для HTTP-методів, які проксі повинен відхиляти (еаприклад --reject-methods='POST,PUT,PATCH').

--reject-paths string     Типово: "^/api/.*/pods/.*/exec,
^/api/.*/pods/.*/attach"

Регулярний вираз для шляхів, які проксі має відхиляти. Шляхи, вказані тут, буде відхилено, навіть якщо їх буде прийнято за допомогою --accept-paths.

-u, --unix-socket string

Сокет Unix, на якому буде запущено проксі.

-w, --www string

Також обслуговуватимуться статичні файли із заданої теки з вказаним префіксом.

-P, --www-prefix string     Типово: "/static/"

Префікс для обслуговування статичних файлів, якщо вказано теку зі статичними файлами.

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes

6.11.3.35 - kubectl replace

Огляд

Заміна ресурсу за назвою файлу або stdin.

Приймаються формати JSON та YAML. Якщо ви замінюєте наявний ресурс, необхідно надати повну специфікацію ресурсу. Її можна отримати за допомогою

kubectl get TYPE NAME -o yaml
kubectl replace -f FILENAME

Приклади

# Замінити pod, використовуючи дані з pod.json
kubectl replace -f ./pod.json

# Замінити pod на основі JSON, переданого в stdin
cat pod.json | kubectl replace -f -

# Оновити версію образу (тег) одноконтейнерного pod до v4
kubectl get pod mypod -o yaml | sed 's/\(image: myimage\):.*$/\1:v4/' | kubectl replace -f -

# Примусово замінити, видалити, а потім перестворити ресурс
kubectl replace --force -f ./pod.json

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--cascade string[="background"]     Типово: "background"

Має бути "background", "orphan" або "foreground". Вибирає стратегію каскадного видалення для залежних елементів (наприклад, Podʼів, створених Replication Controller). Стандартне значення — background.

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--field-manager string     Типово: "kubectl-replace"

Імʼя менеджера, що використовується для відстеження права власності на поле.

-f, --filename strings

Імʼя файлів, яки містять конфігурацію для заміни.

--force

Якщо true, негайно видалити ресурси з API і обійти належне видалення. Зверніть увагу, що негайне видалення деяких ресурсів може призвести до неузгодженості або втрати даних і потребує підтвердження.

--grace-period int     Типово: -1

Період часу в секундах, який дається ресурсу для належного завершення роботи. Якщо значення відʼємнеі – ігнорується. Встановіть значення 1 для негайного припинення роботи. Можна встановити у 0, лише якщо --force має значення true (примусове видалення).

-h, --help

Довідка replace

-k, --kustomize string

Обробити теку kustomization. Цей прапорець не можна використовувати разом з -f або -R.

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--raw string

Необроблений URI для PUT на сервер. Використовує транспорт, вказаний у файлі kubeconfig.

-R, --recursive

Рекурсивно обробити теку, вказану у -f, --filename. Корисно, якщо ви хочете керувати повʼязаними маніфестами, організованими в одній теці.

--save-config

Якщо значення true, конфігурація поточного обʼєкта буде збережена в його анотації. В іншому випадку, анотацію буде збережено без змін. Цей прапорець корисно встановити, якщо ви хочете застосувати kubectl до цього обʼєкта у майбутньому.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--subresource string

Якщо вказано, редагування працюватиме з субресурсом запитуваного обʼєкта. Має бути одним із [status scale]. Цей прапорець є бета-версією і може змінюватися у майбутньому.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--timeout duration

Час очікування перед прийнятям рішення про відмову видалення, нуль означає визначення тайм-ауту за розміром обʼєкту

--validate string[="strict"]     Типово: "strict"

Повинно бути одним із: strict (або true), warn, ignore (або false).

"true" або "strict" буде використовувати схему для перевірки вводу і відхилятиме запит, якщо він невірний. Буде виконана перевірка на стороні сервера, якщо ServerSideFieldValidation увімкнено на api-server, але якщо ні, то повернеться до менш надійної перевірки на стороні клієнта.

"warn" попередить про невідомі або повторювані поля, не блокуючи запит, якщо на боці сервера API увімкнено перевірку полів, і буде поводитися як " ignore" у протилежному випадку.

"false" або "ignore" не виконуватимуть жодної перевірки схеми, мовчки відкидаючі будь-які невідомі або дубльовані поля.

--wait

Якщо true, очікувати, поки ресурси зникнуть, перш ніж повернутися. Очікує фіналізаторів.

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes

6.11.3.36 - kubectl rollout

Керування розгортанням одного або декількох ресурсів.

Допустимі типи ресурсів включають:

  • deployments
  • daemonsets
  • statefulsets
kubectl rollout SUBCOMMAND

Приклади

# Відкотитись до попереднього deployment
kubectl rollout undo deployment/abc

# Перевірити статус розгортання daemonset
kubectl rollout status daemonset/foo

# Перезапустити deployment
kubectl rollout restart deployment/abc

# Перезапустити deployment з міткою 'app=nginx'
kubectl rollout restart deployment --selector=app=nginx

Параметри

-h, --help

Довідка rollout

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

6.11.3.36.1 - kubectl rollout history

Огляд

Переглянути попередні версії та конфігурації розгортання.

kubectl rollout history (TYPE NAME | TYPE/NAME) [flags]

Приклади

# Переглянути історію розгортання deployment
kubectl rollout history deployment/abc

# Переглянути деталі daemonset ревізії 3
kubectl rollout history daemonset/abc --revision=3

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

-f, --filename strings

Імʼя файлу, теки або URL до файлів, що ідентифікують ресурс, який потрібно отримати з сервера.

-h, --help

Довідка history

-k, --kustomize string

Обробити теку kustomization. Цей прапорець не можна використовувати разом з -f або -R.

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

-R, --recursive

Рекурсивно обробити теку, вказану у -f, --filename. Корисно, якщо ви хочете керувати повʼязаними маніфестами, організованими в одній теці.

--revision int

Переглянути деталі, включаючи podTemplate вказаної ревізії

-l, --selector string

Селектор (запит на мітки) для фільтрації, що підтримує '=', '==' і '!=' (наприклад, -l key1=value1,key2=value2). Обʼєкти, щоб мати збіг, повинні задовольняти усім зазначеним обмеженням міток.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl rollout – Керування розгортанням ресурсів

6.11.3.36.2 - kubectl rollout pause

Огляд

Позначає вказані ресурси як призупинені.

Призупинені ресурси не будуть узгоджуватися контролером. Щоб відновити роботу призупиненого ресурсу, скористайтеся "kubectl rollout resume". Наразі призупинення підтримується лише у deployment.

kubectl rollout pause RESOURCE

Приклади

# Позначити deployment nginx як призупинений
# Будь-який поточний стан deployment продовжить свою роботу; нові оновлення
# deployment не матимуть ефекту, доки deployment призупинено
kubectl rollout pause deployment/nginx

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--field-manager string     Типово: "kubectl-rollout"

Імʼя менеджера, що використовується для відстеження права власності на поле.

-f, --filename strings

Імʼя файлу, теки або URL до файлів, що ідентифікують ресурс, який потрібно отримати з сервера.

-h, --help

Довідка pause

-k, --kustomize string

Обробити теку kustomization. Цей прапорець не можна використовувати разом з -f або -R.

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

-R, --recursive

Рекурсивно обробити теку, вказану у -f, --filename. Корисно, якщо ви хочете керувати повʼязаними маніфестами, організованими в одній теці.

-l, --selector string

Селектор (запит на мітки) для фільтрації, що підтримує '=', '==' і '!=' (наприклад, -l key1=value1,key2=value2). Обʼєкти, щоб мати збіг, повинні задовольняти усім зазначеним обмеженням міток.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl rollout – Керування розгортанням ресурсів

6.11.3.36.3 - kubectl rollout restart

Огляд

Перезапускає ресурс.

Розгортання ресурсів буде перезапущено.

kubectl rollout restart RESOURCE

Приклади

# Перезапустити всі deployment у просторі імен test-namespace
kubectl rollout restart deployment -n test-namespace

# Перезапустіть deployment
kubectl rollout restart deployment/nginx

# Перезапустити набір демонів
kubectl rollout restart daemonset/abc

# Перезапустити deployment з міткою app=nginx
kubectl rollout restart deployment --selector=app=nginx

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--field-manager string     Типово: "kubectl-rollout"

Імʼя менеджера, що використовується для відстеження права власності на поле.

-f, --filename strings

Імʼя файлу, теки або URL до файлів, що ідентифікують ресурс, який потрібно отримати з сервера.

-h, --help

Довідка restart

-k, --kustomize string

Обробити теку kustomization. Цей прапорець не можна використовувати разом з -f або -R.

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

-R, --recursive

Рекурсивно обробити теку, вказану у -f, --filename. Корисно, якщо ви хочете керувати повʼязаними маніфестами, організованими в одній теці.

-l, --selector string

Селектор (запит на мітки) для фільтрації, що підтримує '=', '==' і '!=' (наприклад, -l key1=value1,key2=value2). Обʼєкти, щоб мати збіг, повинні задовольняти усім зазначеним обмеженням міток.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl rollout – Керування розгортанням ресурсів

6.11.3.36.4 - kubectl rollout resume

Огляд

Відновити роботу призупиненого ресурсу.

Призупинені ресурси не будуть узгоджуватися контролером. Відновивши ресурс, ми дозволимо йому знову бути узгодженим. Наразі лише deployments підтримують відновлення.

kubectl rollout resume RESOURCE

Приклади

# Відновити роботу призупиненого deployment
kubectl rollout resume deployment/nginx

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--field-manager string     Типово: "kubectl-rollout"

Імʼя менеджера, що використовується для відстеження права власності на поле.

-f, --filename strings

Імʼя файлу, теки або URL до файлів, що ідентифікують ресурс, який потрібно отримати з сервера.

-h, --help

Довідка resume

-k, --kustomize string

Обробити теку kustomization. Цей прапорець не можна використовувати разом з -f або -R.

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

-R, --recursive

Рекурсивно обробити теку, вказану у -f, --filename. Корисно, якщо ви хочете керувати повʼязаними маніфестами, організованими в одній теці.

-l, --selector string

Селектор (запит на мітки) для фільтрації, що підтримує '=', '==' і '!=' (наприклад, -l key1=value1,key2=value2). Обʼєкти, щоб мати збіг, повинні задовольняти усім зазначеним обмеженням міток.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl rollout – Керування розгортанням ресурсів

6.11.3.36.5 - kubectl rollout status

Огляд

Показувати статус розгортання.

Стандартно "rollout status" буде стежити за статусом останнього розгортання, доки воно не завершиться. Якщо ви не бажаєте чекати на завершення розгортання, ви можете використати --watch=false. Зауважте, що якщо у проміжку між ними розпочнеться нове розгортання, то "rollout status" продовжуватиме стежити за останньою ревізією. Якщо ви хочете привʼязатися до певної ревізії і перервати процес, якщо його буде перенесено на іншу ревізію, скористайтеся --revision=N, де N — ревізія, за якою ви хочете стежити.

kubectl rollout status (TYPE NAME | TYPE/NAME) [flags]

Приклади

# Перегляд статусу розгортання deployment
kubectl rollout status deployment/nginx

Параметри

-f, --filename strings

Імʼя файлу, теки або URL до файлів, що ідентифікують ресурс, який потрібно отримати з сервера.

-h, --help

Довідка status

-k, --kustomize string

Обробити теку kustomization. Цей прапорець не можна використовувати разом з -f або -R.

-R, --recursive

Рекурсивно обробити теку, вказану у -f, --filename. Корисно, якщо ви хочете керувати повʼязаними маніфестами, організованими в одній теці.

--revision int

Закріпити за певною ревізією для показу її статусу. Стандартно дорівнює 0 (остання ревізія).

-l, --selector string

Селектор (запит на мітки) для фільтрації, що підтримує '=', '==' і '!=' (наприклад, -l key1=value1,key2=value2). Обʼєкти, щоб мати збіг, повинні задовольняти усім зазначеним обмеженням міток.

--timeout duration

Час очікування перед прийнятям рішення про відмову видалення, нуль означає визначення тайм-ауту за розміром обʼєкту

-w, --watch     Типово: true

Відстежувати статус розгортання, доки воно не завершиться.

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl rollout — Керування розгортанням ресурсів

6.11.3.36.6 - kubectl rollout undo

Огляд

Повернення до попереднього розгортання.

kubectl rollout undo (TYPE NAME | TYPE/NAME) [flags]
# Відкотитися до попередньої версії deployment
kubectl rollout undo deployment/abc

# Відкотитися до ревізії 3 daemonset
kubectl rollout undo daemonset/abc --to-revision=3

# Перевірити відкат до попередньої версії за допомогою dry-run
kubectl rollout undo --dry-run=server deployment/abc

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

-f, --filename strings

Імʼя файлу, теки або URL до файлів, що ідентифікують ресурс, який потрібно отримати з сервера.

-h, --help

Довідка undo

-k, --kustomize string

Обробити теку kustomization. Цей прапорець не можна використовувати разом з -f або -R.

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

-R, --recursive

Рекурсивно обробити теку, вказану у -f, --filename. Корисно, якщо ви хочете керувати повʼязаними маніфестами, організованими в одній теці.

-l, --selector string

Селектор (запит на мітки) для фільтрації, що підтримує '=', '==' і '!=' (наприклад, -l key1=value1,key2=value2). Обʼєкти, щоб мати збіг, повинні задовольняти усім зазначеним обмеженням міток.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--to-revision int

Ревізія для відкату. Стандартно 0 (остання ревізія).

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl rollout – Керування розгортанням ресурсів

6.11.3.37 - kubectl run

Огляд

Створити та запустити певний образ у Pod.

kubectl run NAME --image=image [--env="key=value"] [--port=port] [--dry-run=server|client] [--overrides=inline-json] [--command] -- [COMMAND] [args...]

Приклади

# Запустити pod nginx
kubectl run nginx --image=nginx

# Запустити pod hazelcast і дозволити контейнеру відкривати порт 5701
kubectl run hazelcast --image=hazelcast/hazelcast --port=5701

# Запустити pod hazelcast і встановити змінні середовища "DNS_DOMAIN=cluster" та "POD_NAMESPACE=default" у контейнері
kubectl run hazelcast --image=hazelcast/hazelcast --env="DNS_DOMAIN=cluster" --env="POD_NAMESPACE=default"

# Запустити pod hazelcast і встановити мітки "app=hazelcast" та "env=prod" у контейнері
kubectl run hazelcast --image=hazelcast/hazelcast --labels="app=hazelcast,env=prod"

# Імітація запуску; вивести відповідні обʼєкти API без їх створення
kubectl run nginx --image=nginx --dry-run=client

# Запустити pod nginx, але перевантажити spec частковим набором значень, розібраних з JSON
kubectl run nginx --image=nginx --overrides='{ "apiVersion": "v1", "spec": { ... } }'

# Запустити pod busybox і тримати його на передньому плані, не перезапускати його, якщо він завершиться
kubectl run -i -t busybox --image=busybox --restart=Never

# Запустити pod nginx, використовуючи стандартну команду, але використовуючи власні аргументи (arg1 .. argN) для цієї команди
kubectl run nginx --image=nginx -- <arg1> <arg2> ... <argN>

# Запустити pod nginx, використовуючи іншу команду та власні аргументи
kubectl run nginx --image=nginx --command -- <cmd> <arg1> ... <argN>

Параметри

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--annotations strings

Анотації для застосування до pod.

--attach

Якщо значення true, дочекайтеся запуску Pod, а потім приєднайтеся до нього так, ніби було викликано команду 'kubectl attach ...'. Стандартно має значення false, якщо не задано параметр '-i/--stdin', у цьому випадку значення буде true. За допомогою '--restart=Never' повертається код завершення процесу контейнера.

--cascade string[="background"]     Default: "background"

Має бути "background", "orphan" або "foreground". Вибирає стратегію каскадного видалення для залежних елементів (наприклад, Pods, створених ReplicationController). Стандартно — background.

--command

Якщо присутні істинні та додаткові аргументи, використовуйте їх як поле 'command' у контейнері, а не поле 'args', яке використовується стандартно.

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--env strings

Змінні оточення для установки в контейнері.

--expose --port

Якщо значення true, створить сервіс ClusterIP, асоційований з podʼом. Потрібен --port.

--field-manager string     Типово: "kubectl-run"

Імʼя менеджера, що використовується для відстеження права власності на поле.

-f, --filename strings

імʼя файлу для заміни ресурсу.

--force

Якщо true, негайно видалити ресурси з API і обійти належне видалення. Зверніть увагу, що негайне видалення деяких ресурсів може призвести до неузгодженості або втрати даних і потребує підтвердження.

--grace-period int     Default: -1

Період часу в секундах, який дається ресурсу для належного завершення роботи. Ігнорується, якщо значення відʼємне. Встановлюється у 1 для негайного завершення роботи. Може бути встановлено у 0, тільки якщо --force має значення true (примусове видалення).

-h, --help

Довідка run

--image string

Назва образу контейнера для запуску.

--image-pull-policy string

Політика отримання образів для контейнера. Якщо залишити порожнім, це значення не буде вказано клієнтом і буде використано сервером стандартна поведінка.

-k, --kustomize string

Обробити теку kustomization. Цей прапорець не можна використовувати разом з -f або -R.

-l, --labels string

Мітки через кому для застосування до pod. Перевизначить попередні значення.

--leave-stdin-open

Якщо pod запущено в інтерактивному режимі або за допомогою stdin, залиште stdin відкритим після завершення першого приєднання. Типово, stdin буде закрито після завершення першого приєднання.

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--override-type string     Типово: "merge"

Метод, який використовується для перевизначення згенерованого обʼєкта: json, merge або strategic.

--overrides string

Вбудоване перевизначення JSON для згенерованого обʼєкта. Якщо він не порожній, то використовується для перевизначення згенерованого обʼєкта. Вимагає, щоб обʼєкт надавав дійсне поле apiVersion.

--pod-running-timeout duration     Типово: 1m0s

Тривалість часу (наприклад, 5s, 2m або 3h, більше нуля) для очікування, поки не запрацює хоча б один Pod

--port string

Порт, який експонує цей контейнер.

--privileged

Якщо true, запустити контейнер у привілейованому режимі.

-q, --quiet

Якщо true, не виводити повідомлення.

-R, --recursive

Рекурсивно обробити теку, вказану у -f, --filename. Корисно, якщо ви хочете керувати повʼязаними маніфестами, організованими в одній теці.

--restart string     Типово: "Always"

Політика перезапуску Pod. Підтримувані значення: [Always, OnFailure, Never]

--rm

Якщо значення true, видалити pod після його виходу. Діє лише при приєднанні до контейнера, наприклад, за допомогою '--attach' або '-i/--stdin'.

--save-config

Якщо значення true, конфігурація поточного обʼєкта буде збережена в його анотації. В іншому випадку, анотацію буде збережено без змін. Цей прапорець корисно встановити, якщо ви хочете застосувати kubectl до цього обʼєкта у майбутньому.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

-i, --stdin

Залишати stdin відкритим на контейнері в pod, навіть якщо до нього нічого не приєднано.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--timeout duration

Час очікування перед прийнятям рішення про відмову видалення, нуль означає визначення таймауту залежно від розміру обʼєкта

-t, --tty

Призначити TTY для контейнера в pod.

--wait

Якщо true, очікувати, поки ресурси зникнуть, перш ніж повернутися. Очікує фіналізаторів.

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes

6.11.3.38 - kubectl scale

Огляд

Встановлення нового розміру для deployment, replica set, replication controller або stateful set.

Scale також дозволяє користувачам вказати одну або декілька передумов для дії масштабування.

Якщо вказано параметр --current-replicas або --resource-version, його буде перевірено перед спробою масштабування, і буде гарантовано, що передумови буде виконано, коли масштабування буде надіслано на сервер.

kubectl scale [--resource-version=version] [--current-replicas=count] --replicas=COUNT (-f FILENAME | TYPE NAME)

Приклади

# Масштабувати replica set з назвою 'foo' до 3
kubectl scale --replicas=3 rs/foo

# Масштабувати ресурс, визначений типом та назвою, вказаними у "foo.yaml", до 3
kubectl scale --replicas=3 -f foo.yaml

# Якщо поточний розмір deployment з назвою mysql дорівнює 2, масштабувати mysql до 3
kubectl scale --current-replicas=2 --replicas=3 deployment/mysql

# Масштабування декількох контролерів реплікації
kubectl scale --replicas=5 rc/example1 rc/example2 rc/example3

# Масштабувати stateful set з назвою 'web' до 3
kubectl scale --replicas=3 statefulset/web

Параметри

--all

Вибрати всі ресурси у просторі імен вказаних типів ресурсів.

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--current-replicas int     Типово: -1

Передумова для поточного розміру. Вимагає, щоб поточний розмір ресурсу відповідав цьому значенню для масштабування. -1 ( стандартно) для відсутності умови.

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

-f, --filename strings

Імʼя файлу, теки або URL до файлів, що ідентифікують ресурс, якому потрібно задати новий розмір.

-h, --help

Довідка scale

-k, --kustomize string

Обробити теку kustomization. Цей прапорець не можна використовувати разом з -f або -R.

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

-R, --recursive

Рекурсивно обробити теку, вказану у -f, --filename. Корисно, якщо ви хочете керувати повʼязаними маніфестами, організованими в одній теці.

--replicas int

Нова бажана кількість реплік. Обовʼязково.

--resource-version string

Передумова для версії ресурсу. Вимагає, щоб поточна версія ресурсу відповідала цьому значенню для масштабування./p>

-l, --selector string

Селектор (запит на мітки) для фільтрації, що підтримує '=', '==' і '!=' (наприклад, -l key1=value1,key2=value2). Обʼєкти, щоб мати збіг, повинні задовольняти усім зазначеним обмеженням міток.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--timeout duration

Час очікування перед прийнятям рішення про відмову видалення, нуль означає визначення тайм-ауту за розміром обʼєкту. Будь-які інші значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h).

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes

6.11.3.39 - kubectl set

Огляд

Налаштування ресурсів застосунку.

Ці команди допоможуть вам внести зміни до наявних ресурсів застосунку.

kubectl set SUBCOMMAND

Параметри

-h, --help

Довідка set

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes
  • kubectl set env — Оновити змінні оточення у шаблоні Pod
  • kubectl set image — Оновити образ шаблону Pod
  • kubectl set resources — Оновити запити/ліміти ресурсів у обʼєктів в шаблонах Pod
  • kubectl set selector — Встановити селектор на ресурсі
  • kubectl set serviceaccount — оновити службовий обліковий запис ресурсу
  • kubectl set subject — Оновити обліковий запис користувача, групи або сервісу у привʼязці ролі або привʼязці ролі кластера

6.11.3.39.1 - kubectl set env

Огляд

Оновити змінні середовища у шаблоні Pod.

Вивести перелік визначення змінних середовища в одному або декількох Pod, шаблонах Pod. Додати, оновити або видалити визначення змінних середовища контейнера в одному або декількох шаблонах Pod (в рамках контролерів реплікації або конфігурацій deployment). Переглянути або змінити визначення змінних середовища у всіх контейнерах у вказаних Pod або шаблонах Pod, або тільки тих, що відповідають шаблону.

Якщо передано "--env -", змінні середовища можуть бути прочитані зі STDIN за допомогою стандартного синтаксису env.

Перелік можливих ресурсів містить (незалежно від регістру):

pod (po), replicationcontroller (rc), deployment (deploy), daemonset (ds), statefulset (sts), cronjob (cj), replicaset (rs)

kubectl set env RESOURCE/NAME KEY_1=VAL_1 ... KEY_N=VAL_N

Приклади

# Оновити deployment 'registry' новою змінною середовища
kubectl set env deployment/registry STORAGE_DIR=/local

# Вивести перелік змінних середовища, визначених в deployment 'sample-build'
kubectl set env deployment/sample-build --list

# Вивести перелік змінних середовища, визначених у всіх podʼах
kubectl set env pods --all --list

# Вивести змінений deployment у форматі YAML, не змінюючи обʼєкт на сервері
kubectl set env deployment/sample-build STORAGE_DIR=/data -o yaml

# Оновити всі контейнери у всіх контролерах реплікації в проєкті, додавши змінну середовища ENV=prod
kubectl set env rc --all ENV=prod

# Імпортувати змінні середовища з secret
kubectl set env --from=secret/mysecret deployment/myapp

# Імпортувати змінні середовища з config map з префіксом
kubectl set env --from=configmap/myconfigmap --prefix=MYSQL_ deployment/myapp

# Імпортувати конкретні ключі з config map
kubectl set env --keys=my-example-key --from=configmap/myconfigmap deployment/myapp

# Видалити змінну середовища ENV з контейнера 'c1' у всіх deployment
kubectl set env deployments --all --containers="c1" ENV-

# Видалити змінну середовища ENV з файлу визначення deployment на диску та
# оновити конфігурацію deployment на сервері
kubectl set env -f deploy.json ENV-

# Встановити деякі змінні середовища з локальної оболонки у конфігурацію deployment на сервері
env | grep RAILS_ | kubectl set env -e - deployment/registry

Параметри

--all

Якщо true, вибрати всі ресурси в просторі імен вказаних типів ресурсів

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

-c, --containers string     Типово: "*"

Назви контейнерів у вибраних шаблонах pod для зміни, можна використовувати підстановочні знаки

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

-e, --env strings

Вкажіть пару ключ-значення для змінної оточення, яку потрібно встановити у кожному контейнері.

--field-manager string     Типово: "kubectl-set"

Імʼя менеджера, що використовується для відстеження права власності на поле.

-f, --filename strings

Імʼя файлу, теки або URL до файлів, що ідентифікують ресурс, для оновлення env.

--from string

Імʼя ресурсу, з якого потрібно підʼєднати змінні оточення.

-h, --help

Довідка env

--keys strings

Список ключів через кому для імпорту з вказаного ресурсу

-k, --kustomize string

Обробити теку kustomization. Цей прапорець не можна використовувати разом з -f або -R.

--list

Якщо встановлено, виводити оточення та будь-які зміни у стандартному форматі. Цей прапорець буде вилучено, коли ми матимемо kubectl view env.

--local

Якщо значення true, set env НЕ звʼязуватиметься з api-serverʼом, а виконуватиметься локально.

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--overwrite     Типово: true

Якщо true, дозволити перезапис оточення, інакше відхилити оновлення, які перезаписують існуюче оточення.

--prefix string

Префікс для додавання до імен змінних

-R, --recursive

Рекурсивно обробити теку, вказану у -f, --filename. Корисно, якщо ви хочете керувати повʼязаними маніфестами, організованими в одній теці.

--resolve

Якщо true, показувати посилання на secret або configmap під час виведення списку змінних

-l, --selector string

Селектор (запит на мітки) для фільтрації, що підтримує '=', '==' і '!=' (наприклад, -l key1=value1,key2=value2). Обʼєкти, щоб мати збіг, повинні задовольняти усім зазначеним обмеженням міток.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl set — встановлення певних властивостей для обʼєктів

6.11.3.39.2 - kubectl set image

Огляд

Оновити наявні образи контейнерів ресурсів.

Можливі ресурси включають (не чутливі до регістру):

pod (po), replicationcontroller (rc), deployment (deploy), daemonset (ds), statefulset (sts), cronjob (cj), replicaset (rs)

kubectl set image (-f FILENAME | TYPE NAME) CONTAINER_NAME_1=CONTAINER_IMAGE_1 ... CONTAINER_NAME_N=CONTAINER_IMAGE_N

Приклади

# Встановити образ контейнера nginx в deployment як 'nginx:1.9.1', а образ контейнера busybox на 'busybox'
kubectl set image deployment/nginx busybox=busybox nginx=nginx:1.9.1

# Оновити образ контейнера nginx у всіх deployment та контролерах реплікації на 'nginx:1.9.1'
kubectl set image deployments,rc nginx=nginx:1.9.1 --all

# Оновити образи всіх контейнерів у daemonset abc на 'nginx:1.9.1'
kubectl set image daemonset abc *=nginx:1.9.1

# Вивести результат (у форматі yaml) оновлення образу контейнера nginx з локального файлу, без звернення до сервера
kubectl set image -f path/to/file.yaml nginx=nginx:1.9.1 --local -o yaml

Параметри

--all

Якщо true, вибрати всі ресурси в просторі імен вказаних типів ресурсів

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--field-manager string     Типово: "kubectl-set"

Імʼя менеджера, що використовується для відстеження права власності на поле.

-f, --filename strings

Імʼя файлу, теки або URL до файлів, що ідентифікують ресурс, для отримання ресурсів з сервера.

-h, --help

Довідка image

-k, --kustomize string

Обробити теку kustomization. Цей прапорець не можна використовувати разом з -f або -R.

--local

Якщо значення true, set image НЕ звʼязуватиметься з api-serverʼом, а виконуватиметься локально.

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

-R, --recursive

Рекурсивно обробити теку, вказану у -f, --filename. Корисно, якщо ви хочете керувати повʼязаними маніфестами, організованими в одній теці.

-l, --selector string

Селектор (запит на мітки) для фільтрації, що підтримує '=', '==' і '!=' (наприклад, -l key1=value1,key2=value2). Обʼєкти, щоб мати збіг, повинні задовольняти усім зазначеним обмеженням міток.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl set — встановлення певних властивостей для обʼєктів

6.11.3.39.3 - kubectl set resources

Огляд

Вказує вимоги до обчислювальних ресурсів (ЦП, памʼять) для будь-якого ресурсу, який визначає шаблон pod. Якщо pod успішно заплановано, йому гарантовано надається запитана кількість ресурсів, які він може використовувати до зазначених меж.

Для кожного обчислювального ресурсу, якщо межа вказана, а запит пропущено, стандартний запит буде дорівнювати межі.

Можливі ресурси включають (незалежно від регістру): Використовуйте "kubectl api-resources" для повного списку підтримуваних ресурсів.

kubectl set resources (-f FILENAME | TYPE NAME)  ([--limits=LIMITS & --requests=REQUESTS]

Приклади

# Встановити межі використання ЦП для контейнера nginx у deployment на "200m" та памʼяті на "512Mi"
kubectl set resources deployment nginx -c=nginx --limits=cpu=200m,memory=512Mi

# Встановити запити та межі ресурсів для всіх контейнерів у deployment nginx
kubectl set resources deployment nginx --limits=cpu=200m,memory=512Mi --requests=cpu=100m,memory=256Mi

# Видалити запити ресурсів для контейнерів у deployment nginx
kubectl set resources deployment nginx --limits=cpu=0,memory=0 --requests=cpu=0,memory=0

# Вивести результат (у форматі yaml) оновлення меж використання ресурсів для контейнера nginx з локального файлу, без звернення до сервера
kubectl set resources -f path/to/file.yaml --limits=cpu=200m,memory=512Mi --local -o yaml

Параметри

--all

Якщо true, вибрати всі ресурси в просторі імен вказаних типів ресурсів

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

-c, --containers string     Типово: "*"

Назви контейнерів у вибраних шаблонах pod для зміни, стандартно вибрані всі контейнери, можна використовувати підстановочні знаки

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--field-manager string     Типово: "kubectl-set"

Імʼя менеджера, що використовується для відстеження права власності на поле.

-f, --filename strings

Імʼя файлу, теки або URL до файлів, що ідентифікують ресурс, для отримання ресурсів з сервера.

-h, --help

Довідка resources

-k, --kustomize string

Обробити теку kustomization. Цей прапорець не можна використовувати разом з -f або -R.

--limits string

Вимоги до ресурсів для цього контейнера. Наприклад, 'cpu=100m,memory=256Mi'. Зверніть увагу, що серверні компоненти можуть призначати запити залежно від конфігурації сервера, наприклад, граничних діапазонів.

--local

Якщо значення true, set resources НЕ звʼязуватиметься з api-serverʼом, а виконуватиметься локально.

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

-R, --recursive

Рекурсивно обробити теку, вказану у -f, --filename. Корисно, якщо ви хочете керувати повʼязаними маніфестами, організованими в одній теці.

--requests string

Вимоги до ресурсів для цього контейнера. Наприклад, 'cpu=100m,memory=256Mi'. Зверніть увагу, що серверні компоненти можуть призначати запити залежно від конфігурації сервера, наприклад, граничних діапазонів.

-l, --selector string

Селектор (запит на мітки) для фільтрації, що підтримує '=', '==' і '!=' (наприклад, -l key1=value1,key2=value2). Обʼєкти, щоб мати збіг, повинні задовольняти усім зазначеним обмеженням міток.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl set — встановлення певних властивостей для обʼєктів

6.11.3.39.4 - kubectl set selector

Огляд

Встановити селектор на ресурс. Зауважте, що новий селектор замінить старий, якщо ресурс вже мав селектор перед викликом команди 'set selector'.

Селектор повинен починатися з літери або цифри та може містити літери, цифри, дефіси, крапки та підкреслення, до 63 символів. Якщо вказано --resource-version, оновлення використовуватимуть цю версію ресурсу, інакше використовуватиметься наявна версія ресурсу. Примітка: зараз селектори можна встановлювати лише на обʼєкти типу Service.

kubectl set selector (-f FILENAME | TYPE NAME) EXPRESSIONS [--resource-version=version]

Приклади

# Встановіть мітки і селектор перед створенням пари deployment/service
kubectl create service clusterip my-svc --clusterip="None" -o yaml --dry-run=client | kubectl set selector --local -f - 'environment=qa' -o yaml | kubectl create -f -

kubectl create deployment my-dep -o yaml --dry-run=client | kubectl label --local -f - environment=qa -o yaml | kubectl create -f -

Параметри

--all

Якщо true, вибрати всі ресурси в просторі імен вказаних типів ресурсів

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--field-manager string     Типово: "kubectl-set"

Імʼя менеджера, що використовується для відстеження права власності на поле.

-f, --filename strings

Імʼя файлу, теки або URL до файлів, що ідентифікують ресурс.

-h, --help

Довідка selector

--local

Якщо значення true, анотація НЕ звʼязуватиметься з api-сервером, а виконуватиметься локально.

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

-R, --recursive     Типово: true

Рекурсивно обробити теку, вказану у -f, --filename. Корисно, якщо ви хочете керувати повʼязаними маніфестами, організованими в одній теці.

--resource-version string

Якщо значення не порожнє, оновлення селекторів буде успішним, тільки якщо це поточна версія ресурсу для обʼєкта. Дійсно тільки при вказівці одного ресурсу.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl set — встановлення певних властивостей для обʼєктів

6.11.3.39.5 - kubectl set serviceaccount

Огляд

Оновлення службового облікового запису ресурсів шаблону pod.

Можливі ресурси (нечутливі до регістру) можуть бути такими:

replicationcontroller (rc), deployment (deploy), daemonset (ds), job, replicaset (rs), statefulset

kubectl set serviceaccount (-f FILENAME | TYPE NAME) SERVICE_ACCOUNT

Приклади

# Встановити службовий обліковий запис nginx-deployment у serviceaccount1
kubectl set serviceaccount deployment nginx-deployment serviceaccount1

# Вивести результат (у форматі YAML) оновленого deployment nginx з службовим обліковим записом з локального файлу, не звертаючись до сервера API
kubectl set sa -f nginx-deployment.yaml serviceaccount1 --local --dry-run=client -o yaml

Параметри

--all

Якщо true, вибрати всі ресурси в просторі імен вказаних типів ресурсів

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--field-manager string     Типово: "kubectl-set"

Імʼя менеджера, що використовується для відстеження права власності на поле.

-f, --filename strings

Імʼя файлу, теки або URL до файлів, що ідентифікують ресурс для отримання з сервера.

-h, --help

Довідка serviceaccount

-k, --kustomize string

Обробити теку kustomization. Цей прапорець не можна використовувати разом з -f або -R.

--local

Якщо значення true, set serviceaccount НЕ звʼязуватиметься з api-сервером, а виконуватиметься локально.

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

-R, --recursive

Рекурсивно обробити теку, вказану у -f, --filename. Корисно, якщо ви хочете керувати повʼязаними маніфестами, організованими в одній теці.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl set — встановлення певних властивостей для обʼєктів

6.11.3.39.6 - kubectl set subject

Огляд

Оновлює user, group або service account в обʼєкті RoleBinding або ClusterRoleBinding.

kubectl set subject (-f FILENAME | TYPE NAME) [--user=username] [--group=groupname] [--serviceaccount=namespace:serviceaccountname] [--dry-run=server|client|none]

Приклади

# Оновлення привʼязки кластерних ролей для serviceaccount1
kubectl set subject clusterrolebinding admin --serviceaccount=namespace:serviceaccount1

# Оновлення привʼязки ролей для user1, user2 і group1
kubectl set subject rolebinding admin --user=user1 --user=user2 --group=group1

# Вивести результат (у форматі YAML) оновлення субʼєктів привʼязки ролей локально, без звернення до сервера
kubectl create rolebinding admin --role=admin --user=admin -o yaml --dry-run=client | kubectl set subject --local -f - --user=foo -o yaml

Параметри

--all

Якщо true, вибрати всі ресурси в просторі імен вказаних типів ресурсів

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--field-manager string     Типово: "kubectl-set"

Імʼя менеджера, що використовується для відстеження права власності на поле.

-f, --filename strings

Імʼя файлу, теки або URL до файлів, що ідентифікують ресурси для оновлення.

--group strings

Групи для привʼязки до ролі.

-h, --help

Довідка subject

-k, --kustomize string

Обробити теку kustomization. Цей прапорець не можна використовувати разом з -f або -R.

--local

Якщо значення true, set subject НЕ звʼязуватиметься з api-сервером, а виконуватиметься локально.

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

-R, --recursive

Рекурсивно обробити теку, вказану у -f, --filename. Корисно, якщо ви хочете керувати повʼязаними маніфестами, організованими в одній теці.

-l, --selector string

Селектор (запит на мітки) для фільтрації, що підтримує '=', '==' і '!=' (наприклад, -l key1=value1,key2=value2). Обʼєкти, щоб мати збіг, повинні задовольняти усім зазначеним обмеженням міток.

--serviceaccount strings

Службові облікові записи для привʼязки до ролі.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--user strings

Імена користувачів для привʼязки до ролі.

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl set — встановлення певних властивостей для обʼєктів

6.11.3.40 - kubectl taint

Огляд

Оновлення taint на одному або декількох вузлах.

  • Taint складається з ключа, значення та ефекту. Як аргумент тут він має вигляд ключ=значення:ефект.
  • Ключ повинен починатися з літери або цифри і може містити літери, цифри, дефіси, крапки і підкреслення, до 253 символів.
  • За бажанням, ключ може починатися з префікса субдомену DNS і одного символу "/", наприклад, example.com/my-app.
  • Значення не є обовʼязковим. Якщо вказано, воно повинно починатися з літери або цифри і може містити літери, цифри, дефіси, крапки та символи підкреслення (до 63 символів).
  • Ефект має бути NoSchedule, PreferNoSchedule або NoExecute.
  • Наразі taint може бути застосовано лише до вузла.
kubectl taint NODE NAME KEY_1=VAL_1:TAINT_EFFECT_1 ... KEY_N=VAL_N:TAINT_EFFECT_N

Приклади

# Оновити вузол 'foo', додавши taint з ключем 'dedicated', значенням 'special-user' та ефектом 'NoSchedule'
# Якщо taint з цим ключем та ефектом вже існує, його значення буде замінено на вказане
kubectl taint nodes foo dedicated=special-user:NoSchedule

# Видалити з вузла 'foo' taint з ключем 'dedicated' та ефектом 'NoSchedule', якщо він існує
kubectl taint nodes foo dedicated:NoSchedule-

# Видалити з вузла 'foo' всі taint з ключем 'dedicated'
kubectl taint nodes foo dedicated-

# Додати taint з ключем 'dedicated' на вузли, що мають мітку myLabel=X
kubectl taint node -l myLabel=X dedicated=foo:PreferNoSchedule

# Додати до вузла 'foo' taint з ключем 'bar' без значення
kubectl taint nodes foo bar:NoSchedule

Параметри

--all

Вибрати всі вузли в кластері

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

--field-manager string     Типово: "kubectl-taint"

Імʼя менеджера, що використовується для відстеження права власності на поле.

-h, --help

Довідка taint

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

--overwrite

Якщо true, дозволити перезапис taint, інакше відхиляти оновлення taint, які перезаписують наявні taint.

-l, --selector string

Селектор (запит на мітки) для фільтрації, що підтримує '=', '==' і '!=' (наприклад, -l key1=value1,key2=value2). Обʼєкти, щоб мати збіг, повинні задовольняти усім зазначеним обмеженням міток.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--validate string[="strict"]     Типово: "strict"

Повинно бути одним із: strict (або true), warn, ignore (або false).

"true" або "strict" буде використовувати схему для перевірки вводу і відхилятиме запит, якщо він невірний. Буде виконана перевірка на стороні сервера, якщо ServerSideFieldValidation увімкнено на api-server, але якщо ні, то повернеться до менш надійної перевірки на стороні клієнта.

"warn" попередить про невідомі або повторювані поля, не блокуючи запит, якщо на боці сервера API увімкнено перевірку полів, і буде поводитися як " ignore" у протилежному випадку.

"false" або "ignore" не виконуватимуть жодної перевірки схеми, мовчки відкидаючі будь-які невідомі або дубльовані поля.

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes

6.11.3.41 - kubectl top

Огляд

Показує використання ресурсів (CPU, памʼять).

Команда top дозволяє вам спостерігати за використанням ресурсів вузлами та Podʼами.

Ця команда вимагає наявності працюючого та налаштованого Metrics Server в кластері.

kubectl top [flags]

Параметри

-h, --help

Довідка top

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes
  • kubectl top node — Показати використання ресурсів (процесор/памʼять) вузлами
  • kubectl top pod — Показувати використання ресурсів (процесора/памʼять) Podʼами

6.11.3.41.1 - kubectl top node

Огляд

Показати використання ресурсів (процесор/памʼять) вузлами.

Команда top-node дозволяє переглядати використання ресурсів вузлами кластера.

kubectl top node [NAME | -l label]

Приклади

# Показати метріки для всіх вузлівShow metrics for all nodes
kubectl top node

# Показати метріки для вузла NODE_NAME
kubectl top node NODE_NAME

Параметри

-h, --help

Довідка node

--no-headers

Якщо присутній, то виводити без заголовків.

-l, --selector string

Селектор (запит на мітки) для фільтрації, що підтримує '=', '==' і '!=' (наприклад, -l key1=value1,key2=value2). Обʼєкти, щоб мати збіг, повинні задовольняти усім зазначеним обмеженням міток.

--show-capacity

Вивести ресурси вузлів на основі Capacity замість Allocatable (стандартно) для вузлів.

--sort-by string

Якщо поле не порожнє, відсортувати список ресурсів за вказаним полем. Поле може мати значення 'cpu' або 'memory'.

--use-protocol-buffers     Типово: true

Дозволяє використовувати протокол-буфери для доступу до API Metrics.

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl top — Показ використання ресурсів (CPU/памʼять)

6.11.3.41.2 - kubectl top pod

Огляд

Показувати використання ресурсів (процесора/памʼять) pod'ами

Команда 'top pod' дозволяє вам переглядати використання ресурсів (процесора/памʼяті) podʼами.

Через затримку конвеєра метрик, вони можуть бути недоступні протягом декількох хвилин з моменту створення podʼів.

kubectl top pod [NAME | -l label]

Приклади

# Показати метрики для всіх podʼів у стандартному просторі імен
kubectl top pod

# Показати метрики для всіх podʼів у вказаному просторі імен
kubectl top pod --namespace=NAMESPACE

# Показати метрики для вказаного podʼа та його контейнерів
kubectl top pod POD_NAME --containers

# Показати метрики для podʼів, визначених міткою name=myLabel
kubectl top pod -l name=myLabel

Параметри

-A, --all-namespaces

Якщо вказано, вивести перелік запитуваних обʼєктів у всіх просторах назв. Простір назв у поточному контексті ігнорується, навіть якщо вказано --namespace.

--containers

Якщо є, показати використання контейнерів в межах pod.

--field-selector string

Селектор (запит поля) для фільтрації підтримує '=', '==' і '!=' (наприклад, --field-selector key1=value1,key2=value2). Сервер підтримує лише обмежену кількість запитів до полів кожного типу.

-h, --help

Довідка pod

--no-headers

Якщо присутній, то виводити без заголовків.

-l, --selector string

Селектор (запит на мітки) для фільтрації, що підтримує '=', '==' і '!=' (наприклад, -l key1=value1,key2=value2). Обʼєкти, щоб мати збіг, повинні задовольняти усім зазначеним обмеженням міток.

--sort-by string

Якщо поле не порожнє, відсортувати список ресурсів за вказаним полем. Поле може мати значення 'cpu' або 'memory'.

--sum

Вивести сумарне використання ресурсів

--use-protocol-buffers     Типово: true

Дозволяє використовувати протокол-буфери для доступу до API Metrics.

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl top — Показ використання ресурсів (CPU/памʼять)

6.11.3.42 - kubectl uncordon

Огляд

Позначає вузол як готовий для планування.

kubectl uncordon NODE

Приклади

# Позначити вузол "foo" як готовий для планування
kubectl uncordon foo

Параметри

--dry-run string[="unchanged"]     Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

-h, --help

Довідка uncordon

-l, --selector string

Селектор (запит на мітки) для фільтрації, що підтримує '=', '==' і '!=' (наприклад, -l key1=value1,key2=value2). Обʼєкти, щоб мати збіг, повинні задовольняти усім зазначеним обмеженням міток.

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes

6.11.3.43 - kubectl version

Огляд

Вивести інформацію про версії клієнта та сервера для поточного контексту.

kubectl version [flags]

Приклади

# Вивести версії клієнта та сервера для поточного контексту
kubectl version

Параметри

--client

Якщо true, показує лише клієнтську версію (server не вимагається).

-h, --help

Довідка version

-o, --output string

Формат виводу. Один з: (json, yaml).

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes

6.11.3.44 - kubectl wait

Огляд

Експериментально: Очікувати на певний стан одного чи кількох ресурсів.

Команда бере кілька ресурсів і чекає, доки у полі стану кожного з них не зʼявиться вказана умова.

Крім того, команда може чекати на видалення заданого набору ресурсів, вказавши ключове слово "delete" як значення прапорця --for.

Успішне повідомлення буде виведено у stdout із зазначенням того, що вказану умову було виконано. Ви можете скористатися опцією -o, щоб змінити місце виведення.

kubectl wait ([-f FILENAME] | resource.group/resource.name | resource.group [(-l label | --all)]) [--for=delete|--for condition=available|--for=jsonpath='{}'[=value]]

Приклади

# Очікувати, поки Pod "busybox1" не міститиме умови статусу типу "Ready"
kubectl wait --for=condition=Ready pod/busybox1

# Типове значення умови статусу є true; ви можете очікувати на інші значення після знаку рівності (порівнюється після простого складання Unicode, яке є загальнішою формою нечутливості до регістру)
kubectl wait --for=condition=Ready=false pod/busybox1

# Очікувати, поки Pod "busybox1" не міститиме фази статусу "Running"
kubectl wait --for=jsonpath='{.status.phase}'=Running pod/busybox1

# Очікувати, поки Pod "busybox1" не буде в стані Ready
kubectl wait --for='jsonpath={.status.conditions[?(@.type=="Ready")].status}=True' pod/busybox1

# Очікувати, поки сервіс "loadbalancer" не матиме ingress
kubectl wait --for=jsonpath='{.status.loadBalancer.ingress}' service/loadbalancer

# Очікувати, поки Pod "busybox1" не буде видалено, з таймаутом 60с, після виконання команди "delete"
kubectl delete pod/busybox1
kubectl wait --for=delete pod/busybox1 --timeout=60s

Параметри

--all

Якщо true, вибрати всі ресурси в просторі імен вказаних типів ресурсів

-A, --all-namespaces

Якщо вказано, вивести перелік запитуваних обʼєктів у всіх просторах імен. Простір імен у поточному контексті ігнорується, навіть якщо вказано --namespace.

--allow-missing-template-keys     Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

--field-selector string

Селектор (запит поля) для фільтрації підтримує '=', '==' і '!=' (наприклад, --field-selector key1=value1,key2=value2). Сервер підтримує лише обмежену кількість запитів до полів кожного типу.

-f, --filename strings

Імʼя файлу, теки або URL до файлів, що ідентифікують ресурси.

--for string

Умова для очікування: [delete|condition=ім' condition-name[=condition-value]|jsonpath='{JSONPath expression}'=[JSONPath value]]. Стандартне значення condition-value дорівнює true. Значення умови порівнюються після простого згортання регістру Unicode, що є більш загальною формою нечутливості до регістру.

-h, --help

Довідка wait

--local

Якщо значення true, НЕ звʼязуватиметься з api-сервером, а виконуватиметься локально.

-o, --output string

Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).

-R, --recursive

Рекурсивно обробити теку, вказану у -f, --filename. Корисно, якщо ви хочете керувати повʼязаними маніфестами, організованими в одній теці.

-l, --selector string

Селектор (запит на мітки) для фільтрації, що підтримує '=', '==' і '!=' (наприклад, -l key1=value1,key2=value2). Обʼєкти, щоб мати збіг, повинні задовольняти усім зазначеним обмеженням міток.

--show-managed-fields

Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML.

--template string

Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview].

--timeout duration     Типово: 30s

Час очікування перед прийнятям рішення про відмову видалення, нуль означає визначення тайм-ауту за розміром обʼєкту

Параметри батьківських команд

--as string

Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен.

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--disable-compression

Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--storage-driver-buffer-duration duration     Типово: 1m0s

Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція

--storage-driver-db string     Типово: "cadvisor"

Назва бази даних

--storage-driver-host string     Типово: "localhost:8086"

Хост:порт бази даних

--storage-driver-password string     Типово: "root"

Пароль бази даних

--storage-driver-secure

використовувати захищене зʼєднання з базою даних

--storage-driver-table string     Типово: "stats"

Назва таблиці

--storage-driver-user string     Типово: "root"

Імʼя користувача бази даних

--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

--version version[=true]

--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію

--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Дивіться також

  • kubectl — kubectl керує менеджером кластерів Kubernetes

6.11.4 - Команди kubectl

Довідник команд kubectl

6.11.5 - kubectl

Огляд

kubectl керує менеджером кластерів Kubernetes.

Додаткову інформацію можна знайти в розділі Інструмент командного рядка (kubectl).

kubectl [flags]

Параметри

--add-dir-header
Якщо true, додає теку файлу до заголовка повідомлень логу
--alsologtostderr
писати лог до standard error, а також в файл
--as string

Імʼя користувача, яке використовується для виконання операції.

--as-group stringArray
Назва групи, яка використовується для виконання операції, цей прапорець можна повторити, щоб вказати кілька груп.
--azure-container-registry-config string
Шлях до файлу, що містить інформацію про конфігурацію реєстру контейнера Azure.
--cache-dir string     Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

--client-certificate string

Шлях до файлу клієнтського сертифіката для TLS

--client-key string

Шлях до файлу ключа клієнта для TLS

--cloud-provider-gce-l7lb-src-cidrs cidrs     Типово: 130.211.0.0/22,35.191.0.0/16

CIDR, відкриті в фаєврволі GCE для трафіку L7 LB та перевірок стану

--cloud-provider-gce-lb-src-cidrs cidrs     Типово: 130.211.0.0/22,209.85.152.0/22,209.85.204.0/22,35.191.0.0/16

CIDR, відкриті в фаєврволі GCE для трафіку L4 LB та перевірок стану

--cluster string

Назва файлу kubeconfig кластера, який слід використовувати

--context string

Назва контексту kubeconfig, який слід використовувати

--default-not-ready-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності.

-h, --help

Довідка kubectl

--insecure-skip-tls-verify

Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними

--kubeconfig string

Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів.

--log-backtrace-at traceLocation     Default: :0
коли логування попадаж в рядок file:N, видавати trace стека
--log-dir string
Якщо не порожньо, записати лог-файли в цю теку
--log-file string
Якщо не порожньо, використовувати цей файл
--log-file-max-size uint     Типово: 1800
Визначає максимальний розмір, до якого може вирости файл логу. Одиниця виміру — мегабайти. Якщо значення дорівнює 0, максимальний розмір файлу необмежений.
--log-flush-frequency duration     Типово: 5s
Максимальна кількість секунд між очищеннями журналу
--logtostderr     Типово: true
писати лог в standard error, а не у файл
--match-server-version

Вимагає, щоб версія сервера відповідала версії клієнта

-n, --namespace string

Якщо присутній, простір імен для цього CLI-запиту

--one-output
Якщо true, записувати логи лише до їхнього власного рівня важливості (замість того, щоб записувати до кожного нижчого рівня важливості)
--password string

Пароль для базової автентифікації на API-сервері

--profile string     Типово: "none"

Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output string     Типово: "profile.pprof"

Імʼя файлу, в який записується профіль

--request-timeout string     Типово: "0"

Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів.

-s, --server string

Адреса та порт сервера API Kubernetes

--skip-headers
Якщо true, уникати префіксів заголовків у повідомленнях логу
--skip-log-headers
Якщо true, уникати заголовків при відкритті файлів логів
--stderrthreshold severity     Типово: 2
логи, що дорівнюють або перевищують цей поріг, потрапляють до stderr
--tls-server-name string

Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером

--token string

Токен на предʼявника для автентифікації на API-сервері

--user string

Імʼя користувача kubeconfig, яке слід використовувати

--username string

Імʼя користувача для базової автентифікації на API-сервері

-v, --v Level
число рівня повноти записів логу
--version version[=true]

Вивести інформацію про версію та вийти

--vmodule moduleSpec
список параметрів pattern=N, розділених комами, для файл-фільтрованого логування.
--warnings-as-errors

Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу

Змінні оточення

KUBECONFIG
Шлях до файлу конфігурації kubectl ("kubeconfig"). Типово: "$HOME/.kube/config"
KUBECTL_COMMAND_HEADERS
Якщо встановлено false, вимикає додаткові HTTP заголовки, що деталізують виконану команду kubectl (версія Kubernetes v1.22 або пізніше)
KUBECTL_DEBUG_CUSTOM_PROFILE
Якщо встановлено true, у kubectl debug буде активовано спеціальний прапорець. Цей прапорець використовується для налаштування заздалегідь визначених профілів.
KUBECTL_EXPLAIN_OPENAPIV3
Вмикає чи вимикає використання нового джерела даних OpenAPIv3 для викликів `kubectl explain`. OpenAPIV3 типово увімкнено з версії Kubernetes 1.24.
KUBECTL_ENABLE_CMD_SHADOW
Якщо встановлено true, зовнішні втулки можна використовувати як субкоманди для вбудованих команд, якщо субкоманда не існує. На альфа-стадії ця функція може бути використана лише для команди create (наприклад, kubectl create networkpolicy).
KUBECTL_PORT_FORWARD_WEBSOCKETS
Якщо встановлено true, команда kubectl port-forward спробує передавати дані, використовуючи протокол веб-сокетів. Якщо перехід до веб-сокетів не вдасться, команди повернуться до використання поточного протоколу SPDY.
KUBECTL_REMOTE_COMMAND_WEBSOCKETS
Якщо встановлено true, команди kubectl exec, cp та attach спробують передавати дані, використовуючи протокол веб-сокетів. Якщо перехід до веб-сокетів не вдасться, команди повернуться до використання поточного протоколу SPDY.

Дивіться також

  • kubectl annotate — Оновити анотації на ресурсі
  • kubectl api-resources — Вивести підтримувані API ресурси на сервері
  • kubectl api-versions — Вивести підтримувані API версії на сервері у форматі "група/версія"
  • kubectl apply — Застосувати конфігурацію до ресурсу за імʼям файлу або через stdin
  • kubectl attach — Приєднатися до працюючого контейнера
  • kubectl auth — Перевірити авторизацію
  • kubectl autoscale — Автоматичне масштабування Deployment, ReplicaSet або ReplicationController
  • kubectl certificate — Змінити ресурси сертифікатів
  • kubectl cluster-info — Показати інформацію про кластер
  • kubectl completion — Вивести код автодоповнення для зазначеної оболонки (bash або zsh)
  • kubectl config — Змінити kubeconfig файли
  • kubectl cordon — Позначити вузол як недоступний для планування
  • kubectl cp — Копіювати файли та теки до і з контейнерів
  • kubectl create — Створити ресурс з файлу або stdin
  • kubectl debug — Створити сесії налагодження для виправлення неполадок з робочими навантаженнями та вузлами
  • kubectl delete — Видалити ресурси за допомогою імен файлів, stdin, ресурсів і назв або за допомогою ресурсів і селектора міток
  • kubectl describe — Показати деталі конкретного ресурсу або групи ресурсів
  • kubectl diff — Порівняти живу версію з потенційною версією, яку може бути застосовано
  • kubectl drain — Спорожнити вузол перед обслуговуванням
  • kubectl edit — Редагувати ресурс на сервері
  • kubectl events — Список подій
  • kubectl exec — Виконати команду в контейнері
  • kubectl explain — Документація по ресурсах
  • kubectl expose — Експонувати новий сервіс Kubernetes з replication controller, service, deployment чи pod
  • kubectl get — Показати один або кілька ресурсів
  • kubectl kustomize — Створити kustomization з теки або віддаленого URL
  • kubectl label — Оновити мітки на ресурсі
  • kubectl logs — Вивести логи для контейнера в pod
  • kubectl options — Вивести список прапорців, успадкованих усіма командами
  • kubectl patch — Оновити поле(я) ресурсу
  • kubectl plugin — Надає утиліти для взаємодії з dnekrfvb
  • kubectl port-forward — Gthtyfghfdkznb один або кілька локальних портів до pod
  • kubectl proxy — Запустити проксі до Kubernetes API сервера
  • kubectl replace — Замінити ресурс за імʼям файлу або stdin
  • kubectl rollout — Керувати розгортанням ресурсу
  • kubectl run — Запустити вказаний образ на кластері
  • kubectl scale — Встановити новий розмір для Deployment, ReplicaSet або Replication Controller
  • kubectl set — Встановити конкретні функції на обʼєктах
  • kubectl taint — Оновити taint на одному або кількох вузлах
  • kubectl top — Показати використання ресурсів (CPU/Памʼять/Зберігання)
  • kubectl uncordon — Позначити вузол як доступний для планування
  • kubectl version — Вивести інформацію про клієнтську та серверну версії
  • kubectl wait — Експериментально: Чекати на конкретну умову для одного або кількох ресурсів

6.11.6 - Підтримка JSONPath

Kubectl підтримує шаблони JSONPath.

Шаблон JSONPath складається з виразів JSONPath, які заключені в фігурні дужки {}. Kubectl використовує вирази JSONPath для фільтрації конкретних полів у JSON-обʼєкті та форматування виводу. Окрім оригінального синтаксису шаблону JSONPath, дійсні наступні функції та синтаксис:

  1. Використовуйте подвійні лапки для цитування тексту всередині виразів JSONPath.
  2. Використовуйте оператори range, end для ітерації списків.
  3. Використовуйте відʼємні індекси зрізу для кроку назад через список. Відʼємні індекси не "обгортають" список і є дійсними, поки -index + listLength >= 0.
{
  "kind": "List",
  "items":[
    {
      "kind":"None",
      "metadata":{
        "name":"127.0.0.1",
        "labels":{
          "kubernetes.io/hostname":"127.0.0.1"
        }
      },
      "status":{
        "capacity":{"cpu":"4"},
        "addresses":[{"type": "LegacyHostIP", "address":"127.0.0.1"}]
      }
    },
    {
      "kind":"None",
      "metadata":{"name":"127.0.0.2"},
      "status":{
        "capacity":{"cpu":"8"},
        "addresses":[
          {"type": "LegacyHostIP", "address":"127.0.0.2"},
          {"type": "another", "address":"127.0.0.3"}
        ]
      }
    }
  ],
  "users":[
    {
      "name": "myself",
      "user": {}
    },
    {
      "name": "e2e",
      "user": {"username": "admin", "password": "secret"}
    }
  ]
}
ФункціяОписПрикладРезультат
textзвичайний текстkind is {.kind}kind is List
@поточний обʼєкт{@}той самий, що й вхід
. або []оператор доступу до дочірніх елементів{.kind}, {['kind']} або {['name\.type']}List
..рекурсивний спуск{..name}127.0.0.1 127.0.0.2 myself e2e
*універсальний символ. Отримати всі обʼєкти{.items[*].metadata.name}[127.0.0.1 127.0.0.2]
[start:end:step]оператор індексу{.users[0].name}myself
[,]оператор обʼєднання{.items[*]['metadata.name', 'status.capacity']}127.0.0.1 127.0.0.2 map[cpu:4] map[cpu:8]
?()фільтр{.users[?(@.name=="e2e")].user.password}secret
range, endітерація списку{range .items[*]}[{.metadata.name}, {.status.capacity}] {end}[127.0.0.1, map[cpu:4]] [127.0.0.2, map[cpu:8]]
''інтерпретований рядок з лапками{range .items[*]}{.metadata.name}{'\t'}{end}127.0.0.1 127.0.0.2
\символ екранування{.items[0].metadata.labels.kubernetes\.io/hostname}127.0.0.1

Приклади використання kubectl та виразів JSONPath:

kubectl get pods -o json
kubectl get pods -o=jsonpath='{@}'
kubectl get pods -o=jsonpath='{.items[0]}'
kubectl get pods -o=jsonpath='{.items[0].metadata.name}'
kubectl get pods -o=jsonpath="{.items[*]['metadata.name', 'status.capacity']}"
kubectl get pods -o=jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.startTime}{"\n"}{end}'
kubectl get pods -o=jsonpath='{.items[0].metadata.labels.kubernetes\.io/hostname}'

6.11.7 - kubectl для користувачів Docker

Ви можете використовувати інструмент командного рядка Kubernetes kubectl для взаємодії з сервером API. Використання kubectl є простим, якщо ви знайомі з інструментом командного рядка Docker. Однак, існує декілька відмінностей між командами Docker і командами kubectl. У наступних розділах показано субкоманду Docker та опис еквівалентної команди kubectl.

docker run

Щоб запустити Deployment nginx і експонувати Deployment, див. kubectl create deployment.

docker:

docker run -d --restart=always -e DOMAIN=cluster --name nginx-app -p 80:80 nginx
55c103fa129692154a7652490236fee9be47d70a8dd562281ae7d2f9a339a6db
docker ps
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                NAMES
55c103fa1296        nginx               "nginx -g 'daemon of…"   9 seconds ago       Up 9 seconds        0.0.0.0:80->80/tcp   nginx-app

kubectl:

# запуск pod з nginx
kubectl create deployment --image=nginx nginx-app
deployment.apps/nginx-app created
# додати env до nginx-app
kubectl set env deployment/nginx-app  DOMAIN=cluster
deployment.apps/nginx-app env updated
# експонування порта через service
kubectl expose deployment nginx-app --port=80 --name=nginx-http
service "nginx-http" exposed

За допомогою kubectl ви можете створити Deployment, щоб переконатися, що N Podʼів працюють під управлінням nginx, де N — це кількість реплік, вказана у специфікації, типово дорівнює 1. Ви також можете створити Service з селектором, який відповідає міткам Podʼів. Докладні відомості наведено у статті Використання Service для доступу до застосунку у кластері.

Стандартно образи запускаються у фоновому режимі, подібно до docker run -d .... Щоб запустити щось на передньому плані, скористайтеся kubectl run для створення Pod:

kubectl run [-i] [--tty] --attach <name> --image=<image>

На відміну від docker run ..., якщо ви вкажете --attach, то приєднаєте stdin, stdout і stderr. Ви не можете контролювати, які саме потоки буде приєднано (docker -a ...). Щоб відʼєднатися від контейнера, ви можете використатись комбінацією клавіш Ctrl+P, а потім Ctrl+Q.

docker ps

Для виводу переліку того, що працює, скористайтеся командою kubectl get:

docker:

docker ps -a
CONTAINER ID        IMAGE               COMMAND                  CREATED              STATUS                     PORTS                NAMES
14636241935f        ubuntu:16.04        "echo test"              5 seconds ago        Exited (0) 5 seconds ago                        cocky_fermi
55c103fa1296        nginx               "nginx -g 'daemon of…"   About a minute ago   Up About a minute          0.0.0.0:80->80/tcp   nginx-app

kubectl:

kubectl get po
NAME                        READY     STATUS      RESTARTS   AGE
nginx-app-8df569cb7-4gd89   1/1       Running     0          3m
ubuntu                      0/1       Completed   0          20s

docker attach

Щоб приєднати процес, який вже запущено у контейнері, див. kubectl attach.

docker:

docker ps
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                NAMES
55c103fa1296        nginx               "nginx -g 'daemon of…"   5 minutes ago       Up 5 minutes        0.0.0.0:80->80/tcp   nginx-app
docker attach 55c103fa1296
...

kubectl:

kubectl get pods
NAME              READY     STATUS    RESTARTS   AGE
nginx-app-5jyvm   1/1       Running   0          10m
kubectl attach -it nginx-app-5jyvm
...

Щоб відʼєднатися від контейнера, ви можете скористатись комбінацією клавіш Ctrl+P, а потім Ctrl+Q.

docker exec

Щоб виконати команду у контейнері, див. kubectl exec.

docker:

docker ps
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                NAMES
55c103fa1296        nginx               "nginx -g 'daemon of…"   6 minutes ago       Up 6 minutes        0.0.0.0:80->80/tcp   nginx-app
docker exec 55c103fa1296 cat /etc/hostname
55c103fa1296

kubectl:

kubectl get po
NAME              READY     STATUS    RESTARTS   AGE
nginx-app-5jyvm   1/1       Running   0          10m
kubectl exec nginx-app-5jyvm -- cat /etc/hostname
nginx-app-5jyvm

Використання інтерактивних команд.

docker:

docker exec -ti 55c103fa1296 /bin/sh
# exit

kubectl:

kubectl exec -ti nginx-app-5jyvm -- /bin/sh
# exit

Докладнішу інформацію наведено у статті Отримання доступу до оболонки запущеного контейнера.

docker logs

Щоб переглянути stdout/stderr запущеного процесу, див. kubectl logs.

docker:

docker logs -f a9e
192.168.9.1 - - [14/Jul/2015:01:04:02 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.35.0" "-"
192.168.9.1 - - [14/Jul/2015:01:04:03 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.35.0" "-"

kubectl:

kubectl logs -f nginx-app-zibvs
10.240.63.110 - - [14/Jul/2015:01:09:01 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.26.0" "-"
10.240.63.110 - - [14/Jul/2015:01:09:02 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.26.0" "-"

Існує невелика різниця між Podʼами та контейнерами; стандартно Podʼи не завершують роботу, якщо їхні процеси завершуються. Замість цього вони перезапускають процес. Це схоже на параметр запуску docker --restart=always з однією суттєвою відмінністю. У docker вивід для кожного виклику процесу обʼєднується, а у Kubernetes кожен виклик є окремим. Щоб переглянути результати попереднього запуску у Kubernetes, зробіть так:

kubectl logs --previous nginx-app-zibvs
10.240.63.110 - - [14/Jul/2015:01:09:01 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.26.0" "-"
10.240.63.110 - - [14/Jul/2015:01:09:02 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.26.0" "-"

Для отримання додаткової інформації див. Архітектура логування.

docker stop та docker rm

Щоб зупинити і видалити запущений процес, див. kubectl delete.

docker:

docker ps
CONTAINER ID        IMAGE               COMMAND                CREATED             STATUS              PORTS                         NAMES
a9ec34d98787        nginx               "nginx -g 'daemon of"  22 hours ago        Up 22 hours         0.0.0.0:80->80/tcp, 443/tcp   nginx-app
docker stop a9ec34d98787
a9ec34d98787
docker rm a9ec34d98787
a9ec34d98787

kubectl:

kubectl get deployment nginx-app
NAME         READY   UP-TO-DATE   AVAILABLE   AGE
nginx-app    1/1     1            1           2m
kubectl get po -l app=nginx-app
NAME                         READY     STATUS    RESTARTS   AGE
nginx-app-2883164633-aklf7   1/1       Running   0          2m
kubectl delete deployment nginx-app
deployment "nginx-app" deleted
kubectl get po -l app=nginx-app
# Нічого не повертає

docker login

У kubectl немає прямого аналога docker login. Якщо вас цікавить використання Kubernetes з приватним реєстром, див. Використання приватного реєстру.

docker version

Щоб отримати версії клієнта і сервера, див. kubectl version.

docker:

docker version
Client version: 1.7.0
Client API version: 1.19
Go version (client): go1.4.2
Git commit (client): 0baf609
OS/Arch (client): linux/amd64
Server version: 1.7.0
Server API version: 1.19
Go version (server): go1.4.2
Git commit (server): 0baf609
OS/Arch (server): linux/amd64

kubectl:

kubectl version
Client Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.9+a3d1dfa6f4335", GitCommit:"9b77fed11a9843ce3780f70dd251e92901c43072", GitTreeState:"dirty", BuildDate:"2017-08-29T20:32:58Z", OpenPaasKubernetesVersion:"v1.03.02", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.9+a3d1dfa6f4335", GitCommit:"9b77fed11a9843ce3780f70dd251e92901c43072", GitTreeState:"dirty", BuildDate:"2017-08-29T20:32:58Z", OpenPaasKubernetesVersion:"v1.03.02", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"}

docker info

Для отримання різноманітної інформації про середовище та конфігурацію див. kubectl cluster-info.

docker:

docker info
Containers: 40
Images: 168
Storage Driver: aufs
 Root Dir: /usr/local/google/docker/aufs
 Backing Filesystem: extfs
 Dirs: 248
 Dirperm1 Supported: false
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.13.0-53-generic
Operating System: Ubuntu 14.04.2 LTS
CPUs: 12
Total Memory: 31.32 GiB
Name: k8s-is-fun.mtv.corp.google.com
ID: ADUV:GCYR:B3VJ:HMPO:LNPQ:KD5S:YKFQ:76VN:IANZ:7TFV:ZBF4:BYJO
WARNING: No swap limit support

kubectl:

kubectl cluster-info
Kubernetes master is running at https://203.0.113.141
KubeDNS is running at https://203.0.113.141/api/v1/namespaces/kube-system/services/kube-dns/proxy
kubernetes-dashboard is running at https://203.0.113.141/api/v1/namespaces/kube-system/services/kubernetes-dashboard/proxy
Grafana is running at https://203.0.113.141/api/v1/namespaces/kube-system/services/monitoring-grafana/proxy
Heapster is running at https://203.0.113.141/api/v1/namespaces/kube-system/services/monitoring-heapster/proxy
InfluxDB is running at https://203.0.113.141/api/v1/namespaces/kube-system/services/monitoring-influxdb/proxy

6.11.8 - Правила використання kubectl

Рекомендовані правила використання kubectl.

Використання kubectl у багаторазових скриптах

Для стабільного виводу у скрипті:

  • Використовуйте одну з машинно-орієнтованих форм виводу, таких як -o name, -o json, -o yaml, -o go-template, або -o jsonpath.
  • Повністю вказуйте версію. Наприклад, jobs.v1.batch/myjob. Це гарантує, що kubectl не використовуватиме свою стандартну версію, яка може змінюватися з часом.
  • Не покладайтеся на контекст, налаштування або інші неявні стани.

Субресурси

  • Ви можете використовувати бета-прапорець --subresource для команд kubectl, таких як get, patch, edit та replace для отримання та оновлення субресурсів для всіх ресурсів, які їх підтримують. На цей момент підтримуються лише субресурси status та scale.
    • Для kubectl edit, субресурс scale не підтримується. Якщо ви використовуєте --subresource з kubectl edit і вказуєте scale як субресурс, команда викличе помилку.
  • Контракт API для субресурсу ідентичний до повного ресурсу. Оновлюючи субресурс status до нового значення, майте на увазі, що субресурс може бути потенційно узгоджений контролером до іншого значення.

Рекомендації

kubectl run

Для того, щоб kubectl run відповідав принципу інфраструктури як код:

  • Присвойте образу версію зі специфічним теґом і не переносіть цей теґ на нову версію. Наприклад, використовуйте :v1234, v1.2.3, r03062016-1-4, а не :latest (Для отримання додаткової інформації дивіться Поради щодо конфігурації).
  • Перевірте в скрипті наявність образу з великою кількістю параметрів.
  • Перейдіть до файлів конфігурації, перевірених у контролі вихідного коду, для отримання можливостей, які є необхідними, але не можуть бути виражені за допомогою прапорців kubectl run.

Ви можете використовувати прапорець --dry-run=client, щоб переглянути обʼєкт, який буде відправлений до вашого кластера, без реального його надсилання.

kubectl apply

  • Ви можете використовувати kubectl apply для створення або оновлення ресурсів. Для отримання додаткової інформації про використання kubectl apply для оновлення ресурсів, дивіться Kubectl Book.

6.12 - Компоненти інструментів

6.12.1 - Функціональні можливості

Ця сторінка містить огляд різних функціональних можливостей, які адміністратор може вказати для різних компонентів Kubernetes.

Дивіться функціональні стадії для пояснення стадій функції.

Огляд

Функціональні можливості — це набір пар ключ=значення, які описують функції Kubernetes. Ви можете увімкнути або вимкнути ці функції, використовуючи прапорець командного рядка --feature-gates на кожному компоненті Kubernetes.

Кожен компонент Kubernetes дозволяє вам увімкнути або вимкнути набір функціональних можливостей, які стосуються цього компонента. Використовуйте прапорець -h, щоб побачити повний набір функціональних можливостей для всіх компонентів. Щоб встановити функціональні можливості для компонента, такого як kubelet, використовуйте прапорець --feature-gates, призначений для списку пар функцій:

--feature-gates=...,GracefulNodeShutdown=true

Наступні таблиці є підсумком функціональних можливостей, які ви можете встановити на різних компонентах Kubernetes.

Функціональні можливості для функцій Alpha або Beta

Функціональні можливості для функцій у стані Alpha або Beta
ВластивістьСтандартноСтадіяПочинаючи зДо
AnonymousAuthConfigurableEndpointsfalseAlpha1.31
AnyVolumeDataSourcefalseAlpha1.181.23
AnyVolumeDataSourcetrueBeta1.24
APIResponseCompressionfalseAlpha1.71.15
APIResponseCompressiontrueBeta1.16
APIServerIdentityfalseAlpha1.201.25
APIServerIdentitytrueBeta1.26
APIServerTracingfalseAlpha1.221.26
APIServerTracingtrueBeta1.27
AuthorizeNodeWithSelectorsfalseAlpha1.31
AuthorizeWithSelectorsfalseAlpha1.31
CloudControllerManagerWebhookfalseAlpha1.27
ClusterTrustBundlefalseAlpha1.27
ClusterTrustBundleProjectionfalseAlpha1.29
ComponentSLIsfalseAlpha1.261.26
ComponentSLIstrueBeta1.27
ConsistentListFromCachefalseAlpha1.281.30
ConsistentListFromCachetrueBeta1.31
ContainerCheckpointfalseAlpha1.251.29
ContainerCheckpointtrueBeta1.30
ContextualLoggingfalseAlpha1.24
ContextualLoggingtrueBeta1.30
CoordinatedLeaderElectionfalseAlpha1.31
CPUManagerPolicyAlphaOptionsfalseAlpha1.23
CPUManagerPolicyBetaOptionstrueBeta1.23
CPUManagerPolicyOptionsfalseAlpha1.221.22
CPUManagerPolicyOptionstrueBeta1.23
CRDValidationRatchetingfalseAlpha1.281.29
CRDValidationRatchetingtrueBeta1.30
CronJobsScheduledAnnotationtrueBeta1.28
CrossNamespaceVolumeDataSourcefalseAlpha1.26
CSIMigrationPortworxfalseAlpha1.231.24
CSIMigrationPortworxfalseBeta1.25
CSIVolumeHealthfalseAlpha1.21
CustomCPUCFSQuotaPeriodfalseAlpha1.12
CustomResourceFieldSelectorsfalseAlpha1.301.30
CustomResourceFieldSelectorstrueBeta1.31
DisableCloudProvidersfalseAlpha1.221.28
DisableCloudProviderstrueBeta1.29
DisableKubeletCloudCredentialProvidersfalseAlpha1.231.28
DisableKubeletCloudCredentialProviderstrueBeta1.29
DisableNodeKubeProxyVersionfalseAlpha1.291.30
DisableNodeKubeProxyVersiontrueBeta1.31
DRAControlPlaneControllerfalseAlpha1.26
DynamicResourceAllocationfalseAlpha1.30
EventedPLEGfalseAlpha1.25
GracefulNodeShutdownfalseAlpha1.201.20
GracefulNodeShutdowntrueBeta1.21
GracefulNodeShutdownBasedOnPodPriorityfalseAlpha1.231.23
GracefulNodeShutdownBasedOnPodPrioritytrueBeta1.24
HonorPVReclaimPolicyfalseAlpha1.231.30
HonorPVReclaimPolicytrueBeta1.31
HPAScaleToZerofalseAlpha1.16
ImageMaximumGCAgefalseAlpha1.291.29
ImageMaximumGCAgetrueBeta1.30
ImageVolumefalseAlpha1.31
InPlacePodVerticalScalingfalseAlpha1.27
InTreePluginPortworxUnregisterfalseAlpha1.23
JobBackoffLimitPerIndexfalseAlpha1.281.28
JobBackoffLimitPerIndextrueBeta1.29
JobManagedByfalseAlpha1.30
JobPodReplacementPolicyfalseAlpha1.281.28
JobPodReplacementPolicytrueBeta1.29
JobSuccessPolicyfalseAlpha1.301.30
JobSuccessPolicytrueBeta1.31
KubeletCgroupDriverFromCRIfalseAlpha1.281.30
KubeletCgroupDriverFromCRItrueBeta1.31
KubeletInUserNamespacefalseAlpha1.22
KubeletPodResourcesDynamicResourcesfalseAlpha1.27
KubeletPodResourcesDynamicResourcesfalseAlpha1.27
KubeletPodResourcesGetfalseAlpha1.27
KubeletSeparateDiskGCfalseAlpha1.291.30
KubeletSeparateDiskGCtrueBeta1.31
KubeletTracingfalseAlpha1.251.26
KubeletTracingtrueBeta1.27
LoadBalancerIPModefalseAlpha1.291.30
LoadBalancerIPModetrueBeta1.30
LocalStorageCapacityIsolationFSQuotaMonitoringfalseAlpha1.151.30
LocalStorageCapacityIsolationFSQuotaMonitoringfalseBeta1.31
LoggingAlphaOptionsfalseAlpha1.24
LoggingBetaOptionstrueBeta1.24
MatchLabelKeysInPodAffinityfalseAlpha1.291.30
MatchLabelKeysInPodAffinitytrueBeta1.31
MatchLabelKeysInPodTopologySpreadfalseAlpha1.251.26
MatchLabelKeysInPodTopologySpreadtrueBeta1.27
MaxUnavailableStatefulSetfalseAlpha1.24
MemoryManagerfalseAlpha1.211.21
MemoryManagertrueBeta1.22
MemoryQoSfalseAlpha1.22
MultiCIDRServiceAllocatorfalseAlpha1.271.30
MultiCIDRServiceAllocatorfalseBeta1.31
MutatingAdmissionPolicyfalseAlpha1.30
NFTablesProxyModefalseAlpha1.291.30
NFTablesProxyModetrueBeta1.31
NodeInclusionPolicyInPodTopologySpreadfalseAlpha1.251.25
NodeInclusionPolicyInPodTopologySpreadtrueBeta1.26
NodeLogQueryfalseAlpha1.271.29
NodeLogQueryfalseBeta1.30
NodeSwapfalseAlpha1.221.27
NodeSwapfalseBeta1.281.29
NodeSwaptrueBeta1.30
OpenAPIEnumsfalseAlpha1.231.23
OpenAPIEnumstrueBeta1.24
PodAndContainerStatsFromCRIfalseAlpha1.23
PodDeletionCostfalseAlpha1.211.21
PodDeletionCosttrueBeta1.22
PodIndexLabeltrueBeta1.28
PodLifecycleSleepActionfalseAlpha1.291.29
PodLifecycleSleepActiontrueBeta1.30
PodReadyToStartContainersConditionfalseAlpha1.281.28
PodReadyToStartContainersConditiontrueBeta1.29
PortForwardWebsocketsfalseAlpha1.301.30
PortForwardWebsocketstrueBeta1.31
ProcMountTypefalseAlpha1.12
QOSReservedfalseAlpha1.11
RecoverVolumeExpansionFailurefalseAlpha1.23
RecursiveReadOnlyMountsfalseAlpha1.30
RelaxedEnvironmentVariableValidationfalseAlpha1.30
ResilientWatchCacheInitializationtrueBeta1.31
ResourceHealthStatusfalseAlpha1.31
RetryGenerateNamefalseAlpha1.30
RetryGenerateNamefalseAlpha1.30
RotateKubeletServerCertificatefalseAlpha1.71.11
RotateKubeletServerCertificatetrueBeta1.12
RuntimeClassInImageCriApifalseAlpha1.29
SchedulerQueueingHintstrueBeta1.281.28
SchedulerQueueingHintsfalseBeta1.29
SELinuxMountfalseAlpha1.30
SELinuxMountReadWriteOncePodfalseAlpha1.251.26
SELinuxMountReadWriteOncePodfalseBeta1.271.27
SELinuxMountReadWriteOncePodtrueBeta1.28
SeparateTaintEvictionControllertrueBeta1.29
ServiceAccountTokenJTIfalseAlpha1.291.29
ServiceAccountTokenJTItrueBeta1.30
ServiceAccountTokenNodeBindingfalseAlpha1.291.30
ServiceAccountTokenNodeBindingtrueBeta1.31
ServiceAccountTokenNodeBindingValidationfalseAlpha1.291.29
ServiceAccountTokenNodeBindingValidationtrueBeta1.30
ServiceAccountTokenPodNodeInfofalseAlpha1.291.29
ServiceAccountTokenPodNodeInfotrueBeta1.30
ServiceTrafficDistributionfalseAlpha1.301.30
ServiceTrafficDistributiontrueBeta1.31
SidecarContainersfalseAlpha1.281.28
SidecarContainerstrueBeta1.29
SizeMemoryBackedVolumesfalseAlpha1.201.21
SizeMemoryBackedVolumestrueBeta1.22
StatefulSetAutoDeletePVCfalseAlpha1.231.26
StatefulSetAutoDeletePVCtrueBeta1.27
StorageVersionAPIfalseAlpha1.20
StorageVersionHashfalseAlpha1.141.14
StorageVersionHashtrueBeta1.15
StorageVersionMigratorfalseAlpha1.301.32
StructuredAuthenticationConfigurationfalseAlpha1.291.29
StructuredAuthenticationConfigurationtrueBeta1.30
StructuredAuthorizationConfigurationfalseAlpha1.291.29
StructuredAuthorizationConfigurationtrueBeta1.30
SupplementalGroupsPolicyfalseAlpha1.31
TopologyAwareHintsfalseAlpha1.211.22
TopologyAwareHintsfalseBeta1.231.23
TopologyAwareHintstrueBeta1.24
TopologyManagerPolicyAlphaOptionsfalseAlpha1.26
TopologyManagerPolicyBetaOptionsfalseBeta1.261.27
TopologyManagerPolicyBetaOptionstrueBeta1.28
TopologyManagerPolicyOptionsfalseAlpha1.261.27
TopologyManagerPolicyOptionstrueBeta1.28
TranslateStreamCloseWebsocketRequeststrueBeta1.30
UnauthenticatedHTTP2DOSMitigationfalseBeta1.281.28
UnauthenticatedHTTP2DOSMitigationtrueBeta1.29
UnknownVersionInteroperabilityProxyfalseAlpha1.28
UserNamespacesPodSecurityStandardsfalseAlpha1.29
UserNamespacesSupportfalseAlpha1.281.29
UserNamespacesSupportfalseBeta1.30
VolumeAttributesClassfalseAlpha1.291.30
VolumeAttributesClassfalseBeta1.31
VolumeCapacityPriorityfalseAlpha1.21
WatchCacheInitializationPostStartHookfalseBeta1.31
WatchFromStorageWithoutResourceVersionfalseBeta1.30
WatchListfalseAlpha1.27
WindowsHostNetworktrueAlpha1.26
WinDSRfalseAlpha1.14
WinOverlayfalseAlpha1.141.19
WinOverlaytrueBeta1.20

Функціональні можливості для стабільних або застарілих функцій

Функціональні можливості для стабільних або застарілих функцій
ВластивістьСтандартноСтадіяПочинаючи зДо
AdmissionWebhookMatchConditionsfalseAlpha1.271.27
AdmissionWebhookMatchConditionstrueBeta1.281.29
AdmissionWebhookMatchConditionstrueGA1.30
AggregatedDiscoveryEndpointfalseAlpha1.261.26
AggregatedDiscoveryEndpointtrueBeta1.271.29
AggregatedDiscoveryEndpointtrueGA1.30
AllowServiceLBStatusOnNonLBfalseDeprecated1.29
APIListChunkingfalseAlpha1.81.8
APIListChunkingtrueBeta1.91.28
APIListChunkingtrueGA1.29
APIPriorityAndFairnessfalseAlpha1.181.19
APIPriorityAndFairnesstrueBeta1.201.28
APIPriorityAndFairnesstrueGA1.29
AppArmortrueBeta1.41.30
AppArmortrueGA1.31
CloudDualStackNodeIPsfalseAlpha1.271.28
CloudDualStackNodeIPstrueBeta1.291.29
CloudDualStackNodeIPstrueGA1.30
CPUManagerfalseAlpha1.81.9
CPUManagertrueBeta1.101.25
CPUManagertrueGA1.26
CSIMigrationRBDfalseAlpha1.231.27
CSIMigrationRBDfalseDeprecated1.28
DefaultHostNetworkHostPortsInPodTemplatesfalseDeprecated1.28
DevicePluginCDIDevicesfalseAlpha1.281.28
DevicePluginCDIDevicestrueBeta1.291.30
DevicePluginCDIDevicestrueGA1.31
EfficientWatchResumptionfalseAlpha1.201.20
EfficientWatchResumptiontrueBeta1.211.23
EfficientWatchResumptiontrueGA1.24
ElasticIndexedJobtrueBeta1.271.30
ElasticIndexedJobtrueGA1.31
ExecProbeTimeouttrueGA1.20
HPAContainerMetricsfalseAlpha1.201.26
HPAContainerMetricstrueBeta1.271.29
HPAContainerMetricstrueGA1.30
InTreePluginRBDUnregisterfalseAlpha1.231.27
InTreePluginRBDUnregisterfalseDeprecated1.28
JobPodFailurePolicyfalseAlpha1.251.25
JobPodFailurePolicytrueBeta1.261.30
JobPodFailurePolicytrueGA1.31
JobReadyPodsfalseAlpha1.231.23
JobReadyPodstrueBeta1.241.28
JobReadyPodstrueGA1.29
KMSv1trueDeprecated1.281.28
KMSv1falseDeprecated1.29
KMSv2falseAlpha1.251.26
KMSv2trueBeta1.271.28
KMSv2trueGA1.29
KMSv2KDFfalseBeta1.281.28
KMSv2KDFtrueGA1.29
KubeProxyDrainingTerminatingNodesfalseAlpha1.281.30
KubeProxyDrainingTerminatingNodestrueBeta1.301.30
KubeProxyDrainingTerminatingNodestrueGA1.31
LegacyServiceAccountTokenCleanUpfalseAlpha1.281.28
LegacyServiceAccountTokenCleanUptrueBeta1.291.29
LegacyServiceAccountTokenCleanUptrueGA1.30
LogarithmicScaleDownfalseAlpha1.211.21
LogarithmicScaleDowntrueBeta1.221.30
LogarithmicScaleDowntrueGA1.31
MinDomainsInPodTopologySpreadfalseAlpha1.241.24
MinDomainsInPodTopologySpreadfalseBeta1.251.26
MinDomainsInPodTopologySpreadtrueBeta1.271.29
MinDomainsInPodTopologySpreadtrueGA1.30
NewVolumeManagerReconstructionfalseBeta1.271.27
NewVolumeManagerReconstructiontrueBeta1.281.29
NewVolumeManagerReconstructiontrueGA1.30
NodeOutOfServiceVolumeDetachfalseAlpha1.241.25
NodeOutOfServiceVolumeDetachtrueBeta1.261.27
NodeOutOfServiceVolumeDetachtrueGA1.28
PDBUnhealthyPodEvictionPolicyfalseAlpha1.261.26
PDBUnhealthyPodEvictionPolicytrueBeta1.271.30
PDBUnhealthyPodEvictionPolicytrueGA1.31
PersistentVolumeLastPhaseTransitionTimefalseAlpha1.281.28
PersistentVolumeLastPhaseTransitionTimetrueBeta1.291.30
PersistentVolumeLastPhaseTransitionTimetrueGA1.31
PodDisruptionConditionsfalseAlpha1.251.25
PodDisruptionConditionstrueBeta1.261.30
PodDisruptionConditionstrueGA1.31
PodHostIPsfalseAlpha1.281.28
PodHostIPstrueBeta1.291.30
PodHostIPstrueGA1.30
PodSchedulingReadinessfalseAlpha1.261.26
PodSchedulingReadinesstrueBeta1.271.29
PodSchedulingReadinesstrueGA1.30
RemainingItemCountfalseAlpha1.151.15
RemainingItemCounttrueBeta1.161.28
RemainingItemCounttrueGA1.29
ServerSideApplyfalseAlpha1.141.15
ServerSideApplytrueBeta1.161.21
ServerSideApplytrueGA1.22
ServerSideFieldValidationfalseAlpha1.231.24
ServerSideFieldValidationtrueBeta1.251.26
ServerSideFieldValidationtrueGA1.27
SkipReadOnlyValidationGCEfalseAlpha1.281.28
SkipReadOnlyValidationGCEtrueDeprecated1.29
StableLoadBalancerNodeSettrueBeta1.271.29
StableLoadBalancerNodeSettrueGA1.30
StatefulSetStartOrdinalfalseAlpha1.261.26
StatefulSetStartOrdinaltrueBeta1.271.30
StatefulSetStartOrdinaltrueGA1.31
ValidatingAdmissionPolicyfalseAlpha1.261.27
ValidatingAdmissionPolicyfalseBeta1.281.29
ValidatingAdmissionPolicytrueGA1.30
WatchBookmarkfalseAlpha1.151.15
WatchBookmarktrueBeta1.161.16
WatchBookmarktrueGA1.17
ZeroLimitedNominalConcurrencySharesfalseBeta1.291.29
ZeroLimitedNominalConcurrencySharestrueGA1.30

Використання функцій

Стадії функцій

Кожна функція може бути в стані Alpha, Beta або GA (загальнодоступна).

Alpha означає:

  • Функція є типово вимкненою.
  • Функція може містити помилки. Увімкнення функції може призвести до непередбачуваної поведінки.
  • Підтримка функції може бути припинена в будь-який момент без попередження.
  • API може змінюватися в несумісний спосіб в майбутніх випусках без попередження.
  • Рекомендується використовувати функцію в кластерах з коротким терміном життя через значний ризик помилок та відсутність довгострокової підтримки.

Beta означає:

  • Зазвичай функція є типово увімкненою. Бета API групи є типово вимкненими.
  • Функція є добре протестованою. Увімкнення функції вважається безпечним.
  • Підтримка загального функціонала не буде припинена, хоча деталі можуть змінюватися.
  • Схема та/або семантика обʼєктів можуть змінюватися несумісними способами в наступному бета або стабільному випуску. Коли це станеться, ми надамо інструкції для переходу на наступну версію. Це може вимагати видалення, редагування та повторного створення API обʼєктів. Процес редагування може потребувати певних зусиль. Це може вимагати простою для застосунків, які залежать від функції.
  • Рекомендується використовувати лише для некритичних для бізнесу випадків через можливість несумісних змін у наступних випусках. Якщо у вас є кілька кластерів, які можуть бути оновлені незалежно, ви можете послабити це обмеження.

Функція в стані Загальна доступність (GA) також називається стабільною функцією. Це означає:

  • Функція завжди увімкнена; ви не можете її вимкнути.
  • Відповідний перемикач функціональної можливості більше не потрібен.
  • Стабільні версії функцій зʼявлятимуться у випущеному програмному забезпеченні для багатьох наступних версій.

Перелік функціональних можливостей

Кожна функціональна можливість створена для вмикання/вимикання певної функції.

  • AdmissionWebhookMatchConditions: Вмикає умови збігу для модифікації та перевірки вебхуків допуску.

  • AggregatedDiscoveryEndpoint: Вмикає єдину точку доступу до HTTP /discovery/<version>, яка підтримує власне кешування HTTP за допомогою теґів, що містять усі відомі APIResources на сервері API.

  • AllowServiceLBStatusOnNonLB: Дозволяє встановлювати .status.ingress.loadBalancer для сервісів типів, відмінних від LoadBalancer.

  • AnonymousAuthConfigurableEndpoints: Дозволяє увімкнути налаштовувані точки доступу для анонімної автентифікації для сервера API.

  • AnyVolumeDataSource: Дозволити використання будь-якого власного ресурсу як DataSource для PVC.

  • APIListChunking: Дозволяє клієнтам API отримувати (LIST або GET) ресурси з сервера API частинами.

  • APIPriorityAndFairness: Дозволяє керувати паралельністю запитів за допомоги приорітезації та справедливості на кожному сервері. (Перейменовано з RequestManagement)

  • APIResponseCompression: Стиснення відповідей API для запитів LIST або GET.

  • APIServerIdentity: Присвоює кожному серверу API ідентифікатор у кластері, використовуючи Lease.

  • APIServerTracing: Додає підтримку розподіленого трасування у сервері API. Докладні відомості наведено у статті Трасування системних компонентів Kubernetes.

  • AppArmor: Вмикає використання примусового контролю доступу AppArmor для Podʼів, що працюють на вузлах Linux. Докладнішу інформацію наведено у Посібнику з AppArmor.

  • AuthorizeNodeWithSelectors: Дозволяє авторизатору вузла використовувати детальну авторизацію за допомогою селекторів. Потрібно увімкнути AuthorizeWithSelectors.

  • AuthorizeWithSelectors: Дозволяє використовувати селектори полів та міток для авторизації. Увімкнення полів fieldSelector та labelSelector в API SubjectAccessReview, передає інформацію про селектори полів і міток до вебхуків авторизації, активує функції fieldSelector та labelSelector у бібліотеці CEL для авторизації, а також дозволяє перевіряти поля fieldSelector і labelSelector в умовах збігу вебхуків авторизації.

  • CloudControllerManagerWebhook: Вмикання веб-хуків у менеджері хмарних контролерів.

  • CloudDualStackNodeIPs: Вмикає двостековий kubelet --node-ip із зовнішніми хмарними провайдерами. Див. статтю Налаштування подвійного стека IPv4/IPv6 для більш детальної інформації.

  • ClusterTrustBundle: Вмикає обʼєкти ClusterTrustBundle та інтеграцію kubelet.

  • ClusterTrustBundleProjection: джерела спроєцьованих томів clusterTrustBundle.

  • ComponentSLIs: Вмикає точку доступу /metrics/slis на таких компонентах Kubernetes як kubelet, kube-scheduler, kube-proxy, kube-controller-manager, cloud-controller-manager що дозволяє вам отримувати метрики перевірки працездатності.

  • ConsistentListFromCache:

    Покращує продуктивність API сервера Kubernetes, обслуговуючи узгоджені запити list безпосередньо з кешу спостереження, що підвищує масштабованість та скорочує час відгуку. Для узгодженого списку з кешу Kubernetes потрібна новіша версія etcd (v3.4.31+ або v3.5.13+), яка містить виправлення для функції запиту на прогрес спостереження. Якщо надана стара версія etcd, Kubernetes автоматично визначить це і повернеться до обслуговування узгоджених читань з etcd. Сповіщення про прогрес забезпечують узгодженість кешу спостереження з etcd, одночасно зменшуючи потребу у витратних читаннях кворуму з etcd.

    Детальніше дивіться у документації Kubernetes про Семантику для get і list.

  • ContainerCheckpoint: Вмикає kubelet checkpoint API. Дивіться Kubelet Checkpoint API для більш детальної інформації.

  • ContextualLogging: Вмикає додаткові деталі у виведенні логів компонентів Kubernetes, які підтримують контекстне ведення логів.

  • CoordinatedLeaderElection: Вмикає поведінку, що підтримує API LeaseCandidate, а також забезпечує детерміноване обрання лідера для панелі управління Kubernetes.

  • CPUManager: Вмикає підтримку спорідненості процесорів на рівні контейнерів, див. Політики керування процесорами.

  • CPUManagerPolicyAlphaOptions: Дозволяє тонко налаштовувати політики CPUManager, експериментальні, альфа-опції якості. Ця функціональна можливість захищає групу опцій CPUManager, які мають рівень якості альфа. Ці функціональні можливості ніколи не будуть переведені у бета-версію або стабільну версію.

  • CPUManagerPolicyBetaOptions: Дозволяє тонко налаштовувати політики CPUManager, експериментальні, бета-опції якості. Ця функціональна можливість захищає групу опцій CPUManager, які мають рівень якості бета. Ці функціональні можливості ніколи не будуть переведені у стабільну версію.

  • CPUManagerPolicyOptions: Дозволяє тонко налаштовувати політики CPUManager.

  • CRDValidationRatcheting: Ввімкнути оновлення власних ресурсів, щоб вони містили порушення їхньої схеми OpenAPI, якщо частини ресурсу, що порушують оновлення не змінилися. Докладніші відомості наведено у статті Проковзування валідації.

  • CronJobsScheduledAnnotation: Встановіть час запланованого завдання як анотацію для завдань, створених від імені CronJob.

  • CrossNamespaceVolumeDataSource: Вмикає використання перехресного простору назв джерела даних тома щоб дозволити вам вказувати простір імен джерела у полі dataSourceRef у PersistentVolumeClaim.

  • CSIMigrationPortworx: Вмикає shimʼи та логіку передачі для маршрутизації операцій тому з вбудованого втулка Portworx до втулка Portworx CSI. Вимагає встановлення та налаштування втулка Portworx CSI в кластері.

  • CSIMigrationRBD: Вмикає shimʼи та логіку передачі для маршрутизації операцій тому з вбудованого втулка RBD до втулка Ceph RBD CSI. Вимагає увімкнення прапорця функції CSIMigration та встановлення та налаштування втулка Ceph CSI в кластері. Цей прапорець було відзначено як застарілий на користь прапорця функції InTreePluginRBDUnregister, який запобігає реєстрації вбудованого втулка RBD.

  • CSIVolumeHealth: Вмикає підтримку моніторингу стану справності томів CSI на вузлі.

  • CustomCPUCFSQuotaPeriod: Дозволяє вузлам змінювати cpuCFSQuotaPeriod в конфігурації kubelet.

  • CustomResourceFieldSelectors: Вмикає selectableFields в API CustomResourceDefinition, щоб дозволити фільтрацію запитів list, watch та deletecollection для власних ресурсів.

  • DefaultHostNetworkHostPortsInPodTemplates:

    Ця функціональна можливість керує моментом, коли стандартне значення для .spec.containers[*].ports[*].hostPort назначається для Podʼів, які використовують hostNetwork: true. Типовим з версії Kubernetes v1.28 є те, що стандартне значення встановлюється лише для Podʼів.

    Вмикаючи цю функціональну можливість, стандартне значення буде назначено навіть для .spec вбудованого PodTemplate (наприклад, у Deployment), що є способом, яким працювали старі версії Kubernetes. Вам слід мігрувати свій код так, щоб він не залежав від старої поведінки.

  • DevicePluginCDIDevices: Вмикає підтримку ідентифікаторів пристроїв CDI в API Device Plugin.

  • DisableCloudProviders: Вимикає будь-яку функціональність у kube-apiserver, kube-controller-manager та kubelet, повʼязаних з прапорцем компонента --cloud-provider. прапором компонента.

  • DisableKubeletCloudCredentialProviders: Вмикає вбудовану функціональність kubelet для автентифікації в реєстрі контейнерів хмарного постачальника для отримання облікових даних для отримання образів.

  • DisableNodeKubeProxyVersion: Вимикає встановлення поля kubeProxyVersion вузла.

  • DRAControlPlaneController: Дозволяє підтримувати ресурси з власними параметрами та життєвим циклом, який не залежить від Pod. Розподілом ресурсів займається контролер панелі управління драйвера ресурсу.

  • DynamicResourceAllocation: Дозволяє підтримувати ресурси з власними параметрами та життєвим циклом які не залежать від Pod. Розподілом ресурсів займається планувальник Kubernetes використовуючи "структуровані параметри".

  • EfficientWatchResumption: Дозволяє надсилати користувачам події закладок (сповіщення про хід виконання), що походять зі сховища. Застосовується лише до операцій спостереження.

  • ElasticIndexedJob: Дозволяє масштабувати індексовані завдання шляхом зміни параметрів spec.completions та spec.parallelism таким чином, щоб spec.completions == spec.parallelism. Детальніше див. у документації про еластичні індексовані завдання.

  • EventedPLEG: Вмикає підтримку kubelet для отримання подій життєвого циклу контейнера з container runtime через розширення до CRI. (PLEG, скорочення від "Pod lifecycle event generator" — генератор подій життєвого циклу Pod). Щоб ця функція була корисною, вам також потрібно увімкнути підтримку подій життєвого циклу контейнера у кожному середовищі виконання контейнерів, що працює у вашому кластері. Якщо середовище виконання контейнера не оголошує про підтримку подій життєвого циклу контейнера, то kubelet автоматично перемикається на застарілий загальний механізм PLEG, навіть якщо ви увімкнули цю функціональну можливість.

  • ExecProbeTimeout: Переконайтеся, що kubelet дотримується таймаутів exec probe. Ця функція існує на випадок, якщо будь-яке з ваших робочих навантажень залежить від виправленої помилки, коли Kubernetes ігнорував тайм-аути exec probe. Дивіться проби готовності.

  • GracefulNodeShutdown: Вмикає підтримку відповідного завершення роботи у kubelet. Під час вимкнення системи kubelet намагатиметься виявити подію вимкнення і завершити роботу Podʼів, запущених на вузлі, відповідним чином. Докладніші відомості наведено у статті Відповідне вимикання вузла.

  • GracefulNodeShutdownBasedOnPodPriority: Дозволяє kubelet перевіряти пріоритети Pod під час відповідного завершення роботи вузла.

  • HonorPVReclaimPolicy: Дотримуватися політики відновлення постійного тому, коли він має значення Delete, незалежно від впорядкування видалення PV-PVC. Докладніші відомості наведено у документації Завершувач захисту від видалення постійних томів.

  • HPAContainerMetrics: Дозволяє HorizontalPodAutoscalers виконувати масштабування на основі метрик з окремих контейнерів у межах цільових Podʼів.

  • HPAScaleToZero: Дозволяє встановлювати minReplicas у 0 для ресурсів HorizontalPodAutoscaler при використанні власних або зовнішніх метрик.

  • ImageMaximumGCAge: Вмикає поле конфігурації kubelet imageMaximumGCAge, що дозволяє адміністратору вказати вік, після якого образ буде викинуто у смітник.

  • ImageVolume: Дозволити використання джерела тому image у Pod. За допомогою цього джерела томів ви можете змонтувати образ контейнера як том лише для читання.

  • InPlacePodVerticalScaling: Дозволяє вертикальне масштабування Podʼів на місці.

  • InTreePluginPortworxUnregister: Припиняє реєстрацію вбудованого втулка Portworx у kubelet та контролерах томів.

  • InTreePluginRBDUnregister: Припиняє реєстрацію вбудованого втулка RBD у kubelet та контролерах томів.

  • JobBackoffLimitPerIndex: Дозволяє вказати максимальну кількість повторних спроб для кожного індексу в проіндексованих завданнях.

  • JobManagedBy: Дозволяє делегувати узгодження обʼєкта Job зовнішньому контролеру.

  • JobPodFailurePolicy: Дозволяє користувачам визначати обробку несправностей контейнерів на основі кодів виходу з контейнера та стану контейнерів.

  • JobPodReplacementPolicy: Дозволяє вказувати заміну для Podʼів, що завершуються, в Job

  • JobReadyPods: Дозволяє відстежувати кількість Podʼів, які мають стан Ready. Кількість Ready Podʼів записується у status Job.

  • JobSuccessPolicy: Дозволяє користувачам вказувати, коли Job може бути визнаний успішним на основі набору успішних Podʼів.

  • KMSv1: Вмикає API KMS v1 для шифрування у стані спокою. Докладні відомості наведено у статті Використання постачальника KMS для шифрування даних.

  • KMSv2: Вмикає API KMS v2 для шифрування у стані спокою. Докладні відомості наведено у статті Використання постачальника KMS для шифрування даних.

  • KMSv2KDF: Дозволяє KMS v2 генерувати одноразові ключі шифрування даних. Докладні відомості наведено у статті Використання постачальника KMS для шифрування даних. Якщо у вашому кластері не увімкнено елемент KMSv2, значення елемента KMSv2KDF не матиме жодного впливу.

  • KubeletCgroupDriverFromCRI: Вмикає виявлення параметра конфігурації драйвера cgroup kubelet з CRI. Ви можете використовувати цю функціональну можливість на вузлах з kubelet, які її підтримують, і де є середовище виконання контейнерів CRI, що підтримує виклик CRI RuntimeConfig. Якщо як CRI, так і kubelet підтримують цю функцію, kubelet ігнорує налаштування конфігурації cgroupDriver (або застарілий аргумент командного рядка --cgroup-driver). Якщо ви увімкнете цю функціональну можливість, а середовище виконання контейнерів не підтримує її, kubelet повертається до використання драйвера, налаштованого за допомогою параметра конфігурації cgroupDriver. Дивіться Конфігурація драйвера cgroup для отримання додаткової інформації.

  • KubeletInUserNamespace: Вмикає підтримку запуску kubelet у просторі імен користувачів. Див. розділ Запуск компонентів вузла Kubernetes від імені не-root користувача.

  • KubeletPodResourcesDynamicResources: Розширює ресурси gRPC точки доступа Podʼа kublet, щоб включати ресурси, що виділені в ResourceClaims через API DynamicResourceAllocation. Див. звіт про виділення ресурсів для отримання додаткових відомостей. З цією інформацією про ресурси, клієнти можуть належним чином відстежувати вільні обчислювальні ресурси на вузлі.

  • KubeletPodResourcesDynamicResources: Розширює ресурси gRPC точки доступу Podʼа kubelet, щоб включити ресурси, виділені в ResourceClaims через API DynamicResourceAllocation. Див. звіт про виділення ресурсів для отримання додаткової інформації, інформацією про доступні ресурси, що дозволяє клієнтам належним чином відстежувати вільні обчислювальні ресурси на вузлі.

  • KubeletPodResourcesGet: Вмикає точку доступу Get gRPC в kubeletʼах для ресурсів Pod. Цей API доповнює звіт про розподіл ресурсів.

  • KubeletSeparateDiskGC: Функція розділеної файлової системи образів дозволяє kubelet виконувати збір сміття образів (шарів лише для читання) та/або контейнерів (шарів для запису), розгорнутих на окремих файлових системах.

  • KubeletTracing: Додавання підтримки розподіленого трасування в kubelet. Якщо увімкнено, інтерфейс CRI kubelet та автентифіковані http-сервери використовуються для генерації відрізків трасування OpenTelemetry. Дивіться Трасування для системних компонентів Kubernetes для більш детальної інформації.

  • KubeProxyDrainingTerminatingNodes: Реалізація очищення зʼєднань для термінальних вузлів для сервісів externalTrafficPolicy: Cluster.

  • LegacyServiceAccountTokenCleanUp: Вмикає очищення токенів службових облікових записів, що базуються на Secret, коли вони не використовуються протягом певного часу (стандартно — один рік).

  • LoadBalancerIPMode: Дозволяє встановити ipMode для сервісів, де type встановлено у LoadBalancer. Докладнішу інформацію наведено у статті Визначення IPMode статусу балансувальника навантаження.

  • LocalStorageCapacityIsolationFSQuotaMonitoring: Якщо LocalStorageCapacityIsolation увімкнено для локального ефемерного сховища, резервна файлова система для томів emptyDir підтримує квоти проєктів і UserNamespacesSupport увімкнено, квоти проєктів використовуються для моніторингу споживання сховища томів emptyDir, а не шляхом проходу файловою системою, що забезпечує кращу продуктивність і точність.

  • LogarithmicScaleDown: Вмикає напіввипадковий вибір Podʼів для виселення при зменшенні масштабу контролера на основі логарифмічного обʼєднання міток часу Podʼів.

  • LoggingAlphaOptions: Дозволяє тонко налаштовувати експериментальні, альфа-якості параметрів логування.

  • LoggingBetaOptions: Дозволяє тонко налаштовувати експериментальні, бета-якості параметрів логування.

  • MatchLabelKeysInPodAffinity: Вмикає поля matchLabelKeys та mismatchLabelKeys для pod (anti)affinity.

  • MatchLabelKeysInPodTopologySpread: Вмикає поле matchLabelKeys для Обмеження поширення топології Podʼів.

  • MaxUnavailableStatefulSet: Дозволяє встановити поле maxUnavailable для rolling update strategy набору StatefulSet. Поле визначає максимальну кількість Podʼів, які можуть бути недоступні під час оновлення.

  • MemoryManager: Дозволяє встановити спорідненість памʼяті для контейнера на основі топології NUMA.

  • MemoryQoS: Вмикає захист памʼяті та обмеження використання памʼяті на pod/контейнер за допомогою контролера памʼяті cgroup v2.

  • MinDomainsInPodTopologySpread: Вмикає minDomains в Обмеженнях поширення топології Pod.

  • MultiCIDRServiceAllocator: Відстежуйте розподіл IP-адрес для IP кластера сервісів за допомогою обʼєктів IPAddress.

  • MutatingAdmissionPolicy: У Kubernetes 1.31 цей елемент не має ефекту. У майбутньому випуску Kubernetes цей елемент може бути використано для увімкнення MutatingAdmissionPolicy у ланцюжку допусків.

  • NewVolumeManagerReconstruction:

    Дозволяє покращити виявлення змонтованих томів під час запуску kubelet. Оскільки відповідний код було суттєво перероблено, у версіях Kubernetes від 1.25 до 1.29 можна було вимкнути цю функцію у випадку, якщо kubelet застряг під час запуску або не розмонтував томи з завершених Podʼів.

    Цей рефакторинг лежав в основі функції SELinuxMountReadWriteOncePod у версіях Kubernetes 1.25 та 1.26.

  • NFTablesProxyMode: Дозволяє запуск kube-proxy у режимі nftables.

  • NodeInclusionPolicyInPodTopologySpread: Вмикає використання nodeAffinityPolicy та nodeTaintsPolicy в Обмеження поширення топології Podʼів при обчисленні відхилення розповсюдження топології вузлів.

  • NodeLogQuery: Дозволяє запитувати логи сервісів вузла за допомогою точки доступу /logs.

  • NodeOutOfServiceVolumeDetach: Коли вузол позначено як такий, що не працює, за допомогою taint node.kubernetes.io/out-of-service, то Podʼи на цьому вузлі будуть примусово видалені, якщо вони не можуть толерувати цю позначку, а операції відʼєднання томів для Podʼів, що завершують роботу на цьому вузлі, будуть виконані негайно. Видалені Podʼи можуть бути швидко відновлені на інших вузлах.

  • NodeSwap: Дозволяє kubelet виділяти памʼять підкачки для робочих навантажень Kubernetes на вузлі. Має використовуватися з KubeletConfiguration.failSwapOn, встановленим у false. За більш детальною інформацією зверніться до swap memory

  • OpenAPIEnums: Дозволяє заповнювати поля "enum" схем OpenAPI у специфікації, що повертається від сервера API.

  • PDBUnhealthyPodEvictionPolicy: Вмикає поле unhealthyPodEvictionPolicy в полі PodDisruptionBudget. Визначає, коли слід розглядати можливість виселення несправних Podʼів. Будь ласка, дивіться Політику виселення несправних Podʼів для більш детальної інформації.

  • PersistentVolumeLastPhaseTransitionTime: Додає нове поле до PersistentVolume, яке містить мітку часу, коли том востаннє змінював свою фазу.

  • PodAndContainerStatsFromCRI: Налаштуйте kubelet на збір статистики контейнерів і Podʼів під час виконання CRI-контейнера, а не на збір статистики з cAdvisor. Починаючи з версії 1.26, це також включає збір метрик з CRI та надсилання їх за допомогою /metrics/cadvisor (замість того, щоб cAdvisor відправляв їх безпосередньо).

  • PodDeletionCost: Вмикає функцію Pod Deletion Cost, яка дозволяє користувачам впливати на порядок зменшення масштабу ReplicaSet.

  • PodDisruptionConditions: Вмикає підтримку додавання спеціальної умови, яка вказує на те, що Pod видаляється через збій.

  • PodHostIPs: Вмикає поле status.hostIPs для Podʼів та downward API. Це поле дозволяє вам показувати IP-адреси хостів робочим навантаженням.

  • PodIndexLabel: Дозволяє контролеру Job і контролеру StatefulSet додавати індекс Podʼів як мітку під час створення нових Podʼів. Докладніше дивіться в документах Режим завершення завдання та Мітка індексу Podʼів StatefulSet.

  • PodLifecycleSleepAction: Вмикає дію sleep в хуках життєвого циклу контейнера.

  • PodReadyToStartContainersCondition:

    Дозволяє kubelet позначати стан PodReadyToStartContainers для контейнерів Podʼів.

    Раніше ця функціональна можливість була відома як PodHasNetworkCondition, а повʼязана з нею умова називалася PodHasNetwork.

  • PodSchedulingReadiness: Дозволяє встановлювати поле SchedulingGates для керування готовністю до виселення за розкладом.

  • PortForwardWebsockets: Дозволити потокове передавання WebSocket підпротоколу portforward (port-forward) від клієнтів, які запитують версію v2 (v2.portforward.k8s.io) підпротоколу.

  • ProcMountType: Дозволяє керувати типом монтування proc для контейнерів, встановлюючи поле procMount у SecurityContext.

  • QOSReserved: Дозволяє резервувати ресурси на рівні QoS, запобігаючи тим самим тому, щоб підсистеми на рівнях QoS нижчого рівня виходили за межі ресурсів, запитаних на рівнях QoS вищого рівня (наразі лише памʼять).

  • RecoverVolumeExpansionFailure: Дозволяє користувачам редагувати свої PVC до менших розмірів, щоб можна було відновити їх після попередніх збоїв під час розширення томів. Докладні відомості див. у статті Відновлення після збою під час розширення томів.

  • RecursiveReadOnlyMounts: Вмикає підтримку рекурсивних монтувань лише для читання. Докладні відомості наведено у статті монтування лише для читання.

  • RelaxedEnvironmentVariableValidation: Дозволити майже всі друковані символи ASCII у змінних оточення.

  • RemainingItemCount: Дозволити серверам API показувати кількість елементів, що залишилися, у відповіді на запит chunking list request.

  • ResilientWatchCacheInitialization: Дозволяє відмовостійку ініціалізацію кешу watch, щоб уникнути перевантаження панелі управління.

  • ResourceHealthStatus: Вмикає поле allocatedResourcesStatus у файлі .status для Pod. У полі буде показано додаткові відомості для кожного контейнера у Pod, а також інформацію про стан кожного пристрою, призначеного для Pod. Докладні відомості наведено у статті Втулок пристрою та несправні пристрої.

  • RetryGenerateName: Дозволяє повторити спробу створення обʼєкта, коли API server очікується, що сервер API server згенерує name. Якщо цю можливість увімкнено, запити з використанням generateName будуть автоматично повторюватися, якщо панель управління виявить конфлікт імен з наявним обʼєктом, але не більше 8 спроб.

  • RetryGenerateName: Дозволяє повторити спробу створення обʼєкта, коли очікується, що API server створить name. Коли цю можливість увімкнено, запити з використанням generateName автоматично повторюються у випадку, якщо панель управління виявляє конфлікт імен з наявним обʼєктом, до обмеження у 8 спроб.

  • RotateKubeletServerCertificate: Вмикає ротацію серверного TLS-сертифікату в kubelet. Дивіться kubelet configuration для більш детальної інформації.

  • RuntimeClassInImageCriApi: Дозволяє витягувати зображення на основі класу виконання Podʼів, які посилаються на них.

  • SchedulerQueueingHints: Дозволяє покращення підказок планувальника, що дозволяє зменшити кількість марних перезапитів. Планувальник повторно спробує запланувати Podʼи, якщо щось зміниться у кластері, що може призвести до того, що Pod буде заплановано. Підказки щодо черги — це внутрішні сигнали, які дозволяють планувальнику відфільтрувати зміни у кластері, які мають відношення до незапланованого Podʼа, на основі попередніх спроб планування.

  • SELinuxMount:

    Прискорює запуск контейнера, дозволяючи kubelet монтувати томи для Pod безпосередньо з правильною міткою SELinux замість того, щоб рекурсивно змінювати кожен файл на томах. Це розширює можливості покращення продуктивності за допомогою SELinuxMountReadWriteOncePod, поширюючи реалізацію на всі томи.

    Для увімкнення SELinuxMount потрібно, щоб було увімкнено SELinuxMountReadWriteOncePod.

  • SELinuxMountReadWriteOncePod: Прискорює запуск контейнера, дозволяючи kubelet монтувати томи для Pod безпосередньо з правильною міткою SELinux замість того, щоб рекурсивно змінювати кожен файл на томах. Початкова реалізація була зосереджена на томах ReadWriteOncePod.

  • SeparateTaintEvictionController: Дозволяє запуск TaintEvictionController, який виконує Taint-based Evictions, у контролері, відокремленому від NodeLifecycleController. Коли цю можливість увімкнено, користувачі можуть за бажанням вимкнути виселення на основі Taint, встановивши прапорець --controllers=-taint-eviction-controller у kube-controller-manager.

  • ServerSideApply: Вмикає функцію Server Side Apply (SSA) на сервері API.

  • ServerSideFieldValidation: Вмикає перевірку полів на стороні сервера. Це означає, що перевірка схеми ресурсів виконується на стороні сервера API, а не на стороні клієнта (наприклад, командний рядок kubectl create або kubectl apply).

  • ServiceAccountTokenJTI: Контролює, чи вбудовуються JTI (UUID) у згенеровані токени службових облікових записів, і чи записуються ці JTI до логу аудиту Kubernetes для майбутніх запитів, зроблених цими токенами.

  • ServiceAccountTokenNodeBinding: Контролює, чи дозволяє сервер API привʼязувати токени службових облікових записів до обʼєктів Node.

  • ServiceAccountTokenNodeBindingValidation: Керує тим, чи буде apiserver перевіряти посилання на Node у токенах службових облікових записів.

  • ServiceAccountTokenPodNodeInfo: Керує тим, чи вбудовувати імʼя вузла та uid для повʼязаного з ним вузла при видачі токенів службових облікових записів, привʼязаних до обʼєктів Pod.

  • ServiceTrafficDistribution: Дозволяє використовувати необовʼязкове поле spec.trafficDistribution у Services. У цьому полі можна вказати параметри розподілу трафіку між точками доступу Service.

  • SidecarContainers: Дозволити встановлювати restartPolicy контейнера init значення Always, щоб контейнер ставав sidecar-контейнером (контейнери init, які можна перезапустити). Дивіться Контейнери Sidecar та restartPolicy для отримання більш детальної інформації.

  • SizeMemoryBackedVolumes: Дозволяє kubelet визначати обмеження розміру для памʼяті, яка використовується для томів (головним чином для томів emptyDir).

  • SkipReadOnlyValidationGCE: Пропускає валідацію для GCE, буде увімкнено у наступній версії.

  • StableLoadBalancerNodeSet: Дозволяє зменшити кількість переконфігурацій балансувальника навантаження контролером послуг (KCCM) внаслідок зміни стану вузла.

  • StatefulSetAutoDeletePVC: Дозволяє використовувати необовʼязкове поле .spec.persistentVolumeClaimRetentionPolicy, що забезпечує контроль над видаленням PVC у життєвому циклі StatefulSet. Дивіться PersistentVolumeClaim retention для більш детальної інформації.

  • StatefulSetStartOrdinal: Дозволити налаштування порядкового номера старту у StatefulSet. Дивіться Початковий порядковий номер для більш детальної інформації.

  • StorageVersionAPI: Вмикає API версії зберігання.

  • StorageVersionHash: Дозволити API-серверам показувати хеш версії сховища при відкритті.

  • StorageVersionMigrator: Вмикає міграцію версій сховища. Докладні відомості наведено у статті Міграція обʼєктів Kubernetes за допомогою міграції версій сховища.

  • StructuredAuthenticationConfiguration: Вмикає конфігурацію структурованої автентифікації для сервера API.

  • StructuredAuthorizationConfiguration: Вмикає структуровану конфігурацію авторизації, щоб адміністратори кластера могли вказати більше одного webhook авторизації в ланцюжку обробників серверів API.

  • SupplementalGroupsPolicy: Вмикає підтримку детального контролю SupplementalGroups. Докладні відомості див. у статті Налаштування детального контролю SupplementalGroups для Podʼа.

  • TopologyAwareHints: Вмикає маршрутизацію з урахуванням топології на основі підказок топології у EndpointSlices. Див. статтю Підказки з урахуванням топології для отримання детальнішої інформації.

  • TopologyManagerPolicyAlphaOptions: Дозволяє тонке налаштування політик менеджера топології, експериментальні варіанти з альфа-якістю. Ця функціональна можливість захищає групу параметрів менеджера топології, рівень якості яких є альфа. Ця функціональна можливість ніколи не перейде до бета-версії або стабільної версії.

  • TopologyManagerPolicyBetaOptions: Дозволяє тонке налаштування політик менеджера топології, експериментальні варіанти з бета-якістю. Ця функціональна можливість захищає групу параметрів менеджера топології, рівень якості яких є бета. Ця функціональна можливість ніколи не перейде до стабільної версії.

  • TopologyManagerPolicyOptions: Вмикає тонке налаштування політик менеджера топології.

  • TranslateStreamCloseWebsocketRequests: Дозволити WebSocket потік підпротоколу віддалених команд (exec, cp, attach) від клієнтів, які запитують версію 5 (v5) підпротоколу.

  • UnauthenticatedHTTP2DOSMitigation: Вмикає помʼякшення наслідків відмови в обслуговуванні (DoS) HTTP/2 для неавторизованих клієнтів. У версіях Kubernetes від 1.28.0 до 1.28.2 ця функція не включена.

  • UnknownVersionInteroperabilityProxy: Проксі-запити ресурсів до правильного однорангового kube-apiserver, коли існує декілька kube-апісерверів у різних версіях. Докладнішу інформацію наведено у статті Проксі змішаних версій.

  • UserNamespacesPodSecurityStandards: Дозволити помʼякшення політик стандартів безпеки для Podʼів, які працюють з просторами імен. Ви маєте встановити значення цієї можливості узгоджено на всіх вузлах кластера, а також увімкнути UserNamespacesSupport, щоб використовувати цю можливість.

  • UserNamespacesSupport: Вмикання підтримки простору імен користувача для Podʼів.

  • ValidatingAdmissionPolicy: Вмикання підтримки ValidatingAdmissionPolicy для використання валідації CEL у контролі допуску.

  • VolumeAttributesClass: Вмикання підтримки класів VolumeAttributesClasses. Докладні відомості див. у статті Класи атрибутів томів.

  • VolumeCapacityPriority: Вмикання підтримки пріоритезації вузлів у різних топологіях на основі доступної місткості PV.

  • WatchBookmark: Вмикає підтримку подій закладок для спостереження.

  • WatchCacheInitializationPostStartHook: Вмикає post-start-hook для ініціалізації watchcache як частину readyz (з таймаутом).

  • WatchFromStorageWithoutResourceVersion: Дозволяє watch без resourceVersion працювати зі сховища.

  • WatchList: Вмикання підтримки потокового передавання початкового стану обʼєктів у запитах на спостереження.

  • WindowsHostNetwork: Вмикає підтримку приєднання контейнерів Windows до мережевого простору імен хостів.

  • WinDSR: Дозволяє kube-proxy створювати DSR-балансувальники навантаження для Windows.

  • WinOverlay: Дозволяє kube-proxy працювати в режимі оверлею для Windows.

  • ZeroLimitedNominalConcurrencyShares: Дозволити priority & fairness на сервері API використовувати нульове значення для поля nominalConcurrencyShares секції limited рівня пріоритету.

Що далі

  • У Політиці застарівання Kubernetes пояснюється підхід проєкту до видалення функцій та компонентів.
  • Починаючи з Kubernetes 1.24, нові бета-версії API стандартно не увімкнені. При увімкненні бета-версії вам також потрібно буде увімкнути всі повʼязані з цим API ресурси. Наприклад, щоб увімкнути певний ресурс, наприклад storage.k8s.io/v1beta1/csistoragecapacities, встановіть --runtime-config=storage.k8s.io/v1beta1/csistoragecapacities. Докладнішу інформацію про прапорці командного рядка наведено в Версіювання API.

6.12.2 - Функціональні можливості (вилучені)

Ця сторінка містить список функціональних можливостей воріт, які були видалені. Інформація на цій сторінці є довідковою. Вилучені функціональні можливості відрізняються від GA або застарілих тим, що вилучені функціональні можливості більше не розпізнається як дійсний функціональний елемент. Однак, GA'ed або застарілі функціональні ворота все ще розпізнаються відповідними компонентами Kubernetes, хоча вони не можуть спричинити жодних відмінностей у поведінці кластера.

Для отримання інформації про функціональні можливості, які все ще розпізнаються компонентами Kubernetes, зверніться до Таблиці функціональних можливостей Alpha/Beta або Таблиці функціональних можливостей Graduated/Deprecated.

Вилучені функціональні можливості

В наступній таблиці:

  • У стовпчику "З" вказано реліз Kubernetes, у якому зʼявилася функція або змінено стадію її випуску.
  • Стовпець "До", якщо він не порожній, містить останній випуск Kubernetes, у якому ви все ще можете використовувати функціональні можливості. Якщо стадія функції "Deprecated" або "GA", стовпець "До" вказує на випуск Kubernetes, з якого функцію було вилучено.
Feature Gates Removed
ВластивістьСтандартноСтадіяЗДо
AcceleratorsfalseAlpha1.61.10
AcceleratorsDeprecated1.111.11
AdvancedAuditingfalseAlpha1.71.7
AdvancedAuditingtrueBeta1.81.11
AdvancedAuditingtrueGA1.121.27
AffinityInAnnotationsfalseAlpha1.61.7
AffinityInAnnotationsDeprecated1.81.8
AllowExtTrafficLocalEndpointsfalseBeta1.41.6
AllowExtTrafficLocalEndpointstrueGA1.71.9
AllowInsecureBackendProxytrueBeta1.171.20
AllowInsecureBackendProxytrueGA1.211.25
APISelfSubjectReviewfalseAlpha1.261.26
APISelfSubjectReviewtrueBeta1.271.27
APISelfSubjectReviewtrueGA1.281.29
AttachVolumeLimitfalseAlpha1.111.11
AttachVolumeLimittrueBeta1.121.16
AttachVolumeLimittrueGA1.171.21
BalanceAttachedNodeVolumesfalseAlpha1.111.21
BalanceAttachedNodeVolumesfalseDeprecated1.221.22
BlockVolumefalseAlpha1.91.12
BlockVolumetrueBeta1.131.17
BlockVolumetrueGA1.181.21
BoundServiceAccountTokenVolumefalseAlpha1.131.20
BoundServiceAccountTokenVolumetrueBeta1.211.21
BoundServiceAccountTokenVolumetrueGA1.221.23
ConfigurableFSGroupPolicyfalseAlpha1.181.19
ConfigurableFSGroupPolicytrueBeta1.201.22
ConfigurableFSGroupPolicytrueGA1.231.25
ConsistentHTTPGetHandlerstrueGA1.251.30
ControllerManagerLeaderMigrationfalseAlpha1.211.21
ControllerManagerLeaderMigrationtrueBeta1.221.23
ControllerManagerLeaderMigrationtrueGA1.241.26
CRIContainerLogRotationfalseAlpha1.101.10
CRIContainerLogRotationtrueBeta1.111.20
CRIContainerLogRotationtrueGA1.211.22
CronJobControllerV2falseAlpha1.201.20
CronJobControllerV2trueBeta1.211.21
CronJobControllerV2trueGA1.221.23
CronJobTimeZonefalseAlpha1.241.24
CronJobTimeZonetrueBeta1.251.26
CronJobTimeZonetrueGA1.271.28
CSIBlockVolumefalseAlpha1.111.13
CSIBlockVolumetrueBeta1.141.17
CSIBlockVolumetrueGA1.181.21
CSIDriverRegistryfalseAlpha1.121.13
CSIDriverRegistrytrueBeta1.141.17
CSIDriverRegistrytrueGA1.181.21
CSIInlineVolumefalseAlpha1.151.15
CSIInlineVolumetrueBeta1.161.24
CSIInlineVolumetrueGA1.251.26
CSIMigrationfalseAlpha1.141.16
CSIMigrationtrueBeta1.171.24
CSIMigrationtrueGA1.251.26
CSIMigrationAWSfalseAlpha1.141.16
CSIMigrationAWSfalseBeta1.171.22
CSIMigrationAWStrueBeta1.231.24
CSIMigrationAWStrueGA1.251.26
CSIMigrationAWSCompletefalseAlpha1.171.20
CSIMigrationAWSCompleteDeprecated1.211.21
CSIMigrationAzureDiskfalseAlpha1.151.18
CSIMigrationAzureDiskfalseBeta1.191.22
CSIMigrationAzureDisktrueBeta1.231.23
CSIMigrationAzureDisktrueGA1.241.26
CSIMigrationAzureDiskCompletefalseAlpha1.171.20
CSIMigrationAzureDiskCompleteDeprecated1.211.21
CSIMigrationAzureFilefalseAlpha1.151.20
CSIMigrationAzureFilefalseBeta1.211.23
CSIMigrationAzureFiletrueBeta1.241.25
CSIMigrationAzureFiletrueGA1.261.29
CSIMigrationAzureFileCompletefalseAlpha1.171.20
CSIMigrationAzureFileCompleteDeprecated1.211.21
CSIMigrationGCEfalseAlpha1.141.16
CSIMigrationGCEfalseBeta1.171.22
CSIMigrationGCEtrueBeta1.231.24
CSIMigrationGCEtrueGA1.251.27
CSIMigrationGCECompletefalseAlpha1.171.20
CSIMigrationGCECompleteDeprecated1.211.21
CSIMigrationOpenStackfalseAlpha1.141.17
CSIMigrationOpenStacktrueBeta1.181.23
CSIMigrationOpenStacktrueGA1.241.25
CSIMigrationOpenStackCompletefalseAlpha1.171.20
CSIMigrationOpenStackCompleteDeprecated1.211.21
CSIMigrationvSpherefalseAlpha1.181.18
CSIMigrationvSpherefalseBeta1.191.24
CSIMigrationvSpheretrueBeta1.251.25
CSIMigrationvSpheretrueGA1.261.28
CSIMigrationvSphereCompletefalseBeta1.191.21
CSIMigrationvSphereCompleteDeprecated1.221.22
CSINodeExpandSecretfalseAlpha1.251.26
CSINodeExpandSecrettrueBeta1.271.28
CSINodeExpandSecrettrueGA1.291.30
CSINodeInfofalseAlpha1.121.13
CSINodeInfotrueBeta1.141.16
CSINodeInfotrueGA1.171.22
CSIPersistentVolumefalseAlpha1.91.9
CSIPersistentVolumetrueBeta1.101.12
CSIPersistentVolumetrueGA1.131.16
CSIServiceAccountTokenfalseAlpha1.201.20
CSIServiceAccountTokentrueBeta1.211.21
CSIServiceAccountTokentrueGA1.221.24
CSIStorageCapacityfalseAlpha1.191.20
CSIStorageCapacitytrueBeta1.211.23
CSIStorageCapacitytrueGA1.241.27
CSIVolumeFSGroupPolicyfalseAlpha1.191.19
CSIVolumeFSGroupPolicytrueBeta1.201.22
CSIVolumeFSGroupPolicytrueGA1.231.25
CSRDurationtrueBeta1.221.23
CSRDurationtrueGA1.241.25
CustomPodDNSfalseAlpha1.91.9
CustomPodDNStrueBeta1.101.13
CustomPodDNStrueGA1.141.16
CustomResourceDefaultingfalseAlpha1.151.15
CustomResourceDefaultingtrueBeta1.161.16
CustomResourceDefaultingtrueGA1.171.18
CustomResourcePublishOpenAPIfalseAlpha1.141.14
CustomResourcePublishOpenAPItrueBeta1.151.15
CustomResourcePublishOpenAPItrueGA1.161.18
CustomResourceSubresourcesfalseAlpha1.101.10
CustomResourceSubresourcestrueBeta1.111.15
CustomResourceSubresourcestrueGA1.161.18
CustomResourceValidationfalseAlpha1.81.8
CustomResourceValidationtrueBeta1.91.15
CustomResourceValidationtrueGA1.161.18
CustomResourceValidationExpressionsfalseAlpha1.231.24
CustomResourceValidationExpressionstrueBeta1.251.28
CustomResourceValidationExpressionstrueGA1.291.30
CustomResourceWebhookConversionfalseAlpha1.131.14
CustomResourceWebhookConversiontrueBeta1.151.15
CustomResourceWebhookConversiontrueGA1.161.18
DaemonSetUpdateSurgefalseAlpha1.211.21
DaemonSetUpdateSurgetrueBeta1.221.24
DaemonSetUpdateSurgetrueGA1.251.28
DefaultPodTopologySpreadfalseAlpha1.191.19
DefaultPodTopologySpreadtrueBeta1.201.23
DefaultPodTopologySpreadtrueGA1.241.25
DelegateFSGroupToCSIDriverfalseAlpha1.221.22
DelegateFSGroupToCSIDrivertrueBeta1.231.25
DelegateFSGroupToCSIDrivertrueGA1.261.27
DevicePluginsfalseAlpha1.81.9
DevicePluginstrueBeta1.101.25
DevicePluginstrueGA1.261.27
DisableAcceleratorUsageMetricsfalseAlpha1.191.19
DisableAcceleratorUsageMetricstrueBeta1.201.24
DisableAcceleratorUsageMetricstrueGA1.251.27
DownwardAPIHugePagesfalseAlpha1.201.20
DownwardAPIHugePagesfalseBeta1.211.21
DownwardAPIHugePagestrueBeta1.221.26
DownwardAPIHugePagestrueGA1.271.28
DryRunfalseAlpha1.121.12
DryRuntrueBeta1.131.18
DryRuntrueGA1.191.27
DynamicAuditingfalseAlpha1.131.18
DynamicAuditingDeprecated1.191.19
DynamicKubeletConfigfalseAlpha1.41.10
DynamicKubeletConfigtrueBeta1.111.21
DynamicKubeletConfigfalseDeprecated1.221.25
DynamicProvisioningSchedulingfalseAlpha1.111.11
DynamicProvisioningSchedulingDeprecated1.12
DynamicVolumeProvisioningtrueAlpha1.31.7
DynamicVolumeProvisioningtrueGA1.81.12
EnableAggregatedDiscoveryTimeouttrueDeprecated1.161.17
EnableEquivalenceClassCachefalseAlpha1.81.12
EnableEquivalenceClassCacheDeprecated1.131.23
EndpointSlicefalseAlpha1.161.16
EndpointSlicefalseBeta1.171.17
EndpointSlicetrueBeta1.181.20
EndpointSlicetrueGA1.211.24
EndpointSliceNodeNamefalseAlpha1.201.20
EndpointSliceNodeNametrueGA1.211.24
EndpointSliceProxyingfalseAlpha1.181.18
EndpointSliceProxyingtrueBeta1.191.21
EndpointSliceProxyingtrueGA1.221.24
EndpointSliceTerminatingConditionfalseAlpha1.201.21
EndpointSliceTerminatingConditiontrueBeta1.221.25
EndpointSliceTerminatingConditiontrueGA1.261.27
EphemeralContainersfalseAlpha1.161.22
EphemeralContainerstrueBeta1.231.24
EphemeralContainerstrueGA1.251.26
EvenPodsSpreadfalseAlpha1.161.17
EvenPodsSpreadtrueBeta1.181.18
EvenPodsSpreadtrueGA1.191.21
ExpandCSIVolumesfalseAlpha1.141.15
ExpandCSIVolumestrueBeta1.161.23
ExpandCSIVolumestrueGA1.241.26
ExpandedDNSConfigfalseAlpha1.221.25
ExpandedDNSConfigtrueBeta1.261.27
ExpandedDNSConfigtrueGA1.281.29
ExpandInUsePersistentVolumesfalseAlpha1.111.14
ExpandInUsePersistentVolumestrueBeta1.151.23
ExpandInUsePersistentVolumestrueGA1.241.26
ExpandPersistentVolumesfalseAlpha1.81.10
ExpandPersistentVolumestrueBeta1.111.23
ExpandPersistentVolumestrueGA1.241.26
ExperimentalCriticalPodAnnotationfalseAlpha1.51.12
ExperimentalCriticalPodAnnotationfalseDeprecated1.131.16
ExperimentalHostUserNamespaceDefaultingfalseBeta1.51.27
ExperimentalHostUserNamespaceDefaultingfalseDeprecated1.281.29
ExternalPolicyForExternalIPtrueGA1.181.22
GCERegionalPersistentDisktrueBeta1.101.12
GCERegionalPersistentDisktrueGA1.131.16
GenericEphemeralVolumefalseAlpha1.191.20
GenericEphemeralVolumetrueBeta1.211.22
GenericEphemeralVolumetrueGA1.231.24
GRPCContainerProbefalseAlpha1.231.23
GRPCContainerProbetrueBeta1.241.26
GRPCContainerProbetrueGA1.271.28
HugePagesfalseAlpha1.81.9
HugePagestrueBeta1.101.13
HugePagestrueGA1.141.16
HugePageStorageMediumSizefalseAlpha1.181.18
HugePageStorageMediumSizetrueBeta1.191.21
HugePageStorageMediumSizetrueGA1.221.24
HyperVContainerfalseAlpha1.101.19
HyperVContainerfalseDeprecated1.201.20
IdentifyPodOSfalseAlpha1.231.23
IdentifyPodOStrueBeta1.241.24
IdentifyPodOStrueGA1.251.26
ImmutableEphemeralVolumesfalseAlpha1.181.18
ImmutableEphemeralVolumestrueBeta1.191.20
ImmutableEphemeralVolumestrueGA1.211.24
IndexedJobfalseAlpha1.211.21
IndexedJobtrueBeta1.221.23
IndexedJobtrueGA1.241.25
IngressClassNamespacedParamsfalseAlpha1.211.21
IngressClassNamespacedParamstrueBeta1.221.22
IngressClassNamespacedParamstrueGA1.231.24
InitializersfalseAlpha1.71.13
InitializersDeprecated1.141.14
InTreePluginAWSUnregisterfalseAlpha1.211.30
InTreePluginAzureDiskUnregisterfalseAlpha1.211.30
InTreePluginAzureFileUnregisterfalseAlpha1.211.30
InTreePluginGCEUnregisterfalseAlpha1.211.30
InTreePluginOpenStackUnregisterfalseAlpha1.211.30
InTreePluginvSphereUnregisterfalseAlpha1.211.30
IPTablesOwnershipCleanupfalseAlpha1.251.26
IPTablesOwnershipCleanuptrueBeta1.271.27
IPTablesOwnershipCleanuptrueGA1.281.29
IPv6DualStackfalseAlpha1.151.20
IPv6DualStacktrueBeta1.211.22
IPv6DualStacktrueGA1.231.24
JobMutableNodeSchedulingDirectivestrueBeta1.231.26
JobMutableNodeSchedulingDirectivestrueGA1.271.28
JobTrackingWithFinalizersfalseAlpha1.221.22
JobTrackingWithFinalizersfalseBeta1.231.24
JobTrackingWithFinalizerstrueBeta1.251.25
JobTrackingWithFinalizerstrueGA1.261.28
KubeletConfigFilefalseAlpha1.81.9
KubeletConfigFileDeprecated1.101.10
KubeletCredentialProvidersfalseAlpha1.201.23
KubeletCredentialProviderstrueBeta1.241.25
KubeletCredentialProviderstrueGA1.261.28
KubeletPluginsWatcherfalseAlpha1.111.11
KubeletPluginsWatchertrueBeta1.121.12
KubeletPluginsWatchertrueGA1.131.16
KubeletPodResourcesfalseAlpha1.131.14
KubeletPodResourcestrueBeta1.151.27
KubeletPodResourcestrueGA1.281.29
KubeletPodResourcesGetAllocatablefalseAlpha1.211.22
KubeletPodResourcesGetAllocatabletrueBeta1.231.27
KubeletPodResourcesGetAllocatabletrueGA1.281.29
LegacyNodeRoleBehaviorfalseAlpha1.161.18
LegacyNodeRoleBehaviortrueBeta1.191.20
LegacyNodeRoleBehaviorfalseGA1.211.22
LegacyServiceAccountTokenNoAutoGenerationtrueBeta1.241.25
LegacyServiceAccountTokenNoAutoGenerationtrueGA1.261.28
LegacyServiceAccountTokenTrackingfalseAlpha1.261.26
LegacyServiceAccountTokenTrackingtrueBeta1.271.27
LegacyServiceAccountTokenTrackingtrueGA1.281.29
LocalStorageCapacityIsolationfalseAlpha1.71.9
LocalStorageCapacityIsolationtrueBeta1.101.24
LocalStorageCapacityIsolationtrueGA1.251.26
MinimizeIPTablesRestorefalseAlpha1.261.26
MinimizeIPTablesRestoretrueBeta1.271.27
MinimizeIPTablesRestoretrueGA1.281.29
MixedProtocolLBServicefalseAlpha1.201.23
MixedProtocolLBServicetrueBeta1.241.25
MixedProtocolLBServicetrueGA1.261.27
MountContainersfalseAlpha1.91.16
MountContainersfalseDeprecated1.171.17
MountPropagationfalseAlpha1.81.9
MountPropagationtrueBeta1.101.11
MountPropagationtrueGA1.121.14
MultiCIDRRangeAllocatorfalseAlpha1.251.28
NamespaceDefaultLabelNametrueBeta1.211.21
NamespaceDefaultLabelNametrueGA1.221.23
NetworkPolicyEndPortfalseAlpha1.211.21
NetworkPolicyEndPorttrueBeta1.221.24
NetworkPolicyEndPorttrueGA1.251.26
NetworkPolicyStatusfalseAlpha1.241.27
NodeDisruptionExclusionfalseAlpha1.161.18
NodeDisruptionExclusiontrueBeta1.191.20
NodeDisruptionExclusiontrueGA1.211.22
NodeLeasefalseAlpha1.121.13
NodeLeasetrueBeta1.141.16
NodeLeasetrueGA1.171.23
NonPreemptingPriorityfalseAlpha1.151.18
NonPreemptingPrioritytrueBeta1.191.23
NonPreemptingPrioritytrueGA1.241.25
OpenAPIV3falseAlpha1.231.23
OpenAPIV3trueBeta1.241.26
OpenAPIV3trueGA1.271.28
PersistentLocalVolumesfalseAlpha1.71.9
PersistentLocalVolumestrueBeta1.101.13
PersistentLocalVolumestrueGA1.141.16
PodAffinityNamespaceSelectorfalseAlpha1.211.21
PodAffinityNamespaceSelectortrueBeta1.221.23
PodAffinityNamespaceSelectortrueGA1.241.25
PodDisruptionBudgetfalseAlpha1.31.4
PodDisruptionBudgettrueBeta1.51.20
PodDisruptionBudgettrueGA1.211.25
PodHasNetworkConditionfalseAlpha1.251.27
PodOverheadfalseAlpha1.161.17
PodOverheadtrueBeta1.181.23
PodOverheadtrueGA1.241.25
PodPriorityfalseAlpha1.81.10
PodPrioritytrueBeta1.111.13
PodPrioritytrueGA1.141.18
PodReadinessGatesfalseAlpha1.111.11
PodReadinessGatestrueBeta1.121.13
PodReadinessGatestrueGA1.141.16
PodSecurityfalseAlpha1.221.22
PodSecuritytrueBeta1.231.24
PodSecuritytrueGA1.251.27
PodShareProcessNamespacefalseAlpha1.101.11
PodShareProcessNamespacetrueBeta1.121.16
PodShareProcessNamespacetrueGA1.171.19
PreferNominatedNodefalseAlpha1.211.21
PreferNominatedNodetrueBeta1.221.23
PreferNominatedNodetrueGA1.241.25
ProbeTerminationGracePeriodfalseAlpha1.211.21
ProbeTerminationGracePeriodfalseBeta1.221.24
ProbeTerminationGracePeriodtrueBeta1.251.27
ProbeTerminationGracePeriodtrueGA1.281.28
ProxyTerminatingEndpointsfalseAlpha1.221.25
ProxyTerminatingEndpointstrueBeta1.261.27
ProxyTerminatingEndpointstrueGA1.281.29
PVCProtectionfalseAlpha1.91.9
PVCProtectionDeprecated1.101.10
ReadOnlyAPIDataVolumestrueBeta1.81.9
ReadOnlyAPIDataVolumesGA1.101.10
ReadWriteOncePodfalseAlpha1.221.26
ReadWriteOncePodtrueBeta1.271.28
ReadWriteOncePodtrueGA1.291.30
RemoveSelfLinkfalseAlpha1.161.19
RemoveSelfLinktrueBeta1.201.23
RemoveSelfLinktrueGA1.241.29
RequestManagementfalseAlpha1.151.16
RequestManagementDeprecated1.171.17
ResourceLimitsPriorityFunctionfalseAlpha1.91.18
ResourceLimitsPriorityFunctionDeprecated1.191.19
ResourceQuotaScopeSelectorsfalseAlpha1.111.11
ResourceQuotaScopeSelectorstrueBeta1.121.16
ResourceQuotaScopeSelectorstrueGA1.171.18
RetroactiveDefaultStorageClassfalseAlpha1.251.25
RetroactiveDefaultStorageClasstrueBeta1.261.27
RetroactiveDefaultStorageClasstrueGA1.281.28
RootCAConfigMapfalseAlpha1.131.19
RootCAConfigMaptrueBeta1.201.20
RootCAConfigMaptrueGA1.211.22
RotateKubeletClientCertificatetrueBeta1.81.18
RotateKubeletClientCertificatetrueGA1.191.21
RunAsGrouptrueBeta1.141.20
RunAsGrouptrueGA1.211.22
RuntimeClassfalseAlpha1.121.13
RuntimeClasstrueBeta1.141.19
RuntimeClasstrueGA1.201.24
ScheduleDaemonSetPodsfalseAlpha1.111.11
ScheduleDaemonSetPodstrueBeta1.121.16
ScheduleDaemonSetPodstrueGA1.171.18
SCTPSupportfalseAlpha1.121.18
SCTPSupporttrueBeta1.191.19
SCTPSupporttrueGA1.201.22
SeccompDefaultfalseAlpha1.221.24
SeccompDefaulttrueBeta1.251.26
SeccompDefaulttrueGA1.271.28
SecurityContextDenyfalseAlpha1.271.29
SelectorIndexfalseAlpha1.181.18
SelectorIndextrueBeta1.191.19
SelectorIndextrueGA1.201.25
ServiceAccountIssuerDiscoveryfalseAlpha1.181.19
ServiceAccountIssuerDiscoverytrueBeta1.201.20
ServiceAccountIssuerDiscoverytrueGA1.211.23
ServiceAppProtocolfalseAlpha1.181.18
ServiceAppProtocoltrueBeta1.191.19
ServiceAppProtocoltrueGA1.201.22
ServiceInternalTrafficPolicyfalseAlpha1.211.21
ServiceInternalTrafficPolicytrueBeta1.221.25
ServiceInternalTrafficPolicytrueGA1.261.27
ServiceIPStaticSubrangefalseAlpha1.241.24
ServiceIPStaticSubrangetrueBeta1.251.25
ServiceIPStaticSubrangetrueGA1.261.27
ServiceLBNodePortControlfalseAlpha1.201.21
ServiceLBNodePortControltrueBeta1.221.23
ServiceLBNodePortControltrueGA1.241.25
ServiceLoadBalancerClassfalseAlpha1.211.21
ServiceLoadBalancerClasstrueBeta1.221.23
ServiceLoadBalancerClasstrueGA1.241.25
ServiceLoadBalancerFinalizerfalseAlpha1.151.15
ServiceLoadBalancerFinalizertrueBeta1.161.16
ServiceLoadBalancerFinalizertrueGA1.171.20
ServiceNodeExclusionfalseAlpha1.81.18
ServiceNodeExclusiontrueBeta1.191.20
ServiceNodeExclusiontrueGA1.211.22
ServiceNodePortStaticSubrangefalseAlpha1.271.27
ServiceNodePortStaticSubrangetrueBeta1.281.28
ServiceNodePortStaticSubrangetrueGA1.291.30
ServiceTopologyfalseAlpha1.171.19
ServiceTopologyfalseDeprecated1.201.22
SetHostnameAsFQDNfalseAlpha1.191.19
SetHostnameAsFQDNtrueBeta1.201.21
SetHostnameAsFQDNtrueGA1.221.24
StartupProbefalseAlpha1.161.17
StartupProbetrueBeta1.181.19
StartupProbetrueGA1.201.23
StatefulSetMinReadySecondsfalseAlpha1.221.22
StatefulSetMinReadySecondstrueBeta1.231.24
StatefulSetMinReadySecondstrueGA1.251.26
StorageObjectInUseProtectiontrueBeta1.101.10
StorageObjectInUseProtectiontrueGA1.111.24
StreamingProxyRedirectsfalseBeta1.51.5
StreamingProxyRedirectstrueBeta1.61.17
StreamingProxyRedirectstrueDeprecated1.181.21
StreamingProxyRedirectsfalseDeprecated1.221.24
SupportIPVSProxyModefalseAlpha1.81.8
SupportIPVSProxyModefalseBeta1.91.9
SupportIPVSProxyModetrueBeta1.101.10
SupportIPVSProxyModetrueGA1.111.20
SupportNodePidsLimitfalseAlpha1.141.14
SupportNodePidsLimittrueBeta1.151.19
SupportNodePidsLimittrueGA1.201.23
SupportPodPidsLimitfalseAlpha1.101.13
SupportPodPidsLimittrueBeta1.141.19
SupportPodPidsLimittrueGA1.201.23
SuspendJobfalseAlpha1.211.21
SuspendJobtrueBeta1.221.23
SuspendJobtrueGA1.241.25
SysctlstrueBeta1.111.20
SysctlstrueGA1.211.22
TaintBasedEvictionsfalseAlpha1.61.12
TaintBasedEvictionstrueBeta1.131.17
TaintBasedEvictionstrueGA1.181.20
TaintNodesByConditionfalseAlpha1.81.11
TaintNodesByConditiontrueBeta1.121.16
TaintNodesByConditiontrueGA1.171.18
TokenRequestfalseAlpha1.101.11
TokenRequesttrueBeta1.121.19
TokenRequesttrueGA1.201.21
TokenRequestProjectionfalseAlpha1.111.11
TokenRequestProjectiontrueBeta1.121.19
TokenRequestProjectiontrueGA1.201.21
TopologyManagerfalseAlpha1.161.17
TopologyManagertrueBeta1.181.26
TopologyManagertrueGA1.271.28
TTLAfterFinishedfalseAlpha1.121.20
TTLAfterFinishedtrueBeta1.211.22
TTLAfterFinishedtrueGA1.231.24
UserNamespacesStatelessPodsSupportfalseAlpha1.251.27
ValidateProxyRedirectsfalseAlpha1.121.13
ValidateProxyRedirectstrueBeta1.141.21
ValidateProxyRedirectstrueDeprecated1.221.24
VolumePVCDataSourcefalseAlpha1.151.15
VolumePVCDataSourcetrueBeta1.161.17
VolumePVCDataSourcetrueGA1.181.21
VolumeSchedulingfalseAlpha1.91.9
VolumeSchedulingtrueBeta1.101.12
VolumeSchedulingtrueGA1.131.16
VolumeSnapshotDataSourcefalseAlpha1.121.16
VolumeSnapshotDataSourcetrueBeta1.171.19
VolumeSnapshotDataSourcetrueGA1.201.22
VolumeSubpathtrueGA1.101.24
VolumeSubpathEnvExpansionfalseAlpha1.141.14
VolumeSubpathEnvExpansiontrueBeta1.151.16
VolumeSubpathEnvExpansiontrueGA1.171.24
WarningHeaderstrueBeta1.191.21
WarningHeaderstrueGA1.221.24
WindowsEndpointSliceProxyingfalseAlpha1.191.20
WindowsEndpointSliceProxyingtrueBeta1.211.21
WindowsEndpointSliceProxyingtrueGA1.221.24
WindowsGMSAfalseAlpha1.141.15
WindowsGMSAtrueBeta1.161.17
WindowsGMSAtrueGA1.181.20
WindowsHostProcessContainersfalseAlpha1.221.22
WindowsHostProcessContainerstrueBeta1.231.25
WindowsHostProcessContainerstrueGA1.261.27
WindowsRunAsUserNamefalseAlpha1.161.16
WindowsRunAsUserNametrueBeta1.171.17
WindowsRunAsUserNametrueGA1.181.20

Опис вилучених функціональних можливостей

  • Accelerators: Надавав ранню форму втулка для ввімкнення підтримки графічного процесора Nvidia під час використання Docker Engine; більше не доступний. Див. Втулки пристроїв для альтернатив.

  • AdvancedAuditing: Вмикає розширений аудит

  • AffinityInAnnotations: Вмикає встановлення Спорідненість та антиспорідненість Podʼів.

  • AllowExtTrafficLocalEndpoints: Вмикає сервіс для маршрутизації зовнішніх запитів до локальних точок доступу вузла.

  • AllowInsecureBackendProxy: Дозволяє користувачам пропускати перевірку TLS для kubelet на запитах до логів Pod.

  • APISelfSubjectReview: Вмикає API SelfSubjectReview, який дозволяє користувачам бачити автентифікаційну інформацію субʼєкта запиту. Дивіться API доступу до автентифікаційної інформації для клієнта для більш детальної інформації.

  • AttachVolumeLimit: Вмикає втулки томів, щоб повідомляти про обмеження на кількість томів які може бути приєднано до вузла. Див. розділ динамічні обмеження тому для детальнішої інформації.

  • BalanceAttachedNodeVolumes: Включити підрахунок volume на вузлі, який слід враховувати для збалансованого розподілу ресурсів при плануванні. Вузлу, який має ближче завантаження процесора, завантаження памʼяті та кількість томів, віддається перевага при прийнятті рішень планувальником.

  • BlockVolume: Увімкніть визначення та споживання необроблених блокових пристроїв у Podʼах. Див. статтю Підтримка необроблених блокових томів для більш детальної інформації.

  • BoundServiceAccountTokenVolume:

    Переносить томи ServiceAccount для використання спроєцьованого тому, що складається з ServiceAccountTokenVolumeProjection. Адміністратори кластера можуть використовувати метрику serviceaccount_stale_tokens_total для моніторингу робочих навантажень, які залежать від розширених токенів. Якщо таких навантажень немає, вимкніть розширені токени, запустивши kube-apiserver з прапорцем --service-account-extend-token-expiration=false.

    Ознайомтеся зі статтею Привʼязані токени службових облікових записів для більш детальної інформації.

  • ConfigurableFSGroupPolicy: Дозволяє користувачеві налаштувати політику зміни дозволів на томи для fsGroups під час монтування тому в Pod. Див. Налаштування політики зміни дозволів на томи та права власності для Podʼів для більш детальної інформації.

  • ConsistentHTTPGetHandlers: Нормалізувати передачу URL-адреси та заголовка HTTP-запиту для життєвого циклу обробників з пробами.

  • ControllerManagerLeaderMigration: Вмикає міграцію лідерів для kube-controller-manager та cloud-controller-manager що дозволяє оператору кластера в реальному часі мігрувати контролери з kube-controller-manager у зовнішній контролер-менеджер (наприклад, cloud-controller-manager) у кластері HA без простоїв.

  • CRIContainerLogRotation: Вмикає ротацію логів контейнера для середовища виконання контейнерів CRI. Стандартний максимальний розмір файлу логу становить 10 МБ, а максимальна кількість файлів логу для контейнера — 5. Ці значення можна налаштувати у конфігурації kubelet. Див. статтю ведення логів на рівні вузла для більш детальної інформації.

  • CronJobControllerV2: Використовуйте альтернативну реалізацію контролера CronJob. В іншому випадку буде обрано версію 1 цього ж контролера.

  • CronJobTimeZone: Дозволити використання необовʼязкового поля timeZone у CronJobs

  • CSIBlockVolume: Вмикає підтримку блочного сховища зовнішніми драйверами томів CSI. Див. статтю Підтримка CSI для блочних томів для детальнішої інформації.

  • CSIDriverRegistry: Вмикає всю логіку, повʼязану з обʼєктом CSIDriver API в csi.storage.k8s.io.

  • CSIInlineVolume: Увімкніть підтримку томів CSI Inline для Podʼів.

  • CSIMigration: Вмикає shimʼи та логіку передачі для маршрутизації операцій тому з вбудованого втулка до втулка CSI.

  • CSIMigrationAWS: Вмикає shimʼи та логіку передачі для маршрутизації операцій тому з вбудованого втулка AWS-EBS до втулка EBS CSI. Підтримує відновлення до втулка EBS для операцій монтування на вузлах, на яких функція вимкнена або на яких втулок EBS CSI не встановлено та не налаштовано. Не підтримує відновлення для операцій надання, для них втулок CSI повинен бути встановлений та налаштований.

  • CSIMigrationAWSComplete: Припиняє реєстрування вбудованих втулків EBS в kubelet та контролерах томів та вмикає shimʼи та логіку перекладу для маршрутизації операцій з томами від вбудованого втулка EBS AWS до втулка EBS CSI. Вимагає ввімкнених прапорців CSIMigration та CSIMigrationAWS та встановленого та налаштованого втулка EBS CSI на всіх вузлах кластера. Цей прапорець було відзначено як застарілий на користь прапорця InTreePluginAWSUnregister, який перешкоджає реєстрації вбудованого втулка EBS.

  • CSIMigrationAzureDisk: Вмикає shimʼи та логіку передачі для маршрутизації операцій тому з вбудованого втулка Azure-Disk до втулка AzureDisk CSI. Підтримує відновлення до втулка AzureDisk для операцій монтування на вузлах, на яких функція вимкнена або на яких втулок AzureDisk CSI не встановлено та не налаштовано. Не підтримує відновлення для операцій надання, для них втулок CSI повинен бути встановлений та налаштований. Вимагає увімкнення прапорця функції CSIMigration.

  • CSIMigrationAzureDiskComplete: Припиняє реєстрування вбудованих втулків Azure-Disk в kubelet та контролерах томів та вмикає shimʼи та логіку перекладу для маршрутизації операцій з томами від вбудованого втулка Azure-Disk до втулка AzureDisk CSI. Вимагає ввімкнених прапорців CSIMigration та CSIMigrationAzureDisk та встановленого та налаштованого втулка AzureDisk CSI на всіх вузлах кластера. Цей прапорець було відзначено як застарілий на користь прапорця InTreePluginAzureDiskUnregister, який перешкоджає реєстрації вбудованого втулка AzureDisk.

  • CSIMigrationAzureFile: Вмикає shimʼи та логіку передачі для маршрутизації операцій тому з вбудованого втулка Azure-File до втулка AzureFile CSI. Підтримує відновлення до втулка AzureFile для операцій монтування на вузлах, на яких функція вимкнена або на яких втулок AzureFile CSI не встановлено та не налаштовано. Не підтримує відновлення для операцій надання, для них втулок CSI повинен бути встановлений та налаштований. Вимагає увімкнення прапорця функції CSIMigration.

  • CSIMigrationAzureFileComplete: Припиняє реєстрування вбудованих втулків Azure-File в kubelet та контролерах томів та вмикає shimʼи та логіку перекладу для маршрутизації операцій з томами від вбудованого втулка Azure-File до втулка AzureFile CSI. Вимагає ввімкнених прапорців CSIMigration та CSIMigrationAzureFile та встановленого та налаштованого втулка AzureFile CSI на всіх вузлах кластера. Цей прапорець було відзначено як застарілий на користь прапорця InTreePluginAzureFileUnregister, який перешкоджає реєстрації вбудованого втулка AzureFile.

  • CSIMigrationGCE: Вмикає shimʼи та логіку передачі для маршрутизації операцій тому з вбудованого втулка GCE-PD до втулка PD CSI. Підтримує відновлення до втулка PD для операцій монтування на вузлах, на яких функція вимкнена або на яких втулок PD CSI не встановлено та не налаштовано. Не підтримує відновлення для операцій надання, для них втулок CSI повинен бути встановлений та налаштований. Вимагає увімкнення прапорця функції CSIMigration.

  • CSIMigrationGCEComplete: Припиняє реєстрування вбудованих втулків GCE-PD в kubelet та контролерах томів та вмикає shimʼи та логіку перекладу для маршрутизації операцій з томами від вбудованого втулка GCE-PD до втулка GCE-PD CSI. Вимагає ввімкнених прапорців CSIMigration та CSIMigrationGCE та встановленого та налаштованого втулка GCE-PD CSI на всіх вузлах кластера. Цей прапорець було відзначено як застарілий на користь прапорця InTreePluginGCEUnregister, який перешкоджає реєстрації вбудованого втулка GCE-PD.

  • CSIMigrationOpenStack: Вмикає shimʼи та логіку передачі для маршрутизації операцій тому з вбудованого втулка Cinder до втулка Cinder CSI. Підтримує відновлення до втулка Cinder для операцій монтування на вузлах, на яких функція вимкнена або на яких втулок Cinder CSI не встановлено та не налаштовано. Не підтримує відновлення для операцій надання, для них втулок CSI повинен бути встановлений та налаштований. Вимагає увімкнення прапорця функції CSIMigration.

  • CSIMigrationOpenStackComplete: Припиняє реєстрування вбудованих втулків Cinder в kubelet та контролерах томів та вмикає shimʼи та логіку перекладу для маршрутизації операцій з томами від вбудованого втулка Cinder до втулка Cinder CSI. Вимагає ввімкнених прапорців CSIMigration та CSIMigrationOpenStack та встановленого та налаштованого втулка Cinder CSI на всіх вузлах кластера. Цей прапорець було відзначено як застарілий на користь прапорця InTreePluginOpenStackUnregister, який перешкоджає реєстрації вбудованого втулка Cinder OpenStack.

  • CSIMigrationvSphere: Вмикає shimʼи та логіку передачі для маршрутизації операцій тому з вбудованого втулка vSphere до втулка vSphere CSI. Підтримує відновлення до втулка vSphere для операцій монтування на вузлах, на яких функція вимкнена або на яких втулок vSphere CSI не встановлено та не налаштовано. Не підтримує відновлення для операцій надання, для них втулок CSI повинен бути встановлений та налаштований. Вимагає увімкнення прапорця функції CSIMigration.

  • CSIMigrationvSphereComplete: Припиняє реєстрацію вбудованого втулка vSphere в kubelet та контролерах томів та вмикає shimʼи та логіку перекладу для маршрутизації операцій з томами від вбудованого втулка vSphere до втулка vSphere CSI. Вимагає ввімкнених прапорців CSIMigration та CSIMigrationvSphere та встановленого та налаштованого втулка vSphere CSI на всіх вузлах кластера. Цей прапорець було відзначено як застарілий на користь прапорця InTreePluginvSphereUnregister, який перешкоджає реєстрації вбудованого втулка vSphere.

  • CSINodeExpandSecret: Вмикає передачу секретних даних автентифікації до втулка CSI для використання під час операції NodeExpandVolume CSI.

  • CSINodeInfo: Вмикає всю логіку, повʼязану з обʼєктом API CSINodeInfo в csi.storage.k8s.io.

  • CSIPersistentVolume: Вмикає виявлення та монтування томів, які надаються через сумісний втулок томів CSI (Container Storage Interface).

  • CSIServiceAccountToken: Дозволяє CSI-драйверам отримувати токен службового облікового запису для Podʼів, для яких вони монтували томи. Див. Запити токенів.

  • CSIStorageCapacity: Вмикає втулок CSI для публікації інформації про обсяг сховища та використання цієї інформації планувальником Kubernetes під час планування Podʼів. Див. Обсяг сховища. Для отримання додаткових відомостей див. документацію про типи томів csi.

  • CSIVolumeFSGroupPolicy: Дозволяє CSIDrivers використовувати поле fsGroupPolicy. Це поле керує тим, чи підтримують томи, створені CSIDriver, власність томів та зміни дозволів, коли ці томи монтуються.

  • CSRDuration: Дозволяє клієнтам запитувати час дії для сертифікатів, виданих через Kubernetes CSR API.

  • CustomPodDNS: Дозволяє змінювати налаштування DNS для Pod за допомогою властивості dnsConfig. Для отримання додаткової інформації див. DNS-налаштування Pod.

  • CustomResourceDefaulting: Вмикає підтримку CRD для стандартних значень в схемах перевірки OpenAPI v3.

  • CustomResourcePublishOpenAPI: Вмикає публікацію специфікацій CRD OpenAPI.

  • CustomResourceSubresources: Вмикає субресурси /status та /scale для ресурсів, створених з CustomResourceDefinition.

  • CustomResourceValidation: Вмикає перевірку на основі схеми для ресурсів, створених з CustomResourceDefinition.

  • CustomResourceValidationExpressions: Вмикає перевірку мови виразів у CRD, яка буде перевіряти власний ресурс клієнта на основі правил валідації, написаних у розширенні x-kubernetes-validations.

  • CustomResourceWebhookConversion: Вмикає конверсію на основі webhook для ресурсів, створених з CustomResourceDefinition.

  • DaemonSetUpdateSurge: Дозволяє робочим навантаженням DaemonSet зберігати доступність під час оновлення на кожному вузлі. Див. Виконання поетапного оновлення DaemonSet.

  • DefaultPodTopologySpread: Дозволяє використовувати втулок планування PodTopologySpread для виконання стандартного розподілу.

  • DelegateFSGroupToCSIDriver: Якщо підтримується драйвером CSI, делегує роль застосовуючи fsGroup з securityContext Pod до драйвера, передаючи fsGroup через виклики CSI NodeStageVolume та NodePublishVolume.

  • DevicePlugins: Вмикає device-plugins на основі виділення ресурсів на вузлах.

  • DisableAcceleratorUsageMetrics: Вимкнути метрики акселератора, що збираються kubelet.

  • DownwardAPIHugePages: Вмикає використання великих сторінок (hugepages) у downward API.

  • DryRun: Вмикає запити dry rin на боці сервера, щоб можна було тестувати валідацію, злиття та мутацію без впровадження змін.

  • DynamicAuditing: Використовувалося для увімкнення динамічного аудиту до версії 1.19.

  • DynamicKubeletConfig: Вмикає динамічну конфігурацію kubelet. Функція більше не підтримується за межами підтримуваної політики відхилення. Функціональну можливість було вилучено з kubelet у версії 1.24.

  • DynamicProvisioningScheduling: Розширює стандартний планувальник, щоб врахувати топологію тома і обробляти виділення PV. Цю функцію було замінено функцією VolumeScheduling у версії 1.12.

  • DynamicVolumeProvisioning: Вмикає динамічне виділення постійних томів для Podʼів.

  • EnableAggregatedDiscoveryTimeout: Вмикає пʼятисекундний тайм-аут для агрегованих викликів виявлення.

  • EnableEquivalenceClassCache: Дозволяє планувальнику кешувати еквівалентність вузлів при плануванні Podʼів.

  • EndpointSlice: Вмикає EndpointSlices для більш масштабованих і розширюваних мережевих точок доступу. Див. статтю Увімкнення EndpointSlices.

  • EndpointSliceNodeName: Вмикає поле EndpointSlice nodeName.

  • EndpointSliceProxying: Якщо цю опцію увімкнено, kube-proxy на Linux використовуватиме EndpointSlices як основне джерело даних замість точок доступу, що дає змогу підвищити масштабованість і продуктивність. Див. статтю Увімкнення Endpoint Slices.

  • EndpointSliceTerminatingCondition: Вмикає поля умов terminating та serving EndpointSlice.

  • EphemeralContainers: Вмикає можливість додавання ефемерних контейнерів до запущених Podʼів.

  • EvenPodsSpread: Увімкнення рівномірного планування Podʼів у всіх топологіях доменів. Див. розділ Обмеження поширення топології Podʼів.

  • ExpandCSIVolumes: Дозволяє розширення томів CSI.

  • ExpandedDNSConfig: Дозволяє використовувати kubelet і kube-apiserver, щоб отримати більше шляхів пошуку DNS і довший список шляхів пошуку DNS. Ця функція потребує підтримки середовища виконання контейнерів (Containerd: v1.5.6 або новішої версії, CRI-O: v1.22 або новішої версії). Див. статтю Розширена конфігурація DNS.

  • ExpandInUsePersistentVolumes: Дозволяє розширювати використовувані постійні томи. Див. статтю Зміна розміру PersistentVolumeClaim.

  • ExpandPersistentVolumes: Дозволяє розширювати постійні томи. Див. статтю "Розширення Persistent Volumes Claims".

  • ExperimentalCriticalPodAnnotation: Увімкнути позначення певних Podʼів як критичних, щоб гарантувати їх планування. Ця функція застаріла внаслідок використання пріоритетів та випередження для Podʼів, починаючи з версії 1.13.

  • ExperimentalHostUserNamespaceDefaulting: Дозволяє встановлення стандартного простору імен для хосту. Призначено для контейнерів, які використовують інші простори імен хосту, монтування хосту або контейнери, які мають привілеї або використовують конкретні не іменовані можливості (наприклад, MKNODE, SYS_MODULE і т. д.). Слід вмикати лише у випадку, якщо перепризначення (remapping) просторів імен користувача увімкнено в демоні Docker.

  • ExternalPolicyForExternalIP: Виправляє помилку, коли ExternalTrafficPolicy не застосовується до Service ExternalIPs.

  • GCERegionalPersistentDisk: Увімкніть регіональну функцію PD у GCE.

  • GenericEphemeralVolume: Дозволяє створювати ефемерні, вбудовані томи, які підтримують усі функції звичайних томів (можуть надаватися сторонніми постачальниками сховищ, відстеження ємності сховища, відновлення зі знімка тощо). Див. статтю Ефемерні томи.

  • GRPCContainerProbe: Вмикає метод gRPC для {Liveness,Readiness,Startup}Probe. Див. розділ Налаштування проб життєздатності, готовності та запуску.

  • HugePages: Увімкніть виділення та використання попередньо виділених величезних сторінок.

  • HugePageStorageMediumSize: Увімкніть підтримку декількох розмірів попередньо виділених величезних сторінок.

  • HyperVContainer: Вмикає ізоляцію Hyper-V для контейнерів Windows

  • IdentifyPodOS: Дозволяє вказати поле Pod OS. Це допомагає достовірно ідентифікувати операційну систему під час допуску до сервера API.

  • ImmutableEphemeralVolumes: Дозволяє позначати окремі Secrets та ConfigMaps як незмінні для кращої безпеки та продуктивності.

  • IndexedJob: Дозволяє контролеру Job керувати завершенням Pod за індексом завершення.

  • IngressClassNamespacedParams: Дозволяє посилатися на параметри в межах простору імен у ресурсі IngressClass. Ця можливість додає два поля — Scope та Namespace до IngressClass.spec.parameters.

  • Initializers: Дозволяє асинхронно координувати створення обʼєктів за допомогою втулка допуску Initializers.

  • InTreePluginAWSUnregister: Припиняє реєстрацію вбудованого втулка aws-ebs у kubelet та контролерах томів.

  • InTreePluginAzureDiskUnregister: Припиняє реєстрацію вбудованого втулка azuredisk у kubelet та контролерах томів.

  • InTreePluginAzureFileUnregister: Припиняє реєстрацію вбудованого втулка azurefile у kubelet та контролерах томів.

  • InTreePluginGCEUnregister: Припиняє реєстрацію вбудованого втулка gce-pd у kubelet та контролерах томів.

  • InTreePluginOpenStackUnregister: Припиняє реєстрацію вбудованого втулка OpenStack cinder у kubelet та контролерах томів.

  • InTreePluginvSphereUnregister: Припиняє реєстрацію вбудованого втулка vSphere у kubelet та контролерах томів.

  • IPTablesOwnershipCleanup: Це призводить до того, що kubelet більше не створює застарілі правила iptables.

  • IPv6DualStack: Вмикає підтримку подвійного стека для IPv6.

  • JobMutableNodeSchedulingDirectives: Дозволяє оновити директиви планування вузлів у шаблоні pod Job.

  • JobTrackingWithFinalizers: Дозволяє відстежувати завершення Job, не покладаючись на те, що Pods залишаться в кластері на невизначений час. Контролер Job використовує завершувачі Pod і поле у статусі Job для відстеження завершених Podʼів, щоб зарахувати їх до списку завершених.

  • KubeletConfigFile: Дозволяє завантажувати конфігурацію kubelet з файлу, вказаного за допомогою конфігураційного файлу. Докладнішу інформацію див. у статті налаштування параметрів kubelet за допомогою конфігураційного файлу.

  • KubeletCredentialProviders: Вмикає постачальників облікових даних для kubelet exec для отримання облікових даних для отримання образів.

  • KubeletPluginsWatcher: Вмикає утиліту для відстеження втулків на основі проб, щоб дозволити kubelet виявляти втулки, такі як драйвери томів CSI.

  • KubeletPodResources: Вмикає ресурси точки доступу gRPC kubelet Pod. Докладніші відомості наведено у статті Підтримка моніторингу пристроїв.

  • KubeletPodResourcesGetAllocatable: Вмикає функцію GetAllocatableResources для ресурсів pod у kubelet. Цей API доповнює звіт про розподіл ресурсів

  • LegacyNodeRoleBehavior: Якщо вимкнено, застаріла поведінка балансувальників навантаження сервісів та вимкнення вузлів ігноруватиме мітку node-role.kubernetes.io/master на користь специфічних міток, що надаються мітками NodeDisruptionExclusion та ServiceNodeExclusion.

  • LegacyServiceAccountTokenNoAutoGeneration: Припиняє автоматичне створення токенів службових облікових записів на основі Secret.

  • LegacyServiceAccountTokenTracking: Відстеження використання токенів службових облікових записів, що базуються на Secret.

  • LocalStorageCapacityIsolation: Вмикає використання локального ефемерного сховища, а також властивість sizeLimit тома emptyDir.

  • MinimizeIPTablesRestore: Вмикає нову логіку покращення продуктивності в режимі kube-proxy iptables.

  • MixedProtocolLBService: Вмикає використання різних протоколів в одному екземплярі Service типу LoadBalancer.

  • MountContainers: Вмикає використання контейнерів утиліт на хості як монтувальника томів.

  • MountPropagation: Дозволяє надавати спільний доступ до тому, змонтованого одним контейнером, іншим контейнерам або Podʼам. Докладніші відомості наведено у статті поширення монтування.

  • MultiCIDRRangeAllocator: Вмикає розподільник діапазону MultiCIDR.

  • NamespaceDefaultLabelName: Налаштуйте API Server на встановлення незмінної мітки kubernetes.io/metadata.name у всіх просторах назв, що містить назву простору назв.

  • NetworkPolicyEndPort: Дозволяє визначити порти у правилі NetworkPolicy як діапазон номерів портів.

  • NetworkPolicyStatus: Вмикає субресурс status для обʼєктів NetworkPolicy.

  • NodeDisruptionExclusion: Дозволяє використовувати мітку вузла node.kubernetes.io/exclude-disruption, яка запобігає евакуації вузлів під час збоїв у зоні.

  • NodeLease: Увімкніть новий Lease API для звітування про пульс вузла, який може бути використаний як сигнал про стан вузла.

  • NonPreemptingPriority: Вмикає поле preemptionPolicy для PriorityClass та Pod.

  • OpenAPIV3: Дозволяє серверу API публікувати OpenAPI v3.

  • PersistentLocalVolumes: Вмикає використання типу тому local у Podʼах. Якщо запитується local том, необхідно вказати спорідненість тому до Podʼів.

  • PodAffinityNamespaceSelector: Вмикає функції селектора простору імен за спорідненістю Podʼа та CrossNamespacePodAffinity діапазону квотування.

  • PodDisruptionBudget: Вмикає PodDisruptionBudget.

  • PodHasNetworkCondition: Дозволити kubelet позначати стан PodHasNetwork для контейнерів. Його було перейменовано на PodReadyToStartContainersCondition у версії 1.28.

  • PodOverhead: Вмикає PodOverhead для врахування накладних витрат на Pod.

  • PodPriority: Дозволяє випередження та зміну планування Podʼів на основі їх пріоритетів.

  • PodReadinessGates: Дозволяє увімкнути налаштування поля PodReadinessGate для розширення оцінювання готовності Pod. Дивіться Готовність Podʼа для більш детальної інформації.

  • PodSecurity: Вмикає втулок допуску PodSecurity.

  • PodShareProcessNamespace: Вмикає параметр shareProcessNamespace у Pod для спільного використання єдиного простору імен процесів між контейнерами, запущеними у Pod. Більш детальну інформацію можна знайти у статті Спільний простір імен процесів між контейнерами у Pod.

  • PreferNominatedNode: Цей прапорець вказує планувальнику, чи будуть номіновані вузли перевірятися першими перед тим, як обходити всі інші вузли кластера.

  • ProbeTerminationGracePeriod: Вмикає налаштування рівня проби terminationGracePeriodSeconds у контейнерах Pod. Дивіться пропозицію щодо вдосконалення для більш детальної інформації.

  • ProxyTerminatingEndpoints: Дозволити kube-proxy обробляти завершення точок доступу, коли ExternalTrafficPolicy=Local.

  • PVCProtection: Вмикає запобігання видаленню PersistentVolumeClaim (PVC), коли він все ще використовується яким-небудь Pod.

  • ReadOnlyAPIDataVolumes:

    Встановлює configMap, secret, downwardAPI та projected тому для монтування в режимі "тільки читання".

    Починаючи з Kubernetes v1.10, ці типи томів завжди є тільки для читання, і ви не можете відмовитися від цього.

  • ReadWriteOncePod: Дозволяє використовувати ReadWriteOncePod режим доступу до PersistentVolume.

  • RemoveSelfLink: Встановлює поле .metadata.selfLink порожнім (порожній рядок) для всіх обʼєктів і колекцій. Це поле застаріло з випуску Kubernetes v1.16. Коли цю можливість увімкнено, поле .metadata.selfLink залишається частиною API Kubernetes, але завжди не встановлене.

  • RequestManagement: Дозволяє керувати паралельністю запитів з пріоритетами та справедливістю на кожному сервері API. Замінено на APIPriorityAndFairness з 1.17.

  • ResourceLimitsPriorityFunction: Вмикає функцію пріоритету планувальника, яка присвоює найнижчу можливу оцінку 1 вузлу, який задовольняє хоча б одному з лімітів процесора та памʼяті вхідного Podʼа. Це має на меті розірвати звʼязки між вузлами з однаковими оцінками.

  • ResourceQuotaScopeSelectors: Вмикає селектори області обмежень ресурсів.

  • RetroactiveDefaultStorageClass: Дозволяє призначати StorageClass незвʼязаним постійним томам (PVC) ретроактивно.

  • RootCAConfigMap: Налаштуйте kube-controller-manager на публікацію ConfigMap з назвою kube-root-ca.crt у кожному просторі імен. Цей ConfigMap містить пакет CA, який використовується для перевірки зʼєднань з kube-apiserver. Докладні відомості наведено у статті Токени привʼязаних службових облікових записів.

  • RotateKubeletClientCertificate: Вмикає ротацію клієнтського TLS-сертифікату в kubelet. Дивіться kubelet configuration для більш детальної інформації.

  • RunAsGroup: Вмикає контроль за первинним ідентифікатором групи, встановленим у процесах ініціалізації контейнерів.

  • RuntimeClass: Вмикає RuntimeClass для вибору конфігурацій середовища виконання контейнера.

  • ScheduleDaemonSetPods: Дозволяє Podʼам DemonSet плануватися стандартним планувальником замість контролера DaemonSet.

  • SCTPSupport: Вмикає значення protocol SCTP в означеннях Pod, Service, Endpoints, EndpointSlice та NetworkPolicy.

  • SeccompDefault: Дозволяє використовувати RuntimeDefault як стандартний профіль seccomp для всіх робочих навантажень. Профіль seccomp вказується в ecurityContext Pod та/або Container.

  • SecurityContextDeny: Ця можливість сигналізує про те, що контролер допуску SecurityContextDeny є застарілим.

  • SelectorIndex: Дозволяє використовувати індекси на основі міток і полів у кеші спостереження сервера API для прискорення роботи зі списками.

  • ServiceAccountIssuerDiscovery: Вмикає точки доступу OIDC discovery (URL видачі та JWKS) для видачі службових облікових записів в API-сервері. Див. Налаштування службових облікових записів для контейнерів Pod для отримання додаткових відомостей.

  • ServiceAppProtocol: Вмикає поле appProtocol у Services та Endpoints.

  • ServiceInternalTrafficPolicy: Вмикає поле internalTrafficPolicy у Services.

  • ServiceIPStaticSubrange: Вмикає стратегію розподілу службових кластерних IP-адрес, згідно з якою діапазон ClusterIP поділяється на частини. Динамічні адреси ClusterIP призначатимуться переважно з верхнього діапазону, що дасть змогу користувачам призначати статичні адреси ClusterIP з нижнього діапазону з низьким ризиком колізій. Докладніші відомості наведено у статті Уникнення колізій.

  • ServiceLBNodePortControl: Вмикає поле allocateLoadBalancerNodePorts у Services.

  • ServiceLoadBalancerClass: Вмикає поле loadBalancerClass у Services. Див. Вказання класу реалізації балансувальника навантаження

  • ServiceLoadBalancerFinalizer: Вмикає захист завершувача для Service load balancers.

  • ServiceNodeExclusion: Дозволяє виключати вузли з балансувальників навантаження, створених хмарним постачальником. Вузол може бути виключений, якщо він має мітку "node.kubernetes.io/exclude-from-external-load-balancers".

  • ServiceNodePortStaticSubrange: Дозволяє використовувати різні стратегії розподілу портів для Сервісів NodePort. Докладні відомості наведено у статті резервування діапазонів NodePort для уникнення колізій.

  • ServiceTopology: Вмикає сервіс для маршрутизації трафіку на основі топології вузлів кластера.

  • SetHostnameAsFQDN: Дозволяє вказати повне доменне імʼя (FQDN) як імʼя хосту Podʼів. Див. розділ Поле setHostnameAsFQDN у Pod.

  • StartupProbe: Вмикає пробу запуску в kubelet.

  • StatefulSetMinReadySeconds: Дозволяє контролеру StatefulSet дотримуватися значення minReadySeconds.

  • StorageObjectInUseProtection: Відкладення видалення обʼєктів PersistentVolume або PersistentVolumeClaim, якщо вони все ще використовуються.

  • StreamingProxyRedirects: Доручає серверу API перехоплювати (і виконувати) перенаправлення від бекенда ('kubelet') для потокових запитів. Прикладами потокових запитів є запити exec, attach і port-forward.

  • SupportIPVSProxyMode: Вмикає балансування навантаження сервісів у кластері за допомогою IPVS. Докладні відомості див. у статті проксі-сервери.

  • SupportNodePidsLimit: Вмикає підтримку обмеження PID на вузлі. Параметр pid=<number> в опціях --system-reserved і --kube-reserved можна вказати, щоб гарантувати, що вказану кількість ідентифікаторів процесів буде зарезервовано для системи в цілому і для системних демонів Kubernetes відповідно.

  • SupportPodPidsLimit: Вмикання підтримки обмеження PID у Podʼах.

  • SuspendJob: Дозволяє призупиняти та поновлювати виконання Jobs. Докладнішу інформацію дивіться у документації про Job.

  • Sysctls: Вмикання підтримки параметрів ядра у просторі імен (sysctls), які можна задавати для кожного з Podʼів. Докладні відомості наведено у sysctls.

  • TaintBasedEvictions: Дозволяє виселяти Podʼи з вузлів на основі taints на вузлах і толерантностей на Podʼах. Детальніше дивіться у статті taint та tolerances.

  • TaintNodesByCondition: Дозволяє автоматичне позначення вузлів taints на основі станів вузлів.

  • TokenRequest: Вмикає точку доступу TokenRequest для ресурсів службових облікових записів.

  • TokenRequestProjection: Вмикає інʼєкцію токенів службових облікових записів у Pod через projected том.

  • TopologyManager: Вмикання механізму для координації тонких призначень апаратних ресурсів для різних компонентів у Kubernetes. Див. розділ Керування політиками керування топологією на вузлі.

  • TTLAfterFinished: Дозволити TTL-контролеру очищати ресурси після завершення їх виконання.

  • UserNamespacesStatelessPodsSupport: Увімкніть підтримку простору імен користувачів для stateless Podʼів. Ці функціональні можливості були замінені на UserNamespacesSupport у випуску Kubernetes v1.28.

  • ValidateProxyRedirects: Цей прапорець визначає, чи повинен сервер API перевіряти, що перенаправлення виконуються тільки на той самий хост. Використовується лише якщо увімкнено прапорець StreamingProxyRedirects.

  • VolumePVCDataSource: Підтримка вказівки існуючого PVC як DataSource.

  • VolumeScheduling: Вмикає планування з урахуванням топології тома і робить привʼязку PersistentVolumeClaim (PVC) обізнаною з рішеннями щодо планування. Це також дозволяє використовувати тип тома local при використанні разом з функціональною можливістю PersistentLocalVolumes.

  • VolumeSnapshotDataSource: Вмикання підтримки джерела даних для створення знімків томів.

  • VolumeSubpath: Дозволяє монтувати субшлях тому в контейнері.

  • VolumeSubpathEnvExpansion: Вмикання поля SubPathExpr для розгортання змінних оточення у SubPath.

  • WarningHeaders: Дозволяє надсилати заголовки попередження в відповідях API.

  • WindowsEndpointSliceProxying: Якщо увімкнено, kube-proxy, що працює на Windows, використовуватиме EndpointSlices як основне джерело даних замість Endpoints, що забезпечує масштабованість і покращення продуктивності. Див. статтю Увімкнення Endpoint Slices.

  • WindowsGMSA: Дозволяє передавати специфікацію облікових даних GMSA від Podʼів до середовища виконання контейнера.

  • WindowsHostProcessContainers: Вмикає підтримку контейнерів Windows HostProcess.

  • WindowsRunAsUserName: Вмикання підтримки запуску програм у контейнерах Windows від імені не типового користувача. Докладні відомості наведено у статті Налаштування RunAsUserName.

6.12.3 - kubelet

Огляд

Kubelet є основним "агентом вузла", який працює на кожному вузлі. Він може зареєструвати вузол на apiserver, використовуючи одне з наступного: імʼя хосту; прапорець для перевизначення імені хоста; або спеціальну логіку для провайдера хмарних послуг.

Kubelet працює в термінах PodSpec. PodSpe — це обʼєкт YAML або JSON, який описує Pod. Kubelet приймає набір PodSpec, які надаються різними механізмами (переважно через apiserver) і забезпечує, що контейнери, описані в цих PodSpec, працюють і є справними. Kubelet не управляє контейнерами, які не були створені Kubernetes.

Крім PodSpec з apiserver, є два способи, як маніфест контейнера може бути наданий kubelet.

  • Файл: Шлях, переданий як прапорець у командному рядку. Файли за цим шляхом будуть періодично моніторитися на наявність оновлень. Період моніторингу стандартно становить 20 секунд і налаштовується за допомогою прапорця.
  • HTTP endpoint: HTTP endpoint, переданий як параметр у командному рядку. Цей endpoint перевіряється кожні 20 секунд (також налаштовується за допомогою прапорця).
kubelet [flags]

Параметри

--address string     Типово: 0.0.0.0
IP-адреса, на якій буде працювати kubelet (встановіть 0.0.0.0 або :: для прослуховування на всіх інтерфейсах та в усіх сімействах IP-адрес) (ЗАСТАРІЛО: Цей параметр слід встановлювати через конфігураційний файл, вказаний прапорцем --config kubelet. Дивіться kubelet-config-file для отримання додаткової інформації.)
--allowed-unsafe-sysctls strings
Список небезпечних sysctl або шаблонів sysctl, розділених комами (завершуються на *). Використовуйте їх на свій ризик. (ЗАСТАРІЛО: Цей параметр слід встановлювати через конфігураційний файл, вказаний прапорцем --config kubelet. Дивіться kubelet-config-file для отримання додаткової інформації.)
--anonymous-auth     Типово: true
Дозволяє анонімні запити до сервера kubelet. Запити, які не відхилені іншим методом автентифікації, розглядаються як анонімні. Анонімні запити мають імʼя користувача system:anonymous та імʼя групи system:unauthenticated. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--authentication-token-webhook
Використовуйте API TokenReview для визначення автентифікації за допомогою маркерів доступу. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--authentication-token-webhook-cache-ttl duration     Типово: 2m0s
Тривалість кешування відповідей від вебхук аутентифікатора маркерів. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--authorization-mode string     Типово: AlwaysAllow
Режим авторизації для сервера kubelet. Дійсні варіанти — "AlwaysAllow" або "Webhook". Режим Webhook використовує API SubjectAccessReview для визначення авторизації. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--authorization-webhook-cache-authorized-ttl duration     Типово: 5m0s
Тривалість кешування відповідей "authorized" від вебхук авторизатора. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--authorization-webhook-cache-unauthorized-ttl duration     Типово: 30s
Тривалість кешування відповідей "unauthorized" від веб-хук авторизатора. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--bootstrap-kubeconfig string
Шлях до файлу kubeconfig, який буде використовуватися для отримання клієнтського сертифіката для kubelet. Якщо файл, вказаний прапорцем --kubeconfig, не існує, використовується файл bootstrap kubeconfig для запиту клієнтського сертифіката від API сервера. У разі успіху, файл kubeconfig, що посилається на згенерований клієнтський сертифікат і ключ, буде записано за шляхом, вказаним прапорцем --kubeconfig. Файл клієнтського сертифіката і ключа буде збережено в теці, на яку вказує прапорець --cert-dir.
--cert-dir string     Типово: /var/lib/kubelet/pki
Тека, де розташовані TLS сертифікати. Якщо вказані прапорці --tls-cert-file та --tls-private-key-file, цей прапорець буде ігноруватися.
--cgroup-driver string     Типово: cgroupfs
Драйвер, який kubelet використовує для управління cgroups на хості. Можливі значення: "cgroupfs", "systemd". (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--cgroup-root string     Типово: ''
Необовʼязковий кореневий cgroup для використання з Podʼами. Обробляється контейнерним середовищем на основі принципу найкращих зусиль. Типово: '', що означає використання стандартного значення контейнерного середовища. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--cgroups-per-qos     Типово: true
Увімкнути створення ієрархії QoS cgroup. Якщо це вірно, створюються cgroup верхнього рівня QoS та cgroup Podʼів. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--client-ca-file string
Якщо встановлено, будь-який запит, що містить клієнтський сертифікат, підписаний однією з організацій, зазначених у файлі client-ca-file, буде автентифіковано з ідентичністю, що відповідає CommonName клієнтського сертифіката. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--cloud-config string
Шлях до файлу конфігурації постачальника хмари. Порожній рядок означає відсутність файлу конфігурації. (ЗАСТАРІЛО: буде видалено в версії 1.25 або пізніше, на користь видалення коду постачальників хмари з kubelet.)
--cloud-provider string
Постачальник для хмарних сервісів. Встановіть порожній рядок для запуску без постачальника хмари. Встановіть 'external' для запуску з зовнішнім постачальником хмари. Якщо встановлено, постачальник хмари визначає імʼя вузла (консультуйтеся з документацією постачальника хмари, щоб дізнатися, чи і як використовується імʼя хоста).
--cluster-dns strings
Список IP-адрес DNS-серверів, розділений комами. Це значення використовується для DNS-серверів контейнерів у випадку Podʼів з "dnsPolicy: ClusterFirst".
Примітка: всі DNS-сервери у списку МАЮТЬ обслуговувати один і той же набір записів, інакше розвʼязання імен у кластері може працювати некоректно. Немає гарантії, який саме DNS-сервер буде використовуватися для розвʼязання імен. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--cluster-domain string
Домен для цього кластера. Якщо встановлено, kubelet налаштує всі контейнери для пошуку в цьому домені на додаток до пошукових доменів хоста. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--config string
Kubelet завантажить свою початкову конфігурацію з цього файлу. Шлях може бути абсолютним або відносним; відносні шляхи починаються з поточної робочої теки kubelet. Пропустіть цей прапорець, щоб використовувати вбудовані стандартні значення конфігурації. Прапорці командного рядка переважають над конфігурацією з цього файлу.
--config-dir string     Типово: ''
Шлях до теки для вказівки додаткових конфігурацій, що дозволяє користувачу за бажанням зазначити додаткові конфігурації для перевизначення значень, що надаються стандартно і в прапорці `--config`.
Примітка: Встановіть змінну середовища 'KUBELET_CONFIG_DROPIN_DIR_ALPHA', щоб вказати теку.
--container-log-max-files int32     Типово: 5
<Увага: бета-функція> Встановіть максимальну кількість файлів логів контейнерів, які можуть бути присутніми для контейнера. Число має бути >= 2. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--container-log-max-size string     Типово: 10Mi
<Увага: бета-функція> Встановіть максимальний розмір (наприклад, 10Mi) файлу логу контейнера до того, як буде виконано його ротацію. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--container-runtime-endpoint string     Типово: "unix:///run/containerd/containerd.sock"
Точка доступу до віддаленого сервісу. UNIX доменні сокети підтримуються в Linux, тоді як точки доступу 'npipe' і 'tcp' підтримуються у Windows. Приклади: 'unix:///path/to/runtime.sock', 'npipe:////./pipe/runtime'. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--contention-profiling
Дозволяє профілювання блоків, якщо профілювання увімкнено. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--cpu-cfs-quota     Типово: true
Вмикає застосування квоти CPU CFS для контейнерів, у яких вказано ліміти CPU. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--cpu-cfs-quota-period duration     Типово: 100ms
Встановлює значення періоду квоти CPU CFS, cpu.cfs_period_us, зазвичай використовується стандартне значення ядра Linux. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--cpu-manager-policy string     Типово: none
Політика керування CPU для використання. Можливі значення: "none", "static". (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--cpu-manager-policy-options string
Набір параметрів політики " key=value" менеджера процесорів, які можна використовувати для точного налаштування їхньої поведінки. Якщо не надано, залишити стандартну поведінку. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--cpu-manager-reconcile-period duration     Типово: 10s
<Увага: альфа-функція> Період узгодження політики керування CPU. Приклади: "10s", або "1m". Якщо не вказано, використовується стандартна частота оновлення статусу вузла. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--enable-controller-attach-detach     Типово: true
Дозволяє контролеру Attach/Detach керувати приєднанням/відʼєднанням томів, запланованих до цього вузла, і забороняє kubelet виконувати будь-які операції приєднання/відʼєднання. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--enable-debugging-handlers     Типово: true
Вмикає серверні точки доступу для збору логів та локального запуску контейнерів і команд. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--enable-server     Типово: true
Вмикає сервер kubelet. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--enforce-node-allocatable strings     Типово: pods
Список рівнів застосування обмежень розподілу ресурсів вузла, розділений комами, який буде застосовуватися kubelet. Прийнятні опції: "none", "pods", "system-reserved" та "kube-reserved". Якщо зазначені останні дві опції, обовʼязково також встановити --system-reserved-cgroup і --kube-reserved-cgroup, відповідно. Якщо зазначено "none", додаткові опції не повинні бути встановлені. Дивіться офіційну документацію для отримання додаткової інформації. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--event-burst int32     Типово: 100
Максимальний розмір сплеску записів подій, тимчасово дозволяє записам подій збільшуватися до цього числа, не перевищуючи --event-qps. Число має бути >= 0. Якщо встановлено 0, буде використано стандартне значення (100). (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--event-qps int32     Типово: 50
QPS для обмеження створення подій. Число має бути >= 0. Якщо 0, буде використано стандартне значення QPS (50). (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--eviction-hard strings     Типово: imagefs.available<15%,memory.available<100Mi,nodefs.available<10%
Набір порогів виселення (наприклад, "memory.available<1Gi"), досягнення яких спричиняє виселення Podʼів. На вузлі Linux стандартне значення також включає "nodefs.inodesFree<5%". (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--eviction-max-pod-grace-period int32
Максимальний допустимий період завершення (в секундах) для використання при завершенні Podʼів у відповідь на досягнення мʼякого порогу виселення. Якщо значення відʼємне, використовувати значення, вказане у Podʼі. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--eviction-minimum-reclaim strings
Набір мінімальних відновлень (наприклад, "imagefs.available=2Gi"), що описує мінімальну кількість ресурсів, яку kubelet буде відновлювати під час виселення Podʼів, якщо цей ресурс знаходиться під тиском. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--eviction-pressure-transition-period duration     Типово: 5m0s
Тривалість, протягом якої kubelet має чекати перед виходом із стану тиску виселення. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--eviction-soft strings
Набір порогів виселення (наприклад, "memory.available<1.5Gi"), які при досягненні протягом відповідного пільгового періоду спричинять виселення Podʼів. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--eviction-soft-grace-period strings
Набір пільгових періодів виселення (наприклад, "memory.available=1m30s"), які відповідають тривалості, протягом якої мʼякий поріг виселення має утримуватись перед тим, як буде ініційовано виселення Podʼів. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--exit-on-lock-contention
Чи повинен kubelet завершити роботу після конфлікту файлів блокування.
--experimental-allocatable-ignore-eviction     Типово: false
Якщо встановлено true, жорсткі пороги виселення будуть ігноруватися при розрахунку доступних ресурсів вузла. Дивіться тут для отримання додаткової інформації. (ЗАСТАРІЛО: буде видалено в версії 1.25 або пізніше)
--experimental-mounter-path string     Типово: mount
[Експериментально] Шлях до виконуваного файлу монтувальника. Залиште порожнім, щоб використовувати стандартний mount. (ЗАСТАРІЛО: буде видалено в версії 1.24 або пізніше на користь використання CSI.)
--fail-swap-on     Типово: true
Змушує kubelet не запускатися, якщо на вузлі увімкнено своп. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--feature-gates <Перелік пар 'key=true/false'>
Набір пар key=value, що містить опис функціональних можливостей рівня alpha/experimental. Можливі варіанти:
APIResponseCompression=true|false (BETA - default=true)
APIServerIdentity=true|false (BETA - default=true)
APIServerTracing=true|false (BETA - default=true)
APIServingWithRoutine=true|false (BETA - default=true)
AllAlpha=true|false (ALPHA - default=false)
AllBeta=true|false (BETA - default=false)
AnyVolumeDataSource=true|false (BETA - default=true)
AppArmor=true|false (BETA - default=true)
AppArmorFields=true|false (BETA - default=true)
CPUManagerPolicyAlphaOptions=true|false (ALPHA - default=false)
CPUManagerPolicyBetaOptions=true|false (BETA - default=true)
CPUManagerPolicyOptions=true|false (BETA - default=true)
CRDValidationRatcheting=true|false (BETA - default=true)
CSIMigrationPortworx=true|false (BETA - default=false)
CSIVolumeHealth=true|false (ALPHA - default=false)
CloudControllerManagerWebhook=true|false (ALPHA - default=false)
ClusterTrustBundle=true|false (ALPHA - default=false)
ClusterTrustBundleProjection=true|false (ALPHA - default=false)
ComponentSLIs=true|false (BETA - default=true)
ConsistentListFromCache=true|false (ALPHA - default=false)
ContainerCheckpoint=true|false (BETA - default=true)
ContextualLogging=true|false (BETA - default=true)
CronJobsScheduledAnnotation=true|false (BETA - default=true)
CrossNamespaceVolumeDataSource=true|false (ALPHA - default=false)
CustomCPUCFSQuotaPeriod=true|false (ALPHA - default=false)
CustomResourceFieldSelectors=true|false (ALPHA - default=false)
DevicePluginCDIDevices=true|false (BETA - default=true)
DisableCloudProviders=true|false (BETA - default=true)
DisableKubeletCloudCredentialProviders=true|false (BETA - default=true)
DisableNodeKubeProxyVersion=true|false (ALPHA - default=false)
DynamicResourceAllocation=true|false (ALPHA - default=false)
ElasticIndexedJob=true|false (BETA - default=true)
EventedPLEG=true|false (ALPHA - default=false)
GracefulNodeShutdown=true|false (BETA - default=true)
GracefulNodeShutdownBasedOnPodPriority=true|false (BETA - default=true)
HPAScaleToZero=true|false (ALPHA - default=false)
HonorPVReclaimPolicy=true|false (ALPHA - default=false)
ImageMaximumGCAge=true|false (BETA - default=true)
InPlacePodVerticalScaling=true|false (ALPHA - default=false)
InTreePluginAWSUnregister=true|false (ALPHA - default=false)
InTreePluginAzureDiskUnregister=true|false (ALPHA - default=false)
InTreePluginAzureFileUnregister=true|false (ALPHA - default=false)
InTreePluginGCEUnregister=true|false (ALPHA - default=false)
InTreePluginOpenStackUnregister=true|false (ALPHA - default=false)
InTreePluginPortworxUnregister=true|false (ALPHA - default=false)
InTreePluginvSphereUnregister=true|false (ALPHA - default=false)
InformerResourceVersion=true|false (ALPHA - default=false)
JobBackoffLimitPerIndex=true|false (BETA - default=true)
JobManagedBy=true|false (ALPHA - default=false)
JobPodFailurePolicy=true|false (BETA - default=true)
JobPodReplacementPolicy=true|false (BETA - default=true)
JobSuccessPolicy=true|false (ALPHA - default=false)
KubeProxyDrainingTerminatingNodes=true|false (BETA - default=true)
KubeletCgroupDriverFromCRI=true|false (ALPHA - default=false)
KubeletInUserNamespace=true|false (ALPHA - default=false)
KubeletPodResourcesDynamicResources=true|false (ALPHA - default=false)
KubeletPodResourcesGet=true|false (ALPHA - default=false)
KubeletSeparateDiskGC=true|false (ALPHA - default=false)
KubeletTracing=true|false (BETA - default=true)
LoadBalancerIPMode=true|false (BETA - default=true)
LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - default=false)
LogarithmicScaleDown=true|false (BETA - default=true)
LoggingAlphaOptions=true|false (ALPHA - default=false)
LoggingBetaOptions=true|false (BETA - default=true)
MatchLabelKeysInPodAffinity=true|false (ALPHA - default=false)
MatchLabelKeysInPodTopologySpread=true|false (BETA - default=true)
MaxUnavailableStatefulSet=true|false (ALPHA - default=false)
MemoryManager=true|false (BETA - default=true)
MemoryQoS=true|false (ALPHA - default=false)
MultiCIDRServiceAllocator=true|false (ALPHA - default=false)
MutatingAdmissionPolicy=true|false (ALPHA - default=false)
NFTablesProxyMode=true|false (ALPHA - default=false)
NodeInclusionPolicyInPodTopologySpread=true|false (BETA - default=true)
NodeLogQuery=true|false (BETA - default=false)
NodeSwap=true|false (BETA - default=true)
OpenAPIEnums=true|false (BETA - default=true)
PDBUnhealthyPodEvictionPolicy=true|false (BETA - default=true)
PersistentVolumeLastPhaseTransitionTime=true|false (BETA - default=true)
PodAndContainerStatsFromCRI=true|false (ALPHA - default=false)
PodDeletionCost=true|false (BETA - default=true)
PodDisruptionConditions=true|false (BETA - default=true)
PodIndexLabel=true|false (BETA - default=true)
PodLifecycleSleepAction=true|false (BETA - default=true)
PodReadyToStartContainersCondition=true|false (BETA - default=true)
PortForwardWebsockets=true|false (ALPHA - default=false)
ProcMountType=true|false (ALPHA - default=false)
QOSReserved=true|false (ALPHA - default=false)
RecoverVolumeExpansionFailure=true|false (ALPHA - default=false)
RecursiveReadOnlyMounts=true|false (ALPHA - default=false)
RelaxedEnvironmentVariableValidation=true|false (ALPHA - default=false)
RetryGenerateName=true|false (ALPHA - default=false)
RotateKubeletServerCertificate=true|false (BETA - default=true)
RuntimeClassInImageCriApi=true|false (ALPHA - default=false)
SELinuxMount=true|false (ALPHA - default=false)
SELinuxMountReadWriteOncePod=true|false (BETA - default=true)
SchedulerQueueingHints=true|false (BETA - default=false)
SeparateCacheWatchRPC=true|false (BETA - default=true)
SeparateTaintEvictionController=true|false (BETA - default=true)
ServiceAccountTokenJTI=true|false (BETA - default=true)
ServiceAccountTokenNodeBinding=true|false (ALPHA - default=false)
ServiceAccountTokenNodeBindingValidation=true|false (BETA - default=true)
ServiceAccountTokenPodNodeInfo=true|false (BETA - default=true)
ServiceTrafficDistribution=true|false (ALPHA - default=false)
SidecarContainers=true|false (BETA - default=true)
SizeMemoryBackedVolumes=true|false (BETA - default=true)
StatefulSetAutoDeletePVC=true|false (BETA - default=true)
StatefulSetStartOrdinal=true|false (BETA - default=true)
StorageNamespaceIndex=true|false (BETA - default=true)
StorageVersionAPI=true|false (ALPHA - default=false)
StorageVersionHash=true|false (BETA - default=true)
StorageVersionMigrator=true|false (ALPHA - default=false)
StructuredAuthenticationConfiguration=true|false (BETA - default=true)
StructuredAuthorizationConfiguration=true|false (BETA - default=true)
TopologyAwareHints=true|false (BETA - default=true)
TopologyManagerPolicyAlphaOptions=true|false (ALPHA - default=false)
TopologyManagerPolicyBetaOptions=true|false (BETA - default=true)
TopologyManagerPolicyOptions=true|false (BETA - default=true)
TranslateStreamCloseWebsocketRequests=true|false (BETA - default=true)
UnauthenticatedHTTP2DOSMitigation=true|false (BETA - default=true)
UnknownVersionInteroperabilityProxy=true|false (ALPHA - default=false)
UserNamespacesPodSecurityStandards=true|false (ALPHA - default=false)
UserNamespacesSupport=true|false (BETA - default=false)
VolumeAttributesClass=true|false (ALPHA - default=false)
VolumeCapacityPriority=true|false (ALPHA - default=false)
WatchFromStorageWithoutResourceVersion=true|false (BETA - default=false)
WatchList=true|false (ALPHA - default=false)
WatchListClient=true|false (BETA - default=false)
WinDSR=true|false (ALPHA - default=false)
WinOverlay=true|false (BETA - default=true)
WindowsHostNetwork=true|false (ALPHA - default=true)

(ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--file-check-frequency duration     Типово: 20s
Тривалість між перевірками конфігураційних файлів на наявність нових даних. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--hairpin-mode string     Типово: promiscuous-bridge
Як kubelet повинен налаштовувати hairpin NAT. Це дозволяє точкам доступу Service балансувати навантаження назад на себе, якщо вони намагаються отримати доступ до власного Service. Допустимі значення: "promiscuous-bridge", "hairpin-veth" та "none". (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--healthz-bind-address string     Типово: 127.0.0.1
IP-адреса, на якій буде працювати сервер healthz (встановіть на "0.0.0.0" або "::" для прослуховування на всіх інтерфейсах та IP-сімействах). (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--healthz-port int32     Типово: 10248
Порт точки доступу healthz на localhost (встановіть 0 щоб вимкнути). (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
-h, --help
Довідка kubelet
--hostname-override string
Якщо не порожній, буде використовуватися цей рядок як ідентифікатор замість фактичного імені хоста. Якщо встановлено --cloud-provider, постачальник хмарних послуг визначає імʼя вузла (звіртесь з документацією постачальника хмарних послуг, щоб дізнатися, як використовується імʼя хосту).
--http-check-frequency duration     Типово: 20s
Тривалість між перевірками HTTP на наявність нових даних. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--image-credential-provider-bin-dir string
Шлях до теки, де знаходяться двійкові файли втулка постачальника облікових даних.
--image-credential-provider-config string
Шлях до конфігураційного файлу втулка постачальника облікових даних.
--image-gc-high-threshold int32     Типово: 85
Відсоток використання диска, після якого завжди виконується видалення непотрібних образів. Значення має бути в діапазоні [0, 100], щоб вимкнути збирання сміття, встановіть значення 100. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--image-gc-low-threshold int32     Типово: 80
Відсоток використання диска, до якого прибирання образів ніколи не виконується. Найменше використання диска, при якому проводиться збір сміття. Значення повинні бути в межах [0, 100] і не повинні перевищувати значення --image-gc-high-threshold. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--image-service-endpoint string
Точка доступу до віддаленого сервісу образів. Якщо не вказано, стандартно буде така ж, як і у --container-runtime-endpoint. UNIX доменні сокети підтримуються в Linux, тоді як точки доступу `npipe` і `tcp` підтримуються у Windows. Приклади: unix:///path/to/runtime.sock, npipe:////./pipe/runtime. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--keep-terminated-pod-volumes
Зберігати змонтовані томи завершених Podʼів на вузлі після завершення роботи Podʼів. Може бути корисним для відлагодження проблем, повʼязаних з томами. (DEPRECATED: will be removed in a future version)
--kernel-memcg-notification
Якщо увімкнено, kubelet буде інтегруватися з повідомленням memcg ядра для визначення, чи перевищено порогові значення пам’яті для виселення, замість періодичного опитування. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--kube-api-burst int32     Типово: 100
Сплеск, який буде використовуватися при спілкуванні з API сервером Kubernetes. Число має бути >= 0. Якщо встановлено 0, буде використано стандартне значення (100). Не стосується пудьсу API подій та вузлів, для яких обмеження швидкості контролюється іншим набором прапорців. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--kube-api-content-type string     Типово: application/vnd.kubernetes.protobuf
Тип вмісту запитів, що надсилаються до apiserver. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--kube-api-qps int32     Типово: 50
QPS, який буде використовуватися при спілкуванні з API сервером Kubernetes. Число має бути >= 0. Якщо встановлено 0, буде використано стандартне значення (50). Не стосується пульсу API подій та вузлів, для яких обмеження швидкості контролюється іншим набором прапорців. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--kube-reserved strings     Типово: <None>
Набір пар <resource name>=<resource quantity> (наприклад, "cpu=200m,memory=500Mi,ephemeral-storage=1Gi,pid='100'"), які описують ресурси, зарезервовані для компонентів системи Kubernetes. В даний час підтримуються cpu, memory та локальне ephemeral-storage для кореневої файлової системи. Дивіться тут для отримання додаткової інформації. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--kube-reserved-cgroup string     Типово: ''
Абсолютне імʼя верхнього рівня cgroup, яке використовується для управління компонентами Kubernetes, для яких ресурси обчислення були зарезервовані за допомогою прапорця --kube-reserved. Наприклад, "/kube-reserved". (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--kubeconfig string
Шлях до файлу kubeconfig, що визначає, як підключитися до API сервера. Надання --kubeconfig увімкне режим API сервера, тоді як пропуск --kubeconfig увімкне автономний (standalone) режим.
--kubelet-cgroups string
Необовʼязкове абсолютне імʼя cgroups для створення та запуску kubelet. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--local-storage-capacity-isolation>     Типово: true
Якщо true, увімкнено ізоляцію локального тимчасового зберігання. Інакше функція ізоляції локального зберігання буде вимкнена. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--lock-file string
<Попередження: Альфа функція> Шлях до файлу, який kubelet використовуватиме як файл блокування.
--log-flush-frequency duration     Типово: 5s
Максимальна кількість секунд між очищеннями логу.
--log-json-info-buffer-size string     Типово: '0'
[Alpha] У форматі JSON з розділеними вихідними потоками інформаційні повідомлення можуть бути буферизовані на деякий час для підвищення продуктивності. Стандартне значення, що дорівнює нулю байтів, вимикає буферизацію. Розмір може бути вказаний у байтах (512), кратних 1000 (1K), кратних 1024 (2Ki) або степенях цих значень (3M, 4G, 5Mi, 6Gi). Щоб використовувати це, увімкніть функціональну можливість LoggingAlphaOptions. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--log-json-split-stream
[Alpha] У форматі JSON помилки записуються у stderr, а інформаційні повідомлення — у stdout. Стандартно всі повідомлення записуються в один потік stdout. Щоб використовувати це, увімкніть функціональну можливість LoggingAlphaOptions. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--log-text-info-buffer-size string     Типово: '0'
[Alpha] У текстовому форматі з розділеними вихідними потоками інформаційні повідомлення можуть бути буферизовані на деякий час для підвищення продуктивності. Стандартне значення, що дорівнює нулю байтів, вимикає буферизацію. Розмір може бути вказаний у байтах (512), кратних 1000 (1K), кратних 1024 (2Ki) або степенях цих значень (3M, 4G, 5Mi, 6Gi). Щоб використовувати це, увімкніть функціональну можливість LoggingAlphaOptions. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--log-text-split-stream
[Alpha] У текстовому форматі помилки записуються у stderr, а інформаційні повідомлення — у stdout. Стандартно всі повідомлення записуються в один потік stdout. Щоб використовувати це, увімкніть функціональну можливість LoggingAlphaOptions. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--logging-format string     Типово: text
Встановлює формат логу. Дозволені формати: "json" (контрольований LoggingBetaOptions, "text"). (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--make-iptables-util-chains     Типово: true
Якщо значення істинне, kubelet забезпечить наявність правил утиліти iptables на хості. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--manifest-url string
URL для доступу до додаткових специфікацій Pod, які потрібно запустити. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--manifest-url-header strings
Список HTTP-заголовків, розділених комами, які слід використовувати при доступі до URL, наданого параметру --manifest-url. Кілька заголовків з однаковою назвою будуть додані в тому ж порядку, в якому вони надані. Цей параметр можна використовувати кілька разів. Наприклад: --manifest-url-header 'a:hello,b:again,c:world' --manifest-url-header 'b:beautiful'. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--max-open-files int     Типово: 1000000
Кількість файлів, які може відкрити процес kubelet. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--max-pods int32     Типово: 110
Кількість Podʼів, які можуть працювати на цьому kubelet. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--maximum-dead-containers int32     Типово: -1
Максимальна кількість старих екземплярів контейнерів, які можна зберігати глобально. Кожен контейнер займає певний простір на диску. Щоб вимкнути, встановіть відʼємне число. (ЗАСТАРІЛО: Замість цього використовуйте --eviction-hard або --eviction-soft. Буде видалено в майбутніх версіях.)
--maximum-dead-containers-per-container int32     Типово: 1
Максимальна кількість старих екземплярів, які потрібно зберігати для кожного контейнера. Кожен контейнер займає певний обсяг дискового простору. (ЗАСТАРІЛО: Замість цього використовуйте --eviction-hard або --eviction-soft. Буде видалено в майбутніх версіях.)
--memory-manager-policy string     Типово: None
Політика Memory Manager для використання. Можливі значення: "None", "Static". (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--minimum-container-ttl-duration duration
Мінімальний вік для завершеного контейнера перед тим, як його буде прибрано. Приклади: "300ms", "10s" або "2h45m". (ЗАСТАРІЛО: Замість цього використовуйте --eviction-hard або --eviction-soft. Буде видалено в майбутніх версіях.)
--minimum-image-ttl-duration duration     Типово: 2m0s
Мінімальний вік для невикористаного образу перед тим, як його буде прибрано. Приклади: "300ms", "10s" або "2h45m". (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--node-ip string
IP-адреса (або список IP-адрес для двох стеків, розділених комами) вузла. Якщо не встановлено, kubelet використовуватиме стандартну IPv4-адресу вузла, якщо така є, або його стандартну IPv6-адресу, якщо IPv4-адрес немає. Ви можете передати "::", щоб віддати перевагу стандартній IPv6-адресі замість стандартної IPv4-адреси.
--node-labels <пари key=value>
<Попередження: Alpha функція>Мітки для додавання під час реєстрації вузла в кластері. Мітки повинні бути у форматі key=value, розділені ','. Мітки в просторі 'kubernetes.io' повинні починатися з дозволеного префікса ('kubelet.kubernetes.io', 'node.kubernetes.io') або бути в спеціально дозволеному наборі ('beta.kubernetes.io/arch', 'beta.kubernetes.io/instance-type', 'beta.kubernetes.io/os', 'failure-domain.beta.kubernetes.io/region', 'failure-domain.beta.kubernetes.io/zone', 'kubernetes.io/arch', 'kubernetes.io/hostname', 'kubernetes.io/os', 'node.kubernetes.io/instance-type', 'topology.kubernetes.io/region', 'topology.kubernetes.io/zone').
--node-status-max-images int32     Типово: 50
Максимальна кількість образів для показу в node.status.images. Якщо вказано -1, обмеження не буде застосовано. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--node-status-update-frequency duration     Типово: 10s
Визначає, як часто kubelet сповіщає про статус вузла у майстер. Примітка: будьте обережні при зміні константи, вона повинна узгоджуватися з nodeMonitorGracePeriod в контролері вузлів. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--oom-score-adj int32     Типово: -999
Значення oom-score-adj для процесу kubelet. Значення повинні бути в межах від [-1000, 1000]. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--pod-cidr string
CIDR для використання IP-адрес Pod, використовується тільки в автономному (standalone) режимі. У кластерному режимі це отримується від майстра. Для IPv6 максимальна кількість виділених IP-адрес складає 65536. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--pod-infra-container-image string     Типово: registry.k8s.io/pause:3.9
Вказаний образ не буде видалений під час прибирання образів. Реалізації CRI мають власну конфігурацію для налаштування цього образу. (ЗАСТАРІЛО: буде видалено в 1.27. Прибирання образів буде отримувати інформацію про образи пісочниць з CRI.)
--pod-manifest-path string
Шлях до теки, що містить файли статичних Pod для запуску, або шлях до одного файлу статичного Pod. Файли, що починаються з крапки, будуть ігноруватися. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--pod-max-pids int     Типово: -1
Встановлює максимальну кількість процесів на Pod. Якщо -1, kubelet стандартно використовує доступну на вузлі ємність PID. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--pods-per-core int32
Кількість Podʼів на ядро, які можуть працювати на цьому kubelet. Загальна кількість Podʼів на цьому kubelet не може перевищувати --max-pods, тому буде використовуватися --max-pods, якщо цей розрахунок призведе до більшої кількості дозволених Podʼів на kubelet. Значення 0 вимикає це обмеження. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--port int32     Типово: 10250
Порт, на якому kubelet буде обслуговувати запити. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--protect-kernel-defaults
Стандартна поведінка kubelet для налаштування ядра. Якщо встановлено, kubelet видасть помилку, якщо будь-яке з налаштувань ядра відрізняється від стандартних значень kubelet. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--provider-id string
Унікальний ідентифікатор для ідентифікації вузла в базі даних машин, тобто у постачальника хмари.
--qos-reserved string
<Попередження: Alpha рівень> Набір пар <resource name>=<percentage> (наприклад, "memory=50%"), які описують, як запити ресурсів Pod резервуються на рівні QoS. На даний момент підтримується тільки memory. Потрібно активувати функціональну можливість QOSReserved. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--read-only-port int32     Типово: 10255
Порт тільки для читання, на якому буде працювати kubelet без автентифікації/авторизації (для вимкнення встановіть 0). (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--register-node     Типово: true
Зареєструйте вузол на сервері API. Якщо --kubeconfig не вказано, цей параметр не має значення, оскільки kubelet не матиме API-сервера для реєстрації. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--register-schedulable     Типово: true
Зареєструвати вузол як придатний для планування. Не матиме впливу, якщо --register-node має значення false. (ЗАСТАРІЛО: буде вилучено в майбутніх версіях)
--register-with-taints string
Реєструє вузол з наданим списком taints (розділених комами <key>=<value>:<effect>). Нічого не робить, якщо --register-node має значення false. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--registry-burst int32     Типово: 10
Максимальний розмір для сплеску завантажень, тимчасово дозволяє завантаженням досягати цієї кількості, не перевищуючи при цьому --registry-qps. Використовується тільки якщо --registry-qps більше 0. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--registry-qps int32     Типово: 5
Якщо > 0, обмежити QPS для завантажень з реєстру до цього значення. Якщо 0, без обмежень. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--reserved-cpus string
Список CPU або діапазонів CPU, розділених комами, зарезервованих для системи та використання Kubernetes. Цей конкретний список переважатиме над кількістю CPU в --system-reserved та --kube-reserved. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--reserved-memory string
Список резервувань памʼяті для NUMA вузлів, розділених комами. (наприклад, "--reserved-memory 0:memory=1Gi,hugepages-1M=2Gi --reserved-memory 1:memory=2Gi"). Загальна сума для кожного типу памʼяті повинна дорівнювати сумі --kube-reserved, --system-reserved та --eviction-threshold. Дивіться тут для отримання додаткових відомостей. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--resolv-conf string     Типово: /etc/resolv.conf
Файл конфігурації резольвера, який використовується як основа для конфігурації DNS-резолюції контейнера. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--root-dir string     Типово: /var/lib/kubelet
Шлях до теки для управління файлами kubelet (монтування томів тощо).
--rotate-certificates
Виконувати автоматичну ротацію клієнтськіх сертифікатів kubelet, запитуючи нові сертифікати у kube-apiserver, коли термін дії сертифіката наближається до закінчення. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--rotate-server-certificates
Автоматично запитувати та виконувати ротацію сертифікатів kubelet, запитуючи нові сертифікати у kube-apiserver, коли термін дії сертифіката наближається до закінчення. Потрібно активувати функціональну можливість RotateKubeletServerCertificate та схвалення поданих обʼєктів CertificateSigningRequest. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--runonce
Якщо true, виходити після створення Podʼів з локальних маніфестів або віддалених URL. Взаємовиключно з --enable-server. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--runtime-cgroups string
Необовʼязкова абсолютна назва cgroups для створення та запуску середовища виконання.
--runtime-request-timeout duration     Типово: 2m0s
Тайм-аут для всіх запитів до середовища виконання, окрім довготривалих запитів — pull, logs, exec та attach. Коли тайм-аут перевищено, kubelet скасує запит, видасть помилку і спробує знову пізніше. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--seccomp-default
Вмикає використання RuntimeDefault як стандартного профілю seccomp для всіх навантажень.
--serialize-image-pulls     Типово: true
Витягує образи по одному. Рекомендується *не* змінювати стандартні значення на вузлах, які використовують демон Docker версії < 1.9 або сховище aufs. Деталі дивіться в тікеті #10959. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--streaming-connection-idle-timeout duration     Типово: 4h0m0s
Максимальний час, протягом якого зʼєднання для потокового режиму може бути неактивним перед автоматичним закриттям зʼєднання. 0 вказує на відсутність тайм-ауту. Приклад: 5m. Примітка: всі зʼєднання до сервера kubelet мають максимальну тривалість 4 години. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--sync-frequency duration     Типово: 1m0s
Максимальний проміжок часу між синхронізацією запущених контейнерів та конфігурацією. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--system-cgroups string
Необовʼязкова абсолютна назва cgroups, в якій слід розмістити всі процеси, що не є процесами ядра, що не знаходяться вже в cgroup під '/'. Пусто для відсутності контейнера. Для скасування прапорця потрібне перезавантаження. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--system-reserved string     Типово: <none>
Набір пар <resource name>=<resource quantity> (наприклад, "cpu=200m,memory=500Mi,ephemeral-storage=1Gi,pid='100'"), які описують ресурси, зарезервовані для не-Kubernetes компонентів. Наразі підтримуються тільки cpu, memory та локальне тимчасове сховище для кореневої файлової системи. Дивіться тут для отримання додаткових відомостей. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--system-reserved-cgroup string     Типово: ''
Абсолютна назва cgroup найвищого рівня, яка використовується для управління не-Kubernetes компонентами, для яких ресурси були зарезервовані за допомогою прапорця --system-reserved. Наприклад, /system-reserved. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--tls-cert-file string
Файл, що містить x509 сертифікат, використовується для обслуговування HTTPS (з проміжними сертифікатами, якщо такі є, конкатенованими після серверного сертифіката). Якщо --tls-cert-file та --tls-private-key-file не вказані, для публічної адреси генеруються самопідписані сертифікат і ключ, які зберігаються в теці, вказаній в --cert-dir. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--tls-cipher-suites string
Список наборів шифрів для сервера, розділений комами. Якщо не вказано, будуть використані стандартні набори шифрів Go.
Рекомендовані значення: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305, TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305, TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_GCM_SHA384

Небезпечні значення: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_3DES_EDE_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_RC4_128_SHA.

(ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--tls-min-version string
Minimum TLS version supported. Possible values: "VersionTLS10", "VersionTLS11", "VersionTLS12", "VersionTLS13". (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--tls-private-key-file string
Файл, що містить приватний ключ x509, що відповідає --tls-cert-file. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--topology-manager-policy string     Типово: 'none'
Політика Topology Manager для використання. Можливі значення: "none", "best-effort", "restricted", "single-numa-node". (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--topology-manager-policy-options string
Набір параметрів політики Topology Manager у форматі <key>=<value>, які можна використовувати для тонкого налаштування їх поведінки. Якщо не вказані, зберігається стандартна поведінка. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--topology-manager-scope string     Типово: container
Область, до якої застосовуються топологічні підказки. Topology Manager збирає підказки від постачальників підказок і застосовує їх до визначеної області для забезпечення допуску Pod. Можливі значення: "container", "pod". (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
-v, --v Level
Число для рівня детальності логу
--version version[=true]
Виводить інформацію про версію та виходить; --version=vX.Y.Z... задає відображену версію.
--vmodule <A list of 'pattern=N' strings>
Список налаштувань pattern=N, розділених комами, для фільтрованого логування файлів (працює тільки для текстового формату логу).
--volume-plugin-dir string     Типово: /usr/libexec/kubernetes/kubelet-plugins/volume/exec/
Повний шлях до теки, в якій слід шукати додаткові втулки томів від сторонніх постачальників. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)
--volume-stats-agg-period duration     Типово: 1m0s
Вказує інтервал, через який kubelet обчислює та кешує використання диска томів для всіх Podʼів і томів. Щоб вимкнути обчислення томів, встановіть від’ємне число. (ЗАСТАРІЛО: Цей параметр слід налаштовувати через файл конфігурації, вказаний прапорцем kubelet --config. Дивіться kubelet-config-file для отримання додаткової інформації.)

6.12.4 - kube-apiserver

Огляд

Сервер API Kubernetes перевіряє та налаштовує дані для обʼєктів api, які включають Podʼи, сервіси, replicationcontrollers та інші. API Server обслуговує REST-операції та забезпечує інтерфейс до спільного стану кластера, через який взаємодіють всі інші компоненти.

kube-apiserver [flags]

Параметри

--admission-control-config-file string

Файл з конфігурацією контролю допуску.

--advertise-address string

IP-адреса, на якій буде публікуватися інформація про apiserver для членів кластеру. Ця адреса має бути доступною для решти учасників кластера. Якщо не вказано, буде використано --bind-address. Якщо --bind-address не вказано, буде використано стандартний інтерфейс хоста.

--aggregator-reject-forwarding-redirect     Типово: true

Агрегатор відхиляє перенаправлення відповіді редиректу назад клієнту.

--allow-metric-labels stringToString     Типово: []

Зіставляє метрику-мітку зі списком дозволених значень цієї мітки. Формат ключа — <MetricName>,<LabelName>. Формат значення — < allowed_value>, <allowed_value>...наприклад, metric1,label1='v1,v2,v3', metric1,label2='v1,v2,v3' metric2,label1='v1,v2,v3'.

--allow-metric-labels-manifest string

Шлях до файлу маніфесту, який містить зіставлення allow-list. Формат файлу такий самий, як і у прапорця --allow-metric-labels. Зауважте, що прапорець --allow-metric-labels замінить файл маніфесту.

--allow-privileged

Якщо true, дозволити привілейовані контейнери. [default=false]

--anonymous-auth     Типово: true

Дозволяє анонімні запити до захищеного порту сервера API. Запити, які не були відхилені іншими методами автентифікації, вважаються анонімними. Анонімні запити мають імʼя користувача system:anonymous і назву групи system:unauthenticated.

--api-audiences strings

Ідентифікатори API. Автентифікатор токенів службового облікового запису перевіряє, що токени, які використовуються з API, привʼязані принаймні до однієї з цих аудиторій. Якщо прапорець --service-account-issuer налаштовано, а цей прапорець не встановлено, стандартно у цьому полі буде вказано список з одного елемента, що містить URL-адресу емітента.

--audit-log-batch-buffer-size int     Типово: 10000

Розмір буфера для зберігання подій перед пакетною передачею та записом. Використовується тільки у пакетному режимі.

--audit-log-batch-max-size int     Типово: 1

Максимальний розмір пакету. Використовується тільки в пакетному режимі.

--audit-log-batch-max-wait duration

Час очікування перед примусовим записом пакету, який не досягнув максимального розміру. Використовується тільки в пакетному режимі.

--audit-log-batch-throttle-burst int

Максимальна кількість запитів, надісланих одночасно, якщо ThrottleQPS не використовувався раніше. Використовується тільки в пакетному режимі.

--audit-log-batch-throttle-enable

Чи ввімкнено пакетний тротлінг. Використовується тільки в пакетному режимі.

--audit-log-batch-throttle-qps float

Максимальна середня кількість партій в секунду. Використовується тільки в пакетному режимі.

--audit-log-compress

Якщо встановлено, файли логів, що ротуються, буде стиснуто за допомогою gzip.

--audit-log-format string     Типово: "json"

Формат збережених аудитів. "legacy" вказує на 1-рядковий текстовий формат для кожної події. "json" вказує на структурований формат json. Відомі формати: legacy, json.

--audit-log-maxage int

Максимальна кількість днів для зберігання старих файлів логів аудиту на основі мітки часу, закодованої в їхньому імені.

--audit-log-maxbackup int

Максимальна кількість старих файлів логів аудиту, які слід зберігати. Встановлення значення 0 означатиме відсутність обмежень на кількість файлів.

--audit-log-maxsize int

Максимальний розмір у мегабайтах файлу логу аудиту до того, як буде виконано його ротацію.

--audit-log-mode string     Типово: "blocking"

Стратегія надсилання подій аудиту. Блокування вказує на те, що надсилання подій має блокувати відповіді сервера. Пакетне виконання змушує бекенд буферизувати і записувати події асинхронно. Відомі такі режими: batch, blocking, blocking-strict.

--audit-log-path string

Якщо встановлено, всі запити, що надходять до apiserver, будуть записуватися до цього файлу. '-' означає стандартний вивід.

--audit-log-truncate-enabled

Чи увімкнено усікання подій та пакетів.

--audit-log-truncate-max-batch-size int     Типово: 10485760

Максимальний розмір пакету, що надсилається до відповідного бекенду. Фактичний розмір серіалізованого файлу може бути на кілька сотень байт більшим. Якщо пакет перевищує цей ліміт, він розбивається на кілька пакетів меншого розміру.

--audit-log-truncate-max-event-size int     Типово: 102400

Максимальний розмір події аудиту, що надсилається до відповідного бекенду. Якщо розмір події перевищує це число, перший запит і відповідь видаляються, а якщо це не зменшує розмір достатньо, подія відкидається.

--audit-log-version string     Типово: "audit.k8s.io/v1"

Група та версія API, що використовується для серіалізації подій аудиту, записаних до логу.

--audit-policy-file string

Шлях до файлу, який визначає конфігурацію політики аудиту.

--audit-webhook-batch-buffer-size int     Типово: 10000

Розмір буфера для зберігання подій перед пакетною передачею та записом. Використовується тільки у пакетному режимі.

--audit-webhook-batch-max-size int     Типово: 400

Максимальний розмір пакету. Використовується тільки у пакетному режимі.

--audit-webhook-batch-max-wait duration     Типово: 30s

Час очікування перед примусовим записом пакету, який не досягнув максимального розміру. Використовується тільки у пакетному режимі.

--audit-webhook-batch-throttle-burst int     Типово: 15

Максимальна кількість запитів, надісланих одночасно, якщо ThrottleQPS не використовувався раніше. Використовується тільки у пакетному режимі.

--audit-webhook-batch-throttle-enable     Типово: true

Чи ввімкнено пакетний тротлінг. Використовується тільки у пакетному режимі.

--audit-webhook-batch-throttle-qps float     Типово: 10

Максимальна середня кількість пакетів за секунду. Використовується тільки у пакетному режимі.

--audit-webhook-config-file string

Шлях до файлу у форматі kubeconfig, який визначає конфігурацію вебхука аудиту.

--audit-webhook-initial-backoff duration     Типово: 10s

Час очікування перед повторною спробою після першого невдалого запиту.

--audit-webhook-mode string     Типово: "batch"

Стратегія надсилання подій аудиту. Блокування вказує на те, що надсилання подій має блокувати відповіді сервера. Режим batch змушує бекенд буферизувати і записувати події асинхронно. Відомі такі режими: batch, blocking, blocking-strict.

--audit-webhook-truncate-enabled

Чи увімкнено усікання подій та пакетів.

--audit-webhook-truncate-max-batch-size int     Типово: 10485760

Максимальний розмір пакету, що надсилається до відповідного бекенду. Фактичний розмір серіалізованого файлу може бути на кілька сотень байт більшим. Якщо пакет перевищує цей ліміт, він розбивається на кілька пакетів меншого розміру.

--audit-webhook-truncate-max-event-size int     Типово: 102400

Максимальний розмір події аудиту, що надсилається до відповідного бекенду. Якщо розмір події перевищує це число, перший запит і відповідь видаляються, а якщо це не зменшує розмір достатньо, подія відкидається.

--audit-webhook-version string     Типово: "audit.k8s.io/v1"

Група та версія API, що використовується для серіалізації подій аудиту, записаних у webhook.

--authentication-config string

Файл з конфігурацією автентифікації для налаштування автентифікатора JWT Token або анонімного автентифікатора. Примітка: Ця функція доступна у версії Alpha, починаючи з v1.29.--feature-gate=StructuredAuthenticationConfiguration=true, щоб увімкнути цю функцію.Ця функція є взаємовиключною з прапорцями oidc-*. Для налаштування анонімного автентифікатора вам потрібно ввімкнути --feature-gate=AnonymousAuthConfigurableEndpoints. Коли ви налаштовуєте анонімний автентифікатор у конфігурації автентифікації, ви не можете використовувати прапорець --anonymous-auth.

--authentication-token-webhook-cache-ttl duration     Типово: 2m0s

Тривалість кешування відповідей від автентифікатора токенів вебхуків.

--authentication-token-webhook-config-file string

Файл з конфігурацією вебхука для автентифікації токенів у форматі kubeconfig. Сервер API буде запитувати віддалений сервіс для визначення автентичності токенів на предʼявника.

--authentication-token-webhook-version string     Типово: "v1beta1"

Версія API authentication.k8s.io TokenReview для надсилання та очікування від вебхука.

--authorization-config string

Файл з конфігурацією авторизації для налаштування ланцюжка авторизації.Примітка: Ця можливість зʼявилася у версії Alpha починаючи з v1.29.--feature-gate=StructuredAuthorizationConfiguration=true прапорець функції має бути встановлений у true для увімкнення функціональності.Ця можливість є взаємовиключною з іншими прапорцями --authorization-mode та --authorization-webhook-*.

--authorization-mode strings

Впорядкований список втулків для авторизації на захищеному порту. Стандартно має значення AlwaysAllow, якщо не вказано --authorization-config. Список втулків, розділених комами: AlwaysAllow,AlwaysDeny,ABAC,Webhook,RBAC,Node.

--authorization-policy-file string

Файл з політикою авторизації у форматі json, що використовується з --authorization-mode=ABAC, на захищеному порту.

--authorization-webhook-cache-authorized-ttl duration     Типово: 5m0s

Тривалість кешування 'authorized' відповідей від авторизатора вебхука.

--authorization-webhook-cache-unauthorized-ttl duration     Типово: 30s

Тривалість кешування 'unauthorized' відповідей від авторизатора вебхука.

--authorization-webhook-config-file string

Файл з конфігурацією webhook у форматі kubeconfig, що використовується з --authorization-mode=Webhook. Сервер API запитує віддалений сервіс для визначення доступу на захищеному порту сервера API.

--authorization-webhook-version string     Типово: "v1beta1"

Версія API authorization.k8s.io SubjectAccessReview, яку потрібно надсилати до вебхука та очікувати від нього.

--bind-address string     Типово: 0.0.0.0

IP-адреса, на якій буде прослуховуватися порт --secure-port. Відповідний інтерфейс(и) має бути доступним для решти кластера, а також для CLI/веб-клієнтів. Якщо цей параметр не вказано або вказано невизначену адресу (0.0.0.0 або ::), будуть використані всі інтерфейси та сімейства IP-адрес.

--cert-dir string     Типово: "/var/run/kubernetes"

Тека, в якій знаходяться TLS-сертифікати. Якщо вказано --tls-cert-file та --tls-private-key-file, цей прапорець буде проігноровано.

--client-ca-file string

Якщо встановлено, будь-який запит, що надає клієнтський сертифікат, підписаний одним із центрів сертифікації у клієнтському файлі, буде автентифіковано за допомогою ідентифікатора, що відповідає CommonName клієнтського сертифіката.

--contention-profiling

Дозволяє профілювання блоків, якщо профілювання увімкнено

--cors-allowed-origins strings

Список дозволених джерел для CORS, через кому. Допустимим джерелом може бути регулярний вираз для підтримки співставлення субдоменів. Якщо цей список порожній, CORS не буде ввімкнено. Будь ласка, переконайтеся, що кожен вираз співпадає з повним імʼям хоста шляхом привʼязки до початку за допомогою '^' або включення префікса '//', а також шляхом привʼязки до кінця за допомогою '$' або включення суфікса-розділювача портів ':'. Прикладами допустимих виразів є '//example.com(:|$)' і '^https://example.com(:|$)'

--debug-socket-path string

Використовуйте незахищений (без authn/authz) unix-доменний сокет для профілювання за вказаним шляхом

--default-not-ready-toleration-seconds int     Типово: 300

Вказує толерантність у секундах для notReady:NoExecute, яка стандартно додається до кожного Podʼа, який ще не має такої толерантності.

--default-unreachable-toleration-seconds int     Типово: 300

Показує tolerationSeconds толерантності для unreachable:NoExecute, яка стандартно додається до кожного Podʼа, який ще не має такої толерантності.

--delete-collection-workers int     Типово: 1

Кількість обробників, створених для виклику DeleteCollection. Вони використовуються для прискорення очищення простору імен.

--disable-admission-plugins strings

Втулки допуску, які слід вимкнути, хоча вони є у списку стандартно ввімкнутих втулків (NamespaceLifecycle, LimitRanger, ServiceAccount, TaintNodesByCondition, PodSecurity, Priority, DefaultTolerationSeconds, DefaultStorageClass, StorageObjectInUseProtection, PersistentVolumeClaimResize, RuntimeClass, CertificateApproval, CertificateSigning, ClusterTrustBundleAttest, CertificateSubjectRestriction, DefaultIngressClass, MutatingAdmissionWebhook, ValidatingAdmissionPolicy, ValidatingAdmissionWebhook, ResourceQuota). Список втулків допуску розділених комою: AlwaysAdmit, AlwaysDeny, AlwaysPullImages, CertificateApproval, CertificateSigning, CertificateSubjectRestriction, ClusterTrustBundleAttest, DefaultIngressClass, DefaultStorageClass, DefaultTolerationSeconds, DenyServiceExternalIPs, EventRateLimit, ExtendedResourceToleration, ImagePolicyWebhook, LimitPodHardAntiAffinityTopology, LimitRanger, MutatingAdmissionWebhook, NamespaceAutoProvision, NamespaceExists, NamespaceLifecycle, NodeRestriction, OwnerReferencesPermissionEnforcement, PersistentVolumeClaimResize, PodNodeSelector, PodSecurity, PodTolerationRestriction, Priority, ResourceQuota, RuntimeClass, ServiceAccount, StorageObjectInUseProtection, TaintNodesByCondition, ValidatingAdmissionPolicy, ValidatingAdmissionWebhook. Порядок розташування втулків у цьому прапорці не має значення.

--disable-http2-serving

Якщо значення true, HTTP2-сервіс буде вимкнено [default=false].

--disabled-metrics strings

Цей прапорець забезпечує аварійний вихід для метрик, що поводяться не належним чином. Щоб вимкнути метрику, ви маєте вказати її повну назву. Застереження: вимкнення метрик має вищий пріоритет, ніж показ прихованих метрик.

--egress-selector-config-file string

Файл з конфігурацією селектора egress apiserver.

--emulated-version strings

У версіях різні компоненти емулюють свої можливості (API, функції, ...) інших компонентів.
Якщо встановлено, компонент буде емулювати поведінку цієї версії замість базової двійкової версії.
Формат версії може бути лише major.minor, наприклад: '--emulated-version=wardle=1.2,kube=1.31'. Можливі варіанти:
kube=1.31..1.31 (default=1.31) Якщо компонент не вказано, стандартно використовується "kube"

--enable-admission-plugins strings

Втулки допуску, які слід увімкнути на додачу до стандартно увімкнутих (NamespaceLifecycle, LimitRanger, ServiceAccount, TaintNodesByCondition, PodSecurity, Priority, DefaultTolerationSeconds, DefaultStorageClass, StorageObjectInUseProtection, PersistentVolumeClaimResize, RuntimeClass, CertificateApproval, CertificateSigning, ClusterTrustBundleAttest, CertificateSubjectRestriction, DefaultIngressClass, MutatingAdmissionWebhook, ValidatingAdmissionPolicy, ValidatingAdmissionWebhook, ResourceQuota). Розділений комами список втулків допуску: AlwaysAdmit, AlwaysDeny, AlwaysPullImages, CertificateApproval, CertificateSigning, CertificateSubjectRestriction, ClusterTrustBundleAttest, DefaultIngressClass, DefaultStorageClass, DefaultTolerationSeconds, DenyServiceExternalIPs, EventRateLimit, ExtendedResourceToleration, ImagePolicyWebhook, LimitPodHardAntiAffinityTopology, LimitRanger, MutatingAdmissionWebhook, NamespaceAutoProvision, NamespaceExists, NamespaceLifecycle, NodeRestriction, OwnerReferencesPermissionEnforcement, PersistentVolumeClaimResize, PodNodeSelector, PodSecurity, PodTolerationRestriction, Priority, ResourceQuota, RuntimeClass, ServiceAccount, StorageObjectInUseProtection, TaintNodesByCondition, ValidatingAdmissionPolicy, ValidatingAdmissionWebhook. Порядок розташування втулків у цьому прапорці не має значення.

--enable-aggregator-routing

Вмикає маршрутизацію запитів агрегатора на IP точок доступу, а не на IP кластера.

--enable-bootstrap-token-auth

Увімкніть, щоб дозволити використовувати секрети типу 'bootstrap.kubernetes.io/token' у просторі імен 'kube-system' для автентифікації за допомогою TLS-завантаження.

--enable-garbage-collector     Типово: true

Вмикає загальний збирач сміття. МАЄ бути синхронізовано з відповідним прапорцем kube-controller-manager.

--enable-priority-and-fairness     Типово: true

Якщо true, замініть обробник max-in-flight на покращений обробник, який ставить в чергу та розподіляє відправлення з пріоритетом та справедливістю

--encryption-provider-config string

Файл, що містить конфігурацію для провайдерів шифрування, які будуть використовуватися для зберігання секретів у etcd

--encryption-provider-config-automatic-reload

Визначає, чи слід автоматично перезавантажувати файл, заданий за допомогою --encryption-provider-config, у разі зміни вмісту диска. Встановлення цього параметра у значення true вимикає можливість унікальної ідентифікації окремих втулків KMS за допомогою точок доступу API сервера healthz.

--endpoint-reconciler-type string     Типово: "lease"

Використовувати узгоджувач точок доступу (master-count, lease, none) master-count є застарілим і буде вилучений у наступній версії.

--etcd-cafile string

Файл центру сертифікації SSL, який використовується для захисту звʼязку etcd.

--etcd-certfile string

Файл SSL-сертифікату, який використовується для захисту звʼязку etcd.

--etcd-compaction-interval duration     Типово: 5m0s

Інтервал запитів на ущільнення. Якщо 0, то запит на ущільнення від apiserver вимкнено.

--etcd-count-metric-poll-period duration     Типово: 1m0s

Частота опитування etcd для кількості ресурсів за типом. 0 вимикає збір метрик.

--etcd-db-metric-poll-interval duration     Типово: 30s

Інтервал запитів на опитування etcd та оновлення метрики. 0 вимикає збір метрики

--etcd-healthcheck-timeout duration     Типово: 2s

Тайм-аут для перевірки стану etcd.

--etcd-keyfile string

Файл ключа SSL, який використовується для захисту комунікації etcd.

--etcd-prefix string     Типово: "/registry"

Префікс для додавання до всіх шляхів до ресурсів у etcd.

--etcd-readycheck-timeout duration     Типово: 2s

Тайм-аут для перевірки готовності etcd

--etcd-servers strings

Список etcd серверів для зʼєднання (scheme://ip: port), через кому.

--etcd-servers-overrides strings

Окремі перевизначення серверів etcd для кожного ресурсу, через кому. Формат перевизначення: група/ресурс#сервери, де сервери — це URL-адреси, розділені крапкою з комою. Зауважте, що це стосується лише ресурсів, скомпільованих у цей двійковий файл сервера.

--event-ttl duration     Типово: 1h0m0s

Кількість часу для збереження подій.

--external-hostname string

Імʼя хоста, яке використовуватиметься під час генерації зовнішніх URL-адрес для цього master (наприклад, Swagger API Docs або OpenID Discovery).

--feature-gates colonSeparatedMultimapStringString

Розділений комами список пар component:key=value, які описують функціональні можливості для альфа/експериментальних можливостей різних компонентів.
Якщо компонент не вказано, стандартно використовується "kube". Цей прапорець можна викликати багаторазово. Наприклад: --feature-gates 'wardle:featureA=true,wardle:featureB=false' --feature-gates 'kube:featureC=true'. Можливі варіанти:
kube:APIResponseCompression=true|false (BETA — default=true)
kube:APIServerIdentity=true|false (BETA — default=true)
kube:APIServerTracing=true|false (BETA — default=true)
kube:APIServingWithRoutine=true|false (ALPHA — default=false)
kube:AllAlpha=true|false (ALPHA — default=false)
kube:AllBeta=true|false (BETA — default=false)
kube:AnonymousAuthConfigurableEndpoints=true|false (ALPHA — default=false)
kube:AnyVolumeDataSource=true|false (BETA — default=true)
kube:AuthorizeNodeWithSelectors=true|false (ALPHA — default=false)
kube:AuthorizeWithSelectors=true|false (ALPHA — default=false)
kube:CPUManagerPolicyAlphaOptions=true|false (ALPHA — default=false)
kube:CPUManagerPolicyBetaOptions=true|false (BETA — default=true)
kube:CPUManagerPolicyOptions=true|false (BETA — default=true)
kube:CRDValidationRatcheting=true|false (BETA — default=true)
kube:CSIMigrationPortworx=true|false (BETA — default=true)
kube:CSIVolumeHealth=true|false (ALPHA — default=false)
kube:CloudControllerManagerWebhook=true|false (ALPHA — default=false)
kube:ClusterTrustBundle=true|false (ALPHA — default=false)
kube:ClusterTrustBundleProjection=true|false (ALPHA — default=false)
kube:ComponentSLIs=true|false (BETA — default=true)
kube:ConcurrentWatchObjectDecode=true|false (BETA — default=false)
kube:ConsistentListFromCache=true|false (BETA — default=true)
kube:ContainerCheckpoint=true|false (BETA — default=true)
kube:ContextualLogging=true|false (BETA — default=true)
kube:CoordinatedLeaderElection=true|false (ALPHA — default=false)
kube:CronJobsScheduledAnnotation=true|false (BETA — default=true)
kube:CrossNamespaceVolumeDataSource=true|false (ALPHA — default=false)
kube:CustomCPUCFSQuotaPeriod=true|false (ALPHA — default=false)
kube:CustomResourceFieldSelectors=true|false (BETA — default=true)
kube:DRAControlPlaneController=true|false (ALPHA — default=false)
kube:DisableAllocatorDualWrite=true|false (ALPHA — default=false)
kube:DisableNodeKubeProxyVersion=true|false (BETA — default=true)
kube:DynamicResourceAllocation=true|false (ALPHA — default=false)
kube:EventedPLEG=true|false (ALPHA — default=false)
kube:GracefulNodeShutdown=true|false (BETA — default=true)
kube:GracefulNodeShutdownBasedOnPodPriority=true|false (BETA — default=true)
kube:HPAScaleToZero=true|false (ALPHA — default=false)
kube:HonorPVReclaimPolicy=true|false (BETA — default=true)
kube:ImageMaximumGCAge=true|false (BETA — default=true)
kube:ImageVolume=true|false (ALPHA — default=false)
kube:InPlacePodVerticalScaling=true|false (ALPHA — default=false)
kube:InTreePluginPortworxUnregister=true|false (ALPHA — default=false)
kube:InformerResourceVersion=true|false (ALPHA — default=false)
kube:JobBackoffLimitPerIndex=true|false (BETA — default=true)
kube:JobManagedBy=true|false (ALPHA — default=false)
kube:JobPodReplacementPolicy=true|false (BETA — default=true)
kube:JobSuccessPolicy=true|false (BETA — default=true)
kube:KubeletCgroupDriverFromCRI=true|false (BETA — default=true)
kube:KubeletInUserNamespace=true|false (ALPHA — default=false)
kube:KubeletPodResourcesDynamicResources=true|false (ALPHA — default=false)
kube:KubeletPodResourcesGet=true|false (ALPHA — default=false)
kube:KubeletSeparateDiskGC=true|false (BETA — default=true)
kube:KubeletTracing=true|false (BETA — default=true)
kube:LoadBalancerIPMode=true|false (BETA — default=true)
kube:LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (BETA — default=false)
kube:LoggingAlphaOptions=true|false (ALPHA — default=false)
kube:LoggingBetaOptions=true|false (BETA — default=true)
kube:MatchLabelKeysInPodAffinity=true|false (BETA — default=true)
kube:MatchLabelKeysInPodTopologySpread=true|false (BETA — default=true)
kube:MaxUnavailableStatefulSet=true|false (ALPHA — default=false)
kube:MemoryManager=true|false (BETA — default=true)
kube:MemoryQoS=true|false (ALPHA — default=false)
kube:MultiCIDRServiceAllocator=true|false (BETA — default=false)
kube:MutatingAdmissionPolicy=true|false (ALPHA — default=false)
kube:NFTablesProxyMode=true|false (BETA — default=true)
kube:NodeInclusionPolicyInPodTopologySpread=true|false (BETA — default=true)
kube:NodeLogQuery=true|false (BETA — default=false)
kube:NodeSwap=true|false (BETA — default=true)
kube:OpenAPIEnums=true|false (BETA — default=true)
kube:PodAndContainerStatsFromCRI=true|false (ALPHA — default=false)
kube:PodDeletionCost=true|false (BETA — default=true)
kube:PodIndexLabel=true|false (BETA — default=true)
kube:PodLifecycleSleepAction=true|false (BETA — default=true)
kube:PodReadyToStartContainersCondition=true|false (BETA — default=true)
kube:PortForwardWebsockets=true|false (BETA — default=true)
kube:ProcMountType=true|false (BETA — default=false)
kube:QOSReserved=true|false (ALPHA — default=false)
kube:RecoverVolumeExpansionFailure=true|false (ALPHA — default=false)
kube:RecursiveReadOnlyMounts=true|false (BETA — default=true)
kube:RelaxedEnvironmentVariableValidation=true|false (ALPHA — default=false)
kube:ReloadKubeletServerCertificateFile=true|false (BETA — default=true)
kube:ResilientWatchCacheInitialization=true|false (BETA — default=true)
kube:ResourceHealthStatus=true|false (ALPHA — default=false)
kube:RetryGenerateName=true|false (BETA — default=true)
kube:RotateKubeletServerCertificate=true|false (BETA — default=true)
kube:RuntimeClassInImageCriApi=true|false (ALPHA — default=false)
kube:SELinuxMount=true|false (ALPHA — default=false)
kube:SELinuxMountReadWriteOncePod=true|false (BETA — default=true)
kube:SchedulerQueueingHints=true|false (BETA — default=false)
kube:SeparateCacheWatchRPC=true|false (BETA — default=true)
kube:SeparateTaintEvictionController=true|false (BETA — default=true)
kube:ServiceAccountTokenJTI=true|false (BETA — default=true)
kube:ServiceAccountTokenNodeBinding=true|false (BETA — default=true)
kube:ServiceAccountTokenNodeBindingValidation=true|false (BETA — default=true)
kube:ServiceAccountTokenPodNodeInfo=true|false (BETA — default=true)
kube:ServiceTrafficDistribution=true|false (BETA — default=true)
kube:SidecarContainers=true|false (BETA — default=true)
kube:SizeMemoryBackedVolumes=true|false (BETA — default=true)
kube:StatefulSetAutoDeletePVC=true|false (BETA — default=true)
kube:StorageNamespaceIndex=true|false (BETA — default=true)
kube:StorageVersionAPI=true|false (ALPHA — default=false)
kube:StorageVersionHash=true|false (BETA — default=true)
kube:StorageVersionMigrator=true|false (ALPHA — default=false)
kube:StrictCostEnforcementForVAP=true|false (BETA — default=false)
kube:StrictCostEnforcementForWebhooks=true|false (BETA — default=false)
kube:StructuredAuthenticationConfiguration=true|false (BETA — default=true)
kube:StructuredAuthorizationConfiguration=true|false (BETA — default=true)
kube:SupplementalGroupsPolicy=true|false (ALPHA — default=false)
kube:TopologyAwareHints=true|false (BETA — default=true)
kube:TopologyManagerPolicyAlphaOptions=true|false (ALPHA — default=false)
kube:TopologyManagerPolicyBetaOptions=true|false (BETA — default=true)
kube:TopologyManagerPolicyOptions=true|false (BETA — default=true)
kube:TranslateStreamCloseWebsocketRequests=true|false (BETA — default=true)
kube:UnauthenticatedHTTP2DOSMitigation=true|false (BETA — default=true)
kube:UnknownVersionInteroperabilityProxy=true|false (ALPHA — default=false)
kube:UserNamespacesPodSecurityStandards=true|false (ALPHA — default=false)
kube:UserNamespacesSupport=true|false (BETA — default=false)
kube:VolumeAttributesClass=true|false (BETA — default=false)
kube:VolumeCapacityPriority=true|false (ALPHA — default=false)
kube:WatchCacheInitializationPostStartHook=true|false (BETA — default=false)
kube:WatchFromStorageWithoutResourceVersion=true|false (BETA — default=false)
kube:WatchList=true|false (ALPHA — default=false)
kube:WatchListClient=true|false (BETA — default=false)
kube:WinDSR=true|false (ALPHA — default=false)
kube:WinOverlay=true|false (BETA — default=true)
kube:WindowsHostNetwork=true|false (ALPHA — default=true)

--goaway-chance float

Щоб запобігти застряганню HTTP/2-клієнтів на одному apiserver, випадково закрийте зʼєднання (GOAWAY). Інші запити клієнта не будуть зачеплені, і клієнт відновить зʼєднання, ймовірно, потрапивши на інший apiserver після того, як знову пройде через балансувальник навантаження. Цей аргумент задає частку запитів, які будуть відправлені GOAWAY. Кластери з одним apiserver або ті, що не використовують балансувальник навантаження, НЕ повинні вмикати цей параметр. Мінімальне значення — 0 (вимкнено), максимальне — 0.02 (1/50 запитів); 0.001 (1/1000) є рекомендованим початковим значенням.

-h, --help

Довідка kube-apiserver

--http2-max-streams-per-connection int

Обмеження, яке сервер надає клієнтам на максимальну кількість потоків у зʼєднанні HTTP/2. Нуль означає використання стандартного значення golang.

--kubelet-certificate-authority string

Шлях до файлу сертифіката центру сертифікації.

--kubelet-client-certificate string

Шлях до файлу клієнтського сертифіката для TLS.

--kubelet-client-key string

Шлях до файлу клієнтського ключа для TLS.

--kubelet-preferred-address-types strings     Типово: "Hostname,InternalDNS,InternalIP,ExternalDNS,ExternalIP"

Список бажаних типів NodeAddressTypes для зʼєднань kubelet.

--kubelet-timeout duration     Типово: 5s

Таймаут для операцій kubelet.

--kubernetes-service-node-port int

Якщо значення відмінне від нуля, майстер-сервіс Kubernetes (який створює/підтримує apiserver) матиме тип NodePort, використовуючи його як значення порту. Якщо нульове значення, майстер-сервіс Kubernetes матиме тип ClusterIP.

--lease-reuse-duration-seconds int     Типово: 60

Час у секундах, протягом якого кожна оренда використовується повторно. Менше значення допоможе уникнути повторного використання однієї і тієї ж оренди великою кількістю обʼєктів. Зауважте, що занадто мале значення може спричинити проблеми з продуктивністю на рівні сховища.

--livez-grace-period duration

Цей параметр вказує максимальний час, за який apiserver має завершити свою послідовність запуску і стати активним. З моменту запуску apiserver і до закінчення цього часу /livez вважатиме, що незавершені після запуску хуки будуть успішно завершені, а отже, повертатиме значення true.

--log-flush-frequency duration     Типово: 5s

Максимальна кількість секунд між очищеннями логів

--log-text-info-buffer-size quantity

[Alpha] У текстовому форматі з розділеними потоками виводу інформаційні повідомлення можуть буферизуватися на деякий час для підвищення продуктивності. Стандартне значення, рівне нулю байт, вимикає буферизацію. Розмір можна вказати як кількість байт (512), кратну 1000 (1K), кратну 1024 (2Ki) або степінь (3M, 4G, 5Mi, 6Gi). Увімкніть функцію LoggingAlphaOptions, щоб скористатися цією можливістю.

--log-text-split-stream

[Alpha] У текстовому форматі записувати повідомлення про помилки до stderr та інформаційні повідомлення до stdout. Стандартно до stdout записується один потік. Увімкніть функцію LoggingAlphaOptions, щоб скористатися цією можливістю.

--logging-format string     Типово: "text"

Задає формат логу. Дозволені формати: "text".

--max-connection-bytes-per-sec int

Якщо ненульове, обмежити кожне зʼєднання користувача до цієї кількості байт/сек. Наразі застосовується лише до довготривалих запитів.

--max-mutating-requests-inflight int     Типово: 200

Цей та --max-requests-inflight підсумовуються для визначення загального ліміту паралелізму сервера (який має бути додатнім), якщо --enable-priority-and-fairness має значення true. В іншому випадку цей прапорець обмежує максимальну кількість запитів, що змінюються у процесі виконання, або нульове значення повністю вимикає обмеження.

--max-requests-inflight int     Типово: 400

Це значення та --max-mutating-requests-inflight підсумовуються для визначення загального ліміту паралелізму сервера (який має бути додатнім), якщо --enable-priority-and-fairness має значення true. В іншому випадку цей прапорець обмежує максимальну кількість запитів, що не змінюються у процесі виконання, або нульове значення повністю вимикає ліміт.

--min-request-timeout int     Типово: 1800

Необовʼязкове поле, що вказує мінімальну кількість секунд, протягом яких обробник повинен тримати запит відкритим, перш ніж завершити його виконання. Наразі виконується лише обробником запитів watch, який обирає випадкове значення вище цього числа як таймаут зʼєднання, щоб розподілити навантаження.

--oidc-ca-file string

Якщо встановлено, сертифікат сервера OpenID буде перевірено одним з центрів сертифікації в oidc-ca-файлі, інакше буде використано кореневий центр сертифікації хоста.

--oidc-client-id string

Ідентифікатор клієнта для клієнта OpenID Connect повинен бути встановлений, якщо встановлено oidc-issuer-url.

--oidc-groups-claim string

Якщо вказано, імʼя власного запиту OpenID Connect для вказівки груп користувачів. Очікується, що значенням параметра буде рядок або масив рядків. Цей прапорець є експериментальним, будь ласка, зверніться до документації з автентифікації для отримання більш детальної інформації.

--oidc-groups-prefix string

Якщо вказано, до всіх груп буде додано цей префікс, щоб запобігти конфліктам з іншими стратегіями автентифікації.

--oidc-issuer-url string

URL-адреса емітента OpenID, приймається тільки схема HTTPS. Якщо встановлено, він буде використаний для перевірки OIDC JSON Web Token (JWT).

--oidc-required-claim <comma-separated 'key=value' pairs>

Пара key=value, яка описує необхідний реквізит в ідентифікаторі. Якщо встановлено, перевіряється, що реквізит присутній в ідентифікаторі з відповідним значенням. Повторіть цей прапорець, щоб вказати декілька реквізитів.

--oidc-signing-algs strings     Типово: "RS256"

Список дозволених алгоритмів асиметричного підпису JOSE через кому. JWT з підтримуваними значеннями заголовка 'alg': RS256, RS384, RS512, ES256, ES384, ES512, PS256, PS384, PS512. Значення визначені в RFC 7518 https://tools.ietf.org/html/rfc7518#section-3.1.

--oidc-username-claim string     Типово: "sub"

Запит OpenID для використання в якості імені користувача. Зауважте, що не гарантується унікальність та незмінність запитів, відмінних від стандартного ('sub'). Цей прапорець є експериментальним, будь ласка, зверніться до документації з автентифікації для отримання більш детальної інформації.

--oidc-username-prefix string

Якщо вказано, всі імена користувачів будуть доповнені цим значенням. Якщо не вказано, до імен користувачів, відмінних від "email", буде додано префікс URL-адреси емітента, щоб уникнути зіткнень. Щоб пропустити будь-яку префіксацію, вкажіть значення '-'.

--peer-advertise-ip string

Якщо встановлено і ввімкнено функцію UnknownVersionInteroperabilityProxy, цей IP буде використовуватися одноранговими kube-apiserverʼами для проксі-запитів до цього kube-apiserverʼа, коли запит не може бути оброблений одноранговим через невідповідність версій між kube-apiserʼами. Цей прапорець використовується лише у кластерах, сконфігурованих з декількома kube-apiserverʼами для забезпечення високої доступності.

--peer-advertise-port string

Якщо цей прапорець встановлено і ввімкнено функцію UnknownVersionInteroperabilityProxy, цей порт використовуватиметься одноранговими kube-apiserver'ами для проксі-запитів до цього kube-apiserver'а, коли запит не може бути оброблений одноранговим через невідповідність версій між kube-apiserver'ами. Цей прапорець використовується лише у кластерах, сконфігурованих з декількома kube-apiserver'ами для забезпечення високої доступності.

--peer-ca-file string

Якщо встановлено і ввімкнено функцію UnknownVersionInteroperabilityProxy, цей файл буде використано для перевірки сертифікатів обслуговування однорангових kube-apiserver серверів. Цей прапорець використовується лише у кластерах, сконфігурованих з декількома kube-apiserver'ами для забезпечення високої доступності.

--permit-address-sharing

Якщо це значення дорівнює true, SO_REUSEADDR буде використано при привʼязці порту. Це дозволяє паралельно привʼязуватись до підстановочних IP-адрес, таких як 0.0.0.0, і до конкретних IP-адрес, а також дозволяє уникнути очікування ядром звільнення сокетів у стані TIME_WAIT. [default=false]

--permit-port-sharing

Якщо значення true, SO_REUSEPORT буде використано при привʼязці порту, що дозволяє більш ніж одному екземпляру привʼязуватися до однієї адреси та порту. [default=false]

--profiling     Типово: true

Увімкніть профілювання через веб-інтерфейс host:port/debug/pprof/

--proxy-client-cert-file string

Клієнтський сертифікат, що використовується для підтвердження особи агрегатора або kube-apiserver, коли необхідно здійснити виклик під час запиту. Це включає проксирування запитів до користувацького API-сервера та виклики до втулків допуску webhook. Очікується, що цей сертифікат містить підпис від CA, вказаного у прапорі --requestheader-client-ca-file. Цей CA публікується в configmap 'extension-apiserver-authentication' у просторі імен kube-system. Компоненти, що отримують виклики від kube-aggregator, повинні використовувати цей CA для виконання своєї частини взаємної TLS перевірки.

--proxy-client-key-file string

Приватний ключ для клієнтського сертифіката, що використовується для підтвердження особи агрегатора або kube-apiserver, коли необхідно здійснити виклик під час запиту. Це включає проксирування запитів до користувацького API-сервера та виклики до втулків допуску webhook.

--request-timeout duration     Типово: 1m0s

Необовʼязкове поле, що вказує на тривалість, протягом якої обробник повинен тримати запит відкритим, перш ніж завершити його виконання. Це стандартний таймаут для запитів, але його можна перевизначити за допомогою прапорців, таких як --min-request-timeout для певних типів запитів.

--requestheader-allowed-names strings

Список загальних імен клієнтських сертифікатів, щоб дозволити вказувати імена користувачів у заголовках, визначених параметром --requestheader-username-headers. Якщо він порожній, можна використовувати будь-який сертифікат клієнта, підтверджений центрами сертифікації у файлі --requestheader-client-ca-file.

--requestheader-client-ca-file string

Пакет кореневих сертифікатів для перевірки клієнтських сертифікатів на вхідних запитах перед тим, як довіряти імена користувачів у заголовках, визначених параметром --requestheader-username-headers. ПОПЕРЕДЖЕННЯ: зазвичай не залежить від авторизації, яку вже виконано для вхідних запитів.

--requestheader-extra-headers-prefix strings

Список префіксів заголовків запитів для перевірки. Запропоновано X-Remote-Extra-.

--requestheader-group-headers strings

Список заголовків запитів для перевірки на наявність груп. Пропонується X-Remote-Group.

--requestheader-username-headers strings

Список заголовків запитів для перевірки на наявність імен користувачів. X-Remote-User є поширеним.

--runtime-config <comma-separated 'key=value' pairs>

Набір пар key=value, які вмикають або вимикають вбудовані API. Підтримувані параметри:
v1=true|false для основної групи API
<group>/<version>=true|false для певної групи API та версії (наприклад, apps/v1=true)
api/all=true|false контролює всі версії API
api/ga=true|false контролює всі версії API у формі v[0-9]+
api/beta=true| false контролює всі версії API форми v[0-9]+beta[0-9]+
api/alpha=true|false контролює всі версії API форми v[0-9]+alpha[0 -9]+
api/legacy застаріло та буде видалено в наступній версії

--secure-port int     Типово: 6443

Порт, на якому буде обслуговуватися HTTPS з автентифікацією та авторизацією. Його не можна вимкнути за допомогою 0.

--service-account-extend-token-expiration     Типово: true

Вмикає прогнозоване продовження терміну дії облікового запису під час генерації токенів, що допомагає безпечному переходу від застарілих токенів до привʼязаних токенів облікових записів. Якщо цей прапорець увімкнено, термін дії токенів, що вводяться, буде подовжено до 1 року, щоб запобігти несподіваним збоям під час переходу, ігноруючи значення параметра service-account-max-token-expiration.

--service-account-issuer strings

Ідентифікатор емітента токенів службового облікового запису. Емітент вказуватиме цей ідентифікатор у запиті "iss" на видачу випущених токенів. Це значення є рядком або URI. Якщо цей параметр не є дійсним URI згідно зі специфікацією OpenID Discovery 1.0, функція ServiceAccountIssuerDiscovery залишиться вимкненою, навіть якщо для функції gate буде встановлено значення true. Наполегливо рекомендується, щоб це значення відповідало специфікації OpenID: https://openid.net/specs/openid-connect-discovery-1_0.html. На практиці це означає, що service-account-issuer має бути URL-адресою https. Також наполегливо рекомендується, щоб ця URL-адреса могла обслуговувати документи виявлення OpenID за адресою {service-account-issuer}/.well-known/openid-configuration. Якщо цей прапорець вказано декілька разів, перший раз використовується для генерації токенів, а всі інші - для визначення прийнятних емітентів.

--service-account-jwks-uri string

Перевизначає URI для набору веб-ключів JSON у документі виявлення, що надсилається за адресою /.well-known/openid-configuration. Цей прапорець корисний, якщо документ виявлення та набір ключів надаються сторонам, що довіряють, за URL-адресою, відмінною від зовнішньої URL-адреси сервера API (автоматично визначеною або перевизначеною за допомогою external-hostname).

--service-account-key-file strings

File containing PEM-encoded x509 RSA or ECDSA private or public keys, used to verify ServiceAccount tokens. The specified file can contain multiple keys, and the flag can be specified multiple times with different files. If unspecified, --tls-private-key-file is used. Must be specified when --service-account-signing-key-file is provided

--service-account-lookup     Типово: true

Якщо true, підтвердити наявність токенів ServiceAccount в etcd як частину автентифікації.

--service-account-max-token-expiration duration

Максимальний термін дії токена, створеного емітентом токенів службового облікового запису. Якщо запитується дійсний TokenRequest з тривалістю дії, що перевищує це значення, буде випущено токен з тривалістю дії, що дорівнює цьому значенню.

--service-account-signing-key-file string

Шлях до файлу, який містить поточний приватний ключ емітента токенів службового облікового запису. Цим приватним ключем емітент підписуватиме видані токени ідентифікаторів.

--service-cluster-ip-range string

Діапазон IP-адрес у нотації CIDR, з якого призначаються сервісні кластерні IP-адреси. Він не повинен перетинатися з будь-якими діапазонами IP, призначеними вузлам або Podʼами. Максимальний допустимий діапазон — два двостекових CIDR.

--service-node-port-range <a string in the form 'N1-N2'>     Типово: 30000-32767

Діапазон портів для резервування для сервісів з видимістю NodePort. Він не повинен перетинатися з ефемерним діапазоном портів на вузлах. Приклад: '30000-32767'. Включно з обох кінців діапазону.

--show-hidden-metrics-for-version string

Попередня версія, для якої ви хочете показати приховані метрики. Значення має лише попередня мінорна версія, інші значення не будуть дозволені. Формат: <major>.<minor>, наприклад: '1.16'. Мета цього формату - переконатися, що ви маєте можливість помітити, що наступний реліз приховує додаткові метрики, замість того, щоб дивуватися, коли вони будуть назавжди вилучені в наступному релізі.

--shutdown-delay-duration duration

Час затримки завершення роботи. Протягом цього часу сервер продовжує обслуговувати запити у звичайному режимі. Точки доступу /healthz і /livez повертатимуть успішне завершення, але /readyz одразу ж поверне помилку. Належне завершення роботи почнється після закінчення цієї затримки. Це може бути використано для того, щоб дозволити балансувальнику навантаження припинити надсилання трафіку на цей сервер.

--shutdown-send-retry-after

Якщо значення true, HTTP-сервер продовжуватиме прослуховування доти, доки всі недовготривалі запити у процесі виконання не будуть вичерпані, під час цього вікна всі вхідні запити будуть відхилені з кодом статусу 429 та заголовком відповіді "Retry-After", крім того, встановлюється заголовок відповіді "Connection: close" для того, щоб розірвати TCP-зʼєднання, коли воно не виконується.

--shutdown-watch-termination-grace-period duration

Цей параметр, якщо його встановлено, вказує на максимальну тривалість пільгового періоду, протягом якого apiserver буде чекати, поки активні запити watch не вичерпаються під час вікна належного вимкнення сервера.

--storage-backend string

Бекенд сховища для збереження даних. Параметри: 'etcd3' (стандартно).

--storage-initialization-timeout duration     Типово: 1m0s

Максимальний час очікування ініціалізації сховища перед оголошенням готовності apiserver. Стандартно — 1m.

--storage-media-type string     Типово: "application/vnd.kubernetes.protobuf"

Тип носія для зберігання обʼєктів у сховищі. Деякі ресурси або бекенди сховища можуть підтримувати лише певний тип носія і ігноруватимуть цей параметр. Підтримувані медіа-типи: [application/json, application/yaml, application/vnd.kubernetes.protobuf].

--strict-transport-security-directives strings

Список директив для HSTS через кому. Якщо цей список порожній, то директиви HSTS не будуть додані. Приклад: 'max-age=31536000,includeSubDomains,preload'

--tls-cert-file string

Файл, що містить стандартний сертифікат x509 для HTTPS. (Сертифікат центру сертифікації, якщо такий є, додається після сертифіката сервера). Якщо HTTPS-сервіс увімкнено, а --tls-cert-file і --tls-private-key-file не вказано, для публічної адреси буде згенеровано самопідписаний сертифікат і ключ, які буде збережено в теці, вказаній в --cert-dir.

--tls-cipher-suites strings

Розділений комами список наборів шифрів для сервера. Якщо не вказано, буде використано стандартний набір шифрів Go.
Значення, яким надається перевага: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305, TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305, TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256.
Небезпечні значення: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_3DES_EDE_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_RC4_128_SHA.

--tls-min-version string

Мінімальна підтримувана версія TLS. Можливі значення: VersionTLS10, VersionTLS11, VersionTLS12, VersionTLS13

--tls-private-key-file string

Файл, що містить стандартний приватний ключ x509, який відповідає --tls-cert-file.

--tls-sni-cert-key string

Пара шляхів до файлів сертифіката x509 і приватного ключа, до яких за бажанням додається список доменних шаблонів, які є повними доменними іменами, можливо, з префіксальними підстановчими сегментами. Доменні шаблони також дозволяють використовувати IP-адреси, але IP-адреси слід використовувати лише в тому випадку, якщо apiserver має доступ до IP-адреси, запитуваної клієнтом. Якщо шаблони домену не надано, витягуються імена сертифікатів. Збіги без підстановочних знаків мають перевагу над збігами з підстановочними знаками, а явні шаблони доменів мають перевагу над отриманими іменами. Для кількох пар ключ/сертифікат використовуйте --tls-sni-cert-key кілька разів. Приклади: "example.crt,example.key" або "foo.crt,foo.key:*.foo.com,foo.com".

--token-auth-file string

Якщо встановлено, файл, який буде використано для захисту захищеного порту сервера API за допомогою автентифікації за допомогою токенів.

--tracing-config-file string

Файл з конфігурацією трасування apiserver.

-v, --v int

число рівня деталізації логу

--version version[=true]

--version, --version=raw виводить інформацію про версію та виходить; --version=vX.Y.Z... встановлює вказану версію

--vmodule pattern=N,...

список параметрів pattern=N, розділених комами, для файлового фільтрування логу (працює лише для текстового формату логу).

--watch-cache     Типово: true

Увімкніть кешування watch в apiserver

--watch-cache-sizes strings

Налаштування розміру кешу для деяких ресурсів (pods, nodes і т.д.), через кому. Формат індивідуальних налаштувань: resource[.group]#size, де resource — малі літери множини (без версії), group пропущено для ресурсів apiVersion v1 (застаріле ядро API) і включено для інших, а size — число. Цей параметр має значення лише для ресурсів, вбудованих у apiserver, а не для ресурсів, визначених CRD або зібраних із зовнішніх серверів, і використовується лише у випадку, якщо увімкнено watch-cache. Єдиним допустимим значенням розміру є нуль, що означає вимкнення кешування watch для відповідного ресурсу; усі ненульові значення є еквівалентними і означають, що кешування для цього ресурсу не вимкнено.

6.12.5 - kube-controller-manager

Огляд

Менеджер контролерів Kubernetes — це демон, який вбудовує основні цикли керування, що постачаються з Kubernetes. У робототехніці та автоматизації автоматизації, цикл керування — це нескінченний цикл, який регулює стан системи. У Kubernetes контролер — це цикл керування, який відстежує спільний стан кластера через apiserver і вносить зміни, намагаючись перевести поточний стан у бажаний. Приклади контролерів, які постачаються з Kubernetes сьогодні це контролер реплікації, контролер точок доступу, контролер просторів імен та контролер службових облікових записів.

kube-controller-manager [flags]

Параметри

https://kubernetes.io/docs/concepts/cluster-administration/node-shutdown/#storage-force-detach-on-timeout32     Типово: 5
--allocate-node-cidrs

Чи повинні CIDR для Podʼів бути виділені та налаштовані хмарним провайдером.

--allow-metric-labels stringToString     Типово: []

Зіставляє metric-label зі списком дозволених значень цієї мітки. Формат ключа — <MetricName>,<LabelName>. Формат значення — <дозволене_значення>,<дозволене_значення>...наприклад, metric1,label1='v1,v2,v3', metric1,label2='v1,v2,v3' metric2,label1='v1,v2,v3'.

--allow-metric-labels-manifest string

Шлях до файлу маніфесту, який містить зіставлення allow-list. Формат файлу такий самий, як і у прапорця --allow-metric-labels. Зауважте, що прапорець --allow-metric-labels замінить файл маніфесту.

--attach-detach-reconcile-sync-period duration     Типово: 1m0s

Час очікування синхронізації узгоджувача між приєднанням та відʼєднанням томів. Ця тривалість має бути більшою за одну секунду, і збільшення цього значення порівняно зі стандартним може призвести до того, що томи не будуть збігатися з Podʼами.

--authentication-kubeconfig string

файл kubeconfig, що вказує на 'core' сервер kubernetes з достатніми правами для створення tokenreviews.authentication.k8s.io. Цей параметр не є обовʼязковим. Якщо він порожній, всі запити токенів вважаються анонімними, і жоден клієнтський центр сертифікації не шукається в кластері.

--authentication-skip-lookup

Якщо значення false, authentication-kubeconfig буде використано для пошуку відсутньої конфігурації автентифікації в кластері.

--authentication-token-webhook-cache-ttl duration     Типово: 10s

Тривалість кешування відповідей від автентифікатора токенів webhook.

--authentication-tolerate-lookup-failure

Якщо це значення встановлено, невдачі у пошуку відсутньої конфігурації автентифікації в кластері не вважатимуться фатальними. Зауважте, що це може призвести до автентифікації, яка розглядає всі запити як анонімні.

--authorization-always-allow-paths strings     Типово: "/healthz,/readyz,/livez"

Список HTTP-шляхів, які пропускаються під час авторизації, тобто авторизуються без звʼязку з 'core' сервером kubernetes.

--authorization-kubeconfig string

файл kubeconfig, що вказує на 'core' сервер kubernetes з достатніми правами для створення subjectaccessreviews.authorization.k8s.io. Цей параметр не є обовʼязковим. Якщо він порожній, всі запити, не пропущені авторизацією, будуть заборонені.

--authorization-webhook-cache-authorized-ttl duration     Типово: 10s

Тривалість кешування 'authorized' відповідей від авторизатора вебхука.

--authorization-webhook-cache-unauthorized-ttl duration     Типово: 10s

Тривалість кешування 'unauthorized' відповідей від авторизатора вебхука.

--bind-address string     Типово: 0.0.0.0

IP-адреса, на якій буде прослуховуватися порт --secure-port. Відповідний інтерфейс(и) має бути доступним для решти кластера, а також для CLI/веб-клієнтів. Якщо цей параметр не вказано або вказано невизначену адресу (0.0.0.0 або ::), будуть використані всі інтерфейси та сімейства IP-адрес.

--cert-dir string

Тека, в якій знаходяться TLS-сертифікати. Якщо вказано --tls-cert-file та --tls-private-key-file, цей прапорець буде проігноровано.

--cidr-allocator-type string     Типово: "RangeAllocator"

Тип розподілювача CIDR для використання

--client-ca-file string

Якщо встановлено, будь-який запит, що надає клієнтський сертифікат, підписаний одним із центрів сертифікації у клієнтському файлі, буде автентифіковано за допомогою ідентифікатора, що відповідає загальному імені клієнтського сертифіката.

--cloud-config string

Шлях до файлу конфігурації хмарного провайдера. Порожній рядок, якщо файл конфігурації відсутній.

--cloud-provider string

Провайдер хмарних сервісів. Порожній рядок для відсутності провайдера.

--cluster-cidr string

Діапазон CIDR для вузлів у кластері. Потрібно, щоб --allocate-node-cidrs мав значення true

--cluster-name string     Типово: "kubernetes"

Префікс екземпляру для кластера.

--cluster-signing-cert-file string

Файл, що містить PEM-кодований сертифікат X509 CA, який використовується для випуску кластерних сертифікатів. Якщо вказано, можна не вказувати більш специфічний прапорець --cluster-signing-*.

--cluster-signing-duration duration     Типово: 8760h0m0s

Буде вказано максимальний термін дії підписаних сертифікатів. Окремі CSR можуть запитувати коротші сертифікати, встановивши spec.expirationSeconds.

--cluster-signing-key-file string

Імʼя файлу, що містить PEM-кодований закритий ключ RSA або ECDSA, який використовується для підпису кластерних сертифікатів. Якщо вказано, не можна вказувати більш специфічний прапорець --cluster-signing-*.

--cluster-signing-kube-apiserver-client-cert-file string

Файл, що містить PEM-кодований сертифікат X509 CA, який використовується для випуску сертифікатів для підписувача kubernetes.io/kube-apiserver-client. Якщо вказано, --cluster-signing-{cert,key}-file не має бути задано.

--cluster-signing-kube-apiserver-client-key-file string

Файл, що містить PEM-кодований приватний ключ RSA або ECDSA, який використовується для підпису сертифікатів для підписувача kubernetes.io/kube-apiserver-client. Якщо вказано, --cluster-signing-{cert,key}-file не має бути задано.

--cluster-signing-kubelet-client-cert-file string

Файл, що містить PEM-кодований сертифікат X509 CA, який використовується для випуску сертифікатів для підписувача kubernetes.io/kube-apiserver-client-kubelet. Якщо вказано, --cluster-signing-{cert,key}-file не має бути задано.

--cluster-signing-kubelet-client-key-file string

Файл, що містить PEM-кодований приватний ключ RSA або ECDSA, який використовується для підпису сертифікатів для підписувача kubernetes.io/kube-apiserver-client-kubelet. Якщо вказано, --cluster-signing-{cert,key}-file не має бути задано.

--cluster-signing-kubelet-serving-cert-file string

Файл, що містить PEM-кодований сертифікат X509 CA, який використовується для випуску сертифікатів для підписувача kubernetes.io/kubelet-serving. Якщо вказано, --cluster-signing-{cert,key}-file не має бути задано.

--cluster-signing-kubelet-serving-key-file string

Файл, що містить PEM-кодований приватний ключ RSA або ECDSA, який використовується для підпису сертифікатів для підписувача kubernetes.io/kubelet-serving. Якщо вказано, --cluster-signing-{cert,key}-file не має бути задано.

--cluster-signing-legacy-unknown-cert-file string

Файл, що містить PEM-кодований сертифікат X509 CA, який використовується для видачі сертифікатів для підписувача kubernetes.io/legacy-unknown. Якщо вказано, --cluster-signing-{cert,key}-file не має бути задано.

--cluster-signing-legacy-unknown-key-file string

Файл, що містить PEM-кодований приватний ключ RSA або ECDSA, який використовується для підпису сертифікатів для kubernetes.io/legacy-unknown signer. Якщо вказано, --cluster-signing-{cert,key}-file не має бути задано.

--concurrent-cron-job-syncs int32     Типово: 5

Кількість обʼєктів завдання cron, яким дозволено синхронізуватися одночасно. Більша кількість = швидше реагують завдання, але більше навантаження на процесор (і мережу)

--concurrent-deployment-syncs int32     Типово: 5

Кількість обʼєктів deployment, яким дозволено синхронізуватися одночасно. Більша кількість = швидше розгортання, але більше навантаження на процесор (і мережу)

--concurrent-endpoint-syncs int32     Типово: 5

Кількість операцій синхронізації точок доступу, які будуть виконуватися одночасно. Більша кількість = швидше оновлення точок доступу, але більше навантаження на процесор (і мережу)

--concurrent-ephemeralvolume-syncs int32     Типово: 5

Кількість операцій синхронізації ефемерних томів, які будуть виконуватися одночасно. Більша кількість = швидше оновлення ефемерних томів, але більше навантаження на процесор (і мережу)

Кількість обʼєктів Job, яким дозволено синхронізуватися одночасно. Більша кількість = швидше реагують завдання, але більше навантаження на процесор (і мережу)

--concurrent-namespace-syncs int32     Типово: 10

Кількість обʼєктів namespace, яким дозволено синхронізуватися одночасно. Більша кількість = більш оперативне завершення роботи простору імен, але більше навантаження на процесор (і мережу)

--concurrent-rc-syncs int32     Типово: 5

Кількість контролерів реплікації, яким дозволено синхронізуватися одночасно. Більша кількість = більш оперативне керування реплікацією, але більше навантаження на процесор (і мережу)

--concurrent-replicaset-syncs int32     Типово: 5

Кількість replica set, які дозволено синхронізувати одночасно. Більша кількість = більш оперативне керування реплікацією, але більше навантаження на процесор (і мережу)

--concurrent-resource-quota-syncs int32     Типово: 5

Кількість квот ресурсів, які дозволено синхронізувати одночасно. Більша кількість = більш оперативне керування квотами, але більше навантаження на процесор (і мережу)

--concurrent-service-endpoint-syncs int32     Типово: 5

Кількість операцій синхронізації точок доступу сервісів, які будуть виконуватися одночасно. Чим більше число, тим швидше оновлюватиметься зріз кінцевих точок, але більше завантажуватиметься процесор (і мережа). Стандартно дорівнює 5.

--concurrent-service-syncs int32     Типово: 1

Кількість сервісів, яким дозволено синхронізуватися одночасно. Більша кількість = більш оперативне управління послугами, але більше навантаження на процесор (і мережу)

--concurrent-serviceaccount-token-syncs int32     Типово: 5

Кількість обʼєктів токенів службових облікових записів, яким дозволено синхронізуватися одночасно. Більша кількість = швидша генерація токенів, але більше навантаження на процесор (і мережу)

--concurrent-statefulset-syncs int32     Типово: 5

Кількість обʼєктів statefulset, яким дозволено синхронізуватися одночасно. Більша кількість = більш швидкодіючі statefulsets, але більше навантаження на процесор (і мережу)

--concurrent-ttl-after-finished-syncs int32     Типово: 5

Кількість обробників ttl-after-finished-controller, яким дозволено синхронізуватися одночасно.

--concurrent-validating-admission-policy-status-syncs int32     Типово: 5

Кількість обробників ValidatingAdmissionPolicyStatusController, яким дозволено синхронізуватися одночасно.

--configure-cloud-routes     Типово: true

Чи повинні CIDR, виділені за допомогою allocate-node-cidrs, бути налаштовані на хмарному провайдері.

--contention-profiling

Активувати профілювання блоків, якщо профілювання увімкнено

--controller-start-interval duration

Інтервал між запуском менеджерів контролерів.

--controllers strings     Типово: "*"

Перелік контролерів для ввімкнення. '*' вмикає всі типово визначені контролери, 'foo' вмикає контролер з назвою 'foo', '-foo' вимикає контролер з назвою 'foo'.
Всі контролери: bootstrap-signer-controller, certificatesigningrequest-approving-controller, certificatesigningrequest-cleaner-controller, certificatesigningrequest-signing-controller, cloud-node-lifecycle-controller, clusterrole-aggregation-controller, cronjob-controller, daemonset-controller, deployment-controller, disruption-controller, endpoints-controller, endpointslice-controller, endpointslice-mirroring-controller, ephemeral-volume-controller, garbage-collector-controller, horizontal-pod-autoscaler-controller, job-controller, legacy-serviceaccount-token-cleaner-controller, namespace-controller, node-ipam-controller, node-lifecycle-controller, node-route-controller, persistentvolume-attach-detach-controller, persistentvolume-binder-controller, persistentvolume-expander-controller, persistentvolume-protection-controller, persistentvolumeclaim-protection-controller, pod-garbage-collector-controller, replicaset-controller, replicationcontroller-controller, resourceclaim-controller, resourcequota-controller, root-ca-certificate-publisher-controller, service-cidr-controller, service-lb-controller, serviceaccount-controller, serviceaccount-token-controller, statefulset-controller, storage-version-migrator-controller, storageversion-garbage-collector-controller, taint-eviction-controller, token-cleaner-controller, ttl-after-finished-controller, ttl-controller, validatingadmissionpolicy-status-controller
Стандартно вимкнені контролери: bootstrap-signer-controller, token-cleaner-controller

--disable-attach-detach-reconcile-sync

Вимкнути синхронізацію узгоджувача приєднання томів. Вимкнення цієї опції може призвести до невідповідності томів і Podʼів. Використовуйте з обережністю.

--disable-force-detach-on-timeout

Заборонити примусове відʼєднання томів на основі максимального часу відʼєднання та стану вузла. Якщо цей прапорець встановлено у true, необхідно використовувати функцію примусового вимкнення вузла для відновлення після збою вузла. Докладні відомості див. на сторінці https://kubernetes.io/docs/concepts/cluster-administration/node-shutdown/#storage-force-detach-on-timeout

--disable-http2-serving

Якщо значення true, HTTP2-сервіс буде вимкнено [default=false].

--disabled-metrics strings

Цей прапорець забезпечує аварійний вихід для метрик, що поводяться не належним чином. Щоб вимкнути метрику, ви маєте вказати її повну назву. Застереження: вимкнення метрик має вищий пріоритет, ніж показ прихованих метрик.

--emulated-version strings

У версіях різні компоненти емулюють свої можливості (API, функції, ...) інших компонентів.
Якщо встановлено, компонент буде емулювати поведінку цієї версії замість базової двійкової версії.
Формат версії може бути лише major.minor, наприклад: '--emulated-version=wardle=1.2,kube=1.31'. Можливі варіанти:
kube=1.31..1.31 (default=1.31) Якщо компонент не вказано, стандартно використовується "kube"

--enable-dynamic-provisioning     Типово: true

Увімкніть динамічне створення ресурсів для середовищ, які його підтримують.

--enable-garbage-collector     Типово: true

Вмикає загальний збирач сміття. ПОВИНЕН бути синхронізований з відповідним прапорцем kube-apiserver.

--enable-hostpath-provisioner

Вмикає забезпечення HostPath PV під час роботи без хмарного провайдера. Це дозволяє тестувати та розробляти функції резервування. HostPath provisioning не підтримується жодним чином, не працюватиме в багатовузловому кластері і не повинен використовуватися ні для чого іншого, окрім тестування або розробки.

--enable-leader-migration

Чи вмикати міграцію лідера контролера.

--endpoint-updates-batch-period duration

Тривалість періоду пакетного оновлення точок доступу. Обробка змін у пакунках буде затримана на цей час, щоб обʼєднати їх з потенційними майбутніми оновленнями і зменшити загальну кількість оновлень точок доступу. Більша кількість = більша затримка програмування точок доступу, але менша кількість згенерованих ревізій точок доступу

--endpointslice-updates-batch-period duration

Тривалість періоду пакетного оновлення зрізу точок доступу. Обробка змін у пакунках буде затримана на цей час, щоб обʼєднати їх з потенційними майбутніми оновленнями і зменшити загальну кількість оновлень точок доступу. Більша кількість = більша затримка програмування точок доступу, але менша кількість згенерованих ревізій точок доступу

--external-cloud-volume-plugin string

Втулок для використання, коли хмарний провайдер встановлений як зовнішній. Може бути порожнім, слід встановлювати лише тоді, коли хмарний провайдер є зовнішнім. Наразі використовується для дозволу роботи node-ipam-controller, persistentvolume-binder-controller, persistentvolume-expander-controller та attach-detach-controller у вбудованих хмарних провайдерів.

--feature-gates colonSeparatedMultimapStringString

Розділений комами список пар component:key=value, які описують функціональні можливості для альфа/експериментальних можливостей різних компонентів.
Якщо компонент не вказано, стандартно використовується "kube". Цей прапорець можна викликати багаторазово. Наприклад: --feature-gates 'wardle:featureA=true,wardle:featureB=false' --feature-gates 'kube:featureC=true'. Можливі варіанти:
kube:APIResponseCompression=true|false (BETA — default=true)
kube:APIServerIdentity=true|false (BETA — default=true)
kube:APIServerTracing=true|false (BETA — default=true)
kube:APIServingWithRoutine=true|false (ALPHA — default=false)
kube:AllAlpha=true|false (ALPHA — default=false)
kube:AllBeta=true|false (BETA — default=false)
kube:AnonymousAuthConfigurableEndpoints=true|false (ALPHA — default=false)
kube:AnyVolumeDataSource=true|false (BETA — default=true)
kube:AuthorizeNodeWithSelectors=true|false (ALPHA — default=false)
kube:AuthorizeWithSelectors=true|false (ALPHA — default=false)
kube:CPUManagerPolicyAlphaOptions=true|false (ALPHA — default=false)
kube:CPUManagerPolicyBetaOptions=true|false (BETA — default=true)
kube:CPUManagerPolicyOptions=true|false (BETA — default=true)
kube:CRDValidationRatcheting=true|false (BETA — default=true)
kube:CSIMigrationPortworx=true|false (BETA — default=true)
kube:CSIVolumeHealth=true|false (ALPHA — default=false)
kube:CloudControllerManagerWebhook=true|false (ALPHA — default=false)
kube:ClusterTrustBundle=true|false (ALPHA — default=false)
kube:ClusterTrustBundleProjection=true|false (ALPHA — default=false)
kube:ComponentSLIs=true|false (BETA — default=true)
kube:ConcurrentWatchObjectDecode=true|false (BETA — default=false)
kube:ConsistentListFromCache=true|false (BETA — default=true)
kube:ContainerCheckpoint=true|false (BETA — default=true)
kube:ContextualLogging=true|false (BETA — default=true)
kube:CoordinatedLeaderElection=true|false (ALPHA — default=false)
kube:CronJobsScheduledAnnotation=true|false (BETA — default=true)
kube:CrossNamespaceVolumeDataSource=true|false (ALPHA — default=false)
kube:CustomCPUCFSQuotaPeriod=true|false (ALPHA — default=false)
kube:CustomResourceFieldSelectors=true|false (BETA — default=true)
kube:DRAControlPlaneController=true|false (ALPHA — default=false)
kube:DisableAllocatorDualWrite=true|false (ALPHA — default=false)
kube:DisableNodeKubeProxyVersion=true|false (BETA — default=true)
kube:DynamicResourceAllocation=true|false (ALPHA — default=false)
kube:EventedPLEG=true|false (ALPHA — default=false)
kube:GracefulNodeShutdown=true|false (BETA — default=true)
kube:GracefulNodeShutdownBasedOnPodPriority=true|false (BETA — default=true)
kube:HPAScaleToZero=true|false (ALPHA — default=false)
kube:HonorPVReclaimPolicy=true|false (BETA — default=true)
kube:ImageMaximumGCAge=true|false (BETA — default=true)
kube:ImageVolume=true|false (ALPHA — default=false)
kube:InPlacePodVerticalScaling=true|false (ALPHA — default=false)
kube:InTreePluginPortworxUnregister=true|false (ALPHA — default=false)
kube:InformerResourceVersion=true|false (ALPHA — default=false)
kube:JobBackoffLimitPerIndex=true|false (BETA — default=true)
kube:JobManagedBy=true|false (ALPHA — default=false)
kube:JobPodReplacementPolicy=true|false (BETA — default=true)
kube:JobSuccessPolicy=true|false (BETA — default=true)
kube:KubeletCgroupDriverFromCRI=true|false (BETA — default=true)
kube:KubeletInUserNamespace=true|false (ALPHA — default=false)
kube:KubeletPodResourcesDynamicResources=true|false (ALPHA — default=false)
kube:KubeletPodResourcesGet=true|false (ALPHA — default=false)
kube:KubeletSeparateDiskGC=true|false (BETA — default=true)
kube:KubeletTracing=true|false (BETA — default=true)
kube:LoadBalancerIPMode=true|false (BETA — default=true)
kube:LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (BETA — default=false)
kube:LoggingAlphaOptions=true|false (ALPHA — default=false)
kube:LoggingBetaOptions=true|false (BETA — default=true)
kube:MatchLabelKeysInPodAffinity=true|false (BETA — default=true)
kube:MatchLabelKeysInPodTopologySpread=true|false (BETA — default=true)
kube:MaxUnavailableStatefulSet=true|false (ALPHA — default=false)
kube:MemoryManager=true|false (BETA — default=true)
kube:MemoryQoS=true|false (ALPHA — default=false)
kube:MultiCIDRServiceAllocator=true|false (BETA — default=false)
kube:MutatingAdmissionPolicy=true|false (ALPHA — default=false)
kube:NFTablesProxyMode=true|false (BETA — default=true)
kube:NodeInclusionPolicyInPodTopologySpread=true|false (BETA — default=true)
kube:NodeLogQuery=true|false (BETA — default=false)
kube:NodeSwap=true|false (BETA — default=true)
kube:OpenAPIEnums=true|false (BETA — default=true)
kube:PodAndContainerStatsFromCRI=true|false (ALPHA — default=false)
kube:PodDeletionCost=true|false (BETA — default=true)
kube:PodIndexLabel=true|false (BETA — default=true)
kube:PodLifecycleSleepAction=true|false (BETA — default=true)
kube:PodReadyToStartContainersCondition=true|false (BETA — default=true)
kube:PortForwardWebsockets=true|false (BETA — default=true)
kube:ProcMountType=true|false (BETA — default=false)
kube:QOSReserved=true|false (ALPHA — default=false)
kube:RecoverVolumeExpansionFailure=true|false (ALPHA — default=false)
kube:RecursiveReadOnlyMounts=true|false (BETA — default=true)
kube:RelaxedEnvironmentVariableValidation=true|false (ALPHA — default=false)
kube:ReloadKubeletServerCertificateFile=true|false (BETA — default=true)
kube:ResilientWatchCacheInitialization=true|false (BETA — default=true)
kube:ResourceHealthStatus=true|false (ALPHA — default=false)
kube:RetryGenerateName=true|false (BETA — default=true)
kube:RotateKubeletServerCertificate=true|false (BETA — default=true)
kube:RuntimeClassInImageCriApi=true|false (ALPHA — default=false)
kube:SELinuxMount=true|false (ALPHA — default=false)
kube:SELinuxMountReadWriteOncePod=true|false (BETA — default=true)
kube:SchedulerQueueingHints=true|false (BETA — default=false)
kube:SeparateCacheWatchRPC=true|false (BETA — default=true)
kube:SeparateTaintEvictionController=true|false (BETA — default=true)
kube:ServiceAccountTokenJTI=true|false (BETA — default=true)
kube:ServiceAccountTokenNodeBinding=true|false (BETA — default=true)
kube:ServiceAccountTokenNodeBindingValidation=true|false (BETA — default=true)
kube:ServiceAccountTokenPodNodeInfo=true|false (BETA — default=true)
kube:ServiceTrafficDistribution=true|false (BETA — default=true)
kube:SidecarContainers=true|false (BETA — default=true)
kube:SizeMemoryBackedVolumes=true|false (BETA — default=true)
kube:StatefulSetAutoDeletePVC=true|false (BETA — default=true)
kube:StorageNamespaceIndex=true|false (BETA — default=true)
kube:StorageVersionAPI=true|false (ALPHA — default=false)
kube:StorageVersionHash=true|false (BETA — default=true)
kube:StorageVersionMigrator=true|false (ALPHA — default=false)
kube:StrictCostEnforcementForVAP=true|false (BETA — default=false)
kube:StrictCostEnforcementForWebhooks=true|false (BETA — default=false)
kube:StructuredAuthenticationConfiguration=true|false (BETA — default=true)
kube:StructuredAuthorizationConfiguration=true|false (BETA — default=true)
kube:SupplementalGroupsPolicy=true|false (ALPHA — default=false)
kube:TopologyAwareHints=true|false (BETA — default=true)
kube:TopologyManagerPolicyAlphaOptions=true|false (ALPHA — default=false)
kube:TopologyManagerPolicyBetaOptions=true|false (BETA — default=true)
kube:TopologyManagerPolicyOptions=true|false (BETA — default=true)
kube:TranslateStreamCloseWebsocketRequests=true|false (BETA — default=true)
kube:UnauthenticatedHTTP2DOSMitigation=true|false (BETA — default=true)
kube:UnknownVersionInteroperabilityProxy=true|false (ALPHA — default=false)
kube:UserNamespacesPodSecurityStandards=true|false (ALPHA — default=false)
kube:UserNamespacesSupport=true|false (BETA — default=false)
kube:VolumeAttributesClass=true|false (BETA — default=false)
kube:VolumeCapacityPriority=true|false (ALPHA — default=false)
kube:WatchCacheInitializationPostStartHook=true|false (BETA — default=false)
kube:WatchFromStorageWithoutResourceVersion=true|false (BETA — default=false)
kube:WatchList=true|false (ALPHA — default=false)
kube:WatchListClient=true|false (BETA — default=false)
kube:WinDSR=true|false (ALPHA — default=false)
kube:WinOverlay=true|false (BETA — default=true)
kube:WindowsHostNetwork=true|false (ALPHA — default=true)

--flex-volume-plugin-dir string     Типово: "/usr/libexec/kubernetes/kubelet-plugins/volume/exec/"

Повний шлях до теки, у якій втулок flex volume має шукати додаткові втулки сторонніх розробників.

-h, --help

Довідка kube-controller-manager

--horizontal-pod-autoscaler-cpu-initialization-period duration     Типово: 5m0s

Період після запуску Зod, коли проби CPU можуть бути пропущені.

--horizontal-pod-autoscaler-downscale-stabilization duration     Типово: 5m0s

Період, за який автомасштабування буде дивитися в минуле і не зменшуватиме масштаб нижче будь-якої рекомендації, наданої ним протягом цього періоду.

--horizontal-pod-autoscaler-initial-readiness-delay duration     Типово: 30s

Період після запуску Pod, протягом якого готовність змінюється, буде вважатися початковою готовністю.

--horizontal-pod-autoscaler-sync-period duration     Типово: 15s

Період для синхронізації кількості Podʼів у horizontal pod autoscaler.

--horizontal-pod-autoscaler-tolerance float     Типово: 0.1

Мінімальна зміна (від 1.0) у співвідношенні бажаної та фактичної метрики для того, щоб horizontal pod autoscaler розглянув можливість масштабування.

--http2-max-streams-per-connection int

Обмеження, яке сервер надає клієнтам на максимальну кількість потоків у зʼєднанні HTTP/2. Нуль означає використання стандартних значень golang.

--kube-api-burst int32     Типово: 30

Сплеск для використання під час спілкування з apiserver на kubernetes.

--kube-api-content-type string     Типово: "application/vnd.kubernetes.protobuf"

Тип вмісту запитів, що надсилаються до apiserver.

--kube-api-qps float     Типово: 20

QPS для використання під час спілкування з kubernetes apiserver.

--kubeconfig string

Шлях до файлу kubeconfig з інформацією про авторизацію та розташування майстра (розташування майстра може бути перевизначено прапорцем master).

--large-cluster-size-threshold int32     Типово: 50

Кількість вузлів, з яких node-lifecycle-controller вважає кластер великим для цілей логіки виселення. --secondary-node-eviction-rate неявно перевизначено у 0 для кластерів такого розміру або менших. Зауваження: Якщо вузли знаходяться у декількох зонах, цей поріг буде розглядатися як поріг розміру вузла зони для кожної зони, щоб визначити швидкість виселення вузла незалежно.

--leader-elect     Типово: true

Запускає клієнта виборів лідера і отримує лідерство перед виконанням основного циклу. Увімкніть цю опцію під час запуску реплікованих компонентів для забезпечення високої доступності.

--leader-elect-lease-duration duration     Типово: 15s

Тривалість, протягом якої кандидати, що не є лідерами, чекатимуть після поновлення лідерства, перш ніж спробувати зайняти лідерство в лідируючому, але не поновленому лідерському слоті. Це фактично максимальний час, протягом якого лідер може бути зупинений, перш ніж його замінить інший кандидат. Це застосовується лише у тому випадку, якщо вибори лідера увімкнені.

--leader-elect-renew-deadline duration     Типово: 10s

Інтервал між спробами виконуючого обовʼязки майстра поновити слот лідера до того, як він перестане бути лідером. Він має бути меншим за тривалість оренди. Це застосовується лише у тому випадку, якщо вибори лідера увімкнені.

--leader-elect-resource-lock string     Типово: "leases"

Тип обʼєкта ресурсу, який використовується для блокування під час виборів лідера. Підтримуються такі варіанти 'leases', 'endpointsleases' and 'configmapsleases'.

--leader-elect-resource-name string     Типово: "kube-controller-manager"

Імʼя обʼєкта ресурсу, який використовується для блокування під час виборів лідера.

--leader-elect-resource-namespace string     Типово: "kube-system"

Простір імен обʼєкта ресурсу, який використовується для блокування під час виборів лідера.

--leader-elect-retry-period duration     Типово: 2s

Час, протягом якого клієнти повинні чекати між спробою отримання та поновленням лідерства. Це стосується лише тих випадків, коли увімкнено обрання лідера.

--leader-migration-config string

Шлях до конфігураційного файлу для міграції лідера контролерів або порожній, щоб використовувати значення, яке є стандартною конфігурацією диспетчера контролерів. Конфігураційний файл має бути типу LeaderMigrationConfiguration, група controllermanager.config.k8s.io, версія v1alpha1.

--legacy-service-account-token-clean-up-period duration     Типово: 8760h0m0s

Період часу з моменту останнього використання токену застарілого облікового запису до його видалення.

--log-flush-frequency duration     Типово: 5s

Максимальна кількість секунд між очищеннями логів

--log-text-info-buffer-size quantity

[Alpha] У текстовому форматі з розділеними потоками виводу інформаційні повідомлення можуть буферизуватися на деякий час для підвищення продуктивності. Стандартне значення, рівне нулю байт, вимикає буферизацію. Розмір можна вказати як кількість байт (512), кратну 1000 (1K), кратну 1024 (2Ki) або степінь (3M, 4G, 5Mi, 6Gi). Увімкніть функцію LoggingAlphaOptions, щоб скористатися цією можливістю.

--log-text-split-stream

[Alpha] У текстовому форматі записувати повідомлення про помилки до stderr та інформаційні повідомлення до stdout. Стандартно до stdout записується один потік. Увімкніть функцію LoggingAlphaOptions, щоб скористатися цією можливістю.

--logging-format string     Типово: "text"

Задає формат логу. Дозволені формати: "text".

--master string

Адреса сервера API Kubernetes (перевизначає будь-яке значення в kubeconfig).

--max-endpoints-per-slice int32     Типово: 100

Максимальна кількість точок доступу, яку буде додано до зрізу EndpointSlice. Чим більше точок на зріз, тим менше зрізів точок, але більші ресурси. Стандартне значення — 100.

--min-resync-period duration     Типово: 12h0m0s

Період ресинхронізації у рефлекторах буде випадковим між MinResyncPeriod та 2*MinResyncPeriod.

--mirroring-concurrent-service-endpoint-syncs int32     Типово: 5

Кількість операцій синхронізації точок доступу сервісів, які будуть виконуватися одночасно контролером endpointslice-mirroring-controller. Більша кількість = швидше оновлення зрізу точок доступу, але більше навантаження на процесор (і мережу). Стандартне значення — 5.

--mirroring-endpointslice-updates-batch-period duration

Тривалість періоду пакетного оновлення EndpointSlice для контролера endpointslice-mirroring-controller. Обробка змін EndpointSlice буде затримана на цей період, щоб обʼєднати їх з потенційними майбутніми оновленнями і зменшити загальну кількість оновлень EndpointSlice. Більша кількість = більша затримка програмування точок доступу, але менша кількість згенерованих ревізій точок доступу

--mirroring-max-endpoints-per-subset int32     Типово: 1000

Максимальна кількість точок доступу, яку буде додано до зрізу EndpointSlice контролером endpointslice-mirroring-controller. Чим більше точок на зріз, тим менше зрізів точок, але більші ресурси. Стандартно дорівнює 100.

--namespace-sync-period duration     Типово: 5m0s

Період синхронізації оновлень життєвого циклу простору імен

--node-cidr-mask-size int32

Розмір маски для вузла cidr у кластері. Стандартне значення 24 для IPv4 та 64 для IPv6.

--node-cidr-mask-size-ipv4 int32

Розмір маски для IPv4 вузла cidr у двостековому кластері. Стандартне значення — 24.

--node-cidr-mask-size-ipv6 int32

Розмір маски для IPv6 вузла cidr у двостековому кластері. Стандартне значення — 64.

--node-eviction-rate float     Типово: 0.1

Кількість вузлів на секунду, на яких видаляються підтипи у випадку відмови вузла, коли зона є справною (див. --unhealthy-zone-threshold для визначення справності/несправності зони). Під зоною мається на увазі весь кластер у небагатозонних кластерах.

--node-monitor-grace-period duration     Типово: 40s

Кількість часу, протягом якого ми дозволяємо вузлу не відповідати на запити, перш ніж позначити його як несправний. Має бути у N разів більшою за nodeStatusUpdateFrequency kubelet, де N означає кількість спроб, дозволених kubelet для публікації статусу вузла.

--node-monitor-period duration     Типово: 5s

Період синхронізації NodeStatus у контролері cloud-node-lifecycle-controller.

--node-startup-grace-period duration     Типово: 1m0s

Час, протягом якого ми дозволяємо стартовому вузлу не відповідати, перш ніж позначити його як несправний.

--permit-address-sharing

Якщо це значення дорівнює true, SO_REUSEADDR буде використано при привʼязці порту. Це дозволяє паралельно привʼязуватись до підстановочних IP-адрес, таких як 0.0.0.0, і до конкретних IP-адрес, а також дозволяє уникнути очікування ядром звільнення сокетів у стані TIME_WAIT. [default=false]

--permit-port-sharing

Якщо значення true, SO_REUSEPORT буде використано при привʼязці порту, що дозволяє більш ніж одному екземпляру привʼязуватися до тієї самої адреси та порту. [default=false]

--profiling     Типово: true

Вмикання профілювання через веб-інтерфейс host:port/debug/pprof/

--pv-recycler-increment-timeout-nfs int32     Типово: 30

Інкремент часу, що додається для кожного Gi до ActiveDeadlineSeconds для поду NFS scrubber

--pv-recycler-minimum-timeout-hostpath int32     Типово: 60

Мінімальне значення ActiveDeadlineSeconds, яке потрібно використовувати для HostPath Recycler pod. Це лише для розробки та тестування і не працюватиме у багатовузловому кластері.

--pv-recycler-minimum-timeout-nfs int32     Типово: 300

TМінімальне значення ActiveDeadlineSeconds, яке потрібно використовувати для pod NFS Recycler

--pv-recycler-pod-template-filepath-hostpath string

Шлях до файлу з визначенням тома, який використовується як шаблон для переробки постійного тома HostPath. Він призначений лише для розробки та тестування і не працюватиме у багатовузловому кластері.

--pv-recycler-pod-template-filepath-nfs string

Шлях до файлу з визначенням pod, який використовується як шаблон для рециркуляції постійних томів NFS

--pv-recycler-timeout-increment-hostpath int32     Типово: 30

інкремент часу, що додається до ActiveDeadlineSeconds на кожен Gi, для HostPath Pod scrubber. Це призначено лише для розробки та тестування і не працюватиме у багатовузловому кластері.

--pvclaimbinder-sync-period duration     Типово: 15s

Період синхронізації постійних томів і заявок на постійні томи

--requestheader-allowed-names strings

Список загальних імен клієнтських сертифікатів, щоб дозволити вказувати імена користувачів у заголовках, визначених параметром --requestheader-username-headers. Якщо він порожній, можна використовувати будь-який сертифікат клієнта, підтверджений центрами сертифікації у файлі --requestheader-client-ca-file.

--requestheader-client-ca-file string

Пакет кореневих сертифікатів для перевірки клієнтських сертифікатів на вхідних запитах перед тим, як довіряти іменам користувачів у заголовках, визначених параметром --requestheader-username-headers. ПОПЕРЕДЖЕННЯ: зазвичай не залежить від авторизації, яку вже виконано для вхідних запитів.

--requestheader-extra-headers-prefix strings     Типово: "x-remote-extra-"

Список префіксів заголовків запитів для перевірки. Пропонується X-Remote-Extra-.

--requestheader-group-headers strings     Типово: "x-remote-group"

Список заголовків запитів для перевірки на наявність груп. Пропонується X-Remote-Group.

--requestheader-username-headers strings     Типово: "x-remote-user"

Список заголовків запитів для перевірки на наявність імен користувачів. X-Remote-User є поширеним.

--resource-quota-sync-period duration     Типово: 5m0s

Період синхронізації статусу використання квоти в системі

--root-ca-file string

Якщо встановлено, цей кореневий центр сертифікації буде включено до токену секрету службового облікового запису. Це має бути дійсний пакет центрів сертифікації з PEM-кодуванням.

--route-reconciliation-period duration     Типово: 10s

Період узгодження маршрутів, створених для Node хмарним провайдером.

--secondary-node-eviction-rate float     Типово: 0.01

Кількість вузлів на секунду, на яких видаляються pods у разі відмови вузла, коли зона є несправною (див. --unhealthy-zone-threshold для визначення healthy/unhealthy зони). Під зоною мається на увазі весь кластер у небагатозонних кластерах. Це значення неявно перевизначається на 0, якщо розмір кластера менший за --large-cluster-size-threshold.

--secure-port int     Типово: 10257

Порт, на якому обслуговувати HTTPS з автентифікацією та авторизацією. Якщо 0, не обслуговувати HTTPS взагалі.

--service-account-private-key-file string

Файл, що містить приватний ключ RSA або ECDSA, закодований PEM, який використовується для підпису токенів службових облікових записів.

--service-cluster-ip-range string

Діапазон CIDR для Services у кластері. Потрібно, щоб --allocate-node-cidrs мав значення true

--show-hidden-metrics-for-version string

Попередня версія, для якої ви хочете показати приховані метрики. Значення має лише попередня мінорна версія, інші значення не будуть дозволені. Формат: <major>.<minor>, наприклад: '1.16'. Мета цього формату — переконатися, що ви маєте можливість помітити, що наступний реліз приховує додаткові метрики, замість того, щоб дивуватися, коли вони будуть назавжди вилучені в наступному релізі.

--terminated-pod-gc-threshold int32     Типово: 12500

Кількість podʼів, що завершили роботу, які можуть існувати до того, як збирач завершених podʼів почне їх видалення. Якщо <= 0, то збирач завершених podʼів вимкнено.

--tls-cert-file string

Файл, що містить стандартний сертифікат x509 для HTTPS. (Сертифікат центру сертифікації, якщо такий є, додається після сертифіката сервера). Якщо HTTPS-сервіс увімкнено, а --tls-cert-file і --tls-private-key-file не вказано, для публічної адреси буде згенеровано самопідписаний сертифікат і ключ, які буде збережено в теці, вказаній в --cert-dir.

--tls-cipher-suites strings

Розділений комами список наборів шифрів для сервера. Якщо не вказано, буде використано стандартний набір шифрів Go.
Значення, яким надається перевага: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305, TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305, TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256.
Небезпечні значення: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_3DES_EDE_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_RC4_128_SHA.

--tls-min-version string

Мінімальна підтримувана версія TLS. Можливі значення: VersionTLS10, VersionTLS11, VersionTLS12, VersionTLS13

--tls-private-key-file string

Файл, що містить стандартний приватний ключ x509, який відповідає --tls-cert-file.

--tls-sni-cert-key string

Пара шляхів до файлів сертифіката x509 і приватного ключа, до яких за бажанням додається список шаблонів доменів, які є повними доменними іменами, можливо, з префіксальними підстановчими сегментами. Доменні шаблони також дозволяють використовувати IP-адреси, але IP-адреси слід використовувати лише в тому випадку, якщо apiserver має доступ до IP-адреси, запитуваної клієнтом. Якщо шаблони домену не надано, витягуються імена сертифікатів. Збіги без підстановочних знаків мають перевагу над збігами з підстановочними знаками, а явні шаблони доменів мають перевагу над отриманими іменами. Для кількох пар ключ/сертифікат використовуйте --tls-sni-cert-key кілька разів. Приклади: "example.crt,example.key" або "foo.crt,foo.key:*.foo.com,foo.com".

--unhealthy-zone-threshold float     Типово: 0.55

Частка вузлів у зоні, яка не повинна бути Ready (мінімум 3) для того, щоб зона вважалася несправною.

--use-service-account-credentials

Якщо true, використовуйте окремі облікові дані для кожного контролера.

-v, --v int

число для визначення ступеня деталізації логу

--version version[=true]

--version, --version=raw виводить інформацію про версію та виходить; --version=vX.Y.Z... встановлює вказану версію

--vmodule pattern=N,...

список параметрів pattern=N, розділених комами, для файлового фільтрування логу (працює лише для текстового формату логу).

6.12.6 - kube-proxy

Огляд

Мережевий проксі-сервер Kubernetes працює на кожному вузлі. Це відображає сервіси, визначені у Kubernetes API, на кожному вузлі і може виконувати просте перенаправлення потоків TCP, UDP і SCTP або циклічне перенаправлення TCP, UDP і SCTP через набір бекендів. Наразі IP-адреси та порти кластерів обслуговування можна знайти за допомогою сумісних з Docker-посиланнями змінні оточення, що визначають порти, відкриті проксі-сервісом. Існує надбудова яка надає кластерний DNS для цих кластерних IP-адрес. Користувач повинен створити сервіс за допомогою API apiserver, щоб налаштувати проксі.

kube-proxy [flags]

Параметри

--add_dir_header

Якщо true, додає теку файлу до заголовка повідомлень логу

--alsologtostderr

виводити лог до stderr, а також у файли (не має ефекту, якщо -logtostderr=true)

--bind-address string     Типово: 0.0.0.0

Перевизначає уявлення kube-proxy про первинну IP-адресу вузла. Зауважте, що назва є історичним артефактом, і kube-proxy насправді не привʼязує жодних сокетів до цього IP. Цей параметр ігнорується, якщо конфігураційний файл вказано за допомогою --config.

--bind-address-hard-fail

Якщо true, kube-proxy розцінить невдалу спробу звʼязатися з портом як фатальну і завершить роботу

--cleanup

Якщо true, очистіть iptables та правила ipvs і вийдіть.

--cluster-cidr string

Діапазон CIDR для Podʼів у кластері. (Для двостекових кластерів це може бути пара діапазонів CIDR, розділених комами). Коли --detect-local-mode має значення ClusterCIDR, kube-proxy вважатиме трафік локальним, якщо IP-адреса його джерела знаходиться в цьому діапазоні. (В іншому випадку він не використовується.) Цей параметр ігнорується, якщо конфігураційний файл вказано за допомогою --config.

--config string

Шлях до файлу конфігурації.

--config-sync-period duration     Типово: 15m0s

Як часто оновлюється конфігурація з apiserver. Повинно бути більше 0.

--conntrack-max-per-core int32     Типово: 32768

Максимальна кількість NAT-зʼєднань для відстеження на одне ядро процесора (0 — залишити ліміт як є і ігнорувати conntrack-min).

--conntrack-min int32     Типово: 131072

Мінімальна кількість записів conntrack для розподілу, незалежно від conntrack-max-per-core (встановіть conntrack-max-per-core=0, щоб залишити обмеження без змін).

--conntrack-tcp-be-liberal

Увімкніть ліберальний режим відстеження TCP-пакетів, встановивши nf_conntrack_tcp_be_liberal у 1

--conntrack-tcp-timeout-close-wait duration     Типово: 1h0m0s

Таймаут NAT для TCP-зʼєднань у стані CLOSE_WAIT

--conntrack-tcp-timeout-established duration     Типово: 24h0m0s

Тайм-аут простою для встановлених TCP-зʼєднань (0 — залишити як є)

--conntrack-udp-timeout duration

Тайм-аут очікування для UDP-зʼєднань без відповіді (0 — залишити як є)

--conntrack-udp-timeout-stream duration

Тайм-аут простою для ASSURED UDP-зʼєднань (0 — залишити як є)

--detect-local-mode LocalMode

Режим для виявлення локального трафіку. Цей параметр ігнорується, якщо конфігураційний файл вказано за допомогою --config.

--feature-gates <comma-separated 'key=True|False' pairs>

Набір пар key=value, які описують функціональні можливостідля альфа/експериментальних функцій. Можливі варіанти:
APIResponseCompression=true|false (BETA — default=true)
APIServerIdentity=true|false (BETA — default=true)
APIServerTracing=true|false (BETA — default=true)
APIServingWithRoutine=true|false (ALPHA — default=false)
AllAlpha=true|false (ALPHA — default=false)
AllBeta=true|false (BETA — default=false)
AnonymousAuthConfigurableEndpoints=true|false (ALPHA — default=false)
AnyVolumeDataSource=true|false (BETA — default=true)
AuthorizeNodeWithSelectors=true|false (ALPHA — default=false)
AuthorizeWithSelectors=true|false (ALPHA — default=false)
CPUManagerPolicyAlphaOptions=true|false (ALPHA — default=false)
CPUManagerPolicyBetaOptions=true|false (BETA — default=true)
CPUManagerPolicyOptions=true|false (BETA — default=true)
CRDValidationRatcheting=true|false (BETA — default=true)
CSIMigrationPortworx=true|false (BETA — default=true)
CSIVolumeHealth=true|false (ALPHA — default=false)
CloudControllerManagerWebhook=true|false (ALPHA — default=false)
ClusterTrustBundle=true|false (ALPHA — default=false)
ClusterTrustBundleProjection=true|false (ALPHA — default=false)
ComponentSLIs=true|false (BETA — default=true)
ConcurrentWatchObjectDecode=true|false (BETA — default=false)
ConsistentListFromCache=true|false (BETA — default=true)
ContainerCheckpoint=true|false (BETA — default=true)
ContextualLogging=true|false (BETA — default=true)
CoordinatedLeaderElection=true|false (ALPHA — default=false)
CronJobsScheduledAnnotation=true|false (BETA — default=true)
CrossNamespaceVolumeDataSource=true|false (ALPHA — default=false)
CustomCPUCFSQuotaPeriod=true|false (ALPHA — default=false)
CustomResourceFieldSelectors=true|false (BETA — default=true)
DRAControlPlaneController=true|false (ALPHA — default=false)
DisableAllocatorDualWrite=true|false (ALPHA — default=false)
DisableNodeKubeProxyVersion=true|false (BETA — default=true)
DynamicResourceAllocation=true|false (ALPHA — default=false)
EventedPLEG=true|false (ALPHA — default=false)
GracefulNodeShutdown=true|false (BETA — default=true)
GracefulNodeShutdownBasedOnPodPriority=true|false (BETA — default=true)
HPAScaleToZero=true|false (ALPHA — default=false)
HonorPVReclaimPolicy=true|false (BETA — default=true)
ImageMaximumGCAge=true|false (BETA — default=true)
ImageVolume=true|false (ALPHA — default=false)
InPlacePodVerticalScaling=true|false (ALPHA — default=false)
InTreePluginPortworxUnregister=true|false (ALPHA — default=false)
InformerResourceVersion=true|false (ALPHA — default=false)
JobBackoffLimitPerIndex=true|false (BETA — default=true)
JobManagedBy=true|false (ALPHA — default=false)
JobPodReplacementPolicy=true|false (BETA — default=true)
JobSuccessPolicy=true|false (BETA — default=true)
KubeletCgroupDriverFromCRI=true|false (BETA — default=true)
KubeletInUserNamespace=true|false (ALPHA — default=false)
KubeletPodResourcesDynamicResources=true|false (ALPHA — default=false)
KubeletPodResourcesGet=true|false (ALPHA — default=false)
KubeletSeparateDiskGC=true|false (BETA — default=true)
KubeletTracing=true|false (BETA — default=true)
LoadBalancerIPMode=true|false (BETA — default=true)
LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (BETA — default=false)
LoggingAlphaOptions=true|false (ALPHA — default=false)
LoggingBetaOptions=true|false (BETA — default=true)
MatchLabelKeysInPodAffinity=true|false (BETA — default=true)
MatchLabelKeysInPodTopologySpread=true|false (BETA — default=true)
MaxUnavailableStatefulSet=true|false (ALPHA — default=false)
MemoryManager=true|false (BETA — default=true)
MemoryQoS=true|false (ALPHA — default=false)
MultiCIDRServiceAllocator=true|false (BETA — default=false)
MutatingAdmissionPolicy=true|false (ALPHA — default=false)
NFTablesProxyMode=true|false (BETA — default=true)
NodeInclusionPolicyInPodTopologySpread=true|false (BETA — default=true)
NodeLogQuery=true|false (BETA — default=false)
NodeSwap=true|false (BETA — default=true)
OpenAPIEnums=true|false (BETA — default=true)
PodAndContainerStatsFromCRI=true|false (ALPHA — default=false)
PodDeletionCost=true|false (BETA — default=true)
PodIndexLabel=true|false (BETA — default=true)
PodLifecycleSleepAction=true|false (BETA — default=true)
PodReadyToStartContainersCondition=true|false (BETA — default=true)
PortForwardWebsockets=true|false (BETA — default=true)
ProcMountType=true|false (BETA — default=false)
QOSReserved=true|false (ALPHA — default=false)
RecoverVolumeExpansionFailure=true|false (ALPHA — default=false)
RecursiveReadOnlyMounts=true|false (BETA — default=true)
RelaxedEnvironmentVariableValidation=true|false (ALPHA — default=false)
ReloadKubeletServerCertificateFile=true|false (BETA — default=true)
ResilientWatchCacheInitialization=true|false (BETA — default=true)
ResourceHealthStatus=true|false (ALPHA — default=false)
RetryGenerateName=true|false (BETA — default=true)
RotateKubeletServerCertificate=true|false (BETA — default=true)
RuntimeClassInImageCriApi=true|false (ALPHA — default=false)
SELinuxMount=true|false (ALPHA — default=false)
SELinuxMountReadWriteOncePod=true|false (BETA — default=true)
SchedulerQueueingHints=true|false (BETA — default=false)
SeparateCacheWatchRPC=true|false (BETA — default=true)
SeparateTaintEvictionController=true|false (BETA — default=true)
ServiceAccountTokenJTI=true|false (BETA — default=true)
ServiceAccountTokenNodeBinding=true|false (BETA — default=true)
ServiceAccountTokenNodeBindingValidation=true|false (BETA — default=true)
ServiceAccountTokenPodNodeInfo=true|false (BETA — default=true)
ServiceTrafficDistribution=true|false (BETA — default=true)
SidecarContainers=true|false (BETA — default=true)
SizeMemoryBackedVolumes=true|false (BETA — default=true)
StatefulSetAutoDeletePVC=true|false (BETA — default=true)
StorageNamespaceIndex=true|false (BETA — default=true)
StorageVersionAPI=true|false (ALPHA — default=false)
StorageVersionHash=true|false (BETA — default=true)
StorageVersionMigrator=true|false (ALPHA — default=false)
StrictCostEnforcementForVAP=true|false (BETA — default=false)
StrictCostEnforcementForWebhooks=true|false (BETA — default=false)
StructuredAuthenticationConfiguration=true|false (BETA — default=true)
StructuredAuthorizationConfiguration=true|false (BETA — default=true)
SupplementalGroupsPolicy=true|false (ALPHA — default=false)
TopologyAwareHints=true|false (BETA — default=true)
TopologyManagerPolicyAlphaOptions=true|false (ALPHA — default=false)
TopologyManagerPolicyBetaOptions=true|false (BETA — default=true)
TopologyManagerPolicyOptions=true|false (BETA — default=true)
TranslateStreamCloseWebsocketRequests=true|false (BETA — default=true)
UnauthenticatedHTTP2DOSMitigation=true|false (BETA — default=true)
UnknownVersionInteroperabilityProxy=true|false (ALPHA — default=false)
UserNamespacesPodSecurityStandards=true|false (ALPHA — default=false)
UserNamespacesSupport=true|false (BETA — default=false)
VolumeAttributesClass=true|false (BETA — default=false)
VolumeCapacityPriority=true|false (ALPHA — default=false)
WatchCacheInitializationPostStartHook=true|false (BETA — default=false)
WatchFromStorageWithoutResourceVersion=true|false (BETA — default=false)
WatchList=true|false (ALPHA — default=false)
WatchListClient=true|false (BETA — default=false)
WinDSR=true|false (ALPHA — default=false)
WinOverlay=true|false (BETA — default=true)
WindowsHostNetwork=true|false (ALPHA — default=true)
Цей параметр ігнорується, якщо конфігураційний файл вказано за допомогою --config.

--healthz-bind-address ipport     Типово: 0.0.0.0:10256

IP-адреса та порт для сервера перевірки справності, стандартно "0.0.0.0:10256". Цей параметр ігнорується, якщо конфігураційний файл вказано за допомогою --config.

-h, --help

Довідка kube-proxy

--hostname-override string

Якщо не порожнє, буде використано як імʼя вузла, на якому запущено kube-proxy. Якщо не задано, імʼя вузла вважається таким самим, як і імʼя хоста вузла.

--init-only

Якщо true, виконайте всі кроки ініціалізації, які необхідно виконати з повними привілеями root, а потім вийдіть. Після цього ви можете запустити kube-proxy знову, але тільки з параметром CAP_NET_ADMIN.

--iptables-localhost-nodeports     Типово: true

Якщо значення false, kube-proxy вимкне застарілу поведінку, яка дозволяла доступ до сервісів NodePort через localhost. (Стосується лише режиму iptables та IPv4; NodePort через localhost ніколи не буде дозволено в інших режимах проксі або з IPv6).

--iptables-masquerade-bit int32     Типово: 14

Якщо використовується режим проксі iptables або ipvs, біт простору fwmark, яким слід позначати пакети, що вимагають SNAT. Повинен знаходитися в діапазоні [0, 31].

--iptables-min-sync-period duration     Типово: 1s

Мінімальний період між пересинхронізаціями правил iptables (наприклад, '5s', '1m', '2h22m'). Значення 0 означає, що кожна зміна Service або EndpointSlice призведе до негайного пересинхронізації iptables.

--iptables-sync-period duration     Типово: 30s

Інтервал (наприклад, '5s', '1m', '2h22m'), який вказує, як часто виконуються різні операції ресинхронізації та очищення. Має бути більше 0.

--ipvs-exclude-cidrs strings

Список CIDR, розділених комами, які ipvs-проксі-сервер не повинен торкатися під час очищення правил IPVS.

--ipvs-min-sync-period duration     Типово: 1s

Мінімальний період між ресинхронізаціями правил IPVS (наприклад, '5s', '1m', '2h22m'). Значення 0 означає, що кожна зміна Service або EndpointSlice призведе до негайної пересинхронізації IPVS.

--ipvs-scheduler string

Тип планувальника ipvs, якщо режим проксі — ipvs

--ipvs-strict-arp

Увімкніть строгий ARP, встановивши arp_ignore на 1 і arp_announce на 2

--ipvs-sync-period duration     Типово: 30s

Інтервал (наприклад, '5s', '1m', '2h22m'), який вказує, як часто виконуються різні операції ресинхронізації та очищення. Має бути більше 0.

--ipvs-tcp-timeout duration

Тайм-аут для неактивних TCP-зʼєднань IPVS, 0 — залишити як є. (наприклад, '5s', '1m', '2h22m').

--ipvs-tcpfin-timeout duration

Тайм-аут для IPVS TCP-зʼєднань після отримання FIN-пакету, 0 — залишити як є. (наприклад, '5s', '1m', '2h22m').

--ipvs-udp-timeout duration

Таймаут для IPVS UDP-пакетів, 0 — залишити як є. (наприклад, '5s', '1m', '2h22m').

--kube-api-burst int32     Типово: 10

Сплеск для використання під час спілкування з apiserver на kubernetes.

--kube-api-content-type string     Типово: "application/vnd.kubernetes.protobuf"

Тип вмісту запитів, що надсилаються до apiserver.

--kube-api-qps float     Типово: 5

Використання QPS під час спілкування з apiserver на kubernetes

--kubeconfig string

Шлях до файлу kubeconfig з інформацією про авторизацію (розташування master може бути перевизначено прапорцем master).

--log-flush-frequency duration     Типово: 5s

Максимальна кількість секунд між очищеннями логів

--log-text-info-buffer-size quantity

[Alpha] У текстовому форматі з розділеними потоками виводу інформаційні повідомлення можуть буферизуватися на деякий час для підвищення продуктивності. Стандартне значення, рівне нулю байт, вимикає буферизацію. Розмір можна вказати як кількість байт (512), кратну 1000 (1K), кратну 1024 (2Ki) або степінь (3M, 4G, 5Mi, 6Gi). Увімкніть функцію LoggingAlphaOptions, щоб скористатися цією можливістю.

--log-text-split-stream

[Alpha] У текстовому форматі записувати повідомлення про помилки до stderr та інформаційні повідомлення до stdout. Стандартно до stdout записується один потік. Увімкніть функцію LoggingAlphaOptions, щоб скористатися цією можливістю.

--log_backtrace_at <рядок у вигляді 'file:N'>     Типово: :0

при попаданні в лог-файл рядка file:N, вивести трасування стеку

--log_dir string

Якщо тека не порожня, записати лог-файли у цю теку (не діє, якщо -logtostderr=true).

--log_file string

Якщо файл не порожній, використовуйте цей файл логу (не діє, якщо -logtostderr=true)

--log_file_max_size uint     Типово: 1800

Визначає максимальний розмір, до якого може зрости файл логу (не впливає, якщо -logtostderr=true). Одиниця виміру — мегабайти. Якщо значення дорівнює 0, максимальний розмір файлу необмежений.

--logging-format string     Типово: "text"

Задає формат логу. Дозволені формати: "text".

--logtostderr     Типово: true

писати лог в standard error, а не у файл

--masquerade-all

SNAT для всього трафіку, що надсилається через IP-кластера сервісу. Це може бути необхідним для деяких втулків CNI. Підтримується лише в Linux.

--master string

Адреса сервера API Kubernetes (перевизначає будь-яке значення в kubeconfig).

--metrics-bind-address ipport     Типово: 127.0.0.1:10249

IP-адреса та порт для сервера метрик, типове значення: "127.0.0.1:10249". (Встановіть значення "0.0.0.0:10249" / "[::]:10249" для привʼязки на всіх інтерфейсах). Встановіть пусте значення, щоб вимкнути. Цей параметр ігнорується, якщо конфігураційний файл вказано за допомогою --config.

--nodeport-addresses strings

Список діапазонів CIDR, які містять допустимі IP-адреси вузлів, або, як варіант, єдиний рядок 'primary'. Якщо встановлено перелік CIDRs, зʼєднання з сервісами NodePort будуть прийматися лише з IP-адрес вузла в одному із зазначених діапазонів. Якщо встановлено значення 'primary', сервіси NodePort будуть прийматися лише на основну IP-адресу вузла згідно з обʼєктом Node. Якщо не встановлено, зʼєднання до NodePort будуть прийматися на всіх локальних IP-адресах. Цей параметр ігнорується, якщо конфігураційний файл вказано за допомогою --config.

--one_output

Якщо значення true, записувати логи лише до їхнього власного рівня важливості (замість запису до кожного нижчого рівня важливості; немає ефекту, якщо -logtostderr=true).

--oom-score-adj int32     Типово: -999

Значення oom-score-adj для процесу kube-proxy. Значення має бути в діапазоні [-1000, 1000]. Цей параметр ігнорується, якщо конфігураційний файл вказано за допомогою --config.

--pod-bridge-interface string

Імʼя інтерфейсу bridge. Коли --detect-local-mode має значення BridgeInterface, kube-proxy вважатиме трафік локальним, якщо він походить з цього мосту.

--pod-interface-name-prefix string

Префікс імені інтерфейсу. Коли --detect-local-mode має значення InterfaceNamePrefix, kube-proxy вважатиме трафік локальним, якщо він походить з будь-якого інтерфейсу, назва якого починається з цього префікса.

--profiling

Якщо значення true, вмикає профілювання через веб-інтерфейс у обробнику /debug/pprof. Цей параметр ігнорується, якщо конфігураційний файл вказано за допомогою --config.

--proxy-mode ProxyMode

Режим проксі-сервера: у Linux це може бути 'iptables' (стандартно) або 'ipvs'. У Windows єдиним підтримуваним значенням є 'kernelspace'. Цей параметр ігнорується, якщо у конфігураційному файлі вказано --config.

--show-hidden-metrics-for-version string

Попередня версія, для якої ви хочете показати приховані метрики. Значення має лише попередня мінорна версія, інші значення не будуть дозволені. Формат: <major>.<minor>, наприклад: '1.16'. Мета цього формату — переконатися, що ви маєте можливість помітити, що наступний реліз приховує додаткові метрики, а не дивуватися, коли вони назавжди вилучаються в наступному релізі. Цей параметр ігнорується, якщо конфігураційний файл вказано за допомогою --config.

--skip_headers

Якщо true, уникати префіксів заголовків у повідомленнях логу

--skip_log_headers

Якщо значення true, уникати заголовків при відкритті файлів логу (не впливає, якщо -logtostderr=true)

--stderrthreshold int     Типово: 2

логи на рівні або вище цього порогу потрапляють до stderr під час запису до файлів та stderr (не впливає, якщо -logtostderr=true або -alsologtostderr=true)

-v, --v int

число рівня деталізації логу

--version version[=true]

--version, --version=raw виводить інформацію про версію та виходить; --version=vX.Y.Z... встановлює вказану версію

--vmodule pattern=N,...

список параметрів pattern=N, розділених комами, для файлового фільтрування логу (працює лише для текстового формату логу).

--write-config-to string

Якщо встановлено, записати значення стандартної конфігурації до цього файлу і вийти.

6.12.7 - kube-scheduler

Огляд

Планувальник Kubernetes — це процес панелі управління, який призначає Podʼи до вузлів. Планувальник визначає, які вузли є допустимими для розміщення для кожного Pod у черзі планування відповідно до обмежень та доступних ресурсів. Потім планувальник ранжує кожен допустимий вузол і привʼязує Pod до відповідного вузла. У кластері може використовуватися декілька різних планувальників; kube-scheduler є еталонною реалізацією. Див. статтю планування для отримання додаткової інформації про планування та компонент kube-scheduler.

kube-scheduler [flags]

Параметри

--allow-metric-labels stringToString     Типово: []

Зіставляє метрику-мітку зі списком дозволених значень цієї мітки. Формат ключа — <MetricName>,<LabelName>. Формат значення — < allowed_value>, <allowed_value>...наприклад, metric1,label1='v1,v2,v3', metric1,label2='v1,v2,v3' metric2,label1='v1,v2,v3'.

--allow-metric-labels-manifest string

Шлях до файлу маніфесту, який містить зіставлення allow-list. Формат файлу такий самий, як і у прапорця --allow-metric-labels. Зауважте, що прапорець --allow-metric-labels замінить файл маніфесту.

--authentication-kubeconfig string

файл kubeconfig, що вказує на 'core' сервер kubernetes з достатніми правами для створення tokenreviews.authentication.k8s.io. Цей параметр не є обовʼязковим. Якщо він порожній, всі запити токенів вважаються анонімними, і жоден клієнтський центр сертифікації не шукається в кластері.

--authentication-skip-lookup

Якщо значення false, authentication-kubeconfig буде використано для пошуку відсутньої конфігурації автентифікації в кластері.

--authentication-token-webhook-cache-ttl duration     Типово: 10s

Тривалість кешування відповідей від автентифікатора токенів вебхуків.

--authentication-tolerate-lookup-failure     Типово: true

Якщо це значення встановлено, невдачі у пошуку відсутньої конфігурації автентифікації в кластері не вважатимуться фатальними. Зауважте, що це може призвести до автентифікації, яка розглядає всі запити як анонімні.

--authorization-always-allow-paths strings     Типово: "/healthz,/readyz,/livez"

Список HTTP-шляхів, які пропускаються під час авторизації, тобто авторизуються без звʼязку з 'core' сервером kubernetes.

--authorization-kubeconfig string

файл kubeconfig, що вказує на 'core' сервер kubernetes з достатніми правами для створення subjectaccessreviews.authorization.k8s.io. Цей параметр не є обовʼязковим. Якщо він порожній, всі запити, не пропущені авторизацією, будуть заборонені.

--authorization-webhook-cache-authorized-ttl duration     Типово: 10s

Тривалість кешування 'authorized' відповідей від авторизатора вебхука.

--authorization-webhook-cache-unauthorized-ttl duration     Типово: 10s

Тривалість кешування 'unauthorized' відповідей від авторизатора вебхука.

--bind-address string     Типово: 0.0.0.0

IP-адреса, на якій буде прослуховуватися порт --secure-port. Відповідний інтерфейс(и) має бути доступним для решти кластера, а також для CLI/веб-клієнтів. Якщо цей параметр не вказано або вказано невизначену адресу (0.0.0.0 або ::), будуть використані всі інтерфейси та сімейства IP-адрес.

--cert-dir string

Тека, в якій знаходяться TLS-сертифікати. Якщо вказано --tls-cert-file та --tls-private-key-file, цей прапорець буде проігноровано.

--client-ca-file string

Якщо встановлено, будь-який запит, що надає клієнтський сертифікат, підписаний одним із центрів сертифікації у клієнтському файлі, буде автентифіковано за допомогою ідентифікатора, що відповідає CommonName клієнтського сертифіката.

--config string

Шлях до файлу конфігурації.

--contention-profiling     Типово: true

DEPRECATED: увімкнути профілювання блоків, якщо профілювання увімкнено. Цей параметр ігнорується, якщо у --config вказано конфігураційний файл.

--disable-http2-serving

Якщо значення true, HTTP2-сервіс буде вимкнено [default=false].

--disabled-metrics strings

Цей прапорець забезпечує аварійний вихід для метрик, що поводяться не належним чином. Щоб вимкнути метрику, ви маєте вказати її повну назву. Застереження: вимкнення метрик має вищий пріоритет, ніж показ прихованих метрик.

--emulated-version strings

У версіях різні компоненти емулюють свої можливості (API, функції, ...) інших компонентів.
Якщо встановлено, компонент буде емулювати поведінку цієї версії замість базової двійкової версії.
Формат версії може бути лише major.minor, наприклад: '--emulated-version=wardle=1.2,kube=1.31'. Можливі варіанти:
kube=1.31..1.31 (default=1.31) Якщо компонент не вказано, стандартно використовується "kube"

--feature-gates colonSeparatedMultimapStringString

Розділений комами список пар component:key=value, які описують функціональні можливості для альфа/експериментальних можливостей різних компонентів.
Якщо компонент не вказано, стандартно використовується "kube". Цей прапорець можна викликати багаторазово. Наприклад: --feature-gates 'wardle:featureA=true,wardle:featureB=false' --feature-gates 'kube:featureC=true'. Можливі варіанти:
kube:APIResponseCompression=true|false (BETA — default=true)
kube:APIServerIdentity=true|false (BETA — default=true)
kube:APIServerTracing=true|false (BETA — default=true)
kube:APIServingWithRoutine=true|false (ALPHA — default=false)
kube:AllAlpha=true|false (ALPHA — default=false)
kube:AllBeta=true|false (BETA — default=false)
kube:AnonymousAuthConfigurableEndpoints=true|false (ALPHA — default=false)
kube:AnyVolumeDataSource=true|false (BETA — default=true)
kube:AuthorizeNodeWithSelectors=true|false (ALPHA — default=false)
kube:AuthorizeWithSelectors=true|false (ALPHA — default=false)
kube:CPUManagerPolicyAlphaOptions=true|false (ALPHA — default=false)
kube:CPUManagerPolicyBetaOptions=true|false (BETA — default=true)
kube:CPUManagerPolicyOptions=true|false (BETA — default=true)
kube:CRDValidationRatcheting=true|false (BETA — default=true)
kube:CSIMigrationPortworx=true|false (BETA — default=true)
kube:CSIVolumeHealth=true|false (ALPHA — default=false)
kube:CloudControllerManagerWebhook=true|false (ALPHA — default=false)
kube:ClusterTrustBundle=true|false (ALPHA — default=false)
kube:ClusterTrustBundleProjection=true|false (ALPHA — default=false)
kube:ComponentSLIs=true|false (BETA — default=true)
kube:ConcurrentWatchObjectDecode=true|false (BETA — default=false)
kube:ConsistentListFromCache=true|false (BETA — default=true)
kube:ContainerCheckpoint=true|false (BETA — default=true)
kube:ContextualLogging=true|false (BETA — default=true)
kube:CoordinatedLeaderElection=true|false (ALPHA — default=false)
kube:CronJobsScheduledAnnotation=true|false (BETA — default=true)
kube:CrossNamespaceVolumeDataSource=true|false (ALPHA — default=false)
kube:CustomCPUCFSQuotaPeriod=true|false (ALPHA — default=false)
kube:CustomResourceFieldSelectors=true|false (BETA — default=true)
kube:DRAControlPlaneController=true|false (ALPHA — default=false)
kube:DisableAllocatorDualWrite=true|false (ALPHA — default=false)
kube:DisableNodeKubeProxyVersion=true|false (BETA — default=true)
kube:DynamicResourceAllocation=true|false (ALPHA — default=false)
kube:EventedPLEG=true|false (ALPHA — default=false)
kube:GracefulNodeShutdown=true|false (BETA — default=true)
kube:GracefulNodeShutdownBasedOnPodPriority=true|false (BETA — default=true)
kube:HPAScaleToZero=true|false (ALPHA — default=false)
kube:HonorPVReclaimPolicy=true|false (BETA — default=true)
kube:ImageMaximumGCAge=true|false (BETA — default=true)
kube:ImageVolume=true|false (ALPHA — default=false)
kube:InPlacePodVerticalScaling=true|false (ALPHA — default=false)
kube:InTreePluginPortworxUnregister=true|false (ALPHA — default=false)
kube:InformerResourceVersion=true|false (ALPHA — default=false)
kube:JobBackoffLimitPerIndex=true|false (BETA — default=true)
kube:JobManagedBy=true|false (ALPHA — default=false)
kube:JobPodReplacementPolicy=true|false (BETA — default=true)
kube:JobSuccessPolicy=true|false (BETA — default=true)
kube:KubeletCgroupDriverFromCRI=true|false (BETA — default=true)
kube:KubeletInUserNamespace=true|false (ALPHA — default=false)
kube:KubeletPodResourcesDynamicResources=true|false (ALPHA — default=false)
kube:KubeletPodResourcesGet=true|false (ALPHA — default=false)
kube:KubeletSeparateDiskGC=true|false (BETA — default=true)
kube:KubeletTracing=true|false (BETA — default=true)
kube:LoadBalancerIPMode=true|false (BETA — default=true)
kube:LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (BETA — default=false)
kube:LoggingAlphaOptions=true|false (ALPHA — default=false)
kube:LoggingBetaOptions=true|false (BETA — default=true)
kube:MatchLabelKeysInPodAffinity=true|false (BETA — default=true)
kube:MatchLabelKeysInPodTopologySpread=true|false (BETA — default=true)
kube:MaxUnavailableStatefulSet=true|false (ALPHA — default=false)
kube:MemoryManager=true|false (BETA — default=true)
kube:MemoryQoS=true|false (ALPHA — default=false)
kube:MultiCIDRServiceAllocator=true|false (BETA — default=false)
kube:MutatingAdmissionPolicy=true|false (ALPHA — default=false)
kube:NFTablesProxyMode=true|false (BETA — default=true)
kube:NodeInclusionPolicyInPodTopologySpread=true|false (BETA — default=true)
kube:NodeLogQuery=true|false (BETA — default=false)
kube:NodeSwap=true|false (BETA — default=true)
kube:OpenAPIEnums=true|false (BETA — default=true)
kube:PodAndContainerStatsFromCRI=true|false (ALPHA — default=false)
kube:PodDeletionCost=true|false (BETA — default=true)
kube:PodIndexLabel=true|false (BETA — default=true)
kube:PodLifecycleSleepAction=true|false (BETA — default=true)
kube:PodReadyToStartContainersCondition=true|false (BETA — default=true)
kube:PortForwardWebsockets=true|false (BETA — default=true)
kube:ProcMountType=true|false (BETA — default=false)
kube:QOSReserved=true|false (ALPHA — default=false)
kube:RecoverVolumeExpansionFailure=true|false (ALPHA — default=false)
kube:RecursiveReadOnlyMounts=true|false (BETA — default=true)
kube:RelaxedEnvironmentVariableValidation=true|false (ALPHA — default=false)
kube:ReloadKubeletServerCertificateFile=true|false (BETA — default=true)
kube:ResilientWatchCacheInitialization=true|false (BETA — default=true)
kube:ResourceHealthStatus=true|false (ALPHA — default=false)
kube:RetryGenerateName=true|false (BETA — default=true)
kube:RotateKubeletServerCertificate=true|false (BETA — default=true)
kube:RuntimeClassInImageCriApi=true|false (ALPHA — default=false)
kube:SELinuxMount=true|false (ALPHA — default=false)
kube:SELinuxMountReadWriteOncePod=true|false (BETA — default=true)
kube:SchedulerQueueingHints=true|false (BETA — default=false)
kube:SeparateCacheWatchRPC=true|false (BETA — default=true)
kube:SeparateTaintEvictionController=true|false (BETA — default=true)
kube:ServiceAccountTokenJTI=true|false (BETA — default=true)
kube:ServiceAccountTokenNodeBinding=true|false (BETA — default=true)
kube:ServiceAccountTokenNodeBindingValidation=true|false (BETA — default=true)
kube:ServiceAccountTokenPodNodeInfo=true|false (BETA — default=true)
kube:ServiceTrafficDistribution=true|false (BETA — default=true)
kube:SidecarContainers=true|false (BETA — default=true)
kube:SizeMemoryBackedVolumes=true|false (BETA — default=true)
kube:StatefulSetAutoDeletePVC=true|false (BETA — default=true)
kube:StorageNamespaceIndex=true|false (BETA — default=true)
kube:StorageVersionAPI=true|false (ALPHA — default=false)
kube:StorageVersionHash=true|false (BETA — default=true)
kube:StorageVersionMigrator=true|false (ALPHA — default=false)
kube:StrictCostEnforcementForVAP=true|false (BETA — default=false)
kube:StrictCostEnforcementForWebhooks=true|false (BETA — default=false)
kube:StructuredAuthenticationConfiguration=true|false (BETA — default=true)
kube:StructuredAuthorizationConfiguration=true|false (BETA — default=true)
kube:SupplementalGroupsPolicy=true|false (ALPHA — default=false)
kube:TopologyAwareHints=true|false (BETA — default=true)
kube:TopologyManagerPolicyAlphaOptions=true|false (ALPHA — default=false)
kube:TopologyManagerPolicyBetaOptions=true|false (BETA — default=true)
kube:TopologyManagerPolicyOptions=true|false (BETA — default=true)
kube:TranslateStreamCloseWebsocketRequests=true|false (BETA — default=true)
kube:UnauthenticatedHTTP2DOSMitigation=true|false (BETA — default=true)
kube:UnknownVersionInteroperabilityProxy=true|false (ALPHA — default=false)
kube:UserNamespacesPodSecurityStandards=true|false (ALPHA — default=false)
kube:UserNamespacesSupport=true|false (BETA — default=false)
kube:VolumeAttributesClass=true|false (BETA — default=false)
kube:VolumeCapacityPriority=true|false (ALPHA — default=false)
kube:WatchCacheInitializationPostStartHook=true|false (BETA — default=false)
kube:WatchFromStorageWithoutResourceVersion=true|false (BETA — default=false)
kube:WatchList=true|false (ALPHA — default=false)
kube:WatchListClient=true|false (BETA — default=false)
kube:WinDSR=true|false (ALPHA — default=false)
kube:WinOverlay=true|false (BETA — default=true)
kube:WindowsHostNetwork=true|false (ALPHA — default=true)

-h, --help

Довідка kube-scheduler

--http2-max-streams-per-connection int

Обмеження, яке сервер надає клієнтам на максимальну кількість потоків у зʼєднанні HTTP/2. Нуль означає використання стандартних значень golang.

--kube-api-burst int32     Типово: 100

DEPRECATED: сплеск для використання під час спілкування з apiserver'ом kubernetes. Цей параметр ігнорується, якщо у --config вказано конфігураційний файл.

--kube-api-content-type string     Типово: "application/vnd.kubernetes.protobuf"

DEPRECATED: тип вмісту запитів, що надсилаються до apiserver. Цей параметр ігнорується, якщо у --config вказано конфігураційний файл.

--kube-api-qps float     Типово: 50

DEPRECATED: Використовувати QPS під час спілкування з apiserver'ом kubernetes. Цей параметр ігнорується, якщо у --config вказано конфігураційний файл.

--kubeconfig string

DEPRECATED: шлях до файлу kubeconfig з інформацією про авторизацію та місцезнаходження майстра. Цей параметр ігнорується, якщо у --config вказано конфігураційний файл.

--leader-elect     Типово: true

Запускає клієнта виборів лідера і отримує лідерство перед виконанням основного циклу. Увімкніть цю опцію під час запуску реплікованих компонентів для забезпечення високої доступності.

--leader-elect-lease-duration duration     Типово: 15s

Тривалість, протягом якої кандидати, що не є лідерами, чекатимуть після поновлення лідерства, перш ніж спробувати зайняти лідерство в лідируючому, але не поновленому лідерському слоті. Це фактично максимальний час, протягом якого лідер може бути зупинений, перш ніж його замінить інший кандидат. Це застосовується лише у тому випадку, якщо вибори лідера увімкнені.

--leader-elect-renew-deadline duration     Типово: 10s

Інтервал між спробами виконуючого обовʼязки майстра поновити слот лідера до того, як він перестане бути лідером. Він має бути меншим за тривалість оренди. Це застосовується лише у тому випадку, якщо вибори лідера увімкнені.

--leader-elect-resource-lock string     Типово: "leases"

Тип обʼєкта ресурсу, який використовується для блокування під час обрання лідера. Підтримувані варіанти: 'leases', 'endpointsleases' і 'configmapsleases'.

--leader-elect-resource-name string     Типово: "kube-scheduler"

Імʼя обʼєкта ресурсу, який використовується для блокування під час виборів лідера.

--leader-elect-resource-namespace string     Типово: "kube-system"

Простір імен обʼєкта ресурсу, який використовується для блокування під час виборів лідера.

--leader-elect-retry-period duration     Типово: 2s

Час, протягом якого клієнти повинні чекати між спробою отримання та поновленням лідерства. Це стосується лише тих випадків, коли увімкнено обрання лідера.

--log-flush-frequency duration     Типово: 5s

Максимальна кількість секунд між очищеннями логів

--log-text-info-buffer-size quantity

[Alpha] У текстовому форматі з розділеними потоками виводу інформаційні повідомлення можуть буферизуватися на деякий час для підвищення продуктивності. Стандартне значення, рівне нулю байт, вимикає буферизацію. Розмір можна вказати як кількість байт (512), кратну 1000 (1K), кратну 1024 (2Ki) або степінь (3M, 4G, 5Mi, 6Gi). Увімкніть функцію LoggingAlphaOptions, щоб скористатися цією можливістю.

--log-text-split-stream

[Alpha] У текстовому форматі записувати повідомлення про помилки до stderr та інформаційні повідомлення до stdout. Стандартно до stdout записується один потік. Увімкніть функцію LoggingAlphaOptions, щоб скористатися цією можливістю.

--logging-format string     Типово: "text"

Задає формат логу. Дозволені формати: "text".

--master string

Адреса сервера API Kubernetes (перевизначає будь-яке значення в kubeconfig).

--permit-address-sharing

Якщо це значення дорівнює true, SO_REUSEADDR буде використано при привʼязці порту. Це дозволяє паралельно привʼязуватись до підстановочних IP-адрес, таких як 0.0.0.0, і до конкретних IP-адрес, а також дозволяє уникнути очікування ядром звільнення сокетів у стані TIME_WAIT. [default=false]

--permit-port-sharing

Якщо значення true, SO_REUSEPORT буде використано при привʼязці порту, що дозволяє більш ніж одному екземпляру привʼязуватися до однієї адреси та порту. [default=false]

--pod-max-in-unschedulable-pods-duration duration     Типово: 5m0s

DEPRECATED: максимальний час, протягом якого Pod може перебувати в unschedulablePods. Якщо Pod залишається в unschedulablePods довше, ніж це значення, то його буде переміщено з unschedulablePods до backoffQ або activeQ. Цей прапорець є застарілим і буде вилучений у наступній версії.

--profiling     Типово: true

DEPRECATED: увімкнути профілювання через веб-інтерфейс host:port/debug/prof/. Цей параметр ігнорується, якщо у --config вказано конфігураційний файл.

--requestheader-allowed-names strings

Список загальних імен клієнтських сертифікатів, щоб дозволити вказувати імена користувачів у заголовках, визначених параметром --requestheader-username-headers. Якщо він порожній, можна використовувати будь-який сертифікат клієнта, підтверджений центрами сертифікації у файлі --requestheader-client-ca-file.

--requestheader-client-ca-file string

Пакет кореневих сертифікатів для перевірки клієнтських сертифікатів на вхідних запитах перед тим, як довіряти іменам користувачів у заголовках, визначених параметром --requestheader-username-headers. ПОПЕРЕДЖЕННЯ: зазвичай не залежить від авторизації, яку вже виконано для вхідних запитів.

--requestheader-extra-headers-prefix strings     Типово: "x-remote-extra-"

Список префіксів заголовків запитів для перевірки. Запропоновано X-Remote-Extra-.

--requestheader-group-headers strings     Типово: "x-remote-group"

Список заголовків запитів для перевірки на наявність груп. Пропонується X-Remote-Group.

--requestheader-username-headers strings     Типово: "x-remote-user"

Список заголовків запитів для перевірки на наявність імен користувачів. X-Remote-User є поширеним.

--secure-port int     Типово: 10259

Порт, на якому обслуговувати HTTPS з автентифікацією та авторизацією. Якщо 0, не обслуговувати HTTPS взагалі.

--show-hidden-metrics-for-version string

Попередня версія, для якої ви хочете показати приховані метрики. Значення має лише попередня мінорна версія, інші значення не будуть дозволені. Формат: <major>.<minor>, наприклад: '1.16'. Мета цього формату - переконатися, що ви маєте можливість помітити, що наступний реліз приховує додаткові метрики, замість того, щоб дивуватися, коли вони будуть назавжди вилучені в наступному релізі.

--tls-cert-file string

Файл, що містить стандартний сертифікат x509 для HTTPS. (Сертифікат центру сертифікації, якщо такий є, додається після сертифіката сервера). Якщо HTTPS-сервіс увімкнено, а --tls-cert-file і --tls-private-key-file не вказано, для публічної адреси буде згенеровано самопідписаний сертифікат і ключ, які буде збережено в теці, вказаній в --cert-dir.

--tls-cipher-suites strings

Розділений комами список наборів шифрів для сервера. Якщо не вказано, буде використано стандартний набір шифрів Go.
Значення, яким надається перевага: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305, TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305, TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256.
Небезпечні значення: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_3DES_EDE_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_RC4_128_SHA.

--tls-min-version string

Мінімальна підтримувана версія TLS. Можливі значення: VersionTLS10, VersionTLS11, VersionTLS12, VersionTLS13

--tls-private-key-file string

>Файл, що містить стандартний приватний ключ x509, який відповідає --tls-cert-file.

--tls-sni-cert-key string

Пара шляхів до файлів сертифіката x509 і приватного ключа, до яких за бажанням додається список доменних шаблонів, які є повними доменними іменами, можливо, з префіксальними підстановчими сегментами. Доменні шаблони також дозволяють використовувати IP-адреси, але IP-адреси слід використовувати лише в тому випадку, якщо apiserver має доступ до IP-адреси, запитуваної клієнтом. Якщо шаблони домену не надано, витягуються імена сертифікатів. Збіги без підстановочних знаків мають перевагу над збігами з підстановочними знаками, а явні шаблони доменів мають перевагу над отриманими іменами. Для кількох пар ключ/сертифікат використовуйте --tls-sni-cert-key кілька разів. Приклади: "example.crt,example.key" або "foo.crt,foo.key:*.foo.com,foo.com".

-v, --v int

число рівня деталізації логу

--version version[=true]

--version, --version=raw виводить інформацію про версію та виходить; --version=vX.Y.Z... встановлює вказану версію

--vmodule pattern=N,...

список параметрів pattern=N, розділених комами, для файлового фільтрування логу (працює лише для текстового формату логу).

--write-config-to string

Якщо встановлено, записати значення стандартної конфігурації до цього файлу і вийти.

6.13 - Відлагодження кластера

6.13.1 - Керування потоком

API Priority and Fairness контролює поведінку сервера API Kubernetes у ситуації перевантаження. Ви можете знайти більше інформації про нього у розділі API Priority & Fairness документації.

Діагностика

Кожна відповідь HTTP від API-сервера з увімкненою функцією пріоритету та справедливості має два додаткові заголовки: X-Kubernetes-PF-FlowSchema-UID та X-Kubernetes-PF-PriorityLevel-UID, які вказують на схему потоку, що відповідала запиту, та рівень пріоритету, до якого він був призначений, відповідно. Імена обʼєктів API не включені в ці заголовки (щоб уникнути розкриття деталей у випадку, якщо користувач, який робить запит, не має дозволу на їх перегляд). Під час налагодження ви можете використовувати команду:

kubectl get flowschemas -o custom-columns="uid:{metadata.uid},name:{metadata.name}"
kubectl get prioritylevelconfigurations -o custom-columns="uid:{metadata.uid},name:{metadata.name}"

щоб отримати відповідність UID до імен для FlowSchemas та PriorityLevelConfigurations.

Точки налагодження

З увімкненою функцією APIPriorityAndFairness, kube-apiserver обслуговує наступні додаткові шляхи на своїх HTTP(S) портах.

Вам потрібно переконатися, що у вас є дозволи для доступу до цих точок. Вам не потрібно нічого робити, якщо ви адміністратор. Дозволи можуть бути надані за необхідністю відповідно до RBAC документа для доступу до /debug/api_priority_and_fairness/ шляхом зазначення nonResourceURLs.

  • /debug/api_priority_and_fairness/dump_priority_levels — перелік усіх рівнів пріоритету та поточний стан кожного. Ви можете отримати його так:

    kubectl get --raw /debug/api_priority_and_fairness/dump_priority_levels
    

    Вихідні дані будуть у форматі CSV та подібні до цього:

    PriorityLevelName, ActiveQueues, IsIdle, IsQuiescing, WaitingRequests, ExecutingRequests, DispatchedRequests, RejectedRequests, TimedoutRequests, CancelledRequests
    catch-all,         0,            true,   false,       0,               0,                 1,                  0,                0,                0
    exempt,            0,            true,   false,       0,               0,                 0,                  0,                0,                0
    global-default,    0,            true,   false,       0,               0,                 46,                 0,                0,                0
    leader-election,   0,            true,   false,       0,               0,                 4,                  0,                0,                0
    node-high,         0,            true,   false,       0,               0,                 34,                 0,                0,                0
    system,            0,            true,   false,       0,               0,                 48,                 0,                0,                0
    workload-high,     0,            true,   false,       0,               0,                 500,                0,                0,                0
    workload-low,      0,            true,   false,       0,               0,                 0,                  0,                0,                0
    

    Пояснення для вибраних назв стовпців:

    • IsQuiescing вказує, чи буде цей рівень пріоритету видалено, коли його черги буде спустошено.
  • /debug/api_priority_and_fairness/dump_queues — перелік усіх черг та їх поточний стан. Ви можете отримати його так:

    kubectl get --raw /debug/api_priority_and_fairness/dump_queues
    

    Вихідні дані будуть у форматі CSV та подібні до цього:

    PriorityLevelName, Index,  PendingRequests, ExecutingRequests, SeatsInUse, NextDispatchR,   InitialSeatsSum, MaxSeatsSum, TotalWorkSum
    workload-low,      14,     27,              0,                 0,          77.64342019ss,   270,             270,         0.81000000ss
    workload-low,      74,     26,              0,                 0,          76.95387841ss,   260,             260,         0.78000000ss
    ...
    leader-election,   0,      0,               0,                 0,          5088.87053833ss, 0,               0,           0.00000000ss
    leader-election,   1,      0,               0,                 0,          0.00000000ss,    0,               0,           0.00000000ss
    ...
    workload-high,     0,      0,               0,                 0,          0.00000000ss,    0,               0,           0.00000000ss
    workload-high,     1,      0,               0,                 0,          1119.44936475ss, 0,               0,           0.00000000ss
    

    Пояснення для вибраних назв стовпців:

    • NextDispatchR: показник прогресу R, в одиницях секунд-місць, на якому буде відправлено наступний запит.
    • InitialSeatsSum: сума InitialSeats, повʼязана з усіма запитами в даній черзі.
    • MaxSeatsSum: сума MaxSeats, повʼязана з усіма запитами в даній черзі.
    • TotalWorkSum: сума загальної роботи, в одиницях секунд-місць, усіх запитів, що очікують в черзі.

    Примітка: seat-second (скорочено як ss) є одиницею вимірювання роботи в світі APF.

  • /debug/api_priority_and_fairness/dump_requests — перелік усіх запитів, включаючи запити, що очікують у черзі та запити, що виконуються. Ви можете отримати його так:

    kubectl get --raw /debug/api_priority_and_fairness/dump_requests
    

    Вихідні дані будуть у форматі CSV та подібні до цього:

    PriorityLevelName, FlowSchemaName,   QueueIndex, RequestIndexInQueue, FlowDistingsher,                        ArriveTime,                     InitialSeats, FinalSeats, AdditionalLatency, StartTime
    exempt,            exempt,           -1,         -1,                  ,                                       2023-07-15T04:51:25.596404345Z, 1,            0,          0s,                2023-07-15T04:51:25.596404345Z
    workload-low,      service-accounts, 14,         0,                   system:serviceaccount:default:loadtest, 2023-07-18T00:12:51.386556253Z, 10,           0,          0s,                0001-01-01T00:00:00Z
    workload-low,      service-accounts, 14,         1,                   system:serviceaccount:default:loadtest, 2023-07-18T00:12:51.487092539Z, 10,           0,          0s,                0001-01-01T00:00:00Z
    

    Ви можете отримати більш детальний перелік за допомогою команди:

    kubectl get --raw '/debug/api_priority_and_fairness/dump_requests?includeRequestDetails=1'
    

    Вихідні дані будуть у форматі CSV та подібні до цього:

    PriorityLevelName, FlowSchemaName,   QueueIndex, RequestIndexInQueue, FlowDistingsher,                        ArriveTime,                     InitialSeats, FinalSeats, AdditionalLatency, StartTime,                      UserName,                               Verb,   APIPath,                                   Namespace,   Name,   APIVersion, Resource,   SubResource
    exempt,            exempt,           -1,         -1,                  ,                                       2023-07-15T04:51:25.596404345Z, 1,            0,          0s,                2023-07-15T04:51:25.596404345Z, system:serviceaccount:system:admin,     list,   /api/v1/namespaces/kube-stress/configmaps, kube-stress, ,       v1,         configmaps,
    workload-low,      service-accounts, 14,         0,                   system:serviceaccount:default:loadtest, 2023-07-18T00:13:08.986534842Z, 10,           0,          0s,                0001-01-01T00:00:00Z,           system:serviceaccount:default:loadtest, list,   /api/v1/namespaces/kube-stress/configmaps, kube-stress, ,       v1,         configmaps,
    workload-low,      service-accounts, 14,         1,                   system:serviceaccount:default:loadtest, 2023-07-18T00:13:09.086476021Z, 10,           0,          0s,                0001-01-01T00:00:00Z,           system:serviceaccount:default:loadtest, list,   /api/v1/namespaces/kube-stress/configmaps, kube-stress, ,       v1,         configmaps,
    

    Пояснення для вибраних назв стовпців:

    • QueueIndex: індекс черги. Він буде -1 для рівнів пріоритету без черг.
    • RequestIndexInQueue: індекс у черзі для даного запиту. Він буде -1 для запитів, що виконуються.
    • InitialSeats: кількість місць, які будуть зайняті під час початкового (нормального) етапу виконання запиту.
    • FinalSeats: кількість місць, які будуть зайняті під час завершального етапу виконання запиту, враховуючи повʼязані повідомлення WATCH.
    • AdditionalLatency: додатковий час, витрачений під час завершального етапу виконання запиту. FinalSeats будуть зайняті протягом цього періоду. Це не означає будь-яку затримку, яку спостерігатиме користувач.
    • StartTime: час початку виконання запиту. Він буде 0001-01-01T00:00:00Z для запитів, що очікують у черзі.

Ведення логів налагодження

На рівні -v=3 або вище, API-сервер виводить рядок httplog для кожного запиту в лозі API-сервера, і він містить наступні атрибути.

  • apf_fs: імʼя схеми потоку, до якої був класифікований запит.
  • apf_pl: імʼя рівня пріоритету для цієї схеми потоку.
  • apf_iseats: кількість місць, визначених для початкового (нормального) етапу виконання запиту.
  • apf_fseats: кількість місць, визначених для завершального етапу виконання (з урахуванням повʼязаних повідомлень watch) запиту.
  • apf_additionalLatency: тривалість завершального етапу виконання запиту.

На вищих рівнях деталізації логу будуть рядки, що розкривають деталі того, як APF обробив запит, в основному для цілей налагодження.

Заголовки відповіді

APF додає наступні два заголовки до кожного HTTP повідомлення. Вони не зʼявляться в лозі аудиту. Їх можна переглянути з боку клієнта. Для клієнтів, що використовують klog, використовуйте рівень деталізації -v=8 або вище, щоб переглянути ці заголовки.

  • X-Kubernetes-PF-FlowSchema-UID містить UID обʼєкта FlowSchema, до якого був класифікований відповідний запит.
  • X-Kubernetes-PF-PriorityLevel-UID містить UID обʼєкта PriorityLevelConfiguration, повʼязаного з цією FlowSchema.

Що далі

Для отримання фонової інформації про деталі дизайну пріоритету та справедливості API дивіться пропозицію щодо покращення.

6.14 - Конфігураційні API

6.14.1 - Client Authentication (v1)

Типи ресурсів

ExecCredential

ExecCredential використовується втулками на основі exec для передачі облікових даних до HTTP транспортів.

ПолеОпис
apiVersion
string
client.authentication.k8s.io/v1
kind
string
ExecCredential
spec [Обовʼязкове]
ExecCredentialSpec

Spec містить інформацію, передану транспортом втулку.

status
ExecCredentialStatus

Status заповнюється втулоком і містить облікові дані, які транспорт повинен використовувати для контакту з API.

Cluster

Зустрічається в:

Cluster містить інформацію, що дозволяє exec втулку спілкуватися з кластером Kubernetes, до якого здійснюється автентифікація.

Щоб забезпечити наявність у цій структурі всього необхідного для звʼязку з кластером Kubernetes (як це робиться через kubeconfig), поля повинні відображати структуру "k8s.io/client-go/tools/clientcmd/api/v1". Cluster, за винятком CertificateAuthority, оскільки дані CA завжди будуть передаватися втулку у вигляді байтів.

ПолеОпис
server [Обовʼязкове]
string

Server — це адреса кластера Kubernetes (https://hostname:port).

tls-server-name
string

TLSServerName передається серверу для SNI і використовується у клієнті для перевірки сертифікатів сервера. Якщо ServerName порожній, використовується імʼя хоста, за яким здійснюється контакт з сервером.

insecure-skip-tls-verify
bool

InsecureSkipTLSVerify пропускає перевірку дійсності сертифіката сервера. Це зробить ваші HTTPS-зʼєднання небезпечними.

certificate-authority-data
[]byte

CAData містить сертифікати органів сертифікації, закодовані у форматі PEM. Якщо порожнє, слід використовувати системні корені.

proxy-url
string

ProxyURL — це URL-адреса проксі-сервера, який буде використовуватися для всіх запитів до цього кластера.

disable-compression
bool

DisableCompression дозволяє клієнту відмовитися від стиснення відповідей для всіх запитів до сервера. Це корисно для прискорення запитів (особливо списків), коли пропускна здатність мережі клієнт-сервер достатня, за рахунок економії часу на стиснення (на стороні сервера) і розпакування (на стороні клієнта): https://github.com/kubernetes/kubernetes/issues/112296.

config
k8s.io/apimachinery/pkg/runtime.RawExtension

Config містить додаткові дані конфігурації, специфічні для exec втулка щодо кластера, до якого здійснюється автентифікація.

Ці дані походять з поля extensions[client.authentication.k8s.io/exec] обʼєкта Cluster клієнтської конфігурації:

clusters:

  • name: my-cluster
    cluster:
    ...
    extensions:
    • name: client.authentication.k8s.io/exec # зарезервована назва розширення для конфігурації exec для кожного кластера
      extension:
      audience: 06e3fbd18de8 # довільна конфігурація

В деяких середовищах конфігурація користувача може бути точно такою ж для багатьох кластерів (тобто викликати цей exec втулок), за винятком деяких деталей, специфічних для кожного кластера, таких як аудиторія. Це поле дозволяє безпосередньо вказати конфігурацію для кожного кластера разом з інформацією про кластер. Використання цього поля для зберігання секретних даних не рекомендується, оскільки однією з основних переваг exec втулків є те, що жодні секрети не потрібно зберігати безпосередньо в kubeconfig.

ExecCredentialSpec

Зустрічається в:

ExecCredentialSpec містить інформацію про запит і специфічну для часу виконання, надану транспортом.

ПолеОпис
cluster
Cluster

Cluster містить інформацію, що дозволяє exec втулку спілкуватися з кластером Kubernetes, до якого здійснюється автентифікація. Зверніть увагу, що Cluster є ненульовим тільки тоді, коли provideClusterInfo встановлено в true у конфігурації exec провайдера (тобто, ExecConfig.ProvideClusterInfo).

interactive [Обовʼязкове]
bool

Interactive вказує, чи було передано stdin цьому exec втулку.

ExecCredentialStatus

Зустрічається в:

ExecCredentialStatus містить облікові дані для використання транспортом.

Token і ClientKeyData є конфіденційними полями. Ці дані повинні передаватися тільки в памʼяті між клієнтом і процесом exec втулка. Сам exec втулок повинен бути захищений принаймні через права доступу до файлів.

ПолеОпис
expirationTimestamp
meta/v1.Time

ExpirationTimestamp вказує час, коли надані облікові дані закінчуються.

token [Обовʼязкове]
string

Token є маркером доступу, що використовується клієнтом для автентифікації запитів.

clientCertificateData [Обовʼязкове]
string

PEM-кодовані клієнтські TLS сертифікати (включаючи проміжні, якщо є).

clientKeyData [Обовʼязкове]
string

PEM-кодований приватний ключ для вищезгаданого сертифіката.

6.14.2 - Client Authentication (v1beta1)

Типи ресурсів

ExecCredential

ExecCredential використовується втулками на основі exec для передачі облікових даних до HTTP транспортів.

ПолеОпис
apiVersion
string
client.authentication.k8s.io/v1beta1
kind
string
ExecCredential
spec [Обовʼязкове]
ExecCredentialSpec

Spec містить інформацію, передану транспортом втулку.

status
ExecCredentialStatus

Status заповнюється втулком і містить облікові дані, які транспорт повинен використовувати для контакту з API.

Cluster

Зустрічається в:

Cluster містить інформацію, що дозволяє exec втулку спілкуватися з кластером Kubernetes, до якого здійснюється аутентифікація.

Щоб забезпечити наявність у цій структурі всього необхідного для звʼязку з кластером Kubernetes (як це робиться через kubeconfig), поля повинні відображати структуру "k8s.io/client-go/tools/clientcmd/api/v1". Cluster, за винятком CertificateAuthority, оскільки дані CA завжди будуть передаватися втулку у вигляді байтів.

ПолеОпис
server [Обовʼязкове]
string

Server — це адреса кластера Kubernetes (https://hostname:port).

tls-server-name
string

TLSServerName передається серверу для SNI і використовується у клієнті для перевірки сертифікатів сервера. Якщо ServerName порожній, використовується імʼя хоста, за яким здійснюється контакт з сервером.

insecure-skip-tls-verify
bool

InsecureSkipTLSVerify пропускає перевірку дійсності сертифіката сервера. Це зробить ваші HTTPS-зʼєднання небезпечними.

certificate-authority-data
[]byte

CAData містить сертифікати органів сертифікації, закодовані у форматі PEM. Якщо порожнє, слід використовувати системні корені.

proxy-url
string

ProxyURL — це URL-адреса проксі-сервера, який буде використовуватися для всіх запитів до цього кластера.

disable-compression
bool

DisableCompression дозволяє клієнту відмовитися від стиснення відповідей для всіх запитів до сервера. Це корисно для прискорення запитів (особливо списків), коли пропускна здатність мережі клієнт-сервер достатня, за рахунок економії часу на стиснення (на стороні сервера) і розпакування (на стороні клієнта): https://github.com/kubernetes/kubernetes/issues/112296.

config
k8s.io/apimachinery/pkg/runtime.RawExtension

Config містить додаткові дані конфігурації, специфічні для exec втулка щодо кластера, до якого здійснюється аутентифікація.

Ці дані походять з поля extensions[client.authentication.k8s.io/exec] обʼєктаCluster клієнтської конфігурації:

clusters:

  • name: my-cluster
    cluster:
    ...
    extensions:
    • name: client.authentication.k8s.io/exec # зарезервована назва розширення для конфігурації exec для кожного кластера
      extension:
      audience: 06e3fbd18de8 # довільна конфігурація

В деяких середовищах конфігурація користувача може бути точно такою ж для багатьох кластерів (тобто викликати цей exec втулок), за винятком деяких деталей, специфічних для кожного кластера, таких як аудиторія. Це поле дозволяє безпосередньо вказати конфігурацію для кожного кластера разом з інформацією про кластер. Використання цього поля для зберігання секретних даних не рекомендується, оскільки однією з основних переваг exec плагінів є те, що жодні секрети не потрібно зберігати безпосередньо в kubeconfig.

ExecCredentialSpec

Зустрічається в:

ExecCredentialSpec містить інформацію про запит і специфічну для часу виконання, надану транспортом.

ПолеОпис
cluster
Cluster

Cluster містить інформацію, що дозволяє exec втулку спілкуватися з кластером Kubernetes, до якого здійснюється автентифікація. Зверніть увагу, що Cluster є ненульовим тільки тоді, коли provideClusterInfo встановлено в true у конфігурації exec провайдера (тобто, ExecConfig.ProvideClusterInfo).

interactive [Обовʼязкове]
bool

Interactive вказує, чи було передано stdin цьому exec втулку.

ExecCredentialStatus

Зустрічається в:

ExecCredentialStatus містить облікові дані для використання транспортом.

Token і ClientKeyData є конфіденційними полями. Ці дані повинні передаватися тільки в памʼяті між клієнтом і процесом exec втулка. Сам exec втулок повинен бути захищений принаймні через права доступу до файлів.

ПолеОпис
expirationTimestamp
meta/v1.Time

ExpirationTimestamp вказує час, коли надані облікові дані закінчуються.

token [Обовʼязкове]
string

Token є маркером доступу, що використовується клієнтом для аутентифікації запитів.

clientCertificateData [Обовʼязкове]
string

PEM-кодовані клієнтські TLS сертифікати (включаючи проміжні, якщо є).

clientKeyData [Обовʼязкове]
string

PEM-кодований приватний ключ для вищезгаданого сертифіката.

6.14.3 - Event Rate Limit Configuration (v1alpha1)

Типи ресурсів

Configuration

Configuration надає конфігурацію для контролера доступу EventRateLimit.

ПолеОпис
apiVersion
string
eventratelimit.admission.k8s.io/v1alpha1
kind
string
Configuration
limits [Обовʼязкове]
[]Limit

limits — це обмеження на запити подій, що надходять. Обмеження можуть бути встановлені на події, отримані на рівні сервера, на рівні простору імен, на рівні користувача та на рівні джерела+обʼєкта. Потрібно принаймні одне обмеження.

Limit

Зустрічається в:

Limit — це конфігурація для певного типу обмеження.

ПолеОпис
type [Обовʼязкове]
LimitType

type — це тип обмеження, до якого застосовується ця конфігурація.

qps [Обовʼязкове]
int32

qps — це кількість запитів подій на секунду, дозволених для цього типу обмеження. Поля qps та burst використовуються разом, щоб визначити, чи приймається певний запит події. qps визначає, скільки запитів приймаються після вичерпання кількості запитів burst.

burst [Обовʼязкове]
int32

burst — це кількість запитів подій burst, дозволених для цього типу обмеження. Поля qps та burst використовуються разом, щоб визначити, чи приймається певний запит події. burst визначає максимальний розмір дозволу, наданого для певного відра. Наприклад, якщо burst дорівнює 10, а qps дорівнює 3, то контроль доступу прийме 10 запитів перед блокуванням будь-яких запитів. Кожну секунду буде дозволено ще 3 запити. Якщо деяка частина цього дозволу не використовується, то вона переноситься на наступну секунду, поки не буде досягнуто максимального дозволу у 10 запитів.

cacheSize
int32

cacheSize — це розмір LRU кешу для цього типу обмеження. Якщо кощик видаляється з кешу, то дозвол для цього кошика скидається. Якщо пізніше отримуються більше запитів для видаленого кошика, то цей кошик знову потрапляє в кеш з чистого аркуша, надаючи цьому кошику повний дозвіл на запити burst.

Стандартний розмір кешу становить 4096.

Якщо limitType — 'server', то cacheSize ігнорується.

LimitType

(Аліас string)

Зустрічається в:

LimitType — це тип обмеження (наприклад, на рівні простору імен).

6.14.4 - Image Policy API (v1alpha1)

Типи ресурсів

ImageReview

ImageReview перевіряє, чи дозволений набір образів у поді.

ПолеОпис
apiVersion
string
imagepolicy.k8s.io/v1alpha1
kind
string
ImageReview
metadata
meta/v1.ObjectMeta

Стандартні метадані обʼєкта. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata. Зверніться до документації Kubernetes API для полів метаданих metadata.

spec [Обовʼязкове]
ImageReviewSpec

Spec містить інформацію про под, що оцінюється.

status
ImageReviewStatus

Status заповнюється бекендом і вказує, чи слід дозволити Pod.

ImageReviewContainerSpec

Зустрічається в:

ImageReviewContainerSpec — це опис контейнера в запиті на створення Podʼа.

ПолеОпис
image
string

Це може бути у вигляді image:tag або image@SHA:012345679abcdef.

ImageReviewSpec

Зустрічається в:

ImageReviewSpec — це опис запиту на створення Podʼа.

ПолеОпис
containers
[]ImageReviewContainerSpec

Containers — це список підмножини інформації в кожному контейнері пода, що створюється.

annotations
map[string]string

Annotations — це список ключ-значення, витягнутий з анотацій Podʼа. Він включає лише ключі, які відповідають шаблону *.image-policy.k8s.io/*. Відповідно до кожного веб-хука, щоб визначити, як інтерпретувати ці анотації, якщо взагалі.

namespace
string

Namespace — це простір імен, в якому створюється под.

ImageReviewStatus

Зустрічається в:

ImageReviewStatus — це результат перевірки запиту на створення Podʼа.

ПолеОпис
allowed [Обовʼязкове]
bool

Allowed вказує, що всі образи були дозволені до виконання.

reason
string

Reason має бути порожнім, якщо Allowed є true, у протилежному випадку може містити короткий опис проблеми. Kubernetes може обрізати надто довгі помилки під час відображення користувачу.

auditAnnotations
map[string]string

AuditAnnotations буде додано до обʼєкта атрибутів запиту контролера доступу за допомогою 'AddAnnotation'. Ключі повинні бути без префіксів (тобто контролер доступу додасть відповідний префікс).

6.14.5 - kube-apiserver Admission (v1)

Типи ресурсів

AdmissionReview

AdmissionReview описує запит/відповідь на перегляд доступу.

ПолеОпис
apiVersion
string
admission.k8s.io/v1
kind
string
AdmissionReview
request
AdmissionRequest

Request описує атрибути запиту на перегляд доступу.

response
AdmissionResponse

Response описує атрибути відповіді на перегляд доступу.

AdmissionRequest

Зʼявляється в:

AdmissionRequest описує атрибути доступу для запиту на перегляд доступу.

ПолеОпис
uid [Обовʼязкове]
k8s.io/apimachinery/pkg/types.UID

UID — це ідентифікатор для індивідуального запиту/відповіді. Це дозволяє нам розрізняти випадки запитів, які є в іншому випадку ідентичними (паралельні запити, запити, коли попередні запити не змінили і т. д.). UID призначений для відстеження зворотного звʼязку (запит/відповідь) між KAS і WebHook, а не користувацьким запитом. Він підходить для співставлення записів журналу між вебхуком і apiserver для аудиту або налагодження.

kind [Обовʼязкове]
meta/v1.GroupVersionKind

Kind — це повністю кваліфікований тип обʼєкта, що подається (наприклад, v1.Pod або autoscaling.v1.Scale)

resource [Обовʼязкове]
meta/v1.GroupVersionResource

Resource — це повністю кваліфікований ресурс, що запитується (наприклад, v1.pods)

subResource
string

SubResource — це субресурс, що запитується, якщо такий є (наприклад, "status" або "scale")

requestKind
meta/v1.GroupVersionKind

RequestKind — це повністю кваліфікований тип початкового API-запиту (наприклад, v1.Pod або autoscaling.v1.Scale). Якщо це вказано і відрізняється від значення в "kind", було виконано еквівалентне співставлення та перетворення.

Наприклад, якщо deployments можна змінювати за допомогою apps/v1 та apps/v1beta1, і вебхук зареєстрував правило apiGroups:["apps"], apiVersions:["v1"], resources: ["deployments"] і matchPolicy: Equivalent, API-запит до деплойментів apps/v1beta1 буде перетворено та надіслано до вебхука з kind: {group:"apps", version:"v1", kind:"Deployment"} (відповідно до правила, зареєстрованого вебхуком), і requestKind: {group:"apps", version:"v1beta1", kind:"Deployment"} (вказуючи на тип початкового API-запиту).

Дивіться документацію для поля "matchPolicy" у типі конфігурації вебхука для отримання додаткової інформації.

requestResource
meta/v1.GroupVersionResource

RequestResource — це повністю кваліфікований ресурс початкового API-запиту (наприклад, v1.pods). Якщо це вказано і відрізняється від значення в "resource", було виконано еквівалентне співставлення та перетворення.

Наприклад, якщо deployments можна змінювати за допомогою apps/v1 та apps/v1beta1, і вебхук зареєстрував правило apiGroups:["apps"], apiVersions:["v1"], resources: ["deployments"] і matchPolicy: Equivalent, API-запит до деплойментів apps/v1beta1 буде перетворено та надіслано до вебхука з resource: {group:"apps", version:"v1", resource:"deployments"} (відповідно до ресурсу, зареєстрованого вебхуком), і requestResource: {group:"apps", version:"v1beta1", resource:"deployments"} (вказуючи на ресурс початкового API-запиту).

Дивіться документацію для поля "matchPolicy" у типі конфігурації вебхука.

requestSubResource
string

RequestSubResource — це назва субресурсу початкового API-запиту, якщо такий є (наприклад, "status" або "scale"). Якщо це вказано і відрізняється від значення в "subResource", було виконано еквівалентне співставлення та перетворення. Дивіться документацію для поля "matchPolicy" у типі конфігурації вебхука.

name
string

Імʼя — це назва обʼєкта, як подано в запиті. У разі операції CREATE клієнт може не вказати імʼя та покластися на сервер для генерації імені. Якщо це так, це поле буде містити порожній рядок.

namespace
string

Namespace — це простір імен, повʼязаний із запитом (якщо є).

operation [Обовʼязкове]
Operation

Operation — це операція, що виконується. Це може відрізнятися від операції, що запитується. Наприклад, патч може призвести до виконання операції CREATE або UPDATE.

userInfo [Обовʼязкове]
authentication/v1.UserInfo

UserInfo — це інформація про користувача, який виконує запит

object
k8s.io/apimachinery/pkg/runtime.RawExtension

Object — це обʼєкт з вхідного запиту.

oldObject
k8s.io/apimachinery/ pkg/runtime.RawExtension

OldObject — це існуючий обʼєкт. Заповнюється тільки для запитів TE і UPDATE. 

dryRun
bool

DryRun вказує, що зміни точно не ть збережені —ля цього запиту. Типово: false.

options
k8s.io/apimachinery/pkg/runtime.RawExtension

Options — це структура опцій операції, що виконується. наприклад, meta.k8s.io/v1.DeleteOptions або meta.k8s.io/v1.CreateOptions. Це може бути інше, ніж опції, надані викликачем. наприклад, для запиту патчу виконана операція може бути CREATE, у цьому випадку Options буде meta.k8s.io/v1.CreateOptions, навіть якщо викликач надав meta.k8s.io/v1.PatchOptions.

AdmissionResponse

Зʼявляється в:

AdmissionResponse описує відповідь на перегляд доступу.

ПолеОпис
uid [Обовʼязкове]
k8s.io/apimachinery/pkg/types.UID

UID — це ідентифікатор для індивідуального запиту/відповіді. Це повинно бути скопійовано з відповідного AdmissionRequest.

allowed [Обовʼязкове]
bool

Allowed вказує, чи було дозволено запит на перегляд доступу.

status
meta/v1.Status

Result містить додаткові деталі щодо причин відхилення запиту на перегляд доступу. Це поле НЕ враховується, якщо "Allowed" є "true".

patch
[]byte

Тіло патчу. Наразі ми підтримуємо лише "JSONPatch", який реалізує RFC 6902.

patchType
PatchType

Тип патчу. Наразі ми підтримуємо лише "JSONPatch".

auditAnnotations
map[string]string

AuditAnnotations — це неструктурована карта ключ-значення, встановлена віддаленим контролером перегляду доступу (наприклад, error=image-blacklisted). Контролери MutatingAdmissionWebhook і ValidatingAdmissionWebhook додадуть до ключів префікс з іменем вебхука (наприклад, imagepolicy.example.com/error=image-blacklisted). AuditAnnotations буде надано вебхуком для додавання додаткового контексту до логу аудиту для цього запиту.

warnings
[]string

Warnings — це список попереджувальних повідомлень, що повертаються клієнту API, який робить запит. Попереджувальні повідомлення описують проблему, яку клієнт, що робить API-запит, має виправити або врахувати. По можливості обмежте попереджувальні повідомлення до 120 символів. Попереджувальні повідомлення, що перевищують 256 символів, та велика кількість попереджувальних повідомлень можуть бути скорочені.

Operation

(Аліас string)

Зʼявляється в:

Operation — це тип операції з ресурсом, який перевіряється для контролю доступу

PatchType

(Аліас string)

Зʼявляється в:

PatchType — це тип патчу, що використовується для представлення зміненого обʼєкта.

6.14.6 - kube-apiserver Audit Configuration (v1)

Типи ресурсів

Event

Зустрічається в:

Подія захоплює всю інформацію, яка може бути включена в лог аудиту API.

ПолеОпис
apiVersion
string
audit.k8s.io/v1
kind
string
Event
level [Обовʼязково]
Level

Рівень аудиту, на якому була згенерована подія.

auditID [Обовʼязково]
k8s.io/apimachinery/pkg/types.UID

Унікальний ідентифікатор аудиту, згенерований для кожного запиту.

stage [Обовʼязково]
Stage

Стадія обробки запиту, коли був згенерований цей екземпляр події.

requestURI [Обовʼязково]
string

RequestURI — це URI запиту, який був надісланий клієнтом на сервер.

verb [Обовʼязково]
string

Verb — це дієслово Kubernetes, повʼязане із запитом. Для запитів без ресурсів це нижчий регістр HTTP-методу.

user [Обовʼязково]
authentication/v1.UserInfo

Інформація про автентифікованого користувача.

impersonatedUser
authentication/v1.UserInfo

Інформація про користувача, який діє від імені іншого користувача.

sourceIPs
[]string

IP-адреси джерела, звідки надійшов запит і проміжні проксі-сервери. IP-адреси джерела вказані у наступному порядку:

  1. IP-адреси заголовку запиту X-Forwarded-For
  2. Заголовок X-Real-Ip, якщо він не присутній у списку X-Forwarded-For
  3. Віддалена адреса для зʼєднання, якщо вона не відповідає останній IP-адресі у списку до цього (X-Forwarded-For або X-Real-Ip). Примітка: Усі, крім останнього IP, можуть бути довільно встановлені клієнтом.
userAgent
string

UserAgent записує рядок агента користувача, наданий клієнтом. Зазначте, що UserAgent надається клієнтом і не може бути довіреним.

objectRef
ObjectReference

Обʼєктне посилання на цей запит. Не застосовується для запитів типу Список або запитів без ресурсів.

responseStatus
meta/v1.Status

Статус відповіді, заповнений навіть коли ObjectReference не є типом Status. Для успішних відповідей це міститиме лише Code і StatusSuccess. Для не-статусних типів помилок відповідей це буде автоматично заповнено повідомленням про помилку.

requestObject
k8s.io/apimachinery/pkg/runtime.Unknown

Обʼєкт API із запиту у форматі JSON. RequestObject записується в тому вигляді, в якому він був у запиті (можливо, повторно закодований як JSON), до конвертації версій, стандартно, допуску або злиття. Це зовнішній обʼєкт типу версії, і він може бути недійсним обʼєктом самостійно. Опускається для запитів без ресурсів. Записується тільки на рівні Request та вище.

responseObject
k8s.io/apimachinery/pkg/runtime.Unknown

Обʼєкт API, що повертається у відповіді, у форматі JSON. ResponseObject записується після перетворення на зовнішній тип і серіалізується як JSON. Опускається для запитів без ресурсів. Записується тільки на рівні Response.

requestReceivedTimestamp
meta/v1.MicroTime

Час, коли запит досяг сервера API.

stageTimestamp
meta/v1.MicroTime

Час, коли запит досяг поточної стадії аудиту.

annotations
map[string]string

Анотації — це неструктуровані ключові значення, які зберігаються разом з подією аудиту і можуть бути встановлені втулками, викликаними в ланцюжку обслуговування запитів, включаючи втулки автентифікації, авторизації та допуску. Зазначте, що ці анотації призначені для події аудиту і не відповідають метаданим анотацій надісланого обʼєкта. Ключі повинні унікально ідентифікувати інформуючий компонент.

EventList

EventList містить події аудиту API.

ПолеОпис
apiVersion
string
audit.k8s.io/v1
kind
string
EventList
metadata
meta/v1.ListMeta

Метадані списку, такі як інформація про пагінацію.

items [Обовʼязково]
[]Event

Перелік подій аудиту.

Policy

Зʼявляється у:

Політика визначає конфігурацію журналювання аудиту та правила для того, як різні категорії запитів мають бути зареєстровані.

ПолеОпис
apiVersion
string
audit.k8s.io/v1
kind
string
Policy
metadata
meta/v1.ObjectMeta

ObjectMeta включено для забезпечення сумісності з API-інфраструктурою.

Зверніться до документації Kubernetes API для полів поля metadata.

rules [Обовʼязково]
[]PolicyRule

Правила визначають рівень аудиту, на якому має бути записаний запит.

Запит може відповідати кільком правилам, у такому випадку буде використано ПЕРШЕ відповідне правило.

Типово рівень аудиту — None, але може бути переважений універсальним правилом в кінці списку.

PolicyRules мають строго визначений порядок.

omitStages
[]Stage

OmitStages — це список етапів, для яких не створюються події. Зверніть увагу, що це також може бути вказано для кожного правила окремо, у такому випадку обʼєднання обох буде пропущено.

omitManagedFields
bool

OmitManagedFields вказує, чи слід пропускати керовані поля запитів та відповідей у журналі аудиту API.

Це використовується як глобальний стандарт — значення 'true' призведе до пропуску керованих полів, в іншому випадку керовані поля будуть включені до логу аудиту API.

Зверніть увагу, що це також може бути вказано для кожного правила окремо, у такому випадку значення, зазначене в правилі, переважить глобальний стандарт.

PolicyList

PolicyList — це список політик аудиту.

ПолеОпис
apiVersion
string
audit.k8s.io/v1
kind
string
PolicyList
metadata
meta/v1.ListMeta
Опис не надано.
items [Обовʼязково]
[]Policy
Опис не надано.

GroupResources

Зустрічається в:

GroupResources представляють типи ресурсів в API групі.

ПолеОпис
group
string

Група — це назва API групи, яка містить ресурси. Порожній рядок представляє основну API групу.

resources
[]string

Ресурси — це список ресурсів, до яких застосовується це правило.

Наприклад:

  • pods відповідає Podʼам.
  • pods/log відповідає субресурсу log Podʼів.
  • * відповідає всім ресурсам та їх субресурсам.
  • pods/* відповідає всім субресурсам Podʼів.
  • */scale відповідає всім субресурсам масштабу.

Якщо присутній підстановочний знак, правило перевірки забезпечить, що ресурси не перекриваються між собою.

Порожній список означає, що застосовуються всі ресурси та субресурси в цій API групі.

resourceNames
[]string

resourceNames — це список імен екземплярів ресурсів, які відповідають політиці. Використання цього поля вимагає, щоб Ресурси були вказані. Порожній список означає, що кожен екземпляр ресурсу відповідає.

Level

(Аліас string)

Зустрічається в:

Level визначає кількість інформації, що реєструється під час аудиту

ObjectReference

Зустрічається в:

ObjectReference містить достатньо інформації, щоб дозволити вам перевірити або змінити обʼєкт, на який посилається.

ПолеОпис
resource
string
Опис відсутній.
namespace
string
Опис відсутній.
name
string
Опис відсутній.
uid
k8s.io/apimachinery/pkg/types.UID
Опис відсутній.
apiGroup
string

APIGroup — це назва API групи, яка містить обʼєкт, на який посилаються. Порожній рядок представляє основну API групу.

apiVersion
string

APIVersion — це версія API групи, яка містить обʼєкт, на який посилаються.

resourceVersion
string
Опис відсутній.
subresource
string
Опис відсутній.

PolicyRule

Зʼявляється в:

PolicyRule зіставляє запити на основі метаданих з рівнем аудиту. Запити повинні відповідати правилам кожного поля (перетин правил).

ПолеОпис
level [Обовʼязково]
Level

Рівень, на якому записуються запити, що відповідають цьому правилу.

users
[]string

Користувачі (за автентифікованим імʼям користувача), до яких застосовується це правило. Порожній список означає всіх користувачів.

userGroups
[]string

Групи користувачів, до яких застосовується це правило. Користувач вважається відповідним, якщо він є членом будь-якої з UserGroups. Порожній список означає всі групи користувачів.

verbs
[]string

Дії, що відповідають цьому правилу. Порожній список означає всі дії.

resources
[]GroupResources

Ресурси, що відповідають цьому правилу. Порожній список означає всі види у всіх групах API.

namespaces
[]string

Простори імен, що відповідають цьому правилу. Порожній рядок "" відповідає ресурсам без простору імен. Порожній список означає всі простори імен.

nonResourceURLs
[]string

NonResourceURLs — це набір шляхів URL, які повинні бути аудійовані. * дозволені, але тільки як повний, кінцевий крок у шляху. Приклади:

  • /metrics — Записувати запити для метрик apiserver
  • /healthz* — Записувати всі перевірки стану
omitStages
[]Stage

OmitStages — це список стадій, для яких не створюються події. Зверніть увагу, що це також може бути зазначено для всієї політики, в такому випадку обʼєднання обох буде виключено. Порожній список означає, що обмеження не застосовуються.

omitManagedFields
bool

OmitManagedFields вказує, чи слід виключати керовані поля з тіла запиту та відповіді з логу аудиту API.

  • значення 'true' виключає керовані поля з логу аудиту API
  • значення 'false' вказує, що керовані поля повинні бути включені в логу аудиту API. Зверніть увагу, що значення, якщо зазначене, у цьому правилі буде переважати над глобальним стандартним значенням. Якщо значення не зазначено, то діє глобальне стандартне значення, вказане в Policy.OmitManagedFields.

Stage

(Аліас string)

Зʼявляється в:

Stage визначає стадії обробки запитів, на яких можуть створюватися події аудиту.

6.14.7 - kube-apiserver Configuration (v1)

Пакет v1 — це версія API v1.

Типи ресурсів

AdmissionConfiguration

AdmissionConfiguration надає версійовану конфігурацію для контролерів допуску.

ПолеОпис
apiVersion
string
apiserver.config.k8s.io/v1
kind
string
AdmissionConfiguration
plugins
[]AdmissionPluginConfiguration

Plugins дозволяє вказувати конфігурацію для кожного втулка контролю допуску.

EncryptionConfiguration

EncryptionConfiguration зберігає повну конфігурацію для провайдерів шифрування. Він також дозволяє використовувати шаблони для вказання ресурсів, які повинні бути зашифровані. Використовуйте '*.<group>' для шифрування всіх ресурсів у групі або '*.*' для шифрування всіх ресурсів. '*.' можна використовувати для шифрування всіх ресурсів у основній групі. '*.*' зашифрує всі ресурси, навіть користувацькі, які додаються після запуску сервера API. Використання шаблонів, що перекриваються в межах одного списку ресурсів або між кількома записами, не дозволяється, оскільки частина конфігурації буде неефективною. Списки ресурсів обробляються в порядку, причому перші списки мають пріоритет.

Приклад:

kind: EncryptionConfiguration
apiVersion: apiserver.config.k8s.io/v1
resources:
- resources:
  - events
  providers:
  - identity: {}  # не шифрувати події, навіть якщо *.* зазначено нижче
- resources:
  - secrets
  - configmaps
  - pandas.awesome.bears.example
  providers:
  - aescbc:
      keys:
      - name: key1
        secret: c2VjcmV0IGlzIHNlY3VyZQ==
- resources:
  - '*.apps'
  providers:
  - aescbc:
      keys:
      - name: key2
        secret: c2VjcmV0IGlzIHNlY3VyZSwgb3IgaXMgaXQ/Cg==
- resources:
  - '*.*'
  providers:
  - aescbc:
      keys:
      - name: key3
        secret: c2VjcmV0IGlzIHNlY3VyZSwgSSB0aGluaw==
ПолеОпис
apiVersion
string
apiserver.config.k8s.io/v1
kind
string
EncryptionConfiguration
resources [Обовʼязково]
[]ResourceConfiguration

resources — це список, що містить ресурси та відповідні їм провайдери шифрування.

AESConfiguration

Зʼявляється в:

AESConfiguration містить конфігурацію API для AES-трансформера.

ПолеОпис
keys [Обовʼязково]
[]Key

keys — це список ключів, які використовуються для створення AES-трансформера. Кожен ключ повинен бути 32 байти для AES-CBC та 16, 24 або 32 байти для AES-GCM.

AdmissionPluginConfiguration

Зʼявляється в:

AdmissionPluginConfiguration надає конфігурацію для одного втулка.

ПолеОпис
name [Обовʼязково]
string

Name — це назва контролера допуску. Вона повинна відповідати зареєстрованій назві втулка контролю допуску.

path
string

Path — це шлях до конфігураційного файлу, який містить конфігурацію втулка

configuration
k8s.io/apimachinery/pkg/runtime.Unknown

Configuration — це вбудований конфігураційний обʼєкт, який використовується як конфігурація втулка. Якщо він присутній, то буде використовуватися замість шляху до конфігураційного файлу.

IdentityConfiguration

Зʼявляється в:

IdentityConfiguration — це порожня структура, яка дозволяє використовувати трансформер ідентичності в конфігурації провайдера.

KMSConfiguration

Зʼявляється в:

KMSConfiguration містить назву, розмір кешу та шлях до конфігураційного файлу для трансформера конвертів на основі KMS.

ПолеОпис
apiVersion
string

apiVersion KeyManagementService

name [Обовʼязково]
string

name — це назва втулка KMS,який буде використовуватися.

cachesize
int32

cachesize — це максимальна кількість секретів, які кешуються в памʼяті. Стандартне значення — 1000. Встановіть негативне значення, щоб вимкнути кешування. Це поле дозволено лише для провайдерів KMS v1.

endpoint [Обовʼязково]
string

endpoint — це адреса прослуховувння gRPC сервера, наприклад, "unix:///var/run/kms-provider.sock".

timeout
meta/v1.Duration

timeout для gRPC викликів до kms-втулка (наприклад, 5 секунд). Стандатне значення — 3 секунди.

Key

Зʼявляється в:

Key містить імʼя та секрет наданого ключа для трансформера.

ПолеОпис
name [Обовʼязково]
string

name — це імʼя ключа, який буде використовуватися при збереженні даних на диск.

secret [Обовʼязково]
string

secret — це фактичний ключ, закодований в base64.

ProviderConfiguration

Зʼявляється в:

ProviderConfiguration зберігає надану конфігурацію для провайдера шифрування.

ПолеОпис
aesgcm [Обовʼязково]
AESConfiguration

aesgcm — це конфігурація для трансформера AES-GCM.

aescbc [Обовʼязково]
AESConfiguration

aescbc — це конфігурація для трансформера AES-CBC.

secretbox [Обовʼязково]
SecretboxConfiguration

secretbox — це конфігурація для трансформера на основі Secretbox.

identity [Обовʼязково]
IdentityConfiguration

identity — це (порожня) конфігурація для трансформера ідентичності.

kms [Обовʼязково]
KMSConfiguration

kms містить назву, розмір кешу та шлях до конфігураційного файлу для трансформера конвертів на основі KMS.

ResourceConfiguration

Зʼявляється в:

ResourceConfiguration зберігає конфігурацію для кожного ресурсу.

ПолеОпис
resources [Обовʼязково]
[]string

resources — це список ресурсів Kubernetes, які мають бути зашифровані. Імена ресурсів походять від resource або resource.group з group/version/resource. Наприклад: pandas.awesome.bears.example — це ресурс користувача з 'group': awesome.bears.example, 'resource': pandas. Використовуйте '*.*' для шифрування всіх ресурсів і '*.<group>' для шифрування всіх ресурсів у певній групі. Наприклад: '*.awesome.bears.example' зашифрує всі ресурси у групі 'awesome.bears.example'. Наприклад: '*.' зашифрує всі ресурси в основній групі (такі як pods, configmaps тощо).

providers [Обовʼязково]
[]ProviderConfiguration

providers — це список трансформерів, які використовуються для читання та запису ресурсів на диск. Наприклад: aesgcm, aescbc, secretbox, identity, kms.

SecretboxConfiguration

Зʼявляється в:

SecretboxConfiguration містить API конфігурацію для трансформера Secretbox.

ПолеОпис
keys [Обовʼязково]
[]Key

keys — це список ключів, які використовуються для створення трансформера Secretbox. Кожен ключ повинен бути довжиною 32 байти.

6.14.8 - kube-apiserver Configuration (v1alpha1)

Пакет v1alpha1 — це версія API v1alpha1.

Типи ресурсів

TracingConfiguration

Зʼявляється в:

TracingConfiguration надає версійну конфігурацію для клієнтів OpenTelemetry tracing.

ПолеОпис
endpoint
string

Endpoint колектора, куди цей компонент буде надсилати трасування. Зʼєднання є незахищеним і наразі не підтримує TLS. Рекомендується не вказувати, і використовувати стандартно otlp grpc localhost:4317.

samplingRatePerMillion
int32

SamplingRatePerMillion — це кількість зразків, які потрібно збирати на мільйон проміжків. Рекомендується не вказувати. Якщо не вказано, зразок буде відповідати ставці зразка батьківського проміжку, але інакше ніколи не буде зібраний.

AdmissionConfiguration

AdmissionConfiguration надає версійну конфігурацію для контролерів допуску.

ПолеОпис
apiVersion
string
apiserver.k8s.io/v1alpha1
kind
string
AdmissionConfiguration
plugins
[]AdmissionPluginConfiguration

Plugins дозволяє вказати конфігурацію для кожного втулка контролю допуску.

AuthenticationConfiguration

AuthenticationConfiguration надає версійну конфігурацію для автентифікації.

ПолеОпис
apiVersion
string
apiserver.k8s.io/v1alpha1
kind
string
AuthenticationConfiguration
jwt [Обовʼязково]
[]JWTAuthenticator

jwt — це список автентифікаторів для автентифікації користувачів Kubernetes за допомогою JWT-сумісних токенів. Автентифікатор спробує розпарсити ID токен, перевірити, чи він підписаний налаштованим постачальником. Публічний ключ для перевірки підпису знаходиться на публічній точці доступу постачальника, використовуючи OIDC discovery. Для вхідного токена кожен JWT-автентифікатор буде спробований у порядку, в якому він зазначений у цьому списку. Зверніть увагу, що інші автентифікатори можуть запускатися до або після JWT-автентифікаторів. Специфічне розташування JWT-автентифікаторів відносно інших автентифікаторів не визначено і не є стабільним у різних версіях. Оскільки кожен JWT-автентифікатор повинен мати унікальний URL постачальника, в більшості випадків лише один JWT-автентифікатор спробує криптографічно перевірити токен.

Мінімальне дійсне наповнення JWT повинно містити наступні вимоги:

{
"iss": "https://issuer.example.com",
"aud": ["audience"],
"exp": 1234567890,
"": "username"
}

AuthorizationConfiguration

ПолеОпис
apiVersion
string
apiserver.k8s.io/v1alpha1
kind
string
AuthorizationConfiguration
authorizers [Обовʼязково]
[]AuthorizerConfiguration

Authorizers — це впорядкований список авторизаторів для авторизації запитів. Це схоже на прапорец --authorization-modes в kube-apiserver. Повинен бути принаймні один.

EgressSelectorConfiguration

EgressSelectorConfiguration надає версійну конфігурацію для клієнтів вибору виходу

ПолеОпис
apiVersion
string
apiserver.k8s.io/v1alpha1
kind
string
EgressSelectorConfiguration
egressSelections [Обовʼязково]
[]EgressSelection

connectionServices містить список конфігурацій клієнтів вибору виходу.

TracingConfiguration

TracingConfiguration надає версійну конфігурацію для клієнтів трасування.

ПолеОпис
apiVersion
string
apiserver.k8s.io/v1alpha1
kind
string
TracingConfiguration
TracingConfiguration [Обовʼязково]
TracingConfiguration
(Члени TracingConfiguration вбудовані в цей тип.)

Вбудувати структуру конфігурації трасування компонента.

AdmissionPluginConfiguration

Зʼявляється в:

AdmissionPluginConfiguration надає конфігурацію для одного втулка.

ПолеОпис
name [Обовʼязково]
string

Name — це імʼя контролера допуску. Воно повинно відповідати зареєстрованому імені втулка допуску.

path
string

Path — це шлях до конфігураційного файлу, що містить конфігурацію втулка.

configuration
k8s.io/apimachinery/pkg/runtime.Unknown

Configuration — це вбудований обʼєкт конфігурації, який буде використовуватися як конфігурація втулка. Якщо він присутній, він буде використовуватися замість шляху до конфігураційного файлу.

AnonymousAuthCondition

Зʼявляється в:

AnonymousAuthCondition описує стан, за якого анонімні автентифікації мають бути увімкнені.

ПолеОпис
path [Обовʼязково]
string

Шлях для якого увімкнено анонімну автентифікацію.

AnonymousAuthConfig

Зʼявляється в:

AnonymousAuthConfig надає конфігурацію для анонімного автентифікатора.

ПолеОпис
enabled [Обовʼязково]
bool
Опис не надано.
conditions [Обовʼязково]
[]AnonymousAuthCondition

Якщо встановлено, анонімна автентифікація дозволена, тільки якщо запит відповідає одній з умов.

AudienceMatchPolicyType

(Псевдонім для string)

Зʼявляється в:

AudienceMatchPolicyType є набором допустимих значень для issuer.audienceMatchPolicy

AuthorizerConfiguration

Зʼявляється в:

ПолеОпис
type [Обовʼязково]
string

Type визначає тип авторизатора. "Webhook" підтримується в загальному API-сервері. Інші API-сервери можуть підтримувати додаткові типи авторизаторів, такі як Node, RBAC, ABAC тощо.

name [Обовʼязково]
string

Name використовується для опису вебхука. Це явно використовується в механізмах моніторингу для метрик. Примітка: Імена повинні бути у форматі DNS1123, такі як myauthorizername або піддомени, такі як myauthorizer.example.domain. Обовʼязково, без стандартного значення.

webhook [Обовʼязково]
WebhookConfiguration

Webhook визначає конфігурацію для вебхук-авторизатора. Повинна бути визначена, коли Type=Webhook. Не повинна бути визначена, коли Type!=Webhook.

ClaimMappings

Зʼявляється в:

ClaimMappings надає конфігурацію для зіставлення заявок.

ПолеОпис
username [Обовʼязково]
PrefixedClaimOrExpression

username представляє опцію для атрибута імені користувача. Значення заявки повинно бути єдиним рядком. Також використовується для прапорців --oidc-username-claim і --oidc-username-prefix. Якщо встановлено username.expression, вираз повинен повертати значення рядка. Якщо username.expression використовує 'claims.email', тоді 'claims.email_verified' повинно бути використане в username.expression або extra[].valueExpression or claimValidationRules[].expression. Приклад виразу правил перевірки заявок, який відповідає перевірці, автоматично застосованій, коли username.claim встановлено в 'email', є 'claims.?email_verified.orValue(true)'.

У підході на основі прапорців, --oidc-username-claim і --oidc-username-prefix є необовʼязковими. Якщо --oidc-username-claim не встановлено, стандартне значення — "sub". Для конфігурації автентифікації немає стандартного значення для заявки або префікса. Заявка та префікс повинні бути явно встановлені. Для заявки, якщо --oidc-username-claim не був встановлений з допомогою підходу старого прапорця, налаштуйте username.claim="sub" у конфігурації автентифікації. Для префікса: (1) --oidc-username-prefix="-" не додає префікс до імені користувача. Для такої ж поведінки, використовуючи конфігурацію автентифікації, налаштуйте username.prefix="" (2) --oidc-username-prefix="" і --oidc-username-claim != "email", префікс був ""<value of --oidc-issuer-url>#". Для такої ж поведінки, використовуючи конфігурацію автентифікації, налаштуйте username.prefix="#" (3) --oidc-username-prefix="". Для такої ж поведінки, використовуючи конфігурацію автентифікації, налаштуйте username.prefix=""

groups
PrefixedClaimOrExpression

groups представляє опцію для атрибута груп. Значення заявки повинно бути рядком або масивом рядків. Якщо встановлено groups.claim, префікс повинен бути зазначений (і може бути пустим рядком). Якщо встановлено groups.expression, вираз повинен повертати рядок або масив рядків. "" (пустий рядок), [] (пустий масив) і null значення трактуються як відсутність зіставлення груп.

uid
ClaimOrExpression

uid представляє опцію для атрибута uid. Заявка повинна бути єдиним рядком. Якщо встановлено uid.expression, вираз повинен повертати рядок.

extra
[]ExtraMapping

extra представляє опцію для атрибута extra. вираз повинен повертати рядок або масив рядків. Якщо значення порожнє, відображення extra не буде присутнім.

жорстко закодоване додаткові ключ/значення

  • key: "foo" valueExpression: "'bar'" Це призведе до додаткового атрибута — foo: ["bar"]

жорстко закодований ключ копіює значення заявки

  • key: "foo" valueExpression: "claims.some_claim" Це призведе до додаткового атрибута — foo: [value of some_claim]

жорстко закодований ключ, значення, що походить від значення заявки

  • key: "admin" valueExpression: '(has(claims.is_admin) && claims.is_admin) ? "true":"' Це призведе до:
  • якщо заявка is_admin присутня і true, додатковий атрибут — admin: ["true"]
  • якщо заявка is_admin присутня і false або заявка is_admin відсутня, жоден додатковий атрибут не буде доданий

ClaimOrExpression

Зʼявляється в:

ClaimOrExpression надає конфігурацію для однієї заявки або виразу.

ПолеОпис
claim
string

claim — це заявка JWT, яку потрібно використовувати. Або claim, або expression повинно бути встановлено. Взаємно виключаються в expression.

expression
string

expression представляє вираз, який буде оцінений CEL.

Вирази CEL мають доступ до вмісту заявок токена, організованих у змінні CEL:

  • 'claims' це map назв заявок до значень заявок. Наприклад, змінну з іменем 'sub' можна отримати як 'claims.sub'. Вкладені заявки можна отримати за допомогою позначки крапки, наприклад, 'claims.foo.bar'.

Документація з CEL: https://kubernetes.io/docs/reference/using-api/cel/

Взаємно виключаються в claim.

ClaimValidationRule

Зʼявляється в:

ClaimValidationRule надає конфігурацію для однієї правила перевірки заявки.

ПолеОпис
claim
string

claim — це імʼя обовʼязкової заявки. Також використовується для прапорця --oidc-required-claim. Підтримуються тільки рядкові ключі заявок. Взаємно виключається в expression і message.

requiredValue
string

requiredValue — це значення обовʼязкової заявки. Також використовується для прапорця --oidc-required-claim. Підтримуються тільки рядкові значення заявок. Якщо claim встановлено, а requiredValue не встановлено, заявка повинна бути присутньою зі значенням, встановленим у порожній рядок. Взаємно виключається з expression і message.

expression
string

expression представляє вираз, який буде оцінений CEL. Повинно повернути boolean.

Вирази CEL мають доступ до вмісту заявок токена, організованих у змінні CEL:

  • 'claims' це map назв заявок до значень заявок. Наприклад, змінну з іменем 'sub' можна отримати як 'claims.sub'. Вкладені заявки можна отримати за допомогою позначки крапки, наприклад, 'claims.foo.bar'. Повинно повернути true для проходження перевірки.

Документація з CEL: https://kubernetes.io/docs/reference/using-api/cel/

Взаємно виключається в claim і requiredValue.

message
string

message налаштовує повернуте повідомлення про помилку, коли вираз повертає false. message є літеральним рядком. Взаємно виключається з claim і requiredValue.

Connection

Зʼявляється в:

Connection надає конфігурацію для одного клієнта egress selection.

ПолеОпис
proxyProtocol [Обовʼязково]
ProtocolType

proxyProtocol — це протокол, який використовується для підключення клієнта до сервера konnectivity.

transport
Transport

transport визначає конфігурації транспорту, які ми використовуємо для зʼєднання з сервером konnectivity. Це потрібно, якщо ProxyProtocol — HTTPConnect або GRPC.

EgressSelection

Зʼявляється в:

EgressSelection надає конфігурацію для одного клієнта egress selection.

ПолеОпис
name [Обовʼязково]
string

name — це назва egress selection. Підтримувані значення: "controlplane", "master", "etcd" та "cluster". "master" egress selector застарілий і замінений на "controlplane".

connection [Обовʼязково]
Connection

connection — це точна інформація, що використовується для налаштування egress selection.

ExtraMapping

Зʼявляється в:

ExtraMapping надає конфігурацію для одного додаткового зіставлення.

ПолеОпис
key [Обовʼязково]
string

key — це рядок, що використовується як ключ додаткового атрибуту. key повинен бути шляхом з префіксом домену (наприклад, example.org/foo). Усі символи перед першим "/" повинні бути дійсним піддоменом, як визначено у RFC 1123. Усі символи після першого "/" повинні бути дійсними символами шляху HTTP, як визначено у RFC 3986. key повинен бути у нижньому регістрі. Має бути унікальним.

valueExpression [Обовʼязково]
string

valueExpression — це вираз CEL для вилучення значення додаткового атрибуту. valueExpression повинен виробляти рядкове або масив рядкових значень. "", [], і null значення трактуються як відсутність додаткового зіставлення. Порожні рядкові значення, що містяться в масиві рядків, відфільтровуються.

Вирази CEL мають доступ до вмісту заявок токена, організованих у змінній CEL:

  • 'claims' це map назв заявок до значень заявок. Наприклад, змінну з іменем 'sub' можна отримати як 'claims.sub'. Вкладені заявки можна отримати за допомогою позначки крапки, наприклад, 'claims.foo.bar'.

Документація з CEL: https://kubernetes.io/docs/reference/using-api/cel/

Issuer

Зʼявляється в:

Issuer надає конфігурацію для конкретних налаштувань зовнішнього постачальника.

ПолеОпис
url [Обовʼязково]
string

url вказує на URL-адресу видавця у форматі https://url або https://url/path. Це повинно відповідати заявці "iss" у поданому JWT і видавцю, повернутому з виявлення. Те ж саме значення, що і прапорець --oidc-issuer-url. Інформація про виявлення отримується з "{url}/.well-known/openid-configuration", якщо не перевизначено за допомогою discoveryURL. Має бути унікальним для всіх JWT автентифікаторів. Зверніть увагу, що конфігурація вибору egress не використовується для цього мережевого зʼєднання.

discoveryURL
string

discoveryURL, якщо вказано, перевизначає URL, який використовується для отримання інформації про виявлення, замість використання "{url}/.well-known/openid-configuration". Використовується точне вказане значення, тому "/.well-known/openid-configuration" повинно бути включено в discoveryURL, якщо це потрібно.

Поле "issuer" у отриманій інформації про виявлення повинно відповідати полю "issuer.url" у AuthenticationConfiguration і буде використовуватися для перевірки заявки "iss" у поданому JWT. Це для сценаріїв, коли точки доступу well-known і jwks розміщені в іншому місці, ніж видавець (наприклад, локально в кластері).

Приклад: URL виявлення, який опублікований за допомогою сервіса kubernetes 'oidc' у просторі імен 'oidc-namespace', а інформація про виявлення доступна за адресою '/.well-known/openid-configuration'. discoveryURL: "https://oidc.oidc-namespace/.well-known/openid-configuration" certificateAuthority використовується для перевірки зʼєднання TLS, а імʼя хоста на сертифікаті повинно бути встановлено як 'oidc.oidc-namespace'.

curl https://oidc.oidc-namespace/.well-known/openid-configuration (.discoveryURL field) { issuer: "https://oidc.example.com" (.url field) }

discoveryURL повинен відрізнятися від url. Має бути унікальним для всіх JWT автентифікаторів. Зверніть увагу, що конфігурація вибору egress не використовується для цього мережевого зʼєднання.

certificateAuthority
string

certificateAuthority містить PEM-кодовані сертифікати органу сертифікації, які використовуються для перевірки зʼєднання під час отримання інформації про виявлення. Якщо не встановлено, використовується системний перевіряючий. Те ж саме значення, що і вміст файлу, на який посилається прапорець --oidc-ca-file.

audiences [Обовʼязково]
[]string

audiences — це набір прийнятних аудиторій, до яких повинен бути виданий JWT. Принаймні один з записів повинен відповідати заявці "aud" у поданих JWT. Те ж саме значення, що і прапорець --oidc-client-id (хоча це поле підтримує масив). Має бути непорожнім.

audienceMatchPolicy
AudienceMatchPolicyType

audienceMatchPolicy визначає, як поле "audiences" використовується для відповідності заявці "aud" у поданому JWT. Допустимі значення:

  1. "MatchAny" при вказанні кількох аудиторій та
  2. порожній (або не встановлений) або "MatchAny" при вказанні однієї аудиторії.
  • MatchAny: заявка "aud" у поданому JWT повинна відповідати принаймні одному з записів у полі "audiences". Наприклад, якщо "audiences" — ["foo", "bar"], заявка "aud" у поданому JWT повинна містити або "foo", або "bar" (і може містити обидва).

  • "": Політика відповідності може бути порожньою (або не встановленою) при вказанні однієї аудиторії у полі "audiences". Заявка "aud" у поданому JWT повинна містити одну аудиторію (і може містити інші).

Для більш детальної перевірки аудиторій використовуйте claimValidationRules. приклад: claimValidationRule[].expression: 'sets.equivalent(claims.aud, ["bar", "foo", "baz"])' для вимоги точної відповідності.

JWTAuthenticator

Зʼявляється в:

JWTAuthenticator надає конфігурацію для одного автентифікатора JWT.

ПолеОпис
issuer [Обовʼязково]
Issuer

issuer містить основні параметри підключення постачальника OIDC.

claimValidationRules
[]ClaimValidationRule

claimValidationRules — це правила, які застосовуються для перевірки заявок токена для автентифікації користувачів.

claimMappings [Обовʼязково]
ClaimMappings

claimMappings вказує заявки токена, які будуть розглядатися як атрибути користувача.

userValidationRules
[]UserValidationRule

userValidationRules - це правила, які застосовуються до кінцевого користувача перед завершенням автентифікації. Ці правила дозволяють застосовувати інваріанти до вхідних ідентичностей, такі як запобігання використанню префіксу system:, який зазвичай використовується компонентами Kubernetes. Правила перевірки поєднуються логічним AND і повинні всі повертати true для успішної перевірки.

PrefixedClaimOrExpression

Зʼявляється в:

PrefixedClaimOrExpression надає конфігурацію для однієї префіксованої заявки або виразу.

ПолеОпис
claim
string

claim — це заявка JWT для використання. Є взаємовиключою з expression.

prefix
string

prefix додається до значення заявки, щоб уникнути конфліктів з існуючими іменами. prefix повинен бути встановлений, якщо встановлена заявка, і може бути порожнім рядком. Взаємовиключається з expression.

expression
string

expression представляє вираз, який буде оцінюватися CEL.

CEL вирази мають доступ до вмісту заявок токена, організованого в CEL змінну:

  • 'claims' — це мапа імен заявок до їх значень. Наприклад, змінну з іменем 'sub' можна отримати як 'claims.sub'. Вкладені заявки можна отримати за допомогою нотації крапок, наприклад, 'claims.foo.bar'.

Документація з CEL: https://kubernetes.io/docs/reference/using-api/cel/

Є взаємовиключною з claim і prefix.

ProtocolType

(Аліас string)

Зʼявляється в:

ProtocolType — набір допустимих значень для Connection.ProtocolType

Transport

Зʼявляється в:

TCPTransport надає інформацію для зʼєднання з сервером konnectivity через TCP

FieldDescription
url [Обовʼязково]
string

URL — це місцезнаходження сервера konnectivity, до якого потрібно підʼєднатися. Наприклад, це може бути https://127.0.0.1:8131"

tlsConfig
TLSConfig

TLSConfig — конфігурація, необхідна для використання TLS при підключенні до сервера konnectivity

TLSConfig

Зʼявляється в:

TLSConfig надає інформацію для автентифікації для підключення до konnectivity server. Використовується тільки з TCPTransport.

ПолеОпис
caBundle
string

caBundle — це розташування файлу з CA, який буде використовуватися для встановлення довіри з konnectivity server. Повинно бути відсутнім/порожнім, якщо URL TCPTransport має префікс http://. Якщо відсутній, коли URL TCPTransport має префікс https://, стандартно використовуються системні корені довіри.

clientKey
string

clientKey — це розташування файлу з ключем клієнта, який буде використовуватися в mtls-рукостисканнях з konnectivity server. Повинно бути відсутнім/порожнім, якщо URL TCPTransport має префікс http://. Повинно бути налаштованим, якщо URL TCPTransport має префікс https://

clientCert
string

clientCert — це розташування файлу з сертифікатом клієнта, який буде використовуватися в mtls-рукостисканнях з konnectivity server. Повинно бути відсутнім/порожнім, якщо URL TCPTransport має префікс http://. Повинно бути налаштованим, якщо URL TCPTransport має префікс https://

Transport

Зʼявляється в:

Transport визначає конфігурації транспорту, які ми використовуємо для підключення до konnectivity server.

ПолеОпис
tcp
TCPTransport

TCP — це конфігурація TCP для звʼязку з konnectivity server через TCP. ProxyProtocol з GRPC наразі не підтримується з TCP транспортом. Потрібно налаштувати принаймні один з TCP або UDS.

uds
UDSTransport

UDS — це конфігурація UDS для звʼязку з konnectivity server через UDS. Потрібно налаштувати принаймні один з TCP або UDS.

UDSTransport

Зʼявляється в:

UDSTransport надає інформацію для підключення до konnectivity server через UDS.

ПолеОпис
udsName [Обовʼязкове]
string

UDSName — це назва unix domain socket для підключення до konnectivity server. Це не використовує префікс unix://. (Наприклад: /etc/srv/kubernetes/konnectivity-server/konnectivity-server.socket)

UserValidationRule

Зʼявляється в:

UserValidationRule надає конфігурацію для одного правила перевірки інформації про користувача.

ПолеОпис
expression [Обовʼязкове]
string

expression представляє вираз, який буде оцінюватися CEL. Повинен повернути true, щоб перевірка пройшла успішно.

CEL вирази мають доступ до вмісту UserInfo, організованого в CEL змінну:

Документація з CEL: https://kubernetes.io/docs/reference/using-api/cel/

message
string

message налаштовує повернуте повідомлення про помилку, коли правило повертає false. message є літеральним рядком.

WebhookConfiguration

Зʼявляється в:

ПолеОпис
authorizedTTL [Обовʼязкове]
meta/v1.Duration

Тривалість кешування відповідей "authorized" від вебхука авторизатора. Те ж саме, що й встановлення прапорця --authorization-webhook-cache-authorized-ttl Стандартно: 5m0s

unauthorizedTTL [Обовʼязкове]
meta/v1.Duration

Тривалість кешування відповідей "unauthorized" від вебхука авторизатора. Те ж саме, що й встановлення прапорця --authorization-webhook-cache-unauthorized-ttl Стандартно: 30s

timeout [Обовʼязкове]
meta/v1.Duration

Час очікування відповіді від вебхука Максимально дозволене значення — 30s. Обовʼязкове, стандартне значення відсутнє.

subjectAccessReviewVersion [Обовʼязкове]
string

Версія API authorization.k8s.io SubjectAccessReview, яку потрібно відправити та очікувати від вебхука. Те ж саме, що й встановлення прапорця --authorization-webhook-version Дійсні значення: v1beta1, v1. Обовʼязкове, стандартне значення відсутнє

matchConditionSubjectAccessReviewVersion [Обовʼязкове]
string

MatchConditionSubjectAccessReviewVersion визначає версію SubjectAccessReview, яку використовують для оцінки виразів CEL. Дійсні значення: v1. Обовʼязкове, стандартне значення відсутнє

failurePolicy [Обовʼязкове]
string

Контролює рішення про авторизацію, коли запит вебхука не вдається завершити або повертає некоректну відповідь або помилки при оцінці matchConditions. Дійсні значення:

  • NoOpinion: продовжити до наступних авторизаторів, щоб побачити, чи один з них дозволить запит
  • Deny: відхилити запит без консультації з наступними авторизаторами. Обовʼязкове, стандартне значення відсутнє.
connectionInfo [Обовʼязкове]
WebhookConnectionInfo

ConnectionInfo визначає, як ми спілкуємося з вебхуком

matchConditions [Обовʼязкове]
[]WebhookMatchCondition

matchConditions — це список умов, які мають бути виконані, щоб запит було надіслано на цей вебхук. Порожній список matchConditions відповідає всім запитам. Максимально допустимо 64 умови відповідності.

Точна логіка відповідності (в порядку):

  1. Якщо принаймні одна умова відповідності оцінюється як FALSE, то вебхук пропускається.
  2. Якщо ВСІ умови відповідності оцінюються як TRUE, то вебхук викликається.
  3. Якщо принаймні одна умова відповідності оцінюється як помилка (але жодна з них не є FALSE):
    • Якщо failurePolicy=Deny, то вебхук відхиляє запит
    • Якщо failurePolicy=NoOpinion, то помилка ігнорується, і вебхук пропускається

WebhookConnectionInfo

Зʼявляється в:

ПолеОпис
type [Обовʼязкове]
string

Контролює, як вебхук повинен спілкуватися з сервером. Дійсні значення:

  • KubeConfigFile: використовувати файл, зазначений у kubeConfigFile, щоб знайти сервер.
  • InClusterConfig: використовувати внутрішньокластерну конфігурацію для виклику SubjectAccessReview API, який розміщений kube-apiserver. Цей режим не дозволено для kube-apiserver.
kubeConfigFile [Обовʼязкове]
string

Шлях до KubeConfigFile для інформації про підключення. Обовʼязково, якщо connectionInfo.Type є KubeConfig

WebhookMatchCondition

Зʼявляється в:

ПолеОпис
expression [Обовʼязкове]
string

expression представляє вираз, який буде оцінюватися за допомогою CEL. Повинен оцінюватися як bool. CEL вирази мають доступ до вмісту SubjectAccessReview у версії v1. Якщо версія, вказана в subjectAccessReviewVersion у змінній запиту, є v1beta1, вміст буде перетворено на версію v1 перед оцінкою виразу CEL.

Документація з CEL: https://kubernetes.io/docs/reference/using-api/cel/

6.14.9 - kube-apiserver Configuration (v1beta1)

Пакет v1beta1 є версією v1beta1 API.

Типи ресурсів

TracingConfiguration

З’являється в:

TracingConfiguration надає версійні налаштування для клієнтів трасування OpenTelemetry.

ПолеОпис
endpoint
string

Точка доступу колектора, до якого цей компонент буде надсилати трасування. Зʼєднання є незахищеним і наразі не підтримує TLS. Рекомендовано не встановлювати, стандартна точка доступу для otlp grpc — localhost:4317.

samplingRatePerMillion
int32

SamplingRatePerMillion — це кількість зразків для збору на мільйон відрізків. Рекомендовано не встановлювати. Якщо не задано, семплер дотримується частоти дискретизації батьківського діапазону а якщо ні, то ніколи не робить вибірки.

AuthenticationConfiguration

AuthenticationConfiguration надає версійні налаштування для автентифікації.

ПолеОпис
apiVersion
string
apiserver.k8s.io/v1beta1
kind
string
AuthenticationConfiguration
jwt [Обовʼязково]
[]JWTAuthenticator

jwt — це список автентифікаторів для автентифікації користувачів Kubernetes за допомогою токенів, що відповідають стандартам JWT. Автентифікатор спробує розібрати необроблений ID токен, перевірити, чи підписаний він налаштованим видавцем. Публічний ключ для перевірки підпису виявляється з публічної кінцевої точки видавця за допомогою OIDC discovery. Для вхідного токена кожен JWT автентифікатор буде спробуваний у порядку, в якому він зазначений у цьому списку. Однак зверніть увагу, що інші автентифікатори можуть працювати до або після JWT автентифікаторів. Конкретне положення JWT автентифікаторів щодо інших автентифікаторів не визначено і не стабільне між випусками. Оскільки кожен JWT автентифікатор повинен мати унікальний URL видавця, максимум один JWT автентифікатор спробує криптографічно перевірити токен.

Мінімально допустимий JWT payload повинен містити наступні заявки:

{
"iss": "https://issuer.example.com",
"aud": ["audience"],
"exp": 1234567890,
"": "username"
}

anonymous [Обовʼязково]
AnonymousAuthConfig

Якщо присутній --anonymous-auth не повинен бути встановлений

AuthorizationConfiguration

ПолеОпис
apiVersion
string
apiserver.k8s.io/v1beta1
kind
string
AuthorizationConfiguration
authorizers [Обовʼязково]
[]AuthorizerConfiguration

Authorizers — це впорядкований список авторизаторів для авторизації запитів. Це схоже на прапорець — --authorization-modes kube-apiserver. Має бути принаймні один.

EgressSelectorConfiguration

EgressSelectorConfiguration надає версійні налаштування для клієнтів вибору egress.

ПолеОпис
apiVersion
string
apiserver.k8s.io/v1beta1
kind
string
EgressSelectorConfiguration
egressSelections [Обовʼязково]
[]EgressSelection

connectionServices містить список налаштувань клієнтів вибору egress.

TracingConfiguration

TracingConfiguration надає версійні налаштування для клієнтів трасування.

ПолеОпис
apiVersion
string
apiserver.k8s.io/v1beta1
kind
string
TracingConfiguration
TracingConfiguration [Обовʼязково]
TracingConfiguration
(Елементи TracingConfiguration вбудовані в цей тип.)

Вбудуйте структуру конфігурації трасування компонента.

AnonymousAuthCondition

З’являється в:

AnonymousAuthCondition описує стан, за якого анонімні автентифікації мають бути увімкнені.

ПолеОпис
path [Обовʼязково]
string

Шлях для якого увімкнено анонімну автентифікацію.

AnonymousAuthConfig

З’являється в:

AnonymousAuthConfig надає конфігурацію для анонімного автентифікатора.

ПолеОпис
enabled [Обовʼязково]
bool
Опис не надано.
conditions [Обовʼязково]
[]AnonymousAuthCondition

Якщо встановлено, анонімна автентифікація дозволена, тільки якщо запит відповідає одній з умов.

AudienceMatchPolicyType

(Аліас string)

З’являється в:

AudienceMatchPolicyType — це набір допустимих значень для issuer.audienceMatchPolicy

AuthorizerConfiguration

З’являється в:

ПолеОпис
type [Обовʼязково]
string

Тип відноситься до типу авторизатора "Webhook" підтримується у загальному API сервері Інші API сервери можуть підтримувати додаткові типи авторизаторів такі як Node, RBAC, ABAC і т.д.

name [Обовʼязково]
string

Імʼя, яке використовується для опису webhook Це явно використовується в моніторинговій машинерії для метрик Примітка: Імена повинні бути мітками DNS1123, такими як myauthorizername або піддоменами, такими як myauthorizer.example.domain Обовʼязково, стандартного значення немає

webhook [Обовʼязково]
WebhookConfiguration

Webhook визначає налаштування для Webhook авторизатора Має бути визначено, коли Type=Webhook Не повинно бути визначено, коли Type!=Webhook

ClaimMappings

З’являється в:

ClaimMappings надає налаштування для мапінгу claims.

ПолеОпис
username [Обовʼязково]
PrefixedClaimOrExpression

username представляє опцію для атрибуту username. Значення claim має бути одним рядком. Те ж саме, що й прапори --oidc-username-claim та --oidc-username-prefix. Якщо встановлено username.expression, вираз повинен видавати значення рядка. Якщо username.expression використовує 'claims.email', тоді 'claims.email_verified' повинен використовуватися в username.expression або extra[].valueExpression or claimValidationRules[].expression. Приклад виразу правила валідації claims, який відповідає валідації, що автоматично застосовується, коли username.claim встановлено на 'email', — це 'claims.?email_verified.orValue(true)'.

У підході на основі прапорів, прапорці --oidc-username-claim та --oidc-username-prefix є необовʼязковими. Якщо --oidc-username-claim не встановлено, стандартне значення — "sub". Для конфігурації автентифікації стандартне значення для claim або prefix відсутні. Claim та prefix повинні бути встановлені явно. Для claim, якщо прапорець --oidc-username-claim не було встановлено за допомогою старого підходу, налаштуйте username.claim="sub" у конфігурації автентифікації. Для prefix: (1) --oidc-username-prefix="-", префікс не додавався до імені користувача. Для такої ж поведінки за допомогою конфігурації автентифікації, встановіть username.prefix="" (2) --oidc-username-prefix="" та --oidc-username-claim != "email", префікс був "<значення --oidc-issuer-url>#". Для такої ж поведінки за допомогою конфігурації автентифікації, встановіть username.prefix="#" (3) --oidc-username-prefix="". Для такої ж поведінки за допомогою конфігурації автентифікації, встановіть username.prefix=""

groups
PrefixedClaimOrExpression

groups представляє опцію для атрибуту groups. Значення claim має бути рядком або масивом рядків. Якщо groups.claim встановлено, префікс повинен бути вказаний (і може бути порожнім рядком). Якщо groups.expression встановлено, вираз повинен видавати значення рядка або масиву рядків. "", [], і null значення розглядаються як відсутність мапінгу групи.

uid
ClaimOrExpression

uid представляє опцію для атрибуту uid. Claim повинен бути одним рядковим claim. Якщо uid.expression встановлено, вираз повинен видавати значення рядка.

extra
[]ExtraMapping

extra представляє опцію для атрибуту extra. вираз повинен видавати значення рядка або масиву рядків. Якщо значення порожнє, мапінг extra не буде присутнім.

жорстко закодований extra ключ/значення

  • key: "foo" valueExpression: "'bar'" Це призведе до появи extra атрибуту — foo: ["bar"]

жорстко закодований ключ, значення копіюється з значення claim

  • key: "foo" valueExpression: "claims.some_claim" Це призведе до появи extra атрибуту - foo: [значення some_claim]

жорстко закодований ключ, значення виводиться з значення claim

  • key: "admin" valueExpression: '(has(claims.is_admin) && claims.is_admin) ? "true":""' Це призведе до:
  • якщо claim is_admin присутній та true, extra атрибут — admin: ["true"]
  • якщо claim is_admin присутній та false або claim is_admin не присутній, extra атрибут не буде доданий

ClaimOrExpression

З’являється в:

ClaimOrExpression надає налаштування для одного claim або виразу.

ПолеОпис
claim
string

claim — це JWT claim для використання. Має бути встановлено або claim, або expression. Взаємовиключне з expression.

expression
string

expression представляє вираз, який буде оцінюватися за допомогою CEL.

CEL вирази мають доступ до вмісту claims токену, організованих у CEL змінну:

  • 'claims' — це map з назвами claims до значень claims. Наприклад, змінну з назвою 'sub' можна отримати доступом як 'claims.sub'. Вкладені claims можна отримати доступом за допомогою нотації через крапку, наприклад 'claims.foo.bar'.

Документація з CEL: https://kubernetes.io/docs/reference/using-api/cel/

Взаємовиключне з claim.

ClaimValidationRule

З’являється в:

ClaimValidationRule забезпечує конфігурацію для одного правила валідації заяви.

ПолеОпис
claim
string

claim — це імʼя необхідної заяви. Такий же, як прапорець --oidc-required-claim. Підтримуються тільки ключі заяв у форматі рядка. Взаємно виключає з expression та message.

requiredValue
string

requiredValue — це значення необхідної заяви. Такий же, як прапорець --oidc-required-claim. Підтримуються тільки значення заяв у форматі рядка. Якщо claim встановлено, а requiredValue не встановлено, заява повинна бути присутня з значенням, яке дорівнює порожньому рядку. Взаємновиключнє з expression та message.

expression
string

expression представляє вираз, який буде оцінений CEL. Повинен повернути булеве значення.

Вирази CEL мають доступ до вмісту заявок токена, організованого у змінну CEL:

  • 'claims' — це відображення імен заявок на значення заявок. Наприклад, змінна з імʼям 'sub' може бути доступна як 'claims.sub'. Вкладені заяви можна отримати, використовуючи крапкову нотацію, наприклад 'cl ims.foo.bar'. Повинен повернути true для успішної валідації.

Документація з CEL: https://kubernetes.io/docs/reference/using-api/cel/

Взаємовиключне з claim та requiredValue.

message
string

message налаштовує повідомлення про помилку, яке повертається, коли expression повертає false. message є літералним рядком. Взаємовиключне з claim та requiredValue.

Connection

З’являється в:

Connection надає конфігурацію для одного клієнта вибору egress зʼєднання.

ПолеОпис
proxyProtocol [Обовʼязково]
ProtocolType

Protocol — це протокол, який використовується для зʼєднання клієнта з konnectivity сервером.

transport
Transport

Transport визначає транспортні конфігурації, які ми використовуємо для зʼєднання з konnectivity сервером. Це обовʼязково, якщо ProxyProtocol — це HTTPConnect або GRPC.

EgressSelection

З’являється в:

EgressSelection надає конфігурацію для одного клієнта вибору egress зʼєднання.

ПолеОпис
name [Обовʼязково]
string

name — це назва вибору egress зʼєднання. На даний момент підтримуються значення "controlplane", "master", "etcd" та "cluster". Селекторо egress зʼєднання "master" застарілий і його рекомендується замінити на "controlplane".

connection [Обовʼязково]
Connection

connection — це точна інформація, яка використовується для налаштування вибору вихідного зʼєднання.

ExtraMapping

З’являється в:

ExtraMapping надає конфігурацію для одного додаткового зіставлення.

ПолеОпис
key [Обовʼязково]
string

key — це рядок, який використовується як ключ додаткового атрибуту. key повинен бути шляхом з префіксом домену (наприклад, example.org/foo). Усі символи перед першим "/" повинні бути дійсним субдоменом, як це визначено RFC 1123. Усі символи, що йдуть після першого "/", повинні бути дійсними символами шляху HTTP, як це визначено RFC 3986. key повинен бути написаний малими літерами. Має бути унікальним.

valueExpression [Обовʼязково]
string

valueExpression — це вираз CEL для отримання значення додаткового атрибуту. valueExpression повинен повертати значення рядка або масиву рядків. "", [], та null значення розглядаються як відсутність додаткового зіставлення. Порожні рядкові значення, що містяться у масиві рядків, відфільтровуються.

Вирази CEL мають доступ до вмісту токенів, організованих у змінну CEL:

  • 'claims' — це зіставлення імен вимог до значень вимог. Наприклад, змінна з імʼям 'sub' може бути доступна як 'claims.sub'. Вкладені вимоги можуть бути доступні за допомогою крапкової нотації, наприклад, 'claims.foo.bar'.

Документація з CEL: https://kubernetes.io/docs/reference/using-api/cel/

Issuer

З’являється в:

Issuer надає конфігурацію для специфічних налаштувань зовнішнього постачальника.

discoveryURL повинен відрізнятися від url. Має бути унікальним серед усіх JWT автентифікаторів. Зверніть увагу, що конфігурація вибору вихідного зʼєднання не використовується для цього мережевого зʼєднання.

ПолеОпис
url [Обовʼязково]
string

url вказує на URL видавця у форматі https://url або https://url/path. Це повинно відповідати вимозі "iss" у наданому JWT і видавцю, який повертається discovery. Таке саме значення, як і прапорець --oidc-issuer-url. Інформація про discovery отримується з "{url}/.well-known/openid-configuration", якщо discoveryURL не перевизначений. Вимагається бути унікальним серед усіх JWT автентифікаторів. Зверніть увагу, що конфігурація вибору вихідного зʼєднання не використовується для цього мережевого зʼєднання.

discoveryURL
string

discoveryURL, якщо вказано, перевизначає URL, використовуваний для отримання інформації про discovery, замість використання "{url}/.well-known/openid-configuration". Використовується точне вказане значення, тому "/.well-known/openid-configuration" повинен бути включений у discoveryURL, якщо це необхідно.

Поле "issuer" у отриманій інформації про discovery повинно відповідати полю "issuer.url" в AuthenticationConfiguration і буде використовуватися для перевірки вимоги "iss" у наданому JWT. Це призначено для сценаріїв, коли загальновідомі та точки доступу jwks розміщуються в іншому місці, ніж видавець (наприклад, локально у кластері).

Приклад: URL discovery, який експонується за допомогою сервіса kubernetes 'oidc' у просторі імен 'oidc-namespace' і інформація про discovery доступна за адресою '/.well-known/openid-configuration'. discoveryURL: "https://oidc.oidc-namespace/.well-known/openid-configuration" certificateAuthority використовується для перевірки TLS-зʼєднання, і імʼя хоста на сертифікаті повинно бути налаштовано на 'oidc.oidc-namespace'.

curl https://oidc.oidc-namespace/.well-known/openid-configuration (.discoveryURL поле) { issuer: "https://oidc.example.com" (.url поле) }

certificateAuthority
string

certificateAuthority містить сертифікати уповноважених органів, закодовані в PEM, які використовуються для перевірки зʼєднання під час отримання інформації про discovery. Якщо не встановлено, використовується системний перевіряльник. Таке саме значення, як і вміст файлу, на який посилається прапорець --oidc-ca-file.

audiences [Обовʼязково]
[]string

audiences — це набір прийнятних аудиторій, для яких повинен бути виданий JWT. Щонайменше один з записів повинен відповідати вимозі "aud" у наданих JWT. Таке саме значення, як і прапорець --oidc-client-id (хоча це поле підтримує масив). Має бути непорожнім.

audienceMatchPolicy
AudienceMatchPolicyType

audienceMatchPolicy визначає, як поле "audiences" використовується для співставлення з вимогою "aud" у наданому JWT. Допустимі значення:

  1. "MatchAny", коли вказано кілька аудиторій
  2. порожнє (або не встановлене) або "MatchAny", коли вказано одну аудиторію.
  • MatchAny: вимога "aud" у наданому JWT повинна відповідати щонайменше одному з записів у полі "audiences". Наприклад, якщо "audiences" містить ["foo", "bar"], вимога "aud" у наданому JWT повинна містити або "foo", або "bar" (і може містити обидва).

  • "": Політика співставлення може бути порожньою (або не встановленою), коли у полі "audiences" вказано одну аудиторію. Вимога "aud" у наданому JWT повинна містити одну аудиторію (і може містити інші).

Для більш точного перевірки аудиторій використовуйте claimValidationRules. Приклад: claimValidationRule[].expression: 'sets.equivalent(claims.aud, ["bar", "foo", "baz"])', щоб вимагати точного співпадіння.

JWTAuthenticator

З’являється в:

JWTAuthenticator надає конфігурацію для одного JWT автентифікатора.

ПолеОпис
issuer [Обовʼязково]
Issuer

issuer містить основні параметри підключення постачальника OIDC.

claimValidationRules
[]ClaimValidationRule

claimValidationRules — це правила, які застосовуються для перевірки вимог токенів для автентифікації користувачів.

claimMappings [Обовʼязково]
ClaimMappings

claimMappings вказує вимоги токена, які слід вважати атрибутами користувача.

userValidationRules
[]UserValidationRule

userValidationRules — це правила, які застосовуються до кінцевого користувача перед завершенням автентифікації. Ці правила дозволяють застосовувати інваріанти до вхідних ідентичностей, наприклад, забороняти використання префіксу system:, який зазвичай використовується компонентами Kubernetes. Правила перевірки логічно повʼязані оператором AND і всі повинні повернути true, щоб перевірка пройшла.

PrefixedClaimOrExpression

З’являється в:

PrefixedClaimOrExpression надає конфігурацію для одного префіксованого вимоги або виразу.

ПолеОпис
claim
string

claim — це JWT вимога для використання. Взаємовиключне з expression.

prefix
string

prefix додається до значення вимоги, щоб уникнути конфліктів з існуючими іменами. prefix необхідно встановити, якщо встановлено claim, і він може бути порожнім рядком. Взаємовиключне з expression.

expression
string

expression представляє вираз, який буде оцінюватися за допомогою CEL.

CEL вирази мають доступ до вмісту вимог токену, організованого у змінну CEL:

  • 'claims' є зіставленням імен вимог до значень вимог. Наприклад, змінну з іменем 'sub' можна отримати як 'claims.sub'. Вкладені вимоги можна отримати за допомогою нотації з крапкою, наприклад 'claims.foo.bar'.

Документація з CEL: https://kubernetes.io/docs/reference/using-api/cel/

Взаємовиключне з claim і prefix.

TCPTransport

З’являється в:

TCPTransport надає інформацію для підключення до konnectivity серверу через TCP

ПолеОпис
url [Обовʼязково]
string

URL є місцем розташування konnectivity серверу для підключення. Як приклад, це може бути "https://127.0.0.1:8131"

tlsConfig
TLSConfig

TLSConfig є конфігурацією, необхідною для використання TLS при підключенні до konnectivity серверу

TLSConfig

З’являється в:

TLSConfig надає інформацію для автентифікації для підключення до konnectivity серверу. Використовується тільки з TCPTransport

ПолеОпис
caBundle
string

caBundle — це місцезнаходження файлу CA, який буде використовуватися для визначення довіри до konnectivity серверу. Має бути відсутнім/порожнім, якщо TCPTransport.URL починається з http:// Якщо відсутній, а TCPTransport.URL починається з https://, стандартно використовуються системні корені довіри.

clientKey
string

clientKey — це місцезнаходження файлу клієнтського ключа, який буде використовуватися в mtls рукостисканнях з konnectivity сервером. Має бути відсутнім/порожнім, якщо TCPTransport.URL починається з http:// Має бути налаштований, якщо TCPTransport.URL починається з https://

clientCert
string

clientCert — це місцезнаходження файлу клієнтського сертифіката, який буде використовуватися в mtls рукостисканнях з konnectivity сервером. Має бути відсутнім/порожнім, якщо TCPTransport.URL починається з http:// Має бути налаштований, якщо TCPTransport.URL починається з https://

Transport

З’являється в:

Transport визначає конфігурації транспорту, які ми використовуємо для зʼєднання з konnectivity сервером

ПолеОпис
tcp
TCPTransport

TCP — це конфігурація TCP для звʼязку з konnectivity сервером через TCP. ProxyProtocol GRPC наразі не підтримується з TCP транспортом. Вимагає налаштування хоча б одного з TCP або UDS

uds
UDSTransport

UDS — це конфігурація UDS для звʼязку з konnectivity сервером ерез UDS. Вимагає налаштування хоча б одного з TCP або UDS

UDSTransport

З’являється в:

UDSTransport надає інформацію для підключення до konnectivity серверу через UDS

ПолеОпис
udsName [Обовʼязкове]
string

UDSName — це назва unix domain socket для підключення до konnectivity серверу. Не використовує префікс unix://. (Наприклад: /etc/srv/kubernetes/konnectivity-server/konnectivity-server.socket)

UserValidationRule

З’являється в:

UserValidationRule надає конфігурацію для одного правила валідації інформації про користувача.

ПолеОпис
expression [Обовʼязкове]
string

expression представляє вираз, який буде оцінено за допомогою CEL. Має повернути true, щоб перевірка була успішною.

CEL вирази мають доступ до вмісту UserInfo, організованого в CEL змінну:

Документація з CEL: https://kubernetes.io/docs/reference/using-api/cel/

message
string

message налаштовує повернуте повідомлення про помилку, коли правилоило повертає false. message є літеральним рядком.

WebhookConfiguration

З’являється в:

ПолеОпис
authorizedTTL [Обовʼязкове]
meta/v1.Duration

Тривалість кешування відповідей 'authorized' від webhook авторизатора. Те ж саме, що і встановлення --authorization-webhook-cache-authorized-ttl прапорця. Стандартно: 5m0s

unauthorizedTTL [Обовʼязкове]
meta/v1.Duration

Тривалість кешування відповідей 'unauthorized' від webhook авторизатора. Те ж саме, що і встановлення --authorization-webhook-cache-unauthorized-ttl прапорця. Стандартно: 30s

timeout [Обовʼязкове]
meta/v1.Duration

Тайм-аут для запиту webhook. Максимальне допустиме значення - 30s. Обовʼязкове, стандартного значення немає.

subjectAccessReviewVersion [Обовʼязкове]
string

Версія API authorization.k8s.io SubjectAccessReview, яка буде відправлена та очікувана від webhook. Те ж саме, що і встановлення --authorization-webhook-version прапорця. Допустимі значення: v1beta1, v1. Обовʼязкове, стандартного значення немає

matchConditionSubjectAccessReviewVersion [Обовʼязкове]
string

MatchConditionSubjectAccessReviewVersion визначає версію SubjectAccessReview, для якої оцінюються CEL вирази. Допустимі значення: v1. Обовʼязкове, стандартного значення немає

failurePolicy [Обовʼязкове]
string

Контролює рішення про авторизацію, коли запит webhook не вдається завершити або повертає некоректну відповідь або помилки при оцінці matchConditions. Допустимі значення:

  • NoOpinion: продовжувати до наступних авторизаторів, щоб перевірити, чи дозволяє запит хоча б один з них
  • Deny: відхилити запит без консультацій з наступними авторизаторами. Обовʼязкове, стандартного значення немає.
connectionInfo [Обовʼязкове]
WebhookConnectionInfo

ConnectionInfo визначає, як ми спілкуємося з webhook

matchConditions [Обовʼязкове]
[]WebhookMatchCondition

matchConditions — це список умов, які повинні бути виконані, щоб запит був відправлений на цей webhook. Порожній список matchConditions відповідає всім запитам. Максимум 64 умови відповідності дозволені.

Точна логіка відповідності (у порядку):

  1. Якщо хоча б одна matchCondition оцінюється як FALSE, то webhook пропускається.
  2. Якщо ВСІ matchConditions оцінюються як TRUE, то викликається webhook.
  3. Якщо хоча б одна matchCondition оцінюється як помилка (але жодна не є FALSE):
    • Якщо failurePolicy=Deny, то webhook відхиляє запит
    • Якщо failurePolicy=NoOpinion, то помилка ігнорується, і webhook пропускається

WebhookConnectionInfo

З’являється в:

ПолеОпис
type [Обовʼязкове]
string

Контролює, як webhook має спілкуватися з сервером. Допустимі значення:

  • KubeConfigFile: використовувати файл, вказаний у kubeConfigFile, для знаходження сервера.
  • InClusterConfig: використовувати конфігурацію у кластері для виклику SubjectAccessReview API, розміщеного kube-apiserver. Цей режим не дозволений для kube-apiserver.
kubeConfigFile [Обовʼязкове]
string

Шлях до KubeConfigFile для інформації про зʼєднання. Обовʼязкове, якщо connectionInfo.Type — KubeConfig

WebhookMatchCondition

З’являється в:

ПолеОпис
expression [Обовʼязкове]
string

expression представляє вираз, який буде оцінюватися CEL. Повинен оцінюватися як bool. CEL вирази мають доступ до вмісту SubjectAccessReview у версії v1. Якщо версія, вказана у змінній запиту subjectAccessReviewVersion, є v1beta1, вміст буде конвертовано у версію v1 перед оцінкою виразу CEL.

Документація з CEL: https://kubernetes.io/docs/reference/using-api/cel/

6.14.10 - kube-controller-manager Configuration (v1alpha1)

Типи ресурсів

NodeControllerConfiguration

Зʼявляється у:

NodeControllerConfiguration містить елементи, що описують NodeController.

ПолеОпис
ConcurrentNodeSyncs [Обовʼязкове]
int32

ConcurrentNodeSyncs — це кількість процесів, які одночасно синхронізують вузли

ServiceControllerConfiguration

Зʼявляється у:

ServiceControllerConfiguration містить елементи, що описують ServiceController.

ПолеОпис
ConcurrentServiceSyncs [Обовʼязкове]
int32

concurrentServiceSyncs — це кількість служб, які можуть синхронізуватися одночасно. Більше число = більш чутливе управління службами, але більше навантаження на процесор (і мережу).

CloudControllerManagerConfiguration

CloudControllerManagerConfiguration містить елементи, що описують cloud-controller manager.

ПолеОпис
apiVersion
string
cloudcontrollermanager.config.k8s.io/v1alpha1
kind
string
CloudControllerManagerConfiguration
Generic [Обовʼязкове]
GenericControllerManagerConfiguration

Generic містить конфігурацію для загального контролера-менеджера

KubeCloudShared [Обовʼязкове]
KubeCloudSharedConfiguration

KubeCloudSharedConfiguration містить конфігурацію для функцій, що використовуються як в cloud controller manager, так і в kube-controller manager.

NodeController [Обовʼязкове]
NodeControllerConfiguration

NodeController містить конфігурацію для функцій, повʼязаних з контролером вузлів.

ServiceController [Обовʼязкове]
ServiceControllerConfiguration

ServiceControllerConfiguration містить конфігурацію для функцій, повʼязаних з контролером служб.

NodeStatusUpdateFrequency [Обовʼязкове]
meta/v1.Duration

NodeStatusUpdateFrequency — це частота, з якою контролер оновлює статус вузлів

Webhook [Обовʼязкове]
WebhookConfiguration

Webhook — це конфігурація для вебхуків, розгорнутих в cloud-controller-manager

CloudProviderConfiguration

Зʼявляється у:

CloudProviderConfiguration містить елементи, що описують постачальника хмарних послуг.

ПолеОпис
Name [Обовʼязкове]
string

Name — це постачальник хмарних послуг.

CloudConfigFile [Обовʼязкове]
string

cloudConfigFile — це шлях до файлу конфігурації постачальника хмарних послуг.

KubeCloudSharedConfiguration

Зʼявляється у:

KubeCloudSharedConfiguration містить елементи, які використовуються як kube-controller manager, так і cloud-controller manager, але не genericconfig.

ПолеОпис
CloudProvider [Обовʼязкове]
CloudProviderConfiguration

CloudProviderConfiguration містить конфігурацію для функцій, повʼязаних з CloudProvider.

ExternalCloudVolumePlugin [Обовʼязкове]
string

externalCloudVolumePlugin вказує втулок, який використовувати, коли cloudProvider є "external". Наразі він використовується хмарними провайдерами з репо для керування вузлами та томами в KCM.

UseServiceAccountCredentials [Обовʼязкове]
bool

useServiceAccountCredentials вказує, чи повинні контролери працювати з окремими службовими обліковими даними.

AllowUntaggedCloud [Обовʼязкове]
bool

дозволяє запуск з непозначеними теґами хмарними екземплярами

RouteReconciliationPeriod [Обовʼязкове]
meta/v1.Duration

routeReconciliationPeriod — це період для узгодження маршрутів, створених для вузлів постачальником хмар.

NodeMonitorPeriod [Обовʼязкове]
meta/v1.Duration

nodeMonitorPeriod — це період для синхронізації NodeStatus в NodeController.

ClusterName [Обовʼязкове]
string

clusterName — це префікс екземпляра для кластеру.

ClusterCIDR [Обовʼязкове]
string

clusterCIDR — це CIDR-діапазон для Pods у кластері.

AllocateNodeCIDRs [Обовʼязкове]
bool

AllocateNodeCIDRs дозволяє виділяти CIDR для Podʼів і, якщо ConfigureCloudRoutes є true, налаштовувати їх на постачальнику хмар.

CIDRAllocatorType [Обовʼязкове]
string

CIDRAllocatorType визначає, який тип розподільника Pod CIDR буде використовуватися.

ConfigureCloudRoutes [Обовʼязкове]
bool

configureCloudRoutes дозволяє налаштовувати CIDR, виділені з allocateNodeCIDRs, на постачальнику хмар.

NodeSyncPeriod [Обовʼязкове]
meta/v1.Duration

nodeSyncPeriod — це період для синхронізації вузлів з постачальником хмар. Довші періоди зменшать кількість викликів до постачальника хмар, але можуть затримати додавання нових вузлів в кластер.

WebhookConfiguration

Зʼявляється у:

WebhookConfiguration містить конфігурацію, повʼязану з вебхуками, розгорнутими в cloud-controller-manager.

ПолеОпис
Webhooks [Обовʼязкове]
[]string

Webhooks — це список вебхуків для активації або деактивації: '*' означає "всі стандартно активовані вебхуки" 'foo' означає "активувати 'foo'" '-foo' означає "деактивувати 'foo'" перший елемент для конкретного імені виграє

LeaderMigrationConfiguration

Зʼявляється у:

ControllerLeaderConfiguration надає конфігурацію для блокування мігруючого лідера.

ПолеОпис
apiVersion
string
controllermanager.config.k8s.io/v1alpha1
kind
string
LeaderMigrationConfiguration
leaderName [Обовʼязкове]
string

LeaderName — це назва ресурсу вибору лідера, який захищає міграцію, наприклад, 1-20-KCM-to-1-21-CCM

resourceLock [Обовʼязкове]
string

ResourceLock вказує на тип обʼєкта ресурсу, який буде використовуватися для блокування. Має бути "leases" або "endpoints"

controllerLeaders [Обовʼязкове]
[]ControllerLeaderConfiguration

ControllerLeaders містить список конфігурацій блокувань лідерів, які мігрують.

ControllerLeaderConfiguration

Зʼявляється у:

ControllerLeaderConfiguration надає конфігурацію для блокування мігруючого лідера.

ПолеОпис
name [Обовʼязкове]
string

Name — це назва контролера, що мігрує, наприклад, service-controller, route-controller, cloud-node-controller тощо

component [Обовʼязкове]
string

Component — це назва компонента, в якому контролер має працювати, наприклад, kube-controller-manager, cloud-controller-manager тощо. Або '*' означає, що контролер може працювати під будь-яким компонентом, який бере участь у міграції.

GenericControllerManagerConfiguration

Зʼявляється у:

GenericControllerManagerConfiguration містить конфігурацію для загального контролер-менеджера.

ПолеОпис
Port [Обовʼязкове]
int32

port — це порт, на якому працює HTTP-сервіс контролера-менеджера.

Address [Обовʼязкове]
string

address — це IP-адреса для обслуговування (встановіть на 0.0.0.0 для всіх інтерфейсів).

MinResyncPeriod [Обовʼязкове]
meta/v1.Duration

minResyncPeriod — це період повторної синхронізації в рефлекторах; буде випадковим між minResyncPeriod і 2*minResyncPeriod.

ClientConnection [Обовʼязкове]
ClientConnectionConfiguration

ClientConnection визначає файл kubeconfig та налаштування зʼєднання клієнта для використання проксі-сервером при спілкуванні з apiserver.

ControllerStartInterval [Обовʼязкове]
meta/v1.Duration

Як довго чекати між запуском контролер-менеджерів.

LeaderElection [Обовʼязкове]
LeaderElectionConfiguration

leaderElection визначає конфігурацію клієнта вибору лідера.

Controllers [Обовʼязкове]
[]string

Controllers — це список контролерів для активації або деактивації: '*' означає "всі контролери, що стандартно активовані" 'foo' означає "активувати 'foo'" '-foo' означає "деактивувати 'foo'" перший елемент для конкретного імені виграє

Debugging [Обовʼязкове]
DebuggingConfiguration

DebuggingConfiguration містить конфігурацію для функцій, повʼязаних з відлагодженням.

LeaderMigrationEnabled [Обовʼязкове]
bool

LeaderMigrationEnabled вказує, чи має бути увімкнена міграція лідера для контролер-менеджера.

LeaderMigration [Обовʼязкове]
LeaderMigrationConfiguration

LeaderMigration містить конфігурацію для міграції лідера.

KubeControllerManagerConfiguration

KubeControllerManagerConfiguration містить елементи, що описують kube-controller manager.

ПолеОпис
apiVersion
string
kubecontrollermanager.config.k8s.io/v1alpha1
kind
string
KubeControllerManagerConfiguration
Generic [Обовʼязкове]
GenericControllerManagerConfiguration

Generic містить конфігурацію для загального контролера-менеджера

KubeCloudShared [Обовʼязкове]
KubeCloudSharedConfiguration

KubeCloudSharedConfiguration містить конфігурацію для спільних функцій як в cloud controller manager, так і в kube-controller manager.

AttachDetachController [Обовʼязкове]
AttachDetachControllerConfiguration

AttachDetachControllerConfiguration містить конфігурацію для функцій, повʼязаних з AttachDetachController.

CSRSigningController [Обовʼязкове]
CSRSigningControllerConfiguration

CSRSigningControllerConfiguration містить конфігурацію для функцій, повʼязаних з CSRSigningController.

DaemonSetController [Обовʼязкове]
DaemonSetControllerConfiguration

DaemonSetControllerConfiguration містить конфігурацію для функцій, повʼязаних з DaemonSetController.

DeploymentController [Обовʼязкове]
DeploymentControllerConfiguration

DeploymentControllerConfiguration містить конфігурацію для функцій, повʼязаних з DeploymentController.

StatefulSetController [Обовʼязкове]
StatefulSetControllerConfiguration

StatefulSetControllerConfiguration містить конфігурацію для функцій, повʼязаних з StatefulSetController.

DeprecatedController [Обовʼязкове]
DeprecatedControllerConfiguration

DeprecatedControllerConfiguration містить конфігурацію для деяких застарілих функцій.

EndpointController [Обовʼязкове]
EndpointControllerConfiguration

EndpointControllerConfiguration містить конфігурацію для функцій, повʼязаних з EndpointController.

EndpointSliceController [Обовʼязкове]
EndpointSliceControllerConfiguration

EndpointSliceControllerConfiguration містить конфігурацію для функцій, повʼязаних з EndpointSliceController.

EndpointSliceMirroringController [Обовʼязкове]
EndpointSliceMirroringControllerConfiguration

EndpointSliceMirroringControllerConfiguration містить конфігурацію для функцій, повʼязаних з EndpointSliceMirroringController.

EphemeralVolumeController [Обовʼязкове]
EphemeralVolumeControllerConfiguration

EphemeralVolumeControllerConfiguration містить конфігурацію для функцій, повʼязаних з EphemeralVolumeController.

GarbageCollectorController [Обовʼязкове]
GarbageCollectorControllerConfiguration

GarbageCollectorControllerConfiguration містить конфігурацію для функцій, повʼязаних з GarbageCollectorController.

HPAController [Обовʼязкове]
HPAControllerConfiguration

HPAControllerConfiguration містить конфігурацію для функцій, повʼязаних з HPAController.

JobController [Обовʼязкове]
JobControllerConfiguration

JobControllerConfiguration містить конфігурацію для функцій, повʼязаних з JobController.

CronJobController [Обовʼязкове]
CronJobControllerConfiguration

CronJobControllerConfiguration містить конфігурацію для функцій, повʼязаних з CronJobController.

LegacySATokenCleaner [Обовʼязкове]
LegacySATokenCleanerConfiguration

LegacySATokenCleanerConfiguration містить конфігурацію для функцій, повʼязаних з LegacySATokenCleaner.

NamespaceController [Обовʼязкове]
NamespaceControllerConfiguration

NamespaceControllerConfiguration містить конфігурацію для функцій, повʼязаних з NamespaceController.

NodeIPAMController [Обовʼязкове]
NodeIPAMControllerConfiguration

NodeIPAMControllerConfiguration містить конфігурацію для функцій, повʼязаних з NodeIPAMController.

NodeLifecycleController [Обовʼязкове]
NodeLifecycleControllerConfiguration

NodeLifecycleControllerConfiguration містить конфігурацію для функцій, повʼязаних з NodeLifecycleController.

PersistentVolumeBinderController [Обовʼязкове]
PersistentVolumeBinderControllerConfiguration

PersistentVolumeBinderControllerConfiguration містить конфігурацію для функцій, повʼязаних з PersistentVolumeBinderController.

PodGCController [Обовʼязкове]
PodGCControllerConfiguration

PodGCControllerConfiguration містить конфігурацію для функцій, повʼязаних з PodGCController.

ReplicaSetController [Обовʼязкове]
ReplicaSetControllerConfiguration

ReplicaSetControllerConfiguration містить конфігурацію для функцій, повʼязаних з ReplicaSet.

ReplicationController [Обовʼязкове]
ReplicationControllerConfiguration

ReplicationControllerConfiguration містить конфігурацію для функцій, повʼязаних з ReplicationController.

ResourceQuotaController [Обовʼязкове]
ResourceQuotaControllerConfiguration

ResourceQuotaControllerConfiguration містить конфігурацію для функцій, повʼязаних з ResourceQuotaController.

SAController [Обовʼязкове]
SAControllerConfiguration

SAControllerConfiguration містить конфігурацію для функцій, повʼязаних з ServiceAccountController.

ServiceController [Обовʼязкове]
ServiceControllerConfiguration

ServiceControllerConfiguration містить конфігурацію для функцій, повʼязаних з ServiceController.

TTLAfterFinishedController [Обовʼязкове]
TTLAfterFinishedControllerConfiguration

TTLAfterFinishedControllerConfiguration містить конфігурацію для функцій, повʼязаних з TTLAfterFinishedController.

ValidatingAdmissionPolicyStatusController [Обовʼязкове]
ValidatingAdmissionPolicyStatusControllerConfiguration

ValidatingAdmissionPolicyStatusControllerConfiguration містить конфігурацію для функцій, повʼязаних з ValidatingAdmissionPolicyStatusController.

AttachDetachControllerConfiguration

Зʼявляється в:

AttachDetachControllerConfiguration містить елементи, що описують AttachDetachController.

ПолеОпис
DisableAttachDetachReconcilerSync [Обовʼязкове]
bool

Reconciler виконує періодичний цикл для узгодження бажаного стану з фактичним станом, ініціюючи операції прикріплення/відкріплення. Цей прапорець включає або вимикає узгодження. Станадртне значення — false, отже, включено.

ReconcilerSyncLoopPeriod [Обовʼязкове]
meta/v1.Duration

ReconcilerSyncLoopPeriod — це період часу, протягом якого цикл узгодження станів чекає між наступними виконаннями. Стандартне знаячення — 60 секунд.

disableForceDetachOnTimeout [Обовʼязкове]
bool

DisableForceDetachOnTimeout вимикає примусове відкріплення, коли максимальний час розмонтування перевищено. Стандартне значення — false, отже, примусове відкріплення при відключенні увімкнено.

CSRSigningConfiguration

Зʼявляється в:

CSRSigningConfiguration містить інформацію про конкретного підписувача CSR

ПолеОпис
CertFile [Обовʼязкове]
string

certFile — це імʼя файлу, що містить PEM-кодований сертифікат X509 CA, який використовується для видачі сертифікатів

KeyFile [Обовʼязкове]
string

keyFile — це імʼя файлу, що містить PEM-кодований приватний ключ RSA або ECDSA, який використовується для видачі сертифікатів

CSRSigningControllerConfiguration

Зʼявляється в:

CSRSigningControllerConfiguration містить елементи, що описують CSRSigningController.

ПолеОпис
ClusterSigningCertFile [Обовʼязкове]
string

clusterSigningCertFile — це імʼя файлу, що містить PEM-кодований сертифікат X509 CA, використовується для видачі сертифікатів з обмеженням на кластер

ClusterSigningKeyFile [Обовʼязкове]
string

clusterSigningKeyFile — це імʼя файлу, що містить PEM-кодований приватний ключ RSA або ECDSA, який використовується для видачі сертифікатів з обмеженням на кластер

KubeletServingSignerConfiguration [Обовʼязкове]
CSRSigningConfiguration

kubeletServingSignerConfiguration містить сертифікат і ключ, які використовуються для видачі сертифікатів для kubernetes.io/kubelet-serving

KubeletClientSignerConfiguration [Обовʼязкове]
CSRSigningConfiguration

kubeletClientSignerConfiguration містить сертифікат і ключ, які використовуються для видачі сертифікатів для kubernetes.io/kube-apiserver-client-kubelet

KubeAPIServerClientSignerConfiguration [Обовʼязкове]
CSRSigningConfiguration

kubeAPIServerClientSignerConfiguration містить сертифікат і ключ, які використовуються для видачі сертифікатів для kubernetes.io/kube-apiserver-client

LegacyUnknownSignerConfiguration [Обовʼязкове]
CSRSigningConfiguration

legacyUnknownSignerConfiguration містить сертифікат і ключ, які використовуються для видачі сертифікатів для kubernetes.io/legacy-unknown

ClusterSigningDuration [Обовʼязкове]
meta/v1.Duration

clusterSigningDuration — це максимальний період дії сертифікатів, які видаються. Окремі CSR можуть запитувати коротші сертифікати, встановлюючи spec.expirationSeconds.

CronJobControllerConfiguration

Зʼявляється в:

CronJobControllerConfiguration містить елементи, що описують CronJobController.

ПолеОпис
ConcurrentCronJobSyncs [Обовʼязкове]
int32

concurrentCronJobSyncs — це кількість обʼєктів job, які дозволено синхронізувати одночасно. Більше число = більш швидка реакція job, але більше навантаження на CPU (і мережу).

DaemonSetControllerConfiguration

Зʼявляється в:

DaemonSetControllerConfiguration містить елементи, що описують DaemonSetController.

ПолеОпис
ConcurrentDaemonSetSyncs [Обовʼязкове]
int32

concurrentDaemonSetSyncs — це кількість обʼєктів daemonset, які дозволено синхронізувати одночасно. Більше число = більш швидка реакція daemonset, але більше навантаження на CPU (і мережу).

DeploymentControllerConfiguration

Зʼявляється в:

DeploymentControllerConfiguration містить елементи, що описують DeploymentController.

ПолеОпис
ConcurrentDeploymentSyncs [Обовʼязкове]
int32

concurrentDeploymentSyncs — це кількість обʼєктів deployment, які дозволено синхронізувати одночасно. Більше число = більш швидка реакція deployments, але більше навантаження на CPU (і мережу).

DeprecatedControllerConfiguration

Зʼявляється в:

DeprecatedControllerConfiguration містить елементи, що мають бути застарілими.

EndpointControllerConfiguration

Зʼявляється в:

EndpointControllerConfiguration містить елементи, що описують EndpointController

ПолеОпис
ConcurrentEndpointSyncs [Обовʼязкове]
int32

concurrentEndpointSyncs — це кількість операцій синхронізації точок доступу, які будуть виконуватись одночасно. Більше число = швидше оновлення, але більше навантаження на CPU (і мережу).

EndpointUpdatesBatchPeriod [Обовʼязкове]
meta/v1.Duration

EndpointUpdatesBatchPeriod описує тривалість періоду пакетного оновлення точок доступу. Обробка змін у pod буде затримана на цей час, щоб обʼєднати їх з потенційними майбутніми оновленнями та зменшити загальну кількість оновлень точок доступу.

EndpointSliceControllerConfiguration

Зʼявляєтсья в:

EndpointSliceControllerConfiguration містить елементи, що описують EndpointSliceController.

ПолеОпис
ConcurrentServiceEndpointSyncs [Обовʼязкове]
int32

concurrentServiceEndpointSyncs — це кількість операцій синхронізації точок доступу сервісу, які будуть виконуватись одночасно. Більше число = швидше оновлення EndpointSlice, але більше навантаження на CPU (і мережу).

MaxEndpointsPerSlice [Обовʼязкове]
int32

maxEndpointsPerSlice — максимальна кількість точок доступу, які будуть додані до одного EndpointSlice. Більше точок доступу на один slice призведе до меншої кількості та більших за розміром endpoint slices, але більших ресурсів.

EndpointUpdatesBatchPeriod [Обовʼязкове]
meta/v1.Duration

EndpointUpdatesBatchPeriod описує тривалість періоду пакетного оновлення точок доступу. Обробка змін у pod буде затримана на цей час, щоб обʼєднати їх з потенційними майбутніми оновленнями та зменшити загальну кількість оновлень точок доступу.

EndpointSliceMirroringControllerConfiguration

Зʼявляється в:

EndpointSliceMirroringControllerConfiguration містить елементи, що описують EndpointSliceMirroringController.

ПолеОпис
MirroringConcurrentServiceEndpointSyncs [Обовʼязкове]
int32

mirroringConcurrentServiceEndpointSyncs — це кількість операцій синхронізації точок доступу сервісу, які будуть виконуватись одночасно. Більше число = швидше оновлення EndpointSlice, але більше навантаження на CPU (і мережу).

MirroringMaxEndpointsPerSubset [Обовʼязкове]
int32

mirroringMaxEndpointsPerSubset — максимальна кількість точок доступу, які будуть відображені в EndpointSlice для одного EndpointSubset.

MirroringEndpointUpdatesBatchPeriod [Обовʼязкове]
meta/v1.Duration

mirroringEndpointUpdatesBatchPeriod можна використовувати для пакетного оновлення EndpointSlice. Усі оновлення, викликані змінами в EndpointSlice, будуть затримані до 'mirroringEndpointUpdatesBatchPeriod'. Якщо інші адреси в тому ж ресурсі Endpoints зміняться в цей період, вони будуть обʼєднані в одне оновлення EndpointSlice. Стандартне значення 0 означає, що кожне оновлення Endpoints викликає оновлення EndpointSlice.

EphemeralVolumeControllerConfiguration

Зʼявляєтсья в:

EphemeralVolumeControllerConfiguration містить елементи, що описують EphemeralVolumeController.

ПолеОпис
ConcurrentEphemeralVolumeSyncs [Обовʼязкове]
int32

ConcurrentEphemeralVolumeSyncs — це кількість операцій синхронізації ефемерних томів, які будуть виконуватись одночасно. Більше число = швидше оновлення ефемерних томів, але більше навантаження на CPU (і мережу).

GarbageCollectorControllerConfiguration

Зʼявляється в:

GarbageCollectorControllerConfiguration містить елементи, що описують GarbageCollectorController.

ПолеОпис
EnableGarbageCollector [Обовʼязкове]
bool

Увімкнення загального збирача сміття. ПОВИННО бути синхронізовано з відповідним прапорцем kube-apiserver. УВАГА: загальний збирач сміття є альфа-функцією.

ConcurrentGCSyncs [Обовʼязкове]
int32

ConcurrentGCSyncs — це кількість процесів збирача сміття, які дозволяється синхронізувати одночасно.

GCIgnoredResources [Обовʼязкове]
[]GroupResource

gcIgnoredResources — це список GroupResources, які збирач сміття має ігнорувати.

GroupResource

Зʼявляється в:

GroupResource описує груповий ресурс.

ПолеОпис
Group [Обовʼязкове]
string

Group — це частина групи ресурсу GroupResource.

Resource [Обовʼязкове]
string

Resource — це частина ресурсу ресурсу GroupResource.

HPAControllerConfiguration

Зʼявляється в:

HPAControllerConfiguration містить елементи, що описують HPAController.

ПолеОпис
ConcurrentHorizontalPodAutoscalerSyncs [Обовʼязкове]
int32

ConcurrentHorizontalPodAutoscalerSyncs — кількість обʼєктів HPA, які дозволено синхронізувати одночасно. Більше число = більш чутка обробка HPA, але більше навантаження на CPU (та мережу).

HorizontalPodAutoscalerSyncPeriod [Обовʼязкове]
meta/v1.Duration

HorizontalPodAutoscalerSyncPeriod — період для синхронізації кількості Podʼів в горизонтальному автомасштабувальнику Podʼів.

HorizontalPodAutoscalerDownscaleStabilizationWindow [Обовʼязкове]
meta/v1.Duration

HorizontalPodAutoscalerDownscaleStabilizationWindow — період, протягом якого автомасштабувальник буде переглядати і не зменшувати кількість Podʼів нижче будь-яких рекомендацій, зроблених протягом цього періоду.

HorizontalPodAutoscalerTolerance [Обовʼязкове]
float64

HorizontalPodAutoscalerTolerance — допуск для ситуацій, коли використання ресурсів вказує на необхідність масштабування вгору/вниз.

HorizontalPodAutoscalerCPUInitializationPeriod [Обовʼязкове]
meta/v1.Duration

HorizontalPodAutoscalerCPUInitializationPeriod — період після запуску Podʼа, коли можуть бути пропущені проби CPU.

HorizontalPodAutoscalerInitialReadinessDelay [Обовʼязкове]
meta/v1.Duration

HorizontalPodAutoscalerInitialReadinessDelay — період після запуску Podʼа, протягом якого зміни готовності вважаються як готовність, що встановлюється вперше. Єдиний ефект цього — HPA буде ігнорувати проби CPU від неготових Podʼів, у яких остання зміна готовності відбулася під час цього періоду.

JobControllerConfiguration

Зʼявляється в:

JobControllerConfiguration містить елементи, що описують JobController.

ПолеОпис
ConcurrentJobSyncs [Обовʼязкове]
int32

concurrentJobSyncs — кількість обʼєктів job, які дозволено синхронізувати одночасно. Більше число = більш чутка обробка job, але більше навантаження на CPU (та мережу).

LegacySATokenCleanerConfiguration

Зʼявляється в:

LegacySATokenCleanerConfiguration містить елементи, що описують LegacySATokenCleaner

ПолеОпис
CleanUpPeriod [Обовʼязкове]
meta/v1.Duration

CleanUpPeriod — період часу з моменту останнього використання автоматично згенерованого токена службового облікового запису перед тим, як його можна буде видалити.

NamespaceControllerConfiguration

Зʼявляється в:

NamespaceControllerConfiguration містить елементи, що описують NamespaceController.

ПолеОпис
NamespaceSyncPeriod [Обовʼязкове]
meta/v1.Duration

namespaceSyncPeriod — період для синхронізації оновлень життєвого циклу простору імен.

ConcurrentNamespaceSyncs [Обовʼязкове]
int32

concurrentNamespaceSyncs — кількість обʼєктів простору імен, які можуть синхронізуватися одночасно.

NodeIPAMControllerConfiguration

Зʼявляється в:

NodeIPAMControllerConfiguration містить елементи, що описують NodeIpamController.

ПолеОпис
ServiceCIDR [Обовʼязкове]
string

serviceCIDR — CIDR-діапазон для сервісів в кластері.

SecondaryServiceCIDR [Обовʼязкове]
string

secondaryServiceCIDR — CIDR-діапазон для сервісів в кластері, що використовується в двостекових кластерах. SecondaryServiceCIDR має бути іншої IP-сімʼї, ніж ServiceCIDR.

NodeCIDRMaskSize [Обовʼязкове]
int32

NodeCIDRMaskSize — маска розміру для CIDR вузлів в кластері.

NodeCIDRMaskSizeIPv4 [Обовʼязкове]
int32

NodeCIDRMaskSizeIPv4 — маска розміру для CIDR вузлів в двостековому кластері.

NodeCIDRMaskSizeIPv6 [Обовʼязкове]
int32

NodeCIDRMaskSizeIPv6 — маска розміру для CIDR вузлів в двостековому кластері.

NodeLifecycleControllerConfiguration

Зʼявляється в:

NodeLifecycleControllerConfiguration містить елементи, що описують NodeLifecycleController.

ПолеОпис
NodeEvictionRate [Обовʼязкове]
float32

nodeEvictionRate — кількість вузлів за секунду, на яких видаляються контейнери у разі збоїв вузла, коли зона є справною.

SecondaryNodeEvictionRate [Обовʼязкове]
float32

secondaryNodeEvictionRate — кількість вузлів за секунду, на яких видаляються контейнери у разі збоїв вузла, коли зона є несправною.

NodeStartupGracePeriod [Обовʼязкове]
meta/v1.Duration

nodeStartupGracePeriod — період часу, протягом якого дозволяється, щоб вузол не відгукувався, перш ніж позначити його як несправний.

NodeMonitorGracePeriod [Обовʼязкове]
meta/v1.Duration

nodeMonitorGracePeriod — період часу, протягом якого дозволяється вузлу не відгукуватись, перш ніж позначити його як несправний. Має бути N разів більше, ніж nodeStatusUpdateFrequency kubeletʼа, де N означає кількість спроб, дозволених для kubelet для надсилання статусу вузла.

PodEvictionTimeout [Обовʼязкове]
meta/v1.Duration

podEvictionTimeout — період для належного видалення Podʼів на неактивних вузлах.

LargeClusterSizeThreshold [Обовʼязкове]
int32

secondaryNodeEvictionRate явно перезаписується на 0 для кластерів, менших або рівних largeClusterSizeThreshold.

UnhealthyZoneThreshold [Обовʼязкове]
float32

Зона вважається несправною в nodeEvictionRate та secondaryNodeEvictionRate, коли щонайменше unhealthyZoneThreshold (не менше 3) вузлів у зоні є NotReady.

PersistentVolumeBinderControllerConfiguration

Зʼявляється в:

PersistentVolumeBinderControllerConfiguration містить елементи, що описують PersistentVolumeBinderController.

ПолеОпис
PVClaimBinderSyncPeriod [Обовʼязкове]
meta/v1.Duration

pvClaimBinderSyncPeriod — період для синхронізації постійних томів та заявок на постійні томи.

VolumeConfiguration [Обовʼязкове]
VolumeConfiguration

volumeConfiguration містить конфігурацію для функцій, повʼязаних з томами.

PersistentVolumeRecyclerConfiguration

Зʼявляється в:

PersistentVolumeRecyclerConfiguration містить елементи, що описують втулки для постійних томів.

ПолеОпис
MaximumRetry [Обовʼязкове]
int32

maximumRetry — кількість спроб, які recycler PV виконає у разі невдачі при переробці PV.

MinimumTimeoutNFS [Обовʼязкове]
int32

minimumTimeoutNFS — мінімальний ActiveDeadlineSeconds для використання для Podʼа NFS Recycler.

PodTemplateFilePathNFS [Обовʼязкове]
string

podTemplateFilePathNFS — шлях до файлу з визначенням Podʼа, що використовується як шаблон для переробки постійного тому NFS.

IncrementTimeoutNFS [Обовʼязкове]
int32

incrementTimeoutNFS — приріст часу, який додається за кожен Gi до ActiveDeadlineSeconds для Podʼа NFS scrubber.

PodTemplateFilePathHostPath [Обовʼязкове]
string

podTemplateFilePathHostPath — шлях до файлу з визначенням Podʼа, що використовується як шаблон для переробки постійного тому HostPath. Це лише для розробки та тестування і не працює в кластері з кількома вузлами.

MinimumTimeoutHostPath [Обовʼязкове]
int32

minimumTimeoutHostPath — мінімальний ActiveDeadlineSeconds для використання для Podʼа HostPath Recycler. Це лише для розробки та тестування і не працює в кластері з кількома вузлами.

IncrementTimeoutHostPath [Обовʼязкове]
int32

incrementTimeoutHostPath — приріст часу, який додається за кожен Gi до ActiveDeadlineSeconds для Podʼа HostPath scrubber. Це лише для розробки та тестування і не працює в кластері з кількома вузлами.

PodGCControllerConfiguration

Зʼявляється в:

PodGCControllerConfiguration містить елементи, що описують PodGCController.

ПолеОпис
TerminatedPodGCThreshold [Обовʼязкове]
int32

terminatedPodGCThreshold — кількість завершених Podʼів, які можуть існувати перед тим, як збирач сміття завершених почне видаляти завершені поди. Якщо <= 0, збирач сміття завершених Podʼів вимкнено.

ReplicaSetControllerConfiguration

Зʼявляється в:

ReplicaSetControllerConfiguration містить елементи, що описують ReplicaSetController.

ПолеОпис
ConcurrentRSSyncs [Обовʼязкове]
int32

concurrentRSSyncs — кількість replica set, які можуть синхронізуватися одночасно. Більше число = більш чутливе управління репліками, але більше завантаження на процесор (і мережу).

ReplicationControllerConfiguration

Зʼявляється в:

ReplicationControllerConfiguration містить елементи, що описують ReplicationController.

ПолеОпис
ConcurrentRCSyncs [Обовʼязкове]
int32

concurrentRCSyncs — кількість контролерів реплікацій, які можуть синхронізуватися одночасно. Більше число = більш чутливе управління репліками, але більше завантаження на процесор (і мережу).

ResourceQuotaControllerConfiguration

Зʼявляєтсья в:

ResourceQuotaControllerConfiguration містить елементи, що описують ResourceQuotaController.

ПолеОпис
ResourceQuotaSyncPeriod [Обовʼязкове]
meta/v1.Duration

resourceQuotaSyncPeriod — період для синхронізації статусу використання квоти в системі.

ConcurrentResourceQuotaSyncs [Обовʼязкове]
int32

concurrentResourceQuotaSyncs — кількість ресурсних квот, які можуть синхронізуватися одночасно. Більше число = більш чутливе управління квотами, але більше завантаження на процесор (і мережу).

SAControllerConfiguration

Зʼявляється в:

SAControllerConfiguration містить елементи, що описують ServiceAccountController.

ПолеОпис
ServiceAccountKeyFile [Обовʼязкове]
string

serviceAccountKeyFile — імʼя файлу, що містить PEM-кодований приватний RSA-ключ, який використовується для підписання токенів службовиї облікових записів.

ConcurrentSATokenSyncs [Обовʼязкове]
int32

concurrentSATokenSyncs — кількість операцій синхронізації токенів службових облікових записів які будуть виконуватись одночасно.

RootCAFile [Обовʼязкове]
string

rootCAFile — кореневий сертифікат центру сертифікації, який буде включено у секрет токена службових облікових записів. Це має бути дійсний PEM-кодований CA пакет.

StatefulSetControllerConfiguration

Зʼявляється в:

StatefulSetControllerConfiguration містить елементи, що описують StatefulSetController.

ПолеОпис
ConcurrentStatefulSetSyncs [Обовʼязкове]
int32

concurrentStatefulSetSyncs — кількість обʼєктів StatefulSet, які дозволено синхронізувати одночасно. Більше число = більше чутливість statefulsets, але більше навантаження на ЦП (і мережу).

TTLAfterFinishedControllerConfiguration

Зʼявляється в:

TTLAfterFinishedControllerConfiguration містить елементи, що описують TTLAfterFinishedController.

ПолеОпис
ConcurrentTTLSyncs [Обовʼязкове]
int32

concurrentTTLSyncs — кількість колекторів TTL-after-finished, які дозволено синхронізувати одночасно.

ValidatingAdmissionPolicyStatusControllerConfiguration

Зʼявляється в:

ValidatingAdmissionPolicyStatusControllerConfiguration містить елементи, що описують ValidatingAdmissionPolicyStatusController.

ПолеОпис
ConcurrentPolicySyncs [Обовʼязкове]
int32

ConcurrentPolicySyncs — кількість обʼєктів політики, які дозволено синхронізувати одночасно. Більша кількість = швидше перевірка типів, але більше навантаження на ЦП (і мережу). Стандартне значення — 5.

VolumeConfiguration

Зʼявляється в:

VolumeConfiguration містить усі перераховані прапорці, призначені для конфігурації всіх втулків томів. З цієї конфігурації бінарний файл controller-manager створить багато екземплярів volume.VolumeConfig, кожен з яких містить лише конфігурацію, необхідну для конкретного втулка, які потім передаються відповідному втулку. Бінарний файл ControllerManager є єдиною частиною коду, яка знає, які втулки підтримуються і які прапорці відповідають кожному втулку.

ПолеОпис
EnableHostPathProvisioning [Обовʼязкове]
bool

enableHostPathProvisioning дозволяє створення PV HostPath при запуску без хмарного постачальника. Це дозволяє тестування та розробку функцій provisioning. HostPath provisioning не підтримується в жодному вигляді, не працює в кластері з кількома вузлами і не слід використовувати для нічого іншого, крім тестування або розробки.

EnableDynamicProvisioning [Обовʼязкове]
bool

enableDynamicProvisioning дозволяє створення томів при запуску в середовищі, яке підтримує динамічне створення. Стандартне значення — true.

PersistentVolumeRecyclerConfiguration [Обовʼязкове]
PersistentVolumeRecyclerConfiguration

persistentVolumeRecyclerConfiguration містить конфігурацію для втулків persistent volume.

FlexVolumePluginDir [Обовʼязкове]
string

volumePluginDir — це повний шлях до теки, в якій втулок flex volume має шукати додаткові сторонні втулки томів.

6.14.11 - kube-proxy Configuration (v1alpha1)

Типи ресурсів

ClientConnectionConfiguration

Appears in:

ClientConnectionConfiguration містить деталі для створення клієнта.

ПолеОпис
kubeconfig [Обовʼязкове]
string

kubeconfig — шлях до файлу KubeConfig.

acceptContentTypes [Обовʼязкове]
string

acceptContentTypes визначає заголовок Accept, що надсилається клієнтами при підключенні до сервера, переважаючи стандартне значення 'application/json'. Це поле контролює всі підключення до сервера, що використовуються конкретним клієнтом.

contentType [Обовʼязкове]
string

contentType — це тип вмісту, що використовується при надсиланні даних на сервер з цього клієнта.

qps [Обовʼязкове]
float32

qps контролює кількість запитів на секунду, дозволених для цього зʼєднання.

burst [Обовʼязкове]
int32

burst дозволяє накопичувати додаткові запити, коли клієнт перевищує свій поріг.

DebuggingConfiguration

Appears in:

DebuggingConfiguration містить конфігурацію для функцій, повʼязаних із налагодженням.

ПолеОпис
enableProfiling [Обовʼязкове]
bool

enableProfiling дозволяє профілювання через веб-інтерфейс за адресою host:port/debug/pprof/

enableContentionProfiling [Обовʼязкове]
bool

enableContentionProfiling дозволяє профілювання блокувань, якщо enableProfiling встановлено в true.

LeaderElectionConfiguration

Appears in:

LeaderElectionConfiguration визначає конфігурацію клієнтів вибору лідера для компонентів, які можуть працювати з увімкненим вибором лідера.

ПолеОпис
leaderElect [Обовʼязкове]
bool

leaderElect дозволяє клієнту вибору лідера отримати лідерство перед виконанням основного циклу. Увімкніть це при запуску повторюваних компонентів для високої доступності.

leaseDuration [Обовʼязкове]
meta/v1.Duration

leaseDuration — це тривалість, яку не-лідери кандидати будуть чекати після спостереження за поновленням лідерства, перш ніж спробувати отримати лідерство замісць лідера, який не був поновлений. Це фактично максимальна тривалість, протягом якої лідер може бути зупинений перед заміною іншим кандидатом. Це застосовується тільки в разі увімкнення вибору лідера.

renewDeadline [Обовʼязкове]
meta/v1.Duration

renewDeadline — це інтервал між спробами діючого майстра поновити слот лідерства перед тим, як він перестане бути лідером. Це має бути менше або дорівнювати тривалості оренди. Це застосовується тільки в разі увімкнення вибору лідера.

retryPeriod [Обовʼязкове]
meta/v1.Duration

retryPeriod — це тривалість, протягом якої клієнти повинні чекати між спробами отримання і поновлення лідерства. Це застосовується тільки в разі увімкнення вибору лідера.

resourceLock [Обовʼязкове]
string

resourceLock вказує тип обʼєкта ресурсу, який буде використовуватися для блокування під час циклів вибору лідера.

resourceName [Обовʼязкове]
string

resourceName вказує імʼя обʼєкта ресурсу, який буде використовуватися для блокування під час циклів вибору лідера.

resourceNamespace [Обовʼязкове]
string

resourceNamespace вказує простір імен обʼєкта ресурсу, який буде використовуватися для блокування під час циклів вибору лідера.

KubeProxyConfiguration

KubeProxyConfiguration містить все необхідне для налаштування проксі-сервера Kubernetes.

ПолеОпис
apiVersion
string
kubeproxy.config.k8s.io/v1alpha1
kind
string
KubeProxyConfiguration
featureGates [Обовʼязкове]
map[string]bool

featureGates є зіставленням імен функцій до булевих значень, які дозволяють або забороняють альфа/експериментальні функції.

clientConnection [Обовʼязкове]
ClientConnectionConfiguration

clientConnection вказує файл kubeconfig і налаштування зʼєднання клієнта для використання проксі-сервером при спілкуванні з apiserver.

logging [Обовʼязкове]
LoggingConfiguration

logging вказує параметри ведення логу. Дивіться Logs Options для додаткової інформації.

hostnameOverride [Обовʼязкове]
string

hostnameOverride, якщо не порожній, буде використовуватися як імʼя вузла, на якому працює kube-proxy. Якщо не задано, імʼя вузла вважається таким же, як і hostname вузла.

bindAddress [Обовʼязкове]
string

bindAddress може бути використано для переозначення IP-адреси вузла, яка є основною для kube-proxy. Зверніть увагу, що імʼя є історичним артефактом, і kube-proxy насправді не привʼязує жодні сокети до цього IP.

healthzBindAddress [Обовʼязкове]
string

healthzBindAddress — це IP-адреса та порт для сервера перевірки стану, на якому він буде служити, стандартно "0.0.0.0:10256" (якщо bindAddress не встановлено або IPv4), або "[::]:10256" (якщо bindAddress є IPv6).

metricsBindAddress [Обовʼязкове]
string

metricsBindAddress — це IP-адреса та порт для сервера метрик, на якому він буде служити, стандартно "127.0.0.1:10249" (якщо bindAddress не встановлено або IPv4), або "[::1]:10249" (якщо bindAddress є IPv6). (Встановіть на "0.0.0.0:10249" / "[::]:10249", щоб привʼязатися до всіх інтерфейсів.)

bindAddressHardFail [Обовʼязкове]
bool

bindAddressHardFail, якщо true, вказує kube-proxy вважати помилку привʼязки до порту фатальною і вийти

enableProfiling [Обовʼязкове]
bool

enableProfiling дозволяє профілювання через веб-інтерфейс на обробнику /debug/pprof. Обробники профілювання будуть оброблені сервером метрик.

showHiddenMetricsForVersion [Обовʼязкове]
string

showHiddenMetricsForVersion — це версія, для якої ви хочете показати приховані метрики.

mode [Обовʼязкове]
ProxyMode

mode вказує, який режим проксі використовувати.

iptables [Обовʼязкове]
KubeProxyIPTablesConfiguration

iptables містить параметри конфігурації, що стосуються iptables.

ipvs [Обовʼязкове]
KubeProxyIPVSConfiguration

ipvs містить параметри конфігурації, що стосуються ipvs.

nftables [Обовʼязкове]
KubeProxyNFTablesConfiguration

nftables містить параметри конфігурації, що стосуються nftables.

winkernel [Обовʼязкове]
KubeProxyWinkernelConfiguration

winkernel містить параметри конфігурації, що стосуються winkernel.

detectLocalMode [Обовʼязкове]
LocalMode

detectLocalMode визначає режим, який використовується для виявлення локального трафіку, стандартно — ClusterCIDR

detectLocal [Обовʼязкове]
DetectLocalConfiguration

detectLocal містить додаткові параметри конфігурації, що стосуються DetectLocalMode.

clusterCIDR [Обовʼязкове]
string

clusterCIDR — це діапазон CIDR для Podʼів у кластері. (Для кластерів з подвійними стеками це може бути пара діапазонів CIDR, розділених комою). Коли DetectLocalMode встановлено в ClusterCIDR, kube-proxy буде вважати трафік локальним, якщо його вихідний IP знаходиться в цьому діапазоні. (Інакше не використовується.)

nodePortAddresses [Обовʼязкове]
[]string

nodePortAddresses — це список діапазонів CIDR, які містять допустимі IP-адреси вузлів, або, як варіант, єдиний рядок 'primary'. Якщо задано список CIDR, зʼєднання з сервісами NodePort будуть прийматися лише на IP-адресах вузлів в одному з вказаних діапазонів. Якщо встановлено значення 'primary', сервіси NodePort будуть прийматися лише на основну IPv4 та/або IPv6 адресу вузла згідно з обʼєктом Node. Якщо не встановлено, зʼєднання NodePort будуть прийматися на всіх локальних IP.

oomScoreAdj [Обовʼязкове]
int32

oomScoreAdj — це значення oom-score-adj для процесу kube-proxy. Значення повинні бути в межах [-1000, 1000]

conntrack [Обовʼязкове]
KubeProxyConntrackConfiguration

conntrack містить параметри конфігурації, що стосуються conntrack.

configSyncPeriod [Обовʼязкове]
meta/v1.Duration

configSyncPeriod — це інтервал часу, через який конфігурація з apiserver оновлюється. Має бути більше 0.

portRange [Обовʼязкове]
string

portRange раніше використовувався для конфігурації проксі користувача, але тепер не використовується.

windowsRunAsService [Обовʼязкове]
bool

windowsRunAsService, якщо значення true, вмикає інтеграцію API диспетчера керування сервісами Windows.

DetectLocalConfiguration

Зʼявляється у:

DetectLocalConfiguration містить необовʼязкові налаштування, що стосуються параметра DetectLocalMode

ПолеОпис
bridgeInterface [Обовʼязкове]
string

bridgeInterface — це імʼя інтерфейсу моста (bridge). Коли DetectLocalMode встановлено в LocalModeBridgeInterface, kube-proxy буде вважати трафік локальним, якщо він походить з цього моста.

interfaceNamePrefix [Обовʼязкове]
string

interfaceNamePrefix — це префікс імені інтерфейсу. Коли DetectLocalMode встановлено в LocalModeInterfaceNamePrefix, kube-proxy буде вважати трафік локальним, якщо він походить з будь-якого інтерфейсу, чиє імʼя починається з цього префіксу.

KubeProxyConntrackConfiguration

Зʼявляється у:

KubeProxyConntrackConfiguration містить налаштування conntrack для Kubernetes proxy server.

ПолеОпис
maxPerCore [Обовʼязкове]
int32

maxPerCore — максимальна кількість NAT зʼєднань, які слід відстежувати на однt процесорнt ядро (0 для того, щоб залишити обмеження без змін і проігнорувати min).

min [Обовʼязкове]
int32

min — мінімальне значення записів connect-tracking, які слід виділити, незалежно від maxPerCore (встановіть maxPerCore=0, щоб залишити обмеження без змін).

tcpEstablishedTimeout [Обовʼязкове]
meta/v1.Duration

tcpEstablishedTimeout — як довго неактивне TCP зʼєднання буде зберігатися (наприклад, '2s'). Має бути більше 0 для встановлення.

tcpCloseWaitTimeout [Обовʼязкове]
meta/v1.Duration

tcpCloseWaitTimeout — як довго неактивний запис conntrack у стані CLOSE_WAIT залишиться в таблиці conntrack (наприклад, '60s'). Має бути більше 0 для встановлення.

tcpBeLiberal [Обовʼязкове]
bool

tcpBeLiberal, якщо true, kube-proxy налаштує conntrack для роботи в ліберальному режимі для TCP зʼєднань, і пакети з послідовними номерами за межами вікна не будуть позначені як INVALID.

udpTimeout [Обовʼязкове]
meta/v1.Duration

udpTimeout — як довго неактивний запис conntrack для UDP у стані UNREPLIED залишиться в таблиці conntrack (наприклад, '30s'). Має бути більше 0 для встановлення.

udpStreamTimeout [Обовʼязкове]
meta/v1.Duration

udpStreamTimeout — як довго неактивний запис conntrack для UDP у стані ASSURED залишиться в таблиці conntrack (наприклад, '300s'). Має бути більше 0 для встановлення.

KubeProxyIPTablesConfiguration

Зʼявляється у:

KubeProxyIPTablesConfiguration містить налаштування, повʼязані з iptables, для Kubernetes proxy server.

ПолеОпис
masqueradeBit [Обовʼязкове]
int32

masqueradeBit — біт iptables fwmark простору, який слід використовувати для SNAT, якщо використовується режим iptables або ipvs. Значення повинні бути в межах [0, 31].

masqueradeAll [Обовʼязкове]
bool

masqueradeAll вказує kube-proxy виконувати SNAT для всього трафіку, надісланого на IP-адреси сервісів кластера, при використанні режиму iptables або ipvs. Це може бути необхідно для деяких плагінів CNI.

localhostNodePorts [Обовʼязкове]
bool

localhostNodePorts, якщо false, вказує kube-proxy вимкнути застарілу поведінку дозволу доступу до сервісів NodePort через localhost. (Застосовується лише для режиму iptables та IPv4; localhost NodePorts ніколи не дозволяються з іншими режимами проксі або з IPv6.)

syncPeriod [Обовʼязкове]
meta/v1.Duration

syncPeriod — інтервал (наприклад, '5s', '1m', '2h22m'), що вказує, як часто виконуються різні операції повторної синхронізації та очищення. Має бути більше 0.

minSyncPeriod [Обовʼязкове]
meta/v1.Duration

minSyncPeriod — мінімальний період між повторними синхронізаціями правил iptables (наприклад, '5s', '1m', '2h22m'). Значення 0 означає, що кожна зміна Service або EndpointSlice призведе до негайної повторної синхронізації iptables.

KubeProxyIPVSConfiguration

Зʼявляється у:

KubeProxyIPVSConfiguration містить деталі конфігурації, що стосуються IPVS для Kubernetes proxy server.

ПолеОпис
syncPeriod [Обовʼязкове]
meta/v1.Duration

syncPeriod — інтервал (наприклад, '5s', '1m', '2h22m'), що вказує, як часто виконуються різні операції повторної синхронізації та очищення. Має бути більше 0.

minSyncPeriod [Обовʼязкове]
meta/v1.Duration

minSyncPeriod — мінімальний період між повторними синхронізаціями правил IPVS (наприклад, '5s', '1m', '2h22m'). Значення 0 означає, що кожна зміна Service або EndpointSlice призведе до негайної повторної синхронізації IPVS.

scheduler [Обовʼязкове]
string

scheduler — IPVS планувальник, який слід використовувати

excludeCIDRs [Обовʼязкове]
[]string

excludeCIDRs — список CIDR, які IPVS proxier не повинен торкатися при очищенні IPVS сервісів.

strictARP [Обовʼязкове]
bool

strictARP налаштовує arp_ignore та arp_announce, щоб уникнути відповіді на ARP запити з інтерфейсу kube-ipvs0

tcpTimeout [Обовʼязкове]
meta/v1.Duration

tcpTimeout — значення тайм-ауту для неактивних IPVS TCP сесій. Стандартне значення — 0, що зберігає поточне значення тайм-ауту в системі.

tcpFinTimeout [Обовʼязкове]
meta/v1.Duration

tcpFinTimeout — значення тайм-ауту для IPVS TCP сесій після отримання FIN. Стандартне значення — 0, що зберігає поточне значення тайм-ауту в системі.

udpTimeout [Обовʼязкове]
meta/v1.Duration

udpTimeout — значення тайм-ауту для IPVS UDP пакетів. Стандартне значення — 0, що зберігає поточне значення тайм-ауту в системі.

KubeProxyNFTablesConfiguration

Зʼявляється у:

KubeProxyNFTablesConfiguration містить деталі конфігурації, що стосуються nftables для Kubernetes proxy server.

ПолеОпис
masqueradeBit [Обовʼязкове]
int32

masqueradeBit — це біт простору iptables fwmark, який слід використовувати для SNAT при використанні режиму nftables. Значення повинні бути в межах [0, 31].

masqueradeAll [Обовʼязкове]
bool

masqueradeAll вказує kube-proxy, щоб SNAT весь трафік, що надходить на IP-адреси кластерів Service, при використанні режиму nftables. Це може бути необхідним для деяких CNI втулків.

syncPeriod [Обовʼязкове]
meta/v1.Duration

syncPeriod — інтервал (наприклад, '5s', '1m', '2h22m'), що вказує, як часто виконуються різні операції повторної синхронізації та очищення. Має бути більше 0.

minSyncPeriod [Обовʼязкове]
meta/v1.Duration

minSyncPeriod — мінімальний період між повторними синхронізаціями правил iptables (наприклад, '5s', '1m', '2h22m'). Значення 0 означає, що кожна зміна Service або EndpointSlice призведе до негайної повторної синхронізації iptables.

KubeProxyWinkernelConfiguration

Зʼявляється у:

KubeProxyWinkernelConfiguration містить налаштування Windows/HNS для Kubernetes proxy server.

ПолеОпис
networkName [Обовʼязкове]
string

networkName — це імʼя мережі, яку kube-proxy використовуватиме для створення точок доступу і політик.

sourceVip [Обовʼязкове]
string

sourceVip — це IP-адреса джерела VIP точки доступу, яка використовується для NAT при балансуванні навантаження.

enableDSR [Обовʼязкове]
bool

enableDSR вказує kube-proxy, чи слід створювати HNS політики з DSR.

rootHnsEndpointName [Обовʼязкове]
string

rootHnsEndpointName — це імʼя hnsendpoint, яке прикріплене до l2bridge для кореневого простору мережі.

forwardHealthCheckVip [Обовʼязкове]
bool

forwardHealthCheckVip пересилає VIP сервісу для порту перевірки справності у Windows.

LocalMode

(Аліас для string)

Зʼявляється у:

LocalMode представляє режими для визначення локального трафіку з вузла.

ProxyMode

(Аліас для string)

Зʼявляється у:

ProxyMode представляє режими, що використовуються сервером проксі Kubernetes.

На даний момент доступні два режими проксі на платформах Linux: 'iptables' та 'ipvs'. Один режим проксі доступний на платформах Windows: 'kernelspace'.

Якщо режим проксі не вказано, буде використано найкращий доступний режим проксі (на даний момент це iptables в Linux і kernelspace у Windows). Якщо вибраний режим проксі не може бути використаний (через відсутність підтримки в ядрі, відсутність компонентів користувацького простору тощо), kube-proxy вийде з помилкою.

6.14.12 - kube-scheduler Configuration (v1)

Типи ресурсів

ClientConnectionConfiguration

Зʼявляється у:

ClientConnectionConfiguration містить деталі для створення клієнта.

ПолеОпис
kubeconfig [Обовʼязкове]
string

kubeconfig — шлях до файлу KubeConfig.

acceptContentTypes [Обовʼязкове]
string

acceptContentTypes визначає заголовок Accept, який надсилається клієнтами при підключенні до сервера, перевизначаючи стандатне значення 'application/json'. Це поле буде контролювати всі зʼєднання з сервером, що використовуються певним клієнтом.

contentType [Обовʼязкове]
string

contentType — тип вмісту, який використовується при надсиланні даних на сервер від цього клієнта.

qps [Обовʼязкове]
float32

qps контролює кількість запитів на секунду, дозволених для цього зʼєднання.

burst [Обовʼязкове]
int32

burst дозволяє накопичувати додаткові запити, коли клієнт перевищує свою норму.

DebuggingConfiguration

Зʼявляється у:

DebuggingConfiguration містить конфігурацію для функцій, що повʼязані з налагодженням.

ПолеОпис
enableProfiling [Обовʼязкове]
bool

enableProfiling увімкне профілювання через веб-інтерфейс host:port/debug/pprof/

enableContentionProfiling [Обовʼязкове]
bool

enableContentionProfiling увімкне профілювання блокувань, якщо enableProfiling увімкнено.

LeaderElectionConfiguration

Зʼявляється у:

LeaderElectionConfiguration визначає конфігурацію клієнтів вибору лідера для компонентів, які можуть працювати з увімкненим вибором лідера.

ПолеОпис
leaderElect [Обовʼязкове]
bool

leaderElect увімкне клієнта вибору лідера для отримання лідерства перед виконанням основного циклу. Увімкніть це при запуску реплікованих компонентів для високої доступності.

leaseDuration [Обовʼязкове]
meta/v1.Duration

leaseDuration — це період часу, протягом якого кандидати, які не є лідерами, чекатимуть після поновлення лідерства, перш ніж спробувати зайняти лідерство в лідерському слоті, який вже зайнятий, але не поновлений. Це фактично максимальний термін, на який лідер може бути зупинений, перш ніж його замінить інший кандидат. Це може бути застосовано лише у випадку, якщо вибори лідера увімкнено.

renewDeadline [Обовʼязкове]
meta/v1.Duration

renewDeadline — це інтервал між спробами діючого лідера оновити слот лідерства перед тим, як він припинить лідирування. Це має бути менше або дорівнювати тривалості оренди. Це застосовно тільки тоді, коли вибір лідера увімкнено.

retryPeriod [Обовʼязкове]
meta/v1.Duration

retryPeriod — це тривалість, яку клієнти повинні чекати між спробами отримання та оновлення лідерства. Це застосовно тільки тоді, коли вибір лідера увімкнено.

resourceLock [Обовʼязкове]
string

resourceLock вказує тип обʼєкта ресурсу, який буде використовуватися для блокування під час циклів вибору лідера.

resourceName [Обовʼязкове]
string

resourceName вказує на імʼя обʼєкта ресурсу, який буде використовуватися для блокування під час циклів вибору лідера.

resourceNamespace [Обовʼязкове]
string

resourceNamespace вказує на простір імен обʼєкта ресурсу, який буде використовуватися для блокування під час циклів вибору лідера.

DefaultPreemptionArgs

DefaultPreemptionArgs містить аргументи, які використовуються для налаштування втулка DefaultPreemption.

ПолеОпис
apiVersion
string
kubescheduler.config.k8s.io/v1
kind
string
DefaultPreemptionArgs
minCandidateNodesPercentage [Обовʼязкове]
int32

MinCandidateNodesPercentage — це мінімальна кількість кандидатів для відбору при тестуванні виселення як відсоток від кількості вузлів. Має бути в межах [0, 100]. Стандартно дорівнює 10% від розміру кластера, якщо не вказано.

minCandidateNodesAbsolute [Обовʼязкове]
int32

MinCandidateNodesAbsolute — це абсолютна мінімальна кількість кандидатів для відбору. Ймовірна кількість кандидатів, які будуть перераховані для тестування виселення, розраховується за формулою:

numCandidates = max(numNodes * minCandidateNodesPercentage, minCandidateNodesAbsolute).

Ми говоримо "ймовірна", оскільки є й інші фактори, такі як порушення PDB, які впливають на кількість кандидатів для відбору. Має бути не менше 0 вузлів. Стандартно дорівнює 100 вузлам, якщо не вказано.

InterPodAffinityArgs

InterPodAffinityArgs містить аргументи, які використовуються для налаштування втулка InterPodAffinity.

ПолеОпис
apiVersion
string
kubescheduler.config.k8s.io/v1
kind
string
InterPodAffinityArgs
hardPodAffinityWeight [Обовʼязкове]
int32

HardPodAffinityWeight — це вага оцінки для наявних Podʼів з відповідною жорсткою спорідненністю до вхідного Podʼа.

ignorePreferredTermsOfExistingPods [Обовʼязкове]
bool

IgnorePreferredTermsOfExistingPods налаштовує планувальник ігнорувати бажані правила спорідненості наявних Podʼів при оцінці кандидатів вузлів, якщо вхідний Pod не має спорідненості між Podʼами.

KubeSchedulerConfiguration

KubeSchedulerConfiguration налаштовує планувальник

ПолеОпис
apiVersion
string
kubescheduler.config.k8s.io/v1
kind
string
KubeSchedulerConfiguration
parallelism [Обовʼязкове]
int32

Parallelism визначає кількість паралелізму в алгоритмах для планування Podʼів. Має бути більше 0. Стандартно — 16

leaderElection [Обовʼязкове]
LeaderElectionConfiguration

LeaderElection визначає конфігурацію клієнта виборів лідера.

clientConnection [Обовʼязкове]
ClientConnectionConfiguration

ClientConnection визначає файл kubeconfig і налаштування підключення клієнта для використання проксі-сервером при спілкуванні з apiserver.

DebuggingConfiguration [Обовʼязкове]
DebuggingConfiguration
(Члени DebuggingConfiguration вбудовані в цей тип.)

DebuggingConfiguration містить налаштування для функцій, повʼязаних із налагодженням. TODO: Ми можемо зробити це підструктурою як налагодження componentbaseconfigv1alpha1.DebuggingConfiguration

percentageOfNodesToScore [Обовʼязкове]
int32

PercentageOfNodesToScore — це відсоток усіх вузлів, які, як тільки будуть визнані придатними для запуску Podʼа, планувальник припиняє пошук інших придатних вузлів у кластері. Це допомагає покращити продуктивність планувальника. Планувальник завжди намагається знайти принаймні "minFeasibleNodesToFind" придатних вузлів незалежно від значення цього прапорця. Приклад: якщо розмір кластера 500 вузлів і значення цього прапорця 30, то планувальник припиняє пошук далі придатних вузлів, як тільки знайде 150 придатних. Коли значення дорівнює 0, стандартно буде оцінено відсоток вузлів (5%—50% залежно від розміру кластера). Він перекривається рівнем профілю PercentageOfNodesToScore.

podInitialBackoffSeconds [Обовʼязкове]
int64

PodInitialBackoffSeconds — це початкова фора для непридатних для планування Podʼів. Якщо вказано, він повинен бути більше 0. Якщо це значення нульове, буде використано стандартне значення (1s).

podMaxBackoffSeconds [Обовʼязкове]
int64

PodMaxBackoffSeconds — це максимальна фора для непридатних для планування Podʼів. Якщо вказано, він повинен бути більше podInitialBackoffSeconds. Якщо це значення нульове, буде використано стандартне значення (10s).

profiles [Обовʼязкове]
[]KubeSchedulerProfile

Profiles — це профілі планування, які підтримує kube-scheduler. Podʼи можуть вибрати, щоб їх планували за певним профілем, встановивши відповідну назву планувальника. Podʼи, які не вказують жодної назви планувальника, плануються за допомогою профілю "default-scheduler", якщо він присутній тут.

extenders [Обовʼязкове]
[]Extender

Extenders — це список розширень планувальника, кожне з яких містить значення, як спілкуватися з розширенням. Ці розширення використовуються всіма профілями планувальника.

delayCacheUntilActive [Обовʼязкове]
bool

DelayCacheUntilActive визначає, коли починати кешування. Якщо це true і вибори лідера увімкнені, планувальник чекатиме, щоб заповнити кеші інформаторів, поки не стане лідером. Це призведе до повільнішого перемикання з резервного на основний вузол із перевагою нижчого використання пам’яті під час очікування стати лідером. Стандартно — false.

NodeAffinityArgs

NodeAffinityArgs містить аргументи для налаштування втулка NodeAffinity.

ПолеОпис
apiVersion
string
kubescheduler.config.k8s.io/v1
kind
string
NodeAffinityArgs
addedAffinity
core/v1.NodeAffinity

AddedAffinity застосовується до всіх Podʼів додатково до NodeAffinity, вказаного в PodSpec. Тобто вузли повинні відповідати AddedAffinity І .spec.NodeAffinity. AddedAffinity є станадртно порожнім (є збіг зі всіма вузлами). Коли використовується AddedAffinity, деякі Podʼи з вимогами щодо спорідненості, які збігаються з конкретним вузлом (наприклад, Podʼи Daemonset), можуть залишатися непридатними для планування.

NodeResourcesBalancedAllocationArgs

NodeResourcesBalancedAllocationArgs містить аргументи для налаштування втулка NodeResourcesBalancedAllocation.

ПолеОпис
apiVersion
string
kubescheduler.config.k8s.io/v1
kind
string
NodeResourcesBalancedAllocationArgs
resources [Обовʼязково]
[]ResourceSpec

Ресурси, якими потрібно керувати, стандартно: "cpu" та "memory", якщо не вказано інше.

NodeResourcesFitArgs

NodeResourcesFitArgs містить аргументи для налаштування втулка NodeResourcesFit.

ПолеОпис
apiVersion
string
kubescheduler.config.k8s.io/v1
kind
string
NodeResourcesFitArgs
ignoredResources [Обовʼязково]
[]string

IgnoredResources — список ресурсів, які фільтр NodeResources повинен ігнорувати. Це не застосовується до оцінювання.

ignoredResourceGroups [Обовʼязково]
[]string

IgnoredResourceGroups визначає список груп ресурсів, які фільтр NodeResources повинен ігнорувати. наприклад, якщо група - ["example.com"], вона ігноруватиме всі імена ресурсів, які починаються з "example.com", такі як "example.com/aaa" і "example.com/bbb". Імʼя групи ресурсів не може містити '/'. Це не застосовується до оцінювання.

scoringStrategy [Обовʼязково]
ScoringStrategy

ScoringStrategy вибирає стратегію оцінювання ресурсів вузлів. Стандартно використовується стратегія LeastAllocated з рівною вагою "cpu" та "memory".

PodTopologySpreadArgs

PodTopologySpreadArgs містить аргументи для налаштування втулка PodTopologySpread.

ПолеОпис
apiVersion
string
kubescheduler.config.k8s.io/v1
kind
string
PodTopologySpreadArgs
defaultConstraints
[]core/v1.TopologySpreadConstraint

DefaultConstraints визначає обмеження на розподіл топології, які будуть застосовані до Podʼів, що не мають визначених обмежень у pod.spec.topologySpreadConstraints. .defaultConstraints[*].labelSelectors повинні бути порожніми, оскільки вони виводяться з приналежності Podʼа до Services, ReplicationControllers, ReplicaSets або StatefulSets. Якщо не порожньо, .defaultingType має бути "List".

defaultingType
PodTopologySpreadConstraintsDefaulting

DefaultingType визначає, як виводяться .defaultConstraints. Може бути одним з "System" або "List".

  • "System": Використовувати визначені kubernetes обмеження, які розподіляють Podʼи серед вузлів і зон.
  • "List": Використовувати обмеження, визначені в .defaultConstraints.

Стандартно "System".

VolumeBindingArgs

VolumeBindingArgs містить аргументи для налаштування втулка VolumeBinding.

ПолеОпис
apiVersion
string
kubescheduler.config.k8s.io/v1
kind
string
VolumeBindingArgs
bindTimeoutSeconds [Обовʼязкове]
int64

BindTimeoutSeconds — це тайм-аут в секундах у операції привʼязки томів. Значення повинно бути невідʼємним цілим числом. Значення нуль означає, що немає очікування. Якщо це значення не вказано, буде використано стандартне значення (600).

shape
[]UtilizationShapePoint

Shape вказує точки, що визначають форму функції оцінки, яка використовується для оцінки вузлів на основі використання статично наданих PV. Використання розраховується шляхом поділу загального запитаного обсягу сховища Podʼа на загальну ємність доступних PV на кожному вузлі. Кожна точка містить використання (у діапазоні від 0 до 100) та відповідну оцінку (у діапазоні від 0 до 10). Ви можете налаштувати пріоритет, вказуючи різні оцінки для різних рівнів використання. Стандартні точки Shape:

  1. 0 для 0 використання
  2. 10 для 100 використання. Всі точки повинні бути відсортовані у зростаючому порядку за використанням.

Extender

Зʼявляється в:

Extender містить параметри, що використовуються для звʼязку з розширювачем. Якщо дієслово не вказано/пусте, вважається, що розширювач вирішів не надавати це розширення.

ПолеОпис
urlPrefix [Обовʼязкове]
string

URLPrefix за яким доступний розширювач

filterVerb [Обовʼязкове]
string

Дієслово для виклику фільтрації, порожнє, якщо не підтримується. Це дієслово додається до URLPrefix при виконанні виклику фільтрації розширювача.

preemptVerb [Обовʼязкове]
string

Дієслово для виклику витіснення, порожнє, якщо не підтримується. Це дієслово додається до URLPrefix при виконанні виклику витіснення розширювача.

prioritizeVerb [Обовʼязкове]
string

Дієслово для виклику пріоритезації, порожнє, якщо не підтримується. Це дієслово додається до URLPrefix при виконанні виклику пріоритезації розширювача.

weight [Обовʼязкове]
int64

Числовий множник для оцінок вузлів, які генерує виклик пріоритезації. Вага повинна бути додатним цілим числом

bindVerb [Обовʼязкове]
string

Дієслово для виклику привʼязки, порожнє, якщо не підтримується. Це дієслово додається до URLPrefix при виконанні виклику привʼязки розширювача. Якщо цей метод реалізовано розширювачем, це відповідальність розширювача привʼязати Pod до apiserver. Тільки один розширювач може реалізовувати цю функцію.

enableHTTPS [Обовʼязкове]
bool

EnableHTTPS вказує, чи слід використовувати https для звʼязку з розширювачем

tlsConfig [Обовʼязкове]
ExtenderTLSConfig

TLSConfig вказує налаштування транспортного рівня безпеки

httpTimeout [Обовʼязкове]
meta/v1.Duration

HTTPTimeout вказує тривалість тайм-ауту для виклику розширювача. Тайм-аут фільтрації призводить до невдалої спроби планування Podʼа. Тайм-аут пріоритезації ігнорується, пріоритети k8s/інших розширювачів використовуються для вибору вузла.

nodeCacheCapable [Обовʼязкове]
bool

NodeCacheCapable вказує, що розширювач здатний кешувати інформацію про вузли, отже, планувальник повинен надсилати лише мінімальну інформацію про придатні вузли, припускаючи, що розширювач вже кешував повні дані про всі вузли в кластері

managedResources
[]ExtenderManagedResource

ManagedResources — це список розширених ресурсів, що керуються цим розширювачем.

  • Pod буде надіслано до розширювача на етапах фільтрації, пріоритезації та привʼязки (якщо розширювач є звʼязувальним) тільки якщо Pod запитує принаймні один з розширених ресурсів у цьому списку. Якщо список порожній або не вказаний, всі Podʼи будуть надіслані до цього розширювача.
  • Якщо IgnoredByScheduler встановлено в true для ресурсу, kube-scheduler буде пропускати перевірку ресурсу в предикатах.
ignorable [Обовʼязкове]
bool

Ignorable вказує, чи можна ігнорувати розширювач, тобто планування не повинно не вдасться, якщо розширювач повертає помилку або недоступний.

ExtenderManagedResource

Зʼявляється в:

ExtenderManagedResource описує аргументи розширених ресурсів, якими керує розширювач.

ПолеОпис
name [Обовʼязкове]
string

Назва розширеного ресурсу.

ignoredByScheduler [Обовʼязкове]
bool

IgnoredByScheduler вказує, чи слід kube-scheduler ігнорувати цей ресурс при застосуванні предикатів.

ExtenderTLSConfig

Зʼявляється в:

ExtenderTLSConfig містить налаштування для увімкнення TLS з розширювачем

ПолеОпис
insecure [Обовʼязкове]
bool

Сервер повинен бути доступний без перевірки сертифікату TLS. Тільки для тестування.

serverName [Обовʼязкове]
string

ServerName передається серверу для SNI та використовується в клієнті для перевірки сертифікатів сервера. Якщо ServerName порожній, використовується імʼя хоста, яке використовується для звʼязку з сервером.

certFile [Обовʼязкове]
string

Сервер вимагає автентифікацію клієнтського сертифікату TLS

keyFile [Обовʼязкове]
string

Сервер вимагає автентифікацію клієнтського сертифікату TLS

caFile [Обовʼязкове]
string

Довірені кореневі сертифікати для сервера

certData [Обовʼязкове]
[]byte

CertData містить PEM-кодовані байти (зазвичай зчитуються з файлу клієнтського сертифіката). CertData має пріоритет над CertFile

keyData [Обовʼязкове]
[]byte

KeyData містить PEM-кодовані байти (зазвичай зчитуються з файлу ключа клієнтського сертифіката). KeyData має пріоритет над KeyFile

caData [Обовʼязкове]
[]byte

CAData містить PEM-кодовані байти (зазвичай зчитуються з файлу з кореневими сертифікатами). CAData має пріоритет над CAFile

KubeSchedulerProfile

Зʼявляється в:

KubeSchedulerProfile є профілем планувальника.

ПолеОпис
schedulerName [Обовʼязкове]
string

SchedulerName є імʼям планувальника, асоційованого з цим профілем. Якщо SchedulerName відповідає значенню "spec.schedulerName" Podʼа, то Pod буде плануватися з цим профілем.

percentageOfNodesToScore [Обовʼязкове]
int32

PercentageOfNodesToScore є відсотком усіх вузлів, після знаходження яких, планувальник припиняє пошук більш придатних вузлів у кластері для запуску Podʼа. Це допомагає покращити продуктивність планувальника. Планувальник завжди намагається знайти принаймні "minFeasibleNodesToFind" придатних вузлів незалежно від значення цього прапорця. Наприклад, якщо розмір кластера становить 500 вузлів і значення цього прапорця становить 30, то планувальник припиняє пошук далі, як тільки знаходить 150 придатних вузлів. Коли значення 0, стандартно буде оцінено відсоток (5%–50% в залежності від розміру кластера) вузлів. Це матиме перевагу перед глобальним PercentageOfNodesToScore. Якщо це пусто, буде використано глобальний PercentageOfNodesToScore.

plugins [Обовʼязкове]
Plugins

Plugins визначають набір втулків, які мають бути увімкнені або вимкнені. Увімкнені втулки — це ті, які мають бути увімкнені додатково до стандартних втулків. Вимкнені втулки — це будь-які зі стандартних втулків, які мають бути вимкнені. Коли жоден увімкнений або вимкнений втулок не зазначений для точки розширення, будуть використані стандартні втулки для цієї точки розширення, якщо такі є. Якщо зазначено втулок QueueSort, то той самий втулок QueueSort та PluginConfig повинні бути зазначені для всіх профілів.

pluginConfig [Обовʼязкове]
[]PluginConfig

PluginConfig є необовʼязковим набором параметрів для кожного втулка. Виключення конфігураційних аргументів для втулка є еквівалентним використанню стандартної конфігурації для цього втулка.

Plugin

Зʼявляється в:

Plugin визначає імʼя втулка та його вагу, якщо це застосовується. Вага використовується лише для втулків типу Score.

ПолеОпис
name [Обовʼязкове]
string

Name визначає імʼя втулка

weight [Обовʼязкове]
int32

Weight визначає вагу втулка, використовується лише для втулків типу Score.

PluginConfig

Зʼявляється в:

PluginConfig визначає аргументи, які повинні бути передані втулку під час ініціалізації. Втулок, який викликається на кількох точках розширення, ініціалізується один раз. Args можуть мати довільну структуру. Обробка цих аргументів залежить від самого втулка.

ПолеОпис
name [Обовʼязкове]
string

Name визначає імʼя втулка, що конфігурується

args [Обовʼязкове]
k8s.io/apimachinery/pkg/runtime.RawExtension

Args визначає аргументи, що передаються втулкам під час ініціалізації. Args можуть мати довільну структуру.

PluginSet

Зʼявляється в:

PluginSet визначає включені та виключені втулки для точки розширення. Якщо масив порожній, відсутній або nil, використовуватимуться стандартні втулки для цієї точки розширення.

ПолеОпис
enabled [Обовʼязкове]
[]Plugin

Enabled визначає втулки, які повинні бути активовані додатково до стандартних втулків. Якщо стандартний втулок також конфігуровано у файлі конфігурації планувальника, вага втулка буде перезаписана відповідно. Ці втулки викликаються після стандартних втулків і в тому ж порядку, як зазначено тут.

disabled [Обовʼязкове]
[]Plugin

Disabled визначає стандартні втулки, які повинні бути вимкнені. Коли всі стандартні втулки потрібно вимкнути, слід надати масив, що містить лише один символ "*".

Plugins

Зʼявляється в:

Plugins включає кілька точок розширення. Коли вони вказані, список втулків для конкретної точки розширення є єдиними активованими втулками. Якщо точка розширення пропущена з конфігурації, тоді використовуються стандартні втулки для цієї точки розширення. Активовані втулки викликаються в порядку, зазначеному тут, після стандартних втулків. Якщо їх потрібно викликати перед стандартними втулками, стандартні втулки повинні бути вимкнені і знову увімкнені тут у бажаному порядку.

ПолеОпис
preEnqueue [Обовʼязкове]
PluginSet

PreEnqueue ` це список втулків, які повинні бути викликані перед додаванням Podʼів у чергу планування.

queueSort [Обовʼязкове]
PluginSet

QueueSort — це список втулків, які повинні бути викликані під час сортування Podʼів у черзі планування.

preFilter [Обовʼязкове]
PluginSet

PreFilter — це список втулків, які повинні бути викликані на точці розширення "PreFilter" фреймворку планування.

filter [Обовʼязкове]
PluginSet

Filter — це список втулків, які повинні бути викликані при фільтрації вузлів, що не можуть запустити Pod.

postFilter [Обовʼязкове]
PluginSet

PostFilter — це список втулків, які викликаються після фази фільтрації, але лише коли для Podʼа не були знайдені підходящі вузли.

preScore [Обовʼязкове]
PluginSet

PreScore — це список втулків, які викликаються перед оцінюванням.

score [Обовʼязкове]
PluginSet

Score — це список втулків, які повинні бути викликані при ранжуванні вузлів, які пройшли фазу фільтрації.

reserve [Обовʼязкове]
PluginSet

Reserve — це список втулків, які викликаються при резервуванні/анулюванні резервування ресурсів після того, як вузол призначений для запуску Podʼа.

permit [Обовʼязкове]
PluginSet

Permit — це список втулків, які контролюють привʼязування Podʼа. Ці втулки можуть запобігти або затримати привʼязування Podʼа.

preBind [Обовʼязкове]
PluginSet

PreBind — це список втулків, які повинні бути викликані перед привʼязуванням Podʼа.

bind [Обовʼязкове]
PluginSet

Bind — це список втулків, які повинні бути викликані на точці розширення "Bind" фреймворку планування. Планувальник викликає ці втулки по порядку. Планувальник пропускає решту цих втулків, як тільки один з них повертає успіх.

postBind [Обовʼязкове]
PluginSet

PostBind — це список втулків, які повинні бути викликані після успішного привʼязування Podʼа.

multiPoint [Обовʼязкове]
PluginSet

MultiPoint — це спрощений розділ конфігурації для активації втулків для всіх дійсних точок розширення. Втулки, активовані через MultiPoint, автоматично реєструються для кожної індивідуальної точки розширення, яку втулок реалізував. Вимкнення втулка через MultiPoint вимикає таку поведінку. Те ж саме стосується вимкнення "*" через MultiPoint (жоден стандартний втулок не буде автоматично зареєстрований). Втулки все ще можна вимкнути через їх окремі точки розширення.

Що стосується пріоритету, конфігурація втулків дотримується цієї основної ієрархії

  1. Специфічні точки розширення
  2. Явно сконфігуровані втулки MultiPoint
  3. Набір стандартних втулків, як втулки MultiPoint. Це означає, що втулок з вищим пріоритетом буде виконуватися першим і перезаписувати будь-які налаштування всередині MultiPoint. Явно сконфігуровані втулки користувача також мають вищий пріоритет над стандартними втулками. В межах цієї ієрархії, параметр Enabled має вищий пріоритет над Disabled. Наприклад, якщо втулок зазначено як в multiPoint.Enabled та multiPoint.Disabled, втулок буде активовано. Подібним чином, включення multiPoint.Disabled = '*' і multiPoint.Enabled = pluginA все ще зареєструє цей конкретний втулок через MultiPoint. Це слідує тій же поведінці, що й у всіх інших конфігураціях точок розширення.

PodTopologySpreadConstraintsDefaulting

(Аліас для string)

Зʼявляється в:

PodTopologySpreadConstraintsDefaulting визначає, як встановлювати стандартне значення для втулка PodTopologySpread.

RequestedToCapacityRatioParam

Зʼявляється в:

RequestedToCapacityRatioParam визначає параметри RequestedToCapacityRatio.

ПолеОпис
shape [Обовʼязково]
[]UtilizationShapePoint

Shape є списком точок, що визначають форму функції оцінки.

ResourceSpec

Зʼявляється в:

ResourceSpec представляє один ресурс.

ПолеОпис
name [Обовʼязково]
string

Назва ресурсу.

weight [Обовʼязково]
int64

Вага ресурсу.

ScoringStrategy

Зʼявляється в:

ScoringStrategy визначає ScoringStrategyType для втулка ресурсів вузла.

ПолеОпис
type [Обовʼязково]
ScoringStrategyType

Тип обирає стратегію для виконання.

resources [Обовʼязково]
[]ResourceSpec

Ресурси, які слід враховувати при оцінюванні. Стандартний набір ресурсів включає "cpu" та "memory" з однаковою вагою. Дозволені ваги від 1 до 100. Стандартна вага дорівнює 1, якщо не вказана або явно встановлена в 0.

requestedToCapacityRatio [Обовʼязково]
RequestedToCapacityRatioParam

Аргументи, специфічні для стратегії RequestedToCapacityRatio.

ScoringStrategyType

(Аліас string)

Зʼявляється в:

ScoringStrategyType визначає тип стратегії оцінювання, яка використовується у втулку NodeResourcesFit.

UtilizationShapePoint

Зʼявляється в:

UtilizationShapePoint представляє окрему точку функції пріоритету.

ПолеОпис
utilization [Обовʼязково]
int32

Utilization (вісь x). Дійсні значення від 0 до 100. Повністю використаний вузол відповідає 100.

score [Обовʼязково]
int32

Оцінка, присвоєна даній утилізації (вісь y). Дійсні значення від 0 до 10.

6.14.13 - kubeadm Configuration (v1beta3)

Огляд

Пакунок v1beta3 визначає версію v1beta3 формату конфігураційного файлу kubeadm. Ця версія покращує формат v1beta2, виправляючи деякі незначні проблеми і додаючи кілька нових полів.

Список змін з версії v1beta2:

  • Видалено застаріле поле "ClusterConfiguration.useHyperKubeImage". Kubeadm більше не підтримує образ hyperkube.
  • Поле "ClusterConfiguration.dns.type" було видалено, оскільки CoreDNS є єдиним типом DNS-сервера, який підтримується kubeadm.
  • Додано теги "datapolicy" до полів, які містять секрети. Це призведе до того, що значення полів буде пропущено, коли структури API буде надруковано за допомогою klog.
  • Додано "InitConfiguration.skipPhases", "JoinConfiguration.SkipPhases", щоб дозволити пропустити список фаз під час виконання команд kubeadm init/join.
  • Додано "InitConfiguration.nodeRegistration.imagePullPolicy" та "JoinConfiguration.nodeRegistration.imagePullPolicy", щоб дозволити вказати політику отримання образів під час kubeadm "init" та "join". Значення має бути одним з "Always", "Never" або "IfNotPresent". "IfNotPresent" — це стандартне значення, яке використовувалося до цього оновлення.
  • Додано "InitConfiguration.patches.directory", "JoinConfiguration.patches.directory", щоб дозволити користувачеві конфігурувати теку, з якої буде братися патч для компонентів, розгорнутих за допомогою kubeadm.
  • Перенесено API BootstrapToken* та повʼязані з ним утиліти з групи API "kubeadm" до нової групи "bootstraptoken". API kubeadm версії v1beta3 більше не містить структур BootstrapToken*.

Міграція зі старих версій конфігурації kubeadm

  • kubeadm v1.15.x і новіше можна використовувати для міграції з v1beta1 на v1beta2.
  • kubeadm v1.22.x і новіші більше не підтримують v1beta1 і старіші API, але можуть бути використані для міграції з v1beta2 на v1beta3.
  • kubeadm v1.27.x і новіші більше не підтримують v1beta2 і старіші API.

Основи

Найкращим способом налаштування kubeadm є передача конфігураційного файлу у форматі YAML з опцією --config. Деякі з параметрів конфігурації, визначених у конфігураційному файлі kubeadm, також доступні як прапорці командного рядка, але у цьому випадку підтримуються лише найпоширеніші/простіші випадки використання.

Конфігураційний файл kubeadm може містити декілька типів конфігурацій, розділених трьома тире (---).

kubeadm підтримує наступні типи конфігурацій:

apiVersion: kubeadm.k8s.io/v1beta3
kind: InitConfiguration

apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration

apiVersion: kubeproxy.config.k8s.io/v1alpha1
kind: KubeProxyConfiguration

apiVersion: kubeadm.k8s.io/v1beta3
kind: JoinConfiguration

Щоб вивести стандартні значення для дій "init" і "join", скористайтеся наступними командами:

kubeadm config print init-defaults
kubeadm config print join-defaults

Перелік типів конфігурацій, які необхідно включити до конфігураційного файлу, залежить від дії, яку ви виконуєте (init або join), а також від параметрів конфігурації, які ви збираєтесь використовувати (стандартні або розширені налаштування).

Якщо деякі типи конфігурацій не передбачено або передбачено лише частково, kubeadm використовуватиме стандартні значення; стандартно kubeadm також забезпечує узгодженість значень між компонентами, коли це необхідно (наприклад, прапорець --cluster-cidr на менеджері контролерів та clusterCIDR у kube-proxy).

Користувачам завжди дозволено перевизначати стандартні значення, за винятком невеликої підгрупи налаштувань, що мають стосунок до безпеки (наприклад, примусово вмикати режим авторизації Node і RBAC на api-сервері).

Якщо користувач надасть типи конфігурації, які не очікуються для дії, яку ви виконуєте, kubeadm проігнорує ці типи і видасть попередження.

Типи конфігурації Kubeadm init

При виконанні kubeadm init з опцією --config можуть бути використані наступні типи конфігурацій: InitConfiguration, ClusterConfiguration, KubeProxyConfiguration, KubeletConfiguration, але тільки один з них поміж InitConfiguration та ClusterConfiguration є обовʼязковим.

apiVersion: kubeadm.k8s.io/v1beta3
kind: InitConfiguration
bootstrapTokens:
  ...
nodeRegistration:
  ...

Тип InitConfiguration слід використовувати для налаштування параметрів часу виконання, якими у випадку kubeadm init є конфігурація токена завантажувача та всі параметри, специфічні для вузла, на якому виконується kubeadm, включно з ними:

  • NodeRegistration, що містить поля, які стосуються реєстрації нового вузла у кластері; використовуйте його, щоб налаштувати імʼя вузла, сокет CRI для використання або будь-які інші параметри, які мають застосовуватися лише до цього вузла (наприклад, ip вузла).
  • LocalAPIEndpoint, що представляє точку доступу до екземпляра сервера API, який буде розгорнуто на цьому вузлі; використовуйте його, наприклад, для налаштування адреси оголошення сервера API.
apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
networking:
  ...
etcd:
  ...
apiServer:
  extraArgs:
    ...
  extraVolumes:
    ...
...

Тип InitConfiguration слід використовувати для налаштування параметрів часу виконання, якими у випадку kubeadm init є конфігурація токена завантажувача та всі параметри, специфічні для вузла, на якому виконується kubeadm, включно з ними:

  • NodeRegistration, що містить поля, які стосуються реєстрації нового вузла у кластері; використовуйте його, щоб налаштувати імʼя вузла, сокет CRI для використання або будь-які інші параметри, які мають застосовуватися лише до цього вузла (наприклад, ip вузла).
  • LocalAPIEndpoint, що представляє точку доступу до екземпляра сервера API, який буде розгорнуто на цьому вузлі; використовуйте його, наприклад, для налаштування адреси оголошення сервера API.
apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
networking:
  ...
etcd:
  ...
apiServer:
  extraArgs:
    ...
  extraVolumes:
    ...
...

Тип ClusterConfiguration слід використовувати для налаштування параметрів всього кластера, включаючи налаштування для:

  • networking, що містить конфігурацію мережевої топології кластера; використовуйте їх, наприклад, для налаштування підмережі Pod або підмережі сервісів.
  • etcd: використовуйте для налаштування локального etcd або для налаштування сервера API для використання зовнішнього кластера etcd.
  • конфігурації kube-apiserver, kube-scheduler, kube-controller-manager; використовуйте для налаштування компонентів панелі управління шляхом додавання індивідуальних налаштувань або перевизначення стандартних налаштувань kubeadm.
apiVersion: kubeproxy.config.k8s.io/v1alpha1
kind: KubeProxyConfiguration
  ...

Тип KubeProxyConfiguration слід використовувати для зміни конфігурації, що передається екземплярам kube-proxy, розгорнутим у кластері. Якщо цей обʼєкт не надано або надано лише частково, kubeadm застосовує стандартні значення.

Офіційну документацію про kube-proxy можна знайти на https://kubernetes.io/docs/reference/command-line-tools-reference/kube-proxy/ або https://pkg.go.dev/k8s.io/kube-proxy/config/v1alpha1#KubeProxyConfiguration.

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
  ...

Тип KubeletConfiguration слід використовувати для зміни конфігурацій, які буде передано всім екземплярам kubelet, розгорнутим у кластері. Якщо цей обʼєкт не надано або надано лише частково, kubeadm застосовує стандартні налаштування.

Офіційну документацію про kubelet див. на https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/ або https://pkg.go.dev/k8s.io/kubelet/config/v1beta1#KubeletConfiguration.

Ось повністю заповнений приклад одного YAML-файлу, що містить декілька типів конфігурації для використання під час запуску kubeadm init.

apiVersion: kubeadm.k8s.io/v1beta3
kind: InitConfiguration
bootstrapTokens:
  - token: "9a08jv.c0izixklcxtmnze7"
    description: "kubeadm bootstrap token"
    ttl: "24h"
  - token: "783bde.3f89s0fje9f38fhf"
    description: "another bootstrap token"
    usages:
      - authentication
      - signing
    groups:
      - system:bootstrappers:kubeadm:default-node-token
nodeRegistration:
  name: "ec2-10-100-0-1"
  criSocket: "/var/run/dockershim.sock"
  taints:
    - key: "kubeadmNode"
      value: "someValue"
      effect: "NoSchedule"
  kubeletExtraArgs:
    v: 4
  ignorePreflightErrors:
    - IsPrivilegedUser
  imagePullPolicy: "IfNotPresent"
localAPIEndpoint:
  advertiseAddress: "10.100.0.1"
  bindPort: 6443
certificateKey: "e6a2eb8581237ab72a4f494f30285ec12a9694d750b9785706a83bfcbbbd2204"
skipPhases:
  - addon/kube-proxy
---
apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
etcd:
  # локальний або зовнішній etcd
  local:
    imageRepository: "registry.k8s.io"
    imageTag: "3.2.24"
    dataDir: "/var/lib/etcd"
    extraArgs:
      listen-client-urls: "http://10.100.0.1:2379"
    serverCertSANs:
      -  "ec2-10-100-0-1.compute-1.amazonaws.com"
    peerCertSANs:
      - "10.100.0.1"
  # external:
    # endpoints:
    # - "10.100.0.1:2379"
    # - "10.100.0.2:2379"
    # caFile: "/etcd/kubernetes/pki/etcd/etcd-ca.crt"
    # certFile: "/etcd/kubernetes/pki/etcd/etcd.crt"
    # keyFile: "/etcd/kubernetes/pki/etcd/etcd.key"
networking:
  serviceSubnet: "10.96.0.0/16"
  podSubnet: "10.244.0.0/24"
  dnsDomain: "cluster.local"
kubernetesVersion: "v1.21.0"
controlPlaneEndpoint: "10.100.0.1:6443"
apiServer:
  extraArgs:
    authorization-mode: "Node,RBAC"
  extraVolumes:
    - name: "some-volume"
      hostPath: "/etc/some-path"
      mountPath: "/etc/some-pod-path"
      readOnly: false
      pathType: File
  certSANs:
    - "10.100.1.1"
    - "ec2-10-100-0-1.compute-1.amazonaws.com"
  timeoutForControlPlane: 4m0s
controllerManager:
  extraArgs:
    "node-cidr-mask-size": "20"
  extraVolumes:
    - name: "some-volume"
      hostPath: "/etc/some-path"
      mountPath: "/etc/some-pod-path"
      readOnly: false
      pathType: File
scheduler:
  extraArgs:
    bind-address: "10.100.0.1"
  extraVolumes:
    - name: "some-volume"
      hostPath: "/etc/some-path"
      mountPath: "/etc/some-pod-path"
      readOnly: false
      pathType: File
certificatesDir: "/etc/kubernetes/pki"
imageRepository: "registry.k8s.io"
clusterName: "example-cluster"
---
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
# параметри kubelet вказуються тут
---
apiVersion: kubeproxy.config.k8s.io/v1alpha1
kind: KubeProxyConfiguration
# параметри kube-proxy вказуються тут

Типи конфігурації Kubeadm join

При виконанні kubeadm join з опцією --config слід вказати тип JoinConfiguration.

apiVersion: kubeadm.k8s.io/v1beta3
kind: JoinConfiguration
  ...

Тип JoinConfiguration слід використовувати для налаштування параметрів часу виконання, якими у випадку kubeadm join є метод виявлення, що використовується для доступу до інформації про кластер, а також всі налаштування, специфічні для вузла, на якому виконується kubeadm, включно з:

  • nodeRegistration, що містить поля, які стосуються реєстрації нового вузла у кластері; використовуйте його, щоб налаштувати імʼя вузла, сокет CRI для використання або будь-які інші параметри, які мають застосовуватися лише до цього вузла (наприклад, ip вузла).
  • apiEndpoint, що представляє точку доступу до екземпляра сервера API, який буде розгорнуто на цьому вузлі.

Типи ресурсів

BootstrapToken

Зʼявляється в:

BootstrapToken описує один bootstrap токен, збережений як Secret у кластері

ПолеОпис
token [Обовʼязково]
BootstrapTokenString

token використовується для встановлення двосторонньої довіри між вузлами та панелями управління. Використовується для приєднання вузлів до кластера.

description
string

description встановлює зрозуміле людини повідомлення про те, чому існує цей токен і для чого він використовується, щоб інші адміністратори знали його призначення.

ttl
meta/v1.Duration

ttl визначає час життя цього токена. Стандартно — 24h. expires та ttl взаємовиключні.

expires
meta/v1.Time

expires вказує на мітку часу, коли цей токен закінчується. Стандартно встановлюється динамічно під час виконання на основі ttl. expires та ttl взаємовиключні.

usages
[]string

usages описує способи, якими цей токен може бути використаний. Стандартно може бути використаний для встановлення двосторонньої довіри, але це можна змінити тут.

groups
[]string

groups визначає додаткові групи, з якими цей токен буде автентифікуватися, якщо/коли використовуватиметься для автентифікації

BootstrapTokenString

Зʼявляється в:

BootstrapTokenString — це токен у форматі abcdef.abcdef0123456789, який використовується як для валідації практичності API-сервера з погляду вузла, що приєднується, так і як метод автентифікації вузла на етапі завантаження у фазі "kubeadm join". Цей токен є і повинен бути короткотривалим.

ПолеОпис
- [Обовʼязково]
string
Опис відсутній.
- [Обовʼязково]
string
Опис відсутній.

ClusterConfiguration

ClusterConfiguration містить конфігурацію для всього кластера kubeadm.

ПолеОпис
apiVersion
string
kubeadm.k8s.io/v1beta3
kind
string
ClusterConfiguration
etcd
Etcd

etcd містить конфігурацію для etcd.

networking
Networking

networking містить конфігурацію для мережевої топології кластера.

kubernetesVersion
string

kubernetesVersion — це цільова версія панелі управління.

controlPlaneEndpoint
string

controlPlaneEndpoint встановлює стабільну IP-адресу або DNS-імʼя для панелі управління. Це може бути дійсна IP-адреса або субдомен RFC-1123 DNS з додатковим TCP портом. Якщо controlPlaneEndpoint не вказано, використовуються advertiseAddress + bindPort; якщо controlPlaneEndpoint вказано без TCP порту, використовується bindPort. Можливі варіанти використання:

  • У кластері з більше ніж одним екземпляром панелі управління це поле повинно бути присвоєно адресу зовнішнього балансувальника навантаження перед екземплярами панелі управління.
  • У середовищах з обовʼязковим перерозподілом вузлів controlPlaneEndpoint може бути використаний для призначення стабільного DNS панелі управління.
apiServer
APIServer

apiServer містить додаткові налаштування для API сервера.

controllerManager
ControlPlaneComponent

controllerManager містить додаткові налаштування для менеджера контролерів.

scheduler
ControlPlaneComponent

scheduler містить додаткові налаштування для планувальника.

dns
DNS

dns визначає опції для DNS надбудови, встановленої в кластері.

certificatesDir
string

certificatesDir вказує, де зберігати або шукати всі необхідні сертифікати.

imageRepository
string

imageRepository встановлює реєстр контейнерів для завантаження образів. Якщо порожнє, стандартно буде використано registry.k8s.io. Якщо версія Kubernetes є CI-збіркою (версія Kubernetes починається з ci/), gcr.io/k8s-staging-ci-images буде використовуватись для компонентів панелі управління та для kube-proxy, тоді як registry.k8s.io буде використано для всіх інших образів.

featureGates
map[string]bool

featureGates містить функціональні можливості, увімкнені користувачем.

clusterName
string

Назва кластера.

InitConfiguration

InitConfiguration містить список елементів, специфічних для "kubeadm init"-тільки під час виконання. Тільки інформація kubeadm init. Ці поля використовуються виключно під час першого запуску kubeadm init. Після цього інформація в цих полях НЕ завантажується в kubeadm-config ConfigMap, який використовується, наприклад, під час kubeadm upgrade. Ці поля мають бути порожніми.

ПолеОпис
apiVersion
string
kubeadm.k8s.io/v1beta3
kind
string
InitConfiguration
bootstrapTokens
[]BootstrapToken

bootstrapTokens використовується під час kubeadm init і описує набір Bootstrap Tokens для створення. Ця інформація НЕ завантажується в kubeadm cluster configmap, частково через її конфіденційний характер

nodeRegistration
NodeRegistrationOptions

nodeRegistration містить поля, що стосуються реєстрації нового вузла панелі управління в кластері.

localAPIEndpoint
APIEndpoint

localAPIEndpoint представляє точку доступу екземпляра API сервера, яка розгорнута на цьому вузлі панелі управління. У HA-налаштуваннях це відрізняється від ClusterConfiguration.controlPlaneEndpoint в тому сенсі, що controlPlaneEndpoint є глобальною точкою доступу для кластера, яка потім розподіляє запити на кожен окремий API сервер. Цей конфігураційний обʼєкт дозволяє налаштувати, яку IP-адресу/DNS-імʼя та порт локальний API сервер оголошує як доступні. Стандартно kubeadm намагається автоматично визначити типову IP-адресу інтерфейсу та використовувати її, але в разі невдачі ви можете встановити бажане значення тут.

certificateKey
string

certificateKey встановлює ключ, яким сертифікати та ключі шифруються перед завантаженням у Secret в кластері під час фази uploadcerts init. Ключ сертифіката є кодуванням шістнадцяткового рядка, який є AES ключем розміром 32 байти.

skipPhases
[]string

skipPhases — це список фаз, які потрібно пропустити під час виконання команди. Список фаз можна отримати за допомогою команди kubeadm init --help. Прапорець "--skip-phases" має пріоритет перед цим полем.

patches
Patches

patches містить опції, повʼязані з застосуванням патчів до компонентів, розгорнутих за допомогою kubeadm під час kubeadm init.

JoinConfiguration

JoinConfiguration містить елементи, що описують певний вузол.

ПолеОпис
apiVersion
string
kubeadm.k8s.io/v1beta3
kind
string
JoinConfiguration
nodeRegistration
NodeRegistrationOptions

nodeRegistration містить поля, що стосуються реєстрації нового вузла панелі управління в кластері.

caCertPath
string

caCertPath — це шлях до SSL центра сертифікації, що використовується для захисту звʼязку між вузлом та панеллю управління. Стандартно — /etc/kubernetes/pki/ca.crt.

discovery [Обовʼязкове]
Discovery

discovery визначає параметри, які kubelet використовує під час процесу TLS старту.

controlPlane
JoinControlPlane

controlPlane визначає додатковий екземпляр панелі управління, який буде розгорнутий на приєднаному вузлі. Якщо nil, додатковий екземпляр панелі управління не буде розгорнуто.

skipPhases
[]string

skipPhases — це список фаз, які потрібно пропустити під час виконання команди. Список фаз можна отримати за допомогою команди kubeadm join --help. Прапорець --skip-phases має пріоритет перед цим полем.

patches
Patches

patches містить параметри, повʼязані із застосуванням патчів до компонентів, розгорнутих за допомогою kubeadm під час kubeadm join.

APIEndpoint

Зʼявляється в:

Структура APIEndpoint містить елементи екземпляра API сервера, розгорнутого на вузлі.

ПолеОпис
advertiseAddress
string

advertiseAddress встановлює IP-адресу, яку буде оголошувати API сервер.

bindPort
int32

bindPort встановлює безпечний порт, до якого буде привʼязаний API сервер. Стандартно — 6443.

APIServer

Зʼявляється в:

APIServer містить налаштування, необхідні для розгортання API сервера в кластері.

ПолеОпис
ControlPlaneComponent [Обовʼязкове]
ControlPlaneComponent
(Члени ControlPlaneComponent вбудовані в цей тип.) Опис відсутній.
certSANs
[]string

certSANs встановлює додаткові альтернативні імена субʼєктів (SANs) для сертифіката підпису API сервера.

timeoutForControlPlane
meta/v1.Duration

timeoutForControlPlane контролює тайм-аут, який ми очікуємо для появи API сервера.

BootstrapTokenDiscovery

Зʼявляється в:

BootstrapTokenDiscovery використовується для налаштування параметрів виявлення на основі маркера початкового завантаження.

ПолеОпис
token [Обовʼязкове]
string

token — це маркер, що використовується для перевірки інформації про кластер, отриманої з панелі управління.

apiServerEndpoint
string

apiServerEndpoint — це IP-адреса або доменне імʼя до API сервера, з якого буде отримана інформація.

caCertHashes
[]string

caCertHashes вказує набір публічних ключів для перевірки при використанні виявлення на основі маркера. Кореневий сертифікат CA, знайдений під час виявлення, повинен відповідати одному з цих значень. Зазначення порожнього набору відключає закріплення кореневого сертифіката CA, що може бути небезпечним. Кожен хеш зазначається у форматі <type>:<value>, де єдиним підтримуваним типом на даний момент є "sha256". Це хеш SHA-256 у шістнадцятковому форматі, який обчислюється за допомогою обʼєкта Subject Public Key Info (SPKI) у DER-кодованому форматі ASN.1. Ці хеші можна обчислити за допомогою, наприклад, OpenSSL.

unsafeSkipCAVerification
bool

unsafeSkipCAVerification дозволяє виявлення на основі маркера без перевірки CA за допомогою caCertHashes. Це може послабити безпеку kubeadm, оскільки інші вузли можуть видавати себе за панель управління.

ControlPlaneComponent

Зʼявляється в:

ControlPlaneComponent містить налаштування, спільні для компонентів панелі управління кластера.

ПолеОпис
extraArgs
map[string]string

extraArgs — це додатковий набір параметрів, що передаються компоненту панелі кправління. Ключ у цьому map — це імʼя параметра, як воно зʼявляється в командному рядку, без попереднього дефіса(ів).

extraVolumes
[]HostPathMount

extraVolumes — це додатковий набір хост-томів, змонтованих до компоненту панелі управління.

DNS

Зʼявляється в:

DNS визначає надбудовою DNS, що має використовуватися в кластері.

ПолеОпис
ImageMeta [Обовʼязкове]
ImageMeta
(Члени ImageMeta вбудовані в цей тип.)

imageMeta дозволяє налаштувати образ, яке використовується для компонента DNS.

Discovery

Зʼявляється в:

Discovery визначає параметри для kubelet, які використовуються під час процесу TLS Bootstrap.

ПолеОпис
bootstrapToken
BootstrapTokenDiscovery

bootstrapToken використовується для налаштування параметрів на основі токена bootstrap. bootstrapToken і file є взаємовиключними.

file
FileDiscovery

file використовується для вказівки файлу або URL-адреси до файлу kubeconfig, з якого завантажується інформація про кластер. bootstrapToken і file є взаємовиключними.

tlsBootstrapToken
string

tlsBootstrapToken є токеном, який використовується для TLS bootstrapping. Якщо bootstrapToken встановлено, це поле стандартно встановлюється на .bootstrapToken.token, але може бути перевизначено. Якщо встановлено file, це поле має бути встановлено у випадку, якщо KubeConfigFile не містить іншої інформації для автентифікації.

timeout
meta/v1.Duration

timeout змінює час очікування під час виявлення.

Etcd

Зʼявляється в:

Etcd містить елементи, що описують конфігурацію Etcd.

ПолеОпис
local
LocalEtcd

local надає параметри конфігурації для налаштування локального екземпляра etcd. local і external є взаємовиключними.

external
ExternalEtcd

external описує, як підключитися до зовнішнього кластера etcd. local і external є взаємовиключними.

ExternalEtcd

Зʼявляється в:

ExternalEtcd описує зовнішній кластер etcd. Kubeadm не має знань про знаходження файлів сертифікатів, і вони повинні бути надані.

ПолеОпис
endpoints [Обовʼязково]
[]string

endpoints містить список учасників etcd.

caFile [Обовʼязково]
string

caFile є файлом сертифіката SSL Certificate Authority (CA), який використовується для захисту звʼязку etcd. Обовʼязковий, якщо використовується TLS-зʼєднання.

certFile [Обовʼязково]
string

certFile є файлом сертифіката SSL, який використовується для захисту звʼязку etcd. Обовʼязковий, якщо використовується TLS-зʼєднання.

keyFile [Обовʼязково]
string

keyFile є файлом ключа SSL, який використовується для захисту звʼязку etcd. Обовʼязковий, якщо використовується TLS-зʼєднання.

FileDiscovery

Зʼявляється в:

FileDiscovery використовується для вказання файлу або URL до файлу kubeconfig, з якого завантажується інформація про кластер.

ПолеОпис
kubeConfigPath [Обовʼязково]
string

kubeConfigPath використовується для вказання фактичного шляху до файлу або URL до файлу kubeconfig, з якого завантажується інформація про кластер.

HostPathMount

Зʼявляється в:

HostPathMount містить елементи, що описують томи, які монтуються з хоста.

ПолеОпис
name [Обовʼязково]
string

name — це імʼя тому всередині шаблону Pod.

hostPath [Обовʼязково]
string

hostPath — це шлях на хості, який буде змонтовано всередині Pod.

mountPath [Обовʼязково]
string

mountPath — це шлях всередині Pod, куди буде змонтовано hostPath.

readOnly
bool

readOnly контролює доступ на запис до тому.

pathType
core/v1.HostPathType

pathType — це тип hostPath.

ImageMeta

Зʼявляється в:

ImageMeta дозволяє налаштувати образи, що використовуються для компонентів, які не походять з процесу випуску Kubernetes/Kubernetes

ПолеОпис
imageRepository
string

imageRepository встановлює реєстр контейнерів, з якого будуть завантажені образи. Якщо не встановлено, буде використовуватися imageRepository, визначений у ClusterConfiguration.

imageTag
string

imageTag дозволяє вказати теґ для образу. Якщо це значення встановлено, kubeadm не буде автоматично змінювати версію вище зазначених компонентів під час оновлень.

JoinControlPlane

Зʼявляється в:

JoinControlPlane містить елементи, що описують додатковий екземпляр панелі управління, який потрібно розгорнути на приєднаному вузлі.

ПолеОпис
localAPIEndpoint
APIEndpoint

localAPIEndpoint представляє точку доступу для екземпляра API-сервера, який буде розгорнуто на цьому вузлі.

certificateKey
string

certificateKey є ключем, який використовується для дешифрування сертифікатів після їх завантаження з секрету під час приєднання нового вузла панелі упралвіння. Відповідний ключ шифрування знаходиться в InitConfiguration. Ключ сертифіката є рядком у шістнадцятковому кодуванні, що є AES-ключем розміром 32 байти.

LocalEtcd

Зʼявляється в:

LocalEtcd описує, що kubeadm має запускати кластер etcd локально.

ПолеОпис
ImageMeta [Обовʼязкове]
ImageMeta
(Члени ImageMeta інтегровані в цей тип.)

ImageMeta дозволяє налаштувати контейнер, що використовується для etcd.

dataDir [Обовʼязкове]
string

dataDir — це тека, в якій etcd розміщуватиме свої дані. Стандартно використовується "/var/lib/etcd".

extraArgs
map[string]string

extraArgs — додаткові аргументи, що передаються бінарному файлу etcd при його запуску всередині статичного Pod. Ключ у цьому map є імʼям прапорця, як він зʼявляється на командному рядку, але без дефісів на початку.

serverCertSANs
[]string

serverCertSANs задає додаткові Subject Alternative Names (SANs) для сертифіката підпису сервера etcd.

peerCertSANs
[]string

peerCertSANs задає додаткові Subject Alternative Names (SANs) для сертифіката підпису peer etcd.

Networking

Зʼявляється в:

Networking містить елементи, що описують конфігурацію мережі кластера.

ПолеОпис
serviceSubnet
string

serviceSubnet — це підмережа, що використовується Kubernetes Services. Стандртно — "10.96.0.0/12".

podSubnet
string

podSubnet — це підмережа, що використовується Pod.

dnsDomain
string

dnsDomain — це DNS домен, що використовується Kubernetes Services. Стандартно — "cluster.local".

NodeRegistrationOptions

Зʼявляється в:

NodeRegistrationOptions містить поля, що стосуються реєстрації нової панелі управління або вузла в кластері, як через kubeadm init, так і через kubeadm join.

ПолеОпис
name
string

name — це поле .metadata.name обʼєкта Node API, який буде створений в процесі kubeadm init або kubeadm join. Це поле також використовується в полі CommonName клієнтського сертифікату kubelet до API сервера. Стандартно буде використано імʼя хоста вузла, якщо не надано.

criSocket
string

criSocket використовується для отримання інформації про середовище виконання контейнерів. Ця інформація буде анотована до обʼєкта Node API для подальшого використання.

taints [Обовʼязково]
[]core/v1.Taint

taints вказує на taints, з якими обʼєкт Node API повинен бути зареєстрований. Якщо це поле не встановлено, тобто nil, воно буде стандартно з control-plane taint для вузлів control-plane. Якщо ви не хочете taint для вашого вузла control-plane, встановіть в це поле порожній список, тобто taints: [] у YAML файлі. Це поле використовується виключно для реєстрації вузлів.

kubeletExtraArgs
map[string]string

kubeletExtraArgs передає додаткові аргументи до kubelet. Аргументи тут передаються в командний рядок kubelet через файл середовища kubeadm, що створюється під час виконання, щоб kubelet міг його використовувати. Це переважає загальну базову конфігурацію в ConfigMap kubelet-config. Прапорці мають вищий пріоритет під час парсингу. Ці значення локальні та специфічні для вузла, на якому виконується kubeadm. Ключ у цьому словнику — це назва прапорці, як вона зʼявляється в командному рядку, але без початкових дефісів.

ignorePreflightErrors
[]string

ignorePreflightErrors надає список помилок перед запуском, які слід ігнорувати під час реєстрації поточного вузла, наприклад, IsPrevilegedUser,Swap. Значення all ігнорує помилки від усіх перевірок.

imagePullPolicy
core/v1.PullPolicy

imagePullPolicy вказує політику для витягування образів під час операцій kubeadm "init" та "join". Значення цього поля повинно бути одне з "Always", "IfNotPresent" або "Never". Якщо це поле не встановлено, kubeadm стандартно встановить його в "IfNotPresent", або витягне необхідні образи, якщо вони не присутні на хості.

Patches

Зʼявляється в:

Patches містить параметри, повʼязані з застосуванням патчів до компонентів, розгорнутих за допомогою kubeadm.

ПолеОпис
directory
string

directory — це шлях до теки, що містить файли, названі "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd". "patchtype" може бути одним з "strategic", "merge" або "json" та відповідати форматам патчів, підтримуваних kubectl. Стандартно "patchtype" — "strategic". "extension" повинна бути або "json", або "yaml". "suffix" — це необовʼязковий рядок, який може бути використаний для визначення, які патчі застосовуються першими за алфавітним порядком.

6.14.14 - kubeadm Configuration (v1beta4)

Огляд

Пакунок v1beta4 визначає версію v1beta4 формату конфігураційного файлу kubeadm. Ця версія покращує формат v1beta3, виправляючи деякі незначні проблеми і додаючи кілька нових полів.

Список змін з версії v1beta3:

  • TODO https://github.com/kubernetes/kubeadm/issues/2890
  • Підтримуйте власні змінні оточення у компонентах панелі управління у розділі ClusterConfiguration. Використовуйте apiServer.extraEnvs, controllerManager.extraEnvs, scheduler.extraEnvs, etcd.local.extraEnvs.
  • Тип API ResetConfiguration тепер підтримується у v1beta4. Користувачі можуть скинути конфігурацію вузла, передавши kubeadm reset файл --config.
  • режим dry-run тепер налаштовується у InitConfiguration та JoinConfiguration.
  • Замінено існуючі map додаткових аргументів типу рядок/рядок на структуровані додаткові аргументи, які підтримують дублікати. Зміни застосовано до ClusterConfiguration — apiServer.extraArgs, controllerManager.extraArgs, scheduler.extraArgs, etcd.local.extraArgs. Також до nodeRegistration.kubeletExtraArgs.
  • Додано ClusterConfiguration.encryptionAlgorithm, за допомогою якого можна задати алгоритм асиметричного шифрування, що використовується для ключів і сертифікатів цього кластера. Може бути один з "RSA-2048" (стандартно), "RSA-3072", "RSA-4096" або "ECDSA-P256".
  • Додано ClusterConfiguration.dns.disabled та ClusterConfiguration.proxy.disabled, за допомогою яких можна вимкнути надбудови CoreDNS та kube-proxy під час ініціалізації кластера. Якщо пропустити повʼязані з ними етапи під час створення кластера, ці ж поля буде встановлено у значення false.
  • Додано поле nodeRegistration.imagePullSerial у InitConfiguration та JoinConfiguration, за допомогою якого можна контролювати, чи kubeadm витягує образи послідовно або паралельно.
  • API kubeadm UpgradeConfiguration тепер підтримується у v1beta4 при передачі --config до команд kubeadm upgrade. Використання конфігурації компонентів для kubelet та kube-proxy, InitConfiguration та ClusterConfiguration є застарілим і буде проігноровано при передачі --config до команд upgrade.
  • Додано структуру Timeouts до InitConfiguration, JoinConfiguration, ResetConfiguration та UpgradeConfiguration, яку можна використовувати для налаштування різних тайм-аутів.
  • Додано поля certificateValidityPeriod та caCertificateValidityPeriod до ClusterConfiguration. Ці поля можна використовувати для контролю терміну дії сертифікатів, згенерованих kubeadm під час виконання таких підкоманд, як init, join, upgrade і certs. Стандартні значення залишаються 1 рік для сертифікатів без CA і 10 років для сертифікатів з CA. Лише сертифікати без CA можна поновлювати командою kubeadm certs renew.

Міграція зі старих версій конфігурації kubeadm

  • kubeadm v1.15.x і новіше можна використовувати для міграції з v1beta1 на v1beta2.
  • kubeadm v1.22.x і новіші більше не підтримують v1beta1 і старіші API, але можуть бути використані для міграції з v1beta2 на v1beta3.
  • kubeadm v1.27.x і новіші більше не підтримують v1beta2 і старіші API.
  • TODO: https://github.com/kubernetes/kubeadm/issues/2890 додати версію, яку можна використовувати для конвертації у v1beta4

Основи

Найкращим способом налаштування kubeadm є передача конфігураційного файлу у форматі YAML з опцією --config. Деякі з параметрів конфігурації, визначених у конфігураційному файлі kubeadm, також доступні як прапорці командного рядка, але цей спосіб підтримує лише найпоширеніші/найпростіші випадки використання.

Конфігураційний файл kubeadm може містити декілька типів конфігурацій, розділених трьома тире (---).

kubeadm підтримує наступні типи конфігурацій:

apiVersion: kubeadm.k8s.io/v1beta4
kind: InitConfiguration


apiVersion: kubeadm.k8s.io/v1beta4
kind: ClusterConfiguration


apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration


apiVersion: kubeproxy.config.k8s.io/v1alpha1
kind: KubeProxyConfiguration


apiVersion: kubeadm.k8s.io/v1beta4
kind: JoinConfiguration

apiVersion: kubeadm.k8s.io/v1beta4
kind: ResetConfiguration

apiVersion: kubeadm.k8s.io/v1beta4
kind: UpgradeConfiguration

Для виведення стандартних значень для дій "init" та "join" скористайтеся наступними командами:

kubeadm config print init-defaults
kubeadm config print join-defaults
kubeadm config print reset-defaults
kubeadm config print upgrade-defaults

Перелік типів конфігурацій, які необхідно включити до конфігураційного файлу, залежить від дії, яку ви виконуєте (init або join), а також від параметрів конфігурації, які ви збираєтеся використовувати (стандартні або розширені налаштування).

Якщо деякі типи конфігурацій не передбачено або передбачено лише частково, kubeadm використовуватиме стандартні значення; стандартне налаштування kubeadm включає також забезпечення узгодженості значень між компонентами, коли це необхідно (наприклад, прапорець --cluster-cidr на менеджері контролерів та clusterCIDR на kube-proxy).

Користувачам завжди дозволено перевизначати стандартні значення, за винятком невеликої підгрупи налаштувань, що мають відношення до безпеки (наприклад, включення режиму авторизації Node і RBAC на api-сервері).

Якщо користувач надасть типи конфігурації, які не очікуються для дії, яку ви виконуєте, kubeadm проігнорує ці типи та виведе попередження.

Типи конфігурацій Kubeadm init

При виконанні kubeadm init з опцією --config можуть бути використані наступні типи конфігурацій: InitConfiguration, ClusterConfiguration, KubeProxyConfiguration, KubeletConfiguration, але тільки один з них між InitConfiguration і ClusterConfiguration є обовʼязковим.

apiVersion: kubeadm.k8s.io/v1beta4
kind: InitConfiguration
bootstrapTokens:

	...

nodeRegistration:

	...

Тип InitConfiguration слід використовувати для налаштування параметрів часу виконання, якими у випадку kubeadm init є конфігурація токена завантажувача та всі параметри, специфічні для вузла, на якому виконується kubeadm, включно з:

  • NodeRegistration, що містить поля, які стосуються реєстрації нового вузла у кластері; використовуйте його, щоб налаштувати імʼя вузла, сокет CRI для використання або будь-які інші параметри, які мають застосовуватися лише до цього вузла (наприклад, ip вузла).
  • LocalAPIEndpoint, що представляє точку доступу до екземпляра сервера API, який буде розгорнуто на цьому вузлі; використовуйте його, наприклад, для налаштування адреси оголошень сервера API.
apiVersion: kubeadm.k8s.io/v1beta4
kind: ClusterConfiguration
networking:

	...

etcd:

	...

apiServer:

	extraArgs:
	  ...
	extraVolumes:
	  ...

...

Тип ClusterConfiguration слід використовувати для налаштування параметрів всього кластера, включаючи налаштування для:

  • networking, що зберігає конфігурацію мережевої топології кластера; використовуйте його, наприклад, для налаштування підмережі Pod або підмережі сервісів.
  • etcd: використовуйте його, наприклад, для налаштування локального etcd або для налаштування сервера API для використання зовнішнього кластера etcd.
  • конфігурації kube-apiserver, kube-scheduler, kube-controller-manager; використовуйте його для налаштування компонентів панелі управління, додаючи індивідуальні налаштування або перевизначаючи стандартні налаштування kubeadm.
apiVersion: kubeproxy.config.k8s.io/v1alpha1
kind: KubeProxyConfiguration

	...

Тип KubeProxyConfiguration слід використовувати для зміни конфігурації, що передається екземплярам kube-proxy, розгорнутим у кластері. Якщо цей обʼєкт не надано або надано лише частково, kubeadm застосовує стандартні значення.

Офіційну документацію про kube-proxy можна знайти на https://kubernetes.io/docs/reference/command-line-tools-reference/kube-proxy/ або https://pkg.go.dev/k8s.io/kube-proxy/config/v1alpha1#KubeProxyConfiguration.

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration

	...

Тип KubeletConfiguration слід використовувати для зміни конфігурацій, які буде передано всім екземплярам kubelet, розгорнутим у кластері. Якщо цей обʼєкт не надано або надано лише частково, kubeadm застосовує стандартні налаштування.

Офіційну документацію про kubelet можна знайти на https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/ або https://pkg.go.dev/k8s.io/kubelet/config/v1beta1#KubeletConfiguration.

Ось повністю заповнений приклад одного YAML-файлу, що містить декілька типів конфігурації для використання під час запуску kubeadm init.

apiVersion: kubeadm.k8s.io/v1beta4
kind: InitConfiguration
bootstrapTokens:
  - token: "9a08jv.c0izixklcxtmnze7"
    description: "kubeadm bootstrap token"
    ttl: "24h"
  - token: "783bde.3f89s0fje9f38fhf"
    description: "another bootstrap token"
    usages:
  - authentication
  - signing
    groups:
  - system:bootstrappers:kubeadm:default-node-token

nodeRegistration:
  name: "ec2-10-100-0-1"
  criSocket: "unix:///var/run/containerd/containerd.sock"
  taints:
    - key: "kubeadmNode"
      value: "someValue"
      effect: "NoSchedule"
  kubeletExtraArgs:
    - name: v
      value: 5
  ignorePreflightErrors:
     - IsPrivilegedUser
  imagePullPolicy: "IfNotPresent"

localAPIEndpoint:
  advertiseAddress: "10.100.0.1"
  bindPort: 6443

certificateKey: "e6a2eb8581237ab72a4f494f30285ec12a9694d750b9785706a83bfcbbbd2204"
skipPhases:
  - preflight

timeouts:
  controlPlaneComponentHealthCheck: "60s
  kubernetesAPICall: "40s"
---
apiVersion: kubeadm.k8s.io/v1beta4
kind: ClusterConfiguration
etcd:

  # локальний або зовнішній etcd
  local:
    imageRepository: "registry.k8s.io"
    imageTag: "3.2.24"
    dataDir: "/var/lib/etcd"
    extraArgs:
      - name: listen-client-urls
        value: http://10.100.0.1:2379
    extraEnvs:
      - name: SOME_VAR
        value: SOME_VALUE
    serverCertSANs:
      -  "ec2-10-100-0-1.compute-1.amazonaws.com"
    peerCertSANs:
      - "10.100.0.1"
# external:
  # endpoints:
  # - "10.100.0.1:2379"
  # - "10.100.0.2:2379"
  # caFile: "/etcd/kubernetes/pki/etcd/etcd-ca.crt"
  # certFile: "/etcd/kubernetes/pki/etcd/etcd.crt"
  # keyFile: "/etcd/kubernetes/pki/etcd/etcd.key"

networking:
  serviceSubnet: "10.96.0.0/16"
  podSubnet: "10.244.0.0/24"
  dnsDomain: "cluster.local"

kubernetesVersion: "v1.21.0"
controlPlaneEndpoint: "10.100.0.1:6443"
apiServer:

  extraArgs:
    - name: authorization-mode
      value: "Node,RBAC"
  extraEnvs:
    - name: SOME_VAR
      value: SOME_VALUE
  extraVolumes:
    - name: "some-volume"
      hostPath: "/etc/some-path"
      mountPath: "/etc/some-pod-path"
      readOnly: false
      pathType: File
  certSANs:
    - "10.100.1.1"
    - "ec2-10-100-0-1.compute-1.amazonaws.com"

controllerManager:
  extraArgs:
    - name: node-cidr-mask-size
      value: "20"
  extraVolumes:
    - name: "some-volume"
      hostPath: "/etc/some-path"
      mountPath: "/etc/some-pod-path"
      readOnly: false
      pathType: File

scheduler:
  extraArgs:
    - name: address
      value: "10.100.0.1"
  extraVolumes:
    - name: "some-volume"
      hostPath: "/etc/some-path"
      mountPath: "/etc/some-pod-path"
      readOnly: false
      pathType: File

certificatesDir: "/etc/kubernetes/pki"
imageRepository: "registry.k8s.io"
clusterName: "example-cluster"
encryptionAlgorithm: ECDSA-P256
dns:
  disabled: true  # disable CoreDNS
proxy:
  diabled: true   # disable kube-proxy
---
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
# параметри kubelet вказуються тут
---
apiVersion: kubeproxy.config.k8s.io/v1alpha1
kind: KubeProxyConfiguration
# параметри kube-proxy вказуються тут

Типи конфігурацій Kubeadm join

При виконанні kubeadm join з опцією --config слід вказати тип JoinConfiguration.

apiVersion: kubeadm.k8s.io/v1beta4
kind: JoinConfiguration
discovery:
  bootstrapToken:
    apiServerEndpoint: some-address:6443
    token: abcdef.0123456789abcdef
    unsafeSkipCAVerification: true
  tlsBootstrapToken: abcdef.0123456789abcdef

Тип JoinConfiguration слід використовувати для налаштування параметрів часу виконання, якими у випадку kubeadm join є метод виявлення, що використовується для доступу до інформації про кластер, а також всі налаштування, специфічні для вузла, на якому виконується kubeadm, включно з:

  • nodeRegistration, що містить поля, які стосуються реєстрації нового вузла у кластері; використовуйте його, щоб налаштувати імʼя вузла, сокет CRI для використання або будь-які інші параметри, які мають застосовуватися лише до цього вузла (наприклад, ip вузла).
  • apiEndpoint, що представляє точку доступу до екземпляра сервера API, який буде розгорнуто на цьому вузлі.

Типи конфігурацій Kubeadm reset

При виконанні kubeadm reset з опцією --config слід вказати тип ResetConfiguration.

apiVersion: kubeadm.k8s.io/v1beta4
kind: ResetConfiguration
...

Типи конфігурацій Kubeadm upgrade

При виконанні kubeadm upgrade з опцією --config слід вказати тип UpgradeConfiguration.

apiVersion: kubeadm.k8s.io/v1beta4
kind: UpgradeConfiguration
apply:
  ...

diff:
  ...

node:
  ...

plan:
  ...

Структура UpgradeConfiguration містить кілька підструктур, які застосовуються тільки різних команд kubeadm upgrade. Наприклад, apply використовується з командою kubeadm upgrade apply тож всі інші підструктури будуть проігноровані.

Типи ресурсів

BootstrapToken

Зʼявляється в:

BootstrapToken описує один bootstrap token, зберігається як Secret у кластері

ПолеОпис
token [Обовʼязкове]
BootstrapTokenString

token використовується для встановлення двосторонньої довіри між вузлами та панеллю управління. Використовується для приєднання вузлів до кластера.

description
string

description встановлює зрозуміле людині повідомлення про те, чому існує цей токен і для чого він використовується, щоб інші адміністратори могли зрозуміти його призначення.

ttl
meta/v1.Duration

ttl визначає час життя цього токена. Стандартно — 24h. expires та ttl є взаємовиключними.

expires
meta/v1.Time

expires вказує на момент, коли цей токен закінчує свою дію. Стандартно встановлюється динамічно під час виконання на основі ttl. expires та ttl є взаємовиключними.

usages
[]string

usages описує способи, якими цей токен може бути використаний. Може стандартно використовуватися для встановлення двосторонньої довіри, але це можна змінити тут.

groups
[]string

groups вказує на додаткові групи, до яких цей токен буде автентифікуватися при використанні для автентифікації

BootstrapTokenString

Зʼявляється в:

BootstrapTokenString є токеном формату abcdef.abcdef0123456789, який використовується як для перевірки практичності API сервера з погляду вузла, що приєднується, так і як метод автентифікації вузла в фазі bootstrap команди "kubeadm join". Цей токен є і має бути короткочасним.

ПолеОпис
- [Обовʼязкове]
string
Опис не надано.
- [Обовʼязкове]
string
Опис не надано.

ClusterConfiguration

ClusterConfiguration містить конфігурацію на рівні кластера для кластера kubeadm.

ПолеОпис
apiVersion
string
kubeadm.k8s.io/v1beta4
kind
string
ClusterConfiguration
etcd
Etcd

etcd містить конфігурацію для etcd.

networking
Networking

networking містить конфігурацію для мережевої топології кластера.

kubernetesVersion
string

kubernetesVersion — це цільова версія панелі управління.

controlPlaneEndpoint
string

controlPlaneEndpoint встановлює стабільну IP-адресу або DNS-імʼя для панелі управління; Може бути дійсною IP-адресою або піддоменом RFC-1123 DNS, обидва з необовʼязковим TCP портом. Якщо controlPlaneEndpoint не зазначено, використовуються advertiseAddress + bindPort; якщо controlPlaneEndpoint зазначено, але без TCP порту, використовується bindPort. Можливі використання:

  • У кластері з більше ніж однією панеллю управління, це поле має бути присвоєно адресі зовнішнього балансувальника навантаження перед екземплярами панелі управління.
  • У середовищах з примусовою утилізацією вузлів, controlPlaneEndpoint може використовуватися для присвоєння стабільного DNS панелі управління.
apiServer
APIServer

apiServer містить додаткові налаштування для API сервера.

controllerManager
ControlPlaneComponent

controllerManager містить додаткові налаштування для менеджера контролерів.

scheduler
ControlPlaneComponent

scheduler містить додаткові налаштування для планувальника.

dns
DNS

dns визначає параметри для нпдбудови DNS, встановленої в кластері.

proxy [Обовʼязкове]
Proxy

proxy визначає параметри для надбудови проксі, встановленої в кластері.

certificatesDir
string

certificatesDir вказує, де зберігати або шукати всі необхідні сертифікати.

imageRepository
string

imageRepository встановлює реєстр контейнерів для витягування зображень. Якщо порожньо, стандартно використовується registry.k8s.io. У випадку, якщо версія Kubernetes є CI-збіркою (версія Kubernetes починається з ci/) gcr.io/k8s-staging-ci-images буде використовуватись для компонентів панелі управління та для kube-proxy, тоді як registry.k8s.io буде використовуватися для всіх інших образів.

featureGates
map[string]bool

featureGates містить функціональні можливості, увімкнені користувачем.

clusterName
string

Назва кластера.

encryptionAlgorithm
EncryptionAlgorithmType

encryptionAlgorithm містить тип асиметричного алгоритму шифрування, що використовується для ключів та сертифікатів. Може бути "RSA" (стандартний алгоритм, розмір ключа 2048) або "ECDSA" (використовує еліптичну криву P-256).

certificateValidityPeriod
meta/v1.Duration

certificateValidityPeriod вказує термін дії для не-СА сертифікату, згенерованого kubeadm. Стандартне значення: 8760h (365 днів * 24 години = 1 рік)

caCertificateValidityPeriod
meta/v1.Duration

caCertificateValidityPeriod вказує термін дії для СА сертифікату, згенерованого kubeadm. Стандартне значення: 87600h (365 днів * 24 годин * 10 = 10 років)

InitConfiguration

InitConfiguration містить список елементів, що специфічні для тільки для запуску kubeadm init. Ці поля використовуються лише під час першого запуску kubeadm init. Після цього інформація в цих полях НЕ завантажується до ConfigMap kubeadm-config, який використовується, наприклад, при kubeadm upgrade. Ці поля повинні бути опущені.

ПолеОпис
apiVersion
string
kubeadm.k8s.io/v1beta4
kind
string
InitConfiguration
bootstrapTokens
[]BootstrapToken

bootstrapTokens враховується під час kubeadm init і описує набір Bootstrap Token для створення. Ця інформація НЕ завантажується до ConfigMap кластера kubeadm, частково через її чутливий характер.

dryRun [Обовʼязкове]
bool

dryRun вказує, чи увімкнено режим перевірки, не застосовувати жодні зміни в режимі перевірки, просто вивести те, що буде зроблено.

nodeRegistration
NodeRegistrationOptions

nodeRegistration містить поля, що стосуються реєстрації нового вузла панелі управління в кластері.

localAPIEndpoint
APIEndpoint

localAPIEndpoint представляє точку доступу до екземпляра API сервера, що розгорнутий на цьому вузлі панелі управління. У налаштуваннях HA це відрізняється від ClusterConfiguration.controlPlaneEndpoint тим, що controlPlaneEndpoint є глобальною точкою доступу для кластера, яка потім розподіляє запити між кожним окремим API сервером. Цей обʼєкт конфігурації дозволяє налаштувати, на якій IP/DNS-імʼя та порт локальний API сервер оголошує свою доступність. Стандартно kubeadm намагається автоматично визначити IP адресу інтерфейсу та використовувати її, але якщо цей процес не вдалося, ви можете встановити бажане значення тут.

certificateKey
string

certificateKey встановлює ключ, яким шифруються сертифікати та ключі перед завантаженням в Secret в кластері під час фази uploadcerts init. Ключ сертифіката є рядком у форматі hex, що є AES ключем розміром 32 байти.

skipPhases
[]string

skipPhases є списком фаз, які потрібно пропустити під час виконання команди. Список фаз можна отримати за допомогою команди kubeadm init --help. Прапорець --skip-phases має пріоритет над цим полем.

patches
Patches

patches містить параметри, що стосуються застосування патчів до компонентів, розгорнутих kubeadm під час kubeadm init.

timeouts
Timeouts

timeouts містить різні тайм-аути, які застосовуються до команд kubeadm.

JoinConfiguration

JoinConfiguration містить елементи, що описують конкретний вузол.

ПолеОпис
apiVersion
string
kubeadm.k8s.io/v1beta4
kind
string
JoinConfiguration
dryRun
bool

dryRun вказує, чи увімкнено режим перевірки. Якщо він увімкнений, не застосовуються жодні зміни, просто виводиться те, що буде зроблено.

nodeRegistration
NodeRegistrationOptions

nodeRegistration містить поля, що стосуються реєстрації нового вузла панелі управління в кластері.

caCertPath
string

caCertPath є шляхом до SSL центру сертифікації, що використовується для забезпечення комунікацій між вузлом та панеллю управління. Стандартно — /etc/kubernetes/pki/ca.crt.

discovery [Обовʼязкове]
Discovery

discovery вказує параметри, які kubelet використовує під час процесу TLS bootstrap.

controlPlane
JoinControlPlane

controlPlane визначає додатковий екземпляр панелі управління, який буде розгорнуто на вузлі, що приєднується. Якщо nil, жоден додатковий екземпляр панелі управління не буде розгорнуто.

skipPhases
[]string

skipPhases є списком фаз, які потрібно пропустити під час виконання команди. Список фаз можна отримати за допомогою команди kubeadm join --help. Прапорець --skip-phases має пріоритет над цим полем.

patches
Patches

patches містить параметри, що стосуються застосування патчів до компонентів, розгорнутих kubeadm під час kubeadm join.

timeouts
Timeouts

timeouts містить різні тайм-аути, які застосовуються до команд kubeadm.

ResetConfiguration

ResetConfiguration містить список полів, що є специфічними для режиму kubeadm reset.

ПолеОпис
apiVersion
string
kubeadm.k8s.io/v1beta4
kind
string
ResetConfiguration
cleanupTmpDir
bool

cleanupTmpDir вказує, чи слід очищати теку /etc/kubernetes/tmp під час процесу скидання.

certificatesDir
string

certificatesDir вказує теку, де зберігаються сертифікати. Якщо вказано, вона буде очищена під час процесу скидання.

criSocket
string

criSocket використовується для отримання інформації про середовище виконання контейнерів для видалення контейнерів. Якщо criSocket не вказано через прапорець або файл конфігурації, kubeadm спробує виявити дійсний CRI сокет.

dryRun
bool

dryRun вказує, чи увімкнено режим перевірки. Якщо так, жодні зміни не застосовуються, а просто виводиться те, що буде зроблено.

force
bool

Флаг force інструктує kubeadm скинути вузол без запиту підтвердження.

ignorePreflightErrors
[]string

ignorePreflightErrors надає список помилок перед стартом, які слід ігнорувати під час процесу скидання, наприклад, IsPrivilegedUser,Swap. Значення all ігнорує помилки з усіх перевірок.

skipPhases
[]string

skipPhases є списком фаз, які потрібно пропустити під час виконання команди. Список фаз можна отримати за допомогою команди kubeadm reset phase --help.

unmountFlags
[]string

unmountFlags — список прапорців syscall unmount2(), які kubeadm може використовувати при розмонтуванні тек під час " reset". Цей прапорець може бути одним з: "MNT_FORCE", "MNT_DETACH", "MNT_EXPIRE", "UMOUNT_NOFOLLOW". Стандартно цей список порожній.

timeouts
Timeouts

timeouts містить різні тайм-аути, які застосовуються до команд kubeadm.

UpgradeConfiguration

UpgradeConfiguration містить список опцій, специфічних для підкоманд kubeadm upgrade.

ПолеОпис
apiVersion
string
kubeadm.k8s.io/v1beta4
kind
string
UpgradeConfiguration
apply
UpgradeApplyConfiguration

apply містить список опцій, специфічних для команди kubeadm upgrade apply.

diff
UpgradeDiffConfiguration

diff містить список опцій, специфічних для команди kubeadm upgrade diff.

node
UpgradeNodeConfiguration

node містить список опцій, специфічних для команди kubeadm upgrade node.

plan
UpgradePlanConfiguration

plan містить список опцій, специфічних для команди kubeadm upgrade plan.

timeouts
Timeouts

timeouts містить різні тайм-аути, які застосовуються до команд kubeadm.

APIEndpoint

Зʼявляється в:

Структура APIEndpoint містить елементи для екземпляра API сервера, розгорнутого на вузлі.

ПолеОпис
advertiseAddress
string

advertiseAddress встановлює IP-адресу, яку API сервер буде оголошувати.

bindPort
int32

bindPort встановлює захищений порт, до якого API сервер буде привʼязаний. Стандартно — 6443.

APIServer

Зʼявляється в:

APIServer містить налаштування, необхідні для розгортання API сервера в кластері.

ПолеОпис
ControlPlaneComponent [Обовʼязкове]
ControlPlaneComponent
(Члени ControlPlaneComponent вбудовані в цей тип.) Опис не надано.
certSANs
[]string

certSANs встановлює додаткові альтернативні імена субʼєкта (SAN) для сертифіката підпису API сервера.

Arg

Зʼявляється в:

Arg представляє собою аргумент з імʼям і значенням.

ПолеОпис
name [Обовʼязкове]
string

Імʼя аргументу.

value [Обовʼязкове]
string

Значення аргументу.

BootstrapTokenDiscovery

Зʼявляється в:

BootstrapTokenDiscovery використовується для налаштування параметрів для виявлення з використанням токенів.

ПолеОпис
token [Обовʼязкове]
string

token є токеном, що використовується для перевірки інформації про кластер, отриманої від панелі управління.

apiServerEndpoint
string

apiServerEndpoint є IP-адресою або доменним імʼям API-сервера, з якого буде отримана інформація.

caCertHashes
[]string

caCertHashes вказує набір публічних ключів, які потрібно перевірити при використанні виявлення на основі токенів. Кореневий CA, знайдений під час виявлення, повинен відповідати одному з цих значень. Вказівка порожнього набору вимикає привʼязку кореневого CA, що може бути небезпечним. Кожен хеш вказується як <type>:<value>, де єдиний підтримуваний тип наразі — "sha256". Це хеш SHA-256 коду обʼєкта Subject Public Key Info (SPKI) у DER-кодованому ASN.1. Ці хеші можна розрахувати за допомогою, наприклад, OpenSSL.

unsafeSkipCAVerification
bool

unsafeSkipCAVerification дозволяє виявлення на основі токенів без перевірки CA через caCertHashes. Це може ослабити безпеку kubeadm, оскільки інші вузли можуть видавати себе за панель управління.

ControlPlaneComponent

Зʼявляється в:

ControlPlaneComponent містить налаштування, загальні для компонентів панелі управління кластера.

ПолеОпис
extraArgs
[]Arg

extraArgs — це додатковий набір прапорців, які передаються компоненту панелі управління. Назва аргументу в цьому списку є назвою прапорця, як вона зʼявляється в командному рядку, але без початковиї дефісів. Додаткові аргументи переважатимуть існуючі стандартні аргументи. Дублікати додаткових аргументів дозволені.

extraVolumes
[]HostPathMount

extraVolumes — це додатковий набір томів хостів, які монтуються до компонента панелі управління.

extraEnvs
[]EnvVar

extraEnvs — це додатковий набір змінних середовища, які передаються компоненту панелі управління. Змінні середовища, передані за допомогою extraEnvs, переважатимуть будь-які існуючі змінні середовища або змінні середовища *_proxy, які kubeadm додає стандартно.

DNS

Зʼявляється в:

DNS визначає аддон DNS, який має бути використаний у кластері.

ПолеОпис
ImageMeta [Обовʼязково]
ImageMeta
(Члени ImageMeta вбудовані в цей тип.)

imageMeta дозволяє налаштувати образ, що використовується для надбудови DNS.

disabled [Обовʼязково]
bool

disabled вказує, чи слід вимкнути цю надбудовув кластері.

Discovery

Зʼявляється в:

Discovery визначає параметри для kubelet під час процесу TLS Bootstrap.

ПолеОпис
bootstrapToken
BootstrapTokenDiscovery

bootstrapToken використовується для налаштування параметрів для виявлення за допомогою токена Bootstrap. bootstrapToken і file є взаємовиключними.

file
FileDiscovery

file використовується для вказівки файлу або URL на kubeconfig файл, з якого завантажується інформація про кластер. bootstrapToken і file є взаємовиключними.

tlsBootstrapToken
string

tlsBootstrapToken є токеном, що використовується для TLS bootstrapping. Якщо bootstrapToken встановлено, це поле стандартно буде дорівнювати bootstrapToken.token, але його можна перевизначити. Якщо file встановлено, це поле повинно бути встановлено, якщо файл KubeConfigFile не містить іншої інформації для автентифікації.

EncryptionAlgorithmType

(Аліас для string)

Зʼявляється в:

EncryptionAlgorithmType може визначити тип асиметричного алгоритму шифрування.

EnvVar

Зʼявляється в:

EnvVar представляє змінну середовища, присутню в контейнері.

ПолеОпис
EnvVar [Обовʼязкове]
core/v1.EnvVar
(Члени EnvVar вбудовані в цей тип.) Опис не надано.

Etcd

Зʼявляється в:

Etcd містить елементи, що описують конфігурацію Etcd.

ПолеОпис
local
LocalEtcd

local надає конфігураційні параметри для налаштування локального екземпляра etcd. local та external є взаємовиключними.

external
ExternalEtcd

external описує, як підключитися до зовнішнього кластеру etcd. local та external є взаємовиключними.

ExternalEtcd

Зʼявляється в:

ExternalEtcd описує зовнішній кластер etcd. Kubeadm не має інформації про те, де знаходяться файли сертифікатів, і їх необхідно надати.

ПолеОпис
endpoints [Обовʼязкове]
[]string

endpoints містить список членів etcd.

caFile [Обовʼязкове]
string

caFile є файлом центру сертифікації (CA) SSL, що використовується для захисту комунікації etcd. Необхідний, якщо використовується зʼєднання TLS.

certFile [Обовʼязкове]
string

certFile є файлом сертифікації SSL, що використовується для захисту комунікації etcd. Необхідний, якщо використовується зʼєднання TLS.

keyFile [Обовʼязкове]
string

keyFile є файлом ключа SSL, що використовується для захисту комунікації etcd. Необхідний, якщо використовується зʼєднання TLS.

FileDiscovery

Зʼявляється в:

FileDiscovery використовується для вказівки файлу або URL на kubeconfig файл, з якого слід завантажити інформацію про кластер.

ПолеОпис
kubeConfigPath [Обовʼязкове]
string

kubeConfigPath використовується для вказівки фактичного шляху до файлу або URL на kubeconfig файл, з якого слід завантажити інформацію про кластер.

HostPathMount

Зʼявляється в:

HostPathMount містить елементи, що описують томи, які монтуються з хоста.

ПолеОпис
name [Обовʼязкове]
string

name — це назва тому всередині шаблону Pod.

hostPath [Обовʼязкове]
string

hostPath — це шлях на хості, який буде змонтований всередині Pod.

mountPath [Обовʼязкове]
string

mountPath — це шлях всередині Pod, де буде змонтований hostPath.

readOnly
bool

readOnly контролює доступ на запис до тому.

pathType
core/v1.HostPathType

pathType — це тип hostPath.

ImageMeta

Зʼявляється в:

ImageMeta дозволяє налаштувати образ, що використовується для компонентів, які не походять з процесу релізу Kubernetes/Kubernetes.

ПолеОпис
imageRepository
string

imageRepository визначає реєстр контейнерів, з якого потрібно завантажити образи. Якщо не вказано, буде використано imageRepository, визначений в ClusterConfiguration.

imageTag
string

imageTag дозволяє вказати тег для образу. У випадку, якщо це значення вказане, kubeadm не змінює автоматично версію вищезазначених компонентів під час оновлень.

JoinControlPlane

Зʼявляється в:

JoinControlPlane містить елементи, що описують додатковий екземпляр контрольної плити, який має бути розгорнуто на приєднуючому вузлі.

ПолеОпис
localAPIEndpoint
APIEndpoint

localAPIEndpoint представляє точку доступу екземпляра API сервера, яка має бути розгорнута на цьому вузлі.

certificateKey
string

certificateKey є ключем, що використовується для розшифрування сертифікатів після їх завантаження з Secret при приєднанні нового вузла панелі управління. Відповідний ключ шифрування знаходиться в InitConfiguration. Ключ сертифіката є рядком у шістнадцятковому кодуванні, який є AES ключем розміром 32 байти.

LocalEtcd

Зʼявляється в:

LocalEtcd описує, що kubeadm має запустити кластер etcd локально.

ПолеОпис
ImageMeta [Обовʼязково]
ImageMeta
(Члени ImageMeta вбудовані в цей тип.)

ImageMeta дозволяє налаштувати контейнер, що використовується для etcd.

dataDir [Обовʼязково]
string

dataDir є текою, в якій etcd розміщуватиме свої дані. Стандартно це "/var/lib/etcd".

extraArgs [Обовʼязково]
[]Arg

extraArgs є додатковими аргументами, що передаються бінарному файлу etcd при його запуску всередині статичного Pod. Назва аргументу в цьому списку є іменем прапорця, як вона зʼявляється в командному рядку, за винятком тире на початку. Додаткові аргументи переважатимуть існуючі стандартні аргументи. Дублювання додаткових аргументів дозволяється.

extraEnvs
[]EnvVar

extraEnvs є додатковим набором змінних середовища для передачі компоненту панелі управління. Змінні середовища, передані за допомогою extraEnvs, перезаписуватимуть будь-які існуючі змінні середовища або змінні середовища *_proxy, які kubeadm додає стандартно.

serverCertSANs
[]string

serverCertSANs встановлює додаткові Subject Alternative Names (SANs) для сертифіката підпису сервера etcd.

peerCertSANs
[]string

peerCertSANs встановлює додаткові Subject Alternative Names (SANs) для сертифіката підпису peer etcd.

Networking

Зʼявляється в:

Networking містить елементи, що описують конфігурацію мережі кластера.

ПолеОпис
serviceSubnet
string

serviceSubnet є підмережею, що використовується сервісами Kubernetes. Стандартно це "10.96.0.0/12".

podSubnet
string

podSubnet є підмережею, що використовується Pod.

dnsDomain
string

dnsDomain є доменом DNS, що використовується сервісами Kubernetes. Стандартно це "cluster.local".

NodeRegistrationOptions

Зʼявляється в:

NodeRegistrationOptions містить поля, що стосуються реєстрації новоїпанелі управління або вузла в кластері, або через kubeadm init, або kubeadm join.

ПолеОпис
name
string

name є полем .Metadata.Name обʼєкта Node API, який буде створений в операціях kubeadm init або kubeadm join. Це поле також використовується в полі CommonName клієнтського сертифіката kubelet для API сервера. Стандартно використовується імʼя хосту вузла, якщо не задано.

criSocket
string

criSocket використовується для отримання інформації про середовище виконання контейнерів. Ця інформація буде анотована до обʼєкта Node API для подальшого використання.

taints [Обовʼязкове]
[]core/v1.Taint

taints

taints вказує на taints, з якими обʼєкт Node API повинен бути зареєстрований. Якщо це поле не встановлено, тобто nil, воно буде стандартно з control-plane taint для вузлів control-plane. Якщо ви не хочете taint для вашого вузла control-plane, встановіть в це поле порожній список, тобто taints: [] у YAML файлі. Це поле використовується виключно для реєстрації вузлів.

kubeletExtraArgs
[]Arg

kubeletExtraArgs передає додаткові аргументи до kubelet. Аргументи тут передаються командному рядку kubelet через файл середовища, який kubeadm записує під час виконання для джерела kubelet. Це переважає загальну базову конфігурацію у ConfigMap kubelet-config. Прапорці мають вищий пріоритет при розборі. Ці значення є локальними і специфічними для вузла, на якому виконується kubeadm. Назва аргументу в цьому списку є назвою прапорця, як вона зʼявляється в командному рядку, крім дефісів на початку. Додаткові аргументи переважають існуючі стандартні значення. Дублікати додаткових аргументів дозволені.

ignorePreflightErrors
[]string

ignorePreflightErrors надає масив помилок перед польотом, які слід ігнорувати при реєстрації поточного вузла, наприклад, 'IsPrivilegedUser,Swap'. Значення 'all' ігнорує помилки з усіх перевірок.

imagePullPolicy
core/v1.PullPolicy

imagePullPolicy вказує політику витягування образів під час kubeadm init та join операцій. Значення цього поля має бути одне з "Always", "IfNotPresent" або "Never". Якщо це поле не задане, kubeadm стандартно встановить його в "IfNotPresent", або витягне необхідні образи, якщо вони не присутні на хості.

imagePullSerial
bool

imagePullSerial вказує, чи витягування образів, яке виконує kubeadm, має відбуватися послідовно або паралельно. Стандартно: true

Patches

Зʼявляється в:

Patches містить опції, повʼязані із застосуванням патчів до компонентів, розгорнутих kubeadm.

ПолеОпис
directory
string

directory є шляхом до теки, що містить файли, названі "target[suffix][+patchtype].extension". Наприклад, "kube-apiserver0+merge.yaml" або просто "etcd.json". "target" може бути одним з "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd", "kubeletconfiguration", "corednsdeployment". "patchtype" може бути одним з "strategic", "merge" або "json" і відповідає форматам патчів, підтримуваним kubectl. Стандартно "patchtype" є "strategic". "extension" має бути або "json", або "yaml". "suffix" є необовʼязковим рядком, який можна використовувати для визначення порядку застосування патчів за алфавітним порядком.

Proxy

Зʼявляється в:

Proxy визначає надбудову проксі, яка має використовуватися в кластері.

ПолеОпис
disabled [Обовʼязкове]
bool

disabled визначає, чи слід вимкнути цю надбудову у кластері.

Timeouts

Зʼявляється в:

Timeouts містить різні тайм-аути, які застосовуються до команд kubeadm.

ПолеОпис
controlPlaneComponentHealthCheck
meta/v1.Duration

controlPlaneComponentHealthCheck є часом очікування для перевірки справності компонентів панелі управління, таких як API сервер, під час kubeadm init та kubeadm join. Стандартно — 4м

kubeletHealthCheck
meta/v1.Duration

kubeletHealthCheck є часом очікування для перевірки здоровʼя kubelet під час kubeadm init та kubeadm join. Стандартно — 4м

kubernetesAPICall
meta/v1.Duration

kubernetesAPICall є часом очікування для завершення запиту клієнта kubeadm до API сервера. Це застосовується до всіх типів методів (GET, POST тощо). Стандартно — 1м

etcdAPICall
meta/v1.Duration

etcdAPICall є часом очікування для завершення запиту клієнта kubeadm до кластера etcd. Стандартно — 2м

tlsBootstrap
meta/v1.Duration

tlsBootstrap є часом очікування для завершення TLS bootstrap для приєднуючого вузла. Стандартно — 5м

discovery
meta/v1.Duration

discovery є часом очікування для перевірки ідентичності API сервера для приєднуючого вузла. Стандартно — 5м

upgradeManifests [Обовʼязкове]
meta/v1.Duration

upgradeManifests є тайм-аутом для оновлення статичних манифестів Pod. Стандартно — 5м

UpgradeApplyConfiguration

Зʼявляється в:

UpgradeApplyConfiguration містить список параметрів конфігурації, які специфічні для команди kubeadm upgrade apply.

ПолеОпис
kubernetesVersion
string

kubernetesVersion є цільовою версією панелі управління.

allowExperimentalUpgrades
bool

allowExperimentalUpgrades інструктує kubeadm показувати нестабільні версії Kubernetes як альтернативу оновленню та дозволяє оновлення до альфа/бета/версії-кандидата Kubernetes. Стандартно — false

allowRCUpgrades
bool

Увімкнення allowRCUpgrades покаже версії-кандидати релізів Kubernetes як альтернативу оновленню та дозволяє оновлення до версії-кандидата Kubernetes.

certificateRenewal
bool

certificateRenewal інструктує kubeadm виконати поновлення сертифікатів під час оновлень. Стандартно — true

dryRun
bool

dryRun вказує, чи увімкнено режим перевірки без змін, не застосовувати жодних змін, а лише виводити те, що буде зроблено.

etcdUpgrade
bool

etcdUpgrade інструктує kubeadm виконати оновлення etcd під час оновлень. Стандартно — true

forceUpgrade
bool

forceUpgrade вказує kubeadm оновити кластер без запиту підтвердження.

ignorePreflightErrors
[]string

ignorePreflightErrors надає список помилок перевірки перед виконанням, які слід ігнорувати під час процесу оновлення, наприклад, IsPrivilegedUser,Swap. Значення all ігнорує помилки з усіх перевірок.

patches
Patches

patches містить параметри, повʼязані із застосуванням патчів до компонентів, розгорнутих kubeadm під час kubeadm upgrade.

printConfig
bool

printConfig вказує, чи слід вивести конфігураційний файл, який буде використаний в оновленні.

skipPhases [Обовʼязкове]
[]string

SkipPhases є списком фаз, які слід пропустити під час виконання команди. ПРИМІТКА: Це поле наразі ігнорується для kubeadm upgrade apply, але в майбутньому буде підтримуватися.

imagePullPolicy
core/v1.PullPolicy

imagePullPolicy визначає політику витягування образів під час операцій kubeadm upgrade apply. Значення цього поля має бути одним з "Always", "IfNotPresent" або "Never". Якщо це поле не встановлено, kubeadm автоматично встановить значення "IfNotPresent", або витягне потрібні образи, якщо їх немає на хості.

imagePullSerial
bool

imagePullSerial вказує, чи витягування образів, яке виконує kubeadm, має відбуватися послідовно або паралельно. Стандартно: true

UpgradeDiffConfiguration

Зʼявляється в:

UpgradeDiffConfiguration містить список параметрів конфігурації, які специфічні для команди kubeadm upgrade diff.

ПолеОпис
kubernetesVersion
string

kubernetesVersion є цільовою версією панелі управління.

contextLines
int

diffContextLines є кількістю рядків контексту в diff.

UpgradeNodeConfiguration

Зʼявляється в:

UpgradeNodeConfiguration містить список параметрів конфігурації, які специфічні для команди "kubeadm upgrade node".

ПолеОпис
certificateRenewal
bool

certificateRenewal інструктує kubeadm виконати поновлення сертифікатів під час оновлень. Стандартно — true.

dryRun
bool

dryRun вказує, чи увімкнено режим попереднього перегляду. Якщо так, зміни не будуть застосовані, а буде виведено тільки те, що було б зроблено.

etcdUpgrade
bool

etcdUpgrade інструктує kubeadm виконати оновлення etcd під час оновлень. Стандартно — true.

ignorePreflightErrors
[]string

ignorePreflightErrors надає список помилок попередньої перевірки, які слід ігнорувати під час процесу оновлення, наприклад, 'IsPrivilegedUser,Swap'. Значення 'all' ігнорує помилки з усіх перевірок.

skipPhases
[]string

skipPhases є списком фаз, які слід пропустити під час виконання команди. Список фаз можна отримати за допомогою команди kubeadm upgrade node phase --help.

patches
Patches

patches містить параметри, повʼязані із застосуванням патчів до компонентів, розгорнутих за допомогою kubeadm під час kubeadm upgrade.

imagePullPolicy
core/v1.PullPolicy

imagePullPolicy визначає політику витягування образів під час операцій kubeadm upgrade node. Значенням цього поля має бути одне з "Always", "IfNotPresent" або "Never". Якщо це поле не встановлено, kubeadm автоматично встановить значення "IfNotPresent", або витягне потрібні образи, якщо їх немає на хості.

imagePullSerial
bool

imagePullSerial вказує, чи витягування образів, яке виконує kubeadm, має відбуватися послідовно або паралельно. Стандартно: true

UpgradePlanConfiguration

Зʼявляється в:

UpgradePlanConfiguration містить список параметрів конфігурації, які специфічні для команди "kubeadm upgrade plan".

ПолеОпис
kubernetesVersion [Обовʼязкове]
string

kubernetesVersion є цільовою версією панелі управління.

allowExperimentalUpgrades
bool

allowExperimentalUpgrades інструктує kubeadm показувати нестабільні версії Kubernetes як альтернативу для оновлення і дозволяє оновлювати до альфа/бета/реліз кандидата версій Kubernetes. Стандартно — false

allowRCUpgrades
bool

Увімкнення allowRCUpgrades показуватиме версії-кандидати релізу Kubernetes як альтернативу для оновлення та дозволить оновлення до версії кандидата релізу Kubernetes.

dryRun
bool

dryRun вказує, чи увімкнено режим попереднього перегляду. Якщо так, зміни не будуть застосовані, а буде виведено тільки те, що було б зроблено.

ignorePreflightErrors
[]string

ignorePreflightErrors надає список помилок попередньої перевірки, які слід ігнорувати під час процесу оновлення, наприклад, 'IsPrivilegedUser,Swap'. Значення 'all' ігнорує помилки з усіх перевірок.

printConfig
bool

printConfig вказує, чи слід виводити конфігураційний файл, який буде використовуватися в процесі оновлення.

6.14.15 - kubeconfig (v1)

Типи ресурсів

Config

Config містить інформацію, необхідну для підключення до віддалених кластерів Kubernetes як вказаний користувач

ПолеОпис
apiVersion
string
/v1
kind
string
Config
kind
string

Спадкове поле з pkg/api/types.go TypeMeta. TODO(jlowdermilk): видалити його після усунення залежностей з низхідних напрямків.

apiVersion
string

Спадкове поле з pkg/api/types.go TypeMeta. TODO(jlowdermilk): видалити його після усунення залежностей з низхідних напрямків.

preferences [Обовʼязкове]
Preferences

Preferences містить загальну інформацію для використання у взаємодії з CLI

clusters [Обовʼязкове]
[]NamedCluster

Clusters — це map імен, на які можна посилатися в конфігураціях кластерів

users [Обовʼязкове]
[]NamedAuthInfo

AuthInfos — це map імен, на які можна посилатися в конфігураціях користувача

contexts [Обовʼязкове]
[]NamedContext

Контексти — це map імен, на які можна посилатися, до конфігурацій контекстів

current-context [Обовʼязкове]
string

CurrentContext — це імʼя контексту, який ви хочете використовувати стандартно

extensions
[]NamedExtension

Extensions містить додаткову інформацію. Це корисно для розширювачів, щоб читання та запис не знищували невідомі поля

AuthInfo

Зʼявляється в:

AuthInfo містить інформацію, яка описує ідентифікаційні дані. Це використовується для інформування кластера Kubernetes, хто ви є.

ПолеОпис
client-certificate
string

ClientCertificate — це шлях до файлу клієнтського сертифіката для TLS.

client-certificate-data
[]byte

ClientCertificateData містить дані в кодуванні PEM з файлу клієнтського сертифіката для TLS. Перезаписує ClientCertificate.

client-key
string

ClientKey — це шлях до файлу клієнтського ключа для TLS.

client-key-data
[]byte

ClientKeyData містить дані в кодуванні PEM з файлу клієнтського ключа для TLS. Перезаписує ClientKey.

token
string

Token — це токен, що підтверджує право на доступ до кластера Kubernetes.

tokenFile
string

TokenFile — це вказівка на файл, який містить токен (як описано вище). Якщо присутні як Token, так і TokenFile, перевага надається Token.

as
string

Impersonate — імʼя користувача, від імені якого потрібно діяти. Імʼя збігається з прапорцем.

as-uid
string

ImpersonateUID — це UID, від імені якого потрібно діяти.

as-groups
[]string

ImpersonateGroups — це групи, від імені якої потрібно діяти.

as-user-extra
map[string][]string

ImpersonateUserExtra містить додаткову інформацію для користувача, від імені якого потрібно діяти.

username
string

Username — це імʼя користувача для базової автентифікації в кластері Kubernetes.

password
string

Password — це пароль для базової автентифікації в кластері Kubernetes.

auth-provider
AuthProviderConfig

AuthProvider вказує на власний втулок автентифікації для кластера Kubernetes.

exec
ExecConfig

Exec вказує на власний втулок автентифікації на основі виконання для кластера Kubernetes.

extensions
[]NamedExtension

Extensions містить додаткову інформацію. Це корисно для розширювачів, щоб читання та запис не знищували невідомі поля.

AuthProviderConfig

Зʼявляється в:

AuthProviderConfig містить конфігурацію для вказаного провайдера автентифікації.

ПолеОпис
name [Обовʼязково]
string
Опис не надано.
config [Обовʼязково]
map[string]string
Опис не надано.

Cluster

Зʼявляється в:

Cluster містить інформацію про те, як спілкуватися з кластером Kubernetes.

ПолеОпис
server [Обовʼязково]
string

Server — це адреса кластера Kubernetes (https://hostname:port).

tls-server-name
string

TLSServerName використовується для перевірки сертифіката сервера. Якщо TLSServerName порожній, використовується імʼя хоста, щоб звʼязатися з сервером.

insecure-skip-tls-verify
bool

InsecureSkipTLSVerify пропускає перевірку дійсності сертифіката сервера. Це зробить ваші HTTPS-зʼєднання небезпечними.

certificate-authority
string

CertificateAuthority - це шлях до файлу сертифіката для сертифікаційного центру.

certificate-authority-data
[]byte

CertificateAuthorityData містить PEM-кодовані сертифікати сертифікаційного центру. Перекриває CertificateAuthority.

proxy-url
string

ProxyURL — це URL-адреса проксі, яка буде використовуватися для всіх запитів, здійснюваних цим клієнтом. Підтримуються URL-адреси зі схемами "http", "https" та "socks5". Якщо ця конфігурація не надана або порожній рядок, клієнт спробує створити конфігурацію проксі з змінних середовища http_proxy та https_proxy. Якщо ці змінні середовища не встановлені, клієнт не спробує проксіювати запити.

Проксіювання socks5 наразі не підтримує точки доступу потокової передачі spdy (exec, attach, port forward).

disable-compression
bool

DisableCompression дозволяє клієнту відмовитися від стиснення відповіді для всіх запитів до сервера. Це корисно для прискорення запитів (зокрема списків), коли пропускна здатність мережі між клієнтом і сервером достатня, заощаджуючи час на стисненні (на стороні сервера) та розпакуванні (на стороні клієнта): https://github.com/kubernetes/kubernetes/issues/112296.

extensions
[]NamedExtension

Extensions містить додаткову інформацію. Це корисно для розширювачів, щоб читання і запис не пошкоджували невідомі поля

Context

Зʼявляється в:

Context — це набір посилань на кластер (як спілкуватись з кластером Kubernetes), користувача (як користувач ідентифікує себе) і простір імен (з якою підмножиною ресурсів стандартно працювати)

ПолеОпис
cluster [Обовʼязково]
string

Cluster —це імʼя кластера для цього контексту

user [Обовʼязково]
string

AuthInfo — це імʼя authInfo для цього контексту

namespace
string

Namespace — це стандартний простір імен, який використовується для запитів, де простір імен не вказаний

extensions
[]NamedExtension

Extensions містить додаткову інформацію. Це корисно для розширювачів, щоб читання і запис не пошкоджували невідомі поля

ExecConfig

Зʼявляється в:

ExecConfig визначає команду для надання клієнтських облікових даних. Команда виконується і виводить структурований stdout, що містить облікові дані.

Дивіться групу API client.authentication.k8s.io для специфікацій точного формату вводу та виводу.

ПолеОпис
command [Обовʼязково]
string

Команда для виконання.

args
[]string

Аргументи для передачі команді під час її виконання.

env
[]ExecEnvVar

Env визначає додаткові змінні середовища для експонування процесу. Вони обʼєднуються з середовищем хосту, а також зі змінними, які client-go використовує для передачі аргументів втулку.

apiVersion [Обовʼязково]
string

Бажана версія введення ExecInfo. Повернені ExecCredentials МАЮТЬ використовувати те ж саме кодування версії, що й ввод.

installHint [Обовʼязково]
string

Цей текст показується користувачеві, коли виконуваний файл здається відсутнім. Наприклад, brew install foo-cli може бути гарною підказкою для встановлення foo-cli на системах Mac OS.

provideClusterInfo [Обовʼязково]
bool

ProvideClusterInfo визначає, чи слід надавати інформацію про кластер, яка може потенційно містити дуже великі дані CA, цьому exec втулку як частину змінної середовища KUBERNETES_EXEC_INFO. Стандартно встановлено на false. Пакет k8s.io/client-go/tools/auth/exec надає допоміжні методи для отримання цієї змінної середовища.

interactiveMode
ExecInteractiveMode

InteractiveMode визначає звʼязки цього втулку зі стандартним вводом. Дійсні значення: "Never" (цей exec втулок ніколи не використовує стандартний ввод), "IfAvailable" (цей exec втулок хоче використовувати стандартний ввод, якщо він доступний) або "Always" (цей exec втулок вимагає стандартний ввод для функціонування). Див. значення ExecInteractiveMode для більш детальної інформації.

Якщо APIVersion — client.authentication.k8s.io/v1alpha1 або client.authentication.k8s.io/v1beta1, то це поле є необовʼязковим і стандартно встановлено у "IfAvailable" при відсутності значення. В іншому випадку це поле є обовʼязковим.

ExecEnvVar

Зʼявляється в:

ExecEnvVar використовується для налаштування змінних середовища під час виконання втулка облікових даних на основі exec.

ПолеОпис
name [Обовʼязково]
string
Опис не надано.
value [Обовʼязково]
string
Опис не надано.

ExecInteractiveMode

(Аліас для string)

Зʼявляється в:

ExecInteractiveMode є рядком, який описує взаємодію exec втулка зі стандартним вводом.

NamedAuthInfo

Зʼявляється в:

NamedAuthInfo повʼязує псевдоніми з інформацією для автентифікації.

ПолеОпис
name [Обовʼязкове]
string

Назва є псевдонімом для цієї AuthInfo

user [Обовʼязкове]
AuthInfo

AuthInfo містить інформацію для автентифікації

NamedCluster

Зʼявляється в:

NamedCluster повʼязує псевдоніми з інформацією про кластер.

ПолеОпис
name [Обовʼязкове]
string

Назва є псевдонімом для цього кластера

cluster [Обовʼязкове]
Cluster

Cluster містить інформацію про кластер

NamedContext

Зʼявляється в:

NamedContext повʼязує псевдоніми з інформацією про контекст

ПолеОпис
name [Обовʼязкове]
string

Назва є псевдонімом для цього контексту

context [Обовʼязкове]
Context

Context містить інформацію про контекст

NamedExtension

Зʼявляється в:

NamedExtension повʼязує псевдоніми з інформацією про розширення

ПолеОпис
name [Обовʼязкове]
string

Назва є псевдонімом для цього розширення

extension [Обовʼязкове]
k8s.io/apimachinery/pkg/runtime.RawExtension

Extension містить інформацію про розширення

Preferences

Зʼявляється в:

ПолеОпис
colors
bool
Опис не надано.
extensions
[]NamedExtension

Extensions містить додаткову інформацію. Це корисно для розширювачів, щоб читання і запис не пошкоджували невідомі поля

6.14.16 - Kubelet Configuration (v1)

Типы ресурсов

CredentialProviderConfig

CredentialProviderConfig є конфігурацією, що містить інформацію про кожного exec credential provider. Kubelet читає цю конфігурацію з диска та активує кожного провайдера відповідно до типу CredentialProvider.

ПолеОпис
apiVersion
string
kubelet.config.k8s.io/v1
kind
string
CredentialProviderConfig
providers [Обовʼязково]
[]CredentialProvider

providers є списком втулків провайдерів облікових даних, які будуть активовані kubelet. Кілька провайдерів можуть відповідати одному образу, в такому випадку облікові дані з усіх провайдерів будуть повернуті kubelet. Якщо кілька провайдерів викликаються для одного образу, результати обʼєднуються. Якщо провайдери повертають перекриваючі ключі автентифікації, використовується значення з провайдера, що знаходиться раніше в цьому списку.

CredentialProvider

Зʼявляється в:

CredentialProvider представляє exec втулок, який буде викликаний kubelet. Втулок викликається лише тоді, коли образ, що завантажується, відповідає образам, які обробляє втулок (див. matchImages).

ПолеОпис
name [Обовʼязково]
string

name є обовʼязковим імʼям провайдера облікових даних. Назва повинна відповідати імені виконуваного файлу провайдера, яке бачить kubelet. Виконуваний файл повинен бути в директорії bin kubelet (встановленій за допомогою прапорця --image-credential-provider-bin-dir).

matchImages [Обовʼязково]
[]string

matchImages є обовʼязковим списком рядків, які використовуються для зіставлення з образами, щоб визначити, чи потрібно викликати цього провайдера. Якщо один з рядків відповідає запитаному образу від kubelet, втулок буде викликаний і отримає можливість надати облікові дані. Образи повинні містити домен реєстрації та URL шлях.

Кожен запис у matchImages є шаблоном, який може містити порт і шлях. Глоби можна використовувати в домені, але не в порті чи шляху. Глоби підтримуються як піддомени, наприклад '*.k8s.io' або 'k8s.*.io', та топ-рівневі домени, такі як 'k8s.*'. Підмножки часткових піддоменів, такі як 'app*.k8s.io', також підтримуються. Кожен глоб може відповідати тільки одному сегменту піддомену, тому '*.io' не відповідає '*.k8s.io'.

Зіставлення існує між образом і matchImage, коли всі з нижченаведених умов є істинними:

  • Обидва містять однакову кількість частин домену, і кожна частина має збіг.
  • URL шлях образу має бути префіксом цільового URL шляху образу.
  • Якщо imageMatch містить порт, порт також повинен мати збіг в образі.

Приклади значень matchImages:

  • 123456789.dkr.ecr.us-east-1.amazonaws.com
  • *.azurecr.io
  • gcr.io
  • *.*.registry.io
  • registry.io:8080/path
defaultCacheDuration [Обовʼязково]
meta/v1.Duration

defaultCacheDuration є стандартною тривалістю, впродовж якої втулок кешуватиме облікові дані в памʼяті, якщо тривалість кешу не надана у відповіді втулка. Це поле є обовʼязковим.

apiVersion [Обовʼязково]
string

Обовʼязкова версія вхідного exec CredentialProviderRequest. Повернута CredentialProviderResponse МУСИТЬ використовувати таку ж версію кодування, як і вхідна. Поточні підтримувані значення:

  • credentialprovider.kubelet.k8s.io/v1
args
[]string

Аргументи для передачі команді при її виконанні.

env
[]ExecEnvVar

Env визначає додаткові змінні середовища для передачі процесу. Вони обʼєднуються з середовищем хоста, а також змінними, які client-go використовує для передачі аргументів втулку.

ExecEnvVar

Зʼявляється в:

ExecEnvVar використовується для встановлення змінних середовища при виконанні втулка для облікових даних на основі exec.

ПолеОпис
name [Обовʼязково]
string
Опис не надано.
value [Обовʼязково]
string
Опис не надано.

6.14.17 - Kubelet Configuration (v1alpha1)

Типи ресурсів

CredentialProviderConfig

CredentialProviderConfig є конфігурацією, що містить інформацію про кожен втулок облікових даних exec. Kubelet читає цю конфігурацію з диска та активує кожен втулок відповідно до типу CredentialProvider.

ПолеОпис
apiVersion
string
kubelet.config.k8s.io/v1alpha1
kind
string
CredentialProviderConfig
providers [Обовʼязково]
[]CredentialProvider

providers є списком втулків провайдерів облікових даних, які будуть активовані kubelet. Кілька провайдерів можуть відповідати одному образу, в такому випадку облікові дані з усіх провайдерів будуть повернуті kubelet. Якщо кілька провайдерів викликаються для одного образу, результати обʼєднуються. Якщо провайдери повертають перекриваючі ключі автентифікації, використовується значення з провайдера, що знаходиться раніше в цьому списку.

CredentialProvider

Зʼявляється в:

CredentialProvider представляє втулок exec, який буде викликаний kubelet. Втулок буде викликаний тільки тоді, коли образ, який завантажується, відповідає образам, які підтримуються втулком (див. matchImages).

ПолеОпис
name [Обовʼязково]
string

name є обовʼязковою назвою постачальника облікових даних. Назва повинна відповідати назві виконуваного файлу постачальника, як його бачить kubelet. Виконуваний файл повинен знаходитися в теці bin kubelet (встановленій за допомогою прапорця --image-credential-provider-bin-dir).

matchImages [Обовʼязково]
[]string

matchImages є обовʼязковим списком рядків, які використовуються для зіставлення з образами, щоб визначити, чи потрібно викликати цього провайдера. Якщо один з рядків відповідає запитаному образу від kubelet, втулок буде викликаний і отримає можливість надати облікові дані. Образи повинні містити домен реєстрації та URL шлях.

Кожен запис у matchImages є шаблоном, який може містити порт і шлях. Глоби можуть використовуватися в домені, але не в порту чи шляху. Глоби підтримуються як піддомени, такі як *.k8s.io або k8s.*.io, і домени верхнього рівня, такі як k8s.*. Піддомени з частковими збігами, такі як app*.k8s.io, також підтримуються. Кожен шаблон може відповідати лише одному сегменту піддомена, тому *.io не відповідає *.k8s.io.

Відповідність існує між образами і matchImage, коли все з наведеного нижче є істинними:

  • Обидва містять однакову кількість частин домену, і кожна частина має збіг.
  • Шлях URL образу matchImage повинен бути префіксом шляху URL цільового образу.
  • Якщо imageMatch містить порт, порт також повинен мати збіг в образі.

Приклади значень matchImages:

  • 123456789.dkr.ecr.us-east-1.amazonaws.com
  • *.azurecr.io
  • gcr.io
  • *.*.registry.io
  • registry.io:8080/path
defaultCacheDuration [Обовʼязково]
meta/v1.Duration

defaultCacheDuration є стандартною тривалістю, впродовж якої втулок кешуватиме облікові дані в памʼяті, якщо тривалість кешу не надана у відповіді втулка. Це поле є обовʼязковим.

apiVersion [Обовʼязково]
string

Обовʼязкова версія вхідного exec CredentialProviderRequest. Повернута CredentialProviderResponse МУСИТЬ використовувати таку ж версію кодування, як і вхідна. Поточні підтримувані значення:

  • credentialprovider.kubelet.k8s.io/v1alpha1
args
[]string

Аргументи, які слід передати команді при її виконанні.

env
[]ExecEnvVar

Env визначає додаткові змінні середовища, які слід надати процесу. Вони обʼєднуються з середовищем хоста, а також з змінними, які використовує client-go для передачі аргументів втулку.

ExecEnvVar

Зʼявляється в:

ExecEnvVar використовується для встановлення змінних середовища при виконанні втулка облікових даних на основі exec.

ПолеОпис
name [Обовʼязково]
string
Опис не надано.
value [Обовʼязково]
string
Опис не надано.

6.14.18 - Kubelet Configuration (v1beta1)

Типи ресурсів

FormatOptions

Зʼявляється в:

FormatOptions містить параметри для різних форматів логування.

ПолеОпис
text [Обовʼязково]
TextOptions

[Alpha] Text містить параметри для формату логування "text". Доступно лише при увімкненій функціональній можливості LoggingAlphaOptions.

json [Обовʼязково]
JSONOptions

[Alpha] JSON містить параметри для формату журналювання "json". Доступно лише при увімкненій функціональній можливості LoggingAlphaOptions.

JSONOptions

Зʼявляється в:

JSONOptions містить параметри для формату логування "json".

ПолеОпис
OutputRoutingOptions [Обовʼязково]
OutputRoutingOptions
(Члени OutputRoutingOptions вбудовані в цей тип.) Опис не надано.

LogFormatFactory

LogFormatFactory забезпечує підтримку певного додаткового формату логу, який не є стандартним.

LoggingConfiguration

Зʼявляється в:

LoggingConfiguration містить параметри для логування.

ПолеОпис
format [Обовʼязково]
string

Format Flag визначає структуру повідомлень логу. Станадртне значення для формату — text

flushFrequency [Обовʼязково]
TimeOrMetaDuration

Максимальний час між очищенням логів. Якщо рядок, розбирається як тривалість (наприклад, "1s"). Якщо ціле число, максимальна кількість наносекунд (наприклад, 1с = 1000000000). Ігнорується, якщо обраний механізм логування записує повідомлення без буферизації.

verbosity [Обовʼязково]
VerbosityLevel

Verbosity є порогом, який визначає, які повідомлення логу записуються. Стандартне значення — нуль, що записує лише найбільш важливі повідомлення. Більші значення дозволяють додаткові повідомлення. Повідомлення про помилки завжди записуються.

vmodule [Обовʼязково]
VModuleConfiguration

VModule переозначає поріг детальності для окремих файлів. Підтримується тільки для формату логу "text".

options [Обовʼязково]
FormatOptions

[Alpha] Options містить додаткові параметри, специфічні для різних форматів логування. Використовуються лише параметри для обраного формату, але всі вони перевіряються. Доступно тільки при увімкненій функціональній можливості LoggingAlphaOptions.

LoggingOptions

LoggingOptions можна використовувати з ValidateAndApplyWithOptions для перевизначення деяких глобальних стандартних значень.

ПолеОпис
ErrorStream [Обовʼязково]
io.Writer

ErrorStream можна використовувати для перевизначення стандартного значення os.Stderr.

InfoStream [Обовʼязково]
io.Writer

InfoStream можна використовувати для перевизначення стандартного значення os.Stdout.

OutputRoutingOptions

Зʼявляється в:

OutputRoutingOptions містить параметри, що підтримуються як для формату "text", так і для "json".

ПолеОпис
splitStream [Обовʼязково]
bool

[Alpha] SplitStream перенаправляє повідомлення про помилки на stderr, тоді як інформаційні повідомлення відправляються на stdout з буферизацією. Стандартне значення — записувати обидва потоки у stdout без буферизації. Доступно тільки коли увімкнено функціональну можливість LoggingAlphaOptions.

infoBufferSize [Обовʼязково]
k8s.io/apimachinery/pkg/api/resource.QuantityValue

[Alpha] InfoBufferSize встановлює розмір інформаційного потоку при використанні розділених потоків. Стандартне значення — нуль, що вимикає буферизацію. Доступно тільки коли увімкнено функціональну можливість LoggingAlphaOptions.

TextOptions

Зʼявляється в:

TextOptions містить параметри для формату логування "text".

ПолеОпис
OutputRoutingOptions [Обовʼязково]
OutputRoutingOptions
(Члени OutputRoutingOptions вбудовані в цей тип.) Опис не надано.

TimeOrMetaDuration

Зʼявляється в:

TimeOrMetaDuration присутній лише для зворотної сумісності з полем flushFrequency, і нові поля повинні використовувати metav1.Duration.

ПолеОпис
Duration [Обовʼязково]
meta/v1.Duration

Duration містить тривалість

- [Обовʼязково]
bool

SerializeAsString контролює, чи буде значення серіалізоване як рядок чи ціле число

TracingConfiguration

Зʼявляється в:

TracingConfiguration надає версіоновану конфігурацію для клієнтів OpenTelemetry tracing.

ПолеОпис
endpoint
string

Endpoint колектора, до якого цей компонент буде відправляти трасування. Зʼєднання не є захищеним і наразі не підтримує TLS. Рекомендується не задавати, і endpoint буде за замовчуванням otlp grpc, localhost:4317.

samplingRatePerMillion
int32

SamplingRatePerMillion — кількість зразків для збору на мільйон спанів. Рекомендується не задавати. Якщо не задано, пробник поважає темп рідного спану, але в іншому випадку ніколи не здійснює пробу.

VModuleConfiguration

(Аліас для []k8s.io/component-base/logs/api/v1.VModuleItem)

Зʼявляється в:

VModuleConfiguration — це колекція окремих імен файлів або шаблонів та відповідний поріг докладності.

VerbosityLevel

(Аліас для uint32)

Зʼявляється в:

VerbosityLevel представляє поріг докладності для klog або logr.

CredentialProviderConfig

CredentialProviderConfig — це конфігурація, яка містить інформацію про кожного постачальника облікових даних exec. Kubelet зчитує цю конфігурацію з диска та активує кожного постачальника, як зазначено в типі CredentialProvider.

ПолеОпис
apiVersion
string
kubelet.config.k8s.io/v1beta1
kind
string
CredentialProviderConfig
providers [Обовʼязково]
[]CredentialProvider

providers — це список втулків постачальників облікових даних, які будуть активовані kubelet. Кілька постачальників можуть відповідати одному образу, у такому випадку облікові дані від усіх постачальників будуть повернуті kubelet. Якщо кілька постачальників викликаються для одного образуу, результати обʼєднуються. Якщо постачальники повертають перекриваючі ключі автентифікації, використовується значення від постачальника, який знаходиться раніше в цьому списку.

KubeletConfiguration

KubeletConfiguration містить конфігурацію для Kubelet.

ПолеОпис
apiVersion
string
kubelet.config.k8s.io/v1beta1
kind
string
KubeletConfiguration
enableServer [Обовʼязково]
bool

enableServer вмикає захищений сервер Kubelet. Примітка: незахищений порт Kubelet контролюється параметром readOnlyPort. Стандартне значення: true

staticPodPath
string

staticPodPath — це шлях до теки з локальними (статичними) Podʼами для запуску, або шлях до окремого статичного файлу Podʼа. Стандартно: ""

podLogsDir
string

podLogsDir - власний шлях до кореневої теки, який kubelet використовуватиме для розміщення лог-файлів под'ів. Стандартно: "/var/log/pods/" Примітка: не рекомендується використовувати теку temp як теку логу, оскільки це може спричинити неочікувану поведінку у багатьох місцях.

syncFrequency
meta/v1.Duration

syncFrequency — максимальний період між синхронізацією запущених контейнерів і конфігурацією. Стандартно: "1m"];

fileCheckFrequency
meta/v1.Duration

fileCheckFrequency — тривалість між перевірками конфігураційних файлів на наявність нових даних. Стандартно: "20s"];

httpCheckFrequency
meta/v1.Duration

httpCheckFrequency — інтервал між перевірками http на наявність нових даних. Стандартно: "20s"];

staticPodURL
string

staticPodURL — це URL-адреса для доступу до статичних Podʼів для запуску. Стандартно: ""

staticPodURLHeader
map[string][]string

staticPodURLHeader — map slice із заголовками HTTP, які потрібно використовувати при доступі до podURL. Стандартно: nil

address
string

address — IP-адреса, на якій буде працювати Kubelet (встановлено на 0.0.0.0 для всіх інтерфейсів). Стандартно: "0.0.0.0";

port
int32

port — це порт, на якому буде обслуговуватися Kubelet. Номер порту має бути в діапазоні від 1 до 65535 включно. Стандартно: 10250

readOnlyPort
int32

readOnlyPort - це порт тільки для читання, на якому Kubelet буде працювати без автентифікації/авторизації. Номер порту повинен бути в діапазоні від 1 до 65535 включно. Встановлення цього поля у 0 вимикає сервіс тільки для читання. Стандартно: 0 (вимкнено)

tlsCertFile
string

tlsCertFile — файл, що містить сертифікат x509 для HTTPS. (Сертифікат центру сертифікації, якщо такий є, додається після сертифіката сервера). Якщо tlsCertFile і tlsPrivateKeyFile не вказано, самопідписаний сертифікат і ключ генеруються для публічної адреси і зберігаються у теці, яку передано у прапорці Kubelet --cert-dir. Стандартно: ""

tlsPrivateKeyFile
string

tlsPrivateKeyFile — файл, що містить приватний ключ x509, який відповідає tlsCertFile. Стандартно: ""

tlsCipherSuites
[]string

tlsCipherSuites — список дозволених наборів шифрів для сервера. Зверніть увагу, що набори шифрів TLS 1.3 не налаштовуються. Значення беруться з констант пакета tls (https://golang.org/pkg/crypto/tls/#pkg-constants). Стандартно: nil

tlsMinVersion
string

tlsMinVersion — мінімальна підтримувана версія TLS. Значення беруться з констант пакета tls (https://golang.org/pkg/crypto/tls/#pkg-constants). Стандартно: ""

rotateCertificates
bool

rotateCertificates дозволяє ротацію клієнтських сертифікатів. Kubelet запросить новий сертифікат з API certificates.k8s.io. Для цього потрібен затверджувач, який схвалює запити на підписання сертифікатів. Стандартно: false

serverTLSBootstrap
bool

serverTLSBootstrap вмикає bootstrap серверного сертифікату. Замість того, щоб самостійно підписувати серверний сертифікат, Kubelet буде запитувати сертифікат з API 'certificates.k8s.io'. Для цього потрібен затверджувач для схвалення запитів на підписання сертифікатів (CSR). Функція RotateKubeletServerCertificate має бути ввімкнена при встановленні цього поля. Стандартно: false

authentication
KubeletAuthentication

authentication визначає спосіб автентифікації запитів до сервера Kubelet. Стандартно:

anonymous:
  enabled: false
webhook:
  enabled: true
  cacheTTL: "2m"

authorization
KubeletAuthorization

authorization визначає спосіб авторизації запитів до сервера Kubelet. Стандартно:

mode: Webhook
webhook:
  cacheAuthorizedTTL: "5m"
  cacheUnauthorizedTTL: "30s"

registryPullQPS
int32

registryPullQPS — ліміт отримання образів з реєстру за секунду. Значення не повинно бути відʼємним числом. Встановлення значення 0 означає відсутність обмеження. Стандартно: 5

registryBurst
int32

registryBurst — максимальний розмір стрімких витягань, тимчасово дозволяє стрімким витяганням досягати цього числа, але при цьому не перевищувати registryPullQPS. Значення не повинно бути відʼємним числом. Використовується тільки якщо registryPullQPS більше 0. Стандартно: 10

eventRecordQPS
int32

eventRecordQPS — максимальна кількість створених подій за секунду. Якщо 0, то обмеження не застосовується. Значення не може бути відʼємним. Стандартно: 50

eventBurst
int32

eventBurst - максимальний розмір сплеску створення подій, тимчасово дозволяє створювати події до цього числа, але не більше ніж eventRecordQPS. Це поле не може бути відʼємним числом і використовується лише тоді, коли eventRecordQPS > 0. Стандартно: 100

enableDebuggingHandlers
bool

enableDebuggingHandlers вмикає точки доступу до логів на сервері та локальний запуск контейнерів і команд, включно з функціями exec, attach, logs та portforward. Стандартно: true

enableContentionProfiling
bool

enableContentionProfiling вмикає профілювання блоків, якщо enableDebuggingHandlers має значення true. Стандартно: false

healthzPort
int32

healthzPort — порт точки доступу localhost healthz (для вимкнення встановлюється на 0). Допустиме значення від 1 до 65535. Стандартне значення: 10248

healthzBindAddress
string

healthzBindAddress - IP-адреса для сервера healthz. Стандартно: "127.0.0.1";

oomScoreAdj
int32

oomScoreAdj — значення oom-score-adj для процесу kubelet. Значення має бути в діапазоні [-1000, 1000]. Стандартно: -999

clusterDomain
string

clusterDomain — DNS-домен для цього кластера. Якщо задано, kubelet налаштує всі контейнери на пошук у цьому домені на додаток до пошукових доменів хоста. Стандартно: ""

clusterDNS
[]string

clusterDNS — список IP-адрес для DNS-сервера кластера. Якщо встановлено, kubelet налаштує всі контейнери на використання цього списку для DNS-розпізнавання замість DNS-серверів хоста. Стандартно: nil

streamingConnectionIdleTimeout
meta/v1.Duration

streamingConnectionIdleTimeout — максимальний час, протягом якого потокове зʼєднання може простоювати, перш ніж зʼєднання буде автоматично закрито. Стандартно: "4h";

nodeStatusUpdateFrequency
meta/v1.Duration

nodeStatusUpdateFrequency - частота, з якою kubelet обчислює статус вузла. Якщо функцію оренди вузлів не увімкнено, це також частота, з якою kubelet надсилає статус вузла майстру. Примітка: Якщо функцію оренди вузла не увімкнено, будьте обережні при зміні константи, вона має працювати з nodeMonitorGracePeriod у nodecontroller. Стандартно: "10s"

nodeStatusReportFrequency
meta/v1.Duration

nodeStatusReportFrequency — частота, з якою kubelet надсилає статус вузла майстру, якщо статус вузла не змінюється. Kubelet ігноруватиме цю частоту і відправлятиме статус вузла негайно, якщо буде виявлено будь-яку зміну. Використовується лише тоді, коли увімкнено функцію оренди вузлів. nodeStatusReportFrequency має стандартне значення 5m. Але якщо nodeStatusUpdateFrequency задано явно, стандартне значення nodeStatusReportFrequency буде встановлено на nodeStatusUpdateFrequency для зворотної сумісності. Стандартно: "5m"];

nodeLeaseDurationSeconds
int32

nodeLeaseDurationSeconds - це тривалість, яку Kubelet встановить для відповідного lease. NodeLease надає індикатор справності вузла, змушуючи Kubelet створювати та періодично поновлювати договір оренди, названий на честь вузла, у просторі імен kube-node-lease. Якщо термін дії договору закінчується, вузол можна вважати несправним. Наразі оренда поновлюється кожні 10 секунд, згідно з KEP-0009. У майбутньому інтервал поновлення оренди може бути встановлений на основі тривалості оренди. Значення поля має бути більше 0. Стандартно: 40

imageMinimumGCAge
meta/v1.Duration

imageMinimumGCAge — мінімальний вік невикористаного образу перед тим, як його буде вилучено. Стандартно: "2m"];

imageMaximumGCAge
meta/v1.Duration

imageMaximumGCAge — максимальний вік, протягом якого образ може бути невикористаним, перш ніж його буде вилучено у смітник. Стандартне значення цього поля - "0s", що вимикає це поле - тобто образи не буде вилучено у смітник через те, що їх не було використано надто довго. Стандартно: "0s" (вимкнено)

imageGCHighThresholdPercent
int32

imageGCHighThresholdPercent — це відсоток використання диска, після якого завжди запускається прибирання образів. Відсоток обчислюється діленням значення цього поля на 100, тому значення цього поля має бути від 0 до 100 включно. Якщо вказано, значення має бути більшим за imageGCLowThresholdPercent. Стандартно: 85

imageGCLowThresholdPercent
int32

imageGCLowThresholdPercent — це відсоток використання диска, до якого прибирання образів ніколи не виконуватиметься. Найнижчий відсоток використання диска для збирання сміття. Відсоток обчислюється діленням значення цього поля на 100, тому значення поля має бути у діапазоні від 0 до 100 включно. Якщо вказано, значення має бути меншим за imageGCHighThresholdPercent. Стандартно: 80

volumeStatsAggPeriod
meta/v1.Duration

volumeStatsAggPeriod — це частота для обчислення та кешування обсягу використання диска для всіх Podʼів. Стандартно: "1m"

kubeletCgroups
string

kubeletCgroups — абсолютна назва cgroups для ізоляції kubelet. Стандартно: ""

systemCgroups
string

systemCgroups — абсолютна назва cgroups, до якої слід помістити усі неядерні процеси, які ще не знаходяться у контейнері. Порожньо, якщо немає контейнера. Скидання прапорця вимагає перезавантаження. Якщо це поле не порожнє, слід вказати cgroupRoot. Стандартно: ""

cgroupRoot
string

cgroupRoot - це коренева cgroup, яку слід використовувати для Podʼів. Ця група обробляється під час виконання контейнера на основі принципу найкращих зусиль.

cgroupsPerQOS
bool

cgroupsPerQOS вмикає ієрархію CGroup на основі QoS: CGroups верхнього рівня для класів QoS і всі Burstable та BestEffort Pods підпорядковуються певній CGroup QoS верхнього рівня. Стандартно: true

cgroupDriver
string

cgroupDriver — це драйвер, який kubelet використовує для керування CGroups на хості (cgroupfs або systemd). Стандартно: "cgroupfs";

cpuManagerPolicy
string

cpuManagerPolicy - назва політики, яку буде використано. Потребує увімкнення функціональних можливостей CPUManager. Стандартно: "None"

cpuManagerPolicyOptions
map[string]string

cpuManagerPolicyOptions — це набір key=value, який дозволяє встановити додаткові опції для точного налаштування поведінки політик диспетчера процесорів. Потребує увімкнення функціональних можливостей "CPUManager" та "CPUManagerPolicyOptions". Стандартно: nil

cpuManagerReconcilePeriod
meta/v1.Duration

cpuManagerReconcilePeriod - період узгодження для CPU Manager. Потребує увімкнення функціональної можливості CPUManager. Стандартне значення: "10s"

memoryManagerPolicy
string

memoryManagerPolicy - назва політики, яку використовуватиме менеджер памʼяті. Потребує увімкнення функціональної можливості MemoryManager. Стандартно: "none"

topologyManagerPolicy
string

topologyManagerPolicy — назва політики менеджера топології, яку слід використовувати. Допустимі значення включають:

  • restricted: kubelet дозволяє лише ті Podʼи, які мають оптимальне вирівнювання вузлів NUMA для запитуваних ресурсів;
  • best-effort: kubelet надаватиме перевагу Podʼам з NUMA-вирівнюванням ресурсів процесора та пристроїв;
  • none: kubelet не знає про вирівнювання NUMA ресурсів процесора та пристроїв під час роботи.
  • single-numa-node: kubelet дозволяє використовувати лише Podʼи з єдиним NUMA-вирівнюванням ресурсів процесора та пристроїв.

Default: "none"

topologyManagerScope
string

topologyManagerScope представляє обсяг генерації підказок топології, які запитує менеджер топології та генерують постачальники підказок. Допустимі значення включають:

  • container: політика топології застосовується для кожного контейнера окремо.
  • pod: політика топології застосовується на основі кожного окремого блоку.

Default: "container"

topologyManagerPolicyOptions
map[string]string

TopologyManagerPolicyOptions - це набір key=value, який дозволяє встановити додаткові опції для точного налаштування поведінки політик менеджера топології. Потребує увімкнення обох функціональних можливостей — "TopologyManager" та "TopologyManagerPolicyOptions". Стандартно: nil

qosReserved
map[string]string

qosReserved — це набір пар імені ресурсу та відсотка, які визначають мінімальний відсоток ресурсу, зарезервований для ексклюзивного використання на рівні гарантованого QoS. Наразі підтримувані ресурси: "памʼять" Потребує увімкнення функціональної можливості QOSReserved. Стандартно: nil

runtimeRequestTimeout
meta/v1.Duration

runtimeRequestTimeout — це таймаут для всіх запитів часу виконання, окрім довготривалих запитів — pull, logs, exec та attach. Стандартно: "2m"

hairpinMode
string

hairpinMode вказує, як Kubelet має налаштувати міст контейнера для пакета hairpin. Встановлення цього прапорця дозволяє точкам доступу в Service перерозподіляти навантаження на себе, якщо вони намагаються отримати доступ до свого власного Service. Значення:

  • "promiscuous-bridge": зробити контейнерний міст невпорядкованим.
  • "hairpin-veth": встановити прапорець hairpin на інтерфейсах container veth.
  • "none": нічого не робити.

Зазвичай, для досягнення hairpin NAT потрібно встановити --hairpin-mode=hairpin-veth, оскільки promiscuous-bridge передбачає наявність контейнерного моста з назвою cbr0. Стандартно: "promiscuous-bridge"

maxPods
int32

maxPods — максимальна кількість Podʼів, які можуть бути запущені на цьому Kubelet. Значення має бути цілим невідʼємним числом. Стандартно: 110

podCIDR
string

podCIDR — це CIDR для IP-адрес pod, який використовується лише в режимі standalone. У кластерному режимі він отримується з панелі управління. Стандартно: ""

podPidsLimit
int64

podPidsLimit — максимальна кількість PID у будь-якому pod. Default: -1

resolvConf
string

resolvConf — це файл конфігурації резолвера, який використовується як основа для налаштування DNS-резолюції контейнера. Якщо встановлено порожній рядок, він перевизначає стандартне значення і фактично вимикає DNS-запити. Стандартно: "/etc/resolv.conf"

runOnce
bool

runOnce змушує Kubelet один раз перевірити сервер API на наявність Podʼів, запустити ті з них, які вказані у статичних файлах Podʼів, і вийти. Стандартно: false

cpuCFSQuota
bool

cpuCFSQuota вмикає застосування квоти CPU CFS для контейнерів, які визначають ліміти процесора. Стандартно: true

cpuCFSQuotaPeriod
meta/v1.Duration

cpuCFSQuotaPeriod — це значення періоду квоти CFS процесора, cpu.cfs_period_us. Значення має бути від 1 мс до 1 секунди включно. Потребує увімкнення функціональної можливості CustomCPUCFSQuotaPeriod. Стандартно: "100ms";

nodeStatusMaxImages
int32

nodeStatusMaxImages обмежує кількість зображень, про які повідомляється у Node.status.images. Значення має бути більшим за -2. Зауваження: Якщо вказано -1, обмеження не буде застосовано. Якщо вказано 0, жодного образу не буде повернуто. Стандартно: 50

maxOpenFiles
int64

maxOpenFiles - кількість файлів, які може відкрити процес Kubelet. Значення має бути невідʼємним числом. Стандартно: 1000000

contentType
string

contentType — тип вмісту запитів, що надсилаються до apiserver. Стандартно: "application/vnd.kubernetes.protobuf";

kubeAPIQPS
int32

kubeAPIQPS - це QPS, який слід використовувати під час спілкування з apiserver'ом kubernetes. Стандартно: 50

kubeAPIBurst
int32

kubeAPIBurst — це кількість пакетів, які слід дозволити під час спілкування з сервером API kubernetes. Це поле не може бути відʼємним числом. Стандартно: 100

serializeImagePulls
bool

serializeImagePulls, якщо увімкнено, вказує Kubelet завантажувати образи один за одним. Ми рекомендуємо не змінювати стандартні значення на вузлах, де працює демон docker версії < 1.9 або сховище Aufs. Деталі наведено у Issue #10959. Стандартно: true

maxParallelImagePulls
int32

MaxParallelImagePulls задає максимальну кількість паралельних завантажень образів. Це поле не можна встановити, якщо SerializeImagePulls має значення true. Встановлення значення nil означає відсутність обмежень. Стандартно: nil

evictionHard
map[string]string

evictionHard — це map назв сигналів до величин, що визначає жорсткі пороги виселення. Наприклад: {"memory.available": "300Mi"}. Щоб явно вимкнути, передайте порогове значення 0% або 100% для довільного ресурсу. Стандартно:

memory.available:  "100Mi"
nodefs.available:  "10%"
nodefs.inodesFree: "5%"
imagefs.available: "15%"

evictionSoft
map[string]string

evictionSoft це map імен сигналів до величин, яка визначає мʼякі пороги виселення. Наприклад: {"memory.available": "300Mi"}. Стандартно: nil

evictionSoftGracePeriod
map[string]string

evictionSoftGracePeriod це map назв сигналів до величин, яка визначає пільгові періоди для кожного сигналу мʼякого виселення. Наприклад: {"memory.available": "30s"}. Стандартно: nil

evictionPressureTransitionPeriod
meta/v1.Duration

evictionPressureTransitionPeriod — це тривалість, протягом якої kubelet має зачекати, перш ніж вийти зі стану тиску витіснення. Стандартно: "5m"

evictionMaxPodGracePeriod
int32

evictionMaxPodGracePeriod - це максимально дозволений пільговий період (у секундах), який можна використовувати при завершенні роботи pods у відповідь на досягнення порогу мʼякого виселення. Це значення фактично обмежує значення terminationGracePeriodSeconds під час мʼякого виселення. Примітка: У звʼязку з issue #64530 у поведінці є помилка, коли це значення наразі просто перевизначає пільговий період під час мʼякого виселення, що може збільшити пільговий період порівняно з тим, що встановлено в Pod. Ця помилка буде виправлена в наступному випуску. Стандартно: 0

evictionMinimumReclaim
map[string]string

evictionMinimumReclaim це map імен сигналів до величин, що визначає мінімальні відновлення, які описують мінімальну кількість заданого ресурсу, яку kubelet буде відновлювати при виконанні виселення pod, поки цей ресурс знаходиться під тиском. Наприклад: {"imagefs.available": "2Gi"}. Стандартно: nil

podsPerCore
int32

podsPerCore — максимальна кількість Podʼів на ядро. Не може перевищувати maxPods. Значення має бути цілим невідʼємним числом. Якщо 0, то немає обмеження на кількість Podʼів. Стандартно: 0

enableControllerAttachDetach
bool

enableControllerAttachDetach дозволяє контролеру Attach/Detach керувати приєднанням/відʼєднанням томів, запланованих для цього вузла, і забороняє kubelet виконувати будь-які операції приєднання/відʼєднання. Зауваження: приєднання/відʼєднання томів CSI не підтримується kubelet, тому для цього варіанту використання ця опція має мати значення true. Стандартно: true

protectKernelDefaults
bool

protectKernelDefaults, якщо значення true, призводить до помилки Kubelet, якщо прапорці ядра не відповідають його очікуванням. В іншому випадку Kubelet спробує змінити прапорці ядра так, щоб вони відповідали його очікуванням. Стандартно: false

makeIPTablesUtilChains
bool

makeIPTablesUtilChains, якщо значення true, змушує Kubelet створювати ланцюжок KUBE-IPTABLES-HINT у iptables як підказку іншим компонентам про конфігурацію iptables у системі. Стандартно: true

iptablesMasqueradeBit
int32

iptablesMasqueradeBit раніше контролював створення ланцюжка KUBE-MARK-MASQ. Застарілий: більше не має жодного впливу. Стандартно: 14

iptablesDropBit
int32

iptablesDropBit раніше контролював створення ланцюжка KUBE-MARK-DROP. Застаріла: більше не має жодного впливу. Стандартно: 15

featureGates
map[string]bool

featureGates - це map імен функціональних можливостей до bools, які вмикають або вимикають експериментальні можливості. Це поле змінює вбудовані стандартні значення з "k8s.io/kubernetes/pkg/features/kube_features.go". Стандартно: nil

failSwapOn
bool

failSwapOn вказує Kubelet не запускатися, якщо на вузлі увімкнено підкачку. Стандартно: true

memorySwap
MemorySwapConfiguration

memorySwap налаштовує памʼять підкачки, доступну для контейнерних робочих навантажень.

containerLogMaxSize
string

containerLogMaxSize — величина, що визначає максимальний розмір лог-файлу контейнера перед його ротацією. Наприклад: "5Mi" або "256Ki". Стандартно: "10Mi"";

containerLogMaxFiles
int32

containerLogMaxFiles визначає максимальну кількість файлів логу контейнера, які можуть бути присутніми для контейнера. Стандартно: 5

containerLogMaxWorkers
int32

ContainerLogMaxWorkers визначає максимальну кількість паралельних робочих процесів для виконання операцій ротації логів. Встановіть це значення рівним 1, щоб вимкнути паралельні робочі процеси ротації логу. Стандартно: 1

containerLogMonitorInterval
meta/v1.Duration

ContainerLogMonitorInterval визначає тривалість, протягом якої контейнерні логи відстежуються для виконання операції ротації логів. Стандартно це значення дорівнює 10 * time.Seconds. Але його можна налаштувати на менше значення залежно від частоти генерації логів і розміру, щодо якого потрібно виконати ротацію. Стандартно: 10s

configMapAndSecretChangeDetectionStrategy
ResourceChangeDetectionStrategy

configMapAndSecretChangeDetectionStrategy - режим, у якому працюють менеджери ConfigMap і Secret. Допустимі значення включають:

  • Get: kubelet отримує необхідні обʼєкти безпосередньо з сервера API;
  • Cache: kubelet використовує TTL кеш для обʼєктів, отриманих з сервера API;
  • Watch: kubelet використовує watch для спостереження за змінами в обʼєктах, які його цікавлять.

Default: "Watch"

systemReserved
map[string]string

systemReserved - це набір пар ResourceName=ResourceQuantity (наприклад, cpu=200m,memory=150G), які описують ресурси, зарезервовані для компонентів, що не належать до kubernetes. Наразі підтримуються лише процесор і памʼять. Дивіться http://kubernetes.io/docs/user-guide/compute-resources для більш детальної інформації. Стандартно: nil

kubeReserved
map[string]string

kubeReserved — це набір пар ResourceName=ResourceQuantity (наприклад, cpu=200m,memory=150G), які описують ресурси, зарезервовані для компонентів системи kubernetes. Наразі підтримуються процесор, памʼять та локальне сховище для кореневої файлової системи. Більш детальну інформацію можна знайти на сторінці https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/. Стандартно: nil

reservedSystemCPUs [Обовʼязково]
string

Параметр reservedSystemCPUs визначає список процесорів, зарезервованих для системних потоків рівня хоста та потоків, повʼязаних з kubernetes. Це забезпечує "статичний" список процесорів, а не "динамічний" список за допомогою systemReserved та kubeReserved. Цей параметр не підтримує systemReservedCgroup або kubeReservedCgroup.

showHiddenMetricsForVersion
string

showHiddenMetricsForVersion — це попередня версія, для якої ви хочете показати приховані метрики. Тільки попередня мінорна версія є значущою, інші значення не допускаються. Формат <major>.<minor>, наприклад: 1.16. Метою цього формату є забезпечення можливості помітити, якщо в наступному випуску будуть приховані додаткові метрики, а не бути здивованими, коли вони будуть остаточно видалені в наступному випуску. Стандартно: ""

systemReservedCgroup
string

systemReservedCgroup допомагає kubelet ідентифікувати абсолютну назву верхнього рівня CGroup, який використовується для забезпечення systemReserved обчислювального резервування ресурсів для системних демонів ОС. Дивіться Node Allocatable документацію для отримання додаткової інформації. Стандартно: ""

kubeReservedCgroup
string

kubeReservedCgroup допомагає kubelet ідентифікувати абсолютну назву верхнього рівня CGroup, який використовується для забезпечення KubeReserved обчислювального резервування ресурсів для системних демонів вузла Kubernetes. Дивіться Node Allocatable документацію для отримання додаткової інформації. Стандартно: ""

enforceNodeAllocatable
[]string

Цей прапорець визначає різні примусові дії Node Allocatable, які Kubelet повинен виконувати. Цей прапорець приймає список опцій. Прийнятні опції: none, pods, system-reserved і kube-reserved. Якщо вказано none, інші опції не можуть бути вказані. Коли system-reserved є в списку, має бути вказано systemReservedCgroup. Коли kube-reserved є в списку, має бути вказано kubeReservedCgroup. Це поле підтримується тільки тоді, коли cgroupsPerQOS встановлено на true. Дивіться Node Allocatable для отримання додаткової інформації. Стандартно: ["pods"]

allowedUnsafeSysctls
[]string

Список небезпечних sysctl або шаблонів sysctl, розділених комами (які закінчуються на *). Небезпечні групи sysctl включають kernel.shm*, kernel.msg*, kernel.sem, fs.mqueue.* та net.*. Наприклад: "kernel.msg*,net.ipv4.route.min_pmtu". Стандартно: []

volumePluginDir
string

volumePluginDir — це повний шлях до теки, в якій слід шукати додаткові втулки томів сторонніх розробників. Стандартно: "/usr/libexec/kubernetes/kubelet-plugins/volume/exec/"

providerID
string

providerID, якщо вказано, встановлює унікальний ID екземпляра, який зовнішній постачальник (наприклад, хмарний постачальник) може використовувати для ідентифікації конкретного вузла. Стандартно: ""

kernelMemcgNotification
bool

kernelMemcgNotification, якщо вказано, інструктує kubelet інтегруватися з нотифікацією memcg ядра для визначення, чи перевищені порогові значення памʼяті для виселення, замість опитування. Стандартно: false

logging [Обовʼязково]
LoggingConfiguration

logging вказує параметри логування. Для отримання додаткової інформації зверніться до Options for Logs. стандартно: Format: text

enableSystemLogHandler
bool

enableSystemLogHandler дозволяє отримати доступ до системних логів через веб-інтерфейс за адресою host:port/logs/. Стандартно: true

enableSystemLogQuery
bool

enableSystemLogQuery активує функцію запиту логів вузла на точці доступу /logs. Для роботи цієї функції також потрібно включити EnableSystemLogHandler. Стандартно: false

shutdownGracePeriod
meta/v1.Duration

shutdownGracePeriod вказує загальну тривалість, на яку вузол повинен затримати завершення роботи і загальний період належного завершення роботи для завершення роботи Podʼів під час завершення роботи вузла. Стандартно: "0s"

shutdownGracePeriodCriticalPods
meta/v1.Duration

shutdownGracePeriodCriticalPods вказує тривалість, що використовується для завершення критичних Podʼів під час завершення роботи вузла. Це повинно бути менше ніж shutdownGracePeriod. Наприклад, якщо shutdownGracePeriod=30s, і shutdownGracePeriodCriticalPods=10s, під час завершення роботи вузла перші 20 секунд будуть зарезервовані для мʼякого завершення роботи звичайних Podʼів, а останні 10 секунд будуть зарезервовані для завершення роботи критичних Podʼів. Стандартно: "0s"

shutdownGracePeriodByPodPriority
[]ShutdownGracePeriodByPodPriority

shutdownGracePeriodByPodPriority вказує період часу для належного завершення роботи Podʼів на основі їх значення класу пріоритету. Коли отримано запит на завершення роботи, Kubelet ініціює завершення роботи для всіх Podʼів, що працюють на вузлі, з періодом часу, що залежить від пріоритету Podʼа, і потім чекає на завершення роботи всіх Podʼів. Кожен запис у масиві представляє час належного завершення роботи для Podʼа з значенням класу пріоритету, що лежить у діапазоні цього значення та наступного вищого запису в списку під час завершення роботи вузла. Наприклад, щоб дозволити критичним Podʼам 10 секунд для завершення роботи, Podʼам з пріоритетом >=10000 — 20 секунд, а всім іншим Podʼам — 30 секунд.

shutdownGracePeriodByPodPriority:

  • priority: 2000000000 shutdownGracePeriodSeconds: 10
  • priority: 10000 shutdownGracePeriodSeconds: 20
  • priority: 0 shutdownGracePeriodSeconds: 30

Час, який Kubelet чекатиме перед завершенням роботи, буде максимумом з усіх shutdownGracePeriodSeconds для кожного діапазону класів пріоритету, представленого на вузлі. Коли всі Podʼи завершать роботу або досягнуть своїх періодівналежного завершення, Kubelet звільнить блокування інгібіції завершення роботи. Потрібно, щоб була ввімкнена функція GracefulNodeShutdown. Ця конфігурація має бути порожньою, якщо встановлено або ShutdownGracePeriod, або ShutdownGracePeriodCriticalPods. Стандартно: nil

reservedMemory
[]MemoryReservation

reservedMemory визначає список резервувань памʼяті для NUMA-вузлів, розділений комами. Цей параметр має сенс лише в контексті функції керування памʼяттю. Менеджер памʼяті не виділятиме зарезервовану памʼять для робочих навантажень контейнерів. Наприклад, якщо у вас є NUMA0 з 10Gi памʼяті, і reservedMemory було вказано для резервування 1Gi памʼяті на NUMA0, менеджер памʼяті передбачатиме, що лише 9Gi доступні для виділення. Ви можете вказати різну кількість вузлів NUMA та типів памʼяті. Ви можете взагалі опустити цей параметр, але повинні знати, що кількість зарезервованої памʼяті з усіх вузлів NUMA повинна бути рівною кількості памʼяті, вказаній у node allocatable. Якщо хоча б один параметр node allocatable має ненульове значення, вам потрібно буде вказати принаймні один вузол NUMA. Також уникайте вказування:

  1. Дублікати, той самий вузол NUMA і тип пам’яті, але з іншим значенням.
  2. нульові обмеження для будь-якого типу памʼяті.
  3. Ідентифікатори вузлів NUMAs, які не існують на машині.
  4. типи пам’яті, крім пам’яті та hugepages-

Стандартно: nil

enableProfilingHandler
bool

enableProfilingHandler дозволяє профілювання через веб-інтерфейс host:port/debug/pprof/. Стандартно: true

enableDebugFlagsHandler
bool

enableDebugFlagsHandler дозволяє доступ до прапорців через веб-інтерфейс host:port/debug/flags/v. Стандартно: true

seccompDefault
bool

SeccompDefault дозволяє використовувати RuntimeDefault як профіль seccomp стнадартно для всіх робочих навантажень. Стандартно: false

memoryThrottlingFactor
float64

MemoryThrottlingFactor визначає множник, який множиться на обмеження памʼяті або доступну памʼять вузла при встановленні значення cgroupv2 memory.high для забезпечення MemoryQoS. Зменшення цього коефіцієнта встановить нижчу високу межу для cgroups контейнера і створить більший тиск на відновлення памʼяті, тоді як збільшення зменшить тиск на відновлення. Детальніше дивіться за посиланням: KEP-2570. Стандартно: 0.9

registerWithTaints
[]core/v1.Taint

registerWithTaints — це масив "taints" (міток) для додавання до обʼєкта вузла під час реєстрації kubelet. Набирає чинності лише тоді, коли параметр registerNode встановлено в значення true і під час початкової реєстрації вузла. Стандартно: nil

registerNode
bool

registerNode дозволяє автоматичну реєстрацію з apiserver. Стандартно: true

tracing
TracingConfiguration

Tracing визначає версійовану конфігурацію для клієнтів трасування OpenTelemetry. Див. kep.k8s.io/2832 для отримання додаткової інформації. Стандартно: nil

localStorageCapacityIsolation
bool

LocalStorageCapacityIsolation дозволяє використовувати функцію ізоляції локального тимчасового зберігання. Стандартно: true. Ця функція дозволяє користувачам встановлювати запити/межі для тимчасового зберігання контейнерів та керувати ним так само, як процесорами та памʼяттю. Вона також дозволяє встановлювати sizeLimit для томів emptyDir, що призведе до видалення Podʼа, якщо використання диска з тома перевищить межу. Ця функція залежить від можливості правильної детекції використання кореневої файлової системи диска. Для деяких систем, таких як kind rootless, якщо ця можливість не підтримується, функцію LocalStorageCapacityIsolation слід вимкнути. Після вимкнення користувач не повинен встановлювати запити/межі для тимчасового зберігання контейнерів або sizeLimit для emptyDir. Стандартно: true

containerRuntimeEndpoint [Обовʼязково]
string

ContainerRuntimeEndpoint є точкою доступу середовища виконання контейнерів. В Linux підтримуються Unix Domain Sockets, а у Windows підтримуються точки npipe та tcp. Приклади: 'unix:///path/to/runtime.sock', 'npipe:////./pipe/runtime'

imageServiceEndpoint
string

ImageServiceEndpoint є точкою доступу сервісу контейнерних образів. Unix Domain Socket підтримуються в Linux, а npipe та tcp точки підтримуються у Windows. Приклади: 'unix:///path/to/runtime.sock', 'npipe:////./pipe/runtime'. Якщо не вказано, використовується значення з containerRuntimeEndpoint.

failCgroupV1
bool

FailCgroupV1 забороняє запуск kubelet на хостах, які використовують cgroup v1. Стандартно цей параметр має значення false, що означає, що kubelet дозволяється запускати на хостах cgroup v1, якщо цей параметр явно не ввімкнено. Стандартно: false

SerializedNodeConfigSource

SerializedNodeConfigSource дозволяє серіалізувати v1.NodeConfigSource. Цей тип використовується всередині Kubelet для відстеження збережених динамічних конфігурацій. Він існує в API групі kubeletconfig, оскільки класифікується як версійний вхідний параметр для Kubelet.

ПолеОпис
apiVersion
string
kubelet.config.k8s.io/v1beta1
kind
string
SerializedNodeConfigSource
source
core/v1.NodeConfigSource

source є джерелом, яке ми серіалізуємо.

CredentialProvider

Зʼявляється в:

CredentialProvider представляє втулок exec, який викликається kubelet. Втулок викликається тільки тоді, коли образ, що завантажується, відповідає образам, що обробляються втулком (див. matchImages).

ПолеОпис
name [Обовʼязково]
string

name є обовʼязковою назвою постачальника облікових даних. Має відповідати назві виконуваного файлу постачальника, яку бачить kubelet. Виконуваний файл повинен бути в теці bin kubelet (встановлений прапорцем --image-credential-provider-bin-dir).

matchImages [Обовʼязково]
[]string

matchImages є обовʼязковим списком рядків, які використовуються для порівняння з образами, щоб визначити, чи слід викликати цього постачальника. Якщо один із рядків відповідає запитаному образу від kubelet, втулок буде викликаний і отримає можливість надати облікові дані. Очікується, що образи міститимуть домен реєстрації та URL-адресу.

Кожен запис у matchImages є шаблоном, який може містити порт і шлях. Глоби можна використовувати в домені, але не в порту чи шляху. Глоби підтримуються як піддоменами, такими як '*.k8s.io' або 'k8s.*.io', а також топ-рівневими доменами, такими як 'k8s.*'. Часткові піддомени, такі як 'app*.k8s.io', також підтримуються. Кожен глоб може відповідати лише одному сегменту піддомену, тому '*.io' не відповідає '*.k8s.io'.

Відповідність існує між образом і matchImage, коли всі з нижченаведених умов виконані:

  • Обидва містять однакову кількість частин домену, і кожна частина має збіг.
  • URL шлях образу повинен бути префіксом цільового URL шляху образу.
  • Якщо matchImage містить порт, порт також повинен мати збіг в образі.

Приклади значень matchImages:

  • 123456789.dkr.ecr.us-east-1.amazonaws.com
  • *.azurecr.io
  • gcr.io
  • *.*.registry.io
  • registry.io:8080/path
defaultCacheDuration [Обовʼязково]
meta/v1.Duration

defaultCacheDuration є стандартним періодом, протягом якого втулок буде кешувати облікові дані в памʼяті, якщо в відповіді втулка не вказано період кешування. Це поле є обовʼязковим.

apiVersion [Обовʼязково]
string

Обовʼязкова версія введення запиту CredentialProvider. Повернутий CredentialProviderResponse МУСИТЬ використовувати таку ж версію кодування, як і ввод. Поточні підтримувані значення:

  • credentialprovider.kubelet.k8s.io/v1beta1
args
[]string

Аргументи, які передаються команді при її виконанні.

env
[]ExecEnvVar

Env визначає додаткові змінні середовища, які потрібно надати процесу. Вони обʼєднуються з середовищем хоста, а також змінними, які client-go використовує для передачі аргументів втулку.

ExecEnvVar

Зʼявляється в:

ExecEnvVar використовується для встановлення змінних середовища при виконанні втулку облікових даних на основі exec.

ПолеОпис
name [Обовʼязково]
string

name визначає імʼя змінної середовища.

value [Обовʼязково]
string

value визначає значення змінної середовища.

KubeletAnonymousAuthentication

Зʼявляється в:

ПолеОпис
enabled
bool

enabled дозволяє анонімні запити до сервера kubelet. Запити, які не відхиляються іншим методом автентифікації, обробляються як анонімні запити. Анонімні запити мають імʼя користувача system:anonymous та групу system:unauthenticated.

KubeletAuthentication

Зʼявляється в:

ПолеОпис
x509
KubeletX509Authentication

x509 містить налаштування, що стосуються автентифікації за допомогою клієнтських сертифікатів x509.

webhook
KubeletWebhookAuthentication

webhook містить налаштування, що стосуються автентифікації за допомогою webhook токенів на предʼявника.

anonymous
KubeletAnonymousAuthentication

anonymous містить налаштування, що стосуються анонімної автентифікації.

KubeletAuthorization

Зʼявляється в:

ПолеОпис
mode
KubeletAuthorizationMode

mode визначає режим авторизації для запитів до сервера kubelet. Дійсні значення: AlwaysAllow і Webhook. Режим Webhook використовує API SubjectAccessReview для визначення авторизації.

webhook
KubeletWebhookAuthorization

webhook містить налаштування, що стосуються авторизації через Webhook.

KubeletAuthorizationMode

(Аліас до string)

Зʼявляється в:

KubeletWebhookAuthentication

Зʼявляється в:

ПолеОпис
enabled
bool

enabled дозволяє автентифікацію за допомогою токенів, підтримувану API tokenreviews.authentication.k8s.io.

cacheTTL
meta/v1.Duration

cacheTTL дозволяє кешування результатів автентифікації.

KubeletWebhookAuthorization

Зʼявляється в:

ПолеОпис
cacheAuthorizedTTL
meta/v1.Duration

cacheAuthorizedTTL — тривалість кешування відповідей 'authorized' від веб-хук авторизатора.

cacheUnauthorizedTTL
meta/v1.Duration

cacheUnauthorizedTTL — тривалість кешування відповідей 'unauthorized' від веб-хук авторизатора.

KubeletX509Authentication

Зʼявляється в:

ПолеОпис
clientCAFile
string

clientCAFile — шлях до файлу сертифікатів у форматі PEM. Якщо встановлено, будь-який запит, що надає клієнтський сертифікат, підписаний одним з органів сертифікації з цього пакету, автентифікується з іменем користувача, що відповідає CommonName, та групами, що відповідають організації у клієнтському сертифікаті.

MemoryReservation

Зʼявляється в:

MemoryReservation визначає різні типи резервування памʼяті для кожного взула NUMA.

ПолеОпис
numaNode [Обовʼязково]
int32
Номер NUMA вузла, для якого задається резервування памʼяті.
limits [Обовʼязково]
core/v1.ResourceList
Список ресурсів для резервування, які визначають обмеження памʼяті.

MemorySwapConfiguration

ЗустрЗʼявляється в:

ПолеОпис
swapBehavior
string

swapBehavior налаштовує використання swap-пам’яті для контейнерних навантажень. Може бути однією з таких опцій:

  • "" (порожнє).
  • "NoSwap": Навантаження не можуть використовувати swap. Стандартно
  • "LimitedSwap": Використання swap для навантажень обмежене. Ліміт swap пропорційний запиту пам’яті контейнера.

ResourceChangeDetectionStrategy

(Аліас string)

ЗустрЗʼявляється в:

ResourceChangeDetectionStrategy позначає режим, у якому внутрішні менеджери (секрети, configmap) виявляють зміни об’єктів.

ShutdownGracePeriodByPodPriority

ЗустрЗʼявляється в:

ShutdownGracePeriodByPodPriority визначає період належного завершення перед завершенням роботи для Podʼів на основі їхнього значення пріоритету.

ПолеОпис
priority [Обовʼязкове]
int32

priority — це значення пріоритету, яке повʼязане з періодом належного завершення перед завершенням роботи

shutdownGracePeriodSeconds [Обовʼязкове]
int64

shutdownGracePeriodSeconds — це період належного завершення перед завершенням роботи в секундах

6.14.19 - Kubelet CredentialProvider (v1)

Типи ресурсів

CredentialProviderRequest

CredentialProviderRequest включає образ, для якого kubelet вимагає автентифікацію. Kubelet передасть цей обʼєкт запиту втулку через stdin. Загалом втулки повинні відповідати тією ж версією API, яку вони отримали.

ПолеОпис
apiVersion
string
credentialprovider.kubelet.k8s.io/v1
kind
string
CredentialProviderRequest
image [Обовʼязкове]
string

image — це образ контейнеа, який завантажується в рамках запиту втулка для автентифікатора. Втулки можуть за бажанням розпарсити образ для отримання будь-якої інформації, необхідної для отримання облікових даних.

CredentialProviderResponse

CredentialProviderResponse містить облікові дані, які kubelet повинен використовувати для зазначеного образу, наданого в оригінальному запиті. Kubelet буде читати відповідь з втулка через stdout. Ця відповідь повинна бути встановлена на ту ж версію API, що й CredentialProviderRequest.

ПолеОпис
apiVersion
string
credentialprovider.kubelet.k8s.io/v1
kind
string
CredentialProviderResponse
cacheKeyType [Обовʼязкове]
PluginCacheKeyType

cacheKeyType вказує тип ключа кешування для використання на основі образу, наданого в запиті. Є три дійсні значення для типу ключа кешування: Image, Registry і Global. Якщо вказано недійсне значення, kubelet не буде використовувати відповідь.

cacheDuration
meta/v1.Duration

cacheDuration вказує тривалість, впродовж якої облікові дані повинні бути кешовані. Kubelet використовуватиме це поле для налаштування тривалості кешування в пам’яті для облікових даних в AuthConfig. Якщо null, kubelet використовуватиме defaultCacheDuration, надану в CredentialProviderConfig. Якщо встановлено 0, kubelet не буде кешувати наданий AuthConfig.

auth
map[string]AuthConfig

auth — це map, що містить інформацію для автентифікації, передану в kubelet. Кожен ключ є рядком для образу (детальніше про це нижче). Відповідний authConfig має бути дійсним для всіх образів, що відповідають цьому ключу. Втулок повинен встановити це поле в null, якщо не можна повернути дійсні облікові дані для запитаного образу.

Кожен ключ у map є шаблоном, який може містити порт і шлях. Глоби можна використовувати в домені, але не в порті або шляху. Глоби підтримуються як піддомени, такі як '*.k8s.io' або 'k8s.*.io', і домени верхнього рівня, такі як 'k8s.*'. Часткові піддомени, такі як 'app*.k8s.io', також підтримуються. Кожен глоб може відповідати лише одному сегменту піддомена, тому '*.io' не відповідає '*.k8s.io'.

Kubelet буде порівнювати образ з ключем, коли всі з наступного є істинними:

  • Обидва містять однакову кількість частин домену, і кожна частина має збіг.
  • URL шлях imageMatch має бути префіксом цільового URL шляху образу.
  • Якщо imageMatch містить порт, то порт також повинен збігатись в образі.

Коли повертається кілька ключів, kubelet проходитиме через усі ключі у зворотному порядку, щоб:

  • довші ключі з’являються перед коротшими ключами з тим самим префіксом
  • ключі з глобами з’являються перед ключами без глобів з тим самим префіксом.

Для будь-якого відповідного образу kubelet спробує завантажити образ з наданими обліковими даними, зупиняючись після першого успішно автентифікованого завантаження.

Приклади ключів:

  • 123456789.dkr.ecr.us-east-1.amazonaws.com
  • *.azurecr.io
  • gcr.io
  • *.*.registry.io
  • registry.io:8080/path

AuthConfig

Зустрічається в:

AuthConfig містить інформацію для автентифікації для реєстру контейнерів. Сьогодні підтримується тільки автентифікація на основі імені користувача та пароля, але в майбутньому можуть бути додані інші механізми автентифікації.

ПолеОпис
username [Обовʼязкове]
string

username — це імʼя користувача, яке використовується для автентифікації в реєстрі контейнерів. Порожнє імʼя користувача є дійсним.

password [Обовʼязкове]
string

password — це пароль, який використовується для автентифікації в реєстрі контейнерів. Порожній пароль є дійсним.

PluginCacheKeyType

(Аліас string)

Зустрічається в:

6.14.20 - WebhookAdmission Configuration (v1)

Пакунок v1 є версією v1 API.

Типи ресурсів

WebhookAdmission

WebhookAdmission надає конфігурацію для контролера доступу на основі webhook.<

ПолеОпис
apiVersion
string
apiserver.config.k8s.io/v1
kind
string
WebhookAdmission
kubeConfigFile [Обовʼязкове]
string

KubeConfigFile — це шлях до файлу kubeconfig.

6.15 - Зовнішні API

6.15.1 - Kubernetes Custom Metrics (v1beta2)

Пакунок v1beta2 - це версія v1beta2 API custom_metrics.

Типи ресурсів

MetricListOptions

MetricListOptions використовується для вибору метрик за їх селекторами міток

ПолеОпис
apiVersion
string
custom.metrics.k8s.io/v1beta2
kind
string
MetricListOptions
labelSelector
string

Селектор для обмеження списку обʼєктів, що повертаються, за їхніми мітками. Стандартно — всі обʼєкти.

metricLabelSelector
string

Селектор для обмеження списку метрик, що повертаються, за їхніми мітками

MetricValue

Зʼявляється в:

MetricValue — це значення метрики для певного обʼєкта.

ПолеОпис
apiVersion
string
custom.metrics.k8s.io/v1beta2
kind
string
MetricValue
describedObject [Обовʼязково]
core/v1.ObjectReference

посилання на описуваний обʼєкт

metric [Обовʼязково]
MetricIdentifier
Опис відсутній.
timestamp [Обовʼязково]
meta/v1.Time

вказує час, коли були створені метрики

windowSeconds [Обовʼязково]
int64

вказує на вікно ([Timestamp-Window, Timestamp]), з якого були розраховані ці метрики, при поверненні показника метрики, розраховані з кумулятивних метрик (або нуль для нерозрахованих миттєвих метрик).

value [Обовʼязково]
k8s.io/apimachinery/pkg/api/resource.Quantity

значення метрики для цього обʼєкта

MetricValueList

MetricValueList — це список значень для даної метрики для певного набору обʼєктів

ПолеОпис
apiVersion
string
custom.metrics.k8s.io/v1beta2
kind
string
MetricValueList
metadata [Обовʼязково]
meta/v1.ListMeta
Опис відсутній.
items [Обовʼязково]
[]MetricValue

значення метрики для описаних обʼєктів

MetricIdentifier

Зʼявляється в:

MetricIdentifier ідентифікує метрику за назвою та, за потреби, селектором.

ПолеОпис
name [Обовʼязково]
string

name - це назва даної метрики

selector
meta/v1.LabelSelector

selector представляє селектор міток, який можна використати для вибору цієї метрики, і зазвичай буде просто селектором, переданим у запиті для отримання цієї метрики. Якщо залишити порожнім, для збору метрик буде використано лише назву метрики.

6.15.2 - Kubernetes External Metrics (v1beta1)

Пакет v1beta1 є версією v1beta1 зовнішнього API метрик.

Типи ресурсів

ExternalMetricValue

Зʼявляється в:

ExternalMetricValue — це значення метрики для зовнішньої метрики. Окрема метрика ідентифікується за назвою метрики та набором рядкових міток. Для однієї метрики може бути кілька значень з різними наборами міток.

ПолеОпис
apiVersion
string
external.metrics.k8s.io/v1beta1
kind
string
ExternalMetricValue
metricName [Обовʼязково]
string

назва метрики

metricLabels [Обовʼязково]
map[string]string

набір міток, які ідентифікують один часовий ряд для метрики

timestamp [Обовʼязково]
meta/v1.Time

вказує час, коли були створені метрики

window [Обовʼязково]
int64

вказує на вікно ([Timestamp-Window, Timestamp]), з якого були розраховані ці метрики, при поверненні показника метрики, розраховані з кумулятивних метрик (або нуль для нерозрахованих миттєвих метрик).

value [Обовʼязково]
k8s.io/apimachinery/pkg/api/resource.Quantity

значення метрики

ExternalMetricValueList

ExternalMetricValueList — це список значень для даної метрики для певного набору міток

ПолеОпис
apiVersion
string
external.metrics.k8s.io/v1beta1
kind
string
ExternalMetricValueList
metadata [Обовʼязково]
meta/v1.ListMeta
Опис відсутній.
items [Обовʼязково]
[]ExternalMetricValue

значення метрики для відповідного набору міток

6.15.3 - Kubernetes Metrics (v1beta1)

Пакет v1beta1 є версією v1beta1 API метрик.

Типи ресурсів

NodeMetrics

Зʼявляється в:

NodeMetrics встановлює метрики використання ресурсів вузла.

ПолеОпис
apiVersion
string
metrics.k8s.io/v1beta1
kind
string
NodeMetrics
metadata
meta/v1.ObjectMeta

Стандартні метадані обʼєкта. Більше інформації: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

Звіряйтесь з документацією Kubernetes API для полів metadata.
timestamp [Обовʼязково]
meta/v1.Time

Наступні поля визначають інтервал часу, з якого метрики були зібрані, з інтервалу [Timestamp-Window, Timestamp].

window [Обовʼязково]
meta/v1.Duration
Опис відсутній.
usage [Обовʼязково]
core/v1.ResourceList

Використання памʼяті — це робочий набір памʼяті.

NodeMetricsList

NodeMetricsList — це список NodeMetrics.

ПолеОпис
apiVersion
string
metrics.k8s.io/v1beta1
kind
string
NodeMetricsList
metadata [Обовʼязково]
meta/v1.ListMeta

Стандартні метадані списку. Більше інформації: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds

items [Обовʼязково]
[]NodeMetrics

Список метрик вузла.

PodMetrics

Зʼявляється в:

PodMetrics встановлює метрики використання ресурсів Pod.

ПолеОпис
apiVersion
string
metrics.k8s.io/v1beta1
kind
string
PodMetrics
metadata
meta/v1.ObjectMeta

Стандартні метадані обʼєкта. Більше інформації: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

Звіряйтесь з документацією Kubernetes API для полів metadata.
timestamp [Обовʼязково]
meta/v1.Time

Наступні поля визначають інтервал часу, з якого метрики були зібрані, з інтервалу [Timestamp-Window, Timestamp].

window [Обовʼязково]
meta/v1.Duration
Опис відсутній.
containers [Обовʼязково]
[]ContainerMetrics

Метрики для всіх контейнерів збираються в одному часовому інтервалі.

PodMetricsList

PodMetricsList — це список PodMetrics.

ПолеОпис
apiVersion
string
metrics.k8s.io/v1beta1
kind
string
PodMetricsList
metadata [Обовʼязково]
meta/v1.ListMeta

Стандартні метадані списку. Більше інформації: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds

items [Обовʼязково]
[]PodMetrics

Список метрик поду.

ContainerMetrics

Зʼявляється в:

ContainerMetrics встановлює метрики використання ресурсів контейнера.

ПолеОпис
name [Обовʼязково]
string

Назва контейнера відповідає тій, що з pod.spec.containers.

usage [Обовʼязково]
core/v1.ResourceList

Використання памʼяті — це робочий набір памʼяті.

6.16 - Планування

6.16.1 - Налаштування Планувальника

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.25 [stable]

Ви можете налаштувати поведінку kube-scheduler, написавши конфігураційний файл і передавши його шлях як аргумент командного рядка.

Профіль планування дозволяє налаштувати різні етапи планування в kube-scheduler. Кожен етап відображається в точці розширення. Втулки забезпечують поведінку планування, реалізуючи одну або кілька таких точок розширення.

Ви можете вказати профілі планування, запустивши kube-scheduler --config <filename>, використовуючи структуру KubeSchedulerConfiguration v1.

Мінімальна конфігурація виглядає наступним чином:

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
clientConnection:
  kubeconfig: /etc/srv/kubernetes/kube-scheduler/kubeconfig

Профілі

Профіль планування дозволяє налаштувати різні етапи планування в kube-scheduler. Кожен етап відображається в точці розширення. втулки забезпечують поведінку планування, реалізуючи одну або кілька таких точок розширення.

Ви можете налаштувати один екземпляр kube-scheduler для роботи з декількома профілями.

Точки розширення

Планування відбувається в кілька етапів, які відображаються через такі точки розширення:

  1. queueSort: Ці втулки надають функцію впорядкування, яка використовується для сортування очікуваних Podʼів у черзі планування. Тільки один втулок сортування черги може бути ввімкнений одночасно.
  2. preFilter: Ці втулки використовуються для попередньої обробки або перевірки інформації про Pod або кластер перед фільтрацією. Вони можуть позначити Pod як непридатний для планування.
  3. filter: Ці втулки еквівалентні Предикатам у політиці планування і використовуються для відсівання вузлів, які не можуть запустити Pod. Фільтри викликаються в налаштованому порядку. Pod позначається як непридатний для планування, якщо жоден вузол не пройшов усі фільтри.
  4. postFilter: Ці втулки викликаються в налаштованому порядку, коли для Pod не знайдено відповідних вузлів. Якщо будь-який втулок postFilter позначає Pod як придатний для планування, решта втулків не викликаються.
  5. preScore: Це інформаційна точка розширення, яка може використовуватися для попередньої оцінки.
  6. score: Ці втулки надають оцінку кожному вузлу, який пройшов етап фільтрації. Планувальник обере вузол з найвищою сумою зважених оцінок.
  7. reserve: Це інформаційна точка розширення, яка повідомляє втулки, коли ресурси були зарезервовані для певного Podʼа. Втулки також реалізують виклик Unreserve, який викликається у випадку невдачі під час або після Reserve.
  8. permit: Ці втулки можуть запобігти або затримати привʼязку Podʼа.
  9. preBind: Ці втулки виконують будь-які роботи, необхідні перед привʼязкою Podʼа.
  10. bind: втулки привʼязують Pod до вузла. втулки bind викликаються в порядку, і як тільки один з них виконає привʼязку, решта втулків пропускаються. Принаймні один втулок привʼязки обовʼязковий.
  11. postBind: Це інформаційна точка розширення, яка викликається після привʼязки Podʼа.
  12. multiPoint: Це поле тільки для конфігурації, які дозволяють ввімкнути або вимкнути втулки для всіх їх застосовних точок розширення одночасно.

Для кожної точки розширення ви можете вимкнути конкретні стандартні втулки або ввімкнути власні. Наприклад:

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
  - plugins:
      score:
        disabled:
        - name: PodTopologySpread
        enabled:
        - name: MyCustomPluginA
          weight: 2
        - name: MyCustomPluginB
          weight: 1

Ви можете використовувати * як імʼя в масиві вимкнених втулків, щоб вимкнути всі стандартні втулки для цієї точки розширення. Це також може бути використано для зміни порядку втулків, якщо це необхідно.

Втулки планування

Наступні втулки, які стандартно увімкнені, реалізують одну або більше з цих точок розширення:

  • ImageLocality: Віддає перевагу вузлам, які вже мають образи контейнерів, що запускаються Podʼом. Точки розширення: score.
  • TaintToleration: Реалізує taints and tolerations. Реалізує точки розширення: filter, preScore, score.
  • NodeName: Перевіряє, чи відповідає імʼя вузла у специфікації Podʼа поточному вузлу. Точки розширення: filter.
  • NodePorts: Перевіряє, чи має вузол вільні порти для запитуваних портів Podʼа. Точки розширення: preFilter, filter.
  • NodeAffinity: Реалізує node selectors та node affinity. Точки розширення: filter, score.
  • PodTopologySpread: Реалізує обмеження поширення топології Podʼів. Точки розширення: preFilter, filter, preScore, score.
  • NodeUnschedulable: Відфільтровує вузли, які мають .spec.unschedulable встановлений на true. Точки розширення: filter.
  • NodeResourcesFit: Перевіряє, чи має вузол усі ресурси, які запитує Pod. Оцінка може використовувати одну з трьох стратегій: LeastAllocated (стандартно), MostAllocated та RequestedToCapacityRatio. Точки розширення: preFilter, filter, score.
  • NodeResourcesBalancedAllocation: Віддає перевагу вузлам, які отримають більш збалансоване використання ресурсів, якщо Pod буде заплановано на них. Точки розширення: score.
  • VolumeBinding: Перевіряє, чи має вузол або чи може звʼязати запитувані томи. Точки розширення: preFilter, filter, reserve, preBind, score.
  • VolumeRestrictions: Перевіряє, чи задовольняють томи, змонтовані на вузлі, обмеження, специфічні для постачальника томів. Точки розширення: filter.
  • VolumeZone: Перевіряє, чи задовольняють запитувані томи будь-які вимоги до зони, які вони можуть мати. Точки розширення: filter.
  • NodeVolumeLimits: Перевіряє, чи можуть бути задоволені ліміти томів CSI для вузла. Точки розширення: filter.
  • EBSLimits: Перевіряє, чи можуть бути задоволені ліміти томів AWS EBS для вузла. Точки розширення: filter.
  • GCEPDLimits: Перевіряє, чи можуть бути задоволені ліміти томів GCP-PD для вузла. Точки розширення: filter.
  • AzureDiskLimits: Перевіряє, чи можуть бути задоволені ліміти томів дисків Azure для вузла. Точки розширення: filter.
  • InterPodAffinity: Реалізує між-Podʼову спорідненість та антиспорідненість. Точки розширення: preFilter, filter, preScore, score.
  • PrioritySort: Забезпечує стандартне сортування за пріоритетами. Точки розширення: queueSort.
  • DefaultBinder: Забезпечує стандартний механізм привʼязки. Точки розширення: bind.
  • DefaultPreemption: Забезпечує стандартний механізм попередження. Точки розширення: postFilter.

Ви також можете ввімкнути наступні втулки через API конфігурації компонентів, які не увімкнені стандартно:

  • CinderLimits: Перевіряє, чи можуть бути задоволені ліміти томів OpenStack Cinder для вузла. Точки розширення: filter.

Декілька профілів

Ви можете налаштувати kube-scheduler для роботи з декількома профілями. Кожен профіль має повʼязане імʼя планувальника і може мати різний набір втулків, налаштованих у його точках розширення.

З наступною зразковою конфігурацією, планувальник буде працювати з двома профілями: один зі стандартними втулками і один з усіма вимкненими втулками скорінгу.

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
  - schedulerName: default-scheduler
  - schedulerName: no-scoring-scheduler
    plugins:
      preScore:
        disabled:
        - name: '*'
      score:
        disabled:
        - name: '*'

Podʼи, які хочуть бути заплановані відповідно до певного профілю, можуть включати відповідне імʼя планувальника у своїй .spec.schedulerName.

Стандартно створюється один профіль з іменем планувальника default-scheduler. Цей профіль включає стандартні втулки, описані вище. При оголошенні більше одного профілю для кожного з них потрібно унікальне імʼя планувальника.

Якщо Pod не вказує імʼя планувальника, kube-apiserver встановить його на default-scheduler. Таким чином, для планування цих Podʼів повинен існувати профіль з цим імʼям планувальника.

Втулки, які застосовуються до декількох точок розширення

Починаючи з kubescheduler.config.k8s.io/v1beta3, у конфігурації профілю є додаткове поле multiPoint, яке дозволяє легко увімкнути або вимкнути втулок для кількох точок розширення. Метою конфігурації multiPoint є спрощення конфігурації для користувачів і адміністраторів при використанні користувацьких профілів.

Розглянемо втулок MyPlugin, який реалізує точки розширення preScore, score, preFilter і filter. Щоб увімкнути MyPlugin для всіх доступних точок розширення, конфігурація профілю виглядає так:

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
  - schedulerName: multipoint-scheduler
    plugins:
      multiPoint:
        enabled:
        - name: MyPlugin

Це рівносильно ручному ввімкненню MyPlugin для всіх його точок розширення, як показано нижче:

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
  - schedulerName: non-multipoint-scheduler
    plugins:
      preScore:
        enabled:
        - name: MyPlugin
      score:
        enabled:
        - name: MyPlugin
      preFilter:
        enabled:
        - name: MyPlugin
      filter:
        enabled:
        - name: MyPlugin

Однією з переваг використання multiPoint є те, що якщо MyPlugin реалізує іншу точку розширення в майбутньому, конфігурація multiPoint автоматично увімкне його для нової точки розширення.

Конкретні точки розширення можна виключити з розширення MultiPoint за допомогою поля disabled для цієї точки розширення. Це працює з відключенням стандартних втулків, нестандартних втулків або з підстановним знаком ('*') для відключення всіх втулків. Приклад цього, відключення Score і PreScore, виглядає так:

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
  - schedulerName: non-multipoint-scheduler
    plugins:
      multiPoint:
        enabled:
        - name: 'MyPlugin'
      preScore:
        disabled:
        - name: '*'
      score:
        disabled:
        - name: '*'

Починаючи з kubescheduler.config.k8s.io/v1beta3, усі стандартні втулки ввімкнені внутрішньо через MultiPoint. Однак окремі точки розширення все ще доступні, щоб забезпечити гнучке переналаштування стандартних значень (наприклад, порядок і ваги Score). Наприклад, розглянемо два втулки Score DefaultScore1 і DefaultScore2, кожен з вагою 1. Їх можна змінити місцями з різними вагами так:

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
  - schedulerName: multipoint-scheduler
    plugins:
      score:
        enabled:
        - name: 'DefaultScore2'
          weight: 5

У цьому прикладі не потрібно явно вказувати втулки в MultiPoint, оскільки вони є стандартними втулками. І єдиний втулок, вказаний у Score, це DefaultScore2. Це тому, що втулки, встановлені через конкретні точки розширення, завжди матимуть пріоритет перед втулками MultiPoint. Таким чином, цей фрагмент по суті змінює порядок втулків без необхідності вказувати їх усіх.

Загальна ієрархія для пріоритету при налаштуванні втулків MultiPoint є наступною:

  1. Специфічні точки розширення працюють першими, і їх налаштування переважатимуть над налаштуваннями, встановленими деінде.
  2. Втулки, налаштовані вручну через MultiPoint, і їх налаштування.
  3. Стандартні втулки та їх стандартні налаштування.

Щоб продемонструвати наведені вище ієрархії, наступний приклад базується на цих втулках:

ВтулокТочки розширення
DefaultQueueSortQueueSort
CustomQueueSortQueueSort
DefaultPlugin1Score, Filter
DefaultPlugin2Score
CustomPlugin1Score, Filter
CustomPlugin2Score, Filter

Дійсна конфігурація (для зразка) для цих втулків виглядає так:

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
  - schedulerName: multipoint-scheduler
    plugins:
      multiPoint:
        enabled:
        - name: 'CustomQueueSort'
        - name: 'CustomPlugin1'
          weight: 3
        - name: 'CustomPlugin2'
        disabled:
        - name: 'DefaultQueueSort'
      filter:
        disabled:
        - name: 'DefaultPlugin1'
      score:
        enabled:
        - name: 'DefaultPlugin2'

Зверніть увагу, що немає помилки при повторній декларації втулка MultiPoint у конкретній точці розширення. Повторна декларація ігнорується (і логується), оскільки конкретні точки розширення мають пріоритет.

Крім збереження більшості конфігурацій в одному місці, цей приклад виконує кілька речей:

  • Увімкнено спеціальний втулок queueSort і вимкнено стандартний
  • Увімкнено CustomPlugin1 і CustomPlugin2, які будуть виконуватися першими для всіх своїх точок розширення
  • Вимкнено DefaultPlugin1, але тільки для filter
  • Змінено порядок виконання DefaultPlugin2 для роботи першої в score (навіть перед власними втулками)

У версіях конфігурації до v1beta3, без multiPoint, наведений вище фрагмент рівнозначний цьому:

apiVersion: kubescheduler.config.k8s.io/v1beta2
kind: KubeSchedulerConfiguration
profiles:
  - schedulerName: multipoint-scheduler
    plugins:

      # Вимкнути стандартний втулок QueueSort
      queueSort:
        enabled:
        - name: 'CustomQueueSort'
        disabled:
        - name: 'DefaultQueueSort'

      # Увімкнути спеціальні втулки Filter
      filter:
        enabled:
        - name: 'CustomPlugin1'
        - name: 'CustomPlugin2'
        - name: 'DefaultPlugin2'
        disabled:
        - name: 'DefaultPlugin1'

      # Увімкнути та змінити порядок спеціальних втулків score
      score:
        enabled:
        - name: 'DefaultPlugin2'
          weight: 1
        - name: 'DefaultPlugin1'
          weight: 3

Хоча це складний приклад, він демонструє гнучкість конфігурації MultiPoint, а також її безшовну інтеграцію з наявними методами налаштування точок розширення.

Міграції конфігурації планувальника

  • З версією конфігурації v1beta2 можна використовувати нове розширення для втулка NodeResourcesFit. Нове розширення поєднує функціонал втулків NodeResourcesLeastAllocated, NodeResourcesMostAllocated та RequestedToCapacityRatio. Наприклад, якщо ви раніше використовували втулок NodeResourcesMostAllocated, то тепер ви можете використовувати NodeResourcesFit (стандартно увімкнено) і додати pluginConfig зі scoreStrategy, яка виглядає наступним чином:

    apiVersion: kubescheduler.config.k8s.io/v1beta2
    kind: KubeSchedulerConfiguration
    profiles:
    - pluginConfig:
      - args:
          scoringStrategy:
            resources:
            - name: cpu
              weight: 1
            type: MostAllocated
        name: NodeResourcesFit
    
  • Втулок планувальника NodeLabel застарілий; натомість використовуйте втулок NodeAffinity (стандартно увімкнено), щоб досягти схожої поведінки.

  • Втулок планувальника ServiceAffinity застарілий; натомість використовуйте втулок InterPodAffinity (стандартно увімкнено), щоб досягти схожої поведінки.

  • Втулок планувальника NodePreferAvoidPods застарілий; натомість використовуйте node taints, щоб досягти схожої поведінки.

  • Втулок, увімкнений у конфігураційному файлі v1beta2, має пріоритет над стандартною конфігурацією для цього втулка.

  • Недійсні host або port, налаштовані для адреси привʼязки healthz і метрик планувальника, спричинять невдачу валідації.

  • Вага трьох стандартних втулків збільшена:

    • InterPodAffinity з 1 до 2
    • NodeAffinity з 1 до 2
    • TaintToleration з 1 до 3

  • Втулок планувальника SelectorSpread видалений; натомість використовуйте втулок PodTopologySpread (стандартно увімкнено), щоб досягти схожої поведінки.

Що далі

6.16.2 - Політики планування

У версіях Kubernetes до v1.23 політика планування могла використовуватися для вказівки процесу predicates та priorities. Наприклад, ви могли встановити політику планування, запустивши kube-scheduler --policy-config-file <filename> або kube-scheduler --policy-configmap <ConfigMap>.

Ця політика планування не підтримується з Kubernetes v1.23. Споріднені прапорці policy-config-file, policy-configmap, policy-configmap-namespace та use-legacy-policy-config також не підтримуються. Натомість використовуйте Конфігурацію планувальника, щоб досягти схожої поведінки.

Що далі

6.17 - Інші інструменти

Kubernetes містить кілька інструментів, які допоможуть вам працювати з системою Kubernetes.

crictl

crictl — це інтерфейс командного рядка для перегляду та відлагодження оточення виконання контейнерів, сумісних з CRI.

Dashboard

Dashboard, вебінтерфейс Kubernetes, дозволяє розгортати контейнерні застосунки в кластері Kubernetes, розвʼязувати проблеми з ними та управляти кластером та його ресурсами.

Helm

Helm — це інструмент для управління пакунками наперед сконфігурованих ресурсів Kubernetes. Ці пакунки відомі як Helm charts.

Використовуйте Helm для:

  • Пошуку та використання популярного програмного забезпечення, упакованого як Helm charts для Kubernetes
  • Поширення ваших застосунків у вигляді Helm charts
  • Створення відтворюваних збірок вашого застосунку Kubernetes
  • Управління файлами маніфестів Kubernetes
  • Управління випусками пакунків Helm

Kompose

Kompose — це інструмент для допомоги користувачам Docker Compose в переході до Kubernetes.

Використовуйте Kompose для:

  • Перетворення файлу Docker Compose в обʼєкти Kubernetes
  • Переходу від локальної розробки Docker до управління вашим застосунком через Kubernetes
  • Конвертації файлів Docker Compose yaml версій v1 або v2 або Distributed Application Bundles

Kui

Kui — це графічний інструмент, який обробляє ваші звичайні запити командного рядка kubectl та показує вивід в графічному вигляді.

Kui обробляє звичайні запити командного рядка kubectl та показує вивід в графічному вигляді. Замість ASCII-таблиць, Kui надає графічний рендеринг з таблицями, які можна сортувати.

Kui дозволяє вам:

  • Натискати на довгі, автоматично генеровані назви ресурсів, замість копіювання та вставляння
  • Вводити команди kubectl і бачити їх виконання, іноді навіть швидше, ніж в kubectl
  • Запитувати Job та бачити його виконання у вигляді діаграми водоспаду
  • Переходити за ресурсами в вашому кластері за допомогою графічного інтерфейсу користувача

Minikube

minikube — це інструмент, який запускає локальний однокомпонентний кластер Kubernetes безпосередньо на вашому компʼютері для розробки та тестування.

6.17.1 - Зіставлення dockercli з crictl

7 - Беріть участь в розвитку Kubernetes

Існує багато способів як ви можете зробити власний внесок у розвиток Kubernetes. Ви можете працювати над створенням нових функцій, ви можете документувати код, який вже є, ви можете писати для нашого блогу. А ще, ви можете реалізувати нові функції або виправляти помилки. Ви можете допомагати людям приєднатися до нашої спільноти або підтримувати учасників, які приєднались раніше.

З усіма цими різними способами, що дозволяють зробити внесок у проєкт, ми в Kubernetes маємо спеціальний вебсайт: https://k8s.dev/. Ви можете перейти туди, щоб дізнатися більше про участь в розвитку Kubernetes.

Якщо ви конкретно хочете дізнатися про покращення цієї документації, прочитайте Як покращити документацію Kubernetes.

Ви також можете відвідати сторінку CNCF, присвячену участі в проєкті Kubernetes.

7.1 - Покращення документації Kubernetes

Цей вебсайт підтримується робочою групою Kubernetes SIG Docs. Проєкт Kubernetes вітає допомогу від усіх учасників, незалежно від їхнього досвіду!

Учасники, які мають намір працювати з документацією Kubernetes можуть:

  • Вдосконалювати наявний вміст
  • Створювати новий вміст
  • Перекладати документацію
  • Керувати та публікувати документацію під час релізного циклу Kubernetes

Початок роботи

Будь-хто може відкрити тікет щодо документації або внести зміни через запит на злиття (PR) в репозиторій GitHub kubernetes/website. Для ефективної роботи в спільноті Kubernetes вам слід вміти працювати з git та GitHub.

Для того, щоб долучитись до роботи з документацією:

  1. Ознайомтесь та підпишіть CNCF Contributor License Agreement.
  2. Ознайомтесь з репозиторієм документації та генератором статичних вебсайтів.
  3. Переконайтесь, що ви розумієте базові вимоги щодо відкриття запиту на злиття та процесу рецензування змін.

flowchart TB subgraph third[Створення PR] direction TB U[ ] -.- Q[Зробіть покращення] --- N[Створіть новий
вміст] N --- O[Перекладіть
документацію] O --- P[Керуйте/Публікуйте
документацію релізного
циклу K8s] end subgraph second[Огляд] direction TB T[ ] -.- D[Огляньте репозиторій
kubernetes/website] --- E[Ознайомтесь з
генератором статичних
сайтів Hugo] E --- F[Оновіть відомості про
основні команди GitHub] F --- G[Робіть огляд
відкритих PR
та змін] end subgraph first[Реєстрація] direction TB S[ ] -.- B[Підпишіть CNCF
Contributor
License Agreement] --- C[Приєднайтесь до
каналу sig-docs
в Slack] C --- V[Приєднайтесь до
списку розсилки
kubernetes-sig-docs] V --- M[Відвідуйте тижневі
заходи sig-docs
чи зустрічі в slack] end A([fa:fa-user Новий
учасник]) --> first A --> second A --> third A --> H[Ставте питання!!!] classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px; classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000 class A,B,C,D,E,F,G,H,M,Q,N,O,P,V grey class S,T,U spacewhite class first,second,third white
Схема 1. Початок роботи для нового учасника.

На схемі 1 зображено шлях для нового учасника. Ви можете виконати деякі або всі етапи з Реєстрації та Огляду. Тепер ви готові відкривати PR (запити на злиття), щоб досягти своїх цілей, деякі з яких перелічені в Створення PR. Знову ж таки, не соромтесь ставити питання, питання завжди вітаються!

Деякі завдання вимагають більшого рівня довіри та більшого доступу в організації Kubernetes. Докладнішу інформацію щодо ролей та дозволів дивіться в розділі Участь в SIG Docs.

Ваш перший внесок

Ви можете підготуватися до свого першого внеску, розглянувши кілька кроків перед тим. Схема 2 описує кроки, а опис міститься далі.

flowchart LR subgraph second[Перший внесок] direction TB S[ ] -.- G[Зробіть огляд PR
від інших учасників K8s] --> A[Ознайомтесь з переліком тікетів
на kubernetes/website
щоб знайти щось для першого PR] --> B[Створіть PR!!] end subgraph first[Підготовчі кроки] direction TB T[ ] -.- D[Ознайомтесь з описом внеску] -->E[Ознайомтесь з настановами
щодо вмісту та стилю K8s] E --> F[Дізнайтесь про типи вмісту
сторінок Hugo та
їх shortcodes] end first ----> second classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px; classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000 class A,B,D,E,F,G grey class S,T spacewhite class first,second white
Схема 2. Підготовка до першого внеску.

Отримання допомоги щодо участі

Зробити перший внесок може бути дуже складно. Помічники для нових учасників (New Contributor Ambassador) готові провести вас через створення вашого першого внеску. Ви можете звертатися до них в Slack Kubernetes, переважно в каналі #sig-docs. Також є Зустрічі з новими учасниками, яка відбувається першого вівторка кожного місяця. Ви можете спілкуватися з помічниками для нових учасників та отримати відповіді на свої запитання там.

Наступні кроки

Приєднуйтеся до SIG Docs

SIG Docs — це група учасників, які публікують та підтримують документацію Kubernetes та цей вебсайт. Участь в SIG Docs — це гарний спосіб для учасників Kubernetes (розробка функцій чи інше) зробити значний внесок у проєкт Kubernetes.

SIG Docs спілкується за допомогою різних інструментів:

Інші способи зробити внесок

7.2 - Пропозиції щодо покращення вмісту

Якщо ви помітили проблему з документацією Kubernetes або маєте ідею для нового контенту, створіть тікет. Все, що вам потрібно, це обліковий запис на GitHub та вебоглядач.

У більшості випадків нова робота над документацією Kubernetes починається з тікета на GitHub. Потім учасники Kubernetes переглядають, класифікують та теґують проблеми за потреби. Після цього, ви або інший учасник спільноти Kubernetes відкриваєте pull request зі змінами, щоб розвʼязати проблему.

Створення issue

Якщо ви хочете запропонувати покращення наявного контенту або помітили помилку, створіть тікет.

  1. Натисніть Створити тікет на правій боковій панелі. Це перенаправить вас на сторінку issue на GitHub з попередньо заповненими заголовками.
  2. Опишіть проблему або пропозицію щодо покращення. Надайте якнайбільше деталей.
  3. Натисніть Submit new issue.

Після подання періодично перевіряйте свій тікет або увімкніть сповіщення GitHub. Рецензенти та інші члени спільноти можуть ставити питання перед тим, як вжити заходів щодо вашого тікета.

Пропозиція нового контенту

Якщо у вас є ідея для нового контенту, але ви не впевнені, де його розмістити, ви все одно можете подати тікет. Або:

  • Виберіть наявну сторінку в розділі, до якого, на вашу думку, належить контент, і натисніть Створити тікет.
  • Перейдіть на GitHub та створіть тікет там.

Як подавати тікети

Майте на увазі наступне під час подання тікета:

  • Надайте чіткий опис проблеми. Опишіть, що саме відсутнє, застаріле, неправильне або потребує покращення.
  • Поясніть конкретний вплив проблеми на користувачів.
  • Обмежте обсяг певного тікета до розумного обсягу роботи. Для проблем великого обсягу розбийте їх на менші тікети. Наприклад, "Виправити документацію з безпеки" занадто широке, а "Додати деталі до теми 'Обмеження доступу до мережі'" достатньо конкретне формулювання, щоб бути здійсненним.
  • Пошукайте наявні тікети, щоб побачити, чи є щось повʼязане або схоже на новий тікет.
  • Якщо новий тікет стосується іншого тікета або pull request, посилайтеся на нього або через повну URL-адресу, або через номер тікета або pull request з префіксом #. Наприклад, Introduced by #987654.
  • Дотримуйтесь Кодексу поведінки. Поважайте інших учасників. Наприклад, "Документація жахлива" — це є корисним чи ввічливим відгуком.

7.3 - Створення нового контенту

Цей розділ містить інформацію, яку слід знати перед тим, як створювати новий контент.

flowchart LR subgraph second[Перш ніж розпочати] direction TB S[ ] -.- A[Підпишіть CNCF CLA] --> B[Оберіть гілку Git] B --> C[Одна мова на PR] C --> F[Ознайомтесь з
інструментами для участі] end subgraph first[Основи участі] direction TB T[ ] -.- D[Пишіть документи в markdown
та збирайте сайт за допомогою Hugo] --- E[сирці на GitHub] E --- G[Тека '/content/../docs' містить документи
для кількох мов] G --- H[Ознайомтесь з типом вмісту сторінок Hugo
та shortcodes] end first ----> second classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px; classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000 class A,B,C,D,E,F,G,H grey class S,T spacewhite class first,second white

Схема — Підготовка до створення нового контенту

Вище показана інформація, яку слід знати перед надсиланням нового контенту. Деталі наведені нижче.

Основи участі

  • Пишіть документацію Kubernetes у Markdown та збирайте сайт Kubernetes за допомогою Hugo.
  • Документація Kubernetes використовує CommonMark варіант Markdown.
  • Сирці знаходяться на GitHub. Ви можете знайти документацію Kubernetes в /content/en/docs/. Частина довідкової документації автоматично генерується зі скриптів у теці update-imported-docs/.
  • Типи вмісту сторінок описують вигляд вмісту документації в Hugo.
  • Ви можете використовувати Docsy shortcodes або власні Hugo shortcodes, щоб зробити внесок у документацію Kubernetes.
  • Крім стандартних Hugo shortcodes, ми використовуємо кілька власних Hugo shortcodes у нашій документації для керування процесом обробки вмісту.
  • Сирці документації доступні кількома мовами в /content/. Кожна мова має свою теку з дволітерним кодом, визначеним ISO 639-1 стандартом. Наприклад, сирці документації англійською мовою зберігається в /content/en/docs/, української — /content/uk/docs/, відповідно.
  • Для отримання додаткової інформації про роботу з документацією кількома мовами або початку нової локалізації, див. локалізація.

Перш ніж розпочати

Підпишіть CNCF CLA

Усі учасники Kubernetes повинні ознайомитись з Настановами для учасників та підписати Угоду про ліцензування внесків (CLA, Contributor License Agreement).

Pull requests від учасників, які не підписали CLA, не пройдуть автоматизовані тести. Імʼя та електронна адреса, які ви надаєте, повинні збігатися з тими, що знаходяться у вашій конфігурації git config, а ваше імʼя та електронна адреса в git повинні збігатися з тими, що використовуються для CNCF CLA.

Оберіть гілку Git для використання

Відкриваючи pull request, ви повинні заздалегідь знати, яку гілку взяти за основу для своєї роботи.

СценарійГілка
Поточний або новий контент англійською мовою для поточного випускуmain
Контент для випуску змін функційГілка, яка відповідає основній та мінорній версії, у якій відбувається зміна функцій, використовуючи шаблон dev-<version>. Наприклад, якщо функція змінюється у випуску v1.32, то додайте зміни до документації у гілку dev-1.32.
Контент іншими мовами (локалізація)Використовуйте домовленості локалізації. Див. Стратегію створення гілок локалізації для отримання додаткової інформації.

Якщо ви все ще не впевнені, яку гілку обрати, запитайте у #sig-docs в Slack.

Мови в одному PR

Обмежуйте pull requests однією мовою на PR. Якщо вам потрібно внести однакові зміни до одного і того ж зразка коду кількома мовами, відкрийте окремий PR для кожної мови.

Інструменти

Тека інструменти для учасників в репозиторії kubernetes/website містить інструменти, які допоможуть зробити вашу участь в створенні документації простішою.

7.3.1 - Створення pull request

Щоб створити нові сторінки або покращити наявні, відкрийте pull request (PR). Переконайтеся, що ви виконали всі вимоги у розділі Перш ніж почати.

Якщо ваша зміна невелика або ви незнайомі з git, прочитайте Зміни за допомогою GitHub, щоб дізнатися, як редагувати сторінку.

Якщо ваші зміни значні, прочитайте Робота з локальним форком, щоб дізнатися, як внести зміни локально на вашому компʼютері.

Зміни за допомогою GitHub

Якщо ви менш досвідчені з робочими процесами git, ось легший спосіб відкрити pull request. На схемі 1 описані кроки, а деталі наведені нижче.

flowchart LR A([fa:fa-user Новий
учасник]) --- id1[(kubernetes/website
GitHub)] subgraph tasks[Зміни за допомогою GitHub] direction TB 0[ ] -.- 1[1. Редагувати цю сторінку] --> 2[2. Використовуйте GitHub markdown
редактор для внесення змін] 2 --> 3[3. Заповніть форму Propose file change] end subgraph tasks2[ ] direction TB 4[4. оберіть Propose file change] --> 5[5. оберіть Create pull request] --> 6[6. заповніть форму Open a pull request] 6 --> 7[7. оберіть Create pull request] end id1 --> tasks --> tasks2 classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px; classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold classDef k8s fill:#326ce5,stroke:#fff,stroke-width:1px,color:#fff; classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000 class A,1,2,3,4,5,6,7 grey class 0 spacewhite class tasks,tasks2 white class id1 k8s

Схема 1. Кроки для відкриття PR за допомогою GitHub.

  1. На сторінці, де ви бачите проблему, виберіть опцію Відредагувати сторінку на панелі праворуч.

  2. Внесіть зміни у GitHub markdown редакторі.

  3. Під редактором заповніть форму Propose file change. У першому полі дайте заголовок вашому повідомленню коміту. У другому полі надайте опис.

  4. Оберіть Propose file change.

  5. Оберіть Create pull request.

  6. Зʼявиться екран Open a pull request. Заповніть форму:

    • Поле Subject pull request стандартно містить заголовок коміту. Ви можете змінити його за потреби.
    • Поле Body містить розширене повідомлення коміту, якщо у вас є, і деякий текст шаблону. Додайте деталі, які вимагає текст шаблону, потім видаліть зайвий текст шаблону.
    • Залиште прапорець Allow edits from maintainers увімкненим.
  7. Оберіть Create pull request.

Робота з відгуками на GitHub

Перед злиттям pull request члени спільноти Kubernetes рецензують та схвалюють його. k8s-ci-robot пропонує рецензентів на основі найближчого власника, зазначеного на сторінках. Якщо у вас є конкретна людина на думці, залиште коментар із її імʼям користувача на GitHub.

Якщо рецензент попросить вас внести зміни:

  1. Перейдіть на вкладку Files changed.
  2. Виберіть іконку олівця (редагування) на будь-якому файлі, зміненому pull request.
  3. Внесіть запитані зміни.
  4. Збережіть зміни.

Якщо ви чекаєте на рецензента, виходьте на звʼязок хоча б раз на 7 днів. Ви також можете залишити повідомлення у каналі #sig-docs на Slack.

Коли рецензування буде завершено, рецензент зіллє ваш PR і ваші зміни стануть доступними через кілька хвилин.

Робота з локальним форком

Якщо ви більш досвідчені з git або ваші зміни більші за кілька рядків, працюйте з локальним форком.

Переконайтеся, що на вашому компʼютері встановлений git. Ви також можете використовувати застосунок, що є інтерфейсом користувача для git.

Схема 2 показує кроки, які слід виконати під час роботи з локальним форком. Деталі кожного кроку наведені нижче.

flowchart LR 1[Форк репо kubernetes/website] --> 2[Створіть локальну копію
і встановіть upstream] subgraph changes[Ваші зміни] direction TB S[ ] -.- 3[Створіть гілку
наприклад: my_new_branch] --> 3a[Внесіть зміни за допомогою
текстового редактора] --> 4["Перегляньте зміни
локально за допомогою Hugo
(localhost:1313)
або створіть образ контейнера"] end subgraph changes2[Коміт / Push] direction TB T[ ] -.- 5[Збережіть коміт] --> 6[Надішліть коміт до
origin/my_new_branch] end 2 --> changes --> changes2 classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px; classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold classDef k8s fill:#326ce5,stroke:#fff,stroke-width:1px,color:#fff; classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000 class 1,2,3,3a,4,5,6 grey class S,T spacewhite class changes,changes2 white

Схема 2. Робота з локальним форком для внесення змін.

Форк репозиторію kubernetes/website

  1. Перейдіть до репозиторію kubernetes/website.
  2. Оберіть Fork.

Створення локальної копії та встановлення upstream

  1. У вікні термінала, клонуйте ваш форк та оновіть тему [Docsy Hugo(https://github.com/google/docsy#readme)]:

    git clone git@github.com:<github_username>/website.git
    cd website
    git submodule update --init --recursive --depth 1
    
  2. Перейдіть до нової теки website. Встановіть репозиторій kubernetes/website як upstream remote:

    cd website
    
    git remote add upstream https://github.com/kubernetes/website.git
    
  3. перевірте ваші origin та upstream репозиторії:

    git remote -v
    

    Вихід буде подібним до:

    origin	git@github.com:<github_username>/website.git (fetch)
    origin	git@github.com:<github_username>/website.git (push)
    upstream	https://github.com/kubernetes/website.git (fetch)
    upstream	https://github.com/kubernetes/website.git (push)
    
  4. Отримайте коміти з origin/main вашого форка та upstream/main з kubernetes/website:

    git fetch origin
    git fetch upstream
    

    Це забезпечить актуальність вашого локального репозиторію перед тим, як ви почнете вносити зміни.

Створення гілки

  1. Виберіть гілку, на якій буде базуватись ваша робота:

    • Для покращення наявного контенту використовуйте upstream/main.
    • Для нового контенту про наявні функції використовуйте upstream/main.
    • Для локалізованого контенту дотримуйтесь домовленостей з локалізації. Для додаткової інформації дивіться локалізацію документації Kubernetes.
    • Для нових функцій у майбутньому випуску Kubernetes використовуйте гілку функцій. Для додаткової інформації дивіться документування релізу.
    • Для довготривалих ініціатив, над якими співпрацюють кілька учасників SIG Docs, таких як реорганізація контенту, використовуйте спеціальну гілку, створену для цього.

    Якщо вам потрібна допомога з вибором гілки, запитайте у каналі #sig-docs в Slack.

  2. Створіть нову гілку на основі гілки, визначеної на кроці 1. Цей приклад передбачає, що базова гілка — upstream/main:

    git checkout -b <my_new_branch> upstream/main
    
  3. Внесіть свої зміни за допомогою текстового редактора.

У будь-який час використовуйте команду git status, щоб побачити, які файли ви змінили.

Збереження змін

Коли ви готові подати pull request, збережіть ваші зміни.

  1. У вашому локальному репозиторії перевірте, які файли потрібно зберегти в репо:

    git status
    

    Вихід буде подібним до:

    On branch <my_new_branch>
    Your branch is up to date with 'origin/<my_new_branch>'.
    
    Changes not staged for commit:
    (use "git add <file>..." to update what will be committed)
    (use "git checkout -- <file>..." to discard changes in working directory)
    
    modified:   content/en/docs/contribute/new-content/contributing-content.md
    
    no changes added to commit (use "git add" and/or "git commit -a")
    
  2. Додайте файли, зазначені під Changes not staged for commit, до коміту:

    git add <your_file_name>
    

    Повторіть це для кожного файлу.

  3. Після додавання всіх файлів створіть коміт:

    git commit -m "Ваше коміт-повідомлення"
    
  4. Надішліть вашу локальну гілку та її новий коміт до вашого віддаленого форку:

    git push origin <my_new_branch>
    

Попередній локальний перегляд змін

Рекомендується попередньо переглянути ваші зміни локально перед тим, як надсилати їх або відкривати pull request. Попередній перегляд дозволяє виявити помилки збирання або проблеми з форматуванням Markdown.

Ви можете або зібрати образ контейнера вебсайту, або запустити Hugo локально. Збирання образу контейнера повільніше, але працює з Hugo shortcodes, що може бути корисним для налагодження.

  1. Зберіть образ контейнера локально Вам потрібен цей крок лише якщо ви тестуєте зміни до самого Hugo

    # Виконайте це в терміналі (якщо потрібно)
    make container-image
    
  2. Запустіть Hugo у контейнері:

    # Виконайте це в терміналі
    make container-serve
    
  3. У веббраузері перейдіть на https://localhost:1313. Hugo стежить за змінами та перебудовує сайт за потреби.

  4. Щоб зупинити локальний екземпляр Hugo, поверніться до термінала та натисніть Ctrl+C, або закрийте вікно термінала.

Альтернативно, встановіть і використовуйте команду hugo на вашому компʼютері:

  1. Встановіть версію Hugo, вказану у файлі website/netlify.toml.

  2. Якщо ви не оновили свій репозиторій вебсайту, тека website/themes/docsy є порожньою. Сайт не може зібратися без локальної копії теми. Щоб оновити тему вебсайту, виконайте:

    git submodule update --init --recursive --depth 1
    
  3. У терміналі перейдіть до вашого репозиторію вебсайту Kubernetes та запустіть сервер Hugo:

    cd <path_to_your_repo>/website
    hugo server --buildFuture
    
  4. У веббраузері перейдіть на https://localhost:1313. Hugo стежить за змінами та перебудовує сайт за потреби.

  5. Щоб зупинити локальний екземпляр Hugo, поверніться до термінала та натисніть Ctrl+C, або закрийте вікно термінала.

Відкриття pull request з вашого форку в kubernetes/website

На схемі 3 показано кроки для створення PR із вашого форку в kubernetes/website. Подробиці наведені нижче.

Зверніть увагу, що учасники можуть також згадувати kubernetes/website як k/website.

flowchart LR subgraph first[ ] direction TB 1[1. Перейдіть до репозиторію kubernetes/website] --> 2[2. Оберіть New Pull Request] 2 --> 3[3. Оберіть compare across forks] 3 --> 4[4. Оберіть ваш форк з
меню head repository] end subgraph second [ ] direction TB 5[5. Оберіть вашу гілку з
меню compare] --> 6[6. Оберіть Create Pull Request] 6 --> 7[7. Додайте опис
до вашого PR] 7 --> 8[8. Оберіть Create pull request] end first --> second classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px; classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold class 1,2,3,4,5,6,7,8 grey class first,second white

Схема 3. Кроки для створення PR з вашого форка в kubernetes/website.

  1. У веббраузері перейдіть до репозиторію kubernetes/website.

  2. Оберіть New Pull Request.

  3. Оберіть compare across forks.

  4. У спадному меню head repository, оберіть ваш форк.

  5. У спадному меню compare, оберіть вашу гілку.

  6. Оберіть Create Pull Request.

  7. Додайте опис до вашого pull request:

    • Title (50 символів або менше): Стисло опишіть мету зміни.

    • Description: Опишіть зміну докладніше.

      • Якщо є повʼязаний GitHub issue, додайте Fixes #12345 або Closes #12345 в описі. Автоматизація GitHub закриває зазначений тікет після злиття PR, якщо це використано. Якщо є інші повʼязані PR, вкажіть їх також.
      • Якщо ви хочете отримати пораду щодо чогось конкретного, включіть будь-які питання, які б ви хотіли, щоб рецензенти розглянули в описі.
  8. Оберіть кнопку Create pull request.

Вітаємо! Ваш pull request доступний у Pull requests.

Після створення PR GitHub запускає автоматичні тести та намагається розгорнути попередній перегляд за допомогою Netlify.

  • Якщо збірка Netlify не вдалася, оберіть Details для отримання додаткової інформації.
  • Якщо збірка Netlify вдалася, вибір Details відкриває staged версію вебсайту Kubernetes із вашими змінами. Це те, як рецензенти перевіряють ваші зміни.

GitHub також автоматично призначає мітки PR, щоб допомогти рецензентам. Ви також можете додати їх, якщо це потрібно. Для отримання додаткової інформації дивіться Додавання та видалення міток до тікетів.

Робота з відгуками локально

  1. Після внесення змін, відредагуйте свій попередній коміт:

    git commit -a --amend
    
    • -a: комітить усі зміни
    • --amend: редагує попередній коміт, замість створення нового
  2. За потреби оновіть повідомлення коміту.

  3. Використовуйте git push origin <my_new_branch> для надсилання змін і повторного запуску тестів Netlify.

Зміни від рецензентів

Іноді рецензенти вносять зміни у ваш pull request. Перед внесенням будь-яких інших змін, отримайте ці коміти.

  1. Отримайте коміти з вашого віддаленого форку та виконайте rebase вашої робочої гілки:

    git fetch origin
    git rebase origin/<your-branch-name>
    
  2. Після rebase, зробить примусове надсилання нових змін до вашого форку:

    git push --force-with-lease origin <your-branch-name>
    

Конфлікти злиття та rebase

Якщо інший учасник вносить зміни до того самого файлу в іншому PR, це може створити конфлікт злиття. Ви повинні розвʼязати всі конфлікти злиття у вашому PR.

  1. Оновіть ваш форк та зробіть rebase вашої локальної гілки:

    git fetch origin
    git rebase origin/<your-branch-name>
    

    Після rebase, зробить примусове надсилання нових змін до вашого форку:

    git push --force-with-lease origin <your-branch-name>
    
  2. Отримайте зміни з upstream/main репозиторію kubernetes/website та зробіть rebase у вашій гілці:

    git fetch upstream
    git rebase upstream/main
    
  3. Перевірте результати rebase:

    git status
    

    Це призведе до позначення деяких файлів такими, що містять конфлікти.

  4. Відкрийте кожен файл з конфліктами та знайдіть маркери конфліктів: >>>, <<< і ===. Розвʼяжіть конфлікт і видаліть маркер конфлікту.

  5. Додайте файли до набору змін:

    git add <filename>
    
  6. Продовжіть rebase:

    git rebase --continue
    
  7. Повторюйте кроки 2-5 за необхідності.

    Після застосування всіх комітів, команда git status показує, що rebase завершено.

  8. Зробить примусове надсилання нових змін до вашого форку:

    git push --force-with-lease origin <your-branch-name>
    

    Пул реквест більше не показує жодних конфліктів.

Обʼєднання комітів

Якщо ваш PR має кілька комітів, ви повинні злити їх в один коміт перед злиттям вашого PR. Ви можете перевірити кількість комітів на вкладці Commits вашого PR або за допомогою команди git log локально.

  1. Розпочніть інтерактивний rebase:

    git rebase -i HEAD~<number_of_commits_in_branch>
    

    Злиття комітів є формою rebase. Параметр -i вказує git, що ви хочете виконати інтерактивний rebase. HEAD~<number_of_commits_in_branch> вказує, скільки комітів розглядати для rebase.

    Результат буде схожий на:

    pick d875112ca Original commit
    pick 4fa167b80 Address feedback 1
    pick 7d54e15ee Address feedback 2
    
    # Rebase 3d18sf680..7d54e15ee onto 3d183f680 (3 commands)
    
    ...
    
    # These lines can be re-ordered; they are executed from top to bottom.
    

    Перша частина результату виводить перелік комітів для rebase. Друга частина має параметри для кожного коміту. Заміна слова pick змінює статус коміту після завершення rebase.

    Для цілей rebase зосередьтесь на squash і pick.

  2. Розпочніть редагування файлу.

    Змініть початковий текст:

    pick d875112ca Original commit
    pick 4fa167b80 Address feedback 1
    pick 7d54e15ee Address feedback 2
    

    На:

    pick d875112ca Original commit
    squash 4fa167b80 Address feedback 1
    squash 7d54e15ee Address feedback 2
    

    Це зливає коміти 4fa167b80 Address feedback 1 та 7d54e15ee Address feedback 2 у d875112ca Original commit, залишаючи тільки d875112ca Original commit як частину хронології.

  3. Збережіть і вийдіть з файлу.

  4. Надішліть ваш обʼєднаний коміт:

    git push --force-with-lease origin <branch_name>
    

Беріть участь в інших репо

Проєкт Kubernetes містить понад 50 репозиторіїв. Багато з цих репозиторіїв містять документацію: текст довідки для користувачів, повідомлення про помилки, довідку API або коментарі в коді.

Якщо ви бачите текст, який хочете покращити, скористайтеся GitHub для пошуку по всіх репозиторіях в організації Kubernetes. Це допоможе вам зрозуміти, куди подати ваш тікет або PR.

Кожен репозиторій має свої процеси та процедури. Перед тим як подати тікет або PR, прочитайте README.md, CONTRIBUTING.md та code-of-conduct.md, якщо вони існують.

Більшість репозиторіїв використовують шаблони для тікетів і PR. Подивіться на кілька відкритих тікетів та PR, щоб зрозуміти процеси команди. Обов’язково заповнюйте шаблони з якомога більшою детальністю, коли подаєте тікет або PR.

Що далі

  • Прочитайте Рецензування, щоб дізнатися більше про процес рецензування.

7.3.2 - Документування функцій для випуску

Кожен великий випуск Kubernetes вводить нові функції, які потребують документації. Нові випуски також приносять оновлення наявних функцій і документації (наприклад, оновлення функції з alpha до beta).

Зазвичай робоча група SIG, відповідальна за функцію, подає чернетку документації функції як pull request до відповідної гілки розробки репозиторію kubernetes/website, а хтось з команди SIG Docs надає редакторський відгук або безпосередньо редагує чернетку. Цей розділ охоплює конвенції з гілками та процес, що використовуються під час релізу обома групами.

Для авторів документації

Зазвичай автори документації не пишуть контент з нуля для випуску. Замість цього вони працюють з SIG, що створює нову функцію, щоб вдосконалити чернетку документації та підготувати її до випуску.

Після того як ви вибрали функцію для документування або допомоги, запитайте про це в каналі Slack #sig-docs, на щотижневій зустрічі SIG Docs або безпосередньо в PR, поданому для функції SIG. Якщо вам дозволено, ви можете редагувати PR, використовуючи один з методів, описаних у внесення змін в PR іншої особи.

Дізнайтеся про майбутні функції

Щоб дізнатися про майбутні функції, відвідуйте щотижневу зустріч SIG Release (див. сторінку Спільнота для отримання інформації про майбутні зустрічі) і слідкуйте за документацією, що стосується випуску, в репозиторії kubernetes/sig-release. Кожен випуск має вкладену теку в теці releases. У теці міститься розклад випуску, чернетка приміток до випуску та документ, в якому перераховані всі учасники команди випуску.

Розклад випуску містить посилання на всі інші документи, зустрічі, протоколи зустрічей та етапи, що стосуються випуску. Він також містить інформацію про цілі та графік випуску та будь-які спеціальні процеси для цього випуску. Внизу документа визначено кілька термінів, що стосуються випуску.

Цей документ також містить посилання на Feature tracking sheet, що є офіційним способом дізнатися про всі нові функції, заплановані для включення в випуск.

Документ команди випуску вказує, хто відповідає за кожну роль випуску. Якщо не зрозуміло, до кого звернутися щодо конкретної функції або питання, яке у вас є, або відвідайте зустріч команди випуску, щоб поставити своє питання, або звʼяжіться з керуючим випуску, щоб вони могли спрямувати вас.

Чернетка приміток до випуску є гарним місцем, щоб дізнатись про певні функції, зміни, зняття з підтримки та інше про випуск. Контент не буде остаточним до пізнього етапу циклу випуску, тому використовуйте с обережністю.

Лист відстеження функцій

Лист відстеження функцій для конкретного випуску Kubernetes перераховує кожну функцію, заплановану для випуску. Кожен пункт включає назву функції, посилання на основний тікет функції на GitHub, її рівень стабільності (Alpha, Beta або Stable), SIG і особу, відповідальну за її реалізацію, чи потрібна документація, чернетку примітки до випуску для функції та інформацію про те, чи була вона злитою. Памʼятайте наступне:

  • Функції Beta і Stable зазвичай мають вищий пріоритет для документації, ніж функції Alpha.
  • Випробувати (і, отже, задокументувати) функцію, яка ще не злилася або вважається завершеною в PR, складно.
  • Визначення, чи потрібна функції документація, є ручним процесом. Навіть якщо функція не позначена як така, що потребує документації, вам може знадобитися її задокументувати.

Для розробників або інших учасників SIG

Цей розділ є інформацією для членів інших SIG Kubernetes, які документують нові функції для випуску.

Якщо ви є членом SIG, що розробляє нову функцію для Kubernetes, вам потрібно працювати з SIG Docs, щоб забезпечити документацію вашої функції вчасно для випуску. Перевірте список відстеження функцій або перевірте в каналі Slack Kubernetes #sig-release, щоб ознайомитись з деталями планування та строками.

Створіть попередній PR

  1. Створіть pull request чернетку на основі гілки dev-1.32 в репозиторії kubernetes/website, з невеликим комітом, який ви пізніше виправите. Щоб створити pull request чернетку, скористайтеся спадним меню Create Pull Request та виберіть Create Draft Pull Request, потім натисніть Draft Pull Request.
  2. Відредагуйте опис pull request, щоб включити посилання на kubernetes/kubernetes PR(и) та тікет(и) kubernetes/enhancements.
  3. Залиште коментар у відповідному kubernetes/enhancements тікеті з посиланням на PR, щоб сповістити особу з документації, яка управляє цим випуском, що документація функції готується і повинна бути відстежена для випуску.

Якщо ваша функція не потребує жодних змін документації, переконайтеся, що команда sig-release знає про це, зазначивши це в каналі Slack #sig-release. Якщо функція потребує документації, але PR не створений, функція може бути видалена з віхи (milestone).

PR готовий до рецензування

Коли будете готові, заповніть ваш попередній PR з документацією про функцію та змініть стан PR з чернетки на готовий до рецензування. Щоб позначити pull request як готовий до огляду, перейдіть до блоку злиття і натисніть Ready for review.

Зробіть все можливе, щоб описати вашу функцію та як її використовувати. Якщо вам потрібна допомога в структуризації вашої документації, запитайте в каналі Slack #sig-docs.

Коли ви завершите свій контент, особа з документації, призначена для вашої функції, перегляне його. Щоб забезпечити технічну точність, контент може також вимагати технічного огляду від відповідних SIG. Використовуйте їхні пропозиції, щоб підготувати контент до стану, готового до випуску.

Якщо ваша функція потребує документації, а перший чорновий варіант контенту не отримано, функція може бути видалена з проміжного етапу.

Функціональні можливості

Якщо ваша функція є Alpha або Beta функцією і залежить від (уві)вимкнення функціональних можливостей, вам потрібен файл функціональних можливостей для неї в content/en/docs/reference/command-line-tools-reference/feature-gates/. Назва файлу має бути назвою функціональних можливостей, перетвореним з UpperCamelCase в kebab-case, с розширенням .md. Ви можете подивитися інші файли, що вже знаходяться в цій теці, щоб отримати підказку про те, як повинен виглядати ваш файл. Зазвичай одного абзацу достатньо; для довших пояснень додайте документацію в інше місце і посилайтеся на неї.

Також, щоб забезпечити, що ваші функціональні можливості зʼявляться в таблиці Функціональні можливості Alpha/Beta, включіть наступні деталі у front matter вашого файлу Markdown:

stages:
  - stage: <alpha/beta/stable/deprecated>  # Вкажіть етап розробки функціональних можливостей
    defaultValue: <true or false>     # Встановіть на true, якщо стандартно увімкнено, false в іншому випадку
    fromVersion: <Version>            # Версія, з якої доступна функціональна можливість
    toVersion: <Version>              # (Необов'язково) Версія до якої функціональна можливість доступна

З новими функціональними можливостями також необхідний окремий опис функціональної можливості; створіть новий Markdown файл в content/en/docs/reference/command-line-tools-reference/feature-gates/ (використовуйте інші файли як шаблон).

Коли ви змінюєте функціональну можливість зі стану стандартно вимкнено на стандартно увімкнено, вам також може знадобитися змінити іншу документацію (не лише список функціональних можливостей). Звертайте увагу на такі формулювання, як "Поле exampleSetting є полем beta і є стандартно вимкненим. Ви можете увімкнути його, увімкнувши функціональну можливість ProcessExampleThings."

Якщо ваша функція GA'ed або знята з підтримки (deprecated), додайте додатковий запис stage у блок stages в файлі опису. Переконайтеся, що етапи Alpha та Beta залишаються незмінними. Цей крок переводить функціональну можливість з Функціональних можливостей для Alpha/Feature таблиці до таблиці Функціональних можливостей для стабільних або застарілих функцій. Наприклад:

stages:
  - stage: alpha
    defaultValue: false
    fromVersion: "1.12"
    toVersion: "1.12"
  - stage: beta
    defaultValue: true
    fromVersion: "1.13"
    toVersion: "1.18"
  # Додано блок 'stable' для поточного стану.
  - stage: stable
    defaultValue: true
    fromVersion: "1.19"
    toVersion: "1.27"

Зрештою, Kubernetes взагалі перестане включати функціональну можливість. Щоб вказати на видалення функціональної можливості, включіть removed: true у front matter відповідного файлу опису. Ця дія викликає перехід функціональної можливості з розділу Функціональні можливості для стабільних або застарілих функцій до окремої сторінки з назвою Функціональні можливості (вилучені), включаючи його опис.

Усі PR рецензовані та готові до злиття

Якщо ваш PR ще не був злитий у гілку dev-1.32 до крайнього терміну випуску, працюйте з особою з документації, що управляє випуском, щоб зробити це до моменту. Якщо ваша функція потребує документації, а документація ще не готова, функція може бути видалена з віхи (milestone).

7.3.3 - Дописи в блог та приклади використань

Кожен може зробити допис в блог та подати його на рецензію. Дописі в Приклади використань потребують ретельного перегляду перед затвердженням.

Блог Kubernetes

Блог Kubernetes використовується проєктом для розповіді про нові функції, звітів спільноти та будь-яких новин, які можуть бути актуальними для спільноти Kubernetes. Це стосується як кінцевих користувачів, так і розробників. Більшість контенту блогу стосується подій в основному проєкті, але ми заохочуємо вас подавати інформацію про події в інших частинах екосистеми!

Кожен може написати блог і подати його на рецензію.

Створення публікації

Дописи в блог не повинні мати комерційний характер і повинні складатися з оригінального контенту, що стосується всієї спільноти Kubernetes. Відповідний контент для блогу включає:

  • Нові можливості Kubernetes
  • Оновлення проєктів Kubernetes
  • Оновлення від робочих груп (Special Interest Groups, SIGs)
  • Підручники та керівництва
  • Роздуми щодо Kubernetes
  • Інтеграція з Kubernetes Partner OSS
  • Тільки оригінальний контент

Непридатний контент:

  • Комерційні презентації продуктів
  • Оновлення від партнерів без інтеграції та історії клієнтів
  • Синдиковані пости (переклади різними мовами дозволені)

Щоб подати блог-пост, дотримуйтеся наступних кроків:

  1. Підпишіть CLA, якщо ви цього ще не зробили.

  2. Ознайомтесь з форматом Markdown для наявних блог-постів у репозиторії вебсайту.

  3. Напишіть свій блог у текстовому редакторі за вашим вибором.

  4. На тому ж посиланні з кроку 2, натисніть кнопку Створити новий файл. Вставте свій контент у редактор. Назвіть файл відповідно до запропонованої назви блог-посту, але не вказуйте дату у назві файлу. Рецензенти блогу працюватимуть з вами над остаточною назвою файлу та датою публікації блогу.

  5. Коли ви збережете файл, GitHub проведе вас через процес pull request.

  6. Рецензент блогів перегляне вашу подачу та працюватиме з вами з відгуками та остаточними деталями. Коли блог-пост буде затверджений, блог буде запланований до публікації.

Рекомендації та очікування

  • Дописи в блог не повинні бути комерційними презентаціями.

    • Статті повинні містити контент, який стосується широкої спільноти Kubernetes. Наприклад, розповідь має зосереджуватись на основному Kubernetes, а не на специфічних конфігураціях постачальників. Перевірте Керівництво зі стилю документації для того, що зазвичай дозволено у властивостях Kubernetes.
    • Посилання повинні переважно вести на офіційну документацію Kubernetes. При використанні зовнішніх посилань вони повинні бути різноманітними. Наприклад, допис не повинен містити тільки посилання на блог однієї компанії.
    • Іноді це складний баланс. Команда блогу надає допомогу щодо того, чи є пост прийнятним для блогу Kubernetes, тому не соромтеся звертатися.
  • Дописи в блог не публікуються в конкретні дати.

    • Статті рецензуються волонтерами спільноти. Ми намагаємося врахувати конкретні строки, але не даємо жодних гарантій.
    • Багато основних частин проєктів Kubernetes подають дописи під час релізних вікон, що затримує час публікації. Розгляньте можливість подання під час спокійнішого періоду релізного циклу.
    • Якщо вам потрібна більша координація щодо дат випуску постів, координація з маркетингом CNCF є більш відповідним вибором, ніж створення блог-посту.
    • Іноді рецензії можуть затримуватись. Якщо ви відчуваєте, що ваш допис не отримує необхідної уваги, ви можете звернутися до команди блогу на каналі Slack #sig-docs-blog, щоб запитати в реальному часі.
  • Дописи в блог повинні бути актуальними для користувачів Kubernetes.

    • Теми, повʼязані з участю або результатами діяльності SIGs Kubernetes, завжди актуальні (дивіться роботу в Команді комунікацій для учасників для підтримки цих дописів).
    • Компоненти Kubernetes є навмисно модульними, тому інструменти, які використовують наявні інтеграційні точки, такі як CNI та CSI, актуальні.
    • Пости про інші проєкти CNCF можуть бути актуальними або ні. Рекомендуємо запитати у команди блогу перед поданням чернетки.
      • Багато проєктів CNCF мають власні блоги. Це часто кращий вибір для постів. Існують випадки важливих функцій або досягнень проєкту CNCF, про які користувачі захочуть дізнатися з блогу Kubernetes.
    • Дописи в блог про внесок до проєкту Kubernetes повинні бути на сайті учасників Kubernetes.
  • Дописи в блог повинні бути оригінальним контентом

    • Офіційний блог не призначений для перепрофілювання наявного контенту від інших як нового контенту.
    • Ліцензія для блогу дозволяє використання контенту для комерційних цілей, але не навпаки.
  • Дописи в блог повинні бути спрямовані на майбутнє

    • З огляду на швидкість розвитку проєкту, ми хочемо, щоб контент залишався актуальним для читачів.
    • Краще додати підручник або оновити офіційну документацію, ніж писати огляд високого рівня у блог-пості.
      • Розгляньте можливість концентрації довгого технічного контенту як заклик до дії в блозі та зосередьтесь на проблемному просторі або на тому, чому це важливо для читачів.

Технічні міркування щодо розміщення допису в блозі

Дописи повинні бути у форматі Markdown, щоб використовуватись генератором Hugo для блогу. Є багато ресурсів з використання цього технологічного стека.

Для ілюстрацій, діаграм або графіків можна використовувати shortcode figure. Для інших зображень ми наполегливо рекомендуємо використовувати атрибути alt; якщо зображення не потребує атрибута alt, можливо, воно взагалі не потрібне в статті.

Ми розуміємо, що ця вимога ускладнює процес для менш обізнаних людей, які подають свої матеріали, і ми постійно шукаємо рішення для зниження цього барʼєру. Якщо у вас є ідеї, як знизити барʼєр, будь ласка, запропонуйте допомогу.

Підпроєкт блогу керує процесом рецензування блог-постів. Для отримання додаткової інформації дивіться Submit a post.

Щоб створити блог-пост, дотримуйтеся цих вказівок:

  • Відкрийте pull request з новим блог-постом. Нові блог-пости розміщуються у теці content/en/blog/_posts.

  • Переконайтеся, що ваш блог-пост відповідає чинним домовленостям та містить таку інформацію у frontmatter (метадані):

    • Назва файлу Markdown повинна відповідати формату YYYY-MM-DD-Your-Title-Here.md. Наприклад, 2020-02-07-Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md.

    • Не включайте крапки в назву файлу. Назва, як-от 2020-01-01-whats-new-in-1.19.md, викликає помилки під час збірки.

    • Front matter повинен включати наступне:

      ---
      layout: blog
      title: "Your Title Here"
      date: YYYY-MM-DD
      slug: text-for-URL-link-here-no-spaces
      author: >
        Author-1 (Affiliation),
        Author-2 (Affiliation),
        Author-3 (Affiliation)  
      ---
      
    • Перше або початкове повідомлення коміту повинно бути коротким підсумком виконаної роботи та повинно самостійно описувати блог-пост. Зверніть увагу, що наступні правки вашого блогу будуть обʼєднані в цей основний коміт, тому він повинен бути якомога інформативнішим.

      • Приклади хорошого опису коміту:
        • Add blog post on the foo kubernetes feature
        • blog: foobar announcement
      • Приклади поганого опису коміту:
        • Add blog post
        • .
        • initial commit
        • draft post
    • Команда блогу потім перегляне ваш PR і надасть вам коментарі щодо речей, які потрібно виправити. Після цього бот обʼєднає ваш PR і ваш блог-пост буде опубліковано.

    • Якщо вміст блог-посту містить лише такий контент, який не потребуватиме оновлень, щоб залишатися актуальним для читача, його можна позначити як вічнозелений і звільнити від автоматичного попередження про застарілий контент, що додається до блог-постів старше одного року.

      • Щоб позначити блог-пост як вічнозелений, додайте це до front matter:

        evergreen: true
        
      • Приклади контенту, який не слід позначати вічнозеленим:

        • Підручники, які застосовуються лише до конкретних випусків або версій, а не до всіх майбутніх версій
        • Посилання на API або функції pre-GA

Віддзеркалення з блогу учасників Kubernetes

Щоб віддзеркалити блог-пост з блогу учасників Kubernetes, дотримуйтеся цих рекомендацій:

  • Залиште вміст блогу таким самим. Якщо є зміни, їх слід внести спочатку до оригінальної статті, а потім до віддзеркаленої статті.
  • Віддзеркалений блог-пост повинен мати canonicalUrl, тобто фактично URL оригінального посту після його публікації.
  • Так само як і в блогу учасників Kubernetes, дописи в блогах Kubernetes також згадують авторів у заголовку YAML згідно з новими настановами. Потрібно переконатись в їх наявності.
  • Дати публікації залишаються такими ж, як в оригінальному блозі.

Усі інші рекомендації та очікування, викладені вище, також застосовуються.

Дописи у Приклади використання

Приклади використання висвітлюють, як організації використовують Kubernetes для вирішення реальних проблем. Маркетингова команда Kubernetes і члени CNCF співпрацюватимуть з вами над усіма прикладами використання.

Ознайомтеся з сирцями поточних прикладів використання.

Зверніться до керівництва з підготовки прикладу використання і подайте свій запит, як зазначено в керівництві.

7.4 - Рецензування змін

Цей розділ описує процес рецензування вмісту.

7.4.1 - Рецензування pull request

Будь-хто може рецензувати pull request документації. Відвідайте розділ pull requests у репозиторії вебсайту Kubernetes, щоб побачити відкриті pull request.

Рецензування pull request документації — це чудовий спосіб познайомитися зі спільнотою Kubernetes. Це допомагає вам вивчити кодову базу та завоювати довіру інших учасників.

Перед рецензуванням доцільно:

Перш ніж почати

Перш ніж почати рецензування:

  • Прочитайте Кодекс поведінки CNCF та дотримуйтеся його у будь-який час.
  • Будьте ввічливими, уважними та корисними.
  • Коментуйте позитивні аспекти PR, а також зміни.
  • Будьте емпатичними та враховуйте, як ваш огляд може бути сприйнятий.
  • Передбачайте добрі наміри та ставте уточнювальні питання.
  • Досвідчені учасники можуть співпрацювати з новими учасниками, чиї роботи потребують значних змін.

Процес рецензування

Загалом, огляньте pull request на вміст та стиль англійською мовою. На схемі 1 показані етапи процесу огляду. Деталі для кожного кроку наведено нижче.

flowchart LR subgraph fourth[Початок огляду] direction TB S[ ] -.- M[додавання коментарів] --> N[огляд змін] N --> O[нові учасники повинні
вибрати Comment] end subgraph third[Вибір PR] direction TB T[ ] -.- J[ознайомлення з описом
та коментарями]--> K[перегляд змін у
попередньому перегляді Netlify] end A[Огляд списку
відкритих PR]--> B[Фільтр відкритих PR
за міткою] B --> third --> fourth classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px; classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000 class A,B,J,K,M,N,O grey class S,T spacewhite class third,fourth white

Схема 1. Етапи процесу огляду.

  1. Перейдіть на https://github.com/kubernetes/website/pulls. Ви побачите список усіх відкритих pull request до вебсайту та документації Kubernetes.

  2. Відфільтруйте відкриті PR, використовуючи одну або всі з наступних міток:

    • cncf-cla: yes (Рекомендовано): PR, подані учасниками, які не підписали CLA, не можуть бути об’єднані з осноною кодовою базою репо. Див. Підписання CLA для отримання додаткової інформації.
    • language/en (Рекомендовано): Фільтрує лише PR англійською мовою.
    • size/<розмір>: фільтрує PR певного розміру. Якщо ви новачок, почніть з менших PR.

    Крім того, переконайтеся, що PR не позначено як роботу в процесі. PR з міткою work in progress ще не готові до огляду.

  3. Після того, як ви вибрали PR для огляду, зрозумійте зміни, зроблені в ньому, шляхом:

    • Читання опису PR, щоб зрозуміти зроблені зміни, і читання будь-яких пов’язаних питань
    • Читання коментарів інших рецензентів
    • Клацанням на вкладку Files changed, щоб побачити змінені файли та рядки
    • Попереднього перегляду змін у попередньому перегляді Netlify, прокручуючи до розділу перевірки збірки PR у нижній частині вкладки Conversation. Ось знімок екрана (який показує сайт GitHub на компʼютері; якщо ви переглядаєте на планшеті або смартфоні, вебінтерфейс GitHub дещо відрізняється):
      Деталі pull request GitHub, включаючи посилання на попередній перегляд Netlify
      Щоб відкрити попередній перегляд, натисніть на посилання Details у рядку deploy/netlify у списку перевірок.
  4. Перейдіть на вкладку Files changed, щоб почати свій огляд.

    1. Клацніть на символ + біля рядка, який хочете прокоментувати.

    2. Додайте ваші коментарі щодо рядка та натисніть або Add single comment (якщо у вас є лише один коментар), або Start a review (якщо у вас є кілька коментарів).

    3. Після завершення натисніть Review changes у верхній частині сторінки. Тут ви можете додати короткий зміст свого огляду (і залишити кілька позитивних коментарів для учасника!).Завжди використовуйте "Comment"

      • Уникайте натискання кнопки "Request changes" при завершенні огляду. Якщо ви хочете заблокувати PR від обʼєднання до внесення подальших змін, ви можете залишити коментар "/hold". Зазначте, чому ви встановлюєте hold, і за потреби уточніть умови, за яких hold можна зняти вами або іншими рецензентами.

      • Уникайте натискання кнопки "Approve" при завершенні огляду. Коментар "/approve" є рекомендованим в більшості випадків.

Контрольний список рецензування

Використовуйте наступні пункти як відправну точку при огляді.

Мова та граматика

  • Чи є очевидні помилки в мові або граматиці? Чи є кращий спосіб сформулювати щось?
    • Зосередьтеся на мові та граматиці тих частин сторінки, які змінює автор. Якщо автор не має на меті оновити всю сторінку, він не зобовʼязаний виправляти всі помилки на сторінці.
    • Коли PR оновлює наявну сторінку, слід зосередитися на перегляді тих частин сторінки, які оновлюються. Цей змінений контент слід переглянути на предмет технічної та редакційної відповідності. Якщо ви виявите помилки на сторінці, які не стосуються безпосередньо того, що намагається виправити автор PR, це слід розглядати як окрему проблему (спершу перевірте, чи вже не існує тікет щодо цього).
    • Слідкуйте за pull request, які переміщують контент. Якщо автор перейменовує сторінку або обʼєднує дві сторінки, ми (Kubernetes SIG Docs) зазвичай не просимо до цього автора виправити всі граматичні або орфографічні недоліки в переміщеному контенті.
  • Чи є складні або архаїчні слова, які можна замінити простішими?
  • Чи є слова, терміни або фрази, які можна замінити на недискримінаційні альтернативи?
  • Чи відповідає вибір слів та їхнє написання з великої літери настановам зі стилю?
  • Чи є довгі речення, які можна зробити коротшими або менш складними?
  • Чи є довгі абзаци, які краще б виглядали у вигляді списку або таблиці?

Вміст

  • Чи існує схожий контент в іншому місці на сайті Kubernetes?
  • Чи посилається контент надмірно на зовнішні сайти, окремих постачальників або документацію, що не є відкритим вихідним кодом?

Вебсайт

  • Чи змінив цей PR заголовок сторінки, slug/alias або anchor link? Якщо так, чи є зламані посилання в результаті цього PR? Чи є інший варіант, наприклад, зміна заголовка сторінки без зміни slug?

  • Чи додає PR нову сторінку? Якщо так:

    • Чи використовує сторінка правильний тип контенту сторінки та відповідні Hugo shortcodes?
    • Чи правильно сторінка відображається у боковій навігації (або взагалі)?
    • Чи повинна сторінка з’явитися у списку Docs Home?
  • Чи відображаються зміни у попередньому перегляді Netlify? Будьте особливо уважними до списків, блоків коду, таблиць, приміток та зображень.

Інше

  • Слідкуйте за несуттєвими правками; якщо ви бачите зміну, яку вважаєте несуттєвою правкою, будь ласка, вкажіть цю політику (все ще можна прийняти зміну, якщо вона дійсно є покращенням).
  • Заохочуйте авторів, які роблять виправлення пробілів, робити це в першому коміті свого PR, а потім додавати інші зміни поверх цього. Це полегшує як злиття, так і огляд. Особливо звертайте увагу на несуттєві зміни, які відбуваються в одному коміті разом з великою кількістю виправлень пробілів (і якщо ви це бачите, заохочуйте автора виправити це).

Якщо ви виявляєте невеликі проблеми з PR, які не є суттєвими для змісту, наприклад, друкарські помилки або неправильне використання пробілів, додайте на початку своїх коментарів nit:. Це дає автору зрозуміти, що ця частина вашого зворотного зв’язку не є критичною.

Якщо ви розглядаєте pull request для схвалення, і весь відгук позначений як nit, ви можете обʼєднати PR в будь-якому випадку. У такому випадку часто корисно створити тікет щодо залишених незначних зауважень. Розгляньте, чи можете ви виконати вимоги для позначення цієї нової проблеми як Good First Issue; якщо ви можете, це буде хорошим початком для новачків.

7.4.2 - Рецензування для затверджувачів та рецензентів

Рецензенти та затверджувачі SIG Docs виконують кілька додаткових дій під час огляду змін.

Щотижня конкретний затверджувач документації добровільно погоджується переглядати та рецензувати pull request'и (PR). Ця особа є "PR Wrangler" на тиждень. Детальнішу інформацію можна знайти в розкладі PR Wrangler. Щоб стати PR Wrangler, відвідайте щотижневу зустріч SIG Docs і станьте волонтером. Навіть якщо ви не внесені до розкладу на поточний тиждень, ви все одно можете переглядати pull request'и, які не знаходяться в активному перегляді.

Окрім ротації, бот призначає рецензентів і затверджувачів для PR на основі власників для відповідних файлів.

Огляд PR

Документація Kubernetes дотримується процесу огляду коду Kubernetes.

Все, що описано в Огляд pull request'ів, застосовується, але рецензенти та затверджувачі повинні також робити наступне:

  • Використовуйте команду Prow /assign, щоб за потреби призначити конкретного рецензента для PR. Це особливо важливо, коли мова йде про запит технічного огляду від тих хто робить внесок в покращення коду.

  • Переконайтеся, що PR дотримується настанов з контенту та стилью; надайте автору посилання на відповідну частину керівництва, якщо ні.

  • Використовуйте опцію Request Changes в GitHub, коли це доречно, щоб запропонувати зміни автору PR.

  • Змінюйте свій статус огляду в GitHub за допомогою команд Prow /approve або /lgtm, якщо ваші пропозиції були впроваджені.

Комміти в PR іншої особи

Залишати коментарі до PR корисно, але можуть бути випадки, коли вам потрібно внести зміни в PR іншої особи.

Не "перебирайте на себе" обовʼязки іншої особи, якщо вона явно не попросить вас про це, або ви хочете відновити давно занедбаний PR. Хоча це може бути швидше в короткостроковій перспективі, це позбавляє людину можливості зробити свій внесок.

Процес, який ви використовуєте, залежить від того, чи потрібно редагувати файл, який вже знаходиться у сфері дії PR, чи файл, якого PR ще не торкнувся.

Ви не можете робити коміти в PR іншої особи, якщо виконується будь-яка з наступних умов:

  • Якщо автор PR напряму надіслав (push) свою гілку до https://github.com/kubernetes/website/ репозиторію. Тільки рецензент з доступом на push може робити коміти в PR іншого користувача.

  • Автор PR явно забороняє редагування з боку затверджувачів.

Команди Prow для рецензування

Prow є CI/CD системою на базі Kubernetes, яка запускає завдання для pull requestʼів (PR). Prow дозволяє використовувати команди в стилі чат-ботів для обробки дій GitHub у межах організації Kubernetes, таких як додавання та видалення міток, закриття тікетів та призначення затверджувача. Використовуйте команди Prow у вигляді коментарів GitHub у форматі /<command-name>.

Найбільш поширені команди Prow, які використовують рецензенти та затверджувачі:

Команди Prow для рецензування
Команда ProwОбмеження ролейОпис
/lgtmЧлени організаціїСигналізує, що ви завершили огляд PR і задоволені змінами.
/approveЗатверджувачіЗатверджує PR для злиття.
/assignБудь-хтоПризначає людину для огляду або затвердження PR
/closeЧлени організаціїЗакриває проблему або PR.
/holdБудь-хтоДодає мітку do-not-merge/hold, що означає, що PR не може бути автоматично злитий.
/hold cancelБудь-хтоВидаляє мітку do-not-merge/hold.

Щоб переглянути команди, які ви можете використовувати в PR, дивіться довідку по командах Prow.

Класифікація та категоризація проблем

Загалом, SIG Docs дотримується процесу класифікації проблем Kubernetes і використовує ті ж самі мітки.

Цей фільтр GitHub Issue знаходить тікети, які можуть потребувати класифікації.

Класифікація тікета

  1. Перевірте тікет

    • Переконайтеся, що запит стосується документації вебсайту. Деякі запити можна швидко вирішити, відповівши на запитання або вказавши на відповідний ресурс. Див. розділ Запити щодо підтримки або повідомлення про помилки в коді для деталей.
    • Оцініть, чи має запит значення.
    • Додайте мітку triage/needs-information, якщо запит не містить достатньо деталей для дій або шаблон не заповнений належним чином.
    • Закрийте тікет, якщо він має мітки lifecycle/stale та triage/needs-information.
  2. Додайте мітку пріоритету (докладні визначення міток пріоритету наведено в Issue Triage Guidelines)

    Мітки тікетів
    МіткаОпис
    priority/critical-urgentВиконати негайно.
    priority/important-soonВиконати протягом 3 місяців.
    priority/important-longtermВиконати протягом 6 місяців.
    priority/backlogВідкладено на невизначений термін. Виконати, коли будуть ресурси.
    priority/awaiting-more-evidenceЗберегти як потенційно важливу проблему, щоб вона не загубилася.
    help або good first issueПідходить для тих, хто має дуже мало досвіду з Kubernetes або SIG Docs. Див. Мітки Help Wanted та Good First Issue для отримання додаткової інформації.

    На ваш розсуд, ви можете взяти на себе відповідальність за тікет та створити PR для його вирішення (особливо якщо це швидко або стосується роботи, яку ви вже виконуєте).

Якщо у вас є запитання щодо класифікації тікета, звертайтеся до каналу #sig-docs у Slack або у розсилку kubernetes-sig-docs.

Додавання та видалення міток у тікетів

Щоб додати мітку, залиште коментар в одному з наступних форматів:

  • /<label-to-add> (наприклад, /good-first-issue)
  • /<label-category> <label-to-add> (наприклад, /triage needs-information або /language ja)

Щоб видалити мітку, залиште коментар в одному з наступних форматів:

  • /remove-<label-to-remove> (наприклад, /remove-help)
  • /remove-<label-category> <label-to-remove> (наприклад, /remove-triage needs-information)

У обох випадках мітка повинна вже існувати. Якщо ви спробуєте додати мітку, якої не існує, команда буде проігнорована без будь-яких сповіщень проце.

Список усіх міток можна знайти у розділі міток репозиторію сайту. Не всі мітки використовуються SIG Docs.

Мітки життєвого циклу тікета

Тікети зазвичай відкриваються і закриваються швидко. Однак іноді тікети залишаються неактивними після їх відкриття. Іноді тікет може залишатися відкритим більше ніж 90 днів.

Мітки життєвого циклу тікета
МіткаОпис
lifecycle/staleПісля 90 днів без активності тікет автоматично позначається як застарілий. Тікет буде автоматично закрите, якщо життєвий цикл не буде вручну повернуто за допомогою команди /remove-lifecycle stale.
lifecycle/frozenТікет з цією міткою не стане застарілим після 90 днів без активності. Користувач вручну додає цю мітку до тікетів, які потрібно залишити відкритими набагато довше 90 днів, таких як ті, що мають мітку priority/important-longterm.

Обробка спеціальних типів тікетів

SIG Docs часто стикається з такими типами тікетів, тому важливо знати, як їх обробляти.

Дублікати тікетів

Якщо одна і та ж проблема має один або кілька відкритих тікетів, об’єднайте їх в один тікет. Виберіть тікет, яке слід залишити відкритим (або відкрийте новий), перенесіть всю відповідну інформацію та зв’яжіть пов’язані тікети. Нарешті, позначте всі інші тікети, що описують ту ж проблему, як triage/duplicate і закрийте їх. Наявність єдиного тікета для роботи зменшує плутанину та дозволяє уникнути дублювання роботи над однією і тією ж проблемою.

Якщо тікет про недійсне посилання стосується документації API або kubectl, присвойте йому мітку /priority critical-urgent, поки проблема не буде повністю зрозуміла. Для всіх інших проблем з недійсними посиланнями використовуйте мітку /priority important-longterm, оскільки їх потрібно виправляти вручну.

Проблеми з блогом

Ми очікуємо, що дописи Kubernetes Blog будуть ставати застарілими з часом. Тому ми підтримуємо дописи блогу лише до одного року. Якщо питання стосується допису, якому понад рік, закрийте тікет без виправлення.

Запити на підтримку або звіти про помилки в коді

Деякі питання з документації насправді є проблемами з основним кодом або запитами про допомогу, коли щось, наприклад, керівництво, не працює. Для питань, які не пов’язані з документацією, закрийте тікет з міткою kind/support та коментарем, що спрямовує запитувача до підтримки (Slack, Stack Overflow) та, якщо це актуально, до репозиторію для створення тікета про помилки з функціями (kubernetes/kubernetes є гарним місцем для початку).

Приклад відповіді на запит про підтримку:

This issue sounds more like a request for support and less like an issue specifically for docs. I encourage you to bring your question to the `#kubernetes-users` channel in [Kubernetes slack](https://slack.k8s.io/). You can also search resources like [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) for answers to similar questions.

You can also open issues for Kubernetes functionality in https://github.com/kubernetes/kubernetes.

If this is a documentation issue, please re-open this issue.

Приклад відповіді на звіт про помилку в коді:

This sounds more like an issue with the code than an issue with the documentation. Please open an issue at https://github.com/kubernetes/kubernetes/issues.

If this is a documentation issue, please re-open this issue.

Обʼєднання комітів

Як затверджувач (approver), коли ви переглядаєте pull requests (PRs), є кілька випадків, коли ви можете зробити наступне:

  • Порадити автору обʼєднати коміти.
  • Обʼєднати коміти для автора.
  • Порадити автору не обʼєднувати коміти ще.
  • Запобігти обʼєднанню.

Порада авторам обʼєднати коміти: Нові учасники можуть не знати, що потрібно обʼєднати коміти в своїх pull requests (PRs). Якщо це так, порадьте їм це зробити, надайте посилання на корисну інформацію і запропонуйте допомогу, якщо вона необхідна. Корисні посилання:

Обʼєднання комітів для учасників: Якщо автору може бути важко обʼєднати коміти або існує тиск часу для злиття PR, ви можете виконати обʼєднання за них:

  • Налаштування репозиторію kubernetes/website дозволяють обʼєднання комітів для pull requests. Все просто — оберіть кнопку Squash commits.
  • В PR, якщо автор дозволяє супроводжуючим керувати PR, ви можете обʼєднати їх коміти та оновити їх форк з результатом. Перед обʼєднанням порадьте їм зберегти та надіслати свої останні зміни до PR. Після обʼєднання порадьте їм витягнути обʼєднаний коміт до їх клону.
  • Ви можете дозволити GitHub обʼєднати коміти, використовуючи мітку, щоб Tide / GitHub виконали обʼєднання або натиснувши кнопку Squash commits під час злиття PR.

Порада авторам не обʼєднувати коміти

  • Якщо один коміт робить щось неправильне або небажане, а останній коміт скасовує цю помилку, не обʼєднуйте коміти. Хоча вкладка "Files changed" в PR на GitHub та перегляд Netlify будуть виглядати нормально, злиття цього PR може створити конфлікти rebases або merges для інших осіб. Втручайтеся, щоб уникнути цього ризику для інших учасників.

Ніколи не обʼєднуйте

  • Якщо ви запускаєте локалізацію або випускаєте документацію для нової версії, ви зливаєте гілку, яка не походить з форка користувача, ніколи не обʼєднуйте коміти. Не обʼєднання є важливим, оскільки ви повинні підтримувати історію комітів для цих файлів.

7.5 - Локалізація документації Kubernetes

Ця сторінка містить приклади локалізації документації Kubernetes різними мовами.

Покращення наявної локалізації

Ви можете допомогти додати або покращити вміст наявної локалізації. У Slack Kubernetes, ви можете знайти канал для кожної локалізації. Також є загальний канал SIG Docs Localizations, де ви можете привітатись.

Визначте дволітерний код вашої мови

Звіртесь зі стандартом ISO 639-1, щоб знайти дволітерний код вашої мови. Наприклад, дволітерний код для української мови — uk.

Деякі мови використовують версію коду країни у нижньому регістрі, як визначено стандартом ISO-3166, разом з їх мовними кодами. Наприклад, код бразильської португальської мови — pt-br.

Зробіть форк та клонуйте репозиторій

Спочатку, зробіть форк репозиторію kubernetes/website.

Потім клонуйте його собі на компʼютер та перейдіть в локальну теку:

git clone https://github.com/<username>/website
cd website

Вміст сайту включає підтеки для кожної мови. Для локалізації, вам потрібно змінювати вміст в підтеках content/<two-letter-code>.

Пропонуйте зміни

Створіть або оновіть вибрану локалізовану сторінку на основі англійського оригіналу. Дивіться розділ Локалізація вмісту для отримання додаткових вказівок.

Якщо ви помітили якійсь технічні неточності або інші проблеми з англійською документацією, ви повинні спочатку виправити англійську документацію, а потім повторити відповідні зміни, оновивши локалізацію, над якою ви працюєте.

Обмежте зміни в пул-реквесті однією локалізацією. Розгляд змін, які змінюють вміст у кількох локалізаціях, є проблематичним.

Слідуйте рекомендаціям Пропонування покращення вмісту для пропозиції змін у вмісті локалізації. Це процес подібний до пропозиції змін в оригінальний вміст (англійською мовою).

Створення нової локалізації

Якщо ви хочете мати документацію Kubernetes вашою мовою, ось що вам потрібно зробити.

Оскільки учасники не можуть схвалювати свої власні пул-реквести, вам потрібно принаймні два учасники для початку локалізації.

Всі команди локалізації повинні бути самостійними. Вебсайт Kubernetes радий опублікувати вашу роботу, але вам потрібно перекладати вміст і підтримувати наявний локалізований вміст.

Вам потрібно зʼясувати дволітерний код вашої мови. Зверніться до стандарту ISO 639-1, щоб знайти дволітерний код вашої мови. Наприклад, дволітерний код для української мови — uk.

Якщо мова, для якої ви починаєте локалізацію, використовується в різних місцевостях зі значними відмінностями, можливо, має сенс поєднати дволітерний код країни з дволітерним кодом мови. Наприклад, бразильська португальська позначається як pt-br.

Коли ви починаєте нову локалізацію, вам потрібно локалізувати мінімально необхідний вміст перед тим, як проєкт Kubernetes зможе опублікувати ваші зміни на сайті.

SIG Docs може допомогти вам з роботою в окремій гілці, щоб ви могли поступово працювати для досягнення цієї мети.

Пошук спільноти

Дайте знати команді документації Kubernetes, що ви зацікавлені в створенні локалізації! Приєднуйтесь до каналу Slack SIG Docs та каналу Slack SIG Docs Localizations. Інші команди локалізації будуть раді допомогти вам почати та відповісти на ваші питання.

Розгляньте, будь ласка, можливість участі в зустрічі підгрупи локалізації SIG Docs. Місією підгрупи локалізації SIG Docs є співпраця з командами локалізації SIG Docs з метою спільного визначення та документування процесів створення локалізованих посібників. Крім того, підгрупа локалізації SIG Docs розглядає можливості створення та обміну загальними інструментами серед команд локалізації та визначення нових вимог для команди керівників SIG Docs. Якщо у вас є питання щодо цього засідання, будь ласка, запитуйте на каналі Slack SIG Docs Localizations.

Ви також можете створити канал Slack для своєї локалізації в репозиторії kubernetes/community. Для прикладу, як додавати канал в Slack, див. PR для додавання каналу для перської мови.

Приєднуйтесь до організації Kubernetes на GitHub

Коли ви відкрили PR для локалізації, ви можете стати учасниками організації Kubernetes. Кожна особа в команді повинна створити свій власний Запит на членство в організації у репозиторії kubernetes/org.

Додайте свою команду локалізації на GitHub

Далі, додайте свою команду локалізації Kubernetes в sig-docs/teams.yaml. Для прикладу додавання команди локалізації, див. PR для додавання іспанської команди локалізації.

Члени @kubernetes/sig-docs-**-owners можуть схвалювати PR, які змінюють вміст в межах (і лише в межах) вашої теки локалізації: /content/**/. Для кожної локалізації команда @kubernetes/sig-docs-**-reviews автоматизує додавання рецензій для нових PR. Члени @kubernetes/website-maintainers можуть створювати нові гілки локалізації для координації зусиль з перекладу. Члени @kubernetes/website-milestone-maintainers можуть використовувати команду Prow /milestone для призначення віхи завдання чи PR.

Налаштування робочого процесу

Далі, додайте мітку GitHub для вашої локалізації в репозиторії kubernetes/test-infra. Мітка дозволяє вам фільтрувати завдання та пул-реквести для вашої мови.

Приклад додавання мітки для італійської мови.

Зміна конфігурації сайту

Вебсайт Kubernetes використовує Hugo для обслуговування вмісту. Конфігурація вебсайту знаходиться в файлі hugo.toml. Вам потрібно внести зміни у hugo.toml для увімкнення підтримки нової локалізації.

Додайте блок конфігурації для нової мови до hugo.toml в блок [languages]. Наприклад, блок для німецької мови виглядає так:

[languages.de]
title = "Kubernetes"
description = "Produktionsreife Container-Verwaltung"
languageName = "Deutsch (German)"
languageNameLatinScript = "Deutsch"
contentDir = "content/de"
weight = 8

Змінна languageName містить назву мови, яка показується в панелі вибору мови. Вкажіть у languageName назву в форматі "назва мови вашою мовою (назва мови англійською мовою)". Наприклад, languageName = "한국어 (Korean)" або languageName = "Deutsch (German)".

languageNameLatinScript може використовуватись для доступу до мови латиницею та використовувати в темах. Вкажіть "назва мови латиною" у languageNameLatinScript. Наприклад, languageNameLatinScript = "Korean" або languageNameLatinScript = "Deutsch".

Параметр weight визначає порядок мов у панелі вибору мови. Менше значення weight має пріоритет, що призводить до того, що мова показується першою. Призначаючи параметр weight, важливо ретельно ознайомитись з наявними блоками мов та змінити їх вагу, щоб вони були впорядковані відносно всіх мов, включаючи будь-які нові мови.

Для отримання додаткової інформації щодо багатомовної підтримки Hugo дивіться "Multilingual Mode".

Додавання нової теки локалізації

Додайте теку для вашої мови в теку content в репозиторії. Наприклад, дволітерний код для німецької мови — de:

mkdir content/de

Також потрібно створити теку всередині data/i18n для локалізованих рядків; перегляньте наявні локалізації для прикладу. Для використання цих нових рядків, вам також потрібно створити символічне посилання з i18n/<код-мови>.toml на фактичну конфігурацію рядків у data/i18n/<код-мови>/<код-мови>.toml (не забудьте додати символічне посилання в коміт).

Наприклад, для німецької мови рядки знаходяться в data/i18n/de/de.toml, і i18n/de.toml — це символічне посилання на data/i18n/de/de.toml.

Локалізуйте community code of conduct

Створіть пул-реквест в репозиторії cncf/foundation для додавання правил спільноти вашою мовою.

Створіть файли OWNERS

Для призначення ролей кожному учаснику, який вносить внесок у локалізацію, створіть файл OWNERS всередині підтеки, яка відповідає вашій мові, з таким вмістом

Докладніше про файл OWNERS дивіться — go.k8s.io/owners.

Для прикладу файл Spanish OWNERS, з кодом мови es, виглядає так:

# See the OWNERS docs at https://go.k8s.io/owners

# This is the localization project for Spanish.
# Teams and members are visible at https://github.com/orgs/kubernetes/teams.

reviewers:
- sig-docs-es-reviews

approvers:
- sig-docs-es-owners

labels:
- language/es

Після додавання файлу OWNERS для вашої мови, оновіть кореневий файл OWNERS_ALIASES новою командою Kubernetes для локалізації, sig-docs-**-owners та sig-docs-**-reviews.

Для кожної команди додайте список користувачів GitHub, які потрібні на етапі Додайте свою команду локалізації на GitHub, в алфавітному порядку.

--- a/OWNERS_ALIASES
+++ b/OWNERS_ALIASES
@@ -48,6 +48,14 @@ aliases:
     - stewart-yu
     - xiangpengzhao
     - zhangxiaoyu-zidif
+  sig-docs-es-owners: # Admins for Spanish content
+    - alexbrand
+    - raelga
+  sig-docs-es-reviews: # PR reviews for Spanish content
+    - alexbrand
+    - electrocucaracha
+    - glo-pena
+    - raelga
   sig-docs-fr-owners: # Admins for French content
     - perriea
     - remyleone

Створіть пул-реквест

Далі, створіть пул-реквест (PR) для додавання локалізації в репозиторій kubernetes/website. PR повинен містити мінімально необхідний вміст перед тим, як він може бути схваленим.

Наприклад додавання нової локалізації для французької мови.

Додайте локалізований файл README

Щоб керувати іншими учасниками локалізації, додайте новий README-**.md в корінь репозиторію kubernetes/website, де ** — дволітерний код мови. Наприклад, файл README для української мови буде README-uk.md.

Скеровуйте учасників локалізації до локалізованого файлу README-**.md. Додайте туди ту ж інформацію, що міститься в README.md, а також:

  • Контактну інформацію проєкту локалізації
  • Будь-яку інформацію, специфічну для локалізації

Після створення локалізованого README, додайте посилання на файл у головний англійський README.md, а також включіть контактну інформацію англійською мовою. Ви можете надати ідентифікатор GitHub, адресу електронної пошти, канал Slack або інший метод звʼязку. Ви також повинні надати посилання на локалізований Кодекс поведінки спільноти.

Запуск вашої нової локалізації

Коли локалізація відповідає вимогам для робочого процесу та мінімальним вимогам щодо вмісту, SIG Docs робить наступне:

  • Вмикає на вебсайті відповідний мовний розділ.
  • Сповіщає про наявність локалізованого вмісту через канали Cloud Native Computing Foundation (CNCF), включаючи блог Kubernetes.

Локалізація вмісту

Локалізація всього вмісту Kubernetes є неосяжним завданням. Необхідно починати з мінімально необхідного вмісту та поступово розширювати його.

Мінімально необхідний вміст

Як мінімум, всі локалізації мають містити:

ОписПосилання
ДокументаціяВсі заголовки та підзаголовки
Початок роботиВсі заголовки та підзаголовки
ПосібникиОснови Kubernetes, Привіт Minikube
Локалізація сайтуВсі рядки в новому TOML файлі локалізації
ВипускиВсі заголовки та підзаголовки

Перекладена документація має знаходитись у власній підтеці content/**/ та мати ту ж URL-структуру, що й англійська версія. Наприклад, щоб підготувати Основи Kubernetes для перекладу німецькою мовою, створіть підтеку у content/de та скопіюйте в неї сирці англійської версії:

mkdir -p content/de/docs/tutorials
cp -ra content/en/docs/tutorials/kubernetes-basics/ content/de/docs/tutorials/

Інструменти для роботи з перекладами значно прискорюють процес перекладу. Наприклад, деякі редактори пропонують втулки для швидкого перекладу тексту.

Щоб переконатись в точності та відповідності перекладу, члени вашої команди локалізації повинні ретельно переглянути всі машинно-генеровані переклади перед публікацією.

Локалізація зображень SVG

Проєкт Kubernetes рекомендує використовувати векторні (SVG) зображення, де це можливо, оскільки їх набагато легше редагувати командам локалізації. Якщо ви знаходите растрове зображення, яке потрібно локалізувати, розгляньте можливість спочатку перетворення англійської версії у векторне зображення, а потім локалізуйте його.

При перекладі тексту всередині векторних зображень (SVG — Scalable Vector Graphics) важливо дотримуватися певних рекомендацій, щоб забезпечити точність і підтримувати однорідність між різними мовними версіями. Зображення SVG часто використовуються в документації Kubernetes для ілюстрації концепцій, робочих процесів та схем.

  1. Визначення тексту для перекладу: Почніть з ідентифікації текстових елементів всередині SVG-зображення, які потрібно перекласти. Зазвичай до цих елементів входять мітки, підписи, анотації чи будь-який текст, що передає інформацію.

  2. Редагування файлів SVG: Файли SVG базуються на XML, що означає, що їх можна редагувати за допомогою текстового редактора. Проте важливо враховувати, що більшість зображень в документації Kubernetes вже конвертують текст в криві, щоб уникнути проблем сумісності шрифтів. У таких випадках рекомендується використовувати спеціалізоване програмне забезпечення для редагування SVG, таке як Inkscape. Відкрийте файл SVG у програмі Inkscape та знайдіть елементи тексту, які потребують перекладу.

  3. Переклад текстів: Замініть оригінальний текст перекладеною версією бажаною мовою. Переконайтеся, що перекладений текст точно виражає задумане значення і вміщується у вільне простір у зображенні. При роботі з мовами, які використовують латинський алфавіт, слід використовувати сімʼю шрифтів Open Sans. Ви можете завантажити шрифт Open Sans за цим посиланням: Open Sans Typeface.

  4. Перетворення тексту в криві: Як вже зазначалося, для розвʼязання проблеми сумісності шрифтів рекомендується конвертувати перекладений текст в криві. Конвертація тексту в криві гарантує правильне відображення перекладеного тексту у кінцевому зображенні, навіть якщо система користувача не має шрифту, використаного в оригінальному SVG.

  5. Перегляд та тестування: Після перекладу і конвертації тексту в криві, збережіть та перегляньте оновлене SVG-зображення, щоб переконатися, що текст правильно показується та відповідно вирівняний. Виконайте Попередній перегляд ваших змін локально.

Файли сирців

Локалізація має базуватись на файлах англійською мовою з конкретного релізу, на який спрямовані зусилля команди локалізації. Кожна команда локалізації може визначити, на який реліз спрямовані її зусилля, що позначено нижче як цільова версія.

Для пошуку файлів сирців для цільової версії:

  1. Перейдіть до репозиторію вебсайту Kubernetes https://github.com/kubernetes/website.

  2. Оберіть гілку з вашою цільовою версією користуючись таблицею:

Цільова версіяГілка
Остання версіяmain
Попередня версіяrelease-1.30
Наступна версіяdev-1.32

Гілка main містить вміст для поточного релізу v1.31. Команда релізу створює гілку release-1.31 перед наступним релізом: v1.32.

Рядки сайту в i18n

Локалізація має включати вміст data/i18n/en/en.toml у новому файлі для відповідної мови. Наприклад, для німецької мови: data/i18n/de/de.toml.

Додайте нову теку для локалізації та файл до data/i18n/. Наприклад, для німецької мови (de):

mkdir -p data/i18n/de
cp data/i18n/en/en.toml data/i18n/de/de.toml

Ознайомтесь з коментарями вгорі файлу, щоб зрозуміти, які рядки потрібно локалізувати. Наприклад, це німецькомовний текст-заповнювач для поля пошуку:

[ui_search_placeholder]
other = "Suchen"

Локалізовані рядки сайту дозволяють вам налаштувати текстові рядки, які використовуються в багатьох місцях на сайті. Наприклад, текст копірайту в підвалі на кожній сторінці.

Настанови щодо локалізації певною мовою

Як команда локалізації, ви можете формалізувати найкращі практики, які використовує ваша команда, створивши мовно-специфічний посібник з локалізації.

Наприклад, див. Корейський посібник з локалізації, який включає опис таких тем, як:

  • Частота спринтів та релізи
  • Стратегія створення гілок
  • Робота з pull request
  • Посібник зі стилю
  • Глосарій локалізованих та нелокалізованих термінів
  • Конвенції Markdown
  • Термінологія обʼєктів Kubernetes API

Зустрічі в Zoom для обговорення локалізації відповідною мовою

Якщо проєкту з локалізації потрібен окремий час на зустрічі, звʼяжіться з одним з координаторів SIG Docs або Tech Lead, щоб створити нову регулярну зустріч в Zoom та запрошення в календар. Це потрібно тільки тоді, коли команда достатньо велика та вимагає окремих зустрічей.

Відповідно до правил CNCF, команди локалізації повинні завантажувати свої зустрічі в плейлист YouTube SIG Docs. Координатор SIG Docs або Tech Lead може допомогти з цим процесом до тих пір, поки SIG Docs не автоматизує його.

Стратегія створення гілок

Оскільки проєкти локалізації є зусиллями кількох осіб, ми закликаємо команди працювати в спільних гілках локалізації, особливо на початковому етапі, коли локалізація ще не є оприлюдненою.

Щоб співпрацювати в гілці локалізації:

  1. Член команди @kubernetes/website-maintainers створює гілку локалізації з гілки основного проєкту https://github.com/kubernetes/website.

    Особи з вашої команди, які затверджують зміни, приєднуються до команди @kubernetes/website-maintainers, коли ви створюєте свою команду локалізації до репозиторію kubernetes/org.

    Ми радимо наступну схему найменування гілок:

    dev-<source version>-<language code>.<team milestone>

    Наприклад, затверджувач зміни німецької команди створює гілку для локалізації dev-1.12-de.1 безпосередньо в репозиторії kubernetes/website, яка базується на гілці для Kubernetes v1.12.

  2. Індивідуальні учасники створюють гілки-теми на основі гілки локалізації.

    Наприклад, учасник німецькою команди створює пул-реквест зі змінами у kubernetes:dev-1.12-de.1 з username:local-branch-name.

  3. Затверджувач переглядає зміни та зливає гілку-тему в гілку локалізації.

  4. Періодично затверджувач обʼєднує гілку локалізації зі своєю вихідною гілкою, відкриваючи та затверджуючи новий pull request. Обовʼязково обʼєднуйте (squash) коміти перед затвердженням pull request.

Повторюйте кроки 1-4 за потреби, поки локалізація не буде завершена. Наприклад, наступні гілки локалізації німецькою мовою будуть: dev-1.12-de.2, dev-1.12-de.3 і т.д.

Команди повинні обʼєднувати локалізований вміст у ту гілку, з якої вміст було отримано. Наприклад:

  • Гілку локалізації створену з гілки main потрібно заливати у гілку main.
  • Гілку локалізації створену з release-1.30 потрібно заливати у release-1.30.

На початку кожного етапу команді корисно відкрити тікет для порівняння висхідних змін між попередньою гілкою локалізації та поточною гілкою. Є два скрипти для порівняння змін.

  • upstream_changes.py є корисним для перевірки змін, що були зроблені у відповідному файлі, та
  • diff_l10n_branches.py є корисним для створення переліку застарілих файлів для відповідної гілки локалізації.

Хоча тільки затверджувачі можуть створювати нові гілки локалізації та обʼєднувати пул-реквести, будь-хто може відкрити пул-реквести для нової гілки локалізації. Для цього спеціальні дозволи не потрібні.

Для отримання додаткової інформації про роботу з форками або безпосередньо з репозиторієм, див. "розгалуження та клонування репозиторію".

Внесення змін до оригінальної документації

Команда SIG Docs вітає внески та виправлення до англійської версії документації.

7.6 - Участь у SIG Docs

SIG Docs є однією з робочих груп в проєкті Kubernetes, яка зосереджена на написанні, оновленні та підтримці документації для Kubernetes в цілому. Дивіться SIG Docs в репозиторії спільноти GitHub для отримання додаткової інформації про SIG.

SIG Docs вітає контент та рецензування від усіх учасників. Будь-хто може відкрити pull request (PR), і будь-хто може подавати питання щодо контенту або коментувати pull request'и, що знаходяться в процесі.

Ви також можете стати членом, рецензентом або затверджувачем. Ці ролі вимагають більшого доступу і несуть певні обов’язки щодо затвердження та прийняття змін. Дивіться community-membership для отримання додаткової інформації про те, як працює членство в спільноті Kubernetes.

Решта цього документа описує деякі унікальні способи функціонування цих ролей у SIG Docs, яка відповідає за підтримку одного з найбільш публічно орієнтованих аспектів Kubernetes — вебсайту та документації Kubernetes.

Голова SIG Docs

Кожна SIG, включаючи SIG Docs, обирає одного або кількох членів SIG для виконання ролі голови. Ці особи є контактними точками між SIG Docs та іншими частинами організації Kubernetes. Від них вимагається глибоке знання структури проєкту Kubernetes в цілому та того, як SIG Docs працює в ньому. Дивіться Leadership для ознайомлення з актуальним списку голів.

Команди та автоматизація SIG Docs

Автоматизація в SIG Docs покладається на два різних механізми: GitHub команди та файли OWNERS.

Команди GitHub

Існує дві категорії команд SIG Docs у GitHub:

  • @sig-docs-{language}-owners є затверджувачами та лідерами
  • @sig-docs-{language}-reviews є рецензентами

Кожну з них можна згадати за допомогою їхнього @name в коментарях на GitHub, щоб спілкуватися з усіма в цій групі.

Іноді Prow та команди GitHub збігаються без точного відповідності. Для призначення тікетів, pull request'ів та підтримки затвердження PR автоматизація використовує інформацію з файлів OWNERS.

Файли OWNERS та front-matter

Проєкт Kubernetes використовує автоматизаційний інструмент під назвою prow для автоматизації, повʼязаної з тікетами та pull requestʼами на GitHub. Репозиторій вебсайту Kubernetes використовує два втулки prow:

  • blunderbuss
  • approve

Ці два втулки використовують файли OWNERS та OWNERS_ALIASES на верхньому рівні репозиторію kubernetes/website GitHub для контролю роботи prow у репозиторії.

Файл OWNERS містить список людей, які є рецензентами та затверджувачами SIG Docs. Файли OWNERS також можуть існувати в підтеках та можуть перевизначати, хто може виступати як рецензент або затверджувач файлів у цій теці та вкладених теках. Для отримання додаткової інформації про файли OWNERS в цілому дивіться OWNERS.

Крім того, сам Markdown файл може містити список рецензентів та затверджувачів у його front-matter, вказуючи індивідуальні імена користувачів GitHub або групи GitHub.

Комбінація файлів OWNERS та front-matter у файлах Markdown визначає поради, які отримують власники PR від автоматизованих систем щодо того, кого попросити про технічний та редакційний огляд їх PR.

Як працює злиття

Коли pull request зливається з гілкою, що використовується для публікації контенту, цей контент публікується на http://kubernetes.io. Щоб забезпечити високу якість нашого опублікованого контенту, ми обмежуємо злиття pull requestʼів до затверджувачів SIG Docs. Ось як це працює.

  • Коли pull request має обидві мітки lgtm та approve, не має міток hold та всі тести проходять успішно, pull request зливається автоматично.
  • Члени організації Kubernetes та затверджувачі SIG Docs можуть додавати коментарі для запобігання автоматичного злиття конкретного pull request (додавши коментар /hold або утримуючись від додавання коментаря /lgtm).
  • Будь-який член Kubernetes може додати мітку lgtm, додавши коментар /lgtm.
  • Тільки затверджувачі SIG Docs можуть зливати pull request, додаючи коментар /approve. Деякі затверджувачі також виконують додаткові ролі, такі як PR Wrangler або голова SIG Docs.

Що далі

Для отримання додаткової інформації про внесок до документації Kubernetes дивіться:

7.6.1 - Ролі та обовʼязки

Будь-хто може зробити внесок у Kubernetes. Зі зростанням ваших внесків до SIG Docs, ви можете подати заявку на різні рівні членства в спільноті. Ці ролі дозволяють брати на себе більше відповідальності в спільноті. Кожна роль вимагає більше часу та відданості. Ролі є такими:

  • Будь-хто: регулярні учасники документації Kubernetes
  • Члени: можуть призначати та розподіляти тікети, а також надавати відгук на pull requestʼи, який не є обовʼязковим до виконання
  • Рецензенти: можуть керувати рецензією документаційних pull request'ів і гарантувати якість змін
  • Затверджувачі: можуть керувати рецензією документації та зливати зміни

Будь-хто

Будь-хто з обліковим записом GitHub може зробити свій внесок у Kubernetes. SIG Docs вітає всіх нових учасників!

Будь-хто може:

Після підписання CLA, будь-хто також може:

  • Створити pull request для покращення наявного контенту, додавання нового контенту або написання блогу чи прикладу використання
  • Створювати діаграми, графічні ресурси та вбудовані відеозаписи та відео

Для отримання додаткової інформації дивіться додавання нового контенту.

Члени

Член — це хтось, хто подав кілька pull request'ів до kubernetes/website. Члени є частиною організації Kubernetes на GitHub.

Члени можуть:

  • Робити все, що зазначено в розділі Будь-хто

  • Використовувати коментар /lgtm, щоб додати мітку LGTM (виглядає добре для мене) до pull request'у

  • Використовувати коментар /hold, щоб заблокувати злиття для pull request'у

  • Використовувати коментар /assign, щоб призначити рецензента для pull requestʼу

  • Робити рецензування pull request'ів, які не є обовʼязковими

  • Використовувати автоматизацію для розподілу та категоризації тікетів

  • Документувати нові функції

Набуття членства

Після подання щонайменше 5 значних pull request'ів та виконання інших вимог:

  1. Знайдіть двох рецензентів або затверджувачів, які стануть вашими поручителями.

    Попросіть поручительства в каналі #sig-docs на Slack або в списку розсилки SIG Docs.

  2. Відкрийте тікет на GitHub у репозиторії kubernetes/org. Використовуйте шаблон тікета Organization Membership Request.

  3. Повідомте своїх поручителів про тікет на GitHub. Ви можете:

    • Згадати їх через GitHub-імʼя у тікеті (@<GitHub-username>)

    • Надіслати їм посилання на тікет за допомогою Slack або електронної пошти.

      Поручителі схвалюють ваш запит позначкою +1. Після схвалення запиту вашими поручителями, адміністратор GitHub Kubernetes додає вас як члена. Вітаємо!

      Якщо ваш запит на членство не приймається, ви отримаєте відгук. Після врахування відгуків подайте заявку знову.

  4. Прийміть запрошення до організації Kubernetes на GitHub у своєму обліковому записі електронної пошти.

Рецензенти

Рецензенти відповідають за рецензування відкритих pull request'ів. На відміну від відгуків членів, автор PR повинен враховувати відгуки рецензентів. Рецензенти є членами команди GitHub @kubernetes/sig-docs-{language}-reviews.

Рецензенти можуть:

  • Робити все, що зазначено в розділах Будь-хто та Члени

  • Оглядати pull requestʼи та надавати обовʼязковий відгук

  • Редагувати рядки, що стосуються користувачів, у коді

  • Покращувати коментарі до коду

Ви можете бути рецензентом SIG Docs або рецензентом для документів у певній предметній області.

Призначення рецензентів до pull requestʼів

Автоматизація призначає рецензентів до всіх pull requestʼів. Ви можете запросити огляд від конкретної особи, додавши коментар: /assign [@_github_handle].

Якщо призначений рецензент не прокоментував PR, інший рецензент може втрутитися. Ви також можете призначати технічних рецензентів за потреби.

Використання /lgtm

LGTM означає "Виглядає добре для мене" і вказує, що pull request є технічно точним і готовим до злиття. Усі PR потребують коментаря /lgtm від рецензента та коментаря /approve від затверджувача для злиття.

Коментар /lgtm від рецензента є обовʼязковим і запускає автоматизацію, яка додає мітку lgtm.

Як стати рецензентом

Коли ви відповідаєте вимогам, ви можете стати рецензентом SIG Docs. Рецензенти в інших SIG повинні подавати окрему заявку на статус рецензента в SIG Docs.

Щоб подати заявку:

  1. Відкрийте pull request, що додає ваше імʼя користувача GitHub до розділу файлу OWNERS_ALIASES в репозиторії kubernetes/website.

  2. Призначте PR одному або кільком затверджувачам SIG Docs (імена користувачів вказані в sig-docs-{language}-owners).

Якщо заявку схвалено, лідер SIG Docs додає вас до відповідної команди GitHub. Після додавання K8s-ci-robot призначає та пропонує вас як рецензента на нові pull requestʼи.

Затверджувачі

Затверджувачі оглядають і затверджують pull requestʼи для злиття. Затверджувачі є членами команд GitHub @kubernetes/sig-docs-{language}-owners.

Затверджувачі можуть робити наступне:

  • Все, що зазначено в розділах Будь-хто, Члени та Рецензенти
  • Публікувати контент учасників, затверджуючи та зливаючи pull requestʼи за допомогою коментаря /approve
  • Пропонувати покращення до посібника зі стилю
  • Пропонувати покращення до тестів документації
  • Пропонувати покращення до вебсайту Kubernetes або інших інструментів

Якщо PR вже має /lgtm, або якщо затверджувач також додає коментар /lgtm, PR автоматично зливається. Затверджувач SIG Docs повинен залишити коментар /lgtm лише на змінах, які не потребують додаткового технічного огляду.

Затвердження pull requestʼів

Затверджувачі та лідери SIG Docs є єдиними, хто може зливати pull requestʼи в репозиторій вебсайту. Це супроводжується певними обовʼязками.

  • Затверджувачі можуть використовувати команду /approve, яка зливає PR в репозиторій.

  • Переконайтеся, що запропоновані зміни відповідають посібнику зі змісту документації.

    Якщо у вас є питання, або ви не впевнені в чомусь, не соромтеся запросити додатковий огляд.

  • Переконайтеся, що тести Netlify пройшли перед тим, як ви використаєте команду /approve для PR.

    Тести Netlify повинні пройти перед затвердженням
  • Відвідайте попередній перегляд сторінки Netlify для PR, щоб переконатися, що все виглядає добре перед затвердженням.

  • Беріть участь у графіку чергування PR Wrangler для щотижневих ротацій. SIG Docs очікує, що всі затверджувачі братимуть участь у цій ротації. Дивіться PR чергування для отримання додаткової інформації.

Як стати затверджувачем

Коли ви відповідаєте вимогам, ви можете стати затверджувачем SIG Docs. Затверджувачі в інших SIG повинні подавати окрему заявку на статус затверджувача в SIG Docs.

Щоб подати заявку:

  1. Відкрийте pull request, що додає вас до розділу файлу OWNERS_ALIASES у репозиторії kubernetes/website.

  2. Призначте PR одному або кільком поточним затверджувачам SIG Docs.

Якщо заявку схвалено, лідер SIG Docs додає вас до відповідної команди GitHub. Після додавання, @k8s-ci-robot призначає та пропонує вас як рецензента на нові pull request'и.

Що далі

  • Прочитайте про PR чергування, роль, яку всі затверджувачі виконують по черзі.

7.6.2 - Відповідальні за PR

SIG Docs затверджувачі беруть участь у тижневих чергуваннях стосовно управління pull request'ами для репозиторію.

Цей розділ охоплює обовʼязки відповідальних за PR. Для отримання додаткової інформації щодо якісного рецензування, дивіться Рецензування змін.

Обовʼязки

Кожного дня під час тижневого чергування відповідальний за PR:

  • Робить огляд відкритих pull request'ів на відповідність стилю та змісту.
    • Почніть з найменших PRʼів (size/XS), і закінчіть найбільшими (size/XXL). Огляньте стільки PRʼів, скільки зможете.
  • Переконайтеся, що учасники PR підписали CLA.
    • Використовуйте цей скрипт, щоб нагадати учасникам, які не підписали CLA, зробити це.
  • Надання відгуків про зміни та запит технічних оглядів від членів інших SIG.
    • Надання своїх пропозицій щодо запропонованих змін у PR.
    • Якщо вам потрібно перевірити зміст, залиште коментар у PR і запросіть більше деталей.
    • Призначте відповідну мітку(и) sig/.
    • Якщо необхідно, призначте рецензентів з блоку reviewers: у метаданих файлу.
    • Ви також можете позначити SIG для огляду, коментуючи @kubernetes/<sig>-pr-reviews у PR.
  • Використовуйте коментар /approve для затвердження PR для злиття. Зливайте PR, коли він готовий.
    • PRʼи повинні мати коментар /lgtm від іншого члена перед злиттям.
    • Розгляньте можливість прийняття технічно правильного змісту, який не відповідає настановам зі стилю. Під час затвердження змін відкрийте новий тікет для розвʼязання питання стилю. Зазвичай такі питання стилю можна описати як гарні перші завдання.
    • Використання виправлень стилю як гарних перших завдань — це хороший спосіб забезпечити наявність легших завдань для допомоги в адаптації нових учасників.
  • Також перевіряйте pull requestʼи до коду генератора довідкової документації та оглядайте їх (або залучайте допомогу).
  • Підтримуйте відповідального за тікети у розгляді та теґуванні нових тікетів щодня. Дивіться Розгляд та категоризація тікетів для керівництва з використання метаданих SIG Docs.

Корисні запити GitHub для відповідальних

Наступні запити корисні під час роботи з PRʼами. Після обробки цих запитів зазвичай залишається невеликий список PRʼів для огляду. Ці запити виключають PRʼи локалізації. Усі запити стосуються основної гілки, крім останнього.

  • Без CLA, не допускається до злиття: Нагадуйте учаснику підписати CLA. Якщо і бот, і людина нагадали їм, закрийте PR і нагадайте їм, що вони можуть відкрити його після підписання CLA. Не оглядайте PRʼи, автори яких не підписали CLA!
  • Потребує LGTM: Перелік PRʼів, які потребують LGTM від члена. Якщо PR потребує технічного огляду, залучайте одного з рецензентів, запропонованих ботом. Якщо зміст потребує доопрацювання, додайте пропозиції та відгуки безпосередньо.
  • Має LGTM, потребує затвердження документації: Перелік PRʼів, які потребують коментаря /approve для злиття.
  • Швидкі виграші: Перелік PRʼів до основної гілки без явних блокувань. (змініть "XS" у розмірі мітки, коли будете працювати з PRʼами [XS, S, M, L, XL, XXL]).
  • Не для основної гілки: Якщо PR для гілки dev-, це для майбутнього випуску. Призначте менеджера випуску документації використовуючи: /assign @<github-ім'я_менеджера>. Якщо PR для старої гілки, допоможіть автору визначити кращу гілку.

Корисні команди Prow для відповідальних

# додати мітку англійської мови
/language en

# додати мітку squash до PR, якщо твм більше одного коміту
/label tide/merge-method-squash

# перейменувати PR через Prow (наприклад, робота в процесі [WIP] або кращий опис PR)
/retitle [WIP] <TITLE>

Коли закривати Pull Request'и

Огляди та затвердження є одним з інструментів для утримання нашої черги PR короткою та актуальною. Іншим інструментом є закриття.

Закрийте PRʼи, де:

  • Автор не підписав CLA протягом двох тижнів.

    Автори можуть відкрити PR знову після підписання CLA. Це малоризикований спосіб переконатися, що нічого не зливається без підписаного CLA.

  • Автор не відповів на коментарі чи відгуки протягом 2 або більше тижнів.

Не бійтеся закривати pull request'и. Учасники можуть легко відкрити знову та продовжити роботу. Часто повідомлення про закриття є тим, що спонукає автора продовжити та завершити свій внесок.

Щоб закрити pull request, залиште коментар /close у PR.

Програма тіньового відповідального за PR

У кінці 2021 року SIG Docs представив PR Wrangler Shadow Program. Програма була введена для допомоги новим учасникам зрозуміти процес управління PR.

Як стати тіньовим відповідальним за PR

  • Якщо ви зацікавлені у тому, щоби стати тіньовим відповідальним за PR, будь ласка, відвідайте сторінку Wiki PR Wrangler'ів, щоб побачити графік управління PR на цей рік та зареєструватися.

  • Інші можуть звернутися до Slack-каналу #sig-docs для запиту на участь у підтримці відповідальних за PR на конкретний тиждень. Не соромтеся звертатися до Бреда Топола (@bradtopol) або одного зі співголів/лідерів SIG Docs.

  • Після реєстрації на підтримку відповідального за PR, представте себе відповідальному за PR у Kubernetes Slack.

7.6.3 - Відповідальні за тікети

На додаток до PR чергування, офіційні затверджувачі, рецензенти та члени SIG Docs беруть участь у тижневих чергуваннях у розгляді та категоризації тікетів в репозиторії.

Обовʼязки

Кожного дня під час тижневого чергування Відповідальний за тікети буде відповідати за:

Вимоги

  • Повинен бути активним членом організації Kubernetes.
  • Мінімум 15 значущих внесків у Kubernetes (з яких певна кількість має бути спрямована на kubernetes/website).
  • Виконання ролі неофіційно вже деякий час.

Корисні команди Prow для відповідальних за тікети

Нижче наведені деякі команди, що часто використовуються Відповідальними за тікетами:

# відкрити тікет знов
/reopen

# перенести тікет, що не підходять для k/website до іншого репозиторію
/transfer[-issue]

# змінити стан "протухлих" тікетів
/remove-lifecycle rotten

# змінити стан застарілих тікетів
/remove-lifecycle stale

# призначити sig до тікета
/sig <sig_name>

# додати конкретну область
/area <area_name>

# для тікетів, що підходять для початківців
/good-first-issue

# тікети, що потребують допомоги
/help wanted

# тегування тікетів як підтримки
/kind support

# прийняти розгляду для тікета
/triage accepted

# закрити тікета, з яким ми не будемо працювати і який ще не виправлено
/close not-planned

Щоб знайти більше команд Prow, зверніться до документації Command Help.

Коли закривати тікети

Для успіху проєкту з відкритим вихідним кодом важливо добре керувати тікетами. Але також критично важливо розвʼязувати питання, щоб підтримувати репозиторій і чітко спілкуватися з учасниками та користувачами.

Закривайте тікети, коли:

  • Схожа проблема повідомляється більше одного разу. Спочатку потрібно позначити її як /triage duplicate; повʼязати її з основним тікетом та потім закрити. Також рекомендується направити користувачів до оригінального тікета.
  • Дуже важко зрозуміти та розвʼязати проблему, представлену автором, з наданою інформацією. Однак, заохочуйте користувача надати більше деталей або відкрити питання знову, якщо він зможе відтворити його пізніше.
  • Така ж функціональність реалізована деінде. Можна закрити цей тікет та направити користувача в потрібне місце.
  • Повідомлена проблема наразі не відповідає цілям проєкту або не планується до розвʼязання.
  • Якщо тікет виглядає як спам і явно не стосується теми.
  • Якщо проблема повʼязана з зовнішнім обмеженням або залежністю і знаходиться поза контролем проєкту.

Щоб закрити питання, залиште коментар /close на питання.

7.7 - Cтиль документації

Матеріали цього розділу надають настанови щодо стилю написання, форматування та організації контенту, а також використання налаштувань Hugo, специфічних для документації Kubernetes.

7.7.1 - Посібник з вмісту документації

Ця сторінка містить вказівки щодо документації Kubernetes.

Якщо у вас є запитання про те, що дозволено, приєднуйтесь до каналу #sig-docs у Kubernetes Slack і запитуйте!

Ви можете зареєструватися на Kubernetes Slack за адресою https://slack.k8s.io/.

Для отримання інформації про створення нового вмісту для документації Kubernetes, дотримуйтесь посібника зі стилю.

Огляд

Сирці вебсайту Kubernetes, включаючи документацію, знаходиться в репозиторії kubernetes/website.

Більшість документації Kubernetes знаходиться в теці kubernetes/website/content/<language_code>/docs і специфічна для проєкту Kubernetes.

Що дозволено

Документація Kubernetes дозволяє вміст зі сторонніх проєктів тільки тоді, коли:

  • Вміст документує програмне забезпечення в проєкті Kubernetes
  • Вміст документує програмне забезпечення, яке знаходиться поза проєктом, але необхідне для функціонування Kubernetes
  • Вміст є канонічним на kubernetes.io або посилається на канонічний вміст в іншому місці

Сторонній вміст

Документація Kubernetes включає приклади застосування проєктів у проєкті Kubernetes — проєктів, що знаходяться в організаціях GitHub kubernetes та kubernetes-sigs.

Посилання на активний вміст у проєкті Kubernetes завжди дозволені.

Для функціонування Kubernetes необхідний деякий сторонній вміст. Прикладами є контейнерні середовища (containerd, CRI-O, Docker), мережева політика (втулки CNI), контролери Ingress, та логування.

Документація може посилатися на стороннє програмне забезпечення з відкритим вихідним кодом (OSS) поза проєктом Kubernetes тільки якщо воно необхідне для функціонування Kubernetes.

Контент з подвійним джерелом

Коли це можливо, документація Kubernetes посилається на канонічні джерела замість розміщення дублікату вмісту.

Контент з подвійним джерелом вимагає вдвічі більше зусиль (або більше!) для підтримки та швидше стає застарілим.

Додаткова інформація

Якщо у вас є запитання про дозволений вміст, приєднуйтесь до каналу #sig-docs у Kubernetes Slack і запитуйте!

Що далі

7.7.2 - Посібник зі стилю документації

Ця сторінка надає вказівки щодо стилю написання документації Kubernetes. Це вказівки, а не правила. Використовуйте здоровий глузд та не соромтеся пропонувати зміни до цього документа за допомогою pull request.

Для отримання додаткової інформації про створення нового вмісту для документації Kubernetes, прочитайте Посібник з вмісту документації.

Зміни до посібника зі стилю вносяться групою SIG Docs. Щоб запропонувати зміну або доповнення, додайте її до порядку денного на наступну зустріч SIG Docs та відвідайте зустріч, щоб взяти участь в обговоренні.

Мова

Документація Kubernetes була перекладена кількома мовами (див. локалізовані файли README).

Процес локалізації документації для інших мови описано в розділіЛокалізація документації Kubernetes.

Документація англійською мовою використовує правопис та граматику американської англійської.

Стандарти форматування документації

Використовуйте UpperCamelCase для обʼєктів API

Коли ви посилаєтеся на взаємодію з обʼєктом API, використовуйте UpperCamelCase, також відомий як Pascal case. Ви можете зустріти інші варіанти написання, наприклад, "configMap", в Довіднику API. У загальній документації краще використовувати UpperCamelCase, називаючи обʼєкт "ConfigMap".

Коли ви загалом обговорюєте обʼєкт API, використовуйте велику літеру тільки на початку речення.

Наведені нижче приклади зосереджуються на капіталізації. Для отримання додаткової інформації про форматування імен обʼєктів API перегляньте відповідні рекомендації щодо Стилю коду.

Як робити та не робити — Використовуйте Pascal case для обʼєктів API
РекомендованоНебажано
Ресурс HorizontalPodAutoscaler відповідає за ...Horizontal pod autoscaler відповідає за ...
Обʼєкт PodList є списком Podʼів.Обʼєкт Pod List є списком Podʼів.
Обʼєкт Volume містить поле hostPath.Обʼєкт volume містить поле hostPath.
Кожен обʼєкт ConfigMap є частиною простору імен.Кожен обʼєкт configMap є частиною простору імен.
Для управління конфіденційними даними розгляньте можливість використання API Secret.Для управління конфіденційними даними розгляньте можливість використання secret API.

Використовуйте кутові дужки для заповнювачів

Використовуйте кутові дужки для заповнювачів. Поясніть читачеві, що представляє заповнювач, наприклад:

Показ інформацію про Pod:

kubectl describe pod <pod-name> -n <namespace>

Якщо простір імен Podʼа є default, ви можете пропустити параметр -n.

Використовуйте жирний шрифт для елементів інтерфейсу користувача

Як робити та не робити — Жирний шрифт для елементів інтерфейсу
РекомендованоНебажано
Натисніть Fork.Натисніть "Fork".
Виберіть Other.Виберіть "Other".

Використовуйте курсив для визначення або введення нових термінів

Як робити та не робити — Використання курсиву для нових термінів
РекомендованоНебажано
Кластер — це набір вузлів ..."Кластер" — це набір вузлів ...
Ці компоненти утворюють панель управління.Ці компоненти утворюють панель управління.

Використовуйте стиль коду для імен файлів, тек та шляхів

Як робити та не робити — Використовуйте кодовий стиль для імен файлів, тек та шляхів
РекомендованоНебажано
Відкрийте файл envars.yaml.Відкрийте файл envars.yaml.
Перейдіть до теки /docs/tutorials.Перейдіть до теки /docs/tutorials.
Відкрийте файл /_data/concepts.yaml.Відкрийте файл /_data/concepts.yaml.

Використовуйте міжнародний стандарт для пунктуації всередині лапок

Як робити та не робити — Використовуйте міжнародний стандарт для пунктуації всередині лапок
РекомендованоНебажано
Події записуються з відповідною "стадією".Події записуються з відповідною "стадією."
Копія називається "fork".Копія називається "fork."

Форматування вбудованого коду

Використовуйте кодовий стиль для вбудованого коду та команд

Для вбудованого в документі HTML коду використовуйте теґ <code>. У документі Markdown використовуйте зворотну лапку (`). Проте, API обʼєкти, такі як StatefulSet або ConfigMap, пишуться дослівно (без зворотних лапок); це дозволяє використовувати апострофи для позначення присвійного відмінка.

Як робити та не робити — Використовуйте стиль code для вбудованого коду, команд та API обʼєктів
РекомендованоНебажано
Команда kubectl run створює Pod.Команда "kubectl run" створює Pod.
Kubelet на кожному вузлі отримує Lease...Kubelet на кожному вузлі отримує Lease...
PersistentVolume представляє довговічне сховище...PersistentVolume представляє довговічне сховище...
Поле .spec.group у CustomResourceDefinition...Поле CustomResourceDefinition.spec.group у CustomResourceDefinition...
Для декларативного управління використовуйте kubectl apply.Для декларативного управління використовуйте "kubectl apply".
Огортайте приклади коду потрійними зворотними лапками. (```)Огортайте приклади коду будь-яким іншим синтаксисом.
Використовуйте одинарні зворотні лапки для вбудованого коду. Наприклад, var example = true.Використовуйте дві зірочки (**) або підкреслення (_) для вбудованого коду. Наприклад, var example = true.
Використовуйте потрійні зворотні лапки перед і після багаторядкового блоку коду для виділених блоків коду.Використовуйте багаторядкові блоки коду для створення діаграм, блок-схем або інших ілюстрацій.
Використовуйте значущі імена змінних, які мають контекст.Використовуйте імена змінних, такі як 'foo', 'bar', і 'baz', які не є значущими та не мають контексту.
Видаляйте пробіли в кінці рядків коду.Додавайте пробіли в кінці рядків коду, коли вони важливі, оскільки інструмент читання тексту з екрана також озвучує пробіли.

Використовуйте стиль коду для імен полів обʼєктів та просторів імен

Як робити та не робити — Використовуйте кодовий стиль для імен полів обʼєктів
РекомендованоНебажано
Встановіть значення поля replicas у конфігураційному файлі.Встановіть значення поля "replicas" у конфігураційному файлі.
Значення поля exec є обʼєктом ExecAction.Значення поля "exec" є обʼєктом ExecAction.
Запустіть процес як DaemonSet у просторі імен kube-system.Запустіть процес як DaemonSet у просторі імен kube-system.

Використовуйте стиль коду для назв команд, інструментів та компонентів Kubernetes

Як робити та не робити — Використовуйте кодовий стиль для назв командних інструментів та компонентів Kubernetes
РекомендованоНебажано
kubelet підтримує стабільність вузла.Kubelet підтримує стабільність вузла.
kubectl відповідає за знаходження та автентифікацію на API сервері.Kubectl відповідає за знаходження та автентифікацію на apiserver.
Запустіть процес із сертифікатом, kube-apiserver --client-ca-file=FILENAME.Запустіть процес із сертифікатом, kube-apiserver --client-ca-file=FILENAME.

Початок речення з назви інструменту або компонента

Як робити та не робити — Початок речення з назви інструменту або компонента
РекомендованоНебажано
The kubeadm tool bootstraps and provisions machines in a cluster.kubeadm tool bootstraps and provisions machines in a cluster.
The kube-scheduler is the default scheduler for Kubernetes.kube-scheduler is the default scheduler for Kubernetes.

Використовуйте загальний дескриптор замість назви компонента

Як робити та не робити — Використовуйте загальний дескриптор замість назви компонента
РекомендованоНебажано
API сервер Kubernetes пропонує специфікацію OpenAPI.Apiserver пропонує специфікацію OpenAPI.
Агреговані API є підпорядкованими API серверами.Агреговані API є підпорядкованими APIServers.

Використовуйте звичайний стиль для значень полів типу string та integer

Для значень полів типу string або integer використовуйте звичайний стиль без лапок.

Як робити та не робити — Використовуйте нормальний стиль для значень полів типу string та integer
РекомендованоНебажано
Встановіть значення imagePullPolicy на Always.Встановіть значення imagePullPolicy на "Always".
Встановіть значення image на nginx:1.16.Встановіть значення image на nginx:1.16.
Встановіть значення поля replicas на 2.Встановіть значення поля replicas на 2.

Однак, розгляньте можливість цитування значень у випадках, коли є ризик, що читачі можуть сплутати значення з типом API.

Посилання на API ресурси Kubernetes

Цей розділ описує, як ми посилаємося на API ресурси в документації.

Уточнення щодо терміна "ресурс"

Kubernetes використовує слово ресурс для позначення ресурсів API. Наприклад, шлях URL /apis/apps/v1/namespaces/default/deployments/my-app представляє Deployment з назвою "my-app" у просторі імен "default". У термінології HTTP, простір імен є ресурсом — так само як всі веб-URL ідентифікують ресурс.

Документація Kubernetes також використовує "ресурс" для опису запитів і обмежень на використання процесорів і памʼяті. Дуже часто доцільно посилатися на API ресурси як на "API ресурси", щоб уникнути плутанини з процесорними ресурсами та ресурсами памʼяті або з іншими видами ресурсів.

Якщо ви використовуєте назву ресурсу в нижньому регістрі у множині, наприклад, deployments або configmaps, надайте додатковий контекст, щоб допомогти читачам зрозуміти, що ви маєте на увазі. Якщо ви використовуєте цей термін у контексті, де також можна використовувати назву в UpperCamelCase, і є ризик неоднозначності, розгляньте можливість використання типу API в UpperCamelCase.

Коли використовувати терміни Kubernetes API

Різні терміни Kubernetes API включають:

  • API типи (kind): назви, які використовуються в URL API (такі як pods, namespaces). API типи іноді також називають типами ресурсів.
  • API ресурс: одиничні екземпляри API типу (такі як pod, secret).
  • Обʼєкт: ресурс, який служить як "запис наміру". Обʼєкт є бажаним станом для конкретної частини вашого кластера, який намагається підтримувати панель управління Kubernetes. Всі обʼєкти в API Kubernetes також є ресурсами.

Для ясності ви можете додати "ресурс" або "обʼєкт", коли посилаєтесь на API ресурс у документації Kubernetes. Наприклад: пишіть "обʼєкт Secret", замість "Secret". Якщо з контексту зрозуміло, що мова йде про ресурс, можна не додавати це слово.

Розгляньте можливість перефразування, коли це допомагає уникнути непорозумінь. Звичайною ситуацією є випадок, коли ви хочете почати речення з API типу, наприклад, "Secret"; оскільки в англійській та інших мовах заголовні літери використовуються на початку речень, читачі не можуть визначити, чи маєте ви на увазі API тип або загальне поняття. Перефразування може допомогти.

Назви API ресурсів

Завжди форматуйте назви API ресурсів, використовуючи UpperCamelCase, також відомий як PascalCase. Не пишіть API типи з використанням форматування коду.

Не розбивайте назву API обʼєкта на окремі слова. Наприклад, використовуйте PodTemplateList, а не Pod Template List.

Для отримання додаткової інформації про PascalCase і форматування коду, ознайомтесь із відповідними рекомендаціями щодо Використання UpperCamelCase для API обʼєктів та Використання кодового стилю для вбудованого коду, команд і API обʼєктів.

Для отримання додаткової інформації про термінологію Kubernetes API, ознайомтесь із відповідними рекомендаціями щодо Термінології API Kubernetes.

Форматування фрагментів коду

Не включайте символ командного рядка

Як робити та не робити — Не включайте командний рядок
РекомендованоНебажано
kubectl get pods$ kubectl get pods

Відокремлюйте команди від їх виводу

Переконайтеся, що Pod працює на обраному вами вузлі:

kubectl get pods --output=wide

Результат буде схожим на цей:

NAME     READY     STATUS    RESTARTS   AGE    IP           NODE
nginx    1/1       Running   0          13s    10.200.0.4   worker0

Версіювання прикладів для Kubernetes

Приклади коду та конфігурацій, які включають інформацію про версії, повинні бути узгоджені з текстом.

Якщо інформація є специфічною для версії, версія Kubernetes повинна бути визначена у розділі prerequisites шаблону Task або шаблону Tutorial. Після збереження сторінки, розділ prerequisites буде показаний з назвою — Перед тим, як почати.

Щоб вказати версію Kubernetes для сторінки з завданням або навчальним посібником, включіть min-kubernetes-server-version у front matter сторінки.

Якщо YAML приклад знаходиться у файлі окремо, знайдіть та перегляньте теми, які включають його як посилання. Переконайтеся, що будь-які теми, які використовують окремий YAML, мають відповідну інформацію про версії. Якщо окремий YAML файл не посилається на жодні теми, розгляньте можливість його видалення замість оновлення.

Наприклад, якщо ви пишете навчальний посібник, що стосується версії Kubernetes 1.8, front matter вашого markdown файлу мають виглядати приблизно так:

---
title: <ваша назва навчального посібника>
min-kubernetes-server-version: v1.8
---

У прикладах коду та конфігурацій не включайте коментарі про альтернативні версії. Будьте обережні, щоб не включати некоректні твердження у ваші приклади у вигляді коментарів, наприклад:

apiVersion: v1 # попередні версії використовують...
kind: Pod
...

Словник Kubernetes.io

Список специфічних для Kubernetes термінів і слів, які слід використовувати послідовно у всьому сайті.

Словник Kubernetes.io
ТермінВикористання
KubernetesKubernetes завжди має писатися з великої літери.
DockerDocker завжди має писатися з великої літери.
SIG DocsSIG Docs, а не SIG-DOCS чи інші варіанти.
On-premisesOn-premises або On-prem, а не On-premise чи інші варіанти.
cloud nativeCloud native або cloud native, залежно від структури речення, а не cloud-native чи Cloud Native.
open sourceOpen source або open source, залежно від структури речення, а не open-source чи Open Source.

Shortcodes

Hugo Shortcodes допомагають створювати різні рівні риторичної привабливості. Наша документація підтримує три різні Shortcodes в цій категорії: Note {{< note >}}, Caution {{< caution >}} і Warning {{< warning >}}.

  1. Оточуйте текст відкриваючим та закриваючим Shortcodeʼом.

  2. Використовуйте наступний синтаксис для застосування стилю:

    {{< note >}}
    Немає необхідності включати префікс; Shortcode автоматично додає його. (Note:, Caution:, тощо)
    {{< /note >}}
    

    Вихідний результат:

Note

Використовуйте {{< note >}} для виділення поради або корисної інформації.

Наприклад:

{{< note >}}
Ви _все ще_ можете використовувати Markdown всередині цих Shortcodeʼів.
{{< /note >}}

Вихідний результат:

Ви можете використовувати {{< note >}} у списку:

1. Використовуйте Shortcode примітки у списку

1. Другий пункт з вбудованою приміткою

   {{< note >}}
   Shortcode Warning, Caution і Note, вбудовані у списки, повинні мати відповідний відступ (на рівні початку тексту списку). Див. [Поширені проблеми з Shortcode](#common-shortcode-issues).
   {{< /note >}}

1. Третій пункт у списку

1. Четвертий пункт у списку

Вихідний результат:

  1. Використовуйте Shortcode примітки у списку

  2. Другий пункт з вбудованою приміткою

  3. Третій пункт у списку

  4. Четвертий пункт у списку

Caution

Використовуйте {{< caution >}} для привернення уваги до важливої інформації, щоб уникнути помилок.

Наприклад:

{{< caution >}}
Стиль виклику застосовується лише до рядка теґа вище безпосередньо.
{{< /caution >}}

Вихідний результат:

Warning

Використовуйте {{< warning >}} для вказівки на небезпеку або важливу інформацію, яку потрібно обовʼязково враховувати.

Наприклад:

{{< warning >}}
Будьте обережні.
{{< /warning >}}

Вихідний результат:

Поширені проблеми з Shortcode

Нумеровані списки

Shortcode переривають нумеровані списки, якщо не зробити відступ у на рівні початку тексту списку перед сповіщенням та теґом.

Наприклад:

1. Розігрійте духовку до 350˚F

1. Приготуйте тісто та вилийте його у форму.
   {{< note >}}Змастіть форму для кращих результатів.{{< /note >}}

1. Випікайте 20-25 хвилин або до готовності.

Вихідний результат:

  1. Розігрійте духовку до 350˚F

  2. Приготуйте тісто та вилийте його у форму.

  3. Випікайте 20-25 хвилин або до готовності.

Вирази Include

Shortcode всередині include statements зламають збірку. Необхідно вставити їх у батьківський документ до і після виклику include. Наприклад:

{{< note >}}
{{< include "task-tutorial-prereqs.md" >}}
{{< /note >}}

Елементи Markdown

Переноси рядків

Використовуйте один символ переносу рядка (\n) для розділення контенту на рівні блоків, таких як заголовки, списки, зображення, блоки коду тощо. Винятком є заголовки другого рівня, де необхідно зробити два переноси рядка. Заголовки другого рівня слідують після заголовків першого рівня (або заголовка) без передуючих абзаців або тексту. Два переноси рядка допомагають краще візуалізувати загальну структуру контенту в текстовому редакторі.

Ручне перенесення абзаців у вихідному коді Markdown є доречним, оскільки інструмент git та сайт GitHub генерують порівняння файлів на основі рядків. Ручне перенесення довгих рядків допомагає рецензентам легко знаходити зміни у PR і надавати зворотний звʼязок. Це також допомагає командам, які займаються локалізацією, відслідковувати зміни на рівні рядків1. Перенесення рядка може відбуватися в кінці речення або після знака пунктуації. Винятком є випадки, коли Markdown-посилання або шорткод очікується в одному рядку.

Заголовки та назви

Користувачі цієї документації можуть використовувати інструменти озвучування тексту (екранний зчитувач) або іншу допоміжну технологію (AT). Екранні зчитувачі є лінійними вихідними пристроями, що виводять елементи на сторінку по одному. Якщо на сторінці багато контенту, ви можете використовувати заголовки для створення внутрішньої структури сторінки. Гарна структура сторінки допомагає всім користувачам легко орієнтуватися на сторінці або фільтрувати теми, які їх цікавлять.

Рекомендовані та не рекомендовані приклади використання заголовків
РекомендованоНебажано
Оновлюйте заголовок у метаданих сторінки або блогу.Використовуйте заголовки першого рівня, оскільки Hugo автоматично перетворює заголовок у метаданих сторінки на заголовок першого рівня.
Використовуйте впорядковані заголовки для надання змістовного високорівневого конспекту вашого контенту.Використовуйте заголовки рівнів 4-6, якщо це абсолютно необхідно. Якщо ваш контент настільки деталізований, можливо, його слід розбити на окремі статті.
Використовуйте символи фунта або решітки (#) для контенту, що не відноситься до блогу.Використовуйте підкреслення (--- або ===) для позначення заголовків першого рівня.
Використовуйте "sentence case" (великі літери тільки на початку речення) для заголовків у тілі сторінки. Наприклад, Розширення kubectl за допомогою втулківВикористовуйте "title case" (великі літери на початку кожного слова) для заголовків у тілі сторінки. Наприклад, Розширення Kubectl За Допомогою Втулків
Використовуйте "title case" для заголовків сторінок у метаданих. Наприклад, title: Kubernetes API Server Bypass RisksВикористовуйте "sentence case" для заголовків сторінок у метаданих. Наприклад, не використовуйте title: Kubernetes API server bypass risks

Абзаци

Рекомендовані та не рекомендовані приклади використання абзаців
РекомендованоНебажано
Намагайтеся, щоб абзаци не перевищували 6 речень.Не відступайте перший абзац пробілами. Наприклад, ⋅⋅⋅Три пробіли перед абзацом зроблять його абзацем з відступом.
Використовуйте три дефіси (---), щоб створити горизонтальну лінію. Використовуйте горизонтальні лінії для розділення контенту в абзацах. Наприклад, зміна сцени в історії або зміна теми в розділі.Не використовуйте горизонтальні лінії для декорацій.
Рекомендовані та не рекомендовані приклади використання посилань
РекомендованоНебажано
Створюйте гіперпосилання, що надають контекст для dvscne, на який вони посилаються. Наприклад: Деякі порти на ваших машинах відкриті. Дивіться Перевірка необхідних портів для деталей.Використовуйте неоднозначні терміни, такі як "натисніть тут". Наприклад: Деякі порти на ваших машинах відкриті. Дивіться тут для деталей.
Створюйте посилання в стилі Markdown: [текст посилання](URL). Наприклад: [Hugo shortcodes](/uk/docs/contribute/style/hugo-shortcodes/#table-captions) і вихід буде Hugo shortcodes.Використовуйте посилання в стилі HTML: <a href="/media/examples/link-element-example.css" target="_blank">Відвідайте наш підручник!</a>, або створюйте посилання, що відкриваються в нових вкладках або вікнах. Наприклад: [приклад сайту](https://example.com){target="_blank"}

Списки

Групуйте елементи в списках, які повʼязані між собою і повинні зʼявлятися у певному порядку або для позначення кореляції між кількома елементами. Коли екранний зчитувач натрапляє на список, незалежно від того, чи це упорядкований або неупорядкований список, він оголошує користувачеві, що є група елементів списку. Потім користувач може використовувати клавіші зі стрілками для переміщення між різними елементами списку.

  • Закінчуйте кожен елемент у списку крапкою, якщо один або більше елементів у списку є завершеними реченнями. Для збереження послідовності зазвичай всі елементи або жоден з них мають бути завершеними реченнями.

  • Використовуйте цифру один з крапкою (1.) для упорядкованих списків.

  • Використовуйте (+), (*), або (-) для неупорядкованих списків, але якийсь один з цих символів у одному тексті (уникайте їх змішування)

  • Залишайте порожній рядок після кожного списку.

  • Відступайте вкладені списки на відповідну кількість пробілів, так щоб сімвол початку елемента спіску був на рівні з початком тексту елемента вищого рівня (наприклад, ⋅⋅⋅).

  • Елементи списку можуть складатися з кількох абзаців. Кожен наступний абзац у пункті списку повинен бути відступлений нарівень початку тексту елементу списку або один табулятор.

Таблиці

Семантична мета таблиці — це представлення табличних даних. Користувачі з гарним зором можуть швидко сканувати таблицю, але екранний зчитувач проходить її рядок за рядком. Підпис таблиці використовується для створення описового заголовка для таблиці даних. Допоміжні технології (AT) використовують елемент підпису HTML для таблиці, щоб ідентифікувати вміст таблиці користувачеві в межах структури сторінки.

  • Додавайте підписи до таблиць за допомогою shortcodes Hugo для таблиць.

Рекомендації щодо створення контенту

Цей розділ містить рекомендації для створення чіткого, лаконічного і послідовного контенту.

Використовуйте теперішній час

Рекомендовані та не рекомендовані приклади використання теперішнього часу
РекомендованоНе рекомендовано
Ця команда запускає проксі.Ця команда запустить проксі.

Виняток: Використовуйте майбутній або минулий час, якщо це необхідно для передачі правильного значення.

Використовуйте активний стан

Рекомендовані та не рекомендовані приклади використання активного стану
РекомендованоНе рекомендовано
Ви можете дослідити API за допомогою оглядача.API можна дослідити за допомогою оглядача.
Файл YAML визначає кількість реплік.Кількість реплік визначена у файлі YAML.

Виняток: Використовуйте пасивний стан, якщо активний стан призводить до незручної конструкції.

Використовуйте просту і пряму мову

Використовуйте просту і пряму мову. Уникайте використання зайвих фраз, наприклад, слова "будь ласка".

Рекомендовані та не рекомендовані приклади використання простої і прямої мови
РекомендованоНе рекомендовано
Щоб створити ReplicaSet, ...Для того щоб створити ReplicaSet, ...
Дивіться конфігураційний файл.Будь ласка, дивіться конфігураційний файл.
Перегляньте Podʼи.За допомогою наступної команди ми переглянемо Podʼи.

Звертайтесь до читача на "ви"

Рекомендовані та не рекомендовані приклади звернення до читача
РекомендованоНе рекомендовано
Ви можете створити Deployment за допомогою ...Ми створимо Deployment за допомогою ...
У попередньому виводі ви можете побачити...У попередньому виведенні ми можемо бачити ...

Уникайте латинських фраз

Віддавайте перевагу англійським (місцевим) термінам замість латинських абревіатур.

Рекомендовані та не рекомендовані приклади уникнення латинських фраз
РекомендованоНе рекомендовано
For example (Наприклад), ...e.g., ...
That is (Тобто), ...i.e., ...

Виняток: Використовуйте "etc." (et cetera) для позначення "та інше".

Шаблони, яких слід уникати

Уникайте використання "ми"

Використання "ми" у реченні може бути заплутаним, оскільки читач може не знати, чи є він частиною "ми", про яке ви говорите.

Рекомендовані та не рекомендовані приклади використання "ми"
РекомендованоНе рекомендовано
Версія 1.4 включає ...У версії 1.4 ми додали ...
Kubernetes надає нову функцію для ...Ми надаємо нову функцію ...
Ця сторінка навчить вас, як використовувати Podʼи.На цій сторінці ми навчимося про Podʼи.

Уникайте жаргону та ідіом

Для багатьох читачів англійська є другою мовою. Уникайте жаргону та ідіом, щоб допомогти їм краще зрозуміти тему.

Правильні і неправильні приклади уникання жаргону та ідіом
РекомендованоНе рекомендовано
Internally, ...Under the hood, ...
Create a new cluster.Turn up a new cluster.

Уникайте тверджень про майбутнє

Уникайте обіцянок або натяків на майбутнє. Якщо вам потрібно говорити про функцію в альфа-версії, розмістіть текст під заголовком, який позначає його як альфа-інформацію.

Винятком з цього правила є документація про оголошені застарівання функцій, які плануються до видалення в майбутніх версіях. Один з прикладів такої документації — Посібник з міграції із застарілих API.

Уникайте тверджень, які незабаром стануть неактуальними

Уникайте слів таких як "зараз" і "новий". Функція, яка є новою сьогодні, може не вважатися новою через кілька місяців.

Правильні і неправильні приклади уникання тверджень, які незабаром стануть застарілими
РекомендованоНе рекомендовано
У версії 1.4, ...У поточній версії, ...
Функція Federation надає ...Нова функція Federation надає ...

Уникайте слів, що припускають певний рівень розуміння

Уникайте слів таких як "просто", "легко", "зрозуміло". Ці слова не додають цінності.

Правильні і неправильні приклади уникання слів, що припускають певний рівень розуміння
РекомендованоНе рекомендовано
Включіть одну команду в ...Включіть просто одну команду в ...
Запустіть контейнер ...Продовжте запускати контейнер ...
Ви можете видалити ...Ви можете легко видалити ...
Ці кроки ...Ці прості кроки ...

Файл EditorConfig

Проєкт Kubernetes підтримує файл EditorConfig, який встановлює загальні стилістичні уподобання в текстових редакторах, таких як VS Code. Ви можете використовувати цей файл, якщо хочете переконатися, що ваші внески відповідають решті проєкту. Щоб переглянути файл, зверніться до .editorconfig в кореневій теці репозиторію.

Що далі


  1. Це твердження є хибним оскільки такий підхід ускладнює виконання перекладів речень які в початковому тексті розділені на кілька рядків. Розбивання речення на кілька рядків унеможлювлює використання систем роботи з перекладами, що працюють на рівні рядків, а не речень. В середині речень не має бути переносів на новий рядок!!! ↩︎

7.7.3 - Створення діаграм

Цей посібник показує, як створювати, редагувати та поширювати діаграмами за допомогою JavaScript бібліотеки Mermaid. Mermaid.js дозволяє створювати діаграми за допомогою простого синтаксису, подібного до Markdown, всередині Markdown-файлів. Ви також можете використовувати Mermaid для створення файлів зображень у форматі .svg або .png, які ви можете додати до документації.

Цільовою аудиторією цього посібника є будь-хто, хто бажає дізнатися про Mermaid та/або як створювати і додавати діаграми до документації Kubernetes.

На схемі 1 показані теми, які розглядаються в цьому розділі.

flowchart LR subgraph m[Mermaid.js] direction TB S[ ]-.- C[створення
діаграм
в markdown] --> D[в редакторі
on-line] end A[Чому діаграми
є корисними?] --> m m --> N[3 x методи
створення
діаграм] N --> T[Приклади] T --> X[Стилі
andта
заголовки] X --> V[Поради] classDef box fill:#fff,stroke:#000,stroke-width:1px,color:#000; classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000 class A,C,D,N,X,m,T,V box class S spacewhite %% ви можете додавати гіперпосилання на вузли діаграми Mermaid за допомогою операторів click click A "https://mermaid-js.github.io/mermaid-live-editor/edit/#pako:eNqNkkFr2zAUx7-KUK9yydjNGx1ds9uWwxJKwM5BseRZq2UFWSYZpbBuH2CX0evYadeQtSw0bT-D9I32JLvE3WkCm6f3f-_3f4J3jjPFOI5xXqplVlBt0Nv3aYXg1M38g6aLAsnkHdeSCnb4sZ61GhOaZ0aoCk1etxl_xgmaRYfRPnGSuEv3xW7sg_tsb-y9vXffXs71kb12V3Ztf0N2be9CZoMk1WdMLasZiqKjPWOYgBbar6H4FnAAc1e-SVVRKSrezcQr1gbHif1lH-yd-4qeGtmt73Lfkb0NE23dJcy09cKr4IpkS5DhMkqeoxUC9cabgn3b_h8v6iYaBcwksT-8GZjuQARMJ0-CPE3sTyBu7a59FK0YXNcB-scjwXoH3wb6HzunofMUwGGOPhT-bZCVtK6HPEdztUK5KMv4IM9zUhutznh8MBgMujhaCmaK-NliRTJVKh20F_9A6gXN-LIQhu9Zfdw-7nCDJ7geDR2TEzIkIzIlkkzIqZ-vL497Xphg2a4ebOi5r0qxKbjkKY4hZDynTWlSnFYXUNosGDX8DRNGaRzntKw5wbQxavypynBsdMMfi4aCwm7LruriLzapRXs" _blank click C "https://mermaid-js.github.io/mermaid-live-editor/edit/#pako:eNqNkkFr2zAUx7-KUK9yydjNGx1ds9uWwxJKwM5BseRZq2UFWSYZpbBuH2CX0evYadeQtSw0bT-D9I32JLvE3WkCm6f3f-_3f4J3jjPFOI5xXqplVlBt0Nv3aYXg1M38g6aLAsnkHdeSCnb4sZ61GhOaZ0aoCk1etxl_xgmaRYfRPnGSuEv3xW7sg_tsb-y9vXffXs71kb12V3Ztf0N2be9CZoMk1WdMLasZiqKjPWOYgBbar6H4FnAAc1e-SVVRKSrezcQr1gbHif1lH-yd-4qeGtmt73Lfkb0NE23dJcy09cKr4IpkS5DhMkqeoxUC9cabgn3b_h8v6iYaBcwksT-8GZjuQARMJ0-CPE3sTyBu7a59FK0YXNcB-scjwXoH3wb6HzunofMUwGGOPhT-bZCVtK6HPEdztUK5KMv4IM9zUhutznh8MBgMujhaCmaK-NliRTJVKh20F_9A6gXN-LIQhu9Zfdw-7nCDJ7geDR2TEzIkIzIlkkzIqZ-vL497Xphg2a4ebOi5r0qxKbjkKY4hZDynTWlSnFYXUNosGDX8DRNGaRzntKw5wbQxavypynBsdMMfi4aCwm7LruriLzapRXs" _blank click D "https://mermaid-js.github.io/mermaid-live-editor/edit/#pako:eNqNkkFr2zAUx7-KUK9yydjNGx1ds9uWwxJKwM5BseRZq2UFWSYZpbBuH2CX0evYadeQtSw0bT-D9I32JLvE3WkCm6f3f-_3f4J3jjPFOI5xXqplVlBt0Nv3aYXg1M38g6aLAsnkHdeSCnb4sZ61GhOaZ0aoCk1etxl_xgmaRYfRPnGSuEv3xW7sg_tsb-y9vXffXs71kb12V3Ztf0N2be9CZoMk1WdMLasZiqKjPWOYgBbar6H4FnAAc1e-SVVRKSrezcQr1gbHif1lH-yd-4qeGtmt73Lfkb0NE23dJcy09cKr4IpkS5DhMkqeoxUC9cabgn3b_h8v6iYaBcwksT-8GZjuQARMJ0-CPE3sTyBu7a59FK0YXNcB-scjwXoH3wb6HzunofMUwGGOPhT-bZCVtK6HPEdztUK5KMv4IM9zUhutznh8MBgMujhaCmaK-NliRTJVKh20F_9A6gXN-LIQhu9Zfdw-7nCDJ7geDR2TEzIkIzIlkkzIqZ-vL497Xphg2a4ebOi5r0qxKbjkKY4hZDynTWlSnFYXUNosGDX8DRNGaRzntKw5wbQxavypynBsdMMfi4aCwm7LruriLzapRXs" _blank click N "https://mermaid-js.github.io/mermaid-live-editor/edit/#pako:eNqNkkFr2zAUx7-KUK9yydjNGx1ds9uWwxJKwM5BseRZq2UFWSYZpbBuH2CX0evYadeQtSw0bT-D9I32JLvE3WkCm6f3f-_3f4J3jjPFOI5xXqplVlBt0Nv3aYXg1M38g6aLAsnkHdeSCnb4sZ61GhOaZ0aoCk1etxl_xgmaRYfRPnGSuEv3xW7sg_tsb-y9vXffXs71kb12V3Ztf0N2be9CZoMk1WdMLasZiqKjPWOYgBbar6H4FnAAc1e-SVVRKSrezcQr1gbHif1lH-yd-4qeGtmt73Lfkb0NE23dJcy09cKr4IpkS5DhMkqeoxUC9cabgn3b_h8v6iYaBcwksT-8GZjuQARMJ0-CPE3sTyBu7a59FK0YXNcB-scjwXoH3wb6HzunofMUwGGOPhT-bZCVtK6HPEdztUK5KMv4IM9zUhutznh8MBgMujhaCmaK-NliRTJVKh20F_9A6gXN-LIQhu9Zfdw-7nCDJ7geDR2TEzIkIzIlkkzIqZ-vL497Xphg2a4ebOi5r0qxKbjkKY4hZDynTWlSnFYXUNosGDX8DRNGaRzntKw5wbQxavypynBsdMMfi4aCwm7LruriLzapRXs" _blank click T "https://mermaid-js.github.io/mermaid-live-editor/edit/#pako:eNqNkkFr2zAUx7-KUK9yydjNGx1ds9uWwxJKwM5BseRZq2UFWSYZpbBuH2CX0evYadeQtSw0bT-D9I32JLvE3WkCm6f3f-_3f4J3jjPFOI5xXqplVlBt0Nv3aYXg1M38g6aLAsnkHdeSCnb4sZ61GhOaZ0aoCk1etxl_xgmaRYfRPnGSuEv3xW7sg_tsb-y9vXffXs71kb12V3Ztf0N2be9CZoMk1WdMLasZiqKjPWOYgBbar6H4FnAAc1e-SVVRKSrezcQr1gbHif1lH-yd-4qeGtmt73Lfkb0NE23dJcy09cKr4IpkS5DhMkqeoxUC9cabgn3b_h8v6iYaBcwksT-8GZjuQARMJ0-CPE3sTyBu7a59FK0YXNcB-scjwXoH3wb6HzunofMUwGGOPhT-bZCVtK6HPEdztUK5KMv4IM9zUhutznh8MBgMujhaCmaK-NliRTJVKh20F_9A6gXN-LIQhu9Zfdw-7nCDJ7geDR2TEzIkIzIlkkzIqZ-vL497Xphg2a4ebOi5r0qxKbjkKY4hZDynTWlSnFYXUNosGDX8DRNGaRzntKw5wbQxavypynBsdMMfi4aCwm7LruriLzapRXs" _blank click X "https://mermaid-js.github.io/mermaid-live-editor/edit/#pako:eNqNkkFr2zAUx7-KUK9yydjNGx1ds9uWwxJKwM5BseRZq2UFWSYZpbBuH2CX0evYadeQtSw0bT-D9I32JLvE3WkCm6f3f-_3f4J3jjPFOI5xXqplVlBt0Nv3aYXg1M38g6aLAsnkHdeSCnb4sZ61GhOaZ0aoCk1etxl_xgmaRYfRPnGSuEv3xW7sg_tsb-y9vXffXs71kb12V3Ztf0N2be9CZoMk1WdMLasZiqKjPWOYgBbar6H4FnAAc1e-SVVRKSrezcQr1gbHif1lH-yd-4qeGtmt73Lfkb0NE23dJcy09cKr4IpkS5DhMkqeoxUC9cabgn3b_h8v6iYaBcwksT-8GZjuQARMJ0-CPE3sTyBu7a59FK0YXNcB-scjwXoH3wb6HzunofMUwGGOPhT-bZCVtK6HPEdztUK5KMv4IM9zUhutznh8MBgMujhaCmaK-NliRTJVKh20F_9A6gXN-LIQhu9Zfdw-7nCDJ7geDR2TEzIkIzIlkkzIqZ-vL497Xphg2a4ebOi5r0qxKbjkKY4hZDynTWlSnFYXUNosGDX8DRNGaRzntKw5wbQxavypynBsdMMfi4aCwm7LruriLzapRXs" _blank click V "https://mermaid-js.github.io/mermaid-live-editor/edit/#pako:eNqNkkFr2zAUx7-KUK9yydjNGx1ds9uWwxJKwM5BseRZq2UFWSYZpbBuH2CX0evYadeQtSw0bT-D9I32JLvE3WkCm6f3f-_3f4J3jjPFOI5xXqplVlBt0Nv3aYXg1M38g6aLAsnkHdeSCnb4sZ61GhOaZ0aoCk1etxl_xgmaRYfRPnGSuEv3xW7sg_tsb-y9vXffXs71kb12V3Ztf0N2be9CZoMk1WdMLasZiqKjPWOYgBbar6H4FnAAc1e-SVVRKSrezcQr1gbHif1lH-yd-4qeGtmt73Lfkb0NE23dJcy09cKr4IpkS5DhMkqeoxUC9cabgn3b_h8v6iYaBcwksT-8GZjuQARMJ0-CPE3sTyBu7a59FK0YXNcB-scjwXoH3wb6HzunofMUwGGOPhT-bZCVtK6HPEdztUK5KMv4IM9zUhutznh8MBgMujhaCmaK-NliRTJVKh20F_9A6gXN-LIQhu9Zfdw-7nCDJ7geDR2TEzIkIzIlkkzIqZ-vL497Xphg2a4ebOi5r0qxKbjkKY4hZDynTWlSnFYXUNosGDX8DRNGaRzntKw5wbQxavypynBsdMMfi4aCwm7LruriLzapRXs" _blank

Схема 1. Теми, які розглядаються в цьому розділі

Все що вам треба для роботи з Mermaid це:

Чому слід використовувати діаграми в документації

Діаграми покращують ясність та сприйняття документації. Це має переваги як для користувачів, так і для контриб'юторів.

Переваги для користувачів включають:

  • Приємне перше враження. Детальна текстова сторінка привітання може налякати користувачів, особливо новачків у Kubernetes.
  • Швидке освоєння концепцій. Діаграма може допомогти користувачам зрозуміти ключові моменти складної теми. Ваша діаграма може слугувати візуальним навчальним посібником для занурення в деталі теми.
  • Краще запамʼятовування. Для деяких легше запамʼятати зображення, ніж текст.

Переваги для учасників включають:

  • Допомога у розробці структури та контенту вашого внеску. Наприклад, ви можете почати з простої діаграми, яка охоплює високий рівень, а потім зануритися в деталі.
  • Розширення та зростання спільноти користувачів. Зручна для сприйняття документація, доповнена діаграмами, приваблює нових користувачів, які раніше неохоче брали участь у проєкті через уявну складність.

Вам слід враховувати вашу цільову аудиторію. Окрім досвідчених користувачів K8s, у вас буде багато новачків у Kubernetes. Навіть проста діаграма може допомогти новим користувачам засвоїти концепції Kubernetes. Вони стають впевненішими та більш схильними до подальшого дослідження Kubernetes та документації.

Mermaid

Mermaid — це бібліотека JavaScript з відкритим вихідним кодом, яка дозволяє створювати, редагувати та легко ділитися діаграмами, використовуючи простий синтаксис, схожий на Markdown, який використовується в файлах Markdown.

Нижче наведено особливості Mermaid:

  • Простий синтаксис коду.
  • Включає вебінструмент для кодування та перегляду ваших діаграм.
  • Підтримує кілька форматів, включаючи діаграми процесів, станів та послідовностей.
  • Легке співробітництво з колегами через URL-адресу для кожної діаграми.
  • Широкий вибір форм, ліній, тем та стилів.

Переваги використання Mermaid:

  • Немає потреби в спеціальних інструментах для створення діаграм.
  • Відповідає поточному робочому процесу з використанням PR. Ви можете розглядати код Mermaid як просто текст Markdown, доданий у ваш PR.
  • Простий інструмент створює прості діаграми. Не хочете витрачати час на створення надто складних і деталізованих зображень. Тримайте їх простими!

Mermaid надає простий, відкритий та прозорий метод для спільнот SIG для додавання, редагування та співпраці над діаграмами для нової чи наявної документації.

Онлайн редактор

Онлайн редактор Mermaid — це вебінструмент, який дозволяє створювати, редагувати та переглядати діаграми.

Нижче наведено функції редактора:

  • Показує код Mermaid разом зі згенерованою діаграмою.
  • Генерує URL для кожної збереженої діаграми. URL відображається в адресному рядку вашого оглядача. Ви можете поділитися URL з колегами, які можуть отримати доступ до діаграми та змінювати її.
  • Можливість отримати файли .svg або .png.

Методи створення діаграм

На схемі 2 показано три способи створення та додавання діаграм.

graph TB A[Діаграма] B[В тексті

Код Mermaid
додається
у файл .md] C[Mermaid+SVG

Файл svg, згенерований
Mermaid,
додається у файл .md] D[Зовнішні іструменти

Файл svg, згенерований
стороннім інстументом,
додається у файл .md] A --> B A --> C A --> D classDef box fill:#fff,stroke:#000,stroke-width:1px,color:#000; class A,B,C,D box %% ви можете додавати гіперпосилання на вузли діаграми Mermaid за допомогою операторів click click A "https://mermaid-js.github.io/mermaid-live-editor/edit/#pako:eNqVks1Kw0AQx19lWY9upV6jFNpGPHmqeEk8pMmmDSZNyYdWSqG2HjwIgpQKnn2AYltstckzzL6Rs2kqRRR0YZfZmf_-ZmZ3u9T0LU4V2giMdpOcVvQWwVHWYCTGMIGp6OO6gsn5OlDR4JGIAczhXdyIgRgf1oOSnPAMKczICQ88w7Eyz0x6YCJGqLtH9YP0EjEk4haZS_gge56Vc6tafnK3dnb8xXzJdeFlgxF4gynmTWCONaXwirEEFrCUyvww-znvLzlVDZ4yUCLG4k6uBA3ZVV8MsWfMhZ0u_l-NZECa-ROJhRWC0fiOTmH194rzhyGFQolUtjfV7Y26EZquEYYqt0nd7xDbcV1lx7ZtFkaBf8GVnWKxmNuFK8eKmsp-u8NM3_WDLHawBSFlVmFVpkoSZdRbXzV-ma4U6TRqco_rVEHT4rYRu5FO9VYPpXHbMiJ-ZDmRH1DFNtyQM2rEkV-7bplUiYKYb0SqY-AP9HJV7xMRDjlt" _blank click B "https://mermaid-js.github.io/mermaid-live-editor/edit/#pako:eNqVks1Kw0AQx19lWY9upV6jFNpGPHmqeEk8pMmmDSZNyYdWSqG2HjwIgpQKnn2AYltstckzzL6Rs2kqRRR0YZfZmf_-ZmZ3u9T0LU4V2giMdpOcVvQWwVHWYCTGMIGp6OO6gsn5OlDR4JGIAczhXdyIgRgf1oOSnPAMKczICQ88w7Eyz0x6YCJGqLtH9YP0EjEk4haZS_gge56Vc6tafnK3dnb8xXzJdeFlgxF4gynmTWCONaXwirEEFrCUyvww-znvLzlVDZ4yUCLG4k6uBA3ZVV8MsWfMhZ0u_l-NZECa-ROJhRWC0fiOTmH194rzhyGFQolUtjfV7Y26EZquEYYqt0nd7xDbcV1lx7ZtFkaBf8GVnWKxmNuFK8eKmsp-u8NM3_WDLHawBSFlVmFVpkoSZdRbXzV-ma4U6TRqco_rVEHT4rYRu5FO9VYPpXHbMiJ-ZDmRH1DFNtyQM2rEkV-7bplUiYKYb0SqY-AP9HJV7xMRDjlt" _blank click C "https://mermaid-js.github.io/mermaid-live-editor/edit/#pako:eNqVks1Kw0AQx19lWY9upV6jFNpGPHmqeEk8pMmmDSZNyYdWSqG2HjwIgpQKnn2AYltstckzzL6Rs2kqRRR0YZfZmf_-ZmZ3u9T0LU4V2giMdpOcVvQWwVHWYCTGMIGp6OO6gsn5OlDR4JGIAczhXdyIgRgf1oOSnPAMKczICQ88w7Eyz0x6YCJGqLtH9YP0EjEk4haZS_gge56Vc6tafnK3dnb8xXzJdeFlgxF4gynmTWCONaXwirEEFrCUyvww-znvLzlVDZ4yUCLG4k6uBA3ZVV8MsWfMhZ0u_l-NZECa-ROJhRWC0fiOTmH194rzhyGFQolUtjfV7Y26EZquEYYqt0nd7xDbcV1lx7ZtFkaBf8GVnWKxmNuFK8eKmsp-u8NM3_WDLHawBSFlVmFVpkoSZdRbXzV-ma4U6TRqco_rVEHT4rYRu5FO9VYPpXHbMiJ-ZDmRH1DFNtyQM2rEkV-7bplUiYKYb0SqY-AP9HJV7xMRDjlt" _blank click D "https://mermaid-js.github.io/mermaid-live-editor/edit/#pako:eNqVks1Kw0AQx19lWY9upV6jFNpGPHmqeEk8pMmmDSZNyYdWSqG2HjwIgpQKnn2AYltstckzzL6Rs2kqRRR0YZfZmf_-ZmZ3u9T0LU4V2giMdpOcVvQWwVHWYCTGMIGp6OO6gsn5OlDR4JGIAczhXdyIgRgf1oOSnPAMKczICQ88w7Eyz0x6YCJGqLtH9YP0EjEk4haZS_gge56Vc6tafnK3dnb8xXzJdeFlgxF4gynmTWCONaXwirEEFrCUyvww-znvLzlVDZ4yUCLG4k6uBA3ZVV8MsWfMhZ0u_l-NZECa-ROJhRWC0fiOTmH194rzhyGFQolUtjfV7Y26EZquEYYqt0nd7xDbcV1lx7ZtFkaBf8GVnWKxmNuFK8eKmsp-u8NM3_WDLHawBSFlVmFVpkoSZdRbXzV-ma4U6TRqco_rVEHT4rYRu5FO9VYPpXHbMiJ-ZDmRH1DFNtyQM2rEkV-7bplUiYKYb0SqY-AP9HJV7xMRDjlt" _blank

Схема 2. Методи створення діаграм.

В тексті

На схемі 3 показано кроки для додавання діаграми за допомогою методу Inline.

graph LR A[1. Використовуйте онлайн редактор
для створення/редагування
діаграм] --> B[2. Збережіть
URL діаграми] --> C[3. Скопіюйте код Mermaid
у ваш файл markdown] --> D[4. Додайте підпис] classDef box fill:#fff,stroke:#000,stroke-width:1px,color:#000; class A,B,C,D box %% ви можете додавати гіперпосилання на вузли діаграми Mermaid за допомогою операторів click click A "https://mermaid-js.github.io/mermaid-live-editor/edit/#pako:eNpVkc1OwkAUhV9lMm6LgrqqhoQfd7jBuGpZDO1UGtoOaUvAEBIEFy6MJMbg2jdQBMOPwCvceSPvFDDaJu29d875cmamQy1hc6rTm5A1aqRUNoOckTkk8AwzWMBa9mAm72Qf1jCWA5hjNSXYrGAJ7zCHFUHFFCbYLJRK9s6rYRb7pRySxDhOIFN0rOTw6Ff9ibQx_pPx1iNHybyH3-8KSaWyZpA3jjHLK3zANHF-yZHsy0elvy6XyH8PzHaugnGCrjeVHzboeNrnVoMJueShz1xbQeSAqBTygcj7ZD9L4rOwbotWsGMVjVNkvSijEmw5CMV2o46mYgbqJfhYHouiIndIVbSJ43qefuA4jhbFoahz_SCdTu_qVMu145qeabQ1S3giTNbO_kBITstrBa2oSFSj_jYw3lJHiUwa17jPTapjaXOHNb3YpGbQRWmzYbOYX9huLEKqO8yLuEZZMxZXt4FF9Ths8r2o6DK8dH-n6v4AeRf_cQ" _blank click B "https://mermaid-js.github.io/mermaid-live-editor/edit/#pako:eNpVkc1OwkAUhV9lMm6LgrqqhoQfd7jBuGpZDO1UGtoOaUvAEBIEFy6MJMbg2jdQBMOPwCvceSPvFDDaJu29d875cmamQy1hc6rTm5A1aqRUNoOckTkk8AwzWMBa9mAm72Qf1jCWA5hjNSXYrGAJ7zCHFUHFFCbYLJRK9s6rYRb7pRySxDhOIFN0rOTw6Ff9ibQx_pPx1iNHybyH3-8KSaWyZpA3jjHLK3zANHF-yZHsy0elvy6XyH8PzHaugnGCrjeVHzboeNrnVoMJueShz1xbQeSAqBTygcj7ZD9L4rOwbotWsGMVjVNkvSijEmw5CMV2o46mYgbqJfhYHouiIndIVbSJ43qefuA4jhbFoahz_SCdTu_qVMu145qeabQ1S3giTNbO_kBITstrBa2oSFSj_jYw3lJHiUwa17jPTapjaXOHNb3YpGbQRWmzYbOYX9huLEKqO8yLuEZZMxZXt4FF9Ths8r2o6DK8dH-n6v4AeRf_cQ" _blank click C "https://mermaid-js.github.io/mermaid-live-editor/edit/#pako:eNpVkc1OwkAUhV9lMm6LgrqqhoQfd7jBuGpZDO1UGtoOaUvAEBIEFy6MJMbg2jdQBMOPwCvceSPvFDDaJu29d875cmamQy1hc6rTm5A1aqRUNoOckTkk8AwzWMBa9mAm72Qf1jCWA5hjNSXYrGAJ7zCHFUHFFCbYLJRK9s6rYRb7pRySxDhOIFN0rOTw6Ff9ibQx_pPx1iNHybyH3-8KSaWyZpA3jjHLK3zANHF-yZHsy0elvy6XyH8PzHaugnGCrjeVHzboeNrnVoMJueShz1xbQeSAqBTygcj7ZD9L4rOwbotWsGMVjVNkvSijEmw5CMV2o46mYgbqJfhYHouiIndIVbSJ43qefuA4jhbFoahz_SCdTu_qVMu145qeabQ1S3giTNbO_kBITstrBa2oSFSj_jYw3lJHiUwa17jPTapjaXOHNb3YpGbQRWmzYbOYX9huLEKqO8yLuEZZMxZXt4FF9Ths8r2o6DK8dH-n6v4AeRf_cQ" _blank click D "https://mermaid-js.github.io/mermaid-live-editor/edit/#pako:eNpVkc1OwkAUhV9lMm6LgrqqhoQfd7jBuGpZDO1UGtoOaUvAEBIEFy6MJMbg2jdQBMOPwCvceSPvFDDaJu29d875cmamQy1hc6rTm5A1aqRUNoOckTkk8AwzWMBa9mAm72Qf1jCWA5hjNSXYrGAJ7zCHFUHFFCbYLJRK9s6rYRb7pRySxDhOIFN0rOTw6Ff9ibQx_pPx1iNHybyH3-8KSaWyZpA3jjHLK3zANHF-yZHsy0elvy6XyH8PzHaugnGCrjeVHzboeNrnVoMJueShz1xbQeSAqBTygcj7ZD9L4rOwbotWsGMVjVNkvSijEmw5CMV2o46mYgbqJfhYHouiIndIVbSJ43qefuA4jhbFoahz_SCdTu_qVMu145qeabQ1S3giTNbO_kBITstrBa2oSFSj_jYw3lJHiUwa17jPTapjaXOHNb3YpGbQRWmzYbOYX9huLEKqO8yLuEZZMxZXt4FF9Ths8r2o6DK8dH-n6v4AeRf_cQ" _blank

Схема 3. Кроки метода inline

Ось перелік кроків, які слід виконати для додавання діаграми за допомогою методу Inline:

  1. Створіть вашу діаграму за допомогою онлайн редактора.
  2. Збережіть URL діаграми для подальшого доступу.
  3. Скопіюйте код Mermaid у місце в вашому файлі .md туди, де ви хочете, щоб зʼявилася діаграма.
  4. Додайте підпис під діаграмою, використовуючи текст Markdown.

Під час побудови Hugo виконується код Mermaid і перетворюється на діаграму.

Ось приклад фрагмента коду, що міститься у файлі .md:

---
title: My PR
---
Figure 17 shows a simple A to B process.
some markdown text
...
{{< mermaid >}} 
    graph TB
    A --> B
{{< /mermaid >}}

Figure 17. A to B
more text

Для отримання додаткової інформації про підписи до діаграм, дивіться Як використовувати підписи.

Нижче наведено переваги методу Inline:

  • Використання онлайн редактора.
  • Легко копіювати код Mermaid до та з онлайн редактора та вашого файлу .md.
  • Відсутність необхідності окремої обробки файлів зображень .svg.
  • Текст контенту, код діаграми та підпис до діаграми знаходяться в одному файлі .md.

Ви повинні використовувати локальний та Netlify попередній перегляд для перевірки правильного показу діаграми.

Mermaid+SVG

На схемі 4 показано кроки для додавання діаграми за допомогою методу Mermaid+SVG.

flowchart LR A[1. Використовуйте онлайн
редактор для
створеня/редагування діаграми] B[2. Збережіть
URL діаграми] C[3. Згенеруйте файл .svg та
завантажте його до теки images/ ] subgraph w[ ] direction TB D[4. Використовуйте
shortcode figure
для використання файла
.svg у файлі .md] --> E[5. Додайте підпис] end A --> B B --> C C --> w classDef box fill:#fff,stroke:#000,stroke-width:1px,color:#000; class A,B,C,D,E,w box %% ви можете додавати гіперпосилання на вузли діаграми Mermaid за допомогою операторів click click A "https://mermaid-js.github.io/mermaid-live-editor/edit/#pako:eNp9Ustu2zAQ_BWCucqO08dFLQLEj1tOaXsSc6AlyhIqkQZF1SmCAG7SY4EAReD-RhrHrR3Xzi8s_6hLxjZaoKgO0u5yZnd2qHMaq0TQkKaFGsUZ14YcnzB5FB00CXyFOTzA2o5hbj_ZS1jDnb2CBUYzgskKlnALC1i97utDgqgZ3GPhwSHtmGCytNdPZ1u2w6zs9f4OPMWGd_hduTJS7MQXx_j-BfNTJtvRM1TyDb7DzJN-2Im9tF9c23cnx_9idKLnnjF1sxxrp9l-9nqXpFl9GBAs3bo28BOrXoOr4AC_3gL1TmHttlg76AydmJO85ANR7RMcU9X9gebDjIwilya5FrHJlSRv20x2oxf_988NrjKljbOfpPmg1sKL8aYR1PM3devQdoUn6ZtFrnZlOyHNMjkljcYhk73oJYq4wbHO6c21PaJf9_Do2qJqIRO8bAcnqLrtgw5a6IMRk0wSfOKCV1VXpKSvzlBrUYR7aZoGldHqvQj3Wq3WJm6M8sRk4cHwLIhVobQ_e_VHE3IUtINO0A16wch1owEthS55nuAveO6AjJpMlILREMNEpLwuDKNMXiC0HibciF6SG6VpmPKiEgHltVFvPsqYhkbXYgvq5hxvp9ygLn4DXER0IQ" _blank click B "https://mermaid-js.github.io/mermaid-live-editor/edit/#pako:eNp9Ustu2zAQ_BWCucqO08dFLQLEj1tOaXsSc6AlyhIqkQZF1SmCAG7SY4EAReD-RhrHrR3Xzi8s_6hLxjZaoKgO0u5yZnd2qHMaq0TQkKaFGsUZ14YcnzB5FB00CXyFOTzA2o5hbj_ZS1jDnb2CBUYzgskKlnALC1i97utDgqgZ3GPhwSHtmGCytNdPZ1u2w6zs9f4OPMWGd_hduTJS7MQXx_j-BfNTJtvRM1TyDb7DzJN-2Im9tF9c23cnx_9idKLnnjF1sxxrp9l-9nqXpFl9GBAs3bo28BOrXoOr4AC_3gL1TmHttlg76AydmJO85ANR7RMcU9X9gebDjIwilya5FrHJlSRv20x2oxf_988NrjKljbOfpPmg1sKL8aYR1PM3devQdoUn6ZtFrnZlOyHNMjkljcYhk73oJYq4wbHO6c21PaJf9_Do2qJqIRO8bAcnqLrtgw5a6IMRk0wSfOKCV1VXpKSvzlBrUYR7aZoGldHqvQj3Wq3WJm6M8sRk4cHwLIhVobQ_e_VHE3IUtINO0A16wch1owEthS55nuAveO6AjJpMlILREMNEpLwuDKNMXiC0HibciF6SG6VpmPKiEgHltVFvPsqYhkbXYgvq5hxvp9ygLn4DXER0IQ" _blank click C "https://mermaid-js.github.io/mermaid-live-editor/edit/#pako:eNp9Ustu2zAQ_BWCucqO08dFLQLEj1tOaXsSc6AlyhIqkQZF1SmCAG7SY4EAReD-RhrHrR3Xzi8s_6hLxjZaoKgO0u5yZnd2qHMaq0TQkKaFGsUZ14YcnzB5FB00CXyFOTzA2o5hbj_ZS1jDnb2CBUYzgskKlnALC1i97utDgqgZ3GPhwSHtmGCytNdPZ1u2w6zs9f4OPMWGd_hduTJS7MQXx_j-BfNTJtvRM1TyDb7DzJN-2Im9tF9c23cnx_9idKLnnjF1sxxrp9l-9nqXpFl9GBAs3bo28BOrXoOr4AC_3gL1TmHttlg76AydmJO85ANR7RMcU9X9gebDjIwilya5FrHJlSRv20x2oxf_988NrjKljbOfpPmg1sKL8aYR1PM3devQdoUn6ZtFrnZlOyHNMjkljcYhk73oJYq4wbHO6c21PaJf9_Do2qJqIRO8bAcnqLrtgw5a6IMRk0wSfOKCV1VXpKSvzlBrUYR7aZoGldHqvQj3Wq3WJm6M8sRk4cHwLIhVobQ_e_VHE3IUtINO0A16wch1owEthS55nuAveO6AjJpMlILREMNEpLwuDKNMXiC0HibciF6SG6VpmPKiEgHltVFvPsqYhkbXYgvq5hxvp9ygLn4DXER0IQ" _blank click D "https://mermaid-js.github.io/mermaid-live-editor/edit/#pako:eNp9Ustu2zAQ_BWCucqO08dFLQLEj1tOaXsSc6AlyhIqkQZF1SmCAG7SY4EAReD-RhrHrR3Xzi8s_6hLxjZaoKgO0u5yZnd2qHMaq0TQkKaFGsUZ14YcnzB5FB00CXyFOTzA2o5hbj_ZS1jDnb2CBUYzgskKlnALC1i97utDgqgZ3GPhwSHtmGCytNdPZ1u2w6zs9f4OPMWGd_hduTJS7MQXx_j-BfNTJtvRM1TyDb7DzJN-2Im9tF9c23cnx_9idKLnnjF1sxxrp9l-9nqXpFl9GBAs3bo28BOrXoOr4AC_3gL1TmHttlg76AydmJO85ANR7RMcU9X9gebDjIwilya5FrHJlSRv20x2oxf_988NrjKljbOfpPmg1sKL8aYR1PM3devQdoUn6ZtFrnZlOyHNMjkljcYhk73oJYq4wbHO6c21PaJf9_Do2qJqIRO8bAcnqLrtgw5a6IMRk0wSfOKCV1VXpKSvzlBrUYR7aZoGldHqvQj3Wq3WJm6M8sRk4cHwLIhVobQ_e_VHE3IUtINO0A16wch1owEthS55nuAveO6AjJpMlILREMNEpLwuDKNMXiC0HibciF6SG6VpmPKiEgHltVFvPsqYhkbXYgvq5hxvp9ygLn4DXER0IQ" _blank click E "https://mermaid-js.github.io/mermaid-live-editor/edit/#pako:eNp9Ustu2zAQ_BWCucqO08dFLQLEj1tOaXsSc6AlyhIqkQZF1SmCAG7SY4EAReD-RhrHrR3Xzi8s_6hLxjZaoKgO0u5yZnd2qHMaq0TQkKaFGsUZ14YcnzB5FB00CXyFOTzA2o5hbj_ZS1jDnb2CBUYzgskKlnALC1i97utDgqgZ3GPhwSHtmGCytNdPZ1u2w6zs9f4OPMWGd_hduTJS7MQXx_j-BfNTJtvRM1TyDb7DzJN-2Im9tF9c23cnx_9idKLnnjF1sxxrp9l-9nqXpFl9GBAs3bo28BOrXoOr4AC_3gL1TmHttlg76AydmJO85ANR7RMcU9X9gebDjIwilya5FrHJlSRv20x2oxf_988NrjKljbOfpPmg1sKL8aYR1PM3devQdoUn6ZtFrnZlOyHNMjkljcYhk73oJYq4wbHO6c21PaJf9_Do2qJqIRO8bAcnqLrtgw5a6IMRk0wSfOKCV1VXpKSvzlBrUYR7aZoGldHqvQj3Wq3WJm6M8sRk4cHwLIhVobQ_e_VHE3IUtINO0A16wch1owEthS55nuAveO6AjJpMlILREMNEpLwuDKNMXiC0HibciF6SG6VpmPKiEgHltVFvPsqYhkbXYgvq5hxvp9ygLn4DXER0IQ" _blank

Схема 4. Кроки методу Mermaid+SVG

Нижче наведено кроки, які слід виконати для додавання діаграми за допомогою методу Mermaid+SVG:

  1. Створіть діаграму за допомогою онлайн редактора.
  2. Збережіть URL діаграми для подальшого доступу.
  3. Згенеруйте файл зображення .svg для діаграми та завантажте його до відповідної теки images/.
  4. Використовуйте shortcode {{< figure >}} для посилання на діаграму у файлі .md.
  5. Додайте підпис за допомогою параметра caption у shortcode {{< figure >}}.

Наприклад, використовуйте онлайн редактор для створення діаграми з назвою boxnet. Збережіть URL діаграми для подальшого доступу. Згенеруйте та завантажте файл boxnet.svg до відповідної теки ../images/.

Використовуйте shortcode {{< figure >}} у файлі .md вашого PR, щоб посилатися на файл зображення .svg та додати підпис.

{{< figure src="/static/images/boxnet.svg" alt="Boxnet figure" class="diagram-large" caption="Figure 14. Boxnet caption" >}}

Для отримання додаткової інформації про підписи до діаграм дивіться Як використовувати підписи.

Ви повинні додати URL онлйн редактора як коментар у файлі зображення .svg, використовуючи текстовий редактор. Наприклад, ви б включили наступне на початку файлу зображення .svg:

<!-- Щоб переглянути або редагувати код Mermaid, використовуйте наступний URL: -->
<!-- https://mermaid-js.github.io/mermaid-live-editor/edit/#eyJjb ... <продовження рядка URL> -->

Нижче наведено переваги методу Mermaid+SVG:

  • Використання інструменту онлайн редактора.
  • Інструмент онлайн редактора підтримує найсучасніший набір функцій Mermaid.
  • Використання існуючих методів kubernetes/website для обробки файлів зображень .svg.
  • Середовище не вимагає підтримки Mermaid.

Переконайтеся, що ваша діаграма правильно відображається, використовуючи локальний та Netlify попередній перегляд.

Зовнішні інструменти

На схемі 5 показано кроки, яких слід дотримуватися для додавання діаграми за допомогою зовнішнього інструменту.

Спочатку створіть діаграму за допомогою зовнішнього інструменту і збережіть її як файл зображення у форматі .svg або .png. Після цього виконайте ті самі кроки, що й у методі Mermaid+SVG для додавання файлів зображень у форматі .svg.

flowchart LR A[1. Використовуйте pjdysusq
редактор для
стовреня/редагування діаграми] B[2. Якщо можливо, збережіть
координати діаграми
для доступу учасників] C[3. Згенеруйте файл .svg та
завантажте його до теки images/ ] subgraph w[ ] direction TB D[4. Використовуйте
shortcode figure
для використання файла
.svg у файлі .md] --> E[5. Додайте підпис] end A --> B B --> C C --> w classDef box fill:#fff,stroke:#000,stroke-width:1px,color:#000; class A,B,C,D,E,w box click A "https://mermaid-js.github.io/mermaid-live-editor/edit/#pako:eNp9kttu00AQhl9ltb110pTDjUGVmsMdV8Cd3QvHXicGH8J6TVpVldIGCSEhVUIoPAYhbdq0Je4rzL4R_zoHVSCRC2d2_M8_38z6hPtZILjNwzgb-n1PKvbqtZseOHt1Rt9oQXdU6hEt9Jk-p5Jmeky3iOZs8C44zov8w8uu3GdQzOmKpnRnVHrEcLjXF6t3m0qjWeqL3a34EmYz_C9NGiV6UiVHeP6mxaGbNp0noPgJ1y9UMiRLuqZ7QM2otBjd0C-aV27XeqLP9deqnyGumK8gXNIU3Rf_mBvlitGgloYRMA96zPRYf0bRGUoxPKpmAGk5TwHygy7NCKbndg36Ewxv6Z7V8489htS0sr5BthrNZIBnpJCVcCirjkY6B-qCRYnXE_kuQ5u86PakN-izoWOOQSSFr6IsZW-bbtp2nv3_SkzjvJ9JZW6UhVGvkOLxnLO_SjeL34ywQl8PMt6m9YTVk-CQ1Wr7btpxngPiO9qaC1ytAGub4PhgbEEt0gDfj5EzUDeroIUVVsHQTd2U4efHXp63Rci62RFY49jeCcPQypXM3gt7p9ForOPaMApU394bHFl-FmeyevfikQk7sJpWy2pbHWto3LjFEyETLwrwVZ8YoctVXyTC5TbCQIReESuXu-kppMUg8JToBJHKJLdDL86Fxb1CZW-OU5_bShZiI2pHHm4nWatO_wCdOqqx" click B "https://mermaid-js.github.io/mermaid-live-editor/edit/#pako:eNp9kttu00AQhl9ltb110pTDjUGVmsMdV8Cd3QvHXicGH8J6TVpVldIGCSEhVUIoPAYhbdq0Je4rzL4R_zoHVSCRC2d2_M8_38z6hPtZILjNwzgb-n1PKvbqtZseOHt1Rt9oQXdU6hEt9Jk-p5Jmeky3iOZs8C44zov8w8uu3GdQzOmKpnRnVHrEcLjXF6t3m0qjWeqL3a34EmYz_C9NGiV6UiVHeP6mxaGbNp0noPgJ1y9UMiRLuqZ7QM2otBjd0C-aV27XeqLP9deqnyGumK8gXNIU3Rf_mBvlitGgloYRMA96zPRYf0bRGUoxPKpmAGk5TwHygy7NCKbndg36Ewxv6Z7V8489htS0sr5BthrNZIBnpJCVcCirjkY6B-qCRYnXE_kuQ5u86PakN-izoWOOQSSFr6IsZW-bbtp2nv3_SkzjvJ9JZW6UhVGvkOLxnLO_SjeL34ywQl8PMt6m9YTVk-CQ1Wr7btpxngPiO9qaC1ytAGub4PhgbEEt0gDfj5EzUDeroIUVVsHQTd2U4efHXp63Rci62RFY49jeCcPQypXM3gt7p9ForOPaMApU394bHFl-FmeyevfikQk7sJpWy2pbHWto3LjFEyETLwrwVZ8YoctVXyTC5TbCQIReESuXu-kppMUg8JToBJHKJLdDL86Fxb1CZW-OU5_bShZiI2pHHm4nWatO_wCdOqqx" click C "https://mermaid-js.github.io/mermaid-live-editor/edit/#pako:eNp9kttu00AQhl9ltb110pTDjUGVmsMdV8Cd3QvHXicGH8J6TVpVldIGCSEhVUIoPAYhbdq0Je4rzL4R_zoHVSCRC2d2_M8_38z6hPtZILjNwzgb-n1PKvbqtZseOHt1Rt9oQXdU6hEt9Jk-p5Jmeky3iOZs8C44zov8w8uu3GdQzOmKpnRnVHrEcLjXF6t3m0qjWeqL3a34EmYz_C9NGiV6UiVHeP6mxaGbNp0noPgJ1y9UMiRLuqZ7QM2otBjd0C-aV27XeqLP9deqnyGumK8gXNIU3Rf_mBvlitGgloYRMA96zPRYf0bRGUoxPKpmAGk5TwHygy7NCKbndg36Ewxv6Z7V8489htS0sr5BthrNZIBnpJCVcCirjkY6B-qCRYnXE_kuQ5u86PakN-izoWOOQSSFr6IsZW-bbtp2nv3_SkzjvJ9JZW6UhVGvkOLxnLO_SjeL34ywQl8PMt6m9YTVk-CQ1Wr7btpxngPiO9qaC1ytAGub4PhgbEEt0gDfj5EzUDeroIUVVsHQTd2U4efHXp63Rci62RFY49jeCcPQypXM3gt7p9ForOPaMApU394bHFl-FmeyevfikQk7sJpWy2pbHWto3LjFEyETLwrwVZ8YoctVXyTC5TbCQIReESuXu-kppMUg8JToBJHKJLdDL86Fxb1CZW-OU5_bShZiI2pHHm4nWatO_wCdOqqx" click D "https://mermaid-js.github.io/mermaid-live-editor/edit/#pako:eNp9kttu00AQhl9ltb110pTDjUGVmsMdV8Cd3QvHXicGH8J6TVpVldIGCSEhVUIoPAYhbdq0Je4rzL4R_zoHVSCRC2d2_M8_38z6hPtZILjNwzgb-n1PKvbqtZseOHt1Rt9oQXdU6hEt9Jk-p5Jmeky3iOZs8C44zov8w8uu3GdQzOmKpnRnVHrEcLjXF6t3m0qjWeqL3a34EmYz_C9NGiV6UiVHeP6mxaGbNp0noPgJ1y9UMiRLuqZ7QM2otBjd0C-aV27XeqLP9deqnyGumK8gXNIU3Rf_mBvlitGgloYRMA96zPRYf0bRGUoxPKpmAGk5TwHygy7NCKbndg36Ewxv6Z7V8489htS0sr5BthrNZIBnpJCVcCirjkY6B-qCRYnXE_kuQ5u86PakN-izoWOOQSSFr6IsZW-bbtp2nv3_SkzjvJ9JZW6UhVGvkOLxnLO_SjeL34ywQl8PMt6m9YTVk-CQ1Wr7btpxngPiO9qaC1ytAGub4PhgbEEt0gDfj5EzUDeroIUVVsHQTd2U4efHXp63Rci62RFY49jeCcPQypXM3gt7p9ForOPaMApU394bHFl-FmeyevfikQk7sJpWy2pbHWto3LjFEyETLwrwVZ8YoctVXyTC5TbCQIReESuXu-kppMUg8JToBJHKJLdDL86Fxb1CZW-OU5_bShZiI2pHHm4nWatO_wCdOqqx" click E "https://mermaid-js.github.io/mermaid-live-editor/edit/#pako:eNp9kttu00AQhl9ltb110pTDjUGVmsMdV8Cd3QvHXicGH8J6TVpVldIGCSEhVUIoPAYhbdq0Je4rzL4R_zoHVSCRC2d2_M8_38z6hPtZILjNwzgb-n1PKvbqtZseOHt1Rt9oQXdU6hEt9Jk-p5Jmeky3iOZs8C44zov8w8uu3GdQzOmKpnRnVHrEcLjXF6t3m0qjWeqL3a34EmYz_C9NGiV6UiVHeP6mxaGbNp0noPgJ1y9UMiRLuqZ7QM2otBjd0C-aV27XeqLP9deqnyGumK8gXNIU3Rf_mBvlitGgloYRMA96zPRYf0bRGUoxPKpmAGk5TwHygy7NCKbndg36Ewxv6Z7V8489htS0sr5BthrNZIBnpJCVcCirjkY6B-qCRYnXE_kuQ5u86PakN-izoWOOQSSFr6IsZW-bbtp2nv3_SkzjvJ9JZW6UhVGvkOLxnLO_SjeL34ywQl8PMt6m9YTVk-CQ1Wr7btpxngPiO9qaC1ytAGub4PhgbEEt0gDfj5EzUDeroIUVVsHQTd2U4efHXp63Rci62RFY49jeCcPQypXM3gt7p9ForOPaMApU394bHFl-FmeyevfikQk7sJpWy2pbHWto3LjFEyETLwrwVZ8YoctVXyTC5TbCQIReESuXu-kppMUg8JToBJHKJLdDL86Fxb1CZW-OU5_bShZiI2pHHm4nWatO_wCdOqqx"

Схема 5. Кроки методу з використання зовнішнього інструменту

Нижче наведено кроки, які слід виконати для додавання діаграми за допомогою методу External Tool:

  1. Використовуйте зовнішній інструмент для створення діаграми.
  2. Збережіть координати діаграми для доступу інших учасників. Наприклад, ваш інструмент може надати посилання на зображення діаграми, або ви можете зберегти файл з вихідним кодом, такий як .xml, у публічному репозиторії для подальшого доступу інших учасників.
  3. Згенеруйте та збережіть діаграму у вигляді файлу зображення .svg або .png. Завантажте цей файл у відповідну теку ../images/.
  4. Використовуйте shortcode {{< figure >}} для посилання на діаграму у файлі .md.
  5. Додайте підпис за допомогою параметра caption у shortcode {{< figure >}}.

Ось приклад використання shortcode {{< figure >}} для діаграми images/apple.svg:

{{< figure src="/static/images/apple.svg" alt="red-apple-figure" class="diagram-large" caption="Figure 9. A Big Red Apple" >}}

Якщо ваш зовнішній інструмент малювання дозволяє:

  • Ви можете включати кілька логотипів .svg або .png, іконок та зображень у свою діаграму. Однак, переконайтеся, що ви дотримуєтеся авторських прав і дотримуєтесь керівництва Kubernetes щодо використання контенту третіх сторін.
  • Ви повинні зберегти координати діаграми для подальшого доступу інших учасників. Наприклад, ваш інструмент може надати посилання на зображення діаграми, або ви можете зберегти файл з вихідним кодом, наприклад .xml, для доступу інших учасників.

Для отримання додаткової інформації про логотипи та зображення K8s і CNCF, зверніться до розділу CNCF Artwork.

Нижче наведено переваги методу External Tool:

  • Учасники добре знайомі з зовнішнім інструментом.
  • Діаграми потребують більше деталей, ніж може надати Mermaid.

Не забудьте перевірити, чи правильно відображається ваша діаграма, використовуючи локальний та Netlify попередній перегляд.

Приклади

У цьому розділі показано декілька прикладів діаграм Mermaid.

Приклад 1 — Обмеження на поширення топології Podʼів

Схема 6 показує діаграму зі сторінки Обмеження на поширення топології Podʼів

graph TB subgraph "zoneB" n3(Node3) n4(Node4) end subgraph "zoneA" n1(Node1) n2(Node2) end classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000; classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5; class n1,n2,n3,n4 k8s; class zoneA,zoneB cluster; click n3 "https://mermaid-js.github.io/mermaid-live-editor/edit/#eyJjb2RlIjoiZ3JhcGggVEJcbiAgICBzdWJncmFwaCBcInpvbmVCXCJcbiAgICAgICAgbjMoTm9kZTMpXG4gICAgICAgIG40KE5vZGU0KVxuICAgIGVuZFxuICAgIHN1YmdyYXBoIFwiem9uZUFcIlxuICAgICAgICBuMShOb2RlMSlcbiAgICAgICAgbjIoTm9kZTIpXG4gICAgZW5kXG5cbiAgICBjbGFzc0RlZiBwbGFpbiBmaWxsOiNkZGQsc3Ryb2tlOiNmZmYsc3Ryb2tlLXdpZHRoOjRweCxjb2xvcjojMDAwO1xuICAgIGNsYXNzRGVmIGs4cyBmaWxsOiMzMjZjZTUsc3Ryb2tlOiNmZmYsc3Ryb2tlLXdpZHRoOjRweCxjb2xvcjojZmZmO1xuICAgIGNsYXNzRGVmIGNsdXN0ZXIgZmlsbDojZmZmLHN0cm9rZTojYmJiLHN0cm9rZS13aWR0aDoycHgsY29sb3I6IzMyNmNlNTtcbiAgICBjbGFzcyBuMSxuMixuMyxuNCBrOHM7XG4gICAgY2xhc3Mgem9uZUEsem9uZUIgY2x1c3RlcjtcbiIsIm1lcm1haWQiOiJ7XG4gIFwidGhlbWVcIjogXCJkZWZhdWx0XCJcbn0iLCJ1cGRhdGVFZGl0b3IiOmZhbHNlLCJhdXRvU3luYyI6dHJ1ZSwidXBkYXRlRGlhZ3JhbSI6dHJ1ZX0" _blank click n4 "https://mermaid-js.github.io/mermaid-live-editor/edit/#eyJjb2RlIjoiZ3JhcGggVEJcbiAgICBzdWJncmFwaCBcInpvbmVCXCJcbiAgICAgICAgbjMoTm9kZTMpXG4gICAgICAgIG40KE5vZGU0KVxuICAgIGVuZFxuICAgIHN1YmdyYXBoIFwiem9uZUFcIlxuICAgICAgICBuMShOb2RlMSlcbiAgICAgICAgbjIoTm9kZTIpXG4gICAgZW5kXG5cbiAgICBjbGFzc0RlZiBwbGFpbiBmaWxsOiNkZGQsc3Ryb2tlOiNmZmYsc3Ryb2tlLXdpZHRoOjRweCxjb2xvcjojMDAwO1xuICAgIGNsYXNzRGVmIGs4cyBmaWxsOiMzMjZjZTUsc3Ryb2tlOiNmZmYsc3Ryb2tlLXdpZHRoOjRweCxjb2xvcjojZmZmO1xuICAgIGNsYXNzRGVmIGNsdXN0ZXIgZmlsbDojZmZmLHN0cm9rZTojYmJiLHN0cm9rZS13aWR0aDoycHgsY29sb3I6IzMyNmNlNTtcbiAgICBjbGFzcyBuMSxuMixuMyxuNCBrOHM7XG4gICAgY2xhc3Mgem9uZUEsem9uZUIgY2x1c3RlcjtcbiIsIm1lcm1haWQiOiJ7XG4gIFwidGhlbWVcIjogXCJkZWZhdWx0XCJcbn0iLCJ1cGRhdGVFZGl0b3IiOmZhbHNlLCJhdXRvU3luYyI6dHJ1ZSwidXBkYXRlRGlhZ3JhbSI6dHJ1ZX0" _blank click n1 "https://mermaid-js.github.io/mermaid-live-editor/edit/#eyJjb2RlIjoiZ3JhcGggVEJcbiAgICBzdWJncmFwaCBcInpvbmVCXCJcbiAgICAgICAgbjMoTm9kZTMpXG4gICAgICAgIG40KE5vZGU0KVxuICAgIGVuZFxuICAgIHN1YmdyYXBoIFwiem9uZUFcIlxuICAgICAgICBuMShOb2RlMSlcbiAgICAgICAgbjIoTm9kZTIpXG4gICAgZW5kXG5cbiAgICBjbGFzc0RlZiBwbGFpbiBmaWxsOiNkZGQsc3Ryb2tlOiNmZmYsc3Ryb2tlLXdpZHRoOjRweCxjb2xvcjojMDAwO1xuICAgIGNsYXNzRGVmIGs4cyBmaWxsOiMzMjZjZTUsc3Ryb2tlOiNmZmYsc3Ryb2tlLXdpZHRoOjRweCxjb2xvcjojZmZmO1xuICAgIGNsYXNzRGVmIGNsdXN0ZXIgZmlsbDojZmZmLHN0cm9rZTojYmJiLHN0cm9rZS13aWR0aDoycHgsY29sb3I6IzMyNmNlNTtcbiAgICBjbGFzcyBuMSxuMixuMyxuNCBrOHM7XG4gICAgY2xhc3Mgem9uZUEsem9uZUIgY2x1c3RlcjtcbiIsIm1lcm1haWQiOiJ7XG4gIFwidGhlbWVcIjogXCJkZWZhdWx0XCJcbn0iLCJ1cGRhdGVFZGl0b3IiOmZhbHNlLCJhdXRvU3luYyI6dHJ1ZSwidXBkYXRlRGlhZ3JhbSI6dHJ1ZX0" _blank click n2 "https://mermaid-js.github.io/mermaid-live-editor/edit/#eyJjb2RlIjoiZ3JhcGggVEJcbiAgICBzdWJncmFwaCBcInpvbmVCXCJcbiAgICAgICAgbjMoTm9kZTMpXG4gICAgICAgIG40KE5vZGU0KVxuICAgIGVuZFxuICAgIHN1YmdyYXBoIFwiem9uZUFcIlxuICAgICAgICBuMShOb2RlMSlcbiAgICAgICAgbjIoTm9kZTIpXG4gICAgZW5kXG5cbiAgICBjbGFzc0RlZiBwbGFpbiBmaWxsOiNkZGQsc3Ryb2tlOiNmZmYsc3Ryb2tlLXdpZHRoOjRweCxjb2xvcjojMDAwO1xuICAgIGNsYXNzRGVmIGs4cyBmaWxsOiMzMjZjZTUsc3Ryb2tlOiNmZmYsc3Ryb2tlLXdpZHRoOjRweCxjb2xvcjojZmZmO1xuICAgIGNsYXNzRGVmIGNsdXN0ZXIgZmlsbDojZmZmLHN0cm9rZTojYmJiLHN0cm9rZS13aWR0aDoycHgsY29sb3I6IzMyNmNlNTtcbiAgICBjbGFzcyBuMSxuMixuMyxuNCBrOHM7XG4gICAgY2xhc3Mgem9uZUEsem9uZUIgY2x1c3RlcjtcbiIsIm1lcm1haWQiOiJ7XG4gIFwidGhlbWVcIjogXCJkZWZhdWx0XCJcbn0iLCJ1cGRhdGVFZGl0b3IiOmZhbHNlLCJhdXRvU3luYyI6dHJ1ZSwidXBkYXRlRGlhZ3JhbSI6dHJ1ZX0" _blank

Схема 6. Обмеження поширення топології Podʼів

Код:

graph TB
   subgraph "zoneB"
       n3(Node3)
       n4(Node4)
   end
   subgraph "zoneA"
       n1(Node1)
       n2(Node2)
   end
 
   classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
   classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
   classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
   class n1,n2,n3,n4 k8s;
   class zoneA,zoneB cluster;

Приклад 2 – Ingress

Схема 7 показує діаграму, що зʼявляється на сторінці Що таке Ingress.

graph LR; client([client])-. Ingress-managed
load balancer .->ingress[Ingress]; ingress-->|routing rule|service[Service]; subgraph cluster ingress; service-->pod1[Pod]; service-->pod2[Pod]; end classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000; classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5; class ingress,service,pod1,pod2 k8s; class client plain; class cluster cluster; click client "https://mermaid-js.github.io/mermaid-live-editor/edit/#eyJjb2RlIjoiZ3JhcGggIExSXG4gIGNsaWVudChbY2xpZW50XSktLiBJbmdyZXNzLW1hbmFnZWQgPGJyPiBsb2FkIGJhbGFuY2VyIC4tPmluZ3Jlc3NbSW5ncmVzc107XG4gIGluZ3Jlc3MtLT58cm91dGluZyBydWxlfHNlcnZpY2VbU2VydmljZV07XG4gIHN1YmdyYXBoIGNsdXN0ZXJcbiAgaW5ncmVzcztcbiAgc2VydmljZS0tPnBvZDFbUG9kXTtcbiAgc2VydmljZS0tPnBvZDJbUG9kXTtcbiAgZW5kXG4gIGNsYXNzRGVmIHBsYWluIGZpbGw6I2RkZCxzdHJva2U6I2ZmZixzdHJva2Utd2lkdGg6NHB4LGNvbG9yOiMwMDA7XG4gIGNsYXNzRGVmIGs4cyBmaWxsOiMzMjZjZTUsc3Ryb2tlOiNmZmYsc3Ryb2tlLXdpZHRoOjRweCxjb2xvcjojZmZmO1xuICBjbGFzc0RlZiBjbHVzdGVyIGZpbGw6I2ZmZixzdHJva2U6I2JiYixzdHJva2Utd2lkdGg6MnB4LGNvbG9yOiMzMjZjZTU7XG4gIGNsYXNzIGluZ3Jlc3Msc2VydmljZSxwb2QxLHBvZDIgazhzO1xuICBjbGFzcyBjbGllbnQgcGxhaW47XG4gIGNsYXNzIGNsdXN0ZXIgY2x1c3RlcjtcbiIsIm1lcm1haWQiOiJ7XG4gIFwidGhlbWVcIjogXCJkZWZhdWx0XCJcbn0iLCJ1cGRhdGVFZGl0b3IiOmZhbHNlLCJhdXRvU3luYyI6dHJ1ZSwidXBkYXRlRGlhZ3JhbSI6ZmFsc2V9" _blank click ingress "https://mermaid-js.github.io/mermaid-live-editor/edit/#eyJjb2RlIjoiZ3JhcGggIExSXG4gIGNsaWVudChbY2xpZW50XSktLiBJbmdyZXNzLW1hbmFnZWQgPGJyPiBsb2FkIGJhbGFuY2VyIC4tPmluZ3Jlc3NbSW5ncmVzc107XG4gIGluZ3Jlc3MtLT58cm91dGluZyBydWxlfHNlcnZpY2VbU2VydmljZV07XG4gIHN1YmdyYXBoIGNsdXN0ZXJcbiAgaW5ncmVzcztcbiAgc2VydmljZS0tPnBvZDFbUG9kXTtcbiAgc2VydmljZS0tPnBvZDJbUG9kXTtcbiAgZW5kXG4gIGNsYXNzRGVmIHBsYWluIGZpbGw6I2RkZCxzdHJva2U6I2ZmZixzdHJva2Utd2lkdGg6NHB4LGNvbG9yOiMwMDA7XG4gIGNsYXNzRGVmIGs4cyBmaWxsOiMzMjZjZTUsc3Ryb2tlOiNmZmYsc3Ryb2tlLXdpZHRoOjRweCxjb2xvcjojZmZmO1xuICBjbGFzc0RlZiBjbHVzdGVyIGZpbGw6I2ZmZixzdHJva2U6I2JiYixzdHJva2Utd2lkdGg6MnB4LGNvbG9yOiMzMjZjZTU7XG4gIGNsYXNzIGluZ3Jlc3Msc2VydmljZSxwb2QxLHBvZDIgazhzO1xuICBjbGFzcyBjbGllbnQgcGxhaW47XG4gIGNsYXNzIGNsdXN0ZXIgY2x1c3RlcjtcbiIsIm1lcm1haWQiOiJ7XG4gIFwidGhlbWVcIjogXCJkZWZhdWx0XCJcbn0iLCJ1cGRhdGVFZGl0b3IiOmZhbHNlLCJhdXRvU3luYyI6dHJ1ZSwidXBkYXRlRGlhZ3JhbSI6ZmFsc2V9" _blank click service "https://mermaid-js.github.io/mermaid-live-editor/edit/#eyJjb2RlIjoiZ3JhcGggIExSXG4gIGNsaWVudChbY2xpZW50XSktLiBJbmdyZXNzLW1hbmFnZWQgPGJyPiBsb2FkIGJhbGFuY2VyIC4tPmluZ3Jlc3NbSW5ncmVzc107XG4gIGluZ3Jlc3MtLT58cm91dGluZyBydWxlfHNlcnZpY2VbU2VydmljZV07XG4gIHN1YmdyYXBoIGNsdXN0ZXJcbiAgaW5ncmVzcztcbiAgc2VydmljZS0tPnBvZDFbUG9kXTtcbiAgc2VydmljZS0tPnBvZDJbUG9kXTtcbiAgZW5kXG4gIGNsYXNzRGVmIHBsYWluIGZpbGw6I2RkZCxzdHJva2U6I2ZmZixzdHJva2Utd2lkdGg6NHB4LGNvbG9yOiMwMDA7XG4gIGNsYXNzRGVmIGs4cyBmaWxsOiMzMjZjZTUsc3Ryb2tlOiNmZmYsc3Ryb2tlLXdpZHRoOjRweCxjb2xvcjojZmZmO1xuICBjbGFzc0RlZiBjbHVzdGVyIGZpbGw6I2ZmZixzdHJva2U6I2JiYixzdHJva2Utd2lkdGg6MnB4LGNvbG9yOiMzMjZjZTU7XG4gIGNsYXNzIGluZ3Jlc3Msc2VydmljZSxwb2QxLHBvZDIgazhzO1xuICBjbGFzcyBjbGllbnQgcGxhaW47XG4gIGNsYXNzIGNsdXN0ZXIgY2x1c3RlcjtcbiIsIm1lcm1haWQiOiJ7XG4gIFwidGhlbWVcIjogXCJkZWZhdWx0XCJcbn0iLCJ1cGRhdGVFZGl0b3IiOmZhbHNlLCJhdXRvU3luYyI6dHJ1ZSwidXBkYXRlRGlhZ3JhbSI6ZmFsc2V9" _blank click pod1 "https://mermaid-js.github.io/mermaid-live-editor/edit/#eyJjb2RlIjoiZ3JhcGggIExSXG4gIGNsaWVudChbY2xpZW50XSktLiBJbmdyZXNzLW1hbmFnZWQgPGJyPiBsb2FkIGJhbGFuY2VyIC4tPmluZ3Jlc3NbSW5ncmVzc107XG4gIGluZ3Jlc3MtLT58cm91dGluZyBydWxlfHNlcnZpY2VbU2VydmljZV07XG4gIHN1YmdyYXBoIGNsdXN0ZXJcbiAgaW5ncmVzcztcbiAgc2VydmljZS0tPnBvZDFbUG9kXTtcbiAgc2VydmljZS0tPnBvZDJbUG9kXTtcbiAgZW5kXG4gIGNsYXNzRGVmIHBsYWluIGZpbGw6I2RkZCxzdHJva2U6I2ZmZixzdHJva2Utd2lkdGg6NHB4LGNvbG9yOiMwMDA7XG4gIGNsYXNzRGVmIGs4cyBmaWxsOiMzMjZjZTUsc3Ryb2tlOiNmZmYsc3Ryb2tlLXdpZHRoOjRweCxjb2xvcjojZmZmO1xuICBjbGFzc0RlZiBjbHVzdGVyIGZpbGw6I2ZmZixzdHJva2U6I2JiYixzdHJva2Utd2lkdGg6MnB4LGNvbG9yOiMzMjZjZTU7XG4gIGNsYXNzIGluZ3Jlc3Msc2VydmljZSxwb2QxLHBvZDIgazhzO1xuICBjbGFzcyBjbGllbnQgcGxhaW47XG4gIGNsYXNzIGNsdXN0ZXIgY2x1c3RlcjtcbiIsIm1lcm1haWQiOiJ7XG4gIFwidGhlbWVcIjogXCJkZWZhdWx0XCJcbn0iLCJ1cGRhdGVFZGl0b3IiOmZhbHNlLCJhdXRvU3luYyI6dHJ1ZSwidXBkYXRlRGlhZ3JhbSI6ZmFsc2V9" _blank click pod2 "https://mermaid-js.github.io/mermaid-live-editor/edit/#eyJjb2RlIjoiZ3JhcGggIExSXG4gIGNsaWVudChbY2xpZW50XSktLiBJbmdyZXNzLW1hbmFnZWQgPGJyPiBsb2FkIGJhbGFuY2VyIC4tPmluZ3Jlc3NbSW5ncmVzc107XG4gIGluZ3Jlc3MtLT58cm91dGluZyBydWxlfHNlcnZpY2VbU2VydmljZV07XG4gIHN1YmdyYXBoIGNsdXN0ZXJcbiAgaW5ncmVzcztcbiAgc2VydmljZS0tPnBvZDFbUG9kXTtcbiAgc2VydmljZS0tPnBvZDJbUG9kXTtcbiAgZW5kXG4gIGNsYXNzRGVmIHBsYWluIGZpbGw6I2RkZCxzdHJva2U6I2ZmZixzdHJva2Utd2lkdGg6NHB4LGNvbG9yOiMwMDA7XG4gIGNsYXNzRGVmIGs4cyBmaWxsOiMzMjZjZTUsc3Ryb2tlOiNmZmYsc3Ryb2tlLXdpZHRoOjRweCxjb2xvcjojZmZmO1xuICBjbGFzc0RlZiBjbHVzdGVyIGZpbGw6I2ZmZixzdHJva2U6I2JiYixzdHJva2Utd2lkdGg6MnB4LGNvbG9yOiMzMjZjZTU7XG4gIGNsYXNzIGluZ3Jlc3Msc2VydmljZSxwb2QxLHBvZDIgazhzO1xuICBjbGFzcyBjbGllbnQgcGxhaW47XG4gIGNsYXNzIGNsdXN0ZXIgY2x1c3RlcjtcbiIsIm1lcm1haWQiOiJ7XG4gIFwidGhlbWVcIjogXCJkZWZhdWx0XCJcbn0iLCJ1cGRhdGVFZGl0b3IiOmZhbHNlLCJhdXRvU3luYyI6dHJ1ZSwidXBkYXRlRGlhZ3JhbSI6ZmFsc2V9" _blank
Figure 7. Ingress

Code block:

graph LR;
 client([client])-. Ingress-managed <br> load balancer .->ingress[Ingress];
 ingress-->|routing rule|service[Service];
 subgraph cluster
 ingress;
 service-->pod1[Pod];
 service-->pod2[Pod];
 end
 classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
 classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
 classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
 class ingress,service,pod1,pod2 k8s;
 class client plain;
 class cluster cluster;

Приклад 3 — Потік системи К8s

На схемі 8 зображено Mermaid-діаграму послідовності, яка показує системний потік між компонентами K8 для запуску контейнера.

Потік системи К8s

Схема 8. Потік системи К8s

Код:


%%{init:{"theme":"neutral"}}%%
sequenceDiagram
    actor me
    participant apiSrv as control plane<br><br>api-server
    participant etcd as control plane<br><br>etcd datastore
    participant cntrlMgr as control plane<br><br>controller<br>manager
    participant sched as control plane<br><br>scheduler
    participant kubelet as node<br><br>kubelet
    participant container as node<br><br>container<br>runtime
    me->>apiSrv: 1. kubectl create -f pod.yaml
    apiSrv-->>etcd: 2. save new state
    cntrlMgr->>apiSrv: 3. check for changes
    sched->>apiSrv: 4. watch for unassigned pods(s)
    apiSrv->>sched: 5. notify about pod w nodename=" "
    sched->>apiSrv: 6. assign pod to node
    apiSrv-->>etcd: 7. save new state
    kubelet->>apiSrv: 8. look for newly assigned pod(s)
    apiSrv->>kubelet: 9. bind pod to node
    kubelet->>container: 10. start container
    kubelet->>apiSrv: 11. update pod status
    apiSrv-->>etcd: 12. save new state

Ви можете стилізувати один або декілька елементів діаграми за допомогою CSS. Це досягається за допомогою двох типів операторів у коді Mermaid.

  • classDef визначає клас атрибутів стилю.
  • class визначає один або декілька елементів, до яких буде застосовано клас.

В коді до схеми 7 ви можете побачити приклад.

classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; // визначає стиль для класу k8s
class ingress,service,pod1,pod2 k8s; // Клас k8s застосовується до елементів ingress, service, pod1 та pod2.

Ви можете включити один або декілька операторів classDef та class у вашу діаграму. Ви також можете використовувати офіційний шістнадцятковий код кольору K8s #326ce5 для компонентів K8s у вашій діаграмі.

Для отримання додаткової інформації про стилізацію та класи див. Mermaid Styling and classes docs.

Як використовувати підписи до діаграм

Підпис — це короткий опис діаграми. Підпис може містити назву або короткий опис діаграми. Підписи не замінюють пояснювальний текст у вашій документації, а радше слугують як "контекстний звʼязок" між цим текстом та вашою діаграмою.

Поєднання тексту та діаграми, повʼязаних разом за допомогою підпису, допомагає надати чітке уявлення про інформацію, яку ви хочете донести до користувача.

Без підписів ви змушуєте користувача шукати текст над або під діаграмою, щоб зрозуміти її значення. Це може викликати невдоволення користувача.

На схемі 9 показано три компоненти правильного використання підписів: діаграма, підпис до діаграми та посилання на діаграму в тексті.

flowchart A[Діаграма

вбудований код Mermaid або
файл зображення SVG] B[Підпис діаграми

Вкажіть, Схема номер. та
текст підпису] C[Посилання на діаграму

Посилайтесь
Схема номер в тексті] classDef box fill:#fff,stroke:#000,stroke-width:1px,color:#000; class A,B,C box click A "https://mermaid-js.github.io/mermaid-live-editor/edit#pako:eNptkctOwkAYhV9lMmyrwW01JlyMK1ckbqiLoZ1KY0tJOw0YQsJFdyQmxrA1vgEgKBeBV_j_N_JvQUBjk3bOzJye70ymwU3fklzntuvXzLIIlFFh9GSK8IJ9GMA7tuj7BYOzUnAevzCCIXZhDCtSA1jCFGYM5jQdsysZeMKxGK0PYRW78YH0DBYMPskxTMI-YEK_LfGJFa4vbza8bBFeiTeGNUyxzWD8Cz7dwZ-JRAnYxw72NAZv-EhpVI9R5IrEBFvHDDubvjROYI5t7DBY7-Oxu6XmiAorbNMZFslZ4lI0DP4UwO6uwKF_FudTXC_Z-a8KgxHbl8A-cTdk0xVhmJc2K_l1Zjuuq6ds29ZCFfh3Uk-l0-mtPqo5lirrJ9W6ZvquHyR7pwchLKNltVycwzXubS6A7rMRWwyuytKTBtdJWtIWkasMblSaZI2qllDywnKUH3DdFm4oNS4i5RfuKybXVRDJH1PeEbeB8Lau5jc-OB9Q" _blank click B "https://mermaid-js.github.io/mermaid-live-editor/edit#pako:eNptkctOwkAYhV9lMmyrwW01JlyMK1ckbqiLoZ1KY0tJOw0YQsJFdyQmxrA1vgEgKBeBV_j_N_JvQUBjk3bOzJye70ymwU3fklzntuvXzLIIlFFh9GSK8IJ9GMA7tuj7BYOzUnAevzCCIXZhDCtSA1jCFGYM5jQdsysZeMKxGK0PYRW78YH0DBYMPskxTMI-YEK_LfGJFa4vbza8bBFeiTeGNUyxzWD8Cz7dwZ-JRAnYxw72NAZv-EhpVI9R5IrEBFvHDDubvjROYI5t7DBY7-Oxu6XmiAorbNMZFslZ4lI0DP4UwO6uwKF_FudTXC_Z-a8KgxHbl8A-cTdk0xVhmJc2K_l1Zjuuq6ds29ZCFfh3Uk-l0-mtPqo5lirrJ9W6ZvquHyR7pwchLKNltVycwzXubS6A7rMRWwyuytKTBtdJWtIWkasMblSaZI2qllDywnKUH3DdFm4oNS4i5RfuKybXVRDJH1PeEbeB8Lau5jc-OB9Q" _blank click C "https://mermaid-js.github.io/mermaid-live-editor/edit#pako:eNptkctOwkAYhV9lMmyrwW01JlyMK1ckbqiLoZ1KY0tJOw0YQsJFdyQmxrA1vgEgKBeBV_j_N_JvQUBjk3bOzJye70ymwU3fklzntuvXzLIIlFFh9GSK8IJ9GMA7tuj7BYOzUnAevzCCIXZhDCtSA1jCFGYM5jQdsysZeMKxGK0PYRW78YH0DBYMPskxTMI-YEK_LfGJFa4vbza8bBFeiTeGNUyxzWD8Cz7dwZ-JRAnYxw72NAZv-EhpVI9R5IrEBFvHDDubvjROYI5t7DBY7-Oxu6XmiAorbNMZFslZ4lI0DP4UwO6uwKF_FudTXC_Z-a8KgxHbl8A-cTdk0xVhmJc2K_l1Zjuuq6ds29ZCFfh3Uk-l0-mtPqo5lirrJ9W6ZvquHyR7pwchLKNltVycwzXubS6A7rMRWwyuytKTBtdJWtIWkasMblSaZI2qllDywnKUH3DdFm4oNS4i5RfuKybXVRDJH1PeEbeB8Lau5jc-OB9Q" _blank

Схема 9. Компоненти заголовків

Діаграма

Методи Mermaid+SVG та External Tool генерують файли зображень у форматі .svg.

Існує shortcode {{< figure >}} для діаграми, що знаходиться у файлі зображення .svg, збереженому в /images/docs/components-of-kubernetes.svg:

{{< figure src="/images/docs/components-of-kubernetes.svg" alt="Kubernetes pod running inside a cluster" class="diagram-large" caption="Схема 4. Компоненти архітектури Kubernetes" >}}

Ви повинні передавати значення src, alt, class та caption у shortcode {{< figure >}}. Ви можете змінювати розмір діаграми, використовуючи класи diagram-large, diagram-medium та diagram-small.

Дивіться Методи створення діаграм для отримання додаткової інформації про різні методи створення діаграм.

Підпис до діаграми

Далі додайте підпис до діаграми.

Якщо ви використовуєте діаграму з файла зображення .svg, вам слід використовувати параметр caption shortcodeʼа {{< figure >}}.

{{< figure src="/images/docs/components-of-kubernetes.svg" alt="Kubernetes pod running inside a cluster" class="diagram-large" caption="Схема 4. Компоненти архітектури Kubernetes" >}}

Якщо ви використовуєте діаграму, що є вбудованим кодом Mermaid, тоді слід використовувати текст Markdown.

Схема 4. Компоненти архітектури Kubernetes

Нижче наведено кілька аспектів, які слід враховувати при додаванні підписів до діаграм:

  • Використовуйте shortcode {{< figure >}} для додавання підпису до діаграм, створених за допомогою методів Mermaid+SVG та External Tool.
  • Використовуйте простий текст Markdown для додавання підпису до діаграм, створених за допомогою методу Inline.
  • Перед підписом діаграми додайте Схема НОМЕР.. Ви повинні використовувати слово Схема, і номер повинен бути унікальним для кожної діаграми на вашій сторінці документації. Додайте крапку після номера.
  • Додайте текст підпису діаграми після Схема НОМЕР. в тому ж рядку. Підпис повинен закінчуватися крапкою. Зберігайте текст підпису коротким.
  • Розташовуйте підпис до діаграми ПІД вашою діаграмою.

Посилання на діаграму

Нарешті, ви можете додати посилання на діаграму. Воно використовується у вашому тексті та повинно передувати самій діаграмі. Це дозволяє користувачеві повʼязати ваш текст із відповідною діаграмою. Схема НОМЕР у вашому посиланні та підписі повинні співпадати.

Вам слід уникати використання розпливчастих посилань, таких як ..зображення нижче.. або ..наступна схема..

Ось приклад посилання на діаграму:

Схема 10 зображує компоненти архітектури Kubernetes.
Панель управління ...

Посилання на діаграми є необовʼязковими, і є випадки, коли вони можуть бути невідповідними. Якщо ви не впевнені, додайте посилання на діаграму у ваш текст, щоб побачити, чи виглядає і звучить воно добре. Коли виникають сумніви, використовуйте посилання на діаграму.

Повна картина

Схема 10 показує діаграму архітектури Kubernetes, яка включає діаграму, підпис до діаграми та посилання на діаграму. Shortcode {{< figure >}} показує діаграму, додає підпис і включає необовʼязковий параметр link, щоб ви могли мати гіперпосилання на діаграму. Посилання на діаграму знаходиться в цьому абзаці.

Ось shortcode {{< figure >}} для цієї діаграми:

{{< figure src="/images/docs/components-of-kubernetes.svg" alt="Kubernetes pod running inside a cluster" class="diagram-large" caption="Схема 10. Архітектура Kubernetes." link="/docs/concepts/overview/components/" >}}
Kubernetes pod running inside a cluster

Схема 10. Архітектура Kubernetes.

Поради

  • Завжди використовуйте оналйн редактор для створення/редагування вашої діаграми.

  • Завжди використовуйте локальний Hugo та попередній перегляд Netlify, щоб перевірити, як діаграма відображається в документації.

  • Включайте джерела діаграм, такі як URL, місцезнаходження вихідного коду або вказуйте, що код є самодокументуючим.

  • Завжди використовуйте підписи до діаграм.

  • Дуже корисно включати зображення діаграми у форматі .svg або .png та/або вихідний код Mermaid у тікетах та PRs.

  • Для методів Mermaid+SVG та External Tool використовуйте файли зображень .svg, оскільки вони залишаються чіткими при збільшенні діаграми.

  • Найкраща практика для файлів .svg — завантажити їх в інструмент для редагування SVG та використати функцію "Конвертувати текст у криві". Це гарантує, що діаграма відображатиметься однаково на всіх системах, незалежно від доступності шрифтів і підтримки рендерингу шрифтів.

  • Mermaid не підтримує додаткові іконки або зображень.

  • Shortcodes Hugo Mermaid не працюють в оналайн редакторі.

  • Кожного разу, коли ви змінюєте діаграму в оналайн редакторі, ви повинні зберегти її, щоб згенерувати новий URL для діаграми.

  • Натисніть на діаграми в цьому розділі, щоб переглянути код і відображення діаграми в оналайн редакторі.

  • Перегляньте вихідний код цієї сторінки, diagram-guide.md, для отримання додаткових прикладів.

  • Ознайомтеся з документацією Mermaid, щоб отримати пояснення та приклади.

Найважливіше — Робіть діаграми простими. Це заощадить час вам і вашим колегам-учасникам, а також полегшить читання для нових та досвідчених користувачів.

7.7.4 - Написання нової теми

Ця сторінка показує, як створити нову тему для документації Kubernetes.

Перш ніж ви розпочнете

Створіть форк репозиторію документації Kubernetes, як описано в розділі Створення PR.

Вибір типу сторінки

Перед тим, як почати писати нову тему, подумайте про тип сторінки, який найкраще підходить для вашого контенту:

Керівництво з вибору типу сторінки
ТипОпис
ConceptСторінка концепту пояснює певний аспект Kubernetes. Наприклад, сторінка концепту може описувати обʼєкт Kubernetes Deployment і пояснювати його роль як застосунку під час його розгортання, масштабування та оновлення. Зазвичай сторінки концептів не містять послідовностей кроків, але натомість надають посилання на завдання або підручники. Для прикладу теми концепту, див. Вузли.
TaskСторінка завдання показує, як виконати одне конкретне завдання. Ідея полягає в тому, щоб надати читачам послідовність кроків, які вони можуть виконати під час читання сторінки. Сторінка завдання може бути короткою або довгою, за умови, що вона зосереджена на одній темі. На сторінці завдання можна поєднувати короткі пояснення з кроками, які потрібно виконати, але якщо вам потрібно надати докладне пояснення, ви повинні зробити це в темі концепту. Повʼязані теми завдань і концептів повинні посилатися одна на одну. Для прикладу короткої сторінки завдання див. Налаштування контейнера Pod для використання тому для зберігання. Для прикладу довшої сторінки завдання див. Налаштування проб для перевірки працездатності та готовності.
TutorialСторінка підручника показує, як досягти мети, яка обʼєднує кілька функцій Kubernetes. Підручник може містити кілька послідовностей кроків, які читачі можуть виконувати під час читання сторінки. Або він може надавати пояснення повʼязаних фрагментів коду. Наприклад, підручник може надати покроковий огляд зразка коду. Підручник може включати короткі пояснення функцій Kubernetes, які обʼєднуються, але повинен посилатися на відповідні теми концептів для детального пояснення окремих функцій.

Створення нової сторінки

Використовуйте тип контенту для кожної нової сторінки, яку ви пишете. Сайт документації надає шаблони або Hugo archetypes для створення нових сторінок контенту. Щоб створити нову сторінку, запустіть команду hugo new з шляхом до файлу, який ви хочете створити. Наприклад:

hugo new docs/concepts/my-first-concept.md

Вибір заголовка та імені файлу

Виберіть заголовок, який містить ключові слова, за якими ви хочете, щоб пошукові системи знаходили вашу сторінку. Створіть імʼя файлу, використовуючи слова в заголовку, розділені дефісами. Наприклад, тема з заголовком Використання HTTP-проксі для доступу до API Kubernetes має імʼя файлу http-proxy-access-api.md. Вам не потрібно додавати слово "kubernetes" в імʼя файлу, оскільки "kubernetes" вже є в URL для теми, наприклад:

/docs/tasks/extend-kubernetes/http-proxy-access-api/

Додавання заголовка теми до метаданих front matter

У вашій темі додайте поле title до метаданих. Метадані — це блок YAML, який знаходиться між потрійними рисками на початку сторінки. Ось приклад:

---
title: Використання HTTP-проксі для доступу до API Kubernetes
---

Вибір теки

Залежно від типу сторінки, розмістіть ваш новий файл у підтеці однієї з тек:

  • /content/en/docs/tasks/
  • /content/en/docs/tutorials/
  • /content/en/docs/concepts/

Ви можете розмістити свій файл у наявній підтеці або створити нову підтекуг.

Розміщення вашої теми в таблиці змісту

Таблиця змісту створюється динамічно, використовуючи структуру тек вихідного коду документації. Теки верхнього рівня у /content/en/docs/ створюють навігацію верхнього рівня, а підтеки мають власні записи в таблиці змісту.

Кожна підтека має файл _index.md, який представляє "домашню" сторінку для контенту даної підтеки. _index.md не потребує шаблону. Він може містити оглядовий контент про теми в теці.

Інші файли в теці зазвичай сортуються в алфавітному порядку. Це майже ніколи не є найкращим випадком. Щоб контролювати відносне сортування тем у підтеці, встановіть в ключ метаданих weight: значення, ціле число. Зазвичай ми використовуємо кратні 10, щоб врахувати додавання тем пізніше. Наприклад, тема з вагою 10 буде розташована перед темою з вагою 20.

Вбудовування коду у вашу тему

Якщо ви хочете включити якийсь код у вашу тему, ви можете вбудувати код безпосередньо у файл, використовуючи синтаксис блоку коду markdown. Це рекомендується в таких випадках (не вичерпний список):

  • Код показує вивід з команди, наприклад kubectl get deploy mydeployment -o json | jq '.status'.
  • Код недостатньо загальний для того, щоб користувачі могли його випробувати. Наприклад, ви можете вбудувати YAML файл для створення Pod, який залежить від конкретної реалізації FlexVolume.
  • Код є неповним прикладом, оскільки його мета — підкреслити частину великого файлу. Наприклад, при описі способів налаштування RoleBinding, ви можете надати короткий фрагмент безпосередньо у вашому файлі теми.
  • Код не призначений для того, щоб користувачі його випробовували з інших причин. Наприклад, коли ви описуєте, як новий атрибут має бути доданий до ресурсу за допомогою команди kubectl edit, ви можете надати короткий приклад, який містить лише атрибут для додавання.

Включення коду з іншого файлу

Інший спосіб включити код у вашу тему — створити новий, повний зразок файлу (або групи зразків файлів), а потім посилатися на зразок із вашої теми. Використовуйте цей метод для включення зразків YAML файлів, коли зразок є загальним і багаторазовим, і ви хочете, щоб читач спробував його самостійно.

При додаванні нового самостійного зразка файлу, такого як YAML файл, розмістіть код в одній з підтек <LANG>/examples/, де <LANG> — це мова для теми. У файлі вашої теми використовуйте shortcode code_sample:

{{% code_sample file="<RELPATH>/my-example-yaml>" %}}

де <RELPATH> — це шлях до файлу, який потрібно включити, відносно теки examples. Наступний shortcode Hugo посилається на YAML файл, розташований за адресою /content/en/examples/pods/storage/gce-volume.yaml.

{{% code_sample file="pods/storage/gce-volume.yaml" %}}

Показ як створити обʼєкт API з файлу конфігурації

Якщо вам потрібно продемонструвати, як створити обʼєкт API на основі файлу конфігурації, розмістіть файл конфігурації в одній з підтек у <LANG>/examples.

У вашій темі вкажіть цю команду:

kubectl create -f https://k8s.io/examples/pods/storage/gce-volume.yaml

Для прикладу теми, яка використовує цей прийом, див. Запуск Stateful застосунку в одному екземплярі.

Додавання зображень до теми

Розмістіть файли зображень у теці /images. Переважний формат зображення — SVG.

Що далі

7.7.5 - Типи контенту сторінок

Документація Kubernetes містить кілька типів контенту сторінок:

  • Concept (Концепт)
  • Task (Завдання)
  • Tutorial (Посібник)
  • Reference (Довідка)

Розділи контенту

Кожен тип контенту сторінок містить кілька розділів, визначених коментарями Markdown і HTML-заголовками. Ви можете додати заголовки контенту до вашої сторінки за допомогою shortcode heading. Коментарі та заголовки допомагають підтримувати структуру типів контенту сторінок.

Приклади коментарів Markdown, що визначають розділи контенту сторінки:

<!-- overview -->
<!-- body -->

Щоб створити загальні заголовки на ваших контентних сторінках, використовуйте body heading із рядком заголовка.

Приклади рядків заголовків:

  • whatsnext (що далі)
  • prerequisites (вимоги)
  • objectives (цілі)
  • cleanup (очищення)
  • synopsis (синопсис)
  • seealso (див. також)
  • options (параметри)

Наприклад, щоб створити заголовок whatsnext, додайте shortcode із рядком "whatsnext":

## {{% heading "whatsnext" %}}

Щоб створити заголовок prerequisites, скористайтеся таким shortcode:

## {{% heading "prerequisites" %}}

Shortcode heading очікує один строковий параметр. Рядок заголовка відповідає префіксу змінної у файлах i18n/<lang>.toml. Наприклад:

i18n/en.toml:

[whatsnext_heading]
other = "What's next"

i18n/ko.toml:

[whatsnext_heading]
other = "다음 내용"

Типи контенту

Кожен тип контенту неформально визначає свою очікувану структуру сторінки. Створюйте контент сторінки, використовуючи рекомендовані розділи сторінок.

Концепт

Сторінка концепту пояснює певний аспект Kubernetes. Наприклад, сторінка концепту може описувати обʼєкт Kubernetes Deployment і пояснювати його роль як застосунку під час розгортання, масштабування та оновлення. Зазвичай сторінки концептів не містять послідовностей кроків, а натомість надають посилання на завдання або посібники.

Щоб написати нову сторінку концепту, створіть файл Markdown у підтеці content/en/docs/concepts з такими характеристиками:

Сторінки концептів поділяються на три розділи:

Розділ сторінки
overview
body (основна частина)
whatsnext

Розділи overview і body зʼявляються як коментарі на сторінці концепту. Ви можете додати розділ whatsnext на вашу сторінку за допомогою shortcode heading.

Заповніть кожен розділ контентом. Дотримуйтесь цих вказівок:

  • Організуйте контент за допомогою заголовків H2 і H3.
  • Для розділу overview задайте контекст теми одним абзацом.
  • У розділі body поясніть концепцію.
  • Для розділу whatsnext надайте список із кількох пунктів для подальшого вивчення теми.

Приклад опублікованої сторінки концепту: Анотації.

Завдання

Сторінка завдання показує, як виконати одну дію, зазвичай шляхом надання короткої послідовності кроків. Сторінки завдань містять мінімум пояснень, але часто надають посилання на концептуальні теми, що забезпечують відповідне підґрунтя.

Щоб написати нову сторінку завдання, створіть файл Markdown у підтеці /content/en/docs/tasks з такими характеристиками:

Розділ сторінки
overview
prerequisites
steps
discussion
whatsnext

Розділи overview, steps і discussion зʼявляються як коментарі на сторінці завдання. Ви можете додати розділи prerequisites і whatsnext на вашу сторінку за допомогою shortcode heading.

У кожному розділі напишіть ваш контент, використовуючи такі вказівки:

  • Використовуйте мінімум заголовків H2 (з двома символами # на початку). Самі розділи мають заголовки, які автоматично додаються шаблоном.
  • У розділі overview використовуйте абзац для встановлення контексту для всієї теми.
  • У розділі prerequisites використовуйте списки з пунктами, де це можливо. Додаткові вимоги додавайте під include. Стандартні вимоги включають працюючий кластер Kubernetes.
  • У розділі steps використовуйте пронумеровані списки.
  • У розділі discussion використовуйте звичайний контент для розширення інформації, про яку йдеться у розділі steps.
  • У розділі whatsnext надайте список із кількох тем, які можуть зацікавити читача далі.

Приклад опублікованої сторінки завдання: Використання HTTP-проксі для доступу до API Kubernetes.

Посібник

Сторінка посібника показує, як досягти мети, яка є більшою, ніж одне завдання. Зазвичай сторінка посібника містить кілька розділів, кожен із яких має послідовність кроків. Наприклад, посібник може містити покроковий огляд зразка коду, що ілюструє певну функцію Kubernetes. Посібники можуть включати поверхневі пояснення, але повинні посилатися на повʼязані концептуальні теми для глибоких пояснень.

Щоб написати нову сторінку посібника, створіть файл Markdown у підтеці /content/en/docs/tutorials з такими характеристиками:

Розділ сторінки
overview
prerequisites
objectives
lessoncontent
cleanup
whatsnext

Розділи overview, objectives і lessoncontent зʼявляються як коментарі на сторінці посібника. Ви можете додати розділи prerequisites, cleanup і whatsnext на вашу сторінку за допомогою shortcode heading.

У кожному розділі напишіть ваш контент, використовуючи такі вказівки:

  • Використовуйте мінімум заголовків H2 (з двома символами # на початку). Самі розділи мають заголовки, які автоматично додаються шаблоном.
  • У розділі overview використовуйте абзац для встановлення контексту для всієї теми.
  • У розділі prerequisites використовуйте списки з пунктами, де це можливо. Додаткові вимоги додавайте під include.
  • У розділі objectives використовуйте списки з пунктами.
  • У розділі lessoncontent використовуйте комбінацію пронумерованих списків і наративного контенту, де це доречно.
  • У розділі cleanup використовуйте пронумеровані списки для опису кроків, необхідних для очищення стану кластера після завершення завдання.
  • У розділі whatsnext надайте список із кількох тем, які можуть зацікавити читача далі.

Приклад опублікованої сторінки посібника: Запуск застосунку без збереження стану за допомогою Deployment.

Довідка

Сторінка довідки інструмента компонента показує опис і параметри прапорців для інструмента компонента Kubernetes. Кожна сторінка генерується зі скриптів із використанням команд інструмента компонента.

Сторінка довідки з інструмента має кілька можливих розділів:

Розділ сторінки
synopsis
options
options from parent commands
examples
seealso

Приклади опублікованих сторінок довідки з інструмента:

Що далі

7.7.6 - Організація контенту

Цей сайт використовує Hugo. В Hugo організація контенту є основним концептом.

Списки сторінок

Порядок сторінок

Бічне меню документації, оглядач сторінок документації тощо формуються за допомогою стандартного порядку сортування Hugo, який сортує за вагою (починаючи з 1), датою (новіші перші), і нарешті за заголовком посилання.

Щоб перемістити сторінку або розділ вверх, задайте вагу у front matter сторінки:

title: My Page
weight: 10

Основне меню документації

Основне меню Документація формується з розділів, що знаходяться в docs/, з прапорцем main_menu, встановленим у front matter файлу контенту _index.md:

main_menu: true

Зверніть увагу, що заголовок посилання береться з linkTitle сторінки, тому, якщо ви хочете, щоб він був відмінним від заголовка, змініть його у файлі контенту:

main_menu: true
title: Page Title
linkTitle: Title used in links

Бічне меню документації

Бічне меню документації формується з поточного дерева розділів в docs/.

Воно відображатиме всі розділи та їх сторінки.

Якщо ви не хочете відображати розділ або сторінку, встановіть прапорець toc_hide в значення true у front matter:

toc_hide: true

Коли ви переходите до розділу, який має контент, показується конкретний розділ або сторінка (наприклад, _index.md). Інакше показується перша сторінка всередині цього розділу.

Оглядач сторінок документації

Оглядач сторінок на домашній сторінці документації формується з усіх розділів і сторінок, які безпосередньо знаходяться нижче розділу docs.

Якщо ви не хочете відображати розділ або сторінку, встановіть прапорець toc_hide в значення true у front matter:

toc_hide: true

Посилання сайту в меню у верхньому правому куті, а також у нижньому колонтитулі, формуються за допомогою перегляду сторінок. Це робиться для того, щоб переконатися, що сторінка дійсно існує. Тому, якщо розділ case-studies не існує на сайті (для мови), він не буде показаний.

Пакети сторінок

Окрім окремих контентних сторінок (файли Markdown), Hugo підтримує Пакети сторінок.

Один приклад — Custom Hugo Shortcodes. Це вважається leaf bundle. Все, що знаходиться нижче теки, включаючи index.md, буде частиною пакета. Це також включає посилання, що є відносними до сторінки, зображення, які можна обробити тощо:

en/docs/home/contribute/includes
├── example1.md
├── example2.md
├── index.md
└── podtemplate.json

Ще один широко використовуваний приклад — пакет includes. Він встановлює headless: true у front matter, що означає, що він не отримує власний URL. Він використовується тільки в інших сторінках.

en/includes
├── default-storage-class-prereqs.md
├── index.md
├── partner-script.js
├── partner-style.css
├── task-tutorial-prereqs.md
├── user-guide-content-moved.md
└── user-guide-migration-notice.md

Декілька важливих приміток до файлів у пакетах:

  • Для перекладених пакетів будь-які відсутні не контентні файли будуть успадковані з мов, що знаходяться вище. Це запобігає дублюванню.
  • Усі файли в пакеті є тим, що Hugo називає Resources, і ви можете надавати метадані для кожної мови, такі як параметри і заголовок, навіть якщо це не підтримує front matter (YAML файли тощо). Див. Метадані ресурсів сторінок.
  • Значення, яке ви отримуєте з .RelPermalink Resource є відносним до сторінки. Див. Permalinks.

Стилі

Джерело стилів SASS для цього сайту зберігається у assets/sass і автоматично будується Hugo.

Що далі

7.7.7 - Власні shortcodes Hugo

Ця сторінка пояснює, як використовувати shortcodes Hugo в документації Markdown для Kubernetes.

Детальніше про shortcodes можна дізнатися в документації Hugo.

Стан функції

На сторінці Markdown (.md файл) на цьому сайті ви можете додати shortcodes для відображення версії та стану документованої функції.

Демонстрація стану функції

Нижче наведено демонстрацію фрагмента стану функції, який відображає функцію як стабільну в останній версії Kubernetes.

{{< feature-state state="stable" >}}

Показується як:

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.31 [stable]

Дійсні значення для state:

  • alpha
  • beta
  • deprecated
  • stable

Код стану функції

Показана версія Kubernetes типово є версією сторінки або сайту. Ви можете змінити версію стану функції, передавши параметр for_k8s_version для shortcode. Наприклад:

{{< feature-state for_k8s_version="v1.10" state="beta" >}}

Показується як:

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.10 [beta]

Отримання стану функції з файлу опису

Щоб динамічно визначити стан функції, використовуйте параметр feature_gate_name. Деталі стану функції будуть витягнуті з відповідного файлу опису функціональних можливостей розташованого в content/en/docs/reference/command-line-tools-reference/feature-gates/. Наприклад:

{{< feature-state feature_gate_name="NodeSwap" >}}

Показується як:

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.30 [beta]

Опис функціональних можливостей

На сторінці Markdown (.md файл) на цьому сайті ви можете додати код для показу опису функціональної можливості.

Демонстрація опису функціональної можливості

Нижче наведено демонстрацію фрагмента опису функціональної можливості, який показує функцію як стабільну в останній версії Kubernetes.

{{< feature-gate-description name="DryRun" >}}

Показується як:

DryRun: Вмикає запити dry rin на боці сервера, щоб можна було тестувати валідацію, злиття та мутацію без впровадження змін.

Глосарій

Існують два коротких коди для глосарія: glossary_tooltip та glossary_definition.

Ви можете посилатися на терміни глосарія з включенням, яке автоматично оновлюється і замінює вміст відповідними посиланнями з нашого глосарія. Коли вказівник миші знаходиться над терміном з глосарія, опис терміна з глосарія відобразиться у вигляді підказки. Термін глосарія також відображається як посилання.

Окрім включень з підказками, ви можете повторно використовувати визначення з глосарія у вмісті сторінки.

Дані для термінів глосарія зберігаються в теці глосарія, з файлом вмісту для кожного терміна глосарія.

Демонстрація глосарія

Наприклад, наступне включення в Markdown показується для терміна кластер з підказкою:

{{< glossary_tooltip text="cluster" term_id="cluster" >}}

Ось коротке визначення глосарія:

{{< glossary_definition prepend="Кластер — " term_id="cluster" length="short" >}}

яке показується як:

Кластер — набір робочих машин, що називаються вузлами, які виконують контейнеризовані застосунки. Кожен кластер має принаймні один робочий вузол.

Ви також можете включити повне визначення:

{{< glossary_definition term_id="cluster" length="all" >}}

яке показується як:

Набір робочих машин, що називаються вузлами, які виконують контейнеризовані застосунки. Кожен кластер має принаймні один робочий вузол.

Робочі вузли містять Podʼи, які є компонентами навантаження застосунку. Панель управління керує робочими вузлами та Podʼами в кластері. В операційних середовищах панель управління, зазвичай, працює на кількох компʼютерах, і кластер, як правило, має кілька вузлів, забезпечуючи стійкість до відмов та високу доступність.

Ви можете створити посилання на сторінку довідника API Kubernetes, використовуючи короткий код api-reference, наприклад, на довідник Pod:

{{< api-reference page="workload-resources/pod-v1" >}}

Вміст параметра page є суфіксом URL сторінки довідника API.

Ви можете посилатися на конкретне місце на сторінці, вказавши параметр anchor, наприклад, на довідник PodSpec або розділ environment-variables сторінки:

{{< api-reference page="workload-resources/pod-v1" anchor="PodSpec" >}}
{{< api-reference page="workload-resources/pod-v1" anchor="environment-variables" >}}

Ви можете змінити текст посилання, вказавши параметр text, наприклад, посилаючись на Змінні оточення розділ сторінки:

{{< api-reference page="workload-resources/pod-v1" anchor="environment-variables" text="Змінні оточення" >}}

Заголовки таблиць

Ви можете зробити таблиці більш доступними для екранних зчитувачів, додавши заголовок таблиці. Щоб додати заголовок до таблиці, оберніть таблицю кодом table і вкажіть заголовок за допомогою параметра caption.

Ось приклад:

{{< table caption="Configuration parameters" >}}
Parameter | Description | Default
:---------|:------------|:-------
`timeout` | The timeout for requests | `30s`
`logLevel` | The log level for log output | `INFO`
{{< /table >}}

Показується як:

Configuration parameters
ParameterDescriptionDefault
timeoutThe timeout for requests30s
logLevelThe log level for log outputINFO

Якщо ви переглянете HTML для таблиці, ви повинні побачити цей елемент одразу після відкриваючого елемента <table>:

<caption style="display: none;">Configuration parameters</caption>

Вкладки

На сторінці Markdown (.md файл) на цьому сайті ви можете додати набір вкладок для показу різних варіантів рішення.

Короткий код tabs приймає такі параметри:

  • name: Ім’я, яке відображається на вкладці.
  • codelang: Якщо ви надаєте внутрішній вміст для короткого коду tab, ви можете вказати Hugo, яку мову коду використовувати для підсвічування.
  • include: Файл для включення у вкладку. Якщо вкладка знаходиться в Hugo leaf bundle, файл, який може бути будь-якого MIME типу, підтримуваного Hugo, шукається у самому пакеті. Якщо ні, сторінка вмісту, яку потрібно включити, шукається відносно поточної сторінки. Зверніть увагу, що з include у вас немає внутрішнього вмісту shortcode і ви повинні використовувати синтаксис самозакриваючих теґів. Наприклад, {{< tab name="Content File #1" include="example1" />}}. Мову потрібно вказати у codelang, або мова буде визначена на основі імені файлу. Ффайли non-content стандартно підсвічуються як код.
  • Якщо ваш внутрішній вміст є Markdown, ви повинні використовувати роздільник % для оточення вкладки. Наприклад, {{% tab name="Tab 1" %}}This is **markdown**{{% /tab %}}
  • Ви можете комбінувати зазначені вище варіації всередині набору вкладок.

Нижче наведено демонстрацію shortcode вкладок.

Демонстрація вкладок: Підсвічування коду

{{< tabs name="tab_with_code" >}}
{{< tab name="Tab 1" codelang="bash" >}}
echo "This is tab 1."
{{< /tab >}}
{{< tab name="Tab 2" codelang="go" >}}
println "This is tab 2."
{{< /tab >}}
{{< /tabs >}}

Показується як:


echo "This is tab 1."


println "This is tab 2."

Демонстрація вкладок: Вбудований Markdown та HTML

{{< tabs name="tab_with_md" >}}
{{% tab name="Markdown" %}}
This is **some markdown.**
{{< note >}}
It can even contain shortcodes.
{{< /note >}}
{{% /tab %}}
{{< tab name="HTML" >}}
<div>
	<h3>Plain HTML</h3>
	<p>This is some <i>plain</i> HTML.</p>
</div>
{{< /tab >}}
{{< /tabs >}}

Показується як:

This is some markdown.

Plain HTML

This is some plain HTML.

Демонстрація вкладок: Включення файлів

{{< tabs name="tab_with_file_include" >}}
{{< tab name="Content File #1" include="example1" />}}
{{< tab name="Content File #2" include="example2" />}}
{{< tab name="JSON File" include="podtemplate" />}}
{{< /tabs >}}

Показується як:

This is an example content file inside the includes leaf bundle.

This is another example content file inside the includes leaf bundle.

{
    "apiVersion": "v1",
    "kind": "PodTemplate",
    "metadata": {
      "name": "nginx"
    },
    "template": {
      "metadata": {
        "labels": {
          "name": "nginx"
        },
        "generateName": "nginx-"
      },
      "spec": {
         "containers": [{
           "name": "nginx",
           "image": "dockerfile/nginx",
           "ports": [{"containerPort": 80}]
         }]
      }
    }
  }

Файли вихідного коду

Ви можете використовувати код {{% code_sample %}} для вбудовування вмісту файлу в кодовий блок, щоб користувачі могли завантажити або скопіювати його вміст у буфер обміну. Цей код використовується, коли вміст зразкового файлу є загальним і багаторазовим, і ви хочете, щоб користувачі могли спробувати його самостійно.

Цей короткий код приймає два іменованих параметри: language та file. Обов’язковий параметр file використовується для вказання шляху до файлу, який відображається. Опційний параметр language використовується для вказання мови програмування файлу. Якщо параметр language не надано, код намагатиметься вгадати мову на основі розширення файлу.

Наприклад:

{{% code_sample language="yaml" file="application/deployment-scale.yaml" %}}

Вихідний результат:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 4 # Update the replicas from 2 to 4
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.16.1
        ports:
        - containerPort: 80

Коли ви додаєте новий зразковий файл, наприклад YAML файл, створіть файл в одній з підтек <LANG>/examples/, де <LANG> — це мова для сторінки. У Markdown вашої сторінки використовуйте код code:

{{% code_sample file="<RELATIVE-PATH>/example-yaml>" %}}

де <RELATIVE-PATH> — шлях до зразкового файлу, який потрібно включити, відносно теки examples. Наступний код посилається на YAML файл, розташований за адресою /content/en/examples/configmap/configmaps.yaml.

{{% code_sample file="configmap/configmaps.yaml" %}}

Застарілий код {{% codenew %}} замінюється на {{% code_sample %}}. Використовуйте {{% code_sample %}} (а не {{% codenew %}} чи {{% code %}}) у новій документації.

Маркер контенту третіх сторін

Для роботи з Kubernetes потрібно стороннє програмне забезпечення. Наприклад, вам зазвичай потрібно додати DNS-сервер до вашого кластера, щоб забезпечити правильну роботу розпізнавання імен.

Коли ми посилаємося на стороннє програмне забезпечення або згадуємо про нього, ми дотримуємося керівництва з контенту і також позначаємо ці сторонні елементи.

Використання цих shortcodes додає відмову від відповідальності до будь-якої сторінки документації, яка їх використовує.

Списки

Для списку кількох сторонніх елементів додайте:

{{% thirdparty-content %}}

відразу після заголовка розділу, що включає всі елементи.

Елементи

Якщо у вас є список, в якому більшість елементів належать до програмного забезпечення проєкту (наприклад: сам Kubernetes, і окремий компонент Descheduler), то є інша форма для використання.

Додайте короткий код:

{{% thirdparty-content single="true" %}}

перед елементом або відразу після заголовка для конкретного елемента.

Рядки версій

Щоб створити рядок версії для включення в документацію, ви можете вибрати з кількох shortcode для версії. Кожен код версії відображає рядок версії, отриманий зі значення параметра версії, знайденого у файлі конфігурації сайту, hugo.toml. Два найбільш часто використовуваних параметри версії — це latest і version.

{{< param "version" >}}

Код {{< param "version" >}} генерує значення поточної версії документації Kubernetes з параметра сайту version. Код param приймає назву одного параметра сайту, в цьому випадку: version.

Показується як:

v1.31

{{< latest-version >}}

Код {{< latest-version >}} повертає значення параметра сайту latest. Параметр сайту latest оновлюється, коли випускається нова версія документації. Цей параметр не завжди відповідає значенню version у наборі документації.

Показується як:

v1.31

{{< latest-semver >}}

Короткий код {{< latest-semver >}} генерує значення latest без префікса "v".

Показується як:

1.31

{{< version-check >}}

Код {{< version-check >}} перевіряє, чи присутній параметр min-kubernetes-server-version на сторінці, а потім використовує це значення для порівняння з version.

Показується як:

Для перевірки версії введіть kubectl version.

{{< latest-release-notes >}}

Код {{< latest-release-notes >}} генерує рядок версії з latest і видаляє префікс "v". Короткий код друкує нове посилання на сторінку з нотатками про випуски з модифікованим рядком версії.

Показується як:

https://git.k8s.io/kubernetes/CHANGELOG/CHANGELOG-1.31.md

Що далі

7.8 - Оновлення довідкової документації

Тематика цього розділу описує, як генерувати довідники Kubernetes.

Щоб створити довідкову документацію, ознайомтесь з наступним посібником:

7.8.1 - Швидкий старт з довідковою документацією

Ця сторінка показує, як використовувати скрипт update-imported-docs.py для генерації довідкової документації Kubernetes. Скрипт автоматизує налаштування збірки та генерує довідкову документацію для релізу.

Перш ніж ви розпочнете

Вимоги:

  • Вам потрібна машина, що працює під управлінням Linux або macOS.

  • Вам потрібно встановити ці інструменти:

  • Ваша змінна середовища PATH повинна включати необхідні інструменти для збірки, такі як бінарники Go та python.

  • Вам потрібно знати, як створити pull request до репозиторію на GitHub. Це включає створення власного форку репозиторію. Для отримання додаткової інформації дивіться Робота з локальним клоном.

Отримання репозиторію документації

Переконайтеся, що ваш форк репозиторію website синхронізований з віддаленим репозиторієм kubernetes/website на GitHub (гілка main), і клонуйте ваш форк website собі локально.

mkdir github.com
cd github.com
git clone git@github.com:<your_github_username>/website.git

Визначте базову теку вашого клону. Наприклад, якщо ви слідували попередньому кроку для отримання репозиторію, ваша базова тека — github.com/website. Наступні кроки посилаються на вашу базову теку як <web-base>.

Огляд update-imported-docs

Скрипт update-imported-docs.py розташований у теці <web-base>/update-imported-docs/.

Скрипт будує наступні довідки:

  • Довідкові сторінки компонентів та інструментів
  • Довідка по команді kubectl
  • Довідка по API Kubernetes

Скрипт update-imported-docs.py генерує довідкову документацію Kubernetes з вихідного коду Kubernetes. Скрипт створює тимчасову теку в /tmp на вашій машині та клонує потрібні репозиторії: kubernetes/kubernetes та kubernetes-sigs/reference-docs у цю теку. Скрипт встановлює вашу змінну середовища GOPATH на цю тимчасову теку. Встановлюються три додаткові змінні середовища:

  • K8S_RELEASE
  • K8S_ROOT
  • K8S_WEBROOT

Скрипт потребує два аргументи для успішного виконання:

  • YAML конфігураційний файл (reference.yml)
  • Версія релізу, наприклад: 1.17

Конфігураційний файл містить поле generate-command. Поле generate-command визначає серію інструкцій для збірки з kubernetes-sigs/reference-docs/Makefile. Змінна K8S_RELEASE визначає версію релізу.

Скрипт update-imported-docs.py виконує наступні кроки:

  1. Клонування повʼязаних репозиторіїв, зазначених у конфігураційному файлі. Для генерації довідкових документів типово клонуються kubernetes-sigs/reference-docs.
  2. Запуск команд під час клонування репозиторіїв для підготовки генератора документації та генерація HTML і Markdown файлів.
  3. Копіювання згенерованих HTML і Markdown файлів до локального клону репозиторію <web-base> за вказаними в конфігураційному файлі шляхами.
  4. Оновлення посилань команд kubectl з kubectl.md у секції в довідці по команді kubectl.

Коли згенеровані файли знаходяться у вашому локальному клоні репозиторію <web-base>, ви можете подати їх у pull request до <web-base>.

Формат конфігураційного файлу

Кожен конфігураційний файл може містити кілька репозиторіїв, які будуть імпортовані разом. За необхідності, ви можете налаштувати конфігураційний файл, редагуючи його вручну. Можна створювати нові конфігураційні файли для імпорту інших груп документів. Ось приклад YAML конфігураційного файлу:

repos:
- name: community
  remote: https://github.com/kubernetes/community.git
  branch: master
  files:
  - src: contributors/devel/README.md
    dst: docs/imported/community/devel.md
  - src: contributors/guide/README.md
    dst: docs/imported/community/guide.md

Окремі Markdown документи, імпортовані за допомогою інструмента, повинні відповідати Посібнику зі стилю документації.

Налаштування reference.yml

Відкрийте <web-base>/update-imported-docs/reference.yml для редагування. Не змінюйте вміст поля generate-command, якщо не розумієте, як команда використовується для побудови довідок. Оновлення reference.yml зазвичай не потрібне. Іноді зміни в upstream вихідному коді можуть вимагати змін у конфігураційному файлі (наприклад: залежності версій golang та зміни сторонніх бібліотек). Якщо ви стикаєтеся з проблемами збірки, зверніться до команди SIG-Docs у #sig-docs Kubernetes Slack.

У reference.yml, files містить список полів src та dst. Поле src містить розташування згенерованого Markdown файлу у теці збірки kubernetes-sigs/reference-docs, а поле dst визначає, куди скопіювати цей файл у клонованому репозиторії kubernetes/website. Наприклад:

repos:
- name: reference-docs
  remote: https://github.com/kubernetes-sigs/reference-docs.git
  files:
  - src: gen-compdocs/build/kube-apiserver.md
    dst: content/en/docs/reference/command-line-tools-reference/kube-apiserver.md
  ...

Зверніть увагу, що коли є багато файлів для копіювання з одного джерела в одну й ту ж теку призначення, ви можете використовувати шаблони в значенні src. Ви повинні надати назву теки як значення для dst. Наприклад:

  files:
  - src: gen-compdocs/build/kubeadm*.md
    dst: content/en/docs/reference/setup-tools/kubeadm/generated/

Запуск інструмента update-imported-docs

Ви можете запустити інструмент update-imported-docs.py наступним чином:

cd <web-base>/update-imported-docs
./update-imported-docs.py <configuration-file.yml> <release-version>

Наприклад:

./update-imported-docs.py reference.yml 1.17

Конфігураційний файл release.yml містить інструкції для виправлення відносних посилань. Щоб виправити відносні посилання у ваших імпортованих файлах, встановіть властивість gen-absolute-links на true. Ви можете знайти приклад цього в release.yml.

Додавання та коміт змін у репо kubernetes/website

Перегляньте файли, що були згенеровані та скопійовані до <web-base>:

cd <web-base>
git status

Вивід показує нові та змінені файли. Згенеровані результати варіюються залежно від змін, внесених у upstream вихідний код.

Згенеровані файли компонентів інструментів

content/en/docs/reference/command-line-tools-reference/cloud-controller-manager.md
content/en/docs/reference/command-line-tools-reference/kube-apiserver.md
content/en/docs/reference/command-line-tools-reference/kube-controller-manager.md
content/en/docs/reference/command-line-tools-reference/kube-proxy.md
content/en/docs/reference/command-line-tools-reference/kube-scheduler.md
content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm.md
content/en/docs/reference/kubectl/kubectl.md

Згенеровані файли довідки команди kubectl

static/docs/reference/generated/kubectl/kubectl-commands.html
static/docs/reference/generated/kubectl/navData.js
static/docs/reference/generated/kubectl/scroll.js
static/docs/reference/generated/kubectl/stylesheet.css
static/docs/reference/generated/kubectl/tabvisibility.js
static/docs/reference/generated/kubectl/node_modules/bootstrap/dist/css/bootstrap.min.css
static/docs/reference/generated/kubectl/node_modules/highlight.js/styles/default.css
static/docs/reference/generated/kubectl/node_modules/jquery.scrollto/jquery.scrollTo.min.js
static/docs/reference/generated/kubectl/node_modules/jquery/dist/jquery.min.js
static/docs/reference/generated/kubectl/css/font-awesome.min.css

Згенеровані теки та файли довідки по Kubernetes API

static/docs/reference/generated/kubernetes-api/v1.31/index.html
static/docs/reference/generated/kubernetes-api/v1.31/js/navData.js
static/docs/reference/generated/kubernetes-api/v1.31/js/scroll.js
static/docs/reference/generated/kubernetes-api/v1.31/js/query.scrollTo.min.js
static/docs/reference/generated/kubernetes-api/v1.31/css/font-awesome.min.css
static/docs/reference/generated/kubernetes-api/v1.31/css/bootstrap.min.css
static/docs/reference/generated/kubernetes-api/v1.31/css/stylesheet.css
static/docs/reference/generated/kubernetes-api/v1.31/fonts/FontAwesome.otf
static/docs/reference/generated/kubernetes-api/v1.31/fonts/fontawesome-webfont.eot
static/docs/reference/generated/kubernetes-api/v1.31/fonts/fontawesome-webfont.svg
static/docs/reference/generated/kubernetes-api/v1.31/fonts/fontawesome-webfont.ttf
static/docs/reference/generated/kubernetes-api/v1.31/fonts/fontawesome-webfont.woff
static/docs/reference/generated/kubernetes-api/v1.31/fonts/fontawesome-webfont.woff2

Виконайте git add та git commit, щоб зафіксувати файли.

Створення pull request

Створіть pull request до репозиторію kubernetes/website. Слідкуйте за вашим pull request і відповідайте на коментарі рецензентів за потреби. Продовжуйте слідкувати за вашим pull request до його злиття.

Через кілька хвилин після злиття вашого pull request, ваша оновлена довідкова документація буде видна в опублікованій документації.

Що далі

Щоб згенерувати окрему довідкову документацію, вручну налаштувавши необхідні репозиторії та запустивши цільові завдання збірки, дивіться наступні посібники:

7.8.2 - Внесок у код Kubernetes

Ця сторінка показує, як зробити внесок у проєкт kubernetes/kubernetes. Ви можете виправити помилки, знайдені в документації API Kubernetes або вмісті компонентів Kubernetes, таких як kubeadm, kube-apiserver та kube-controller-manager.

Якщо ви хочете відновити довідкову документацію для API Kubernetes або компонентів kube-* з коду upstream, перегляньте наступні інструкції:

Перш ніж ви розпочнете

  • Вам потрібно встановити наступні інструменти:

  • Ваша змінна середовища GOPATH повинна бути встановлена, а розташування etcd повинно бути у вашій змінній середовища PATH.

  • Вам потрібно знати, як створити pull request у репозиторій GitHub. Зазвичай це включає створення форку репозиторію. Для отримання додаткової інформації дивіться Створення Pull Request та Стандартний Workflow Fork & Pull Request на GitHub.

Загальна картина

Довідкова документація для API Kubernetes та компонентів kube-*, таких як kube-apiserver, kube-controller-manager, автоматично генерується з вихідного коду в upstream Kubernetes.

Коли ви бачите помилки в згенерованій документації, ви можете розглянути можливість створення патчу для виправлення помилки в upstream проєкті.

Клонування репозиторію Kubernetes

Якщо ви ще не маєте репозиторію kubernetes/kubernetes, отримайте його зараз:

mkdir $GOPATH/src
cd $GOPATH/src
go get github.com/kubernetes/kubernetes

Визначте базову теку вашого клону репозиторію kubernetes/kubernetes. Наприклад, якщо ви слідували попередньому кроку для отримання репозиторію, ваша базова тека — $GOPATH/src/github.com/kubernetes/kubernetes. Наступні кроки посилаються на вашу базову теку як <k8s-base>.

Визначте базову теку вашого клону репозиторію kubernetes-sigs/reference-docs. Наприклад, якщо ви слідували попередньому кроку для отримання репозиторію, ваша базова тека — $GOPATH/src/github.com/kubernetes-sigs/reference-docs. Наступні кроки посилаються на ваш базовий каталог як <rdocs-base>.

Редагування вихідного коду Kubernetes

Довідкова документація API Kubernetes автоматично генерується з OpenAPI специфікації, яка створюється з вихідного коду Kubernetes. Якщо ви хочете змінити довідкову документацію API, перший крок — змінити один або кілька коментарів у вихідному коді Kubernetes.

Документація для компонентів kube-* також генерується з вихідного коду upstream. Ви повинні змінити код, повʼязаний з компонентом, який ви хочете виправити, щоб виправити згенеровану документацію.

Зробіть зміни у вихідному коді upstream

Ось приклад редагування коментаря у вихідному коді Kubernetes.

У вашому локальному репозиторії kubernetes/kubernetes, перейдіть на основну гілку і переконайтеся, що вона оновлена:

cd <k8s-base>
git checkout master
git pull https://github.com/kubernetes/kubernetes master

Припустимо, що у цьому вихідному файлі в основній гілці є помилка "atmost":

kubernetes/kubernetes/staging/src/k8s.io/api/apps/v1/types.go

У вашому локальному середовищі відкрийте types.go і змініть "atmost" на "at most".

Перевірте, що ви змінили файл:

git status

Вивід показує, що ви в основній гілці та що вихідний файл types.go був змінений:

On branch master
...
    modified:   staging/src/k8s.io/api/apps/v1/types.go

Збережіть відредагований файл

Виконайте git add і git commit, щоб зберегти зміни, які ви внесли до цього моменту. У наступному кроці ви зробите другий коміт. Важливо зберігати ваші зміни в окремих комітах.

Перейдіть до <k8s-base> і запустіть ці скрипти:

./hack/update-codegen.sh
./hack/update-openapi-spec.sh

Виконайте git status, щоб побачити, що було згенеровано.

On branch master
...
    modified:   api/openapi-spec/swagger.json
    modified:   api/openapi-spec/v3/apis__apps__v1_openapi.json
    modified:   pkg/generated/openapi/zz_generated.openapi.go
    modified:   staging/src/k8s.io/api/apps/v1/generated.proto
    modified:   staging/src/k8s.io/api/apps/v1/types_swagger_doc_generated.go

Перегляньте вміст api/openapi-spec/swagger.json, щоб переконатися, що помилка виправлена. Наприклад, ви можете виконати git diff -a api/openapi-spec/swagger.json. Це важливо, оскільки swagger.json є вхідними даними для другого етапу процесу генерації документації.

Виконайте git add і git commit, щоб зберегти ваші зміни. Тепер у вас є два коміти: один з відредагованим файлом types.go, і один, що містить згенеровану OpenAPI специфікацію та супутні файли. Залишить ці два коміти окремо. Тобто, не зливайте ваші коміти.

Подайте свої зміни як pull request до основної гілки репозиторію kubernetes/kubernetes. Слідкуйте за вашим pull request і відповідайте на коментарі рецензентів за потреби. Продовжуйте слідкувати за вашим pull request, поки він не буде злитий.

PR 57758 є прикладом pull request, який виправляє помилку в коді Kubernetes.

Cherry-pick вашого коміту у релізну гілку

У попередньому розділі ви відредагували файл в основній гілці та потім запустили скрипти для генерації OpenAPI специфікації та супутніх файлів. Потім ви подали свої зміни у pull request до основної гілки репозиторію kubernetes/kubernetes. Тепер припустимо, що ви хочете повернути вашу зміну в релізну гілку. Наприклад, якщо основна гілка використовується для розробки версії Kubernetes 1.31, і ви хочете повернути вашу зміну у гілку release-1.30.

Згадайте, що ваш pull request має два коміти: один для редагування types.go і один для файлів, згенерованих скриптами. Наступний крок — запропонувати cherry pick вашого першого коміту у гілку release-1.30. Ідея полягає в тому, щоб зробити cherry-pick коміту, що редагував types.go, але не коміту, що має результати запуску скриптів. Для інструкцій дивіться Запропонувати Cherry Pick.

Коли у вас є pull request для cherry-pick вашого коміту у гілку release-1.30, наступний крок — запустити ці скрипти в гілці release-1.30 у вашому локальному середовищі.

./hack/update-codegen.sh
./hack/update-openapi-spec.sh

Тепер додайте коміт до вашого cherry-pick pull request, що містить нещодавно згенеровану OpenAPI специфікацію та супутні файли. Слідкуйте за вашим pull request, поки він не буде злитий у гілку release-1.30.

На цьому етапі й основна гілка, й гілка release-1.30 містять ваш оновлений файл types.go та набір згенерованих файлів, що відображають зміну, яку ви внесли в types.go. Зазначте, що згенерована OpenAPI специфікація та інші згенеровані файли в гілці release-1.30 не обовʼязково будуть такими ж, як згенеровані файли в основній гілці. Згенеровані файли в гілці release-1.30 містять API елементи лише з Kubernetes 1.30. Згенеровані файли в основній гілці можуть містити API елементи, які не є в 1.30, але розробляються для 1.31.

Генерація опублікованих довідкових документів

Попередній розділ показав, як редагувати вихідний файл і потім згенерувати декілька файлів, включаючи api/openapi-spec/swagger.json у репозиторії kubernetes/kubernetes. Файл swagger.json є файлом визначення OpenAPI, який використовується для генерації документації API.

Тепер ви готові слідувати посібнику Генерація довідкової документації для API Kubernetes, щоб згенерувати опубліковану довідкову документацію API Kubernetes.

Що далі

7.8.3 - Генерація документації для API Kubernetes

Ця сторінка демонструє, як оновити документацію API Kubernetes.

Документація API Kubernetes формується на основі специфікації OpenAPI Kubernetes з використанням коду генерації з kubernetes-sigs/reference-docs.

Якщо ви знайшли помилки у згенерованій документації, вам потрібно виправити їх на upstream.

Якщо вам потрібно тільки згенерувати документацію з OpenAPI, продовжте читати цю сторінку.

Перш ніж ви розпочнете

Вимоги:

  • Вам потрібна машина, що працює під управлінням Linux або macOS.

  • Вам потрібно встановити ці інструменти:

  • Ваша змінна середовища PATH повинна включати необхідні інструменти для збірки, такі як бінарники Go та python.

  • Вам потрібно знати, як створити pull request до репозиторію на GitHub. Це включає створення власного форку репозиторію. Для отримання додаткової інформації дивіться Робота з локальним клоном.

Налаштування локальних репозиторіїв

Створіть локальне робоче середовище і встановіть ваш GOPATH:

mkdir -p $HOME/<workspace>

export GOPATH=$HOME/<workspace>

Отримайте локальну копію наступних репозиторіїв:

go get -u github.com/kubernetes-sigs/reference-docs

go get -u github.com/go-openapi/loads
go get -u github.com/go-openapi/spec

Якщо у вас ще немає репозиторію kubernetes/website, отримайте його зараз:

git clone https://github.com/<your-username>/website $GOPATH/src/github.com/<your-username>/website

Отримайте копію репозиторію kubernetes/kubernetes як k8s.io/kubernetes:

git clone https://github.com/kubernetes/kubernetes $GOPATH/src/k8s.io/kubernetes
  • Основна тека вашої копії kubernetes/kubernetes репозиторію є $GOPATH/src/k8s.io/kubernetes. Подальші кроки використовують цю основну директорію як <k8s-base>.

  • Основна тека вашої копії kubernetes/website репозиторію є $GOPATH/src/github.com/<your username>/website. Подальші кроки використовують цю основну директорію як <web-base>.

  • Основна тека вашої копії kubernetes-sigs/reference-docs репозиторію є $GOPATH/src/github.com/kubernetes-sigs/reference-docs. Подальші кроки використовують цю основну директорію як <rdocs-base>.

Генерація документації API

Цей розділ демонструє, як згенерувати опубліковану документацію API Kubernetes.

Встановлення змінних для зборки

  • Встановіть K8S_ROOT на <k8s-base>.
  • Встановіть K8S_WEBROOT на <web-base>.
  • Встановіть K8S_RELEASE на версію документації, яку ви хочете зібрати. Наприклад, якщо ви хочете зібрати документацію для Kubernetes 1.17.0, встановіть K8S_RELEASE на 1.17.0.

Наприклад:

export K8S_WEBROOT=${GOPATH}/src/github.com/<your-username>/website
export K8S_ROOT=${GOPATH}/src/k8s.io/kubernetes
export K8S_RELEASE=1.17.0

Створення теки версії та завантаження специфікації Open API

Ціль збірки updateapispec створює теку версії для збірки. Після створення теки, специфікація Open API завантажується з репозиторію <k8s-base>. Ці кроки забезпечують відповідність версій конфігураційних файлів і Kubernetes Open API специфікації з версією релізу. Назва теки версії слідує шаблону v<major>_<minor>.

У теці <rdocs-base>, виконайте наступну ціль збірки:

cd <rdocs-base>
make updateapispec

Збірка документації API

Ціль copyapi будує документацію API та копіює згенеровані файли до теки у <web-base>. Виконайте наступну команду у <rdocs-base>:

cd <rdocs-base>
make copyapi

Перевірте, що ці два файли були згенеровані:

[ -e "<rdocs-base>/gen-apidocs/build/index.html" ] && echo "index.html built" || echo "no index.html"
[ -e "<rdocs-base>/gen-apidocs/build/navData.js" ] && echo "navData.js built" || echo "no navData.js"

Перейдіть до основної теки вашого локального <web-base>, і перегляньте, які файли були змінені:

cd <web-base>
git status

Вихідний результат буде подібним до:

static/docs/reference/generated/kubernetes-api/v1.31/css/bootstrap.min.css
static/docs/reference/generated/kubernetes-api/v1.31/css/font-awesome.min.css
static/docs/reference/generated/kubernetes-api/v1.31/css/stylesheet.css
static/docs/reference/generated/kubernetes-api/v1.31/fonts/FontAwesome.otf
static/docs/reference/generated/kubernetes-api/v1.31/fonts/fontawesome-webfont.eot
static/docs/reference/generated/kubernetes-api/v1.31/fonts/fontawesome-webfont.svg
static/docs/reference/generated/kubernetes-api/v1.31/fonts/fontawesome-webfont.ttf
static/docs/reference/generated/kubernetes-api/v1.31/fonts/fontawesome-webfont.woff
static/docs/reference/generated/kubernetes-api/v1.31/fonts/fontawesome-webfont.woff2
static/docs/reference/generated/kubernetes-api/v1.31/index.html
static/docs/reference/generated/kubernetes-api/v1.31/js/jquery.scrollTo.min.js
static/docs/reference/generated/kubernetes-api/v1.31/js/navData.js
static/docs/reference/generated/kubernetes-api/v1.31/js/scroll.js

Оновлення індексних сторінок документації API

При генерації документації для нового релізу, оновіть файл <web-base>/content/en/docs/reference/kubernetes-api/api-index.md з новим номером версії.

  • Відкрийте <web-base>/content/en/docs/reference/kubernetes-api/api-index.md для редагування, і оновіть номер версії документації API. Наприклад:

    ---
    title: v1.17
    ---
    
    [Kubernetes API v1.17](/docs/reference/generated/kubernetes-api/v1.17/)
    
  • Відкрийте <web-base>/content/en/docs/reference/_index.md для редагування, і додайте нове посилання на найновішу документацію API. Видаліть найстаріше посилання на версію документації API. Має бути пʼять посилань на найновіші версії документації API.

Локальне тестування документації API

Опублікуйте локальну версію документації API. Перевірте локальний попередній перегляд.

cd <web-base>
git submodule update --init --recursive --depth 1 # якщо ще не зроблено
make container-serve

Коміт змін

У <web-base>, виконайте git add і git commit, щоб зафіксувати зміни.

Подайте ваші зміни як pull request до репозиторію kubernetes/website. Слідкуйте за вашим pull request, і відповідайте на коментарі рецензентів за потреби. Продовжуйте слідкувати за вашим pull request до його злиття.

Що далі

7.8.4 - Генерація документації для команд kubectl

Ця сторінка показує, як згенерувати довідкову документацію для команд kubectl.

Перш ніж ви розпочнете

Вимоги:

  • Вам потрібна машина, що працює під управлінням Linux або macOS.

  • Вам потрібно встановити ці інструменти:

  • Ваша змінна середовища PATH повинна включати необхідні інструменти для збірки, такі як бінарники Go та python.

  • Вам потрібно знати, як створити pull request до репозиторію на GitHub. Це включає створення власного форку репозиторію. Для отримання додаткової інформації дивіться Робота з локальним клоном.

Налаштування локальних репозиторіїв

Створіть локальне робоче середовище і встановіть ваш GOPATH:

mkdir -p $HOME/<workspace>

export GOPATH=$HOME/<workspace>

Отримайте локальну копію наступних репозиторіїв:

go get -u github.com/spf13/pflag
go get -u github.com/spf13/cobra
go get -u gopkg.in/yaml.v2
go get -u github.com/kubernetes-sigs/reference-docs

Якщо у вас ще немає репозиторію kubernetes/website, отримайте його зараз:

git clone https://github.com/<your-username>/website $GOPATH/src/github.com/<your-username>/website

Отримайте копію репозиторію kubernetes/kubernetes як k8s.io/kubernetes:

git clone https://github.com/kubernetes/kubernetes $GOPATH/src/k8s.io/kubernetes

Видаліть пакет spf13 з $GOPATH/src/k8s.io/kubernetes/vendor/github.com:

rm -rf $GOPATH/src/k8s.io/kubernetes/vendor/github.com/spf13

Репозиторій kubernetes/kubernetes надає вихідний код kubectl і kustomize.

  • Визначте основну теку вашої копії репозиторію kubernetes/kubernetes. Наприклад, якщо ви слідували попередньому кроку для отримання репозиторію, ваша основна тека є $GOPATH/src/k8s.io/kubernetes. Подальші кроки використовують цю основну теку як <k8s-base>.

  • Визначте основну теку вашої копії репозиторію kubernetes/website. Наприклад, якщо ви слідували попередньому кроку для отримання репозиторію, ваша основна тека є $GOPATH/src/github.com/<your-username>/website. Подальші кроки використовують цю основну теку як <web-base>.

  • Визначте основну теку вашої копії kubernetes-sigs/reference-docs репозиторію. Наприклад, якщо ви слідували попередньому кроку для отримання репозиторію, ваша основна тека є $GOPATH/src/github.com/kubernetes-sigs/reference-docs. Подальші кроки використовують цю основну теку як <rdocs-base>.

У вашій локальній копії k8s.io/kubernetes перевірте гілку інтересу і переконайтеся, що вона актуальна. Наприклад, якщо ви хочете згенерувати документацію для Kubernetes 1.30.0, ви можете використати ці команди:

cd <k8s-base>
git checkout v1.30.0
git pull https://github.com/kubernetes/kubernetes 1.30.0

Якщо вам не потрібно редагувати вихідний код kubectl, дотримуйтесь інструкцій для Налаштування змінних для зборки.

Редагування вихідного коду kubectl

Документація довідки для команд kubectl автоматично генерується з вихідного коду kubectl. Якщо ви хочете змінити довідкову документацію, перший крок — змінити один або кілька коментарів у вихідному коді kubectl. Змініть їх у вашій локальній копії репозиторію kubernetes/kubernetes, а потім подайте pull request до основної гілки github.com/kubernetes/kubernetes.

PR 56673 є прикладом pull requestг, який виправляє помилку в вихідному коді kubectl.

Слідкуйте за вашим pull request і відповідайте на коментарі рецензентів. Продовжуйте слідкувати за вашим pull request до його злиття в цільову гілку репозиторію kubernetes/kubernetes.

Cherry pick вашої зміни до релізної гілки

Ваша зміна тепер знаходиться в основній гілці, яка використовується для розробки наступного випуску Kubernetes. Якщо ви хочете, щоб ваша зміна зʼявилася в документації для версії Kubernetes, яка вже була випущена, вам потрібно запропонувати, щоб вашу зміну було вибрано для релізної гілки.

Наприклад, припустимо, що основна гілка використовується для розробки Kubernetes 1.31 і ви хочете повернути вашу зміну до релізної гілки release-1.30. Для інструкцій про те, як це зробити, дивіться Пропонування вибірки.

Слідкуйте за вашим запитом на вибірку до його злиття в релізну гілку.

Налаштування змінних для збірки

Перейдіть до <rdocs-base>. У командному рядку встановіть наступні змінні середовища.

  • Встановіть K8S_ROOT на <k8s-base>.
  • Встановіть K8S_WEBROOT на <web-base>.
  • Встановіть K8S_RELEASE на версію документації, яку ви хочете зібрати. Наприклад, якщо ви хочете зібрати документацію для Kubernetes 1.30, встановіть K8S_RELEASE на 1.30.

Наприклад:

export K8S_WEBROOT=$GOPATH/src/github.com/<your-username>/website
export K8S_ROOT=$GOPATH/src/k8s.io/kubernetes
export K8S_RELEASE=1.30

Створення теки версії

Ціль збірки createversiondirs створює версійну теку і копіює конфігураційні файли довідки для kubectl до теки версії. Назва теки версії слідує шаблону v<major>_<minor>.

У теці <rdocs-base> виконайте наступну ціль зборки:

cd <rdocs-base>
make createversiondirs

Перевірте теґ релізу у k8s.io/kubernetes

У вашій локальній копії <k8s-base> перевірте гілку, яка містить версію Kubernetes, яку ви хочете задокументувати. Наприклад, якщо ви хочете згенерувати документацію для Kubernetes 1.30.0, перевірте теґ v1.30. Переконайтеся, що ваша локальна гілка актуальна.

cd <k8s-base>
git checkout v1.30.0
git pull https://github.com/kubernetes/kubernetes v1.30.0

Запустіть код генерації документації

У вашій локальній копії <rdocs-base>, виконайте ціль зборки copycli. Команда запускається як root:

cd <rdocs-base>
make copycli

Команда copycli очищує тимчасову теку збірки, генерує файли команд kubectl і копіює зведену HTML-сторінку довідки команд kubectl та активи до <web-base>.

Знайдіть згенеровані файли

Перевірте, чи ці два файли були згенеровані:

[ -e "<rdocs-base>/gen-kubectldocs/generators/build/index.html" ] && echo "index.html built" || echo "no index.html"
[ -e "<rdocs-base>/gen-kubectldocs/generators/build/navData.js" ] && echo "navData.js built" || echo "no navData.js"

Знайдіть скопійовані файли

Перевірте, чи всі згенеровані файли були скопійовані до вашої <web-base> теки:

cd <web-base>
git status

Вивід має включати змінені файли:

static/docs/reference/generated/kubectl/kubectl-commands.html
static/docs/reference/generated/kubectl/navData.js

Вивід також може включати:

static/docs/reference/generated/kubectl/scroll.js
static/docs/reference/generated/kubectl/stylesheet.css
static/docs/reference/generated/kubectl/tabvisibility.js
static/docs/reference/generated/kubectl/node_modules/bootstrap/dist/css/bootstrap.min.css
static/docs/reference/generated/kubectl/node_modules/highlight.js/styles/default.css
static/docs/reference/generated/kubectl/node_modules/jquery.scrollto/jquery.scrollTo.min.js
static/docs/reference/generated/kubectl/node_modules/jquery/dist/jquery.min.js
static/docs/reference/generated/kubectl/node_modules/font-awesome/css/font-awesome.min.css

Локально протестуйте документацію

Побудуйте документацію Kubernetes у вашій локальній копії <web-base>.

cd <web-base>
git submodule update --init --recursive --depth 1 # якщо не було зроблено раніше
make container-serve

Перегляньте локальний попередній перегляд.

Додайте та зафіксуйте зміни в kubernetes/website

Запустіть git add та git commit, щоб зафіксувати файли.

Створіть pull request

Створіть pull request до репозиторію kubernetes/website. Слідкуйте за вашим pull request і відповідайте на коментарі рецензентів за потреби. Продовжуйте слідкувати за вашим pull request до його злиття.

Через кілька хвилин після злиття вашого pull request оновлені теми довідки стануть видимими в опублікованій документації.

Що далі

7.8.5 - Генерація довідкової документації для метрик

Ця сторінка демонструє, як згенерувати довідкову документацію для метрик.

Перш ніж ви розпочнете

Вимоги:

  • Вам потрібна машина, що працює під управлінням Linux або macOS.

  • Вам потрібно встановити ці інструменти:

  • Ваша змінна середовища PATH повинна включати необхідні інструменти для збірки, такі як бінарники Go та python.

  • Вам потрібно знати, як створити pull request до репозиторію на GitHub. Це включає створення власного форку репозиторію. Для отримання додаткової інформації дивіться Робота з локальним клоном.

Клонування репозиторію Kubernetes

Генерація документації для метрик відбувається в репозиторії Kubernetes. Щоб клонувати репозиторій, перейдіть до теки, де ви хочете, щоб знаходилася клонована копія.

Потім виконайте наступну команду:

git clone https://www.github.com/kubernetes/kubernetes 

Це створить теку kubernetes у вашій поточній робочій теці.

Генерація документації для метрик

У клонованому репозиторії Kubernetes знайдіть теку test/instrumentation/documentation. Документація для метрик генерується в цій теці.

З кожним релізом додаються нові метрики. Після того, як ви запустите скрипт генерації документації для метрик, скопіюйте документацію для метрик на вебсайт Kubernetes і опублікуйте оновлену документацію для метрик.

Щоб згенерувати останні метрики, переконайтеся, що ви знаходитесь в кореневій теці клонованого репозиторію Kubernetes. Потім виконайте наступну команду:

./test/instrumentation/update-documentation.sh

Щоб перевірити наявність змін, виконайте команду:

git status

Вивід буде схожий на:

./test/instrumentation/documentation/documentation.md
./test/instrumentation/documentation/documentation-list.yaml

Скопіюйте згенерований файл документації для метрик в репозиторій вебсайту Kubernetes

  1. Встановіть змінну середовища для кореневої теки вебсайту Kubernetes.

    Виконайте наступну команду, щоб встановити кореневу теку вебсайту:

    export WEBSITE_ROOT=<шлях до кореня вебсайту>
    
  2. Скопіюйте згенерований файл метрик в репозиторій вебсайту Kubernetes.

    cp ./test/instrumentation/documentation/documentation.md "${WEBSITE_ROOT}/content/en/docs/reference/instrumentation/metrics.md"
    

Створіть pull request

Щоб створити pull request, дотримуйтесь інструкцій у розділі Відкриття pull request.

Що далі

7.8.6 - Генерація довідкових сторінок для компонентів та інструментів Kubernetes

Ця сторінка показує, як створювати довідкові сторінки для компонентів та інструментів Kubernetes.

Перш ніж ви розпочнете

Розпочніть з розділу Передумови у довідковому посібнику Quickstart для генерування документації.

Дотримуйтесь інструкцій у довідковому посібнику Quickstart, щоб згенерувати довідкові сторінки для компонентів та інструментів Kubernetes.

Що далі


7.8.7 -

Вимоги:

  • Вам потрібна машина, що працює під управлінням Linux або macOS.

  • Вам потрібно встановити ці інструменти:

  • Ваша змінна середовища PATH повинна включати необхідні інструменти для збірки, такі як бінарники Go та python.

  • Вам потрібно знати, як створити pull request до репозиторію на GitHub. Це включає створення власного форку репозиторію. Для отримання додаткової інформації дивіться Робота з локальним клоном.

7.9 - Розширена участь

Ця сторінка передбачає, що ви вже знаєте, як додавати новий контент та перевіряти роботу інших, і готові дізнатися більше про способи участі. Вам потрібно використовувати командний рядок Git та інші інструменти для виконання деяких з цих завдань.

Пропонування покращень

Члени SIG Docs можуть пропонувати покращення.

Після того, як ви вже деякий час вносите зміни в документацію Kubernetes, у вас можуть зʼявитися ідеї щодо покращення настанов зі стилю, настанов з контенту, інструментів, які використовуються для створення документації, стилю вебсайту, процесів перевірки та злиття pull request-ів, або інших аспектів документації. Для забезпечення максимальної прозорості ці пропозиції повинні обговорюватися на зустрічі SIG Docs або у списку розсилки kubernetes-sig-docs. Крім того, корисно мати певний контекст щодо того, як все зараз працює і чому в минулому були прийняті певні рішення, перш ніж пропонувати кардинальні зміни. Найшвидший спосіб отримати відповіді на запитання про те, як працює документація, — запитати в каналі #sig-docs на kubernetes.slack.com.

Після того, як обговорення відбулося, і SIG Docs погодився щодо бажаного результату, ви можете працювати над запропонованими змінами найбільш відповідним чином. Наприклад, оновлення керівництва зі стилю або функціональності вебсайту може включати відкриття pull request, тоді як зміна, повʼязана з тестуванням документації, може передбачати співпрацю з sig-testing.

Координація документації для випуску Kubernetes

Затверджувачі SIG Docs можуть координувати документацію для випуску Kubernetes.

Кожен випуск Kubernetes координується командою, яка бере участь у робочій групі (SIG) sig-release. Серед інших членів команди випуску: загальний керівник випуску, а також представники sig-testing та інші. Щоб дізнатися більше про процеси випуску Kubernetes, зверніться до https://github.com/kubernetes/sig-release.

Представник SIG Docs для даного випуску координує наступні завдання:

  • Моніторинг електронної таблиці для відстеження функцій щодо нових або змінених функцій, які впливають на документацію. Якщо документація для певної функції не буде готова до випуску, ця функція може не бути включена у випуск.
  • Регулярне відвідування зустрічей sig-release та надання оновлень про статус документації для випуску.
  • Перегляд та редагування документації для функцій, підготовлених SIG, відповідальним за реалізацію функції.
  • Злиття pull request-ів, повʼязаних з випуском, і підтримка гілки Git для випуску.
  • Наставництво інших учасників SIG Docs, які хочуть навчитися виконувати цю роль у майбутньому. Це називається "shadowing".
  • Публікація змін у документації, повʼязаних з випуском, коли публікуються артефакти випуску.

Координація випуску зазвичай займає 3-4 місяці, і цей обовʼязок передається між затверджувачами SIG Docs.

Виконання обовʼязків New Contributor Ambassador

Затверджувачі SIG Docs можуть бути New Contributor Ambassador.

Помічники для нових учасників вітають нових учасників SIG-Docs, пропонують PRʼи новим учасникам та наставляють нових учасників через їх перші кілька PR-ів.

ОбовʼязкиNew Contributor Ambassador включають:

  • Моніторинг каналу #sig-docs Slack на предмет запитань від нових учасників.
  • Співпраця з керівниками PRʼів для ідентифікації good first issues для нових учасників.
  • Наставництво нових учасників через їхні перші кілька PRʼів до репозиторію документації.
  • Допомога новим учасникам у створенні складніших PRʼів, необхідних їм для того, щоб стати членами Kubernetes.
  • Поручительство за учасників на їхньому шляху до членства у Kubernetes.
  • Проведення щомісячної зустрічі для допомоги та наставництва нових учасників.

Поточні Амбасадори нових учасників оголошуються на кожній зустрічі SIG-Docs та в каналі #sig-docs Kubernetes.

Рецензенти SIG Docs можуть бути поручителями нових учасників.

Після того, як новий учасник успішно подав 5 значних pull requestʼів до одного або кількох репозиторіїв Kubernetes, він має право подати заявку на членство в організації Kubernetes. Членство учасника повинно бути підтримано двома поручителями, які вже є рецензентами.

Нові учасники документації можуть запитати поручителів, запитавши в каналі #sig-docs на Slack Kubernetes або у списку розсилки SIG Docs. Якщо ви впевнені в роботі заявника, ви можете добровільно поручитись за нього. Коли кандидати подають свою заявку на членство, відповідайте на заявку з "+1" і включайте деталі про те, чому ви вважаєте, що заявник добре підходить для членства в організації Kubernetes.

Виконання обовʼязків співголови SIG

Члени SIG Docs можуть бути співголовою SIG Docs.

Вимоги

Член Kubernetes повинен відповідати наступним вимогам для того, щоб бути співголовою:

  • Розуміти робочі процеси та інструментарій SIG Docs: git, Hugo, локалізація, блог.
  • Розуміти, як інші SIG Kubernetes та репозиторії впливають на робочий процес SIG Docs, включаючи: команди в k/org, процеси в k/community, втулки в k/test-infra, та роль SIG Architecture. Крім того, розуміти, як працює процес випуску документації Kubernetes.
  • Отримати схвалення від спільноти SIG Docs або безпосередньо, або за допомогою консенсусу.
  • Виділяти принаймні 5 годин на тиждень (і часто більше) на цю роль протягом мінімум 6 місяців.

Обовʼязки

Роль співголови полягає в обслуговуванні: співголови підвищують можливості учасників, керують процесами та політикою, організовують та проводять зустрічі, планують роботу сортувальників PR-ів, висвітлюють важливість документації в спільноті Kubernetes, забезпечують успішне завершення випусків документації та фокусують SIG Docs на ефективних пріоритетах.

Обовʼязки включають:

  • Фокусування SIG Docs на максимальному задоволенні розробників через відмінну документацію
  • Втілення кодексу поведінки спільноти та відповідальність за його дотримання серед членів SIG
  • Вивчення та встановлення найкращих практик для SIG шляхом оновлення рекомендацій щодо внесення змін
  • Організація та проведення зустрічей SIG: щотижневі оновлення статусу, щоквартальні ретроспективи/планування та інші за потребою
  • Організація та проведення спринтів документації на заходах KubeCon та інших конференціях
  • Рекрутинг та захист інтересів SIG Docs у CNCF та її платинових партнерів, включаючи Google, Oracle, Azure, IBM та Huawei
  • Забезпечення безперебійної роботи SIG

Ефективне проведення зустрічей

Щоб організовувати та проводити ефективні зустрічі, вони спрямовують, що робити, як це робити та чому.

Дотримуйтесь кодексу поведінки спільноти:

  • Проводьте шанобливі, інклюзивні дискусії, використовуючи шанобливу, інклюзивну мову.

Встановіть чіткий порядок денний:

  • Встановіть чіткий порядок денний тем
  • Опублікуйте порядок денний заздалегідь

Для щотижневих зустрічей скопіюйте нотатки з попереднього тижня у розділ "Минулі зустрічі" нотаток

Співпрацюйте для точних нотаток:

  • Записуйте обговорення зустрічі
  • Розгляньте можливість делегування ролі стенографіста

Чітко та точно призначайте дії:

  • Записуйте завдання, відповідального за нього та очікувану дату виконання

Модеруйте за потребою:

  • Якщо обговорення відходить від порядку денного, поверніть учасників до поточної теми
  • Забезпечте різні стилі обговорення, зберігаючи фокус та поважаючи час учасників

Повага до часу учасників:

Починайте і закінчуйте зустрічі вчасно.

Ефективне використання Zoom:

Отримання ролі хоста в Zoom

Запис зустрічей в Zoom

Коли ви готові розпочати запис, натисніть "Record to Cloud".

Коли ви готові зупинити запис, натисніть "Stop".

Відео автоматично завантажується на YouTube.

Завершення роботи співголови SIG (Emeritus)

Дивіться: k/community/sig-docs/offboarding.md

7.10 - Перегляд аналітики сайту

Ця сторінка містить інформацію про інформаційну аналітичну панель kubernetes.io.

Переглянути панель.

Ця панель побудована за допомогою Google Looker Studio та відображає інформацію, зібрану на kubernetes.io за допомогою Google Analytics 4 з серпня 2022 року.

Використання панелі

Стандартно панель відображає всю зібрану аналітику за останні 30 днів. Використовуйте селектор дат, щоб переглянути дані за інший період. Інші варіанти фільтрації дозволяють переглядати дані на основі місця розташування користувачів, пристрою, з якого вони отримали доступ до сайту, перекладу документації та іншого.

Якщо ви помітили проблему з цією панеллю або хочете запросити будь-які покращення, будь ласка, відкрийте тікет.

7.11 - Рекомендації з перекладу українською мовою

Дорогі друзі! Раді вітати вас у спільноті українських учасників проєкту Kubernetes. Ця сторінка створена з метою полегшити вашу роботу в роботі з перекладу документації. Вона містить правила, якими ми керувалися під час перекладу. Будемо дуже вдячні, якщо ви допоможете розширити правила перекладу.

Сподіваємось, ці рекомендації стануть вам у пригоді.

Загальний процес

  1. Клонуйте (зробіть форк) репозиторію kubernetes/website.
  2. Ознайомтесь з цим документом.
  3. Зробіть переклад
  4. Створіть пул-реквест в kubernetes/website.

Якщо вам знадобиться допомога, зареєструйтеся в Slack Kubernetes, приєднайтеся до каналу#kubernetes-docs-uk та спитайте там.

Отримання допомоги

Якщо ви виявили вади в перекладеному вмісті, створіть тікет на kubernetes/website додавши в тіло тікета команду Prow — /language uk.

Наявні проблеми/оновлення локалізації

Якщо ви виявили проблеми з перекладеним вмістом і не можете їх негайно виправити, створіть тікет у kubernetes/website з описом що не так, на якій сторінці (посилання) і додайте в опис тікета, з нового рядка, команду Prow — /language uk.

Переклад

  • У випадку, якщо у перекладі термін набуває неоднозначності та розуміння тексту ускладнюється, надайте у дужках англійський варіант, наприклад: точки доступу (endpoints). Якщо при перекладі термін втрачає своє значення, краще не перекладати його.
  • Назви обʼєктів Kubernetes залишаємо без перекладу і пишемо з великої літери: Service, Pod, Deployment, Volume, Namespace, за винятком терміна node (вузол). Назви обʼєктів Kubernetes вважаємо за іменники ч.р. і відмінюємо за допомогою апострофа: Podʼів, Deploymentʼами.
  • Для слів, що закінчуються на приголосний, у родовому відмінку однини використовуємо закінчення : Podʼа, Deploymentʼа. Слова, що закінчуються на голосний, не відмінюємо: доступ до Service, за допомогою Namespace. У множині використовуємо англійську форму: користуватися Services, спільні Volumes.
  • Частовживані та усталені за межами Kubernetes слова перекладаємо українською і пишемо з малої літери (labelмітка). У випадку, якщо термін для означення обʼєкта Kubernetes вживається у своєму загальному значенні поза контекстом Kubernetes (service як службова програма, deployment як розгортання), перекладаємо його і пишемо з малої літери, наприклад: service discoveryвиявлення сервісу, continuous deploymentбезперервне розгортання.
  • Складені слова вважаємо за власні назви та не перекладаємо (LabelSelector, kube-apiserver).
  • Для перевірки закінчень слів у родовому відмінку однини (-а/-я, -у/-ю) використовуйте онлайн словник. Якщо слова немає у словнику, визначте його відмінювання і далі відмінюйте за правилами. Докладніше дивіться тут.
  • Для символу тире використовуйте символ mdash «—» (&mdash;, U+2014) замість двох звичайних тире «–» (&ndash;, U+2013), чи дефісу «-» (U+002D)
  • Апостроф: використовуйте літеру-апостроф ʼ (U+02BC) замість звичайного апострофа ' (U+0027), чи правої одинарної лапки (U+2019).

Примітки

На поточний момент в перекладі документації активну участь бере @Andygol. Перекладені матеріали можна переглянути в репозиторії на GitHub Andygol/k8s-website в гілці main-uk-wip.

В репозиторії kubernetes/website ви можете знайти Обговорення Translation tooling for Kubernetes localization #45209 щодо використання систем перекладу та інструментів для локалізації документації Kubernetes.

Також ви можете стежити за процесом тестування таких інструментів в тікеті Test translation tooling for localizations #45756

8 - Сторінка тестування документації

Ця сторінка має дві мети:

  • Показати, як документація Kubernetes використовує Markdown
  • Надати документ "тестування", який можна використовувати для перевірки змін в HTML, CSS та шаблонах, що впливають на загальну документацію.

Рівні заголовків

Вищезазначений заголовок є H2. Заголовок сторінки відображається як H1. Наступні секції показують H3-H6.

H3

Заголовок H3.

H4

Заголовок H4.

H5

Заголовок H5.

H6

Заголовок H6.

Вбудовані елементи

Вбудовані елементи зʼявляються в тексті параграфа, пункту списку, зауваження чи іншого блочного елемента.

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

Стилі тексту в рядку

  • жирний
  • курсив
  • жирний курсив
  • перекреслений
  • підкреслений
  • підкреслений курсив
  • підкреслений жирний
  • підкреслений жирний курсив
  • моноширинний текст
  • моноширинний жирний

Списки

Markdown не має строгих правил обробки списків. Коли ми перейшли з Jekyll на Hugo, деякі списки були зламані. Щоб їх виправити, слід памʼятати про наступне:

  • Переконайтеся, що ви відступаєте елементи підсписку на 2 пробіли.

  • Щоб закінчити один список і почати інший, потрібно вставити HTML-коментар на новому рядку між списками, вирівняний з лівим краєм. Перший список інакше не закінчиться, незалежно від кількості порожніх рядків між ним і другим.

Списки з маркерами

  • Це елемент списку.
  • Це інший елемент списку в тому ж списку.
  • Можна поєднувати - і *.
    • Щоб зробити піделемент, відступіть на два пробіли.
      • Це підпункт. Відступіть ще на два пробіли.
    • Ще один піделемент.
  • Це новий список. З Hugo потрібно використовувати HTML-коментар для розділення двох послідовних списків. HTML-коментар повинен бути на лівому краю.

  • Списки з маркерами можуть містити абзаци або блочні елементи.

    Відступіть вміст так, щоб він був на тому ж рівні, що й перший рядок маркера. Цей абзац і рядок блоку коду вирівнюються з першою B в Bullet вище.

    ls -l
    
    • І підсписок після деякого блочного контенту
  • Елемент списку з маркерами може містити нумерований список.

    1. Нумерований піделемент 1
    2. Нумерований піделемент 2

Нумеровані списки

  1. Це елемент списку
  2. Це інший елемент списку в тому ж списку. Номер, який ви використовуєте в Markdown, не обовʼязково корелює з номером у кінцевому результаті. За угодою, ми зберігаємо їх в синхронізації.
  1. Це новий список. З Hugo потрібно використовувати HTML-коментар для розділення двох послідовних списків. HTML-коментар повинен бути на лівому краю.

  2. Нумеровані списки можуть містити абзаци або блочні елементи.

    Відступіть вміст так, щоб він був на тому ж рівні, що й перший рядок маркера. Цей абзац і рядок блоку коду вирівнюються з N у Numbered вище.

    ls -l
    
    • І підсписок після деякого блочного контенту. Це на тому ж "рівні", що й абзац і блок коду вище, попри те, що відступ більше.

Вкладки

Списки вкладок можна використовувати для умовного відображення вмісту, наприклад, коли потрібно задокументувати кілька варіантів, які потребують різних інструкцій або контексту.

Будь ласка, оберіть варіант.

Вкладки також можуть містити вкладені елементи форматування.

  1. Впорядкований список
  2. (Чи ні)
  3. Списик
echo 'Списки вкладок можуть містити блоки коду!'

Заголовок всередині табличного списку

Вкладені заголовки також можуть бути включені.

Списки перевірки

Списки перевірки технічно є списками з маркерами, але маркери приховані за допомогою CSS.

  • Це елемент списку перевірки
  • Це вибраний елемент списку перевірки

Блоки коду

Ви можете створювати блоки коду двома різними способами, оточуючи блок коду трьома зворотними косими апострофами на рядках перед і після блоку коду. Використовуйте тільки зворотні косі апострофи для блоків коду. Це дозволяє вказати мову коду, що дозволяє підсвічування синтаксису. Це також більш передбачувано, ніж використання відступів.

це блок коду, створений зворотними косими апострофами

Метод зворотних косих апострофів має деякі переваги.

  • Працює майже завжди
  • Компактніший при перегляді вихідного коду
  • Дозволяє вказати, якою мовою написаний блок коду, для підсвічування синтаксису
  • Має чіткий кінець. Іноді метод відступу не працює з мовами, де пробіли мають значення, такими як Python або YAML.

Щоб вказати мову для блоку коду, помістіть її безпосередньо після першої групи зворотних косих апострофів:

ls -l

Звичайні мови, що використовуються в блоках коду документації Kubernetes, включають:

  • bash / shell (обидві працюють однаково)
  • go
  • json
  • yaml
  • xml
  • none (відключає підсвічування синтаксису для блоку)

Блоки коду, що містять shortcodes Hugo

Щоб показати сирі shortcodes Hugo, як у наведеному вище прикладі, і запобігти їх інтерпретації Hugo, використовуйте коментарі в стилі C безпосередньо після < і перед > символами. Наступний приклад ілюструє це (перегляньте вихідний код Markdown для цієї сторінки).

{{< alert color="warning" >}}Це попередження.{{< /alert >}}

Посилання

Щоб відформатувати посилання, помістіть текст посилання всередину квадратних дужок, після чого вкажіть цільове посилання в дужках.

  • [Посилання на Kubernetes.io](https://kubernetes.io/) або
  • [Відносне посилання на Kubernetes.io](/)

Ви також можете використовувати HTML, але це не рекомендується. Наприклад, <a href="https://kubernetes.io/">Посилання на Kubernetes.io</a>.

Зображення

Щоб відформатувати зображення, використовуйте аналогічний синтаксис до посилань, але додайте перед зображенням символ !. У квадратних дужках міститься альтернативний текст зображення. Намагайтеся завжди використовувати альтернативний текст, щоб люди, які користуються читачами екрану, могли отримати користь від зображення.

іконка олівця

Щоб вказати додаткові атрибути, такі як ширина, заголовок, підпис тощо, використовуйте figure shortcode, що є переважним у порівнянні з використанням HTML <img> теґу. Якщо ви хочете, щоб зображення також було гіперпосиланням, використовуйте атрибут link, замість того щоб обгортати все зображення в синтаксисі посилання Markdown, як показано нижче.

Зображення, що ілюструє figure shortcode

Іконка олівця

Зображення, що ілюструє figure shortcode

Навіть якщо ви вирішите не використовувати figure shortcode, зображення може бути також посиланням. Цього разу іконка олівця посилається на вебсайт Kubernetes. Зовнішні квадратні дужки обгортають весь теґ зображення, а цільове посилання знаходиться в дужках в кінці.

іконка олівця

Ви також можете використовувати HTML для зображень, але це не рекомендується.

іконка олівця

Таблиці

Прості таблиці мають один рядок настроку, а стовпці розділені символами |. Заголовок відокремлюється від тіла комірками, що містять лише щонайменше три символи -. Для зручності обслуговування намагайтеся тримати всі роздільники комірок на одному рівні, навіть якщо потрібно використовувати додатковий простір.

Заголовок комірки 1Заголовок комірки 2
Комірка тіла 1Комірка тіла 2

Заголовок є необовʼязковим. Будь-який текст, розділений |, буде відображатися як таблиця.

Markdown таблиці мають труднощі з блочними елементами всередині комірок, такими як пункти списку, блоки коду або кілька параграфів. Для складних або дуже широких таблиць використовуйте HTML замість Markdown.

Заголовок комірки 1Заголовок комірки 2
Комірка тіла 1Комірка тіла 2

Візуалізації з Mermaid

Ви можете використовувати візуалізації Mermaid JS. Версія Mermaid JS вказана в /layouts/partials/head.html

{{< mermaid >}}
graph TD;
  A-->B;
  A-->C;
  B-->D;
  C-->D;
{{</ mermaid >}}

В результаті виходить:

graph TD; A-->B; A-->C; B-->D; C-->D;
{{< mermaid >}}
sequenceDiagram
    Alice ->> Bob: Hello Bob, how are you?
    Bob-->>John: How about you John?
    Bob--x Alice: I am good thanks!
    Bob-x John: I am good thanks!
    Note right of John: Bob thinks a long<br/>long time, so long<br/>that the text does<br/>not fit on a row.

    Bob-->Alice: Checking with John...
    Alice->John: Yes... John, how are you?
{{</ mermaid >}}

В результаті виходить:

sequenceDiagram Alice ->> Bob: Hello Bob, how are you? Bob-->>John: How about you John? Bob--x Alice: I am good thanks! Bob-x John: I am good thanks! Note right of John: Bob thinks a long
long time, so long
that the text does
not fit on a row. Bob-->Alice: Checking with John... Alice->John: Yes... John, how are you?

Ви можете переглянути більше прикладів в офіційній документації.

Бокові панелі та зауваження

Бокові панелі та зауваження забезпечують спосіб додати візуальну важливість тексту. Використовуйте їх помірковано.

Бокові панелі

Бокова панель відзначає текст візуально, але без візуальної виразності зауважень.

Це бокова панель.

Ви можете мати параграфи та блокові елементи всередині бокової панелі.

Ви навіть можете включати блоки коду.

sudo dmesg

Зауваження

Зауваження (примітки, попередження тощо) використовують shortcodes Hugo.

Включення

Щоб додати короткі коди до включень.

Вбудоване середовище Katacoda