🎄NoĂ«l approche
 ✹🎅
DĂ©couvrez le Calendrier de l’Avent du Cloud ! 🎄

Le Calendrier de l'Avent du Cloud

24 astuces sur Kubernetes

1. Utiliser une stratégie orientée conteneur, tu devras !

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.

1

2. Spécifier un namespace par défaut, il faudra !

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

2

3. Adoptes l'auto-complétion et ta vie changera !

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

3

4. Stocker les configurations dans un outil de controle de version il faudra.

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

4

5. Utilises des alias et du temps tu gagneras.

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'

5

6. Extraire du YAML Ă  partir de commande kubectl

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

6

7. La consommation des ressources tu afficheras.

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

7

8. En Minikube & KinD, des alliées tu trouveras.

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

KinD

8

9. Nettoyer les images Docker inutilisées, tu devras !

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

9

10. La qualité de service de tes applications, tu définiras.

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.

10

11. Entre les namespaces Kubernetes, tu navigueras.

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

kubectx demo GIF

kubens

kubens demo GIF

11

12. Les accÚs génériques à kubectl, redouter tu dois.

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.

12

13. La stratégie d'éviction des pods, tu adapteras

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.

13

14. Etendre kubectl en traitant les sorties de type raw

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)'

14

15. Configurez l'affinité des nodes

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

15

16. Utilisez des sondes (probes)

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.

16

17. Taints & Tolérations des pods

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"

17

18. Les well-known labels, tu utiliseras

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

18

19. Les pods orphelins, tu oublieras.

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.

19

20. Des rÚgles d'affinités, tu mettras en place

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"

20

21. DĂ©finissez des Pod Security Standards

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 :

21

22. DĂ©ployez votre cluster au plus prĂšs de vos utilisateurs finaux

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.

22

23. Utilisez les métriques comme base d'information

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.

23

24. Optimisez etcd

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.

Vous n’ĂȘtes pas seul !

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 :

24