Інформація в цьому документі може бути застарілою
Дата оновлення цього документа старіша за оригінал, можливо інформація в ньому застаріла. Радимо ознайомитись з оригіналом англійською для отримання найсвіжіших відомостей: Container Runtimes
Щоб 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:
# параметри 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
У Linux контрольні групи використовуються для обмеження ресурсів, які виділяються процесам.
І kubelet, і середовище виконання контейнерів, що працює під ним, мають взаємодіяти з контрольними групами, щоб забезпечувати керування ресурсами Podʼів та контейнерів і встановлювати такі ресурси, як запити та обмеження CPU/памʼяті. Щоб взаємодіяти з контрольними групами, kubelet і середовище виконання контейнерів мають використовувати драйвер cgroup. Дуже важливо, щоб kubelet і середовище виконання контейнерів використовували той самий драйвер cgroup і були налаштовані однаково.
Доступні два драйвери cgroup:
Драйвер cgroupfs — це стандартний драйвер cgroup у kubelet. Коли використовується драйвер cgroupfs, kubelet і середовище виконання контейнерів безпосередньо взаємодіють із файловою системою cgroup, щоб налаштовувати cgroups.
Драйвер cgroupfs не рекомендовано, коли systemd є системою ініціалізації, оскільки systemd очікує, що в системі буде єдиний менеджер cgroup. Крім того, якщо ви використовуєте cgroup v2, використовуйте драйвер cgroup systemd замість cgroupfs.
Коли 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 може не усунути цих помилок.
Якщо ваша автоматизація це дозволяє, замініть вузол іншим з оновленою конфігурацією або перевстановіть його за допомогою автоматизації.
Ваше середовище виконання контейнерів має підтримувати v1 інтерфейсу середовища виконання контейнерів (CRI).
Kubernetes починаючи з v1.26 працює тільки з v1 CRI API. Якщо середовище виконання контейнерів не підтримує v1 API, kubelet не зареєструється як вузол.
У цьому розділі описано кроки, потрібні для використання 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.
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.
У вашій конфігурації 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 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.
У вашій конфігурації CRI-O можна задати таке значення конфігурації:
[crio.image]
pause_image="registry.k8s.io/pause:3.10"
Цей параметр конфігурації підтримує перезавантаження конфігурації наживо (live reload), щоб застосувати цю зміну: systemctl reload crio або надсилання сигналу SIGHUP процесу crio.
cri-dockerd для інтеграції Docker Engine з Kubernetes.На кожному з ваших вузлів встановіть Docker для вашого дистрибутиву Linux згідно з Встановлення Docker Engine.
Встановіть cri-dockerd, дотримуючись вказівок у розділі встановлення документації.
Для cri-dockerd стандартний сокет CRI — /run/cri-dockerd.sock.
Mirantis Container Runtime (MCR) — це комерційне середовище виконання контейнерів, яке раніше було відоме як Docker Enterprise Edition.
Ви можете використовувати Mirantis Container Runtime з Kubernetes за допомогою компонента з відкритим кодом cri-dockerd, який входить до складу MCR.
Докладніше про встановлення Mirantis Container Runtime див. посібник з розгортання MCR.
Перевірте юніт systemd із назвою cri-docker.socket, щоб дізнатися шлях до сокета CRI.
Адаптер cri-dockerd приймає аргумент командного рядка, який визначає, який образ контейнера використовувати як інфраструктурний контейнер Podʼа («pause image»). Цей аргумент командного рядка — --pod-infra-container-image.
Крім середовища виконання контейнерів, вашому кластеру потрібен робочий мережевий втулок.
Елементи на цій сторінці відносяться до сторонніх продуктів чи проєктів, які надають функціонал, необхідний для Kubernetes. Автори проєкту Kubernetes не несуть відповідальності за ці проєкти. Ознайомтесь з настановами на вебсайті CNCF для отримання докладної інформації.
Ознайомтесь з посібником з контенту перед тим, як пропонувати додавання посилання на стороні компоненти.