Vous travaillez avec Kubernetes tous les jours ? Vous vous demandez comment éviter de refaire (encore et encore...) les mêmes tâches ?
Reminder de l’édition 2021 du Calendrier de l’Avent du Cloud et excellentes premières pierres pour améliorer vos habitudes, voici 7 bonnes pratiques opérationnelles pour la gestion de votre cluster Kubernetes.
L’auto-complétion de kubectl est essentielle pour une utilisation quotidienne d’un cluster Kubernetes. Elle vous permet de gagner du temps sur la rédaction des commandes mais également de voir les options disponibles suivant les actions que vous souhaitez effectuer. Vous pouvez mettre en place l’auto-complétion bash en utilisant cette commande :
echo "source <(kubectl completion bash)" >> ~/.bashrcLa commande ajoute l’auto-complétion au .bashrc, ainsi la prochaine fois que vous ouvrirez un shell, l’auto-complétion sera disponible.
Pour plus d’informations 👉 bash auto-complétion
L’utilisation des namespaces Kubernetes permet de séparer votre cluster en plusieurs environnements identifiés par différents noms et pouvant être managés par différents utilisateurs. Un des inconvénients à l’utilisation de kubectl, c’est que pour travailler dans un namespace particulier, disons working-namespace, vous devez ajouter le flag --namespace=working-namespace à la fin de chacune de vos commandes. Il est donc fréquent d'oublier cette option et de se retrouver avec des objets tels que des déploiements, ou encore des services, dans le mauvais namespace (ex : default).
Avec cette astuce, vous pouvez spécifier un namespace (de préférence avant d'exécuter vos commandes kubectl). En utilisant la commande suivante, les commandes qui suivront seront exécutées en utilisant ce nouveau contexte et donc le namespace que vous avez choisi !
kubectl config set-context --current --namespace=working-namespacePour effectuer des actions sur différents namespaces, ou sur différents clusters, il est possible de naviguer entre eux en quelques commandes. Mais saviez-vous que des outils peuvent simplifier votre navigation ?
kubectx et kubens font partie de ces outils. Ils permettent de naviguer respectivement entre les contextes et entre les namespaces. Très simple à mettre en place, ils sont tous les deux disponibles au sein du même dépôt Github 👉 https://github.com/ahmetb/kubectx/
Stocker les fichiers de configuration de votre cluster dans un outil de gestion de versions vous permet de conserver l’évolution de la configuration. C’est essentiel pour le suivi de cette dernière puisque les objets Kubernetes sont amenés à être détruits et recréés. Évitez au maximum d’effectuer des changements de configuration directement sur les objets du cluster. Une fois appliquée sur un objet, la nouvelle configuration écrase la précédente. Impossible de revenir simplement à la version précédente à moins d’avoir une mémoire d’exception !
Préférez donc l’utilisation d'outils de versions tels que git, svn ou encore mercurial, pour suivre les changements de configuration, faciliter les rollbacks et aider à la re-création et la restauration du cluster.
La rédaction de commandes kubectl peut rapidement tourner au roman ! Pour y remédier, et également accélérer le temps de rédaction, vous pouvez mettre en place des alias. Plus besoin de taper kubectl un nombre incalculable de fois et votre clavier vous en remerciera !
Mais alors quels alias sont vraiment pertinents ? 🤔
IBM a listé les alias à mettre en place pour couvrir les commandes les plus utilisées de kubectl :
alias k='kubectl'
alias kc='k config view --minify | grep name'
alias kdp='kubectl describe pod'
alias krh='kubectl run --help | more'
alias ugh='kubectl get --help | more'
alias c='clear'
alias kd='kubectl describe pod'
alias ke='kubectl explain'
alias kf='kubectl create -f'
alias kg='kubectl get pods --show-labels'
alias kr='kubectl replace -f'
alias kh='kubectl --help | more'
alias krh='kubectl run --help | more'
alias ks='kubectl get namespaces'
alias l='ls -lrt'
alias ll='vi ls -rt | tail -1'
alias kga='k get pod --all-namespaces'
alias kgaa='kubectl get all --show-labels'Kubernetes met en place un processus de "garbage collection" qui nettoie les images inutilisées. Ce processus est géré par le Kubelet qui tourne sur chaque noeud du cluster. Le Kubelet surveille automatiquement les images et supprime de manière périodique toutes les images inutilisées.
L’algorithme établit l’ordre de suppression en fonction du stockage utilisé par l’image et à quand remonte sa dernière utilisation. Par conséquent, une image lourde inutilisée depuis une semaine sera supprimée avant une image de plus petite taille ayant été utilisée pour la dernière fois hier.
Cette fonctionnalité peut être modifiée et adaptée suivant le besoin ! Vous pouvez décider quand le processus de "garbage collection" doit s'exécuter suivant l’utilisation du disque est définissant le seuil de déclenchement du processus (high-threshold) et l’utilisation du disque qu’il doit chercher à atteindre (low-threshold).
Pour définir ces seuils, vous utiliserez deux flags de configuration du Kubelet :
image-gc-high-threshold ➡️ Qui définit le seuil de déclenchement (par défaut 85%).image-gc-low-threshold ➡️ Qui définit le seuil à atteindre (par défaut 80%).Pour les définir, rendez-vous dans les variables environnements du Kubelet (/var/lib/kubelet/kubeadm-flags.env) et ajoutez :
KUBELET_KUBEADM_ARGS="--image-gc-high-threshold=60 --image-gc-low-threshold=50"Ensuite, il ne vous reste plus qu'à redémarrer de Kubelet
systemctl daemon-reload
systemctl restart kubeletPrenez garde aux accès que vous accordez aux utilisateurs qui utilisent kubectl. Kubernetes est construit pour être utilisé par une multitude d'équipes par cluster, offrant ainsi des accès sans restriction à de nombreuses fonctionnalités, notamment administratives, qui permettent de gérer toutes les facettes du cluster.
Veillez donc à votre chaîne de permission, ainsi qu’aux permissions que vous accordez autant aux utilisateurs humains qu’à vos comptes de services !
À ce jour, la meilleure solution reste une bonne classification des permissions suivant les environnements virtuels (namespace) et suivant les acteurs qui opèrent dans ces environnements (via l'utilisation de politique RBAC). Répertoriez les différents niveaux et façon d’y accéder. Une bonne pratique concernant la gestion des permissions est la fermeture de tous les accès par défaut pour ensuite procéder à l’ouverture des fonctionnalités au compte-gouttes suivant les besoins.
Qualifiés par la communauté de "Naked" Pods, les pods dits “orphelins” sont ceux qui ne sont pas liés à un contrôleur de plus haut niveau (ReplicaSets, Deployments, ...). Comme ils ne sont pas managés, ils ne seront pas relancés en cas d'erreur ou d'échec du nœud.
En utilisant des objets Deployment et donc des ReplicasSet, vous assurez le nombre de pods que vous désirez voir disponible et pouvez également spécifier la stratégie à adopter pour remplacer les pods. Il est donc toujours préférable d’utiliser ces contrôleurs de haut niveau, plutôt que de déployer des pods directement.
Pour des cas particuliers où il vous parait nécessaire d'utiliser un pod sans contrôleur de plus haut niveau, par exemple un traitement qui ne doit pas redémarrer (option : restartPolicy: Never), la bonne pratique reste d’utiliser l’objet Job.
