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

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

Прод оточення

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

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

Щоб 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.

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

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