🥇CRI-O som erstatning for Docker som runtime-miljø til Kubernetes: opsætning på CentOS 8

Hej! Mit navn er Sergey, jeg er DevOps hos Surf. DevOps-afdelingen i Surf har til opgave ikke kun at etablere samarbejde mellem specialister og integrere arbejdsprocesser, men også at forske aktivt i og implementere aktuelle teknologier både i vores egen infrastruktur og i kundernes infrastruktur.

Nedenfor vil jeg kort fortælle om ændringerne i den teknologiske stak til containere, som vi har mødt under studiet af distributionen CentOS 8 og hvad det er CRI-O og hvordan man hurtigt indstiller et kørsel miljø med det Kubernetes.

Hvorfor Docker ikke er inkluderet i standardudgaven af CentOS 8

Efter installationen af de seneste store versioner RHEL 8 eller CentOS 8 kan man ikke undgå at bemærke: i disse distributioner og officielle repositories er applikationen Docker, som ideologisk og funktionelt erstatter pakkene Podman, Buildah (tilgængelige i distributionen som standard) og CRI-O. Dette skyldes den praktiske implementering af standarder, der udvikles, herunder af Red Hat inden for Open Container Initiative (OCI) projektet.

Målet med OCI, som er en del af The Linux Foundation, er at skabe åbne industrielle standarder for formater og udførelsesmiljøer for containere, som kan løse flere opgaver. For det første må de ikke modsætte sig Linux-filosofien (for eksempel i den del, hvor hver program skal udføre én enkelt opgave, og Docker repræsenterer en slags alt-i-én kombajn). For det andet, kunne de afhjælpe alle nuværende mangler i softwaren. DockerFor det tredje, skulle de være fuldstændig kompatible med forretningens krav, der stilles af de førende kommercielle platforme til implementering, styring og vedligeholdelse af containeriserede applikationer (for eksempel Red Hat OpenShift).

Ulemper Docker og fordelene ved den nye software er allerede blevet beskrevet ret detaljeret i denne artikel, og man kan finde en detaljeret beskrivelse af alt, hvad der tilbydes inden for OCI-projektet, samt dets arkitektoniske egenskaber i den officielle dokumentation og artikler fra både Red Hat selv (en god artikel i Red Hat blog), samt i tredjeparts anmeldelser.

Det er vigtigt at nævne, hvilken funktionalitet de dele af den foreslåede stak har:

Podman — direkte interaktion med containere og lager til billeder gennem process runC;
Buildah — opbygning og upload til registreret billeder;
CRI-O — et udførelsesmiljø til systemer til orkestrering af containere (for eksempel Kubernetes).

Jeg mener, at det er fornuftigt at inkludere et diagram over forbindelserne for at forstå den generelle interaktion mellem komponenterne i stakken. Kubernetes c runC og lavniveau biblioteker ved hjælp af CRI-O:

CRI-O og Kubernetes de følger den samme udgivelses- og supportcyklus (kompatibilitetsmatrixen er meget enkel: de større versioner Kubernetes og CRI-O matcher), og dette, i betragtning af målet om fuld og grundlæggende test af dette staks funktionalitet af udviklerne, giver os ret til at forvente maksimal mulig stabilitet i driften under alle brugsscenarier (her bidrager den relative letvægtsstruktur også til fordel). CRI-O sammenlignet med Docker på grund af den målrettede begrænsning af funktionaliteten).

Ved installationen Kubernetes "right way" metode (ifølge OCI, selvfølgelig) ved brug af CRI-O og få en fungerende kommando. CentOS 8 stødte vi på nogle mindre problemer, som vi dog lykkedes med at overvinde. Jeg vil være glad for at dele installations- og konfigurationsvejledningen med dig, som samlet set kun vil tage omkring 10 minutter.

Sådan distribueres Kubernetes på CentOS 8 ved brug af CRI-O-miljøet

Forudsætninger: der skal være mindst én vært (2 kerner, 4 GB RAM, og en lagerplads på mindst 15 GB) med installeret CentOS 8 (det anbefales at bruge installationsprofilen "Server"), samt en post for den i den lokale DNS (i værste fald kan man klare sig med en post i /etc/hosts). Og glem ikke at deaktivere swap..

Alle operationer på værten udføres som brugeren root, vær venlig opmærksom.

I det første trin konfigurerer vi operativsystemet, installerer og konfigurerer de nødvendige afhængigheder for CRI-O.
- Lad os opdatere operativsystemet:
```
dnf -y update
```
- Dernæst er det nødvendigt at konfigurere firewall og SELinux. Her afhænger alt af det miljø, hvori vores vært eller værter vil fungere. Du kan enten konfigurere firewallen i henhold til anbefalingerne fra dokumentationen, eller hvis du er i et betroet netværk eller bruger en tredjeparts firewall, ændre standardzonen til betroet eller deaktivere firewallen:
```
firewall-cmd --set-default-zone trusted

firewall-cmd --reload
```
  For at deaktivere firewallen kan du bruge følgende kommando:
```
systemctl disable --now firewalld
```
  SELinux skal deaktiveres eller omstilles til "permissive"-tilstand:
```
setenforce 0

sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config
```
- vi skal indlæse de nødvendige kernemoduler og pakker og konfigurere, at modulet "br_netfilter" indlæses automatisk ved systemstart:
```
modprobe overlay

modprobe br_netfilter

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

dnf -y install iproute-tc
```
- For at aktivere pakke-omdirigering og korrekt behandling af trafik, vil vi foretage de nødvendige indstillinger:
```
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
```
  Vi anvender de foretagne indstillinger:
```
sysctl --system
```
- Lad os angive den nødvendige version CRI-O (major version CRI-O, som tidligere nævnt, svarer til den krævede version Kubernetes), da den seneste stabile version Kubernetes for nuværende er 1.18:
```
export REQUIRED_VERSION=1.18
```
  Lad os tilføje de nødvendige depot:
```
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 installere CRI-O:
```
dnf -y install cri-o
```
  Vær opmærksom på det første punkt, vi støder på under installationen: det er nødvendigt at redigere konfigurationen CRI-O før tjenesten startes, da den krævede komponent conmon har et andet placering end angivet:
```
sed -i 's//usr/libexec/crio/conmon//usr/bin/conmon/' /etc/crio/crio.conf
```
  Nu kan vi aktivere og starte dæmonen CRI-O:
```
systemctl enable --now crio
```
  Man kan kontrollere status for dæmonen:
```
systemctl status crio
```
Installation og aktivering Kubernetes.
- Lad os tilføje det nødvendige depot:
```
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 installere Kubernetes (versioner 1.18, som tidligere angivet):
```
dnf install -y kubelet-1.18* kubeadm-1.18* kubectl-1.18* --disableexcludes=kubernetes
```
- Et andet vigtigt punkt: da vi ikke bruger dæmonen Docker, men bruger dæmonen CRI-O, er det nødvendigt at foretage de nødvendige indstillinger i konfigurationsfilen /var/lib/kubelet/config.yaml, efter først at have oprettet den nødvendige mappe: Kubernetes mkdir /var/lib/kubeletcat < /var/lib/kubelet/config.yaml apiVersion: kubelet.config.k8s.io/v1beta1 kind: KubeletConfiguration cgroupDriver: systemd EOF
```
Et tredje vigtigt punkt, vi møder under installationen: på trods af at vi har angivet den anvendte driver
```
- cgroup , og dens konfiguration via argumenter, er forældet (hvilket er angivet i dokumentationen), må vi tilføje argumenter i filen, ellers kan vores klynge ikke initialiseres:, og dens konfiguration gennem de videregivne argumenter kubelet er forældet (hvilket er nævnt direkte i dokumentationen), vi er nødt til at tilføje argumenterne i filen, ellers bliver vores klynge ikke initialiseret:
```
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 aktivere demon. kubelet:
```
sudo systemctl enable --now kubelet
```
  For at konfigurere control-plane eller worker noder på få minutter, kan du bruge dette script..
Det er tid til at initialisere vores klynge.
- For at initialisere klyngen skal du køre kommandoen:
```
kubeadm init --pod-network-cidr=10.244.0.0/16
```
  Vær sikker på at skrive kommandoen til at deltage i klyngen "kubeadm join ..." som foreslået i bunden af output, eller mindst de angivne tokens.
- Vi installerer en plugin (CNI) til at arbejde med Pod-netværk. Jeg anbefaler at bruge Calico. Måske den mere populære Flannel har kompatibilitetsproblemer med nftables, og også Calico — den eneste CNI-implementering, der anbefales og er fuldt testet af projektet. Kubernetes:
```
kubectl --kubeconfig /etc/kubernetes/admin.conf apply -f https://docs.projectcalico.org/v3.15/manifests/calico.yaml 
```
- For at forbinde worker-noden til vores klynge skal den konfigureres i henhold til punkterne i instruktion 1 og 2, eller ved at bruge script, så udfør kommandoen fra output "kubeadm init ...", som vi skrev i det forrige skridt:
```
kubeadm join $CONTROL_PLANE_ADDRESS:6443 --token $TOKEN 
    --discovery-token-ca-cert-hash $TOKEN_HASH
```
- Lad os kontrollere, at vores klynge er initialiseret og er begyndt at køre:
```
kubectl --kubeconfig=/etc/kubernetes/admin.conf get pods -A
```
Færdig! Du kan allerede placere belastning på din K8s-klynge.

Hvad venter os fremover?

Jeg håber, at ovenstående instruktion har hjulpet dig med at spare lidt tid og nerver.
Udviklingen inden for industrien afhænger ofte af, hvordan den bliver modtaget af flertallet af slutbrugere og udviklere af anden software i den relevante niche. Det er endnu ikke helt klart, hvilken konklusion OCI's initiativer vil føre til om nogle år, men vi ser frem til at følge med i det. Du kan dele dine tanker lige nu i kommentarerne.

Hold dig opdateret!

Denne artikel blev tiltrådt takket være følgende kilder: