🥇CRI-O Dockeri asendajana Kubernetes’e täitmis- ja keskkonnana: seadistamine CentOS 8-le

Tere! Minu nimi on Sergei, olen DevOps Surfis. Surfis on DevOps osakonna ülesanne mitte ainult spetsialistide vahelise koostöö korraldamine ja tööprotsesside integreerimine, vaid ka aktiivsed uuringud ja uusimate tehnoloogiate rakendamine nii meie infrastruktuuris kui ka kliendi infrastruktuuris.

Allpool räägin natuke muutustest konteinerite tehnoloogilises virnas, millega me kokku puutusime, uurides distributsiooni CentOS 8 ja sellest, mis on CRI-O ning kuidas kiiresti seadistada selle abil täideviimisruum Kubernetes.

Miks Docker ei ole CentOS 8 standardse komplekti osa

Viimaste suurte väljaannete installimise järel RHEL 8 või CentOS 8 on raske mitte märgata, et nendes distributsioonides ja ametlikes hoidlates puudub rakendus Docker, mis ideoloogiliselt ja funktsionaalselt asendab pakette Podman, Buildah (mis on distributsioonis vaikimisi olemas) ja CRI-O. See on seotud standardite praktilise rakendamisega, mida arendavad sealhulgas Red Hat või Open Container Initiative (OCI) projektis.

OCI eesmärk, mis kuulub The Linux Foundation'i, on luua avatud tööstusstandardeid konteinerite formaatidele ja täitmisringidele, mis lahendaks mitmeid ülesandeid. Esiteks, need ei tohiks olla vastuolus Linuxi filosoofiaga (näiteks osa sellest, et iga programm peaks täitma ühte kindlat toimingut, mitte " Docker kõik-ühes lahendust"). Teiseks, need peaksid kõrvaldanud kõik olemasolevad tarkvaravead Docker. Kolmandaks, need peaksid olema täielikult kooskõlas juhtivate kaubanduslike platvormide ärinõuetega, mis on suunatud konteineriseeritud rakenduste juurutamisele, haldamisele ja hooldamisele (näiteks Red Hat OpenShift).

Puudused Docker Uue tarkvara eelised on juba üsna põhjalikult kajastatud selles artiklis, ja üksikasjaliku kirjelduse saamiseks kogu OCI projekti tarkvarastekki ja selle arhitektuuri omadustega saab tutvuda ametlikus dokumentatsioonis ja artiklites nii Red Hat'i poolt (kvaliteetne artikkel Red Hat blogis), kui ka kolmandate osapoolte ülevaadetes.

On oluline märkida, millised funktsioonid on pakutud steigi komponentidel:

Podman — otsene interaktsioon konteinerite ja piltide hoidla vahel läbi runC protsessi;
Buildah — piltide kokku kogumine ja registrisse laadimine;
CRI-O — täitmis keskkond konteinerite orkestreerimise süsteemide jaoks (näiteks Kubernetes).

Arvan, et komponentide vahelise üldise interaktsiooni skeemi mõistmiseks on mõistlik tuua siia välja seoseid näitav skeem. Kubernetes c runC ja madala taseme raamatukogud, kasutades CRI-O:

CRI-O ja Kubernetes järgivad sama väljalaske ja toe tsüklit (ühilduvuse matriiis on väga lihtne: peamised versioonid Kubernetes ja CRI-O kattuvad), ja see, arvestades arendajate poolt selle stacki täielikku ja põhjalikku testimist, annab meile õiguse oodata maksimaalselt saavutatavat stabiilsust igasugustes kasutamisstsenaariumites (siin on kasuks ka suhteline kergus CRI-O võrreldes Docker funktsionaalsuse eesmärgipärase piiramise tõttu).

Installeerimisel Kubernetes «right way» viisil (OCI arvates) kasutades CRI-O järgnevaga CentOS 8 olime silmitsi väikeste raskustega, kuid oleme need edukalt ületanud. Olen rõõmus, et saan jagada teiega paigaldamise ja seadistamise juhendit, mis kokku võtab kuni 10 minutit.

Kuidas seadistada Kubernetes CentOS 8-l CRI-O keskkonna abil

Eeltingimused: vähemalt ühe hosti olemasolu (2 tuuma, 4 GB RAM, vähemalt 15 GB salvestusruumi) koos installitud CentOS 8 (soovitatav on installiprofiil „Server”), samuti selle jaoks kohalik DNS-i kirje (ülim juhul võib kasutada ka kirjet /etc/hosts). Ja ärge unustage swap välja lülitada.

Kõik toimingud hostis tuleb teostada kasutajana root, olge ettevaatlik.

Esimeses etapis seadistame operatsioonisüsteemi, installime ja seadistame CRI-O jaoks vajalikud eeltingimused.
- Uuendame operatsioonisüsteemi:
```
dnf -y update
```
- Seejärel on vaja seadistada tulemüür ja SELinux. Siin sõltub kõik meie hosti või hostide keskkonnast. Saate kas seadistada tulemüüri vastavalt soovitustele dokumentatsioonis, või kui viibite usaldusväärses võrgus või kasutate kolmanda osapoole tulemüüri, muuta vaikeala usaldusväärseks või tulemüüri välja lülitada:
```
firewall-cmd --set-default-zone trusted

firewall-cmd --reload
```
  Tulemüüri väljalülitamiseks saate kasutada järgmist käsku:
```
systemctl disable --now firewalld
```
  SELinux tuleb välja lülitada või seadistada „permissive” režiimi:
```
setenforce 0

sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config
```
- laeme vajalikud kernelimoodulid ja paketid, seadistame mooduli „br_netfilter” automaatse laadimise süsteemi käivitamisel:
```
modprobe overlay

modprobe br_netfilter

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

dnf -y install iproute-tc
```
- pakettide edastamise ja liikluse korrektse töötlemise aktiveerimiseks teeme vastavad seadistused:
```
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
```
  rakendame tehtud seadistused:
```
sysctl --system
```
- seame vajalikku versiooni CRI-O (peamine versioon CRI-O, nagu juba mainitud, vastavad nõutavale versioonile Kubernetes), kuna viimase stabiilne versioon Kubernetes hetkel on 1.18:
```
export REQUIRED_VERSION=1.18
```
  lisame vajalikud repositooriumid:
```
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
```
- nüüd saame paigaldada CRI-O:
```
dnf -y install cri-o
```
  Pöörake tähelepanu esimeselle nüansile, millega kohtume installimise käigus: конфигурацию необходимо отредактировать CRI-O enne teenuse käivitamist, kuna nõutav komponent conmon asub muus kohas kui määratud:
```
sed -i 's//usr/libexec/crio/conmon//usr/bin/conmon/' /etc/crio/crio.conf
```
  Nüüd saab teenuseaktiveerida ja käivitada CRI-O:
```
systemctl enable --now crio
```
  Saame kontrollida teenuse staatust:
```
systemctl status crio
```
Paigaldamine ja aktiveerimine Kubernetes.
- Lisame nõutud hoidla:
```
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
```
  Nüüd saame paigaldada Kubernetes (versioonid 1.18, nagu juba eelnevalt mainitud):
```
dnf install -y kubelet-1.18* kubeadm-1.18* kubectl-1.18* --disableexcludes=kubernetes
```
- Teine oluline nüanss: kuna me ei kasuta teenust Docker, vaid sellest teenusest CRI-O, enne käivitamist ja algatamist Kubernetes on vajalikud seadistused teha konfiguratsioonifailis /var/lib/kubelet/config.yaml, luues eelnevalt vajaliku katalooge:
```
mkdir /var/lib/kubelet

cat < /var/lib/kubelet/config.yaml
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
cgroupDriver: systemd
EOF
```
- Kolmas oluline punkt, millega me kokku puutume paigaldamisel: vaatamata sellele, et oleme määranud kasutatava draiveri cgroup, ja selle seadistamine edastatud argumentide kaudu kubelet on aegunud (millest on dokumentatsioonis selgelt märgitud), me peame lisama faili argumendid, vastasel juhul ei initsialiseerita meie klastrit:
```
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
```
- Nüüd saame deemonit aktiveerida kubelet:
```
sudo systemctl enable --now kubelet
```
  Et seadistada kontrollimise keskus või töötaja node'd mõne minutiga, võite kasutada seda skripti.
On aeg meie klastrit initsialiseerida.
- Klastri initsialiseerimiseks käivitage käsk:
```
kubeadm init --pod-network-cidr=10.244.0.0/16
```
  Kohustuslik on üles kirjutada klastrisse liitumise käsk „kubeadm join …“, mida pakutakse kasutamiseks väljundi lõpus, või vähemalt märgitud tokenid.
- Paigaldame plugina (CNI) pod-võrgu tööks. Soovitan kasutada Calico. Võimalik, et populaarsem Flannel on ühilduvusprobleemidega nftables, ja see on Calico ainus CNI teostus, mida projekt soovitab ja on täielikult testitud Kubernetes:
```
kubectl --kubeconfig /etc/kubernetes/admin.conf apply -f https://docs.projectcalico.org/v3.15/manifests/calico.yaml 
```
- Worker sõlme ühendamiseks meie klastriga tuleb see seadistada vastavalt juhiste punktidele 1 ja 2, või kasutada skripti, seejärel täita eelnevalt kirjutatud käsk «kubeadm init …» väljundist:
```
kubeadm join $CONTROL_PLANE_ADDRESS:6443 --token $TOKEN 
    --discovery-token-ca-cert-hash $TOKEN_HASH
```
- Kontrollime, et meie klaster on algatatud ja töötab:
```
kubectl --kubeconfig=/etc/kubernetes/admin.conf get pods -A
```
Valmis! Saate nüüd oma K8s klastris koormust paigutada.

Mida oodata edasi

Loodan, et ülalolev juhend aitas teil natuke aega ja närve säästa.
Tööstuses toimuvate protsesside lõpp sõltub sageli sellest, kuidas nad on vastu võetud lõppkasutajate ja teiste tarkvara arendajate seas oma vastavas nišis. Praegu ei ole täpselt selge, kuhu OCI algatused paar aasta pärast viivad, kuid oleme rõõmsad, et saame seda jälgida. Oma arvamust saate jagada kohe kommentaarides.

Jälgige meid!

See artikkel ilmus tänu järgmistele allikatele: