kubectl : rôle et commandes de base

Auteur : Rédaction Domeny.ForSale Publié le 05.10.2026

En bref : kubectl est un outil en ligne de commande permettant d’utiliser Kubernetes, un système qui gère les applications exécutées dans des conteneurs. Il permet de vérifier l’état des applications, de déployer des changements, de consulter les logs et de gérer les ressources du cluster. Ce n’est pas Kubernetes lui-même, et il ne crée pas automatiquement un environnement pour exécuter les applications : il doit avoir accès à un cluster existant.

Comment kubectl interagit avec Kubernetes

Un cluster Kubernetes est un environnement composé de machines, appelées nœuds, et de composants qui gèrent l’exécution des applications. Un conteneur permet de regrouper une application et ses dépendances. Kubernetes exécute les conteneurs dans des unités appelées Pods ; un Pod peut contenir un ou plusieurs conteneurs qui fonctionnent ensemble.

kubectl s’exécute sur l’ordinateur d’un administrateur ou d’un développeur, ou dans un système qui automatise les déploiements. Il envoie des requêtes au serveur API de Kubernetes, le point de communication qui permet de consulter et de modifier les ressources du cluster. Il ne pilote pas directement chaque conteneur : ce sont les composants de Kubernetes qui effectuent les actions nécessaires pour atteindre l’état demandé.

Par exemple, si vous demandez de maintenir trois copies d’une application, kubectl transmet cette configuration à l’API. Kubernetes cherche ensuite à maintenir ces copies en fonctionnement. Vous pouvez fermer le terminal : l’exécution de l’application ne dépend pas du maintien du processus kubectl.

Ce qu’il faut pour commencer

Installer kubectl ne suffit pas. Vous avez besoin d’un cluster et des autorisations nécessaires pour l’utiliser. Il peut s’agir d’un environnement de test local, créé par exemple avec kind ou minikube, ou d’un cluster fourni par votre entreprise ou un fournisseur cloud.

Les informations de connexion se trouvent généralement dans un fichier kubeconfig. Celui-ci contient les adresses des clusters, les paramètres d’authentification ou des références aux mécanismes de connexion, ainsi que des contextes. Un contexte indique le cluster utilisé et l’utilisateur sous lequel vous intervenez ; il peut également définir un espace de noms par défaut. Un espace de noms, ou namespace, regroupe des ressources au sein du cluster.

La configuration se trouve par défaut dans $HOME/.kube/config, mais vous pouvez indiquer un autre fichier. Avant de commencer, vérifiez le client et la connexion active :

kubectl version --client
kubectl config current-context
kubectl cluster-info

La première commande vérifie la version de l’outil local, sans confirmer l’accès au cluster. La deuxième affiche le contexte sélectionné, et la troisième tente de récupérer des informations sur le cluster. Les erreurs peuvent provenir d’une configuration absente, de problèmes réseau, d’une authentification expirée ou d’autorisations insuffisantes.

Consultez la documentation officielle de Kubernetes pour connaître la procédure d’installation et les écarts de version pris en charge entre le client et le serveur. En entreprise, suivez également les instructions de connexion fournies par l’administrateur.

Commandes de base pour vérifier les applications

Les commandes prennent généralement la forme kubectl verbe type-ressource nom. Les options permettent notamment de choisir l’espace de noms et le format du résultat. Pour débuter, les opérations de lecture sont les plus utiles :

Commande	Utilisation
`kubectl get pods -n test`	Liste des Pods de l’espace de noms `test` et aperçu de leur état.
`kubectl describe pod NOM -n test`	Détails du Pod et événements utiles au diagnostic.
`kubectl logs NOM -n test`	Logs du conteneur dans le Pod indiqué.
`kubectl get deployments -n test`	État des ressources qui gèrent les copies de l’application.

Remplacez NOM par le nom réel du Pod. Si le Pod contient plusieurs conteneurs, l’option -c NOM_CONTENEUR peut être nécessaire pour consulter les logs.

Supposons que l’application ne réponde plus après un déploiement. Commencez par get pods pour vérifier si ses Pods fonctionnent. Utilisez ensuite describe pour rechercher des événements concernant, par exemple, le téléchargement de l’image ou le démarrage du conteneur, puis consultez les logs de l’application. L’état du Pod ne suffit pas toujours à déterminer la cause du problème.

Déployer des changements à partir d’un fichier YAML

kubectl peut créer des ressources à l’aide de commandes individuelles, mais la configuration d’une application est souvent enregistrée dans un manifeste, un fichier qui décrit l’état souhaité des ressources. Le format YAML est le plus courant. Vous pouvez conserver ce fichier dans un dépôt et examiner ses modifications avant le déploiement.

Le manifeste suivant crée un Deployment, une ressource qui maintient un nombre défini de copies de l’application et gère leur mise à jour :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo
spec:
  replicas: 1
  selector:
    matchLabels:
      app: demo
  template:
    metadata:
      labels:
        app: demo
    spec:
      containers:
        - name: nginx
          image: nginx:stable

Enregistrez-le sous le nom deployment.yaml. Dans un cluster de test, vous pouvez appliquer la configuration et vérifier la progression du déploiement :

kubectl apply -f deployment.yaml
kubectl rollout status deployment/demo
kubectl get pods -l app=demo

Cet exemple lance un serveur nginx, mais ne le rend pas automatiquement accessible sur Internet. L’accès réseau nécessite une configuration supplémentaire, souvent une ressource Service qui dirige le trafic vers les Pods. L’exécution de cet exemple dépend aussi de la possibilité de télécharger l’image et des ressources disponibles dans le cluster.

Éviter les modifications dans le mauvais environnement

kubectl peut servir à gérer aussi bien un environnement de test qu’un environnement de production. Avant toute opération modifiant les ressources, vérifiez le contexte et l’espace de noms. Vous pouvez les indiquer explicitement avec les options --context et -n, plutôt que de vous fier aux paramètres par défaut.

Avant d’appliquer un manifeste, vous pouvez utiliser kubectl diff -f deployment.yaml pour afficher les différences par rapport aux ressources existantes, ainsi que kubectl apply --dry-run=server -f deployment.yaml pour envoyer une requête d’essai sans enregistrer la modification. Ces commandes ne garantissent toutefois pas que l’application fonctionnera correctement après le déploiement.

La commande delete supprime des ressources et peut interrompre le fonctionnement de l’application. Traitez le kubeconfig comme un fichier sensible : ne le publiez pas dans un dépôt et n’utilisez pas de configuration provenant d’une source non fiable. Faites vos premiers exercices dans un cluster de test, en commençant par vérifier le contexte et consulter l’état des Pods.

Voir aussi : Qu’est-ce que FTP ?