Le Calendrier de l'Avent du Cloud

Optimiser les images est une amélioration simple quand on parle d’augmenter les performances de Kubernetes. Les applications conteneurisées qui sont conçues pour tourner sur des machines virtuelles contiennent souvent des librairies ou supplément logique qui ne sont pas nécessaires dans le cas de déploiement en environnement conteneurisé. Adopter des images optimisées pour les conteneurs permet de réduire la taille des images et donc d’accélérer le téléchargement des images et le lancement des conteneurs par Kubernetes.

Une image adaptée pour les conteneurs c’est une image :

• Qui ne contient qu’une seule application ou qu’un seul traitement (ex : web-serveur OU Base de Données).
• Contient seulement une petite image, car les images lourdes sont plus difficilement portables.
• Qui utilise un système d’exploitation "container-friendly" (ex : Alpine) car ils sont plus résistants aux erreurs de configurations, ont une plus petite surface d’attaque et sont simplement plus légers. (cf. point n°2)
• Qui met en place un processus de build à plusieurs étapes qui permet de conserver une application de petite taille en ne déployant que l’application compilée et non ses fichiers sources.
• Qui met en place des endpoints de healthcheck et readiness, ce qui permettra à Kubernetes d’effectuer les actions adaptées si le container est hors-service.

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 oh-oh-oh-ns, vous devez ajouter le flag --namespace=oh-oh-oh-ns à 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, des services, etc 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 kubectl 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=oh-oh-oh-ns

L’auto-complétion de kubectl est essentielle pour une utilisation quotidienne d’un cluster kubernetes. Elle vous permettra 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 par l’utilisation d’une commande simple :

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

La commande ajoute l’auto-complétion au .bashrc, ainsi la prochaine fois que vous ouvrerez un shell, l’auto-complétion sera disponible.

Pour plus d’informations : bash auto-complétion

Stocker les fichiers configurations de votre cluster dans un outil de version 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 version tels que git, svn, mercurial et autres 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 !

Oui mais 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'

kubectl applique du yaml à votre cluster, la plupart de ces commandes génèrent donc des YAML complexes.

Utiliser le YAML généré des commandes kubectl permet de se créer des bases de fichiers Kubernetes, cette base permet de se prémunir d’un démarrage "from scratch". Extraire la sortie de kubectl donne accès à la structure YAML de ces objets via l'utilisation de la commande d’édition ou de génération de kubectl.

Voici quelques exemples d’extractions :

kubectl run busybox --image=busybox --dry-run=client -o yaml --restart=Never > busybox.yamlkubectl create job my-job --dry-run=client -o yaml --image=busybox -- date > job.yamlkubectl get -o yaml deploy/nginx > nginx.yaml

Via la commande kubectl top, vous pouvez afficher la consommation de ressources des nodes et des pods de vos clusters. C’est l’une des commandes les plus utilisées pour un premier monitoring de ces objets. Elle permet un accès rapide et simple à des informations essentielles à la fois sur la santé et sur les coûts engendrés par le fonctionnement d’une application.

Accéder aux consommations des nodes :

❯ k top node NAME CPU(cores) CPU% MEMORY(bytes) MEMORY% docker-desktop 4332m 72% 1585Mi 84%

Accéder aux consommations des pods :

❯ k top pods NAME CPU(cores) MEMORY(bytes) kuard-5795cd587d-8qtsd 1m 0Mi kuard-5795cd587d-df4qp 1m 0Mi kuard-5795cd587d-qsjt4 1m 0Mi kuard-tm75s 1m 0Mi

Chez KIOWY on adore tout tester directement en production !

C’est faux, tellement faux que ça a même été difficile à écrire ! Mais la problématique reste : comment tester des objets Kubernetes en amont pour éviter une catastrophe lors du déploiement sur un cluster de production ? Utiliser Minikube ou KinD.

Ces solutions permettent de mettre en place un cluster local directement sur votre machine ! Minikube est rapide et simple à installer et se démarre directement via la commande minikube start. Une fois lancé vous pouvez procéder à des actions comme sur n’importe quel cluster. Quant à KinD, abréviation de Kubernetes in Docker, il s’agit d’un outil qui permet de déployer un cluster directement dans Docker via la commande kind create cluster

Envie d’essayer ? Voici quelques liens pour vous aider :

Minikube

• Installer Minikube
• Installer Kubernetes avec Minikube

KinD

• Installer KinD

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 node 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. (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 ajouter :

KUBELET_KUBEADM_ARGS="--image-gc-high-threshold=60 --image-gc-low-threshold=50"

Une fois fait il ne vous reste plus qu'à redémarrer de Kubelet

systemctl daemon-reload systemctl restart kubelet

Le Scheduler de Kubernetes attribue les instances aux nœuds suivant un algorithme précis. Pour l’aider dans sa tâche vous pouvez spécifier les contraintes en ressources de ce dont vous demandez le déploiement. En définissant les requêtes et les limites de consommations ressources (CPU, RAM, etc..), vous optimisez le fonctionnement du scheduler et la stabilité de votre cluster par la même occasion.

La spécification de ces requêtes et ses limites vous permet de définir un profil pour votre application, ce profil définit la qualité de service de votre application ce qui va permettre au scheduler d'adapter au mieux sa stratégie d’attribution.

Pour définir ce profil, il suffit d’ajouter ces spécifications à votre application:

resources: requests: memory: 1Gi cpu: 250m limits: memory: 2.5Gi cpu: 750m

Définir un profil adapté au fonctionnement du micro-service fait partie des bonnes pratiques qui ont le plus d’impact sur le bon fonctionnement et la stabilité du cluster. Elle permet à la fois au scheduler de choisir le nœud idéal pour l'application à déployer mais aussi de définir la place de l’application dans la hiérarchie d'éviction. Maximisant ainsi les performances du nœud et du cluster.

Pour effectuer des actions sur différents namespaces ou 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. Super simple à mettre en place, ils sont tous les deux disponibles au sein du même dépôt Github : https://github.com/ahmetb/kubectx/

kubectx

kubens

Prenez 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 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. Différencier 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 pour ensuite procéder à l’ouverture des fonctionnalités au compte-gouttes suivant les acteurs.

Voici une astuce bien plus utile qu’il n’y paraît ! Kubernetes vous permet de spécifier une stratégie d’éviction des pods de vos applications. Abrégée PDB, pour Pod Disruption Budget, cette solution vous permet de garantir le "no downtime" d’une application sur cluster Kubernetes. Il permet de spécifier le nombre minimal d’instance disponible à tout instant.

Une fois déployé, le PDB devient obligatoire pour tous les déploiements qui contiennent plus d’une instance avec lesquels il est associé.

Pour créer un PDB, il suffit d’appliquer le YAML correspondant au cluster. Via le label selector vous définissez les applications sur lequel le PDB s’applique. Il faut bien comprendre que le PDB ne s’applique qu'en cas les perturbations “volontaires” du cluster. Dans le cas de la perte d’une machine, il ne pourra pas s’appliquer.

apiVersion: policy/v1beta1 kind: PodDisruptionBudget metadata: name: pdb-pour-les-app-a spec: minAvailable: 2 selector: matchLabels: app: app-a

Exemple de PDB pour toutes les applications avec le label app-a

Dans cet exemple, la spécification minAvailable défini pour les applications ayant le label app-a qu’en cas de node drain, l’evinction laissera en place deux instances de l’application.

kubectl propose de détailler les ressources et instances de ressource de l’api-server. Ce qui permet d’accéder à tous les champs disponibles ainsi qu'à leurs valeurs. En utilisant le flag -o kubectl vous pouvez afficher la sortie détaillée d’une ressource en YAML...

kubectl get deployments -o yaml

... mais aussi en JSON

kubectl get deployments -o yaml

À partir de ce type de sortie, vous avez de nombreuses possibilités pour traiter, adapter ou étendre la sortie de votre commande. Par exemple, en utilisant la sortie détaillée au format JSON, vous pouvez associer l’outil jq pour chercher dans la sortie les déploiements qui contiennent des réplicas en erreur :

kubectl get deployments | jq '.items[] | {name: .metadata.name, replicas: .status.replicas, available: (.status.availableReplicas // 0), unavailable: (.status.unavailableReplicas // 0)} | select (.unavailable > 0)'

Les machines d’un cluster sont rarement toutes identiques et comme nous l’avons vu dans l’astuce du jour 10, c’est le rôle du scheduler de choisir le nœud le mieux adapté pour déployer les pods de notre application. Mais il est également possible de plus ou moins d’orienter son choix par le biais de l’affinité des noeuds (Node Affinity) et de l’affinité des pods (Pod Affinity, mais elle on en reparlera plus tard 🧐).

L’affinité suivant le nœud permet au scheduler de sélectionner un nœud suivant une de ses caractéristiques. Disons que soyez en possession de deux nœuds, un avec une grande puissance CPU (32 cœurs) et l’autre plus orienté RAM avec moins de cœurs mais mémoire DDR4. Si ces spécificités sont décrites via labels, il vous suffira de décrire une affinité de nœud pour orienter le choix du scheduler vers la machine orienté CPU par nodeSelector.

… nodeSelector: cpuType: 32core

Votre affinité est créée ! Vous pouvez adapter comment et avec quelle force elle s’applique en utilisant les options :

• requiredDuringSchedulingIgnoredDuringExecution : À appliquer obligatoirement. Le scheduler ne déploiera les pods que sur les nœuds qui possèdent ce sélecteur.
• preferredDuringSchedulingIgnoredDuringExecution : À appliquer de préférence. Le scheduler va essayer de déployer sur un nœud possédant le sélecteur, si aucun n’est disponible il déploiera les pods sur le premier noeud disponible.

Il existe également d’autres options pour effectuer des affinités sur combinaisons logiques. Pour plus d’informations : Docs Kubernetes - Assigning Pods to Nodes

Probe est le nom qu’on donne aux sondes qui permettent de s’assurer de la santé d’une application. Fidèle à sa philosophie REST, Kubernetes autorise la définition de sondes. L’outil utilise lui-même ce type de mécanisme notamment dans le Kubelet pour s'assurer de la bonne santé des pods et des applications au sein d'un nœud.

On distingue deux types de probes :

• Readiness probes : qui aide à déterminer si les conteneurs d’une application sont prêts à recevoir du trafic.
• Liveness probes : qui aide à déterminer la santé d’un conteneur et s'il a besoin d’être redémarré.

Définissez vos sondes en suivant le formalisme du Kubelet pour que la gestion de votre application s’intègre à la gestion des autres éléments du cluster. Une fois configuré, il ne vous reste qu'à définir les actions qui seront effectuer suivants les retours de sondes en termes de délais, timeouts et retries.

Saviez-vous que les nœuds ont une odeur particulière ? Non, c’est pourtant tout le sujet de notre astuce du 17 décembre. Kubernetes permet de s’assurer que des pods ne se déploient pas sur un nœud spécifique via la notion de Taints ( qui n’a pas de traduction directe en français mais qui se rapproche de l’idée d’entacher ). Le Taints s’applique à un nœud et a un effet opposé à l’affinité, avec un peu plus d'agressive. Cette marque repousse les pods en les empêchant de se déployer sur le nœud sur lequel la marque est appliquée. Dans un cluster Kubernetes par défaut, c’est ce mécanisme qui permet d'orienter le déploiement des applications sur des nœuds de type worker plutôt que sur le ou les nœuds de type controller.

Pour appliquer un taint, vous utiliserez l’option kubernetes du même nom.

kubectl taint nodes backup1=backups-only:NoSchedule

Pour supprimer un taint, il suffit de spécifier - en fin de commande :

kubectl taint nodes backup1=backups-only:NoSchedule-

Pour permettre à des pods de se déployer malgré un taint, il faut que les pods en question est une tolération dans leurs spécifications. Le mécanisme de Taints & Tolérations est particulièrement utile si vous voulez dédier un nœud à l'exécution de Jobs de backup par exemple. Pour permet à un pod de passer outre un taint de nommer backup-only, ajoutez la tolération aux specs des pods a déployer :

spec: tolerations: - key: "backup1" operator: "Equal" value: "backups-only" effect: "NoSchedule"

On a vu hier qu’on pouvait appliquer les taints & tolérations en utilisant les labels, et on verra dans les prochains jours que c’est également le cas pour tous les autres mécanismes d’affinités. Pour éviter d’avoir à définir des labels et vous aidez à identifier les différents éléments, Kubernetes attribue des labels par défaut suivant les objets, les machines et leurs caractéristiques (ex : kubernetes.io/arch=amd64). Ces labels sont qualifiés de Well-Known et sont listés dans la documentation de Kubernetes

Liste des well-known labels : Well-Known Labels, Annotations and Taints

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 semble qu’il soit nécessaire d'utiliser un pod sans controlleur de plus haut niveau, par exemple un traitement qui ne doit pas redémarrer (option : restartPolicy: Never), la bonne practique reste d’utiliser l’objet Job.

Nous avons parlé d’affinités pour les nœuds mais saviez-vous que vous pouvez définir des affinités inter-pods ?

Vous pouvez spécifier dans les spécificités de vos pods, des affinités et anti-affinités pour définir la répartition et les regroupements des pods dans les nœuds du cluster. Ces définitions sont à l’échelle des pods et sont traitées par le scheduler. Spécifier les affinités inter-pods permet par exemple de définir qu’un web-serveur est toujours déployé à côté de sa base de données, et que deux réplicas d’une base de données ne sont jamais déployés sur le même noeud pour assurer la pérennité de la base en cas d'échec d'un noeud.

spec: affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: app operator: In values: - web-store topologyKey: "kubernetes.io/hostname" podAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: app operator: In values: - store topologyKey: "kubernetes.io/hostname"

Les Pod Security Standards définissent les politiques de sécurité à appliquer aux pods et se décomposent en trois niveaux.

• privileged - Pas de restriction, c’est le plus haut niveau de privilèges qui peut être accordé. Il permet notamment l’attribut des autres politiques de permissions.
• baseline - Politiques de restrictions minimales qui empêchent l’attribution de permissions. Il accorde le niveau minimal spécifié à la configuration du pod.
• restricted - Le plus haut niveau de restriction. Il suit les actuelles bonnes pratiques pour le renforcement de la sécurité des pods.

Ce découpage en niveau vient remplacer l’utilisation des Pod Security Policies qui sont dépréciés depuis Kuberetes v1.21 et seront supprimées du projet en v1.25.

Plus d’information sur :

• Kubernetes Documentation - Pod Security Standards
• Dépréciation des Pod Security Policies

On sait comme les latences réseaux peuvent être frustrantes, et l’utilisation de technologies cloud n’échappe pas au problèmes. Pour les limiter au maximum, vous pouvez réduire la distance physique entre les nœuds de votre cluster et les utilisateurs de vos applications.

La plupart des fournisseurs de cloud possèdent des datacenters dans de nombreuses zones géographiques. Choisir une zone proche des finaux permet de contribuer à une latence aussi basse que possible. Lors de vos déploiements, gardez en tête que suivant la zone de déploiement et le fournisseur choisi vous pourrez rencontrer des limitations ou des cas particuliers de restrictions qui peuvent influer sur la disponibilité de vos applications.

Nous l’avons vu le jour n°16, Kubernetes vous permet de mettre en place des sondes (probes) pour que les scheduler puisse s’assurer de l’état de santé de vos pods et prendre les actions nécessaire pour que votre cluster atteigne l’état que vous avez défini. Mais au-delà d’une fiabilisation du fonctionnement même de votre cluster, les métriques ainsi que les logs vous donnent une base d’information solide sur l’état de tous les objets déployés dans votre cluster. Vous pouvez mettre en place un outil d’agrégation de logs tel que fluentd pour avoir une vue d'ensemble des logs du cluster. Les sondes et les systèmes de suivis vous permettent d’intégrer simplement des outils de monitoring tels que par exemple Prometheus associés à Grafana pour avoir un dashboard qui regroupe un maximum d’informations et suivre les performances de votre cluster.

ETCD c’est la base de connaissance stateful de Kubernetes, sous la forme d’une base de donnée clé-valeur stocké dans le control plane du cluster. Un trafic d’informations important se fait entre l’objet etcd et le kube-apiserver. Quand c’est possible, choyer ce point de votre architecture, en mettant ces éléments sur le même nœud pour réduire la latence réseau par exemple ou en déployant le nœud qui les contient sur une machine avec SSD avec haut débit limitant les latences sur les entrées/sorties. Ce type d'optimisation technique maximisera les performances de etcd.

C’est sur cette dernière astuces que s’achève notre Calendrier de l’Avent du Cloud ! 🎄☁️ On espère que vous avez appris de ces astuces et bonnes pratiques. Besoin d’en savoir plus sur Kubernetes, le Cloud ou les infrastructures "as a Service" ? Que se soit pour discuter d’un point en particulier, d'un besoin d’accompagnement sur un projet ou de formation :