Ceci est une ancienne révision du document !
Table des matières
Version - 2020.02
Dernière mise-à-jour : 2022/09/15 08:56
DOF304 - Travailler avec des Pods et des Conteneurs
Contenu du Module
- DOF304 - Travailler avec des Pods et des Conteneurs
- Contenu du Module
- LAB #1 - Application Configuration
- 1.1 - Présentation
- 1.2 - Création d'une ConfigMap
- 1.3 - Création d'un Secret
- 1.4 - Utilisation de ConfigMaps et de Secrets
- Utilisation de Variables d'environnement
- Utilisation de Volumes de Configuration
- LAB #2 - Gestion des Ressources des Conteneurs
- 2.1 - Présentation
- 2.2 - Resource Requests
- 2.3 - Resource Limits
- LAB #3 - Supervision des Conteneurs
- 3.1 - Présentation
- 3.2 - Liveness Probes
- Le Probe exec
- Le Probe httpGet
- 3.3 - Startup Probes
- 3.4 - Readiness Probes
- LAB #4 - Gestion des Politiques de Redémarrage
- 4.1 - Présentation
- 4.2 - Always
- 4.3 - OnFailure
- 4.4 - Never
- LAB #5 - Création de Pods Multi-conteneurs
- 5.1 - Présentation
- 5.2 - Mise en Place
- LAB #6 - Conteneurs Init
- 6.1 - Présentation
- 6.2 - Mise en Place
LAB #1 - Application Configuration
1.1 - Présentation
La gestion de la configuration d'application ou Application Configuration est le processus de passage de valeurs dynamiques aux applications au moment du runtime.
Il y a deux façons de stocker des informations dans K8s :
- ConfigMaps,
- Secrets.
Les données stockées dans des ConfigMaps et des Secrets peuvent être passées aux conteneurs en utilisant des :
- Variables d'environnement,
- Volumes de configuration.
1.2 - Création d'une ConfigMap
Pour commencer, créez le fichier myconfigmap.yaml :
root@kubemaster:~# vi myconfigmap.yaml
root@kubemaster:~# cat myconfigmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: my-configmap
data:
key1: Hello, world!
key2: |
Test
multiple lines
more lines
Important : Notez que les données sont stockées dans des Key-values. La première donnée dans la section data est key1: Hello, world! tandis que la deuxième, key2, est en plusieures lignes.
Créez maintenant la ConfigMap :
root@kubemaster:~# kubectl create -f myconfigmap.yaml configmap/my-configmap created
Pour consulter le contenu de la ConfigMap, utilisez la commande kubectl describe :
root@kubemaster:~# kubectl describe configmap my-configmap Name: my-configmap Namespace: default Labels: <none> Annotations: <none> Data ==== key1: ---- Hello, world! key2: ---- Test multiple lines more lines BinaryData ==== Events: <none>
1.3 - Création d'un Secret
Créez maintenant le fichier mysecret.yaml :
root@kubemaster:~# vi mysecret.yaml root@kubemaster:~# cat mysecret.yaml apiVersion: v1 kind: Secret metadata: name: my-secret type: Opaque data: secretkey1: secretkey2:
Important : Notez que les clefs secrets n'ont pas encore été définies.
Cryptez maintenant les deux clefs en utilisant base64 :
root@kubemaster:~# echo -n 'secret' | base64 c2VjcmV0 root@kubemaster:~# echo -n 'anothersecret' | base64 YW5vdGhlcnNlY3JldA==
Copiez et collez les chaînes base64 dans le ficheir mysecret.yaml :
root@kubemaster:~# vi mysecret.yaml root@kubemaster:~# cat mysecret.yaml apiVersion: v1 kind: Secret metadata: name: my-secret type: Opaque data: secretkey1: c2VjcmV0 secretkey2: YW5vdGhlcnNlY3JldA==
Important : Remplacez les chaînes par celles que VOUS avez créé.
Créez maintenant le Secret :
root@kubemaster:~# kubectl create -f mysecret.yaml secret/my-secret created
1.4 - Utilisation de ConfigMaps et de Secret
Utilisation des Variables d'environnement
Créez le fichier envpod.yaml :
root@kubemaster:~# vi envpod.yaml
root@kubemaster:~# cat envpod.yaml
apiVersion: v1
kind: Pod
metadata:
name: envpod
spec:
containers:
- name: busybox
image: busybox
command: ['sh', '-c', 'echo "configmap: $CONFIGMAPVAR secret: $SECRETVAR"']
env:
- name: CONFIGMAPVAR
valueFrom:
configMapKeyRef:
name: my-configmap
key: key1
- name: SECRETVAR
valueFrom:
secretKeyRef:
name: my-secret
key: secretkey1
Important : Notez que la variable $CONFIGMAPVAR contiendra la valeur de key1 de la ConfigMap et que la variable $SECRETVAR contindra la valeur de secretkey1 du Secret.
Créez maintenant le pod :
root@kubemaster:~# kubectl create -f envpod.yaml pod/envpod created
Consultez maintenant les logs du pod :
root@kubemaster:~# kubectl logs envpod configmap: Hello, world! secret: secret
Important : Notez que le conteneur dans le pod voit bien les valeurs des deux variables.
Utilisation des Volumes de Configuration
Créez le fichier volumepod.yaml :
root@kubemaster:~# vi volumepod.yaml
root@kubemaster:~# cat volumepod.yaml
apiVersion: v1
kind: Pod
metadata:
name: volumepod
spec:
containers:
- name: busybox
image: busybox
command: ['sh', '-c', 'while true; do sleep 3600; done']
volumeMounts:
- name: configmap-volume
mountPath: /etc/config/configmap
- name: secret-volume
mountPath: /etc/config/secret
volumes:
- name: configmap-volume
configMap:
name: my-configmap
- name: secret-volume
secret:
secretName: my-secret
Créez maintenant le pod :
root@kubemaster:~# kubectl create -f volumepod.yaml pod/volumepod created
Utilisez maintenant la commande kubectl exec pour consulter les config data files dans le conteneur :
root@kubemaster:~# kubectl exec volumepod -- ls /etc/config/configmap key1 key2 root@kubemaster:~# kubectl exec volumepod -- cat /etc/config/configmap/key1 Hello, world!root@kubemaster:~# [Enter] root@kubemaster:~# kubectl exec volumepod -- cat /etc/config/configmap/key2 Test multiple lines more lines root@kubemaster:~# kubectl exec volumepod -- ls /etc/config/secret secretkey1 secretkey2 root@kubemaster:~# kubectl exec volumepod -- cat /etc/config/secret/secretkey1 secretroot@kubemaster:~# [Enter] root@kubemaster:~# kubectl exec volumepod -- cat /etc/config/secret/secretkey2 anothersecretroot@kubemaster:~# [Enter] root@kubemaster:~#
Dernièrement, supprimez les pods envpod et volumepod :
root@kubemaster:~# kubectl delete pod envpod volumepod pod "envpod" deleted pod "volumepod" deleted
LAB #2 - Gestion des Ressources des Conteneurs
2.1 - Présentation
Deux aspects importants de la gestion des ressources des conteneurs sont :
- Resource Requests,
- Une Resource Request permet de définir des ressources telles le CPU et la mémoire au moment du scheduling. Autrement dit, si la Resource Request est de 5Go, le scheduleur des pods cherchera une noeud ayant 5 Go de RAM disponible. Une Resource Request n'est pas une limite car le pod peut utiliser plus ou moins de mémoire.
- Resource Limits,
- Une Resource Limit permet de définir des limites des ressources telles le CPU et la mémoire. Différents Container Runtimes réagissent de manières différentes devant une Resource Limit. Par exemple, certains vont arrêter le processus du conteneur en cas de dépassement de la limite. Dans le cas de Docker, si la limite du CPU est dépassé, Docker va limiter l'utilisation du CPU. Par contre dans le cas d'un dépassement de la limite de la mémoire, Docker va tuer le processus du conteneur.
Pour les deux types, les demandes et les limites de la mémoire sont généralement exprimées en Mi, tandis que les les demandes et les limites du CPU sont exprimées en 1/1000 d'un processeur. Par exemple le chiffre 250m représente 250/1000 d'un CPU ou 1/4.
2.2 - Resource Requests
Créez le fichier bigrequestpod.yaml :
root@kubemaster:~# vi bigrequestpod.yaml
root@kubemaster:~# cat bigrequestpod.yaml
apiVersion: v1
kind: Pod
metadata:
name: bigrequestpod
spec:
containers:
- name: busybox
image: busybox
command: ['sh', '-c', 'while true; do sleep 3600; done']
resources:
requests:
cpu: "10000m"
memory: "128Mi"
Créez le pod :
root@kubemaster:~# kubectl create -f bigrequestpod.yaml pod/bigrequestpod created
Consultez maintenant le statut du pod créé :
root@kubemaster:~# kubectl get pod bigrequestpod NAME READY STATUS RESTARTS AGE bigrequestpod 0/1 Pending 0 92s
Important : Notez que le statut du pod est en pending. Le pod restera en pending car ni kubenode1, ni kubenode2 sont capables de satisfaire la demande de 10000m.
2.3 - Resource Limits
Créez le fichier resourcepod.yaml :
root@kubemaster:~# vi resourcepod.yaml
root@kubemaster:~# cat resourcepod.yaml
apiVersion: v1
kind: Pod
metadata:
name: resourcepod
spec:
containers:
- name: busybox
image: busybox
command: ['sh', '-c', 'while true; do sleep 3600; done']
resources:
requests:
cpu: "250m"
memory: "128Mi"
limits:
cpu: "500m"
memory: "256Mi"
Créez le pod :
root@kubemaster:~# kubectl create -f resourcepod.yaml pod/resourcepod created
Consultez le statut des pods :
root@kubemaster:~# kubectl get pods NAME READY STATUS RESTARTS AGE bigrequestpod 0/1 Pending 0 20m my-deployment-67b5d4bf57-6wcrq 1/1 Running 0 22h myapp-deployment-689f9d59-c25f9 1/1 Running 0 7d myapp-deployment-689f9d59-nn9sw 1/1 Running 0 7d myapp-deployment-689f9d59-rnc4r 1/1 Running 0 7d resourcepod 1/1 Running 0 5m49s
Important : Notez que le statut du pod bigrequestpod est toujours en pending.
LAB #3 - Supervision des Conteneurs
3.1 - Présentation
La supervision des conteneurs concerne la surveillance de la santé des conteneurs afin d'assurer des applications et des solutions robustes en redémarrant des conteneurs cassés. Pour accomplir cette tâche, K8s utilise des sondes ou probes en anglais.
Il existe plusieurs types de sondes :
- Liveness Probes,
- Par défaut K8s considère un conteneur HS uniquement quand le conteneur en question s'arrête,
- Liveness probes permettent une configuration plus sophistiquée de mécanisme.
- Startup Probes,
- Similaires aux Liveness Probes, les Startup Probes n'interviennent uniquement au démarrage du conteneur et s'arrêtent quand l'application a démarré.
- Readiness Probes,
- Similaires aux Startup Probes car ils n'interviennet qu'au démarrage du pod, les Readiness Probes sont responsables du blocage du trafic vers les pods tant que tous les conteneurs du pod n'ont pas réussi les Readiness Probes.
3.2 - Liveness Probes
Le Probe exec
Créez le fichier livenesspod.yaml :
root@kubemaster:~# vi livenesspod.yaml
root@kubemaster:~# cat livenesspod.yaml
apiVersion: v1
kind: Pod
metadata:
name: livenesspod
spec:
containers:
- name: busybox
image: busybox
command: ['sh', '-c', 'while true; do sleep 3600; done']
livenessProbe:
exec:
command: ["echo", "Hello, world!"]
initialDelaySeconds: 5
periodSeconds: 5
Important : Dans le fichier ci-dessus, si la commande echo “Hello, World! retourne un code de retour de 0, le conteneur sera considéré en bonne santé. Le Liveness Probe démarrera 5 secondes après le démarrage du conteneur grâce à la directive initialDelaySeconds. Ensuite le probe s'exécutera tous les 5 secondes grâce à la directive periodSeconds.
Créez le pod :
root@kubemaster:~# kubectl create -f livenesspod.yaml pod/livenesspod created
Consultez le statut du pod :
root@kubemaster:~# kubectl get pod livenesspod NAME READY STATUS RESTARTS AGE livenesspod 1/1 Running 0 90s
Important : Notez que le pod est en bonne santé et à un statut de running.
Le Probe httpGet
Créez le fichier livenesspodhttp.yaml :
root@kubemaster:~# vi livenesspodhttp.yaml
root@kubemaster:~# cat livenesspodhttp.yaml
apiVersion: v1
kind: Pod
metadata:
name: livenesspodhttp
spec:
containers:
- name: nginx
image: nginx:1.19.1
livenessProbe:
httpGet:
path: /
port: 80
initialDelaySeconds: 5
periodSeconds: 5
Important : Dans le fichier ci-dessus, si la commande GET / s'exécute sans erreur, le conteneur sera considéré en bonne santé. Le Liveness Probe démarrera 5 secondes après le démarrage du conteneur grâce à la directive initialDelaySeconds. Ensuite le probe s'exécutera tous les 5 secondes grâce à la directive periodSeconds.
Créez le pod :
root@kubemaster:~# kubectl create -f livenesspodhttp.yaml pod/livenesspodhttp created
Consultez le statut du pod :
root@kubemaster:~# kubectl get pod livenesspodhttp NAME READY STATUS RESTARTS AGE livenesspodhttp 1/1 Running 0 52s
Important : Notez que le pod est en bonne santé et à un statut de running.
3.3 - Startup Probes
Créez le fichier startuppod.yaml :
root@kubemaster:~# vi startuppod.yaml
root@kubemaster:~# cat startuppod.yaml
apiVersion: v1
kind: Pod
metadata:
name: startuppod
spec:
containers:
- name: nginx
image: nginx:1.19.1
startupProbe:
httpGet:
path: /
port: 80
failureThreshold: 30
periodSeconds: 10
Important : Dans le fichier ci-dessus, le Startup Probe va attendre un maximum de 30 secondes pour que l'application démarre grâce à la directive failureThreshold. Le probe s'exécutera tous les 10 secondes grâce à la directive periodSeconds.
Créez le pod :
root@kubemaster:~# kubectl create -f startuppod.yaml pod/startuppod created
Consultez le statut du pod :
root@kubemaster:~# kubectl get pod startuppod NAME READY STATUS RESTARTS AGE livenesspod 1/1 Running 0 90s
Important : Notez que le pod est en bonne santé et à un statut de running.
3.4 - Readiness Probes
Créez le fichier readinesspod.yaml :
root@kubemaster:~# vi readinesspod.yaml
root@kubemaster:~# cat readinesspod.yaml
apiVersion: v1
kind: Pod
metadata:
name: readinesspod
spec:
containers:
- name: nginx
image: nginx:1.19.1
readinessProbe:
httpGet:
path: /
port: 80
initialDelaySeconds: 5
periodSeconds: 5
Important : Dans le fichier ci-dessus, si la commande GET / s'exécute sans erreur, le conteneur sera considéré dasn un état de READY. Le Readiness Probe démarrera 5 secondes après le démarrage du conteneur grâce à la directive initialDelaySeconds. Ensuite le probe s'exécutera tous les 5 secondes grâce à la directive periodSeconds.
Créez le pod et consultez son statut :
root@kubemaster:~# kubectl create -f readinesspod.yaml;kubectl get pod readinesspod;sleep 1;kubectl get pod readinesspod;sleep 3;kubectl get pod readinesspod;sleep 3;kubectl get pod readinesspod;sleep 3;kubectl get pod readinesspod;sleep 3;kubectl get pod readinesspod pod/readinesspod created NAME READY STATUS RESTARTS AGE readinesspod 0/1 Pending 0 0s NAME READY STATUS RESTARTS AGE readinesspod 0/1 ContainerCreating 0 1s NAME READY STATUS RESTARTS AGE readinesspod 0/1 Running 0 4s NAME READY STATUS RESTARTS AGE readinesspod 0/1 Running 0 7s NAME READY STATUS RESTARTS AGE readinesspod 0/1 Running 0 10s NAME READY STATUS RESTARTS AGE readinesspod 1/1 Running 0 13s
Important : Notez que le pod est a un statut de running 4 secondes après son démarrage. Par contre, le pod ne passe qu'en READY au bout de 13 secondes quand le Readiness Probe a réussi.
LAB #4 - Gestion des Politiques de Redémarrage
4.1 - Présentation
K8s peut redémarrer des conteneurs en cas de problèmes. Il y a trois politiques de redémarrage :
- Always,
- Always est la politique par défaut,
- Always redémarre toujours un conteneur quelque soit le code retour quand le conteneur est arrêté.
- OnFailure,
- OnFailure ne redémarre un conteneur que dans ls cas où celui-ci sort avec un code retour autre que 0 ou dans le cas où un Liveness Probe a rapporté la mauvaise santé du conteneur. Dans le cas contraire, où le conteneur a terminé sa tâche et sort avec un code retour de 0, la politique ne le redémarre pas.
- Never,
- Never est l'opposé de Always. Le conteneur n'est jamais redémarré en cas d'arrêt, quelque soit la cause de cette dernière.
4.2 - Always
Créez le fichier alwayspod.yaml :
root@kubemaster:~# vi alwayspod.yaml
root@kubemaster:~# cat alwayspod.yaml
apiVersion: v1
kind: Pod
metadata:
name: alwayspod
spec:
restartPolicy: Always
containers:
- name: busybox
image: busybox
command: ['sh', '-c', 'sleep 10']
Créez le pod et consultez son statut :
root@kubemaster:~# kubectl create -f alwayspod.yaml;kubectl get pod alwayspod;sleep 9;kubectl get pod alwayspod;sleep 9;kubectl get pod alwayspod;sleep 9;kubectl get pod alwayspod pod/alwayspod created NAME READY STATUS RESTARTS AGE alwayspod 0/1 ContainerCreating 0 0s NAME READY STATUS RESTARTS AGE alwayspod 1/1 Running 0 9s NAME READY STATUS RESTARTS AGE alwayspod 1/1 Running 1 (6s ago) 19s NAME READY STATUS RESTARTS AGE alwayspod 0/1 Completed 1 (15s ago) 28s
Important : Notez que le pod a été redémarré.
4.3 - OnFailure
Créez le fichier onfailure.yaml :
root@kubemaster:~# vi onfailure.yaml
root@kubemaster:~# cat onfailure.yaml
apiVersion: v1
kind: Pod
metadata:
name: onfailure
spec:
restartPolicy: OnFailure
containers:
- name: busybox
image: busybox
command: ['sh', '-c', 'sleep 10']
Créez le pod et consultez son statut :
root@kubemaster:~# kubectl create -f onfailure.yaml;kubectl get pod onfailure;sleep 9;kubectl get pod onfailure;sleep 9;kubectl get pod onfailure;sleep 9;kubectl get pod onfailure;sleep 9;kubectl get pod onfailure;sleep 9;kubectl get pod onfailure pod/onfailure created NAME READY STATUS RESTARTS AGE onfailure 0/1 Pending 0 0s NAME READY STATUS RESTARTS AGE onfailure 1/1 Running 0 9s NAME READY STATUS RESTARTS AGE onfailure 0/1 Completed 0 19s NAME READY STATUS RESTARTS AGE onfailure 0/1 Completed 0 28s NAME READY STATUS RESTARTS AGE onfailure 0/1 Completed 0 37s NAME READY STATUS RESTARTS AGE onfailure 0/1 Completed 0 46s
Important : Notez que le pod n'a pas été redémarré.
Supprimez maintenant le pod onfailure :
root@kubemaster:~# kubectl delete pod onfailure pod "onfailure" deleted
Modifiez ensuite le fichier onfailure.yaml en ajoutant la chaîne this is a bad command :
root@kubemaster:~# vi onfailure.yaml
root@kubemaster:~# cat onfailure.yaml
apiVersion: v1
kind: Pod
metadata:
name: onfailure
spec:
restartPolicy: OnFailure
containers:
- name: busybox
image: busybox
command: ['sh', '-c', 'sleep 10;this is a bad command']
Créez le pod et consultez son statut :
root@kubemaster:~# kubectl create -f onfailure.yaml;kubectl get pod onfailure;sleep 9;kubectl get pod onfailure;sleep 9;kubectl get pod onfailure;sleep 9;kubectl get pod onfailure;sleep 9;kubectl get pod onfailure;sleep 9;kubectl get pod onfailure pod/onfailure created NAME READY STATUS RESTARTS AGE onfailure 0/1 Pending 0 0s NAME READY STATUS RESTARTS AGE onfailure 1/1 Running 0 9s NAME READY STATUS RESTARTS AGE onfailure 1/1 Running 1 (5s ago) 18s NAME READY STATUS RESTARTS AGE onfailure 0/1 Error 1 (14s ago) 27s NAME READY STATUS RESTARTS AGE onfailure 0/1 Error 1 (23s ago) 36s NAME READY STATUS RESTARTS AGE onfailure 1/1 Running 2 (21s ago) 46s
Important : Notez que le pod a été redémarré à cause de l'erreur.
4.4 - Never
Créez le fichier never.yaml :
root@kubemaster:~# vi never.yaml
root@kubemaster:~# cat never.yaml
apiVersion: v1
kind: Pod
metadata:
name: never
spec:
restartPolicy: Never
containers:
- name: busybox
image: busybox
command: ['sh', '-c', 'sleep 10;this is a bad command']
Créez le pod et consultez son statut :
root@kubemaster:~# kubectl create -f never.yaml;kubectl get pod never;sleep 9;kubectl get pod never;sleep 9;kubectl get pod never;sleep 9;kubectl get pod never;sleep 9;kubectl get pod never;sleep 9;kubectl get pod never pod/never created NAME READY STATUS RESTARTS AGE never 0/1 ContainerCreating 0 0s NAME READY STATUS RESTARTS AGE never 1/1 Running 0 9s NAME READY STATUS RESTARTS AGE never 0/1 Error 0 18s NAME READY STATUS RESTARTS AGE never 0/1 Error 0 27s NAME READY STATUS RESTARTS AGE never 0/1 Error 0 36s NAME READY STATUS RESTARTS AGE never 0/1 Error 0 45s
Important : Notez que le pod n'a pas été redémarré.
LAB #5 - Création de Pods Multi-conteneurs
5.1 - Présentation
Il est toujours préférable de ne mettre qu'un seul conteneur dans un pod. L'exception à cette règle est quand deux ou plus de pods ont besoin d'intéragir afin de remplir leur rôles respectifs. Le autres conteneur s'appellent des sidecars (side-cars en français) ou des helpers (assistants en français). L'intéraction s'appelle Cross-Container Interaction.
Cette intéraction prend la forme de partager :
- le même espace réseau,
- les conteneurs peuvent se communiquer sur tous les ports, même si les ports ne sont pas exposés au cluster,
- le même espace de stockage,
- les conteneurs peuvent partager les mêmes volumes.
5.2 - Mise en Place
Commencez par créer le fichier multicontainerpod.yaml :
root@kubemaster:~# vi multicontainerpod.yaml
root@kubemaster:~# cat multicontainerpod.yaml
apiVersion: v1
kind: Pod
metadata:
name: multicontainerpod
spec:
containers:
- name: nginx
image: nginx
- name: redis
image: redis
- name: couchbase
image: couchbase
Important : Notez que le fichier créera trois conteneurs - nginx, redis et couchbase.
Créez ensuite le pod :
root@kubemaster:~# kubectl create -f multicontainerpod.yaml pod/multicontainerpod created
Consultez l'état du pod :
root@kubemaster:~# kubectl get pod multicontainerpod NAME READY STATUS RESTARTS AGE multicontainerpod 0/3 ContainerCreating 0 65s
Important : Notez qu'il y a actuellement 0 de 3 pods dans un état de READY.
Attendez quelques minutes et constatez de nouveau l'état du pod :
root@kubemaster:~# kubectl get pod multicontainerpod NAME READY STATUS RESTARTS AGE multicontainerpod 3/3 Running 0 16m
Important : Notez qu'il y a actuellement 3 de 3 pods dans un état de READY.
Créez maintenant le fichier helper.yaml :
root@kubemaster:~# vi helper.yaml
root@kubemaster:~# cat helper.yaml
apiVersion: v1
kind: Pod
metadata:
name: helperpod
spec:
containers:
- name: busybox1
image: busybox
command: ['sh', '-c', 'while true; do echo logs data > /output/output.log; sleep 5; done']
volumeMounts:
- name: sharedvol
mountPath: /output
- name: helper
image: busybox
command: ['sh', '-c', 'tail -f /input/output.log']
volumeMounts:
- name: sharedvol
mountPath: /input
volumes:
- name: sharedvol
emptyDir: {}
Important : Notez que ce fichier créera un pod contenant deux conteneurs - busybox1 et helper. Chaque conteneur partage un volume identique qui s'appelle sharedvol. Dans le conteneur *busybox1 ce volume est monté sur /output tandis que dans le conteneur helper, le même volume est monté sur /input.
Créez le pod helper :
root@kubemaster:~# kubectl create -f helper.yaml pod/helperpod created
Consultez les logs du conteneur helper dans le pod helperpod :
root@kubemaster:~# kubectl logs helperpod -c helper logs data
Important : Notez que le conteneur busybox1 a écrit la chaîne logs data dans le fichier /output/output.log tous les 5 secondes grâce à l'exécution de la commande while true; do echo logs data > /output/output.log; sleep 5; done. Le conteneur helper exécute la commande tail -f /input/output.log. Le log du conteneur helper contient donc la chaîne logs data issu du fichier output.log car ce fichier est partagé entre les deux conteneurs.
LAB #6 - Conteneurs Init
6.1 - Présentation
Un Conteneur Init est un conteneur qui ne s'exécute qu'une seule fois au démarrage du pod. S'il existe plusieurs conteneurs Init, ceux-ci s'exécutent dans l'ordre. Un conteneur Init doit terminer son exécution avant que le conteneur Init suivant, ou l'application si le conteneur Init concerné est le dernier, peut s'exécuter. Le but d'un conteneur Init est d'exécuter du code qui n'a pas besoin de se trouver dans les conteneurs de l'application afin rendre plus légers ces derniers, par exemple :
- isoler, d'une manière sécurisée, des données sensibles tels des mots de passe afin d'éviter à ce que celles-ci soient compromises si un conteneur de l'application est compromis,
- injecter des données dans un volume partagé,
- faire patienter un pod en attendant que d'autres ressources de K8s soient créées.
6.2 - Mise en Place
Commencez par créer le fichier initpod.yaml :
root@kubemaster:~# vi initpod.yaml
root@kubemaster:~# cat initpod.yaml
apiVersion: v1
kind: Pod
metadata:
name: initpod
spec:
containers:
- name: nginx
image: nginx:1.19.1
initContainers:
- name: delay
image: busybox
command: ['sleep', '30']
Important : Notez que le conteneur delay va faire patienter la création du conteneur nginx pendant 30 secondes.
Créez le pod initpod :
root@kubemaster:~# kubectl create -f initpod.yaml pod/initpod created
Consultez l'état du pod :
root@kubemaster:~# kubectl get pod initpod NAME READY STATUS RESTARTS AGE initpod 0/1 Init:0/1 0 6s
Important : Notez que le STATUS du pod est Init:0/1.
Patientez au moins 30 secondes puis exécutez la dernière commande de nouveau :
root@kubemaster:~# kubectl get pod initpod NAME READY STATUS RESTARTS AGE initpod 1/1 Running 0 79s
Important : Notez que le STATUS du pod est Running.
— Copyright © 2022 Hugh Norris
