Les 6 bonnes pratiques à adopter pour votre architecture Kubernetes !
Depuis son lancement en 2015, Kubernetes est parvenu à devenir l’outil incontournable d’orchestration de conteneur et l’un des projets open-source les plus utilisés. En effet, avec l’avènement des conteneurs qui offrent une alternative plus souple et moins lourde que les machines virtuelles, des problématiques de déploiement et de gestion à grande échelle se sont imposées.
Kubernetes répond à cela avec une solution qui simplifie le déploiement d’applications conteneurisées et leurs élasticités, tout en apportant une meilleure optimisation des ressources hardware. Cet outil simplifie le travail des opérateurs, mais aussi des développeurs qui gagnent en capacité d’autonomie et de performance.
Cependant, malgré la puissance de cet outil, il existe des pièges dans lesquels ne pas tomber et cela passe par plusieurs bonnes pratiques à adopter le plus tôt possible :
1/ Conteneuriser oui, mais quoi ?
Avant d’aborder la gestion de l’architecture Kubernetes, il est important de ne pas perdre de vue la raison pour laquelle vous l’utilisez, c'est-à-dire la gestion d’applications conteneurisées. Il peut être tentant de conteneuriser toutes les parties d’une application, mais cela n’est pas forcément la bonne réponse.
Posez-vous les bonnes questions :
Est-ce que ce composant fonctionne en stateful ?
Même s'il est possible d’implémenter du stateful dans Kubernetes (les Volumes et les Stateful States sont là pour ça), cela peut générer de la complexité. Le principe de conteneur est de pouvoir facilement les détruire pour en recréer de nouveaux, et des composants stateful (data, …) pourraient complexifier votre exploitation de Kubernetes.
Votre application a-t-elle besoin d’absorber une charge importante ?
Les conteneurs se prêtent particulièrement bien à l’élasticité, et sont donc des bons choix pour une implémentation dans Kubernetes.
Bien d’autres critères existent (l’utilisation de Linux, les technologies utilisées, …). Il faut aussi garder en tête que conteneuriser des applications ne se fait pas en un claquement de doigt, cela nécessite souvent une refactorisation. Il est alors important de pouvoir évaluer les bénéfices à réaliser cette transformation, ce qui peut passer par une étude globale au préalable.
2/ Établir les règles d’architecture et d’exploitation
Afin de diviser de manière pertinente son architecture, plusieurs choix s’imposent :
Utiliser plusieurs namespaces dans un cluster
Utiliser plusieurs clusters
Le premier choix permet de garder les ressources proches dans le but d'optimiser l’exploitation des clusters, tandis que le second privilégie un isolement plus poussé et plus sécurisé.
Même s’il est possible de regrouper toutes ses ressources dans un cluster et un namespace unique, cela peut apporter des risques.
Les principaux facteurs qui vont influer cette segmentation sont :
L’isolation des environnements et des projets (exemple : SI RH vs SI métier / Environnement Test vs Production)
Le contrôle et l’optimisation des ressources
La définition de rôles et de permissions
En général, il convient d’utiliser un namespace pour chaque application. Des clusters pour les différents environnements sont également recommandés pour éviter les impacts entre la prod et la non-prod.
3/ Surveiller ses ressources
L’implémentation du monitoring est primordiale pour le bon fonctionnement de son architecture.
Une observabilité solide vous permettra de disposer des informations nécessaires pour un troubleshooting efficace, ainsi qu’une optimisation des ressources et des coûts. Ce paramètre est d’une importance majeure, car dans une architecture Kubernetes, définir la cause d’un dysfonctionnement peut s’avérer complexe.
Le choix des outils de monitoring est vaste et varié, mais l’on peut citer Prometheus comme étant l’un des plus populaires, souvent couplé avec Grafana pour la visualisation des données. Pour le logging plusieurs solutions existent, l’outil le plus utilisé chez nos clients est la suite ELK. Loki peut aussi être utilisé avec Prometheus et Grafana si l’on privilégie une gestion open-source des logs.
4/ La sécurité avant tout
L’un des axes directeurs dans l’exploitation de Kubernetes est la mise en place d’une sécurité robuste. Les configurations par défaut, la communication pod-to-pod, les images utilisées, … sont des facteurs à risques dans votre architecture.
Les premières étapes importantes à suivre peuvent se répartir selon 4 niveaux :
Le code applicatif : Analyse du code, suivi d’activité, …
Les images : Vérification des sources, limitation des conteneurs privilégiés, …
Les clusters : Suivi d’activité, RBAC, isolation des pods, …
L’infrastructure : Audit de logs, restriction des API de metadata, IAM, …
La sécurité est une préoccupation majeure : plus de 50% des organisations admettent qu'elles n'ont pas assez investi dans la sécurisation des conteneurs. Avoir une longueur d’avance dans ce domaine vous permettra d’avoir une architecture véritablement solide sur le long terme.
5/ Managé ou non managé ?
La gestion de l’architecture peut être radicalement différente selon le degré de management de vos services.
Le choix d’une solution non managée vous permettra de privilégier un contrôle total des ressources. Les nœuds et les logiciels nécessiteront une installation manuelle dans le cluster, tandis que la maintenance des configurations et des versions sont des éléments à prendre en charge.
L’un des points majeurs concernant cette solution est le degré de compétence requis de la part des administrateurs, ce qui peut être un challenge compte tenu du marché de l’emploi pour ce secteur.
Un moyen de pallier cette problématique est de choisir une solution managée. De cette manière, l’architecture va passer par un provider qui prendra en charge l’installation et la configuration des ressources. Le degré de management peut varier selon les providers, mais le concept reste le même, c’est-à-dire simplifier la gestion de l’environnement Kubernetes au prix d’une perte d’indépendance et de contrôle sur ses ressources.
Attention : le planning des mises à jour Kubernetes peut être décalé par rapport au rythme de sortie de la communauté open-source.
6/ Automatiser pour mieux régner
Les conteneurs et Kubernetes sont intimement liés à la mouvance DevOps et à l’automatisation. Plus vite vous serez mature dans l’automatisation, plus vite vous pourrez booster la productivité des développeurs et des opérateurs en leur offrant de la liberté et de l’autonomie.
Par exemple, une automatisation du provisionning de cluster va faciliter la création de nouveaux projets, tout en orientant l’architecture vers une segmentation par cluster.
Cette mise en place de l’automatisation sollicite un plus grand nombre de compétences de la part des collaborateurs, et comme présenté précédemment, les solutions managées peuvent aider. Des solutions open-source de la CNCF existent également pour les solutions non managées.
Avec ces conseils en tête, vous devriez être prêt à concevoir une architecture Kubernetes robuste et pérenne.
Si vous désirez en savoir plus, nous proposons un accompagnement de nos clients dans la définition de l’architecture, le pilotage de la migration vers Kubernetes et la sélection d’intégrateur pour assurer l’exploitation de votre solution.
Ne ratez pas nos futurs articles et nous espérons vous retrouver très vite !