🥇CRI-O come sostituto di Docker come ambiente di esecuzione per Kubernetes: configurazione su CentOS 8

Ciao! Mi chiamo Sergey, sono DevOps in Surf. Il dipartimento DevOps di Surf si propone non solo di facilitare la collaborazione tra specialisti e integrare i processi lavorativi, ma anche di condurre ricerche attive e implementare tecnologie attuali sia nella propria infrastruttura che in quella dei clienti.

Di seguito parlerò brevemente delle modifiche nel stack tecnologico per i container, con cui ci siamo imbattuti durante lo studio della distribuzione CentOS 8 e di ciò che è CRI-O e di come configurare rapidamente un ambiente di esecuzione per Kubernetes.

Perché Docker non è presente nella distribuzione standard di CentOS 8

Dopo l'installazione delle ultime versioni principali RHEL 8 o CentOS 8 non si può non notare: in queste distribuzioni e nei repository ufficiali manca l'applicazione Docker, che viene ideologicamente e funzionalmente sostituita dai pacchetti Podman, Buildah (presente nella distribuzione di default) e CRI-O. Questo è legato all'implementazione pratica degli standard sviluppati, tra l'altro, anche da Red Hat nell'ambito del progetto Open Container Initiative (OCI).

L'obiettivo dell'OCI, che è parte della Linux Foundation, è creare standard industriali aperti per i formati e l'ambiente di esecuzione dei container, che risolvano diverse problematiche. In primo luogo, non devono contraddire la filosofia di Linux (ad esempio, in quella sua parte che afferma che ogni programma deve svolgere un'unica azione, mentre Docker rappresenta una sorta di macchina multifunzione). In secondo luogo, dovrebbero eliminare tutte le lacune del software Docker. In terzo luogo, dovrebbero essere completamente compatibili con i requisiti aziendali imposti dalle principali piattaforme commerciali per il deployment, la gestione e il supporto delle applicazioni containerizzate (ad esempio, Red Hat OpenShift).

Svantaggi Docker I benefici del nuovo software sono già stati ampiamente descritti in questo articolo, e una descrizione dettagliata di tutto ciò che viene proposto nell'ambito del progetto OCI e delle sue peculiarità architetturali può essere trovata nella documentazione ufficiale e negli articoli sia di Red Hat stessa (ottimo su Habr. nel blog di Red Hat), sia in recensioni di terze parti È importante notare quale funzionalità abbiano i componenti dello stack proposto:.

— interazione diretta con i container e lo storage delle immagini tramite il processo runC;

Podman — costruzione e caricamento delle immagini nel registro;
Buildah — ambiente di esecuzione per i sistemi di orchestrazione dei container (ad esempio, Kubernetes).
CRI-O — ambiente di esecuzione per sistemi di orchestrazione dei contenitori (ad esempio, Kubernetes).

Penso che per comprendere il diagramma complessivo delle interazioni tra i componenti dello stack sia utile presentare qui uno schema delle connessioni Kubernetes c runC e librerie a basso livello utilizzando CRI-O:

CRI-O e Kubernetes seguono lo stesso ciclo di rilascio e supporto (la matrice di compatibilità è molto semplice: le versioni maggiori Kubernetes e CRI-O coincidono), e questo, tenendo conto dell'obiettivo di un test completo e approfondito del funzionamento di questo stack da parte degli sviluppatori, ci dà il diritto di aspettarci una stabilità massima raggiungibile nel funzionamento in qualsiasi scenario d'uso (qui gioca a favore anche il peso relativamente contenuto CRI-O rispetto a Docker a causa di un'intenzionale limitazione delle funzionalità).

Durante l'installazione Kubernetes nel modo «giusto» (secondo OCI, ovviamente) utilizzando CRI-O in CentOS 8 ci siamo imbattuti in alcune difficoltà minori, che abbiamo però superato con successo. Sarò felice di condividere con voi le istruzioni di installazione e configurazione, che nella loro totalità richiederanno al massimo 10 minuti.

Come distribuire Kubernetes su CentOS 8 utilizzando l'ambiente CRI-O

Requisiti preliminari: almeno un host (2 core, 4 GB di RAM, disco di almeno 15 GB) con installato CentOS 8 (si consiglia di scegliere il profilo di installazione «Server»), e registrazioni DNS locali per esso (nel peggiore dei casi è possibile utilizzare una registrazione in /etc/hosts). E non dimenticate di disabilitare lo swap.

Tutte le operazioni sull'host vengono eseguite come utente root, prestate attenzione.

Nel primo passaggio configureremo il sistema operativo, installeremo e configureremo le dipendenze preliminari per CRI-O.
- Aggiorniamo il sistema operativo:
```
dnf -y update
```
- Successivamente, è necessario configurare il firewall e SELinux. Qui dipende tutto dall'ambiente in cui funzionerà il nostro host o gli host. È possibile configurare il firewall seguendo le raccomandazioni di documentazione, oppure, se ci si trova in una rete fidata o si utilizza un firewall di terze parti, cambiare la zona predefinita in quella fidata o disattivare il firewall:
```
firewall-cmd --set-default-zone trusted

firewall-cmd --reload
```
  Per disattivare il firewall, è possibile utilizzare il seguente comando:
```
systemctl disable --now firewalld
```
  SELinux deve essere disabilitato oppure impostato in modalità «permissiva»:
```
setenforce 0

sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config
```
- carichiamo i moduli del kernel necessari e i pacchetti, configurando il caricamento automatico del modulo «br_netfilter» all'avvio del sistema:
```
modprobe overlay

modprobe br_netfilter

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

dnf -y install iproute-tc
```
- per attivare il forwarding dei pacchetti e per un'elaborazione corretta del traffico, effettueremo le impostazioni necessarie:
```
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
```
  applicheremo le impostazioni effettuate:
```
sysctl --system
```
- imposteremo la versione necessaria CRI-O (versione maggiore CRI-O, come già menzionato, corrisponde alla versione richiesta Kubernetes), poiché l'ultima versione stabile Kubernetes attualmente è la 1.18:
```
export REQUIRED_VERSION=1.18
```
  aggiungeremo i repository necessari:
```
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
```
- ora possiamo installare CRI-O:
```
dnf -y install cri-o
```
  Fai attenzione al primo aspetto che incontriamo durante il processo di installazione: è necessario modificare la configurazione CRI-O prima di avviare il servizio, poiché il componente richiesto conmon ha una posizione di installazione diversa da quella indicata:
```
sed -i 's//usr/libexec/crio/conmon//usr/bin/conmon/' /etc/crio/crio.conf
```
  Ora possiamo attivare e avviare il demone CRI-O:
```
systemctl enable --now crio
```
  Possiamo controllare lo stato del demone:
```
systemctl status crio
```
Installazione e attivazione Kubernetes.
- Aggiungeremo il repository richiesto:
```
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
```
  ora possiamo installare Kubernetes (versioni 1.18, come già indicato sopra):
```
dnf install -y kubelet-1.18* kubeadm-1.18* kubectl-1.18* --disableexcludes=kubernetes
```
- Un secondo aspetto importante: poiché non stiamo utilizzando un demone Docker, ma utilizziamo un demone CRI-O, prima dell'avvio e dell'inizializzazione Kubernetes è necessario apportare le impostazioni nel file di configurazione /var/lib/kubelet/config.yaml, creando prima la cartella necessaria:
```
mkdir /var/lib/kubelet

cat < /var/lib/kubelet/config.yaml
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
cgroupDriver: systemd
EOF
```
- Un terzo punto importante che incontriamo durante l'installazione: nonostante abbiamo specificato il driver utilizzato cgroup, e la sua configurazione tramite argomenti passati kubelet è obsoleta (come indicato chiaramente nella documentazione), dobbiamo aggiungere nel file gli argomenti, altrimenti il nostro cluster non si inizializzerà:
```
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
```
- Ora possiamo attivare il demone kubelet:
```
sudo systemctl enable --now kubelet
```
  Per configurare control-plane o worker nodi in pochi minuti, puoi utilizzare questo script.
È ora di inizializzare il nostro cluster.
- Per inizializzare il cluster, esegui il comando:
```
kubeadm init --pod-network-cidr=10.244.0.0/16
```
  Assicurati di annotare il comando di join al cluster «kubeadm join …», che viene suggerito alla fine dell'output, o almeno i token indicati.
- Installeremo un plugin (CNI) per gestire la rete dei Pod. Ti consiglio di usare Calico. Potrebbe essere più popolare Flannel ha problemi di compatibilità con nftables, e inoltre Calico è l'unica implementazione CNI raccomandata e completamente testata dal progetto Kubernetes:
```
kubectl --kubeconfig /etc/kubernetes/admin.conf apply -f https://docs.projectcalico.org/v3.15/manifests/calico.yaml 
```
- Per collegare un nodo worker al nostro cluster, è necessario configurarlo seguendo i punti 1 e 2 delle istruzioni, oppure utilizzare uno script, quindi eseguire il comando dall'output «kubeadm init …», che abbiamo annotato nella fase precedente:
```
kubeadm join $CONTROL_PLANE_ADDRESS:6443 --token $TOKEN 
    --discovery-token-ca-cert-hash $TOKEN_HASH
```
- Verifichiamo che il nostro cluster sia stato inizializzato e sia attivo:
```
kubectl --kubeconfig=/etc/kubernetes/admin.conf get pods -A
```
Fatto! Puoi già distribuire carichi di lavoro sul tuo cluster K8s.

Cosa ci aspetta in futuro

Spero che le istruzioni sopra ti abbiano aiutato a risparmiare un po' di tempo e nervi.
L'esito dei processi che avvengono nell'industria dipende spesso da come vengono percepiti dalla maggior parte degli utenti finali e dagli sviluppatori di altri software nella relativa nicchia. Non è ancora chiaro quale risultato porteranno in pochi anni le iniziative OCI, ma saremo felici di seguirle. Puoi esprimere la tua opinione proprio ora nei commenti.

Resta sintonizzato!

Questo articolo è stato reso possibile grazie alle seguenti fonti:

Sezione sui Container runtimes in documentazione Kubernetes
Pagina del progetto CRI-O su Internet
Articoli nei blog di Red Hat: questo, questo e molti altri

Fonte: habr.com