Marques

Catégories de formation

Technique Microsoft

Utilisateur final Microsoft

Auto-apprentissage CKAd

Module 2

Broad Skills propose une large gamme de services de conseil en technologie open source

NOUS CONTACTER

CKAD Auto-apprentissage Mod 2

Dans ce module du cours de préparation en ligne CKAD Broad Skills, nous couvrirons les concepts de base et les sujets de configuration identifiés par le programme d'examen CNCF CKAD. Si vous n'êtes pas déjà familiarisé avec le programme, prenez un moment pour vous familiariser car vous devrez démontrer une connaissance de chaque sujet afin de réussir l'examen.

modules d'autoformation ckaD

Pods multi-conteneurs

Un pod peut exécuter un ou plusieurs conteneurs. Les pods multi-conteneurs sont étroitement couplés en ce sens que les conteneurs sont co-localisés, co-planifiés et les conteneurs partagent les mêmes espaces de noms network , uts et ipc. Il existe trois modèles de pods multi-conteneurs :

Side-car - les conteneurs side-car étendent et améliorent le conteneur "principal" dans la nacelle. Le diagramme ci-dessous montre un conteneur de serveur Web qui enregistre ses journaux dans un système de fichiers partagé. Le conteneur side-car de sauvegarde des journaux envoie les journaux du serveur Web à un agrégateur de journaux.

Ambassador - les conteneurs Ambassador représentent la connexion locale d'un pod avec le monde extérieur. Le diagramme montre un cluster Redis à trois nœuds (1, 2, 3). Le conteneur ambassadeur est un proxy qui envoie les lectures et écritures appropriées du conteneur principal de l'application au cluster Redis. Le conteneur d'application principal est configuré pour se connecter à un serveur Redis local, car les deux conteneurs partagent le même espace de noms uts.

Adaptateur - les conteneurs d'adaptateur standardisent et normalisent la sortie pour les systèmes de surveillance à distance qui nécessitent des formats de données standard. Le diagramme ci-dessous montre un conteneur d'adaptateur de surveillance exécutant un agent qui lit les données de l'application principale, les traite, puis exporte les données normalisées vers des systèmes de surveillance situés ailleurs sur le réseau.

Un pod multi-conteneurs est créé en spécifiant une ou plusieurs entrées de conteneur supplémentaires dans un manifeste de pod. Vous trouverez ci-dessous un exemple de pod multi-conteneurs avec un conteneur principal nginx et un side-car de conteneur fluent-bit en yaml. Le conteneur nginx écrit ses journaux dans un fichier à l'emplacement /tmp/nginx/ , qui est partagé entre tous les conteneurs du pod. Le conteneur Fluent-Bit lit le fichier à partir du répertoire partagé et le sort sur sa propre sortie standard.

apiVersion : v1

genre: Pod

métadonnées :

nom: side-car

spécification :

conteneurs :

- nom : nginx

image: nginx:dernière

volumeMontages :

- nom : vol-partagé

chemin de montage : /tmp/nginx/

commander:

- /bin/sh

- -c

- nginx -g 'démon désactivé ;' > /tmp/nginx/nginx.log

- nom : adaptateur

image : fluide/fluent-bit

commander:

- /bit-fluent/bin/bit-fluent

- -je

- queue

- -p

- chemin=/nginx/nginx.log

- -O

- sortie standard

volumeMontages :

- nom : vol-partagé

chemin de montage : /nginx

tomes :

- nom : vol-partagé

VideDir : {}

restartPolicy : OnFailure

Sondes de vivacité et sondes de préparation

Une sonde de vivacité est une vérification de l'état qui indique à un kubelet quand redémarrer un conteneur. Les sondes Liveness aident à attraper les verrous lorsqu'une application semble s'exécuter mais ne peut pas continuer. La mise en œuvre d'une sonde de vivacité dans un déploiement est un début pour créer une application d'auto-réparation.

Une application peut ne pas être immédiatement prête à accepter le trafic lorsque son conteneur démarre pour la première fois ; une sonde de préparation informe Kubernetes quand il est possible de commencer à envoyer du trafic vers un conteneur après son démarrage. Par exemple, un conteneur d'une application Java peut prendre quelques minutes à charger et peut ne pas être prêt à accepter le trafic tant qu'il n'est pas complètement exécuté. Dans ce scénario, la sonde de préparation atténue les longs temps de chargement.

Il existe trois options pour les sondes d'activité et de préparation :

exec - prend une commande, un code de sortie de 0 est successhttpGet - effectue un http get, un état 200-399 est goodtcpSocket - une connexion réussie à un port spécifié est un succès

Les sondes de vivacité et de préparation sont configurées de la même manière pour chaque conteneur d'un pod. Par exemple, le manifeste de pod suivant a un nginx . conteneur avec une sonde d'activité qui exécute un accès http au chemin racine du port 80. Si le serveur Web nginx répond avec un code 200 - 399, le pod est actif. La sonde de vivacité attend 10 secondes avant le premier contrôle et vérifie périodiquement toutes les 20 secondes. Compte::

apiVersion : v1

genre: Pod

métadonnées :

nom: ready-pod

Étiquettes:

application : ready-pod

spécification :

conteneurs :

- nom : nginx

image: nginx:dernière

vivacitéSonde :

httpObtenir :

chemin: /

ports : 80

InitialDelaySecondes : 10

périodeSecondes : 20

Journalisation des conteneurs

Kubernetes récupère les journaux de conteneur à partir de la sortie standard et des flux d'erreur standard d'un conteneur. Les applications exécutées dans le conteneur doivent sortir leurs journaux vers un emplacement lu par le moteur de journalisation du conteneur (généralement STDOUT).

Vous pouvez récupérer les journaux de conteneur avec la commande kubectl logs pod_name. Si le pod est un pod multi-conteneurs, le conteneur doit être spécifié avec l'option -c avec le nom du conteneur kubectl logs pod_name -c container_name

Dans cet exemple, nous créons un pod appelé logging-pod qui affiche la date et l'heure du système toutes les secondes.

$ kubectl exécuter logging-pod --generator=run-pod/v1 --image=busybox:latest \

--command -- /bin/sh -c ' while true; rendez-vous; dormir 1 ; terminé'

pod/logging-pod créé

Ensuite, les journaux du conteneur sont récupérés avec les journaux kubectl

$ kubectl enregistre logging-pod

Lun 24 févr. 23:25:16 UTC 2020

Lun 24 févr. 23:25:17 UTC 2020

Lun 24 févr. 23:25:18 UTC 2020

Lun 24 févr. 23:25:19 UTC 2020

Lun 24 févr. 23:25:20 UTC 2020

Voici d'autres options de journalisation de conteneur utiles :

--previous - récupère les journaux de conteneur à partir de l'instanciation précédente d'un conteneur, ceci est utile pour les conteneurs en boucle de crash -f - diffuse les journaux de conteneur --since - imprime les journaux depuis une période de temps spécifique, par exemple --depuis 15m --timestamps - inclut les horodatages

Surveillance des applications

Pour l'examen CKAD, la portée des applications de surveillance est uniquement dans la portée de Kubernetes (y compris le serveur de métriques Kubernetes). Les métriques clés à surveiller sont les ressources telles que le processeur et la mémoire, ainsi que les déploiements et leurs pods en cours d'exécution. Les étiquettes filtrent pour une application ou un domaine spécifique pendant la surveillance.

Le serveur de métriques Kubernetes n'est pas installé avec l'installation de Kubernetes à l'aide de kubeadm. Installez le serveur de métriques Kubernetes et apprenez-en plus sur le serveur de métriques ici.

Avec le serveur de métriques installé, vous pouvez afficher les ressources utilisées signalées par les kubelets sur chaque pod avec les pods supérieurs de kubectl :

$ kubectl top pods -n kube-system

NOM CPU(cœurs) MÉMOIRE(octets)

coredns-6955765f44-dwv9q 2m 8Mi

coredns-6955765f44-kjlc7 2m 8Mi

etcd-ubuntu 11m 71Mi

être apiserver-personnalité 27m 225Mi

kube-controller-manager-ubuntu 8m 36Mi

kube-proxy-zhhs8 1m 14Mi

être planificateur-ubuntu 2m 15Mi

metrics-server-64cfb5b5d8-cxq7d 1m 10Mi

tisser-net-fv9mb 1m 45Mi

Débogage

Le débogage des applications en cours d'exécution dans Kubernetes commence par la récupération d'informations d'état simples sur les pods.

Voici quelques endroits pour commencer à chercher :

Statut du pod : le pod est-il en cours d'exécution, en attente ou en boucle ? Nombre de redémarrages du pod : le pod a-t-il de nombreux redémarrages récents ? Ressources du pod : le pod demande-t-il plus de ressources disponibles dans son espace de noms ou sur son nœud ? Les détails du pod sont récupérés par introspection le pod avec kubectl décrit le pod pod_name .

Jetez un œil à la façon dont les problèmes courants de pod sont débogués à l'aide de la description du pod.

Voici les segments clés d'une description d'un pod en attente :

$ kubectl décrire le pod busybox

Nom: busybox

Espace de noms : par défaut

...

Statut: En attente

IP : 10.32.0.5

IP :

IP : 10.32.0.5

Conteneurs :

myapp-conteneur :

Identifiant du conteneur :

Image : occupéBOX

...

Conditions:

Type Statut

Initialisé Vrai

Prêt Faux

ConteneursPrêt Faux

PodSchedulé Vrai

...

Événements:

Type Raison Âge De Message

---- ------ ---- ---- -------

Normal Scheduled 10s default-scheduler Attribué avec succès la boîte par défaut/busybox à ubuntu

Avertissement InspectFailed 9s (x2 over 9s) kubelet, ubuntu Échec de l'application de la balise d'image par défaut « busyBOX » : n'a pas pu analyser la référence d'image « busyBOX » : format de référence non valide : le nom du référentiel doit être en minuscules

Avertissement Échec de 9s (x2 sur 9s) kubelet, erreur ubuntu : InvalidImageName

La section Événements de la description indique que le nom de l'image n'est pas valide. La correction du nom de l'image résoudra ce problème.

Voici un autre pod en attente :

$ kubectl obtenir des pods

NOM ÉTAT PRÊT REDÉMARRAGE ÂGE

nginx 0/1 En attente 0 2m15s

Ce pod nginx est en attente depuis plus de 2 minutes.

Regardons les événements du pod .

$ kubectl décrire pod nginx | grep -A4 Événements

Événements:

Type Raison Âge De Message

---- ------ ---- ---- -------

Avertissement FailedScheduling 76s (x4 sur 3m54s) default-scheduler 0/1 nodes sont disponibles : 1 CPU insuffisant.

Les ressources disponibles dans le cluster sont insuffisantes. Nous pouvons voir si le pod fait une demande de ressource matérielle en consultant la section Conteneurs de la description du pod.

$ kubectl décrire pod nginx | grep -A10 Conteneurs

Conteneurs :

nginx :

Image : nginx

Port:

Port hôte:

Limites:

processeur : 2

mémoire : 2Gi

Demandes :

processeur : 1500 m

mémoire : 1536 Mi

Le pod demande 1500m de cpu. Il n'y a pas de nœuds dans le cluster avec 1500 m d'espace libre de processeur, le pod reste donc en attente. Il existe plusieurs façons de résoudre ce problème : réduisez la demande de processeur du conteneur, libérez du processeur sur un nœud de cluster ou ajoutez un nouveau nœud de travail au cluster.

Exercice d'entraînement

Créez un pod multi-conteneurs nommé ckad-sidecar contenant les éléments suivants :

Le conteneur principal s'appelle nginx et exécute l'image nginx. awk NR==4 && tail -f /dev/null Le pod ne redémarre qu'en cas d'échec, puis récupérez les journaux du conteneur à partir du conteneur busybox.