40 KiB
Kubernetes на Orange Pi 5 Plus под управлением Ubuntu 20.04 (на других Orange Pi, Raspberry Pi и других SBC тоже должно работать)
Подготовка
Установим DBus и Avahi (не обязательно)
DBus — система межпроцессного взаимодействия, которая позволяет различным приложениям и службам в системе общаться друг с другом. DBus часто используется для управления службами, взаимодействия с системными демонами и упрощения интеграции приложений.
Avahi — это демон и утилиты для работы с mDNS/DNS-SD (Bonjour) и реализация протокола Zeroconf. Avahi тесно интегрирован с D-Bus и используется для обнаружения устройств и сервисов в локальной сети и предоставляет автоматическое обнаружение устройств и сервисов в локальной сети. Например, Avahi используется для обнаружения сетевых принтеров, файловых серверов и других ресурсов без необходимости ручной настройки. Нам avahi понадобится для обнаружения хостов кластера в локальной сети.
sudo apt update
sudo apt install dbus avahi-daemon avahi-utils
Запускаем эти сервисы:
sudo systemctl start dbus
sudo systemctl start avahi-daemon
А также включаем автозапуск при загрузке:
sudo systemctl enable dbus
sudo systemctl enable avahi-daemon
Возможные проблемы с DBus
При проверке статуса dbus sudo systemctl status dbus
, случается, выскакивают предупреждения, типа:
Xxx xx xx:xx:xx _xxx-hostname-xxx_ dbus-daemon[909]: Unknown username "whoopsie" in message bus configuration file
Это связано с тем, что в конфигурационном файле DBus указаны несуществующий пользователь whoopsie. Это системный пользователь, используемый сервисом Whoopsie, отвечающий за отправку отчётов об ошибках на серверы разработчиков (Canonical) в системах Ubuntu. Если whoopsie или его конфигурация установлены, но пользователь отсутствует, возникают такие предупреждения.
Я не возражаю против отправки отчётов об ошибках, тем более, что сервис whoopsie у меня не запущен. :) Так что просто добавлю пользователя whoopsie в систему:
sudo adduser --system --no-create-home --disabled-login whoopsie
Но если внутренний параноик вам шепчет, что это не безопасно, то нужно найти в каких конфигурационных файлах DBus встречается whoopsie grep -r "whoopsie" /etc/dbus-1/
и закомментировать или удалить соответствующие строки.
Также, порадовать своего внутреннего параноика, можно отключить отправку отчётов об ошибках в Ubuntu:
sudo systemctl stop whoopsie
sudo apt-get remove --purge whoopsie
После всех упражнений (добавления пользователя whoopsie или, наоборот истребления его, и отключения сервиса whoopsie) перезагрузим D-Bus:
sudo systemctl restart dbus
Теперь проверкак статуса dbus:
sudo systemctl status dbus
Не должна выдавать предупреждений:
dbus.service - D-Bus System Message Bus
Loaded: loaded (/lib/systemd/system/dbus.service; static)
Active: active (running) since Sat XXXX-XX-XX XX:XX:XX MSK; 1min ago
TriggeredBy: ● dbus.socket
Docs: man:dbus-daemon(1)
Main PID: 8437 (dbus-daemon)
Tasks: 1 (limit: 18675)
Memory: 616.0K
CPU: 112ms
CGroup: /system.slice/dbus.service
└─8437 @dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
XXX XX XX:XX:XX _xxx-hostname-xxx_ systemd[1]: Started D-Bus System Message Bus.
Возможные проблемы с Avahi
При проверке статуса avahi sudo systemctl status avahi-daemon
, случается, выскакивают предупреждения, типа:
Xxx xx xx:xx:xx _xxx-hostname-xxx_ avahi-daemon[2079]: Failed to parse address 'fe80::1%xxxxxxxx', ignoring.
Я не понял как это исправить и почему локальная петля (loopback) для iv6 fe80::1
— проблема. Отключение
обслуживания IPv6 для avahi в конфиге /etc/avahi/avahi-daemon.conf
не помогло. Ставил в нем use-ipv6=no
,
но предупреждения продолжались. Но, вроде, это не критично, но...
СООБЩАЙТЕ, ЕСЛИ ЗНАЕТЕ КАК ЭТО ИСПРАВИТЬ! |
Пока я нашел следующее решение (по карйне мере у меня сработало, и сработало только если его проделать после всех
предыдущих пунктов по установке avahi-daemon
вручную). Порядок действий напоминает шаманство:
Запускаем конфигуратор Orange Pi:
sudo orangepi-config
Панель orangepi-config на Orange Pi 5 выглядит так:
Выбираем пункт 'System: System and security settings' и заходим в панель 'System Settings'. Выбираем в ней пункт 'Avahi: Announce system in the network':
Сервис устанавливается.
Возможно, на панели 'System Setting' вместо пункта 'Avahi: Announce system in the network' будет пункт 'Avahi: Disable system announcement in the network':
Всё равно выбираем его: сначала отключаем avahi-демон; после возвращаемся в 'System Settings'; повторно выбираем пункт 'Avahi: Announce system in the network' и устанавливаем avahi-демон заново через 'Avahi: Announce system in the network'... Всё как у настоящих системщиков — надо "выйти и зайти".
Покидаем orangepi-config (Back и затем Exit) и перезагружаем Orange Pi:
sudo reboot
После перезагрузки предупреждения о проблемах loopback для iv6 (fe80::1
) в avahi должны исчезнуть.
sudo service avahi-daemon status
Все чисто. Магия!
Настройка сети
hostname
Настроить имя хоста (hostname) можно командой hostnamectl
. Например, для узла opi5plus-1
:
sudo hostnamectl set-hostname opi5plus-1
Или просто отредактировать файл /etc/hostname
:
sudo nano /etc/hostname
И внесем в него имя узла (на самом деле заменим, т.к. в файле уже прописано имя хоста). Например, opi5plus-1
,
opi5plus-2
и так далее. Сохраняем и закрываем файл.
Изменения вступят в силу после перезагрузки узла. Но чтобы не перезагружать узел, можно применить изменения в /etc/hostname
сразу:
sudo service systemd-hostnamed restart
Кстати, чтобы временно изменить hostname, можно использовать команду hostname
. Например для узла opi5plus-1
:
sudo hostname opi5plus-1
Что бы узнать текущее имя хоста, можно использовать команду hostname
:
hostname
ip
Можно настроить статический IP-адрес для каждого узла кластера (об этом будет отдельная заметка). Но можно и оставить и автоматическое получение IP-адреса от DHCP-сервера. Для этого надо на зарезервировать IP-адреса для каждого узла кластера в DHCP-сервере. Резервирование IP-адресов в DHCP-сервере обычно делается по MAC-адресу устройства.
Чтобы узнать MAC- и IP-адреса Orange Pi. На Ubuntu это можно сделать, например, с помощью команды ifconfig
.
Увидим что-то вроде этого:
...
...
enP4p65s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.110 netmask 255.255.255.0 broadcast 192.168.1.255
inet6 fe80::1e2f:65ff:fe49:3ab0 prefixlen 64 scopeid 0x20<link>
ether 1c:2f:65:49:3a:b0 txqueuelen 1000 (Ethernet)
RX packets 656166 bytes 157816045 (157.8 MB)
RX errors 0 dropped 12472 overruns 0 frame 0
TX packets 44578 bytes 4805687 (4.8 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
...
- MAC-адрес:
ether 1c:2f:65:49:3a:b0
- IP-адрес:
inet 192.168.1.110
И кстати, на Orange Pi 5 Plus есть два сетевых интерфейса: enP4p65s0
и enP3p49s0
(и, если установлен
WiFi-адаптер PCIe, ещё и третий). Так что стоит зарезервировать в DHCP адреса для всех интерфейсов.
DNS
На всякий случай, установим утилиты для работы с DNS (они обычно уже установлены в Ubuntu, но на всякий случай):
sudo apt install dnsutils
В случае с DHCP настройки DNS получены автоматически, при каждой перезагрузке узла конфигурационный файл
/etc/resolv.conf
будет перезаписываться. Но если у нас статический IP-адрес, то нам надо настроить /etc/resolv.conf
вручную. В нем указывается DNS-сервер, к которому обращается узел для преобразования доменных имен в IP-адреса,
а так же указывается домен, к которому принадлежит узел и который будет использоваться по умолчанию для преобразования
коротких доменных имен в полные.
sudo nano /etc/resolv.conf
В файле, обычно уже прописаны DNS-сервера. Нам остается только добавить доменное имя. Получим что-то типа вот такого:
# Generated by NetworkManager
nameserver 192.168.1.1
nameserver fe80::1%enP4p65s0
search local
Как видим мы добавили строку search local
, где local
— это доменное имя которое будет добавляться к коротким,
и таким образом hostname в нашем случае opi5plus-1
будет преобразовываться в opi5plus-1.local
. Сохраняем и
закрываем файл.
hosts
Что бы узлы кластера могли общаться между собой по именам, нам надо добавить их в файл /etc/hosts
. Откроем его:
sudo nano /etc/hosts
И добавим в него строки вида для каждого узла кластера. Например, для узлов opi5plus-1
:
127.0.0.1 localhost
127.0.1.1 opi5plus-1.local opi5plus-1
::1 localhost ip6-localhost ip6-loopback opi5plus-1.local opi5plus-1
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
# УЗЛЫ КЛАСТЕРА (не забудьте заменить ip-адреса и имена узлов)
192.168.1.XX1 opi5 opi5.local
192.168.1.XX2 opi5plus-1 opi5plus-1.local
192.168.1.XX3 opi5plus-2 opi5plus-2.local
192.168.1.XX4 opi5plus-3 opi5plus-3.local
192.168.1.XX5 rpi3b rpi3b.local
Перезагружаем сетевые настройки:
sudo service networking restart
Теперь узлы кластера могут общаться между собой по именам. Можно проверить, например, пингом:
ping opi5plus-3
SSH-авторизация по ключам
Для общения между узлами кластера по SSH без ввода пароля, нам надо настроить авторизацию по ключам. Выпустим по паре ключей (публичный и приватный) на каждом узле кластера. На каждом узле выполним команду:
ssh-keygen -t rsa
В процессе генерации ключей нам предложат указать место для сохранения ключей. По умолчанию они сохраняются в папке
~/.ssh/
(папка .ssh
в домашнем каталоге пользователя). Можно оставить по умолчанию, нажав Enter. Так же предложат
указать пароль для ключа. Нужно оставить пустым, нажав Enter. После генерации ключей, в папке ~/.ssh/
появятся два
файла: id_rsa
(приватный ключ) и id_rsa.pub
(публичный ключ).
Теперь надо обменяться публичными ключами между узлами кластера. Для этого на каждом узле кластера выполним команды,
например для узла opi5plus-1.local
(не забываем заменить [user]
на имя пользователя):
ssh-copy-id [user]@opi5plus-2.local
ssh-copy-id [user]@opi5plus-3.local
Таким образом, хост opi5plus-1.local
отправит свой публичный ключ на хосты opi5plus-2.local
и opi5plus-3.local
.
С другими узлами кластера поступим аналогично.
При обмене ключами сначала попросят ввести yes
для подтверждения подключения к хосту, и предотвращения MITM-атаки
(Man-In-The-Middle — человек посередине). После этого попросят ввести пароль пользователя на удаленном хосте. После
успешного ввода пароля, публичный ключ будет добавлен в файл ~/.ssh/authorized_keys
на удаленном хосте. Теперь можно
подключаться к удаленному хосту без ввода пароля.
Проверим, что авторизация по ключам работает. Подключимся к удаленному хосту (например к opi5plus-2.local
):
ssh [user]@opi5plus-2.local
Для отключения с удаленного хоста наберем команду logout
.
Еще немного подготовительных действий
Настойка времени
Для самого Kubernates не так важно, чтобы время на всех узлах было синхронизировано, но для баз данных, кэшей и других сервисов, работающих на узлах кластера, это может оказаться критичным. Поэтому настроим синхронизацию времени.
Посмотреть текущий часовой пояс можно командой:
timedatectl
Установим на всех узлах один и тот же часовой пояс. Например, для Москвы:
sudo timedatectl set-timezone Europe/Moscow
На Orange Pi 5 настройку часового пояса можно сделать и через sudo orangepi-config
(пункт 'System: Timezone').
Также установим NTP (Network Time Protocol) для синхронизации времени. Описание установки и настройки есть в другой заметке.
Следует отметить, что т.к. у Orange Pi 5 Plus есть встроенные часы реального времени (RTC), а NTP-клиент имеет
более высокие накладные расходы, по сравнению с SNTP (Simple Network Time Protocol). Для микрокомпьютеров можно
немного поднастроить NTP. В частности убрать дефолтный список серверов времени и добавить только ближайшие к нам.
Список NTP-серверов можно посмотреть на сайте ntppool.org. Например, для России список
пула в /etc/ntp.conf
будет такой (и добавим еще московский сервер...
и не забудьте убрать дефолтные):
pool 0.ru.pool.ntp.org minpoll 9 maxpoll 14
pool 1.ru.pool.ntp.org minpoll 9 maxpoll 14
pool 2.ru.pool.ntp.org minpoll 9 maxpoll 14
pool 3.ru.pool.ntp.org minpoll 9 maxpoll 14
server ntp.msk-ix.ru minpoll 8 maxpoll 12 prefer
Здесь:
pool
— Указывает пул серверов времени. Клиент автоматически выбирает серверы из указанного пула и может переключаться между ними для повышения надежности и отказоустойчивости.server
— указывает конкретный сервер времени для синхронизации. Если сервер недоступен, NTP-клиент будет пытаться подключиться к нему снова через некоторое время.minpoll
иmaxpoll
— это минимальный и максимальный интервалы обращения к серверу. Значения — это степени двойки. По умолчанию значения равны 6 (64 секунды) и 10 (~17 минут). Но для микрокомпьютеров можно установить побольше. У нас 9 (~8.5 минуты) и 14 (~4.5 часа). На самом деле обращения к серверам времени будут происходить в случайные интервалы времени (jitter), но в пределах указанных значений.prefer
-- это приоритетный сервер. Если у нас несколько серверов, то NTP-клиент будет обращаться к приоритетному.
Это позволит уменьшить нагрузку от NTP-клиента и снизить трафик.
Установка необходимых пакетов
В системе уже должны быть установлены пакеты apt-transport-https
(для работы с HTTPS-репозиториями) и curl
(для
передачи и получения данных с использованием различных протоколов), wget
(для загрузки файлов из интернета), gnupg
(для работы с GPG-ключами), sudo
(для выполнения команд от имени суперпользователя), iptables
(для настройки
фильтрации пакетов), tmux
(для работы с несколькими терминалами в одном окне). Проверим их наличие:
sudo apt install apt-transport-https curl wget gnupg sudo iptables tmux
Также установим keepalived
(для обеспечения высокой доступности, балансировки нагрузки, мониторинга состояния
серверов и автоматического переключения на резервные серверы в случае сбоя) и haproxy
(балансировщик нагрузки и
прокси-сервер для TCP и HTTP приложений, для распределения трафика между серверами и обеспечения высокой доступности).
sudo apt install keepalived haproxy
Модули и параметры ядра
В каждом узле, создадим конфигурационный файл для загрузки необходимых Kubernetes модулей ядра (overlay
и
br_netfilter
). Для этого создадим конфиг в папке /etc/modules-load.d/
. Файл может иметь любое имя с расширением
.conf
, для удобства назовем его k8s.conf
:
sudo nano /etc/modules-load.d/k8s.conf
В файле пропишем модули:
# Load overlay module (драйвер для работы с файловой системой overlayfs, для объединения
# нескольких файловых систем в одну)
overlay
# Load br_netfilter module (Драйвер для работы с сетевыми мостами и фильтрацией пакетов)
br_netfilter
Сохраняем и закрываем файл и теперь, благодаря конфигу, эти модули ядра будут автоматически загружаться при каждой перезагрузке узла. Но чтобы загрузить сразу и сейчас выполним команды:
sudo modprobe overlay
sudo modprobe br_netfilter
Проверим, что модуль overlay
загружен:
lsmod | grep overlay
Увидим что-то вроде:
overlay 126976 0
Цифры 126976
— это размер модуля в байтах и 0
— количество других модулей, которые используют этот модуль.
Проверим для модуля br_netfilter
:
`lsmod | grep br_netfilter`
Увидим типа такого:
br_netfilter 28672 0
bridge 266240 1 br_netfilter
Как видим, модуль br_netfilter
загружен, и он используется модулем bridge
.
Затем создадим конфигурационный файл для ядра Linux в папке /etc/sysctl.d/
. В эту папку помещаются файлы с
для настройки параметров ядра Linux. Создадим файл k8s.conf
:
sudo nano /etc/sysctl.d/k8s.conf
В файле пропишем параметры:
# Enable IPv6 traffic through iptables on bridges (Разрешаем обработку IPv6-трафика через iptables на сетевых мостах)
net.bridge.bridge-nf-call-ip6tables = 1
# Enable IPv4 traffic through iptables on bridges (Разрешаем обработку IPv4-трафика через iptables на сетевых мостах)
net.bridge.bridge-nf-call-iptables = 1
# Enable IP forwarding (Разрешаем пересылку IP-пакетов для маршрутизации трафика между контейнерами)
net.ipv4.ip_forward = 1
В принципе, первые два параметра уже установлены по умолчанию (посмотреть текущие параметры ядра можно командой
sysctl -a
), но на всякий случай все равно укажем их в файле. Сохраняем и закрываем файл. Теперь при перезагрузке
узла эти параметры будут загружаться автоматически. Но чтобы загрузить их сразу исопльзуем команду:
sudo sysctl -f /etc/sysctl.d/k8s.conf
Проверим, что параметры загружены:
sudo sysctl net.bridge.bridge-nf-call-iptables net.bridge.bridge-nf-call-ip6tables net.ipv4.ip_forward
Увидим, что параметры установлены:
net.bridge.bridge-nf-call-iptables = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.ipv4.ip_forward = 1
Отключение swap
Для обеспечения стабильной и предсказуемой работы контейнеров, Kubernetes требует отключения файла подкачки (swap). Это может замедлить работу системы (по этому лучше использовать Orange Pi c большим объемом памяти), но когда включен swap, ядро может перемещать неактивные страницы памяти на диск, что может привести к задержкам и непредсказуемому поведению контейнеров. Отключение swap позволяет Kubernetes более точно управлять ресурсами и гарантировать, что контейнерам будет выделено достаточно памяти.
Проверим, включен ли swap:
sudo swapon --show
Если увидим, что swap включен, например вот так:
NAME TYPE SIZE USED PRIO
/dev/zram0 partition 7.8G 0B 5
Как видим, у нас есть swap-раздел /dev/zram0
. Это "электронный диск" в памяти, который используется для
кэширования данных. Отключим его:
sudo swapoff /dev/zram0
Сначала узнать как на самом деле называется служба zram
в вашей системе можно командой:
systemctl list-units --type=service | grep zram
Затем отключим эту службу чтобы электронный диск не создавался при каждой загрузке:
sudo systemctl disable orangepi-zram-config.service
И остановим службу:
sudo service orangepi-zram-config stop
И наконец, удалим соответствующие записи из файла /etc/fstab
, чтобы предотвратить их автоматическое монтирование при
загрузке системы. Для этого удалим из файла /etc/fstab
строку, содержащую /dev/zram0
:
sudo sed -i '/zram0/d' /etc/fstab
Теперь проверим, что swap отключен:
sudo swapon --show
Если ничего не выводится, значит swap отключен. Но возможно, даже если swap отключен и его нет в /etc/fstab
, он может
был создан и включен с помощью dphys-swapfile
. Чтобы исключить swap сперва отключим его:
sudo swapoff -a
Отключим службу dphys-swapfil
:
sudo service dphys-swapfile stop
sudo systemctl disable dphys-swapfile
И удалим файл подкачки, если он есть:
sudo rm /var/swap
Установим Docker и Kubernetes
Ключи и репозитории
Для начала на каждом узле нашего будущего кластера надо установить GPG-ключи репозитория Docker и Kubernetes.
Установка GPG-ключей для Docker подробна описана в отдельной инструкции. Для
Kubernetes ключи устанавливаются похожим образом. Скачиваем GPG-ключ в папку /etc/apt/trusted.gpg.d/
:
curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.30/deb/Release.key | sudo gpg --dearmor -o /etc/apt/trusted.gpg.d/kubernetes-apt-keyring.gpg
Добавляем репозиторий Kubernetes (с указанием этого GPG-ключа и ARM-платформы, ведь у нас Orange Pi 5 Plus на ARM64):
echo 'deb [arch=arm64 signed-by=/etc/apt/trusted.gpg.d/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.30/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list
А для старенького Raspberry Pi 3 Model B+ на ARMv7:
echo 'deb [arch=armhf signed-by=/etc/apt/trusted.gpg.d/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.30/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list
Готово. Теперь обновим список пакетов:
sudo apt update
Установка Docker и Kubernetes
Наконец, установим Docker и Kubernetes:
sudo apt install docker-ce docker-ce-cli containerd.io docker-compose-plugin kubelet kubeadm kubectl
Где:
docker-ce
— это Docker Community Edition (Docker CE) — это бесплатная версия Docker, которая включает в себя Docker Engine, Docker CLI и Docker Compose.containerd.io
— это контейнерный менеджер, который управляет жизненным циклом контейнеров.docker-compose-plugin
— это плагин для Docker, который позволяет использовать Docker Compose с Kubernetes.kubelet
— это агент, который работает на каждом узле кластера и отвечает за запуск контейнеров.kubeadm
— это утилита для управления кластером Kubernetes.kubectl
— это утилита командной строки для управления кластером Kubernetes.
Так же нам надо на каждый узел установить cri-dockerd
-- демон, который позволяет Kubernetes использовать
Docker в качестве контейнерного рантайма. Начиная с версии 1.20, Kubernetes прекратил прямую поддержку Docker
и для взаимодействия появился cri-dockerd
-- интерфейс Container Runtime Interface (CRI) для Docker,
выступающий в роли моста между Kubernetes и Docker. Он позволяет Kubernetes управлять контейнерами.
Найти самый свежий релиз cri-dockerd
можно на странице релизов.
Перед загрузкой рекомендуется проверить актуальную архитектуру с помощью команды: uname -m
. Например, для Orange Pi 5
покажет архитектуру aarch64
(вариант ARM64). Скачаем соответствующий релиз:
sudo wget https://github.com/Mirantis/cri-dockerd/releases/download/v0.3.16/cri-dockerd-0.3.16.arm64.tgz
Распакуем архив, переместим исполняемый файл в папку /usr/local/bin/
и удалим архив:
sudo tar xvf cri-dockerd-0.3.16.arm64.tgz
sudo mv cri-dockerd/cri-dockerd /usr/local/bin/
sudo rm -rf cri-dockerd-0.3.16.arm64.tgz
Сделаем службу cri-dockerd
для systemd. Для этого в папке /etc/systemd/system/
создадим файл cri-docker.service
.
Он описывает службу cri-dockerd
и определяет, как и когда она должна быть запущена. Создадим файл:
sudo nano /etc/systemd/system/cri-docker.service
Содержимое файла (см. тут),
но с поправкой на путь к cri-dockerd
:
[Unit]
Description=CRI Interface for Docker Application Container Engine
Documentation=https://docs.mirantis.com
After=network-online.target firewalld.service docker.service
Wants=network-online.target
Requires=cri-docker.socket
[Service]
Type=notify
# ExecStart=/usr/bin/cri-dockerd --container-runtime-endpoint fd://
ExecStart=/usr/local/bin/cri-dockerd --container-runtime-endpoint fd://
ExecReload=/bin/kill -s HUP $MAINPID
TimeoutSec=0
RestartSec=2
Restart=always
StartLimitBurst=3
StartLimitInterval=60s
LimitNOFILE=infinity
LimitNPROC=infinity
LimitCORE=infinity
TasksMax=infinity
Delegate=yes
KillMode=process
[Install]
WantedBy=multi-user.target
Где:
- [Unit] -- Описывает службу.
Description
-- Описание службы.Documentation
-- Ссылка на документацию.After
-- Указывает, что служба должна быть запущена после указанных служб.Wants
-- Указывает, что служба требует наличия указанных служб.Requires
-- Указывает зависимость от сокетаcri-docker.socket
.
- [Service] -- Конфигурация службы.
Type
-- Определяет тип службы.ExecStart
-- Указывает команду, которая будет запущена при старте службы.ExecReload
-- Указывает команду, которая будет запущена при перезагрузке службы.TimeoutSec
-- Устанавливает время ожидания завершения службы.RestartSec
-- Устанавливает время между перезапусками службы.Restart
-- Указывает, как ведет себя сервис в случае ошибки.always
-- перезапускать всегда.StartLimitBurst
-- Устанавливает количество попыток запуска службы.StartLimitInterval
-- Устанавливает интервал между попытками запуска службы.LimitNOFILE
-- Устанавливает максимальное количество открытых файлов.infinity
-- неограничено.LimitNPROC
-- Устанавливает максимальное количество процессов.LimitCORE
-- Устанавливает максимальный размер ядра.TasksMax
-- Устанавливает максимальное количество задач.Delegate
-- Указывает, что служба может делегировать свои привилегии.KillMode
-- Устанавливает режим завершения процесса.
- [Install] -- Указывает, когда и как служба должна быть активирована.
WantedBy
-- Указывает, что служба должна быть активирована вместе с ёmulti-user.targetё.
Создадим конфигурацию сокета cri-docker.socket
для службы cri-dockerd
. Она определяет, как и где сервис будет
слушать входящие соединения и управлять доступом к нему. Создадим файл:
sudo nano /etc/systemd/system/cri-docker.socket
Содержимое файла (см. тут):
[Unit]
Description=CRI Docker Socket for the API
PartOf=cri-docker.service
[Socket]
ListenStream=%t/cri-dockerd.sock
SocketMode=0660
SocketUser=root
SocketGroup=docker
[Install]
WantedBy=sockets.target
Где:
- [Unit] -- Описывает службу.
Description
-- Описание сокета.PartOf
-- Указывает, что этот сокет является частью службы cri-docker.service.
- [Socket] -- Конфигурация сокета.
ListenStream
-- Указывает путь к сокету, который будет использоваться для связи.SocketMode
-- Устанавливает права доступа к сокету (0660 -- чтение и запись для владельца и группы, чтение для остальных).SocketUser
-- Устанавливает владельца сокета.SocketGroup
-- Устанавливает группу, которой принадлежит сокет.
- [Install]: Указывает, когда и как сокет должен быть активирован.
WantedBy
-- Указывает, что сокет должен быть активирован вместе с sockets.target.- Этот файл гарантирует, что cri-dockerd будет слушать на указанном сокете .
Теперь перезагрузим службы, настроим их на автозапуск и запустим их:
sudo systemctl daemon-reload
sudo systemctl enable cri-docker.service
sudo systemctl enable --now cri-docker.socket
Проверим доступность сокета пользователем `:
sudo usermod -aG docker $USER
Проверим, что контейнерный рантайм cri-dockerd
работает. Например, командой:
sudo crictl --runtime-endpoint unix:///var/run/cri-dockerd.sock version
Увидим что-то вроде:
Version: 0.1.0
RuntimeName: docker
RuntimeVersion: 27.4.1
RuntimeApiVersion: v1