Créer un dossier « lab09 » et se mettre dans ce dossier.
mkdir lab09
cd lab09
Comme la gestion de stockage par défaut sur minikube est très basique et il ne couvre pas bien les cas d’un cluster avec des nœuds multiples. On va supprimer le node worker « kubelabs-m02 » pour cette partie.
Pour effectuer cette procédure d’une manière sécurisée on va commencer par drainer et défaire le node de cluster K8s:
kubectl get nodes
kubectl drain kubelabs-m02 --ignore-daemonsets
kubectl uncordon kubelabs-m02
Ensuite on va supprimer ce node sur minikube
minikube node list
minikube node delete kubelabs-m02
Vérifiez que le clister contient qu’un nœud
kubectl get nodes
« Helm » est un gestionnaire de paquet pour k8s. Il permet d’installer des paquets sans faire des copier-coller pénibles de YAML :
arkade get helm
sudo mv /home/ubuntu/.arkade/bin/helm /usr/local/bin/
Testez l’installation
helm version
Dans cette partie on va installer un cms wordpress avec helm.
Cherchez un chart « wordpress » dans https://artifacthub.io/
Prenez la version de dépot « bitnami » et ajoutez le dépôt
helm repo add bitnami https://charts.bitnami.com/bitnami
Listez les dépôts
helm repo update
helm repo list
Cherchez une release
helm search repo wordpress
L’installation d’un package avec Helm se fait avec la commande helm suivie des options suivantes :
Afin d’installer WordPress, lancez la commande suivante:
helm install wpblog bitnami/wordpress
Helm va renvoyer un résumé des éléments qui seront créés lors de l’installation. On retrouve ainsi les pods, les services, les volumes persistants, etc.
Enfin, le package a été déployé dans l’espace de noms par défaut (default).
Donc l’application a été déployée dans l’espace de noms par défaut (default) avec un nom générique. Afin de prendre de bonnes habitudes, l’installation du WordPress va être refaite en respectant les bonnes pratiques suivantes:
Supprimez l’installation
helm uninstall wpblog
Listez et supprimez aussi les volumes
kubectl get pvc
kubectl delete pvc data-wpblog-mariadb-0
Ensuite refaites l’installation avec un « namespace » et un nom « wpblog ».
Mais avant l’installation on peut afficher les variables qui sont paramétrable pour cette application avec la commande suivante:
helm show values bitnami/wordpress
Lancez l’installation avec les valeurs personnalisées
helm install wpblog bitnami/wordpress \
--namespace intranet \
--create-namespace \
--set mariadb.primary.persistence.size=4Gi,persistence.size=6Gi
Basculez sur le nouveau « namespace » « intranet »
kubens intranet
Listez les déploiements
helm ls
Listez les ressources déployées
kubectl get all -l "app.kubernetes.io/instance=wpblog"
Vous avez remarqué que le service par défaut utilisé pour celle application est de type « LoadBalancer ».
Mettez à jour l’application pour l’exposer avec un service de type « NodePort » et ignorer l’erreur concernant le « StatefulSet ».
helm upgrade wpblog bitnami/wordpress --set service.type=NodePort
Listez les services et vérifiez que le type a été modifié
kubectl get services
Listez les valeurs qu’on vient de personnaliser
helm get values wpblog
Accédez à l’application avec le « port-forwarding »
kubectl port-forward --address 0.0.0.0 services/wpblog-wordpress 8081:80
Ouvrez l’interface via http://[LAB_ENVIRONMENT_IP]:8081
Recuperze l’uilisateur et le mot de passe pour se connecter à l’interface d’administration « wordpress »
http://[LAB_ENVIRONMENT_IP]:8081/wp-admin
Nettoyez les ressources
helm uninstall wpblog
kubectl get pvc
kubectl delete pvc data-wpblog-mariadb-0
Refaites le déploiement de l’application « WordPress » avec la personnalisation des variables suivantes :
https://artifacthub.io/packages/helm/bitnami/wordpress?modal=values-schema
Créez un fichier values.yaml et renseignez les variables à personnaliser dans ce fichier.
Effectuez l’installation avec la commande suivante:helm install wpblog bitnami/wordpress --values=values.yaml
Accédez à l’application et testez les accès.
Pour savoir ce que nous venons d’installer, faites un rendu (templating) des fichiers du chart dans un grand fichier à la racine du projet en lançant:
helm template wpblog bitnami/wordpress --values=values.yaml >> wpblog-fullresources.yaml
On peut maintenant lire les fichier K8s déployés et ainsi apprendre de nouvelles techniques et syntaxes. En le parcourant on peut constater que la plupart des objets abordés pendant cette formation y sont présent plus certains autres.
Nettoyez les ressources
Dans cette partie on va créer un helm chart pour l’application «mailhog». La création d’un package se fait à l’aide de la commande helm suivie des options suivantes :
Pour créer un chart pour l’application «mailhog», lancez la commande suivante :
helm create mailhog
Par défaut, cette commande réalise les opérations suivantes :
tree mailhog/
mailhog/
├── Chart.yaml
├── charts
├── templates
│ ├── NOTES.txt
│ ├── _helpers.tpl
│ ├── deployment.yaml
│ ├── hpa.yaml
│ ├── ingress.yaml
│ ├── service.yaml
│ ├── serviceaccount.yaml
│ └── tests
│ └── test-connection.yaml
└── values.yaml
Ce répertoire contient les éléments suivants :
Le contenu des variables par défaut du fichier « values.yaml » est disponible à l’aide de la structure « .Values ». Pour accéder à la variable replicaCount de ce fichier, vous pourrez faire appel à la référence «.Values.replicaCount ».
La variable «. Chart » va contenir quant à elle la version déployée ou la version du chart.
Enfin, la « variable.Release » va contenir des informations sur l’espace de noms.
Le chart a été généré. Il faut maintenant l’adapter au cas de l’application « mailhog » en réalisant les modifications suivantes :
Cette partie se fait au niveau du fichier values.yaml. Dans la variable image, modifiez le contenu des champs suivants :
Ci-dessous la déclaration de la variable image après la modification:
image:
repository: mailhog/mailhog
pullPolicy: IfNotPresent
# Overrides the image tag whose default is the chart appVersion.
tag: "v1.0.0"
Toujours dans le fichier values.yaml, les modifications suivantes seront réalisées dans la déclaration de la variable service :
Ci-dessous le champ service suite à cette modification:
service:
type: ClusterIP
port: 8025
smtp:
port: 1025
Au niveau du fichier service.yaml, le champ ports sera modifié de la manière suivante :
Ci-dessous le champ ports suite à ces modifications:
ports:
- port: {{ .Values.service.port }}
targetPort: http
protocol: TCP
name: http
- port: {{ .Values.service.smtp.port }}
targetPort: smtp
protocol: TCP
name: smtp
Au niveau du fichier « deployment.yaml », le champ ports sera modifié de la manière suivante :
Ci-dessous le contenu du champ deployment –> spec –> template –> spec –> containers –> ports suite à ces modifications:
ports:
- name: http
containerPort: 8025
protocol: TCP
- name: smtp
containerPort: 1025
protocol: TCP
Afin de configurer la persistance de données, un objet ConfigMap sera déclaré. Ce dernier devra contenir deux déclarations dans le champ data :
Pour le reste, l’en-tête s’inspirera du contenu du fichier service.yaml.
Ci-dessous la déclaration complète du fichier:
apiVersion: v1
kind: ConfigMap
metadata:
name: {{ include "mailhog.fullname" . }}
labels:
{{ include "mailhog.labels" . | indent 4 }}
data:
MH_STORAGE: maildir
MH_MAILDIR_PATH: /maildir
Sauvegardez ce fichier dans le répertoire templates sous le nom configmap.yaml.
Autre opération à réaliser : utiliser ces déclarations comme variables d’environnement dans le container. Dans le fichier « deployement.yaml », au même niveau que le champ ports, ajoutez un champ envFrom avec la déclaration suivante:
envFrom:
- configMapRef:
name: {{ include "mailhog.fullname" . }}
La déclaration du volume persistant sera conditionnée à l’aide de deux variables du champ « persistence »:
Ci-dessous un exemple de déclaration de volume persistant correspondant à ces critères:
{{ if .Values.persistence.enabled }}
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: {{ include "mailhog.fullname" . }}
labels:
{{ include "mailhog.labels" . | indent 4 }}
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: {{ .Values.persistence.size }}
{{ end }}
Sauvegardez ce fichier dans le répertoire « templates » sous le nom de « persistentvolumeclaim.yaml ».
Dans le fichiers values.yaml ajoutez les valeurs par défaut pour « persistence »
persistence:
enabled: true
size: 5Gi
Le montage de ce volume persistant, comme vu les fois précédentes, réclame deux modifications :
Autre point important : le volume persistant devra être conditionné à la valeur du champ « persistence.enabled ».
Ci-dessous la déclaration à ajouter pour déclarer l’existence du volume de données de MailHog:
{{- if .Values.persistence.enabled }}
volumes:
- name: mailhog-maildir
persistentVolumeClaim:
claimName: {{ include "mailhog.name" . }}
{{- end }}
containers:
Et enfin la définition du point de montage:
envFrom:
- configMapRef:
name: {{ include "mailhog.fullname" . }}
{{- if .Values.persistence.enabled }}
volumeMounts:
- mountPath: /maildir
name: mailhog-maildir
{{- end }}
livenessProbe:
Le message qui sera affiché au déploiement est personnalisable à l’aide du contenu du fichier « NOTES.txt » dans le répertoire templates. N’hésitez pas à le modifier afin de donner des indications comme :
Dans notre cas on va juste changer la publication de service
echo "Visit http://127.0.0.1:8025 to use your application"
Validez et vérifiez les erreurs avec la commande suivante :
helm lint mailhog
Avant d’installer l’application il est toujours recommandé de tester l’application pour valider les différentes templates avec l’option « –dry-run »
helm install --dry-run mailhog mailhog/
Déployez l’application avec la commande suivante:
helm install mailhog mailhog/
Listez les ressources de l’application
kubectl get all -l "app.kubernetes.io/name=mailhog"
L’application « mailhog » utilise deux ports d’écoute :
Comme on a utilisé un service « ClusterIP » l’application est injoignable depuis l’extérieur du cluster Kubernetes. Il est néanmoins possible de faire suivre le port de service sur la machine de l’utilisateur à l’aide de l’instruction « port-forward » de la commande « kubectl ». Pour fonctionner :
kubectl port-forward --address 0.0.0.0 services/mailhog 8025
L’application MailHog sera alors accessible en entrant l’adresse http://[LABIP]:8081 dans un navigateur.
Nettoyer les ressources
helm uninstall mailhog
Créer et tester un chart pour l’application « dockercoins » vue dans le « Lab05 ».