🥇 CRI-O som ett alternativ till Docker som körmiljö för Kubernetes: installation på CentOS 8

Hej! Jag heter Sergej, jag är DevOps på Surf. DevOps-avdelningen på Surf har som mål att inte bara förbättra samarbetet mellan specialister och integrera arbetsprocesser, utan också aktivt undersöka och implementera aktuella teknologier både i vår egen infrastruktur och i kundens infrastruktur.

Nedan kommer jag att berätta lite om förändringarna i teknikstacken för containrar som vi stött på vid studiet av distributionen. CentOS 8 och vad som är CRI-O och hur man snabbt konfigurerar en körmiljö med hjälp av det. Kubernetes.

Varför Docker saknas i standardinstallationen av CentOS 8

Efter installationen av de senaste stora release-versionerna RHEL 8 eller CentOS 8 kan man inte låta bli att märka: i dessa distributioner och officiella repositoryn saknas applikationen Docker, som ideologiskt och funktionellt ersätter paketen Podman, Buildah (som finns i distributionen som standard) och CRI-O. Detta är kopplat till den praktiska implementeringen av standarder, som utvecklas av bland annat Red Hat inom ramarna för Open Container Initiative (OCI).

Målet med OCI, som är en del av The Linux Foundation, är att skapa öppna branschstandarder för format och körmiljöer för containrar, som ska lösa flera uppgifter. För det första, de ska inte strida mot Linux-filosofin (till exempel i den delen att varje program ska utföra en enda uppgift, medan Docker detta är en slags allt-i-ett lösning). För det andra, de ska kunna eliminera alla befintliga brister i programvaran. DockerFör det tredje, de ska vara helt kompatibla med affärskraven ställda av ledande kommersiella plattformar för distribution, hantering och underhåll av containeriserade applikationer (till exempel Red Hat OpenShift).

Nackdelar Docker och fördelarna med den nya programvaran har redan beskrivits ganska detaljerat i denna artikel, och en detaljerad beskrivning av all programvara som erbjuds inom ramen för OCI-projektet och dess arkitektoniska särdrag finns i den officiella dokumentationen och artiklar från både Red Hat (bra artikeln i Red Hat-bloggen) och externa recensioner.

Det är viktigt att notera vilken funktionalitet komponenterna i den föreslagna stacken har:

Podman — direkt interaktion med containrar och bildlagring genom processen runC;
Buildah — bygga och ladda upp bilder till ett register;
CRI-O — körmiljö för system för orkestrering av containrar (till exempel Kubernetes).

Jag tror att det är lämpligt att presentera en översikt av sambanden mellan komponenterna i stacken här. Kubernetes c runC och lågnivåbibliotek med användning av CRI-O:

CRI-O och Kubernetes följer samma cykel för utgivning och stöd (kompatibilitetsmatrisen är väldigt enkel: majorversionerna Kubernetes och CRI-O överensstämmer), och detta, med tanke på fokus på omfattande och heltäckande testning av detta stack av utvecklarna, ger oss rätt att förvänta maximalt uppnåelig stabilitet i driften vid alla användningsscenarier (här hjälper också den relativa lättvikten CRI-O jämfört med Docker på grund av avsiktlig begränsning av funktionaliteten).

Vid installation Kubernetes på "rätt sätt" (enligt OCI, naturligtvis) med användning av CRI-O till CentOS 8 ställdes vi inför vissa mindre svårigheter, som vi dock framgångsrikt övervann. Jag skulle vara glad att dela med mig av installations- och konfigurationsanvisningarna som tillsammans tar högst 10 minuter.

Så här distribuerar du Kubernetes på CentOS 8 med hjälp av miljön CRI-O

Förutsättningar: minst en värd (2 kärnor, 4 GB RAM, lagringsutrymme på minst 15 GB) med installerad CentOS 8 (profilen "Server" rekommenderas), samt en post för den i lokal DNS (om det är absolut nödvändigt kan du klara dig med en post i /etc/hosts). Och glöm inte att stänga av swap.

Alla operationer på värden utförs som användaren root, var vänlig var försiktig.

I det första steget kommer vi att konfigurera OS, installera och konfigurera förhandskraven för CRI-O.
- Uppdatera OS:
```
dnf -y update
```
- Därefter måste vi konfigurera brandväggen och SELinux. Här beror allt på miljön i vilken vår värd eller värdar kommer att arbeta. Du kan antingen konfigurera brandväggen enligt rekommendationerna från dokumentationen, eller om du är i ett betrott nätverk eller använder en extern brandvägg, ändra standardzonen till betrodd eller stänga av brandväggen:
```
firewall-cmd --set-default-zone trusted

firewall-cmd --reload
```
  För att stänga av brandväggen kan följande kommando användas:
```
systemctl disable --now firewalld
```
  SELinux måste stängas av eller sättas i "permissive"-läge:
```
setenforce 0

sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config
```
- låt oss ladda de nödvändiga kärnmodulerna och paketen, konfigurera automatisk laddning av modulen "br_netfilter" vid systemstart:
```
modprobe overlay

modprobe br_netfilter

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

dnf -y install iproute-tc
```
- För att aktivera paketdirigering och korrekt hantering av trafik ska vi göra följande inställningar:
```
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
```
  Tillämpa de gjorda inställningarna:
```
sysctl --system
```
- Ange den nödvändiga versionen CRI-O (huvudversion CRI-O, som nämnts tidigare, överensstämmer med den krävd versionen Kubernetes), då den senaste stabila versionen Kubernetes är för närvarande 1.18:
```
export REQUIRED_VERSION=1.18
```
  Lägg till de nödvändiga repositories:
```
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
```
- Nu kan vi installera CRI-O:
```
dnf -y install cri-o
```
  Observera den första detaljen vi stöter på under installationsprocessen: det är nödvändigt att redigera konfigurationen CRI-O innan tjänsten startas, eftersom den nödvändiga komponenten conmon har en annan placering än den angivna:
```
sed -i 's//usr/libexec/crio/conmon//usr/bin/conmon/' /etc/crio/crio.conf
```
  Nu kan vi aktivera och starta demon CRI-O:
```
systemctl enable --now crio
```
  Du kan kontrollera demonens status:
```
systemctl status crio
```
Installation och aktivering Kubernetes.
- Lägg till det krävs repository:
```
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
```
  Nu kan vi installera Kubernetes (version 1.18, som nämnts ovan):
```
dnf install -y kubelet-1.18* kubeadm-1.18* kubectl-1.18* --disableexcludes=kubernetes
```
- Den andra viktiga detaljen: eftersom vi inte använder demon Docker, utan använder demon CRI-O, innan vi startar och initialiserar Kubernetes måste vi göra de nödvändiga inställningarna i konfigurationsfilen /var/lib/kubelet/config.yaml, efter att ha skapat den nödvändiga katalogen:
```
mkdir /var/lib/kubelet

cat < /var/lib/kubelet/config.yaml
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
cgroupDriver: systemd
EOF
```
- Den tredje viktiga punkten vi stöter på under installationen: trots att vi angav den använda drivrutinen cgroup, och dess konfiguration via överlämnade argument kubelet är föråldrad (vilket betecknas tydligt i dokumentationen), behöver vi lägga till argument i filen, annars kommer vår kluster inte att initialiseras:
```
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
```
- Nu kan vi aktivera demon kubelet:
```
sudo systemctl enable --now kubelet
```
  För att konfigurera kontrollplan eller arbetare noder på bara några minuter kan du använda detta skript.
Det är dags att initiera vår kluster.
- För att initiera klustret, kör kommandot:
```
kubeadm init --pod-network-cidr=10.244.0.0/16
```
  Se till att skriva ner kommandot för att ansluta till klustret 'kubeadm join …' som föreslås i slutet av utskriften, eller åtminstone de angivna token.
- Vi installerar en plugin (CNI) för att arbeta med Pod-nätverket. Jag rekommenderar att använda Calico. Kanske mer populär Flannel har kompatibilitetsproblem med nftables, och Calico är den enda CNI-implementering som rekommenderas och är fullt testad av projektet Kubernetes:
```
kubectl --kubeconfig /etc/kubernetes/admin.conf apply -f https://docs.projectcalico.org/v3.15/manifests/calico.yaml 
```
- För att ansluta arbetarnoden till vårt kluster behöver den konfigureras enligt punkterna i instruktionerna 1 och 2, eller använda skript, och sedan köra kommandot från utskriften 'kubeadm init …' som vi skrev ner i föregående steg:
```
kubeadm join $CONTROL_PLANE_ADDRESS:6443 --token $TOKEN 
    --discovery-token-ca-cert-hash $TOKEN_HASH
```
- Vi kontrollerar att vårt kluster har initierats och börjat fungera:
```
kubectl --kubeconfig=/etc/kubernetes/admin.conf get pods -A
```
Klart! Du kan nu distribuera arbetsbelastning på din K8s-kluster.

Vad väntar oss framöver

Jag hoppas att instruktionen ovan har hjälpt dig spara lite tid och nervös energi.
Resultatet av processerna som pågår i branschen beror ofta på hur de tas emot av den stora massan av slutanvändare och utvecklare av annan programvara inom den relevanta nischen. Det är fortfarande oklart vilket resultat initiative OCI kommer att leda till om några år, men vi kommer gärna att följa det. Du kan dela med dig av din åsikt just nu i kommentarerna.

Stay tuned!

Denna artikel har uppstått tack vare följande källor: