Découvrez les commandes de vérification
Super ! Vous avez enfin déployé le site d’e-commerce de LiveCorp grâce au fichier YAML de déploiement !
Il est maintenant temps d’analyser ce déploiement afin de voir si tout se passe bien. Il arrive évidemment que quelques fois les déploiements ne se passent pas comme prévu.
Il faut donc intervenir sur le cluster afin de diagnostiquer les applications. Pour cela, il faut connaître certaines commandes qui sont très utiles afin de comprendre ce qu’il se passe dans le cluster.
Lors du déploiement du site e-commerce de LiveCorp, celui-ci peut ne pas fonctionner car il existe une erreur dans la déclaration du fichier. Par exemple, le nom de l’image dans la registry peut ne pas exister, ou encore la version de celle-ci n’est peut-être pas existante dans la registry.
De plus, le site web génère des logs applicatifs qui peuvent être une mine d’informations utiles comme le nombre de personnes connectées, ou les problèmes de connexion à la base de données.
Récupérez la liste des pods avec kubectl get pods
La première que vous connaissez déjà est la commandekubectl get pods . Cette commande récupère la liste de tous les pods tournant dans le cluster. Par défaut, si aucun namespace n’est spécifié, la commande n’affiche que les pods tournant dans le namespace par défaut, comme le site web LiveCorp.
La commandekubectl get pods retournera alors les 5 pods déployés du cluster.
Pour filtrer par namespace, il faut ajouter le flag-n avec le nom du namespace dans lequel on veut chercher. Par exemplekubectl get pods -n kube-system affichera la liste de tous les pods qui tourne dans le namespace système de Kubernetes.
Pour afficher tous les pods de tous les namespaces, il existe un flag -A . La commande retournera alors tous les pods qui tournent dans le cluster.
kubectl get pods -A
Cette commande est très pratique pour avoir un premier aperçu de l’état des pods. Comme expliqué dans le chapitre précédent, les pods ont un cycle de vie. Si tout se passe bien, le statut par défaut est Running.
Pour diagnostiquer cette erreur, il existe deux autres commandes qui permettent d’avoir une vue plus détaillée de l’erreur. Ces deux commandes sontkubectl logs etkubectl describe.
Affichez les logs d’un pod spécifique avec kubectl logs
Cette commande affiche les logs applicatifs d'un pod spécifique. Si vous appliquez cette commande sur un des pods du site web, vous allez récupérer les logs de l’application.
kubectl logs site-ecommerce-deployment-567d948-vplf7 /docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration /docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/ /docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh 10-listen-on-ipv6-by-default.sh: info: Getting the checksum of /etc/nginx/conf.d/default.conf 10-listen-on-ipv6-by-default.sh: info: Enabled listen on IPv6 in /etc/nginx/conf.d/default.conf /docker-entrypoint.sh: Sourcing /docker-entrypoint.d/15-local-resolvers.envsh /docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh /docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh /docker-entrypoint.sh: Configuration complete; ready for start up 2024/06/17 10:02:29 [notice] 1#1: using the "epoll" event method 2024/06/17 10:02:29 [notice] 1#1: nginx/1.27.0 2024/06/17 10:02:29 [notice] 1#1: built by gcc 12.2.0 (Debian 12.2.0-14) 2024/06/17 10:02:29 [notice] 1#1: OS: Linux 6.1.75+ 2024/06/17 10:02:29 [notice] 1#1: getrlimit(RLIMIT_NOFILE): 1048576:1048576 2024/06/17 10:02:29 [notice] 1#1: start worker processes 2024/06/17 10:02:29 [notice] 1#1: start worker process 29 2024/06/17 10:02:29 [notice] 1#1: start worker process 30
Vous pouvez spécifier le nom du pod ou utiliser un sélecteur pour cibler plusieurs pods. Dans notre cas, la commande suivante va récupérer les logs applicatifs des 5 pods du site e-commerce. Le filtre se fait par rapport au label défini dans le fichier YAML, iciapp=site-ecommerce .
kubectl logs -l app=site-ecommerce /docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh /docker-entrypoint.sh: Configuration complete; ready for start up 2024/06/17 12:58:53 [notice] 1#1: using the "epoll" event method 2024/06/17 12:58:53 [notice] 1#1: nginx/1.27.0 2024/06/17 12:58:53 [notice] 1#1: built by gcc 12.2.0 (Debian 12.2.0-14) 2024/06/17 12:58:53 [notice] 1#1: OS: Linux 6.1.75+ 2024/06/17 12:58:53 [notice] 1#1: getrlimit(RLIMIT_NOFILE): 1048576:1048576 2024/06/17 12:58:53 [notice] 1#1: start worker processes 2024/06/17 12:58:53 [notice] 1#1: start worker process 30 2024/06/17 12:58:53 [notice] 1#1: start worker process 31 /docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh /docker-entrypoint.sh: Configuration complete; ready for start up 2024/06/17 10:02:28 [notice] 1#1: using the "epoll" event method 2024/06/17 10:02:28 [notice] 1#1: nginx/1.27.0 2024/06/17 10:02:28 [notice] 1#1: built by gcc 12.2.0 (Debian 12.2.0-14) 2024/06/17 10:02:28 [notice] 1#1: OS: Linux 6.1.75+ 2024/06/17 10:02:28 [notice] 1#1: getrlimit(RLIMIT_NOFILE): 1048576:1048576 2024/06/17 10:02:28 [notice] 1#1: start worker processes 2024/06/17 10:02:28 [notice] 1#1: start worker process 30 2024/06/17 10:02:28 [notice] 1#1: start worker process 31 …
Cette commande va alors lire les métadonnées de chaque pod et retourner les logs de tous les pods qui contiennent le labelapp: site-ecommerce .
Dans le cas où le pod contiendrait plusieurs conteneurs, vous pouvez choisir le conteneur dans lequel aller chercher les logs :
kubectl logs site-ecommerce-deployment-567d948-vplf7 -c conteneur
Affichez la description détaillée d’une ressource avec kubectl describe
Cette commande affiche une description détaillée d'une ressource Kubernetes, telle qu'un pod. Elle fournit des informations sur l'état actuel de la ressource, ses configurations et les événements associés.
Vous allez retrouver dans la sortie de cette commande beaucoup de champs que vous avez spécifiés dans votre YAML de déploiement, mais aussi d’autres champs qui ont été générés par Kubernetes lui-même.
Par exemple, vous allez retrouver le nom du déploiement que vous avez appliqué lors du déploiement du fichier YAML du site web. Vous allez aussi retrouver le namespace dans lequel les pods ont été déployés. Cette commande retourne aussi les labels posés sur les différents pods du site.
Mais cette commande vous retourne aussi énormément d’informations générées par Kubernetes lui-même pour gérer votre application. Les informations du fichier YAML ont été surlignées en gras afin que vous puissiez les voir.
Cette commande vous indique aussi une liste d’événements et d’erreurs qui se sont produits lors du déploiement de votre application. Elle est beaucoup plus descriptive que la commandekubectl get pods et peut être une mine d’informations sur ce qui ne va pas sur vos pods.
kubectl describe pod/site-ecommerce-deployment-567d948-vplf7 Name: site-ecommerce-deployment-567d948-vplf7 Namespace: default Priority: 0 Service Account: default Node: gke-cluster-1-default-pool-e55f41dd-85kb/10.128.15.201 Start Time: Mon, 17 Jun 2024 10:02:21 +0000 Labels: app=nginx pod-template-hash=567d948 Annotations: <none> Status: Running IP: 10.36.0.12 IPs: IP: 10.36.0.12 Controlled By: ReplicaSet/site-ecommerce-deployment-567d948 Containers: site-ecommerce: Container ID: containerd://b331da0a4a95898988f5fcff223e15db3e30d99df13a0294ff1e72632aa780b3 Image: site-ecommerce:1.2.0 Image ID: docker.io/library/nginx@sha256:56b388b0d79c738f4cf51bbaf184a14fab19337f4819ceb2cae7d94100262de8 Port: 8080/TCP Host Port: 0/TCP State: Running Started: Mon, 17 Jun 2024 10:02:29 +0000 Ready: True Restart Count: 0 Environment: <none> Mounts: /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-q7gvz (ro) Conditions: Type Status PodReadyToStartContainers True Initialized True Ready True ContainersReady True PodScheduled True Volumes: kube-api-access-q7gvz: Type: Projected (a volume that contains injected data from multiple sources) TokenExpirationSeconds: 3607 ConfigMapName: kube-root-ca.crt ConfigMapOptional: <nil> DownwardAPI: true QoS Class: BestEffort Node-Selectors: <none> Tolerations: node.kubernetes.io/not-ready:NoExecute op=Exists for 300s node.kubernetes.io/unreachable:NoExecute op=Exists for 300s Events: <none>
Affichez les événements générés par Kubernetes avec kubectl events
Cette commande affiche les événements générés par Kubernetes. Les événements peuvent fournir des informations utiles sur l'état de vos pods, déploiements et autres ressources, ainsi que sur les erreurs éventuelles. Par défaut, la commandekubectl get events n’affichera les événements que du namespace par défaut.
Cette commande affiche tous les événements générés par Kubernetes lors de l’application du fichier YAML de déploiement du site web, comme par exemple le démarrage des conteneurs du site e-commerce.
kubectl get events LAST SEEN TYPE REASON OBJECT MESSAGE 8m41s Normal Killing pod/site-ecommerce-deployment-567d948-6ddk9 Stopping container site-ecommerce 8m7s Normal Killing pod/site-ecommerce-deployment-567d948-7q2sc Stopping container site-ecommerce 8m41s Normal Scheduled pod/site-ecommerce-deployment-567d948-n7z4k Successfully assigned default/site-ecommerce-deployment-567d948-n7z4k to gke-cluster-1-default-pool-e55f41dd-85kb 8m40s Normal Pulled pod/site-ecommerce-deployment-567d948-n7z4k Container image "nginx:1.27.0" already present on machine 8m40s Normal Created pod/site-ecommerce-deployment-567d948-n7z4k Created container site-ecommerce 8m40s Normal Started pod/site-ecommerce-deployment-567d948-n7z4k Started container site-ecommerce 8m7s Normal Scheduled pod/site-ecommerce-deployment-567d948-r5jz4 Successfully assigned default/site-ecommerce-deployment-567d948-r5jz4 to gke-cluster-1-default-pool-e55f41dd-0mkl 8m6s Normal Pulled pod/site-ecommerce-deployment-567d948-r5jz4 Container image "site-ecommerce:1.2.0" already present on machine 8m6s Normal Created pod/site-ecommerce-deployment-567d948-r5jz4 Created container site-ecommerce 8m6s Normal Started pod/site-ecommerce-deployment-567d948-r5jz4 Started container site-ecommerce 8m41s Normal SuccessfulCreate replicaset/site-ecommerce-deployment-567d948 Created pod: site-ecommerce-deployment-567d948-n7z4k 8m7s Normal SuccessfulCreate replicaset/site-ecommerce-deployment-567d948 Created pod: site-ecommerce-deployment-567d948-r5jz4
Vous pouvez filtrer les événements sur les ressources que vous voulez afficher. Par exemple, pour filtrer les événements des pods dans le namespace par défaut, la commande est la suivante :
kubectl get events --field-selector=involvedObject.kind=Pod LAST SEEN TYPE REASON OBJECT MESSAGE 8m32s Normal Killing pod/site-ecommerce-deployment-567d948-6ddk9 Stopping container site-ecommerce 7m58s Normal Killing pod/site-ecommerce-deployment-567d948-7q2sc Stopping container nginx 8m32s Normal Scheduled pod/site-ecommerce-deployment-567d948-n7z4k Successfully assigned default/site-ecommerce-deployment-567d948-n7z4k to gke-cluster-1-default-pool-e55f41dd-85kb 8m31s Normal Pulled pod/site-ecommerce-deployment-567d948-n7z4k Container image "site-ecommerce:1.2.0" already present on machine 8m31s Normal Created pod/site-ecommerce-deployment-567d948-n7z4k Created container site-ecommerce 8m31s Normal Started pod/site-ecommerce-deployment-567d948-n7z4k Started container site-ecommerce 7m58s Normal Scheduled pod/site-ecommerce-deployment-567d948-r5jz4 Successfully assigned default/site-ecommerce-deployment-567d948-r5jz4 to gke-cluster-1-default-pool-e55f41dd-0mkl 7m57s Normal Pulled pod/site-ecommerce-deployment-567d948-r5jz4 Container image "nginx:1.27.0" already present on machine 7m57s Normal Created pod/site-ecommerce-deployment-567d948-r5jz4 Created container site-ecommerce 7m57s Normal Started pod/site-ecommerce-deployment-567d948-r5jz4 Started container site-ecommerce
Vous voyez que Kubernetes retourne tous les événements qui se sont passés sur le cluster.
Dans ce screencast, vous avez :
récupéré la liste des pods ;
affiché les logs applicatifs du site web ;
récupéré la description générée par Kubernetes du site web ;
affiché les différents événements générés par Kubernetes.
Récupérez des informations générées par l’application
Vous avez maintenant toutes les commandes pour récupérer des informations concernant les pods. Le site e-commerce de LiveCorp génère des logs applicatifs pour donner des informations sur le bon fonctionnement du site, le nombre de connexions, les erreurs applicatives et bien plus encore…
Génération et récupération des logs dans les pods Kubernetes
Les conteneurs d'un pod enregistrent leurs activités dans des fichiers journaux qui constituent les logs du pod. Ces logs peuvent contenir des informations utiles sur l'état des conteneurs, les erreurs rencontrées et les activités générales de l'application.
Il existe différents types de logs :
Les logs des conteneurs: Ces logs sont générés par les processus en cours d'exécution à l'intérieur des conteneurs. Ils peuvent inclure des messages d'impression, des erreurs et des informations de débogage.
Les logs des pods: Ces logs regroupent les logs de tous les conteneurs d'un pod. Ils offrent une vue d'ensemble des activités du pod.
Les logs d'événements: Ces logs enregistrent les événements importants qui se produisent dans le cluster Kubernetes, tels que les démarrages et arrêts de pods, les changements d'état des déploiements et les erreurs.
La commande kubectl logs est l'outil principal pour récupérer les logs des pods et des conteneurs Kubernetes.
Alice vous demande de récupérer les logs du site e-commerce que vous avez déployés dans le chapitre précédent. Connaissant la commande de récupération des logs, vous n’avez aucune difficulté à récupérer les logs du conteneur :
kubectl logs site-ecommerce-deployment-567d948-r5jz4 -c nginx-container /docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration /docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/ /docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh 10-listen-on-ipv6-by-default.sh: info: Getting the checksum of /etc/nginx/conf.d/default.conf 10-listen-on-ipv6-by-default.sh: info: Enabled listen on IPv6 in /etc/nginx/conf.d/default.conf /docker-entrypoint.sh: Sourcing /docker-entrypoint.d/15-local-resolvers.envsh /docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh /docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh /docker-entrypoint.sh: Configuration complete; ready for start up 2024/06/17 14:54:33 [notice] 1#1: using the "epoll" event method 2024/06/17 14:54:33 [notice] 1#1: nginx/1.27.0 2024/06/17 14:54:33 [notice] 1#1: built by gcc 12.2.0 (Debian 12.2.0-14) 2024/06/17 14:54:33 [notice] 1#1: OS: Linux 6.1.75+ 2024/06/17 14:54:33 [notice] 1#1: getrlimit(RLIMIT_NOFILE): 1048576:1048576 2024/06/17 14:54:33 [notice] 1#1: start worker processes 2024/06/17 14:54:33 [notice] 1#1: start worker process 29 2024/06/17 14:54:33 [notice] 1#1: start worker process 30
Alice vous explique néanmoins que ces commandes sont intéressantes lorsqu’il s’agit de récupérer les logs d’un seul pod, mais lorsqu’il s’agit de récupérer tous les logs de toutes les applications présentes dans le cluster, des solutions comme Elastic sont plus intéressantes car elle centralise les logs sur un seul serveur et vous permet de chercher dans ces logs.
Vous avez maintenant toutes les clés pour pouvoir récupérer et suivre les logs de vos applications avec Kubernetes !
Résolvez les problèmes de déploiement de votre application
Le déploiement du site e-commerce nécessite une connexion à une base de données afin de stocker les données du site web. Alice vous dit alors qu’un fichier de déploiement de la base de données a été généré par un autre développeur mais celui-ci tombe systématiquement en erreur.
Elle vous propose alors de diagnostiquer ce fichier en récupérant les logs du conteneur qui tombe en erreur à chaque déploiement. Une fois l’erreur découverte, il faudra résoudre le problème en diagnostiquant l’erreur.
Pour cela, elle vous fournit un fichier de déploiement et vous propose d’essayer de le débugger tout seul. Le fichier est le suivant :
apiVersion: apps/v1
kind: Deployment
metadata:
name: mysql
spec:
selector:
matchLabels:
app: mysql
template:
metadata:
labels:
app: mysql
spec:
containers:
- image: mysql:5.9
name: mysql
ports:
- containerPort: 3306
name: mysqlDébogage d'un déploiement Kubernetes échoué
La première chose à faire est de déployer ce fichier sur le cluster Kubernetes et d’utiliser les commandes précédemment apprises afin de trouver le problème.
kubectl apply -f mysql-deployment.yaml
Une fois le déploiement appliqué, vous constatez avec la commandekubectl get pods une erreur de type ErrImagePull et ImagePullBackOff
kubectl get pods NAME READY STATUS RESTARTS AGE mysql-78f75bfcd-xnhpp 0/1 ErrImagePull 0 7s kubectl get pods NAME READY STATUS RESTARTS AGE mysql-78f75bfcd-xnhpp 0/1 ImagePullBackOff 0 9m58s
Ce type d’erreur intervient quand l’image ne peut pas être trouvée sur le hub Docker. En cherchant un peu dans le hub, vous vous rendez compte que l’image d’origine n’existe pas. A la place, vous trouvez une version plus récente de l’image.
Après quelques modifications, le fichier ressemble maintenant à ça :
apiVersion: apps/v1
kind: Deployment
metadata:
name: mysql
spec:
selector:
matchLabels:
app: mysql
template:
metadata:
labels:
app: mysql
spec:
containers:
- image: mysql:8.4.0
name: mysql
ports:
- containerPort: 3306
name: mysqlUne fois appliqué, le déploiement créé bien le pod, mais une nouvelle erreur intervient. Cette fois-ci c’est une erreur de type CrashLookBackOff :
kubectl get pods NAME READY STATUS RESTARTS AGE mysql-67c5f7dcb8-sfx5h 0/1 CrashLoopBackOff 2 (20s ago) 60s
Vous lancez alors la commandekubectl describe afin d’avoir plus d’informations sur cette erreur :
kubectl describe pod/mysql-67c5f7dcb8-sfx5h [...] Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 18m default-scheduler Successfully assigned default/mysql-67c5f7dcb8-sfx5h to gke-cluster-1-default-pool-e55f41dd-85kb Normal Pulling 18m kubelet Pulling image "mysql:8.4.0" Normal Pulled 17m kubelet Successfully pulled image "mysql:8.4.0" in 17.129s (17.129s including waiting) Normal Created 16m (x5 over 17m) kubelet Created container mysql Normal Started 16m (x5 over 17m) kubelet Started container mysql Normal Pulled 16m (x4 over 17m) kubelet Container image "mysql:8.4.0" already present on machine Warning BackOff 3m1s (x67 over 17m) kubelet Back-off restarting failed container mysql in pod mysql-67c5f7dcb8-sfx5h_default(80374c4d-0d8d-4ecf-9f20-12e95be3dcf7)
En regardant les événements, vous voyez bien que le conteneur redémarre mais vous n’avez pas plus d’informations sur la cause du redémarrage.
Vous vient alors l’idée de regarder les logs générés par l’application. Peut-être aurez-vous plus d’informations sur la cause de l’erreur.
kubectl logs pod/mysql-67c5f7dcb8-sfx5h 2024-06-17 14:16:29+00:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 8.4.0-1.el9 started. 2024-06-17 14:16:29+00:00 [Note] [Entrypoint]: Switching to dedicated user 'mysql' 2024-06-17 14:16:29+00:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 8.4.0-1.el9 started. 2024-06-17 14:16:30+00:00 [ERROR] [Entrypoint]: Database is uninitialized and password option is not specified You need to specify one of the following as an environment variable: - MYSQL_ROOT_PASSWORD - MYSQL_ALLOW_EMPTY_PASSWORD - MYSQL_RANDOM_ROOT_PASSWORD
En examinant les journaux du conteneur, vous constatez qu'il génère des erreurs liées à l'absence d'une variable d'environnement définie lors de son démarrage. Vous retournez voir Alice pour lui faire part de votre découverte, mais vous lui dites que vous ne savez pas comment passer des variables d’environnement dans le conteneur.
Alice vous explique que tout ceci est normal car vous n’avez pas encore appris comment injecter une variable d’environnement dans un conteneur. Elle vous félicite alors d’avoir réussi à diagnostiquer cette erreur et vous fournit l’information à ajouter dans votre fichier. Votre fichier ressemble alors à ceci :
apiVersion: apps/v1
kind: Deployment
metadata:
name: mysql
spec:
selector:
matchLabels:
app: mysql
strategy:
type: Recreate
template:
metadata:
labels:
app: mysql
spec:
containers:
- image: mysql:8.4.0
name: mysql
env:
- name: MYSQL_ROOT_PASSWORD
value: my-password
ports:
- containerPort: 3306
name: mysqlUne fois le fichier modifié et appliqué dans le cluster :
Dans ce screencast, vous avez appris à :
récupérer l’erreur générée par le fichier Deployment ;
diagnostiquer la cause de l’erreur ;
corriger l’erreur en mettant la bonne version de l’image ;
ajouter un paramètre supplémentaire pour démarrer l’image.
A vous de jouer
Contexte
Au secours ! Un de nos développeurs a livré un fichier YAML, mais quand Charlie l’applique sur le cluster, celui-ci tombe en erreur !
Je n’ai pas le temps de m’en occuper, je suis occupée sur une feature importante à livrer avant ce soir.
En plus, l’application génère des informations importantes qui nous servent pour une autre application.
Je te remets le fichier YAML en question et te charge de corriger le fichier ! Pourrais-tu aussi récupérer les informations générées par l’application et me l’envoyer par mail ?
apiVersion: apps/v1
kind: Deployment
metadata:
name: mysql
spec:
selector:
matchLabels:
app: mysql
strategy:
type: Recreate
template:
metadata:
labels:
app: mysql
spec:
containers:
- image: mysql:8.4.0
name: mysql
ports:
- containerPort: 3306
name: mysqlConsignes
Corrigez le fichier fourni par Alice ;
Vérifiez que le déploiement s’exécute correctement ;
Récupérez les logs générés par l’application.
En résumé
La commande
kubectl logspermet de récupérer les logs applicatifs des pods. Cette commande permet de récupérer les informations de l’application.La commande
kubectl describepermet d’avoir plus d’informations lors d’une erreur de déploiement. Cette commande permet d’avoir des informations exhaustives de l’état des déploiements dans Kubernetes.La commande
kubectl eventspermet d’avoir accès à tous les événements du cluster Kubernetes. Elle permet de voir ce que le cluster a effectué comme tâche afin de garantir l’état désiré.
Dans le prochain chapitre, vous allez apprendre à exposer votre application via un service. Mais d'abord, un quiz pour tester vos connaissances !
