DOF304 - Travailler avec des Pods et des Conteneurs

• DOF304 - Travailler avec des Pods et des Conteneurs
  • Contenu du Module
  • LAB #1 - Application Configuration
    • 1.1 - Création d'une ConfigMap
    • 1.2 - Création d'un Secret
    • 1.3 - 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 - Resource Requests
    • 2.2 - Resource Limits
  • LAB #3 - Supervision des Conteneurs
    • 3.1 - Liveness Probes
      • Le Probe exec
      • Le Probe httpGet
    • 3.2 - Startup Probes
    • 3.3 - Readiness Probes
  • LAB #4 - Gestion des Politiques de Redémarrage

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.

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

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>

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:

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==

Créez maintenant le Secret :

root@kubemaster:~# kubectl create -f mysecret.yaml
secret/my-secret created

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

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

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

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.

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

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 

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.

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

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

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

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

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

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

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

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

Copyright © 2022 Hugh Norris