CRI-O като заместител на Docker като изпълнителна среда за Kubernetes: настройка на CentOS 8

Здравейте! Казвам се Сергей и съм DevOps в Surf. DevOps отделът в Surf не само, че се грижи за взаимодействието между специалистите и интегрирането на работните процеси, но също така активно изследва и внедрява съвременни технологии както в собствената инфраструктура, така и в инфраструктурата на клиента.

По-долу ще ви разкажа малко за промените в технологичния стек за контейнери, с които се сблъсквахме при проучването на дистрибуцията CentOS 8 и какво представлява CRI-O и как бързо да настроите с негова помощ изпълнителна среда за Kubernetes.

Защо Docker липсва в стандартната версия на CentOS 8

След инсталирането на последните големи версии RHEL 8 или CentOS 8 не може да се не забележи, че в тези дистрибуции и официални хранилища липсва приложението Docker, което идеологически и функционално замества пакетите Podman, Buildah (налични в дистрибуцията по подразбиране) и CRI-O. Това е свързано с практическото реализиране на стандартите, разработвани, между другото, от Red Hat в рамките на проекта Open Container Initiative (OCI).

Целта на OCI, която е част от The Linux Foundation, е създаването на отворени индустриални стандарти за формати и изпълнителни среди за контейнери, които да решават няколко задачи. Първо, да не противоречат на философията на Linux (например, в частта, в която всяка програма трябва да изпълнява само едно действие, докато Docker представлява нещо като комбинирана система всичко в едно). На второ място, да отстранят всички съществуващи недостатъци в софтуера. DockerНа трето място, да бъдат напълно съвместими с бизнес изискванията, поставени от водещите търговски платформи за разгръщане, управление и обслужване на контейнеризирани приложения (например, Red Hat OpenShift).

Недостатъци Docker и предимствата на новия софтуер вече бяха доста подробно описани в тази статия, а за подробно описание на всичко, предлагано в рамките на проекта OCI, и архитектурните му особености можете да се запознаете с официалната документация и статиите както от самия Red Hat (неподходяща статия в Red Hat blog), така и в независимите ревюта..

Важно е да се отбележи каква функционалност имат компонентите на предлагания стек:

• Podman — директно взаимодействие с контейнерите и хранилището на образи чрез процеса runC;
• Buildah — изграждане и качване в регистър на образи;
• CRI-O — изпълнителна среда за системи за оркестрация на контейнери (например, Kubernetes).

Смятам, че за разбиране на общата схема на взаимодействие между компонентите на стека, е целесъобразно да представим тук схемата на връзките. Kubernetes с runC и нискоуровневите библиотеки с използването на CRI-O:

CRI-O и Kubernetes се придържат към един и същ цикъл на издаване и поддръжка (матрицата на съвместимост е много проста: мажорните версии Kubernetes и CRI-O съcoпадат), а това, предвид насоките за пълно и всестранно тестване на работата на този стек от разработчиците, ни дава основание да очакваме максимално постижима стабилност в работата при всякакви сценарии на използване (тук допринася и относителната лекота CRI-O в сравнение с Docker поради целенасоченото ограничаване на функционалността).

При инсталиране Kubernetes по "правилния начин" (според OCI, разбира се) с използването на CRI-O на CentOS 8 се сблъскахме с малки затруднения, които обаче успешно преодоляхме. Ще се радвам да споделя с вас инструкция за инсталация и настройка, които общо взето ще отнемат не повече от 10 минути.

Как да развернем Kubernetes на CentOS 8 с използването на среда CRI-O

Предварителни изисквания: наличие на поне един хост (2 ядра, 4 GB RAM, устройство с минимум 15 GB) с инсталирана CentOS 8 (препоръчително е да се избере профил "Сървър"), както и записи за него в локалния DNS (в краен случай може да се избегне с запис в /etc/hosts). И не забравяйте да изключите swap.

Всички операции на хоста извършваме от името на потребителя root, моля, бъдете внимателни.

1. На първия етап ще конфигурираме ОС, ще инсталираме и настройваме предварителните зависимости за CRI-O.
   • Актуализираме ОС:

     dnf -y update
     

   • След това е необходимо да настроим защитната стена и SELinux. Тук зависим от средата, в която ще работят нашият хост или хостове. Можете или да настроите защитната стена съгласно препоръките от документацията, или, ако сте в доверена мрежа или използвате външна защитна стена, да промените подразбиращата се зона на доверена или да изключите защитната стена:

     firewall-cmd --set-default-zone trusted
     
     firewall-cmd --reload

     За да изключите защитната стена, можете да използвате следната команда:

     systemctl disable --now firewalld
     

     SELinux трябва да бъде изключен или да бъде преведен в режим "permissive":

     setenforce 0
     
     sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config

   • ще заредим необходимите ядрови модули и пакети, ще настроим автоматичното зареждане на модула "br_netfilter" при стартиране на системата:

     modprobe overlay
     
     modprobe br_netfilter
     
     echo "br_netfilter" >> /etc/modules-load.d/br_netfilter.conf
     
     dnf -y install iproute-tc
     

   • За да активираме пренасочването на пакети и да обработваме трафика правилно, ще направим съответните настройки:

     cat > /etc/sysctl.d/99-kubernetes-cri.conf <<EOF
     net.bridge.bridge-nf-call-iptables = 1
     net.ipv4.ip_forward = 1
     net.bridge.bridge-nf-call-ip6tables = 1
     EOF
     

     Ще приложим направените настройки:

     sysctl --system

   • Ще зададем необходимата версия CRI-O (главна версия CRI-O, както вече беше споменато, съвпада с изискваната версия Kubernetes), тъй като последната стабилна версия Kubernetes в момента е 1.18:

     export REQUIRED_VERSION=1.18
     

     Ще добавим необходимите репозитории:

     dnf -y install 'dnf-command(copr)'
     
     dnf -y copr enable rhcontainerbot/container-selinux
     
     curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable.repo https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/CentOS_8/devel:kubic:libcontainers:stable.repo
     
     curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable:cri-o:$REQUIRED_VERSION.repo https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$REQUIRED_VERSION/CentOS_8/devel:kubic:libcontainers:stable:cri-o:$REQUIRED_VERSION.repo

   • Сега можем да инсталираме CRI-O:

     dnf -y install cri-o
     

     Обърнете внимание на първия нюанс, който срещаме по време на инсталацията: необходимо е да редактираме конфигурацията CRI-O преди стартиране на услугата, тъй като изискваният компонент conmon има различно от посоченото местоположение:

     sed -i 's//usr/libexec/crio/conmon//usr/bin/conmon/' /etc/crio/crio.conf

     Сега можем да активираме и стартираме демона CRI-O:

     systemctl enable --now crio
     

     Можем да проверим статуса на демона:

     systemctl status crio
     

2. Инсталация и активиране Kubernetes.
   • Ще добавим необходимия репозиторий:

     cat < /etc/yum.repos.d/kubernetes.repo
     [kubernetes]
     name=Kubernetes
     baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-$basearch
     enabled=1
     gpgcheck=1
     repo_gpgcheck=1
     gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
     exclude=kubelet kubeadm kubectl
     EOF
     

     Сега можем да инсталираме Kubernetes (версия 1.18, както вече беше посочено по-горе):

     dnf install -y kubelet-1.18* kubeadm-1.18* kubectl-1.18* --disableexcludes=kubernetes

   • Вторият важен нюанс: тъй като не използваме демон Docker, а използваме демон CRI-O, преди стартиране и инициализация Kubernetes е необходимо да направим съответните настройки в конфигурационния файл /var/lib/kubelet/config.yaml, като предварително създадем необходимата директория:

     mkdir /var/lib/kubelet
     
     cat < /var/lib/kubelet/config.yaml
     apiVersion: kubelet.config.k8s.io/v1beta1
     kind: KubeletConfiguration
     cgroupDriver: systemd
     EOF

   • Третият важен момент, с който се сблъскваме по време на инсталацията: въпреки че указахме използвания драйвер cgroup, и неговата настройка чрез аргументите, които предаваме kubelet е остаряла (както е посочено в документацията), необходимо е да добавим аргументи в файла, иначе нашият клъстер няма да бъде инициализиран:

     cat /dev/null > /etc/sysconfig/kubelet
     
     cat < /etc/sysconfig/kubelet
     KUBELET_EXTRA_ARGS=--container-runtime=remote --cgroup-driver=systemd --container-runtime-endpoint='unix:///var/run/crio/crio.sock'
     EOF

   • Сега можем да активираме демона kubelet:

     sudo systemctl enable --now kubelet
     

     За да настроим контролна равнина или работник възли за минути, можете да използвате този скрипт.

3. Време е да инициализираме нашия клъстер.
   • За инициализация на клъстера изпълнете команда:

     kubeadm init --pod-network-cidr=10.244.0.0/16
     

     Не забравяйте да запишете командата за присъединяване към клъстера „kubeadm join …“, която се предлага в края на изхода, или поне посочените токени.

   • Да инсталираме плъгин (CNI) за работа с Pod мрежа. Препоръчвам да използвате Calico. Може би по-популярният Flannel има проблеми с съвместимостта с nftables, а и Calico е единствената реализация на CNI, която е препоръчана и напълно тествана от проекта Kubernetes:

     kubectl --kubeconfig /etc/kubernetes/admin.conf apply -f https://docs.projectcalico.org/v3.15/manifests/calico.yaml 

   • За свързване на работна възел към нашия клъстер, тя трябва да бъде настроена според точките от инструкции 1 и 2, или да използвате скрипт, след това изпълнете командата от изхода „kubeadm init …“, която записахме на предишния етап:

     kubeadm join $CONTROL_PLANE_ADDRESS:6443 --token $TOKEN 
         --discovery-token-ca-cert-hash $TOKEN_HASH

   • Ще проверим, че нашият клъстер е инициализиран и е започнал работа:

     kubectl --kubeconfig=/etc/kubernetes/admin.conf get pods -A
     

   Готово! Вече можете да разполагате полезен товар на вашия K8s клъстер.

Какво ни чака напред

Надявам се, че горната инструкция ви е помогнала да спестите малко време и нерви.
Изходът на процесите в индустрията често зависи от начина, по който ги възприема основната маса от крайни потребители и разработчици на друго софтуерно решение в съответстващата ниша. Все още не е съвсем ясно какъв резултат ще доведат инициативите на OCI през следващите години, но ще се радваме да следим това. Можете да споделите мнението си веднага в коментарите.

Останете на линия!

Тази статия се появи благодарение на следните източници:

• Раздела за Container runtimes в документацията на Kubernetes
• Страницата на проекта CRI-O в интернет
• Статии в блоговете на Red Hat: тази, тази и много други

Източник: habr.com