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

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

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

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

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

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

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

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

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

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

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

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

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

Що далі

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

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

  • Docker Desktop може запускати локальний кластер Kubernetes
  • Podman Desktop може запускати локальний кластер Kubernetes
  • Rancher Desktop надає Kubernetes на вашому робочому столі
  • MicroK8s запускає легкий кластер Kubernetes
  • Red Hat CodeReady Containers (CRC) запускає мінімальний кластер OpenShift локально (OpenShift є сумісним з Kubernetes)

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

Використання онлайн-майданчиків

🛇 Цей елемент посилається на сторонній проєкт або продукт, який не є частиною Kubernetes. Докладніше

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

  • Killercoda надає інтерактивні сценарії Kubernetes та ігрове середовище

Ці платформи корисні для швидких експериментів та виконання навчальних посібників без локального встановлення.

Вправи з кластерами, подібними до промислових

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

Щоб дізнатися більше про промислові середовища, див. Промислове середовище.

Примітка:

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

Що далі

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-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, включають Автентифікацію токенів за допомогою вебхуків. Вебхуки та інші спеціальні типи авторизації повинні бути увімкнені додаванням Контролерів допуску (Admission Controllers) до сервера API.

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

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

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

Що далі

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

Примітка: Dockershim було вилучено з проєкту Kubernetes починаючи з випуску 1.24. Ознайомтесь з Питання та відповіді щодо вилучення Dockershim для отримання додаткових відомостей.

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

Kubernetes 1.37 вимагає використання runtime, який відповідає специфікації 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 використовуються 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.37, з увімкненою функціональною можливістю KubeletCgroupDriverFromCRI і середовищем виконання контейнерів, яке підтримує RuntimeConfig CRI RPC, kubelet автоматично визначає відповідний драйвер cgroup з runtime, та ігнорує налаштування cgroupDriver у конфігурації kubelet.

Однак, старі версії середовищ виконання контейнерів (зокрема, containerd 1.y і нижче) не підтримують RuntimeConfig CRI RPC і можуть не реагувати правильно на цей запит, тому Kubelet повертається до використання значення у своєму власному прапорці --cgroup-driver.

У Kubernetes 1.38 ця поведінка відкату буде відкинута, і старі версії containerd зазнають невдачі з новими kubelet.

Увага:

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

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

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

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

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-socket для 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 є типово вимкненим.

Вам потрібно увімкнути підтримку CRI для того, щоб мати можливість використовувати containerd в Kubernetes. Переконайтеся, що cri немає в disabled_plugins у файлі /etc/containerd/config.toml; якщо вносили зміни до цього файлу, перезапустіть containerd.

Якщо ви стикаєтесь з постійними збоями після початкового встановлення кластера або після встановлення CNI, скоріш за все конфігурація containerd отримана з пакунка містить несумісні налаштування. Зважте на перевстановлення налаштувань containerd, командою containerd config default > /etc/containerd/config.toml (див. getting-started.md) і потім внесіть зміни в налаштування, як вказано вище.

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

sudo systemctl restart containerd

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

Перевизначення образу пісочниці (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, який ймовірно буде працювати добре для вас. Для перемикання на драйвер 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.10"

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

Docker Engine

Примітка:

Ці інструкції передбачають, що ви використовуєте адаптер cri-dockerd для інтеграції Docker Engine з Kubernetes.

  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 - Встановлення Kubernetes за допомогою інструментів розгортання

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

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

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

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

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

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

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

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

Примітка:

Встановлення за допомогою kubeadm виконується за допомогою бінарних файлів, які використовують динамічне звʼязування та передбачають, що ваша цільова система надає бібліотеку glibc. Це припущення стосується багатьох дистрибутивів Linux (включаючи Debian, Ubuntu, Fedora, CentOS і т. д.), але не завжди відповідає дійсності у випадку власних та легких дистрибутивів, які типово не включають glibc, наприклад, Alpine Linux. Очікується, що дистрибутив включає або шар сумісності, який забезпечує необхідні символи, або glibc.

Перевірте версію вашої операційної системи

Примітка: Цей розділ містить посилання на проєкти сторонніх розробників, які надають функціонал, необхідний для Kubernetes. Автори проєкту Kubernetes не несуть відповідальності за ці проєкти. Проєкти вказано в алфавітному порядку. Щоб додати проєкт до цього списку, ознайомтеся з посібником з контенту перед надсиланням змін. Докладніше.
  • Проєкт kubeadm підтримує ядра LTS. Дивіться Список ядер LTS.
  • Ви можете отримати версію ядра за допомогою команди uname -r.

Докладнішу інформацію наведено у Вимоги до ядра Linux.

  • Проєкт kubeadm підтримує останні версії ядра. Список останніх версій ядра наведено у Windows Server Release Information.
  • Ви можете отримати версію ядра (яку також називають версією ОС) за допомогою команди systeminfo.

Докладнішу інформацію наведено у статті Сумісність версій ОС Windows.

Кластер Kubernetes, створений за допомогою kubeadm, залежить від програмного забезпечення, яке використовує можливості ядра. Це програмне забезпечення включає, але не обмежується container runtime, kubelet та втулком Container Network Interface.

Щоб допомогти вам уникнути несподіваних помилок, спричинених використанням непідтримуваної версії ядра, kubeadm виконує попередню перевірку SystemVerification. Ця перевірка не спрацює, якщо версія ядра не підтримується.

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

Перевірка унікальності 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 -zv -w 2

Мережевий втулок 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 повідомить про помилку та запросить вас вказати, яке середовище ви хочете використовувати.

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

Примітка:

Рушій Docker не має реалізації CRI, що є вимогою для роботи контейнерного середовища в Kubernetes. З цього приводу слід встановити додатковий сервіс cri-dockerd. cri-dockerd — це проєкт, побудований на основі колишньої вбудованої підтримки Docker Engine, яка була вилучена з kubelet у версії 1.24.

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

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

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

Примітка: Сховища застарілих пакунків (apt.kubernetes.io та yum.kubernetes.io) визнані застарілими та заморожені станом на 13 вересня 2023. Наполегливо рекомендується використання нових репозиторіїв пакунків, розміщених за адресою pkgs.k8s.io, які є обовʼязковими для встановлення версій Kubernetes, випущених після 13 вересня 2023 року. Застарілі репозиторії та їх вміст можуть бути видалені у будь-який момент у майбутньому без попереднього повідомлення. Нові репозиторії пакунків надають можливість завантаження версій Kubernetes, починаючи з v1.24.0.

Примітка:

Є окремий репозиторій пакунків для кожної мінорної версії Kubernetes. Якщо ви хочете встановити іншу мінорну версію, крім v1.37, див. посібник з встановлення для бажаної мінорної версії.

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

  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.37/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg

Примітка:

У випусках старших за Debian 12 та Ubuntu 22.04 теки /etc/apt/keyrings типово не існує, її слід створити до команди curl.

  1. Додайте відповідний репозиторій Kubernetes apt. Зверніть увагу, що цей репозиторій містить пакунки лише для Kubernetes 1.37; для інших мінорних версій 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.37/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. (Опціонально) Увімкніть kubelet перед запуском kubeadm:

    sudo systemctl enable --now kubelet

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

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

    # Встановити SELinux у режим `permissive` (фактично відключити його)
sudo setenforce 0
sudo sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config

    Увага:

  2. Встановлення SELinux у режим permissive за допомогою виконання setenforce 0 та sed ... фактично його вимикає. Це необхідно для того, щоб дозволити контейнерам отримувати доступ до файлової системи хосту, наприклад, деякі мережеві застосунки кластера вимагають цього. Ви повинні зробити це до тих пір, поки підтримка SELinux не буде покращена в kubelet.
  3. Ви можете залишити увімкненим SELinux, якщо ви знаєте, як його налаштувати, але це може вимагати налаштувань, які не підтримуються kubeadm.

    1. Додайте репозиторій Kubernetes yum. Параметр exclude в визначенні репозиторію забезпечує, що пакунки, повʼязані з Kubernetes, не оновлюються при виконанні звичайного dnf update, оскільки є спеціальна процедура, якої слід дотримуватися для оновлення Kubernetes. Зверніть увагу, що цей репозиторій має пакунки лише для Kubernetes v1.37; для інших мінорних версій 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.37/rpm/
   enabled=1
   gpgcheck=1
   gpgkey=https://pkgs.k8s.io/core:/stable:/v1.37/rpm/repodata/repomd.xml.key
   exclude=kubelet kubeadm kubectl cri-tools kubernetes-cni
   EOF

    2. Встановіть kubelet, kubeadm та kubectl:

      Для систем з DNF4 (Fedora < 41, RHEL/CentOS < 10):

      sudo dnf install -y kubelet kubeadm kubectl --disableexcludes=kubernetes

      Для систем Fedora з DNF5:

      sudo dnf install -y kubelet kubeadm kubectl --setopt=disable_excludes=kubernetes

      Для RHEL/CentOS 10 та пізніших версій, щоб уникнути завантаження iptables як залежності:

      sudo dnf install -y kubelet kubeadm kubectl --setopt=disable_excludes=kubernetes --setopt=install_weak_deps=False

    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 повинна бути встановлена на теку з правами на запис. Якщо ви використовуєте Flatcar Container Linux, встановіть DOWNLOAD_DIR="/opt/bin".
    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

    Примітка:

    Зверніться до приміток в розділі Перш ніж ви розпочнете для дистрибутивів Linux, які типово не містять glibc.

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

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

    sudo systemctl enable --now kubelet

    Примітка:

    Дистрибутив Flatcar Container Linux монтує теку /usr як файлову систему тільки для читання. Перед ініціалізацією кластера вам потрібно виконати додаткові кроки для налаштування теки для запису. Див. Посібник з усунення несправностей kubeadm, щоб дізнатися, як налаштувати теку для запису.

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

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

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

    Що далі