La plupart des ingénieurs ne veulent pas passer plus de temps que nécessaire pour maintenir leurs clusters hautement disponibles, sécurisés et rentables. Comment vous assurez-vous que votre cluster de moteurs Google Kubernetes est prêt pour les tempêtes à venir ?
Voici quatorze tactiques d’optimisation réparties en trois domaines principaux de votre cluster. Utilisez-les pour créer un cluster GKE économe en ressources et hautement disponible avec une sécurité hermétique.
Voici les trois sections principales de cet article :
- La gestion des ressources
- Sécurité
- La mise en réseau
Conseils de gestion des ressources pour un cluster GKE
1. Mise à l’échelle automatique
Utilisez les capacités d’autoscaling de Kubernetes pour vous assurer que vos charges de travail fonctionnent bien pendant les pics de charge et contrôler les coûts en période de charges normales ou faibles.
Kubernetes vous offre plusieurs mécanismes d’autoscaling. Voici un aperçu rapide pour vous mettre au courant :
- Autoscaler de pod horizontal: HPA ajoute ou supprime automatiquement des répliques de pod en fonction des métriques d’utilisation. Cela fonctionne très bien pour la mise à l’échelle des applications sans état et avec état. Utilisez-le avec Cluster Autoscaler pour réduire le nombre de nœuds actifs lorsque le nombre de pod diminue. HPA est également pratique pour gérer les charges de travail avec de courts pics d’utilisation élevée.
- Mise à l’échelle automatique des pods verticaux: VPA augmente et réduit les demandes de ressources CPU et mémoire des conteneurs de pods pour s’assurer que l’utilisation allouée et réelle du cluster correspond. Si votre configuration HPA n’utilise pas de processeur ou de mémoire pour identifier les cibles de mise à l’échelle, il est préférable de l’utiliser avec VPA.
- Mise à l’échelle automatique des clusters: il adapte dynamiquement le nombre de nœuds pour correspondre à l’utilisation actuelle du cluster GKE. Fonctionne parfaitement avec les charges de travail conçues pour répondre à une demande en constante évolution.
Bonnes pratiques d’autoscaling dans un cluster GKE
- Utiliser HPA, VPA et Node Auto Provisioning (NAP): En utilisant ensemble HPA, VPA et NAP, vous laissez GKE faire évoluer efficacement votre cluster horizontalement (pods) et verticalement (nœuds). VPA définit des valeurs pour le processeur, les demandes de mémoire et les limites des conteneurs, tandis que NAP gère les pools de nœuds et élimine la limitation par défaut de démarrage de nouveaux nœuds uniquement à partir de l’ensemble de pools de nœuds créés par l’utilisateur.
- Vérifiez si vos politiques HPA et VPA sont en conflit: assurez-vous que les politiques VPA et HPA n’interfèrent pas les unes avec les autres. Par exemple, si HPA s’appuie uniquement sur les métriques de CPU et de mémoire, HPA et VPA ne peuvent pas fonctionner ensemble. Examinez également vos paramètres de densité d’emballage lors de la conception d’un nouveau cluster GKE pour un niveau de service professionnel ou spécialisé.
- Utiliser les scores pondérés par instance: Cela vous permet de déterminer quelle part de votre pool de ressources choisi sera dédiée à une charge de travail spécifique et de vous assurer que votre machine est la mieux adaptée à la tâche.
- Réduisez les coûts avec une stratégie d’instances mixtes: L’utilisation d’instances mixtes permet d’obtenir une disponibilité et des performances élevées à un coût raisonnable. Il s’agit essentiellement de choisir parmi différents types d’instances, dont certaines peuvent être moins chères et suffisamment bonnes pour les charges de travail à faible débit ou à faible latence. Ou vous pouvez exécuter un plus petit nombre de machines avec des spécifications plus élevées. De cette façon, cela réduirait les coûts car chaque nœud nécessite l’installation de Kubernetes, ce qui ajoute toujours un peu de surcharge.
2. Choisissez la topologie de votre cluster GKE
Vous pouvez choisir parmi deux types de clusters :
- Topologie régionale: Dans un cluster Kubernetes régional, Google réplique le plan de contrôle et les nœuds sur plusieurs zones d’une même région.
- Topologie zonale: Dans un cluster zonal, ils s’exécutent tous les deux dans une seule zone de calcul spécifiée lors de la création du cluster.
Si votre application dépend de la disponibilité d’une API de cluster, choisissez une topologie de cluster régionale, qui offre une plus grande disponibilité pour l’API du plan de contrôle du cluster.
Étant donné que c’est le plan de contrôle qui effectue des tâches telles que la mise à l’échelle, le remplacement et la planification des pods, s’il devient indisponible, vous rencontrez des problèmes de fiabilité. D’autre part, les clusters régionaux ont des nœuds répartis sur plusieurs zones, ce qui peut augmenter votre trafic réseau entre zones et, par conséquent, les coûts.
3. Nœuds Bin Pack pour une utilisation maximale
Il s’agit d’une approche intelligente de l’optimisation des coûts de GKE partagée par l’équipe d’ingénierie de Delivery Hero.
Pour optimiser l’utilisation des nœuds, il est préférable d’ajouter des pods aux nœuds de manière compacte. Cela ouvre la porte à la réduction des coûts sans aucun impact sur les performances. Cette stratégie est appelée binpacking et va à l’encontre de Kubernetes qui favorise une distribution uniforme des pods entre les nœuds.
Source: Héros de la livraison
L’équipe de Delivery Hero a utilisé GKE Autopilot, mais ses limites ont obligé les ingénieurs à créer eux-mêmes le binpacking. Pour obtenir l’utilisation la plus élevée des nœuds, l’équipe définit un ou plusieurs pools de nœuds de manière à permettre aux nœuds d’inclure des pods de la manière la plus compacte (tout en laissant une certaine mémoire tampon pour le processeur partagé).
En fusionnant les pools de nœuds et en effectuant le binpacking, les pods s’intègrent plus efficacement dans les nœuds, aidant Delivery Hero à réduire le nombre total de nœuds d’environ 60 % dans cette équipe.
4. Mettre en œuvre le suivi des coûts
La surveillance des coûts est une partie importante de la gestion des ressources car elle vous permet de garder un œil sur vos dépenses et d’agir instantanément sur les alertes de pic de coûts.
Pour mieux comprendre vos coûts Google Kubernetes Engine, mettez en œuvre une solution de surveillance qui collecte des données sur la charge de travail de votre cluster, le coût total, les coûts divisés par étiquettes ou espaces de noms et les performances globales.
La mesure de l’utilisation de GKE vous permet de surveiller l’utilisation des ressources, de mapper les charges de travail et d’estimer la consommation des ressources. Activez-le pour identifier rapidement les charges de travail les plus gourmandes en ressources ou les pics de consommation de ressources.
Cette étape est le strict minimum que vous pouvez faire pour le suivi des coûts. Le suivi de ces 3 métriques est ce qui fait vraiment la différence dans la façon dont vous gérez vos ressources cloud : dépenses cloud quotidiennes, coût par processeur provisionné et demandé, et répartition des coûts historiques.
5. Utiliser des machines virtuelles Spot
Les machines virtuelles Spot sont une incroyable opportunité de réduction des coûts : vous pouvez obtenir une remise pouvant atteindre 91 % sur la tarification à l’utilisation. Le hic, c’est que Google peut récupérer la machine à tout moment, vous devez donc avoir une stratégie en place pour gérer l’interruption.
C’est pourquoi de nombreuses équipes utilisent des machines virtuelles ponctuelles pour les charges de travail tolérantes aux pannes et aux interruptions, telles que les tâches de traitement par lots, les bases de données distribuées, les opérations CI/CD ou les microservices.
Bonnes pratiques pour exécuter votre cluster GKE sur des VM Spot
- Comment choisir la bonne VM spot ? Choisissez un type de machine virtuelle spot légèrement moins populaire, il est moins susceptible d’être interrompu. Vous pouvez également vérifier sa fréquence d’interruption (le taux auquel cette instance a récupéré de la capacité au cours du mois précédent).
- Configurer des groupes de VM Spot: Cela augmente vos chances d’arracher les machines que vous voulez. Les groupes d’instances gérés peuvent demander plusieurs types de machines en même temps, en ajoutant de nouvelles machines virtuelles ponctuelles lorsque des ressources supplémentaires deviennent disponibles.
Bonnes pratiques de sécurité pour les clusters GKE
L’étude Red Hat 2022 sur l’état de Kubernetes et la sécurité des conteneurs a révélé que près de 70 % des incidents sont dus à des erreurs de configuration.
GKE sécurise votre cluster Kubernetes sur plusieurs couches, y compris l’image du conteneur, son environnement d’exécution, le réseau du cluster et l’accès au serveur d’API du cluster. Google recommande généralement de mettre en œuvre une approche en couches de la sécurité du cluster GKE.
Les aspects de sécurité les plus importants sur lesquels se concentrer sont :
- Authentification et autorisation
- Avion de contrôle
- Nœud
- Sécurité Internet
1. Suivez les repères de la CEI
Tous les domaines de sécurité clés font partie des références du Center of Internet Security (CIS), une collection de meilleures pratiques mondialement reconnue qui vous donne un coup de main pour structurer les efforts de sécurité.
Lorsque vous utilisez un service géré tel que GKE, vous n’avez pas le pouvoir sur tous les éléments de référence CIS. Mais certaines choses sont définitivement sous votre contrôle, comme l’audit, la mise à niveau et la sécurisation des nœuds de cluster et des charges de travail.
Vous pouvez soit parcourir les Benchmarks CIS manuellement, soit utiliser un outil qui effectue le travail de benchmarking pour vous. Nous avons récemment introduit un module de sécurité des conteneurs qui analyse votre cluster GKE pour vérifier les écarts de référence et priorise les problèmes pour vous aider à agir.
2. Mettre en œuvre le RBAC
Le contrôle d’accès basé sur les rôles (RBAC) est un composant essentiel pour gérer l’accès à votre cluster GKE. Il vous permet d’établir un accès plus précis aux ressources Kubernetes au niveau du cluster et de l’espace de noms, et de développer des politiques d’autorisation détaillées.
CIS GKE Benchmark 6.8.4 souligne que les équipes donnent la préférence au RBAC par rapport à l’ancien contrôle d’accès basé sur les attributs (ABAC).
Un autre benchmark CIS GKE (6.8.3) suggère d’utiliser des groupes pour gérer les utilisateurs. C’est ainsi que vous simplifiez le contrôle des identités et des autorisations et que vous n’avez pas besoin de mettre à jour la configuration RBAC chaque fois que vous ajoutez ou supprimez des utilisateurs du groupe.
3. Suivez le principe du moindre privilège
Assurez-vous d’accorder aux comptes d’utilisateurs uniquement les privilèges qui leur sont essentiels pour faire leur travail. Rien de plus que ça.
Le CIS GKE Benchmark 6.2.1 indique : Préfère ne pas exécuter les clusters GKE à l’aide du compte de service par défaut de Compute Engine.
Par défaut, les nœuds ont accès au compte de service Compute Engine. Cela est pratique pour plusieurs applications, mais ouvre la porte à plus d’autorisations que nécessaire pour exécuter votre cluster GKE. Créez et utilisez un compte de service à privilèges minimaux au lieu du compte par défaut et suivez le même principe partout ailleurs.
4. Renforcez la sécurité de votre plan de contrôle
Google met en œuvre le modèle de responsabilité partagée pour gérer les composants du plan de contrôle GKE. Pourtant, c’est vous qui êtes responsable de la sécurisation des nœuds, des conteneurs et des pods.
Le serveur d’API Kubernetes utilise une adresse IP publique par défaut. Vous pouvez le sécuriser à l’aide de réseaux autorisés et de clusters Kubernetes privés qui vous permettent d’attribuer une adresse IP privée.
Une autre façon d’améliorer la sécurité de votre plan de contrôle consiste à effectuer une rotation régulière des informations d’identification. Les certificats TLS et l’autorité de certification du cluster font l’objet d’une rotation automatique lorsque vous lancez le processus.
5. Protégez les métadonnées des nœuds
Les benchmarks CIS GKE 6.4.1 et 6.4.2 soulignent deux facteurs critiques qui peuvent compromettre la sécurité de votre nœud et vous incombent.
Kubernetes a déprécié le…