Conteneurs se sont imposés comme la norme pour le cloud native développement d’applications, et Kubernetes, également appelé K8s, est sans doute l’outil d’orchestration de conteneurs le plus populaire. Une étude de la Cloud Native Computing Foundation (CNCF) a révélé que 91 % des répondants utilisent Kubernetes, dont 83 % en production. Ce chiffre était de 78 % l’année précédente.
Toutefois, la popularité n’est pas synonyme de facilité d’utilisation. Kubernetes est un système complexe. Sa prise en main nécessite une importante courbe d’apprentissage. Même si les bonnes pratiques et recommandations Kubernetes suivantes ne s’appliquent pas toutes à votre situation, celles qui sont pertinentes peuvent vous aider à tirer davantage parti de Kubernetes, plus facilement et plus rapidement.
À lire également : Les principales entreprises du cloud
20 bonnes pratiques Kubernetes
1) Opter pour un hébergement chez un fournisseur
Utilisez un hébergement externe pour lancer votre déploiement Kubernetes. Selon le type de service hébergé choisi, votre équipe n’aura pas à provisionner manuellement les composants du plan de contrôle, à ajouter des nœuds pour étendre votre cluster ni à configurer les pods qui prennent en charge vos conteneurs. Elle n’aura pas non plus à mettre en œuvre le contrôle d’accès basé sur les rôles (RBAC) pour sécuriser vos environnements distincts, ni à instrumenter la supervision et la journalisation de votre cluster.
2) Utiliser la dernière version
Utilisez la version la plus récente de Kubernetes. Outre les mises à jour et les fonctionnalités supplémentaires, la dernière version contient des correctifs pour les failles de sécurité des versions précédentes. C’est essentiel pour atténuer bon nombre des vulnérabilités susceptibles d’affecter votre cluster. Les anciennes versions bénéficient également d’un support moindre de la part de la communauté Kubernetes.
3) Utiliser un système de contrôle de version
Vous devez stocker les fichiers de configuration liés à votre déploiement, à l’ingress, aux services et les autres fichiers dans un système de contrôle de version avant de les envoyer vers un cluster. Cela vous aide à savoir qui a effectué les modifications et à mettre en place un processus d’approbation des changements afin d’améliorer la stabilité et la sécurité de votre cluster.
4) Utiliser des labels et des annotations
À mesure que le nombre d’objets de votre cluster augmente, il devient plus difficile de les trouver et de les organiser. Les labels ─ structures clé/valeur attribuées aux objets ─ permettent d’associer des métadonnées pertinentes et porteuses de sens aux objets du cluster, afin de les catégoriser, de les retrouver et d’agir sur eux en bloc.
Vous pouvez utiliser les labels pour déterminer si un pod fait partie d’un déploiement de production ou canary, et s’il appartient au front-end ou au back-end. Ils peuvent également indiquer à quelle couche appartient un objet et sa version, ainsi que distinguer les versions stables des versions alpha.
5) Utiliser des sondes de disponibilité et de vivacité
Les sondes de disponibilité et de vivacité sont essentiellement des contrôles d’état de santé. Une sonde de disponibilité vérifie qu’un pod donné est opérationnel avant d’autoriser l’acheminement de la charge vers celui-ci. Si le pod n’est pas prêt, les requêtes sont retirées de votre service jusqu’à ce que la sonde confirme qu’il est opérationnel. Une sonde de vivacité vérifie si l’application fonctionne toujours. Elle tente d’interroger le pod pour obtenir une réponse, puis vérifie son état de santé. En l’absence de réponse, l’application ne fonctionne pas sur le pod. Si le contrôle échoue, la sonde de vivacité lance un nouveau pod et y démarre l’application.
6) Définir les demandes et les limites de ressources
Les demandes de ressources précisent les ressources minimales qu’un conteneur peut utiliser, tandis que les limites de ressources indiquent les ressources maximales.
Sans demandes ni limites de ressources, les pods d’un cluster peuvent utiliser davantage de ressources que nécessaire. Si le pod commence à consommer davantage de CPU ou de mémoire sur le nœud, le planificateur peut ne plus être en mesure de placer de nouveaux pods. Le nœud lui-même peut même tomber en panne.
Pour les demandes comme pour les limites, il est courant de définir le CPU en millicœurs. La mémoire est définie en mégaoctets ou en mébioctets.
7) Utiliser des images de conteneurs plus petites
Les images de base peuvent être constituées jusqu’à 80 % de paquets et de bibliothèques inutiles. Utilisez plutôt des images de conteneurs plus petites, comme les images Alpine, qui sont 10 fois moins volumineuses que les images de base. Elles nécessitent moins d’espace de stockage et vous aideront à extraire et à construire l’image plus rapidement. En outre, plus l’image du conteneur est petite, moins le risque de problèmes de sécurité est élevé. Vous pouvez ensuite ajouter les paquets et bibliothèques nécessaires à l’exécution de votre application.
8) Superviser les composants du plan de contrôle
Supervisez la charge de travail, la consommation de ressources et les performances des composants du plan de contrôle, notamment l’API Kubernetes, kubelet, etcd, controller-manager, kube-proxy et kube-dns. Cela permettra d’identifier les problèmes et les menaces au sein du cluster, ainsi que d’accroître sa latence.
Vous devez également utiliser des outils de supervision automatisés plutôt que de gérer manuellement les alertes.
9) Utiliser la mise à l’échelle automatique
Tirez parti des mécanismes de mise à l’échelle automatique de Kubernetes pour adapter automatiquement la taille des services du cluster en cas de hausse de la consommation de ressources.
La mise à l’échelle horizontale automatique des pods ajuste automatiquement le nombre de pods d’un déploiement, d’un contrôleur de réplication, d’un jeu de réplicas ou d’un jeu avec état en fonction de l’utilisation estimée du CPU.
La mise à l’échelle verticale automatique des pods recommande les valeurs appropriées pour les demandes et les limites de CPU et de mémoire. Elle peut également mettre automatiquement ces valeurs à jour.
La mise à l’échelle automatique du cluster augmente ou réduit la taille du pool de nœuds workers. Elle ajuste la taille d’un cluster Kubernetes en fonction de son utilisation actuelle.
10) Adopter GitOps
Utilisez GitOps, un workflow basé sur Git, comme modèle privilégié afin d’utiliser Git comme source unique de vérité pour toutes les automatisations, y compris les pipelines CI/CD. L’utilisation d’un framework GitOps peut améliorer la productivité en accélérant le développement des applications et en réduisant les délais de déploiement. Elle peut également améliorer la traçabilité des erreurs et automatiser les workflows CI/CD.
11) Superviser l’utilisation des disques
Comme une utilisation élevée des disques peut affecter les performances du cluster, vous devez surveiller régulièrement tous les volumes de disque associés à votre cluster, ainsi que le système de fichiers racine. Grâce à la supervision des alertes, vous pourrez prendre des mesures correctives en augmentant la capacité ou en libérant de l’espace disque lorsque cela est nécessaire.
12) Commencer par des applications sans état
Avec un back-end sans état, les équipes de développement peuvent s’assurer qu’il n’existe pas de connexions persistantes qui compliquent la mise à l’échelle. L’utilisation d’un modèle sans état permet également aux développeurs de déployer des applications plus efficacement, sans interruption de service.
Les applications sans état facilitent la migration et la mise à l’échelle lorsque cela est nécessaire, en fonction des besoins de l’entreprise.
À lire également : Les principales entreprises de l’edge computing
Bonnes pratiques Kubernetes : autorisation et authentification
13) Mettre en place un contrôle d’accès basé sur les rôles
Pour renforcer la sécurité de vos workloads Kubernetes, activez le contrôle d’accès basé sur les rôles (RBAC) de Kubernetes. RBAC est généralement activé par défaut dans Kubernetes 1.6 et les versions ultérieures. Comme Kubernetes combine des contrôleurs d’autorisation, vous devez également désactiver le contrôle d’accès basé sur les attributs (ABAC) historique lorsque vous activez RBAC.
Attribuez des rôles à chaque utilisateur de votre cluster et à chaque compte de service exécuté dans celui-ci. Les rôles RBAC contiennent plusieurs autorisations qu’un utilisateur ou un compte de service peut exercer. Vous pouvez attribuer le même rôle à plusieurs personnes, et chaque rôle peut disposer de plusieurs autorisations. Les paramètres RBAC peuvent également s’appliquer aux espaces de noms. Si vous attribuez à un utilisateur un rôle autorisé dans un espace de noms, il n’aura pas accès aux autres espaces de noms du cluster. Kubernetes fournit des propriétés RBAC telles que le rôle et le rôle de cluster pour définir les politiques de sécurité.
14) Utiliser une authentification tierce pour le serveur d’API
Intégrez Kubernetes à un fournisseur d’authentification tiers afin de bénéficier de fonctionnalités de sécurité supplémentaires, comme l’authentification multifacteur. Cela permet également de garantir que kube-apiserver ne change pas lorsque vous ajoutez ou supprimez des utilisateurs. Dans la mesure du possible, veillez à ne pas gérer les utilisateurs au niveau du serveur d’API.
À lire également : DevOps, low-code et RPA : avantages et inconvénients
Bonnes pratiques Kubernetes : problèmes de sécurité
15) Utiliser des politiques réseau
Utilisez des politiques réseau pour restreindre l’accès aux services au sein d’un cluster Kubernetes. Elles peuvent également restreindre l’accès à l’API de métadonnées de votre cloud depuis les pods du cluster et contrôler le flux du trafic au niveau de l’adresse IP ou du port.
Vous trouverez des informations sur la configuration d’une politique réseau dans la documentation Kubernetes.
16) Ne pas s’exécuter en tant que root
L’UID (la chaîne générée par le système Kubernetes qui identifie de manière unique les objets) de l’utilisateur exécutant un conteneur est directement associé à l’hôte. Si le conteneur s’exécute avec l’UID 0 (root), il apparaîtra également comme root sur le nœud où il s’exécute.
Kubernetes intègre des protections pour empêcher l’élévation des privilèges via ce mécanisme. Cependant, il existe toujours un risque que des problèmes de sécurité permettent une élévation des privilèges. Évitez cette situation en n’exécutant pas vos conteneurs en tant que root. Modifiez plutôt le Dockerfile de vos conteneurs construits afin de créer et d’utiliser un utilisateur doté d’un UID connu.
17) Créer un pare-feu
Créez un pare-feu pour votre serveur d’API afin d’empêcher les attaquants d’envoyer des demandes de connexion à votre serveur d’API depuis Internet. Vous pouvez utiliser des règles de pare-feu classiques ou des règles de pare-feu au niveau des ports. Si vous utilisez une solution comme GKE, vous pouvez recourir à une fonctionnalité de réseau maître autorisé pour limiter les adresses IP pouvant accéder au serveur d’API.
18) Restreindre l’accès à l’API
La plupart des implémentations cloud de Kubernetes restreignent déjà l’accès à l’API Kubernetes de votre cluster au moyen de RBAC, d’Identity & Access Management (IAM) ou d’Active Directory (AD). Si votre cluster n’utilise pas ces méthodes, configurez-les à l’aide de projets open source permettant d’interagir avec différentes méthodes d’authentification.
19) Restreindre l’accès SSH
Une autre mesure de sécurité importante consiste à restreindre l’accès SSH à vos nœuds Kubernetes. En général, vous ne laissez pas le port 22 ouvert sur un nœud, mais vous pouvez en avoir besoin à un moment donné pour déboguer certains problèmes. Configurez vos nœuds via votre fournisseur cloud afin de bloquer l’accès au port 22, sauf via le VPN de votre organisation ou un hôte bastion. Vous pourrez obtenir rapidement un accès SSH, mais pas les attaquants externes.
20) Auditer les journaux de stratégie
Auditez régulièrement tous les journaux stockés dans /var/log/audit.log afin d’identifier les menaces, de surveiller la consommation de ressources et de capturer les battements de cœur des événements clés du cluster Kubernetes. Les politiques par défaut du cluster Kubernetes sont définies dans le fichier /etc/kubernetes/audit-policy.yaml. Vous pouvez les personnaliser en fonction de besoins spécifiques. Vous pouvez également utiliser Fluentd, un outil open source, pour maintenir une couche de journalisation centralisée pour vos conteneurs.
À lire également : Comment la virtualisation des bases de données aide à migrer un entrepôt de données vers le cloud
Bonnes pratiques Kubernetes : un apprentissage continu est nécessaire
Ces bonnes pratiques Kubernetes ne sont qu’une partie des nombreuses recommandations disponibles pour rendre Kubernetes plus facile à utiliser et plus utile dans le développement d’applications. Il reste néanmoins beaucoup à apprendre pour utiliser Kubernetes efficacement.
Cela peut sembler accablant pour les équipes de développement déjà submergées par les nombreuses tâches qu’impose le développement moderne d’applications ─ même avec le nombre croissant d’outils et de services conçus pour accélérer les processus concernés. Mais en commençant par ces conseils, vous serez bien engagé sur la voie qui vous permettra de faire progresser vos projets complexes de développement d’applications avec Kubernetes.
À lire également : Prévisions technologiques pour 2022 : cloud, données, cybersécurité, IA et plus encore
À propos de l’auteur :
Alexander Ivenin est responsable technique système chez ClearScale.