Kubectl est l'outil en ligne de commande (CLI) principal pour interagir avec l'API Kubernetes et gérer votre cluster. Il permet de déployer des applications, inspecter et gérer les ressources du cluster, et visualiser les logs.
kubectl essentiellesPour les exemples suivants, nous utiliserons un Pod simple :
# pod-busybox.yaml
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: busybox
image: busybox:1.36
# Garde le conteneur en vie
command: ['sh', '-c', 'sleep 3600']
# Appliquer ce pod pour les tests
kubectl apply -f pod-busybox.yaml
Ces commandes permettent d'obtenir des informations sur les objets Kubernetes.
kubectl getAffiche des informations de base sur une ou plusieurs ressources.
# Syntaxe générale
kubectl get <type_objet> [<nom_objet>] [-n <namespace>] [-o <format>] [--selector <label_selector>] [--sort-by <jsonpath>]
# Lister tous les pods dans le namespace courant ('default')
kubectl get pods
# Lister les pods dans un autre namespace
kubectl get pods -n kube-system
# Obtenir des informations détaillées sur un pod spécifique
kubectl get pod my-pod -o wide
# L'option '-o wide' ajoute des colonnes comme IP, NODE
# Obtenir la définition YAML complète d'un pod
kubectl get pod my-pod -o yaml
# Obtenir la définition JSON
kubectl get pod my-pod -o json
# Lister tous les pods triés par nom de noeud
kubectl get pods --all-namespaces -o wide --sort-by=.spec.nodeName
# Lister les pods avec un label spécifique (ex: app=mon-app)
kubectl get pods --selector app=mon-app
# Lister plusieurs types de ressources
kubectl get pods,services
| Option | Description |
|---|---|
-n, --namespace |
Spécifie le namespace |
-o, --output |
Format de sortie (wide, yaml, json, jsonpath, custom-columns, etc.) |
--selector, -l |
Filtre basé sur les labels (ex: app=nginx, env=prod,tier=frontend) |
--sort-by |
Trie les résultats en utilisant une expression JSONPath (ex: .metadata.name) |
--all-namespaces, -A |
Liste les ressources dans tous les namespaces |
kubectl describeFournit une vue détaillée et lisible d'une ressource spécifique, incluant les événements associés. Très utile pour le dépannage.
# Syntaxe
kubectl describe <type_objet> <nom_objet> [-n <namespace>]
# Décrire le pod 'my-pod'
kubectl describe pod my-pod
# Décrire un noeud
kubectl describe node k8s-worker1
Le résultat inclut des informations sur la configuration, le statut, les conditions, les ressources allouées et les événements récents liés à l'objet.
kubectl logsAffiche les logs d'un conteneur dans un Pod.
# Syntaxe
kubectl logs <nom_pod> [-c <nom_conteneur>] [-n <namespace>] [--follow] [--previous] [--tail <lignes>]
# Afficher les logs du pod 'my-pod' (s'il n'a qu'un conteneur)
kubectl logs my-pod
# Afficher les logs d'un conteneur spécifique si le pod en a plusieurs
# kubectl logs my-multi-container-pod -c specific-container
# Suivre les logs en temps réel (comme 'tail -f')
kubectl logs my-pod --follow
# Afficher les logs du conteneur précédent (s'il a redémarré)
kubectl logs my-pod --previous
# Afficher les N dernières lignes de logs
kubectl logs my-pod --tail=50
Ces commandes permettent de créer ou de mettre à jour des objets.
kubectl createCrée une ou plusieurs ressources à partir de fichiers YAML/JSON ou de la ligne de commande (moins courant pour les objets complexes).
# Créer une ressource à partir d'un fichier
kubectl create -f mon-objet.yaml
# Créer un namespace
kubectl create namespace mon-namespace
# Créer un déploiement simple (méthode impérative)
kubectl create deployment mon-nginx --image=nginx
kubectl createéchoue si la ressource existe déjà. Il est généralement préférable d'utiliserkubectl applypour une approche déclarative.
kubectl applyApplique une configuration à une ressource par nom de fichier ou stdin. C'est la méthode recommandée pour gérer les objets Kubernetes de manière déclarative. Elle crée la ressource si elle n'existe pas, ou la met à jour si elle existe.
# Syntaxe
kubectl apply -f <fichier_ou_url_ou_repertoire>
# Appliquer la configuration d'un fichier
kubectl apply -f mon-objet.yaml
# Si mon-objet.yaml est modifié, ré-exécuter la commande mettra à jour l'objet.
# Appliquer tous les fichiers .yaml dans un répertoire
kubectl apply -f ./mon-repertoire/
apply est idempotente : l'appliquer plusieurs fois avec le même fichier ne change rien après la première application réussie (sauf si le fichier change).
kubectl editOuvre la configuration d'une ressource dans votre éditeur de texte par défaut ($EDITOR). Après enregistrement et fermeture, kubectl tente d'appliquer les modifications.
# Syntaxe
kubectl edit <type_objet> <nom_objet> [-n <namespace>]
# Éditer la configuration du pod 'my-pod'
kubectl edit pod my-pod
Attention : Toutes les modifications ne sont pas autorisées sur un objet existant (par exemple, la plupart des champs
specd'un Pod sont immuables).editest utile pour des changements rapides maisapply -fest plus robuste pour la gestion des configurations.
kubectl execExécute une commande dans un conteneur d'un Pod.
# Syntaxe
kubectl exec <nom_pod> [-c <nom_conteneur>] [-n <namespace>] -- <commande> [args...]
# Exécuter 'ls /' dans le conteneur du pod 'my-pod'
kubectl exec my-pod -- ls /
# Obtenir un shell interactif dans le conteneur (-i: stdin, -t: tty)
kubectl exec -it my-pod -- sh
kubectl deleteSupprime des ressources par nom, label, fichier ou type.
# Syntaxe
kubectl delete <type_objet> <nom_objet> [-n <namespace>]
kubectl delete -f <fichier.yaml>
kubectl delete <type_objet> -l <label_selector>
# Supprimer le pod 'my-pod'
kubectl delete pod my-pod
# Supprimer la ressource définie dans un fichier
kubectl delete -f mon-objet.yaml
# Supprimer tous les pods avec le label 'env=test'
kubectl delete pods -l env=test
# Supprimer tous les pods et services avec le label 'app=myapp'
kubectl delete pods,services -l app=myapp
kubectl api-resourcesListe les types de ressources disponibles dans le cluster, leurs versions API et s'ils sont liés à un namespace.
$ kubectl api-resources
NAME SHORTNAMES APIVERSION NAMESPACED KIND
bindings v1 true Binding
componentstatuses cs v1 false ComponentStatus
configmaps cm v1 true ConfigMap
endpoints ep v1 true Endpoints
events ev v1 true Event
limitranges limits v1 true LimitRange
Notez les raccourcis (
SHORTNAMES) commepopourpods,svcpourservices,nspournamespaces,deploypourdeployments, etc. Vous pouvez utiliserkubectl get poau lieu dekubectl get pods.
kubectl pour l'examen CKAIndispensable pour gagner du temps !
# Activer l'auto-complétion pour la session bash actuelle
source <(kubectl completion bash)
# Activer l'auto-complétion de manière permanente (ajouter au ~/.bashrc)
echo "source <(kubectl completion bash)" >> ~/.bashrc
# Créer un alias court pour kubectl
alias k=kubectl
# Activer l'auto-complétion pour l'alias 'k'
echo "complete -F __start_kubectl k" >> ~/.bashrc
# Recharger le .bashrc ou ouvrir un nouveau shell pour appliquer
source ~/.bashrc
Pour créer rapidement des objets simples sans écrire de YAML complet.
# Créer un déploiement Nginx
k create deployment nginx --image=nginx
# Créer un service NodePort pour le déploiement nginx sur le port 80
k expose deployment nginx --port=80 --type=NodePort
# Lancer un pod temporaire pour le débogage
k run tmp-busybox --image=busybox:1.36 --rm -it -- sh
# '--rm' supprime le pod à la sortie, '-it' donne un shell interactif
--dry-run=client -o yaml pour générer du YAMLExtrêmement utile pour obtenir rapidement une base de fichier YAML pour un objet.
# Générer le YAML pour un déploiement sans le créer
k create deployment mon-nginx --image=nginx --dry-run=client -o yaml > mon-deploiement.yaml
# YAML généré :
$ cat mon-deploiement.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
creationTimestamp: null
labels:
app: mon-nginx
name: mon-nginx
spec:
replicas: 1
selector:
matchLabels:
app: mon-nginx
strategy: {}
template:
metadata:
creationTimestamp: null
labels:
app: mon-nginx
spec:
containers:
- image: nginx
name: nginx
resources: {}
status: {}
# Générer le YAML pour un service
$ k create service clusterip mon-svc --tcp=80:8080 --dry-run=client -o yaml
apiVersion: v1
kind: Service
metadata:
creationTimestamp: null
labels:
app: mon-svc
name: mon-svc
spec:
ports:
- name: 80-8080
port: 80
protocol: TCP
targetPort: 8080
selector:
app: mon-svc
type: ClusterIP
status:
loadBalancer: {}
Modifiez ensuite le fichier YAML généré avant de l'appliquer avec k apply -f ....
kubernetes.io/docs)Pendant l'examen CKA, vous avez accès à la documentation officielle. Utilisez-la !
Cherchez des exemples de YAML pour les types d'objets dont vous avez besoin.
RBAC est le mécanisme standard pour contrôler l'accès aux ressources de l'API Kubernetes. Il permet de définir finement qui (Subject) peut faire quoi (Verbs) sur quelles ressources (Resources) et où (Namespace ou Cluster-wide).
Les composants principaux de RBAC sont :
User, un Group, ou un ServiceAccount.get, list, watch, create, update, patch, delete).Role : Permissions limitées à un namespace spécifique.ClusterRole : Permissions applicables à l'ensemble du cluster (ressources cluster-wide comme les nodes, ou toutes les ressources d'un certain type dans tous les namespaces).Role ou ClusterRole à un ou plusieurs Subjects.
RoleBinding : Lie un Role à un Subject dans un namespace spécifique. Peut aussi lier un ClusterRole à un Subject, mais les permissions du ClusterRole seront limitées au namespace du RoleBinding.ClusterRoleBinding : Lie un ClusterRole à un Subject pour l'ensemble du cluster.Imaginons que nous voulions donner à un utilisateur dev-user la permission de lire (get, list, watch) les Pods et leurs logs dans le namespace dev.
Créer le Role (pod-reader-role.yaml) :
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: dev # Important: Ce Role ne s'applique qu'au namespace 'dev'
name: pod-reader
rules:
- apiGroups: [""] # "" indique le core API group
resources: ["pods", "pods/log"] # Ressources ciblées
verbs: ["get", "watch", "list"] # Actions autorisées
Créer le RoleBinding (pod-reader-binding.yaml) :
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: read-pods-dev
namespace: dev # Important: Le binding est aussi dans le namespace 'dev'
subjects:
- kind: User
name: dev-user # Nom de l'utilisateur (doit exister ou être géré par un système externe)
apiGroup: rbac.authorization.k8s.io
roleRef: # Lie au Role créé précédemment
kind: Role # Type de référence (Role ou ClusterRole)
name: pod-reader # Nom du Role à lier
apiGroup: rbac.authorization.k8s.io
Appliquer les fichiers :
kubectl create namespace dev # Si le namespace n'existe pas
kubectl apply -f pod-reader-role.yaml
kubectl apply -f pod-reader-binding.yaml
Maintenant, dev-user peut lister les pods dans le namespace dev, mais pas les supprimer ni accéder aux pods d'autres namespaces.
Kubernetes ne gère pas nativement les objets User. Contrairement aux ServiceAccount, il n'y a pas de ressource API pour créer un utilisateur standard comme dev-user. L'authentification des utilisateurs est déléguée à des mécanismes externes configurés sur le serveur API.
Pour l'exemple ci-dessus et dans de nombreux scénarios (y compris l'examen CKA), l'identité de dev-user serait établie via un certificat client X.509. Voici les étapes générales pour créer un tel utilisateur :
Générer une clé privée pour l'utilisateur :
openssl genrsa -out dev-user.key 2048
Créer une demande de signature de certificat (CSR) :
Le CN (Common Name) sera le nom d'utilisateur (dev-user) et O (Organization) peut spécifier les groupes.
# Remplacer /O=dev-group si vous souhaitez associer l'utilisateur à un groupe RBAC
openssl req -new -key dev-user.key -out dev-user.csr -subj "/CN=dev-user"
Créer un objet CertificateSigningRequest dans Kubernetes :
Encodez le fichier .csr en base64 et créez un objet YAML.
# Encoder le CSR en base64 (pour l'insérer dans le YAML)
cat dev-user.csr | base64 | tr -d '\n'
# Copier le résultat
# Créer le fichier csr.yaml
cat <<EOF > dev-user-csr.yaml
apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
name: dev-user-csr
spec:
request: # Coller le CSR encodé en base64 ici
signerName: kubernetes.io/kube-apiserver-client # Signataire pour les certificats clients
usages:
- client auth # Usage requis pour l'authentification client
EOF
# Appliquer le YAML
kubectl apply -f dev-user-csr.yaml
Approuver la CSR :
Un administrateur du cluster doit approuver la demande.
kubectl certificate approve dev-user-csr
Récupérer le certificat signé :
kubectl get csr dev-user-csr -o jsonpath='{.status.certificate}' | base64 --decode > dev-user.crt
Configurer kubectl pour le nouvel utilisateur :
Ajoutez les crédentials et créez un contexte pour dev-user.
# Ajouter les crédentials
kubectl config set-credentials dev-user --client-key=dev-user.key --client-certificate=dev-user.crt --embed-certs=true
# Créer un contexte liant l'utilisateur au cluster et au namespace 'dev'
# Pour récupérer le nom du cluster
kubectl config get-clusters
kubectl config set-context dev-context --cluster=<votre-nom-de-cluster> --namespace=dev --user=dev-user
# Utiliser le nouveau contexte (pour tester les permissions)
kubectl config use-context dev-context
# Vérifier (devrait fonctionner grâce au RoleBinding)
kubectl get pods -n dev
# Tenter une action non autorisée (devrait échouer)
controlplane:~$ k get pod
No resources found in dev namespace.
controlplane:~$ k get pod -n kube-system
Error from server (Forbidden): pods is forbidden: User "dev-user" cannot list resource "pods" in API group "" in the namespace "kube-system"
Cette méthode via certificats est l'une des façons de gérer l'authentification. D'autres méthodes comme les tokens OIDC sont courantes en production. L'important est de comprendre que la définition de l'utilisateur et son authentification sont distinctes de son autorisation (gérée par RBAC).
Un ServiceAccount fournit une identité pour les processus s'exécutant dans des Pods afin qu'ils puissent interagir avec l'API Kubernetes. C'est un type de Subject pour RBAC.
Chaque namespace a un ServiceAccount par défaut (default), mais il est recommandé de créer des ServiceAccounts spécifiques pour vos applications avec des permissions minimales.
Créer un ServiceAccount (myapp-sa.yaml) :
apiVersion: v1
kind: ServiceAccount
metadata:
name: myapp-sa
namespace: default # Ou un autre namespace
Lier le ServiceAccount à un Role (ou ClusterRole) via un RoleBinding (myapp-sa-binding.yaml) :
Supposons que nous voulions que ce ServiceAccount puisse lire les ConfigMaps dans son namespace.
Créer un Role configmap-reader (similaire à pod-reader mais pour configmaps et verbs: ["get", "list"]).
Créer le RoleBinding :
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: read-configmaps-myapp
namespace: default
subjects:
- kind: ServiceAccount # Le sujet est un ServiceAccount
name: myapp-sa # Nom du ServiceAccount créé
namespace: default # Namespace du ServiceAccount
roleRef:
kind: Role
name: configmap-reader # Nom du Role donnant accès aux ConfigMaps
apiGroup: rbac.authorization.k8s.io
Utiliser le ServiceAccount dans un Pod :
apiVersion: v1
kind: Pod
metadata:
name: my-app-pod
namespace: default
spec:
serviceAccountName: myapp-sa # Spécifie le SA à utiliser
containers:
- name: my-app
image: bitnami/kubectl:latest # Utilise une image avec kubectl
# Maintient le conteneur en fonctionnement pour pouvoir utiliser 'exec'
command: ["tail", "-f", "/dev/null"]
# Ce conteneur peut maintenant lire les ConfigMaps dans le namespace 'default'
# si le RoleBinding est correctement configuré pour myapp-sa
Pour donner des permissions à travers tout le cluster (par exemple, lister tous les Nodes).
Créer le ClusterRole (node-reader-clusterrole.yaml) :
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
# Pas de namespace pour un ClusterRole
name: node-reader
rules:
- apiGroups: [""]
resources: ["nodes"] # Ressource cluster-wide
verbs: ["get", "list", "watch"]
Créer le ClusterRoleBinding (read-nodes-global-binding.yaml) :
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: read-nodes-global
subjects:
- kind: User
name: cluster-admin-trainee
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole # Référence à un ClusterRole
name: node-reader # Nom du ClusterRole à lier
apiGroup: rbac.authorization.k8s.io
La commande kubectl auth can-i permet de vérifier si un utilisateur ou un ServiceAccount a une permission spécifique.
# Est-ce que je peux créer des déploiements dans le namespace 'default' ?
kubectl auth can-i create deployments --namespace default
# Est-ce que l'utilisateur 'dev-user' peut lister les pods dans 'dev' ?
kubectl auth can-i list pods --namespace dev --as dev-user
# Est-ce que le ServiceAccount 'myapp-sa' dans 'default' peut obtenir des secrets ?
kubectl auth can-i get secrets --namespace default --as system:serviceaccount:default:myapp-sa
Les ResourceQuotas limitent la consommation de ressources agrégées par namespace.
| Type | Exemples de Limites |
|---|---|
| Compute | requests.cpu, requests.memory, limits.cpu, limits.memory |
| Storage | requests.storage, persistentvolumeclaims, <storageclass>.storageclass.storage.k8s.io/requests.storage |
| Objects | pods, services, configmaps, secrets, deployments.apps, jobs.batch |
apiVersion: v1
kind: ResourceQuota
metadata:
name: compute-resources
namespace: dev
spec:
hard:
requests.cpu: "10"
requests.memory: 20Gi
limits.cpu: "20"
limits.memory: 40Gi
requests.storage: 100Gi
persistentvolumeclaims: "10"
pods: "50"
services: "20"
count/deployments.apps: "15"
kubectl apply -f compute-resources-quota.yaml
kubectl get resourcequota -n dev
Important : Si un namespace a un ResourceQuota pour requests.cpu ou requests.memory, tous les Pods doivent spécifier des requests/limits (sinon rejetés).
Error from server (Forbidden): must specify limits.cpu,limits.memory,requests.cpu,requests.memory
Solution : Utiliser un LimitRange pour définir des valeurs par défaut.
Les LimitRanges définissent des contraintes par défaut, minimales et maximales pour les ressources individuelles (Pods, Containers, PVC) dans un namespace.
| ResourceQuota | LimitRange |
|---|---|
| Limite agrégée du namespace | Limite par objet individuel |
| Ex: Max 20 CPU total | Ex: Chaque container max 2 CPU |
| Vérifié à la création de l'objet | Appliqué/modifié à la création |
limits (si non spécifiées)requests (si non spécifiées)limit et request (évite l'overcommit excessif)apiVersion: v1
kind: LimitRange
metadata:
name: resource-constraints
namespace: dev
spec:
limits:
- type: Container
default:
cpu: 500m
memory: 512Mi
defaultRequest:
cpu: 250m
memory: 256Mi
max:
cpu: 2
memory: 2Gi
min:
cpu: 100m
memory: 128Mi
maxLimitRequestRatio:
cpu: 4
memory: 2
kubectl apply -f resource-constraints-limitrange.yaml
Pod sans requests/limits → Kubernetes injecte automatiquement les valeurs default et defaultRequest du LimitRange.
# Pod déployé sans resources
spec:
containers:
- name: nginx
image: nginx
# Résultat après application du LimitRange
spec:
containers:
- name: nginx
image: nginx
resources:
requests:
cpu: 250m
memory: 256Mi
limits:
cpu: 500m
memory: 512Mi
Recommandation : Utiliser les deux ensemble. LimitRange assure que chaque container a des requests/limits appropriées, ResourceQuota limite la consommation totale du namespace.
Les Pod Security Standards définissent 3 niveaux de sécurité pour les Pods. Ils sont appliqués via Pod Security Admission (remplace PodSecurityPolicy déprécié).
| Contrôle | Privileged | Baseline | Restricted |
|---|---|---|---|
| Containers privilégiés | ✓ | ✗ | ✗ |
| hostNetwork/PID/IPC | ✓ | ✗ | ✗ |
| hostPath volumes | ✓ | ✓ | ✗ |
| runAsNonRoot | ✗ | ✗ | Obligatoire |
| Capabilities | Toutes | Drop dangerous | Drop ALL (uniquement NET_BIND_SERVICE : port <1024) |
| Seccomp | Optionnel | Optionnel | Obligatoire |
| Privilege escalation | ✓ | ✓ | ✗ |
| Mode | Effet |
|---|---|
| enforce | Rejette les Pods non-conformes |
| audit | Enregistre une violation dans les logs d'audit |
| warn | Affiche un warning à l'utilisateur mais autorise |
kubectl label namespace production \
pod-security.kubernetes.io/enforce=restricted \
pod-security.kubernetes.io/audit=restricted \
pod-security.kubernetes.io/warn=restricted
apiVersion: v1
kind: Pod
metadata:
name: safe-pod
namespace: production
spec:
securityContext:
runAsNonRoot: true
runAsUser: 1000
seccompProfile:
type: RuntimeDefault
containers:
- name: nginx
image: nginx
securityContext:
allowPrivilegeEscalation: false
capabilities:
drop:
- ALL
readOnlyRootFilesystem: true
volumeMounts:
- name: cache
mountPath: /var/cache/nginx
volumes:
- name: cache
emptyDir: {}
restricted (enforce + audit + warn)baseline (enforce), restricted (warn)warn, puis audit, enfin enforcePour utiliser les commandes kubectl top node et kubectl top pod, vous devez installer le Metrics Server. C'est un agrégateur de données d'utilisation des ressources à l'échelle du cluster.
Installation du Metrics Server :
La méthode d'installation peut varier légèrement selon les versions de Kubernetes. Une méthode courante consiste à appliquer un manifeste fourni.
# ATTENTION: Vérifiez la compatibilité de ce manifeste avec votre version K8s
# URL potentiellement plus à jour: https://github.com/kubernetes-sigs/metrics-server
# Pour K8s >= 1.19 (avec APIService v1)
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml
Note : Sur certains environnements (comme Minikube, k3s, certains clouds managés), Metrics Server peut être déjà installé ou nécessiter une commande d'activation spécifique (ex:
minikube addons enable metrics-server). De plus, si vos nœuds ont des IPs internes uniquement, une configuration supplémentaire (--kubelet-preferred-address-types=InternalIP) peut être nécessaire dans le déploiement du Metrics Server. Sur du Bare Metal, il peut-être nécessaire d'autoriser les certificats auto signés--kubelet-insecure-tlssur l'arg du déploiement.
Une fois le Metrics Server déployé et opérationnel (cela peut prendre une minute ou deux pour qu'il collecte les premières métriques), vous pouvez utiliser kubectl top :
# Afficher l'utilisation CPU/Mémoire des noeuds
$ kubectl top node
NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
k8s-control 243m 12% 1600Mi 42%
k8s-worker1 84m 4% 868Mi 22%
k8s-worker2 149m 7% 859Mi 22%
# Afficher l'utilisation CPU/Mémoire des pods dans le namespace courant
$ kubectl top pod
NAME CPU(cores) MEMORY(bytes)
my-deployment-5f85c44867-2xqrq 0m 3Mi
my-deployment-5f85c44867-tnvlv 0m 3Mi
# Afficher les pods dans un autre namespace
kubectl top pod -n kube-system
# Trier les pods par utilisation CPU
kubectl top pod --sort-by=cpu
# Trier les pods par utilisation mémoire
kubectl top pod --sort-by=memory
kubectl top est très utile pour avoir un aperçu rapide de la consommation des ressources.