CRI-O comme alternative à Docker en tant qu'environnement d'exécution pour Kubernetes : configuration sur CentOS 8

Bonjour ! Je m'appelle Serge, je suis DevOps chez Surf. Le département DevOps de Surf a pour mission non seulement de faciliter la coopération entre les spécialistes et d'intégrer les processus de travail, mais aussi de mener des recherches actives et d'implémenter des technologies actuelles tant dans notre propre infrastructure que dans celle de nos clients.

Ci-dessous, je vais vous parler des changements apportés à la pile technologique pour les conteneurs que nous avons rencontrés lors de l'étude de la distribution. CentOS 8 et de ce qu'est CRI-O et comment configurer rapidement un environnement d'exécution avec son aide. Kubernetes.

Pourquoi Docker est-il absent de l'installation standard de CentOS 8 ?

Après avoir installé les dernières versions majeures de RHEL 8 ou CentOS 8 on ne peut s'empêcher de remarquer : dans ces distributions et dans les dépôts officiels, l'application Docker, qui remplacent idéologiquement et fonctionnellement les paquets Podman, Buildah (présents par défaut dans la distribution) et CRI-O. Cela est dû à la mise en œuvre pratique des normes élaborées, y compris par Red Hat dans le cadre du projet Open Container Initiative (OCI).

L'objectif de l'OCI, qui fait partie de The Linux Foundation, est de créer des normes industrielles ouvertes pour les formats et les environnements d'exécution de conteneurs qui répondent à plusieurs objectifs. Premièrement, ils ne doivent pas contredire la philosophie de Linux (par exemple, dans sa partie qui stipule que chaque programme doit effectuer une seule tâche, alors que Docker représente un genre de machine polyvalente). Deuxièmement, ils devraient pouvoir éliminer tous les défauts existants dans le logiciel. DockerTroisièmement, ils devraient être entièrement compatibles avec les exigences commerciales imposées par les principales plateformes commerciales pour le déploiement, la gestion et la maintenance des applications conteneurisées (comme Red Hat OpenShift).

Inconvénients Docker et les avantages du nouveau logiciel ont déjà été décrits en détail dans cet article, et une description détaillée de l'ensemble de la pile logicielle proposée dans le cadre du projet OCI et de ses caractéristiques architecturales peut être trouvée dans la documentation officielle et dans des articles tant de Red Hat (une bonne article dans le blog de Red Hat), que d'autres sources. revues.

Il est important de noter quelles fonctionnalités possèdent les composants de la pile proposée :

• Podman — interaction directe avec les conteneurs et le stockage d'images via le processus runC ;
• Buildah — construction et chargement d'images dans un registre ;
• CRI-O — un environnement d'exécution pour les systèmes d'orchestration de conteneurs (par exemple, Kubernetes).

Je pense qu'il est utile de fournir ici un schéma des interactions entre les composants de la pile pour comprendre l'ensemble. Kubernetes c runC et des bibliothèques de bas niveau en utilisant CRI-O:

CRI-O et Kubernetes suivent le même cycle de version et de support (la matrice de compatibilité est très simple : les versions majeures Kubernetes et CRI-O coïncident), ce qui, compte tenu de l'objectif d'un test complet et approfondi du fonctionnement de cette pile par les développeurs, nous donne le droit d'attendre une stabilité maximale dans le fonctionnement dans tous les scénarios d'utilisation (la légèreté relative CRI-O par rapport à Docker en raison d'une limitation ciblée des fonctionnalités).

Lors de l'installation Kubernetes la méthode « right way » (selon OCI, bien sûr) en utilisant CRI-O sur CentOS 8 nous avons rencontré quelques difficultés que nous avons toutefois surmontées avec succès. Je serai heureux de partager avec vous un guide d'installation et de configuration qui ne prendra au total pas plus de 10 minutes.

Comment déployer Kubernetes sur CentOS 8 en utilisant l'environnement CRI-O

Conditions préalables : un hôte avec au moins 2 cœurs, 4 Go de RAM et un stockage d'au moins 15 Go installé, CentOS 8 (le profil d'installation « Server » est recommandé), ainsi qu'une entrée pour lui dans le DNS local (vous pouvez, en dernier recours, vous contenter d'une entrée dans /etc/hosts). Et n'oubliez pas de désactiver le swap.

Toutes les opérations sur l'hôte sont effectuées sous le compte de l'utilisateur root, soyez vigilant.

1. À la première étape, nous allons configurer le système d'exploitation, installer et configurer les dépendances préliminaires pour CRI-O.
   • Mettons à jour le système d'exploitation :

     dnf -y update
     

   • Ensuite, il est nécessaire de configurer le pare-feu et SELinux. Tout dépend ici de l'environnement dans lequel notre hôte ou les hôtes fonctionneront. Vous pouvez soit configurer le pare-feu selon les recommandations de documentation, soit, si vous êtes dans un réseau de confiance ou si vous utilisez un pare-feu tiers, changer la zone par défaut en zone de confiance ou désactiver le pare-feu :

     firewall-cmd --set-default-zone trusted
     
     firewall-cmd --reload

     Pour désactiver le pare-feu, vous pouvez utiliser la commande suivante :

     systemctl disable --now firewalld
     

     SELinux doit être désactivé ou mis en mode « permissive » :

     setenforce 0
     
     sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config

   • nous chargerons les modules et les paquets du noyau nécessaires, et nous configurerons le chargement automatique du module « br_netfilter » au démarrage du système :

     modprobe overlay
     
     modprobe br_netfilter
     
     echo "br_netfilter" >> /etc/modules-load.d/br_netfilter.conf
     
     dnf -y install iproute-tc
     

   • Pour activer le forwarding des paquets et traiter correctement le trafic, nous allons effectuer les réglages nécessaires :

     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
     

     Appliquons les réglages effectués :

     sysctl --system

   • Définissons la version requise CRI-O (version majeure CRI-O, comme mentionné précédemment, coïncide avec la version requise Kubernetes), car la dernière version stable Kubernetes actuellement est 1.18 :

     export REQUIRED_VERSION=1.18
     

     Ajoutons les dépôts nécessaires :

     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

   • Maintenant nous pouvons installer CRI-O:

     dnf -y install cri-o
     

     Faites attention au premier point que nous rencontrons lors de l'installation : il faut modifier la configuration CRI-O avant de démarrer le service, car le composant requis conmon a un emplacement différent de celui spécifié :

     sed -i 's//usr/libexec/crio/conmon//usr/bin/conmon/' /etc/crio/crio.conf

     Nous pouvons maintenant activer et démarrer le démon CRI-O:

     systemctl enable --now crio
     

     Vous pouvez vérifier l'état du démon :

     systemctl status crio
     

2. Installation et activation Kubernetes.
   • Ajoutons le dépôt requis :

     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
     

     Nous pouvons maintenant installer Kubernetes (versions 1.18, comme indiqué précédemment) :

     dnf install -y kubelet-1.18* kubeadm-1.18* kubectl-1.18* --disableexcludes=kubernetes

   • Un deuxième point important : puisque nous n'utilisons pas de démon Docker, mais utilisons un démon CRI-O, avant de démarrer et d'initialiser Kubernetes il est nécessaire d'apporter les réglages appropriés dans le fichier de configuration /var/lib/kubelet/config.yaml, après avoir créé le répertoire requis :

     mkdir /var/lib/kubelet
     
     cat < /var/lib/kubelet/config.yaml
     apiVersion: kubelet.config.k8s.io/v1beta1
     kind: KubeletConfiguration
     cgroupDriver: systemd
     EOF

   • Un troisième point important que nous rencontrons lors de l'installation : même si nous avons spécifié le pilote utilisé cgroup, et que sa configuration via des arguments transmis kubelet est obsolète (comme l'indique clairement la documentation), nous devons ajouter dans le fichier des arguments, sinon notre cluster ne s'initialisera pas :

     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

   • Nous pouvons maintenant activer le démon kubelet:

     sudo systemctl enable --now kubelet
     

     Pour configurer plan de contrôle ou travailleur les nœuds en quelques minutes, vous pouvez utiliser ce script.

3. Il est temps d'initialiser notre cluster.
   • Pour initialiser le cluster, exécutez la commande :

     kubeadm init --pod-network-cidr=10.244.0.0/16
     

     Assurez-vous de noter la commande pour rejoindre le cluster « kubeadm join … », qui est suggérée à la fin de la sortie, ou au minimum, les jetons indiqués.

   • Installons le plugin (CNI) pour le fonctionnement du réseau Pod. Je recommande d'utiliser Calico. Peut-être que le plus populaire Flannel a des problèmes de compatibilité avec nftables, et Calico est la seule implémentation CNI recommandée et entièrement testée par le projet Kubernetes:

     kubectl --kubeconfig /etc/kubernetes/admin.conf apply -f https://docs.projectcalico.org/v3.15/manifests/calico.yaml 

   • Pour connecter un nœud de travail à notre cluster, il doit être configuré selon les étapes 1 et 2 de l'instruction, ou utiliser le script, puis exécutez la commande de sortie « kubeadm init … », que nous avons notée à l'étape précédente :

     kubeadm join $CONTROL_PLANE_ADDRESS:6443 --token $TOKEN 
         --discovery-token-ca-cert-hash $TOKEN_HASH

   • Vérifions que notre cluster est initialisé et fonctionne :

     kubectl --kubeconfig=/etc/kubernetes/admin.conf get pods -A
     

   C'est bon ! Vous pouvez déjà déployer des charges de travail sur votre cluster K8s.

Que nous réserve l'avenir

J'espère que le guide ci-dessus vous a fait gagner un peu de temps et de nerfs.
L'issue des processus dans l'industrie dépend souvent de la façon dont ils sont acceptés par la majorité des utilisateurs finaux et des développeurs d'autres logiciels dans la niche concernée. Il n'est pas encore clair où mèneront les initiatives OCI dans quelques années, mais nous serons ravis de suivre cela. Vous pouvez partager votre avis dès maintenant dans les commentaires.

Restez à l'écoute !

Cet article est issu des sources suivantes :

• La section sur les runtimes de conteneurs dans documentation Kubernetes
• La page du projet CRI-O sur Internet
• Des articles de blogs Red Hat : celui-ci, celui-ci et bien d'autres

Source : habr.com