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

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

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

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

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

• containerd
• CRI-O
• Docker Engine
• Mirantis Container Runtime

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

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

Стандартно ядро 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
• systemd

Драйвер 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

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

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

• containerd
• CRI-O

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

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

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

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

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

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

containerd

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

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

• Linux
• Windows

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

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

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

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

 SystemdCgroup = true

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

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

sudo systemctl restart containerd

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

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

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

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

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

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

Зверніть увагу, що це найкраща практика для kubelet оголошувати відповідний pod-infra-container-image. Якщо це не налаштовано, kubelet може намагатися прибрати образ pause. Триває робота над закріпленням образу pause в containerd, щоб більше не вимагати цього налаштування в kubelet.

CRI-O

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

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

Драйвер cgroup

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

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

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

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

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

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

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

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

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

Docker Engine

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

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

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

Mirantis Container Runtime

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

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

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

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

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

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

Що далі

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