Installation de kubernetes en environnement de labs, II

Table des matières
show

INSTALLATION DE DOCKER SUR MASTER-NODE

Ce guide a pour objectif de montrer l’installation de Docker CE (Communauty Edition) sur Cent OS 8. Cette opération est strictement la même sur MASTER-NODE, NODE-1 et NODE-2

1.    Etape 0 : Préparation de l’installation de Docker CE :

Etant donné que nous sommes sous Hyper-V, il peut être intéressant de créer un point de contrôle:

Ensuite, avant de commencer : il faut effectuer appliquer toutes les mises à jour disponibles sur Cent OS et redémarrer :

dnf update -y ; reboot

Une fois que le serveur à redémarrer, il faut se connecter en root pour commencer les étapes d’installation à proprement parler.

2.    Etape 1 : Ajouter, activer le repository officiel DOCKER CE et vérifier son ajout :

2.1      Ajout et activation du repository en question :

La commande ci-dessous va ajouter le repository officel de docker :

dnf config-manager –add-repo=https://download.docker.com/linux/centos/docker-ce.repo
2.2      Vérification de l’ajout du repository :

Il faut maintenant s’assurer que le repository en question a été correctement ajouté :

sudo dnf repolist -v

1.1.1. Lister les packages disponibles :

On peut lister les package disponibles dans le repository docker :

dnf list docker-ce –showduplicates | sort -r
2.3      Installer docker ce:

On va demander l’installation de la version la plus adéquate en remplaçant les packets qui pourraient être en conflits :

dnf install docker-ce –nobest–allowerasing

il faudra valider à chaque fois par « o » lorsque l’installer demandera une configuration de l’opération à réaliser.

Ainsi, le résultat de l’opération est ci-dessous :

2.4      Démarrage du service « docker »:

Nous allons démarrer le service « docker », l’autoriser et vérifier son statut :

2.4.1      Démarrage et vérification du service « docker » :

La commande à utiliser est la suivante :

systemctl enable –now docker
2.4.2      Vérification de l’état de fonctionnement du service docker :

Commande :

systemctl status docker
2.5      Ajouter l’utilisateur courant au groupe docker et vérifier que l’ajout est bel et bien effectué :

Ceci permet de donner toutes les autorisations au compte courant :

sudo usermod -aG docker $USER
2.6      Autoriser docker au niveau du firewall :

Afficher les informations sur l’autorisation de docker au niveau du firewall. Pour cela, il sera nécessaire d’utiliser l’IP Masquerading.

2.6.1 Rappel sur l’IP masquerading :

Le masquage d’adresse IP est un processus selon lequel un ordinateur se comporte comme une Passerelle IP pour le réseau.Tous les ordinateurs du réseau envoient leurs paquets IP au travers de cette passerelle, qui va remplacer les adresses IP sources avec sa propre adresse IP et ensuite les transférer sur Internet.

Une passerelle IP fait référence à un périphérique réseau dont le rôle est de transférer le traffic réseau vers d’autres réseaux. Il semble que le deamon docker a déjà effectué cette modification à au sein de iptables, mais apparemment, il semble nécessaire d’active cela spécifiquement pour les zones du firewall pour que le masquerading de iptables puisse fonctionner .

2.6.2      Activer le masquerading et configurer le firewall pour docker :

il faut donc :

Autoriser le masquerading pour le réseau docker ingress et egress :

firewall-cmd –zone=public –add-masquerade –permanent

Autoriser spécifiquement le traffic entrant sur les ports 80 et 44

firewall-cmd –zone=public –add-port=80/tcp
firewall-cmd –zone=public –add-port=443/tcp

Recharger le firewall pour l’application des règles permanentes

firewall-cmd –reload

2.6.2.1      Alternative :

Il est aussi possible de placer « docker0 » dans la trusted zone pour le séparer de tout le reste et ensuite ajouter le masquerading :

firewall-cmd –zone=trusted –change-interface=docker0
firewall-cmd –zone=trusted –add-masquerade –permanent
firewall-cmd –reload
2.7      Redémarrer docker :

Il faut redémarrer docker pour que les modifications puissent être prise en compte :

systemctl restart docker
2.8      Vérification du fonctionnement de docker

On peut vérifier que docker est proprement installé et fonctionne correctement :

docker info 

On va ensuite télécharger l’image hello-world :

docker run hello-world

On peut utiliser les autres commandes pour vérifier que notre image est présente, a été téléchargée, et le container que nous venons d’exécuter est dans l’état « exited » :

docker images
docker ps -a
2.8.1      Les suppléments pour tester docker :

Démarrage et mise à jour de l’image alpinel

docker  run -it –rm –name alpone alpine sh             
apk update

Installation de curl, wget, vim, nano et bash sur l’image alpine :

2.8.2      Ajouter des packages à votre dockere file :

INSTALLATION DE KUBERNETES ET ACTIVATION DU MASTER NODES

Il est maintenant question d’installer kubernetes (kubeadm) sur le master-node. Il va être intéressant de réaliser cette configuration à partir d’une session SSH. Pour cela, il faut utiliser putty et se connecter au master-node ;

1.    Désactivation de SELinux :

La désactivation de SELinux est nécessaire pour permettre aux containers d’accéder au système de fichier de l‘hôte, ce qui est nécessaire pour le fonctionnement des pods et autres services.

sed -i –follow-symlinks ‘s/SELINUX=enforcing/SELINUX=disabled/g’ /etc/sysconfig/selinux
reboot

2.    Configuration du firewall :

kubernetes utilise différents ports de communication et d’accès et ses ports doivent être autorisés au sein du firewall pour que kubernetes ne soit pas limité par le firewall. Ci-dessous, le tableau des ports utilisés par kubernetes :

Pour autoriser les ports de kubernetes au sein du firewall, il faut utiliser les commandes ci-dessous :

firewall-cmd –permanent –add-port=6443/tcp
firewall-cmd –permanent –add-port=2379-2380/tcp
firewall-cmd –permanent –add-port=10250/tcp
firewall-cmd –permanent –add-port=10251/tcp
firewall-cmd –permanent –add-port=10252/tcp
firewall-cmd –permanent –add-port=10255/tcp
firewall-cmd –reload
modprobe br_netfilter
echo ‘1’ > /proc/sys/net/bridge/bridge-nf-call-iptables

3.    Préparation de l’installation de kubernetes :

3.1      Préparation de l’installation de kubernetes :

Pour préparer l’installation de kubernetes, il faut manuelle rajouter les repositories de kubernetes vu qu’ils ne viennent pas installés par défaut sur CentOS 8 :

cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
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
EOF

4.    Installation et configuration de kubernetes :

Installer kubernetes consiste à installer kubeadm. L’installation de kubeadm va bootstrapper un cluster kubernetes minimum viable, qui est conforme aux meilleures pratiques. Avec kubeadm, le cluster en cours d’installation va passer les tests de conformité de kubernetes.

Kubeadm supporte aussi les fonctions de cycle de vie telles que les mises à jour, les downgrade et la gestion des jetons de bootstrap. Il permet aussi une intégration simplifé avec d’autres outils d’orchestration tels que Ansible et Terraform.

4.1      Installation de kubernetes :

La commande ci-dessous va installer kubernetes :

dnf install kubeadm -y

4.2      Démarrage et autorisation du service :

Il est temps de démarrer et d’autoriser le service kubelet :

systemctl enable kubelet
systemctl start kubelet

5.    Initialisation du cluster et création du Control plane Master avec kubeadm :

Le master kubernetes va agir en tant que control pane pour exécuter les services critiques nécessaires au fonctionnement du cluster. Le processus d’initialisation va effectuer une série de precheck pour s’assurer que chaque machine est prête pour exécuter Kubernetes. Ses prechecks exposent des avertissements et s’arrêtent sur les erreurs. Kubeadm init va alors télécharger et installer les composants du control pane du cluster.

Il est temps d’initialiser le master kubernetes, mais avant cela, il faut désactiver le swap sinon la commande kubeadm init ne fonctionnera pas. Une fois le swap désactivé, il sera alors possible d’initialiser le cluster le master.

5.1      Désactivation du swap :

IL y a 2 possibilités de désactivation du swap :

  • Désactivation momentanée du swap : Dans ce cas, si le serveur est redémarré, le swap sera à nouveau actif. Si le swap est réactivé lors du démarrage du serveur, le master ne démarrera pas ;
  • Désactivation permanente du swap : Dans ce cas, le swap restera désactivé;
5.1.1      Option 1 : Désactivation momentanée du swap :

Dans un premier temps, il faut afficher le degré de la charge de la mémoire et identifier la partition qui héberge la zone de swap à l’aide de la commande suivante :

free -h

Ensuite, il faut lance la commande blkid, il faut regarder la ligne TYPE= »swap » dans l’objectif d’identifier la partition swap, tels que présenté dans la capture d’écran ci-dessous :

blkid

Sur notre master actuel, notre swap est situé ici « /dev/mapper/cl-swap ».

Ensuite, il faut utiliser la commande lsblk pour rechercher et identifier la partition [SWAP] telles que présentées dans la capture d’écran ci-dessous :

lsblk

Après avoir identifié la partition ou le fichier de swap, il faut exécuter la commande ci-dessous pour désactiver la zone de swap :

swapoff /dev/mapper/cl-swap

Il est aussi possible de désactiver le swap tous les swaps :

Swapoff -a

Ensuite, on va vérifier que le swap a été désactivé :

5.1.2      Option 2 : Désactivation permanente du swap :

Pour désactiver le swap de façon permanente, il faut ouvrir le fichier/etc/fstab, rechercher la ligne du swap et la commenter à l’aide du « # » :

vim /etc/fstab

Ensuite, il faut redémarrer ou appliquer les nouveaux paramètres de configuration du swap à l’aide de la commande « mount -a » (dans certains cas, elle peut ne pas fonctionner):

reboot

Ou

mount -a

Une fois le redémarrage effectué, il faut vérifier que le swap a été complètement désactivé de manière permanente :

free -h
5.2      Initialisation du master :

Maintenant que le swap est désactivé, il est possible d’utiliser la commande kubeadm init pour initialiser ou le master :

kubeadm init

Cette commande va vous fournir la commande permettant d’ajouter des nœuds workers à votre cluster, en vous indiquant le token que vous allez utiliser avec la commande kubeadm join :

5.2.1      Possibilités d’erreurs :

Il existe des possibilités d’erreurs lorsque vous lancez la commande kubeadmin.

5.3      Autoriser les utilisateurs à utiliser le cluster kubernetes :

Une fois le cluster initialiser, il faut permettre aux utilisateurs d’utiliser le cluster. Il est possible de :

  • Autoriser l’utilisateur root d’utiliser le cluster ;
  • Autoriser un sudouser d’utiliser le cluster ;

Les 2 sections suivantes vont montrer comment réaliser ses 2 opération :

5.3.1      Autoriser le root à utiliser le cluster :

Pour permettre au root d’utiliser le cluster, il faut utiliser les commandes ci-dessous :

mkdir -p $HOME/.kube

Puis :

cp -i /etc/kubernetes/admin.conf $HOME/.kube/config

Puis :

chown $(id -u):$(id -g) $HOME/.kube/config
5.3.2      Autoriser un sudouser à utiliser le cluster :

Il est aussi possible d’ajouter un sudo user :

mkdir -p $HOME/.kube
cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
chown $(id -u):$(id -g) $HOME/.kube/config
5.4      Vérification de l’activation de la commande « kubectl » :

Maintenant, on va vérifier que la commande « kubectl » est activée. A ce moment-là, le status du master-node est « NotReady ». Ceci parce que le réseau de pod n’a pas encore été déployé.

kubectl get nodes

Le réseau de pods est le réseau superposé du cluster, qui est déployé au-dessus du réseau de nœud actuel. Il est conçu pour permettre la connectivité réseau à travers le pods. Dans la prochaine section nous allons configurer le réseau des Pods.

6.    Configuration du réseau des pods :

Déployer un réseau de cluster est un processus hautement flexible dépendant de nos besoins et il existe plusieurs options disponibles. Vu que nous voulons maintenir notre installation le plus simple possible alors nous allons utiliser « Weavenet » plugin qui ne va requérir aucune configuration ou code supplémentaire et fournir une adresse IP par pod (ce qui nous arrange). Vous pouvez voir plus d’options, regardez ici : cliquez ici .

Les commandes ci-dessous vont permettre de configurer le réseau de pods :

Maintenant, on va vérifier l’état de notre master-node qui devrait être à ready.

7.    Récupération de la commande et du token de jonction des worker et du token :

Les tokens de bootstrap sont utilisés pour établir une relation de confiance bidirectionnelle entre un nœud rejoingnant le cluster et un nœud control-plane (Master). Lors de l’initialisation du cluster kubernetes avec kubeadm init sur le master, la commande de jonction est générée avec un token de sécurité disponible sur 24H. il est possible de regénérer ce token et la commande de jonction si nécessaire.

Il faut pour cela utiliser la commande kubeadm token create avec le paramètre –print-join-command. On va rediriger le flux de sortie de la commande dans le fichier /data/joinkube.txt . Ceci permettra de récupérer la commande de jonction et le token correspondant depuis infra-router pour la copier dans l’invite de putty correspondant aux worker node-1 et node-2 ;

kubeadm token create –print-join-command >> /data/joinkube.txt

On peut se rendre sur infra-router pour récupérer la commande de jonction et le token correspondant.

Il sera donc possible de copier et coller cette commande dans putty au moment de joindre le node-1 et le node-2 au control-plane. Dans cette procédure, cette jonction s’effectue exactement :

  • ici pour le node-1 : jonction du node-1 ;
  • et ici pour le node-2 : jonction du node-2;

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *