Au cours des trois dernières années, j'ai navigué dans les eaux parfois tumultueuses de la gestion de clusters Kubernetes. Ce périple, riche en défis et en découvertes, m'a permis d'acquérir une compréhension approfondie de cette technologie de pointe et de ses multiples facettes. Dans cet article, je souhaite partager avec vous les dix leçons les plus précieuses que j'ai apprises en travaillant sur les clusters Kubernetes.

Leçon 1 : Préfére l'utilisation dans le cloud

Sauf contrainte extrême, il est inutile de gérer soi-même l'infrastructure sous-jacente de Kubernetes. Vous passerez votre temps à débugger des problèmes qui n'apportent aucune plus-value à votre entreprise. Être un expert de kube-api, kube-apiserver, kubelet, etcd, kube-proxy, etc., c'est bien, mais au quotidien devoir maintenir cela soi-même n'apporte pas de plus-value. Pas besoin de se prétendre expert de ces concepts pour gérer efficacement un cluster. Déléguez cette tâche bas niveau à des fournisseurs de services cloud (AWS, Azure, GCP, OVH…) qui le font mieux que vous. Chez @HK-TECH, nous avons fait le choix d'AWS et du cluster EKS (ECS ce n'est pas du Kubernetes !)

Leçon 2 : Déployez toute votre infrastructure liée à Kubernetes avec du code. 

Pas une seule brique de votre cluster ne doit avoir été faite à la main sur la console, même un simple tag. Surtout, pas de "J'ai fixé rapidement sur la console, je vais mettre à jour le code après". Mytho, vous ne le ferez jamais.

Leçon 3 : Évitez de multiplier l'utilisation des helm charts dont vous n'avez aucune maîtrise. 

Oui, c'est génial, ça marche vite, vous n'avez pas à vous casser la tête pour faire vos propres YAML, sauf le jour où vous allez faire une mise à jour qui va tout casser. Si vraiment vous avez la flemme et pas le temps, faites au moins l'effort de comprendre chaque variable du fichier values.yaml et surtout pas de valeur par défaut. Chez HK-Tech, la règle c'est pas de Helm chart, dans le pire, on récupère les templates.

Leçon 4 : Kubernetes n'aime pas le lift and shift. 

Il va falloir donc mettre la main dans vos vieilles applis pour les repenser afin qu'elles soient compatibles cloud. Ce n'est pas à Kube de s'adapter à votre appli, mais c'est à l'application de s'adapter. Si vous n'êtes pas en mesure de recoder vos applis, il faut peut-être rester sur vos bonnes vieilles VM.

Leçon 5 : Mesh ou pas mesh ? N'installez pas de service mesh si vous n'en avez pas besoin. 

Comment savoir si vous en avez besoin ? Posez-vous deux questions : Les applications de mon cluster communiquent-elles entre elles ? Les échanges entre les applications de mon cluster ont-ils besoin d'être sécurisés ? Si la réponse est oui aux deux, dans ce cas, l'installation d'un service mesh peut être utile. Je n'ai pas de recommandation à vous faire, globalement, ils se valent tous.

Leçon 6 : Évitez de multiplier les outils. 

Kubernetes a des tonnes d'outils annexes à vous proposer qui vous promettent monts et merveilles pour avoir une meilleure efficacité sur la gestion de vos clusters : argocd, lens, k9s, keda, krew, kubectx, kubens, kail… Évitez de les empiler, le bon ami kubectl répond à 90 % des besoins. À titre personnel, je me limite à l’utilisation de : kubectx, kubens, k9s qui me procure un vrai gain sur l’administration de mes clusters.

Leçon 7 : Toujours définir les limites de ressources (mémoire et CPU) allouées à vos pods. 

Cela vous évitera d'avoir le risque d’une application mal codée ou configurée qui va accaparer toutes les ressources de votre cluster et faire tomber vos applications les unes après les autres parce que certains pods sont un peu trop gourmands. C'est aussi l'une des raisons pour lesquelles vous devrez vous méfier des helm charts et toujours vérifier le code source des manifestes qui est derrière le bel emballage.

Leçon 8 : Pensez stateless. 

Dans l'idéal, il vaut mieux éviter de persister les données dans vos pods. Si pour une raison quelconque c'est pas possible de faire autrement, alors privilégiez les montages sur des NAS plutôt que sur des disques. Autrement, vous aurez la mauvaise surprise de constater que certains pods de votre déploiement n'ont pas accès aux ressources persistées. Et oui, un disque dur ne peut être monté sur un seul nœud, par conséquent si vos pods sont distribués sur plusieurs nœuds, les pods du même nœud verront les mêmes données mais pas ceux des autres nœuds. Avec le montage type NAS tel que EFS, vous éviterez ce problème.

Leçon 9 : Configurez HPA (Horizontal Pod Autoscaler). 

Si vous voulez éviter de continuer à travailler comme dans l'ancien monde et bénéficier de la puissance de Kubernetes sur la capacité d'autogérer l'utilisation des ressources selon la demande, il vous faudra configurer HPA sur tous vos projets d'applications. (Autre limite des helm charts, où c'est malheureusement souvent très absent).

Leçon 10 : N'ayez pas peur du changement. 

En moyenne par an, prévoyez 3 montées de version de votre cluster, soit une mise à jour tous les 4 mois. Certaines mises à jour sont transparentes, mais très souvent il y aura des changements avec impacts. Pour mieux préparer ces montées de versions, je vous recommande de lire, relire et encore relire les release notes et les retours d'expérience de ceux qui ont effectué les mises à jour avant vous.
Ce que je recommande et ce que nous avons mis en place chez HK-TECH, c’est d’être toujours une version en retard par rapport à la dernière version (sauf s'il y a des changements de sécurité).

Voilà, Happy Kubernetes."