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

Ciao! Mi chiamo Sergey, sono DevOps in Surf. Il dipartimento DevOps di Surf ha come obiettivo non solo il miglioramento della collaborazione tra specialisti e l'integrazione dei flussi di lavoro, ma anche la ricerca attiva e l'implementazione di tecnologie attuali nella propria infrastruttura e in quella dei clienti.

Di seguito parlerò un po' dei cambiamenti nel stack tecnologico per i container che abbiamo incontrato durante lo studio della distribuzione CentOS 8 e di cosa sia CRI-O e come configurare rapidamente un ambiente di esecuzione utilizzando esso per Kubernetes.

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

Dopo aver installato gli ultimi importanti rilasci RHEL 8 o CentOS 8 non si può non notare: in queste distribuzioni e nei repository ufficiali manca l'applicazione Docker, che ideologicamente e funzionalmente sostituisce i pacchetti Podman, Buildah (presenti nella distribuzione di default) e CRI-O. Questo è dovuto all'attuazione pratica degli standard sviluppati, tra l'altro, dalla Red Hat nell'ambito del progetto Open Container Initiative (OCI).

L'obiettivo di OCI, parte della Linux Foundation, è creare standard industriali aperti per formati e ambienti di esecuzione dei container che affrontino diverse problematiche. Innanzitutto, non devono contraddire la filosofia di Linux (ad esempio, nella sua parte che afferma che ogni programma deve svolgere un'unica funzione, e rappresentano un tipo di "tutto in uno"). Docker In secondo luogo, devono eliminare tutte le attuali carenze nel software. DockerIn terzo luogo, devono essere completamente compatibili con i requisiti aziendali imposti dalle principali piattaforme commerciali per il deployment, la gestione e la manutenzione delle applicazioni containerizzate (ad esempio, Red Hat OpenShift).

Svantaggi Docker I vantaggi del nuovo software sono stati già ampiamente descritti in questo articolo, e una descrizione dettagliata di tutto ciò che viene offerto nel progetto OCI, insieme alle sue caratteristiche architettoniche, è disponibile nella documentazione ufficiale e in articoli sia di Red Hat (un'ottima articolo nel blog di Red Hat), che di fonti esterne. le recensioni.

È importante notare quali funzionalità hanno i componenti del stack proposto:

Podman — interazione diretta con i container e lo storage delle immagini tramite il processo runC;
Buildah — costruzione e caricamento delle immagini nel registro;
CRI-O — ambiente di esecuzione per sistemi di orchestrazione dei container (ad esempio, Kubernetes).

Penso che sia utile fornire qui uno schema delle relazioni per comprendere l'architettura generale dell'interazione tra i componenti dello stack. 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, considerando l'obiettivo di un test completo e approfondito del funzionamento di questo stack da parte degli sviluppatori, ci dà il diritto di aspettarci la massima stabilità operativa in tutti gli scenari d'uso (qui gioca a favore anche la relativa leggerezza CRI-O rispetto a Docker a causa della limitazione mirata delle funzionalità).

Durante l'installazione di Kubernetes in modo 'giusto' (secondo OCI, naturalmente) utilizzando CRI-O con CentOS 8 abbiamo incontrato alcune difficoltà, che comunque abbiamo superato con successo. Sarò felice di condividere con voi le istruzioni per l'installazione e la configurazione, che insieme richiederanno al massimo 10 minuti.

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

Prerequisiti: almeno un host (2 core, 4 GB di RAM, disco di almeno 15 GB) con installato CentOS 8 (si consiglia il profilo di installazione "Server"), e una registrazione per esso nel DNS locale (in casi estremi, è possibile utilizzare una registrazione in /etc/hosts). E non dimenticate di disattivare lo swap.

Tutte le operazioni sull'host devono essere eseguite come utente root, prestare attenzione.

Nella prima fase configureremo il sistema operativo, installeremo e configureremo le dipendenze preliminari per CRI-O.
- Aggiorniamo il sistema operativo:
```
dnf -y update
```
- Dopo, è necessario configurare il firewall e SELinux. Qui dipende tutto dall'ambiente in cui lavoreranno il nostro host o gli host. Puoi o configurare il firewall seguendo le raccomandazioni di documentazione, oppure, se ti trovi in una rete fidata o utilizzi un firewall di terze parti, cambiare la zona predefinita in fidata o disattivare il firewall:
```
firewall-cmd --set-default-zone trusted

firewall-cmd --reload
```
  Per disattivare il firewall, puoi utilizzare il seguente comando:
```
systemctl disable --now firewalld
```
  SELinux deve essere disabilitato o impostato in modalità "permissive":
```
setenforce 0

sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config
```
- installeremo i moduli del kernel e i pacchetti necessari, configureremo 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 l'inoltro dei pacchetti e gestire correttamente il traffico, faremo le impostazioni corrispondenti:
```
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 principale CRI-O, come già accennato, corrispondono alla versione richiesta Kubernetes), poiché l'ultima versione stabile Kubernetes attualmente è 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 dettaglio 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 differente da quella indicata:
```
sed -i 's\/usr\/libexec\/crio\/conmon\/\/usr\/bin\/conmon\/' \/etc\/crio\/crio.conf
```
  Ora è possibile attivare e avviare il demone CRI-O:
```
systemctl enable --now crio
```
  È possibile controllare lo stato del demone:
```
systemctl status crio
```
Installazione e attivazione Kubernetes.
- Aggiungiamo 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 importante aspetto: poiché non utilizziamo il demone Docker, ma utilizziamo il demone CRI-O, prima dell'avvio e dell'inizializzazione Kubernetes è necessario apportare le configurazioni necessarie 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 importante aspetto che affrontiamo durante l'installazione: nonostante abbiamo specificato il driver utilizzato cgroup, e la sua configurazione tramite argomenti forniti kubelet è obsoleta (come indicato esplicitamente nella documentazione), dobbiamo aggiungere gli argomenti al file, altrimenti il nostro cluster non verrà inizializzato:
```
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 usare questo script.
È ora di inizializzare il nostro cluster.
- Per inizializzare il cluster, eseguire il comando:
```
kubeadm init --pod-network-cidr=10.244.0.0/16
```
  Assicurati di annotare il comando per unirti al cluster «kubeadm join …», suggerito alla fine dell'output, oppure, almeno, i token indicati.
- Installeremo il plugin (CNI) per il funzionamento della Pod network. Raccomando di utilizzare Calico. Potrebbe essere più popolare Flannel ha problemi di compatibilità con nftables, e poi Calico — l'unica implementazione CNI consigliata e completamente testata dal progetto Kubernetes:
```
kubectl --kubeconfig /etc/kubernetes/admin.conf apply -f https://docs.projectcalico.org/v3.15/manifests/calico.yaml 
```
- Per connettere il nodo worker al nostro cluster, è necessario configurarlo seguendo i punti delle istruzioni 1 e 2, oppure utilizzare per connetterci a WinRM. Apriamo e modifichiamo i parametri per la connessione., 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 operativo:
```
kubectl --kubeconfig=/etc/kubernetes/admin.conf get pods -A
```
Fatto! Ora puoi distribuire il tuo carico di lavoro sul tuo cluster K8s.

Cosa ci aspetta nel prossimo futuro

Spero che le istruzioni sopra ti abbiano aiutato a risparmiare un po' di tempo e nervi.
L'esito dei processi in corso nell'industria dipende spesso da come vengono ricevuti dalla maggior parte degli utenti finali e dagli sviluppatori di altro software nella relativa nicchia. Non è ancora chiaro quale sarà il risultato delle iniziative OCI tra qualche anno, ma saremo felici di seguire il loro sviluppo. Puoi condividere la tua opinione direttamente nei commenti.

Rimanete sintonizzati!

Questo articolo è stato realizzato grazie alle seguenti fonti: