Bash completion des commandes kubectl

Les commandes et options de kubectl sont nombreuses, heureusement il est possible de configurer bash pour les auto-compléter.

Sur Linux, il faut installer le paquet bash-completion puis exécuter la commande suivante :

echo "source <(kubectl completion bash)" >> ~/.bashrc

Rappels, diagnostics avec describe et logs

Lorsqu'un Pod est en erreur, les deux premières choses à vérifier sont les logs des conteneurs et les évènements du Pod.

Pour les logs :

kubectl logs --tail 500 <nom du pod>

Pour les évènements :

kubectl describe <nom du pod>

Le Status du Pod donnera une piste sur la cause de l'échec :

• Waiting : l'image du Pod ne peut problement pas être récupérée depuis le registre (vérfier l'imagePullSecret)
• Pending : le Pod ne peut pas être ordonnancé (manque de ressources, impossible d'obtenir un PV, etc.)
• Failure : le Pod a démarré puis a échoué, vérifier les logs

L'option --previous permet de consulter les logs du conteneur précédent (celui qui a échoué et a été remplacé par un nouveau)

kubectl get logs --previous <nom du pod>

Forcer la suppression d'un Pod

À leur suppression, les Pods sont arrêtés "gracieusement" avec un délai qui leur est alloué. Pendant cette période ils sont dans l'état Terminating.

Il arrive que les Pods reste bloqué dans cet état, ou qu'on ne veuille tout simplement pas attendre l'arrêt gracieux du Pod. Il est possible dans ce cas d'arrêter le Pod de manière instantanée.

kubectl delete pod <nom du pod> --grace-period=0 --force

Obenir un shell à l'intérieur du cluster

Il est souvent utile d'obtenir un shell à l'intérieur du commande, par exemple pour tester la résolution DNS des services.

La commande suivante démarre un Pod (--restart Never = pas de création de Deployment) en mode intéractif à partir d'une image busybox.

kubectl run -it shell --image busybox --restart Never --rm -- sh

Mettre un pod en quarantaine

Les sélecteurs de labels des ReplicaSets et des Services peuvent être utilisées à des fins de diagnostic.

Lorsqu'un Pod faisant partie d'un ReplicaSet présente un comportement anormal, il peut être utile de le mettre "de côté" le temps du diagnostic. Il suffit pour cela de supprimer le label sélectionné, sur le Pod en question.

Par exemple, pour un ReplicaSet définit comme tel :

selector:
  matchLabels:
    app: mon-app

On ira supprimer le label app=mon-app sur le Pod défaillant. En conséquence, il sera remplacé par un nouveau Pod sain, et le Pod défaillant ainsi mis en quarantaine peut être diagnostiqué serainement.

De la même manière, on pourra isoler un Pod du point de vue réseau en supprimant le label sélectionné par le Service correspondant.

Forcer la mise à jour d'une image taguée latest

Lorsqu'un Deployment créé des Pods basés sur une image taguée :latest, il n'y a pas de solution "propre" de forcer la mise à jour de l'image. Le plus simple dans ce cas là est de supprimer les Pods, ce qui provoquera un pull de l'image.

kubectl delete pod <nom du pod>

Appliquer plusieurs manifestes d'un coup

La plupart des commandes qui permettent d'appliquer un manifeste acceptent un répertoire en argument. Ceci permet d'appliquer d'un coup tous les manifestes contenus dans un répertoire

kubectl apply -f ./chemin/vers/repertoire/

Définir des limites de ressources par défaut

Les requêtes et limites de ressources permettent d'indiquer les ressources requises par un Pod, ainsi que la quantité maximale de ressources qui lui sont allouées.

Exemple :

containers:
  - name: db
    ...
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

Une bonne pratique est de spécifier ces valeurs pour tous les conteneurs, il est cependant facile d'oublier de le faire.

Kubernetes offre la possibilité de définir des valeurs par défaut pour les requêtes et les limites de ressources, au niveau de chaque namespace. Ces limites par défaut sont définis par les objets LimitRange.

Exemple :

apiVersion: v1
kind: LimitRange
metadata:
  name: mylimits
spec:
  limits:
  - max:
      cpu: "2"
      memory: 1Gi
    min:
      cpu: 200m
      memory: 6Mi
    type: Pod
  - default:
      cpu: 300m
      memory: 200Mi
    defaultRequest:
      cpu: 200m
      memory: 100Mi
    max:
      cpu: "2"
      memory: 1Gi
    min:
      cpu: 100m
      memory: 3Mi
    type: Container

Les LimitRange permettent aussi de définir des valeurs minimum et maximum pour les limites et les requêtes.

Comparer des ressources déployées avec un manifeste local

Il peut être judicieux de vérifier les changements effectués sur un manifeste avant de l'appliquer (par exemple après avoir fait de nombreuses modifications sur un long manifeste).

Kubectl dispose d'une commande méconnue qui permet d'afficher un diff entre la ressource déployée sur le cluster un son manifeste.

kubectl alpha diff manifest.yaml

Afficher les détails des requêtes kubectl

Enfin, il peut être intéressant de visualiser les requêtes qui sont effectivement envoyées au cluster lors de l'exécution d'une commande kubectl (par exemple pour développer une application cliente de l'API du cluster)

On peut exécuter kubectl en mode verbeux pour afficher toutes les requêtes, les réponses et leurs en-têtes.

kubectl get pods --v=8