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

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

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

Защо Docker не е включен в CentOS 8?

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

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

Ограничения докер и предимствата на новия софтуер вече са описани подробно в тази статия, а подробно описание на целия софтуерен стек, предлаган в рамките на проекта OCI, и неговите архитектурни характеристики могат да бъдат намерени в официалната документация и статии от самия Red Hat (не е лошо статия в блога на Red Hat) и на трети страни прегледи.

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

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

Мисля, че за да разберете общата схема на взаимодействие между компонентите на стека, е препоръчително да предоставите диаграма на връзка тук Kubernetes c тичамC и използване на библиотеки от ниско ниво CRI-O:

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

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

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

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

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

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

     dnf -y update
     

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

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

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

     systemctl disable --now firewalld
     

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

     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 <<EOF > /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

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

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

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

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

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

     sudo systemctl enable --now kubelet
     

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

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

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

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

   • Нека инсталираме плъгина (CNI) за мрежата Pod. Препоръчвам да използвате американ. Вероятно по-популярни бархет има проблеми със съвместимостта с nftables, да и американ - единственото изпълнение на 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 след няколко години, но ще ги гледаме с удоволствие. Можете да споделите вашето мнение още сега в коментарите.

Остани настроен!

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

• Раздел относно времето за изпълнение на контейнера Документация на Kubernetes
• Страница Проект CRI-O в Интернет
• Статии в блога на Red Hat: този, това и много други

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