1 - Навчальне оточення
Якщо ви вивчаєте Kubernetes, вам потрібно місце для практики. На цій сторінці описано варіанти налаштування оточення Kubernetes, де ви зможете експериментувати та навчатися.
Встановлення kubectl
Перш ніж налаштовувати кластер, вам знадобиться інструмент командного рядка kubectl. Цей інструмент дозволяє вам взаємодіяти з кластером Kubernetes і виконувати команди в ньому.
Інструкції з встановлення див. у розділі Встановлення та налаштування kubectl.
Налаштування локальних оточень Kubernetes
Локальний запуск Kubernetes надає вам безпечне оточення для навчання та експериментів. Ви можете створювати та знищувати кластери, не турбуючись про витрати чи вплив на промислові системи.
kind
kind (Kubernetes IN Docker) запускає кластери Kubernetes, використовуючи контейнери Docker як вузли. Він є легким і розроблений спеціально для тестування самого Kubernetes, але також чудово підходить для навчання.
Щоб розпочати роботу з kind, див. kind Quick Start.
minikube
minikube запускає одновузловий кластер Kubernetes на вашому локальному компʼютері. Він підтримує кілька середовищ виконання контейнерів і працює на Linux, macOS та Windows.
Щоб розпочати роботу з minikube, ознайомтеся з посібником minikube Get Started.
Інші локальні варіанти
🛇 Цей елемент посилається на сторонній проєкт або продукт, який не є частиною Kubernetes.
ДокладнішеІснує кілька сторонніх інструментів, які також можуть запускати Kubernetes локально. Kubernetes не надає підтримку для цих інструментів, але вони можуть добре підійти для ваших навчальних потреб:
Інструкції з налаштування та підтримку дивіться в документації до кожного інструменту.
Використання онлайн-пісочниць
🛇 Цей елемент посилається на сторонній проєкт або продукт, який не є частиною Kubernetes.
ДокладнішеОнлайн-пісочниці Kubernetes дозволяють випробувати Kubernetes без встановлення будь-чого на ваш компʼютер. Ці оточення працюють у вашому вебоглядачі:
- Killercoda надає інтерактивні сценарії Kubernetes та оточення-пісочницю
Ці платформи корисні для швидких експериментів та виконання навчальних посібників без локального встановлення.
Вправи з кластерами, подібними до промислових
Якщо ви хочете попрактикуватися в налаштуванні кластера, більш подібного до промислового, ви можете скористатися kubeadm. Налаштування кластера за допомогою kubeadm — це складне завдання, яке вимагає наявності декількох машин (фізичних або віртуальних) та ретельного конфігурування.
Щоб дізнатися більше про промислові оточення, див. Промислове оточення.
Примітка:
Налаштування кластера, подібного до промислового, значно складніше, ніж налаштування навчальних оточень, описаних вище. Почніть спочатку з kind, minikube або онлайн-пісочниці.
Що далі
2 - Промислове оточення
Створіть кластер Kubernetes промислової якості
Кластер 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: Налаштуйте балансувальник навантаження для розподілу зовнішніх запитів API між екземплярами служби apiserver, що працюють на різних вузлах. Докладніше дивіться Створення зовнішнього балансувальника навантаження.
- Відокремте службу etcd та робіть її резервні копії: Служби 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). Незалежно від того, чи керуєте ви власною панеллю управління, чи хмарний провайдер робить це за вас, вам все одно потрібно подумати, як ви хочете керувати своїми робочими вузлами (їх також називають просто вузлами).
- Налаштуйте вузли: Вузли можуть бути фізичними або віртуальними машинами. Якщо ви хочете створювати власні вузли та керувати ними, ви можете встановити підтримувану операційну систему, а потім додати та запустити відповідні служби вузла. Розгляньте такі питання:
- Вимоги ваших робочих навантажень під час налаштування вузлів: наявність відповідного обсягу памʼяті, CPU, швидкості дисків та ємності сховища.
- Чи підійдуть звичайні компʼютерні системи, чи у вас є робочі навантаження, які потребують процесорів GPU, вузлів Windows або ізоляції віртуальних машин.
- Перевірте вузли: Дивіться Правильне налаштування вузла для інформації про те, як переконатися, що вузол відповідає вимогам для приєднання до кластера Kubernetes.
- Додайте вузли до кластера: Якщо ви керуєте своїм власним кластером, ви можете додавати вузли, налаштовуючи свої власні машини та додаючи їх вручну або налаштувавши їх на самостійну реєстрацію в apiserver кластера. Дивіться розділ Вузли для інформації щодо того, як налаштувати Kubernetes для додавання вузлів цими способами.
- Масштабуйте вузли: Майте план розширення ємності, яка зрештою знадобиться вашому кластеру. Дивіться Міркування щодо великих кластерів, щоб визначити, скільки вузлів вам потрібно, виходячи з кількості Podʼів і контейнерів, які вам потрібно запустити. Якщо ви керуєте вузлами самостійно, це може означати придбання та встановлення власного фізичного обладнання.
- Автомасштабуйте вузли: Ознайомтесь з Автомасштабуванням вузлів, щоб дізнатись про інструменти, доступні для автоматизованого керування вашими вузлами та ємністю, яку вони надають.
- Налаштуйте перевірки справності вузлів: Для важливих робочих навантажень потрібно переконатися, що вузли та 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-config або прапорця --authorization-mode. Наприклад, цей прапорець у файлі kube-adminserver.yaml (в /etc/kubernetes/manifests) може бути встановлений у значення Node,RBAC. Це дозволить авторизацію Node та RBAC для автентифікованих запитів.
- Створіть сертифікати користувачів та привʼязки ролей (RBAC): Якщо ви використовуєте авторизацію RBAC, користувачі можуть створювати CertificateSigningRequest (CSR), які можуть бути підписані CA кластера. Потім ви можете привʼязувати Roles та ClusterRoles до кожного користувача. Дивіться Запити на підпис сертифікатів для отримання деталей.
- Створіть політики, що комбінують атрибути (ABAC): Якщо ви використовуєте авторизацію ABAC, ви можете призначати комбінації атрибутів для формування політик для авторизації обраних користувачів або груп для доступу до певних ресурсів (наприклад, Pod), просторів імен або apiGroup. Докладніше дивіться Приклади.
- Зверніть увагу на контролери допуску: Додаткові форми авторизації для запитів, які можуть надходити через API-сервер, включають автентифікацію токенів за допомогою вебхуків. Вебхуки та інші спеціальні типи авторизації потрібно увімкнути, додавши контролери допуску до API-сервера.
Встановлення обмежень на ресурси робочих навантажень
Вимоги від промислових робочих навантажень можуть створювати тиск як всередині, так і поза панеллю управління Kubernetes. Розгляньте ці пункти під час налаштування відповідно до потреб робочих навантажень вашого кластера:
- Встановіть обмеження простору імен: Встановіть квоти для кожного простору імен на такі речі, як памʼять та CPU. Дивіться Керування ресурсами памʼяті, CPU та API для отримання деталей.
- Підготуйтесь до навантаження на DNS: Якщо ви очікуєте, що робочі навантаження значно масштабуватимуться, ваша служба DNS повинна бути готовою також масштабуватися. Дивіться Автоматичне масштабування служби DNS в кластері.
- Створюйте додаткові службові облікові записи: Облікові записи користувачів визначають, що користувачі можуть робити в кластері, тоді як службовий обліковий запис визначає доступ Podʼів у межах певного простору імен. Типово Pod отримує типовий службовий обліковий запис зі свого простору імен. Дивіться Управління службовими обліковими записами для інформації про створення нового службового облікового запису. Наприклад, ви можете:
Що далі
2.1 - Середовища виконання контейнерів
Щоб Podʼи могли працювати на кожному вузлі кластера, на нього потрібно встановити середовище виконання контейнерів. На цій сторінці описано, що для цього потрібно, і повʼязані завдання з налаштування вузлів.
Kubernetes 1.37 вимагає використання середовища виконання, яке відповідає Container Runtime Interface (CRI).
Докладніше див. Підтримка версій CRI.
Ця сторінка містить огляд того, як використовувати кілька поширених середовищ виконання контейнерів з Kubernetes.
Примітка:
Релізи Kubernetes до v1.24 містили пряму інтеграцію з Docker Engine за допомогою компонента dockershim. Ця спеціальна пряма інтеграція більше не є частиною Kubernetes (про її вилучення було оголошено у випуску v1.20). Прочитайте Перевірка впливу видалення dockershim на ваш кластер, щоб зрозуміти, як це вилучення може вплинути на вас. Про міграцію з dockershim див. Міграція з dockershim.
Якщо ви використовуєте версію Kubernetes, відмінну від v1.37, перегляньте документацію для цієї версії.
Конфігурація мережі
Стандартно ядро 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 контрольні групи використовуються для обмеження ресурсів, які виділяються процесам.
І kubelet, і середовище виконання контейнерів, що працює під ним, мають взаємодіяти з контрольними групами, щоб забезпечувати керування ресурсами Podʼів та контейнерів і встановлювати такі ресурси, як запити та обмеження CPU/памʼяті. Щоб взаємодіяти з контрольними групами, kubelet і середовище виконання контейнерів мають використовувати драйвер cgroup. Дуже важливо, щоб kubelet і середовище виконання контейнерів використовували той самий драйвер cgroup і були налаштовані однаково.
Доступні два драйвери cgroup:
Драйвер cgroupfs
Драйвер cgroupfs — це стандартний драйвер cgroup у kubelet. Коли використовується драйвер cgroupfs, kubelet і середовище виконання контейнерів безпосередньо взаємодіють із файловою системою cgroup, щоб налаштовувати cgroups.
Драйвер cgroupfs не рекомендовано, коли systemd є системою ініціалізації, оскільки systemd очікує, що в системі буде єдиний менеджер cgroup. Крім того, якщо ви використовуєте cgroup v2, використовуйте драйвер cgroup systemd замість cgroupfs.
Драйвер cgroup systemd
Коли systemd вибрано системою ініціалізації для дистрибутиву Linux, процес ініціалізації створює й використовує кореневу контрольну групу (cgroup) і діє як менеджер cgroup.
systemd тісно інтегрований із cgroups і виділяє по одній cgroup на кожен юніт systemd. Тому, якщо ви використовуєте systemd як систему ініціалізації з драйвером cgroupfs, у системі зʼявляються два різні менеджери cgroup.
Два менеджери cgroup дають два різні уявлення про доступні та використовувані ресурси в системі. У деяких випадках вузли, на яких kubelet і середовище виконання контейнерів налаштовані на cgroupfs, а решта процесів використовує systemd, стають нестабільними під тиском на ресурси.
Щоб усунути цю нестабільність, використовуйте systemd як драйвер cgroup для kubelet і середовища виконання контейнерів, коли системою ініціалізації вибрано systemd.
Щоб встановити systemd як драйвер cgroup, змініть параметр cgroupDriver у KubeletConfiguration і встановіть його в systemd. Наприклад:
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
...
cgroupDriver: systemd
Якщо ви налаштовуєте systemd як драйвер cgroup для kubelet, ви також маєте налаштувати systemd як драйвер cgroup для середовища виконання контейнерів. Інструкції див. у документації вашого середовища виконання контейнерів. Наприклад:
У Kubernetes 1.37, якщо ввімкнено функціональну можливість KubeletCgroupDriverFromCRI і середовище виконання контейнерів підтримує CRI RPC RuntimeConfig, kubelet автоматично визначає відповідний драйвер cgroup із середовища виконання та ігнорує налаштування cgroupDriver у конфігурації kubelet.
Однак старіші версії середовищ виконання контейнерів (зокрема containerd 1.y і старіші) не підтримують CRI RPC RuntimeConfig і можуть некоректно відповідати на цей запит, тому kubelet повертається до використання значення свого прапорця --cgroup-driver.
У Kubernetes 1.38 цю резервну поведінку буде вилучено, і старіші версії containerd не працюватимуть із новішими kubelet.
Увага:
Зміна драйвера cgroup вузла, який уже приєднався до кластера, — делікатна операція. Якщо kubelet створював Podʼи, використовуючи семантику одного драйвера cgroup, перемикання середовища виконання контейнерів на інший драйвер cgroup може спричинити помилки під час спроби повторно створити пісочницю Podʼа для таких наявних Podʼів. Перезапуск kubelet може не усунути цих помилок.
Якщо ваша автоматизація це дозволяє, замініть вузол іншим з оновленою конфігурацією або перевстановіть його за допомогою автоматизації.
Підтримка версій CRI
Ваше середовище виконання контейнерів має підтримувати v1 інтерфейсу середовища виконання контейнерів (CRI).
Kubernetes починаючи з v1.26 працює тільки з v1 CRI API. Якщо середовище виконання контейнерів не підтримує v1 API, kubelet не зареєструється як вузол.
Середовища виконання контейнерів
Примітка: Цей розділ містить посилання на проєкти сторонніх розробників, які надають функціонал, необхідний для Kubernetes. Автори проєкту Kubernetes не несуть відповідальності за ці проєкти. Проєкти вказано в алфавітному порядку. Щоб додати проєкт до цього списку, ознайомтеся з
посібником з контенту перед надсиланням змін.
Докладніше.
containerd
У цьому розділі описано кроки, потрібні для використання containerd як середовища виконання CRI.
Щоб встановити containerd у вашій системі, дотримуйтеся інструкцій із початку роботи з containerd. Поверніться до цього кроку, коли створите коректний файл конфігурації config.toml.
Ви можете знайти цей файл тут: /etc/containerd/config.toml.
Ви можете знайти цей файл тут: C:\Program Files\containerd\config.toml.
У Linux стандартний сокет CRI для containerd — /run/containerd/containerd.sock. У Windows стандартна точка доступу CRI — npipe://./pipe/containerd-containerd.
Налаштування драйвера cgroup systemd
Щоб використовувати драйвер cgroup systemd у /etc/containerd/config.toml з runc, встановіть таку конфігурацію залежно від версії Containerd.
Containerd версії 1.x:
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
...
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
SystemdCgroup = true
Containerd версії 2.x:
[plugins.'io.containerd.cri.v1.runtime'.containerd.runtimes.runc]
...
[plugins.'io.containerd.cri.v1.runtime'.containerd.runtimes.runc.options]
SystemdCgroup = true
Драйвер cgroup systemd рекомендовано, якщо ви використовуєте cgroup v2.
Примітка:
Якщо ви встановили containerd з пакунка (наприклад, RPM або .deb), може виявитися, що втулок інтеграції CRI стандартно вимкнено.
Щоб використовувати containerd з Kubernetes, потрібно ввімкнути підтримку CRI. Переконайтеся, що cri немає у списку disabled_plugins у /etc/containerd/config.toml; якщо ви вносили зміни до цього файлу, також перезапустіть containerd.
Якщо після початкового встановлення кластера або після встановлення CNI контейнери циклічно аварійно завершуються (crash loop), конфігурація containerd, що постачається з пакунком, може містити несумісні параметри. Спробуйте скинути конфігурацію containerd командою containerd config default > /etc/containerd/config.toml, як зазначено в getting-started.md, а потім відповідно встановіть параметри конфігурації, наведені вище.
Якщо ви застосували цю зміну, обовʼязково перезапустіть containerd:
sudo systemctl restart containerd
У Kubernetes v1.28 можна ввімкнути автоматичне виявлення драйвера cgroup як альфа-можливість. Докладніше див. драйвер cgroup systemd.
Перевизначення образу пісочниці (pause)
У вашій конфігурації containerd можна перевизначити образ пісочниці, задавши такий параметр конфігурації:
[plugins."io.containerd.grpc.v1.cri"]
sandbox_image = "registry.k8s.io/pause:3.10"
Після оновлення файлу конфігурації вам, можливо, також доведеться перезапустити containerd: systemctl restart containerd.
CRI-O
У цьому розділі наведено необхідні кроки для встановлення CRI-O як середовища виконання контейнерів.
Щоб встановити CRI-O, дотримуйтеся інструкцій із встановлення CRI-O.
Драйвер cgroup
CRI-O стандартно використовує драйвер cgroup systemd, який, імовірно, добре вам підійде. Щоб перейти на драйвер cgroup cgroupfs, відредагуйте /etc/crio/crio.conf або розмістіть додатковий файл конфігурації (drop-in) у /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.10"
Цей параметр конфігурації підтримує перезавантаження конфігурації наживо (live reload), щоб застосувати цю зміну: systemctl reload crio або надсилання сигналу SIGHUP процесу crio.
Docker Engine
Примітка:
Ці інструкції передбачають, що ви використовуєте адаптер
cri-dockerd для інтеграції Docker Engine з Kubernetes.
-
На кожному з ваших вузлів встановіть Docker для вашого дистрибутиву Linux згідно з Встановлення Docker Engine.
-
Встановіть 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.
Що далі
Крім середовища виконання контейнерів, вашому кластеру потрібен робочий мережевий втулок.