Les Bonnes Pratiques sur Kubernetes

Avant de se lancer

Vous souhaitez maitriser toutes les bonnes astuces pour vos conteneurs applicatifs ? Notre formation Kubernetes vous apprendra tout ce qu’il y a à savoir sur l’outil et vous permettre d’automatiser et de gérer vos environnements d’applications conteneurisées.

L’équipe Ambient IT

Principes Fondamentaux

Kubernetes est basé sur des principes fondamentaux qu’il faut bien comprendre et appliquer pour être sûr de bien le faire fonctionner :

• Les Pods : ce sont les plus petites unités de Kubernetes, c’est un ensemble de 1 ou plusieurs conteneurs
• Les Services : ce sont les ensembles de pods
• Les Deployment : ce sont là où vous décrivez l’état souhaité de votre application
• Les SatefulSets : gére le déploiement et la mise à l’échelle des pods

Vous devez les connaître sur le bout des doigts avant toute chose. Et si ce n’est pas le cas, retournez immédiatement faire vos devoirs !

Haute Disponibilité

Qu’est-ce que la haute disponibilité dans Kubernetes ? C’est un système conçu pour être littéralement tout le temps disponible, et donc, résistant aux pannes et autres défaillances.

Ce n’est pas seulement un ensemble de sécurités à configurer, c’est une approche proactive complète lors de l’utilisation de l’outil.

Kubernetes dispose de mécanisme de haute disponibilité :

Utiliser le bon contrôleur pour Les replicas

Les réplicas sont gérées via un ReplicaSet ou avec des abstractions de plus haut niveau comme les Deployments ou les StatefulSets.

Ce sont elles qui garantissent qu’un nombre spécifique de pods est bien toujours actif.

Pour vous assurer que vos réplicas fonctionnent correctement, assurez-vous d’utiliser le bon contrôleur :

• Les Deployments sont plus adaptés aux applications sans état. Vous pouvez faire de la mise à jour continue et des retours en arrière
• Les StatefulSets sont eux idéaux pour les applications avec état qui ont besoin d’identifiants réseaux stables et uniques

Il est également nécessaire de s’assurer que vous avez bien défini les demande de ressources et les limites pour le processeur et la mémoire pour chacun de vos conteneurs.

configurer les Liveness et readiness probes

Ce sont des outils très important dans la haute disponibilité de Kubernetes, il est crucial de bien les comprendre :

• Les liveness probes déterminent si un pod est toujours en train de fonctionner. Si la sonde échoue, Kubernetes redémarre le pod concerné
• Les readiness probes déterminent si un module est prêt à recevoir du trafic. Si une sonde échoue, Kubernetes arrête simplement de lui envoyer du trafic

Pour vous assurer du bon fonctionnement de ses sondes, assurez-vous qu’initialDelaySeconds soit réglé sur une valeur appropriée.

successThreshold et failureThreshold vous permettent de déterminer à combien de réussite ou d’échec une sonde est considérée comme réussie ou terminée, alors ne vous en privez pas.

Un dernier conseil pour la route : évitez d’utiliser des endpoints qui mettent une charge lourde sur le serveur. Les sondes doivent utiliser des chemins légers et renvoyer des réponses rapidement.

Vous devez bien les configurer afin que vos applications restent opérationnelles, surtout en cas d’éventuelle défaillance technique.

Stratégies de Déploiement

S’il existe de nombreuses stratégies de déploiement, certaines sont plus conseillées que d’autres :

Rolling Update

Le rolling Update, ou mise à jour continue, permet de remplacer la version en cours d’exécution de votre application par une nouvelle version sans interruption de service.

En réalité, c’est la mise à jour par défaut de Kubernetes, c’est pourquoi la meilleure solution est tout simplement de ne pas la changer !

Cette stratégie s’assure que seul un certain nombre de pods sont hors service pendant la mise à jour afin de ne pas perturber le bon fonctionnement de votre application.

Cette stratégie est très dépendante des sondes (vues plus haut) donc, assurez-vous qu’elles fonctionnent bien.

Vous devez aussi vous assurer que les demandes et les limites soient finement réglées pour le CPU et la mémoire. Lors, des MaJ, les ressources fluctuent beaucoup donc soyez vigilants.

Blue/Green Deployment

Le blue/green deployment consiste à gérer les versions avec 2 environnements identiques configurés de la même manière :

• Le bleu héberge la version actuelle de l’application
• Le vert héberge la future version mise à jour

Un seul des environnements est actif à la fois, cela permet non seulement de ne pas avoir d’interruption lors d’une MaJ mais également de revenir facilement en arrière en cas de problème.

C’est une stratégie de déploiement plus sûre que le Rolling Update mais qui demande aussi plus de ressources et qui n’est pas spécialement adaptée si vous avez besoin de mettre régulièrement vos environnements à jour.

Pour réaliser ce type de déploiement, vous devez tout d’abord vous assurer que le bleu et le vert soient aussi identiques que possible. C’est crucial pour éviter les mauvaises surprises.

Configuration et déploiement

structurez vos fichiers YAML

Les fichiers YAML sont cruciaux dans l’utilisation de Kubernetes.

Ils doivent être clairs, bien structurés et surtout bien commentés ! La force des fichiers YAML est qu’ils sont lisibles par l’homme alors, profitez-en :

• Nommez vos fichiers YAML pour savoir ce qu’ils font d’un coup d’œil
• Répartissez les composants dans différents fichiers pour ne pas les rendre trop lourds
• Utilisez des répertoires à thème pour rassembler vos fichiers

Utiliser des modèles et des valeurs paramétrables est crucial car cela permet de les réutiliser plus facilement. Le déploiement dans différents environnements devient ainsi plus facile.

N’hésitez pas également à commenter vos fichiers afin de n’avoir aucun doute sur leur fonctionnement exact et pour pouvoir les partager avec d’autres personnes.

Intégrer des méthodes GitOps

Le GitOps permet de gérer l’état de votre infrastructure via des fichiers de configuration stockés dans un dépôt git.

C’est très pratique pour garantir la traçabilité et la révision de tous les changements que vous pourriez apporter à votre système.

Pour implémenter des méthodes GitOps dans Kubernetes, vous avez besoin d’un outil adéquat :

• Flux assure automatiquement que l’état du cluster correspond à la configuration Git. C’est un outil pratiquement autonome capable de se gérer lui-même
• ArgoCD est un outil de livraison continue, il a l’avantage d’être déclaratif comme Kubernetes

Si vous souhaitez implémenter des méthodes GitOps dans votre cluster Kubernetes, je vous conseille de ne pas le faire à moitié et de tout automatiser via les workflow git (mises à jour de l’infrastructure et de la configuration, les déploiements d’applications, etc.).

Évitez à tout prix les modifications manuelles de l’État et mettez en place des politiques de contrôle d’accès très strictes pour Git, car maintenant, c’est lui qui contrôle votre infrastructure.

Gestion des Ressources

Définir les limites et les requêtes de ressources

Vous devez assigner des requêtes et des limites de ressources à vos conteneurs. C’est très utile pour garantir une utilisation optimale des ressources du cluster et éviter les contentions :

• Les requêtes sont la quantité de CPU et mémoire que Kubernetes donne à un conteneur.
• Les limites sont la quantité maximale de mémoire et de CPU qu’un conteneur peut utiliser. Si un conteneur tente d’en utiliser plus, il sera « choke ».

Avant de déployer une application, vous devez vous assurer de bien évaluer ses besoins en ressources. Le but étant évidemment de donner assez de ressources, mais aussi d’éviter le surprovisionnement qui serait un gaspillage de ressources.

Assurer la Qualité de Service des pods

La Qualité de Service des Pods doit être ajustée en fonction des besoins de votre application. Connaitre les classes QoS de Kubernetes est crucial si vous voulez des applications performantes :

• Un pod est Guaranteed si chaque conteneur du module a des demandes et des limites de ressources spécifiées. Il faut aussi que les demandes et les limites soient les mêmes pour le CPU et la mémoire. C’est la classe à privilégier pour vos déploiements.
• Burstable veut dire qu’au moins un conteneur du module a des demandes de ressources différentes et des limites définies ou si seulement l’une des deux (CPU ou mémoire) est spécifiée. C’est une classe pensée pour les pods qui ont besoin de plus de ressources de temps en temps.
• BestEffort est la classe QoS la plus basse, ils n’ont aucune limite ou demande de ressources. C’est la classe à n’utiliser que pour les pods non critiques dont vous pouvez tolérer une interruption de service.

Stockage et Persistance

PersistentVolumes et StatefulSets

Les StatefulSets et PersistentVolumes sont vos meilleurs amis pour les applications qui demandent un stockage persistant. Il faut bien maitriser les méthodes pour les provisionner et les attacher à vos Pods :

• Pour les PersistentVolumes assurez-vous de choisir la bonne classe de stockage qui correspond bien à vos besoins en termes de performances et durabilité. Privilégiez aussi le provisionnement dynamique.
• Les StatefulSets ont besoins d’identifiants réseaux stables et uniques pour chaque pod. Utilisez bien PersistentVolumeClaims pour être sûr que chaque réplique dispose de son propre volume.

faut-il externaliser la gestion de l’état ?

Dans certains cas de figures, je vous conseille d’utiliser des services gérés pour la persistance des données.

Vous pouvez, par exemple, utiliser des bases de données en tant que service pour réduire la complexité opérationnelle.

Comment gérer efficacement le stockage persistant ?

Le stockage persistant doit être géré en planifiant une stratégie de sauvegarde claire dont vous comprenez bien les implications dans la portabilité et la disponibilité de vos applications.network policie kuber

Sécurité et Gouvernance

gérer les configurations et les secrets

Les ConfigMaps et les Secrets doivent impérativement être gérés de façon sécurisée

Montez les Secrets en tant que volumes plutôt qu’en variable d’environnement, cela permet de les cacher et de les rendre donc moins exposés.

Une autre bonne pratique pour vos secrets est le chiffrage au repos dans la base de données etcd. C’est une fonction native de Kubernetes et doit être utilisé autant que possible.

Les espaces de nom sont également cruciaux. Ils permettent un contrôle quasi total des accès aux secrets. Pour vous assurer de garder l’œil sur les accès, des outils de surveillances sont disponibles.

Enfin, la meilleure consigne à suivre est sans aucun doute la rotation régulière des secrets. Vous pouvez facilement l’automatiser pour en limiter le risque de fuite.

Mettre en place le RBAC

Le contrôle d’accès basé sur les rôles doit être votre premier réflexe dans la sécurisation de vos clusters Kubernetes.

C’est une méthode de régulation de l’accès aux ressources en fonction des rôles que vous donnez aux utilisateurs individuels au sein de votre entreprise.

La première règle que vous devez respecter est de toujours donner le minimum de droit possible. Il est toujours mieux qu’un utilisateur vous demande l’autorisation avant une action que de donner trop de privilèges à vos utilisateurs.

En utilisant les rôles prédéfinis donnés par Kubernetes, vous devriez pouvoir attribuer des accès facilement et sans grand risque.

Pourquoi et comment utiliser les Network Policies ?

Les Network Policies permettent de contrôler le trafic réseau entre les Pods.

C’est très pratique pour appliquer des règles de communication strictes et améliorer la sécurité du réseau. C’est aussi la meilleure pratique de sécurité en cas de configuration multienvironnement.

C’est aussi une excellente façon de mettre en place des accès minimaux (comme vu précédement).

Commencez par établir une politique par défaut. La pratique la plus classique, c’est de refuser par défaut tout le trafic entrant dans l’espace de noms (donc aucun accès au pods) sauf en cas d’exception (décidées par vous).

Il ne vous reste plus qu’à définir des règles pour autoriser le trafic entrant vers certains modules.

Il est possible de spécifier le trafic en fonction des étiquettes des modules, des espaces de noms ou des plages d’adresse IP.

Vous pouvez de la même façon définir des règles de sorties.

Comment garantir la sécurité et la conformité dans Kubernetes ?

Des politiques de sécurité comme les Pod Security Policies sont très pratiques pour réaliser des audits et être bien sûr que votre infrastructure est bien conforme aux bonnes pratiques de sécurité !

Conclusion

Adopter ces bonnes pratiques vous aidera à construire et à maintenir des applications robustes, sécurisées et évolutives

J’espère que cet article vous sera utile et que vous saurez appliquer ces recommandations dans vos environnements Kubernetes.