CLOUD

COMPUTING

RAPPORT DU TP
KUBERNETES

2022

PRÉPARÉ PAR
HACHHACH MANAL
ZAIMI SOUKAINA
CREATION DE L'INFRASTRUCTURE

Dans cette section, nous avons commencer par créer trois Volumes
dans l'OpenStack avec l'image snap-tpkube-2022 comme Volume
Source. Ensuite, nous avons créer trois machines avec 2 vCPU, 4 Go
de RAM, réseau vlan1383 ou vlan1368 et avec les volumes
précédemment créés comme sources de démarrage .

l'adresse IP du Master Node : 192.168.246.19

DÉPLOIEMENT DU CLUSTER

Dans cette section, nous avons déployer un cluster Kubernetes

avec l'outil RKE (Rancher Kubernetes Engine).

Préparation de nœuds

1.SSH
Nous avons créer une paire de clefs ssh sans passphrase sur le
nœud Master (commande ssh-keygen)

on a ajouté la clef publique (.ssh/id_rsa.pub) du Master au

fichier des clefs autorisées (.ssh/authorized_keys) sur tous les
nœuds (y compris sur le nœud Master).

PAGE 02
Finalement on a testé si le nœud Master arrive à se connecter en
ssh sur tous les nœuds (y compris sur lui-même).

Connection avec la 2ème VM dont l'adresse ip : 192.186.246.85

Connection avec la 3ème VM dont l'adresse ip : 192.168.246.30

2.Proxy
Ajoutez la variable NO_PROXY dans les variables d'environnement
sur toutes les machines
- Ajoutez la ligne à la fin du fichier /etc/environment

PAGE 03
Pour redémarrez toutes les machines : $ sudo reboot , après click
sur R (restart).

Déploiement de Kubernetes avec RKE

nous avons crée un cluster de 3 machines.

La machine Master Node :

La machine n°1 : worker nodes

La machine n°2 : worker nodes

PAGE 03
Démarrez le cluster Kubernetes avec RKE

Installation et configuration de kubectl

Quel est l'état des nœuds ? statut : ready

UTILISATION DU CLUSTER

Création d'un pod

Nous allons commencer par créer un Pod qui est la plus petite
unité que nous pouvons déployer dans le cluster K8s.

Sur quel nœud le Pod a-t-il été lancé ?

sur le noeud : 192.168.246.85

PAGE 04
Vérifiez l'accessibilité du Pod en interrogeant le port 8080 de tous
les nœuds. Que pouvez-vous conclure ? nous pouvons accéder au
pod de n'importe quelle machine en utilisant l'adresse
correspondant

Visualisez les logs du pod

Vous pouvez également exécuter une commande dans n'importe

quel Pod du cluster avec kubectl exec.

Création d'un deployment

Créez cet objet dans le cluster

Quels rôles jouent les labels et les sélecteurs ?

Les labels sont des paires clé/valeur attachées à des objets, tels
que des pods, sont destinées à être utilisées pour spécifier les
attributs d'identification des objets . Elles peuvent être attachées
aux objets au moment de la création, puis ajoutées et modifiées à
tout moment. Chaque objet peut avoir un ensemble d'étiquettes
clé/valeur définies. Chaque clé doit être unique pour un objet
donné.
Les sélecteurs : Via un sélecteur d'étiquettes , le client/utilisateur
peut identifier un ensemble d'objets. Le sélecteur d'étiquettes est
la primitive de regroupement principale dans Kubernetes.
PAGE 05
 Sur quelle image seront basés les conteneurs créés ?
image : nginx

Vous pouvez suivre le processus de déploiement et visualiser l'état

des déploiements avec les commandes

Combien de replicas ont été créés par le déploiement ?

3 replicas

Nous allons mettre à l'échelle votre déploiement pour avoir 6

replicas avec la commande $ kubectl scale deployment nginx-
deployment --replicas=6

Que voyez-vous dans la liste des événements de déploiement ?

dans la liste des évenements de déploiement nous voyons

l'historique des actions réalisées (créations des réplicats)

Visualisez les pods lancées par le déploiement

Comment sont distribués les pods entre les nœuds Workers?
(utilisez l'option -o wide) => distribution equitable

PAGE 06
 Création d'une Service
Quel est l'intérêt de la section selector dans le fichier yaml?
le module contrôleur de Kubernetes va utiliser les paramètres
présents dans la section selector.
À noter que le champ Selector permet des conditions de sélection
multiples qui peuvent être basées sur des logiques combinatoire
le ou les labels que nous utilisons comme selector doivent se
retrouver dans les metadatas du pod… sinon nous risquons d’avoir
un problème.
Que permet de faire un Service de type NodePort?
NodePort : Expose le service sur un port statique sur chaque nœud
du cluster

Créez le service dans le cluster

Détectez quel port est exposé sur les nœuds pour atteindre le
service => port: 32692
Affichez des endpoints du service

Quelles adresses sont affichées dans la liste des ENDPOINTS?

10.42.1.6 - 10.42.1.7 - 10.42.1.8 - 10.42.2.6 - 10.42.2.7 - 10.42.2.8

Vérifiez que le déploiement est bien accessible depuis n'importe

quel nœud du cluster => connexion avec succes

PAGE 07
Vérifier que le service est accessible depuis le Pod nginx-pod créé
précédemment

Rolling Updates

Nous allons modifier les paramètres de déploiement pour faire une

pause de 10 secondes après le déploiement de chaque nouveau Pod
$ kubectl patch deployment nginx-deployment -p '{"spec":
{"minReadySeconds": 10}}'

Rollbacks
nous avons effectué le Rollback de déploiement nginx-deployment
$ kubectl rollout undo deployments nginx-deployment
Suivez le processus de Rollback
$ watch -n 1 curl -I 127.0.0.1:[node_port]
Récupérez l'historique du déploiement
Quelle commande utiliserez-vous ?

PAGE 08
Récupérez l'historique du déploiement
Quelle commande utiliserez-vous ?

Volumes

Créez le Persistent Volume dans le cluster

Que signifie l'accès mode "ReadWriteOnce"?

ReadWriteOnce -- le volume peut être monté en lecture-écriture
par un seul nœud

Visualisez les volumes persistants

Quel est le statut du PV après création ?

statut: available

Quelle est la stratégie de rétention de volume persistant créée

et que signifie-t-elle ?
Retain -- remise en état manuelle
La politique de récupération Retain permet la récupération
manuelle de la ressource. Lorsque le PersistentVolumeClaim est
supprimé, le PersistentVolume existe toujours et le volume est
considéré comme «libéré». Mais il n'est pas encore disponible pour
une autre demande car les données du demandeur précédent
restent sur le volume.

Créez cet objet dans le cluster

Visualisez l'état des Persistant Volumes et Persistant Volume
Claims

Quel est le statut du PV et du PVC après la création de la claim ?

staut du pv et pvc ; Bound
PAGE 09
 Est-ce que deux claims peuvent utiliser le même volume
persistant ?
deux claims ne peuvent pas utiliser le même volume persistant

Maintenant, vous pouvez attacher le PersistantVolumeClaim à un

Pod.
Créez cet objet dans le cluster
Vérifiez que votre pod est lancé
Trouvez un moyen de vérifier que le volume persistent fonctionne
correctement
Comment l'avez-vous vérifié ?
d'après le log et le pod , nous voyons qu'il est lié .

Variables d'environnement

Créez le Pod dans le cluster

Visualisez les logs du pod

Que voyez-vous dans les logs du Pod?

username=administrator

Secrets
fichier secret.yml

PAGE 10
Créez le secret dans le cluster

Créez le fichier pod_with_secret.yml

Visualisez les logs du pod

Init containers

Créez cet objet dans le cluster

Surveillez le déploiement du Pod

Sur quel nœud Worker le Pod a-t-il été lancé (utilisez l'option -o
wide ou la commande kubectl describe pods <NOM_DU_POD>)
le pod a été lancé sur la machine 192.168.246.85

PAGE 11
resultat : kubernetes

Sondes de Liveness et Readiness

1.Liveness probe

Nous avons créer cet objet dans le cluster avec la commande

$ kubectl apply -f liveness_pod.yml
Nous avons supprimez le répertoire /usr/share/nginx à l'intérieur du
Pod liveness-pod
$ kubectl exec -it liveness-pod -- rm -r /usr/share/nginx

PAGE 12
Surveillez les événements et le comportement du Pod liveness-pod

Que fait Kubernetes en cas d'échec de la Liveness probe?

Liveness probe : vérifie si l'application est en bon état de
fonctionnement. Elle est utilisée tout le long de la vie de
conteneur. En cas d'échec, Kubernetes supposera que votre
application est bloquée et la redémarrera.
2.Readiness probe

Créez ces objets dans le cluster

Etudiez le comportement des Pods avec une sonde Readiness

Surveillez les pods

Que remarquez-vous?
statut du pod nginx-nogood : imagePullBackOff
L'état ImagePullBackOffsignifie qu'un pod n'a pas pu démarrer, car
Kubernetes n'a pas pu extraire une image de conteneur.

PAGE 13
Surveillez la liste des endpoints du service

Que remarquez-vous?
Dans nginx-readiness , nous remarquons que nous n'avons qu'une
seule adresse 10.42.2.17:80 alors que nous devrions en avoir 2

Est-ce que le service répond aux requêtes?

Oui, car le service dirige toutes les requêtes de port de nœud vers
le pod

Trouvez et corrigez l'erreur

On a exécuté la commande "describe" , et le problème provient
del'image nginx

PAGE 14
Nous avons corrigé l'image avec la comande :
$ kubectl edit pod nginx-nogood

D'après le screen en dessous , le status du pod nginx-nogood a

passé de l'état imagePullBackOff à l'état Running.

Ainsi dans la liste des endpoints de nginx-readiness , nous avons

obtenu 2 adresses .

Création d'un Ingress

Création de DNS

Nous avons crée cet objet dans le cluster et visualisé la liste des
Ingress

Quelles adresses se trouvent dans le colonne ADDRESS ?

192.168.246.30 et 192.168.246.85
Essayez d'accéder au Service en utilisant le nom DNS
précédemment créé à parir de votre navigateur ou en executant
la commande curl

Que pouvez-vous constater ?

PAGE 15
UN DÉPLOIEMENT PLUS COMPLEXE

Service Redis

PersistantVolume

Nous avons créé un volume persistant avec le nom redis-pv , de

type hostPath, avec une capacité de stockage de 500Mi , le mode
d'accès ReadWriteOnce et un point de montage /mnt/redis.

PersistantVolumeClaim

nous avons créé un PersistantVolumeClaim avec le nom redis-pvc

qui demande un stockage avec une capacité de 500Mi et le mode
d'accès ReadWriteOnce.

Et on vérifié que les états de PersistantVolume et

PersistantVolumeClaim sont Bound

Secret

Créez le Secret avec le nom redis-secret qui a un champ nommé

password. Ce champ doit contenir le mot redispassword qui sera
utilisé comme mot de passe d'authetification Redis. N'oubliez pas
que les secrets doivent être encodés en base64.

PAGE 16
Deployment

Créez un déploiement avec le nom redis-deployment

Verifiez le Deployement et le Pod crée

$ kubectl get deployments
$ kubectl get pods

PAGE 17
Service

Créez un service de type ClusterIP avec le nom redis-service qui

Utilise un selector sur le label app: redis
Transfére le trafic envoyé au port TCP 6379 du Service sur le
port 6379 du Pod

Vous avez créé le service Redis, vous devez maintenant vérifier s'il
fonctionne correctement.
Connectez-vous avec telnet sur le Redis à partir de Pod busybox et
testez si Redis fonctionne correctement

PAGE 18
 Service Redis

Deployment

Service

Verifiez le Service et les Endpoints

$ kubectl get services
$ kubectl get endpoints

Ingress
Créez un Ingress avec le nom counter-ingress et Verifiez

PAGE 19
 Verification de l'application

Pour vérifier le fonctionnement de l'application, vous pouvez

essayer d'y accéder avec votre navigateur en utilisant le nom DNS
créé précédemment et le préfixe /counter.

fichier couter deployment

PAGE 20
fichier ingress

PAGE 21