Formation DevOps | Formation kubernetes​ : 8 - Utilisation de kubectl commands

www.itgalaxy.io

Utilisation de kubectl commands

Dans ce chapitre on va manupuler la ligne de command kubectl :

Premier contact avec Kubectl

kubectl est (presque) le seul outil dont nous aurons besoin pour communiquer à API Kubernetes

• Il s’agit d’un outil CLI riche autour de l’API Kubernetes (Tout ce que vous pouvez faire avec kubectl, vous pouvez le faire directement avec l’API)

• Sur nos machines, il y a un fichier ~/.kube/config avec :

• l’adresse de l’API Kubernetes

• le chemin d’accès à nos certificats TLS utilisés pour s’authentifier

• Vous pouvez également utiliser l’indicateur –kubeconfig pour transmettre un fichier de configuration

• Ou directement –server, –user, etc.

• kubectl peut être prononcé “Cube C T L”, “Cube cuttle”, “Cube cuddle”.

The parallel avec kubectl

• Nous commençons souvent à gérer les clusters Kubernetes avec kubectl (déploiement d’applications, dépannage…)

• À grande échelle (avec de nombreuses applications ou clusters), cela devient fastidieux, répétitif et sujet aux erreurs

• Au lieu de cela, nous utilisons des pipelines automatisés, des outils d’observabilité, etc.

Dans de nombreux cas, nous avons encore besoin de kubectl :

• Pour débeuguer des scénarios délicats

• Inspecter et fouiller les choses

kubectl get

Regardez la composition de notre cluster :

kubectl get node

Ces commandes sont équivalentes :

kubectl get no
kubectl get node
kubectl get nodes

kubectl get peut générer du JSON, YAML ou être directement formaté :

Donnez-nous plus d’informations sur les nœuds :

kubectl get nodes -o wide

Prenons un peu de YAML :

kubectl get no -o yaml

(Ab) en utilisant kubectl et jq

C’est très simple de créer des rapports personnalisés

Afficher la capacité de tous nos nœuds sous forme de flux d’objets JSON :

kubectl get nodes -o json | jq ".items[] | {name:.metadata.name} + .status.capacity"

Explorer les types et les définitions

Nous pouvons lister tous les types de ressources disponibles en exécutant kubectl api-resources(Dans Kubernetes 1.10 et versions antérieures, cette commande était kubectl get)

Nous pouvons afficher la définition d’un type de ressource avec :

kubectl explain type

On peut visualiser la définition d’un champ dans une ressource, par exemple :

kubectl explain node.spec

Ou obtenez la définition complète de tous les champs et sous-champs :

kubectl explain node --recursive

Types et les noms

• Les noms de ressources les plus courants ont trois formes :

Singulier (par exemple, nœud, service, déploiement)

Pluriel (par exemple, nœuds, services, déploiements)

Court (par exemple non, svc, déployer)

• Certaines ressources n’ont pas de nom court

Les points de terminaison n’ont qu’une forme plurielle (car même une seule ressource Endpoints est en fait une liste de points de terminaison)

Affichage des détails

Nous pouvons utiliser kubectl get -o yaml pour voir tous les détails disponibles, cependant, la sortie YAML est souvent à la fois trop et pas assez

Par exemple, kubectl get node node1 -o yaml est :

• trop d’informations (ex : liste des images disponibles sur ce nœud)

• pas assez d’informations (par exemple : n’affiche pas les pods exécutés sur ce nœud)

• difficile à lire pour un opérateur humain

Pour un aperçu complet, nous pouvons utiliser kubectl décrire à la place

kubectl describe

kubectl describe a besoin d’un type de ressource et (éventuellement) d’un nom de ressource

Il est possible de fournir un préfixe de nom de ressource (tous les objets correspondants seront affichés)

kubectl describe récupérera des informations supplémentaires sur la ressource

Examinez les informations disponibles pour node1 avec l’une des commandes suivantes :

 kubectl describe node/node1
 kubectl describe node node1

(Nous devrions remarquer un tas de modules de plans de contrôle.)

Liste des conteneurs en cours d’exécution

Les conteneurs sont manipulés via des pods

Un pod est un groupe de conteneurs :

• fonctionnant ensemble (sur le même nœud)

• partage de ressources (RAM, CPU ; mais aussi réseau, volumes)

Répertoriez les pods sur notre cluster :

 kubectl get pods

Namespaces

Les namespace nous permettent de séparer les ressources

Répertoriez les namespace sur notre cluster avec l’une de ces commandes :

kubectl get namespaces
kubectl get namespace
kubectl get ns

Vous savez quoi… Ce truc du système Kube semble suspect.

En fait, je suis presque sûr que cela est apparu plus tôt, lorsque nous l’avons fait :

 kubectl describe node node1

Explorer Kube-public

Le seul objet intéressant dans kube-public est un ConfigMap nommé cluster-info

Répertoriez les objets ConfigMap :

  kubectl -n kube-public get configmaps

Inspectez les informations sur le cluster :

  kubectl -n kube-public get configmap cluster-info -o yaml

Explorer Kube-Node-Lease ?

À partir de Kubernetes 1.14, il existe un espace de noms kube-node-lease (ou dans Kubernetes 1.13 si la porte de fonctionnalité NodeLease est activée)

• ce namespace contient un objet Lease par nœud.

• Node leases sont une nouvelle façon d’implémenter node heartbeats .

Service

• Un service est un point de terminaison stable pour se connecter à « quelque chose » (Dans la proposition initiale, ils étaient appelés « portails »)

• Lister les services sur notre cluster avec l’une de ces commandes :

 kubectl get services
 kubectl get svc

Démarrer un pod simple avec Kubectl Run

Kubectl Run est pratique pour démarrer un seul pod

• Nous devons spécifier au moins un nom et l’image que nous voulons utiliser

• En option, nous pouvons spécifier la commande à exécuter dans le pod

• Envoyons une requête ping à l’adresse de localhost, l’interface de bouclage :

 kubectl run pingpong --image alpine ping 127.0.0.1

• Le résultat nous indique qu’un Pod a été créé :

pod/pingpong created














Streaming logs en temps réel

Tout comme les journaux Docker, les journaux kubectl prennent en charge des options pratiques :

• -f/–follow pour diffuser les journaux en temps réel (à la queue -f)

• –tail pour indiquer combien de lignes vous souhaitez voir (à partir de la fin)

• –since pour obtenir les journaux uniquement après un horodatage donné

Consultez les derniers journaux de notre commande ping :

  kubectl logs pingpong --tail 1 --follow

Arrêtez-le avec Ctrl-C

Scaling notre application

kubectl nous donne une commande simple pour faire évoluer une charge de travail :

kubectl scale TYPE NAME --replicas=HOWMANY

Essayons-le sur notre Pod, pour avoir plus de Pods !

Essayez de mettre à l’échelle le pod :

    kubectl scale pod pingpong --replicas=3

🤔 Nous obtenons l’erreur suivante, qu’est-ce que cela signifie ?

Error from server (NotFound): the server could not find the requested resource

Mise à l’échelle d’un pod

• Nous ne pouvons pas « faire évoluer un Pod » (ce n’est pas tout à fait vrai ; nous pourrions lui donner plus de CPU/RAM)

• Si nous voulons plus de Pods, nous devons créer plus de Pods (c’est-à-dire exécuter kubectl run plusieurs fois)

• Il doit y avoir une meilleure façon !

Création d’un déploiement en cours d’exécution ping

• Créons un déploiement au lieu d’un seul pod

• Créez le déploiement ; faites attention au –:

kubectl create deployment pingpong --image=alpine -- ping 127.0.0.1

• Le – est utilisé pour séparer : “options/flags de kubectl run , commande à exécuter dans le conteneur











Pouvons-nous scale maintenant ?

• Essayons à nouveau l’échelle kubectl, mais sur le déploiement !

• Faites évoluer notre déploiement pingpong :

kubectl scale deployment pingpong --replicas 3

• Notez qu’on pourrait aussi l’écrire ainsi :

kubectl scale deployment/pingpong --replicas 3

• Vérifiez que nous avons maintenant plusieurs pods :

kubectl get pods

Vérification des journaux de déploiement

Les journaux Kubectl ont besoin d’un nom de pod

Mais cela peut aussi fonctionner avec un type/nom (par exemple, déploiement/pingpong)

Visualisez le résultat de notre commande ping :

 kubectl logs deploy/pingpong --tail 2

Il nous montre les logs du premier Pod du Déploiement

Nous verrons plus tard comment récupérer les logs de tous les Pods !

Résilience

• Le pingpong de déploiement surveille son jeu de répliques

• Le jeu de réplicas garantit que le bon nombre de pods sont en cours d’exécution

• Que se passe-t-il si les pods disparaissent ?

• Dans une fenêtre séparée, regardez la liste des pods :

 watch Kubectl get pods

• Détruisez le pod actuellement affiché par les journaux kubectl :

 kubectl delete pod pingpong-xxxxxxxxxx-yyyyy

Ce qui s’est passé?

• kubectl delete pod termine le pod gracieusement (en lui envoyant le signal TERM et en attendant qu’il s’arrête)

• Dès que le pod est dans l’état « Terminating », le Replica Set le remplace

• Mais nous pouvons toujours voir la sortie du pod “Terminating” dans les journaux Kubectl

• Jusqu’à 30 secondes plus tard, à l’expiration du délai de grâce

• Le pod est ensuite tué et les journaux kubectl se terminent

Supprimer un pod autonome

Que se passe-t-il si nous supprimons un Pod autonome ?

(comme le premier Pod de pingpong que nous avons créé)

Supprimez le pod :

 kubectl delete pod pingpong

Aucun pod de remplacement n’est créé car aucun contrôleur ne le surveille

C’est pourquoi nous utiliserons rarement des Pods autonomes dans la pratique. (sauf par exemple pour un débogage ponctuel ou l’exécution d’une courte tâche supervisée)

1. Nous contactez

2. Infra as a Service

  • Description: Infrastructure cloud évolutive et sécurisée
  • Links:

3. Projets Développeurs

4. Développeurs

5. Formations Complètes

6. Marketplace

7. Blogs

This website is powered by ItGalaxy.io