🥇CRI-O ca înlocuitor pentru Docker ca mediu de execuție pentru Kubernetes: configurare pe CentOS 8

Salut! Mă numesc Serghei, sunt DevOps la Surf. Departamentul DevOps de la Surf are ca obiectiv nu doar facilitarea colaborării între specialiști și integrarea proceselor de lucru, ci și cercetări active și implementarea tehnologiilor actuale atât în infrastructura proprie, cât și în infrastructura clientului.

Mai jos, voi vorbi puțin despre schimbările din tehnologia stivei pentru containere, cu care ne-am confruntat în timpul studiului distribuției CentOS 8 și despre ce este CRI-O și cum să configurezi rapid un mediu de execuție pentru Kubernetes.

De ce Docker lipsește în livrarea standard a CentOS 8

După instalarea celor mai recente versiuni mari RHEL 8 sau CentOS 8 nu putem să nu observăm: în aceste distribuții și în repositoarele oficiale lipsește aplicația Docker, care înlocuiește ideologic și funcțional pachetele Podman, Buildah (prezentă în distribuție în mod implicit) și CRI-O. Aceasta se datorează implementării practice a standardelor dezvoltate, printre altele, de compania Red Hat în cadrul proiectului Open Container Initiative (OCI).

Scopul OCI, care este parte a The Linux Foundation, este de a crea standarde industriale deschise pentru formatele și medii de execuție ale containerelor, care să abordeze mai multe obiective simultan. În primul rând, să nu contravină filosofiei Linux (de exemplu, în ceea ce privește faptul că fiecare program ar trebui să execute o singură acțiune, iar Docker este un fel de combine totul într-unul). În al doilea rând, să elimine toată lista de neajunsuri din software Docker. În al treilea rând, să fie complet compatibile cu cerințele de afaceri impuse de cele mai importante platforme comerciale pentru desfășurarea, gestionarea și întreținerea aplicațiilor containerizate (de exemplu, Red Hat OpenShift).

Dezavantaje Docker și avantajele noului software au fost deja descrise destul de detaliat în această articole, iar pentru o descriere detaliată a întregului stack de software propus în cadrul proiectului OCI și a caracteristicilor sale arhitecturale, se poate consulta documentația oficială și articole atât de la Red Hat însăși (un blog destul de bun în Red Hat blog), cât și din surse externe. articol Este important să menționăm ce funcționalitate au componentele stack-ului propus: se menționează.

— interacțiune directă cu containerele și depozitul de imagini prin procesul runC;

Podman — construirea și încărcarea imaginilor în registru;
Buildah — mediu de execuție pentru sistemele de orchestrare a containerelor (de exemplu, Kubernetes).
CRI-O — исполняемая среда для систем оркестрации контейнеров (например, Kubernetes).

Cred că pentru a înțelege schema generală de interacțiune dintre componentele stivei, este util să prezentăm aici schema legăturilor Kubernetes c runC și bibliotecile de nivel inferior utilizând CRI-O:

CRI-O și Kubernetes urmează același ciclu de lansare și suport (matricea de compatibilitate este foarte simplă: versiunile majore Kubernetes și CRI-O coincid), iar acest lucru, având în vedere orientarea spre testarea completă și cuprinzătoare a funcționării acestei stive de către dezvoltatori, ne oferă dreptul să așteptăm o stabilitate maximă în funcționare în orice scenariu de utilizare (aici ajută și relativitatea ușoară CRI-O în comparație cu Docker din cauza restricționării intenționate a funcționalității).

During the installation Kubernetes în modul „right way” (după cum consideră OCI, desigur) utilizând CRI-O pe CentOS 8 ne-am confruntat cu unele dificultăți minore, pe care le-am depășit cu succes. Voi fi bucuros să împărtășesc cu voi instrucțiunile de instalare și configurare, care, în total, vor dura maximum 10 minute.

Cum să desfășurăm Kubernetes pe CentOS 8 utilizând mediul CRI-O

Cerințe preliminare: să existe cel puțin un gazdă (2 cores, 4 GB RAM, stocare de minimum 15 GB) cu instalată CentOS 8 (recomandat profilul de instalare „Server”), precum și înregistrări pentru acesta în DNS local (în caz extrem se poate utiliza o înregistrare în /etc/hosts). Și nu uitați să dezactivați swap-ul.

Toate operațiile pe gazdă se efectuează în numele utilizatorului root, fiți atenți.

În primul pas vom configura SO-ul, vom instala și configura dependențele preliminare pentru CRI-O.
- Vom actualiza SO-ul:
```
dnf -y update
```
- Apoi trebuie să configurăm firewall-ul și SELinux. Aici depindem de mediul în care vor funcționa gazda sau gazdele noastre. Puteți fie să configurați firewall-ul conform recomandărilor din documentation, fie, dacă vă aflați într-o rețea de încredere sau folosiți un firewall extern, să schimbați zona implicită în zona de încredere sau să dezactivați firewall-ul:
```
firewall-cmd --set-default-zone trusted

firewall-cmd --reload
```
  Pentru a dezactiva firewall-ul, se poate folosi următoarea comandă:
```
systemctl disable --now firewalld
```
  SELinux trebuie dezactivat sau pus în modul „permissive”:
```
setenforce 0

sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config
```
- vom încărca modulele de kernel necesare și pachetele, vom configura încărcarea automată a modulului „br_netfilter” la startul sistemului:
```
modprobe overlay

modprobe br_netfilter

echo "br_netfilter" >> /etc/modules-load.d/br_netfilter.conf

dnf -y install iproute-tc
```
- Pentru a activa redirecționarea pachetelor și a trata corespunzător traficul, vom efectua setările necesare:
```
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
```
  vom aplica setările efectuate:
```
sysctl --system
```
- vom specifica versiunea necesară CRI-O (versiunea majoră CRI-O, așa cum s-a menționat, se potrivește cu versiunea necesară Kubernetes), deoarece ultima versiune stabilă Kubernetes în prezent este 1.18:
```
export REQUIRED_VERSION=1.18
```
  vom adăuga repozitoarele necesare:
```
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
```
- acum putem instala CRI-O:
```
dnf -y install cri-o
```
  Atenție la primul detaliu pe care-l întâlnim în timpul instalării: este necesar să edităm configurația CRI-O înainte de a porni serviciul, deoarece componenta necesară conmon are un loc de plasare diferit de cel specificat:
```
sed -i 's//usr/libexec/crio/conmon//usr/bin/conmon/' /etc/crio/crio.conf
```
  Acum putem activa și porni demonul CRI-O:
```
systemctl enable --now crio
```
  Se poate verifica starea demonului:
```
systemctl status crio
```
Instalare și activare Kubernetes.
- Vom adăuga repozitoriul necesar:
```
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
```
  Acum putem instala Kubernetes (versiunile 1.18, așa cum s-a menționat mai sus):
```
dnf install -y kubelet-1.18* kubeadm-1.18* kubectl-1.18* --disableexcludes=kubernetes
```
- Un alt detaliu important: deoarece nu folosim demonul Docker, ci folosim demonul CRI-O, înainte de a porni și inițializa Kubernetes este necesar să facem setările corespunzătoare în fișierul de configurație /var/lib/kubelet/config.yaml, creând mai întâi directorul necesar:
```
mkdir /var/lib/kubelet

cat < /var/lib/kubelet/config.yaml
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
cgroupDriver: systemd
EOF
```
- O a treia problemă importantă pe care o întâlnim la instalare: deși am specificat driverul utilizat cgroup, și configurarea acestuia prin argumentele transmise kubelet a devenit învechită (așa cum este menționat direct în documentație), este necesar să adăugăm argumente în fișier, altfel clusterul nostru nu va fi inițializat:
```
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
```
- Acum putem activa daemonul kubelet:
```
sudo systemctl enable --now kubelet
```
  Pentru a configura control-plane sau worker nodurile în câteva minute, puteți folosi acest script.
Este timpul să inițializăm cluster-ul nostru.
- Pentru a inițializa cluster-ul, rulați comanda:
```
kubeadm init --pod-network-cidr=10.244.0.0/16
```
  Asigurați-vă că notați comanda de aderare la cluster «kubeadm join …» propusă la sfârșitul ieșirii, sau cel puțin token-urile specificate.
- Vom instala un plugin (CNI) pentru rețeaua Pod. Vă recomand să folosiți Calico. Poate că acesta este mai popular Flannel are probleme de compatibilitate cu nftables, și de asemenea Calico — este singura implementare CNI recomandată și complet testată de proiectul Kubernetes:
```
kubectl --kubeconfig /etc/kubernetes/admin.conf apply -f https://docs.projectcalico.org/v3.15/manifests/calico.yaml 
```
- Pentru a conecta nodul worker la cluster-ul nostru, acesta trebuie configurat conform instrucțiunilor 1 și 2, sau folosiți script, apoi rulați comanda din ieșirea «kubeadm init …» pe care am notat-o în etapa anterioară:
```
kubeadm join $CONTROL_PLANE_ADDRESS:6443 --token $TOKEN 
    --discovery-token-ca-cert-hash $TOKEN_HASH
```
- Să verificăm că cluster-ul nostru a fost inițializat și a început să funcționeze:
```
kubectl --kubeconfig=/etc/kubernetes/admin.conf get pods -A
```
Gata! Puteți deja să desfășurați sarcini utile pe cluster-ul dvs. K8s.

Ce ne așteaptă mai departe

Sper că instrucțiunea de mai sus v-a ajutat să economisiți puțin timp și nervi.
Evoluția proceselor din industrie depinde adesea de modul în care acestea sunt acceptate de majoritatea utilizatorilor finali și dezvoltatorilor de software din nișa respectivă. Nu este încă foarte clar la ce concluzie vor duce inițiativele OCI în câțiva ani, dar vom urmări cu plăcere. Puteți împărtăși părerea dvs. chiar acum în comentarii.

Rămâneți conectați!

Acest articol a apărut datorită următoarelor surse: